Cultura e ingegneria SRE

1) Cos'è la cultura SRE

La cultura SRE è un insieme di valori e pratiche che rendono l'affidabilità gestibile: obiettivi SLO, errori-budget, rischi di cambiamento consapevoli, stabilizzazione rapida dell'apprendimento degli incidenti.
Il paradigma chiave è che la velocità è il nemico dell'affidabilità. La velocità di rilascio è possibile quando i rischi vengono dosati e automatizzati.

• User-centric indica l'affidabilità come la vede l'utente (SLI/SLO).
• Automation-first: qualsiasi azione ripetibile script/criterio/controller.
• Blamelessness, gli errori sono di sistema, indaghiamo sulle cause, non sulle persone.
• Data-driven: soluzioni basate su metriche e budget di errore.
• Semplicità: meccanismi semplici e collaudabili> soluzioni «magiche».

2) I principi di base dell'ingegneria SRE

1. SLO/SLI e bilancio degli errori sono la base delle priorità e dell'alerting.
2. L'incidente la stabilizzazione dell'RCA, prima i sintomi, poi le cause.
3. La riduzione del lavoro manuale (toil) è l'obiettivo del 50% del tempo di SRE, con il tempo inferiore.
4. Prod-pronta - La produzione readavaè obbligatoria fino al traffico esterno.
5. Semplicità e isolamento: meno relazioni, più limiti di blast radius.
6. L'osservabilità predefinita è metrica/loga/pista, widget SLO, sintetico.
7. Le modifiche sono gestite - progressive delivery, canarini, auto-rollback.
8. Sicurezza by design - Segreti, accessibilità, controllo, privilegi minimi.
9. Cicli di studio - dribli, giochi di caos, postmortem, retrospettive.
10. FinOps-consapevole è il prezzo delle device, cost-to-serve, efficace SLO.

3) Rituali e processi

3. 1 Production Readiness Review (PRR)

• SLI/SLO, dashboard e alert (fast/slow burn).
• Health-endpoint '/healthz ', '/readyz', '/startupz '.
• Runbook/playbook incidenti, owner/on-call, escalation chain.
• Backups/DR-piano, limiti di risorse, calcoli di bilancio.
• Test di tolleranza (flag, script rollback).

3. 2 Briefing settimanale SLO

Stato error-budget per servizi.
Incidenti in una settimana, progressi CAPA.
Rischio di rilascio: dove consentito/limitato dal deposito (budget).

3. 3 Postmortem senza accuse

Fatti e timeline, l'influenza utente che ha aiutato/ostacolato.
Cause di sistema (processi/strumenti), non «colpevole».
Cape specifiche con proprietari e scadenze, pubblicità all'interno dell'azienda.

3. 4 Giochi di caos e dribbli

Iniezioni di errore pianificate (rete, database, cache, nodi) + SLO target.
«Game day»: tempo di stabilizzazione, misura MTTR, regolazione playbook.

4) Alerting e rumore

• Alert only on symptoms - Disabilitato SLO o percorso utente.
• Multi-window, multi-burn - Canali veloci e lenti.
• Quorum/anti-flapping: ritardi «for», soppressione in maintenance.
• «CPU> 80%» è il tipo di segnale per i dashboard, non per il cercapersone.

• La percentuale di actionable è pari all '80%.
• Median time-to-ack 5 minuti (P1).
• La riduzione di «Pager fatigue» è che ci sono più di una pagella notturna a settimana per un ingegnere.

5) Gestione delle modifiche

Progressive delivery: canary → 10% → 25% → 50% → 100%.
Auto-rollback per segnali SLO (errori/latitanza).
Feature-flags e kill-switch invece di un ripristino globale.
Change policy by risk: fast lane для low-risk; CAV - Solo high-risk.

yaml steps:
- setWeight: 10
- analysis: { template: "slo-check" } # fail ⇒ rollback
- setWeight: 25
- analysis: { template: "slo-check" }

6) Riduzione del toil (lavoro manuale di routine)

Esempi di sorgenti toil: deploi manuali, riavvii, tickets di accesso, pulizia delle code.

• Inventario delle attività ripetute, automazione/autoasservimento.
• KPI:% di tempo per toil, «passo automatico/incidente», «minuti prima del self-service».
• Catalogo dei servizi della piattaforma (namespace, database, code, dashboard, alert).

7) Osservabilità e SLO-primo design

Golden Signals (latency, traffic, errors, saturation).
schede SLO in ogni squadra: obiettivo, finestra, budget, burn-alert.
Drilldown: da metriche a fogli/piste; 'trace _ id' nei loghi predefiniti.
Sintetico: blackbox + headless script (login/deposit/checkout).

8) Gestione della potenza e sostenibilità

