Remediação

Concluído

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 distintas quanto aparecem no diagrama. Em particular, a linha entre as fases de resposta e remediação começa muitas vezes a não ser muito clara. Isto é particularmente verdade quando as ações destinadas a mitigar ou melhorar a situação têm o efeito oposto. Neste caso, a resposta e a remediação tendem a sobrepor-se ou a alternar entre si.

Cycle diagram of circles labeled with incident responses phases. Circles are connected to next circle with arrows from phase to phase. Detections, Response, and Remediation are highlighted.

Nesta unidade, você aprenderá mais sobre a remediaçã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 já tiver uma lista de verificação para a remediação, isso geralmente significa que é altura de introduzir a automatização. Quando você pode descrever exatamente o que precisa ser feito e em que ordem para remediar um problema, é o momento perfeito para ensinar essas etapas a uma máquina para que o sistema possa fazer isso por você.

Onde começar

Ficou a saber a importância de reduzir o tempo que demora a responder a um incidente. Agora, vamos analisar algumas questões que podem ajudar a acelerar o processo de remedição ou correção do problema.

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

No entanto, ajuda a fornecer às pessoas contexto e orientação para o caminho a seguir e o que se deve analisar.

Como e a quem escalar

Uma pergunta importante a responder na formulação do seu ponto de partida na remediação é: quando fica bloqueado, a quem pode ligar para escalar o problema? Deve tentar passar mais responsabilidades da equipa de serviço para a equipa em geral e não apenas para as Operações e para a Engenharia de Fiabilidade do Site. Deve ser da responsabilidade de todos os membros da equipa ter os sistemas em funcionamento para cumprir os seus objetivos de fiabilidade.

Que recursos são úteis para as primeiras pessoas a dar resposta?

A próxima consideração é determinar o que as primeiras pessoas a dar resposta podem utilizar para começar o processo. Por exemplo, tal pode incluir métricas, registos ou consultas relevantes. Se for possível, estes devem ser fornecidos num livro/guia resolução de problemas do Azure. Falaremos sobre eles daqui a pouco.

Também é útil fornecer links simples para recursos (geralmente em um guia de solução de problemas). Se o seu objetivo for dar resposta e remediar o problema o mais rapidamente possível, ajudar as pessoas a encontrar as respostas às perguntas sem terem de procurar o documento ou URL certo vai permitir acelerar o processo.

Informar os intervenientes

Você pode ficar tão focado em resolver 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 comunicar com outras equipas internas e mantê-las informadas sobre o que está a acontecer quando ocorre um incidente. Se você não fornecer atualizações consistentes, é provável que eles venham por aí pedindo uma atualização de status. Eles têm todo o direito a essas informações, mas você precisa de uma maneira melhor de conscientizá-los sobre o problema e o que está sendo feito a respeito.

Tem de ser claro quanto ao reconhecimento das suas equipas internas. Seja claro ao apresentar o que você sabe e o que está sendo feito e defina expectativas em termos de quando eles ouvirão de você.

A fórmula para as suas comunicações com os intervenientes é simples:

  • Isto é o que sabemos.
  • É isso que estamos fazendo.
  • Entraremos em contacto consigo dentro de X períodos de tempo.

Isso ajudará a evitar que as partes interessadas venham até você e o interrompam quando você estiver tentando corrigir os problemas.

Uma forma de distribuir estas informações é através da utilização de uma página Web com estado facilmente editável como a que mencionámos na última unidade. Em muitos casos, você pode querer ter uma página de status separada e mais detalhada para as partes interessadas internas e uma página externa para seus clientes. A fórmula anterior funciona para ambos os casos.

Utilizar os Livros e os Guias de Resolução de Problemas do Azure Monitor

O Azure tem dois recursos intimamente 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 o propósito deste módulo, eles são intercambiáveis, inclusive tendo a mesma interface de usuário. Você pode encontrar Pastas de Trabalho do Azure Monitor no portal do Azure em Azure Monitor. Você encontrará os Guias de Solução de Problemas do Azure Insights no portal do Azure quando uma instância do Applications Insight for 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. Quando cria um novo, pode adicionar à página:

  • Texto arbitrário, como uma lista com marcadores de itens a fazer ou outras informações úteis para alguém que consulte a página
  • Links para outros sistemas, por exemplo, links para outros painéis ou documentação
  • Consultas KQL (Linguagem de Consulta Kusto)

É esse último item que torna o documento "vivo". Em um módulo anterior neste caminho de aprendizagem, exploramos a linguagem de consulta KQL incorporada ao Log Analytics e outras partes do Azure Monitor. Com recurso a esta linguagem, poderíamos escrever as nossas próprias consultas para devolver e apresentar informações de diagnóstico da nossa aplicação 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. Isto significa que o seu guia de resolução de problemas pode indicar não só "Certifique-se de verificar a taxa de erro no servidor Web", mas também pode mostrar um gráfico atual para essa taxa de erro ao lado das instruções. Pode ter uma ligação como "eis a documentação de reinício do servidor Web" que faz com que a primeira pessoa a dar resposta consiga aceder de imediato à documentação necessária.

O Azure também fornece alguns modelos existentes para o ajudar a começar a criar os seus próprios documentos. Eis uma captura de ecrã de alguns dos modelos previamente criados que lhe podem ser fornecidos:

Screenshot of default example troubleshooting guides as found in the Azure portal.

Há um recurso de editor avançado para pastas de trabalho e guias de solução de problemas que permitem acessar e inserir uma representação de modelo JSON ou do Azure Resource Manager desse documento. Isso significa que é possível rastrear e distribuir esses documentos usando o sistema de controle de origem 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ê estiver provisionando outra infraestrutura. Criar um conjunto de documentos de solução de problemas personalizados para acompanhar um novo serviço no momento em que o serviço é provisionado torna-se fácil usando essa prática recomendada.

Outras sugestões e ferramentas úteis

Ao longo deste módulo, você aprendeu sobre as várias ferramentas e atalhos que você 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 Painel do aplicativo no Application Insights para gerar automaticamente um painel que tenha a maioria dos principais itens necessários como ponto de partida. Observe que ele não inclui a Integridade do Serviço do Azure. Deve afixar isto no dashboard para verificar se o problema reside nos seus sistemas ou no próprio serviço cloud.
  • Você pode usar o Mapa do Aplicativo no Application Insights para detalhar exatamente o que está acontecendo para causar os problemas. Pode seguir os trilhos para encontrar a causa do erro (por exemplo, um URL com formato incorreto).
  • 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.

Verifique o seu conhecimento

1.

Quando você se comunica com as partes interessadas, qual desses itens é desnecessário na fórmula que sugerimos?

2.

Porque é que os livros e os guias de resolução de problemas são considerados documentos dinâmicos na nossa descrição?