O processo de revisão pós-incidente

Uma parte fundamental de uma revisão pós-incidente é a construção de uma cronologia compartilhada e precisa que reflete a natureza não linear de um incidente.

Por não linear, queremos dizer que os incidentes quase nunca são apenas "essa coisa acontece, e então isso aconteceu, então notamos, então fizemos algo, e então terminamos." As pessoas entram e saem, pessoas diferentes notam e tentam coisas diferentes; algum trabalho, outros não. E se várias pessoas estão trabalhando ao mesmo tempo, essas coisas podem acontecer ao mesmo tempo, também, então é um pouco mais complicado.

Para criar uma linha do tempo como esta, mesmo uma complexa, há sempre uma primeira etapa importante: coletar os dados.

Coletar os dados

Antes de realizar uma revisão pós-incidente, primeiro você precisa coletar dados. Especificamente, você precisa coletar o máximo de conversa e contexto (técnico e não técnico) em torno do evento que puder para poder usar todos os dados cruciais contidos nele. A conversa entre os membros da equipe que aconteceu durante a interrupção ou incidente será uma das fontes de informação mais avançadas.

Você também deve coletar dados do seu sistema de monitoramento e de outros locais em que as pessoas envolvidas no incidente desenharam o contexto. Que informações eles estavam recebendo de seus sistemas quando o incidente estava acontecendo?

E, por fim, se possível, seria útil para você ter uma visão melhor do que mudou pouco antes e durante o incidente, porque as alterações geralmente contribuem para fatores quando ocorre um incidente.

Podemos examinar esse processo como três partes separadas:

• Colete a conversa: Em outros módulos neste roteiro de aprendizagem, mencionamos que é importante esculpir um local específico para que as pessoas se comuniquem durante um incidente. Durante o incidente, o ideal é que as pessoas compartilhem o que funcionou e o que falhou, o que estão hesitantes em tentar, o que tentaram no passado. Essa conversa entre as pessoas enquanto elas trabalham e resolvem o problema é sua melhor fonte de aprendizado.
• Determine o contexto: as pessoas em um incidente estão recebendo sinais de vários lugares. Um dos principais lugares é o sistema de monitoramento. Discutimos a importância de ter um sistema de monitoramento sólido em um módulo anterior neste roteiro de aprendizagem. Idealmente, devemos ser capazes de examinar o sistema de monitoramento para criar um instantâneo pontual para o período de tempo em torno ou relacionado ao incidente.
• Encontre as alterações: você pode fazer isso por meio de logs de atividade e auditoria.

Ferramentas do Azure para ajudar a coletar os dados

O Azure oferece várias ferramentas que podem ajudar nesse processo:

Azure DevOps para manter metadados sobre o incidente

Em um módulo anterior neste roteiro de aprendizagem, discutimos o uso de Quadros do Azure no pacote do Azure DevOps como um único local para coletar todas as informações sobre um incidente a partir da resposta inicial. Isso nos ajuda com perguntas sobre quando um incidente foi declarado pela primeira vez, quem estava de plantão, quem foi atribuído ao incidente, e assim por diante. Você também pode usar o Wiki do Azure DevOps como uma maneira centralizada de obter algumas das informações sobre o incidente em si e a conversa que aconteceu durante o incidente.

API do Microsoft Graph para extrair a conversa

A API do Microsoft Graph fornece uma maneira programática de localizar, exportar e trazer a conversa coletada dentro do canal do Teams dedicado a esse incidente específico. Os dados recuperados também incluem metadados que serão úteis ao construir uma cronologia, incluindo quem ingressou no canal (e quando) e carimbos de data/hora para partes individuais da conversa.

Uma maneira fácil de começar a usar a API do Microsoft Graph é usar o Microsoft Graph Explorer. O Microsoft Graph Explorer é um navegador de API baseado na Web que permite que você escolha as chamadas à API escolhendo opções pré-preenchidas. É assim que parece:

Percorreremos um conjunto de chamadas à API "Microsoft Teams" e "Microsoft Teams (beta)" para recuperar a conversa. Cada etapa do caminho, escolheremos uma consulta, executaremos a consulta e selecionaremos as informações na resposta que nos ajudará com a próxima etapa. Em seguida, usamos essas informações para construir a próxima solicitação. Por exemplo, primeiro consultamos uma lista de IDs de equipe para mostrar as equipes das quais fazemos parte. Escolhemos o que precisamos na resposta e inserimos essa ID na próxima URL de consulta para obter uma lista de canais nessa equipe.

Aqui estão nossas etapas:

1. GET "minhas equipes unidas" (para encontrar a ID da equipe que usamos).
2. GET "canais de uma equipe da qual sou membro" (para encontrar a ID do canal do canal que usamos para esse incidente).
3. GET "mensagens em um canal" (para recuperar a conversa).

Se mais tarde quisermos construir um programa para executar cada uma dessas etapas (e de fato o fazemos), há uma opção de snippets de código na janela de solicitação que apresenta o código de exemplo para essa consulta em várias linguagens de programação diferentes.

Painéis direcionados para exibição de contexto

Os painéis no Azure nos permitem coletar as informações do Azure Monitor que são importantes para a conscientização operacional em uma única página. A interface do usuário nos permite escolher o período de tempo que está sendo exibido, portanto, é possível "retroceder o tempo" e mostrar as informações do painel para o período de tempo associado a um incidente, se assim escolhermos (fornecer as informações não é muito antigo para não ser mais mantido no Azure Monitor). Essa interface do usuário reconstruída pode ser útil ao tentar determinar o que as pessoas em um incidente viram durante esse incidente, mas requer que a pessoa que está fazendo a revisão de incidentes procure manualmente o período de tempo certo.

Um recurso de painéis no Azure que muitas vezes é ignorado é a capacidade de despejar um modelo de qualquer painel sendo exibido em um arquivo JSON usando o botão Baixar (seta para baixo) e carregá-los de volta com o botão Carregar (seta para cima). Isso significa que podemos procurar manualmente no momento certo, baixar o painel nesse estado e compartilhar o arquivo JSON com outras pessoas ou simplesmente baixar o painel atual e modificar o JSON para nossa especificação. Se você pesquisar a cadeia de caracteres "time" em um arquivo de painel JSON baixado, você se deparará com uma seção semelhante a 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"
          },

Modifique esta seção para sua especificação e recarregue. Se você não estiver familiarizado com o formato em uso, poderá alterar o painel manualmente, baixá-lo e ver o formato necessário.

Logs de auditoria e Log Analytics para exploração de alterações

Um workspace do Log Analytics pode receber dados de várias fontes, incluindo o Log de Atividades do Azure. Primeiro, crie um novo workspace do Log Analytics. Em seguida, vá para o recurso log de atividades no portal e escolha as configurações de diagnóstico. Isso fornece a opção de enviar o log de atividades para uma assinatura do Azure para seu novo workspace.

Em pouco tempo, você poderá usar todo o poder da KQL (Linguagem de Consulta Kusto) para recuperar informações detalhadas sobre as alterações que ocorreram nessa assinatura desde que você conectou a fonte de dados.

Por exemplo, a consulta a seguir mostra informações sobre recursos que foram alterados ou excluídos. Podemos definir o intervalo de tempo para a consulta no gerenciador de consultas para aprimorar com mais precisão o tempo pouco antes do incidente, se desejarmos.

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

Uma observação rápida: quando você define o log de atividades do Azure como uma fonte de dados, as informações começam a fluir para o workspace do Log Analytics a partir desse ponto no tempo a seguir. Você não poderá consultar esse workspace em busca de dados retroativamente para eventos que ocorreram antes de fazer a conexão.

Essas ferramentas devem ser capazes de fornecer um bom começo na coleta de informações necessárias para que uma cronologia seja usada em uma revisão pós-incidente. Antes de se aprofundar em uma revisão pós-incidente, gostaríamos de avisá-lo sobre algumas armadilhas comuns. Esse é o assunto da nossa próxima unidade.