O processo de análise 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 cronologia como esta, incluindo uma cronologia complexa, há sempre um primeiro passo importante: recolher os dados.
Recolher os dados
Para poder realizar uma análise pós-incidente, tem de recolher os dados. Particularmente, tem de recolher o máximo de informações e contexto (técnico e não técnico) possível sobre a conversa em torno do evento, de modo a conseguir utilizar todos os dados essenciais lá contidos. A conversa entre os membros da equipa que ocorreu durante a interrupção ou o incidente será uma das melhores fontes de informação.
Também deve recolher os dados do seu sistema de monitorização e dos outros locais em que as pessoas envolvidas no incidente forneceram contexto. Que informações é que as pessoas obtiveram dos seus sistemas quando o incidente decorreu?
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 dividir este processo em três partes distintas:
- 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 dos principais locais é o seu sistema de monitorização. Falámos da importância de ter um sistema de monitorização coeso num módulo anterior deste percurso de aprendizagem. Idealmente, deveríamos ser capazes de olhar para o sistema de monitoramento para construir um instantâneo point-in-time 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 na recolha de dados
O Azure oferece uma série de ferramentas que podem ser úteis neste pro:
Azure DevOps para reter 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. Isto é útil em questões sobre quando um incidente foi declarado pela primeira vez, quem estava de serviço, quem foi designado para o incidente, etc. Pode também utilizar a Wiki do Azure DevOps como local central para obter algumas das informações sobre o incidente propriamente dito e a conversa que decorreu durante o incidente.
API Microsoft Graph para extrair a conversação
A API Microsoft Graph proporciona uma forma programática de localizar, exportar e abrir a conversação que foi recolhida no canal do Teams dedicado a este 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 forma fácil de começar a utilizar a API Microsoft Graph é utilizar o Explorador do Microsoft Graph. O Explorador do Microsoft Graph é um browser de API na Web que lhe permite escolher as chamadas à API através da seleção de opções pré-preenchidas. O aspeto é o seguinte:
Percorreremos um conjunto de chamadas de API "Microsoft Teams" e "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, vamos utilizar esta informação para construir o próximo pedido. Por exemplo, começamos por consultar uma lista de IDs de equipa para mostrar as equipas em que estamos. Escolhemos aquela de que precisamos na resposta e inserimos este ID no próximo URL de consulta para obter uma lista de canais nessa equipa.
Eis os nossos passos:
- OBTENHA "as minhas equipas associadas" (para encontrar o ID da equipa que utilizamos).
- GET "canais de uma equipe da qual sou membro" (para encontrar o ID do canal que usamos para esse incidente).
- RECEBA "mensagens em um canal" (para recuperar a conversa).
Se mais tarde quiséssemos construir um programa para executar cada uma dessas etapas (e de fato fazemos), há uma opção de trechos de código na janela de solicitação que apresenta código de exemplo para essa consulta em várias linguagens de programação diferentes.
Dashboards direcionados para apresentar o 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). Esta interface de utilizador reconstruída pode ser útil para tentar determinar o que as pessoas num incidente viram durante o mesmo, mas requer que a pessoa a fazer a análise do incidente procure manualmente o período temporal correto.
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 secção segundo as suas especificações e volte a carregar. 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 Log Analytics para exploração de mudanças
Um espaço de trabalho do Log Analytics pode receber dados de várias fontes, incluindo o Log de Atividades do Azure. Primeiro, crie uma nova área de trabalho do Log Analytics. 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 da consulta no explorador de consultas, de forma a incidir com maior precisão sobre a altura imediatamente antes do incidente, se assim 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 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.
Estas ferramentas deverão ser um bom ponto de partida para recolher informações necessárias para uma cronologia a utilizar na análise pós-incidente. Antes de iniciar uma análise pós-incidente, gostaríamos de alertar para algumas armadilhas comuns. Este é o assunto da nossa próxima unidade.