Odzyskiwanie po awarii z AI

Odzyskiwanie po awarii w zespołach pracujących z AI obejmuje dwa promienie rażenia: zmianę wypuszczoną przez agenta, cofaną checkpointami, przyrostowymi commitami, feature flagami i celowanymi revertami, oraz infrastrukturę pod nią, odtwarzaną runbookami PITR dla Postgresa, kopiami Velero i przećwiczonym failoverem. Oba łączy jedna dyscyplina: zapisane cele odtwarzania, przećwiczona procedura i człowiek przy każdej nieodwracalnej bramce.

Agent AI właśnie zrefaktoryzował twój moduł uwierzytelniania w 47 plikach. Testy przechodzą, typy się zgadzają, scalasz. Dwie godziny później tokeny sesji nie są walidowane w API administracyjnym, trzy inne PR-y zostały scalone na wierzchu, a rollback nie jest już jednym kliknięciem. Miesiąc później przychodzi inna katastrofa: twój główny region gaśnie w trakcie wdrożenia, strona statusu wciąż świeci na zielono, bo nikt jej nie zaktualizował, a runbook to strona w Confluence edytowana ostatnio czternaście miesięcy temu, odwołująca się do hosta Postgresa wycofanego wiosną.

Inna skala, to samo pytanie — jak szybko wrócicie i ile stracicie po drodze? Odzyskiwanie po awarii to ten jeden obszar, w którym „napiszemy dokumentację później” po cichu zamienia się w „straciliśmy sześć godzin i kawałek danych klientów”. Dobra wiadomość: wolne, żmudne części — pisanie precyzyjnych runbooków, tworzenie eksperymentów chaosu, które naprawdę sprawdzają twoje RPO, utrwalanie bieżącego zachowania kodu, zanim agent go przepisze, zamiana bałaganiarskiej osi czasu w bezobwiniający post-mortem — to dokładnie to, w czym narzędzia AI są dobre, o ile zakotwiczysz je w prawdziwych narzędziach i utrzymasz człowieka przy bramce zatwierdzania.

Co daje ten podręcznik odzyskiwania po awarii

Konfigurację siatek bezpieczeństwa dla wszystkich trzech narzędzi, żeby agent nie mógł wykonać zmiany w 47 plikach, której nie da się cofnąć
Prompt wymuszający adwersaryjny przegląd diffu agenta, polujący na ciche zmiany zachowania, których testy nie łapią
Procedury odzyskiwania po regresjach wprowadzonych przez AI na każdym etapie: przed scaleniem, po scaleniu i przy uszkodzeniu danych
Gotowy do wklejenia prompt, który zamienia twój stos w runbook point-in-time recovery dla Postgresa z jawnymi celami RTO/RPO i weryfikacją łańcucha WAL
Chaos Mesh Schedule, który co tydzień zabija pod głównej bazy i sprawdza failover przy RPO 5 minut — wygenerowany, a nie wyklepany z pamięci
Podręcznik z bramką ludzką na czas prawdziwej awarii regionu oraz prompt szkicujący bezobwiniający post-mortem z prawdziwych logów
Listę trybów awarii, które po cichu psują plany odzyskiwania, i sposób na złapanie ich, zanim zrobi to katastrofa

Dwa promienie rażenia, jedna dyscyplina

Plan odzyskiwania jest użyteczny tylko wtedy, gdy nazywa, z czego odzyskuje. Niemal wszystko, co idzie źle w zespole pracującym z AI, wpada do jednego z dwóch kubełków, a każdy z nich chce innych narzędzi:

Zmiana. Agent wprowadził regresję. Promień rażenia to commit, PR albo wdrożenie. Odzyskiwanie to checkpoint, revert, przełączenie feature flagi albo hotfix — mierzone w minutach i sprowadzające się do pytania, czy zmiana była na tyle mała, by dało się ją czysto cofnąć.
Infrastruktura. Zniknęła baza danych, region albo klaster. Promień rażenia to wszystko, co na nich stoi. Odzyskiwanie to restore albo failover — mierzone względem celów ustalonych z wyprzedzeniem i sprowadzające się do pytania, czy to przećwiczyliście.

