Criar um plano eficaz de gerenciamento de incidentes para gerenciar interrupções

Um incidente é um evento não planejado que interrompe, degrada ou ameaça interromper a operação normal de um sistema. Incidentes geralmente afetam negativamente clientes ou uma empresa. Eles existem em um espectro, desde interrupções transitórias ou localizadas até eventos ou desastres generalizados. Exemplos de incidentes de segurança incluem violações de dados, violações regulatórias, malware ou comprometimentos de identidade. As causas incluem falhas de hardware ou infraestrutura, limites de recursos, erros humanos, como implantações com falha ou configurações incorretas, ou fatores externos, como ataques de segurança.

O IcM (gerenciamento de incidentes) fornece uma abordagem sistemática para restaurar o serviço durante interrupções. Ele coordena a detecção, a investigação, a mitigação e a resolução, mantendo a comunicação clara e documentando insights para melhoria contínua. A resposta a incidentes segue o mesmo guia estratégico, independentemente do tipo de incidente.

Ao criar seu plano IcM, não se concentre apenas em dashboards e runbooks. Como arquiteto, projete operações em que pessoas, processos e ferramentas trabalhem em conjunto sob pressão para restaurar sistemas de forma eficiente e sem caos. Sua estratégia de IcM deve ser dimensionada com base na gravidade, desde a mitigação rápida de incidentes menores até os esforços coordenados entre equipes para grandes eventos. A resposta também pode variar dependendo da causa.

Este artigo se concentra nas fases do IcM, que incluem preparação, resposta a incidentes ativos, revisão pós-incidente e melhoria contínua. Essa orientação também inclui um exemplo para ilustrar as práticas de design. Antes de começar, examine as principais estratégias e escolha as que fazem sentido para sua empresa. Para obter mais informações, consulte estratégias de arquitetura OE:08 para criar um processo de IcM.

Este artigo não aborda desastres que exigem esforços de recuperação especializados. Para obter mais informações sobre como lidar com esses cenários, consulte Desenvolver um plano de recuperação de desastre para implantações de várias regiões.

Terminologia

Antes de começar a desenvolver seu plano de gerenciamento de incidentes, familiarize-se com esses termos-chave.

Prazo Definition
Raio de explosão O escopo da área afetada ou de impacto quando ocorre um incidente, que as estratégias de contenção visam limitar.
Contas de quebra de vidro Credenciais de emergência com privilégios elevados, usadas em incidentes críticos, são estritamente controladas com diretrizes de uso claras.
Equipe de Ponte A equipe de triagem que se reúne para investigar um incidente, também chamada de ponte de engenharia. Consiste em especialistas técnicos relevantes e tomadores de decisão.
Contenção A primeira etapa na correção de incidentes que isola os componentes afetados para evitar que o problema se espalhe para outras partes da carga de trabalho.
Gerenciamento de incidentes (IcM) O processo estruturado de detecção, triagem, mitigação e resolução de incidentes, enquanto coordena a comunicação e captura as lições aprendidas.
Last-known-good O último estado saudável do workload antes do início de um incidente, usado como ponto de referência para operações de reversão.
Mitigação Ações para reduzir ou remover o impacto de um incidente, incluindo reversão, recuo, desvio ou correções de emergência.
Retrospectiva Um processo de revisão pós-incidente sem culpabilização, focado em identificar lições aprendidas e melhorias acionáveis, em vez de atribuir culpa.
RCA (análise de causa raiz) Um processo sistemático de investigação de um incidente para identificar os fatores subjacentes responsáveis pelo problema e evitar a recorrência.
Nível de gravidade Um sistema de classificação, como crítico, alto, médio e baixo, que determina o nível de resposta apropriado com base no impacto nos negócios e nos usuários afetados.
Triagem O processo de analisar e priorizar incidentes para determinar a gravidade, o efeito e as ações de resposta apropriadas.

Preparação

