Odzyskiwanie po awarii z AI

Odzyskiwanie po awarii w pracy z agentami AI obejmuje dwa promienie rażenia: zmianę wypuszczoną przez agenta, cofaną checkpointami, odwracalnymi commitami, feature flagami i celowanymi revertami, oraz infrastrukturę pod spodem, odtwarzaną runbookami PITR, kopiami zapasowymi i przećwiczonym failoverem. Oba wymagają celów odtwarzania ustalonych z góry, prób, które je mierzą, i człowieka przy każdym nieodwracalnym kroku.

Ten przewodnik jest dla programisty, który ma dyżur, i dla tech leada odpowiedzialnego za plan odtwarzania usługi. Scenariusz, na który cię przygotowuje: agent refaktoryzuje moduł uwierzytelniania w 47 plikach, testy przechodzą, scalasz, a dwie godziny później API administracyjne przestaje walidować tokeny sesji, a na wierzchu leżą już trzy kolejne PR-y. Miesiąc później główny region gaśnie w trakcie wdrożenia, a runbook dla Postgresa wskazuje host wycofany wiosną.

Co wyniesiesz z tego planu odtwarzania po awarii

Tabelę celów odtwarzania (RTO i RPO dla każdego poziomu usług), dzięki której każdy kolejny artefakt da się przetestować
Ustawienia dla każdego narzędzia i dwa prompty, które utrzymują dużą zmianę agenta odwracalną commit po commicie
Procedurę „najpierw revert” dla scalonej zmiany agenta, która szkodzi produkcji, wraz z promptem, który ją prowadzi
Prompt generujący runbook odtwarzania Postgresa do punktu w czasie (PITR) z twojej prawdziwej konfiguracji pgBackRest oraz zaplanowane zadanie agenta tylko do odczytu, które zatrzymuje CI błędem, gdy runbook rozjedzie się z konfiguracją
Próbę failoveru w Chaos Mesh z kryteriami zaliczenia mierzonymi względem RTO i RPO oraz wskazaną osobą, która podpisuje wynik
Prompt do failoveru z bramką człowieka, prompt do post-mortemu bez szukania winnych i tryby awarii, które po cichu psują plany odtwarzania

Po jakiej awarii się podnosisz?

Zanim wybierzesz narzędzie, nazwij promień rażenia. Oba rodzaje awarii wymagają innej mechaniki, ale tej samej dyscypliny.

	Zmiana agenta	Infrastruktura
Promień rażenia	Commit, PR lub wdrożenie	Baza danych, klaster lub region i wszystko, co na nich stoi
Mechanizm odtwarzania	Checkpoint, `git revert`, przełączenie feature flagi, minimalny hotfix	Odtworzenie z kopii, promocja repliki, failover regionu
Miara	Czas od alertu do wycofania zmiany	RTO (czas do przywrócenia usługi) i RPO (ile danych możesz stracić)
Co decyduje o sukcesie	Czy zmiana była na tyle mała, żeby dało się ją czysto cofnąć	Czy procedurę przećwiczono na prawdziwej topologii
Kto zatwierdza nieodwracalny krok	Dyżurny inżynier odpowiedzialny za usługę	Incident commander

Na obu poziomach agent przygotowuje, sprawdza i wyjaśnia. Każdy krok, którego nie da się cofnąć – force-push, odtworzenie danych, promocję repliki, przełączenie DNS – zatwierdza człowiek.

Ustal cele odtwarzania, zanim cokolwiek wygenerujesz

Każdy artefakt poniżej zależy od dwóch liczb dla każdego poziomu usług. Runbook, którego celem jest „szybkie odtwarzanie”, nie może zakończyć się niepowodzeniem. Runbook z celem „RTO 15 minut, RPO 5 minut dla płatności” – może. Zacznij od tego szablonu i wpisz wartości zatwierdzone przez biznes:

Poziom	Przykładowe usługi	RTO	RPO	Sposób tworzenia kopii
Krytyczny	uwierzytelnianie, płatności	15 min	0–5 min	Replika strumieniowa i ciągła archiwizacja WAL
Wysoki	główne API	1 godz.	5 min	Archiwizacja WAL i częste kopie bazowe
Średni	funkcje drugorzędne	4 godz.	1 godz.	Snapshoty co godzinę
Niski	narzędzia wewnętrzne	24 godz.	24 godz.	Kopie dzienne

