Rôles et responsabilités dans les opérations

1) Pourquoi formaliser les rôles

La répartition claire des rôles réduit MTTA/MTR, élimine les « zones grises », accélère les sorties et rend la conformité SLO/Complaence reproductible. Rôles = responsabilité + pouvoirs + interfaces (à qui nous écrivons, à qui nous augmentons, quelles solutions sont autorisées).

2) Modèle RACI de base

R (Responsible) : Exécute le travail.
A (Comptable) - assume la responsabilité finale et prend des décisions.
C (Consulted) est un expert, consulté avant/pendant.
I (Informed) - est informé sur SLA.

3) Catalogue des rôles (descriptions et responsabilités)

3. 1 Incident Commander (IC)

Objectif : diriger la réponse à l'incident SEV-1/0.
Pouvoirs : déclarer SEV, geler les sorties, changer le trafic, escalader.
Les principaux défis sont : temporisation, prise de décision, maintien de la concentration, répartition des tâches, Go/No-Go.
Artefacts : Carte d'incident, Apdates sur SLA, AAR final.

3. 2 P1/P2 On-Call (Primary/Secondary)

Objectif : réponse primaire et actions techniques.
P1 : triage, lancement de playbooks, communication avec IC.
P2 : backup, changements complexes, maintien du contexte, dans les tempêtes - prend les subpots.

3. 3 SRE / Platform Engineer

Objectif : fiabilité de la plate-forme et de la rampe (SLO, alertes, GitOps, Auto Skale, DR).
Défis : SLI/SLO, hygiène alerte, versions progressives, infrastructure comme code, capacity, observability.
Au moment de l'incident : diagnostic de la racine, retouches/folbacks, inclusion de degrade-UX.

3. 4 Service Owner / Product Owner

Objectif : la qualité du service au sens commercial.
Tâches : Définir les priorités/SLO, négocier les versions/fenêtres, participer à Go/No-Go.
Comms : la solution pour savoir quand et quoi dire aux clients avec Comms.

3. 5 Release Manager

Objectif : Apporter des changements en toute sécurité.
Tâches : orchestration de release, chekap gates, canari/blue-green, annotations de release, freeze en cas d'incident.

3. 6 CAB Chair / Change Manager

Objectif : gérer le risque de changement.
Tâches : processus RFC, plan/backout, calendrier des conflits, approbation des risques élevés.

3. 7 RCA Lead / Problem Manager

Objectif : Examen post-incident, CAPA.
Tâches : temporisation, causalité probante, actions correctives/préventives, contrôle D + 14/D + 30.

3. 8 Security (IR Lead, AppSec/CloudSec)

Objectif : sécurité et intervention en cas d'incidents de sécurité.
Tâches : triage sécurité-événements, rotation des clés, isolation, forensing, notifications réglementaires, audit WORM.

3. 9 DataOps / Analytics

Objectif : fiabilité des données et des pipelines.
Défis : fraîcheur/qualité (DQ), contrats de données, lineage, backfill, BI/rapports SLA.

3. 10 FinOps

Objectif : Coûts gérables.
Tâches : quotas/limites, rapports $/unité, gates budgétaires, optimisations (volumes logiques, egress, redondance).

3. 11 Compliance / Legal

Objectif : conformité à la réglementation et aux contrats.
Tâches : délais de notification, rétroaction/invariabilité, harmonisation des textes publics.

3. 12 Support / Comms

Objectif : communication avec les clients/stackholders internes.
Tâches : état de la page, mises en page, fréquence et clarté des messages, collecte des commentaires.

3. 13 Vendor Manager / Provider Owner

Objectif : relations avec des fournisseurs externes (PSP/KYC/CDN, etc.).
Défis : escalade, SLA/OLA, itinéraires de secours, coordination des fenêtres.

4) Rôles dans le changement et l'escalade

Changement : P1/P2 + IC-of-the-day (ne pas combiner avec la P1).
Escalade temporelle : P1→P2 (5 min sans ack) → IC (10 min) → Duty Manager (15 min).
Heures de quiet : Les signaux P2/P3 ne sont pas réveillés ; signaux de sécurité - toujours.

