Proceso de revisión posterior al incidente

Una parte clave de una revisión posterior al incidente es la construcción de una cronología compartida y precisa que refleja la naturaleza no lineal de un incidente.

Al hablar de no lineal, nos referimos a que los incidentes casi nunca son simplemente "esto sucede, y luego eso sucedió, luego lo notamos, luego hicimos algo, y después terminamos". La gente entra y sale, diferentes personas se fijan y prueban cosas diferentes; algunas funcionan, otras no. Y si varias personas trabajan al mismo tiempo, estas cosas también pueden ocurrir al mismo tiempo, por lo que es un poco más complicado.

Para crear una escala de tiempo como esta, incluso una compleja, siempre hay un primer paso importante: recopilar los datos.

Recopilación de los datos

Antes de poder realizar una revisión posterior al incidente, primero debe recopilar datos. En concreto, debe recopilar tanto como sea posible de la conversación y el contexto (tanto técnico como no técnico) que rodean el evento, para que pueda usar todos los datos cruciales contenidos en él. La conversación entre los miembros del equipo que se produjeron durante la interrupción o el incidente será una de sus fuentes de información más ricas.

También deberemos recopilar datos de nuestro sistema de supervisión y de otros sitios de los que hayan obtenido contexto quienes hayan intervenido en el incidente. ¿Qué información obtenían de los sistemas cuando el incidente estaba ocurriendo?

Y, por último, si es posible, sería útil obtener una mejor imagen de lo que cambió justo antes y durante el incidente, ya que los cambios suelen contribuir a factores cuando se produce un incidente.

Podemos examinar este proceso como tres partes independientes:

• Recopilar la conversación: en otros módulos de esta ruta de aprendizaje, hemos mencionado que es importante crear un lugar específico para que las personas se comuniquen durante un incidente. Durante el incidente, idealmente las personas comparten lo que funcionó y lo que falló, lo que están dudando de intentarlo, lo que han intentado en el pasado. Esta conversación entre las personas a medida que trabajan y resuelven el problema es su mejor fuente de aprendizaje.
• Determinar el contexto: las personas de un incidente reciben señales de varios lugares. Un lugar principal es el sistema de supervisión. Hemos analizado la importancia de tener un sistema de supervisión sólido en un módulo anterior en esta ruta de aprendizaje. Lo ideal es que podamos consultar el sistema de monitoreo para crear una instantánea en un momento dado durante el período de tiempo relacionado con el incidente.
• Busque los cambios: puede hacerlo a través de los registros de actividad y auditoría.

Herramientas de Azure para ayudar a recopilar los datos

Azure ofrece una serie de herramientas que pueden ayudar con este proceso:

Azure DevOps para contener metadatos sobre el incidente

En un módulo anterior de esta ruta de aprendizaje, analizamos el uso de Azure Boards en el conjunto de Azure DevOps como un lugar para recopilar toda la información sobre un incidente a partir de la respuesta inicial. Nos ayuda con preguntas sobre cuándo se declaró por primera vez un incidente, quién estaba de guardia, quién fue asignado al incidente, y demás. También puede usar la Wiki de Azure DevOps como una manera centralizada de extraer algunos de los fragmentos de información sobre el propio incidente y la conversación que se produjo durante el incidente.

Microsoft Graph API para extraer la conversación

Microsoft Graph API proporciona una manera programática de buscar, exportar y traer la conversación que se recopiló dentro del canal de Teams dedicado a este incidente específico. Los datos recuperados también incluyen metadatos que serán útiles al construir una cronología, incluyendo quién se unió al canal (y cuándo) y marcas de tiempo para partes individuales de la conversación.

Una manera sencilla de empezar a trabajar con Microsoft Graph API es usar el Explorador de Microsoft Graph. El Explorador de Microsoft Graph es un explorador de API basado en web que le permite elegir las llamadas API eligiendo opciones rellenadas previamente. Así es como se ve:

Recorreremos un conjunto de llamadas API de "Microsoft Teams" y "Microsoft Teams (beta)" para recuperar la conversación. Cada paso del camino, elegiremos una consulta, ejecutaremos la consulta y, a continuación, seleccionaremos la información de la respuesta que nos ayuda con el paso siguiente. A continuación, usamos esta información para construir la siguiente solicitud. Por ejemplo, primero consultamos una lista de identificadores de equipo para mostrar los equipos de los que formamos parte. Elegimos el que necesitamos de la respuesta e insertamos este identificador en la siguiente dirección URL de consulta para obtener una lista de canales en ese equipo.

Estos son nuestros pasos:

1. GET "mis equipos unidos" (para encontrar el identificador de equipo del equipo que usamos).
2. Obtén "los canales de un equipo del que soy miembro" (para encontrar el identificador del canal que usamos para ese incidente).
3. GET "mensajes en un canal" (para recuperar la conversación).

Si más adelante queríamos construir un programa para realizar cada uno de esos pasos (y, de hecho, lo hacemos), hay una opción de fragmentos de código en la ventana de solicitud que presenta código de ejemplo para esa consulta en varios lenguajes de programación diferentes.

Cuadros de mando enfocados para la visualización de contexto

Los paneles de Azure nos permiten recopilar la información de Azure Monitor que nos importa para el reconocimiento operativo en una sola página. La interfaz de usuario nos permite elegir el período de tiempo que se muestra, por lo que es posible "retroceder en el tiempo" y mostrar la información del panel de control para el período de tiempo asociado a un incidente, si así lo deseamos (siempre que la información no sea demasiado antigua para conservarse en Azure Monitor). Esta interfaz de usuario reconstruida puede ser útil al intentar determinar lo que las personas de un incidente vieron durante ese incidente, pero requiere que la persona que realiza la revisión del incidente busque manualmente el período de tiempo adecuado.

Una característica de los paneles de Azure que a menudo se pasa por alto es su capacidad de volcar una plantilla de cualquier panel que se muestra en un archivo JSON mediante el botón Descargar (flecha abajo) y cargarlos de nuevo con el botón Cargar (flecha arriba). Esto significa que podríamos buscar manualmente el momento adecuado, descargar el panel en ese estado y compartir el archivo JSON con otros usuarios, o simplemente descargar el panel actual y modificar el JSON a nuestra especificación. Si busca la cadena "time" en un archivo de panel JSON descargado, aparecerá una sección similar a la siguiente:

"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"
          },

Modifique esta sección según tu especificación y vuelva a cargarla. Si no está familiarizado con el formato en uso, puede cambiar el panel manualmente, descargarlo y ver el formato necesario.

Registros de auditoría y Log Analytics para la exploración de cambios

Un área de trabajo de Log Analytics puede tomar datos de muchos orígenes, incluido el registro de actividad de Azure. En primer lugar, cree un área de trabajo de Log Analytics. A continuación, vaya a la característica Registro de actividad en el portal y elija Configuración de diagnóstico. Esto proporciona la opción de enviar el registro de actividad de una suscripción de Azure a la nueva área de trabajo.

En poco tiempo, podrá usar toda la eficacia del lenguaje de consulta kusto (KQL) para recuperar información detallada sobre los cambios que han tenido lugar en esa suscripción desde que conectó el origen de datos.

Por ejemplo, la consulta siguiente muestra información sobre los recursos que han cambiado o se han eliminado. Podemos establecer el intervalo de tiempo de la consulta en el explorador de consultas para que se afina con mayor precisión en el tiempo poco antes del incidente si lo deseamos.

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

Una breve nota: al establecer el registro de actividad de Azure como origen de datos, la información comienza a fluir al espacio de trabajo de Log Analytics a partir de ese momento. No podrá consultar ese espacio de trabajo de forma retroactiva para los eventos que tuvieron lugar antes de establecer la conexión.

Estas herramientas deben ser capaces de proporcionarle un buen comienzo para recopilar información necesaria para que una cronología se use en una revisión posterior al incidente. Antes de profundizar en una revisión posterior al incidente, nos gustaría advertirle sobre algunas trampas comunes. Ese es el tema de nuestra siguiente unidad.