Runbooks et réponse aux incidents : du diagnostic à l'action en 5 minutes

Un runbook est une procédure pas-à-pas qui transforme une alerte en action : symptôme constaté → diagnostic → remédiation → escalade si nécessaire. Sans runbook, le SRE de garde à 3 h du matin ouvre le dashboard, regarde l’alerte, et passe 30 minutes à chercher quoi faire. Avec un runbook, il sait en moins de 5 minutes : quel est l’impact, comment diagnostiquer, quoi corriger, et qui appeler si ça ne suffit pas. Ce guide vous apprend à écrire des runbooks actionnables, à structurer le triage des incidents par sévérité, à mener des postmortems blameless, et à mesurer votre progression avec les bonnes métriques.

Ce que vous allez apprendre

Runbook vs Playbook : la différence entre une procédure pour une alerte et une procédure pour un type d’incident
Le format standard d’un runbook : les 4 sections (symptôme, diagnostic, remédiation, escalade) plus les prérequis d’accès
Bonnes pratiques de rédaction : toolbox pod, classification des erreurs, commandes copier-coller, vérifications standardisées
Triage 60 secondes : le protocole réflexe pour évaluer impact, blast radius, dernier changement, et choisir la stratégie
Mapping severity ↔ SEV : la relation entre la sévérité d’alerte (critical/warning) et le niveau d’incident (SEV-1/2/3)
Rôles pendant un incident : incident commander, ops lead, scribe, communicateur — qui fait quoi
Templates de communication : messages copiables pour Slack et la status page
Postmortem blameless : structure complète avec 5 catégories d’action items (prévention, détection, mitigation, remédiation, résilience)
Validation CI : automatiser la vérification des runbook_url et dashboard_url

Runbook vs Playbook

Avant de plonger, clarifions la terminologie :

Type	Scope	Exemple	Quand l’utiliser
Runbook	Une alerte spécifique	`PaymentErrorRateHigh.md`	L’alerte X vient de sonner — que faire ?
Playbook	Un type d’incident	`database-outage-playbook.md`	La base de données est down — quel que soit l’alerte qui l’a signalé

Un runbook est court, direct, lié à une alerte précise. Un playbook est plus large : il couvre un scénario d’incident (saturation réseau, panne DB, attaque DDoS) et peut référencer plusieurs runbooks.

Le problème : une alerte sans runbook

Imaginez : 3 h du matin, votre téléphone sonne. PaymentErrorRateHigh — critical. Vous ouvrez le dashboard. Le taux d’erreur est à 4 %. Et maintenant ? Qu’est-ce qui cause ces erreurs ? Est-ce la base de données, un déploiement récent, un fournisseur externe ? Faut-il rollback ? Qui prévenir ?

Sans runbook, chaque incident est une improvisation. Le SRE de garde doit reconstituer le diagnostic à partir de zéro, dans le stress, avec une visibilité partielle. Le résultat : un MTTR qui se compte en heures au lieu de minutes, des actions incohérentes d’un incident à l’autre, et une équipe qui s’épuise.

Avec un runbook, le SRE lit la procédure, suit les étapes, et résout — ou escalade — en quelques minutes. Le diagnostic n’est plus un art réservé aux experts : c’est une procédure documentée que n’importe quel membre de l’équipe de garde peut exécuter.

Le format standard d’un runbook

Un runbook efficace se structure en 5 sections : les prérequis d’accès, puis les 4 sections du cycle incident.

Structure complète

Section	Question	Contenu
0. Prérequis	De quoi ai-je besoin pour exécuter ce runbook ?	Accès kubectl, Grafana, logs, traces, toolbox pod
1. Symptôme	Que se passe-t-il vu de l’utilisateur ?	Impact, métriques affectées, classification des erreurs
2. Diagnostic	Quelle est la cause probable ?	Commandes toolbox, checklists ordonnées, arbre de décision
3. Remédiation	Comment corriger ?	Actions par cause, rollback, vérification après action
4. Escalade	Et si je n’arrive pas à résoudre ?	Qui, quand, par quel canal, quelles infos transmettre

Prérequis : la section souvent oubliée

Un runbook “copier-coller” ne sert à rien si le SRE de garde n’a pas les accès nécessaires. Listez explicitement :