Antes de ocorrer um incidente, configure a base para uma resposta efetiva projetando a observabilidade, definindo funções e processos claros e preparando as ferramentas e os recursos de que suas equipes precisam. Documente o plano de resposta a incidentes e atualize-o e examine-o regularmente.

  1. Mantenha diagramas de arquitetura precisos e atualizados que mostram todos os componentes e suas interações para ajudar as equipes a identificar rapidamente gargalos ou pontos únicos de falha. Essa abordagem permite uma solução de problemas mais rápida durante situações de alta pressão.

  2. Defina os dados de incidente que seu conjunto de ferramentas de monitoramento deve fornecer para toda a carga de trabalho.

    • Colete dados de telemetria de ponta a ponta, incluindo infraestrutura e aplicativos.

    • Habilite o registro em log estruturado para todos os componentes para dar suporte à triagem e investigação e envie logs para coletores de dados para análise. Se necessário, também encaminhe logs para pontos de coleta gerenciados centralmente. Verifique se os membros da equipe têm acesso temporário e privilégios mínimos durante incidentes.

    • Crie painéis com base no modelo de saúde da carga de trabalho. Os painéis mostram métricas e sinais que sua equipe monitora.

    • Configure alertas acionáveis que disparam notificações somente quando os limites são excedidos e um possível incidente é detectado. Ajuste alertas para evitar muitos alertas (ruído em excesso) ou poucos alertas. Por exemplo, para incidentes em sites ativos, os alertas devem monitorar métricas críticas, como CPU (unidade de processamento central), memória, tempos de resposta e desempenho do banco de dados para detectar problemas acionáveis que se alinham com metas de desempenho.

      Encaminhar alertas automaticamente para as equipes certas. Por exemplo, o suporte à camada 1 obtém todos os alertas, enquanto os engenheiros de segurança recebem apenas alertas relacionados à segurança.

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

  3. Defina as principais funções para garantir a responsabilidade, a tomada de decisões e o acompanhamento efetivo durante e após incidentes. Crie processos de aprovação apropriados e codifique-os em uma árvore de decisão clara. Defina níveis de autorização para diferentes tipos de gravidade, decisões de mitigação, caminhos de escalonamento e outras áreas.

    Use os exemplos a seguir como ponto de partida e adapte-os para ajustar sua estrutura de equipe.

    Função Responsabilidades
    Gerenciador de Resposta a Incidentes Gerencia o incidente desde a detecção até a resolução e a Análise de Causa Raiz. Garante que os processos sejam seguidos, as decisões sejam tomadas e as pessoas certas sejam informadas.
    Líder de Retrospectiva Lidera as revisões pós-incidente, captura as lições aprendidas, produz relatórios acionáveis e garante que as descobertas sejam aplicadas.
    Engenheiro de plantão Atenua e resolve incidentes ativamente. Segue as responsabilidades para diferentes tipos de incidentes e colabora com equipes especializadas conforme necessário para garantir a resolução oportuna do incidente.

  4. Definir procedimentos para investigação:

    • Defina categorias para tipos de incidentes, como incidentes operacionais, de segurança, de desempenho e de implantação, e os níveis de gravidade, como críticos, altos, médios e baixos, que se aplicam à carga de trabalho.

    • Documente como avaliar a gravidade, o impacto e a urgência do incidente. Considere o impacto do usuário, os sistemas afetados e as funções críticas aos negócios. Com base no nível de gravidade, a equipe ativa o plano de recuperação de desastre para casos que atendem aos limites de nível de desastre. Ou seguem o plano de resposta padrão para incidentes menos graves.

    • Defina estratégias que isolem ou removam o componente afetado dos caminhos de fluxo de carga de trabalho, como desligar um recurso ou redirecionar o tráfego. Identifique quais funções têm autoridade para executar a ação de contenção.

      Defina sistemas de monitoramento para iniciar automaticamente a contenção para incidentes definidos. Essa abordagem mantém os humanos em loop para decisões críticas. Administradores do sistema, engenheiros e desenvolvedores seniores devem colaborar para limitar o raio de explosão enquanto mantém a funcionalidade degradada. Se um componente precisar permanecer disponível para triagem, isole estritamente seu acesso do restante da carga de trabalho.

    • Crie diretrizes para selecionar estratégias de mitigação com base na gravidade do incidente, como isolamento, reversão, alterações de configuração e soluções alternativas.

    • Especifique quais equipes ou indivíduos lidam com o incidente com base no tipo e na gravidade. Inclua caminhos de escalonamento para quando os respondentes iniciais não puderem resolver o problema.

    • Descrever quais dados coletar durante a triagem, como logs, métricas, relatórios de usuários e alertas, para dar suporte à investigação e à tomada de decisões. Inclua também quem deve ter acesso a esses dados.

    Importante

    Proteja suas credenciais de emergência ou contas de quebra de vidro estabelecendo regras claras. Determine quem pode usá-los, quando e exatamente como. Emparelhe essas regras com exercícios de emergência e acompanhe cada execução. Defina com que frequência a equipe deve praticar exercícios. Durante um incidente, não há tempo para resolver na hora. Os drills fornecem práticas e oportunidades de refinamento adequadas.

  5. Configure sua infraestrutura para dar suporte à resolução:

    • Parametrizar pipelines. Permita que os pipelines de implantação e recuperação aceitem rapidamente versões específicas, facilitando a reversão rápida ou a correção da implantação.

    • Verifique a consistência do plano de dados. Mantenha chaves, segredos, configurações e dados de estado alinhados durante as operações de recuperação.

    • Automatizar o dimensionamento de infraestrutura. Ajuste os recursos automaticamente para lidar com turnos de tráfego ou aumento da carga.

    • Implemente auto recuperação. Automatize com segurança as respostas a padrões comuns de incidentes, mas inclua o monitoramento adequado e as opções para substituição manual.

  6. Definir processos de comunicação. Documente planos claros de comunicação e escalonamento para que o suporte de camada 1 possa alcançar rapidamente as equipes certas. Especifique os canais de comunicação apropriados para stakeholders internos e externos e inclua agendas de chamada e detalhes de contato.

  7. Defina o uso de uma ferramenta IcM e os procedimentos operacionais padrão que ela deve capturar em um fluxo de trabalho simples. O fluxo de trabalho inclui quatro etapas: criar, reconhecer, atenuar e resolver. A ferramenta dá visibilidade às equipes, acompanha o progresso, mantém a responsabilidade e garante o tratamento consistente de incidentes em todos os momentos. Ele centraliza todas as atividades para dar suporte à gestão de sites em tempo real e rotações de chamada.

  8. Defina os critérios que marcam oficialmente um incidente como fechado:

    • Inclua fatores de resolução claros. Normalmente, a resolução significa que o sistema e os serviços operam em SLAs (contratos de nível de serviço), desempenho e confiabilidade retornam a níveis aceitáveis e ações de mitigação imediatas concluídas com êxito.

    • Inclua verificações de validação para confirmar a resolução completa. Use ferramentas de monitoramento para verificar se o incidente não afeta mais o sistema e os usuários afetados não têm mais interrupção.

    • Inclua os requisitos de comunicação ao fechar um incidente. Notifique os stakeholders relevantes, incluindo equipes internas, equipe de suporte e usuários afetados, e forneça um resumo das ações executadas junto com o trabalho contínuo.

    • Inclua uma documentação detalhada ao fechar um incidente. Registre todos os detalhes no sistema IcM. Inclua o gatilho, as etapas de contenção, as decisões de triagem e a resolução final. Trate esta documentação como a entrega da RCA e a retrospectiva para capturar as lições aprendidas.

    Importante

    Projete suas operações para que apenas a autoridade designada, como o Gerenciador de Resposta a Incidentes, possa fechar um incidente. Imponha listas de verificação estritas para bloquear o fechamento prematuro. Ignorar etapas pode deixar problemas ocultos não resolvidos, o que pode transformar um incidente fechado em um desastre repetido.

