Les sept phases d'une réponse efficace aux incidents

Détecter l'incident

Dans l'idéal, les outils de surveillance et d'alerte détecteront et informeront votre équipe d'un incident avant même que vos clients ne le remarquent. Il peut toutefois arriver que vous découvriez d'abord un incident sur Twitter ou dans des tickets de support client.

Quelle que soit la façon dont l'incident est détecté, la première étape pour vous doit être de consigner la création d'un incident dans un outil de suivi des incidents. Dans une solution de gestion des incidents telle que Jira Service Management, les alertes et la communication sont intégrées à votre outil de suivi.

Configurer les canaux de communication de l'équipe

L'une des premières choses que fait le gestionnaire d'incident (IM) lorsqu'il se connecte est de mettre en place les canaux de communication de l'équipe chargée des incidents. L'objectif à ce stade est d'établir et de rassembler toutes les communications des équipes en cas d'incident dans des endroits bien identifiés, par exemple :

• Groupe de discussion dans Slack ou un autre service de messagerie
• Chat vidéo dans une app de conférence comme Zoom (ou si vous êtes tous au même endroit, rassemblez l'équipe dans une salle physique)

Nous préférons utiliser à la fois le chat vidéo et un outil de chat texte pendant les incidents, car les deux excellent à des fins différentes. Le chat vidéo est idéal pour créer rapidement une image mentale partagée de l'incident par le biais de discussions de groupe. Et Slack permet de générer un enregistrement horodaté de l'incident, et de collecter des liens vers des captures d'écran, des URL et des tableaux de bord.

Slack et la plupart des autres outils de chat permettent aux utilisateurs de définir un sujet de groupe. Le gestionnaire d'incident doit utiliser ce champ pour obtenir des informations sur l'incident ainsi que des liens utiles.

Enfin, le gestionnaire d'incident définit son propre état dans le chat en fonction de la clé du ticket de l'incident qu'il gère. Cela permet à ses collègues de savoir qu'il est occupé à gérer un incident.

Évaluer l'impact et appliquer un niveau de gravité

Une fois les canaux de communication de l'équipe chargée des incidents configurés, il est temps d'évaluer l'incident afin que l'équipe puisse décider de ce qu'il faut en dire et de qui doit le résoudre.

Nous utilisons la série de questions suivantes que les responsables des incidents doivent poser à leurs équipes :

• Quel est l'impact pour les clients (internes ou externes) ?
• Que voient les clients ?
• Combien de clients sont concernés (certains, tous) ?
• Quand l'incident a-t-il commencé ?
• Combien de cas de support les clients ont-ils ouverts ?
• Y a-t-il d'autres facteurs (par ex. Twitter, sécurité ou perte de données) ?

L'étape suivante consiste généralement à assigner un niveau de gravité.

Niveaux de gravité de la réponse aux incidents

Gravité 1
Description : incident critique ayant un impact très élevé
Exemples :

• Un service orienté client est indisponible pour tous les clients
• Violation de la confidentialité
• Perte de données client

Gravité 2
Un incident majeur ayant un impact significatif
Exemples :

• Un service orienté client est indisponible pour certains clients, mais pas pour tous.
• Une fonctionnalité principale est considérablement affectée.

Gravité 3
Un incident mineur ayant un faible impact
Exemples :

• Un inconvénient mineur pour les clients, solution de contournement disponible.
• Dégradation des performances utilisables.

Utiliser un système de numérotation pour les niveaux de gravité permet de définir et de communiquer rapidement l'incident. Il suffit que quelqu'un dise « nous avons peut-être un incident de gravité 1 », et les bonnes personnes peuvent immédiatement comprendre la gravité avant même d'obtenir des informations supplémentaires.

Les niveaux de gravité peuvent également aider à élaborer des directives pour les attentes en matière de réponse.

Dans certaines entreprises, par exemple, les incidents de gravité 3 peuvent être traités pendant les heures ouvrables, tandis que les incidents de gravité 1 et 2 nécessitent d'appeler des membres de l'équipe pour une correction immédiate.

Les définitions de gravité des incidents doivent être documentées et homogènes dans l'ensemble de l'organisation.

Communiquez avec les clients

Lorsqu'une équipe a établi que l'incident était réel, vous devez le communiquer en interne et en externe dès que possible.

L'objectif de la communication interne est de concentrer la réponse aux incidents et de réduire la confusion.

L'objectif de la communication externe est d'indiquer aux clients que l'équipe a été informée d'une défaillance et que vous la traitez en urgence. Communiquer rapidement et avec précision aide à établir la confiance avec vos clients et le reste de votre organisation.

De nombreuses équipes utilisent Statuspage pour la communication sur les incidents à la fois en interne et en externe. Voici deux modèles simples pour mettre à jour une page d'état interne ou externe :

Page d'état interne
- -

Nous enquêtons sur un incident affectant , et . Nous fournirons des mises à jour par e-mail et sur Statuspage sous peu.

Page d'état externe
Examen de problèmes avec

Nous étudions des problèmes avec et fournirons prochainement des mises à jour ici.

Faire remonter aux bons intervenants

Parfois, les premiers intervenants sont ceux qui résolvent l'incident. Mais le plus souvent, ces intervenants doivent impliquer d'autres équipes dans l'incident en les appelant à l'aide d'un outil d'alerte. Grâce à Jira Service Management, les intervenants peuvent choisir la méthode d'alerte qu'ils utilisent, voire les utiliser toutes au même endroit.

Les outils d'alerte permettent aux équipes de définir des services d'astreinte afin de faire tourner le personnel qui doit être joignable lors d'un incident. Cela vaut mieux que de compter sur une personne spécifique chaque fois qu'un incident survient. Cette personne ne sera pas toujours disponible (elle peut prendre des vacances, changer d'emploi ou faire un burn-out à force d'être sans cesse appelée).

Déléguer les rôles de réponse aux incidents

Lorsqu'un nouvel intervenant est appelé pour un incident et se connecte, le gestionnaire d'incident lui délègue un rôle. Il est important que l'intervenant comprenne alors ce qui est requis de son rôle, et comment aider rapidement et efficacement l'équipe chargée de l'incident.

La définition des rôles présente un autre avantage : elle permet plus d'adaptabilité et de flexibilité. Tant qu'une personne sait jouer un certain rôle, elle peut jouer ce rôle pour tout incident.

Trois rôles clés de réponse aux incidents

Responsable des incidents

Chaque incident est géré par le gestionnaire d'incident, qui est globalement responsable et dispose de toute autorité pour l'incident.

Le gestionnaire d'incident est habilité à prendre toutes les mesures nécessaires pour résoudre l'incident, notamment appeler toute personne au sein de l'organisation et veiller à ce que les personnes impliquées dans un incident restent concentrées sur la restauration du service le plus rapidement possible.

Responsable technique

Un intervenant technique expérimenté. Il est chargé de développer des théories sur les défaillances et leurs causes, de décider des changements et de piloter l'équipe technique. Il travaille en étroite collaboration avec le gestionnaire d'incident.

Responsable des communications

Une personne expérimentée en matière de communications publiques, éventuellement issue de l'équipe de support client ou des relations publiques. Le responsable des communications est chargé de la rédaction et de l'envoi des communications internes et externes sur l'incident.

Résoudre l'incident

Il n'existe pas de processus unique pour résoudre tous les incidents : si c'était le cas, nous l'automatiserions simplement et c'en serait fini. À la place, inspirez-vous de la méthode scientifique. Itérez sur le processus suivant pour vous adapter rapidement à divers scénarios de réponse aux incidents :

• Observez ce qui se passe. Partagez et vérifiez vos observations.
• Développez des théories relatives aux motifs de l'incident.
• Développez et réalisez des expériences pour prouver ou réfuter vos théories.
• Répétez jusqu'à ce que l'incident soit résolu.

Un incident est résolu lorsque l'impact sur l'activité actuelle ou imminente disparaît. À ce stade, la réponse d'urgence prend fin, et l'équipe passe à toutes les tâches de nettoyage et au post-mortem.

Nous envoyons des communications internes et externes finales lorsque l'incident est résolu. Les communications internes récapitulent l'impact et la durée de l'incident, y compris le nombre de dossiers de support créés et d'autres aspects importants de l'incident. En outre, elles indiquent clairement que l'incident est résolu et qu'aucune communication ultérieure ne sera faite sur le sujet. Les communications externes sont généralement brèves, indiquant aux clients que le service a été rétabli et que nous allons réaliser un post-mortem.

Conclusion

Le processus de réponse aux incidents implique de nombreuses composantes mobiles. Vous souhaitez garder une trace de chaque étape grâce à une communication fluide ? Rien de plus facile avec une solution de gestion des incidents comme Jira Service Management. Centralisez les alertes et unifiez les équipes de manière flexible pour résoudre les incidents rapidement.