Processus d’un examen post-incident
Un élément fondamental d’un examen post-incident est la construction d’une chronologie partagée et précise qui reflète la nature non linéaire d’un incident.
Par « non linéaire », nous signifions que les incidents ne se résument presque jamais à « ceci s’est produit, puis cela, puis nous avons remarqué quelque chose, ce qui nous a amenés à faire telle chose, puis nous avons terminé ». Les gens vont et viennent, différentes personnes remarquent et essaient différentes choses, certaines fonctionnent, d’autres non. Et si plusieurs personnes travaillent en même temps, ces choses peuvent également se produire en même temps, donc c’est un peu plus compliqué.
Pour créer une chronologie telle que celle-ci, même une chronologie complexe, il y a toujours une première étape importante : collecter les données.
Collecter les données
Avant de pouvoir effectuer un examen post-incident, vous devez collecter des données. Plus précisément, vous devez recueillir la plus grande quantité d’informations possible sur la conversation et le contexte (technique et non technique) entourant l’événement, afin de pouvoir utiliser toutes les données cruciales qu’il renferme. La conversation qu’ont eue les membres de l’équipe à l’occasion de la panne ou de l’incident est l’une des sources d’informations les plus riches.
Vous devez également collecter des données auprès de votre système de supervision et des autres sources dont les personnes impliquées dans l’incident ont pu tirer des éléments du contexte. Quelles informations obtenaient-elles de vos systèmes quand l’incident était en cours ?
Enfin, dans la mesure du possible, il serait utile d’avoir une meilleure image de ce qui a changé juste avant et pendant l’incident, car les changements contribuent souvent aux incidents.
L’examen de ce processus peut comprendre trois parties :
- Collecter la conversation : Dans d’autres modules de ce parcours d’apprentissage, nous avons mentionné qu’il est important que les personnes puissent communiquer tout à leur aise au cours d’un incident. Pendant l’incident, les personnes partagent idéalement ce qui a fonctionné et ce qui a échoué, ce qu’elles hésitent à essayer, ce qu’elles ont essayé dans le passé. Cette conversation entre les personnes à mesure qu’elles travaillent sur le problème et le résolvent est votre meilleure source d’apprentissage.
- Déterminer le contexte : Les personnes impliquées dans un incident reçoivent des signaux émanant de différentes sources. Votre système de supervision est l’une des principales sources. Nous avons abordé l’importance de disposer d’un système de supervision solide dans un module précédent de ce parcours d’apprentissage. Idéalement, nous devrions être en mesure de consulter le système de supervision afin de créer un instantané à un point dans le temps pour la période autour de l’incident ou relative à ce dernier.
- Rechercher les changements : Vous pouvez effectuer cette opération par le biais des journaux d’activité et d’audit.
Outils Azure facilitant la collecte des données
Azure met à votre disposition une série d’outils qui peuvent vous aider dans ce processus :
Azure DevOps pour conserver les métadonnées relatives à l’incident
Dans un module précédent de ce parcours d’apprentissage, nous avons abordé l’utilisation d’Azure Boards dans la suite Azure DevOps pour collecter toutes les informations relatives à un incident depuis la réponse initiale. Cet outil aide à répondre aux questions sur la date de la déclaration initiale d’un incident, les personnes d’astreinte, la personne affectée à l’incident, etc. Vous pouvez également utiliser le wiki Azure DevOps pour extraire de façon centralisée des informations sur l’incident lui-même et sur la conversation qui s’est produite pendant ce dernier.
API Microsoft Graph pour l’extraction de la conversation
L’API Microsoft Graph fournit une méthode programmatique pour rechercher, exporter et exposer la conversation qui a été collectée dans le canal Teams consacré à l’incident concerné. Les données récupérées comportent également des métadonnées qui sont utiles lors de la construction d’une chronologie, notamment les personnes qui ont rejoint le canal (et à quel moment) et les horodatages des différentes parties de la conversation.
L’Afficheur Microsoft Graph est un moyen simple de commencer à utiliser l’API Microsoft Graph. L’Afficheur Microsoft Graph est un navigateur d’API basé sur le web qui vous permet de choisir les appels d’API à partir d’options préremplies. Voici à quoi il ressemble :
Nous parcourons un ensemble d’appels d’API « Microsoft Teams » et « Microsoft Teams (bêta) » pour récupérer la conversation. À chaque étape de la procédure, nous choisissons une requête, l’exécutons, puis sélectionnons les informations de la réponse qui nous aident pour l’étape suivante. Nous utilisons ensuite ces informations pour construire la requête suivante. Par exemple, nous interrogeons d’abord une liste d’ID d’équipe pour afficher les équipes dont nous faisons partie. Nous choisissons dans la réponse l’ID dont nous avons besoin et l’insérons dans l’URL de requête suivante pour obtenir la liste des canaux de cette équipe.
Voici les étapes à suivre :
- GET « Équipes que j’ai rejointes » (pour trouver l’ID de l’équipe que nous utilisons).
- GET « canaux d’une équipe dont je suis membre » (afin de trouver l’ID du canal que nous avons utilisé pour cet incident).
- GET « message dans un canal » (pour récupérer la conversation).
Si, par la suite, nous souhaitons créer un programme pour effectuer chacune de ces étapes (ce qui est le cas), il existe une option extraits de code dans la fenêtre de requête qui présente l’exemple de code pour cette requête dans différents langages de programmation.
Tableaux de bord ciblés pour l’affichage du contexte
Dans Azure, les tableaux de bord vous permettent de collecter sur une seule page les informations d’Azure Monitor qui nous intéressent du point de vue de la sensibilisation opérationnelle. L’interface utilisateur nous permet de choisir la période d’affichage. Nous pouvons ainsi « remonter le temps » et afficher les informations du tableau de bord pour la période associée à un incident si tel est notre choix (à condition que les informations ne soient pas trop anciennes pour être conservées dans Azure Monitor). Cette interface utilisateur reconstruite peut être utile quand vous tentez de déterminer ce que les personnes impliquées dans un incident ont vu au cours de celui-ci, mais cela nécessite que la personne effectuant l’examen post-incident effectue une recherche manuelle de la période de temps appropriée.
L’une des fonctionnalités des tableaux de bord sur Azure, souvent négligée, est sa capacité à vider dans un fichier JSON un modèle de tableau de bord affiché, à l’aide du bouton Télécharger (flèche vers le bas), et à le recharger, avec le bouton Charger (flèche vers le haut). Cela signifie que nous pourrions effectuer une recherche manuelle de la période appropriée, télécharger le tableau de bord dans cet état et partager le fichier JSON avec d’autres utilisateurs ou simplement télécharger le tableau de bord actuel et modifier le JSON selon nos spécifications. Si vous recherchez la chaîne « time » dans un fichier de tableau de bord JSON téléchargé, vous obtenez une section qui ressemble à ceci :
"metadata": {
"model": {
"timeRange": {
"value": {
"relative": {
"duration": 24,
"timeUnit": 1
}
},
"type": "MsPortalFx.Composition.Configuration.ValueTypes.TimeRange"
},
"filterLocale": {
"value": "en-us"
},
"filters": {
"value": {
"MsPortalFx_TimeRange": {
"model": {
"format": "utc",
"granularity": "auto",
"relative": "24h"
},
"displayCache": {
"name": "UTC Time",
"value": "Past 24 hours"
},
Modifiez cette section selon vos spécifications et rechargez-la. Si vous n’êtes pas familiarisé avec le format utilisé, vous pouvez changer le tableau de bord manuellement, le télécharger et voir le format requis.
Journaux d’audit et Log Analytics pour l’exploration des changements
Un espace de travail Log Analytics peut accepter des données de nombreuses sources, y compris le journal d’activité Azure. Tout d’abord, créez un espace de travail Log Analytics. Accédez ensuite à la fonctionnalité Journal des activités dans le portail, puis choisissez Paramètres de diagnostic. Vous pouvez ainsi envoyer le journal d’activité d’un abonnement Azure à votre nouvel espace de travail.
En peu de temps, vous pouvez utiliser toute la puissance du langage de requête Kusto (KQL) pour récupérer des informations détaillées sur les changements apportés à cet abonnement depuis que vous avez connecté la source de données.
Par exemple, la requête suivante affiche des informations sur des ressources qui ont changé ou ont été supprimées. Si nous le souhaitons, nous pouvons définir la plage de temps de la requête dans l’Explorateur de requêtes sur la courte période qui précède l’incident.
AzureActivity
| where CategoryValue == 'Administrative'
| where OperationNameValue endswith "write" or OperationNameValue endswith "delete"
| project TimeGenerated, Level, ResourceGroup, ResourceId, OperationName, OperationNameValue, ActivityStatus, Caller
| order by TimeGenerated nulls first
Une remarque rapide : les informations commencent à affluer dans l’espace de travail Log Analytics dès que vous définissez le journal d’activité Azure comme source de données. Vous ne pouvez pas interroger cet espace de travail de façon rétroactive pour obtenir des données sur des événements qui ont eu lieu avant que vous n’établissiez la connexion.
Vous devriez pouvoir vous appuyer sur ces outils pour commencer à collecter les informations nécessaires à l’établissement d’une chronologie à utiliser dans un examen post-incident. Avant que vous ne vous plongiez dans un examen post-incident, nous aimerions attirer votre attention sur certains pièges courants. Tel est l’objet de notre prochaine unité.