Detectar, investigar e responder

A fase 2 concentra-se na detecção e resposta a incidentes de forma rápida e eficaz. Essa fase identifica os problemas precocemente, avalia seu impacto e implementa as estratégias de mitigação corretas, ao mesmo tempo em que contém a interrupção. Essa fase também garante que a triagem, a resolução e a comunicação sejam coordenadas, consistentes e responsáveis em todas as equipes.

Importante

A comunicação clara e consistente mantém o controle e a clareza em situações de alto estresse. Defina exatamente quem fala, o que é compartilhado e com que frequência. Padronizar a cadência de atualização, os canais e os formatos de mensagem para que ninguém esbarrá em busca de informações durante a crise. Verifique se todas as partes interessadas, de engenheiros a executivos, sabem quando esperar atualizações e quando o escalonamento é necessário.

  1. Agir imediatamente quando alertas ou relatórios de usuário indicarem um problema. Use ferramentas de observabilidade e desempenho para correlacionar anomalias com alterações no sistema. O destinatário do incidente configura uma equipe de triagem (ponte) com os membros certos e concorda com o modo de comunicação, o acompanhamento de progresso e o acesso aos ativos de incidentes.

  2. Mobilize a equipe de engenharia de ponte para avaliar o impacto e a gravidade. Avalie o impacto do incidente usando as classificações de severidade predefinidas. Use dados para justificar critérios descritos no plano de resposta a incidentes, como o número de usuários afetados, funções comerciais interrompidas, implicações de segurança e conformidade e potencial impacto na confiança e reputação do cliente. Essa avaliação determina o nível de resposta apropriado e orienta as próximas etapas de mitigação.

  3. A fase de investigação começa quando as equipes de engenharia adequadas são envolvidas e iniciam uma Análise de Causa Raiz (RCA). Esse processo envolve uma análise técnica profunda para identificar a causa e conter o impacto. Os engenheiros usam dados de observabilidade, painéis de telemetria, logs do sistema e históricos de alterações para rastrear anomalias e identificar pontos de falha. Eles se concentram em isolar o problema rapidamente, validar hipóteses usando dados em tempo real e desenvolver um plano preciso de mitigação que restaura a estabilidade do serviço sem introduzir novos riscos.

    Dilema: Uma RCA pode levar um tempo significativo. Para correlacionar problemas de desempenho, você deve coletar e armazenar dados. O tempo e a infraestrutura necessários podem adicionar trabalho extra às equipes de operações e custo à carga de trabalho.

    Risco: Se você executar uma RCA sem proteção de segurança adequada, poderá expor informações confidenciais ao fornecer acesso a logs e dados.

  4. Siga as estratégias de contenção para isolar os componentes afetados e limitar o raio de explosão. Você pode executar as seguintes ações:

    • Bloqueie o acesso aos componentes afetados usando caminhos separados para triagem. Por exemplo, você pode desligar um recurso, limitar o tráfego ou desabilitar um microsserviço com falha.

    • Limite o alcance do incidente a usuários, regiões ou componentes específicos.

    • Mantenha a funcionalidade da carga de trabalho em um estado degradado, se possível.

  5. Selecione uma estratégia de mitigação apropriada. Escolha abordagens de mitigação com base no estado atual da carga de trabalho, recursos disponíveis e restrições imediatas.

    Sua escolha depende de fatores como tipo de infraestrutura, mecanismos de bypass disponíveis, complexidade da correção, requisitos de confidencialidade e conformidade de dados, dependências do sistema e RTOs (objetivos de tempo de recuperação).

    • Rollback: Reverta os sistemas atualizados para a última configuração conhecida em bom estado. A equipe de carga de trabalho deve definir o que significa o último bem conhecido. Normalmente, ele se refere ao último estado saudável da carga de trabalho antes do início da implantação, que pode não ser a versão do aplicativo imediatamente anterior. A reversão pode ser complexa, especialmente quando alterações de esquema ou dados estão envolvidas. Para reduzir o risco, torne as atualizações de esquema aditivas em vez de substituir registros. Os dados antigos e novos podem coexistir até que você possa remover com segurança os registros preteridos. As reversões podem exigir cuidadoso planejamento e coordenação em várias equipes.

    • Fallback: Remova os sistemas atualizados recentemente do roteamento de tráfego de produção e direcione todo o tráfego para a infraestrutura estável. Essa estratégia de baixo risco resolve problemas de implantação sem causar mais interrupções. O fallback em implantações canárias pode ser complicado dependendo da infraestrutura e do design do aplicativo. Verifique se há capacidade adequada na pilha estável antes de alternar de volta o tráfego. O fallback dá suporte à operação contínua e isola a implantação problemática.

    • Ignorar a função ofensiva: Use sinalizadores de recursos ou propriedades de configuração de runtime para ignorar a funcionalidade problemática. Essa abordagem permite que a distribuição continue e isole o problema. Avalie as concessões e comunique-as às partes interessadas. Inclua por quanto tempo você pode tolerar um estado degradado e o tempo estimado para resolver totalmente o problema. Obtenha a aprovação das partes interessadas para o plano.

    • Implantação de emergência (hotfix): Implantar um hotfix durante a implantação para resolver o problema rapidamente. Siga as práticas de implantação seguras, incluindo a promoção de código por meio de ambientes e checagens de qualidade, mas acelere os prazos. Reduzir ou modificar os tempos de bake e os testes para acelerar o processo de implantação. Use testes automatizados para garantir a confiabilidade. As correções frequentes exigem coordenação e planejamento cuidadoso para minimizar o risco e resolver o problema prontamente.

    Importante

    Verifique se as decisões de mitigação seguem regras de autorização predefinidas. O Gerenciador de Incidentes deve lidar com todas as ações de mitigação. Exigir que a equipe autorizada aprove etapas de alto impacto e documente todas as ações. Mantenha as ações controladas, seguras e responsáveis enquanto restaura o sistema.

    Quando um problema de impacto do usuário começa aproximadamente ao mesmo tempo em que sua equipe implantou uma alteração, suponha que a alteração seja a causa provável e reverta-a imediatamente em vez de passar muito tempo investigando primeiro. O tempo necessário para selecionar a estratégia de mitigação é contabilizado em seu MTTR (tempo médio de recuperação). Otimize esse tempo tomando medidas de mitigação imediatamente.

  6. Aplique a resolução. Esta etapa se concentra em restaurar o sistema para o estado operacional completo, evitando a recorrência. As equipes de engenharia aplicam correções verificadas que seguem procedimentos roteirizados específicos da equipe. Eles usam ferramentas de análise de log e monitoramento para orientar a investigação. As etapas de reversão desfazem alterações ineficazes para garantir que cada ação encaminhe o sistema de forma consistente rumo à recuperação completa.

  7. Gere um relatório RCA. Depois de resolver um incidente, gere o relatório RCA dentro do período de tempo do SLA. O proprietário do incidente ou um membro da equipe intimamente envolvido se o proprietário não estiver disponível, deverá criar o relatório para garantir a precisão. Siga um modelo de RCA definido que tenha diretrizes claras sobre quais informações incluir e compartilhar, ou crie e aprove um novo modelo por meio da revisão de stakeholders.

