Podczas awarii problem techniczny rzadko jest tym trudnym. Trudna jest koordynacja. Oto sekwencja, która powstrzymuje mały zespół przed pogorszeniem sprawy.
Większość małych zespołów źle obsługuje swoją pierwszą poważną awarię — nie z niekompetencji, tylko dlatego, że wszyscy debugują jednocześnie, nikt nie rozmawia z klientami, a dwie osoby wdrażają sprzeczne poprawki. Poniższy playbook istnieje, żeby temu zapobiec.
Pierwsze dziesięć minut
- Ogłoś to. Powiedz słowo «incydent» na głos na kanale zespołu. Niejasność, czy to poważne, kosztuje więcej czasu niż jakikolwiek krok techniczny.
- Wyznacz prowadzącego incydent. Jedna osoba, wprost. Ona nie debuguje — koordynuje, decyduje i prowadzi oś czasu.
- Oceń zasięg rażenia: kogo dotyczy, czy pieniądze płyną błędnie, czy dane są zagrożone. To determinuje wszystko dalej.
- Zatamuj krwawienie, zanim znajdziesz przyczynę. Rollback, wyłączenie funkcji, strona serwisowa. Zrozumienie może poczekać; wpływ na klienta nie.
- Opublikuj komunikat o statusie. Nawet «badamy sprawę» bije milczenie — to milczenie zamienia awarię w problem zaufania.
Role, nawet w czteroosobowym zespole
| Rola | Robi | NIE robi |
|---|---|---|
| Prowadzący incydent | Decyduje, koordynuje, śledzi oś czasu | Debuguje — w chwili gdy zacznie, koordynacja się kończy |
| Badający | Znajduje i naprawia przyczynę | Rozmawia z klientami |
| Komunikacja | Aktualizuje status, klientów, zespół wewnętrzny | Publicznie spekuluje o przyczynie |
W małym zespole jedna osoba może pełnić dwie role — ale prowadzący incydent i badający nigdy nie mogą być tą samą osobą podczas poważnego incydentu.
Co mówić klientom
- Szybko potwierdź, nawet bez odpowiedzi — «wiemy o problemie i badamy go» w ciągu minut
- Opisz wpływ ich językiem: czego nie mogą teraz zrobić, a nie która usługa jest zdegradowana
- Podaj czas kolejnej aktualizacji i dotrzymaj go, nawet jeśli nic się nie zmieniło
- Nigdy nie spekuluj o niepotwierdzonej przyczynie — sprostowania kosztują więcej zaufania niż kosztowałoby milczenie
- Powiedz jasno, kiedy jest naprawione, a przy istotnym wpływie dołóż pisemne wyjaśnienie
Potem: część, którą wszyscy pomijają
Postmortem w ciągu 48 godzin, póki pamięć jest dokładna. Bez obwiniania — nie z uprzejmości, tylko dlatego, że obwinianie skłania ludzi do ukrywania informacji, a kolejnemu incydentowi trudniej wtedy zapobiec.
- Oś czasu: co się stało, kiedy, kto co zrobił — wyłącznie fakty
- Wpływ: czas trwania, dotknięci użytkownicy, konsekwencje pieniężne albo dla danych
- Czynniki współprzyczyniające, w liczbie mnogiej — jedna przyczyna źródłowa to niemal zawsze uproszczenie
- Zadania z właścicielami i datami; pozycje bez obu są dekoracją
- Co poszło dobrze — wykrycie albo reakcja, która zadziałała, warta jest wzmocnienia
Nie wznosisz się do poziomu swojego planu reagowania na incydenty. Spadasz do poziomu tego, który faktycznie przećwiczyłeś.
Przygotowanie, zanim się wydarzy
- Alerty na objawy, które czują klienci (nie działa płatność), a nie tylko metryki infrastruktury (wysoki CPU)
- Rollback będący jedną komendą i przećwiczony w spokojnych warunkach
- Strona statusu, która istnieje, zanim będzie potrzebna
- Spisana eskalacja: do kogo dzwonimy o 3 w nocy i do kogo, jeśli nie odbierze
- Jeden próbny przebieg — celowo zepsuj coś na stagingu i przejdź playbook
Potwierdź odtworzenie rzeczywistymi ścieżkami
Mniej błędów może ukrywać niespójne dane. Ustal wymagane dowody przed zamknięciem incydentu.
- Zapisz wpływ, ostatni poprawny stan i ostatnie zmiany.
- Wybierz odwracalne działanie z właścicielem i warunkiem zatrzymania.
- Sprawdź główne ścieżki, opóźnione zadania i uzgodnienie danych.
Najczęstsze pytania
Co zrobić najpierw, gdy produkcja padnie?
Ogłosić incydent i wskazać jedną osobę jako prowadzącego, a potem łagodzić zamiast diagnozować — rollback, wyłączenie zepsutej funkcji albo tryb serwisowy. Przywrócenie usługi jest pierwsze; zrozumienie przyczyny to zadanie na potem, gdy klienci znów pracują.
Czy powinniśmy od razu poinformować klientów?
Tak. Potwierdź w ciągu minut, opisz wpływ w kategoriach tego, czego nie mogą zrobić, i zobowiąż się do czasu kolejnej aktualizacji. Milczenie podczas awarii szkodzi zaufaniu bardziej niż sama awaria, a spekulacja, którą później prostujesz, jest gorsza od obu.
Czy potrzebujemy postmortem po każdym incydencie?
Przy wszystkim, co dotknęło klientów — tak, i powinien powstać w ciągu 48 godzin, póki pamięć jest wierna. Prowadź go bez obwiniania: zespoły przypisujące winę dostają mniej szczerych informacji, co czyni kolejny incydent bardziej, a nie mniej prawdopodobnym.
Czy zawsze wycofywać podejrzane wdrożenie?
Nie. Najpierw sprawdź zmiany danych i skutki zewnętrzne. Powrót kodu nie zawsze je odwraca i może pogorszyć incydent.
Jesteś właśnie w trakcie incydentu?
Robimy awaryjną reakcję techniczną — triage, złagodzenie, przyczyna źródłowa i postmortem po wszystkim.
Warto doczytać
Postmortem: dobre praktyki pisania takiego, który ktoś przeczyta
Większość postmortemów to archeologia: dokładny zapis czegoś, czego nikt nie zmieni. Użyteczny produkuje niewielką liczbę rzeczy, które faktycznie zostaną zrobione.
Audyt techniczny MVP: co sprawdzamy w pierwszych 48 godzinach
Większość audytów MVP kończy się dokumentem. Użyteczny kończy się decyzjami: co się pali, co może poczekać i ile kosztuje naprawa.