Pierwsza godzina awarii: kto prowadzi, co komunikować i co wycofać

Poniedziałek, 8:40. Księgowość zgłasza, że system ERP zwraca błąd po zalogowaniu. Trzech administratorów zaczyna szukać przyczyny niezależnie od siebie, każdy w innym miejscu. Telefon w dziale IT dzwoni bez przerwy, a kierownictwo dowiaduje się o awarii od użytkowników. Po 40 minutach ktoś zauważa, że o 7:55 wdrożono nową konfigurację aplikacji. Wycofanie zmiany trwa pięć minut.

W małym zespole czas trwania awarii rzadko zależy od trudności problemu technicznego. Zależy od tego, czy ktoś prowadzi, czy użytkownicy wiedzą, co się dzieje, i czy pierwszym pytaniem było „co się zmieniło”. Ten wpis to plan pierwszej godziny dla zespołu dwu- lub kilkuosobowego, z szablonami do skopiowania.

Minuta 0: potwierdź awarię i wyznacz prowadzącego

Pierwszy krok to potwierdzenie, że problem jest rzeczywisty i szerszy niż jedno stanowisko: drugi użytkownik, druga lokalizacja, alert w monitoringu. Potem pada jedno zdanie, które zmienia tryb pracy: „ogłaszam awarię, prowadzę ja”.

Prowadzący nie musi być najbardziej doświadczoną osobą w zespole. Jego zadaniem jest koordynacja, komunikacja i notatki, a nie diagnoza. Zasada, która działa w małych zespołach: pierwsza osoba, która potwierdzi awarię, prowadzi, dopóki wyraźnie nie przekaże tej roli komuś innemu.

Rola	Zadania	W zespole dwuosobowym
Prowadzący	decyzje, komunikaty, notatki, pilnowanie czasu	osoba A
Diagnozujący	zakres, ostatnie zmiany, wycofanie, testy	osoba B
Kontakt z użytkownikami	zbieranie zgłoszeń, odpowiadanie odsyłaczem do komunikatu	prowadzący albo helpdesk

Od tej chwili wszystko, co dotyczy awarii, dzieje się w jednym miejscu: jednym wątku na czacie zespołu albo jednym dokumencie. Ustalenia z rozmów telefonicznych prowadzący przepisuje tam od razu.

Minuta 5: ustal zakres

Zanim ktokolwiek zacznie naprawiać, zespół odpowiada na cztery pytania: kogo dotyczy problem (wszystkich, jednej lokalizacji, jednej grupy), których systemów, od kiedy dokładnie (godzina z monitoringu lub dziennika, a nie z pierwszego zgłoszenia) i co nadal działa. To, co działa, zawęża poszukiwania równie skutecznie jak to, co nie działa.

Objaw	Pierwsze podejrzenie
Jedna aplikacja nie działa dla wszystkich	ostatnie wdrożenie, certyfikat, baza danych, brak miejsca na dysku
Wiele systemów naraz w jednej lokalizacji	łącze, przełącznik, DNS, zasilanie
Nie działa logowanie do wielu usług	kontrolery domeny, DNS, czas systemowy, wygasłe hasło konta serwisowego
Wszystko działa, ale wolno	magazyn danych, trwające zadanie kopii, nasycone łącze
Problem występuje tylko poza biurem	VPN, publiczny DNS, certyfikat bramy

Minuta 15: pierwszy komunikat

Pierwszy komunikat wychodzi najpóźniej po 15 minutach, nawet jeśli zespół nie wie jeszcze nic o przyczynie. Użytkownicy nie potrzebują diagnozy, tylko informacji, że problem jest znany, kto się nim zajmuje i kiedy będzie kolejna wiadomość.

[AWARIA] <system>, od <godzina>

Co nie działa: <objaw z perspektywy użytkownika, np. błąd po zalogowaniu do ERP>
Kogo dotyczy: <wszyscy / lokalizacja / dział>; nie dotyczy: <jeśli wiadomo>
Obejście: <np. faktury wystawiamy ręcznie według instrukcji z intranetu> albo: brak
Zajmuje się: zespół IT, prowadzi <imię i nazwisko>
Następna informacja: o <godzina, np. 9:30>, także jeśli nic się nie zmieni

