Symulacje incydentów

1) Dlaczego symulacje

• niższe MTTD/MTTA/MTTR, zwiększenie zaufania do kickbacks i fylovers;
• zidentyfikowanie luk w procesach (eskalacja, komunikacja) i niedociągnięć architektonicznych;
• służyć jako wejście do RCA → CAPA i poprawić dokumentację (runbook/SOP);
• Potwierdzenie gotowości do spełnienia wymogów dotyczących SLA/regulacji/audytu.

2) Formaty symulacji

Tablet (tablet) - skrypt konwersacyjny na tablecie/czacie: tani, szybki, świetny do praktykowania ról i komunikacji.
Dzień Gry (ćwiczenia w scenie/sprzedaż z ograniczeniami) - praktyczne kroki dla odtwarzaczy; w sprzedaży - tylko bezpieczne, odwracalne działania z wyraźnymi bramami.
Chaos Engineering - kontrolowane awarie (odłączenie zależności/sieci/węzłów) w celu sprawdzenia stabilności i bram SLO.
Ćwiczenia DR (Recovery Disaster) - awaria AZ/region, odzyskiwanie z kopii zapasowych, przełączanie dostawców.
Comms-drill - czysto komunikacja: strona stanu, szablony wiadomości, PR/Legal.

3) Role i obowiązki

Incydent Commander (IC) - podejmuje decyzje, prowadzi plan, deeskalacja.
Tech Lead (TL) - diagnostyka, techniczne „zastrzyki” i hipotezy.
Comms Lead (CL) - wewnętrzne/zewnętrzne aktualizacje, strona stanu.
Skryba - protokół (linia czasowa, działania, decyzje, artefakty).
Obserwatorzy/oceniający - rejestrowanie wskaźników i zgodność z procedurami.
Red Team (opcjonalnie) - wprowadza nieoczekiwane „zastrzyki”.

4) Metryka sukcesu symulacji

MTTD/MTTA/MTTR według incydentu syntetycznego.
Comm SLA: aktualność i jakość aktualizacji.
SLO-barierki: prawidłowa reakcja na szybkość spalania, kworum próbek zewnętrznych.
Wierność książki startowej:% wykonanych kroków na dokument, brak improwizacji.
Opóźnienie eskalacji - szybkość podłączenia żądanej roli/dostawcy.
Pass-rate list kontrolnych: zgodność z „gotowe/przyjęte/zamknięte”.
Hałas i zmęczenie: dodatkowe wpisy, przeciążenie na dyżur.
Zakończenie CAPA: odsetek zakończonych działań po symulacji.

5) Przygotowanie: czego potrzebujesz przed rozpoczęciem

Cel i hipotezy: co sprawdzamy (procesy, architektura, ludzie).
Scenariusz i „zastrzyki”: kolejność objawów/zdarzeń z czasem.
ograniczenia bezpieczeństwa: zakaz nieodwracalnych zmian; cofnąć punkty.
Dane i stoiska: ruch syntetyczny, flagi funkcji degradacji, bezpieczne klucze.
Dokumenty: linki do runbooka/SOP, eskalacja, lista kontaktowa dostawców.
Możliwość obserwacji: wstępnie oznaczone deski rozdzielcze/wpisy, kanarki testowe.
Logistyka: czas/czas trwania, uczestnicy, kanał wojenny-pokój, nagrywanie.

6) Wykonanie symulacji: etapy

1. Krótki (5-10 min): IC przypomina cele, role, zasady bezpieczeństwa, kryteria ukończenia.
2. T0 - Zastrzyk objawów: alert (s), spadek SLI w biznesie, status zewnętrzny dostawcy.
3. Triage i eskalacja: przypisywanie SEV, zamrażanie wersji, łączenie niezbędnych ról.
4. Diagnostyka: hipotezy, DNS/TLS/CDN/DB/cache/bus check, adnotacje uwolnienia.
5. Działania łagodzące: otkat/kanareyka, flagi degradacji, awaria dostawcy, limity/retras.
6. Komunikacja: regularne aktualizacje (format: Impakt → Diagnostyka → Deystviya → Sled. aktualizacja).
7. Odzyskiwanie i weryfikacja: syntetyka zewnętrzna + SLI w zielonej strefie N.
8. Sprawozdanie (AAR): 15-30 min - fakty, wnioski, CAPA.

7) Przykładowe scenariusze (katalog)

Spadek sukcesu płatniczego: dostawca A degraduje się w jednym kraju; przewidywane działania - redystrybucja ruchu, umożliwienie uproszczonego UX, komunikacja.
Awaria DNS: błąd zapisu/TTL, niektórzy użytkownicy nie rozwiązują domeny; spodziewane kroki - poprawki/folback, rozliczenie CDN, aktualizacje stanu.
Wygasły certyfikat TLS: uścisk dłoni dla starych klientów; przedłużenie i kontrola łańcuchowa w oczekiwaniu.
Kafka lag: zwiększenie opóźnienia w zdarzeniach KYC/AML; oczekiwania - skala konsumentów, ograniczenie producentów.
Baza danych p99 i wzrost 5xx: wąskie wskaźniki, limit połączenia; oczekiwania - flagi funkcji, limity, hotfix/rollback.
Awaria regionalna: zamknięcie AZ/PoP; oczekiwanie - przełączanie GSLB/Anycast, weryfikacja danych i SLO.
Drill komunikacyjny: wszystko jest „zielone”, ale sprawdzamy wzory, odstępy i koordynację z Legal/PR.

