Ruoli e responsabilità nelle operazioni
1) Perché formalizzare i ruoli
La netta distribuzione dei ruoli riduce MTTA/MTTR, elimina le zone grigie, accelera le release e rende riproducibile la corrispondenza SLO/Compilation. Ruoli = responsabilità + autorità + interfacce (a chi scriviamo, chi scaliamo, quali soluzioni sono autorizzate).
2) Modello RACI di base
R - Esegue il lavoro.
A (Accountable) - ha la responsabilità finale e decide.
C (Consulted) è un esperto, consultato prima/durante.
I (Informed) - Viene informato tramite SLA.
3) Directory dei ruoli (descrizioni e responsabilità)
3. 1 Incident Commander (IC)
Obiettivo: guida la risposta all'incidente SEC-1/0.
Le autorizzazioni sono di dichiarare la SEV, congelare i rilasci, cambiare il traffico, scalare.
Le attività principali sono timeline, decisione, attenzione, distribuzione delle attività, Go/No-Go.
Gli artefatti sono la scheda dell'incidente, gli update della SLA, l'AAR finale.
3. 2 P1/P2 On-Call (Primary/Secondary)
Obiettivo: risposta primaria e azioni tecniche.
P1: triage, avvio playbook, collegamento IC.
P2: bacap, modifiche complesse, tenuta del contesto, in caso di tempeste - prende i passaggi.
3. 3 SRE / Platform Engineer
Obiettivo: affidabilità della piattaforma e della ringhiera (SLO, alert, GitOps, autoscale, DR).
Attività: SLI/SLO, alert-igiene, release progressive, infrastruttura come codice, capacità, osservabilità.
Durante l'incidente: diagnosi radice, ritiri/folback, attivazione degrade-UX.
3. 4 Service Owner / Product Owner
Obiettivo: la qualità del servizio in senso aziendale.
Attività: definizione di SLO/priorità, negoziazione di release/finestre, partecipazione a Go/No-Go.
La soluzione è quando e cosa dire ai clienti con Comms.
3. 5 Release Manager
L'obiettivo è consegnare le modifiche in modo sicuro.
Attività: orchestrazione di lanci, checkup di gate, canarino/blue-green, annotazioni di release, freeze in caso di incidenti.
3. 6 CAB Chair / Change Manager
L'obiettivo è gestire il rischio di cambiamento.
Attività: processo RFC, piano/backout, calendario dei conflitti, approvazione high-risk.
3. 7 RCA Lead / Problem Manager
Obiettivo: analisi post - incidente, CAPA.
Attività: timeline, causalità probatoria, azioni di correzione/prevenzione, controllo D + 14/D + 30.
3. 8 Security (IR Lead, AppSec/CloudSec)
Obiettivo: sicurezza e risposta agli incidenti di sicurezza.
Attività: triage degli eventi di sicurezza, rotazione delle chiavi, isolamento, forensica, notifiche di regolazione, controllo WORM.
3. 9 DataOps / Analytics
Obiettivo: affidabilità dei dati e delle pipeline.
Attività: freschezza/qualità (DQ), contratti dati, lineage, backfill, SLA BI/report.
3. 10 FinOps
L'obiettivo è il costo gestito.
Attività: quote/limiti, report $/unità, gate di budget, ottimizzazioni (volumi logici, egress, riserva).
3. 11 Compliance / Legal
Obiettivo: conformità a regolatori e contratti.
Attività: date di notifica, retenze/invariabilità evidence, negoziazione dei testi pubblici.
3. 12 Support / Comms
L'obiettivo è comunicare con clienti/steakholder interni.
Operazioni: stato, layout degli update, frequenza e chiarezza dei messaggi, raccolta di feedback.
3. 13 Vendor Manager / Provider Owner
Scopo: relazioni con provider esterni (PSP/KYC/CDN, ecc.).
Attività: escalation, SLA/OLA, rotte di riserva, coordinazione delle finestre.
4) Ruoli di cambio e escalation
Cambio: P1/P2 + IC-of-the-day (non combinare con P1).
Intervalli di tempo: P1→P2 (5 minuti senza ack) → IC (10 min) → Duty Manager (15 min).
Quiet Hours: i segnali P2/P3 non vengono svegliati; i segnali di sicurezza sono sempre.
5) Interfacce di interazione (con chi e come)
IC ↔ Release Manager: soluzioni freeze/rollback.
IC ↔ Comms: i testi degli update e la frequenza.
SRE : Business SLI (successo dei pagamenti, freschezza dei dati) in SLO-Gardrail.
Sicurezza ↔ Legale: segnalazioni di incidenti di sicurezza, tempi di notifica.
Vendor Owner ↔ IC: stato del provider, switchover/folback.
6) KPI per ruolo (punti di riferimento)
IC: Time-to-Declare, conformità a Comms SLA, MTTR per SEC-1/0.
P1/P2: MTTA, Time-to-First-Action,% segui playbook.
SRE/Platform: SLO coverage, Alert Hygiene,% di recupero automatico è riuscito.
Release Manager: Change Failure Rate, On-time windows, Mean Rollback Time.
RCA Lead: Postmortem Lead Time, CAPA Completion/Overdue, Reopen ≤ 5–10%.
Security: Mean Time to Contain, Secret/Cert Rotation Time.
DataOps: Freshness SLO Adherence, Success Rate backfile.
Comms: Status Accuracy, Complaint Rate/Incidente.
FinOps: $/unità, il% di risparmio di QoQ, il rispetto delle quote.
7) Modelli di schede di ruolo
7. 1 Scheda IC
Role: Incident Commander
Scope: SEV-1/0 (prod)
Decisions: declare SEV, freeze deploy, traffic shift, rollback/failover
Runbooks: rb://core/ic, rb://comms/status
SLA: TTD ≤10m, first comms ≤15m, updates q=15–30m
Escalations: Duty Manager (15m), Exec On-call (30m)7. 2 Scheda P1/P2
Role: Primary/Secondary On-call (service: checkout-api)
Runbooks: rb://checkout/5xx, rb://checkout/rollback
Tools: logs, traces, SLO board, feature flags
SLA: Ack ≤5m, first action ≤10m, handover at shift boundaries7. 3 Carta Release Manager
Role: Release Manager
Gates: tests, signatures, active_sev=none, SLO guardrails green 30m
Strategy: canary 1/5/25%, blue-green optional, auto-rollback on burn
Evidence: release annotations, diff configs, dashboards before/after8) Processi e partecipazione dei ruoli (riepilogo)
A — Accountable, R — Responsible, C — Consulted, I — Informed.
9) Assegno fogli
9. 1 Assegnazione ruoli
- Ogni ruolo ha un proprietario, un vice e una zona di copertura.
- Sono descritte le autorizzazioni (le decisioni che possono essere prese).
- Le playbook e i canali di comunicazione sono collegati.
- Pubblicato da SLA per reazione/comms.
- Il ruolo è disponibile nella directory (CMDB) di ogni servizio.
9. 2 Cambio e handover
- Carta di cambio aggiornata (incidenti attivi, rischi, finestre).
- Le disponibilità JIT/JEA sono state verificate.
- Messaggio eco nel canale: «Cambio accettato/consegnato».
9. 3 Post-incidente
- AAR eseguito, RCA assegnato.
- CAPE con proprietari/scadenze, D + 14/D + 30 controllo.
- Playbook/alert/criteri aggiornati.
10) Anti-pattern
«Chi decide» non è chiaro.
IC combinato con P1 - Perdita della guida.
Commesse pubbliche senza accordo con Legale/Comms.
Lancio senza Release Manager e gate per la crescita del CFR.
Nessuna prenotazione dei ruoli (malattia/congedo).
«Eroismo» invece del processo, salviamo manualmente, ma non fissiamo le ringhiere.
I ruoli non sono riportati nella CMDB/directory del servizio per le scale perse.
11) Incorporazione negli strumenti
ChatOps: команды `/who oncall`, `/declare sev1`, `/freeze`, `/rollback`, `/status update`.
Catalogo/CMDB: il servizio ha proprietario, on-call, SLO, dashboard, playbook, finestre.
Alert-as-Code - Ogni pagina ha un owner e un playbook predefiniti.
GitOps: Le soluzioni IC/Release si riflettono nelle annotazioni di rilascio e nei ticket.
12) Metriche della maturità di distribuzione dei ruoli
Coverage ruoli nelle directory: ≥ 100% dei servizi critici.
On-call SLA: Ack p95 da 5 min; Page Storage p95 è sotto controllo.
Postmortem SLA: bozza da 72h; CAPA completion ≥ 85%.
Cambio governance:% high-risk modifiche con RFC/CAV al 95%.
Comms: Adherence ≥ 95%, Complaint Rate ↓ QoQ.
13) Mini modelli
13. 1 RACI per il servizio (file in repo)
yaml service: payments-api roles:
owner: team-payments oncall: oncall-payments ic: ic-of-the-day raci:
incident: {A: ic-of-the-day, R: oncall-payments, C: security,data, I: mgmt,comms}
releases: {A: release-manager, R: dev,platform, C: security, I: support}
changes: {A: cab, R: owner, C: sre,security, I: affected-teams}
postmortem: {A: rca-lead, R: owner, C: security,data, I: mgmt}13. 2 Profilo ruolo (Markdown)
Role: Duty Manager
Purpose: Escalation and SEV-1/0
Powers: Assign ICs, reallocate resources, approve freeze
Inputs: # war-room channel, SLO dashboards, IC reports
Outputs: resolutions, post-factual report, CAPA escalations14) Totale
Le operazioni sono sostenibili quando i ruoli sono trasparenti, dotati di poteri e integrati negli strumenti. Catalogo dei ruoli, RACI, interfacce chiare e metriche per ruolo trasformano incidenti, release e modifiche in processi gestiti: le decisioni vengono prese rapidamente, i rischi vengono controllati e gli utenti vedono un servizio stabile.