Estratégias de arquitetura para executar 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:

A análise de modos de falha (FMA) ajuda-o a identificar potenciais pontos de falha dentro da sua carga de trabalho e dos fluxos associados. Este guia descreve as melhores práticas para realizar a FMA para que possa planear ações de mitigação, desenhar novas cargas de trabalho ou refatorar cargas existentes para minimizar o efeito generalizado das falhas. Ao analisar cada etapa do seu fluxo e identificar o raio de explosão de múltiplos tipos de falha, pode melhorar a resiliência da sua arquitetura.

Um princípio fundamental do FMA é que as falhas acontecem não importa quantas camadas de resiliência você aplique. Ambientes mais complexos estão expostos a mais tipos de falhas. Dada essa realidade, o FMA permite que você projete sua carga de trabalho para suportar a maioria dos tipos de falhas e se recupere graciosamente dentro dos objetivos de recuperação definidos.

Se você ignorar completamente o FMA ou executar uma análise incompleta, sua carga de trabalho correrá o risco de comportamento imprevisto e possíveis interrupções causadas por um projeto abaixo do ideal.

Definições

Rever e aplicar as recomendações para identificar fluxos. Assume-se que identificou e priorizou os fluxos de utilizadores e do sistema com base na criticidade.

Os dados que recolhe e os artefactos que cria no seu trabalho fornecem-lhe uma descrição concreta dos caminhos de dados envolvidos ao longo dos fluxos. Para ter sucesso no teu trabalho de FMA, a precisão e o rigor nos teus artefatos são fundamentais.

Depois de determinar os fluxos críticos, você pode planejar seus componentes necessários. Em seguida, siga cada fluxo passo a passo para identificar dependências, incluindo serviços de terceiros e possíveis pontos de falha, e planeje suas estratégias de mitigação.

Decomponha a sua carga de trabalho

À medida que avanças da ideação para o design, identifica os tipos de componentes que suportam a tua carga de trabalho. Sua carga de trabalho determina os componentes necessários para os quais você deve planejar. Normalmente, você precisa planejar o controle de entrada, rede, computação, dados, armazenamento, serviços de suporte (como autenticação, mensagens e gerenciamento de segredos ou chaves) e controle de saída. Nesta fase do seu trabalho de design, talvez você não conheça as tecnologias específicas que implantará, portanto, seu design pode se parecer com o exemplo a seguir.

Depois de criar o seu design inicial de arquitetura, sobreponha os seus fluxos para identificar os componentes discretos que são usados nesses fluxos. Crie listas ou diagramas de workflow que descrevam os fluxos e os seus componentes. Para compreender a criticidade dos componentes, use as definições de criticidade que atribuiu aos fluxos. Considere o efeito de um mau funcionamento de um componente em seus fluxos.

Identificar dependências de carga de trabalho

Identifique as dependências da sua carga de trabalho para realizar a análise do ponto único de falha. Decompor sua 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 escopo da carga de trabalho que são necessários para que a carga de trabalho funcione. Dependências internas típicas incluem APIs ou soluções de gestão de segredos e chaves como o Azure Key Vault. Para essas dependências, capture os dados de confiabilidade, como 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. As dependências externas típicas incluem soluções de autenticação, como o Microsoft Entra ID, e soluções de conectividade na nuvem, como o Azure ExpressRoute.

Identifique e documente as dependências em sua carga de trabalho e inclua-as em seus artefatos de documentação de fluxo.

Avalie os pontos de falha nos seus fluxos

Nos fluxos críticos da carga de trabalho, considere cada componente e determine como esse componente e suas dependências podem ser afetados por um modo de falha. Lembre-se de que há muitos modos de falha a serem considerados ao planejar resiliência e recuperação. Qualquer componente pode ser afetado por mais de um modo de falha a qualquer momento. Considere falhas de leitura e de escrita separadamente porque o impacto e os possíveis passos de mitigação variam. Os modos de falha incluem:

• Interrupção regional. Uma região inteira do Azure não está disponível.

• Interrupção da zona de disponibilidade. Uma zona de disponibilidade do Azure não está disponível.

• Interrupção do serviço. Um ou mais serviços do Azure não estão disponíveis.

• Negação de serviço distribuída (DDoS) ou outro ataque malicioso.

• Configuração incorreta do aplicativo ou componente.

• Erro do operador.

• Interrupção de manutenção planeada.

• Sobrecarga de componentes.

Analisa sempre o efeito no contexto do fluxo que estás a tentar analisar, por isso certifica-te de documentar o efeito no utilizador e o resultado esperado desse fluxo. Por exemplo, se você tiver um aplicativo de comércio eletrônico e estiver analisando seu fluxo de clientes, o efeito de um modo de falha específico em um ou mais componentes pode ser que todos os clientes não consigam concluir o checkout.

