Incident management : runbooks qui marchent (incident.io)

À la fin de ce tutoriel, vous poserez un incident management utile à 3 h du matin : déclarer, rôles (lead, comms, scribe), timeline, Catalog (services, owners, dashboards), Workflows incident.io qui collent le bon runbook, et un lab CloudWatch + SNS en ca-central-1. Git reste la source de vérité ; incident.io est le fil d’exécution, pas un wiki de plus.

Niveau : Intermédiaire · Temps estimé : 50–70 min · Versions cibles : incident.io Response + Catalog + Workflows (On-call optionnel, 2026) · AWS CLI v2 · CloudWatch · SNS · Markdown Git · Dernière vérification : 2026-09-11 · Region : ca-central-1

Slug : wow-incident-io-runbooks · Série : WOW (27/50) · Mot-clé SEO : incident.io runbooks · Publish : HOLD

← Précédent : Grafana Loki Tempo · → Suivant : SRE : error budgets et SLOs · Aussi : ChatGPT runbooks · Step Functions SRE · CloudWatch alarmes

Prérequis

• Alerting — CloudWatch alarmes · OpenTelemetry
• Dépôt Git docs/runbooks/ — ChatGPT × runbooks
• Compte AWS lab (AWS_PROFILE=lab) — Démarrer avec AWS
• Workspace incident.io (Response + Catalog). On-call optionnel si PagerDuty page encore
• Slack ou Teams branché sur le workspace

Coût estimé : 0–1 € (métrique + alarme + SNS). Pas de NAT, RDS, EKS. Cleanup en fin de lab. Abonnement incident.io hors AWS.

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
aws sts get-caller-identity

Ce que nous allons construire

Incident management / runbooks (WOW 27/50) — ca-central-1
  ├── Pourquoi les wikis d’astreinte pourrissent
  ├── Fil incident.io : declare → channel → roles → timeline
  ├── Catalog : Service → Team → Runbook → Dashboard
  ├── Workflows : alerte → sévérité → page → coller le runbook
  ├── Lab : métrique custom + alarme CloudWatch + SNS
  ├── Runbook Git (read-only → fix → verify → rollback)
  └── Postmortem, follow-ups, pont SLO

(Schéma — alt : « Alerte CloudWatch ca-central-1 → incident Slack incident.io + Catalog + runbook Git ».)

Étape 1 — Pourquoi les runbooks « ne marchent pas »

Un runbook n’est pas une page Confluence. C’est le contrat d’exécution : déclencheur, preuves, actions, rollback, owners. Le MTTR se joue sur le temps de compréhension (qui, quoi, où regarder), pas sur un modèle qui tape kubectl tout seul.

Symptôme	Cause	À 3 h
Wiki 2022, prod 2026	Pas de revue / owner	Commandes mortes
Runbook hors du canal	On cherche le lien 12 min	Canal chaos
« Appeler Bob »	Pas de Catalog / paging	Escalade au feeling
Fix sans preuve	Pas de diag read-only	Double incident
Postmortem slide	Follow-ups non trackés	Récidive

incident.io : le canal Slack est l’incident, le Catalog relie service → équipe → docs, les Workflows collent le contexte sans ticket. Ce n’est pas un bot de change prod, ni un substitut des error budgets.

Étape 2 — Le fil incident.io (Response)

Déclarer (slash command, alerte, UI) ouvre un canal, une timeline auditable, des rôles et des champs custom.

Rôle	Mission	Anti-pattern
Incident Lead	Cadence, décisions, freeze scope	Lead = unique typer
Comms	Statut interne / status page	Silence 40 min
Scribe	Timeline + actions	« On écrira demain »

Figez les sévérités avant l’incendie (Sev-1 client down → Sev-4 latent). Un Workflow peut suggérer la sev depuis les labels (service, env, slo_burn) ; un humain confirme. Timeline = preuve postmortem (qui a page, quel runbook, quel rollback). Zéro secret dans Slack : IDs, ARNs, extraits redactés.

Étape 3 — Catalog : la carte, pas le wiki

Le Catalog est une carte : services, teams, owners, dépendances, contacts, liens de runbooks, dashboards. Il alimente Workflows, Insights, Triggers, On-call et parfois les status pages. Alimentation : manuel, API, ou import (Backstage, PagerDuty).

