Odzyskiwanie po awarii wspomagane przez AI

Twój główny region właśnie zgasł w trakcie wdrożenia. Kanał on-call płonie, status page nadal świeci na zielono, bo nikt go nie zaktualizował, a kierownictwo chce ETA, którego nie masz. Twój runbook to strona w Confluence ostatnio edytowana czternaście miesięcy temu, która odwołuje się do hosta Postgresa wycofanego z użycia na wiosnę.

Odzyskiwanie po awarii to ten jeden obszar, gdzie „dokumentację napiszemy później” po cichu zamienia się w „straciliśmy sześć godzin i sporą porcję danych klientów”. Dobra wiadomość: powolne, żmudne części DR — pisanie precyzyjnych runbooków PITR, tworzenie eksperymentów chaosu, które faktycznie weryfikują Twoje RPO, i przekuwanie chaotycznej osi czasu incydentu w bezwinny post-mortem — to dokładnie to, w czym narzędzia AI do kodowania są dobre, o ile zakotwiczysz je w prawdziwych narzędziach i utrzymasz człowieka przy bramce zatwierdzania.

Co z tego wyniesiesz

• Gotowy prompt do wklejenia, który zamienia Twój stos technologiczny w runbook odzyskiwania do punktu w czasie (PITR) dla Postgresa z jawnymi celami RTO/RPO i weryfikacją łańcucha WAL
• Schedule w Chaos Mesh, który co tydzień ubija pod główny bazy danych i weryfikuje failover w ramach 5-minutowego RPO — wygenerowany, a nie wklepywany z pamięci
• Trójnarzędziowy przepływ pracy (Cursor / Claude Code / Codex) do trzymania artefaktów DR w kontroli wersji i ich ponownej walidacji w CI
• Prompt, który tworzy bezwinny post-mortem na podstawie Twoich rzeczywistych logów i osi czasu
• Krótką listę trybów awarii, które po cichu rozwalają plany DR, oraz sposób na ich wyłapanie zanim zrobi to katastrofa

Najpierw zdefiniuj cele odzyskiwania

Każdy artefakt DR poniżej zależy od dwóch liczb dla każdego poziomu usług: RTO (jak długo do przywrócenia usługi) i RPO (ile danych możesz sobie pozwolić stracić). Zapisz je jawnie, zanim cokolwiek wygenerujesz — runbook celujący w „szybkie odzyskiwanie” jest bezużyteczny; ten celujący w „RTO 15 min, RPO 5 min dla płatności” jest testowalny.

Realistyczna macierz startowa wygląda tak:

Poziom	Przykładowe usługi	RTO	RPO	Podejście do kopii zapasowych
Krytyczny	uwierzytelnianie, płatności	15 min	0–5 min	Replika synchroniczna/strumieniowa + archiwizacja WAL
Wysoki	główne API	1 godzina	5 min	Archiwizacja WAL + częste kopie bazowe
Średni	funkcje drugorzędne	4 godziny	1 godzina	Migawki co godzinę
Niski	narzędzia wewnętrzne	24 godziny	24 godziny	Kopie zapasowe dzienne

Notatka

Dobierz model do zadania. Użyj Claude Fable 5 (/model fable) do przemyślenia planu failover między wieloma regionami, gdzie kolejność zależności i kompromisy w utracie danych wymagają najwyższej jakości rozumowania; Claude Opus 4.8 do tego samego rodzaju zadań, gdy budżet jest ograniczony; Claude Sonnet 4.6 do rutynowych edycji runbooków i poprawek YAML; oraz Codex na GPT-5.5 do zadań w chmurze, które generują i walidują infrastrukturę-jako-kod względem sklonowanego repozytorium. Szczegóły cenowe znajdziesz w porównaniu modeli.

Przepływ pracy: wygeneruj prawdziwy runbook PITR

Najcenniejszym artefaktem DR dla większości zespołów jest runbook odzyskiwania do punktu w czasie dla Postgresa, który inżynier on-call może wykonać o 3 nad ranem bez zastanawiania się. Wzorzec, który faktycznie działa na produkcji, to archiwizacja WAL plus zewnętrzne narzędzie do kopii bazowych — pgBackRest lub WAL-G — a nie funkcja plpgsql po stronie serwera. Odzyskiwanie PITR ustawia restore_command i recovery_target_time oraz polega na nieprzerwanym łańcuchu WAL między kopią bazową a docelowym momentem.

Niech Twoje narzędzie AI napisze runbook na podstawie Twojej faktycznej konfiguracji, a nie generycznego szablonu:

Wskazówka

Prompt do wklejenia — wygeneruj runbook PITR dla Postgresa:

