Fermez
Manuel de gestion des incidents Atlassian

Répondre à un incident

Caution alert exclamation point

Répondre à un incident

Les sections suivantes décrivent le processus de réponse aux incidents d'Atlassian. Le responsable de l'incident suit l'incident dans une série d'étapes allant de la détection à la résolution.

Workflow of Atlassian incident response from new to fixing to resolved
Book illustration with a light bulb over it

Présentation

Définition des incidents et des valeurs en matière d'incident. Connaissance des bons outils et des rôles de l'équipe.

Illustration of different kinds of charts

Post-mortems des incidents

Exécution d'un post-mortem sans reproche, identification des causes profondes et planification du travail de résolution

Détecter

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

Nous utilisons une URL courte facile à retenir qui redirige Atlassian vers un portail Jira Service Desk interne. Atlassian peut vérifier si un incident est déjà en cours en consultant un tableau de bord Jira ou une macro Jira dans Confluence. Des équipes telles que nos équipes de support client disposent de tableaux de bord installés sur des sites connus pour surveiller les incidents en cours.

Nous renseignons les champs suivants pour chaque incident :

Champ Jira

Type

Texte d'aide

Summary

Texte

Quelle est l'urgence ?

Description

Texte

Quel est l'impact sur les clients ? Incluez vos coordonnées pour que les intervenants puissent vous contacter.

Gravité

Sélection unique

(Lien hypertexte vers une page Confluence avec notre échelle de gravité) Sélectionner une gravité de 2 ou 1 signifie que vous croyez que le problème doit être résolu immédiatement (les personnes adéquates seront contactées).

Service défectueux

Sélection unique

Le service dont la panne provoque l'incident. En cas de doute, indiquez le service que vous soupçonnez. Sélectionnez « Inconnu » si vous n'en avez aucune idée.

Produits concernés

Cases à cocher

Quels produits sont concernés par cet incident ? Sélectionnez toutes les réponses qui s'appliquent.

Lorsque l'incident est créé, l'identifiant de son ticket est utilisé dans toutes les communications internes relatives à l'incident.

Les clients ouvriront souvent des cas de support au sujet d'un incident qui les affecte. Lorsque nos équipes de support client déterminent que ces cas sont tous liés à un incident, ils étiquettent ces cas avec l'identifiant du ticket de l'incident pour suivre l'impact sur le client et simplifier le suivi des clients affectés lors de la résolution de l'incident.

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 d'incident Bitbucket. Nous avons également un fichier global de responsables des incidents connus 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 responsable de l'incident lorsqu'il se connecte est de s'auto-attribuer le ticket et de le passer à l'état En cours de correction. Le champ Responsable du ticket Jira affiche également l'identité du responsable de l'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 groupe de discussion 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 responsable de l'incident ou toute autre personne de l'équipe enregistre 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 responsable de l'incident définit son propre état de conversation personnelle en fonction de l'identifiant du ticket de l'incident qu'il gère. Cela permet à leurs collègues de savoir qu'ils sont occupés à gérer un incident. 

Évaluer

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) ?

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 : 

Gravité

Description

Examples

1

Un incident critique à grand impact

  • Un service orienté client, comme Jira Cloud, est en panne pour tous les clients

  • La confidentialité ou la vie privée est violée.

  • Perte de données du client.


2

Un incident majeur sans impact significatif

  • Un service orienté client n'est pas disponible pour un sous-ensemble de clients

  • Une fonctionnalité principale (par exemple, git push, création de ticket) est considérablement affectée.

3

Un incident mineur avec un faible impact

  • Un inconvénient mineur pour les clients, solution de contournement disponible.

  • Dégradation des performances utilisables.

Une fois que vous avez déterminé l'impact de l'incident, ajustez ou confirmez la gravité du ticket d'incident et communiquez-le à l'équipe. Nous avons constaté que numéroter le niveau était très utile pour communiquer clairement la gravité.

Chez Atlassian, les incidents de gravité 3 sont transmis aux équipes de livraison pour résolution pendant les heures de bureau, tandis que les incidents de gravité 1 et 2 nécessitent l'appel de membres de l'équipe pour une correction immédiate. La différence de réponse entre la gravité 1 et 2 est plus nuancée et dépend du service concerné.

Votre matrice de gravité doit être documentée et convenue entre toutes vos équipes de sorte à fournir une réponse cohérente aux incidents en fonction de l'impact sur le client.

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 :

 

Statuspage interne

Statuspage externe

Nom de l'incident

<Identifiant du ticket de l'incident> - <Gravité> - <Résumé de l'incident>

Étude des tickets avec <produit>

Message

Nous étudions un incident affectant <produit x>, <produit y> et <produit z>. Nous fournirons des mises à jour par e-mail et la page Statuspage sous peu.

Nous étudions les tickets liés à <produit> et nous fournirons prochainement des mises à jour ici.

En plus de créer un incident Statuspage, nous envoyons un e-mail à une liste de diffusion des incidents, qui inclut notre direction technique, les principaux responsables des incidents et d'autres personnes intéressées. Le contenu de cet e-mail est identique à celui de la Statuspage interne de l'incident. L'e-mail permet au personnel de répondre et de poser des questions, tandis que la Statuspage est davantage une communication à sens unique.

Notez que nous incluons toujours l'identifiant du ticket Jira de l'incident dans toutes les communications internes relatives à l'incident, afin que le personnel sache quel groupe de discussion rejoindre pour toute question supplémentaire.

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 :

  • Responsable de l'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 à son sujet 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 (<Identifiant du ticket de l'incident> - <Gravité> - <Résumé de l'incident>)

  • 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 liste de contrôle 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 effectuons une itération 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 motifs 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.

Book illustration with a light bulb over it

Présentation

Définition des incidents et des valeurs en matière d'incident. Connaissance des bons outils et des rôles de l'équipe.

Illustration of different kinds of charts

Post-mortems des incidents

Exécution d'un post-mortem sans reproche, identification des causes profondes et planification du travail de résolution

Vous recherchez un outil pour vous aider à exécuter un processus de gestion des incidents ?