Prosimy nie zgłaszać tego problemu osobno.

Kolejne komunikaty wychodzą w zapowiedzianym rytmie, zwykle co 30 minut. Komunikat „bez zmian, pracujemy dalej, następna informacja o 10:00” jest lepszy niż cisza, bo cisza generuje telefony, które zabierają czas diagnozującym.

Minuta 15–30: co się zmieniło

Większość awarii w małym środowisku ma przyczynę w zmianie: wdrożeniu, aktualizacji, zmianie konfiguracji, wygaśnięciu certyfikatu lub hasła. Dlatego pierwsze pytanie diagnozującego brzmi „co się zmieniło w ostatnich godzinach”, a nie „dlaczego to nie działa”.

Na serwerach Windows zmiany zostawiają ślady w dzienniku System:

# 19: zainstalowana aktualizacja; 1074: restart lub wyłączenie zlecone przez proces albo użytkownika
# 7040: zmiana typu uruchamiania usługi; 7045: zainstalowana nowa usługa
Get-WinEvent -FilterHashtable @{
    LogName   = 'System'
    Id        = 19, 1074, 7040, 7045
    StartTime = (Get-Date).AddHours(-6)
} | Select-Object TimeCreated, Id, ProviderName, @{ Name = 'Opis'; Expression = { ($_.Message -split "`n")[0] } }

Ten sam blok uruchomiony przez Invoke-Command -ComputerName srv-app-01, srv-app-02 -ScriptBlock { ... } sprawdza kilka serwerów jednocześnie.

W klastrze Kubernetes pierwszym źródłem są zdarzenia, posortowane od najstarszych do najnowszych:

kubectl get events -A --sort-by=.lastTimestamp
kubectl rollout history deployment/erp-api -n erp

Zdarzenia są domyślnie przechowywane przez godzinę, więc po dłuższym czasie trzeba ich szukać w centralnym systemie logów, jeśli są tam przesyłane.

W repozytorium infrastruktury i w Argo CD widać, co i kiedy zostało wdrożone:

git log --all --since="6 hours ago" --date=iso --pretty=format:"%h %ad %an %s"
argocd app history erp

argocd app history pokazuje identyfikator, datę i rewizję każdej synchronizacji. Jeśli rewizja z 7:55 poprzedza pierwsze zgłoszenie o kilka minut, hipoteza jest gotowa.

Najpierw wycofaj, potem szukaj przyczyny

Jeśli w oknie przed awarią była zmiana, jej wycofanie jest pierwszym działaniem, a nie ostatnią deską ratunku. Przywrócenie usługi jest celem pierwszej godziny; zrozumienie przyczyny jest celem przeglądu po awarii.

Zmiana	Wycofanie	Uwagi
Wdrożenie przez GitOps	`git revert <commit>` i synchronizacja	historia w repozytorium pozostaje kompletna
Aktualizacja Windows	`wusa /uninstall /kb:<numer>`	pakiety łączone z aktualizacją stosu obsługi usuwa się przez `DISM /Online /Remove-Package`
Zmiana w zasadach grupy	`Restore-GPO` z kopii albo wyłączenie łącza GPO	stacje widzą zmianę po odświeżeniu zasad
Zmiana na maszynie z checkpointem	przywrócenie checkpointu	utrata zapisów od chwili utworzenia checkpointu
Reguła zapory, rekord DNS	przywrócenie poprzedniej wartości	wymaga zapisanej poprzedniej wartości

W modelu GitOps wycofaniem jest revert w repozytorium. argocd app rollback działa tylko przy wyłączonej automatycznej synchronizacji i zostawia aplikację niezgodną z repozytorium, więc nadaje się na sytuację, w której nie ma dostępu do repozytorium.

Wyjątki są dwa: zmiany, których nie da się cofnąć (migracja schematu bazy, dane już przetworzone przez nową wersję), oraz sytuacje, w których wycofanie jest bardziej ryzykowne niż awaria. Wtedy decyzję podejmuje prowadzący i zapisuje ją w notatkach.

Notatki z godzinami

