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; algumas funcionam, outras 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 suas fontes de informação mais ricas.

Você também deve coletar dados do seu sistema de monitoramento e de outros lugares que as pessoas envolvidas no incidente contextualizaram. 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 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 poder examinar o sistema de monitoramento para criar um instantâneo pontual para o período próximo ou relacionado ao incidente.
• Encontre as alterações: você pode fazer isso por meio de logs de atividade e auditoria.

Azure ferramentas para ajudar a coletar os dados

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

Azure DevOps para armazenar metadados sobre o incidente

Em um módulo anterior neste roteiro de aprendizagem, discutimos o uso de Azure Boards no conjunto de 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 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.

Microsoft API do Graph para extrair a conversa

O Microsoft API do Graph fornece uma maneira programática de recuperar a conversa coletada dentro do canal do Teams dedicado a esse incidente específico. Os dados recuperados incluem carimbos de data/hora, autoria, edições, respostas e algumas mensagens do sistema, que podem ajudar na construção de uma cronologia.

Uma maneira fácil de começar a usar a API de Microsoft Graph é usar o Gerenciador de Microsoft Graph. Microsoft Graph Explorer é um navegador de API baseado na Web que permite escolher chamadas de API de um painel de Consultas de amostras e experimentá-las interativamente.

Antes de executar as consultas, verifique se o usuário ou o aplicativo que você está usando tem as permissões e o consentimento necessários para o modo de acesso escolhido. Em cenários delegados, a listagem de equipes unidas usa Team.ReadBasic.All, a listagem de canais usa Channel.ReadBasic.All e a leitura de mensagens de canal exige ChannelMessage.Read.All. Se posteriormente você automatizar o fluxo de trabalho com acesso somente para o aplicativo, use GET /users/{id | user-principal-name}/joinedTeams em vez do alias /me/joinedTeams, utilizando a permissão de aplicativo Team.ReadBasic.All. Para as etapas de leitura específicas do canal, as opções com privilégios mínimos, exclusivas do aplicativo, são ChannelSettings.Read.Group para listar canais e ChannelMessage.Read.Group para ler mensagens, ambas com consentimento específico do recurso.

Percorreremos um conjunto de chamadas de API do Microsoft Graph v1.0 para o "Microsoft Teams" a fim de recuperar a conversa. (As mensagens do canal passaram da versão beta para a v1.0 há alguns anos, portanto, os endpoints beta não são mais necessários para este cenário.) A cada etapa, 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 aquela que precisamos da resposta e inserimos essa ID na próxima URL de consulta para obter uma lista de canais nessa equipe.

Aqui estão nossas etapas, mostradas como pontos de extremidade Microsoft Graph v1.0:

1. GET /me/joinedTeams (para localizar a ID da equipe que usamos em um cenário delegado) ou GET /users/{id | user-principal-name}/joinedTeams (para fazer o mesmo em um cenário somente de aplicativo).
2. GET /teams/{team-id}/channels (para localizar a ID do canal que usamos para esse incidente).
3. GET /teams/{team-id}/channels/{channel-id}/messages?$expand=replies (para recuperar a conversa em tópicos).
4. Siga @odata.nextLink e replies@odata.nextLink quando necessário, ou chame GET /teams/{team-id}/channels/{channel-id}/messages/{message-id}/replies para percorrer discussões maiores.

Se você usou um canal compartilhado, observe que a joinedTeams API não retorna a equipe de host para um canal compartilhado do qual o usuário é membro direto. Esta ressalva se aplica independentemente de você chamar GET /me/joinedTeams ou GET /users/{id | user-principal-name}/joinedTeams. Nesse caso, comece com os identificadores de equipe e canal conhecidos ou use as APIs de equipe associadas para localizar a equipe de host.

No Graph Explorer, você pode inserir esses URLs diretamente ou selecionar as entradas equivalentes no painel integrado de exemplos de consultas no Microsoft Teams.

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.

Dependendo de como sua equipe usa o Teams, o histórico de mensagens também pode conter mensagens do sistema que ajudam a explicar quando os membros foram adicionados ou removidos. No entanto, se você precisar de um registro detalhado de auditoria da associação de canais ou alterações de acesso, complemente esses dados com logs de auditoria do Microsoft 365.

Painéis de controle e pastas de trabalho para visualização de contexto

Azure dashboards e blocos de notas do Azure Monitor podem ajudar a reconstruir o contexto que os operadores viram durante um incidente. Os painéis são úteis para uma visão geral operacional rápida nos serviços de Azure. As pastas de trabalho geralmente são as mais adequadas para análise de incidentes porque dão suporte a consultas, parâmetros, detalhamentos e texto narrativo mais avançados ao lado de gráficos.

Se você já tiver um painel ou pasta de trabalho que capture os sinais certos, defina seu intervalo de tempo para o período ao redor do incidente e use-o para reconstruir o que as pessoas viram na época. Isso pode ser especialmente útil ao correlacionar métricas, logs e alertas em vários recursos.

Os painéis compartilhados são Azure recursos e ainda podem ser exportados como JSON do portal. Esse caminho de exportação/importação é útil quando você deseja versionar ou templatizar um painel. No entanto, para a maioria dos cenários de investigação pós-incidente, as pastas de trabalho são a ferramenta mais flexível porque permitem combinar visualizações, consultas KQL e texto explicativo em um único artefato.

Logs de atividades, logs de recursos e Log Analytics para exploração de alterações

Um espaço de trabalho de análise de logs pode receber dados de diversas fontes, incluindo o log de atividades do Azure, os logs de recursos do Azure e diagnósticos específicos do serviço. Primeiro, crie um novo workspace Log Analytics. Em seguida, no portal Azure, abra Monitor → Activity log e selecione Export Activity Logs na parte superior do painel. Isso abre uma configuração de diagnóstico que permite enviar o log de atividades de uma assinatura do Azure para o seu espaço de trabalho.

Em pouco tempo, você poderá usar a 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 na experiência de Registros para focar com mais precisão no período imediatamente anterior ao 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

Essa consulta é útil para alterações no plano de gerenciamento, mas lembre-se do que ela não mostra. AzureActivity captura operações de plano de controle, como criar, atualizar, excluir e ações de política. Ele não captura alterações no nível do aplicativo ou do plano de dados dentro de um serviço. Para investigá-los, combine essa consulta com logs de recursos do Azure, logs de auditoria específicos do serviço, histórico de implantação e registros de CI/CD ou de controle de versão.

Uma observação rápida: quando você exporta o log de atividades do Azure, as informações começam a fluir para o workspace do Log Analytics a partir desse momento. Você não poderá consultar esse workspace 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.