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 la mayor cantidad posible de la conversación y el contexto (tanto técnicos como no técnicos) que rodean el evento para poder utilizar todos los datos cruciales que se encuentran en ellos. 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ó 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 el Azure DevOps Wiki 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 recuperar la conversación recopilada dentro del canal de Teams dedicado a este incidente específico. Los datos recuperados incluyen marcas de tiempo, autoría, ediciones, respuestas y algunos mensajes del sistema, lo que puede ayudar a construir una cronología.

Una manera sencilla de empezar a trabajar con Microsoft Graph API es usar Microsoft Graph Explorer. Microsoft Graph Explorer es un explorador de API basado en web que permite elegir llamadas API de un Sample consultas panel e intentarlas de forma interactiva.

Antes de ejecutar las consultas, asegúrese de que el usuario o la aplicación que usa tiene los permisos y el consentimiento necesarios para el modo de acceso que ha elegido. En escenarios delegados, enumerar equipos unidos usa Team.ReadBasic.All, enumerar canales usa Channel.ReadBasic.Ally leer mensajes de canal requiere ChannelMessage.Read.All. Si más adelante automatiza el flujo de trabajo con acceso de solo aplicación, use GET /users/{id | user-principal-name}/joinedTeams en lugar del alias de solo delegado /me/joinedTeams con el permiso de aplicación Team.ReadBasic.All. Para los pasos de lectura específicos del canal, las opciones de solo aplicación con privilegios mínimos son ChannelSettings.Read.Group para enumerar canales y ChannelMessage.Read.Group para leer mensajes, ambos con consentimiento específico del recurso.

Recorreremos un conjunto de llamadas API de Microsoft Graph v1.0 "Microsoft Teams" para recuperar la conversación. (Los mensajes de canal se han movido de la versión beta a la versión 1.0 hace varios años, por lo que los puntos de conexión beta ya no son necesarios para este escenario). 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, que se muestran como puntos de conexión de Microsoft Graph v1.0:

1. GET /me/joinedTeams (para encontrar el identificador de equipo del equipo que usamos en un escenario delegado) o GET /users/{id | user-principal-name}/joinedTeams (para hacer lo mismo en un escenario de solo aplicación).
2. GET /teams/{team-id}/channels (para encontrar el identificador de canal del canal que usamos para ese incidente).
3. GET /teams/{team-id}/channels/{channel-id}/messages?$expand=replies (para recuperar la conversación en subproceso).
4. Siga @odata.nextLink y replies@odata.nextLink según sea necesario, o llame GET /teams/{team-id}/channels/{channel-id}/messages/{message-id}/replies para navegar por subprocesos más grandes.

Si ha usado un canal compartido, tenga en cuenta que la joinedTeams API no devuelve el equipo host de un canal compartido del que es miembro directo el usuario. Esta advertencia se aplica ya sea que llame a GET /me/joinedTeams o GET /users/{id | user-principal-name}/joinedTeams. En ese caso, empiece por los identificadores de canal y equipo conocidos o use las API del equipo asociadas para localizar el equipo host.

En el Explorador de gráficos, puede escribir estas URL directamente o elegir las entradas equivalentes del panel de Consultas de muestra integrado en Microsoft Teams.

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.

En función de cómo el equipo use Teams, el historial de mensajes también puede contener mensajes del sistema que ayuden a explicar cuándo se agregaron o quitaron los miembros. Sin embargo, si necesita un registro de auditoría fidedigno de los cambios de acceso o pertenencia a canales, complemente estos datos con los registros de auditoría de Microsoft 365.

Paneles y libros de trabajo para la visualización contextual.

Los paneles de Azure y los libros de Azure Monitor pueden ayudar a reconstruir el contexto que observaron los operadores durante un incidente. Los paneles son útiles para una visión general operativa de un vistazo en los servicios de Azure. Los libros suelen ser la mejor opción para el análisis de incidentes, ya que admiten consultas, parámetros, detalles y texto narrativo enriquecidos junto con gráficos.

Si ya tiene un panel de control o libro de trabajo que captura las señales correctas, establezca su intervalo de tiempo en el período que rodea el incidente y úselo para reconstruir lo que las personas vieron en ese momento. Esto puede ser especialmente útil al correlacionar métricas, registros y alertas entre varios recursos.

Los paneles compartidos son Azure recursos y todavía se pueden exportar como JSON desde el portal. Esa ruta de acceso de exportación e importación es útil cuando desea versionar o usar como plantilla un panel. Sin embargo, para la mayoría de los escenarios de investigación posteriores a incidentes, los libros son la herramienta más flexible porque permiten combinar visualizaciones, consultas KQL y texto explicativo en un único artefacto.

Registros de actividad, registros de recursos y Log Analytics para la exploración de cambios

Un área de trabajo de Log Analytics puede tomar datos de muchos orígenes, como Azure registro de actividad, registros de recursos Azure y diagnósticos específicos del servicio. En primer lugar, cree una nueva Log Analytics área de trabajo. A continuación, en el portal de Azure, abra Monitor → Registro de actividad y seleccione Exportar registros de actividad en la parte superior del panel. Se abre una configuración de diagnóstico que le permite enviar el registro de actividad para una suscripción de Azure al área de trabajo.

En poco tiempo, puede usar el lenguaje de consulta kusto (KQL) para recuperar información detallada sobre los cambios que han tenido lugar en esa suscripción desde que ha conectado el origen de datos.

Por ejemplo, la consulta siguiente muestra información sobre los recursos que cambiaron o se eliminaron. Podemos establecer el intervalo de tiempo en la experiencia de registros para afinar de forma más precisa en el período justo antes del incidente.

AzureActivity
| where CategoryValue == 'Administrative'
| where OperationNameValue endswith "write" or OperationNameValue endswith "delete"
| project TimeGenerated, Level, ResourceGroup, ResourceId, OperationName, OperationNameValue, ActivityStatusValue, Caller
| order by TimeGenerated desc

Esta consulta es útil para los cambios en el plano de administración, pero recuerde lo que no se muestra. AzureActivity captura las operaciones del plano de control, como crear, actualizar, eliminar y acciones de directiva. No captura los cambios en el plano de datos ni en el nivel de aplicación dentro de un servicio. Para investigarlas, empareje esta consulta con registros de recursos Azure, registros de auditoría específicos del servicio, historial de implementación y registros de CI/CD o de control de código fuente.

Una nota rápida: al exportar el registro de actividad de Azure, la información comienza a fluir al Log Analytics workspace desde ese momento. No podrá consultar ese área de trabajo de forma retroactiva para los eventos que tuvieron lugar antes de realizar 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.