Incidenti e playbook SRE

1) Che cos'è un incidente e come corrisponde a SLO

L'incidente è un evento che compromette la funzione SLO/servizio o crea un rischio di violazione (il bilancio errato è inaccettabile rapidamente).
Metriche classiche: MTTD, MTTA, MTTR, MTBF.
L'errore di bilancio e il burn-rate determinano la priorità e le finestre di escalation.

2) Livelli di serietà e criteri

Trigger SEC: 5xx%, p95> soglia, decline spike, Kafka-lag> soglia, NodeNotReady>X, TLS scade <7 giorni, segnali DDoS/fuga.

3) Ruoli e responsabilità (RACI)

Invio Comment (IC) - Decisione unificata, gestione del flusso di lavoro, modifica dello stato del SEV.
Ops Lead (Tech Lead) - strategia tecnica, ipotesi, coordinamento dei record.
Comunicazioni Lead (Comms) - Stato-update (interno/esterno), StatusPage/chat/posta elettronica.
Scribe (Cronista) - timeline, soluzioni, manufatti, collegamenti grafici/logici.
On-call Engineers/SMEs - Esecuzione delle azioni di playbook.
Sicurezza/Privacy - Abilitato per incidenti di sicurezza o PII.
FinOps/Payments per l'impatto su billing/PSP/costo.

4) Ciclo di vita dell'incidente

1. L'oggetto (alert/report/sintetico) è la creazione automatica della tessera dell'incidente.
2. Triage (IC assegnato, SEC assegnato, raccolta del contesto minimo).
3. Stabilizzazione (mitigation - disattiva fich/rollback/rate-limit/failover).
4. Indagine (RCA-ipotesi, raccolta dei fatti).
5. Ripristino del servizio (validate SLO, sorveglianza).
6. Comunicazione (interno/esterno, rapporto finale).
7. Postmortem (nessuna accusa, CAPO-piano, proprietari, scadenze).
8. Prevention (test/alert/playbook/flag, pre-apprendimento del comando).

5) Comunicazioni e war-room

Un unico canale di incidente ('# inc-sev1-YYYYMDD-hhmm'), solo fatti e azioni.
I comandi in stile protocollo radio sono "IC: assegnare rollback versione 1. 24 → ETA 10 min".

Stato-update: SEV-1 ogni 15 minuti, EV-2 ogni 30-60 minuti

Status Page/Comunicazione esterna - Tramite Comms Lead per modello.
Vietato: camere silenziose parallele, ipotesi non verificate in un canale comune.

6) Alerting e SLO-burn (esempio di regole)

Canale veloce (1-5 min) e canale lento (1-2 h) burn-rate.
Segnali multi - errore di bilancio, 5xx%, p95, Kafka-lag, pagamenti decline-rate, sintetica.
La ricerca della causa principale è solo dopo la stabilizzazione dei sintomi.

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) Playbook vs ramboki

Playbook - Script di azioni per tipo di incidente (ramificazioni, condizioni, rischi).
Runbook è una mappa specifica dei passaggi/comandi (controlli, registrazioni, verifiche).
Regola: il playbook fa riferimento a più runbook (rollbacks, feature-flags, failover, scalabilità, blocco del traffico, ecc.).

8) Modello di tessera di incidente

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) Modello di playbook SRE (Markdown)

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

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

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

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

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

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

10) Playbook tipici

10. 1 API 5xx Spike

Stabilizzazione: disattivare il phicheflag problematico; Migliorare le repliche API Attivare la cache La cancellazione del comunicato.
Diagnostica: disf release, errori nei logs (top-exceptions), altezza p95, pressure database/cache.
Rischi: a cascata nei pagamenti/backend.

10. 2 БД: replication lag / lock storm

Stabilizzazione: sospensione dei giubbotti pesanti/reporti; Reindirizzare le letture alla procedura guidata ingrandire wal _ buffers/replica-slot.
Diagnostica: transazioni lunghe, richieste di blocco, modifiche al piano.
Fissazione: indici/hints, rifinitura del jobs, suddivisione delle richieste.

10. 3 Kafka consumer lag

Stabilizzazione: scalare temporaneamente consumer's; Ridurre la produzione da servizi non critici aumentare le partenze/quote.
Diagnosi: rebalance, decerializzazioni lente, pause GC.
Verifica: La Lega si avvicina al target, non ci sono drop.

10. 4 K8s NodeNotReady/tempesta di risorse

Stabilizzazione: cordon + drain; Ridistribuire i carichi di lavoro controllare CNI/overlay; Spegnere i rumorosi DaemonSet.
Diagnostica: disk pressure, OOM, throttling, network drops.
Prevenzione: pod disruption budget gets, limiti di risorse/richiesti.

