Po recovery: zielone wykresy to nie koniec

Najpierw potwierdzić stan

Po recovery trzeba sprawdzić, czy system naprawdę wrócił do działania.

Nie tylko czy endpoint odpowiada 200.

Trzeba sprawdzić ścieżki, które były dotknięte awarią.

zapisy
odczyty
workery
kolejki
cron jobs
integracje
cache
raporty
alerty

Jeżeli przełączaliśmy bazę, trzeba potwierdzić, że wszystkie klienty używają nowego endpointu.

Jeżeli zatrzymaliśmy workery, trzeba je świadomie włączyć.

Jeżeli zamroziliśmy zapisy, trzeba wiedzieć, kiedy zostały odmrożone.

Jeżeli porzuciliśmy dane po target time, trzeba zapisać, co dokładnie zostało utracone.

Bez tego zespół ma tylko poczucie ulgi.

Nie ma potwierdzonego stanu systemu.

Odtworzyć timeline

Postmortem zaczyna się od osi czasu.

Nie od winnego.

Nie od jednej wielkiej przyczyny.

Najpierw trzeba zbudować chronologię.

kiedy zaczęła się awaria
kiedy system ją wykrył
kiedy człowiek ją zobaczył
kiedy podjęto decyzję
kiedy zatrzymano pogłębianie szkody
kiedy rozpoczęto recovery
kiedy przywrócono działanie
kiedy potwierdzono poprawny stan

Timeline ujawnia prawdę o RTO.

Jeżeli samo odtworzenie trwało 25 minut, ale decyzja zajęła godzinę, procedura nie mieści się w 25 minutach.

Jeżeli alert pojawił się po 40 minutach, recovery techniczne mogło być dobre, ale detekcja była słaba.

Jeżeli zespół czekał na dostęp do sekretów, problemem jest operacyjna gotowość, nie baza danych.

Sprawdzić RPO

Po recovery trzeba policzyć realną utratę danych.

jaki był target time
kiedy zatrzymano zapisy
jakie dane powstały między tymi momentami
co udało się odzyskać
co trzeba odtworzyć ręcznie
co uznajemy za utracone

To powinno trafić do notatki z incydentu.

Nie po to, żeby dramatyzować.

Po to, żeby sprawdzić, czy deklarowane RPO było prawdziwe.

Jeżeli organizacja mówiła o RPO 15 minut, a realnie straciła dwie godziny danych, to nie jest drobna różnica.

To informacja o architekturze, backupach, detekcji albo decyzjach.

Poprawić runbook

Runbook po incydencie zwykle wygląda inaczej niż przed incydentem.

To normalne.

Podczas recovery wychodzą rzeczy, których nie dało się zobaczyć w dokumencie.

brakowało komendy
link prowadził do starego panelu
uprawnienia miała tylko jedna osoba
walidacja była nieprecyzyjna
nie było listy workerów
nie było decyzji, kto przełącza ruch
nie było planu dla danych po target time

Te poprawki trzeba zrobić szybko.

Nie za miesiąc.

Pamięć operacyjna paruje bardzo szybko po incydencie.

Najlepszy moment na poprawienie runbooka jest wtedy, kiedy zespół nadal pamięta, gdzie bolało.

Dodać test odtworzeniowy

Backup, którego nikt nie odtworzył, jest hipotezą.

Po incydencie warto dopisać najprostszy test:

weź ostatni backup
odtwórz do wskazanego momentu
uruchom aplikację testowo
sprawdź kilka krytycznych zapytań
zmierz czas
zapisz wynik

To nie musi być od razu pełny drill disaster recovery.

Lepszy mały, powtarzalny test niż wielki dokument, którego nikt nie uruchamia.

Z czasem można dodać więcej:

test sekwencji
test integralności
test logowania
test zapisu zamówienia
test workerów
test przełączenia endpointu

Recovery jest umiejętnością.

Umiejętności nie powstają od samego posiadania instrukcji.

Postmortem bez teatru

Dobry postmortem powinien odpowiedzieć na kilka pytań.

co się stało
jaki był wpływ
jak to wykryliśmy
co zrobiliśmy
co zadziałało
co nie zadziałało
co zmieniamy
kto jest właścicielem zmian
do kiedy

Nie chodzi o to, żeby znaleźć osobę, która kliknęła zły przycisk.

Chodzi o to, żeby system był mniej zależny od idealnych ludzi.

Jeżeli jedna komenda mogła usunąć produkcyjne dane bez blokady, problemem nie jest tylko osoba.

Problemem jest brak guardrail.

Jeżeli decyzja o PITR trwała godzinę, problemem nie jest tylko stres.

Problemem jest brak wcześniejszych progów decyzyjnych.

Koniec serii, początek praktyki

Proste recovery składa się z kilku nudnych elementów:

znane pojęcia
kompatybilne migracje
backup, który da się odtworzyć
WAL albo binlog
lista klientów bazy
plan przepięcia ruchu
runbook
test odtworzeniowy
postmortem

Żaden z tych elementów nie jest spektakularny.

Razem robią różnicę między improwizacją a kontrolowanym powrotem do działania.

To jest cała magia.

Czyli żadna.