Dodaj tabelę do repozytorium (commit) obok runbooków, na przykład jako ops/recovery-objectives.md, żeby każdy prompt poniżej mógł wskazać ją agentowi zamiast powtarzać liczby.

Zadbaj, by zmianę agenta dało się cofnąć, zanim trafi do main

Najtańsze odtwarzanie to takie, które przygotujesz, zanim agent zacznie pracę. Każde narzędzie ma lokalne cofanie edycji agenta, ale żadne nie zastępuje Gita: checkpoint istnieje na jednej maszynie, nie obejmuje niektórych rodzajów zmian i nigdy nie obejmuje tego, co już scalono.

Claude Code zapisuje checkpoint swoich edycji plików przed każdym wysłanym promptem. Uruchom /rewind albo naciśnij dwa razy Esc przy pustym polu promptu i wybierz, czy przywrócić kod, rozmowę, czy jedno i drugie. Checkpointy nie śledzą plików zmienionych przez polecenia Bash, takie jak rm czy skrypt migracji, więc zrób commit, zanim pozwolisz agentowi uruchomić cokolwiek destrukcyjnego. Stare checkpointy są usuwane automatycznie, więc nie traktuj ich jak archiwum.

Trwałe reguły umieść w CLAUDE.md. Od v2.1.277 w kanale latest Claude Code czyta też AGENTS.md, gdy projekt nie ma CLAUDE.md; na Bedrocku, Google Cloud, Foundry i bramach LLM wymaga to v2.1.281. Treść reguł jest w bloku pod tymi zakładkami.

W codex-cli 0.157.1 polecenie codex features list pokazuje funkcję undo ze statusem removed, więc mechanizmem wycofywania jest Git. Każdą dużą zmianę prowadź na osobnej gałęzi lub w osobnym worktree. Zadanie w Codex Cloud daje diff, który sprawdzasz, zanim dotknie twojego repozytorium (w 0.157.1 codex cloud jest oznaczone jako eksperymentalne):

# Terminal: przejrzyj wynik zadania w chmurze i zastosuj go lokalnie tylko wtedy, gdy jest poprawny
codex cloud list
codex cloud diff TASK_ID
codex cloud apply TASK_ID

TASK_ID weźmiesz z codex cloud list. Reguły umieść w AGENTS.md.

Cursor ma własne cofanie edycji Agenta w obrębie sesji (Cursor CLI wymienia polecenie /rewind, sprawdzone 2026-08-28). Traktuj je wyłącznie jako cofanie w obrębie sesji, a zanim na nim polegasz, potwierdź sterowanie w dokumentacji checkpointów Cursora. Reguły umieść w regule projektu w sekcji Rules, a pull request niech najpierw przejrzy Bugbot, zanim zobaczy go człowiek.

Same reguły bezpieczeństwa są identyczne we wszystkich trzech narzędziach:

## Change safety
- Work on a branch named agent/<task>. Never commit to main. Never force-push.
- Before a change that touches more than 10 files, list the files and wait for approval.
- Commit after each step that passes `npm test` and `npm run typecheck`. One logical step per commit.
- Never delete a file, edit a migration that has run, or change *.config.*, .env*, Dockerfile
  or infra/ without showing the diff and waiting for approval.
- If a test fails after a step, revert that step's commit and report why. Do not fix forward.

Dwa nawyki odróżniają dwuminutowy revert od popołudnia rozplątywania commitów: commituj kroki, z których każdy przechodzi testy, i zanim zacznie się przepisywanie, utrwal obecne zachowanie w testach.

Refactor UserService from a monolithic class to the repository pattern. It touches about
30 files. Do not make the change in one pass. Follow this plan:

Commit 1: add the UserRepository interface and a Postgres implementation. Change nothing else.
Commit 2: inject the repository into UserService; UserService still uses its own methods.
Commit 3 onward: migrate one method per commit, starting with findById, then create.

Every commit must pass `npm test` and `npm run typecheck`, be revertable on its own with
`git revert`, and touch the minimum number of files. After each commit, print the commit
hash, the files changed and the test result, then stop and wait for me to say "continue".

Before we refactor src/middleware/auth/, write behaviour-capture tests in
src/middleware/auth/auth-middleware.behavior-capture.test.ts.

For each exported middleware:
1. Call it with a valid request and assert the exact status, headers and next() call.
2. Call it with an expired token, a missing token and a token for a disabled user, and
   assert the exact error response for each.
3. Assert the registration order of the middleware chain on /api/admin/* routes.

Do not change any production code. Run the new tests against the current code and show
that they pass. Then make one deliberate mutation (skip the token-expiry check), show
that at least one test fails, and revert the mutation.

Krok z mutacją pokazuje, że testy w ogóle potrafią wykryć błąd. Zestaw testów utrwalających, który zostaje zielony, gdy psujesz kod, niczego nie chroni. Pełną technikę opisuje strona o testach charakteryzujących.

Wycofaj zmianę agenta, która już trafiła na produkcję

Gdy scalona zmiana szkodzi produkcji, szybkość jest ważniejsza od elegancji. Działaj w tej kolejności i zatrzymaj się na pierwszym kroku, który przywraca usługę:

Przełącz flagę. Jeśli zmiana wyszła za feature flagą, wyłącz ją. Dlatego zmiany pisane przez agentów powinny wychodzić za flagami i przez canary; konfigurację opisuje strona o progressive delivery.
Cofnij merge (git revert). Cofnij commit scalający na main i pozwól CI go wdrożyć:
Okno terminala
```
# Terminal: znajdź commit scalający PR, a potem go cofnij (zachowując rodzica z main)
git log --merges --oneline -20
git revert -m 1 MERGE_SHA
```
MERGE_SHA to commit scalający z logu. Jeśli PR scalono metodą squash, znajdź jego commit przez git log --oneline i uruchom git revert SHA bez -m 1. Jeśli późniejsze PR-y zależą od kodu agenta i revert wywołuje konflikty, przejdź do kroku 3 zamiast rozplątywać historię w trakcie incydentu.
Wypuść minimalny hotfix. Przywróć zachowanie sprzed awarii i nie zmieniaj niczego więcej; właściwą poprawkę otwórz jako zwykły PR po incydencie.
Sprawdź usunięte pliki. Refaktoryzacja agenta może usunąć plik, którego brak nikt nie zauważy, dopóki nie wykona się dana ścieżka kodu. Wypisz, co usunął PR, poleceniem git diff --name-only --diff-filter=D MERGE_SHA^1 MERGE_SHA, a plik przywróć przez git checkout MERGE_SHA^ -- PATH.

Production incident. The error rate on /api/admin/* rose to 15% after PR #847 (an
agent-written refactor of the auth module) was merged and deployed.

Do not edit any files yet. Do this and report back:
1. Show exactly what PR #847 changed in the auth middleware pipeline.
2. Compare the middleware registration order on /api/admin/* before and after the merge.
3. List every removed function call, listener, error branch and config value in the diff.
4. Tell me whether `git revert -m 1` of the merge commit applies cleanly on current main,
   and which later commits touch the same files.
5. If a revert is not clean, propose the smallest hotfix that restores the old behaviour,
   as a diff, plus a test that fails on current main and passes with the hotfix.

Do not refactor, rename or improve anything. Restore behaviour only.

Weryfikacją jest test regresji z kroku 5: oblewa na zepsutym buildzie i przechodzi z poprawką, więc recenzent sprawdza jeden test i jeden mały diff, zamiast ponownie czytać całą refaktoryzację.

Odtwórz dane, które zepsuła zmiana agenta

Tu spotykają się oba promienie rażenia: poprawką kodu jest revert, ale poprawką danych – odtworzenie z kopii.

Zatrzymaj zapisy ze złego kodu. Najpierw wdróż rollback albo przełącz flagę. Nie naprawiaj „do przodu”, dopóki trwają błędne zapisy.
Zmierz szkody zapytaniami tylko do odczytu. Poproś agenta o zapytania SELECT, które znajdą wiersze zapisane lub zmienione w oknie incydentu, i uruchom je sam na replice do odczytu. Zanotuj liczby wierszy, zanim cokolwiek zmienisz.
Odtwórz do bazy pobocznej. Użyj runbooka PITR opisanego niżej, żeby odtworzyć stan sprzed złego wdrożenia do osobnej instancji, nigdy na działający primary.
Napraw przejrzanym skryptem. Niech agent napisze skrypt naprawczy, który kopiuje poprawne wartości z bazy pobocznej. Uruchom go najpierw na kopii, porównaj liczby wierszy i sumy kontrolne z krokiem 2 i uzyskaj zgodę drugiej osoby, zanim skrypt trafi na produkcję.
Zamknij lukę. Dodaj ograniczenie w bazie albo test walidacji, który odrzuciłby błędne zapisy, i zapisz klasę błędu (zob. taksonomię błędów).

Wygeneruj runbook PITR dla Postgresa, z którego skorzysta dyżurny

Runbook odtwarzania do punktu w czasie (PITR) to artefakt, po który dyżurni sięgają najpierw, więc napisz go tak, żeby dało się go wykonać nawet w środku nocy. Sprawdzony wzorzec to ciągła archiwizacja WAL i zewnętrzne narzędzie do kopii, takie jak pgBackRest albo WAL-G. Odtworzenie ustawia recovery_target_time i wymaga nieprzerwanego łańcucha WAL od kopii bazowej do tego punktu. Niech agent pisze runbook na podstawie twojej prawdziwej konfiguracji, a nie szablonu:

Read infra/pgbackrest.conf, infra/postgresql.conf and ops/recovery-objectives.md.
Write ops/runbooks/pitr.md: a point-in-time-recovery runbook for our Postgres 16 primary,
backed up with pgBackRest to S3 (stanza prod-main). Targets: RTO 15 min, RPO 5 min.

The runbook must:
1. Use `pgbackrest --stanza=prod-main info` to find the latest backup that finished
   before a given target timestamp.
2. Run `pgbackrest --stanza=prod-main verify` and stop, with a clear message, if any WAL
   segment between that backup and the target is missing.
3. Restore into a NEW data directory on a separate host with --type=time, --target and
   --target-action=promote. Never restore over the running primary.
4. Verify after the restore: row counts on orders, payments and users compared with the
   last known-good report, and the recovery end time in the Postgres log.
5. Be a numbered checklist. Mark each step REVERSIBLE or IRREVERSIBLE, and put
   "REQUIRES APPROVAL FROM THE INCIDENT COMMANDER" before the step that points traffic
   at the restored database.

Use only options that appear in `pgbackrest help restore` and the Postgres 16 docs. After
the runbook, list every option you used and the command that documents it.

Ostatnie polecenie jest w prompcie dlatego, że agent najczęściej myli się tu w dwóch miejscach: wymyśla opcje pgBackRest i pomija sprawdzenie luki w WAL. Uruchom pgbackrest help restore i sprawdź każdą wypisaną opcję, zanim runbook zostanie scalony. Rdzeń poprawnego runbooka wygląda tak:

# Na hoście odtwarzania, jako użytkownik postgres
pgbackrest --stanza=prod-main info                      # kopie i zakres WAL potrzebny każdej z nich
pgbackrest --stanza=prod-main verify                    # sprawdza integralność kopii i archiwum WAL
pgbackrest --stanza=prod-main --type=time \
  "--target=2026-09-25 14:02:00+00" --target-action=promote restore

Utrzymuj runbook w zgodzie z konfiguracją dzięki zaplanowanej kontroli dryfu

Runbook starzeje się w dniu, w którym ktoś zmienia nazwę stanzy albo przenosi host. Uruchamiaj na nim agenta tylko do odczytu według harmonogramu, z domyślnej gałęzi, i kończ zadanie błędem, gdy runbook rozjedzie się z konfiguracją.

# Zaplanowane zadanie CI na domyślnej gałęzi; ANTHROPIC_API_KEY pochodzi z magazynu sekretów
claude -p "Read infra/pgbackrest.conf and ops/runbooks/pitr.md. Check that every stanza,
host, bucket and path in the runbook exists in the config. Print one line per mismatch.
End with DRIFT if there is at least one mismatch, otherwise CLEAN." \
  --allowedTools "Read,Grep,Glob" --permission-mode dontAsk > drift.txt
tail -n 1 drift.txt | tr -d '*[:space:]' | grep -qx CLEAN

--permission-mode dontAsk odrzuca każde narzędzie spoza listy dozwolonych, więc zadanie może tylko czytać. Ostatnia linia zamienia werdykt na kod wyjścia zadania; tr -d usuwa znaczniki Markdown, takie jak **CLEAN**, którymi model może otoczyć słowo, więc samo formatowanie nie przerwie zadania.

# Zaplanowane zadanie CI na domyślnej gałęzi; CODEX_API_KEY pochodzi z magazynu sekretów
codex -a never exec --sandbox read-only \
  "Read infra/pgbackrest.conf and ops/runbooks/pitr.md. Check that every stanza, host,
bucket and path in the runbook exists in the config. Print one line per mismatch. End with
DRIFT if there is at least one mismatch, otherwise CLEAN." -o drift.txt
tail -n 1 drift.txt | grep -qx CLEAN

-a stoi przed exec (w 0.157.1 codex exec go nie przyjmuje), a -o zapisuje ostatnią wiadomość agenta do pliku. Runner musi obsługiwać piaskownicę tylko do odczytu: linuksowa piaskownica potrafi zawieść w nieuprzywilejowanym kontenerze, więc przetestuj zadanie na obrazie runnera, na którym je planujesz. Jeśli model może sformatować werdykt (na przykład **CLEAN**), usuń znaczniki przed sprawdzeniem: tail -n 1 drift.txt | tr -d '*[:space:]' | grep -qx CLEAN, albo poproś o samo słowo CLEAN w osobnej, ostatniej linii.

Utwórz zaplanowaną Automation dla Cloud Agenta z tym samym promptem i niech przy wykrytym dryfie otwiera pull request z poprawką runbooka. Człowiek przegląda ten pull request jak każdy inny; agent nigdy nie edytuje main.

Uruchamiaj zadanie z tokenem, który może czytać repozytorium i nic więcej (permissions: contents: read w GitHub Actions i persist-credentials: false przy checkout). Szczegóły bezpiecznego uruchamiania agentów w CI opisuje strona o agentach bez interfejsu w CI.

Sprawdź prawdziwe ustawienia kopii zamiast je zgadywać

Wygenerowana polityka kopii jest tylko prawdopodobna. Podłączony do konta chmurowego przez serwer MCP z tożsamością tylko do odczytu agent odczyta faktyczne reguły cyklu życia bucketów, harmonogramy snapshotów i regiony replik, a potem wskaże lukę w RPO. Serwer AWS rejestrujesz w każdym narzędziu tak samo; ten przykład używa profilu powiązanego z rolą IAM tylko do odczytu i dodaje flagę proxy --read-only, która ukrywa narzędzia mogące wymagać uprawnień do zapisu, jako drugą warstwę ochrony ponad rolą. Endpoint pozostaje w us-east-1; region, który odpytujesz, trafia do serwera jako metadane AWS_REGION (bez --metadata bierze się z profilu). W Claude Code lub Codeksie uruchom potem /mcp, w Cursorze otwórz ustawienia MCP. Sprawdź, czy potrzebne narzędzia nadal są na liście. Zarządzany serwer AWS MCP Server ma w README awslabs oznaczenie preview (sprawdzone 2026-09-26); w Claude Code możesz go też zainstalować jako wtyczkę aws-core z claude-plugins-official:

claude mcp add aws-mcp -- uvx mcp-proxy-for-aws-cli@latest \
  https://aws-mcp.us-east-1.api.aws/mcp --profile agent-readonly --metadata AWS_REGION=eu-west-1 --read-only

codex mcp add aws-mcp -- uvx mcp-proxy-for-aws-cli@latest \
  https://aws-mcp.us-east-1.api.aws/mcp --profile agent-readonly --metadata AWS_REGION=eu-west-1 --read-only

Dodaj to do ~/.cursor/mcp.json:

{
  "mcpServers": {
    "aws-mcp": {
      "command": "uvx",
      "args": ["mcp-proxy-for-aws-cli@latest", "https://aws-mcp.us-east-1.api.aws/mcp",
               "--profile", "agent-readonly", "--metadata", "AWS_REGION=eu-west-1", "--read-only"]
    }
  }
}

Azure, Google Cloud i pozostałych dostawców, razem z ustawieniami tylko do odczytu, opisuje strona o serwerach MCP platform chmurowych; Kubernetes i Terraform – strona o serwerach MCP dla infrastruktury.

Using the aws-mcp tools, read-only: for the RDS instances and S3 buckets tagged
tier=critical or tier=high, list the automated backup retention, whether point-in-time
recovery is enabled, the cross-region replication target, and every lifecycle rule that
expires or transitions objects in the WAL archive bucket.

Compare each against ops/recovery-objectives.md. Output a table with one row per resource:
resource, tier, target RPO, what the current settings can actually deliver, and the gap.
Do not change any setting. For each gap, propose the Terraform change as a diff for
infra/, and say which AWS API call you read each fact from.

Dla obciążeń w Kubernetesie kopie zasobów klastra i wolumenów trwałych robi Velero. Poproś o Schedule dla przestrzeni nazw payments i auth z harmonogramem (cron) dopasowanym do RPO poziomu i TTL zgodnym z polityką retencji, a potem udowodnij, że działa, odtwarzając kopię do przestrzeni testowej: velero restore create --from-backup BACKUP_NAME --namespace-mappings payments:payments-drill. Kopia, której nigdy nie odtworzono, nie jest kopią.

Udowodnij, że failover działa, dzięki zaplanowanej próbie chaosu

Nieprzetestowany plan odtwarzania to hipoteza. Zaplanowany eksperyment Chaos Mesh testuje failover na bieżąco: zasób Schedule (apiVersion: chaos-mesh.org/v1alpha1) uruchamia PodChaos z akcją pod-kill według crona.

Write chaos/postgres-failover.yaml: a Chaos Mesh Schedule (apiVersion chaos-mesh.org/v1alpha1)
that runs every Saturday at 03:00 ("0 3 * * 6") in the staging cluster, with type PodChaos,
action pod-kill, mode one, selecting pods labelled app=postgresql-primary in namespace db,
concurrencyPolicy Forbid and historyLimit 5.

Then write ops/runbooks/failover-drill.md that defines pass and fail:
- recovery time = first successful write to the new primary minus the kill time; fail above 15 min
- data loss = replication lag on the standby at kill time; fail above 5 min
- a script, scripts/drill-report.sh, that pulls both numbers from our Prometheus
  (pg_replication_lag_seconds and the app's write-success counter) and prints PASS or FAIL

Use only fields defined in Chaos Mesh's Schedule and PodChaos types. List them at the end.

Manifest to łatwiejsza połowa. Definicja sukcesu i porażki zamienia zabijanie podów w dowód.

Uruchamiaj próbę w klastrze stagingowym o topologii takiej jak produkcja, nigdy na ruchu klientów.
Niech drill-report.sh automatycznie zapisuje czas zabicia poda, czas promocji i pierwszy udany zapis; nikt nie czyta logów ręcznie.
Traktuj FAIL jak zgłoszenie P2 z właścicielem, a nie ciekawostkę.
Niech tech lead usługi co miesiąc podpisuje wyniki prób w zgłoszeniu. To ten podpis, a nie zielony panel kopii, jest dowodem, że RTO i RPO są dotrzymane.
Każdą nieudaną próbę przepuść przez prompt do post-mortemu z końca tego przewodnika.

Przeprowadź prawdziwy failover z człowiekiem przy każdym nieodwracalnym kroku

W trakcie incydentu używaj agenta do przygotowania i sprawdzenia kolejnego działania, nigdy do wykonywania nieodwracalnych poleceń na podstawie swobodnego tekstu. Sesja pozostaje tylko do odczytu, a każde polecenie uruchamia człowiek. Szerszą pętlę incydentu (powiadamianie, triaż, komunikaty o statusie) opisuje strona o reagowaniu na incydenty.

We have lost us-east-1. Read ops/runbooks/pitr.md, ops/recovery-objectives.md and
infra/dns.tf. Do not run any command.

Produce an ordered checklist to fail payments, auth and the core API over to us-west-2.
For each step give: the exact command, whether it is reversible, what to check before
running it, and what output proves it worked. The first step must stop writes to the
failed primary. Before promoting a replica, check its replication lag against the RPO.
Mark every irreversible step (stopping writes, promotion, DNS cutover) as
REQUIRES INCIDENT COMMANDER APPROVAL.

Ta sama dyscyplina dotyczy ransomware: agent może przeczytać katalog kopii i oś czasu modyfikacji plików, żeby znaleźć ostatnią kopię zakończoną przed pierwszym zdarzeniem szyfrowania, i przygotować reguły izolacji sieci, a odtworzenie uruchamia człowiek.

Co psuje plany odtwarzania po awarii i jak się z tego podnieść?

Luka w WAL blokuje odtwarzanie. Reguła cyklu życia albo zawodzący archive_command usunęły segmenty. Jak się podnieść: odtwórz do najpóźniejszego punktu, na który pozwala pozostały łańcuch, zgłoś faktyczną utratę danych i dodaj verify oraz kontrolę reguł cyklu życia do zadania wykrywającego dryf.
Opóźnienie replikacji przekracza RPO w najgorszym momencie. Skok zapisów poprzedzający awarię zostawia replikę kilka minut w tyle. Jak się podnieść: alertuj na opóźnienie względem wartości RPO, a lista kroków failoveru niech porównuje opóźnienie przed promocją; zob. monitoring i obserwowalność.
Split-brain po failoverze. Stary primary nadal przyjmuje zapisy po promocji repliki. Jak się podnieść: najpierw odetnij stary primary, zrób jego snapshot, wyeksportuj wiersze przyjęte po czasie promocji (porównując je z nowym primary) i po przeglądzie odtwórz je, a potem odbuduj go jako replikę przez pg_rewind albo świeżą kopię bazową; niech „zatrzymaj zapisy” zawsze będzie pierwszym krokiem każdej listy failoveru.
Próba przechodzi, a prawdziwy failover zawodzi. Staging ma trzy węzły, produkcja 30. Jak się podnieść: odwzoruj topologię produkcji w klastrze prób i zmieniaj wstrzykiwaną awarię (zabicie poda, partycja sieci, pełny dysk).
Agent wymyśla flagę albo pole CRD. Runbook lub manifest się nie uruchomi. Jak się podnieść: prompty powyżej każą agentowi wypisać każdą opcję ze źródłem; sprawdź tę listę z --help albo typami CRD przed scaleniem.
Revert ma konflikty, bo późniejsze PR-y budują na kodzie agenta. Jak się podnieść: wypuść minimalny hotfix zamiast rozplątywać commity w trakcie incydentu, a właściwą poprawkę zaplanuj później. Odwracalne commity (opisane wyżej) sprawiają, że zdarza się to rzadziej.
Brakuje potrzebnego checkpointu. Zmianę wprowadziło polecenie powłoki, którego checkpointy nie śledzą, albo snapshoty zostały już usunięte. Jak się podnieść: trwałym zapisem jest Git; commituj każdy krok, żeby zawsze był commit, do którego można wrócić.

Zamień incydent w post-mortem i test regresji

Incydent nie jest zamknięty, dopóki lekcja nie trafi do repozytorium: post-mortem, test regresji i zmieniony runbook albo reguła. Dawaj agentowi prawdziwe artefakty, a nie swoje wspomnienia o nich.

Draft a blameless post-mortem from incident/timeline.csv, logs/incident-2026-09-25/ and
the drill-report.sh output for the last failed drill.

Structure: a one-paragraph summary; a minute-by-minute timeline; root cause, separating the
trigger from the underlying cause; customer impact (duration, failed requests, data loss
measured against the RPO); what went well; what went wrong; 3 to 5 action items, each with
an owner role, a priority and the test, alert or runbook change that proves it is done.
Describe systems and decisions, never individuals. Mark every statement the logs do not
support as UNVERIFIED.

Trzymaj post-mortem obok runbooka, który ma zmienić, żeby następna próba sprawdzała lekcję z ostatniego incydentu. Przy incydentach wywołanych zmianą agenta oznacz klasę błędu i postępuj zgodnie z procesem organizacyjnym opisanym na stronie o incydentach z udziałem agentów.

Dokąd dalej w temacie odtwarzania po awarii

Reagowanie na incydenty Powiadamianie, triaż i komunikaty o statusie wokół kroków odtwarzania z tej strony.

Progressive delivery Flagi, canary i automatyczny rollback po SLO, żeby zła zmiana agenta nie trafiła do wszystkich.

Przećwiczony pipeline rollbacku Rollback jako przećwiczony krok pipeline’u, z decyzją człowieka o produkcji.

Taksonomia błędów Sklasyfikuj, co poszło źle, i znajdź najwcześniejszą kontrolę, która wyłapie to następnym razem.

Monitoring i obserwowalność Alerty na opóźnienie replikacji i stan kopii, które wcześnie wyłapują luki w odtwarzaniu.

Infrastruktura jako kod Utrzymuj infrastrukturę failoveru powtarzalną i przejrzaną.