Write a point-in-time-recovery runbook for our Postgres 16 primary,
backed up with pgBackRest to S3 (stanza name: prod-main).

Targets: RTO 15 minutes, RPO 5 minutes.

The runbook must:
1. List exact pgBackRest commands to find the latest full backup whose
   stop time is at or before a given target timestamp.
2. Verify the WAL chain is intact from that base backup to the target
   time, and explicitly fail closed if there is a gap.
3. Show the recovery.signal + postgresql.auto.conf settings
   (restore_command, recovery_target_time, recovery_target_action=promote).
4. Include a post-restore verification step: row counts on the three
   highest-value tables and a check that the latest archived WAL segment
   is replayed.
5. Be a numbered checklist a sleep-deprived on-call can follow, with the
   one irreversible step (promote) called out and gated behind explicit
   confirmation.

Output as Markdown. Do not invent flags — use only real pgBackRest and
Postgres options.

Czytaj to, co wygeneruje, krytycznie. Dwie rzeczy, które AI najczęściej tu psuje, to wymyślanie flag pgBackRest i prześlizgiwanie się nad sprawdzeniem luki w łańcuchu WAL — czyli dokładnie ta awaria, która zostawia Cię na lodzie w trakcie odzyskiwania. Jeśli jakaś komenda wygląda nieznajomo, sprawdź ją w pgbackrest --help, zanim trafi do runbooka.

Gdzie pasuje każde z narzędzi

Sam runbook jest identyczny niezależnie od narzędzia — to plik Markdown w Twoim repozytorium. Różni się to, jak sterujesz generowaniem i jak utrzymujesz go w zgodzie z rzeczywistością w czasie.

Cursor

Otwórz runbook w edytorze i użyj trybu agenta, aby Cursor mógł odczytać Twój faktyczny pgbackrest.conf, docker-compose.yml i pliki migracji jako źródło prawdy, zamiast zgadywać nazwy hostów i nazwy stanz. Iteruj w miejscu: gdy któryś krok wygląda źle, zaznacz go i poproś Cursor o poprawienie tylko tego kroku. Użyj checkpointu, zanim pozwolisz mu ruszyć wiele plików, żeby jednym kliknięciem cofnąć złe przepisanie.

To najszybsza pętla, gdy konfiguracja DR żyje w tym samym repozytorium, które edytujesz, i chcesz widzieć różnice na bieżąco.

Claude Code

Użyj trybu headless, aby ponownie generować i walidować runbook jako część zaplanowanego ćwiczenia DR lub sprawdzenia przed wydaniem, tak by nigdy po cichu nie zgnił:

claude -p "Read infra/pgbackrest.conf and ops/runbooks/pitr.md. \
Verify every pgBackRest flag in the runbook exists in this version, \
and that the stanza name matches the config. List any drift as a \
checklist of fixes. Exit non-zero if the runbook references a host or \
stanza not present in the config." \
  --allowedTools "Read,Grep"

Wepnij to w cotygodniowy zadanie CI. Czerwony build oznacza, że Twój runbook rozjechał się z rzeczywistością — czyli dokładnie wtedy, gdy chcesz się o tym dowiedzieć, a nie w trakcie awarii. Flaga --allowedTools "Read,Grep" utrzymuje sprawdzenie w trybie tylko do odczytu, więc może działać bez nadzoru.

Codex

Przekaż całe zadanie do Codex Cloud: daj mu repozytorium i zadanie w stylu „regenerate ops/runbooks/pitr.md from the current pgBackRest config and open a PR”. Działając na GPT-5.5, pracuje w izolowanym środowisku na sklonowanej kopii, więc może wygrepować prawdziwą konfigurację, ponownie wygenerować runbook i wypchnąć branch do przeglądu, nie dotykając Twojej maszyny.

Do pracy lokalnej codex w worktree trzyma zmiany DR odizolowane od Twoich gałęzi funkcji, a jego integracja z GitHubem może otworzyć PR do zatwierdzenia przez człowieka.

Uwaga

Runbook PITR jest tyle wart, ile łańcuch WAL, który za nim stoi. Klasyczna cicha awaria: archive_command zwraca sukces, podczas gdy bucket archiwum ma regułę cyklu życia, która wygasiła starsze segmenty, zostawiając lukę nie do przeskoczenia przez Twoje odzyskiwanie. Spraw, by krok weryfikacji w runbooku faktycznie wylistował zarchiwizowane segmenty i potwierdził ciągłość — nie ufaj temu, że „kopie zapasowe są zielone”.

Kopie zapasowe reszty stosu

Baza danych to rzadko cała historia. W przypadku obciążeń hostowanych na Kubernetes, Velero tworzy kopie zapasowe zasobów klastra i wolumenów trwałych i jest standardowym narzędziem, do którego skonfigurowania warto poprosić asystenta AI — a nie wymyślonym wewnętrznym serwisem kopii zapasowych.

