Playbook di operazioni

1) Cos'è un playbook e cosa è diverso dal runbook

Runbook è un'istruzione lineare passo passo per una tipica operazione/alert («fai uno, due, tre»).
Il playbook è un albero di soluzioni per scenari di bivio, sintomi diversi, ipotesi diverse, rami di azione diversi. Include criteri di selezione, condizioni gate e rami fallback.
Assegnazione playbook: ridurre MTTA/MTTR e il livello di improvvisazione in caso di incertezza.

2) Dove i playbook sono necessari in primo luogo

Incidenti: calo di SLO (availability/latency/success), fallimento di business SLI (conversione/successo dei pagamenti).
Modifiche: release, migrazioni, flag fich, confighi (canary/rollback).
Finestre di servizio: upgrade database/broker, rotazioni certificati.
Provider: PSP/KYC/CDN/IDP - degrado e swich-over.
Sicurezza, chiave compromessa, attività sospetta.
DataOps: ritardo di freschezza, deriva del circuito, degradazione del pipline.

3) Standard di playbook (composizione minima)

1. Scheda: ID, Versione/Data, Proprietario (comando/ruolo), Servizi/regioni/tenenti, Criteri/standard correlati.
2. Obiettivo e condizioni di avvio: quali SLO/SLI proteggere, quali alert/trigger sono applicabili.
3. Sintomi di ↔ Ipotesi: tabella di corrispondenza per ritagliare rapidamente le ipotesi sbagliate.
4. Struttura di soluzioni: bivio, gate di sicurezza, criteri di arresto/continuazione.
5. Azioni: blocchi passo-passo con comandi/riferimenti runbook e.
6. Comunicazioni: modello di update (Impakt→Diagnostika→Deystviya→Sled. update), canali e frequenze.
7. Ritorno/folback: piano backout chiaro, limiti e bandiera di degrado UX.
8. Criteri di completamento: metriche, finestre temporanee di sorveglianza.
9. Evidence: cosa salvare (fogli, grafici, schermate, ID ticket).
10. Cronologia delle modifiche: changelog, limitazioni note.

4) Tassonomia playbook (esempio di catalogo)

INC- incidenti (SLO/SLI, provider, infrastrutture).
REL- - comunicati, rimborsi, conferme/bandiere.
Finestra di servizio MW (DB/queue/cert/OS).
Sicurezza SEC- (disponibilità, chiavi, attività sospette).
DATA- freschezza/qualità/schemi.
PROV- provider esterni (PSP/KYC/CDN/Email/SMS).

5) Ciclo di vita e possesso

1. Avvia in base all'incidente/simulazione/modifica.
2. Bozza: autore = proprietario del servizio; ringhiera: SRE/protezione/dati (per dominio).
3. Pilota: tabletop/game-day; fissa i tempi di percorrenza e i difetti.
4. Pubblicazione: in repo (Docs-as-Code), versione, tag, riferimenti ai dashboard.
5. Aggiornamento: RCA/CAPA, almeno una volta al trimestre; La SLA è fresca.
6. Archivio/deprecazione - Durante la sostituzione/perdita di rilevanza.

6) Integrazione con gli strumenti

Alert → Playbook: ogni regola di pagina fa riferimento esattamente a un playbook di base.
ChatOps: '/play start <id> 'apre la carta, registra l'evidenza, mette i timer degli update.
CMDB/catalogo: il servizio ha un elenco di playbook rilevanti, proprietari, SLO, dashboard.
GitOps, playbook e runbook e vivono in Git, passano per la riva e i liner.

7) Metriche di qualità playbook

Actionability: il 90% dei lanci porta a azioni specifiche senza un'escalation di «ignoto».
Time-to-first-action: minuto-due da Page al primo passo.
Coverage:% Pagine alert con playbook collegato (obiettivo 100%).
Freshness, la quota di playbook è più fresca di 90 giorni.
Defect rate - Osservazioni su ruspe/simulazioni su 100 playbook.
Reuse: quante volte il playbook è stato effettivamente utilizzato (e quali esiti ha portato).

8) Anti-pattern

Un'enciclopedia playbook di 20 pagine senza struttura di soluzioni.
Comandi privi di aspettative di risultati («esegui X» - cosa cambierà?).
Nessun piano backout e nessun limite - rischio di escalation del problema.
Nessun canale/intervallo di comunicazione specificato - Aumento dei rischi PR.
Playbook senza proprietario/data di aggiornamento: nessuno crede che sia rilevante.
Decine di playbook simili invece di uno parametrabile.

9) Mini modello playbook (idea YAML)

