Compartilhar via


Recomendações para realizar uma análise do modo de falha

Aplica-se a esta recomendação da lista de verificação de confiabilidade bem arquitetada: Power Platform

RE:03 Use a análise do modo de falha (FMA) para identificar e priorizar falhas em potencial nos componentes da solução. Realize FMA para ajudar você a avaliar o risco e o efeito de cada modo de falha. Determine como a carga de trabalho responde e se recupera.

Este guia descreve as melhores práticas para realizar a análise do modo de falha (FMA) para a carga de trabalho. FMA é a prática de identificação de pontos de falha em potencial dentro da carga de trabalho e dos fluxos associados, além do planejamento das ações de mitigação de acordo. Em cada etapa do fluxo, você identifica o raio de ativação de vários tipos de falha, o que ajuda a projetar uma nova carga de trabalho ou refatorar uma carga de trabalho existente para minimizar o efeito generalizado de falhas.

Um princípio-chave da FMA é que as falhas acontecem independentemente de quantas camadas de resiliência você aplicar. Os ambientes mais complexos estão expostos a mais tipos de falhas. Dada essa realidade, a FMA permite a você projetar a carga de trabalho para suportar a maioria dos tipos de falhas e se recuperar tranquilamente quando ocorre uma falha.

Se você ignorar a FMA ou realizar uma análise incompleta, a carga de trabalho correrá o risco de comportamento imprevisto e interrupções em potencial causadas por um design inadequado.

Definições

Termo Definição
Modo de falha Um tipo de problema que pode fazer com que um ou mais componentes da carga de trabalho sejam degradados ou afetados gravemente a ponto de estarem indisponíveis.
Mitigação As atividades identificadas por você para resolver problemas de maneira proativa ou reativa.
Duplicatas Os processos e os procedimentos de monitoramento e alerta de dados e aplicativos.

Estratégias-chave de design

No contexto da FMA, o reconhecimento dos pré-requisitos é crucial. Comece revisando e implementando recomendações para identificar fluxos, priorizando-os com base na gravidade. Os artefatos de dados desempenham um papel fundamental na descrição dos caminhos de dados dentro desses fluxos. Ao se aprofundar na abordagem de FMA, concentre-se no planejamento de componentes para fluxos críticos, na identificação de dependências (internas e externas) e na elaboração das estratégias de mitigação.

Pré-requisitos

Revise e implemente as recomendações para identificar e classificar fluxos. Presume-se que você tenha identificado e priorizado fluxos de usuários e sistemas com base na gravidade.

Os dados coletados e os artefatos criados por você no trabalho oferecem uma descrição concreta dos caminhos de dados envolvidos em todos os fluxos. Para ser bem-sucedido no trabalho de FMA, a precisão e o rigor nos artefatos são críticos.

Abordagem de FMA

Depois de determinar os fluxos críticos, você poderá planejar os componentes necessários. Em seguida, siga cada fluxo passo a passo para identificar dependências, inclusive serviços de terceiros e pontos de falha em potencial, e planejar as estratégias de mitigação.

Decompor a carga de trabalho

À medida que move da ideação para o design, você precisa identificar os tipos de componente necessários para dar suporte à carga de trabalho. A carga de trabalho determina os componentes necessários que você deve planejar.

Depois de criar o design de arquitetura inicial, você pode sobrepor os fluxos para identificar os componentes discretos usados nesses fluxos e criar listas ou diagramas de fluxo de trabalho que descrevam os fluxos e os componentes. Para compreender a gravidade dos componentes, use as definições de gravidade atribuídas por você aos fluxos. Leve em consideração o efeito de um mau funcionamento do componente nos fluxos.

Identificar dependências

Identifique as dependências da carga de trabalho para realizar a análise do ponto de falha único. A decomposição da carga de trabalho e a sobreposição de fluxos fornecem um insight sobre dependências internas e externas para a carga de trabalho.

Dependências internas são componentes no escopo da carga de trabalho necessários para que a carga de trabalho funcione. Entre as dependências internas típicas estão APIs ou soluções de gerenciamento de segredos/chaves, como o Azure Key Vault. Para essas dependências, capture os dados de confiabilidade, como contratos de nível de serviço (SLAs) de disponibilidade e limites de escala. As dependências externas são componentes necessários fora do escopo da carga de trabalho, como outro aplicativo ou serviço de terceiros. Entre as dependências externas estão soluções de autenticação, como ID do Microsoft Entra e a infraestrutura do Power Platform.

