Simulări incidente

1) De ce fac simulări

• reducerea MTTD/MTTA/MTTR, creșterea încrederii în kickback-uri și fylovere;
• identificarea lacunelor de proces (escaladare, comunicații) și a deficiențelor arhitecturale;
• servi ca o intrare la RCA→CAPA și de a îmbunătăți documentația (runbook/SOP);
• Confirmați disponibilitatea pentru cerințele SLA/de reglementare/audit.

2) Formate de simulare

Tabletop (tabletop) - script conversațional pe bord/chat: ieftin, rapid, excelent pentru practicarea rolurilor și comunicațiilor.
Ziua Jocului (exerciții în scenă/vânzare cu restricții) - pași practici pentru cărți de joc; în vânzări - numai acțiuni sigure, reversibile, cu porți clare.
Chaos Engineering - eșecuri controlate (deconectarea dependențelor/rețelelor/nodurilor) pentru a verifica stabilitatea și porțile SLO.
Exerciții DR (Recuperare în caz de dezastru) - eșec AZ/regiune, recuperare de la copii de rezervă, furnizori de comutare.
Comms-drill - comunicații pur: pagina de stare, șabloane de mesaje, PR/Legal.

3) Roluri și responsabilități

Incident Commander (IC) - ia decizii, conduce un plan, de-escaladare.
Tech Lead (TL) - diagnosticare, „injecții” tehnice și ipoteze.
Comms Lead (CL) - actualizări interne/externe, pagina de stare.
Scribe - protocol (cronologie, acțiuni, decizii, artefacte).
Observatori/Evaluatori - măsurători de înregistrare și respectarea procedurilor.
Red Team (opțional) - introduce „injecții” neașteptate.

4) Măsurarea succesului simulării

MTTD/MTTA/MTTR prin incident sintetic.
Comm SLA: actualitatea și calitatea actualizărilor.
SLO-guardrails: reacție corectă la arde-rata, cvorum de probe externe.
Fidelitate Runbook:% din pași finalizați pe document, fără improvizație.
Latența de escaladare - viteza de conectare a rolului/furnizorului dorit.
Lista de verificare trece-rata: conformitatea cu „gata/acceptat/închis”.
Zgomot și oboseală: alerte suplimentare, supraîncărcare la apel.
Finalizarea CAPA: procentul de acțiuni finalizate după simulare.

5) Pregătirea: ceea ce aveți nevoie înainte de începere

Scop și ipoteze: ceea ce verificăm (procese, arhitectură, oameni).
Scenariu și „injecții”: succesiunea simptomelor/evenimentelor cu temporizări.
Restricții de securitate: interzicerea schimbărilor ireversibile; anulează punctele.
Date și standuri: trafic sintetic, steaguri caracteristici de degradare, chei securizate.
Documente: link-uri către runbook/SOP, escaladare, lista de contacte a furnizorilor.
Observabilitate: tablouri de bord/alerte pre-marcate, canare de testare.
Logistică: timp/durată, participanți, canal de război, înregistrare.

6) Executarea simulării: etape

1. Scurt (5-10 min): IC seamănă cu obiective, roluri, reguli de siguranță, criterii de finalizare.
2. T0 - Injectarea simptomelor: alertă (alerte), scăderea SLI de afaceri, starea externă a furnizorului.
3. Triaj și escaladare: atribuirea SEVS, înghețarea eliberărilor, conectarea rolurilor necesare.
4. Diagnostic: ipoteze, DNS/TLS/CDN/DB/cache/bus check, eliberarea adnotărilor.
5. Acțiuni atenuante: otkat/kanareyka↓, steaguri de degradare, failover furnizor, limite/retras.
6. Comunicări: actualizări regulate (format: Impakt→Diagnostika→Deystviya→Sled. actualizare).
7. Recuperare și verificare: sintetice externe + SLI în intervalele N ale zonei verzi.
8. Debrief (AAR): 15-30 min - fapte, concluzii, CAPA.

7) Scenarii de exemplu (catalog)

Scăderea succesului plăților: Furnizorul A se degradează într-o țară; acțiuni așteptate - redistribuirea traficului, permițând UX simplificat, comunicare.
Eșec DNS: scriere/eroare TTL, unii utilizatori nu rezolvă domeniul; pași așteptați - remedieri/folback, compensare CDN, actualizări de stare.
Certificat TLS expirat: pauze de strângere de mână pentru clienții vechi; extensie de urgență și verificare în lanț în așteptare.
Kafka lag: întârziere crescândă a evenimentelor KYC/AML; așteptări - scalarea consumatorilor, limitarea producătorilor.
Baza de date p99 ↑ și creștere 5xx: indici înguste, limita de conexiune; așteptări - dispun de steaguri, limite, hotfix/rollback.
Eșec regional: închiderea AZ/PoP; așteptare - comutare GSLB/Anycast, verificarea datelor și SLO.
Burghiu de comunicare: totul este „verde”, dar verificăm modele, intervale și coordonare cu Legal/PR.

