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 refletindo a natureza não linear de um incidente.
Por não linear, queremos dizer que incidentes quase nunca são apenas "algo acontece e, em seguida, percebemos, em seguida, fazemos algo e, em seguida, terminamos". As pessoas entram e saem, pessoas diferentes percebem e tentam coisas diferentes, algumas funcionam e outras não. E, se várias pessoas estiverem trabalhando ao mesmo tempo, esses eventos também poderão acontecer ao mesmo tempo. Portanto, isso é um pouco mais complicado.
Para criar uma linha do tempo como essa, mesmo uma complexa, sempre há uma primeira etapa importante: coletar os dados.
Coletar os dados
Para realizar uma revisão pós-incidente, primeiro você precisará coletar os dados. Especificamente, você precisa coletar o máximo que conseguir da conversa e do contexto (técnico e não técnico) relacionado ao evento, para que você possa usar todos os dados cruciais contidos neles. A conversa entre os membros da equipe que ocorreu durante a interrupção ou o 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. Quais informações elas estavam recebendo dos seus sistemas quando o incidente estava acontecendo?
E, por fim, se possível, seria útil para você obter uma visão melhor do que foi alterado momentos antes e durante o incidente, pois as alterações costumam ser fatores contribuintes quando ocorre um incidente.
Podemos examinar esse processo como três partes separadas:
- Coletar a conversa: Em outros módulos neste roteiro de aprendizagem, mencionamos que é importante proporcionar um local específico para que as pessoas se comuniquem durante um incidente. Durante o incidente, idealmente as pessoas estão compartilhando o que funcionou, o que falhou, o que elas hesitam em tentar e o que elas tentaram no passado. Essa conversa das pessoas enquanto elas trabalham e resolvem o problema é a melhor fonte de aprendizado.
- Determinar o contexto: As pessoas em um incidente estão recebendo sinais de vários locais. Um local primário é o seu sistema de monitoramento. Discutimos a importância de ter um sistema de monitoramento sólido em um módulo anterior deste 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.
- Localize as alterações: Você pode fazer isso por meio de logs de auditoria e de atividade.
Ferramentas do Azure para ajudar a coletar os dados
O Azure oferece várias ferramentas que podem ajudar com esse processo:
O Azure DevOps para reter metadados sobre o incidente
Em um módulo anterior deste roteiro de aprendizagem, discutimos usando o Azure Boards no pacote do Azure DevOps como um local para coletar todas as informações sobre um incidente, a partir da resposta inicial. Ele 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 a Wiki do Azure DevOps como um modo centralizado de reunir algumas das informações sobre o incidente em si e a conversa que ocorreu durante o incidente.
API do Microsoft Graph para extrair a conversa
A API do Microsoft Graph fornece uma forma programática de localizar, 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 são úteis ao construir uma cronologia, incluindo quem ingressou no canal (e quando) e os carimbos de data/hora de partes individuais da conversa.
Uma forma fácil de começar a usar a API do Microsoft Graph é usando o Explorador do Microsoft Graph. O Explorador do Microsoft Graph é um navegador de API baseado na Web que permite que você escolha as chamadas à API escolhendo opções preenchidas previamente. Esta é a aparência dele:
Vamos percorrer um conjunto de chamadas à API do "Microsoft Teams" e do "Microsoft Teams (beta)" para recuperar a conversa. Em cada etapa, escolheremos uma consulta, executaremos a consulta e, em seguida, selecionaremos as informações na resposta que nos ajudarão na próxima etapa. Em seguida, usaremos essas informações para construir a próxima solicitação. Por exemplo, primeiro consultamos uma lista de IDs de equipe para mostrar às 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.
A seguir estão as etapas:
- GET "my joined teams" (para localizar a ID da equipe que usamos).
- GET "channels of a team which I am member of" (para localizar a ID do canal que usamos para esse incidente).
- GET "messages in a channel" (para recuperar a conversa).
Se mais tarde quiséssemos construir um programa para executar cada uma dessas etapas (e realmente fazemos isso), há uma opção snippets de código na janela da solicitação que apresenta o código de exemplo dessa 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 conscientização operacional juntos em uma página única. Se desejarmos, a interface do usuário nos permite escolher o período de tempo que está sendo exibido para que seja possível "voltar ao tempo" e mostrar as informações do painel para o período de tempo associado a um incidente (desde que as informações não sejam muito antigas e não estejam mais retidas 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 isso requer que a pessoa que está realizando a revisão do incidente busque manualmente o período de tempo certo.
Um recurso dos painéis no Azure que geralmente é ignorado é a sua capacidade de despejar um modelo de qualquer painel que esteja sendo exibido em um arquivo JSON usando o botão de Download (seta para baixo) e carregá-los novamente com o botão de Upload (seta para cima). Isso significa que podemos buscar manualmente o 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 a nossa especificação. Se você pesquisar a cadeia de caracteres "time" em um arquivo do painel JSON baixado, será exibida 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 essa seção para a sua especificação e recarregue. Se você não estiver familiarizado com o formato em uso, poderá alterar o painel manualmente, baixá-lo e exibir o formato necessário.
Logs de Auditoria e Log Analytics para exploração de alterações
Um workspace do Log Analytics pode obter dados de várias fontes, incluindo do log de atividades do Azure. Primeiro, crie um workspace do Log Analytics. Em seguida, acesse o recurso log 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 o seu novo workspace.
Em pouco tempo, você poderá usar toda a potência da KQL (Linguagem de Consulta Kusto) para recuperar informações detalhadas sobre as alterações realizadas 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. Se desejarmos, poderemos definir o intervalo de tempo da consulta no gerenciador de consultas para aprimorar com mais precisão o tempo logo antes do incidente.
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 desse momento em diante. Você não conseguirá consultar o workspace para obter dados retroativamente de eventos que ocorreram antes de você fazer a conexão.
Essas ferramentas devem ser capazes de proporcionar um bom começo na coleta de informações necessárias para serem usadas em uma cronologia na revisão pós-incidente. Antes de mergulhar diretamente em uma revisão pós-incidente, gostaríamos de avisar você sobre algumas armadilhas comuns. Esse é o assunto de nossa próxima unidade.