Co robisz, by ten sam rodzaj incidentu nie wydarzył się po raz drugi?

Question

Accepted Answer

Przeprowadź **bezobwiniający postmortem**, który znajduje systemową przyczynę, a następnie przekuj go w **konkretne, mające właściciela i śledzone** action itemy — i zweryfikuj, że faktycznie trafiają na produkcję. Celem nie jest znalezienie winnego; to zmiana systemu tak, by ta klasa porażki stała się niemożliwa lub samowykrywalna.

## Główna pętla

1. **Bezobwiniający postmortem.** Zbuduj szczerą oś czasu: co się stało, kiedy wykryliśmy, jak zareagowaliśmy, jaki był wpływ. Obwinianie zabija prawdę, której potrzebujesz.
2. **Dokop się do systemowej przyczyny**, a nie wyzwalacza. „Inżynier wypchnął zły config” to wyzwalacz; „nie było walidacji ani staged rolloutu dla configów” to przyczyna. Użyj **Five Whys**, ale zatrzymaj się na systemie, nigdy na osobie.
3. **Wygeneruj warstwy zapobiegania**, a nie pojedynczą poprawkę:
   - **Zapobiegaj** — uczyń porażkę niemożliwą (walidacja, typy, zabezpieczenia).
   - **Wykrywaj** — wyłap ją wcześniej (alerty, SLO, syntetyczne checki).
   - **Mityguj** — ogranicz promień rażenia (rollback, flagi, circuit breakery).
4. **Przydziel właścicieli i terminy.** Action item bez właściciela to życzenie. Śledź je jak prawdziwą pracę w backlogu.
5. **Zweryfikuj i zamknij pętlę.** Czy poprawka trafiła na produkcję? Czy wyłapałaby oryginał? Czy MTTR i wykrywanie faktycznie się poprawiły?

## Trade-offy i pułapki

- **Postmortemy, które produkują dokumenty, a nie zmiany** — najczęstsza porażka. Brak follow-through oznacza, że spotkasz ten sam incident ponownie.
- **Nadmierne naprawianie konkretnego objawu**, podczas gdy klasa buga pozostaje otwarta. Napraw kategorię, nie tylko ten przypadek.
- **Zmęczenie alertami** od nawarstwiania wykrywania bez strojenia; głośne alerty są ignorowane, a następny incident się prześlizguje.
- **Kultura obwiniania** spycha raportowanie do podziemia; tracisz near-missy, które są Twoimi najtańszymi lekcjami.
- Traktuj **powtarzające się incidenty jako sygnał porażki procesu**, a nie pecha — śledź nawrotowość jako metrykę.

## Dlaczego to ważne

Incidenty to czesne, które już zapłaciłeś; jedynym marnotrawstwem jest nieuczenie się z nich. Zespół, który systematycznie zapobiega nawrotom, staje się co kwartał bardziej niezawodny, podczas gdy zespół, który tylko gasi pożary, na zawsze przeżywa te same awarie. Zbudowanie tej pętli uczenia się — i bezpieczeństwa, by być w niej szczerym — jest jedną z najtrwalszych rzeczy, jakie Tech Lead może po sobie zostawić.