8) Szablon „wtrysk” (karta)

ID: INJ-2025-11-01-01
Purpose: Verification of failover payments and comms SLA
Trigger T0: 30% reduction in transaction success in the TR region (alert SLI + burn rate)
Signals: 5xx growth in payment API, external status PSP-A = partial outage
Expected actions: reduction of the share on PSP-A to 30%, inclusion of degrade-payments-UX, status update 15 min
Success criteria: success of payments ≥ 98% in 30 minutes, two green SLI intervals
NOTAM (security): prohibition of direct database edits; flags/routing only

9) Bezpieczeństwo i zgodność

Symulacje produkcji - tylko odwracalne: flagi funkcyjne, przełączanie ruchu w małych frakcjach, uwagi do odczytu, „ruch cieni”.
Kontrola/audyt dostępu: wszystkie działania za pośrednictwem ChatOps/pipeline; Logowania w niezmodyfikowalnym magazynie.
PII/tajemnice - nieużywane w artefaktach szkoleniowych; depersonalizowane dane.
Regulacja: jeżeli symulacja wpływa na komunikację klienta - oznaczanie „nauczania” w kanałach prywatnych; publiczne stanowiska nie są naśladowane.

10) Ocena i AAR → RCA → CAPA

AAR (After Action Review) - bezpośrednio po ćwiczeniu: co było oczekiwane/widziane, co działało/nie.
RCA - dla znaczących awarii (na przykład eskalacja nie zadziałała) według szablonu RCA.
CAPA - lista działań z właścicielami/terminami/miernikami efektów (zmiany w odtwarzaczach, wpisach, architekturze).
Punkty kontrolne - D + 14/D + 30: weryfikacja wykonania, powtarzane mini wiertła w punktach wrażliwych.

11) Dokumentacja i artefakty

Plan symulacji: cele, scenariusz, zastrzyki, uczestnicy, okna, kryteria sukcesu.
Linia czasu (UTC): T0...Tn, rozwiązania IC, kroki techniczne, aktualizacje.
Zdjęcia desek rozdzielczych/dzienników, wyciągów z wpisów i statusów.

Raport podsumowujący - Wskaźniki, rozbieżności w Playbook, CAPA

Aktualizacje dokumentacji: runbook/SOP/edycje kontaktowe, linki do nowych desek rozdzielczych.

12) Częstotliwość i zasięg

Tabletop: 2-4 razy w miesiącu (według kluczowych strumieni i ról).
Dni gry w scenie: 1-2 razy w miesiącu.
Przypadki chaosu (prod-light): kwartalne, ściśle przez bramy.
Ćwiczenia DR: 1-2 razy w roku z prawdziwym przełączaniem.
Comms-drill: miesięcznie trenować szablony i aktualizacje SLA.

13) Listy kontrolne

Przed symulacją

• Scenariusz, „zastrzyki”, kryteria sukcesu, okna bezpieczeństwa.
• Role, kanały, status szablonów są spójne.
• Dostępność stojaków/flag/desek rozdzielczych sprawdzonych.
• Plan wycofania i odwracalności jest udokumentowany.
• Ryzyko i wpływ na ocenę SLO/klientów.

Podczas

• Przypisane SEV, zwolnienia zamrożone (w razie potrzeby).
• Komunikacja w harmonogramie, format jest spójny.
• Wszystkie działania za pośrednictwem narzędzi audytu.
• Scribe utrzymuje protokół, zbiera artefakty.
• Bezpieczeństwo: przestrzegane są zakazy/ograniczenia.

Po

• AAR opublikowane, raport zapisany.
• RCA (w przypadku awarii) jest inicjowany.
• CAPA są wydawane z właścicielami/terminami.
• Zaktualizowany książka startowa/SOP/kontakty.
• Planowana jest powtórna część słabych punktów.

14) Anty-wzory

„Improwizacja zamiast planu” - nie ma scenariusza i kryteriów sukcesu.
Ryzyko bez bram i plan anulowania - ćwiczenia zamieniają się w incydent.
Praca tylko sprzętu bez komunikacji i eskalacji.
Brak AAR/RCA - zespół nie uczy się.
Prod-chaos bez obserwowalności i SLO-gardrails.
Nieprzezroczyste prawa: tajne ręczne edycje w prod.

15) Mini szablony

Porządek dzienny gry (60-90 min)

1. Krótkie (5 min) → Cele, role, bezpieczeństwo.
2. Scenariusz T0 (5 min) → Prezentacja objawów.
3. Triage/eskalacja (10 min).
4. Diagnostyka + działania (30-45 min) - 1-2 „wstrzyknięcia”.
5. Odzyskiwanie i weryfikacja (10 min).
6. AAR (15 min) - wnioski, CAPA.

Szablon AAR (krótki)

What was expected:
What happened:
What worked:
What didn't work:
Solutions and why:
Actions (CAPA) with deadlines:
Responsible persons:
Retest Date:

16) Sedno sprawy

Symulacje incydentów są „symulatorem” dla ludzi, procesów i architektury. Regularne, bezpieczne i wymierne ćwiczenia zmieniają kryzysy w rutynowe: zespół reaguje szybciej, playbooks naprawdę działa, architektura jest bardziej stabilna, a regulator i klienci widzą dojrzałość funkcji operacyjnej. Najważniejsze jest jasne cele, bezpieczne bramy, dobre wskaźniki i obowiązkowe AAR → RCA → CAPA.