Przywrócenie usługi nie oznacza rozwiązania problemu
Poniedziałek, 9:20. Przestaje działać jedna z kluczowych usług. Monitoring zgłasza problem, Service Desk zaczyna odbierać zgłoszenia, a do obsługi incydentu dołączają kolejne zespoły. Po kilkudziesięciu minutach udaje się znaleźć przyczynę, zastosować obejście i przywrócić działanie. Sytuacja opanowana. Użytkownicy wracają do pracy, liczba zgłoszeń spada, a incydent zostaje zamknięty.
Z operacyjnego punktu widzenia można uznać to za sukces. Szczególnie jeśli organizacja mierzy przede wszystkim czas reakcji, MTTR czy realizację SLA.
Miesiąc później sytuacja się powtarza. Ten sam komponent, podobne objawy, ponownie zaangażowane jest kilka zespołów i ponownie kilkadziesiąt minut niedostępności. Być może tym razem usługa zostaje przywrócona szybciej, bo zespół pamięta poprzednie rozwiązanie.
Tylko czy rzeczywiście jest to sukces?
Pierwszy incydent może być nieprzewidywalnym zdarzeniem technicznym. Drugi, wynikający z tej samej przyczyny, coraz częściej jest już problemem sposobu zarządzania operacjami.
Gaszenie pożaru jest potrzebne. Ale nie może być celem
Podczas krytycznego incydentu priorytet jest oczywisty: ograniczyć wpływ na biznes i jak najszybciej przywrócić usługę. Nie jest to najlepszy moment na wielogodzinną analizę przyczyn źródłowych. Presja czasu sprawia, że zespoły wykorzystują obejścia, restarty, przełączenia ruchu czy wycofanie ostatniej zmiany. I bardzo dobrze, właśnie tego oczekujemy od sprawnych operacji.
Problem zaczyna się jednak później. Po przywróceniu usługi presja znika. Zespół wraca do kolejnych zgłoszeń, projektów i zmian. Incydent zostaje opisany, zamknięty i po kilku dniach przestaje być tematem. Znane obejście zaczyna funkcjonować jako nieformalny sposób radzenia sobie z problemem. W ten sposób organizacja może stać się bardzo skuteczna w usuwaniu skutków, jednocześnie pozostając zaskakująco nieskuteczna w eliminowaniu ich przyczyn.
To jeden z paradoksów operacji IT: można poprawiać czas obsługi incydentów i jednocześnie nie poprawiać jakości usług.
Drugi incydent kosztuje więcej niż kolejne minuty niedostępności
Koszt powtarzającego się problemu nie ogranicza się do czasu, przez który system był niedostępny. Ponownie angażujemy Service Desk, administratorów, właścicieli aplikacji i menedżerów. Ponownie przerywamy ich zaplanowaną pracę. Ponownie biznes czeka na przywrócenie usługi, a użytkownicy szukają obejścia. Dochodzi do tego koszt znacznie trudniejszy do pokazania w raporcie – utrata zaufania.
Za pierwszym razem biznes może zaakceptować informację, że wydarzyła się trudna do przewidzenia awaria. Za trzecim czy czwartym razem pytanie nie brzmi już „co się stało?”, lecz „dlaczego znowu się to stało?”. I jest to trafne pytanie…
Jeżeli organizacja posiada historię incydentów, dane z monitoringu, CMDB, informacje o zmianach i wiedzę zespołów, każdy poważniejszy incydent powinien zwiększać jej wiedzę o własnym środowisku. Jeżeli tego nie robi, duża część wartości tych danych zostaje niewykorzystana.
Sprawdź, czego nauczyły Cię ostatnie incydenty
Dojrzałości operacyjnej nie mierzyłbym wyłącznie liczbą incydentów. W złożonym środowisku problemy będą występować niezależnie od jakości procesów i technologii. Znacznie ciekawsze jest sprawdzenie, ile z nich organizacja już wcześniej widziała.
Warto wziąć kilkadziesiąt istotniejszych incydentów z ostatnich miesięcy i poszukać podobieństw. Nie tylko identycznych kodów błędów, ale tych samych usług, komponentów, zależności, zmian poprzedzających awarię czy stosowanych obejść. Następnie warto sprawdzić, które z tych zdarzeń doprowadziły do trwałego działania naprawczego, a które zakończyły się wyłącznie przywróceniem usługi.
Taki prosty przegląd potrafi powiedzieć o jakości operacji więcej niż kolejny dashboard prezentujący liczbę zamkniętych ticketów. Problem Management nie powinien bowiem oznaczać tworzenia dodatkowej kolejki zgłoszeń. Jego wartość pojawia się wtedy, gdy wiedza z incydentów prowadzi do zmian w środowisku, monitoringu, architekturze lub sposobie świadczenia usług.
Dojrzałe IT powinno mieć coraz lepszą pamięć
Przez ostatnie miesiące pisaliśmy o CMDB, ITSM, zależnościach usługowych, monitoringu i odporności operacyjnej. Wszystkie te elementy mają znaczenie tylko wtedy, gdy pomagają organizacji podejmować lepsze decyzje.
Dojrzałość operacyjna nie oznacza środowiska, w którym nic się nie psuje. Takie środowisko nie istnieje. Oznacza organizację, która po każdym istotnym zdarzeniu wie o swoim IT trochę więcej niż wcześniej i potrafi tę wiedzę wykorzystać.
Dlatego po kolejnym poważnym incydencie warto spojrzeć nie tylko na czas przywrócenia usługi. Warto zadać znacznie trudniejsze pytanie: Co konkretnie zmienimy, żeby następnym razem ten incydent nie wydarzył się ponownie?
Jeżeli odpowiedzią jest wyłącznie „będziemy wiedzieli, jak szybciej go naprawić”, problem nadal istnieje.
Podsumowanie
Pierwszy incydent jest testem technologii. Powtarzający się incydent staje się testem organizacji.
Dojrzałe operacje nie kończą pracy w momencie, w którym dashboard ponownie świeci na zielono. Wykorzystują incydenty jako źródło wiedzy, eliminują powtarzalne przyczyny i stopniowo zmniejszają ryzyko kolejnych zakłóceń. Bo celem nie powinno być wyłącznie coraz szybsze gaszenie tych samych pożarów. Celem jest sprawić, żeby było ich coraz mniej.
W Ingrifo pomagamy organizacjom porządkować operacje IT, łączyć dane z różnych obszarów i wykorzystywać je do świadomego doskonalenia usług. Sprawdź, gdzie Twoje operacje mogą działać lepiej.
Dowiedz się więcej na:
ingrifo.com