Considere a probabilidade de cada tipo de modo de falha. Alguns modos de falha são muito improváveis, como falhas multizona ou multirregional. Adicionar planeamento de mitigação para além da redundância não é um bom uso de recursos e tempo.

Planear estratégias de mitigação

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

Construir mais resiliência inclui adicionar redundância aos seus componentes, como infraestrutura, dados e rede, e garantir que o design da sua aplicação segue as melhores práticas de durabilidade, como dividir aplicações monolíticas em aplicações isoladas e microserviços. Para obter mais informações, consulte Recomendações para redundância e Recomendações para autopreservação.

Para projetar para desempenho degradado, identifique possíveis pontos de falha que podem 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, para que a função não esteja mais disponível na experiência do usuário. Para retornar ao exemplo de aplicativo de comércio eletrônico, um componente com falha, como um microsserviço, pode fazer com que seu mecanismo de recomendação fique indisponível, mas os clientes ainda podem pesquisar produtos e concluir a transação.

Você também precisa planejar a mitigação em torno das dependências. Dependências fortes desempenham um papel crítico na função e disponibilidade do aplicativo. Se estiverem ausentes ou com avarias, podem causar um efeito significativo. A ausência de dependências fracas pode afetar apenas 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 suas dependências. Classifique as dependências como fortes ou fracas para ajudá-lo a identificar quais componentes são essenciais para o aplicativo.

Se o aplicativo tiver dependências fortes sem as quais não possa operar, os destinos de disponibilidade e recuperação dessas dependências deverão estar alinhados com os destinos do próprio aplicativo. Minimize as dependências para obter controle sobre a confiabilidade do aplicativo. Para obter mais informações, consulte Minimizar a coordenação entre serviços de aplicativos para obter escalabilidade.

Se o ciclo de vida do aplicativo estiver intimamente ligado ao ciclo de vida de suas dependências, a agilidade operacional do aplicativo poderá ser limitada, especialmente para novas versões.

Implemente a deteção de falhas

A deteção de falhas é essencial para garantir que identifica corretamente os pontos de falha na sua análise e planeia adequadamente as suas estratégias de mitigação. Neste contexto, deteção significa monitorizar a sua infraestrutura, dados e aplicação, e alertar quando surgem problemas. Automatize a deteção tanto quanto possível e crie redundância em seus processos de operações para garantir que os alertas sejam sempre detetados e respondidos com rapidez suficiente para atender às suas necessidades de negócios. Para obter mais informações, consulte as Recomendações para monitorização.

Documente as suas conclusões de FMA

Para 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 de fluxo e mitigação, e o efeito da falha na sua 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. Use essa priorização para concentrar sua documentação nos modos de falha que são comuns e severos o suficiente para justificar o gasto de tempo, esforço e recursos no projeto de estratégias de mitigação. Por exemplo, pode haver alguns modos de falha que são muito raros na ocorrência ou deteção. Projetar estratégias de mitigação em torno deles não vale o custo.

Consulte a tabela de exemplo seguinte como ponto de partida para a documentação.

Durante o exercício inicial de FMA, os documentos que produzir consistem maioritariamente em planeamento teórico. Revise e atualize regularmente os documentos da FMA para garantir que se mantêm atualizados de acordo com a sua carga de trabalho. Testes de caos e experiências reais ajudam-no a refinar as suas análises ao longo do tempo.

Monitorização do Azure

Usa o Azure Monitor e o Log Analytics para detetar problemas na tua carga de trabalho. Para uma compreensão mais profunda dos problemas relacionados com a sua infraestrutura, aplicações e bases de dados, utilize ferramentas como Application Insights, Container Insights, Network Insights, VM Insights e SQL Insights.

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

Use o monitor de conexão e a solução de problemas de conexão no Observador de Rede do Azure para modelar e validar cenários de conectividade de rede antes da implantação. Ao simular testes sintéticos e solucionar possíveis caminhos de roteamento, essas ferramentas ajudam a antecipar e documentar possíveis modos de falha em sua arquitetura de rede. Além disso, analisando logs históricos de fluxo de rede virtual com análise de tráfego, você pode identificar padrões de tráfego bloqueado ou anômalo que podem informar sua documentação do FMA na infraestrutura do Azure.

Exemplo

A tabela a seguir mostra um exemplo de FMA para um site de comércio eletrônico hospedado em instâncias do Serviço de Aplicativo do Azure com bancos de dados SQL do Azure e encabeçado pelo Azure Front Door.

de fluxo de usuário: login do usuário, pesquisa de produtos e interação com o carrinho de compras

Link relacionado

• Resiliência e dependências

Lista de verificação de fiabilidade

Consulte o conjunto completo de recomendações.