Zarządzanie incydentami dla dynamicznych zespołów
Zarządzanie incydentami w erze DevOps
Stosowanie zasad otwartej komunikacji bez wskazywania winnych w zespołach zarządzających incydentami
Nie można zmienić sposobu tworzenia, wdrażania i obsługi oprogramowania bez zmiany sposobu reagowania na incydenty.
W swoim przełomowym przemówieniu z 2009 roku, zatytułowanym „10+ Deploys Per Day: Dev and Ops Cooperation at Flickr” (Ponad 10 wdrożeń dziennie: współpraca zespołów programistycznego i operacyjnego w firmie Flickr) John Allspaw i Paul Hammond nakreślili wizję świata, w którym programiści i zespoły odpowiedzialne za eksploatację systemów informatycznych współpracują ze sobą i często przeprowadzają wydania. W ciągu następnej dekady ta wizja przybrała kształt ruchu DevOps.
Koncepcja DevOps opiera się na nowych sposobach reagowania na incydenty. Nie dziwi fakt, że Allspaw i Hammond w swoim wystąpieniu poświęcili tyle uwagi zarządzaniu incydentami.
„Ważne, aby zdać sobie sprawę, że kiedyś dojdzie do usterki” — wspomniał Hammond w swoim wystąpieniu. „Nie pytaj, czy do niej dojdzie, tylko — kiedy to się stanie”.
W przeciwieństwie do ram postępowania, takich jak ITIL, nie ma żadnego „oficjalnego” dokumentu zawierającego najlepsze praktyki dla zespołu DevOps. Można jednak ogólnie przyjąć, że podstawą DevOps jest dostarczanie wartości biznesowej organizacji przez przełamywanie barier izolacyjnych w organizacji, zwiększanie przejrzystości i wspieranie otwartej komunikacji między zespołami programistycznymi i odpowiedzialnymi za eksploatację IT.
Ta sama kultura przejrzystości, widoczności i szybkiego uczenia się ma również zastosowanie do zarządzania incydentami.
Dlaczego? Ponieważ pierwszymi i najważniejszymi krokami, które podejmuje się w ramach zarządzania incydentami, są ustalenie, co poszło nie tak, zaangażowanie do pracy nad problemem właściwych ludzi i promowanie kultury eliminującej szukanie winnych.
Zarządzanie incydentami według zasad DevOps wymaga kultury komunikacji, między zespołami programistycznymi i operacyjnymi, która jest otwarta i wolna od wskazywania winnych. Wymaga również opracowania uproszczonych procesów, które poprawią niezawodność usług IT, zwiększą zadowolenie klientów i podniosą wartość biznesową. Inżynier DevOps może pomóc we wdrożeniu praktyk i kultury DevOps.
Dla porównania, ITIL to zalecany zbiór 26 procesów, procedur, zadań i list kontrolnych opracowany w celu udoskonalenia określonych praktyk w dziedzinie zarządzania usługami IT. ITIL koncentruje się na zapewnianiu jakości i spójności usług, a także na poprawie odporności systemów.
Jedną z zalet ITIL jest fakt, że umożliwia organizacjom, które chcą udoskonalić swoje praktyki ITSM, rozpoczęcie od szablonowych najlepszych praktyk, a nie od zera. I choć niektórzy uważają, że ITIL najlepiej sprawdza się w przypadku dużych firm, te ramy postępowania są na tyle elastyczne, że mniejsze firmy mogą wybrać z nich procesy adekwatne do własnej działalności i znaleźć w nich coś wartościowego.
Wadą ITIL — jeśli starasz się szybko wprowadzić zmiany w swoim procesie reagowania na incydenty — jest to, że może wymagać formalnego zarządzania zmianami i udziału konsultanta specjalisty, co opóźni wprowadzenie ulepszeń.
W zespołach, które chcą zacząć od razu, podejście do zarządzania incydentami oparte na zasadach DevOps pomoże ich członkom zebrać się i przyniesie natychmiastowe korzyści.
Konfigurowanie harmonogramu dyżurów domowych za pomocą Opsgenie
W tym samouczku nauczysz się konfigurować harmonogram dyżurów domowych, stosować reguły zastępujące, ustawiać powiadomienia o dyżurach domowych oraz wykonywać inne czynności w Opsgenie.
Przeczytaj ten samouczekNajlepsze praktyki w zakresie informowania o incydentach
Informowanie o incydentach to proces powiadamiania użytkowników, że usługa doświadcza pewnego rodzaju przestoju lub obniżenia wydajności.
Przeczytaj ten artykuł