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

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

OE:07 Desenvolva uma prática de operações de emergência eficaz. Verifique se a carga de trabalho emite sinais de integridade significativos. Colete os dados resultantes e use-os para gerar alertas acionáveis que decretam respostas de emergência por meio de painéis e consultas. Defina claramente responsabilidades humanas, como rotações mediante chamada, gerenciamento de incidentes, acesso a recursos de emergência e execução post-mortem.

Este guia descreve as recomendações para projetar uma estratégia de resposta a emergências. Algumas de suas cargas de trabalho podem ser de missão crítica, e os problemas que surgem ao longo do ciclo de vida de uma carga de trabalho podem ser graves o suficiente para justificar a declaração de emergência. Você pode implementar processos e procedimentos controlados e concentrados rigorosamente que a 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 poderão acarretar um ambiente caótico se a equipe 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 a organização e realize um treinamento de resposta a emergências regular.

Estratégias-chave de design

Uma estratégia de resposta a emergências deve ser um conjunto bem definido de processos e procedimentos. Cada processo e procedimento deve ter scripts para garantir que cada etapa ajude sua equipe a avançar rapidamente e com segurança na resolução de um problema. Para desenvolver uma estratégia de resposta a emergências, leve em consideração a seguinte visão geral:

  • Pré-requisitos
    • Desenvolver um sistema de monitoramento
    • Criar um plano de resposta a incidentes
  • Fases de incidente
    • Detecção e contenção
    • Triagem
  • Fases de pós-incidente
    • Análise de causa raiz (RCA)
    • Post-mortem
  • Atividade contínua
    • Análises de resposta a emergências

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

Sistema de monitoramento

A fim de ter uma estratégia robusta de resposta a emergências, é necessário ter um sistema de monitoramento robusto, ou plataforma de observabilidade, em vigor. A plataforma de observabilidade deve ter as seguintes características:

  • Monitoramento holístico: verifique se você monitore na íntegra a carga de trabalho de uma perspectiva de configuração e aplicativo e inclua o monitoramento de infraestrutura caso os componentes da carga de trabalho estejam hospedados na nuvem ou no local. Certifique-se de que todos os componentes de sua carga de trabalho estejam cobertos por sua estratégia de monitoramento. Por exemplo, se sua carga de trabalho interagir com recursos do Azure ou um sistema local, inclua esses componentes em seu monitoramento.

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

  • Painéis úteis: crie painéis com base em seu modelo de integridade que são 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 que sejam úteis para as equipes da carga de trabalho. Evite alertas que não exijam ação das 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 indicadas recebam automaticamente alertas que exijam uma ação delas. Por exemplo, a equipe de suporte de Nível 1 deve receber notificações para todos os alertas, e os engenheiros de segurança só devem receber alertas para eventos de segurança.

Saiba mais em Recomendações para projetar e criar uma estrutura de monitoramento.

Plano de resposta a incidentes

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

Defina claramente os componentes a seguir no plano.

Direitos

Identifique um gerente de respostas a incidentes. Essa pessoa é proprietária do incidente, desde o início até a correção, passando pela análise de causa raiz. Um gerente de resposta a incidentes garante que os processos sejam seguidos e as partes apropriadas sejam informadas, conforme a equipe de resposta executa seu trabalho.

Identifique um líder post-mortem. Esse indivíduo garante que os post-mortems sejam realizados logo após a resolução do incidente. Eles produzem um relatório, que ajuda a aplicar as descobertas resultantes do incidente.

Processos e procedimentos

A equipe da carga de trabalho deve definir e compreender critérios de emergência. Quando a 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 ainda assim deve ser considerado uma emergência, o que exige a ativação do plano de resposta a emergências. As emergências podem ser internas à carga de trabalho, como bugs no código do aplicativo, ou resultado de um problema com uma dependência da carga de trabalho, como a indisponibilidade de uma API ou de um banco de dados. Uma emergência também pode ser causada por uma interrupção do fornecedor (como um problema na ID do Microsoft Entra ou no Power Platform). A equipe de suporte precisa ser capaz de identificar se um problema se enquadra nos critérios de emergência, mesmo sem ter acesso direto ao problema subjacente.

Defina planos de comunicação e escalonamento com precisão. Com base no tipo de notificação de alerta que recebem, certifique-se de que os membros da equipe de suporte de Nível 1 possam entrar em contato facilmente com as equipes apropriadas para problemas que precisam ser escalonados.

Outros itens a serem incluídos

Documente todas as ferramentas padrão que são usadas durante incidentes para comunicação interna, como 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 as credenciais de emergência, também conhecidas como contas quebra-vidro. Inclua um guia passo a passo que descreva como elas devem ser usadas.

Crie instruções de treinamento de resposta a emergências e mantenha um registro de quando as simulações são executadas.

Documente quaisquer medidas legais ou regulamentares necessárias, como a comunicação de violações de dados.

Detecção e contenção de incidentes

Quando tem um sistema de monitoramento bem projetado que monitora anomalias e emite alertas automáticos para elas, você consegue detectar rapidamente problemas e determinar a gravidade. Se o problema for considerado uma emergência, o plano poderá ser iniciado. Em alguns casos, a equipe de suporte não é notificada pelo sistema de monitoramento. Os usuários podem relatar problemas ao suporte usando meios de comunicação da equipe de suporte. Ou eles podem entrar em contato com pessoas com quem trabalham regularmente ou com quem sabem que estão trabalhando com o Power Platform, como seus administradores de serviço do Power Platform ou a equipe do Centro de Excelência. Não importa como a equipe de suporte é notificada, ela deve seguir sempre as mesmas etapas para validar o problema e determinar a gravidade. O desvio em relação ao plano de resposta pode adicionar estresse e confusão.

