Partilhar via

Recomendações para conceber uma estratégia de resposta de emergência

  • 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 a carga de trabalho emite sinais de estado de funcionamento significativos em toda a infraestrutura e código. Recolha os dados resultantes e utilize-os para gerar alertas acionáveis que decretam respostas de emergência através de dashboards e consultas. Defina claramente as responsabilidades humanas, tais como rotações de chamada, gestão de incidentes, acesso a recursos de emergência e execução de autópsias.

Este guia descreve as recomendações para conceber uma estratégia de resposta de emergência. Alguns problemas que surgem ao longo do ciclo de vida de uma carga de trabalho são suficientemente críticos para justificar a sua declaração de emergência. Pode implementar processos e procedimentos bem controlados e focados que a sua equipa pode seguir para garantir que um problema é 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 stress e a confusão, crie uma estratégia de resposta, partilhe a estratégia de resposta com a sua organização e realize uma formação de resposta de emergência regular.

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 passo progride para a resolução rápida e segura de um problema. Para desenvolver uma estratégia de resposta de emergência, considere a seguinte descrição geral:

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

As secções seguintes fornecem recomendações para cada uma destas fases.

Observabilidade

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

  • Monitorização holística: certifique-se de que monitoriza cuidadosamente a carga de trabalho a partir de uma perspetiva de infraestrutura e aplicação.

  • Registo verboso: ative o registo verboso para os seus componentes para ajudar nas investigações quando faz a triagem de um problema. Estruturar registos para que sejam fáceis de gerir. Envie automaticamente registos para sinks de dados para serem preparados para análise.

  • Dashboards úteis: crie dashboards baseados em modelos de estado de funcionamento adaptados a cada equipa na sua organização. Diferentes equipas são responsáveis por diferentes aspetos do estado de funcionamento da carga de trabalho.

  • Alertas acionáveis: crie alertas úteis para as suas equipas de cargas de trabalho. Evite alertas que não exijam ação das suas equipas. Demasiados alertas deste tipo podem levar a que as pessoas ignorem ou bloqueiem notificações de alertas.

  • Notificações automáticas: certifique-se de que as equipas adequadas recebem automaticamente alertas que necessitam de ação das mesmas. Por exemplo, a sua equipa de suporte de escalão 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, veja Recomendações para conceber e criar uma arquitetura de observabilidade.

Plano de resposta a incidentes

A base de uma estratégia de resposta de emergência é um plano de resposta a incidentes. Tal como um plano de recuperação após 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ões que esteja sujeito a revisões regulares que garantam que está atualizado.

Defina claramente os seguintes componentes no seu plano.

Funções

Identificar um gestor de resposta a incidentes. Esta pessoa é proprietária do incidente desde a iniciação à remediação até à análise da causa raiz. Um gestor de resposta a incidentes garante que os processos são seguidos e as partes adequadas são informadas à medida que a equipa de resposta realiza o seu trabalho.

Identifique um líder pós-morte. Este indivíduo garante que as autópsias são realizadas logo após o incidente ser resolvido. Produzem um relatório, o que o ajuda a aplicar as conclusões que saem do incidente.

Processos e procedimentos

A sua equipa de carga de trabalho deve definir e compreender os critérios de emergência. Quando a sua equipa determinar que um caso é grave, pode declarar um desastre e iniciar o plano de recuperação após desastre. Em casos menos graves, o problema pode não cumprir os critérios de um desastre. Mas ainda deve considerar o problema como uma emergência, o que requer o início do plano de resposta de emergência. As emergências podem ser problemas internos na carga de trabalho ou podem ser resultado de um problema com uma dependência da carga de trabalho. A equipa de suporte tem de ser capaz de determinar se um problema comunicado por utilizadores externos cumpre os critérios de emergência, mesmo que não tenha visibilidade sobre o problema subjacente.

Defina com precisão planos de comunicação e escalamento. Com base no tipo de notificação de alerta que recebem, certifique-se de que o suporte do escalão 1 pode contactar facilmente as equipas adequadas para os quais os problemas são escalados. Certifique-se de que sabe que tipo de comunicação é adequado para as partes internas e externas. Nos planos de comunicação e escalamento, inclua uma lista do agendamento de chamadas e do pessoal.

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

Outros itens a incluir

Documente todas as ferramentas padrão que serão utilizadas durante incidentes para comunicação interna, como o Microsoft Teams, e para controlar as atividades ao longo do incidente, como ferramentas de suporte de permissões ou ferramentas de planeamento de registos de tarefas pendentes.

Documente as suas credenciais de emergência, também conhecidas como contas break-glass. Inclua um guia passo a passo que descreva como devem ser utilizados.

Crie instruções de pormenorização de resposta de emergência e mantenha um registo de quando os exercícios foram realizados.

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

Deteção de incidentes

