Remediação
Dividir o ciclo de vida da resposta a incidentes em cinco fases, como você viu neste módulo, ajuda a entender o processo, mas as fases nem sempre são tão diferentes quanto parecem no diagrama. Em particular, o limiar entre as fases de resposta e correção muitas vezes não é totalmente claro. Isso é especialmente verdadeiro quando ações destinadas a mitigar ou melhorar a situação têm o efeito oposto. Nesse caso, a resposta e a correção tendem a se sobrepor ou formar um loop em que cada uma delas leva à outra.
Nesta unidade, você aprenderá mais sobre a correção e as etapas que compõem essa fase, bem como algumas dicas e ferramentas úteis. Uma coisa importante a ser observada: as medidas descritas aqui não devem ser vistas como uma lista de verificação prescritiva.
Se você realmente tiver uma lista de verificação para correção já em mãos, isso geralmente é um indicador de que é hora de colocar a automação em cena. Quando você consegue descrever exatamente o que precisa ser feito e em qual ordem fazê-lo para corrigir um problema, esse é o momento perfeito para ensinar essas etapas a um computador para que o sistema possa fazer isso para você.
Onde começar
Você aprendeu sobre a importância de reduzir o tempo necessário para responder a um incidente. Agora, vamos ver algumas coisas que podem ajudar a acelerar o processo de mitigação ou correção do problema.
Diferentes membros da equipe podem ter modelos mentais distintos de como as coisas funcionam e ideias diferentes sobre qual deve ser a primeira etapa. Um pode começar verificando os logs, enquanto outro pode primeiro realizar consultas e verificar as métricas. Não há um único caminho correto para o sucesso.
No entanto, é útil fornecer às pessoas contexto e diretrizes sobre que rumo elas devem tomar e que informações devem examinar.
Como e para quem escalonar
Uma pergunta importante a ser respondida no formular seu ponto de partida de correção é: quando você fica preso, para quem você pode ligar para escalonar o problema? Você deve estar tentando repassar para a equipe em geral uma parte maior das responsabilidades de estar disponível a solicitações, não apenas operações ou engenharia de confiabilidade do site. Deve ser responsabilidade de todos os membros da equipe manterem os sistemas em funcionamento para atender aos seus objetivos de confiabilidade.
Quais recursos são úteis para os primeiros respondentes?
A próxima consideração é determinar as coisas que os primeiros respondentes podem usar para começar o processo. Isso pode incluir métricas relevantes, logs, consultas e assim por diante. Eles devem ser fornecidos em uma pasta de trabalho/guia de solução de problemas do Azure, se possível. Falaremos sobre isso daqui a pouco.
Também é útil fornecer links simples para recursos (geralmente em um guia de solução de problemas). Se seu objetivo é responder ao problema e corrigi-lo o mais rápido possível, ajudar as pessoas a encontrar as respostas a perguntas sem que precisem pesquisar a URL ou o documento correto é algo que agiliza o processo.
Atualizar stakeholders
Você pode se concentrar tanto em corrigir o problema que pode se esquecer de que existem muitas pessoas que não estão diretamente envolvidas na resposta ao incidente, mas que querem e precisam saber o que está acontecendo.
É importante comunicar-se com outras equipes internas e mantê-las informadas sobre o que está acontecendo quando um incidente ocorre. Se você não fornecer atualizações constantes, é provável que essas equipes venham até você em busca de informações. Elas têm todo o direito de obter essas informações, mas você precisa de uma forma melhor de mantê-las informadas sobre o problema e o que está sendo feito para resolvê-lo.
Você precisa ser claro com suas equipes internas quanto ao reconhecimento das informações. Seja claro ao apresentar o que você sabe e o que está sendo feito e estabeleça as expectativas em termos de quando você terá novidades para elas.
A fórmula para suas comunicações com os stakeholders é simples:
- É isso o que sabemos.
- É isso que estamos fazendo.
- Retornaremos a você em um período de tempo X.
Isso ajudará a evitar que os stakeholders tomem a iniciativa de procurar você a você e o interrompam enquanto você estiver tentando resolver os problemas.
Uma forma de distribuir essas informações é por meio do uso de uma página da Web de status facilmente editável, como aquela mencionada na última unidade. Em muitos casos, talvez você queira ter uma página de status separada e mais detalhada para stakeholders internos e uma externa para seus clientes. A fórmula anterior funciona para ambos os casos.
Usar Guias de Solução de Problemas e Pastas de Trabalho do Azure Monitor
O Azure tem dois recursos bem relacionados que podem ser extremamente úteis para uma equipe na fase de correção: Pastas de Trabalho do Azure Monitor e Guias de Solução de Problemas do Application Insights. Para os fins deste módulo, elas são intercambiáveis e, inclusive, têm a mesma interface do usuário. Você pode encontrar o Azure Monitor Workbooks no portal do Azure, dentro do Azure Monitor. Você encontrará os Guias de Solução de Problemas do Azure Insights no portal do Azure quando uma instância do Application Insights for selecionada.
Você pode pensar nas pastas de trabalho e nos guias de solução de problemas como se fossem "documentos dinâmicos" que você pode criar usando uma interface de criação de páginas. Ao criar um, você pode adicionar à página:
- Textos arbitrários, como uma lista com marcadores ou outras informações úteis para quem consulta a página
- Links para outros sistemas, como por exemplo, links para outros painéis de controle ou documentação
- consultas do KQL (Linguagem de Consulta Kusto)
É esse último item que torna o documento "dinâmico". Em um módulo anterior deste roteiro de aprendizagem, exploramos a linguagem de consulta KQL integrada a Log Analytics e outras partes do Azure Monitor. Usando essa linguagem, poderíamos escrever nossas próprias consultas para retornar e exibir informações de diagnóstico de nosso aplicativo e da infraestrutura do Azure. Quando uma consulta KQL é inserida em uma pasta de trabalho ou guia de solução de problemas, os resultados atuais dessa consulta são exibidos ao vivo para os leitores do documento. Isso significa que o guia de solução de problemas pode dizer não apenas "não se esqueça de verificar a taxa de erros no servidor Web", mas também pode mostrar um grafo atual para essa taxa de erro logo em seguida, ao lado das instruções. Ele pode ter um link como "aqui está a documentação de reinicialização do servidor Web", que leva o primeiro respondente à documentação de que ele precisa.
O Azure também fornece alguns modelos existentes para ajudar você a começar a criar seus próprios documentos. Aqui está uma captura de tela de alguns dos modelos predefinidos que podem ser oferecidos a você:
Há um recurso de Editor avançado para Pastas de Trabalho e guias de solução de problemas que permite acessar e inserir uma representação em JSON ou um modelo do Azure Resource Manager desse documento. Isso significa que é possível acompanhar e distribuir esses documentos usando o sistema de controle do código-fonte de sua escolha. Também permite automatizar o provisionamento de pastas de trabalho ou guias de solução de problemas, o que é útil quando você está provisionando outras infraestruturas. A criação de um conjunto de documentos de solução de problemas personalizado para acompanhar um novo serviço quando o serviço é provisionado se torna um procedimento fácil usando essa prática recomendada.
Outras dicas e ferramentas úteis
Ao longo deste módulo, você aprendeu sobre as diversas ferramentas e atalhos que pode usar para aumentar a eficiência e reduzir o tempo de resposta a incidentes. Ao finalizarmos esta última unidade, faremos uma breve visão geral de algumas ferramentas e técnicas que são úteis no diagnóstico de problemas em seus sistemas.
- Você pode usar o link do Painel de Aplicativos no Application Insights para gerar automaticamente um painel que tenha a maioria dos principais itens de que você precisará como ponto de partida. Observe que isso não inclui a Integridade do Serviço do Azure. Você deve fixá-lo em seu painel para verificar se o problema está em seus sistemas ou com o próprio serviço de nuvem.
- Você pode usar o Mapa do Aplicativo no Application Insights para analisar exatamente o que está acontecendo e causando os problemas. Você pode seguir as pistas para localizar a causa do erro (por exemplo, uma URL malformada).
- Você pode usar o Log Analytics para consultar qualquer parte do sistema.
Todas as ferramentas mencionadas são indispensáveis na correção de problemas.