Wskazówka

Prompt do wklejenia — wygeneruj harmonogram kopii zapasowych Velero:

Generate a Velero Schedule manifest that backs up the "payments" and
"auth" namespaces every 6 hours, snapshots their PersistentVolumes,
excludes Secrets of type kubernetes.io/service-account-token, and sets
a 30-day TTL. Then give me the exact `velero backup describe` and
`velero restore create` commands to validate a restore into a scratch
namespace. Use only real Velero CRD fields and CLI flags.

W przypadku magazynu obiektów i zarządzanych baz danych preferuj natywną replikację między regionami dostawcy oraz funkcje point-in-time (na przykład automatyczne kopie zapasowe RDS z PITR czy replikację międzyregionalną S3 / S3 Cross-Region Replication) zamiast budowania własnych rozwiązań. Poproś narzędzie AI o wygenerowanie Terraform dla nich, a następnie przejrzyj ten IaC tak samo, jak przejrzałeś runbook.

Notatka

Praca z DR dotyka wielu API chmurowych i to tam serwery MCP zarabiają na swoje miejsce. Z podłączonym serwerem MCP AWS lub Cloudflare wszystkie trzy narzędzia mogą odczytać Twoje faktyczne reguły cyklu życia bucketów i regiony replik zamiast zgadywać — zamieniając „wygeneruj wiarygodną politykę kopii zapasowych” w „przeprowadź audyt mojej prawdziwej i powiedz, gdzie jest luka w RPO”. Konfiguracja MCP jest identyczna w Cursor, Claude Code i Codex: zarejestruj serwer raz i odwołuj się do niego z dowolnego z nich.

Testowanie: ćwiczenia chaosu, które weryfikują Twoje RPO

Nieprzetestowany plan DR to hipoteza. Najtańszym sposobem na ciągłe testowanie failover jest zaplanowany eksperyment Chaos Mesh, który ubija pod główny bazy danych i sprawdza, czy system odzyskuje się w ramach zadeklarowanych celów. CRD Schedule (apiVersion: chaos-mesh.org/v1alpha1) uruchamia PodChaos typu pod-kill według crona.

Wskazówka

Prompt do wklejenia — wygeneruj cotygodniowe ćwiczenie failover:

Write a Chaos Mesh Schedule (apiVersion chaos-mesh.org/v1alpha1) that:
- runs every Saturday at 03:00 (cron "0 3 * * 6")
- uses type "PodChaos" with action pod-kill, mode one
- targets pods with label app=postgresql-primary
- sets concurrencyPolicy Forbid and historyLimit 5

Then write a follow-up runbook (Markdown) describing how I assert the
drill passed: how to confirm the standby was promoted, how to measure
actual recovery time against a 15-minute RTO, and how to measure
replication lag at kill time against a 5-minute RPO. Use only real
Chaos Mesh CRD fields.

Wygenerowany manifest to łatwiejsza połowa. Runbook, który definiuje zaliczenie/niezaliczenie względem Twojego RTO/RPO, to ta połowa, która nadaje ćwiczeniu sens — bez niego po prostu ubijasz pody i masz nadzieję. Potraktuj przekroczone RTO w sobotnim ćwiczeniu jako zgłoszenie P2, a nie ciekawostkę.

1. Uruchom ćwiczenie w klastrze stagingowym, który odzwierciedla topologię produkcyjną, nigdy na żywym ruchu klientów.

2. Przechwytuj oś czasu automatycznie: moment ubicia, moment promocji, pierwszy udany zapis do nowego węzła głównego.

3. Porównaj zmierzone RTO/RPO z celami i załóż zgłoszenie dla każdego przekroczenia.

4. Wprowadź logi z ćwiczenia prosto do promptu post-mortem poniżej, aby luki zamieniły się w elementy do działania, zamiast zostać zapomniane do poniedziałku.

Gdy dzieje się naprawdę: playbook z bramką dla człowieka

Gdy faktycznie jesteś w trakcie incydentu, AI najlepiej wykorzystać do wygenerowania i zwalidowania kolejnego działania — nigdy do odpalania nieodwracalnych komend wprost z dowolnego tekstu. Trzymaj człowieka przy bramce zatwierdzania dla wszystkiego, co promuje replikę, przekierowuje DNS lub wyłącza zapisy.

Wskazówka

Prompt do wklejenia — triage żywej awarii regionalnej:

We have lost us-east-1. Read ops/runbooks/pitr.md and infra/dns.tf.

