Suivi des incidents

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 consiste à faire en sorte que les personnes qu’il prend en charge ne savent 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 utilisons la fonctionnalité d’élément de travail de 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.
• Le lieu 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 DevOps, que vous pouvez utiliser pour créer et suivre les éléments de travail d’incident dans Azure Boards.
• Azure Table Storage, où vous pouvez stocker et récupérer des informations sur les personnes qui sont d'astreinte afin de pouvoir avertir les personnes appropriées pour qu'elles répondent à l'incident. Dans notre exemple, nous allons l'utiliser en tant que magasin de clés/attributs simple et sans schéma prédéfini pour les données du planning d'astreinte.
• Microsoft Teams, que vous pouvez utiliser pour créer un canal d'incident unique afin de suivre en temps réel les conversations de vos équipes d'ingénierie au fur et à mesure 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 interrogeons Azure Table Storage pour l’entrée de liste qui identifie l’ingénieur en appel actuel. Cela retourne une réponse JSON, que nous analysons ensuite.

Étant donné que notre requête peut retourner une liste, nous devons itérer sur chaque élément correspondant à l’étape suivante. Dans un flux de travail de production, utilisez ces données pour identifier un propriétaire d’incident principal et toutes les sauvegardes. Le répondeur principal peut être affecté à l’élément de travail Azure DevOps, tandis que d’autres répondeurs peuvent être suivis via des tâches, des commentaires ou des notifications liés.

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.