Type	Attributs utiles
Service	slug, repo, team, runbook URL, dashboard, region
Team	Slack handle, schedule / escalation
Environment	prod / lab, compte AWS, ca-central-1
Dashboard	URL Grafana / CloudWatch

# catalog/checkout-api.yaml — Git, à sync dans Catalog (pas un CLI officiel)
kind: Service
slug: checkout-api
owner: payments-oncall
region: ca-central-1
runbook: docs/runbooks/checkout-error-rate.md
dashboard: https://grafana.example.internal/d/checkout
depends_on: [payments-gateway, inventory-api]
alerts:
  service_label: checkout-api

Un service prod sans owner Catalog = dette. Les Workflows ne pagent pas « la bonne équipe » si la carte est vide. Dix fiches valides battent quatre cents stubs.

Étape 4 — Workflows : le runbook dans le chemin

Si (alerte / champ / sévérité) alors (actions) : pager la bonne équipe, poser une sev, inviter le CS, update status page, coller runbook + dashboard du service.

Couche DEH : triage (service/env) → pin runbook + dashboard → paging On-call ou PagerDuty via Catalog. Aucun restart / terraform apply auto.

CloudWatch doit porter des labels mappables ; l’alert source les relie au Catalog. Runbook exécutable = ordre, copy-paste, sorties attendues, humain sur le fix. Orchestration AWS longue → Step Functions SRE.

Étape 5 — Anatomie du runbook Git

Même contrat que ChatGPT runbooks : ChatGPT rédige, Git garde, incident.io surface.

Bloc	Minimum
Métadonnées	ID, sev, service, owners, revue
Déclencheur	Alarme / seuil / symptôme
Impact	User, SLO, blast radius
Diagnostics	Read-only + sortie attendue
Remédiation	Ordre, risque, prérequis
Vérification	Postconditions mesurables
Rollback	Si ça empire
Escalade	Après N échecs / T min

# Runbook : CheckoutErrorRate élevée
- **ID :** RB-CHK-001 · **Sev :** 2 (1 si checkout down > 5 min)
- **Service :** checkout-api · **Owners :** @payments-oncall
- **Region :** ca-central-1 · **Revue :** 2026-09-11

## Déclencheur
Alarme CloudWatch `deh-lab-checkout-error-rate` (namespace `DEH/Lab`).

## Diagnostics (read-only)
`aws cloudwatch get-metric-statistics --namespace DEH/Lab --metric-name CheckoutErrorRate --period 60 --statistics Average --region ca-central-1 ...`
Logs redactés. Hypothèses classées — pas de fix au feeling.

## Remédiation
Rollback du dernier deploy **si** la preuve pointe le release. Sinon scale / flag — **humain décide**.

## Vérification / escalade
Alarme OK + error rate sous seuil 5 min. Lead annonce. Si pire : annuler le rollback. Sev-1 → comms + status page.

Revue 90 jours ou après un incident qui a menti. Lien Catalog = chemin Git stable.

Étape 6 — Lab ca-central-1 : alarme → SNS

Objectif : prouver le déclencheur AWS. Le HTTPS vers l’alert source incident.io se configure dans l’UI (URL + secret) : aucun secret dans ce tuto.

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1

TOPIC_ARN=$(aws sns create-topic --name deh-lab-incident-alerts 
  --query TopicArn --output text)

aws cloudwatch put-metric-alarm 
  --alarm-name deh-lab-checkout-error-rate 
  --namespace DEH/Lab --metric-name CheckoutErrorRate 
  --statistic Average --period 60 --threshold 5 
  --comparison-operator GreaterThanThreshold 
  --evaluation-periods 1 --datapoints-to-alarm 1 
  --treat-missing-data notBreaching 
  --alarm-actions "$TOPIC_ARN"

aws cloudwatch put-metric-data --namespace DEH/Lab 
  --metric-name CheckoutErrorRate --value 12 --unit None

aws cloudwatch describe-alarms 
  --alarm-names deh-lab-checkout-error-rate 
  --query 'MetricAlarms[0].StateValue'

Attendez ~1 min (ALARM). Mappez service=checkout-api dans l’alert source. Visez alerte ingérée + Workflow contexte (lien runbook), sans paging réel si pas de rotation lab.

Cleanup :