Produce an ordered recovery checklist to fail payments, auth, and the
core API over to us-west-2, where each step states: the exact command,
whether it is reversible, and what to verify before moving on. Flag
every irreversible step (replica promotion, DNS cutover, disabling
writes in the failed region) as REQUIRES HUMAN APPROVAL. Do not run
anything — output the checklist only.

W scenariuszu ransomware obowiązuje ta sama dyscyplina: użyj narzędzia, by znaleźć ostatnią czystą kopię zapasową sprzed zaszyfrowania i naszkicować reguły izolacji sieciowej, a następnie niech człowiek je wykona. Przydatne, konkretne wywołanie Claude Code:

claude -p "Given the pgBackRest backup catalog in this repo's logs/ \
directory and the file-modification timeline in incident/timeline.csv, \
identify the most recent backup whose stop time precedes the first \
encryption event, and explain how you ruled out later backups." \
  --allowedTools "Read,Grep"

Zwróć uwagę na formę headless claude -p oraz listę dozwolonych narzędzi tylko do odczytu: to analizuje i rekomenduje, nie odtwarza.

Gdy to się psuje

Nawet dobrze wygenerowany plan DR zawodzi w przewidywalny sposób. Uważaj na te przypadki:

• Luki w łańcuchu WAL. Reguły cyklu życia bucketów lub po cichu zawodzące archive_command wygaszają segmenty między kopią bazową a docelowym momentem. Odzyskiwanie przerywa się w połowie. Naprawa: runbook musi weryfikować ciągłość, a nie ją zakładać.
• Opóźnienie replikacji przekracza RPO w najgorszym momencie. Pod szczytem zapisów, który często poprzedza awarię, Twój standby zostaje w tyle o minuty. Promowanie go traci więcej danych, niż pozwala Twoje RPO. Naprawa: alertuj o opóźnieniu względem liczby RPO i niech krok failover sprawdza opóźnienie przed promocją.
• Failover, który gubi zapisy. Promujesz standby, ale stary węzeł główny nadal przyjmuje zapisy (split-brain) albo zapisy w locie nigdy się nie zreplikowały. Naprawa: pierwszym krokiem playbooka jest zawsze wyłączenie zapisów na uszkodzonym węźle głównym, przed promocją.
• Ćwiczenie przechodzi, prawdziwa rzecz zawodzi. Staging ma 3 węzły; produkcja ma 30 i inną topologię. Naprawa: uruchamiaj ćwiczenia względem klastra, który odzwierciedla skalę produkcji, i rotuj wstrzykiwaną awarię.
• AI wymyśla flagi lub pola. Wygenerowana flaga pgBackRest lub pole Chaos Mesh, które nie istnieje, czyni artefakt niewykonywalnym. Naprawa: zawsze waliduj wygenerowane komendy względem --help lub dokumentacji CRD przed commitem — traktuj wynik AI jako szkic, nigdy jako wyrocznię.

Zamykanie pętli: post-mortem

Incydent nie jest zakończony, dopóki nie uchwycisz nauki. AI jest naprawdę dobre w przekuwaniu chaotycznej osi czasu i ściany logów w ustrukturyzowany, bezwinny post-mortem — pod warunkiem, że nakarmisz je prawdziwymi artefaktami.

Wskazówka

Prompt do wklejenia — naszkicuj bezwinny post-mortem:

Draft a blameless post-mortem from the attached incident timeline and
logs (incident/timeline.csv, logs/incident-2026-06-05/).

Structure: one-paragraph executive summary, a minute-by-minute timeline,
root cause (distinguish trigger from underlying cause), customer impact
(duration, requests failed, estimated data loss), what went well, what
went wrong, and 3-5 concrete action items each with an owner role and a
priority. Keep it blameless: describe systems and decisions, never
individuals. Flag any place where the logs are insufficient to determine
what happened.

Uruchom to z Claude Fable 5 (/model fable), gdy łańcuch przyczynowy plącze się między usługami — jakość rozumowania jest warta kosztu na tym jednym dokumencie, który przeczytają wszyscy; jeśli budżet jest ograniczony, sięgnij po Opus 4.8. Trzymaj wynik w repozytorium obok runbooka, który ma usprawnić, aby następne ćwiczenie testowało względem wniosków z poprzedniego incydentu.

Co dalej

• Zgodność bezpieczeństwa — planowanie odzyskiwania zorientowane na bezpieczeństwo i wątek ransomware
• Testowanie wydajności — testowanie obciążeniowe systemów DR, zanim na nich polegniesz
• Monitorowanie i obserwowalność — alerty o opóźnieniu replikacji i kondycji kopii zapasowych, które wcześnie wyłapują luki DR
• Infrastruktura jako kod — utrzymywanie infrastruktury failover odtwarzalną i przejrzaną