Dyscyplina jest w obu przypadkach identyczna: zapisz cel przed incydentem, przećwicz procedurę, trzymaj człowieka przy każdym nieodwracalnym kroku i utrwal to, czego się nauczyliście. Reszta tego przewodnika prowadzi tę dyscyplinę na obu skalach.

Najpierw cele odtwarzania

Każdy artefakt DR poniżej zależy od dwóch liczb na poziom usługi: RTO (jak długo do przywrócenia usługi) i RPO (ile danych możesz stracić). Zapisz je jawnie, zanim cokolwiek wygenerujesz — runbook celujący w „szybkie odzyskanie” jest bezużyteczny, a ten celujący w „RTO 15 min, RPO 5 min dla płatności” da się przetestować.

Realistyczna macierz startowa wygląda tak:

Poziom	Przykładowe usługi	RTO	RPO	Podejście do kopii
Krytyczny	auth, 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 drugoplanowe	4 godziny	1 godzina	Migawki co godzinę
Niski	narzędzia wewnętrzne	24 godziny	24 godziny	Kopie dzienne

Zapobieganie: siatka bezpieczeństwa, zanim agent zacznie

Najlepsze odzyskiwanie po awarii to takie, którego nie potrzebujesz. Każde narzędzie ma własne miejsce na reguły, a to właśnie reguły sprawiają, że duża zmiana prowadzona przez agenta pozostaje odwracalna.

System checkpointów Cursora daje automatyczne punkty powrotu:

Checkpointy to automatyczne migawki zmian Agenta w twoim kodzie
Aby się cofnąć, kliknij Restore Checkpoint przy odpowiednim wcześniejszym żądaniu albo przycisk + po najechaniu na wiadomość
Checkpointy są trzymane lokalnie i są niezależne od Gita — do trwałej kontroli wersji używaj Gita, nie checkpointów

Dodaj jawne reguły bezpieczeństwa:

SAFETY REQUIREMENTS:
Before any multi-file refactoring:
1. List all files that will be modified
2. Verify the test suite passes BEFORE making changes
3. After changes, run the full test suite
4. If any test fails, revert ALL changes and report what went wrong

NEVER delete files without explicit user confirmation.
NEVER modify configuration files (*.config.*, .env*, Dockerfile) without showing the diff first.

Claude Code pracuje bezpośrednio z Gitem. Ustanów bezpieczeństwo oparte na commitach:

SAFETY PROTOCOL:
Before starting any multi-file modification:
1. Run: git stash (save any uncommitted work)
2. Create a safety branch: git checkout -b ai/[task-description]
3. Commit after each logical step with descriptive messages
4. Run tests after each commit
5. If tests fail, use git diff to identify the problem

After completing the task:
- Run the FULL test suite (npm test)
- Run type checking (npm run type-check)
- Run linting (npm run lint)
- Show the complete diff from main for review

NEVER force-push. NEVER modify the main branch directly.

System uprawnień Claude Code daje dodatkową warstwę bezpieczeństwa — zapisy do plików wymagają jawnej zgody, chyba że są automatycznie zatwierdzone w ustawieniach.

Zadania chmurowe Codeksa działają w izolowanych piaskownicach z wbudowanym bezpieczeństwem:

SAFETY PROTOCOL:
- All changes happen in a new branch (never modify main)
- Cloud tasks cannot push directly to main
- Every task produces a PR for human review
- Worktrees provide isolation between parallel tasks

Before submitting a PR:
1. Run the full test suite
2. Run the linter
3. Generate a comprehensive PR description explaining all changes
4. Flag any files that were deleted or had configuration changes

Piaskownica Codeksa oznacza, że rozbiegane zadanie nie może wpłynąć na twoje lokalne środowisko ani na inne gałęzie.

