Share via

Recomendações para criar 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 Desenvolva uma prática eficaz de operações de emergência. Verifique se a carga de trabalho emite sinais de integridade significativos entre a infraestrutura e o código. Colete os dados resultantes e use-os para gerar alertas acionáveis que geram respostas de emergência por meio de painéis e consultas. Defina claramente as responsabilidades humanas, como rotações de chamada, gerenciamento de incidentes, acesso a recursos de emergência e execução de pós-morte.

Este guia descreve as recomendações para criar uma estratégia de resposta a emergências. Alguns problemas que surgem ao longo do ciclo de vida de uma carga de trabalho são críticos o suficiente para justificar a declaração de emergências. Você pode implementar processos e procedimentos fortemente controlados e focados que sua equipe pode seguir para garantir que um problema seja tratado de maneira calma e ordenada. Emergências naturalmente aumentam os níveis de estresse de todos e podem levar a um ambiente caótico se sua equipe não estiver bem preparada. Para ajudar a minimizar o estresse e a confusão, crie uma estratégia de resposta, compartilhe a estratégia de resposta com sua organização e execute treinamentos regulares de resposta a emergências.

Principais estratégias de design

Uma estratégia de resposta de emergência deve ser um conjunto ordenado e bem definido de processos e procedimentos. Cada processo e procedimento devem 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 de incidente
    • Detecção
    • Contenção
    • Triagem
  • Fases pós-incidente
    • RCA (análise de causa raiz)
    • Análise posterior
  • Atividade contínua
    • Análises de resposta de emergência

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

Observabilidade

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

  • Monitoramento holístico: certifique-se de monitorar completamente sua carga de trabalho de uma perspectiva de infraestrutura e aplicativo.

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

  • Painéis úteis: crie painéis baseados em modelo de integridade que são adaptados para cada equipe em toda a sua organização. Equipes diferentes são responsáveis por diferentes aspectos da integridade da carga de trabalho.

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

  • Notificações automáticas: verifique se as equipes apropriadas recebem automaticamente alertas que exigem ação deles. Por exemplo, sua equipe de suporte de camada 1 deve receber notificações para todos os alertas, enquanto os 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.

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 desastre, defina de forma clara e completa funções, responsabilidades e procedimentos para um plano de resposta a incidentes. O plano deve ser um documento controlado por versão sujeito a revisões regulares que garantem que ele esteja atualizado.

Defina claramente os seguintes componentes em seu plano.

Funções

Identificar um gerenciador de resposta a incidentes. Essa pessoa possui o incidente desde a inicialização até a correção até a análise da causa raiz. Um gerenciador de resposta a incidentes garante que os processos sejam seguidos e as partes apropriadas sejam informadas à medida que a equipe de resposta executa seu trabalho.

Identifique um líder pós-morte. Esse indivíduo garante que as pós-morte sejam executadas logo após a resolução do incidente. Eles produzem um relatório, que ajuda você 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 desastre. 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, que requer o início do plano de resposta de emergência. Emergências podem ser problemas internos à sua carga de trabalho ou podem ser resultado de um problema com uma dependência de 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 os planos de comunicação e escalonamento. Com base no tipo de notificação de alerta que eles recebem, verifique se o suporte de camada 1 pode entrar em contato facilmente com as equipes apropriadas para escalonar problemas. Verifique se eles sabem qual tipo de comunicação é apropriado para partes internas e externas. Em planos de comunicação e escalonamento, inclua uma lista do agendamento de plantão e da equipe.

No plano geral, inclua scripts de contenção e triagem. As equipes seguem esses procedimentos passo a passo quando executam suas funções de contenção e triagem. Inclua uma descrição do que define um fechamento de incidente.

Outros itens a serem incluídos

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

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

Crie instruções de análise de resposta de emergência e mantenha um registro de quando as análises foram executadas.

Documente as medidas legais ou regulatórias necessárias, por exemplo, comunicando violações de dados.

Detecção de incidentes

Quando você tem uma plataforma de observabilidade bem projetada que monitora anomalias e alertas automaticamente sobre elas, você pode detectar problemas rapidamente e determinar sua gravidade. Se o problema for considerado uma emergência, o plano poderá ser iniciado. Em alguns casos, a equipe de suporte não é notificada por meio da plataforma de observabilidade. Os clientes podem relatar problemas para dar suporte usando as vias de comunicação da equipe de suporte. Ou eles podem entrar em contato com pessoas com quem trabalham regularmente, como executivos de contas ou VPs. Não importa como a equipe de suporte seja notificada, ela sempre deve seguir as mesmas etapas para validar o problema e determinar a gravidade. O desvio do plano de resposta pode adicionar estresse e confusão.

Contenção

A primeira etapa na correção do problema é conter o problema para proteger o restante da 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. Os administradores do sistema, engenheiros e desenvolvedores seniores devem trabalhar juntos para criar estratégias de contenção. A contenção deve limitar o raio de explosão de problemas e manter a funcionalidade da carga de trabalho em um estado degradado até que o problema seja resolvido. Se um componente afetado precisar ser acessível para executar 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 restante dos sistemas.

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 ineficazes ou que podem causar outros problemas. Use ferramentas de análise e agregação de logs off-the-shelf para investigar com eficiência problemas que exigem análise profunda. Depois que o problema for resolvido, siga os processos bem definidos para trazer o componente afetado de volta aos caminhos de fluxo de carga de trabalho com segurança.

Relatórios de RCA

Os SLAs (contratos de nível de serviço) para seus clientes podem determinar que você precisa 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 poderá criar os relatórios do RCA. Essa estratégia garante uma contabilidade precisa do incidente. Normalmente, as organizações têm um modelo RCA definido com diretrizes sobre como as informações são apresentadas e quais tipos de informações podem ou não ser compartilhadas. Se você precisar criar seu próprio modelo e diretrizes, verifique se eles são revisados e aprovados pelos stakeholders.

Pós-morte de incidentes

Um indivíduo imparcial deve levar a autópsias sem culpa. Em sessões pós-morte, todos compartilham suas descobertas de um incidente. Cada equipe envolvida na resposta a incidentes deve ser representada por indivíduos que trabalharam no incidente. Esses indivíduos devem vir à sessão preparados com exemplos das áreas que foram bem-sucedidas e áreas que podem ser melhoradas. A sessão não é um fórum para atribuir blame para o incidente ou problemas que podem ter ocorrido durante a resposta. O líder pós-morte deve deixar a sessão com uma lista clara de itens de ação que se concentram no aprimoramento, 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 capturar o tipo específico de incidente anteriormente, ou um novo monitoramento pode precisar ser implementado para capturar o comportamento que não foi contabilizado.

  • 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 alarmes falsos ou escalonamentos desnecessários.

Da mesma forma, implementar agressivamente o dimensionamento automático ou outras ações de autorrecuperação para responder a violações de limite pode levar a despesas desnecessárias e carga de gerenciamento. Talvez você não saiba os limites exatos a serem definidos para alertas e ações automáticas, como dimensionamento. Execute testes em ambientes inferiores e em produção para ajudá-lo a determinar os limites certos para seus requisitos.

Facilitação do Azure

O Azure Monitor é uma solução abrangente para coletar, analisar e responder a dados de monitoramento de ambientes locais e de 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 machine learning. Automatizar e otimizar a triagem de incidentes e medidas proativas. Para obter mais informações, consulte AIOps e machine learning no Monitor.

O Log Analytics é uma ferramenta de análise robusta incorporada ao Monitor. Você pode usar o Log Analytics para executar consultas em logs agregados e obter insights 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 à preparação para incidentes do Azure e Preparaçã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