Gestion des incidents pour les équipes haute vélocité
Post-mortems d'incident publics et privés
Connaître le bon moment pour partager une explication post-incident publique
Il fut un temps où presque tous les incidents informatiques se limitaient à l'organisation dans laquelle ils se produisaient. Mais aujourd'hui, avec les services web et l'infrastructure cloud, c'est rarement le cas. Les incidents technologiques constituent un véritable problème « un à plusieurs » qui a entraîné un changement important dans la façon dont les équipes réagissent, apprennent et communiquent à propos des incidents.
Examinons le post-mortem d'incident (souvent appelé « revue post-incident » ou « PIR »).
Un post-mortem d'incident rassemble les personnes pour évoquer les détails d'un incident : pourquoi il s'est produit, son impact, quelles actions ont été entreprises pour l'atténuer et le résoudre, et les actions à entreprendre pour éviter qu'un tel incident ne se reproduise.
Un post-mortem d'incident peut être divisé en deux artefacts distincts : la réunion qui a l'incident pour objet et le rapport post-mortem correspondant créé suite à cette réunion.
Ces deux activités, la réunion et le rapport, sont souvent utilisées de façon interchangeable lorsqu'il est question de « post-mortem ». Les employés peuvent parler de l'une ou de l'autre, ou des deux, lorsqu'ils utilisent le terme.
Les partenaires, les clients et les utilisateurs finaux peuvent également vouloir savoir ce qui s'est passé et quelles mesures vous avez prises pour améliorer leur expérience. La mise en ligne de votre post-mortem d'incident sur votre site web public n'est pas toujours appropriée. Cependant, vos équipes marketing ou relations publiques peuvent vous aider à tourner vos phrases. Ainsi, les personnes obtiennent les informations de manière informative et la confiance dans vos services est renforcée.
Quand exécuter un post-mortem d'incident ?
Chez Atlassian, nous effectuons toujours des post-mortems internes pour les incidents (« majeurs ») de gravité 1 et 2. Pour les incidents mineurs, ils sont facultatifs. Nous encourageons les employés à utiliser le processus de post-mortem pour toute situation où il serait utile.
Qui réalise un post-mortem ?
Habituellement, l'équipe qui fournit le service à l'origine de l'incident est responsable de la réalisation du post-mortem associé. Elle nomme une personne responsable de cette dernière, qui se verra assigner le problème. Elle est le « propriétaire du post-mortem » et gère ce dernier de sa rédaction et de son approbation, jusqu'à sa publication. Les incidents au niveau de l'infrastructure et de la plateforme ont souvent un impact sur une partie représentative de l'entreprise, rendant les post-mortems plus complexes et intensifs. Pour cette raison, nous demandons parfois à un responsable de programme dédié de posséder des post-mortems au niveau de l'infrastructure ou de la plateforme, parce que les employés concernés sont mieux placés pour travailler dans les groupes et qu'ils sont en mesure de fournir les efforts nécessaires.
Partage d'un rapport post-mortem interne
Une fois le post-mortem approuvé, nous pouvons multiplier sa valeur en partageant ce que nous avons appris avec l'ensemble de l'entreprise. Pour ce faire, Atlassian a implémenté une action d'automatisation qui crée un brouillon de billet de blog dans Confluence lorsque le ticket de post-mortem est approuvé.
Création d'un rapport post-mortem public
Bien que ce soit moins courant, il s'avère souvent judicieux de publier une version publique d'un post-mortem après un incident.
Cette publication est particulièrement fréquente pour les services aux consommateurs à grande échelle qui rencontrent des pannes affectant de nombreux utilisateurs. Le plus souvent, ces équipes publient une version abrégée du rapport interne, plutôt que le rapport interne complet. Il est important d'effacer toute information privée ou sensible.
Partage d'un rapport post-mortem public
Il est parfois difficile de déterminer le bon canal pour publier un post-mortem public. Certaines équipes le publient directement sur votre blog d'entreprise ou sur votre site web. D'autres équipes disposent d'un blog d'ingénierie distinct adapté à la publication d'un post-mortem.
Dans notre produit Statuspage, les utilisateurs peuvent publier un post-mortem public directement sur leur page d'état après la résolution d'un incident.
Découvrez la communication sur les incidents grâce à Statuspage
Dans ce tutoriel, nous allons vous montrer comment utiliser des modèles d'incident pour communiquer efficacement pendant les pannes. Vous pouvez les adapter à de nombreux types d'interruption de service.
Lire ce tutorielEn quoi un processus de post-mortem d'incident est-il important ?
Un post-mortem d'incident, également appelé revue post-incident, est le meilleur moyen de travailler sur ce qui s'est passé lors d'un incident et de consigner les leçons apprises.
Lire cet article