Compartilhar via

Recomendações para projetar uma estratégia de resposta a emergências

  • Artigo

Aplica-se a esta recomendação da lista de verificação do Azure Well-Architected Framework Operational Excellence:

OE:08 Desenvolva uma prática eficaz de operações de emergência. Certifique-se de que sua carga de trabalho emita sinais de integridade significativos na infraestrutura e no código. Colete os dados resultantes e use-os para gerar alertas acionáveis que promulgam respostas de emergência por meio de painéis e consultas. Defina claramente as responsabilidades humanas, como rodízios de plantão, gerenciamento de incidentes, acesso a recursos de emergência e execução de autópsias.

Este guia descreve as recomendações para projetar 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ência. Você pode implementar processos e procedimentos rigidamente controlados e focados que sua equipe pode seguir para garantir que um problema seja tratado de maneira calma e ordenada. As 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 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 com rapidez e segurança. Para desenvolver uma estratégia de resposta a emergências, considere a seguinte visão geral:

  • Pré-requisitos
    • Desenvolva uma plataforma de observabilidade
    • Criar um plano de resposta a incidentes
  • Fases do incidente
    • Detecção
    • Contenção
    • Triagem
  • Fases pós-incidente
    • Análise de causa raiz (RCA)
    • Análise posterior
  • Atividade em andamento
    • 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 de uma perspectiva de infraestrutura e aplicativo.

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

  • Painéis úteis: crie painéis baseados em modelo de integridade personalizados para cada equipe em sua organização. Diferentes equipes 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 exijam 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: 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 devem receber alertas apenas 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 controlado por versão sujeito a revisões regulares que garantam que esteja atualizado.

Defina claramente os seguintes componentes em seu plano.

Funções

Identifique um gerente de resposta a incidentes. Essa pessoa é proprietária do incidente desde o início até a correçã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 executa seu trabalho.

Identifique um líder post-mortem. Esse indivíduo garante que as autópsias sejam realizadas 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 o problema uma emergência, o que exige o início do plano de resposta a emergências. As 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, certifique-se de que seu suporte de nível 1 possa entrar em contato facilmente com as equipes apropriadas para encaminhar os problemas. Certifique-se de que eles saibam qual tipo de comunicação é apropriado para partes internas e externas. Nos planos de comunicação e escalonamento, inclua uma lista da agenda 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 incluir

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íquetes 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 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.

Documente quaisquer medidas legais ou regulatórias 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 as alerta automaticamente, pode detectar problemas rapidamente e determinar sua gravidade. Se o problema for considerado uma emergência, o plano pode ser iniciado. Em alguns casos, a equipe de suporte não é notificada por meio da plataforma de observabilidade. Os clientes podem relatar problemas ao 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 vice-presidentes. Não importa como a equipe de suporte seja notificada, eles devem sempre seguir as mesmas etapas para validar o problema e determinar a gravidade. O desvio do plano de resposta pode adicionar estresse e confusão.

Definir procedimentos de 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. Administradores de sistema, 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 restante dos sistemas.

Definir procedimentos de triagem

Depois de conter o problema com êxito, você pode iniciar 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 à 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 seguir os scripts que desenvolvem. É importante que as equipes sigam roteiros 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 agregação e análise de logs prontas para uso para investigar com eficiência problemas que exigem 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 acordos de nível de serviço (SLAs) para seus clientes podem determinar que você tenha que 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 de 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 de RCA. Essa 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 quais 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.

Realizar autópsias de incidentes

Um indivíduo imparcial deve liderar autópsias sem culpa. Nas sessões post-mortem, todos compartilham suas descobertas de um incidente. Cada equipe envolvida na resposta ao incidente deve ser representada por indivíduos que trabalharam no incidente. Esses indivíduos devem vir para a sessão preparados com exemplos das áreas que foram bem-sucedidas e das á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 da análise retrospectiva deve sair da sessão com uma lista clara de itens de ação que se concentram na melhoria, 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 detectar o tipo específico de incidente mais cedo, ou um novo monitoramento pode precisar ser implementado para detectar 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 alarmes falsos ou escalonamentos desnecessários.

Da mesma forma, a implementação agressiva de escalabilidade automática ou outras ações de autocorreção para responder a violações de limite pode levar a gastos desnecessários e carga de gerenciamento. 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 corretos 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 autocorreçã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 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