Praktyczne scenariusze disaster recovery dla sklepów online od planu po testy odtwarzania

Najszybsza droga do bolesnej przerwy w sprzedaży? Liczyć, że kopie zapasowe „jakoś są”, a plan disaster recovery istnieje „w głowie admina”. W e-commerce błąd kosztuje minuty przychodów i reputację: anulowane koszyki, zdublowane płatności, pomylone stany magazynowe. Poniżej konkretne, sprawdzone scenariusze i układ działań: od planu DR po testy odtwarzania — z naciskiem na pułapki, które najczęściej wykładają sklepy online.

Na jakie pytania musisz mieć odpowiedź przed kryzysem

Kluczowe dylematy właściciela i zespołu technicznego

• Jaki maksymalny czas niedostępności (RTO) i utrata danych (RPO) są akceptowalne dla zamówień i płatności?
• Skąd i jak szybko odtworzysz bazę danych, pliki multimediów i indeks wyszukiwarki?
• Co zrobisz, gdy dostawca płatności lub region chmurowy padnie w godzinach szczytu?
• Jak potwierdzisz, które zamówienia zostały opłacone, jeśli awaria nastąpi w trakcie autoryzacji?
• Jak sprawdzisz, że kopie zapasowe da się odtworzyć w nowej infrastrukturze (a nie tylko na papierze)?

1) Ustal RTO/RPO na twardo i przypisz je do komponentów sklepu

Priorytety: co musi wstać najpierw

Bez konkretnego RTO/RPO cały plan disaster recovery jest życzeniowy. Rozbij sklep na komponenty: front (WWW), API, baza danych transakcyjnych, pliki multimediów, wyszukiwarka, kolejki zadań, integracje (ERP, WMS, PSP), panel admina. Dla każdego nadaj klasę krytyczności i zdefiniuj cele RTO/RPO. Kryterium: utracona sprzedaż vs koszt utrzymania redundancji.

Przykładowa macierz krytyczności

Pułapki do uniknięcia

• Jedno RTO/RPO dla całego systemu. Różnicuj: zaoszczędzisz na mniej krytycznych warstwach.
• Niedoszacowanie RPO dla płatności. Każda minuta to realne spory z klientami i chargebacki.
• Brak akceptacji biznesu. Cele DR muszą być zatwierdzone przez stronę biznesową.

2) Kopie zapasowe oparte na 3-2-1-0: lokal, offsite, test odtwarzania

Strategia 3-2-1-0, czyli bez „kopii-widma”

• 3 kopie: produkcyjna + 2 niezależne kopie zapasowe.
• 2 różne nośniki/warstwy: np. snapshot bazy + eksport logiczny + backup plików na obiekcie.
• 1 kopia offsite/off-account: inny region lub inne konto (izolacja przed ransomware i błędami IAM).
• 0 błędów w weryfikacji: regularna próba odtworzenia i checksumy.

Harmonogram i retencja dopasowane do RPO

Dla bazy transakcyjnej zastosuj mieszany plan: ciągły binlog/WAL do obiektu + snapshoty co 4–6 godzin + dobowe pełne eksporty logiczne. Pliki multimediów synchronizuj wersjonowaniem w storage obiektowym z 30–90 dni retencji i blokadą usunięcia (immutability/WORM) dla krytycznych zasobów. Kopie trzymaj w innym regionie i na innym koncie chmurowym.

Testy odtwarzania jako wymóg, nie opcja

Co miesiąc odtwarzaj bazę do izolowanego środowiska i uruchamiaj podstawowe scenariusze: rejestracja, płatność testowa, generowanie faktury, reindeks. Jeśli nie możesz przejść end-to-end, backup jest fikcją. Dokumentuj czasy: od „start odtwarzania” do „usługa dostępna”.

Oszczędny wariant na start

• Snapshot bazy + eksport logiczny raz dziennie, z kopiowaniem do innego regionu.
• Pliki w storage z włączonym wersjonowaniem i lifecycle do tańszych klas.
• Miesięczny „restore day” w środowisku dev z zamrożonym obrazem aplikacji.

3) Wieloregion i replikacja: wybierz prosty wzorzec i go opisz

Active–passive dla mniejszych budżetów

Najprostszy układ: region A aktywny, region B w gotowości. Replikuj bazę asynchronicznie (RPO zgodne z tolerancją). Aplikacja i konfiguracje przygotowane jako obraz/kontener. DNS/traffic manager ustawiony do ręcznego lub półautomatycznego przełączenia. Plusy: przewidywalne koszty. Minus: krótka przerwa przy failoverze.