## 0. Prérequis

### Accès requis
- kubectl avec contexte `production` (RBAC : rôle `sre-oncall`)
- Grafana : https://grafana.example.com (SSO)
- Loki : via Grafana → Explore
- Traces : Tempo via Grafana → Explore

### Outils
- Toolbox pod : `kubectl -n tools run -it --rm debug --image=nicolaka/netshoot -- bash`
- Feature flags : LaunchDarkly → projet "payments"
- Rollback : ArgoCD → Application "payment-api"

### Conventions
- Namespace production : `payments`
- Service : `payment-api`
- Dashboard principal : https://grafana.example.com/d/payment-red
- Logs query : `{namespace="payments", app="payment-api"}`

N’attendez pas d’avoir pg_isready, curl, ou dig dans vos images applicatives — elles sont souvent minimalistes. Utilisez un pod toolbox avec les outils de diagnostic :

kubectl -n payments run -it --rm debug \
  --image=nicolaka/netshoot -- bash

De là, vous pouvez dig postgres.payments.svc, curl http://payment-api:8080/health, nc -zv postgres 5432, etc.

Exemple complet : PaymentErrorRateHigh (version production-ready)

# Runbook : PaymentErrorRateHigh

**Alerte** : PaymentErrorRateHigh
**Sévérité alerte** : critical
**Owner** : équipe payments (@payments-oncall)
**Dernière mise à jour** : 2026-02-05
**Dashboard** : https://grafana.example.com/d/payment-red

---

## 0. Prérequis

### Accès requis
- kubectl contexte `production` (RBAC : `sre-oncall`)
- Grafana (SSO)
- LaunchDarkly (feature flags)
- ArgoCD (rollback)

### Toolbox
    kubectl -n payments run -it --rm debug --image=nicolaka/netshoot -- bash

### Conventions
- Namespace : `payments`
- Deployment : `payment-api`
- Dashboard : https://grafana.example.com/d/payment-red

---

## 1. Symptôme

Les utilisateurs voient des erreurs lors du paiement. Le taux d'erreur
du service payment-api dépasse 1 % sur les 5 dernières minutes.

**Impact** : paiements échoués — perte de revenus directe.

### Classification des erreurs

Avant de diagnostiquer, identifier le **type d'erreur** :

| Type | Symptôme | Cause probable | Section diagnostic |
|------|----------|----------------|-------------------|
| **5xx** | Erreurs serveur (500, 502, 503) | Bug applicatif, DB down, dépendance en erreur | 2.1, 2.2, 2.3 |
| **4xx** | Erreurs client (400, 401, 403) | Changement d'API, auth cassée | Pas d'action infra — remonter au dev |
| **Timeout** | Requêtes qui n'aboutissent pas | Saturation, DB lente, réseau | 2.4 |
| **TLS/DNS** | Erreurs de connexion | Certificat expiré, DNS mal configuré | 2.5 |

Vérifier dans le dashboard "Error breakdown" quel type domine.

---

## 2. Diagnostic

Suivre dans l'ordre — s'arrêter dès qu'une cause est identifiée.

### 2.1 Déploiement récent ?

    kubectl -n payments rollout history deployment/payment-api

Si déploiement dans les 30 dernières minutes → **rollback** (section 3.1).

### 2.2 Base de données accessible ?

Depuis le pod toolbox :

    # Lancer le toolbox
    kubectl -n payments run -it --rm debug --image=nicolaka/netshoot -- bash

    # Tester la connectivité PostgreSQL
    nc -zv postgres.payments.svc 5432
    # Si OK : "Connection to postgres.payments.svc 5432 port [tcp/postgresql] succeeded!"

    # DNS résout ?
    dig postgres.payments.svc

Si la DB ne répond pas → escalader à l'équipe DBA (section 4.2).

### 2.3 Fournisseur de paiement externe ?

**Isoler si c'est nous ou le provider** :

1. Vérifier les pages de statut :
   - Stripe : https://status.stripe.com
   - Adyen : https://status.adyen.com

2. Dans les logs, chercher le pattern d'erreur :

   ```plaintext
   {namespace="payments"} |= "stripe" or "adyen" | json | status >= 500
   ```