Capacity planning: RPS/concorrenza target, riserva AZ/regione.
Bullkhead/shedding - Isolamento dei pool, primo guasto delle funzioni secondarie.
Backpressure e code: doppio controllo, DLQ, concorrenza adattiva.
Failover e DR: RPO/RTO, DR-Drily regolari.

9) Sicurezza come parte dell'affidabilità

Secret Manager dei segreti, accesso JIT, controllo.
WAF/DDoS-guard sul perimetro, limiti per cliente/tenente.
Riduzioni PII, DSAR/Legale Hold in incidenti.
Supply chain security: firma degli artefatti, criterio delle immagini di base.

10) Salute di lui-colla

Rotazioni senza «single», finestre di riposo chiare.
La soglia «sveglia di notte» è solo P1/P2 SLO.
Psicogygien, la carenza di sonno è registrata come un rischio operativo.
Metriche: pagelle/ned, pagelle notturne/ingegnere, tempi di recupero.

11) Metriche di maturità SRE

SLO coverage: la percentuale di percorsi critici con SLO/alert è pari al 90%.
Errore-budget governance - Esistono regole freeze e si applicano.
Toil: 30-40% del tempo, tendenza al calo.
MTTD/MTTR: mediani nella dinamica trimestrale.
Auto-mitigation rate:% degli incidenti con azione automatica.
PRR pass-rate: percentuale di rilasci completati.
Postmortem SLA: SEV-1 - entro 48 ore.

12) Documentazione e conoscenza

• Runbooks/playbook (top script 5xx spike, DB lag, Kafka lag, NodeNotReady, TLS).
• Schede SLO e dashboard.
• FOGLI e modelli di rilascio PRR.
• Catalogo dei servizi della piattaforma e OLAs/SLAs.
• Materiali didattici: SRE 101, Chaos 101, On-call 101.

13) Anti-pattern

Hero-culture: «soccorritori» al posto dei registri di sistema.
Alerting rumoroso: CPU/unità nel cercapersone, centinaia di segnali inutili.
«L'uomo è un uomo», una responsabilità smodata, nessun proprietario.
L'assenza dello SLO, «teniamo il verde tutto», è il caos della priorità.
Postmortem ritardati e caccia alle streghe.
Rimborsi globali senza canarini.
I segreti nella configa/repo; Nessun controllo delle attività.
Osservabilità come «grafici belli» senza segnali actionabili.

14) Modelli di manufatti

14. 1 SRE-Carta (frammento)

yaml mission: "Make reliability manageable and economical"
tenets:
- "User - SLI/SLO Center"
- "Automation-first, minimizing toil"
- "Blameless & learning"
governance:
error_budget:
freeze_threshold: 0. 8 # 80% of the budget burned ⇒ release frieze review_cadence: "weekly"
oncall:
paging_policy: "SLO-only, P1/P2 at night"
health_metrics: ["pages_per_week", "night_pages_per_engineer"]

14. 2 Foglio di assegno mini PRR

• SLI/SLO e burn-alert configurati
• Health-endpoint e sintetico
• Runbook/playbook + proprietario/on-call
• Rollback/flag/canarino
• Dashboard latency/errors/traffic/saturation
• Limiti/quote/protezione
• Piano DR e backup testati

15) Implementazione per fasi (4 sprint)

Sprint 1 - Fondamenta

Definisci percorsi utente critici e SLI.
Formulare lo SLO e avviare i burn-alert.
Immettere PRR e playbook minimi.

Sprint 2 - Gestione delle modifiche

Canarie, auto-rollback SLO.
Attività self-service, catalogo dei servizi.
Inventario toil e piano di automazione.

Sprint 3 - Cicli di formazione

Il rituale post-mortem, il calendario dei giochi del caos.
Dashboard SLO + incidenti, rendicontazione error-budget.

Sprint 4 - Ottimizzazione e zoom

Portafoglio SLO, «cost per 9».
Implementazione della disciplina DR, verifica della sicurezza.
KPI-colla, prevenzione bruciatura.

16) Mini FAQ

SRE = «riparare tutto»?
No, no. SRE gestisce il sistema di affidabilità: SLO, alerting, processi, automazione e formazione.

Come convincere le imprese a investire nell'affidabilità?
Mostra AI: riduzione del MTTR, aumento della conversione, meno crediti SLA, meno cost-to-serve, rilascio stabile.

Sono necessari comandi SRE separati?
Modello ibrido: SRE strategico nella piattaforma + embedded-SRE nei prodotti critici.

Totale

La cultura SRE non è un ruolo, ma un modo per lavorare a rischio: SLO, bilancio degli errori, modifiche gestite, automazione e formazione. Fissare i principi, creare rituali (PRR, postmortem, giochi di caos), togliere il toil, costruire l'osservazione'predefinite'e osservare il call. In questo modo si ottiene una velocità di sviluppo sostenibile, rilasci prevedibili e una piattaforma affidabile e conveniente.