Atividades pós-incidente

Faça retrospectivas após cada incidente. Eles fornecem oportunidades críticas de aprendizagem, destacam pontos fracos em resposta, implantação ou infraestrutura e informam melhorias. Documente itens de ação e rastreie-os em uma lista de pendências para implementação iterativa.

O objetivo não é atribuir culpa, mas identificar melhorias acionáveis. Um facilitador imparcial deve liderar esse processo. Os indivíduos que trabalharam na resposta devem representar cada equipe envolvida no incidente. Eles devem vir preparados com observações sobre sucessos e áreas de melhoria:

  • Aprimoramentos do plano de resposta: Atualize processos ou procedimentos para garantir ações mais claras e eficazes.

  • Melhorias de observabilidade: Ajuste os limites, adicione monitoramento ou implemente alertas para detectar incidentes semelhantes anteriormente.

  • Correção da carga de trabalho: Resolva vulnerabilidades expostas durante o incidente para correções permanentes.

Resposta para falha de implantação - Exemplo

O exemplo a seguir descreve um incidente relacionado à implantação. Mesmo com um planejamento e teste cuidadosos, as implantações às vezes podem introduzir problemas que afetam o desempenho do sistema ou a experiência do usuário.

Neste exemplo, uma equipe de carga de trabalho distribui um recurso de aprimoramento de pesquisa que inclui vários componentes:

  • Um novo endpoint de API de pesquisa que possui funcionalidade de filtragem aprimorada
  • Um esquema de banco de dados atualizado
  • Um widget de pesquisa de interface do usuário (interface do usuário) reprojetado
  • Nova lógica de cache

