Répondre à un incident

Détecter

Les employés de votre entreprise peuvent prendre conscience des incidents de plusieurs manières. Ils peuvent être alertés par un dispositif de surveillance, par des rapports client ou via une observation directe. Même si un incident se produit, la première mesure prise par l'équipe consiste à enregistrer un ticket d'incident (dans notre cas, un ticket Jira).

Créer un nouvel incident

Lorsque le ticket de l'incident a été créé, mais n'a pas encore été assigné à un responsable d'incident, l'incident est à l'état Nouveau. Il s'agit de l'état initial dans notre workflow d'incidents Jira.

Nous disposons d'un service qui utilise les webhooks de Jira pour déclencher une alerte de page lorsqu'un nouvel incident majeur est créé. Ceci alerte un responsable d'incident d'astreinte pour le service sélectionné. Par exemple, un incident avec Bitbucket appellera un responsable des incidents Bitbucket. Nous avons également un fichier global de responsables de la gestion des incidents majeurs (MIM) sous le nom de « responsable des incidents d'astreinte ».

L'alerte de page inclut l'identifiant du ticket, la gravité et le résumé de l'incident, qui indique au responsable de l'incident où aller pour commencer à gérer l'incident (ticket Jira), quel est généralement le problème et quelle est sa gravité.

Communications Open

La première chose que fait le gestionnaire d'incident lorsqu'il se connecte est de s'auto-assigner le ticket et de le passer à l'état En cours de correction. Le champ Responsable du ticket Jira affiche également l'identité du gestionnaire d'incident actuel. Dans une intervention d'urgence, il est très important de savoir clairement qui est responsable. Nous devons donc veiller à ce que ce champ soit exact.

Ensuite, le responsable de l'incident configure les canaux de communication de l'équipe chargée de l'incident. L'objectif à ce stade est d'établir et de concentrer toutes les communications des équipes en cas d'incident dans des endroits connus. Nous utilisons normalement trois méthodes de communication en équipe, chacune étant représentée par un champ sur le ticket Jira, pour chaque incident :

• Groupe de discussion dans Slack ou un autre service de messagerie. Il permet à l'équipe de communiquer, de partager des observations, des liens et des captures d'écran de manière horodatée et préservée. Donner le même nom au canal de chat que l'identifiant du ticket (par exemple, HOT-1234) permet plus facilement aux personnes concernées de participer à la conversation.
• Tchat vidéo dans une application de conférence comme Skype, Blue Jeans ou similaire ; ou si vous êtes tous au même endroit, rassemblez l'équipe dans une salle physique. Nous trouvons que la communication en face à face aide les équipes à gérer les tâches plus rapidement et avec moins de va-et-vient.
• Une page Confluence a appelé le « document d'état de l'incident ». Lorsque des personnes modifient simultanément la même page, elles peuvent voir quelles informations sont collectées en temps réel. C'est un excellent moyen de suivre les changements (par exemple, un tableau indiquant qui a changé quoi, quand, comment, pourquoi, comment annuler, etc.), plusieurs workflows ou un calendrier plus long. Un document d'état d'incident est extrêmement utile comme source de vérité lors d'incidents complexes ou prolongés.

Nous avons constaté que l'utilisation du tchat vidéo et du groupe de discussion était plus efficace lors d'un incident, car les deux sont optimisés pour différentes choses. Le tchat vidéo permet de créer rapidement une image mentale partagée de l'incident par le biais de discussions de groupe, tandis que le groupe de discussion est idéal pour conserver un enregistrement horodaté de l'incident, des liens partagés vers des tableaux de bord, des captures d'écran et d'autres URL.

Ces méthodes peuvent également être utilisées pour enregistrer des observations importantes, des changements et des décisions qui se produisent dans des conversations non enregistrées. Pour ce faire, le gestionnaire d'incident ou toute autre personne de l'équipe consigne simplement, en temps réel, les observations, les changements et les décisions dans le groupe de discussion dédié. Ce n'est pas grave si les gens semblent se parler à eux-mêmes ! Ces remarques sont extrêmement utiles pendant le post-mortem lorsque les équipes doivent reconstituer la chronologie de l'incident et déterminer sa cause.

La plupart des systèmes de groupe de discussion ont une fonctionnalité de sujet du groupe. Le responsable de l'incident met à jour le sujet du groupe avec des informations sur l'incident et des liens utiles, entre autres :

• Le résumé et la gravité de l'incident.
• Qui occupe quel rôle, en commençant par le responsable de l'incident.
• Renvoie vers le ticket de l'incident, la salle de tchat vidéo et le document d'état de l'incident.

Cela permet à toute personne disposant de l'identifiant du ticket de l'incident de rejoindre le tchat et de se mettre au courant de l'incident (rappelez-vous que nous avons nommé le groupe de discussion en fonction de l'identifiant du ticket de l'incident, par exemple, HOT-1234).

Enfin, le gestionnaire d'incident définit son propre état dans le chat en fonction de l'identifiant 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

Une fois les canaux de communication de l'équipe chargée des incidents configurés, le moment est venu 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 gestionnaires d'incident 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) ?

