Recomendações para realizar a análise do modo de falha
Aplica-se a esta recomendação da lista de verificação de fiabilidade do Azure Well-Architected Framework:
| RE:03 | Utilize a análise do modo de falha (FMA) para identificar e priorizar potenciais falhas nos componentes da solução. Execute o FMA para o ajudar a avaliar o risco e o efeito de cada modo de falha. Determine como a carga de trabalho responde e recupera. |
|---|
Este guia descreve as melhores práticas para realizar a análise do modo de falha (FMA) para a carga de trabalho. O FMA é a prática de identificar potenciais pontos de falha na carga de trabalho e os fluxos associados e planear as ações de mitigação em conformidade. Em cada passo do fluxo, identifica o raio de explosão de vários tipos de falhas, o que o ajuda a conceber uma nova carga de trabalho ou a refatorizar uma carga de trabalho existente para minimizar o efeito generalizado de falhas.
Um dos principais princípios do FMA é que as falhas ocorrem independentemente do número de camadas de resiliência que aplicar. Os ambientes mais complexos são expostos a mais tipos de falhas. Tendo em conta esta realidade, o FMA permite-lhe conceber a carga de trabalho para suportar a maioria dos tipos de falhas e recuperar corretamente quando ocorre uma falha.
Se ignorar completamente o FMA ou efetuar uma análise incompleta, a carga de trabalho está em risco de comportamento imprevisto e potenciais interrupções causadas por um design inferior ao ideal.
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 gravemente afetados ao ponto de estarem indisponíveis. |
| Mitigação | As atividades que identificou para resolver problemas de forma proativa ou reativa. |
| Deteção | Os seus processos e procedimentos de alerta e monitorização de aplicações, dados e infraestrutura. |
Principais estratégias de conceção
Pré-requisitos
Reveja e implemente as recomendações para identificar fluxos. Presume-se que identificou e atribuiu prioridades a fluxos de utilizadores e sistemas com base na importância.
Os dados que recolheu e os artefactos que criou no seu trabalho fornecem-lhe uma descrição concreta dos caminhos de dados envolvidos ao longo dos fluxos. Para ter êxito no seu trabalho do FMA, a precisão e a exatidão nos artefactos são fundamentais.
Abordagem do FMA
Depois de determinar os fluxos críticos, pode planear os componentes necessários. Em seguida, siga cada fluxo passo a passo para identificar dependências, incluindo serviços de terceiros e potenciais pontos de falha, e planeie as suas estratégias de mitigação.
Decompor a carga de trabalho
À medida que passa da ideia para a estrutura, tem de identificar os tipos de componentes necessários para suportar a carga de trabalho. A carga de trabalho determina os componentes necessários para os quais tem de planear. Normalmente, tem de planear o controlo de entradas, redes, computação, dados, armazenamento, serviços de suporte (como autenticação, mensagens e gestão de segredos ou chaves) e controlo de saída. Nesta fase do seu trabalho de conceção, poderá não conhecer as tecnologias específicas que irá implementar, pelo que a sua estrutura poderá ter um aspeto semelhante ao seguinte exemplo.
Depois de criar a sua estrutura de arquitetura inicial, pode sobrepor os fluxos para identificar os componentes discretos que são utilizados nesses fluxos e criar listas ou diagramas de fluxo de trabalho que descrevem os fluxos e os respetivos componentes. Para compreender a importância dos componentes, utilize as definições de criticidade que atribuiu aos fluxos. Considere o efeito de uma avaria do componente nos fluxos.
Identificar dependências
Identifique as dependências da carga de trabalho para realizar a análise de ponto único de falha. Decompor a carga de trabalho e sobrepor fluxos fornece informações sobre dependências internas e externas à carga de trabalho.
As dependências internas são componentes no âmbito da carga de trabalho que são necessários para a carga de trabalho funcionar. As dependências internas típicas incluem APIs ou soluções de gestão de segredos/chaves, como o Azure Key Vault. Para estas dependências, capture os dados de fiabilidade, como os SLAs de disponibilidade e os limites de dimensionamento. As dependências externas são componentes necessários fora do âmbito da carga de trabalho, como outra aplicação ou serviço de terceiros. As dependências externas típicas incluem soluções de autenticação, como Microsoft Entra ID e soluções de conectividade à cloud, como o Azure ExpressRoute.
Identifique e documente as dependências na carga de trabalho e inclua-as nos artefactos da documentação do fluxo.
Pontos de falha
Nos fluxos críticos da carga de trabalho, considere cada componente e determine como esse componente e as respetivas dependências podem ser afetados por um modo de falha. Lembre-se de que existem muitos modos de falha a considerar ao planear a resiliência e a recuperação. Qualquer componente pode ser afetado por mais do que um modo de falha em qualquer altura. Estes modos de falha incluem:
Indisponibilidade regional. Uma região inteira do Azure não está disponível.
Indisponibilidade da zona de disponibilidade. Uma zona de disponibilidade do Azure não está disponível.
Indisponibilidade do serviço. Um ou mais serviços do Azure estão indisponíveis.
Denial of Service distribuído (DDoS) ou outro ataque malicioso.
Configuração incorreta da aplicação ou componente.
Erro do operador.
Interrupção da manutenção planeada.
Sobrecarga do componente.
A análise deve estar sempre no contexto do fluxo que está a tentar analisar, por isso certifique-se de que documenta o efeito no utilizador e o resultado esperado desse fluxo. Por exemplo, se tiver uma aplicação de comércio eletrónico e estiver a analisar o fluxo de clientes, o efeito de um determinado modo de falha num ou mais componentes poderá ser o facto de todos os clientes não conseguirem concluir a finalização da compra.
Considere a probabilidade de cada tipo de modo de falha. Alguns são muito improváveis, como indisponibilidades de várias zonas ou de várias regiões, e adicionar planeamento de mitigação para além da redundância não é uma boa utilização dos recursos e do tempo.
Mitigação
As estratégias de mitigação enquadram-se em duas categorias abrangentes: criar mais resiliência e conceber um desempenho degradado.
Criar mais resiliência inclui adicionar redundância aos seus componentes, como infraestrutura, dados e rede, e garantir que a estrutura da sua aplicação segue as melhores práticas de durabilidade, por exemplo, dividir aplicações monolíticas em aplicações isoladas e microsserviços. Para obter mais informações, veja Recomendações para redundância e Recomendações para auto-preservação.
Para conceber um desempenho degradado, identifique potenciais pontos de falha que podem desativar um ou mais componentes do fluxo, mas não desativam totalmente esse fluxo. Para manter a funcionalidade do fluxo ponto a ponto, poderá ter de redirecionar um ou mais passos para outros componentes ou aceitar que um componente com falha executa uma função, pelo que a função já não está disponível na experiência do utilizador. Para voltar ao exemplo de aplicação de comércio eletrónico, um componente com falhas como um microsserviço pode fazer com que o motor de recomendação fique indisponível, mas os clientes ainda podem procurar produtos e concluir a transação.
Também tem de planear a mitigação em torno das dependências. As dependências fortes desempenham um papel fundamental na função e disponibilidade da aplicação. Se estiverem ausentes ou estiverem a sofrer uma avaria, poderá haver um efeito significativo. A ausência de dependências fracas só pode afetar funcionalidades específicas e não afetar a disponibilidade geral. Esta distinção reflete o custo para manter a relação de elevada disponibilidade entre o serviço e as respetivas dependências. Classifique as dependências como fortes ou fracas para ajudar a identificar que componentes são essenciais para a aplicação.
Se a aplicação tiver dependências fortes sem as quais não consegue operar, os destinos de disponibilidade e recuperação destas dependências deverão estar alinhados com os destinos da própria aplicação. Minimize as dependências para obter controlo sobre a fiabilidade da aplicação. Para obter mais informações, veja Minimizar a coordenação entre os serviços de aplicações para alcançar a escalabilidade.
Se o ciclo de vida da aplicação estiver estreitamente associado ao ciclo de vida das respetivas dependências, a agilidade operacional da aplicação poderá ser limitada, especialmente para novas versões.
Deteção
A deteção de falhas é essencial para garantir que identificou corretamente pontos de falha na sua análise e planeou corretamente as estratégias de mitigação. Neste contexto, a deteção significa a monitorização da sua infraestrutura, dados e aplicações e alertas quando surgem problemas. Automatize a deteção o máximo possível e crie redundância nos seus processos de operações para garantir que os alertas são sempre detetados e que são respondidos com rapidez suficiente para satisfazer os seus requisitos empresariais. Para obter mais informações, veja Recomendações para monitorização.
Resultado
Para obter o resultado da sua análise, crie um conjunto de documentos que comuniquem eficazmente as suas conclusões, as decisões que tomou relativamente aos componentes do fluxo e a mitigação e o efeito da falha na carga de trabalho.
Na sua análise, priorize os modos de falha e as estratégias de mitigação que identificou com base na gravidade e probabilidade. Utilize esta atribuição de prioridades para focar a sua documentação nos modos de falha que são comuns e severos o suficiente para garantir que gasta tempo, esforço e recursos na conceção de estratégias de mitigação. Por exemplo, podem existir alguns modos de falha que são muito raros na ocorrência ou deteção. Conceber estratégias de mitigação à sua volta não vale o custo.
Veja a tabela de exemplo seguinte para obter um ponto de partida da documentação.
Durante o exercício FMA inicial, os documentos que produzir serão maioritariamente planeamento teórico. Os documentos FMA devem ser revistos e atualizados regularmente para garantir que se mantêm atualizados com a carga de trabalho. Os testes de caos e as experiências do mundo real irão ajudá-lo a refinar as suas análises ao longo do tempo.
Facilitação do Azure
Utilize o Azure Monitor e o Log Analytics para detetar problemas na carga de trabalho. Para obter mais informações sobre problemas relacionados com a sua infraestrutura, aplicações e bases de dados, utilize ferramentas como o Application Insights, o Container Insights, o Network Insights, o VM Insights e o SQL Insights.
O Azure Chaos Studio é um serviço gerido que utiliza a engenharia de caos para o ajudar a medir, compreender e melhorar a resiliência da aplicação na cloud e do serviço.
Para obter informações sobre como aplicar princípios FMA a serviços comuns do Azure, veja Análise do modo de falha para aplicações do Azure.
Exemplo
A tabela seguinte mostra um exemplo de FMA para um site de comércio eletrónico alojado em instâncias Serviço de Aplicações do Azure com bases de dados SQL do Azure e é apresentado pelo Azure Front Door.
Fluxo de utilizador: Início de sessão do utilizador, pesquisa de produtos e interação do carrinho de compras
| Componente | Risco | Probabilidade | Efeito/Mitigação/Nota | Indisponibilidade |
|---|---|---|---|---|
| Microsoft Entra ID | Falha do serviço | Baixo | Indisponibilidade total da carga de trabalho. Dependente da Microsoft para remediar. | Completa |
| Microsoft Entra ID | Configuração incorreta | Médio | Os utilizadores não conseguem iniciar sessão. Sem efeito a jusante. O suporte técnico comunica o problema de configuração da equipa de identidade. | Nenhuma |
| Azure Front Door | Falha do serviço | Baixo | Indisponibilidade total para utilizadores externos. Dependente da Microsoft para remediar. | Apenas externo |
| Azure Front Door | Indisponibilidade regional | Muito baixa | Efeito mínimo. O Azure Front Door é um serviço global, pelo que o encaminhamento de tráfego global direciona o tráfego através de regiões do Azure não afetadas. | Nenhuma |
| Azure Front Door | Configuração incorreta | Médio | As configurações incorretas devem ser detetas durante a implementação. Se estas ocorrerem durante uma atualização de configuração, os administradores têm de reverter as alterações. A atualização de configuração causa uma breve indisponibilidade externa. | Apenas externo |
| Azure Front Door | Ataque DDoS | Médio | Potencial de interrupção. A Microsoft gere a proteção do DDoS (L3 e L4) e o Azure Firewall de Aplicações Web bloqueia a maioria das ameaças. Risco potencial de efeito de ataques L7. | Potencial para indisponibilidade parcial |
| SQL do Azure | Falha do serviço | Baixo | Indisponibilidade total da carga de trabalho. Dependente da Microsoft para remediar. | Completa |
| SQL do Azure | Indisponibilidade regional | Muito baixa | O grupo de ativação pós-falha automática faz a ativação pós-falha para a região secundária. Potencial indisponibilidade durante a ativação pós-falha. Objetivos de tempo de recuperação (RTOs) e objetivos de ponto de recuperação (RPOs) a determinar durante o teste de fiabilidade. | Potencial completo |
| SQL do Azure | Indisponibilidade da zona de disponibilidade | Baixo | Nenhum efeito | Nenhuma |
| SQL do Azure | Ataque malicioso (injeção) | Médio | Risco mínimo. Todas as SQL do Azure instâncias estão vinculadas à rede virtual através de pontos finais privados e os grupos de segurança de rede (NSGs) adicionam mais proteção de rede intra-virtual. | Potencial baixo risco |
| Serviço de Aplicações | Falha do serviço | Baixo | Indisponibilidade total da carga de trabalho. Dependente da Microsoft para remediar. | Completa |
| Serviço de Aplicações | Indisponibilidade regional | Muito baixa | Efeito mínimo. Latência para utilizadores em regiões afetadas. O Azure Front Door encaminha automaticamente o tráfego para regiões não afetadas. | Nenhuma |
| Serviço de Aplicações | Indisponibilidade da zona de disponibilidade | Baixo | Nenhum efeito. Os serviços de aplicações foram implementados como redundância entre zonas. Sem redundância entre zonas, existe um potencial de efeito. | Nenhuma |
| Serviço de Aplicações | Ataque DDoS | Médio | Efeito mínimo. O tráfego de entrada está protegido pelo Azure Front Door e pelo Azure Firewall de Aplicações Web. | Nenhuma |
Ligações relacionadas
Lista de verificação de fiabilidade
Veja o conjunto completo de recomendações.
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários