Partilhar via

Recomendações para a conceção de uma estratégia de resposta a emergências

  • Artigo

Aplica-se a esta recomendação de lista de verificação de Excelência Operacional do Azure Well-Architected Framework:

OE:08 Desenvolver uma prática eficaz de operações de emergência. Certifique-se de que sua carga de trabalho emita sinais de integridade significativos em toda a infraestrutura e código. Colete os dados resultantes e use-os para gerar alertas acionáveis que executam respostas de emergência por meio de painéis e consultas. Defina claramente as responsabilidades humanas, como rotações de permanência, gerenciamento de incidentes, acesso a recursos de emergência e execução post mortems.

Este guia descreve as recomendações para a conceção de uma estratégia de resposta a emergências. Algumas questões que surgem ao longo do ciclo de vida de uma carga de trabalho são críticas o suficiente para justificar a declaração de emergência. Você pode implementar processos e procedimentos rigorosamente controlados e focados que sua equipe pode seguir para garantir que um problema seja tratado de forma calma e ordenada. As emergências aumentam naturalmente os níveis de stress de todos e podem levar a um ambiente caótico se a sua equipa não estiver bem preparada. Para ajudar a minimizar o estresse e a confusão, projete uma estratégia de resposta, compartilhe a estratégia de resposta com sua organização e realize treinamentos regulares de resposta a emergências.

Principais estratégias de design

Uma estratégia de resposta a emergências deve ser um conjunto ordenado e bem definido de processos e procedimentos. Cada processo e procedimento deve ter scripts para garantir que cada etapa progrida sua equipe para resolver um problema de forma rápida e segura. Para desenvolver uma estratégia de resposta a emergências, considere a seguinte visão geral:

  • Pré-requisitos
    • Desenvolver uma plataforma de observabilidade
    • Criar um plano de resposta a incidentes
  • Fases do incidente
    • Detection
    • Contenção
    • Triagem
  • Fases pós-incidente
    • Análise de causa raiz (RCA)
    • Autópsia
  • Atividade em curso
    • Exercícios de resposta a emergências

As seções a seguir fornecem recomendações para cada uma dessas fases.

Para ter uma estratégia robusta de resposta a emergências, você precisa ter uma plataforma de observabilidade robusta. Sua plataforma de observabilidade deve ter as seguintes características:

  • Monitoramento holístico: certifique-se de monitorar completamente sua carga de trabalho do ponto de vista da infraestrutura e do aplicativo.

  • Registro detalhado: habilite o registro detalhado para seus componentes para ajudar nas investigações ao fazer a triagem de um problema. Estruture logs para que sejam fáceis de gerenciar. Envie automaticamente logs para coletores de dados para serem preparados para análise.

  • Painéis úteis: crie painéis baseados em modelos de integridade que são personalizados para cada equipe em sua organização. Diferentes equipes são responsáveis por diferentes aspetos da saúde da carga de trabalho.

  • Alertas acionáveis: crie alertas que são úteis para suas equipes de carga de trabalho. Evite alertas que não exijam ação de suas equipes. Demasiados alertas deste tipo podem levar as pessoas a ignorar ou bloquear notificações de alerta.

  • Notificações automáticas: certifique-se de que as equipes apropriadas recebam automaticamente alertas que exijam ação delas. Por exemplo, sua equipe de suporte de nível 1 deve receber notificações para todos os alertas, enquanto seus engenheiros de segurança só devem receber alertas para eventos de segurança.

Para obter mais informações, consulte Recomendações para projetar e criar uma estrutura de observabilidade.

Criar um plano de resposta a incidentes

A base de uma estratégia de resposta a emergências é um plano de resposta a incidentes. Como um plano de recuperação de desastres, defina de forma clara e completa funções, responsabilidades e procedimentos para um plano de resposta a incidentes. O plano deve ser um documento com controle de versão sujeito a revisões regulares que garantam sua atualização.

Defina claramente os seguintes componentes no seu plano.

Funções

Identifique um gerenciador de resposta a incidentes. Essa pessoa é proprietária do incidente desde o início até a remediação e a análise da causa raiz. Um gerente de resposta a incidentes garante que os processos sejam seguidos e as partes apropriadas sejam informadas à medida que a equipe de resposta realiza seu trabalho.

Identifique um líder post mortem. Este indivíduo garante que as autópsias são realizadas logo após a resolução do incidente. Eles produzem um relatório, que ajuda a aplicar as descobertas que saem do incidente.

Processos e procedimentos

Sua equipe de carga de trabalho deve definir e entender os critérios de emergência. Quando sua equipe determina que um caso é grave, você pode declarar um desastre e iniciar o plano de recuperação de desastres. Em casos menos graves, o problema pode não atender aos critérios de um desastre. Mas você ainda deve considerar a questão uma emergência, o que requer iniciar o plano de resposta de emergência. As emergências podem ser problemas internos à sua carga de trabalho ou podem ser o resultado de um problema com uma dependência da sua carga de trabalho. A equipe de suporte deve ser capaz de determinar se um problema relatado por usuários externos atende aos critérios de emergência, mesmo que eles não tenham visibilidade do problema subjacente.

Defina com precisão planos de comunicação e escalonamento. Com base no tipo de notificação de alerta que eles recebem, certifique-se de que seu suporte de nível 1 possa entrar em contato facilmente com as equipes apropriadas para encaminhar problemas. Certifique-se de que eles sabem que tipo de comunicação é apropriado para partes internas e externas. Nos planos de comunicação e escalonamento, inclua uma lista do horário de plantão e da equipe.

No plano geral, inclua roteiros de contenção e triagem. As equipas seguem estes procedimentos passo-a-passo quando desempenham as suas funções de contenção e triagem. Inclua uma descrição do que define um encerramento de incidente.

Outros pontos a incluir

Documente todas as ferramentas padrão que serão usadas durante incidentes para comunicação interna, como o Microsoft Teams, e para rastrear as atividades ao longo do incidente, como ferramentas de emissão de tíquetes ou ferramentas de planejamento de lista de pendências.

Documente suas credenciais de emergência, também conhecidas como contas de quebra-vidro. Inclua um guia passo a passo que descreva como eles devem ser usados.

Crie instruções de exercícios de resposta a emergências e mantenha um registro de quando os exercícios foram realizados.

Documentar quaisquer medidas legais ou regulamentares necessárias, por exemplo, comunicar violações de dados.

Agir sobre os gatilhos de observabilidade

Quando você tem uma plataforma de observabilidade bem projetada que monitora anomalias e alerta automaticamente sobre elas, você pode detetar rapidamente problemas e determinar sua gravidade. Se o problema for considerado uma emergência, o plano pode ser iniciado. Em alguns casos, a equipa de suporte não é notificada através da plataforma de observabilidade. Os clientes podem relatar problemas ao suporte usando as vias de comunicação da equipe de suporte. Ou podem entrar em contato com pessoas com quem trabalham regularmente, como executivos de contas ou VPs. Não importa como a equipe de suporte é notificada, eles devem sempre seguir as mesmas etapas para validar o problema e determinar a gravidade. O desvio do plano de resposta pode aumentar o stress e a confusão.

Definir procedimentos de contenção

A primeira etapa na correção de problemas é conter o problema para proteger o restante da sua carga de trabalho. Uma estratégia de contenção depende do tipo de problema, mas geralmente envolve a remoção do componente afetado dos caminhos de fluxo de carga de trabalho. Por exemplo, você pode desligar um recurso ou removê-lo dos caminhos de roteamento de rede. Administradores de sistemas, engenheiros e desenvolvedores seniores devem trabalhar juntos para projetar estratégias de contenção. A contenção deve limitar o raio de explosão dos problemas e manter a funcionalidade da carga de trabalho em um estado degradado até que o problema seja resolvido. Se um componente afetado precisar estar acessível para realizar a triagem, é vital que seu acesso ao restante da carga de trabalho seja bloqueado. Tanto quanto possível, você só deve acessar o componente por meio de um caminho separado da carga de trabalho e do resto dos sistemas.

Definir procedimentos de triagem