Active–active dla krytycznych okresów

Gdy sezon sprzedażowy nie wybacza, rozważ aktywną–aktywną warstwę front/API z sesjami stateless i bazą działającą w modelu read-write w jednym regionie, read-replica w drugim oraz mechanizmem promowania replica do master. Zadbaj o idempotentność zapisów i odporność na split-brain (mechanizmy quorum, fencing).

Pułapki architektoniczne

• Brak zgodności konfiguracji między regionami (inne limity, brak tajemnic/secrets, różne rozmiary instancji).
• DNS bez krótkiego TTL — przełączenie trwa wieczność.
• Replikacja tylko bazy, bez plików i cache — po przełączeniu wysypują się zdjęcia i pre-warm.

4) Izolacja kont i zależności: uciekaj od pojedynczych punktów krytycznych

Backupy cross-account i minimalny multicloud

Przechowuj kopie w innym koncie/billingu, z minimalnymi uprawnieniami tylko do odczytu. Jeśli budżet pozwala, trzymaj krytyczną kopię bazy w alternatywnej chmurze jako zimny storage. Celem jest przeżycie błędnej polityki IAM, ataku na główne konto lub awarii usługodawcy.

Plan B dla PSP, e-mail i CDN

• Płatności: miej aktywnego drugiego dostawcę jako fallback (karta/bank/BNPL) i przełącznik w panelu.
• E-mail: alternatywny SMTP, aby dokończyć procesy (reset hasła, potwierdzenia zamówień).
• CDN: możliwość szybkiej zmiany originu lub awaryjne serwowanie statycznych z „maintenance mode”.

Najczęstsze zaniedbania

• Przechowywanie kluczy do backupów w tym samym KMS co produkcja.
• Brak DR dla panelu admina — nie da się anulować/obsłużyć zamówień w kryzysie.
• Brak eksportów konfiguracji sklepu (stawki, reguły promocji, podatki) w kontroli wersji.

5) Runbooki, IaC i obrazy: od słów do automatycznego odtwarzania

Runbook techniczny i biznesowy

Runbook to krok-po-kroku: gdzie kliknąć, jaki skrypt uruchomić, jak zweryfikować. Osobny dla techniki (odtwarzanie bazy, przełączenie DNS, weryfikacja zdrowia) i biznesu (komunikaty, polityka zwrotów, ręczne dokańczanie zamówień). Zero skrótów myślowych — osoba „spoza projektu” ma dać radę.

Automatyzacja IaC i obrazy niezmienne

Bez powtarzalnego sposobu stawiania środowiska RTO jest loterią. Utrzymuj infrastrukturę jako kod (Terraform/Pulumi) i używaj niezmiennych obrazów (Packer/Docker) podpisanych i wersjonowanych. Każde wydanie aplikacji ma mieć tag/commit, którym odtworzysz identyczny stan w regionie zapasowym.

• Przykład: obraz „shop-frontend:2024.07.15-abc123” + moduł Terraform, który w 15 minut stawia load balancer, ASG i sekrety. Tyle wystarczy, by front wrócił bez ręcznego „klikania”.
• Sens praktyczny: krótszy RTO, mniej różnic „działa u nas, nie działa u nich”, łatwiejsze testy DR w pipeline’ach.

„One-click” odtwarzanie i suchy rozruch

Zepnij odtwarzanie w pipeline: przycisk uruchamia provisioning, restore bazy, przełącza zmienne i odpala testy end-to-end. Raz w sprintcie zrób „suchy rozruch” w izolowanym VPC — bez DNS — i zmierz czasy.

• Przykład: job CI “dr-restore-staging” — przywraca snapshot + WAL, synchronizuje pliki z obiektu, uruchamia smoke testy (koszyk, checkout w trybie sandbox PSP).
• Efekt vs wysiłek: 1–2 dni pracy na spięcie pipeline’u zdejmują stres z nocnych awarii przez resztę roku.

Konfiguracje i sekrety jako źródła prawdy

Trzymaj konfiguracje sklepu (podatki, reguły promocji, metody dostaw) w repozytorium lub eksportuj je cyklicznie do wersjonowanych plików. Sekrety w managerze tajemnic z rotacją i kopią w drugim koncie/regionie. Bez tej dyscypliny odtworzysz serwery, ale nie odtworzysz biznesu.

