Shit happens…

Od czasu do czasu słyszymy o mniej lub bardziej spektakularnych awariach znanych aplikacji, jak choćby Facebook czy Instagram.

Powiedzmy sobie szczerze: nam też się to zdarza w naszej pracy. W końcu zdarza się najlepszym. Błąd na produkcji zaraz po wdrożeniu – kto tego nie doświadczył?

Why?

Zastanawialiście się kiedyś, jak to się dzieje? Jak to jest, że pomimo wielu godzin testów i litrów wylanego potu, przygotowywania strategii, planu testów, zdefiniowania scenariuszy, danych testowych, chuchania i dmuchania, w kilka godzin po wdrożeniu klient zgłasza błąd o najwyższym priorytecie?

Często wynikać to może z ograniczeń lub założeń jakie mamy podczas samego testowania. Jednym z najbardziej oczywistych jest czas, który może być niewystarczający, gdy wersja jest dostępna później niż zakładaliśmy. Termin wdrożenia nieprzesuwalny – kto tego nie słyszał? W pośpiechu łatwo coś pominąć i nieszczęście gotowe. A wiadomo…

„Gdzie się człowiek śpieszy, tam się diabeł cieszy”

Kolejną rzeczą jest niestabilne lub niepełne środowisko testowe (praca z wykorzystaniem mocków, stubów zamiast rzeczywistej infrastruktury). Zdarza się także, że nie mamy dostępu do danych produkcyjnych, a te generowane pod testy okazują się niewystarczające.

Czasami nasza wiedza biznesowa jest niepełna, co nie pozwala na weryfikację wszystkich możliwych przypadków. W szczególności tych brzegowych lub specyficznych. Oczywiście pojawiają się też błędy ludzkie – przeoczenia, omyłki. Wszak któż ich nie popełnia, niech pierwszy rzuci kamień.

What now?

Tak jak napisałem na wstępie – nawet najlepszym się zdarza. Warto jednak każdy taki przypadek przeanalizować i wyciągnąć wnioski na przyszłość. Z doświadczenia wiem, że dobre przyjrzenie się problemom i przygotowanie skrupulatnej analizy wystąpienia awarii (root cause analysis), może przełożyć się na szybkie podniesienie komfortu pracy. Już tłumaczę o co mi chodzi.

Otóż często dzieje się tak, że zgłaszane podczas trwania projektu ryzyka są ignorowane (akceptowane) przez klienta lub nawet przez ludzi z naszej organizacji. Wytłumaczenia są różne. Od „bo biznes klienta bardzo tego potrzebuje” – to odnośnie nieprzesuwalnego terminu do „bo to kosztuje” w przypadku właściwej infrastruktury lub kopiowania danych produkcyjnych.

Jeden fuck up może zmienić wiele

Ale to od nas zależy czy tak się stanie. Nie oznacza to, że zachęcam teraz do sabotowania pracy zespołu i celowego wywołania awarii. O, nie! Jednak wystąpienie takiej sytuacji należy wykorzystać możliwie jak najlepiej.

Wystąpienie issue na produkcji, może znacząco ułatwić uzyskanie tego wszystkiego, co przez miesiące było niemożliwe do osiągnięcia. Okazuje się często, że postawienie środowiska z prawdziwego zdarzenia możliwe jest w ciągu kilku godzin lub dni i to łącznie z zestawem danych produkcyjnych. Nagle każde zgłoszenie zagrożenia terminu wdrożenia i ryzyka z tym związane są słyszane przez klienta.

Wciąż pozostają jeszcze błędy ludzkie, niewystarczająca wiedza biznesowa, problemy komunikacyjne w zespole i wiele innych. Wszystko to musi zostać zidentyfikowane podczas root cause analysis i odpowiednie lekcje muszą zostać odrobione. To (i nie tylko to) powinno być wstępem do wprowadzenia usprawnień:

• w sposobie pracy całego zespołu projektowego,
• procesu zarządzania środowiskiem testowym i danymi testowymi,
• współpracy z klientem,
• wszelkich procesów wytwarzania oprogramowania jak i jego testowania,
• przebiegu samego wdrożenia.

Podsumowując

Problemy po wdrożeniu mogą przytrafić się każdemu. Ważne jest jednak to, co z tym zrobimy, żeby takie lub podobne błędy nie pojawiły się w przyszłości. Konieczne jest zastanowienie się nad tym co poszło nie tak i zidentyfikowanie przyczyn. Później pozostaje wdrożenie usprawnień i obserwowanie ich efektów.

Jakie jest twoje doświadczenie z błędami na produkcji? Co udało ci się dzięki nim ulepszyć lub zmienić? Podziel się swoją opinią w komentarzu.

* obrazek zaczerpnięty ze strony