yaml id: INC-PAY-001 name: "Payment Success Down"
version: 2. 4 (2025-10-15)
owner: team-payments@sre scope: [prod, region: eu, tenants: all]
goal: "Restore success_ratio ≥ 98% without violating SLA"
triggers:
- alert: slo. burn. payment_success_ratio
- external_status: psp-a partial outage symptoms:
- "5xx growth in payments-api"
- "p95 latency> 400ms on PSP-A"
decision_tree:
- if: "quorum(eu,us) confirms drop AND PSP-A status=partial"
then:
- action: "Reduce PSP-A weight to 30%"
runbook: rb://payments/traffic-shift guardrails: ["success_ratio improving 10m", "p95<300ms"]
- action: "Enable degrade_payments_ux"
runbook: rb://payments/feature-flags
- action: "Status update (30m) by template"
comms: statuspage://payments else:
- action: "Check database/cache/queue"
runbook: rb://payments/diag-stack fallback:
- action: "Failover на PSP-B 70%"
guardrails: ["fraud_rate stable", "chargeback risk noted"]
rollback:
- condition: "PSP-A green 60m"
- steps:
- "Weight of PSP-A 30→70→80 (every 30 m at green SLI)"
evidence:
- "SLI screenshots, p95/5xx graphs, links to logs/trails"
completion:
- "success_ratio ≥98% during 30 m, no burn in 6 h"

10) Esempi finiti (sezioni)

A) Pagamenti: «Il provider è degradato in una sola regione»

Sintomi: riduzione del success _ ratio dei coorti TR, aumento dei timeout PSP-A.
Soluzioni: ridurre il peso di PSP-A per TR, includere degrade-UX, aumentare i retrai con budget SLA, preparare un update client.
Backout - Restituire peso con una SLI verde 60 minuti.

B) Database: «Crescita p99 e connection errors»

I sintomi sono: p99↑, errori di connection reset, crescita wait events.
Le soluzioni includono script read-only, limitano il carico write, ridimensionano il pool/replica, se necessario, il faulover hot.
Backout - Ripristina le impostazioni, replica-prime.

C) Cache: «Miss rate»

Sintomi: Miss rate> 40%, aumento CPU BD.
Soluzioni: bilanciare l'eviction policy, aumentare la memoria/charding, attivare temporaneamente il read-through, limitare l'RPS a chiave calda.
Backout: ripristinare la politica, ritardare il problema shard.

D) CDN: «Degrado regionale dei contenuti»

Sintomi: aumento latency/timeout in un paese, lamentele RUM.
Soluzioni: modificare il routing map/GSLB, aggirare POP problematico, ridurre TTL, abilitare origin-shield.
Lo status update con geografia influenzale.

E) KYC: «Identificazioni fallite»

Sintomi: calo di approve rate, crescita di vendor _ errore.
Le soluzioni includono il passaggio di parte del traffico a un provider alternativo, la riduzione della rigidità delle regole, l'avvio della review manuale per i VIP.
Compliance: riepilogo di tutte le modifiche, notifiche Risk/Legale se necessario.

11) Comunicazioni (modello di update)

Impact: EU payment success drop (-3. 1% to SLO, 25 min).
Diagnosis: confirmed by quorum; PSP-A partial outage; p95 = 420ms.
Action: PSP-A weight reduced to 30%, degrade-UX included; next update 18:30 UTC.

12) Foglio di assegno dell'autore del playbook

• Target, proprietari, SLO/SLI e trigger indicati.
• Ci sono la tabella «Sintomi dell'ipotesi» e l'albero delle soluzioni.
• Passaggi fattibili con i risultati previsti e gate di sicurezza.
• Backout/fallback e condizioni di restituzione.
• Modello di comunicazione e frequenza degli update.
• Riferimenti a dashboard/alert/loga-ricerca/roulotte.
• Sezione evidence obbligatoria e criteri di completamento.
• Versione, data, SLA freschezza, cronologia dei cambiamenti.

13) Foglio di assegno del revolver

• Playbook riprodotto su tabletop/game-day.
• I passaggi sono sicuri (limiti/canarino/autotrasporto), i segreti non vengono rivelati.
• I ruoli e le escalation sono chiari; IC/Comms specificati.
• Nessuna duplicazione con playbook adiacenti; i parametri sono stati emessi.
• È chiaro quando fermare e passare a fallback/rollback.
• Il documento è disponibile da un alert di 1 clic.

14) Parametrizzazione e riutilizzo

Trascinare le variabili (regione, provider, soglie) in «values».
I passaggi generali (ad esempio, ridurre il peso del provider, includere degrade-UX) sono personalizzati runbook 'ami.
Supporta i generatori dei modelli: 'plb new --type = INC --service = payments'.

15) Road map di implementazione (4-6 settimane)

1. L'inventario degli alert di pagina è in grado di mappare ogni playbook di base.
2. Modelli: approvare la struttura YAML/Markdown, assegni e lenti.
3. I primi 5 script (pagamenti/database/CDN/KYC/cache) possono essere scritti/ritirati su tavoletop.
4. Integrazione: collegamenti da alert, comando, evidence-bot.
5. Esercitazioni: mini-drill settimanali per playbook; AAR→uluchsheniya.
6. SLA freschezza e gelosia trimestrale; Report sulle metriche di qualità.

16) Totale

Le playbook sono scenari operativi con bivio e ringhiera che trasformano il caos «cosa fare?» in una prevedibile sequenza di decisioni. Quando le playbook sono standardizzate, integrate con gli alert e allenate regolarmente, il team reagisce più rapidamente, i rischi sono controllati e le aziende vedono stabilità e maturità operativa.