Depois de conter o problema com êxito, você pode começar o trabalho de triagem. As etapas que você segue durante a triagem dependem do tipo de problema. A equipe de uma determinada área de suporte de carga de trabalho deve criar procedimentos para incidentes relacionados à sua equipe. Por exemplo, as equipes de segurança devem fazer a triagem de problemas de segurança e devem seguir os scripts que desenvolvem. É importante que as equipes sigam scripts bem definidos enquanto trabalham em seus esforços de triagem. Esses scripts devem ser processos passo a passo que incluem processos de reversão para desfazer alterações que são ineficazes ou podem causar outros problemas. Use ferramentas prontas para agregação e análise de logs para investigar com eficiência problemas que exigem uma análise profunda. Depois que o problema for resolvido, siga processos bem definidos para trazer com segurança o componente afetado de volta aos caminhos de fluxo de carga de trabalho.

Gerar relatórios de incidentes RCA

Os contratos de nível de serviço (SLAs) para os seus clientes podem ditar que tem de emitir relatórios RCA dentro de um determinado período de tempo após a resolução do incidente. O proprietário do incidente deve criar os relatórios RCA. Se isso não for possível, outra pessoa que trabalhou em estreita colaboração com o proprietário do incidente pode criar os relatórios RCA. Esta estratégia garante uma contabilidade precisa do incidente. Normalmente, as organizações têm um modelo de RCA definido com diretrizes sobre como as informações são apresentadas e que tipos de informações podem ou não ser compartilhadas. Se você precisar criar seu próprio modelo e diretrizes, certifique-se de que eles sejam revisados e aprovados pelas partes interessadas.

Manter incidente post mortems

Um indivíduo imparcial deve liderar postmortems irrepreensíveis. Nas sessões post-mortem, todos partilham as suas conclusões sobre um incidente. Cada equipa que esteve envolvida na resposta ao incidente deve ser representada por indivíduos que trabalharam no incidente. Essas pessoas devem vir para a sessão preparadas com exemplos das áreas que foram bem-sucedidas e áreas que podem ser melhoradas. A sessão não é um fórum para atribuir culpa pelo incidente ou problemas que possam ter surgido durante a resposta. O líder post mortem deve sair da sessão com uma lista clara de itens de ação que se concentram na melhoria, tais como:

  • Melhorias no plano de resposta. Processos ou procedimentos podem precisar ser reavaliados e reescritos para capturar melhor as ações apropriadas.

  • Melhorias na plataforma de observabilidade. Os limites podem precisar ser reavaliados para detetar o tipo específico de incidente mais cedo ou um novo monitoramento pode precisar ser implementado para detetar comportamentos que não foram contabilizados.

  • Melhorias na carga de trabalho. O incidente pode expor uma vulnerabilidade na carga de trabalho que deve ser tratada como uma correção permanente.

Considerações

Uma estratégia de resposta excessivamente agressiva pode levar a falsos alarmes ou escalonamentos desnecessários.

Da mesma forma, a implementação agressiva de dimensionamento automático ou outras ações de autorrecuperação para responder a violações de limites pode levar a despesas desnecessárias e encargos de gestão. Talvez você não saiba os limites exatos a serem definidos para alertas e ações automáticas, como dimensionamento. Realize testes em ambientes inferiores e em produção para ajudá-lo a determinar os limites certos para suas necessidades.

Facilitação do Azure

O Azure Monitor é uma solução abrangente para coletar, analisar e responder a dados de monitoramento de ambientes locais e na nuvem. Ele inclui uma plataforma de alerta robusta que você pode configurar para notificações automáticas e outras ações, como dimensionamento automático e outros mecanismos de autorrecuperação.

Use o Monitor para integrar o aprendizado de máquina. Automatize e otimize a triagem de incidentes e medidas proativas. Para obter mais informações, consulte AIOps e aprendizado de máquina no Monitor.

O Log Analytics é uma ferramenta de análise robusta integrada ao Monitor. Você pode usar o Log Analytics para executar consultas em logs agregados e obter informações sobre sua carga de trabalho.

A Microsoft oferece treinamento de preparação para incidentes relacionados ao Azure. Para obter mais informações, consulte Introdução à prontidão para incidentes do Azure e Prontidão para incidentes.

Lista de verificação de Excelência Operacional

Consulte o conjunto completo de recomendações.

Lista de verificação de Excelência Operacional