Processus de révision post-incident

Une partie clé 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 entendons que les incidents ne sont presque jamais juste « cette chose se produit, puis cela s’est produit, puis nous avons remarqué, puis nous avons fait quelque chose, puis nous avons terminé . » Les gens viennent et sortent, des gens différents remarquent et essaient des choses différentes ; un peu de travail, certains ne le font pas. Et si plusieurs personnes travaillent en même temps, ces choses peuvent se produire en même temps, donc c’est un peu plus compliqué.

Pour créer une chronologie comme celle-ci, même complexe, il existe toujours une première étape importante : collecter les données.

Collecter les données

Avant de pouvoir effectuer une révision post-incident, vous devez d’abord collecter des données. Plus précisément, vous devez collecter autant de conversation et de contexte (technique et non technique) autour de l’événement que vous pouvez pour pouvoir utiliser toutes les données cruciales contenues dans celui-ci. La conversation entre les membres de l’équipe qui se sont produits pendant la panne ou l’incident sera l’une de vos sources d’informations les plus riches.

Vous devez également collecter des données à partir de votre système de surveillance et d’autres endroits où les personnes impliquées dans l’incident ont dessiné le contexte. Quelles informations recevaient-elles de vos systèmes lorsque l’incident se passait ?

Enfin, si possible, il serait utile d’obtenir une meilleure image de ce qui a changé juste avant et pendant l’incident, car les changements contribuent souvent à des facteurs quand un incident se produit.

Nous pouvons examiner ce processus comme trois parties distinctes :

• Collectez la conversation : dans d’autres modules de ce parcours d’apprentissage, nous avons mentionné qu’il est important d’extraire un endroit spécifique pour que les personnes communiquent pendant un incident. Pendant l’incident, dans l’idéal, les gens partagent ce qui a fonctionné et ce qui a échoué, ce qu’ils hésitent à essayer, ce qu’ils ont essayé par le passé. Cette conversation entre les personnes qui travaillent et résolvent le problème est votre meilleure source d’apprentissage.
• Déterminer le contexte : les personnes d’un incident reçoivent des signaux provenant de différents endroits. Un emplacement principal est votre système de surveillance. Nous avons discuté de l’importance d’avoir un système de surveillance solide dans un module précédent dans ce parcours d’apprentissage. Dans l’idéal, nous devons être en mesure d’examiner le système de surveillance pour créer un instantané à un point dans le temps pendant la période autour ou lié à l’incident.
• Recherchez les modifications : vous pouvez effectuer cette opération par le biais des journaux d’activité et d’audit.

Outils Azure pour aider à collecter les données

Azure propose un certain nombre d’outils qui peuvent aider 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 comme un seul endroit pour collecter toutes les informations relatives à un incident à partir de la réponse initiale. Il nous aide à nous poser des questions sur le moment où un incident a été déclaré, qui était à l’appel, qui a été affecté à l’incident, et ainsi de suite. Vous pouvez également utiliser le Wiki Azure DevOps comme moyen centralisé d’extraire certaines informations sur l’incident lui-même et la conversation qui s’est produite pendant l’incident.

API Microsoft Graph pour l’extraction de la conversation

L’API Microsoft Graph fournit un moyen programmatique de rechercher, d’exporter et d’apporter la conversation qui a été collectée à l’intérieur du canal Teams consacré à cet incident spécifique. Les données récupérées incluent également des métadonnées qui seront utiles lors de la construction d’une chronologie, y compris ceux qui ont rejoint le canal (et quand) et les horodatages pour des parties individuelles de la conversation.

Une façon simple de commencer avec l’API Microsoft Graph consiste à utiliser l’Explorateur Microsoft Graph. Microsoft Graph Explorer est un navigateur d’API web qui vous permet de choisir les appels d’API en choisissant des options préremplies. Voici ce à quoi il ressemble :