Il est à présent temps de commencer à compléter la chronologie de l'incident. Enregistrez les observations de l'équipe pour que les personnes qui rejoignent la discussion puissent se mettre rapidement au courant. Ceci sera également important plus tard dans le processus du post-mortem. Vérifiez bien si l'heure de début de l'incident correspond à un changement (par exemple, un déploiement Bamboo) afin que les changements puissent être annulés afin de résoudre potentiellement l'incident.

En fonction de l'impact de l'incident et de la quantité de travail que nos équipes estiment nécessaire pour résoudre le ticket, nous assignons l'un des niveaux de gravité suivants aux tickets :

Envoi de communications initiales

Lorsque vous êtes raisonnablement sûr que l'incident est réel, vous devez le communiquer en interne et en externe dès que possible. L'objectif de la communication interne initiale 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 vous êtes conscients d'une défaillance et que vous la traitez en urgence. Communiquer rapidement et avec précision sur les incidents aide à établir la confiance avec votre personnel et vos clients.

Nous utilisons Statuspage pour les communications relatives aux incidents, à la fois en interne et en externe. Nous avons des pages d'état distinctes pour le personnel interne de l'entreprise et les clients externes. Nous parlerons plus en détail de la manière de les utiliser ultérieurement, mais pour le moment, l'objectif est de communiquer le plus rapidement possible. Pour cela, nous utilisons les modèles suivants :

Faire remonter

Vous vous êtes chargé de la gestion de l'incident, vous avez établi des communications avec l'équipe, évalué la situation et dit au personnel et aux clients qu'un incident était en cours. Que devez-vous faire ensuite ?

Vos premiers intervenants peuvent être les seules personnes dont vous avez besoin pour résoudre l'incident, mais bien souvent, vous devez impliquer d'autres équipes dans l'incident en les appelant. Nous appelons ce processus Remontée.

Le système principal dans cette étape est un outil d'alerte et d'inscription de page comme OpsGenie. OpsGenie et les systèmes similaires vous permettent de définir des listes d'appels de sorte qu'une rotation de personnel soit mise en place pour chaque équipe et que ses membres puissent être contactés pour répondre en cas d'urgence. Cette méthode est préférable à compter à tout moment sur des individus spécifiques (« Rappelez Bob »), car les personnes ne seront pas toujours disponibles (elles ont tendance à partir en vacances de temps en temps, à changer d'emploi ou à s'épuiser quand on les appelle trop). Elle est également supérieure aux « meilleurs efforts » des groupes d'astreinte, car elle détermine clairement qui est chargé de répondre.

Indiquez toujours l'identifiant du ticket Jira d'un incident dans une alerte de page concernant cet incident. C'est l'identifiant que la personne recevant l'alerte utilise pour rejoindre le groupe de discussion relatif à l'incident.

Déléguer

Lorsque vous avez fait remonter le ticket à une personne et qu'elle se connecte, le responsable de l'incident lui délègue un rôle. Tant qu'elle comprend ce qui est attendu d'elle, elle pourra travailler rapidement et efficacement au sein de l'équipe chargée des incidents.

Les rôles que nous utilisons chez Atlassian sont les suivants :

• Gestionnaire d'incident, décrit dans la page Présentation.
• Responsable technique, un intervenant technique senior. Il est chargé de développer des théories sur les défaillances et leurs causes, de décider des changements et de diriger l'équipe technique. Il travaille en étroite collaboration avec le responsable de l'incident.
• Responsable des communications, une personne expérimentée en matière de communications publiques, éventuellement issue l'équipe de support client ou des relations publiques. Il est chargé de la rédaction et de l'envoi des communications internes et externes sur l'incident.

Nous utilisons le sujet du groupe de discussion pour indiquer qui occupe actuellement quel rôle, et nous le mettons à jour si les rôles changent au cours d'un incident.

Le responsable de l'incident peut également créer et déléguer des rôles selon les besoins de l'incident, par exemple, plusieurs responsables techniques si plusieurs workflows sont en cours ou des responsables distincts pour les communications internes et externes.

Dans le cas d'incidents complexes ou de grande ampleur, il est conseillé de faire appel à un autre responsable d'incident qualifié en guise de « vérificateur » de secours pour le responsable de l'incident. Il peut se concentrer sur des tâches spécifiques qui libèrent le responsable de l'incident, notamment le contrôle de la chronologie.

Envoi de communications de suivi

Vous avez déjà envoyé des communications initiales, mais une fois que l'équipe chargée des incidents a commencé son travail, vous devez tenir le personnel et les clients informés au sujet de l'incident.

Il est essentiel de tenir le personnel interne informé, car cela crée une vérité commune et cohérente sur l'incident. Lorsque quelque chose se passe mal, les informations sont rares, en particulier aux premiers stades, et si vous n'établissez pas une source d'information fiable sur ce qui s'est passé et sur la réponse apportée, les gens ont tendance à tirer leurs propres conclusions.

Pour les communications internes, nous suivons le modèle suivant :