10. 5 certificati TLS scadono

Stabilizzazione: aggiornamento forzato del segreto/ingress; override temporaneo.
Diagnostica: catena di fiducia, clock-skew.
Prevenzione: alert T-30/T-7/T-1, auto-renual.

10. 6 DDoS/traffico anomalo

Stabilizzazione: regole WAF/bot, rate-limit/geo-filtri, upstream shed load.
Diagnostica: profili di attacco (L3/4/7), sorgenti, ombrelloni.
Prevenzione: anycast, autoscaling, cache, play-not con provider.

10. 7 PSP-Outage di pagamento

Stabilizzazione: smart-routing su metodi PSP alternativi; alzare retry con jitter; degrado UI «morbido».
Diagnostica: chike per codice, stato API/stato pagina PSP.
Comunicazioni: update trasparenti per il business e lo zapport, statistiche ND/conversione corrette.

10. 8 Incidente di sicurezza/fuga di PII

Stabilizzazione: isolamento dei nodi/segreto-rotazione, blocco dell'esfiltrazione, Legale Hold.
Diagnostica: timeline di accesso, soggetti/campi interessati.
Notifiche: regolatori/partner/utenti in base ai requisiti giurisdizionali.
Prevenzione: aumento DLP/segmentazione, «least privilege».

11) Automazione playbook

ChatOps del comando: '/ic set sec 1 ', '/deploy rollback api 1. 23. 4`, `/feature off X`.
Runbook-bot - Passo mezzo automatico (drain node, flip traffic, purge cache).
Self-healing gancio: rilevatore → mitigation standard (rate-limit, restart, scale).
Creazione automatica di schede/timeline di alert e comandi.

12) Qualità playbook: assegno-foglio

• Sintomi e rilevatori chiari (metriche/loghi/piste).
• Passo rapido di stabilizzazione con valutazione del rischio.
• I comandi/script sono aggiornati, verificati in staging.
• Convalida il ripristino SLO.
• Modelli di comunicazione e criteri di update esterni.
• Collegamento postmortem e CAPE dopo la chiusura.

13) Postmortem (blameless) e CAPO

L'obiettivo è studiare, non trovare il colpevole.
Contenuto: ciò che è successo è stato scoperto che è stato buono/male, il contributo fattori (quei + processi), azioni per prevenire.
Termine: SEV-1 - entro 48 ore; SEC-2 - 3 giorni lavorativi.
CAPA: proprietari specifici, tempi, effetti misurabili (riduzione MTTR/crescita MTTD).

14) Aspetti legali e base di prova

Legale Hold: congelamento di cavi/piste/alert, write-once deposito.
Catena di memorizzazione degli artefatti: accessibilità per ruolo, controllo dell'integrità.
Notifiche regolatorie: date/modelli per le giurisdizioni (soprattutto per i pagamenti/PII interessati).
Privacy: minimizzazione e occultamento di PII durante l'analisi.

15) Metriche di efficienza del processo di incidenti

MTTD/MTTA/MTTR per quartieri e domini.
La SEV (underrating/overrating) è corretta.
Percentuale di incidenti con mitigate auto.
Copertura con playbook di script top-N (> 90%).
Esegui CAPA entro il termine.

16) Implementazione per fasi

1. Settimana 1: matrice SEC, ruoli on-call, modello di tessera condivisa, war-room regola.
2. Settimana 2: playbook per i primi 5 sintomi (5xx, BB, Kafka-lag, NodeNotReady, TLS).
3. Settimana 3: ChatOps/bot, creazione di schede automatiche, modelli di comunicazione/StatusPage.
4. Settimana 4 +: playbook di sicurezza, PSP-Outage, Legale Hold, regolari dribbli/giochi di caos.

17) Esempi di runbook «veloci» (frammenti)

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

Drain node

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

Feature-flag OFF (esempio)

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

18) Mini FAQ

Quando alzare il SEV-1?
Quando soffre di funzione SLO/business chiave (pagamenti, login, gioco), e burn-rate «mangia» il budget con ore di anticipo.

Cosa c'è di più importante, RCA o recupero?
Sempre stabilizzato, poi RCA. Il tempo fino alla stabilizzazione è l'indicatore principale.

Dobbiamo automatizzare tutto?
Automatizzare passaggi frequenti e sicuri rari/rischiosi - tramite mezzo auto e conferma IC.

Totale

Un processo affidabile di incidenti si basa su tre pilastri: ruoli chiari e regole SEC, playbook di qualità/runbook automatizzati e cultura post-mortem senza accuse. Fissare i modelli, allenare on-call, misurare il budget MTTR/errato e migliorare costantemente i rilevatori e le playbook, riducendo direttamente i rischi e i costi di inattività.