• Przykład: nightly export „store-configs.tar.gz” + checksum do obiektu off-account; klucze PSP w Secrets Managerze z replikacją cross-region.
• Pułapka: brak zgodności wersji schematu bazy z wersją konfiguracji — etap migracji musi być częścią runbooka.

6) Testy odtwarzania, które łapią realne błędy

Zestaw scenariuszy na cały kwartał

• Pad bazy w południe: przywróć snapshot + WAL do punktu w czasie, uruchom sklep w trybie write i porównaj transakcje z raportem PSP (T+0) — różnice rozlicz skryptem „reconcile”.
• Utrata regionu: promuj replikę w regionie B, przełącz ruch (niski TTL), sprawdź multimedia z CDN i generowanie dokumentów.
• Błąd migracji schematu: odtwórz stan sprzed deployu, wykonaj migracje od nowa na kopii — zweryfikuj, że klucze obce i indeksy są spójne.
• Usunięte pliki produktowe: odtwórz z wersjonowania obiektu, policz brakujące checksumy i porównaj miniatury.

Kryteria zaliczenia: czasy RTO/RPO w widełkach, brak błędów 5xx w krytycznych ścieżkach (koszyk, checkout), różnice z PSP < ustalony próg i automatycznie oznaczone do ręcznego kontaktu z klientem.

Metryki, które musisz zapisać po każdym teście

• TTR (time to restore) per komponent i „czas do pierwszego zakupu”.
• Lag replikacji i czas reindeksu wyszukiwarki.
• Odsetek zamówień wymagających ręcznego wyjaśnienia po reconcile.

7) Porządkowanie danych: płatności, zamówienia, stany po awarii

Reconcile z PSP bez łez

• Wymuś idempotency-key dla każdego zlecenia płatności (order_id + hash koszyka). Po restarcie odpytywanie PSP po tym kluczu minimalizuje duplikaty.
• Po awarii: pobierz raport dzienny PSP, dopasuj do zamówień po external_id, a nie tylko statusie w bazie. Transakcje „autoryzowane, brak zamówienia” — utwórz szkice i wyślij prośbę o potwierdzenie do klienta.
• Przykład skryptu: „psp_reconcile —from T-30m —to now() —apply”. Najpierw dry-run, potem commit zmian.

Magazyn i integracje: deduplikacja i retry z głową

• Kolejki integracji z ERP/WMS z kluczami idempotencji (order_id, wersja stanu). Po wstaniu systemu pozwól na „pull” z ERP z ostatnich 2 godzin i dopiero potem włącz „push”.
• Zamówienia w statusie „w trakcie” po awarii — wyślij zapytanie o rezerwacje do WMS, różnice zbij automatycznie do najbliższego stanu spójnego (np. zdejmij rezerwację, jeśli płatność nie doszła).

Logika naprawcza w aplikacji

• Endpointy naprawcze „/admin/tools/retry-payment”, „/admin/tools/rebuild-inventory-delta” z kontrolą dostępu i dziennikiem działań.
• Idempotentne webhooki: przechowuj „event_id” i ignoruj powtórki; bez tego po DR webhooki z PSP potrafią „zalać” zamówienia.

8) Tryby degradacji: sprzedawaj, nawet jeśli nie w 100%

Proste przełączniki, które ratują dzień

• Katalog tylko do odczytu: blokada edycji kont i opinii, priorytet dla koszyka i płatności.
• Fallback płatności: jeśli PSP A nie odpowiada, oferuj BLIK/przelew tradycyjny/płatność przy odbiorze z wyjaśnieniem na checkout.
• „Zarezerwuj i zapłać później”: przy braku PSP generuj rezerwację z linkiem do płatności po wznowieniu usług.
• Statyczny status page poza główną infrastrukturą (np. inny hosting) — aktualizowany z runbooka biznesowego.

Krótki przykład: awaria PSP w weekend — w 5 minut wyłączasz karty, zostawiasz BLIK/przelew i jasny komunikat. Lepsze 70% konwersji niż 0% przy pełnym „maintenance”.

9) Monitoring i sygnały do przełączenia na DR

Co mierzyć, aby decyzje nie były „na oko”

• Lag replikacji bazy, p95/p99 checkoutu, odsetek 5xx/4xx w API, timeouty do PSP, głębokość kolejek (ERP/WMS), błędy zapisu w storage.
• Health backupów: „ostatni udany restore” jako metryka w monitoringu, nie tylko „ostatni backup OK”.
• Alerty z progami zgodnymi z RTO/RPO (np. lag > RPO/2 => czerwony alert).

