W 2019 rozmawiałem z dyrektorem IT banku regionalnego, który właśnie wdrożył system core banking. Projekt przekroczył budżet o 40 procent. Na retrospekcji wszyscy zgodnie stwierdzili: to wina vendora. Vendor dostarczył za późno, dokumentacja była niekompletna, wsparcie kiepskie. Klasyczna analiza przyczyn źródłowych zakończyła się po 15 minutach. Problem w tym, że pół roku później ten sam zespół wdrażał system CRM i historia się powtórzyła. Tym razem vendor był inny.
Root Cause Analysis w teorii brzmi jak instrukcja obsługi pralki. W praktyce to raczej rozmowa z kimś, kto nie chce przyznać, że zapomniał wysypać proszku.
Nie szukaj jednej przyczyny, bo jej nie ma
Pierwsza zasada RCA, którą wszyscy znają i nikt nie stosuje: problem ma zazwyczaj więcej niż jedną przyczynę źródłową. W książce “The Fifth Discipline” Peter Senge opisywał to jako myślenie systemowe. Organizacje to sieci zależności, nie liniowe sekwencje zdarzeń. Ale w 12-osobowym zespole IT łatwiej powiedzieć “nie dostaliśmy dostępu do środowiska testowego”, niż przyznać, że nikt nie sprawdził, czy ktoś o ten dostęp w ogóle poprosił trzy tygodnie temu.
W zespołach, które pracują pod presją deadline’u, RCA zamienia się w zabawę w gorącego ziemniaka. Kto zostanie z problemem w ręku, jak muzyka przestanie grać? W metodyce Scrum jest coś, co nazywa się Sprint Retrospective. To moment, w którym zespół ma rozmawiać o tym, co poszło nie tak. W praktyce wygląda to jak oglądanie przez dziadków wnuków grających w piłkę: wszyscy wiedzą, że coś się dzieje, ale nikt nie chce wchodzić na boisko.
Pytaj “dlaczego” pięć razy, jeśli masz czas
Technika Five Whys pochodzi z Toyoty, lata 50. XX wieku. Taiichi Ohno używał jej na linii produkcyjnej. Pytasz “dlaczego” kolejny raz, aż dotrzesz do prawdziwej przyczyny. W fabryce samochodów działa to świetnie, bo maszyna albo stanęła, albo nie. W projekcie IT masz 40 mikroserwisów, 12 integracji, 3 zespoły i jednego product ownera, który zmienił zdanie w połowie sprintu. Po trzecim “dlaczego” dostajesz odpowiedź: “bo tak jest w architekturze”. Po czwartym: “bo architekt wyjechał na urlop”. Po piątym: “bo nikt nie zapytał go przed urlopem”.
Widziałem zespół, który zrobił Five Whys na poważnie. Deployment padł w piątek o 18:00. W poniedziałek rano zrobili warsztat. Po godzinie doszli do wniosku, że problem zaczął się 8 miesięcy wcześniej, kiedy ktoś w dziale zakupów wybrał najtańszą ofertę na monitoring. Nikt nie sprawdził, czy integruje się z ich CI/CD. Przez 8 miesięcy nikt tego nie zauważył, bo monitorowali tylko produkcję, a nie staging. Czyli naprawdę pięć razy “dlaczego” działa. Tylko że trzeba mieć odwagę dotrzeć do końca.
Nie obwiniaj ludzi, obwiniaj proces (ale to ludzie go wymyślili)
Root Cause Analysis ma jedną świętą zasadę: nie szukamy winnych, szukamy przyczyn. To brzmi pięknie na szkoleniu z ITIL Foundation. W rzeczywistości każdy proces zaprojektował ktoś konkretny, zaakceptował ktoś inny, a wdrożył jeszcze ktoś trzeci. Kiedy proces zawodzi, za nim stoją ludzie, którzy podjęli decyzje. Ale mówienie “proces był zły” jest bezpieczniejsze niż “Jan źle zaprojektował proces”.
W zespole, który znam, deployment approval wymagał zgody trzech osób: tech leada, product ownera i release managera. Release manager miał zwyczaj zatwierdzać wszystko automatycznie, bo “nie chciał blokować zespołu”. Tech lead sprawdzał kod, ale nie testy. Product owner nigdy nie patrzył na technical details. Proces był, checklist był, ale każdy element tego procesu zakładał, że ktoś inny zrobi swoją część. Kiedy deployment padł, RCA wskazało: “brak właściwego review”. Nie wskazało, że wszyscy trzej zignorowali swoje obowiązki, bo to by oznaczało konflikt.
Zbieraj dane, ale wiedz, że ludzie kłamią
Kolejna zasada RCA: zbierz dane zanim zaczniesz analizować. Logi, metryki, timeline, decyzje. Problem w tym, że w środowisku IT dane zawsze są niepełne. Ktoś nie logował, ktoś wyłączył verbose mode, żeby nie zapchać dysku, ktoś zrestartował środowisko, zanim ktokolwiek zdążył zapisać stan. A nawet jak masz wszystkie dane, to ludzie i tak opowiedzą swoją wersję, która jakoś zawsze wygląda lepiej niż to, co mówią logi.
Widziałem post-mortem po awarii systemu płatniczego, w którym developer twierdził, że deployment zrobił o 14:00. Logi mówiły 13:47. 13 minut różnicy. Ale w tym oknie ktoś inny zrobił zmianę w konfiguracji. Developer nie pamiętał, bo “to była rutynowa akcja”. I teraz masz dwa zdarzenia w tym samym czasie, żadne oficjalnie nie zaplanowane, oba “rutynowe”. RCA pokazało: brak change management. Ale prawdziwy problem był inny: wszyscy robili zmiany bez zgłaszania, bo proces zgłoszeń był na tyle upierdliwy, że łatwiej było go ominąć.
Znajdź przyczynę, ale zignoruj kontekst organizacyjny
Ostatnia zasada, której nikt nie wymienia wprost: RCA działa, o ile nie dotkniesz polityki. Możesz znaleźć przyczynę techniczną, procesową, nawet ludzką. Ale jeśli przyczyna to “dyrektor zarządu kazał skrócić projekt o 3 miesiące, bo obiecał zarządowi”, to RCA się kończy. Nikt nie napisze w raporcie: “root cause: dyrektor podjął decyzję bez konsultacji z zespołem”. Zamiast tego będzie: “zbyt optymistyczne szacunki”, “niedostateczna analiza ryzyka”, “brak eskalacji”.
Clayton Christensen w “The Innovator’s Dilemma” pisał o tym, jak organizacje same sobie kopią grób, podejmując racjonalne decyzje w lokalnym kontekście. RCA w projekcie IT często odkrywa racjonalne decyzje, które w sumie dały irracjonalny wynik. Ale powiedzenie tego na głos oznacza przyznanie, że system nie działa. A system to ludzie na stanowiskach, którzy mają wpływ na to, czy dostaniesz budżet na kolejny projekt.
Zdjęcie: Jakub Zerdzicki / Pexels