Quando tem uma plataforma de observabilidade bem concebida que monitoriza anomalias e alertas automaticamente sobre as mesmas, pode detetar rapidamente problemas e determinar a respetiva 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 comunicar problemas de suporte através das vias de comunicação da equipa de suporte. Em alternativa, podem contactar as pessoas com quem trabalham regularmente, como executivos de contas ou VPs. Independentemente da forma como a equipa de suporte é notificada, deve seguir sempre os mesmos passos para validar o problema e determinar a gravidade. O desvio do plano de resposta pode aumentar o stress e a confusão.

Contenção

O primeiro passo na remediação do problema é conter o problema para proteger o resto da carga de trabalho. Uma estratégia de contenção depende do tipo de problema, mas normalmente envolve remover o componente afetado dos caminhos de fluxo de carga de trabalho. Por exemplo, pode encerrar um recurso ou removê-lo dos caminhos de encaminhamento de rede. Os administradores de sistema, engenheiros e programadores seniores devem trabalhar em conjunto para conceber 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 num estado degradado até que o problema seja resolvido. Se um componente afetado precisar de estar acessível para efetuar a triagem, é vital que o acesso ao resto da carga de trabalho seja bloqueado. Tanto quanto possível, só deve aceder ao componente através de um caminho separado da carga de trabalho e do resto dos sistemas.

Triagem

Depois de conter o problema com êxito, pode iniciar o trabalho de triagem. Os passos que seguir durante a triagem dependem do tipo de problema. A equipa de uma determinada área de suporte de carga de trabalho deve criar procedimentos para incidentes relacionados com a equipa. Por exemplo, as equipas de segurança devem fazer a triagem de problemas de segurança e devem seguir os scripts que desenvolvem. É importante que as equipas sigam scripts bem definidos à medida que trabalham nos seus esforços de triagem. Estes scripts devem ser processos passo a passo que incluem processos de reversão para anular alterações ineficazes ou que podem causar outros problemas. Utilize ferramentas de análise e agregação de registos off-the-shelf para investigar de forma eficiente problemas que requerem uma análise profunda. Depois de o problema ser resolvido, siga os processos bem definidos para colocar o componente afetado de forma segura novamente nos caminhos do fluxo de carga de trabalho.

Relatórios de 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 tenha trabalhado de perto 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 partilhadas. Se precisar de criar o seu próprio modelo e diretrizes, certifique-se de que são revistos e aprovados pelos intervenientes.

Autópsias de incidentes

Um indivíduo imparcial deve liderar postmortems sem culpa. Nas sessões pós-morte, todos partilham as suas conclusões de um incidente. Cada equipa envolvida na resposta ao incidente deve ser representada por indivíduos que trabalharam no incidente. Esses indivíduos devem vir à sessão preparados com exemplos das áreas com êxito e áreas que podem ser melhoradas. A sessão não é um fórum para atribuir culpas pelo incidente ou problemas que possam ter surgido durante a resposta. O líder pós-morte deve sair da sessão com uma lista clara de itens de ação que se focam na melhoria, como:

  • Melhorias ao plano de resposta. Os processos ou procedimentos podem ter de ser reavaliados e reescritos para capturar melhor as ações adequadas.

  • Melhorias na plataforma de observabilidade. Os limiares podem ter de ser reavaliados para capturar o tipo específico de incidente anteriormente ou poderá ter de ser implementada uma nova monitorização 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 tem de ser tratada como uma remediação permanente.

Considerações

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

Da mesma forma, a implementação agressiva do dimensionamento automático ou outras ações de auto-recuperação para responder a quebras de limiar pode levar a despesas desnecessárias e encargos de gestão. Poderá não saber os limiares exatos a definir para alertas e ações automáticas, como o dimensionamento. Efetue testes em ambientes mais baixos e em produção para o ajudar a determinar os limiares certos para os seus requisitos.

Facilitação do Azure

O Azure Monitor é uma solução abrangente para recolher, analisar e responder à monitorização de dados de ambientes na cloud e no local. Inclui uma plataforma de alerta robusta que pode configurar para notificações automáticas e outras ações, como o dimensionamento automático e outros mecanismos de auto-recuperação.

Utilize o Monitor para integrar o machine learning. Automatizar e otimizar a triagem de incidentes e as medidas proativas. Para obter mais informações, veja AIOps e machine learning no Monitor.

O Log Analytics é uma ferramenta de análise robusta incorporada no Monitor. Pode utilizar o Log Analytics para executar consultas em registos agregados e obter informações sobre a sua carga de trabalho.

A Microsoft oferece formação de preparação para incidentes relacionados com o Azure. Para obter mais informações, veja Introdução à preparação de incidentes do Azure e Preparação de incidentes.

Lista de verificação de Excelência Operacional

Veja o conjunto completo de recomendações.

Lista de verificação de Excelência Operacional