Close

La voie vers une meilleure gestion des incidents
débute ici

Créer de meilleures chronologies d'incident (et pourquoi elles sont importantes)

La gestion des incidents se complexifie parallèlement à la technologie, à la documentation et à la communication.

C'est pourquoi de plus en plus d'entreprises adoptent des chronologies d'incidents, un flux d'activité d'incident centralisé conçu pour garder les équipes en phase pendant un incident et fournir un enregistrement que ces mêmes équipes peuvent utiliser après l'incident pour identifier les causes profondes et améliorer les performances futures.

Qu'est-ce qu'une chronologie d'incident ?

Une chronologie d'incident est un enregistrement complet en temps réel d'un incident. Il inclut souvent des entrées manuelles (chat), des enregistrements consolidés des pages, des alertes et des accusés de réception, ainsi que des mises à jour automatiques du système (par exemple, la notification indiquant que quelqu'un a modifié le niveau de gravité d'un incident ou l'a marqué comme résolu). Il est également souvent synchronisé avec le chat ou un canal Slack.

La chronologie est là pour garder l'équipe en phase, permettre aux nouveaux membres de l'équipe de se mettre à jour rapidement et simplifier le processus de post-mortems d'incident.

« Donnez-moi une liste de tous les changements apportés au cours des, disons, trois derniers jours. Sans une chronologie précise, nous ne serons pas en mesure d'établir le lien de cause à effet, et nous finirons probablement par provoquer une autre panne. »

— Tiré du livre « The Phoenix Project »,
Gene Kim, Kevin Behr, George Spafford

Valeur d'une chronologie d'incident

Une vue unique en temps réel

Le manque de communication entre les équipes ou les parties prenantes est l'un des principaux facteurs pour qu'un incident échappe rapidement à tout contrôle. Une chronologie d'incident atténue ce risque en fournissant à tout le monde les mêmes informations dans une seule vue en temps réel. Autrement dit, tout le monde, des développeurs travaillant sur l'incident à l'équipe de communication responsable de la mise à jour des parties prenantes (des utilisateurs aux directeurs), peut se tenir informé sans avoir à recouper les informations d'innombrables appels téléphoniques, threads d'e-mails et chats.

La vue unique en temps réel permet également aux parties prenantes d'identifier plus facilement non seulement le problème central de l'incident, mais aussi les risques et les problèmes potentiels dans les systèmes interconnectés. En donnant à plusieurs équipes l'accès à une chronologie, il est plus facile d'identifier les problèmes, causes ou risques potentiels dans des systèmes interconnectés.

Des post-mortems d'incident plus robustes

Chez Atlassian, les post-mortems d'incident constituent un élément essentiel de nos processus de gestion des incidents et des problèmes. Ils rassemblent les gens pour comprendre ce qui s'est passé, pourquoi et ce que nous pouvons faire pour éviter une nouvelle occurrence du problème à l'avenir. Pour aller au fond de ces questions, il est utile de disposer d'un enregistrement détaillé de tout ce qui s'est passé pendant un incident, des alertes aux mises à jour des parties prenantes jusqu'à la correction finale.

Pour de nombreuses entreprises, la chronologie des incidents fait office d'enregistrement détaillé. Il ne s'agit pas seulement d'un outil de collaboration en temps réel sur les incidents, mais également d'une vue unique de ce qui s'est passé, quand, et parfois pourquoi ; des informations qui peuvent faire gagner des heures aux équipes pendant la phase d'examen post-mortem.

Aller plus loin dans les KPI

Une chronologie d'incident aide souvent les équipes à étudier un incident en profondeur, mais son utilité ne s'arrête pas là. Elle peut également être utilisée parallèlement à des chronologies d'incidents similaires afin d'aider les équipes à repérer des tendances et à diagnostiquer des problèmes plus importants avec des KPI importants.

Si la résolution d'un incident a nécessité plus de temps que la moyenne, où étaient les points de défaillance ? En quoi cela correspond-il à d'autres incidents similaires ? Quelles sont les parties du processus qui nécessitent un examen plus approfondi ? Une tendance susceptible d'entraîner un problème plus important en ce qui concerne les processus, la technologie ou la configuration d'équipe se dessine-t-elle ? Les alertes sont-elles émises au besoin ou devons-nous revoir nos seuils d'alerte ? Le planning d'astreinte fournit-il une couverture suffisante des incidents ? Nos équipes sont-elles structurées de la bonne façon ?

Une chronologie peut servir de point de données unique pour l'examen ou l'un des nombreux points de données d'une enquête sur les problèmes liés aux SLA et aux SLO.

Chronologies d'incident et ChatOps

Les chronologies d'incidents sont généralement fournies par les systèmes de gestion des incidents comme Opsgenie afin de centraliser toutes les informations sur les incidents.

ChatOps pour la gestion des incidents a le même objectif. Seule différence : au lieu d'être hébergé dans un système de gestion des incidents, ChatOps centralise généralement la chronologie dans un programme de chat comme Slack, qui se synchronise avec les plateformes de gestion des incidents comme Opsgenie et d'autres sources pertinentes (et récupère les informations qu'elles contiennent).

Les avantages de ChatOps (accès aux mêmes informations entre les équipes, conversations et mises à jour en temps réel, moins de changements contextuels, plus besoin d'innombrables appels téléphoniques, et enregistrement intégré pour les post-mortems) sont identiques à ceux d'une chronologie d'incident. La différence fondamentale est simplement l'emplacement et la quantité d'informations. Pour la plupart des équipes chargées des incidents, les informations importantes sont généralement masquées par de nombreuses interférences dans le flux ChatOps. Il est utile d'intégrer des informations riches dans votre chronologie d'incident, tout en conservant le journal de discussion pour référence ultérieure si vous en avez besoin.

suivant
5 whys