A equipe executa as seguintes etapas para detectar, atenuar e resolver o incidente:

  1. Detecção: A equipe percebe um problema quando as taxas de erro aumentam em um dos grupos de distribuição canário. A equipe imediatamente usa suas ferramentas de observabilidade, como APM (monitoramento de desempenho de aplicativos), registro em log e telemetria que vincula os usuários a fases de distribuição, para identificar o grupo afetado.

    A equipe se preparou para esse cenário criando uma forte observabilidade em seu processo de implantação. Eles executaram testes de fumaça e verificações de qualidade em cada fase de distribuição e instrumentavam seu aplicativo com registro em log, rastreamento e métricas de desempenho. A telemetria vincula os usuários a grupos de distribuição específicos, para que eles possam identificar rapidamente qual versão afetou quais usuários. Eles também agendaram implantações durante o horário de trabalho quando o suporte total estava disponível e garantiram que a equipe de suporte soubesse como escalonar problemas de acordo com o plano de resposta a emergências. Essa preparação permite que eles detectem o pico nas taxas de erro rapidamente e respondam sem demora.

  2. Mitigação: A equipe decide rapidamente sobre uma estratégia de mitigação. Eles consideram a possibilidade de reverter para a última versão conhecida como boa, voltar ao ambiente estável, ignorar a função problemática usando um sinalizador de recurso ou implantar uma correção emergencial. A árvore de decisão e o processo de aprovação já estão definidos.

    Depois que a equipe revisa todas as estratégias disponíveis, ela restringe sua escolha para reversão ou fallback e, por fim, opta por fallback. Eles determinam que redirecionar o tráfego para a pilha estável é mais rápido e apresenta menor risco do que uma reversão completa, que poderia exigir operações complexas com dados e esquemas. A equipe confirma que o stack estável tem capacidade suficiente para lidar com a carga de produção completa e eles podem isolar os sistemas atualizados do roteamento de tráfego de produção.

    A equipe juntou várias alterações interdependentes, incluindo a API, o esquema de banco de dados, os componentes da interface do usuário e a lógica de cache, portanto, identificar o componente específico que causou os erros é mais desafiador e demorado do que se eles tivessem implantado cada alteração separadamente.

  3. Resolução: A equipe implementa o procedimento de fallback. Eles redirecionam o tráfego para fora do ambiente atualizado para isolar a implantação problemática. A equipe pode resolver o problema subjacente sem afetar a maioria dos usuários.

    A implementação de fallback revela lacunas operacionais. Eles encontram informações de contato desatualizadas para dois membros-chave da equipe, e um engenheiro na cadeia de escalonamento deixou a empresa meses antes. A equipe perde tempo descobrindo o indivíduo responsável. Quando eles tentam remover a implantação atualizada do balanceador de carga, a documentação faz referência a uma configuração de balanceador de carga desatualizada que foi alterada em uma atualização recente do Azure. Eles têm que encontrar o procedimento correto sob pressão temporal.

    A comunicação é uma parte fundamental do plano de mitigação. A equipe informa aos stakeholders sobre a decisão e suas implicações, incluindo a linha do tempo esperada para resolver o problema no ambiente isolado. A equipe já padronizava a cadência para fornecer atualizações de status durante incidentes de implantação, para que os stakeholders saibam quando esperar relatórios de progresso e atualizações. A equipe também definiu o tipo e o nível de detalhes a serem compartilhados com os usuários e garantiu a conformidade com outros requisitos para comunicações de incidentes de implantação. Essa abordagem estruturada minimiza a confusão e ajuda a manter a confiança no processo de resposta.

  4. Retrospectiva: Depois que a equipe atenua o incidente de implantação, ela faz uma retrospectiva para capturar as lições aprendidas e melhorar os processos futuros. A sessão inclui todos os envolvidos na distribuição, desde desenvolvedores e operadores até representantes de suporte e partes interessadas. A equipe analisa a sequência de eventos, desde a detecção até a mitigação, para entender o que correu bem e onde existiam lacunas.

    Um ponto importante é que agrupar as alterações da API de pesquisa, atualizações de esquema de banco de dados, redesenho da interface do usuário e alterações na camada de cache complicou os esforços de solução de problemas e recuperação.

  5. Melhorias pós-incidente: Na retrospectiva, a equipe implementa várias melhorias operacionais para tornar as implantações futuras mais seguras e mitigações mais confiáveis:

    • Alterações menores e frequentes: A equipe muda para implantações menores e incrementais para reduzir o delta entre versões sucessivas e tornar a mitigação mais simples e de menor risco.

      Para o aprimoramento da pesquisa especificamente, a equipe decide implantar cada componente de forma independente. Agora, eles implantam primeiro as alterações de esquema de banco de dados compatíveis com versões anteriores, depois atualizam o ponto de extremidade da API e, em seguida, realizam outras alterações. Essa abordagem permite que a equipe valide cada camada de forma independente antes de adicionar a próxima camada e isolar problemas com mais facilidade a um componente específico.

    • Testes e análises regulares: A equipe estabelece uma prática de testes frequentes para a estratégia completa de mitigação de falhas de implantação. Eles introduzem testes de engenharia de caos e injeção de falhas para simular cenários de falha e validar processos de mitigação. Essas simulações regulares teriam identificado os problemas encontrados durante o incidente, incluindo as informações de contato desatualizadas e os procedimentos operacionais desatualizados.

