Incidente și cărți de redare SRE

1) Care este incidentul și modul în care se referă la SLO

Un incident este un eveniment care încalcă o funcție SLO/serviciu sau creează un risc de încălcare (un buget eronat este ars inacceptabil de repede).
Valori clasice: MTTD, MTTA, MTTR, MTBF.
Eroarea bugetară și rata de ardere determină prioritatea și ferestrele de escaladare.

2) Niveluri de severitate (VES) și criterii

Declanșatoare SEV: peste 5xx%, p95> prag, declin de plată spike, Kafka-lag> prag, NodeNotReady> X min, TLS expiră <7 zile, semnale DDoS/scurgere.

3) Roluri și responsabilități (RACI)

Incident Commander (IC) - unic de luare a deciziilor, gestionarea fluxului de sarcini, schimbarea statutului SEVV.
Ops Lead (Tech Lead) - strategie tehnică, ipoteze, coordonarea remedierilor.
Communications Lead (Comms) - actualizări de stare (interne/externe), StatusPage/chat/mail.
Scribe (Chronicler) - cronologie, soluții, artefacte, link-uri către grafice/jurnale.
Ingineri de gardă/IMM-uri - executarea de acțiuni playbook.
Securitate/Confidențialitate - Activat pentru incidente de securitate sau PII.
FinOps/Payments - atunci când afectează facturarea/PSP/cost.

4) Ciclul de viață incident

1. Detectarea (alertă/raport/sintetic) → auto-crearea unui card incident.
2. Triaj (IC atribuit, SEV atribuit, colectarea contextului minim).
3. Stabilizare (atenuare: dezactivați caracteristica/rollback/rate-limit/failover).
4. Investigație (ipoteze RCA, culegerea faptelor).
5. Service recovery (validare SLO, observare).
6. Comunicare (interior/exterior, raport final).
7. Postmortem (fără taxe, plan CAPA, proprietari, termene limită).
8. Prevenire (teste/alerte/playbook-uri/steaguri, instruire suplimentară a echipei).

5) Comunicații și „cameră de război”

Unified Incident Channel ('# inc-sev1-YYYYYMMDD-hhmm'), numai fapte și acțiuni.

Comenzi în stilul protocolului radio: "IC: Atribui versiunea rollback 1. 24 → ETA 10 min"

Actualizări de stare: SEV-1 la fiecare 15 minute, SEV-2 la fiecare 30-60 de minute.
Status Page/comunicare externă - prin Comms Lead după șablon.
Interzis: camere paralele „liniștite”, ipoteze netestate într-un canal comun.

6) Alertarea și SLO-burn (reguli de exemplu)

canal rapid (1-5 min) și canal lent (1-2 h) arde rata.
Multi-semnale: eroare de buget, 5xx%, p95, Kafka-lag, rata de scădere a plăților, sintetice.
Căutați cauza principală - numai după stabilizarea simptomelor.

promql
Error rate 5xx> SLO sum (rate (http_requests_total{status=~"5"..}[5m]) )/sum (rate (http_requests_total[5m]))> 0. 01

Burn-rate fast (example)
(sum(rate(http_requests_total{status=~"5.."}[1m])) / sum(rate(http_requests_total[1m])))
/ (1 - SLO) > 14. 4

7) Playbooks vs ranbooks

Playbook - scenariul acțiunilor pe tipuri de incidente (ramificare, condiții, riscuri).
Runbook - o anumită „hartă” de pași/comenzi (verificări, remedieri, verificare).
Regulă: playbook se referă la mai multe runbooks (rollback-uri, feature-steaguri, failover, scalare, blocarea traficului, etc.).

8) șablon de card incident

yaml id: INC-YYYYMMDD-XXXX title: "[SEV-1] Рост 5xx на API /payments"
status: active    monitoring    resolved sev: 1 reported_at: 2025-11-03T17:42Z ic: <ФИО>
ops_lead: <name>
comms_lead: <name>
scope: regions: [eu-west-1], tenants: [prod], services: [api, payments]
impact: "5xx = 12% (usually <0. 5%), deposit conversion -20%"
mitigation: "rollback to 1. 23. 4, rate-limit 2k rps on, feature X off"
timeline:
- "17:42: alert SLO burn-rate fast"
- "17:46: IC appointed, war-room open"
- "17:52: release 1 found. 24 as a candidate"
- "18:02: Rollback complete, 5xx back to 0. 3%"
artifacts:
dashboards: [...]
logs: [...]
traces: [...]
risk: "another surge is possible when turning on feature X"
next_steps: "canary release, tests, postmortem until 2025-11-05"

9) șablon SRE playbook (Markdown)

markdown
Playbook: <title>
Area/symptoms
List of detectors, signatures in metrics/logs/traces.

Triage & Mitigation
- [] Restrict traffic/enable WAF rule/OFF feature
- [] Rollback/canary release/roll out configuration fix
- [] Enable degradation mode (read-only, cache force)

Diagnostics (RCA hints)
- Metrics:... Logs:... Trails:...
- Common Root Causes/Hypothesis Checklist

Risks and communications
- Internal/external updates, SLA obligations

Verification
- [] SLO restored (threshold/window time)
- [] No recourse for related services

Follow-up
- CAPA, tasks in backlog, updating alerts/dashboards/playbook

10) Cărți de redare tipice

10. 1 API 5xx Spike

Stabilizare: opriți ficheflag problematic; Boost replici API Activați caching rulare înapoi eliberarea.
Diagnosticare: eliberare diff, erori în busteni (excepții de sus), creștere p95, presiune DB/cache.
Riscuri: cascadă în plăți/backend.

10. 2 БД: replicare lag/furtună de blocare

Stabilizare: suspendarea lucrărilor/rapoartelor grele; redirecționează citește către expertul crește wal_buffers/replika-sloty.
Diagnosticare: tranzacții lungi, cereri de blocare, modificări de plan.
Fixare: indici/indicii, reamenajarea de locuri de muncă, interogări divizate.

10. 3 Kafka lag de consum

Stabilizare: scară temporară a consumatorilor; reducerea producției din servicii non-critice; creșterea părților/cotelor.
Diagnostic: reechilibre, deserializări lente, pauze GC.
Verificare: lag → la valoarea țintă, fără picături.

10. 4 K8s NodeNotReady/furtună de resurse

Stabilizare: cordon + scurgere; redistribuie sarcinile; Verificați CNI/suprapunere opriți DaemonSets zgomotoase.
Diagnosticare: presiune pe disc, OOM, accelerare, picături de rețea.
Prevenire: bugete de perturbare a capsulelor, limite/cereri de resurse.

10. 5 TLS/certificate expiră

Stabilizare: actualizare forțată a secretului/pătrunderii; suprascriere temporară.
Diagnosticare: lanț de încredere, ceas-skew.
Prevenire: alerte T-30/T-7/T-1, auto-renuale.

10. 6 DDoS/trafic anormal

Stabilizare: reguli WAF/bot, limită de rată/geo-filtre, încărcare în amonte.
Diagnostic: profile de atac (L3/4/7), surse, umbrele.
Prevenire: anycast, autoscaling, caching, play-nice cu furnizorii.

10. 7 Pauză PSP de plată

Stabilizare: rutare inteligentă la PSP/metode alternative; ridica încercați din nou cu jitter; degradare „moale” UI.
Diagnosticare: eșecuri spike după coduri, stări API/pagini de stare PSP.
Comunicații: actualizări transparente pentru afaceri și suport, statistici corecte ND/conversie.

10. 8 Incident de siguranță/scurgere PII

Stabilizare: izolarea nodului/rotirea secretă, blocarea exfiltrării, prinderea legală.
Diagnosticare: calendare de acces, subiecte/câmpuri afectate.
Notificări: Autorități de reglementare/Parteneri/Utilizatori în funcție de cerințele jurisdicției.
Prevenire: accesoriu DLP/segmentare, „cel mai mic privilegiu”.

11) Automatizarea cărților de joacă