3. Si les erreurs viennent **du provider** (leur 5xx, pas le nôtre) :
   - Rien à faire côté infra
   - Communiquer au product owner
   - Attendre résolution provider

4. Si les erreurs sont **notre côté** (timeouts, TLS, DNS vers provider) :

   Depuis le toolbox :
   ```bash
   curl -v https://api.stripe.com/v1/health
   dig api.stripe.com
   ```

### 2.4 Saturation des ressources ?

    kubectl -n payments top pods -l app=payment-api

**Si OOMKilled** : ne pas scaler aveuglément. Vérifier d'abord :
- Requests/limits actuels : `kubectl get pod <pod> -o jsonpath='{.spec.containers[*].resources}'`
- Pic soudain ou croissance lente ? (dashboard mémoire)
- Logs applicatifs pour fuite mémoire (heap, GC)

**Si CPU > 90 %** : vérifier le **throttling** avant de scaler :
- Dashboard cAdvisor : `container_cpu_cfs_throttled_seconds_total`
- Si throttling élevé avec p99 dégradé → scale-up justifié
- Si CPU haut mais pas de throttling → peut-être juste un pic normal

### 2.5 Problème TLS / DNS / egress ?

Depuis le toolbox :

    # Test egress vers dépendance externe
    curl -v https://api.stripe.com/v1/health

    # Vérifier le certificat
    openssl s_client -connect api.stripe.com:443 -servername api.stripe.com

    # DNS interne
    dig kubernetes.default.svc

---

## 3. Remédiation

### 3.1 Rollback du dernier déploiement

    kubectl -n payments rollout undo deployment/payment-api

**Vérification** : le taux d'erreur redescend sous 1 % dans les 5 minutes.

### 3.2 Désactiver une feature flag

Si un feature flag récent est suspecté :

1. LaunchDarkly → projet "payments"
2. Désactiver le flag suspecté
3. Vérifier le taux d'erreur

### 3.3 Redémarrage des pods

    kubectl -n payments rollout restart deployment/payment-api

Utile si état incohérent (connexions DB stale, cache corrompu).

### 3.4 Scale-up (après vérification saturation)

    kubectl -n payments scale deployment/payment-api --replicas=6

Seulement si la section 2.4 a confirmé une saturation réelle.

---

## 4. Escalade

| Délai | Action | Contact |
|-------|--------|---------|
| T+0 | Acquitter l'alerte, commencer le diagnostic | SRE de garde |
| T+15 min | Si non résolu → appeler le secondaire | @payments-oncall-secondary |
| T+30 min | Si non résolu → escalader au lead | @payments-eng-lead |
| T+1 h | Si non résolu → incident commander | @incident-commander |

### 4.2 Escalade DBA

Si la base de données ne répond pas :

- Contact : @dba-oncall
- Slack : #dba-incidents
- Infos à transmettre : résultat du `nc -zv`, erreurs dans les logs pods