Triagem

A primeira etapa na correção do problema é identificar o componente da carga de trabalho que o está causando. As etapas seguidas por você 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 ao seu trabalho. Por exemplo, as equipes de segurança devem fazer a triagem de problemas de segurança e seguir os scripts desenvolvidos por eles. É importante que as equipes sigam scripts bem definidos enquanto atuam nos esforços de triagem. Esses scripts devem ser instruções passo a passo que têm processos de reversão para desfazer alterações que são ineficazes ou podem causar outros problemas. Depois que o problema for resolvido, siga processos bem definidos para trazer o componente afetado de volta para os caminhos do fluxo da carga de trabalho em segurança.

Relatórios da análise de causa raiz

O proprietário do incidente ou alguém que trabalhou em estreita colaboração com ele deve criar os relatórios de análise de causa raiz (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. Caso precise criar seu próprio modelo e diretrizes, assegure-se de que as partes envolvidas revisem e aprovem antes de finalizá-los.

Post-mortems de incidente

Um indivíduo imparcial deve realizar post-mortems irrepreensíveis. Em sessões post-mortem, todos compartilham as descobertas de um incidente. Cada equipe envolvida na resposta ao incidente deve ser representada por pessoas que trabalharam no incidente. Essas pessoas devem chegar à sessão preparados com exemplos das ações 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 surgir durante a resposta. O líder de post-mortem deve sair da sessão com uma lista clara dos itens de ação concentrados na melhoria, tais como:

  • Melhorias no plano de resposta. Processos ou procedimentos talvez precisem ser reavaliados e reescritos para capturar melhor as ações indicadas.
  • Melhorias no sistema de monitoramento. Os limites podem precisar ser reavaliados para detectar o tipo específico de incidente antes, ou um novo monitoramento talvez precise ser implementado para detectar um comportamento que não tenha sido levado em conta.
  • Melhorias feitas na carga de trabalho. O incidente pode expor uma vulnerabilidade na carga de trabalho que deve ser resolvida como uma correção permanente.

Considerações

A estratégia de resposta a emergências deve estar intimamente alinhada com a estratégia de suporte geral do Power Platform. Trabalhe com os administradores e a equipe do Centro de Excelência do Power Platform para discutir opções e processos de suporte e resposta a emergências que talvez já estejam definidos.

À medida que você define o processo de suporte e o caminho de escalonamento, é importante categorizar soluções compiladas com base na gravidade. Essa prática permite que você estabeleça processos que garantam que os aplicativos críticos tenham as proteções necessárias para suportá-los, sem prejudicar a inovação em cenários de produtividade ou sobrecarregar suas equipes de resposta a incidentes. Ao definir os modelos de suporte, pense também em um caminho de graduação. Uma solução pode começar exigindo apenas suporte em nível de produtividade, mas crescer em funcionalidade ou base de usuários para exigir um nível mais alto de suporte. Defina como os criadores podem solicitar suporte mais formal e fazer a transição de uma solução para ambientes com suporte.

Facilitação do Power Platform

O Power Platform se integra ao Application Insights, que faz parte do ecossistema do Azure Monitor. Use essa integração para:

  • Receber telemetria sobre diagnóstico e desempenho capturados pela plataforma do Dataverse no Application Insights. É possível assinar para receber telemetria sobre operações realizadas pelos aplicativos no banco de dados do Dataverse e em aplicativos baseados em modelo. Essa telemetria fornece informações que é possível usar para realizar o diagnóstico e solucionar problemas relacionados aos erros e ao desempenho.

  • Conectar os aplicativos de tela ao Application Insights. Você pode usar essa análise para realizar o diagnóstico de problemas e compreender o que os usuários fazem com os aplicativos. É possível coletar informações para a tomar decisões comerciais melhores e aprimorar a qualidade de seus aplicativos.

  • Configure a Telemetria do Power Automate para fluir no Application Insights, por exemplo, para monitorar execuções de fluxo de nuvem e criar alertas para falhas de execução de fluxo da nuvem.

  • Capture dados de telemetria do seu agente do Microsoft Copilot Studio para uso no Azure Application Insights. Você pode usar essa telemetria para monitorar mensagens registradas e eventos enviados de e para o agente, tópicos a serem disparados durante conversas do usuário e eventos de telemetria personalizados que podem ser enviados de seus tópicos.

O Application Insights é uma solução abrangente para coletar, analisar e responder a dados de monitoramento de ambientes de nuvem e local. Ele inclui uma plataforma de alertas robusta que você pode configurar para notificações automáticas e outras ações.

O Kit de Automação do Power Platform é um conjunto de ferramentas que agiliza o uso e o suporte do Power Automate para desktop em projetos de automação. O kit fornece ferramentas que ajudam a gerenciar projetos de automação e monitorá-los para estimar o dinheiro economizado e o ROI (retorno sobre o investimento). Parte do Kit de Automação é o centro de controle, que complementa o recurso existente de execuções de fluxo da área de trabalho do Monitor. O foco principal do centro de controle é uma exibição do orquestrador para analistas de suporte e organizações monitorar, tomar uma medida e alertar quando necessário.

Próximas etapas