Comenzi ChatOps: '/ic set sev 1 ', '/implementare rollback api 1. 23. 4 ', '/feature off X'.
Runbook-bots: pași semi-automați (nod de scurgere, trafic flip, memorie cache de purjare).
Cârlige de auto-vindecare: detector → atenuare standard (rată-limită, repornire, scară).
Creați automat carduri/linii temporale din alerte și comenzi.

12) Calitatea cărții de redare: lista de verificare

• Simptome clare și detectoare (metrici/busteni/urme).
• Pași rapizi de stabilizare cu evaluarea riscurilor.
• Comenzile/scripturile sunt actualizate, verificate în stadiu.
• Verificarea recuperării SLO.
• Șabloane de comunicare și criterii de actualizare externe.
• Referință post-mortem și CAPA după închidere.

13) Postmortem (fără vină) și CAPA

Scopul: să învețe, nu să găsească vinovatul.
Conținut: ce s-a întâmplat, ce s-a dovedit a fi bun/rău, contribuția factorilor (acei + procese), acțiunile de prevenire.
Termen: SEV-1 - în termen de 48 de ore; SEV-2 - 3 zile lucrătoare.
CAPA: proprietari specifici, sincronizare, efecte măsurabile (MTTR redus/MTTD crescut).

14) Aspecte juridice și baza de probe

Legal Hold: congelare busteni/piste/alerte, scrie-o dată de stocare.
Lanțul de depozitare a artefactelor: acces după rol, controlul integrității.
Anunțuri de reglementare: termene/modele pentru jurisdicții (în special cu plăți/PII afectate).
Confidențialitate: minimizarea PII și mascarea în timpul parsării.

15) Măsurători ale performanței proceselor incidente

MTTD/MTTA/MTTR pe trimestru și domeniu.
Precizia SEVS (subestimare/supraevaluare).
Ponderea incidentelor de auto-atenuare.
Acoperire Playbook de scenarii de top N (> 90%).
Efectuați CAPA la timp.

16) Implementarea pe etape

1. Săptămâna 1: matricea SEV, rolurile de gardă, șablonul general al cardului, reglementările camerei de război.
2. Săptămâna 2: Cărți de joc pentru primele 5 simptome (5xx, DB lag, Kafka-lag, NodeNotReady, TLS).
3. Săptămâna 3: ChatOps/boți, carduri de auto-creare, șabloane de comunicare/StatusPage.

4. Săptămâna 4 +: Cărți de siguranță, Întreruperi PSP, Așteptare legală, Exerciții regulate/Jocuri de haos

17) Exemple de ranbook-uri „rapide” (fragmente)

Rollback API (K8s)

bash kubectl rollout undo deploy/api -n prod kubectl rollout status deploy/api -n prod --timeout=5m
Verification:
kubectl -n prod top pods -l app=api

Nod de scurgere

bash kubectl cordon $NODE && kubectl drain $NODE --ignore-daemonsets --delete-emptydir-data --timeout=10m

Feature-flag OFF (exemplu)

bash curl -X POST "$FF_URL/toggle" -H "Authorization: Bearer $TOKEN" -d '{"feature":"X","enabled":false}'

18) Mini-Întrebări frecvente

Când să ridice SEV-1?
Atunci când funcția cheie SLO/de afaceri (plăți, conectare, joc) suferă, și arde-rata „mănâncă” bugetul pentru ore înainte.

Ce este mai important - RCA sau recuperare?
Întotdeauna stabilizare, apoi RCA. Timpul până la stabilizare este principalul indicator.

Trebuie să automatizez totul?
Automatizați pașii frecvenți și siguri; rare/riscante - prin confirmare semi-automată și IC.

Total

Procesul de incidente robuste se bazează pe trei piloni: roluri clare și reguli SEVV, cărți de joc de calitate/ranbook-uri cu automatizare și o cultură post-mortem fără vină. Modelele de captare, trenul de gardă, măsurarea bugetului MTTR/eronat și îmbunătățirea constantă a detectoarelor și a cărților de redare - acest lucru reduce direct riscul și costul timpilor de nefuncționare.