**Informations à transmettre lors de toute escalade** :
- Heure de début de l'incident
- Type d'erreur dominant (5xx, timeout, TLS...)
- Impact (% d'erreur, estimation utilisateurs affectés)
- Étapes de diagnostic déjà effectuées
- Hypothèses testées et résultats

Lier les runbooks aux alertes

Chaque alerte Prometheus doit contenir des annotations standardisées :

annotations:
  runbook_url: "https://wiki.example.com/runbooks/payment-error-rate"
  dashboard_url: "https://grafana.example.com/d/payment-red"
  log_query_url: "https://grafana.example.com/explore?query={namespace=\"payments\"}"
  owner: "payments-team"

Annotation	Usage
`runbook_url`	Lien direct vers le runbook de l’alerte
`dashboard_url`	Dashboard principal pour le diagnostic visuel
`log_query_url`	Requête Loki pré-remplie pour les logs
`trace_query_url`	Requête Tempo pré-remplie (optionnel)
`owner`	Équipe responsable (@team ou email)

Quand l’alerte sonne, le SRE clique sur runbook_url et arrive directement sur la procédure.

Validation CI des liens

Un lien cassé est pire que pas de lien. Intégrez une validation dans votre pipeline CI :

Logique de gating :

Parser les fichiers de règles Prometheus (.yaml)
Extraire chaque runbook_url et dashboard_url
Pour chaque URL : vérifier qu’elle retourne HTTP 200
Si une alerte severity: critical n’a pas de runbook_url → échec du build

Exemple de script (pseudo-code) :

#!/bin/bash
RULES_DIR="prometheus/rules"
FAILED=0

for rule_file in $RULES_DIR/*.yaml; do
  # Extraire les URLs de runbook_url
  urls=$(yq '.groups[].rules[].annotations.runbook_url' "$rule_file" | grep -v null)

  for url in $urls; do
    status=$(curl -s -o /dev/null -w "%{http_code}" "$url")
    if [ "$status" != "200" ]; then
      echo "FAILED: $url returns $status"
      FAILED=1
    fi
  done

  # Vérifier que les alertes critical ont un runbook
  critical_without_runbook=$(yq '.groups[].rules[] |
    select(.labels.severity == "critical") |
    select(.annotations.runbook_url == null) |
    .alert' "$rule_file")

  if [ -n "$critical_without_runbook" ]; then
    echo "FAILED: Critical alert without runbook: $critical_without_runbook"
    FAILED=1
  fi
done

exit $FAILED

Triage par sévérité : le protocole 60 secondes

Quand un incident survient, les 60 premières secondes sont critiques. Voici le protocole réflexe :

Mapping alert severity ↔ incident SEV

La severity d’une alerte (critical/warning/info) n’est pas la même chose que le SEV d’un incident (SEV-1/2/3). La severity décrit la configuration de l’alerte ; le SEV décrit l’impact réel constaté.

Alert severity	Incident SEV probable	Exemple
`critical`	SEV-1 ou SEV-2 selon impact réel	Alerte critical mais 2 % des users → SEV-2
`warning`	SEV-2 ou SEV-3 selon durée et impact	Warning persistant 2 h → peut monter en SEV-2
`info`	Pas d’incident	Notification, pas d’action immédiate

Grille de sévérité incident

Niveau	Critères	Exemples	Qui mobiliser	Délai réponse
SEV-1	> 50 % utilisateurs affectés, service core down, perte de données, brèche sécurité	Checkout en panne, fuite de données, base corrompue	IC + équipe complète + management	< 15 min
SEV-2	< 50 % utilisateurs, fonctionnalité importante dégradée, contournement possible	Recherche lente, notifications retardées, 1 provider sur 2 en erreur	Équipe on-call + engineering lead	< 30 min
SEV-3	Impact limité, fonctionnalité secondaire, pas d’impact revenu	Page marketing en erreur, outil interne lent	Équipe on-call uniquement	< 4 h (heures ouvrées)

Évaluation impact × urgence

	Urgence haute (empire rapidement)	Urgence basse (stable)
Impact fort (service core, > 50 % users)	SEV-1	SEV-2
Impact modéré (fonctionnalité secondaire, < 50 % users)	SEV-2	SEV-3
Impact faible (cosmétique, outil interne)	SEV-3	Pas d’incident — ticket

Rôles pendant un incident

Un incident SEV-1 avec 5 personnes qui font toutes la même chose est pire qu’un incident avec 4 personnes aux rôles définis.

Les 4 rôles essentiels

Rôle	Responsabilité	Qui
Incident Commander (IC)	Coordonne la réponse, décide des actions, gère les priorités, déclare la fin de l’incident. Ne tape pas de commandes.	SRE senior ou engineering lead
Ops Lead	Exécute les actions techniques : diagnostic, remédiation, surveillance	SRE de garde ou dev de l’équipe owner
Scribe	Note en temps réel : actions, timestamps, décisions, liens, hypothèses testées. Alimente le postmortem.	Membre de l’équipe dédié
Communicateur	Tient informés management, support client, status page à intervalles réguliers (15-30 min)	Engineering manager ou membre dédié

Pour un SEV-3, le SRE de garde cumule les 4 rôles. Pour un SEV-1, séparer les rôles est indispensable.

Templates de communication

Update interne (Slack incident channel)

Postez une mise à jour toutes les 15-30 minutes :

🔴 **Incident Update — [timestamp]**

**Impact** : Checkout en erreur pour ~15 % des utilisateurs
**Status** : Diagnostic en cours
**Mitigation** : Rollback v2.4.1 en cours
**Next step** : Vérifier taux d'erreur post-rollback
**ETA** : 10 min pour confirmation
**Owner** : @alice-martin (IC) / @bob-dupont (Ops Lead)

Update externe (status page)

Pour les utilisateurs et clients :

**[Investigating] Difficultés de paiement**

Nous avons identifié un problème affectant les paiements sur notre
plateforme. Certains utilisateurs peuvent rencontrer des erreurs lors
du checkout.

**Services impactés** : Paiement par carte
**Workaround** : Réessayer dans quelques minutes ou utiliser PayPal
**Prochaine mise à jour** : dans 30 minutes

_Dernière mise à jour : 14h45 UTC_

Déroulement type d’un incident

Détection

L’alerte sonne. Le chronomètre MTTD commence — c’est le temps entre le début réel du problème et sa détection.
Acquittement

Le SRE de garde acquitte l’alerte dans l’outil d’astreinte. Le chronomètre MTTA s’arrête ici.
Triage 60 secondes

Appliquer le protocole : impact, blast radius, dernier changement, stratégie. Décider du SEV.
Mobilisation (si SEV-1/2)

Créer un canal Slack dédié (#incident-2026-02-07-payments). Assigner les rôles : IC, Ops Lead, Scribe, Communicateur.
Diagnostic

Suivre le runbook : vérifier les causes probables dans l’ordre. Le scribe note chaque action et résultat.
Remédiation

Appliquer le correctif. Mitigation d’abord (rollback, disable flag), RCA ensuite. Vérifier le retour à la normale.
Communication

Informer les parties prenantes que l’incident est résolu. Mettre à jour la status page. Le chronomètre MTTR s’arrête ici.
Postmortem

Dans les 48 h, rédiger un postmortem blameless avec action items typés. Mettre à jour le runbook si nécessaire.

Postmortem blameless

Un postmortem est un document écrit qui analyse un incident après sa résolution. L’objectif : comprendre ce qui s’est passé et éviter que ça se reproduise. Le mot clé est blameless : focus sur les systèmes et processus, pas sur les individus.

Pourquoi “blameless” ?

Si un ingénieur a fait une erreur, c’est que le système lui a permis de la faire. Un déploiement qui casse la production n’est pas la faute de l’ingénieur — c’est la faute du pipeline qui n’a pas détecté le problème.

Google SRE : “un postmortem blameless fait que les ingénieurs se sentent en sécurité pour rapporter les détails sans craindre de représailles — ce qui permet d’obtenir les informations nécessaires pour corriger les causes racines.”

Les 5 catégories d’action items

Des action items vagues (“améliorer le monitoring”) ne seront jamais faits. Classez chaque action dans une catégorie :

Catégorie	Objectif	Exemples
Prévention	Empêcher que l’erreur se produise	Tests CI, validation schéma DB, review obligatoire
Détection	Détecter plus vite si ça se reproduit	Nouvelle alerte, SLO, dashboard, Watchdog
Mitigation	Réduire l’impact quand ça arrive	Rollback automatique, feature flags, autoscaling safe
Remédiation	Corriger la cause racine	Bugfix, refactoring, changement de design
Résilience	Tolérer la panne	Timeouts, circuit breakers, bulkheads, retry with backoff

Template postmortem

# Postmortem : [Titre descriptif de l'incident]

**Date** : 2026-02-07
**Durée** : 14h32 — 15h47 (1 h 15 min)
**Sévérité** : SEV-1
**Incident Commander** : Alice Martin
**Ops Lead** : Bob Dupont
**Scribe** : Charlie Durand
**Auteur du postmortem** : Bob Dupont
**Statut** : Action items en cours

---

## Résumé

Le service payment-api a retourné un taux d'erreur 5xx de 12 % pendant
1 h 15 entre 14h32 et 15h47, impactant environ 8 000 transactions de
paiement. Cause racine : migration de schéma DB non rétrocompatible.

## Impact

- ~8 000 tentatives de paiement échouées
- Perte de revenu estimée : ~24 000 €
- 47 tickets support client ouverts
- Status page en "major outage" pendant 1 h

## Timeline

| Heure | Événement |
|-------|-----------|
| 14h28 | Déploiement v2.4.1 avec migration de schéma |
| 14h32 | Alerte PaymentErrorRateHigh (critical) |
| 14h34 | Acquittement, ouverture runbook, triage SEV-1 |
| 14h35 | Canal #incident-2026-02-07-payments créé |
| 14h38 | Diagnostic : déploiement récent identifié |
| 14h42 | Tentative rollback kubectl |
| 14h45 | Rollback échoué — migration DB irréversible |
| 14h50 | Escalade équipe DB |
| 15h05 | Fix identifié : code compatible ancien+nouveau schéma |
| 15h35 | Fix déployé (v2.4.2) |
| 15h47 | Taux d'erreur < 0.1 %. Incident résolu |

## Causes racines

Migration de schéma v2.4.1 : colonne `payment_method` renommée en
`payment_type`. Pods en rolling update utilisaient l'ancien nom →
erreurs SQL.

**Cause contribuante** : pas de validation rétrocompatibilité schéma DB
dans le pipeline CI.

## Ce qui a bien fonctionné

- MTTD = 4 min (alerte rapide)
- Runbook a orienté vers "déploiement récent"
- MTTA = 2 min

## Ce qui doit être amélioré

- Rollback applicatif insuffisant si migration DB irréversible
- Pipeline CI n'a pas détecté l'incompatibilité
- Communication support client : 25 min de délai

## Action items

| Catégorie | Action | Owner | Deadline |
|-----------|--------|-------|----------|
| **Prévention** | Check rétrocompatibilité schéma DB dans CI | @platform | 2026-02-15 |
| **Prévention** | Documenter pattern expand-then-contract | @dba | 2026-02-20 |
| **Détection** | Alerte sur erreurs SQL liées aux colonnes | @payments | 2026-02-25 |
| **Mitigation** | Runbook : cas "rollback DB impossible" | @payments-oncall | 2026-02-12 |
| **Résilience** | Feature flag pour activer/désactiver migration | @platform | 2026-03-01 |

## Leçons apprises

Les migrations de schéma doivent être **rétrocompatibles** (expand then
contract) : l'ancien et le nouveau code doivent pouvoir coexister pendant
le rolling update.

Les 5 erreurs de postmortem à éviter

Erreur	Pourquoi c’est un problème	Solution
Chercher un coupable	Les gens cachent les détails	Focus systèmes et processus
Action items sans owner	”Améliorer le monitoring” ne sera jamais fait	Owner + deadline obligatoires
Action items non typés	Tickets vagues sans direction	Catégoriser : prévention/détection/mitigation/remédiation/résilience
Pas de timeline	Impossible de comprendre la chronologie	Minute par minute, du scribe
Postmortem trop tardif	Souvenirs flous après 2 semaines	Rédiger dans les 48 h

Métriques d’incident : MTTD, MTTA, MTTR, MTBF

Les métriques d’incident mesurent l’efficacité de votre processus.

Les 4 métriques essentielles

Métrique	Nom complet	Ce qu’elle mesure
MTTD	Mean Time To Detect	Temps entre le début du problème et sa détection
MTTA	Mean Time To Acknowledge	Temps entre l’alerte et l’acquittement
MTTR	Mean Time To Resolve	Temps entre la détection et le retour à la normale
MTBF	Mean Time Between Failures	Temps moyen entre deux incidents

Convention MTTR recommandée

MTTR a plusieurs définitions (Resolve, Recover, Repair). Adoptez une convention d’équipe et documentez-la :

MTTR = retour à une expérience utilisateur acceptable (pas “tous les systèmes parfaits”)

Si les utilisateurs peuvent à nouveau payer, l’incident est résolu — même si le fix définitif n’est pas encore déployé.

Cibles et leviers

Métrique	Cible	Si hors cible	Levier
MTTD	< 5 min	Alertes trop lentes	Améliorer seuils, alertes symptom-first, Watchdog
MTTA	< 15 min	Équipe ne réagit pas	Planning astreinte, outil de paging, alert fatigue
MTTR	< 1 h (SEV-1)	Résolution trop lente	Meilleurs runbooks, automatisation, formation
MTBF	En augmentation	Mêmes incidents récurrents	Suivre les action items postmortem

Anti-patterns

Anti-pattern	Problème	Solution
Runbook “fourre-tout”	30 pages pour 15 alertes	1 runbook = 1 alerte
Pas de prérequis	SRE n’a pas les accès le jour J	Section 0. Prérequis explicite
Commandes vagues	”Vérifiez que la base fonctionne”	Commandes exactes, toolbox pod
Scale-up réflexe	OOMKilled → scale sans vérifier	D’abord requests/limits, leak, GC
Pas de classification erreurs	Traiter 5xx et 4xx de la même façon	Tableau 5xx/4xx/timeout/TLS
Runbook jamais testé	Procédure cassée le jour J	Game day trimestriel
Postmortem = blâme	Personne ne rapporte les détails	Blameless : systèmes, pas individus
Action items vagues	”Améliorer le monitoring”	Owner + deadline + catégorie
Pas de scribe	Timeline reconstituée de mémoire	Scribe dédié en SEV-1
Pas de communication	Management appelle le SRE	Templates + updates réguliers

Workflow : mettre en place le processus

Inventoriez vos alertes critical

Listez toutes les alertes critical. Ce sont vos candidats prioritaires.
Écrivez le premier runbook

Choisissez l’alerte la plus fréquente. Écrivez les 5 sections (prérequis
- 4 sections incident). Faites relire par un junior.
Standardisez les annotations

Ajoutez runbook_url, dashboard_url, owner dans chaque alerte.
Configurez la validation CI

Script qui vérifie : HTTP 200 sur chaque URL, runbook obligatoire si severity: critical.
Définissez votre grille de sévérité

SEV-1/2/3 avec critères clairs, mapping severity ↔ SEV, rôles par niveau.
Formalisez les rôles

IC, Ops Lead, Scribe, Communicateur. Templates de communication.
Rédigez votre premier postmortem

Après le prochain incident, utilisez le template avec les 5 catégories d’action items.
Itérez chaque trimestre

Revue runbooks, suivi action items, game day pour tester les procédures.

À retenir

Runbook = procédure pour une alerte (court, direct). Playbook = procédure pour un type d’incident (DB down, saturation) qui regroupe plusieurs alertes
Un runbook a 5 sections : prérequis (accès, toolbox, conventions) + symptôme + diagnostic + remédiation + escalade
Utilisez un pod toolbox (nicolaka/netshoot) pour le diagnostic — n’attendez pas d’avoir les outils dans vos images applicatives
Classification des erreurs : 5xx, 4xx, timeout, TLS — chaque type a une remédiation différente
Protocole triage 60 secondes : impact, blast radius, dernier changement, stratégie (mitigation d’abord, RCA ensuite)
4 rôles en SEV-1 : IC (coordonne), Ops Lead (exécute), Scribe (note la timeline), Communicateur (informe)
Postmortem blameless avec 5 catégories d’action items : prévention, détection, mitigation, remédiation, résilience
Convention MTTR : retour à une expérience utilisateur acceptable (pas tous les systèmes parfaits). Documentez votre définition.

Sources

Google SRE Book — Postmortem Culture : sre.google/sre-book/postmortem-culture
Google SRE Workbook — Postmortem Culture : sre.google/workbook/postmortem-culture
Google SRE Book — Example Postmortem : sre.google/sre-book/example-postmortem
PagerDuty — Incident Response Guide : response.pagerduty.com
PagerDuty — Postmortem Guide : postmortems.pagerduty.com
Atlassian — Incident Management Metrics : atlassian.com/incident-management/kpis/common-metrics

Prochaines étapes

Alerting efficace Configurer les alertes symptom-first et les annotations runbook_url qui pointent vers vos runbooks

Dashboards utiles Concevoir les dashboards RED et USE que vos runbooks référencent pour le diagnostic

Observabilité Kubernetes Les signaux clés K8s (OOMKilled, pending, restarts) et les runbooks associés

SLI, SLO, SLA Définir les objectifs de fiabilité qui déterminent vos seuils d'alerte et niveaux de sévérité

Corrélation des signaux Relier logs, métriques et traces pour accélérer le diagnostic pendant un incident