Przejrzyj diff adwersaryjnie

Kontrola typów i zielony zestaw testów to najsłabszy dowód, jaki masz na temat refaktoru agenta. Poproś o przegląd, który poluje na to, co one przepuszczają:

I need you to review the changes the AI agent just made. Be adversarial.

1. Read the complete diff (git diff main...HEAD)
2. For each modified file, check:
   - Were any function calls removed that are not covered by tests?
   - Were any middleware registrations, event listeners, or side effects changed?
   - Were any error handling paths altered or removed?
   - Were any configuration values changed?
3. List files that were DELETED and verify nothing else depends on them
4. Check for behavioral changes that would pass type-checking but change runtime behavior
   (e.g., changing an async function to sync, changing error types, altering return values)

I am especially worried about silent behavioral changes that tests do not catch.

Zrób zmianę na tyle małą, by dało się ją cofnąć

Dwa nawyki robią dla odwracalności więcej niż jakiekolwiek narzędzia: commituj krokami, z których każdy przechodzi testy, i utrwal istniejące zachowanie w testach przed przepisaniem kodu.

I need to refactor the UserService from a monolithic class to the repository pattern.
This affects approximately 30 files.

DO NOT make all changes at once. Follow this incremental plan:

Commit 1: Create the UserRepository interface and implementation.
          Change nothing else. All existing code still works.
          Run tests.

Commit 2: Add the repository as a dependency to UserService.
          UserService still uses its internal methods (no behavior change).
          Run tests.

Commit 3: Migrate the first method (findById) to use the repository.
          Run tests.

Commit 4: Migrate the next method (create). Run tests.

Continue this pattern for each method. Every commit must:
- Pass all tests
- Be independently revertable
- Change the minimum number of files

Stop after each commit so I can review before continuing.

Before we refactor the auth middleware, I need behavior-capture tests.

For each middleware function in /src/middleware/auth/:
1. Write a test that calls the middleware with a valid request and asserts the EXACT current behavior
2. Write a test that calls it with an invalid request and asserts the EXACT error response
3. Write a test that verifies the middleware chain order (which middleware runs before which)

These tests should FAIL if the refactoring changes any observable behavior.
They are intentionally brittle - that is the point. They are our safety net.

Name them clearly: auth-middleware.behavior-capture.test.ts
After the refactoring is complete and verified, we will remove these in favor of proper tests.

Wdrażaj tak, by rollback był przełącznikiem, a nie alarmem pożarowym

Feature flagi dla zmian generowanych przez AI

Wdrażaj zmiany wspomagane przez AI za feature flagami. Gdy coś pójdzie źle, przełącz flagę zamiast wycofywać wdrożenie.
Wdrożenia kanarkowe

Skieruj 5% ruchu na nową wersję. Monitoruj poziom błędów, opóźnienia i kluczowe metryki biznesowe przez 30 minut, zanim poszerzysz.
Automatyczne wyzwalacze rollbacku

Ustaw automatyczne wycofanie, gdy poziom błędów przekroczy 2x bazę albo opóźnienie p99 przekroczy 3x bazę.
Monitoring po wdrożeniu

Obserwuj dashboardy przez 4 godziny po wdrożeniu zmian generowanych przez AI. Tryby awarii kodu z AI są często subtelne — przypadki brzegowe i wyścigi, a nie wywrotki.

Odzyskiwanie po zmianie, którą wypuściłeś

Agent zepsuł testy przed scaleniem

Najłatwiejsze odzyskiwanie, a zarazem to, w którym mechanika zależy od użytego narzędzia.

Użyj checkpointów Cursora, aby przywrócić ostatni dobry stan:

Znajdź żądanie tuż przed psującą zmianą
Kliknij przy nim Restore Checkpoint (albo przycisk + po najechaniu na tę wiadomość), aby wrócić do tego stanu
Alternatywnie użyj Cmd+Z, aby cofnąć ostatnie edycje