Prowadzący zapisuje każde ustalenie i każde działanie z godziną i inicjałami osoby. Notatki służą do trzech rzeczy: komunikatów, przekazania prowadzenia i przeglądu po awarii.

08:41 MK  Zgłoszenie z księgowości: ERP zwraca błąd 502 po zalogowaniu.
08:44 MK  Potwierdzone na dwóch stanowiskach i z sieci serwerowej. Awaria ogłoszona, prowadzi MK.
08:52 MK  Pierwszy komunikat wysłany: e-mail do wszystkich, SMS do kierowników.
08:55 PW  argocd app history erp: synchronizacja o 07:55, zmiana puli połączeń (a1b2c3d).
09:01 PW  git revert a1b2c3d wypchnięty, synchronizacja zakończona 09:04.
09:07 MK  Księgowość potwierdza: logowanie działa. Obserwacja do 09:40.
09:10 MK  Komunikat: usługa przywrócona, przyczyna w analizie.

Kiedy eskalować

Progi eskalacji ustala się przed awarią, żeby w jej trakcie nie dyskutować, czy „już pora”.

Sytuacja	Do kogo	Kiedy
Brak hipotezy po 30 minutach	druga osoba z zespołu, dostawca systemu	po upływie progu
Awaria usługi dostawcy lub chmury	zgłoszenie u dostawcy z najwyższym priorytetem, równolegle z diagnozą	w pierwszych 15 minutach
Podejrzenie incydentu bezpieczeństwa: szyfrowanie plików, nieznane konta, nietypowe logowania	kierownictwo i procedura reagowania na incydenty; maszyny odłączać od sieci, nie wyłączać	natychmiast
Możliwe naruszenie ochrony danych osobowych	inspektor ochrony danych; zgłoszenie do organu nadzorczego w ciągu 72 godzin	natychmiast
Czas awarii przekracza RTO systemu	kierownictwo, decyzja o trybie awaryjnym	po przekroczeniu RTO

Krótki przegląd po awarii

W ciągu kilku dni roboczych zespół spotyka się na 30–45 minut. Celem nie jest znalezienie winnego, tylko ustalenie, co sprawiło, że awaria trwała tyle, ile trwała, i co skróci następną.

Awaria:             <system>, <data>, <od–do>, łącznie <czas>
Wpływ:              <kogo dotyczyła, co nie działało, czy były straty danych>
Oś czasu:           <z notatek: wykrycie, ogłoszenie, komunikat, hipoteza, wycofanie, potwierdzenie>
Przyczyna:          <bezpośrednia i ta, która na nią pozwoliła>
Co zadziałało:      <np. revert w 6 minut, komunikat w 11 minut>
Co nie zadziałało:  <np. nikt nie wiedział o wdrożeniu o 07:55>
Zadania:            <działanie>, <odpowiedzialny>, <termin>

Zadania z przeglądu trafiają do zwykłej listy zadań zespołu, z terminem. Przegląd bez zadań jest tylko rozmową.

Sprawdź u siebie

Ostatnio zainstalowane aktualizacje na kilku serwerach, bez logowania na każdy z nich:

Invoke-Command -ComputerName srv-app-01, srv-app-02 -ScriptBlock {
    Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 3 HotFixID, InstalledOn
} | Format-Table PSComputerName, HotFixID, InstalledOn

Dobry wynik to lista, którą da się zestawić z kalendarzem zmian. Jeśli zebranie odpowiedzi na pytanie „co się zmieniło w ostatniej dobie” zajmuje więcej niż kilka minut, w czasie awarii zajmie znacznie więcej.

Ostrzeżenia w klastrze w ostatniej godzinie:

kubectl get events -A --field-selector type=Warning --sort-by=.lastTimestamp

W spokojnym dniu lista powinna być krótka i zrozumiała. Długa lista powtarzających się ostrzeżeń, których nikt nie wyjaśnia, w czasie awarii ukryje to jedno ważne.

Stan synchronizacji aplikacji w Argo CD:

argocd app list

Dobry wynik: wszystkie aplikacje mają STATUS Synced i HEALTH Healthy. Aplikacja trwale OutOfSync oznacza zmiany wprowadzone poza repozytorium, których „git log” w czasie awarii nie pokaże.