Nous allons parcourir un ensemble d’appels d’API « Microsoft Teams » et « Microsoft Teams (bêta) » pour récupérer la conversation. Chaque étape de la façon, nous allons choisir une requête, exécuter la requête, puis sélectionner les informations dans la réponse qui nous aide à effectuer 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 celui dont nous avons besoin dans la réponse et insérons cet ID dans l’URL de requête suivante pour obtenir la liste des canaux de cette équipe.

Voici nos étapes :

1. OBTENEZ « mes équipes jointes » (pour trouver l’ID d’équipe de l’équipe que nous utilisons).
2. GET « canaux d’une équipe dont je suis membre » (pour rechercher l’ID de canal du canal que nous avons utilisé pour cet incident).
3. GET « messages dans un canal » (pour récupérer la conversation).

Si nous voulions plus tard construire un programme pour effectuer chacune de ces étapes (et en effet, nous le faisons), il existe une option d’extraits de code dans la fenêtre de requête qui présente un exemple de code pour cette requête dans un certain nombre de langages de programmation différents.

Tableaux de bord ciblés pour l’affichage de contexte

Les tableaux de bord dans Azure nous permettent de collecter les informations d’Azure Monitor qui nous intéressent pour la sensibilisation opérationnelle ensemble sur une seule page. L’interface utilisateur nous permet de choisir la période affichée. Il est donc possible de « rembobiner le temps » et d’afficher les informations de tableau de bord pour la période associée à un incident si nous le choisissons (si nous choisissons les informations ne sont pas trop anciennes pour ne plus être conservées dans Azure Monitor). Cette interface utilisateur reconstruite peut être utile lorsque vous essayez de déterminer ce que les personnes d’un incident ont vu pendant cet incident, mais il exige que la personne effectuant la révision de l’incident recherche manuellement la période appropriée.

L’une des fonctionnalités des tableaux de bord sur Azure qui sont souvent négligés est leur capacité à vider un modèle de tout tableau de bord affiché dans un fichier JSON à l’aide du bouton Télécharger (flèche bas) et de les charger avec le bouton Charger (flèche haut). Cela signifie que nous pourrions rechercher manuellement le bon moment, télécharger le tableau de bord dans cet état et partager le fichier JSON avec d’autres personnes, ou simplement télécharger le tableau de bord actuel et modifier le JSON dans notre spécification. Si vous recherchez la chaîne « time » dans un fichier de tableau de bord JSON téléchargé, vous trouverez 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 dans votre spécification et rechargez-la. Si vous n’êtes pas familiarisé avec le format utilisé, vous pouvez modifier le tableau de bord manuellement, le télécharger et voir le format requis.

Journaux d’audit et Log Analytics pour l’exploration des modifications

Un espace de travail Log Analytics peut prendre des données de nombreuses sources, y compris le journal d’activité Azure. Tout d’abord, créez un espace de travail Log Analytics. Ensuite, accédez à la fonctionnalité journal d’activité dans le portail et choisissez Paramètres de diagnostic. Cela permet d’envoyer le journal d’activité d’un abonnement Azure à votre nouvel espace de travail.

Dans un court délai, vous serez en mesure d’utiliser toute la puissance du langage de requête Kusto (KQL) pour récupérer des informations détaillées sur les modifications qui ont eu lieu dans cet abonnement depuis que vous avez connecté la source de données.

Par exemple, la requête suivante montre des informations sur les ressources qui ont changé ou qui ont été supprimées. Nous pouvons définir l’intervalle de temps pour la requête dans l’Explorateur de requêtes afin qu’elle soit plus précisément affinée dans l’heure peu avant l’incident si nous le désirons.

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 : lorsque vous définissez le journal d’activité Azure en tant que source de données, les informations commencent à circuler dans l’espace de travail Log Analytics à partir de ce point dans le temps. Vous ne pourrez pas interroger cet espace de travail pour les données rétroactivement pour les événements qui ont eu lieu avant d’établir la connexion.

Ces outils doivent être en mesure de vous donner un bon début sur la collecte d’informations nécessaires à une chronologie à utiliser dans un examen post-incident. Avant de vous plonger directement dans une révision post-incident, nous aimerions vous avertir de certains pièges courants. C’est le sujet de notre prochaine unité.