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
Ошибочная доля 5xx > SLO sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.01

Burn-rate быстрый (пример)
(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: <ФИО>
comms_lead: <ФИО>
scope: regions: [eu-west-1], tenants: [prod], services: [api, payments]
impact: "5xx=12% (обычно <0.5%), конверсия депозитов -20%"
mitigation: "откат на 1.23.4, включен rate-limit 2k rps, фича X выключена"
timeline:
- "17:42: алерт SLO burn-rate быстрый"
- "17:46: назначен IC, открыт war-room"
- "17:52: найден релиз 1.24 как кандидат"
- "18:02: откат завершен, 5xx вернулись к 0.3%"
artifacts:
dashboards: [...]
logs: [...]
traces: [...]
risk: "возможен очередной всплеск при включении фичи X"
next_steps: "канареечный релиз, тесты, постмортем до 2025-11-05"

9) șablon SRE playbook (Markdown)

markdown
Плейбук: <название>
Область/симптомы
Список детекторов, сигнатуры в метриках/логах/трассах.

Быстрая стабилизация (Triage & Mitigation)
- [ ] Ограничить трафик/включить WAF-правило/фичефлаг OFF
- [ ] Роллбэк/канареечный релиз/выкатить фикс конфигурации
- [ ] Включить деградационный режим (read-only, кэш-форс)

Диагностика (RCA hints)
- Метрики: … Логи: … Трассы: …
- Частые первопричины/чек-лист гипотез

Риски и коммуникации
- Внутренние/внешние апдейты, SLA-обязательства

Верификация
- [ ] SLO восстановлено (порог/время окна)
- [ ] Нет регресса по смежным сервисам

Последующие действия
- CAPA, задачи в backlog, обновление алертов/дашбордов/плейбука

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
Верификация:
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.

Rezultat

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.