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 reflita a natureza não linear de um incidente.

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

Para criar uma linha do tempo como esta, mesmo que complexa, há sempre um primeiro passo importante: reunir os dados.

Reunir os dados

Antes de realizar uma revisão pós-incidente, você precisa primeiro coletar dados. Especificamente, você precisa coletar o máximo possível da conversa e do contexto (técnico e não técnico) em torno do evento 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 suas fontes mais ricas de informação.

Também deve reunir dados do seu sistema de monitorização e de outros locais dos quais as pessoas envolvidas no incidente obtiveram contexto. Que informações eles estavam recebendo de seus sistemas quando o incidente estava acontecendo?

E, finalmente, se possível, seria útil para você ter uma imagem melhor do que mudou pouco antes e durante o incidente, porque as mudanças são muitas vezes fatores que contribuem quando um incidente ocorre.

Podemos olhar para este processo como três partes separadas:

• Colete a conversa: Em outros módulos deste caminho de aprendizagem, mencionamos que é importante criar um lugar específico para as pessoas se comunicarem durante um incidente. Durante o incidente, o ideal é que as pessoas compartilhem o que funcionou e o que falhou, o que hesitam em tentar, o que tentaram no passado. Esta conversa entre as pessoas à medida que trabalham e resolvem o problema é a sua melhor fonte de aprendizagem.
• Determine o contexto: As pessoas em um incidente estão recebendo sinais de vários lugares. Um lugar principal é o seu sistema de monitoramento. Discutimos a importância de ter um sistema de monitoramento sólido em um módulo anterior neste caminho de aprendizagem. Idealmente, deveríamos ser capazes de olhar para o sistema de monitorização para construir um instantâneo de um ponto no tempo para o período de tempo ao redor 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 reunir os dados

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

Azure DevOps para armazenar metadados sobre o incidente

Em um módulo anterior neste caminho de aprendizagem, discutimos o uso do Azure Boards no pacote de DevOps do Azure 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 designado para o incidente e assim por diante. Você também pode usar o Wiki de DevOps do Azure 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 encontrar, exportar e trazer a conversa que foi 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 entrou 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 de API escolhendo opções pré-preenchidas. Veja como é:

Percorreremos um conjunto de chamadas de API do "Microsoft Teams" e do "Microsoft Teams (beta)" para recuperar a conversa. Em cada etapa do processo, escolheremos uma consulta, executaremos a consulta e, em seguida, selecionaremos as informações da resposta que nos ajudarão na 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 aquele de que precisamos da resposta e inserimos esse ID na URL seguinte de consulta para obter uma lista de canais nessa equipa.

Aqui estão os nossos passos:

1. OBTENHA "as minhas equipas associadas" (para encontrar o ID da equipa que utilizamos).
2. GET "canais de uma equipa da qual sou membro" (para encontrar o identificador do canal que utilizámos para esse incidente).
3. OBTENHA "mensagens num canal" (para recuperar a conversa).

Se mais tarde quiséssemos construir um programa para executar cada uma dessas etapas (e de fato fazemos), há um trechos de código opção na janela de solicitação que apresenta 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 permitem-nos recolher as informações do Azure Monitor que são importantes para nós para a consciência operacional em conjunto numa ú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 desejarmos (desde que as informações não sejam muito antigas para não serem mais retidas no Azure Monitor). Essa interface de usuário reconstruída pode ser útil ao tentar determinar o que as pessoas em um incidente viram durante esse incidente, mas exige que a pessoa que faz a revisão do incidente procure manualmente o período de tempo certo.

Um recurso dos painéis no Azure que muitas vezes é negligenciado é sua capacidade de despejar um modelo de qualquer painel que está sendo exibido em um arquivo JSON usando o botão Baixar (seta para baixo) e carregá-los novamente 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 de acordo com nossa especificação. Se você pesquisar a string "time" em um arquivo de painel JSON baixado, encontrará uma seção parecida com 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 de acordo com sua especificação e faça o upload novamente. Se você não estiver familiarizado com o formato em uso, poderá alterar o painel manualmente, baixá-lo e ver o formato necessário.

Registos de auditoria e análise de registos para análise detalhada de alterações

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

Em pouco tempo, você poderá usar todo o poder da Kusto Query Language (KQL) 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 explorador de consultas para afinarmos de forma mais precisa o tempo pouco antes do incidente, caso assim desejemos.

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 espaço de trabalho do Log Analytics a partir desse momento. Você não poderá consultar esse espaço de trabalho em busca de dados retroativamente para eventos que ocorreram antes de fazer a conexão.

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