Facilitação do Azure

  • A Microsoft fornece 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.

  • O Azure Monitor é uma solução para coletar, analisar e responder a dados de monitoramento de ambientes locais e de nuvem. Ele inclui uma plataforma de alertas 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 Azure Monitor para integrar o machine learning. Automatize e otimize a triagem de incidentes e medidas proativas. Para obter mais informações, consulte operações de IA e machine learning no Azure Monitor.

    • O Log Analytics é uma ferramenta de análise no Azure Monitor. Você pode usar o Log Analytics para executar consultas em logs agregados e obter insights sobre sua carga de trabalho.

    • O Application Insights é uma extensão do Azure Monitor que fornece recursos de APM.

  • O Microsoft Sentinel é uma solução de SIEM (gerenciamento de eventos e informações de segurança) e de orquestração de segurança, automação e resposta (SOAR). É uma solução única para detecção de alertas, visibilidade de ameaças, busca proativa e resposta a ameaças.

  • O Azure Pipelines fornece serviços de build e lançamento para dar suporte à CI/CD (integração contínua e entrega contínua) de seus aplicativos.

  • Os Planos de Teste do Azure são uma solução de gerenciamento de teste baseada em navegador. Essa solução fornece recursos necessários para testes manuais planejados, testes de aceitação do usuário e testes exploratórios. Os Planos de Teste do Azure também fornecem uma maneira de coletar comentários dos stakeholders.

  • Os Aplicativos Lógicos do Azure são uma plataforma baseada em nuvem para executar fluxos de trabalho automatizados que integram aplicativos, dados, serviços e sistemas. Você pode usar os Aplicativos Lógicos para criar uma nova versão do aplicativo quando ele receber uma atualização. O Azure mantém um histórico das versões e pode reverter ou promover qualquer versão anterior.

  • Muitos serviços de banco de dados do Azure fornecem funcionalidade de restauração a um ponto no tempo (PITR) que pode ajudá-lo quando você precisa reverter:

  • O Azure Chaos Studio é um serviço gerenciado que usa a engenharia do caos para ajudá-lo a medir, entender e melhorar sua resiliência de aplicativos e serviços de nuvem.

  • Last updated on