Communication opérationnelle¶

Statuspage, communication de crise, ChatOps et rapports d'exploitation.

La communication pendant un incident¶

La résolution technique d'un incident n'est que la moitie du travail. Une mauvaise communication peut transformer un incident de severity 3 en crise de confiance avec les utilisateurs ou le management.

Flux de communication pendant un incident¶

sequenceDiagram
    participant Sys as Systeme
    participant Resp as Responsable incident
    participant SP as Statuspage
    participant Chat as Canal incident
    participant Stake as Parties prenantes

    Sys->>Resp: Alerte detectee
    Resp->>Chat: Ouverture canal incident
    Resp->>SP: Premiere mise a jour (< 10 min)
    Resp->>Stake: Notification initiale
    loop Toutes les 30 min
        Resp->>SP: Mise a jour statut
        Resp->>Chat: Update technique interne
    end
    Resp->>SP: Resolution + resume
    Resp->>Stake: Message cloture
    Resp->>Chat: Fermeture canal, lien postmortem

Statuspage¶

La statuspage est la façade publique de votre état opérationnel. Elle permet aux utilisateurs de suivre les incidents sans inonder le support.

Quand mettre à jour la statuspage¶

• Immédiatement (< 10 min) : des qu'un impact utilisateur est confirme
• Régulièrement : toutes les 30 minutes minimum pendant un incident actif
• À la résolution : message de clôture avec résumé et prochaines étapes si pertinent

Templates par sévérité¶

Transparence vs panique¶

La transparence est preferable à l'opacite, mais le message doit rester factuel et orient solution :

• Factuel : ce qui est impacte, ce qui fonctionne encore
• Orienté solution : "nous travaillons à la résolution", pas "tout est casse"
• Sans speculations techniques : les utilisateurs n'ont pas besoin du root cause en temps réel

Outils statuspage¶

Communication de crise¶

La première annonce¶

La première annonce doit arriver vite, même si elle contient peu d'informations. Le silence est pire que l'incertitude.

Structure : Quoi (symptome, pas cause) | Impact (qui, quoi) | Statut (en cours d'investigation) | Prochaine MAJ (heure precise)

Mises à jour régulières¶

Même si rien n'a change techniquement, une mise à jour "nous continuons d'investiguer, prochaine MAJ dans 30 min" est indispensable. Elle signale que l'incident est pris en charge.

Message de résolution¶

• Confirmer la résolution et l'heure
• Décrire brievement ce qui s'est passe (sans blame)
• Indiquer les mesures preventives prévues
• Mentionner le postmortem a venir si pertinent

Canaux dédiés et war rooms¶

Séparation signal / bruit¶

• Un canal général #ops-alerts pour toutes les alertes (bruit acceptable)
• Un canal par incident #inc-20240315-database créé dynamiquement (signal pur)
• Le canal incident est archive après clôture, lien vers postmortem en description

War room¶

La war room est la réunion de crise synchrone (vocal ou video) pour les incidents majeurs :

• Convocation immédiate : responsable incident, tech lead, potentiellement product owner
• Scribe désigné : documente le timeline en temps réel
• Responsable communication : géré les parties prenantes externes pendant que les tech résolvent
• Durée max avant pause délibérée : 90 minutes (fatigue cognitive)

ChatOps¶

Le ChatOps consiste à déclencher des opérations depuis le canal de chat, rendant les actions visibles et tracables par toute l'équipe.

Opérations courantes en ChatOps¶

Intégration monitoring¶

Les bots ChatOps peuvent poster automatiquement dans le bon canal :

• Alertes Grafana avec lien direct vers le dashboard
• Notifications de déploiement depuis CI/CD
• Mises à jour de tickets incidents

Rapports d'exploitation¶

Rapport hebdomadaire¶

Contenu type : nombre d'incidents par sévérité, MTTR moyen, top 3 des alertes les plus fréquentes, déploiements effectues, toil mesure.

Rapport mensuel¶

Contenu type : tendances SLO (consommation error budget), incidents significatifs avec liens postmortems, avancement des actions correctives, métriques on-call (pages/semaine, interventions nocturnes), roadmap fiabilité.