aws cloudwatch delete-alarms --alarm-names deh-lab-checkout-error-rate
aws sns delete-topic --topic-arn "$TOPIC_ARN"

Pas d’instance. Coût = put-metric + alarme.

Étape 7 — Postmortem, follow-ups, pont SRE

La timeline alimente le postmortem. Chaque cause → follow-up (owner, due) : runbook manquant, seuil idiot, Catalog vide, paging trop large.

1. Le runbook Git était-il le bon et à jour ?
2. Le Catalog a-t-il page la bonne équipe du premier coup ?
3. Error budget brûlé ? → WOW 28 SLO

« Blameless » ≠ zéro action. On attaque le système (seuils, Catalog, golden path), pas la personne.

Erreurs fréquentes

Erreur	Impact	Correction
Runbook seulement dans incident.io	Divergence, pas de PR	Git = source, Catalog = lien
Workflow restart prod	Outage amplifié	Read-only + humain
Catalog « plus tard »	Paging générique	10 services d’abord
Alerte sans service / env	Pas de matching	Dimensions / labels
Region us-east-1 par habitude	Lab incohérent	Forcer ca-central-1
Secrets dans le canal	Fuite	Redact, Vault/SSM
Pas de cleanup lab	Alarmes zombies	delete-alarms + delete-topic

Quiz (5 questions)

1. Un runbook qui « marche » en incident, c’est surtout :
– A. Un PDF RH
– B. Le contrat d’exécution (preuves, ordre, rollback) collé dans le fil
– C. Un bot kubectl apply sans garde-fou

2. Le Catalog incident.io sert à :
– A. Remplacer Git
– B. Relier services, owners, runbooks, dashboards pour les Workflows
– C. Stocker les secrets AWS

3. Region lab DEH imposée :
– A. us-east-1
– B. ca-central-1
– C. eu-west-3

4. Action Workflow interdite par défaut ici :
– A. Pinner le runbook Git
– B. Remédiation destructive auto (restart / apply prod)
– C. Page l’équipe Catalog

5. Source de vérité du texte du runbook :
– A. Le message Slack du 12 mars
– B. Le Markdown versionné dans Git
– C. Un screenshot Confluence

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

FAQ

incident.io remplace PagerDuty ?

Pas forcément. Certains migrent paging + Response. D’autres gardent PagerDuty, importent services/schedules dans le Catalog, et choisissent quoi pager où.

Faut-il Backstage d’abord ?

Non. 10 fiches Catalog + 3 runbooks Git suffisent. Backstage aide quand le volume explose — WOW Backstage.

Générer les runbooks avec ChatGPT ?

Oui pour brouillon / revue, logs redactés, human-in-the-loop. Pas d’exécution prod. Voir ChatGPT runbooks.

Pourquoi ca-central-1 ?

Standard lab DevOps Elastic Hayway : IAM, alarmes et tutos comparables.

SNS suffit-il pour déclencher incident.io ?

SNS est le pont AWS. Il faut une alert source (HTTPS, email-to-alert, ou intégration native). Le lab prouve l’alarme ; le mapping labels → Catalog se fait dans le produit.

Combien de Workflows au jour 1 ?

Deux : contexte (runbook + dashboard) et paging Sev-1/2. Trop de branches = toil.

Pour aller plus loin

• SRE : error budgets et SLOs (WOW 28) · ChatGPT runbooks · Step Functions SRE
• CloudWatch alarmes · OpenTelemetry · Backstage IDP · E-books

Maillage série WOW

← Précédent	Grafana Loki Tempo
→ Suivant	SRE : error budgets et SLOs
Aussi	ChatGPT runbooks · Step Functions SRE · CloudWatch · Backstage

---

Meta publication (SEO)

• Title SEO : Incident.io runbooks : incident management qui marche (guide FR)
• Meta description : Incident management 2026 avec incident.io : Catalog, Workflows, runbooks Git et lab CloudWatch/SNS en ca-central-1. FAQ, quiz, check-list DEH.
• Focus keyword : incident.io runbooks
• Secondary : incident management, runbooks SRE, Catalog incident.io
• Image : assets/web/devopelastichayway/cover-wow-incident-io-runbooks-1200x630.webp
• Catégorie : WOW / SRE · URL : https://devopelastichayway.com/tutoriels/wow-incident-io-runbooks/
• Publish : HOLD (WP-CLI feu vert Maître)