5) Interfaces d'interaction (avec qui et comment)

IC ↔ Release Manager : solutions freeze/rollback.
IC ↔ Comms : textes d'update et fréquence.
SRE ↔ DataOps : Business SLI (succès des paiements, fraîcheur des données) dans les garderies SLO.
Security ↔ Legal : rapports d'incidents de sécurité, délais de notification.
Vendor Owner ↔ IC : statut de fournisseur, switchover/folback.

6) KPI par rôle (repères)

IC : Time-to-Declare, conformité à Comms SLA, MTTR par SEV-1/0.
P1/P2 : MTTA, Time-to-First-Action, % en suivant les playbacks.
SRE/Platform : SLO coverage, Alert Hygiene, % de rebonds auto réussis.
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 backfill.
Comms : Status Accuracy, Taux complet/incident.
FinOps : $/unité, % d'économie QoQ, respect des quotas.

7) Modèles de cartes de rôle

7. 1 Carte 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 Carte de 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 boundaries

7. 3 Carte 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/after

8) Processus et participation des rôles (résumé)

A — Accountable, R — Responsible, C — Consulted, I — Informed.

9) Chèques-feuilles

9. 1 Attribution de rôles

• Chaque rôle a un propriétaire, un adjoint et une zone de couverture.
• Les pouvoirs (quelles décisions peuvent être prises) sont décrits.
• Les pleybooks et les canaux de communication sont liés.
• Publié par SLA sur la réaction/comms.
• Le rôle est disponible dans le répertoire (CMDB) de chaque service.

9. 2 Changement et handover

• Carte de poste mise à jour (incidents actifs, risques, fenêtres).
• Les accès JIT/JEA ont été vérifiés.
• Message d'écho à la chaîne : « changement accepté/remis ».

9. 3 Post-incident

• L'AAR a eu lieu, RCA a été nommé.
• CAPA avec propriétaires/délais, contrôle D + 14/D + 30.
• Mise à jour des playbooks/alertes/politiques.

10) Anti-modèles

Obscur "qui décide" → les retards et doubles des efforts.
IC est aligné avec P1 - perte de leadership.
Comms publics sans accord avec Legal/Comms.
La sortie sans Release Manager et les gates → la croissance des CFR.
Absence de réservation des rôles (maladie/vacances).
« Héroïsme » au lieu du processus : on sauve manuellement, mais on ne fixe pas la rampe.
Les rôles ne sont pas reflétés dans le répertoire CMDB/Service → les escalades perdues.

11) Incorporation dans les outils

ChatOps: команды `/who oncall`, `/declare sev1`, `/freeze`, `/rollback`, `/status update`.
Catalogue/CMDB : le service est propriétaire, on-call, SLO, dashboards, playbooks, fenêtres.
Alert-as-Code : chaque Page a un owner et un playbook par défaut.
GitOps : Les solutions IC/Release sont reflétées dans les annotations de version et les tickets.

12) Métriques de maturité de la répartition des rôles

Coverage des rôles dans les répertoires : ≥ 100 % des services critiques.
On-call SLA : Ack p95 ≤ 5 min ; Page Storm p95 sous contrôle.
SLA Postmortem : brouillon ≤ 72h ; CAPA completion ≥ 85%.
Changement de gouvernance :% de changements à haut risque avec RFC/BOU ≥ 95 %.
Comms: Adherence ≥ 95%, Complaint Rate ↓ QoQ.

13) Mini-modèles

13. 1 RACI pour le service (dossier au repaire)

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 du rôle (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) Résultat

Les opérations sont durables lorsque les rôles sont transparents, autorisés et intégrés dans les outils. Le répertoire des rôles, RACI, des interfaces claires et des métriques pour chaque rôle transforment les incidents, les sorties et les changements en processus gérables : les décisions sont prises rapidement, les risques sont contrôlés et les utilisateurs voient un service stable.