• Nous communiquons via notre Statuspage interne et par e-mail, comme décrit dans la section « Communications initiales » ci-dessus.
• Utilisez la même convention pour le format du nom de l'incident et de l'objet des e-mails ( - - )
• Commencez par un résumé d'une à deux phrases de l'état actuel et de l'impact.
• Une section « État actuel » avec une liste à puces contenant deux à quatre points.
• Une section « Prochaines étapes » avec une liste à puces contenant deux à quatre points.
• Indiquez quand et par quel biais les prochaines communications seront envoyées.

Nous utilisons cette checklist pour passer en revue les communications afin d'en vérifier l'exhaustivité :

• Quel est l'impact actuel sur les clients ?
• Combien de clients internes et externes sont affectés ?
• La cause profonde est-elle connue ? De quoi s'agit-il ?
• Disposons-nous d'une date approximative de restauration ? Quelle est-elle ?
• Quand et où se fera la prochaine mise à jour ?

Nous encourageons nos responsables des incidents à indiquer clairement les inconnues dans leurs communications internes. Cela permet de réduire l'incertitude. Par exemple, si vous ignorez encore quelle est la cause profonde, il est de loin préférable de dire « la cause profonde est à l'heure actuelle encore inconnue » plutôt que de ne pas en parler du tout.

Il est important de tenir les clients externes informés, car cela renforce la confiance. Même s'ils sont concernés, ils pourront avancer dans d'autres domaines tant qu'ils savent que vous les tiendrez informés.

Pour les communications externes, nous mettons simplement à jour l'incident que nous avons ouvert précédemment sur la Statuspage externe, modifiant son état si nécessaire. Nous essayons de fournir des mises à jour « brèves et concises », parce que les clients externes ne s'intéressent pas aux détails techniques d'un incident, ils veulent juste savoir s'il est déjà corrigé ou, si ce n'est pas le cas, quand il le sera. Généralement, un ou deux phrases suffiront.

Les communications relatives aux incidents sont un art, et plus vous pratiquez, mieux vous le maîtriserez. Dans notre formation destinée aux responsables des incidents, nous simulons une situation d'incident hypothétique pour lequel nous rédigeons des brouillons de communication que nous lisons au reste de la classe. C'est un bon moyen de développer cette compétence avant de l'utiliser en situation réelle. Il est également conseillé de demander à une autre personne de relire vos communications à titre de « deuxième avis » avant de les envoyer.

Révisez

Il n'existe pas de processus normatif unique pour résoudre tous les incidents : si c'était le cas, nous l'automatiserions simplement et c'en serait fini. À la place, nous itérons sur le processus suivant pour nous 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 causes de l'incident.
• Développez des expériences qui valideront ou invalideront ces théories. Réalisez ces expériences.
• Répétez la procédure.

Par exemple, vous pouvez observer un taux d'erreur élevé dans un service correspondant à une panne que votre fournisseur d'infrastructures régional a publiée sur sa Statuspage. Vous pourriez imaginer que la panne est isolée dans cette région, décider de basculer vers une autre région et observer les résultats.

Les plus grands défis pour le responsable de l'incident, à ce stade, concernent le maintien de la discipline de l'équipe :

• L'équipe communique-t-elle efficacement ?
• Quels sont les observations, théories et workflows actuels ?
• Notre prise de décisions est-elle efficace ?
• Les changements que nous apportons sont-ils intentionnels et réfléchis ? Savons-nous quels changements nous apportons ?
• Les rôles sont-ils clairement déterminés ? Tout le monde fait-il son travail ? Devons-nous faire remonter l'incident à davantage d'équipes ?

Quoi qu'il arrive, ne paniquez pas, cela n'aide pas. Restez calme et l'équipe réagira comme vous.

Le responsable de l'incident doit surveiller l'état de fatigue de l'équipe et prévoir les changements nécessaires. Une équipe dédiée risque de s'épuiser lors de la résolution d'incidents complexes. Les responsables des incidents doivent savoir depuis combien de temps les membres sont éveillés, depuis combien de temps ils travaillent, et doivent leur désigner des remplaçants.

Résolution

Un incident est résolu lorsque l'impact sur le business actuel ou imminent 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.

Les tâches de nettoyage peuvent être facilement liées et suivies sous forme de liens de ticket à partir du ticket Jira de l'incident.

Chez Atlassian, nous utilisons les champs personnalisés de Jira pour suivre l'heure de début de l'impact, l'heure de détection et l'heure de fin de l'impact d'un incident. Nous utilisons ces champs pour calculer le délai de reprise, qui est l'intervalle entre le début et la fin, et le temps de détection, qui est l'intervalle entre le début et la détection. La distribution des délais de reprise et des temps de détection de vos incidents est souvent un indicateur important pour votre entreprise.

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 cas de support créés et d'autres aspects importants de l'incident. En outre, il indique 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.

Pour découvrir comment Jira Service Management aide les équipes à exécuter chaque étape du processus de réponse (qu'il s'agisse de centraliser les alertes, d'organiser la communication sur les incidents, d'unifier les équipes pour améliorer la collaboration, ou encore de réaliser des post-mortems des incidents pour analyser leurs causes profondes), cliquez sur le bouton ci-dessous.