El proceso de revisión posterior al incidente
Una parte esencial de una revisión posterior al incidente es la construcción de una cronología precisa y común a todos que refleje la naturaleza no lineal de un incidente.
Por no lineal nos referimos a que los incidentes casi nunca ocurren en plan "pasó esto, y luego pasó lo otro, después nos dimos cuenta de aquello, luego hicimos esto y lo finiquitamos todo". Al contrario: la gente entra y sale, hay diferentes personas que observan y prueban cosas distintas, 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 línea 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 a un incidente, primero debemos recopilar los datos. En concreto, debemos recopilar toda la conversación y el contexto (sean o no de naturaleza técnica) en torno al evento que podamos, ya que así podremos usar todos los datos fundamentales que hay en ellos. La conversación que los miembros del equipo mantuvieron durante la interrupción o el incidente será una de las fuentes de información más importantes.
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 estaban obteniendo de los sistemas cuando el incidente estaba teniendo lugar?
Y, por último, si es posible, sería bastante útil componerse una mejor idea de lo que cambió justo antes del incidente y durante este, ya que los cambios suelen ser factores que contribuyen a que se produzca un incidente.
Este proceso se puede considerar como compuesto por tres partes independientes:
- Recopilar la conversación: En otros módulos de esta ruta de aprendizaje, hemos mencionado que es importante disponer de un lugar concreto donde las personas puedan comunicarse durante un incidente. Durante el incidente, lo ideal es que las personas pongan en común qué ha funcionado y qué no, con qué acciones tuvieron dudas, qué intentaron hacer en el pasado. Esta conversación entre las personas a medida que trabajan y resuelven el problema es la mejor fuente de aprendizaje.
- Determinar el contexto: Las personas implicadas en un incidente reciben señales de varios sitios, y uno de ellos fundamental es el sistema de supervisión. En un módulo anterior de esta ruta de aprendizaje ya vimos lo importante que es tener un sistema de supervisión sólido. Lo ideal es que podamos echar un vistazo al sistema de supervisión para tener una instantánea puntual del período de tiempo relativo al incidente.
- Hallar los cambios: Esto se puede lograr a través de registros de actividad y auditoría.
Herramientas de Azure que ayudan a recopilar los datos
Azure ofrece una serie de herramientas que nos pueden ayudar en este proceso:
Azure DevOps para almacenar metadatos sobre el incidente
En un módulo anterior de esta ruta de aprendizaje, analizamos el uso de Azure Boards, del conjunto de aplicaciones Azure DevOps, como lugar donde recopilar toda la información sobre un incidente, empezando por la respuesta inicial. Esta herramienta nos ayuda con preguntas sobre cuándo un incidente se declaró por primera vez, quién estaba al cargo, quién se asignó al incidente, etc. También podemos usar la wiki de Azure DevOps como sitio centralizado donde incluir parte de la información sobre el incidente en sí 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 encontrar, exportar e incorporar la conversación que se recopiló en el canal de Teams dedicado a este incidente específico. Los datos recuperados también incluirán metadatos que serán útiles a la hora de elaborar una cronología, incluido quién se unió al canal (y cuándo) y las marcas de tiempo de los elementos individuales de la conversación.
Una forma fácil de empezar a trabajar con Microsoft Graph API consiste en usar el Probador de Microsoft Graph. El Probador de Microsoft Graph es un explorador de API basado en web en el que se pueden seleccionar llamadas API eligiendo opciones rellenadas previamente. Este es su aspecto:
Vamos a ir pasando por un conjunto de llamadas API de "Microsoft Teams" y "Microsoft Teams (beta)" para recuperar la conversación. En cada paso del proceso, elegiremos una consulta, ejecutaremos la consulta y, después, seleccionaremos la información de la respuesta que nos sea de ayuda para el siguiente paso. Usaremos dicha información para construir la siguiente solicitud. Por ejemplo, primero realizamos una consulta para obtener una lista de identificadores de equipo que nos indique 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 de ese equipo.
Estos son nuestros pasos:
- GET "mis equipos unidos" (para encontrar el identificador de equipo del equipo que usamos).
- GET "canales de un equipo del que soy miembro" (para encontrar el identificador de canal del canal que usamos con ese incidente).
- GET "mensajes en un canal" (para recuperar la conversación).
Si más adelante quisiéramos (y querremos) crear un programa que realizara cada uno de estos pasos, existe una opción Fragmentos de código en la ventana de solicitud que muestra el código de ejemplo de la consulta en varios lenguajes de programación diferentes.
Paneles dirigidos para la visualización de contexto
Los paneles de Azure nos permiten recopilar en una misma página toda la información de Azure Monitor que nos importa para adquirir un conocimiento operativo de un asunto. La interfaz de usuario nos permite elegir el período de tiempo que queremos ver, de forma que nos sea posible "ir atrás en el tiempo" y mostrar la información del panel correspondiente al período de tiempo asociado a un incidente si así lo quisiéramos (siempre y cuando la información no sea demasiado antigua como para que Azure Monitor ya no la conserve). Esta interfaz de usuario reconstruida puede ser útil a la hora de intentar averiguar qué fue lo que vieron las personas implicadas en un incidente durante el mismo, si bien requiere que la persona encargada de la revisión posterior al incidente encuentre manualmente el período de tiempo adecuado.
Una característica de los paneles de Azure que a menudo se pasa por alto es que permiten volcar una plantilla de cualquier panel en pantalla en un archivo JSON usando el botón de Descarga (flecha abajo) y, luego, volver a cargarla con el botón de Carga (flecha arriba). Esto significa que podríamos buscar manualmente el momento adecuado, descargar el panel en ese estado y compartir el archivo JSON con los demás, o simplemente, descargar el panel actual y modificar el JSON de acuerdo con nuestras especificaciones. Si buscamos la cadena "time" en un archivo de panel JSON descargado, aparecerá una sección como esta:
"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"
},
Solo tenemos que modificarla según nuestras especificaciones y volver a cargarla. Si no está familiarizado con el formato que se usa, puede cambiar el panel manualmente, descargarlo y ver el formato requerido.
Registros de auditoría y Log Analytics para la exploración de cambios
Un área de trabajo de Log Analytics admite datos de muchos orígenes, incluido el registro de actividad de Azure. Primero, debemos crear un área de trabajo de Log Analytics Después, vaya a la característica Registro de actividad del portal y elija Configuración de diagnóstico. Esto nos ofrece la posibilidad de enviar el registro de actividad de una suscripción de Azure a nuestra nueva área de trabajo.
En breve, podremos usar toda la eficacia del lenguaje de consulta de Kusto (KQL) para recuperar información detallada sobre los cambios que se han producido en esa suscripción desde que se 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 afinar con más precisión el tiempo previo al incidente que queramos.
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
Nota rápida: cuando el registro de actividad de Azure se establece como origen de datos, la información comienza a fluir al área de trabajo de Log Analytics desde ese momento en el tiempo en adelante. No podremos consultar de manera retroactiva los datos de esa área de trabajo relativos a eventos que hayan tenido lugar antes de realizar la conexión.
Estas herramientas deben constituir un buen punto de partida para recopilar la información que necesitamos crear una cronología que podamos usar en una revisión posterior al incidente. Antes de sumergirnos de lleno en una revisión posterior al incidente, nos gustaría advertir de algunas trampas comunes. A eso dedicaremos nuestra siguiente unidad.