Remediação

Dividir o ciclo de vida da resposta a incidentes em cinco fases como você viu neste módulo ajuda você a entender o processo, mas as fases nem sempre são tão distintas quanto aparecem no diagrama. Em particular, a linha entre as fases de resposta e remediação geralmente começa a se confundir. Isso é especialmente verdadeiro quando ações destinadas a atenuar ou melhorar a situação têm o efeito oposto. Nesse caso, a resposta e a correção tendem a se sobrepor ou ir e voltar entre os dois.

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 observar: você não deve tomar as medidas descritas aqui 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ê pode descrever exatamente o que precisa ser feito e em que ordem corrigir um problema, é o momento perfeito para ensinar essas etapas a uma máquina para que o sistema possa fazer isso por você.

Por onde começar

Você aprendeu sobre a importância de reduzir o tempo necessário para responder a um incidente. Agora vamos examinar algumas coisas que podem ajudar a acelerar o processo de correção ou corrigir o problema.

Membros diferentes da equipe podem ter modelos mentais diferentes de como as coisas funcionam e ideias diferentes sobre qual deve ser o primeiro passo. Um pode primeiro examinar os logs, enquanto outro pode primeiro executar consultas e examinar as métricas. Não há um único caminho correto para o sucesso.

No entanto, ajuda a fornecer às pessoas contexto e orientação sobre onde elas devem ir e o que elas devem olhar.

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 colocar os sistemas em execução para atender aos seus objetivos de confiabilidade.

Quais recursos são úteis para os socorristas?

A próxima consideração é determinar essas coisas que os socorristas 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 do Azure/guia de solução de problemas, se possível. Falaremos sobre eles em apenas um momento.

Também é útil fornecer links simples para recursos (geralmente em um guia de solução de problemas). Se seu objetivo for responder e corrigir o problema o mais rápido possível, ajudar as pessoas a encontrar as respostas para perguntas sem precisar pesquisar o documento ou URL certo acelerará o processo.

Atualizar stakeholders

Você pode se concentrar tanto em corrigir o problema que pode esquecer que há muitas pessoas que não estão diretamente envolvidas na resposta ao incidente, mas que querem e precisam saber o que está acontecendo.

É importante se comunicar com outras equipes internas e mantê-las informadas do que está acontecendo quando ocorre um incidente. Se você não fornecer atualizações consistentes a elas, provavelmente elas aparecerão solicitando uma atualização de status. Eles têm todo o direito a essas informações, mas você precisa de uma maneira melhor de torná-los cientes do problema e do que está sendo feito sobre isso.

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 definir expectativas em termos de quando eles terão resposta de você.

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 impedir que os stakeholders venham até você e interrompam você quando você estiver no meio da tentativa de corrigir os problemas.

Uma maneira de distribuir essas informações é por meio do uso de uma página da Web de status facilmente editável, como a que mencionamos 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 pastas de trabalho e guias de solução de problemas do Azure Monitor

O Azure tem dois recursos intimamente relacionados que podem ser tremendamente ú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 este módulo, eles são intercambiáveis, tendo, inclusive, a mesma interface do usuário. Você pode encontrar Workbooks do Azure Monitor no portal do Azure, em Azure Monitor. Você encontrará guias de solução de problemas do Azure Insights no portal do Azure quando uma instância do Application Insight tiver sido selecionada.

Você pode pensar em pastas de trabalho e guias de solução de problemas como "documentos dinâmicos" que você pode criar usando uma interface de criação de página. Ao criar um novo, você pode adicionar à página:

• Texto arbitrário, como uma lista com marcadores de itens a fazer ou outras informações úteis para alguém consultar a página
• Links com outros sistemas, por exemplo, conexões com outros dashboards ou documentação
• consultas do KQL (Linguagem de Consulta Kusto)

É o último item que torna o documento "ativo". Em um módulo anterior neste roteiro de aprendizagem, exploramos a linguagem de consulta KQL integrada ao Log Analytics e outras partes do Azure Monitor. Usando esse idioma, 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 "Certifique-se de verificar a taxa de erros no servidor Web", mas também pode mostrar um grafo atual para essa taxa de erros bem ali 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 diretamente à documentação necessária.

O Azure também fornece alguns modelos existentes para ajudá-lo a começar a criar seus próprios documentos. Aqui está uma captura de tela de alguns dos modelos pré-fabricados que você pode oferecer:

Há um recurso de editor avançado para pastas de trabalho e guias de solução de problemas que permitem acessar e inserir um JSON ou uma representação de modelo do Azure Resource Manager desse documento. Isso significa que é possível rastrear e distribuir esses documentos usando o sistema de controle do código-fonte de sua escolha. Ele também permite automatizar o provisionamento de pastas de trabalho ou guias de solução de problemas, o que é útil para quando você está provisionando outra infraestrutura. Criar um conjunto de documentos de solução de problemas personalizados para usar um novo serviço no momento em que o serviço é provisionado torna-se fácil usando essa prática recomendada.

Outras dicas e ferramentas úteis

Ao longo deste módulo, você aprendeu sobre as várias ferramentas e atalhos que pode usar para aumentar a eficiência e reduzir o tempo de resposta a incidentes. Ao encerrarmos esta última unidade, faremos uma breve visão geral de algumas ferramentas e técnicas que são úteis para diagnosticar 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 itens principais que você precisará como ponto de partida. Observe que ele não inclui o Azure Service Health. Você deve fixar isso no painel para verificar se o problema é com seus sistemas ou com o próprio serviço de nuvem.
• Você pode usar o Mapa do Aplicativo no Application Insights para detalhar exatamente o que está acontecendo para causar 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 anteriores são inestimáveis na correção de problemas.