Close

Poznaj Jira Service Management i inne zaawansowane narzędzia podczas wydarzenia Atlassian przedstawia: ITSM o wysokiej dynamice.

Zarejestruj się bezpłatnie

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.

Proces zarządzania incydentami według zasad DevOps

Podejście DevOps do zarządzania incydentami nie jest znacząco różne od tradycyjnej procedury skutecznego zarządzania incydentami. W zarządzaniu incydentami zgodnym z zasadami DevOps nacisk kładzie się na zaangażowanie zespołów programistycznych od samego początku — także w dyżury domowe — oraz na przypisywanie prac w oparciu o wiedzę, a nie zajmowane stanowiska.

1. Wykrywanie
Zamiast żywić (płonną) nadzieję, że do incydentu nigdy nie dojdzie, zespoły DevOps reagujące na incydenty przywiązują dużą wagę do odpowiedniego przygotowania. Pracują wspólnie, aby zaplanować reakcje na potencjalne incydenty, identyfikując słabości w obrębie systemów. Konfigurują narzędzia do monitorowania, systemy powiadamiania i opracowują wykazy procedur, które ułatwią każdemu członkowi zespołu ustalenie, z kim ma się skontaktować w razie wykrycia incydentu i jakie kolejne kroki podjąć.

2. Reagowanie
Zamiast wyznaczać jednego inżyniera pełniącego dyżur domowy i odpowiedzialnego za reagowanie na wszystkie incydenty, które wystąpią na jego zmianie, zespoły DevOps zarządzające incydentami wyznaczają wielu członków, którzy są dostępni w przypadku eskalacji. Jeśli wyznaczony inżynier pełniący dyżur domowy nie jest w stanie samodzielnie rozwiązać incydentu, może skorzystać z wykazu procedur w charakterze przewodnika. Taki inżynier może zaangażować odpowiednie osoby do oceny wpływu i poziomu ważności problemu, a także eskalować go do właściwych osób reagujących.

3. Rozwiązywanie
Gdy przychodzi czas reakcji na incydent, zespołom DevOps zarządzającym incydentami często udaje się szybko opracować rozwiązanie. Dzieje się tak dlatego, że zespół jako całość lepiej zna kod aplikacji lub systemu — ponieważ to jego członkowie go napisali. A dzięki wcześniejszemu przygotowaniu i dobrym systemom komunikacji członkowie zespołu wspólnie wykonują pracę pozwalającą rozwiązać incydent, przez co rozwiązanie powstaje szybciej niż w przypadku reakcji podejmowanych przez zespół zewnętrzny, który widzi kod po raz pierwszy.

4. Analiza
Zespoły DevOps zarządzające incydentami zamykają incydent procesem analizy post-mortem bez wskazywania winnych. Zbierają się wspólnie, aby podzielić się informacjami, wskaźnikami oraz wnioskami z myślą o ciągłym ulepszaniu odporności systemów oraz szybkim i sprawnym rozwiązywaniu przyszłych incydentów.

5. Gotowość
Po rozwiązaniu incydentu, wykonaniu wszystkich kroków koniecznych do usunięcia jego skutków oraz przywróceniu systemu zespoły DevOps zarządzające incydentami cofają się o krok w celu oceny gotowości na kolejny incydent. Przyglądają się wnioskom wynikającym z przeprowadzonej analizy post-mortem, aktualizują wykazy procedur oraz wprowadzają konieczne poprawki w narzędziach do monitorowania i systemach powiadamiania. Koncentracja zespołów DevOps na ciągłym doskonaleniu odnosi się także do ludzi i zespołu, nie tylko technologii. Po zakończeniu incydentu każdy członek zespołu jest lepiej przygotowany na kolejny.

Najlepsze praktyki dla skutecznych zespołów DevOps zarządzających incydentami

Przyjęcie podejścia DevOps w przypadku reagowania na incydenty może poprawić komunikację między zespołami programistycznymi a zespołami ds. eksploatacji IT, skrócić czas reakcji na incydent i jego naprawienia oraz wzmocnić odporność systemu.

Automatyzacja procesów i przepływów pracy
Zintegruj narzędzia centrum obsługi, do monitorowania, obsługi zgłoszeń, CMDB / zarządzania zasobami oraz czatu, aby usprawnić obsługę alertów i przepływów pracy związanych z incydentami IT oraz upewnić się, że właściwe osoby otrzymują powiadomienia z informacjami potrzebnymi do przystąpienia do opracowania rozwiązania. Przygotuj wykazy procedur zawierające wstępnie zdefiniowane przepływy pracy, aby użytkownicy mogli szybko przystąpić do działania, gdy dojdzie do incydentu.

Komunikacja międzyzespołowa
Zapewnij członkom zespołów możliwość komunikacji na poziomie całej organizacji przy użyciu narzędzi czatu w czasie rzeczywistym. Wykorzystaj narzędzia do utworzenia rejestru incydentu, aby każdy mógł w dowolnej chwili dołączyć i szybko zorientować się, co się stało i jakie działania podjęto.

Zaniechanie wskazywania winnych
Po rozwiązaniu incydentu zbierzcie się jako zespół i przyjrzyjcie się zdarzeniu w trakcie sesji analizy post-mortem bez wskazywania winnych. Unikajcie wytykania palcami i skoncentrujcie się na dzieleniu się informacjami, które pomogą wszystkim lepiej realizować swoje zadania i przyczynią się do zapewniania większej niezawodności systemu.

Identyfikacja wyników biznesowych i koncentracja na ich osiąganiu
Reagowanie na incydenty według modelu DevOps nie ogranicza się do lepszej komunikacji. Jest sposobem zapewnienia współpracy programistów i osób zajmujących się eksploatacją systemów informatycznych w celu wypracowania autentycznej wartości biznesowej. Wskaźnik poprawy swojego zespołu możesz określić, obserwując wskaźniki, takie jak średni czas wykrycia (MTTD), średni czas naprawy (MTTR) czy średni czas między awariami (MTBF).

Harmonogram dyżurów domowych jako sposób na pełnienie przez programistów i administratorów systemów roli inżynierów SRE
W zespołach DevOps linia dzieląca programistów i administratorów systemów zaczyna się zacierać, a osoby reagujące na incydent często przyjmują rolę inżynierów ds. niezawodności lokalizacji (SRE). Wciąż poszczególne osoby prawdopodobnie będą mieć wiedzę specjalistyczną z zakresu kodu aplikacji albo kodu struktury. Opracuj harmonogram dyżurów domowych, aby mieć pewność, że osoby reagujące na incydenty będą razem miały odpowiedni zestaw umiejętności.

Dowiedz się więcej o tym, jak Jira Service Management może pomóc w zarządzaniu incydentami opartym na DevOps.

Następny
SRE