Checkpointy są trzymane lokalnie i niezależnie od Gita, więc gdy potrzebujesz trwałego punktu powrotu, sięgnij po Gita.

# If working on a branch (recommended):
git diff main  # See what changed
git stash       # Save current state
git checkout main  # Return to clean state

# If you committed incrementally (recommended):
git log --oneline -10  # Find the last good commit
git revert HEAD~3..HEAD  # Revert the bad commits

Zmiana została scalona i produkcja cierpi

Tu szybkość liczy się bardziej niż elegancja. Skieruj agenta na konkretny PR i zabroń mu poprawiania czegokolwiek po drodze:

We have a production incident. The error rate on /api/admin/* endpoints spiked to 15%
after merging PR #847 (AI-assisted auth module refactoring).

Investigate immediately:
1. Show me exactly what PR #847 changed in the auth middleware pipeline
2. Compare the middleware registration order before and after the PR
3. Check if any route-specific middleware was removed or reordered
4. Look at the error logs - what specific error are users hitting?
5. Identify the minimal fix (do not refactor further - just restore correct behavior)
6. Generate the fix as a hotfix PR with only the necessary changes

Speed is critical. Do not optimize or clean up. Fix the regression and nothing else.

Zmiana uszkodziła dane

Najgroźniejszy scenariusz i ten, w którym podręczniki na poziomie zmiany i infrastruktury się spotykają: naprawą jest odtworzenie z kopii.

Zatamuj krwotok

Wdróż rollback natychmiast. Nie próbuj naprawiać do przodu, gdy zagrożona jest integralność danych.
Oceń szkody

Odpytaj bazę o rekordy zmodyfikowane w oknie incydentu. Ustal zasięg uszkodzenia.
Odtwórz z kopii

Użyj poniższego runbooka point-in-time recovery, by przywrócić dotknięte dane do stanu sprzed incydentu.
Analiza przyczyny źródłowej

Ustal, który kod wygenerowany przez AI spowodował uszkodzenie. Brakująca walidacja? Złe zapytanie? Wyścig?
Zapobiegnij powtórce

Dodaj konkretne przypadki testowe dla tego trybu awarii. Dodaj ograniczenia w bazie, które wyłapią uszkodzenie na warstwie danych. Zaktualizuj reguły agenta, aby zapobiec podobnym wzorcom.

Odzyskiwanie infrastruktury pod spodem

Najcenniejszym artefaktem DR dla większości zespołów jest runbook point-in-time recovery dla Postgresa, który dyżurny inżynier może wykonać o 3 nad ranem bez myślenia. Wzorzec, który naprawdę 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. Odtwarzanie PITR ustawia restore_command i recovery_target_time i opiera się na nieprzerwanym łańcuchu WAL między kopią bazową a czasem docelowym.

Niech twoje narzędzie AI napisze runbook na podstawie twojej faktycznej konfiguracji, a nie ogólnego szablonu:

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 krytycznie to, co powstanie. Dwie rzeczy, które AI najczęściej tu przekręca, to wymyślanie flag pgBackRest i prześlizgiwanie się nad sprawdzeniem luki w łańcuchu WAL — dokładnie tej awarii, która zostawia cię w połowie odtwarzania. Jeśli komenda wygląda nieznajomo, sprawdź ją w pgbackrest --help, zanim trafi do runbooka.

Gdzie pasuje które narzędzie

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

Otwórz runbook w edytorze i użyj trybu agenta, żeby Cursor mógł przeczytać twoje faktyczne pgbackrest.conf, docker-compose.yml i pliki migracji jako źródło prawdy, zamiast zgadywać nazwy hostów i stanz. Iteruj w miejscu: gdy krok wygląda źle, zaznacz go i poproś Cursora o poprawę tylko tego kroku. Ustaw checkpoint, zanim pozwolisz mu ruszyć wiele plików, żeby móc cofnąć złe przepisanie jednym kliknięciem.

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

Użyj trybu headless, aby regenerować i walidować runbook w ramach zaplanowanej próby DR albo 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 cotygodniowe zadanie CI. Czerwony build oznacza, że runbook rozjechał się z rzeczywistością — a to dokładnie ten moment, w którym 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.

Przekaż całe zadanie do Codex Cloud: daj mu repozytorium i zadanie w stylu „zregeneruj ops/runbooks/pitr.md z bieżącej konfiguracji pgBackRest i otwórz PR”. Działając na GPT-5.6 Sol, pracuje w izolowanym środowisku na wypakowanej kopii, więc może przeszukać prawdziwą konfigurację, zregenerować runbook i wypchnąć gałąź do przeglądu, nie dotykając twojej maszyny.

Do pracy lokalnej codex w worktree trzyma zmiany DR w izolacji od gałęzi funkcjonalnych, a integracja z GitHubem potrafi otworzyć PR do zatwierdzenia przez człowieka.

Kopie reszty stosu

Baza danych rzadko jest całą historią. Dla obciążeń na Kubernetes Velero tworzy kopie zasobów klastra i wolumenów trwałych i to jego warto kazać skonfigurować asystentowi AI — a nie wymyślonej wewnętrznej usłudze kopii.

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.

Dla obiektowych magazynów i zarządzanych baz danych wybieraj natywne funkcje dostawcy — replikację międzyregionową i point-in-time (na przykład automatyczne kopie RDS z PITR albo S3 Cross-Region Replication) — zamiast pisać własne. Poproś narzędzie AI o wygenerowanie dla nich Terraforma, a potem przejrzyj IaC tak samo, jak przejrzałeś runbook.

Testowanie: próby chaosu sprawdzające twoje RPO

Nieprzetestowany plan DR to hipoteza. Najtańszy sposób ciągłego testowania failoveru to zaplanowany eksperyment Chaos Mesh, który zabija pod głównej bazy i sprawdza, czy system wraca w ramach zadeklarowanych celów. CRD Schedule (apiVersion: chaos-mesh.org/v1alpha1) uruchamia PodChaos typu pod-kill na cronie.

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 definiujący zaliczenie/oblanie względem twoich RTO/RPO to ta połowa, która nadaje próbie sens — bez niego tylko zabijasz pody i masz nadzieję. Traktuj przekroczone RTO w sobotniej próbie jak zgłoszenie P2, a nie ciekawostkę.

Uruchamiaj próbę na klastrze staging odwzorowującym topologię produkcji, nigdy na żywym ruchu klientów.
Zbieraj oś czasu automatycznie: czas zabicia, czas promocji, pierwszy udany zapis do nowego primary.
Porównaj zmierzone RTO/RPO z celami i załóż zgłoszenie dla każdego przekroczenia.
Podaj logi z próby prosto do promptu post-mortem poniżej, żeby luki zamieniły się w zadania, a nie zostały zapomniane do poniedziałku.

Gdy dzieje się naprawdę: podręcznik z bramką ludzką

W trakcie incydentu AI najlepiej służy do generowania i walidowania następnego działania — nigdy do odpalania nieodwracalnych komend prosto z wolnego tekstu. Trzymaj człowieka przy bramce zatwierdzania dla wszystkiego, co promuje replikę, przekierowuje DNS albo wyłącza zapisy.

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ę sprzed szyfrowania i naszkicować reguły izolacji sieciowej, a wykonanie zostaw człowiekowi. 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 bezgłową formę claude -p i listę dozwolonych narzędzi tylko do odczytu: to analizuje i rekomenduje, a nie odtwarza.

Kiedy plany odzyskiwania zawodzą

Obie skale zawodzą w przewidywalny sposób. Uważaj na te przypadki:

Luki w łańcuchu WAL. Reguły cyklu życia kubełka albo po cichu zawodzące archive_command wygaszają segmenty między kopią bazową a czasem docelowym. Odtwarzanie przerywa w połowie. Naprawa: runbook musi weryfikować ciągłość, a nie ją zakładać.
Opóźnienie replikacji przekracza RPO w najgorszym momencie. Przy skoku zapisów, który często poprzedza awarię, standby zostaje w tyle o minuty. Promocja traci więcej danych, niż pozwala twoje RPO. Naprawa: alertuj na opóźnienie względem liczby RPO, a krok failoveru niech sprawdza opóźnienie przed promocją.
Failover, który gubi zapisy. Promujesz standby, ale stary primary wciąż przyjmuje zapisy (split-brain) albo zapisy w locie nigdy się nie zreplikowały. Naprawa: pierwszym krokiem podręcznika jest zawsze wyłączenie zapisów na uszkodzonym primary, przed promocją.
Próba przechodzi, prawdziwa awaria nie. Staging ma 3 węzły, produkcja 30 i inną topologię. Naprawa: prowadź próby na klastrze odwzorowującym skalę produkcji i rotuj wstrzykiwaną awarię.
AI wymyśla flagi albo pola. Wygenerowana flaga pgBackRest albo pole Chaos Mesh, które nie istnieje, czyni artefakt nieuruchamialnym. Naprawa: zawsze waliduj wygenerowane komendy względem --help albo referencji CRD przed commitem — traktuj wynik AI jako szkic, nigdy jako ewangelię.
Nie da się cofnąć, bo inne zmiany zależą od kodu agenta. Właśnie to kupują ci przyrostowe commity. Jeśli problem wprowadził jeden commit, cofnij ten commit; jeśli zmiany są splątane, celowany hotfix bije rozplątywanie w trakcie incydentu.
Agent usunął pliki, których nikt nie zauważył przez tygodnie. Git cię ratuje: git log --diff-filter=D znajduje usunięte pliki, a git checkout <commit>^ -- <filepath> je przywraca. Dodaj sprawdzenie CI oznaczające usunięcia do dodatkowej uwagi w przeglądzie.
Strategia kopii nie pokrywa trybów awarii typowych dla AI. Kopie bazy i kod w Gicie pokrywają większość z nich. Unikalnym ryzykiem jest subtelna zmiana zachowania, która przechodzi każdą kontrolę — dlatego testy utrwalające zachowanie na ścieżkach krytycznych i wdrożenia za feature flagami należą do strategii kopii, a nie tylko do standardu kodowania.

Domknięcie pętli: post-mortem

Incydent nie kończy się, dopóki nauka nie zostanie utrwalona. AI jest naprawdę dobre w zamienianiu bałaganiarskiej osi czasu i ściany logów w ustrukturyzowany, bezobwiniający post-mortem — pod warunkiem że podasz mu prawdziwe artefakty.

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 jest splątany między usługami — jakość rozumowania jest warta kosztu w tym jednym dokumencie, który przeczytają wszyscy; przy ograniczonym budżecie zejdź na Opus 5. Trzymaj wynik w repozytorium obok runbooka, który ma poprawić, żeby kolejna próba testowała wnioski z ostatniego incydentu.

Dokąd dalej z odzyskiwaniem po awarii

Reagowanie na incydenty Automatyzacja dyżurów i obsługa incydentów wspomagana przez AI.

Pipeline'y CI/CD Zbuduj siatki bezpieczeństwa wdrożeń, na których opiera się ten podręcznik.

Bezpieczeństwo i zgodność Planowanie odzyskiwania pod kątem bezpieczeństwa, wątek ransomware i ścieżki audytowe.

Testy wydajnościowe Obciąż systemy DR testami, zanim na nich polegniesz.

Monitoring i obserwowalność Alerty o opóźnieniu replikacji i kondycji kopii, które wcześnie łapią luki w DR.

Infrastructure as Code Utrzymuj infrastrukturę failoveru odtwarzalną i zrecenzowaną.