Reguły przełączenia i odpowiedzialność

• Definicja „major incident”: które metryki i przez ile minut. Decyzja o failoverze przypisana roli, nie osobie.
• Pre-checklist przed przełączeniem: replikacja w tyle < RPO, obrazy gotowe, DNS TTL skrócony, komunikat klienta przygotowany.

10) Mini lista kontrolna DR sklepu (szybki przegląd)

• RTO/RPO zmapowane per komponent i zatwierdzone przez biznes.
• Backup 3-2-1-0: inny region + inne konto, miesięczny test odtwarzania zaliczony.
• Runbook techniczny i biznesowy, przetestowane „od A do Z”.
• IaC + obrazy niezmienne z wersjami spójnymi ze schematem bazy.
• Plan B dla PSP, e-mail i CDN oraz szybkie przełączniki w panelu.
• Idempotency-key w płatnościach i integracjach, skrypt reconcile gotowy.

11) Koszty DR: gdzie oszczędzać, a gdzie nie ryzykować

Hot-warm zamiast hot-hot dla mniejszych sklepów

Pełne multi-active bywa przerostem formy. Często wystarczy „ciepły” standby: baza i storage gotowe do promocji, aplikacja startuje na żądanie.

• Przykład: replikacja bazy cross-region + terraformowany szkielet (VPC/LB/sekrety) bez stałych nodów aplikacji. Compute uruchamiasz dopiero przy failoverze.
• Sens praktyczny: koszty stałe niższe o rząd wielkości, RTO nadal w dziesiątkach minut, nie godzinach.

Backupy w tańszych klasach storage z „buforem gorącym”

Archiwum jest tanie, ale czas odzysku potrafi zjeść RTO. Trzymaj ostatnie N snapshotów w klasie „hot”, resztę archiwizuj.

• Przykład: 7 dziennych snapshotów w Standard, starsze do Glacier/Archive; test odtwarzania raz w miesiącu z archiwum.
• Efekt vs wysiłek: kilka reguł lifecycle daje oszczędność bez ryzyka wydłużenia odtwarzania „z wczoraj”.

Secondary DNS tylko dla krytycznych rekordów

Podwójny DNS dla całej strefy bywa drogi i skomplikowany. Zduplikuj rekordy ruchu transakcyjnego, resztę zostaw u głównego dostawcy.

• Przykład: A/ALIAS dla „checkout.” i „api.” w dwóch providerach; statyczne „www.” i marketing w jednym.
• Sens praktyczny: redukcja opłat i złożoności, a jednocześnie szybkie przełączenie najważniejszych ścieżek.

12) SaaS i headless: DR, gdy nie kontrolujesz wszystkiego

Ekspozy z SaaS do własnego „source of truth”

Jeśli core stoi na platformie SaaS, odzyskaj kontrolę przez regularne eksporty i buforowanie kluczowych danych.

• Przykład: cykliczny export zamówień, klientów i konfiguracji stawek do obiektu + replikacja do BI/DWH. Webhooki zapisuj w kolejce z idempotency.
• Sens praktyczny: przy awarii SaaS wciąż przeliczysz zwroty, wyślesz powiadomienia i zrobisz reconcile z PSP.

Fallback frontu przy padzie backendu SaaS

Nawet na SaaS możesz utrzymać „tryb katalogu” lub „rezerwuj i zapłać później” na własnym froncie.

• Przykład: headless frontend na CDN + cache koszyka w przeglądarce; brak API => zbieraj leady/rez., wyślij link do płatności po wznowieniu.
• Efekt vs wysiłek: 1 sprint pracy daje miękkie lądowanie zamiast czarnego ekranu.

Re-play webhooków i kolejność zdarzeń

Po przerwie łączności SaaS wyśle grad zdarzeń. Zachowaj kolejność i odrzucaj duplikaty.

• Przykład: przechowuj „event_id” i „event_time”; przetwarzaj według czasu, duplikaty ignoruj, brakujące dociągaj z API po „since=last_seen”.
• Sens praktyczny: koniec z „przestawianiem” statusów zamówień w tył/przód po odtwarzaniu.

13) Cache i indeksy: od razu zdatne do sprzedaży

Snapshoty wyszukiwarki zamiast pełnej reindeksacji

Rebuild indeksu po DR potrafi trwać dłużej niż całe odtwarzanie.

