W licznych przypadkach rozwiązanie incydentu jest procesem złożonym, który wymaga znacznego zaangażowania personelu IT. W nawiązaniu do raportu „2014 State of On-Call Report”, większość firm twierdzi, że średni czas rozwiązania incydentu (średni czas naprawy) waha się w przedziale 10-30 minut i do rozwiązania wymaga uwagi 5 osób. Tak wysoka utylizacja zasobów w bieżące utrzymanie i wsparcie systemów informatycznych jest bardzo kosztowna. Czy można temu jakoś zaradzić? Czy można skrócić średni czas naprawy incydentów (ang. Mean Time To Repair)?

Tak wysokie zużycie zasobów prowadzi jednocześnie do opisywanego wcześniej problemu – „keep-the-lights-on„. Konieczność zaangażowania wielu zasobów do utrzymania poprawnego działania systemów skraca tym samym czas, który mógłby być w pełni poświęcony na realizację projektów rozwojowych. Zachodzi zatem konieczność zadania sobie pytania, w jaki sposób można:

  1. Przyspieszyć czas rozwiązywania incydentu;
  2. Zmniejszyć ilość potrzebnych zasobów do rozwiązania incydentu.

Wszystkie te działania będą się bardzo mocno koncentrować na skróceniu miary – średni czas naprawy,  zdefiniowanej w ramach procesu zarządzania dostępnością (ang. Availability Management) w zakresie naprawialności (ang. maintainability).

Średni czas naprawy zależy od szybkości procesowania incydentów

ITIL definiuje incydent (ang. incident), jako nieplanowaną przerwę w usłudze informatycznej lub obniżenie jakości usługi informatycznej. Awaria elementu konfiguracji (CI), który nie wpłynął jeszcze negatywnie na usługę, również jest incydentem, na przykład: awaria jednego z dysków dublowanych w klastrze. Za poprawne zarządzanie incydentami będzie odpowiadać proces zarządzania incydentami. Mniej formalne stwierdzenie mówi, że proces zarządzania incydentami, ma na celu jak najszybsze rozwiązanie incydentów IT (w czasie rzeczywistym).

Bez względu na przyjętą definicję, cały proces zarządzania incydentami, począwszy od alarmu aż po rozwiązanie, może się znacząco wydłużać w czasie. Nie pozostaje to bez wpływu na MTTR – średni czas naprawy. Płynne, efektywne przejścia pomiędzy kolejnymi etapami cyklu życia incydentów będzie bezpośrednio wpływać na średni czas naprawy.

Kolejne etapy w cyklu życia incydentu, mające bezpośredni wpływ na średni czas naprawy:

  1. Alarm;
  2. Powiadomienie;
  3. Badanie;
  4. Diagnoza;
  5. Rozwiązanie;
  6. Dokumentacja

Alarm

Otrzymałem wiadomość, że coś poważnego właśnie się dzieje…

Rozbijając cykl życia incydentu na poszczególne fazy, okaże się, że faza pierwsza wymaga najmniejszej porcji czasu na „zaalarmowanie”. Na podstawie danych zebranych od klientów, VictorOps szacuje, że ta faza zajmuje ok. 5% czasu całego cyklu. Taki mały udział jest związany z coraz to lepszymi sposobami alarmowania o zdarzeniach infrastrukturalnych. Inteligentne systemy wykrywania zdarzeń, efektywniejsze kanały komunikacji – to wszystko przełożyło się na skrócenie czasu w tej fazie. Oczywiście – celem jest dążenie do 0.

Powiadomienie

Wiem, że mamy problem, ale nie mam żadnego pojęcia, na co lub na kogo ma on wpływ…

Jest to ta faza cyklu życia incydentu, która może dostarczyć sporo stresu. Dla kogoś, kto ma podnieść słuchawkę i zadzwonić do osoby, która może w tym czasie spać (np. o 4 nad ranem) może być to nieco kłopotliwe i z pewnością powoduje chwile zawahania. Tej fazie poświęcone jest 18% czasu . Oznacza to, że od otrzymania alertu, mija 18% czasu ,zanim uda się nawiązać kontakt z osobą, która zajmie się zgłoszeniem. Problemem tutaj bywa często brak dostatecznej ilości informacji o zdarzeniu, więc znalezienie odpowiedniego zespołu/osoby może zająć trochę czasu.

