Roluri și responsabilități în operațiuni
1) De ce să formalizați rolurile
Alocarea clară a rolurilor reduce MTTA/MTTR, elimină zonele gri, accelerează eliberările și face ca SLO/conformitatea să fie reproductibilă. Roluri = responsabilitate + autoritate + interfețe (cui scriem, pe cine escaladăm, ce decizii sunt autorizate).
2) Modelul de bază RACI
R (Responsabil) - efectuează lucrarea.
A (Responsabil) - poartă responsabilitatea finală și ia decizii.
C (Consultat) - expert, consultat înainte/în timpul.
I (Informat) - informat de SLA.
3) Catalog de roluri (descrieri și responsabilități)
3. 1 Comandantul incidentului (IC)
Scop: Conduce răspunsul la incidentul SEV-1/0.
Autoritatea: declara SEVV, congela eliberări, comuta traficul, escalada.
Sarcini principale: cronologie, luarea deciziilor, reținerea concentrării, alocarea sarcinilor, Go/No-Go.
Artefacte: card incident, actualizări SLA, AAR final.
3. 2 P1/P2 de gardă (primar/secundar)
Obiectiv: răspuns iniţial şi acţiuni tehnice.
P1: triaj, rulează playbook-uri, comunicare cu IC.
P2: rezervă, schimbări complexe, retenție de context, în furtuni - ia substreams.
3. 3 Inginer SRE/Platformă
Scop: fiabilitate platformă și balustradă (SLO, alerte, GitOps, autoscale, DR).
Sarcini: SLI/SLO, igienă alertă, versiuni progresive, infrastructură ca cod, capacitate, observabilitate.
În timpul incidentului: diagnosticare rădăcină, rollback-uri/folback-uri, degrade-UX activat.
3. 4 Proprietar de service/Proprietar de produs
Scop: calitatea serviciilor într-un sens de afaceri.
Sarcini: definirea SLO/priorități, coordonarea versiunilor/ferestrelor, participarea la Go/No-Go.
Comms: Decide când și ce să le spună clienților alături de Comms.
3. 5 Manager de lansare
Scop: Livrare sigură a schimbării.
Sarcini: orchestrarea lansărilor, verificarea porților, canar/albastru-verde, adnotări ale lansărilor, îngheț pentru incidente.
3. 6 CAB Chair/Change Manager
Scop: Schimbarea managementului riscului
Sarcini: proces RFC, plan/backout, calendar de conflict, aprobări cu risc ridicat.
3. 7 RCA Lead/Manager de probleme
Scop: debriefing post-incident, CAPA.
Obiective: cronologie, cauzalitate probatorie, acțiuni de corectare/prevenire, control D + 14/D + 30.
3. 8 Securitate (IR Lead, AppSec/CloudSec)
Scop: Securitate și răspuns la incidente.
Sarcini: evenimente de securitate triaj, rotație cheie, izolare, criminalistică, notificări de reglementare, audit WORM.
3. 9 DataOps/Analytics
Scop: fiabilitatea datelor și conductelor.
Obiective: prospețime/calitate (DQ), contracte de date, descendență, restituiri, SLA BI/rapoarte.
3. 10 FinOps
Scop: valoare gestionată.
Sarcini: cote/limite, rapoarte $/unitate, porți bugetare, optimizări (volume jurnal, ieșire, rezervare).
3. 11 Conformitate/Juridic
Scop: reglementare și conformitate contractuală.
Sarcini: termeni de notificare, păstrarea/invariabilitatea probelor, coordonarea textelor publice.
3. 12 Suport/Comms
Scop: comunicarea cu clienții/părțile interesate interne.
Sarcini: pagina de stare, machete de actualizări, frecvența și claritatea mesajelor, colectarea de feedback.
3. 13 Furnizor Manager/Furnizor Proprietar
Scop: relațiile cu furnizorii externi (PSP/KYC/CDN etc.).
Sarcini: escaladare, SLA/OLA, rute de rezervă, coordonarea ferestrelor.
4) Roluri în schimbare și escaladare
Shift: P1/P2 + IC-of-the-day (nu se combină cu P1).
Escaladarea timpului: P1→P2 (5 min fără ack) → IC (10 min) → Duty Manager (15 min).
Ore de liniște: semnalele P2/P3 nu se trezesc; semnale de securitate - întotdeauna.
5) Interfețe de interacțiuni (cine cu cine și cum)
IC ↔ Release Manager: soluții de congelare/rollback.
IC ↔ Comms: actualizați textele și frecvența.
SRE ↔ DataOps: SLI de afaceri (succes de plată, prospețimea datelor) în SLO-gardrails.
Securitate ↔ juridice: rapoarte de incidente de securitate, perioade de notificare.
Proprietarul furnizorului ↔ IC: starea furnizorului, comutare/folback.
6) KPI după rol (repere)
IC: Timp de declarare, conformitate Comms SLA, MTTR prin SEV-1/0.
P1/P2: MTTA, Time-to-First-Action,% urmează playbooks.
SRE/Platformă: acoperire SLO, igienă alertă,% auto-rollback-uri de succes.
Release Manager: Schimbarea ratei de eșec, ferestre la timp, timpul mediu Rollback.
Plumb RCA: Timp de plumb postmortem, Finalizarea CAPA/Restante, Redeschide ≤ 5-10%.
Securitate: Timpul mediu pentru a conține, Timp de rotație Secret/Cert.
DataOps: Prospețime SLO Aderență, Rata de succes Backfills.
Comms: Precizia stării, Rata plângerii/Incident.
FinOps: $/unitate,% economii QoQ, respectarea cotei.
7) Șabloane de card de rol
7. 1 IC Card
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 P1/P2 card
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 boundaries
7. 3 Release Manager Card
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/after
8) Procese și participarea la rol (rezumat)
A - Responsabil, R - Responsabil, C - Consultat, I - Informat.
9) Liste de verificare
9. 1 Atribuirea rolurilor
- Fiecare rol are un proprietar, un înlocuitor și o zonă de acoperire.
Autorizațiile (ce decizii pot lua) sunt descrise.
- Legați cărțile de redare și link-urile.
- SLA-uri publicate prin reacție/comms.
- Rolul este disponibil în CMDB pentru fiecare serviciu.
9. 2 Shift și predare
- Shift card actualizat (incidente active, riscuri, ferestre).
- JIT/JEA accesează verificate.
- Echo mesaj pentru a canaliza „schimbare acceptată/trecut”.
9. 3 Post-incident
- AAR efectuate, RCA atribuite.
- CAPA cu proprietari/termene limită, D + 14/D + 30 control.
- Actualizat playbook-uri/alerte/politici.
10) Anti-modele
Neclar „cine decide” → întârzieri și eforturi duplicate.
IC combinat cu P1 - pierderea conducerii.
Comunicații publice fără acord cu Legal/Comms.
O versiune fără Release Manager și porți → creșterea CFR.
Fără rezervare de rol (boală/concediu).
„Eroism” în loc de proces: economisim manual, dar nu fixați balustrada.
Rolurile nu se reflectă în CMDB/Service Catalog → escaladări pierdute.
11) Încorporarea în instrumente
ChatOps: команды '/who oncall ', '/declare sev1', '/freeze ', '/rollback', '/status update '.
Directory/CMDB: serviciul are un proprietar, de gardă, SLO, tablouri de bord, playbook-uri, ferestre.
Alert-as-Code: Fiecare pagină are un proprietar și un playbook implicit.
Soluțiile GitOps: IC/Release se reflectă în adnotările de lansare și bilete.
12) Măsurarea scadenței distribuției rolului
Acoperirea rolurilor în directoare: ≥ 100% din serviciile critice.
SLA de gardă: Ack p95 ≤ 5 min; Pagina Storm p95 sub control.
Postmortem SLA: draft ≤ 72h; Finalizarea CAPA ≥ 85%.
Modificarea guvernanței:% modificări cu risc ridicat cu RFC/CAB ≥ 95%.
Comms: Aderență ≥ 95%, Rata plângerii ↓ QoQ.
13) Mini șabloane
13. 1 RACI pentru service (fișier în 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 Profil rol (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 escalations
14) Linia de jos
Operațiunile sunt robuste atunci când rolurile sunt transparente, împuternicite și încorporate în instrumente. Catalogul de roluri, RACI, interfețe clare și valori pentru fiecare rol transformă incidentele, eliberările și schimbările în procese gestionate: deciziile se iau rapid, riscurile sunt controlate, iar utilizatorii văd un serviciu stabil.