• Przykład: OpenSearch/Elastic snapshot repo w obiekcie; po przywróceniu bazy montujesz snapshot z T-1h i robisz tylko delta-index.
• Sens praktyczny: klienci widzą wyniki po minutach, nie godzinach; CPU idzie na sprzedaż, nie na indeksację.

Pre-warming kluczowych cache

Zimny CDN i aplikacja = skoki latency i błędy 5xx.

• Przykład: lista TOP 500 URL (produkt/kategoria/checkout) odświeżana co tydzień; po DR job „prewarm” odpala równolegle z otwarciem ruchu.
• Efekt vs wysiłek: prosty skrypt curl/Locust zmniejsza p95 o kilkadziesiąt procent przy pierwszych wizytach.

Stale-while-revalidate jako bezpłatne turbo

Gdy origin wstaje, CDN może przez chwilę serwować „stare” treści.

• Przykład: nagłówki Cache-Control: s-maxage=600, stale-while-revalidate=300 dla list kategorii i opisów, bez stosowania dla checkout API.
• Sens praktyczny: UX stabilny, a jednocześnie brak ryzyka w procesach transakcyjnych.

14) DNS i domeny: drobiazgi, które potrafią wstrzymać sprzedaż

TTL per rekord, nie globalnie

Krótki TTL na wszystko to wyższe koszty i brak korzyści. Skracaj tylko tam, gdzie planujesz failover.

• Przykład: „api.” i „checkout.” TTL=60s, „www.” TTL=1800s; w runbooku krok „skróć TTL 24h przed planowanym testem DR”.
• Sens praktyczny: szybsze przełączenie bez zbędnych przepaleń DNS.

Plan awaryjny na rejestratora i NS

Pad rejestratora lub blokada konta może unieruchomić nawet perfekcyjny DR.

• Przykład: dostęp „break-glass” (MFA offline), drugi kontakt administracyjny w WHOIS, przygotowana strefa w Secondary DNS (AXFR/transfer z podpisem).
• Efekt vs wysiłek: godzina konfiguracji dziś oszczędza dzień nerwów przy incydencie.

CAA/DS i certyfikaty po odtworzeniu

Zmiana ścieżek i LB po DR bez sprawdzonych certów kończy się 526/SSL error.

• Przykład: automatyczna emisja certyfikatów w regionie B (ACME/Let’s Encrypt) + CAA dopuszczające CA używanego w DR.
• Sens praktyczny: brak ręcznego „polowania” na cert w najgorszym możliwym momencie.

15) Krótkie scenariusze „z życia” i gotowe reakcje

Checkout wolniejszy o 2x po DR

• Reakcja: włącz tryb degradacji (mniej rekomendacji, brak recenzji), zwiększ rozmiar workerów tylko dla ścieżki /checkout, uruchom pre-warm cache PSP SDK.
• Przykład: feature flag „light-checkout” z rolloutem 100% na 24h.

ERP nie odbiera przez 6 godzin

• Reakcja: przełącz integrację na pull co 15 min, odkładaj eventy w kolejce z idempotency-key, blokuj anulacje po stronie sklepu do czasu potwierdzenia rezerwacji.
• Przykład: task „erp_sync —mode=pull —since=last_success” uruchamiany z runbooka biznesowego.

CDN serwuje stare zdjęcia po przełączeniu originu

• Reakcja: purge tylko prefiksów „/media/products/last-7d/”, ustaw versioning query (v=timestamp) w linkach generowanych przez aplikację.
• Przykład: migracja szablonu obrazków „/img/{sku}.jpg?v={build_id}”.

Zamiast globalnego „purge all” zrób selektywną, etapową walidację: najpierw unieważnij tylko ostatnie katalogi i warianty (miniatury, webp/avif), po 5–10 minutach — kolejne poziomy. Jeśli CDN wspiera tagi/surrogate-keys, oznaczaj zasoby produktowe wspólnym tagiem i czyść

16) Testy odtwarzania bez zatrzymania ruchu

Dry-run: odtwarzanie „obok”, nie „zamiast”

Najtańszy i najbezpieczniejszy start to pełny restore środowiska w odizolowanej sieci, z danymi zamaskowanymi.

• Przykład: przywróć snapshot bazy do read-only, postaw aplikację w trybie „no-mail/no-psp”, odpal testy checkoutu do sandbox PSP.
• Efekt vs wysiłek: 1–2 godziny pracy skryptów dają realny czas TTR i listę brakujących sekretów/zmiennych środowiskowych.

Game day w godzinach niskiego ruchu