8) Șablon „injecție” (card)

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) Siguranță și conformitate

Simulări de producție - numai reversibile: steaguri de caracteristici, comutarea traficului în fracții mici, remarci pentru lectură, „trafic umbră”.
Control acces/audit: toate acțiunile prin ChatOps/pipeline; Jurnalele de stocare non-modificabile.
PII/secrete - nefolosite în artefacte de antrenament; date depersonalizate.
Reglementare: dacă simularea afectează comunicațiile clienților - marcarea „predării” în canale private; posturile publice nu sunt imitate.

10) Evaluare și AAR → RCA → CAPA

AAR (After Action Review) - imediat după exercițiu: ceea ce era de așteptat/văzut, ceea ce a funcționat/nu.
RCA - pentru eșecuri semnificative (de exemplu, escaladarea nu a funcționat) în conformitate cu modelul RCA.
CAPA - lista de acțiuni cu proprietari/termene limită/metrici de efect (modificări în playbook-uri, alerte, arhitectură).
Puncte de control - D + 14/D + 30: verificarea execuției, mini-exerciții repetate în puncte vulnerabile.

11) Documentație și artefacte

Planul de simulare: obiective, scenariu, injecții, participanți, ferestre, criterii de succes.
Linia de timp (UTC): T0...Tn, soluții IC, pași tehnici, actualizări.
Imagini de tablouri de bord/jurnale, extrase de alerte și stări.

Raport de sinteză - Metrics, Playbook Discrepancies, CAPAs

Actualizări documentație: runbook/SOP/contact edits, link-uri către noi tablouri de bord.

12) Frecvență și acoperire

Tabletop: de 2-4 ori pe lună (prin fluxuri cheie și roluri).
Zilele jocului în etapă: 1-2 ori pe lună.
Cazuri de haos (prod-light): trimestrial, strict prin porți.
Exerciții DR: 1-2 ori pe an cu comutare reală.
Comms-drill: lunar pentru a instrui șabloane și actualizări SLA.

13) Liste de verificare

Înainte de simulare

• Scenariu, „injecții”, criterii de succes, ferestre de siguranță.
• Rolurile, canalele, starea șabloanelor sunt consecvente.
• Disponibilitatea standurilor/steagurilor/tablourilor de bord bifate.
• Planul de retragere și reversibilitate este documentat.
• Riscurile și impactul asupra SLO/clienților evaluate.

În timpul

• SEV atribuite, congela eliberări (dacă este necesar).
• Comunicarea pe un program, formatul este consecvent.
• Toate acțiunile prin instrumente de audit.
• Scribul menține un protocol, colectează artefacte.
• Siguranță: interdicțiile/restricțiile sunt respectate.

După

• AAR postat, raport salvat.
• RCA (în caz de eșecuri) este inițiată.
• CAPAs sunt emise cu proprietari/termene limită.
• Runbook actualizat/SOP/contacte.
• O retestare a vulnerabilităților este planificată.

14) Anti-modele

„Improvizație în loc de plan” - nu există scenariu și criterii pentru succes.
Riscurile fără porți și planul de anulare - exercițiile se transformă într-un incident.
Elaborarea numai echipamente fără comunicații și escaladare.
Lipsa AAR/RCA - echipa nu învață.
Prod-haos fără observabilitate și SLO-gardrails.
Drepturi opace: modificări manuale secrete în prod.

15) Mini șabloane

Agenda zilei de joc (60-90 min)

1. Scurt (5 min) → Obiective, roluri, securitate.
2. Scenariul T0 (5 min) → Prezentarea simptomelor.
3. Triaj/escaladare (10 min).
4. Diagnostic + acțiuni (30-45 min) - 1-2 „injecții”.
5. Recuperare și verificare (10 min).
6. AAR (15 min) - concluzii, CAPA.

Șablon AAR (scurt)

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

16) Linia de jos

Simulările incidentelor sunt un „simulator” pentru oameni, procese și arhitectură. Exercițiile regulate, sigure și măsurabile transformă crizele într-o rutină: echipa reacționează mai repede, cărțile de redare funcționează cu adevărat, arhitectura este mai stabilă, iar autoritatea de reglementare și clienții văd maturitatea funcției operaționale. Principalul lucru este obiective clare, porți sigure, valori bune și AAR→RCA→CAPA obligatorii.