Inteligentne kierowanie zdarzeń może przyspieszyć tę fazę. Odciąży personel od konieczności podejmowania decyzji o tym, kto powinien podjąć stosowne akcje. Oczywiście wykonanie telefonu nadal będzie czynnością wymagającą czasu, ale zaoszczędzimy go na zastanawianiu się, czy osoba, do której chcemy zadzwonić, jest tą właściwą.

Badanie

Potrzebuję pomocy z zagłębieniem się w ten problem…

40% średniego czasu naprawy jest poświęcone na badanie zgłoszenia. Wymaga ono od osoby wielotorowego myślenia: z jednej strony wykrywanie potencjalnych przyczyn; z drugiej zaś – analiza informacji pod kątem najbardziej prawdopodobnych powodów. Ta faza zawiera w sobie również fazę logowania do systemów, sprawdzanie logów czy systemów monitorujących. Bardzo często sięga się tutaj do bazy wiedzy – artykułów, wiki, FAQ. Jest to szukanie igły w stogu siana… (wybacz za porównanie).

Ustrukturyzowane i kompletne powiadomienia mogą znacząco skrócić czas na badanie sprawy. Im więcej informacji zawrzemy (dobrze byłoby, gdyby jakość również szła z nimi w parze), tym lepiej. Pozostanie w ciągłym kontakcie z osobą, od której otrzymaliśmy powiadomienie może również wpłynąć na skrócenie czasu. Czat, wiadomości, telefony. Jak widać, warto poświęcić swoją uwagę tej fazie, gdyż na niej(teoretycznie) możemy zaoszczędzić najwięcej.

Diagnoza

Ok, jak to teraz mam naprawić?

Gdy już wiadomo gdzie jest problem, można przejść do znalezienia właściwej odpowiedzi – rozwiązania. Oczywiście łatwiej pisze się o tym, niż faktycznie wygląda to w rzeczywistości. Osoby rozwiązujące będą wspierać się wewnętrznymi dokumentacjami różnego rodzaju, wiki, czy też własnym doświadczeniem. Jak można zredukować 15% średniego czasu potrzebnego w tej fazie? Jeżeli do każdego alarmu można byłoby dołożyć informację o potencjalnych przyczynach i sposobach rozwiązania (w oparciu o bazę wiedzy), to z pewnością udałoby się mocno ograniczyć czas w tej fazie.

Rozwiązanie

Ratuję świat…

Faza ta zajmuje ok 10% średniego czasu naprawy, który potrzebny jest zespołowi/osobie na rozwiązanie incydentu. Redukcja w tej fazie będzie przede wszystkim związania z dokumentowaniem rozwiązań. Sednem będzie budowanie bazy wiedzy, o którą oprzemy nasze starania w redukowaniu MTTR (średni czas naprawy).

Dokumentacja

Po tym jak incydent zostanie rozwiązany, najlepsze praktyki nakazują dokumentację działań i rozwiązania. Takie podejście gwarantuje, że przy następnym wystąpieniu tego samego zdarzenia, personel IT zostanie ukierunkowany na potencjalne przyczyny i możliwe rozwiązania. Element uczenia się (w oparciu o istniejące materiały) to klucz do redukcji średniego czasu naprawy, bo im bardziej kompetentny i doświadczony zespół będziemy posiadać, tym szybciej będziemy mogli rozwiązywać napływające zgłoszenia i incydenty.

Podsumowanie

Każdy z punktów bezpośrednio dotykał trzech procesów: zarządzania zdarzeniami, incydentami i wiedzą. Można byłoby zatem odnieść wrażenie, że (głównie) dzięki tym dwóm procesom będziemy mogli znacząco skrócić średni czas naprawy. Cóż – tak! Ale efektywnie działające procesy wymagają dużego wysiłku również z innych stron. Te dwa procesy zazębiają się z innymi procesami, a także otrzymują i przekazują informacje zwrotne.

Zatem idąc po łańcuszku zależności pomiędzy procesami, dojdziemy do ostatecznego wniosku, by zredukować średni czas naprawy potrzebny jest wysiłek całej organizacji, nie tylko osób biorących udział w tych trzech procesach.

 

Źródło: 2014 State of On-Call Report