Krótkie, kontrolowane cięcie jednej zależności pokazuje prawdziwe zachowanie systemu pod presją.

• Przykład: na 10 min odetnij DNS do ERP lub PSP sandbox; obserwuj kolejki, idempotency, komunikaty dla klienta.
• Antywzorzec: 24-godzinne „mega testy” raz w roku. Lepsze 4 mini-symulacje kwartalnie.

Kryteria zaliczenia testu (mierzalne)

Bez jasnych progów wszystko „działa”. Ustal minimalne minimum i trzymaj się go.

• Przykład: RTO ≤ 45 min (od decyzji do pierwszego zamówienia), błąd 5xx ≤ 1% po 15 min od otwarcia ruchu, różnica stocku do reconcile ≤ 0,5% SKU.
• Po co: żeby biznes wiedział, czy akceptowalne ryzyko faktycznie jest akceptowalne.

17) Komunikacja i UX w trybie awaryjnym

Tryb „lekki checkout” jako funkcja, nie skrypt na boku

Jedno kliknięcie, zero dylematów. Flaga w konfiguracji odchudza widoki i zależności.

• Przykład: wyłącz sugestie, recenzje, cross-sell, zredukuj zewnętrzne skrypty, wymuś płatność 1–2 metodami o najwyższym SLA.
• Efekt vs wysiłek: kilkanaście KB mniej JS i mniej requestów = niższe p95/p99 bez skalowania.

Transparentny banner i kolejka miękka

Krótki komunikat z czasem odświeżenia potrafi uratować konwersję.

• Przykład: banner „Działamy w trybie awaryjnym, czas płatności może być dłuższy (do 60 s).” + lekka kolejka (token + ETA) przy skoku 429.
• Antywzorzec: ukrywanie problemu i losowe 500/timeouty — klienci wracają rzadziej niż po uczciwym komunikacie.

Fallback na wiadomości offline

Kiedy e-mail pada, zamień je na SMS lub powiadomienia web push w kluczowych miejscach lejka.

• Przykład: po złożeniu zamówienia wysyłaj krótkiego SMS z numerem i linkiem do statusu, a e-mail dorzuć po wznowieniu.
• Efekt vs wysiłek: prosty webhook do taniego dostawcy SMS domyka komunikację bez ingerencji w backend.

18) Po odtworzeniu: rozrachunki i spójność danych

Reconcile płatności w obu kierunkach

Najpierw pobierz ground truth z PSP, dopiero potem poprawiaj statusy lokalnie.

• Przykład: job „payments_reconcile —since=last_success” pobiera transakcje, mapuje po idempotency-key i — jeśli brakuje order_id — tworzy wpis „orphan” do manualnej weryfikacji.
• Po co: unikasz podwójnych capture/refund i nie ścigasz duchów z logów.

Stock i rezerwacje: algorytm łagodnego powrotu

Przy niespójności zapasów nie rób globalnego „sync hard”. Działaj etapami.

• Przykład: najpierw „ship-block” dla SKU z rozjazdem > N sztuk, potem synchronizacja partii po partii według ABC (najbardziej rotujące jako pierwsze).
• Efekt vs wysiłek: mniej oversell/undersell i krótsze okno ryzyka na topowych produktach.

Ścieżka dowodowa dla księgowości

Zbiorczy raport incydentu to nie luksus — bez niego wracają te same błędy.

• Przykład: CSV „orders_delta.csv” (przed/po), „payments_delta.csv” (autoryzacje/capture/refund), „stock_delta.csv”; dołącz hash backupu i timestampy.
• Antywzorzec: odtwarzanie „na oko”, bez artefaktów — brak audytu to otwarta furtka do powtórki problemu.

19) Zmiany w trakcie incydentu: jak nie pogorszyć sprawy

Freeze kodu, hotfixy tylko przez konfigurację

W DR wdrażasz config i flagi, nie nowy kod.

• Przykład: przełącznik „psp_set=minimal” i „feature.reviews=false” w konsoli; zakaz deployu bez zgody roli „incident commander”.
• Efekt vs wysiłek: mniejsze ryzyko regresji i krótszy MTTR.

Plan powrotu do regionu A

Failback to też projekt. Bez check-listy łatwo zgubić dane.

• Przykład: odwrócenie replikacji (B→A), freeze zamówień na 2–3 min, synchronizacja delta, test canary 5% ruchu, potem 25/50/100% z rollbackiem jednym przełącznikiem DNS.
• Po co: minimaliz