Identifique e documente as dependências na carga de trabalho e as inclua nos artefatos de documentação do fluxo.

Pontos de falha

Nos fluxos críticos da carga de trabalho, leve em consideração cada componente e determine como esse componente e as dependências podem ser afetados por um modo de falha. Lembre-se de que existem muitos modos de falha a serem levados em consideração durante o planejamento para resiliência e recuperação. Qualquer componente pode ser afetado por mais de um modo de falha ao mesmo tempo. Entre esses modos de falha estão:

  • Interrupção regional: uma região inteira do Azure ou do Power Platform está indisponível
  • Interrupção de serviço: um ou mais serviços do Azure ou do Power Platform estão indisponíveis
  • Negação de serviço distribuída (DDoS) ou outro ataque mal-intencionado
  • Má configuração do aplicativo ou do componente
  • Erro do operador
  • Interrupção de manutenção planejada
  • Sobrecarga do componente

Leve em consideração a probabilidade de cada tipo do modo de falha. Algumas são muito improváveis, como interrupções multizona ou multirregião, e a adição do planejamento de mitigação além da redundância não é um bom uso de recursos e tempo.

Mitigação

As estratégias de mitigação se enquadram em duas grandes categorias: a compilação de mais resiliência e o design para desempenho degradado.

A compilação de mais resiliência significa garantir que o design do aplicativo segue as melhores práticas em termos de durabilidade; por exemplo, a divisão de aplicativos monolíticos em aplicativos e microsserviços isolados e o uso de configurações de resiliência fornecidas pela plataforma, como políticas de repetição. Para obter mais informações, consulte Recomendações para redundância e Recomendações para autopreservação.

Para projetar para desempenho degradado, identifique pontos de falha em potencial que possam desabilitar um ou mais componentes do fluxo, mas não desabilitam totalmente esse fluxo. Para manter a funcionalidade do fluxo de ponta a ponta, talvez seja necessário redirecionar uma ou mais etapas para outros componentes ou aceitar que um componente com falha execute uma função, logo, a função não está mais disponível na experiência do usuário. Para retornar ao exemplo do aplicativo de comércio eletrônico, um componente com falha, como um microsserviço, pode fazer com que o mecanismo de recomendação esteja indisponível, mas os clientes ainda podem procurar produtos e concluir a transação.

Você também precisa planejar a mitigação relacionada às dependências. As dependências fortes desempenham um papel crítico na função e na disponibilidade do aplicativo. Se elas estiverem ausentes ou apresentando um mau funcionamento, é possível que haja um efeito significativo. A ausência de dependências fracas só pode afetar recursos específicos, e não afetar a disponibilidade geral. Essa distinção reflete o custo para manter a relação de alta disponibilidade entre o serviço e as dependências. Classifique as dependências como fortes ou fracas para ajudar a identificar quais componentes são essenciais para o aplicativo.

Se o aplicativo tiver dependências fortes sem as quais não consegue operar, os destinos de disponibilidade e recuperação dessas dependências deverão estar alinhados com os destinos do próprio aplicativo. Se o ciclo de vida do aplicativo estiver intimamente associado ao ciclo de vida das dependências, a agilidade operacional do aplicativo poderá ser limitada, especialmente para novas versões.

Duplicatas

A detecção de falhas é essencial para garantir que você tenha identificado corretamente pontos de falha na análise e planejado devidamente as estratégias de mitigação. A detecção nesse contexto significa o monitoramento da infraestrutura, dos dados e do aplicativo, além de alertas quando surgirem problemas. Automatize a detecção o máximo possível e compile redundância nos processos operacionais para garantir que os alertas sejam sempre captados e respondidos com rapidez suficiente para atender às necessidades de negócios. Para obter mais informações, consulte Recomendações de monitoramento.

Resultado

Para obter o resultado da análise, crie um conjunto de documentos que comuniquem efetivamente as descobertas, as decisões tomadas por você em relação aos componentes do fluxo e à mitigação, além do efeito da falha sobre a carga de trabalho.

