Suivi des incidents
- 7 minutes
Les incidents ont un cycle de vie. Pour répondre le plus efficacement, vous devez être en mesure de suivre l’évolution de l’incident lui-même et l’évolution de votre réponse, depuis le début de ce cycle de vie.
Évaluer ce que vous savez
Une bonne façon d’évaluer votre procédure de suivi des incidents à l’aide d’un incident spécifique consiste à vous poser une série de questions :
- Quand avez-vous d’abord appris le problème ? Si votre objectif est de réduire le temps nécessaire à la récupération des incidents, vous devez commencer à capturer des informations à partir du moment où vous êtes conscient des problèmes.
- Comment avez-vous trouvé le problème ? Votre système de surveillance vous a-t-il alerté sur l’incident ? Avez-vous d’abord entendu parler de cela par des plaintes de vos clients, directement ou via les réseaux sociaux ?
- Si vous venez de découvrir le problème, êtes-vous le premier à le savoir ? Si c’est le cas, qui avez-vous besoin d’informer ? Si ce n’est pas le cas, qui est au courant du problème ?
- Si d’autres sont conscients, que se passe-t-il (s’il y a quelque chose) à ce sujet ? Est-ce que tout le monde part du principe que quelqu’un d’autre s’y intéresse, ou qu’une personne a commencé à prendre des mesures pour y remédier ?
- À quel point est-ce grave ? Nous n’avons peut-être aucune notion de gravité ou d’impact, et il n’y a pas de moyen pour nous de découvrir à quel point le problème est grave et qui est concerné.
Il peut s’agir de questions difficiles à répondre si rien n’est suivi.
Normaliser l’emplacement où les informations sur les incidents seront suivies
Il existe de nombreux endroits possibles où vous pourriez conserver et partager votre liste d'incidents (actifs ou autres) et toutes les informations actuelles sur ces incidents. Elles peuvent être aussi simples qu’une zone de fichiers partagée avec des documents Word et aussi complexes que des logiciels et services de suivi des incidents hautement spécialisés. Entre ces deux extrêmes se trouvent les systèmes de gestion de tickets et de suivi du travail dont vous pouvez vous servir pour cette tâche. Quel système vous choisissez est en fait moins important que la façon dont vous l’utilisez. Quel que soit le système que vous utilisez, tous ceux qui peuvent avoir une connexion à tous les incidents (ingénieurs, support client, gestion, relations publiques, juridiques, et ainsi de suite) doivent savoir où accéder au système, comment déclencher un incident et comment accéder aux données le cas échéant. Un moyen sûr d’échouer avec le suivi des incidents est d’avoir les personnes qu’il prendra en charge ne sait pas comment accéder au système (« quelle était l’URL de notre système à nouveau ? ») quand ils en ont besoin.
Dans ce module, nous allons utiliser la fonctionnalité d’élément de travail d’Azure DevOps pour notre exemple de système de suivi.
Créer un pont de conversation
Pour répondre à certaines des questions de la section Évaluer ce que vous connaissez et commencer le processus de réponse aux incidents, vous devez avoir un moyen de communiquer avec d’autres personnes sur l’incident. Dans l’idéal, il s’agira d'un moyen électronique destiné aux échanges en équipe, même si les conférences téléphoniques fonctionnent également. Les appels de conférence/ponts téléphoniques sont moins prisés, car il est plus difficile de revoir a posteriori les communications liées aux incidents (par conséquent, le rôle « Scribe » mentionné précédemment).
Quel que soit le moyen que vous choisissez, assurez-vous de créer un canal spécifiquement dédié et strictement limité à la discussion sur cet incident et rien d'autre. Il est important de garder une discussion non pertinente hors de ce canal, car vous devez être en mesure de prendre les données et de les analyser ultérieurement dans votre révision post-incident.
Dans ce module, nous allons utiliser Microsoft Teams comme méthode de communication par incident.
Automatiser le lancement du suivi des incidents
Alors, examinons les pièces que nous avons rassemblées jusqu’à présent. Nous avons :
- Liste des personnes à l’appel (et rotation définie pour eux).
- Rôle que nous pouvons affecter aux personnes travaillant sur un incident.
- Un endroit spécifique où nous allons déclarer l'incident et le suivre.
- Canal unique pour les personnes travaillant sur cet incident pour communiquer à ce sujet.
Vous pouvez et devez automatiser la création et la gestion de toutes ces choses dans la mesure du possible. Lorsqu’un problème urgent se produit, vous ne voulez pas avoir à rappeler toutes les étapes nécessaires pour déclencher un incident, amener les bonnes personnes et le suivre. Tout ce que vous voulez vraiment faire est de pouvoir pousser le bouton « go » afin que le travail puisse immédiatement commencer à traiter le problème.
Utiliser Logic Apps pour l’automatisation sans code
Une façon d’automatiser votre réponse initiale consiste à utiliser Logic Apps, qui peut simplifier le travail de planification, d’automatisation et d’orchestration des tâches, des processus métier et des flux de travail.
Logic Apps est un service cloud Azure pour créer des solutions d’intégration. Il utilise des connecteurs pour créer des flux de travail automatisés. Les déclencheurs démarrent l’application logique lorsqu’un événement spécifique se produit ou lorsque les données répondent à des critères spécifiés. Les actions sont les opérations qui sont ensuite effectuées dans le flux de travail d’application logique.
Pour notre exemple, nous allons utiliser les connecteurs d’application logique suivants pour le suivi des incidents :
- Azure Boards (une partie d’Azure DevOps), que vous pouvez utiliser pour créer et suivre les problèmes/incidents.
- Stockage Azure, où vous pouvez stocker et récupérer des informations sur les personnes qui sont en cours d’appel afin de pouvoir affecter les personnes appropriées pour répondre à l’incident. Dans notre exemple, nous allons utiliser le service Stockage Table Azure, car il offre un magasin de type « clé-valeur » très simple qui facilite le stockage d’une liste d’ingénieurs et de leur statut d’astreinte.
- Microsoft Teams, que vous pouvez utiliser pour créer un nouveau canal d'incident unique afin de suivre les échanges de vos équipes techniques en temps réel pendant qu'elles communiquent sur des incidents spécifiques. Cela vous permet de conserver les interactions par rapport à la chronologie des événements ultérieurement lors de l’exécution d’une révision post-incident.
Nous allons maintenant lier tout cela avec une application logique. Tout d’abord, examinez l’application complète, comme indiqué dans le Concepteur Logic Apps, puis nous allons la parcourir pas à pas.
La première étape consiste à gérer un déclencheur, cette requête HTTP que nous avons mentionnée. Une requête HTTP POST est envoyée à notre application logique qui contient une charge utile JSON avec des informations sur l’incident que nous souhaitons déclarer. Nous analysons cette charge utile et renvoyons un accusé de réception que nous avons reçu :
À l’aide de ces informations, nous créons un élément de travail dans notre organisation Azure DevOps représentant cet incident.
Il crée ensuite un canal Teams pour l’incident :
Une fois le canal créé, l’élément de travail que nous avons créé il y a un instant est mis à jour avec un lien vers le nouveau canal. Cela conserve toutes les informations au même endroit (l'élément de travail) et permet aux personnes qui le consultent plus tard de savoir où aller si elles veulent rejoindre ce canal.
C’est lâ que la personne d’astreinte entre en scène. Nous effectuons une recherche dans Azure Table Storage pour trouver l’adresse e-mail de l’ingénieur indiqué comme étant de garde. Cela retourne une réponse JSON, que nous analysons ensuite.
Étant donné que notre requête retourne une liste, nous devons itérer sur chaque élément de cette liste à l’étape suivante. Nous affectons l’élément de travail à chaque personne (ils sont désormais « propriétaires » de l’incident).
Ensuite, en guise d'étape finale, nous envoyons un message au canal Teams avec un pointeur vers l'élément de travail pour les personnes qui rejoignent le canal et veulent savoir où sont stockées les informations définitives concernant cet incident.
C’est un exemple de la façon dont nous pouvons automatiser la configuration des mécanismes de suivi et de communication des incidents. Dans l’unité suivante, nous allons explorer un peu plus en détail les aspects de la communication autour d’un incident.