Em sua análise, priorize os modos de falha e as estratégias de mitigação identificadas por você com base na gravidade e na probabilidade. Use essa priorização para concentrar a documentação nos modos de falha comuns e graves o suficiente para justificar o gasto de tempo, esforço e recursos no projeto das estratégias de mitigação. Por exemplo, é possível que haja alguns modos de falha muito raros em ocorrência ou detecção. O design das estratégias de mitigação relacionadas a deles não vale a pena.

Consulte a tabela de exemplo para obter um ponto de partida da documentação.

Durante o exercício inicial de FMA, os documentos produzidos por você vão ser principalmente de planejamento teórico. Os documentos de FMA devem ser revisados e atualizados regularmente para garantir que eles permaneçam atualizados em relação à carga de trabalho. O teste do caos e as experiências de mundo real vão ajudar você a refinar as análises com o passar do tempo.

Exemplo

A tabela a seguir mostra um exemplo de FMA para um aplicativo de despesa hospedado como um aplicativo de tela do Power Apps com um back-end do Microsoft Dataverse e APIs hospedadas no APIM para interagir com um sistema de terceiros.

Fluxo do usuário: login do usuário, envio de solicitação de despesa e interação com o relatório de despesas

Componente Risco Probabilidade Efeito/Mitigação/Observação Interrupção
Microsoft Entra ID Interrupção do serviço Baixo Interrupção total da carga de trabalho. Dependente de Microsoft remediar. Completo
Microsoft Entra ID Má configuração Médio Os usuários não conseguem entrar. Sem efeito posterior. O suporte técnico relata o problema de configuração para a equipe de identidade. Nenhum
Power Apps Interrupção do serviço Baixo Interrupção total para usuários externos. Dependente de Microsoft remediar. Completo
Power Apps Interrupção regional Muito baixo Interrupção total para usuários externos. Dependente de Microsoft remediar. Completo
Power Apps DDoS Médio Potencial de interrupção. Microsoft gerencia a proteção DDoS (L3 e L4). Potencial de interrupção parcial
Dataverse Interrupção do serviço Baixo Interrupção total da carga de trabalho. Dependente de Microsoft remediar. Completo
Dataverse Interrupção regional Muito baixo O grupo de failover automático faz failover para a região secundária. Interrupção e potencial durante o failover. Os objetivos do tempo de recuperação (RTOs) e os objetivos do ponto de recuperação (RPOs) devem ser determinados durante o teste de confiabilidade. Potencial completo
Dataverse Ataque mal-intencionado (injeção) Médio Risco mínimo. Baixo risco em potencial
Gerenciamento de API Interrupção do serviço Baixo Interrupção total para usuários externos. Dependente de Microsoft remediar. Completo
Gerenciamento de API Interrupção regional Muito baixo Interrupção total para usuários externos. Dependente de Microsoft remediar. Completo
Gerenciamento de API DDoS Médio Potencial de interrupção. Microsoft gerencia a proteção DDoS (L3 e L4). Potencial de interrupção parcial
A solução do Power Platform Má configuração Médio As configurações incorretas devem ser detectadas durante a implantação. Se isso ocorrer durante uma atualização de configuração, os administradores deverão reverter alterações. A atualização de configuração causa uma breve interrupção externa. Potencial de interrupção total

Facilitação do Power Platform

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

  • Assine para receber a telemetria capturada pela plataforma do Dataverse no Application Insights em diagnóstico, desempenho e operação realizados pelos aplicativos no banco de dados do Dataverse e dentro dos 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.

  • Conecte os aplicativos de tela ao Application Insights para usar essas análises a fim de realizar o diagnóstico de problemas, compreender o que os usuários efetivamente fazem com os aplicativos, tomar decisões de negócios melhores e melhorar a qualidade dos aplicativos.

  • Configure a telemetria do Power Automate para fluir até o Application Insights. Você pode usar essa telemetria para monitorar execuções do fluxo da nuvem e criar alertas para falhas na execução de fluxo da nuvem.

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

Power Platform recursos registram atividades no Microsoft portal de conformidade do Purview. A maioria dos eventos estará disponível 24 horas depois da atividade. Não use essas informações no monitoramento em tempo real. Para obter mais informações sobre como registrar atividades no Power Platform, consulte:

Lista de verificação de confiabilidade

Consulte o conjunto completo de recomendações.