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 | Use a análise de modo de falha (FMA) para identificar e priorizar possíveis falhas nos componentes da solução. Execute o FMA para ajudá-lo 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 práticas recomendadas para executar a análise de modo de falha (FMA) para sua carga de trabalho. FMA é a prática de identificar potenciais pontos de falha dentro de sua carga de trabalho e os fluxos associados e planejar ações de mitigação de acordo. Em cada etapa do fluxo, você identifica o raio de explosã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 das falhas.
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 quando ocorre uma falha.
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
| 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 a ponto de ficarem indisponíveis. |
| Mitigação | As atividades que identificou para resolver problemas de forma proativa ou reativa. |
| Detection | Seus processos e procedimentos de monitoramento e alerta de infraestrutura, dados e aplicativos. |
Principais estratégias de design
Rever e implementar as recomendações para a identificação de fluxos. Supõe-se que você tenha identificado e priorizado os fluxos de usuário e sistema com base na criticidade.
Os dados que você reuniu e os artefatos que você criou em seu trabalho fornecem uma descrição concreta de seus caminhos de dados envolvidos ao longo dos fluxos. Para ter sucesso em seu trabalho de FMA, a precisão e o rigor em seus 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.
Decompor a carga de trabalho
À medida que você passa da ideação para o design, precisa identificar os tipos de componentes necessários para dar suporte à sua 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 seu projeto de arquitetura inicial, você pode sobrepor seus fluxos para identificar os componentes discretos que são usados nesses fluxos e criar listas ou diagramas de fluxo de trabalho que descrevem os fluxos e seus componentes. Para entender a criticidade dos componentes, use as definições de criticidade que você atribuiu aos fluxos. Considere o efeito de um mau funcionamento de um componente em seus fluxos.
Identificar dependências
Identifique as dependências da carga de trabalho para executar sua análise de ponto de falha único. 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. As dependências internas típicas incluem APIs ou soluções de gerenciamento de segredos/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.
Avaliar pontos de falha
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. Esses 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.
A análise deve estar sempre no contexto do fluxo que você está tentando analisar, portanto, certifique-se de documentar o efeito sobre o usuário 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. Algumas são muito improváveis, como interrupções em várias zonas ou várias regiões, e adicionar 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: construir mais resiliência e projetar para desempenho degradado.
A criação de mais resiliência inclui adicionar redundância aos seus componentes, como infraestrutura, dados e rede, e garantir que o design do aplicativo siga as práticas recomendadas para durabilidade, por exemplo, dividindo aplicativos monolíticos em aplicativos e microsserviços isolados. 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 eles estiverem ausentes ou experimentando um mau funcionamento, pode haver 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.
Detection
A deteção de falhas é essencial para garantir que você tenha identificado corretamente os pontos de falha em sua análise e planejado adequadamente suas estratégias de mitigação. A deteção, neste contexto, significa a monitorização da sua infraestrutura, dados e aplicação, e a tomada de alertas 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 monitoramento.
Resultado
Para obter o resultado de sua análise, crie um conjunto de documentos que comuniquem efetivamente suas descobertas, as decisões que você tomou em relação aos componentes de fluxo e mitigação e o efeito da falha em sua carga de trabalho.
Em sua análise, priorize os modos de falha e as estratégias de mitigação que você identificou com base na gravidade e na 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 a seguir para obter um ponto de partida da documentação.
Durante o seu exercício inicial de FMA, os documentos que você produz serão principalmente planejamento teórico. Os documentos do FMA devem ser revisados e atualizados regularmente para garantir que eles permaneçam atualizados com sua 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
Use o Azure Monitor e o Log Analytics para detetar problemas em sua carga de trabalho. Para obter mais informações sobre problemas relacionados à sua infraestrutura, aplicativos e bancos de dados, use ferramentas como Application Insights, Container Insights, Network Insights, VM Insights e SQL Insights.
O Azure Chaos Studio é um serviço gerenciado que usa engenharia de caos para ajudá-lo a medir, entender e melhorar sua resiliência de aplicativos e serviços na nuvem.
Para obter informações sobre como aplicar os princípios do FMA aos serviços comuns do Azure, consulte Análise do modo de falha para aplicativos 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.
Fluxo de usuários: login do usuário, pesquisa de produtos e interação com o carrinho de compras
| Componente | Risco | Probabilidade | Efeito/Atenuação/Nota | Indisponibilidade |
|---|---|---|---|---|
| Microsoft Entra ID | Falha do serviço | Baixo | Interrupção total da carga de trabalho. Dependente da Microsoft para corrigir. | Total |
| Microsoft Entra ID | Configuração incorreta | Médio | Os utilizadores não conseguem iniciar sessão. Sem efeito a jusante. O Help desk relata o problema de configuração para a equipe de identidade. | Nenhuma |
| Azure Front Door | Falha do serviço | Baixo | Interrupção total para usuários externos. Dependente da Microsoft para corrigir. | Apenas externo |
| Azure Front Door | Interrupção regional | Muito baixa | Efeito mínimo. O Azure Front Door é um serviço global, portanto, o roteamento de tráfego global direciona o tráfego por regiões do Azure não afetadas. | Nenhuma |
| Azure Front Door | Configuração incorreta | Médio | Erros de configuração devem ser detetados durante a implantação. Se isso acontecer durante uma atualização de configuração, os administradores deverão reverter as alterações. A atualização de configuração causa uma breve interrupção externa. | Apenas externo |
| Azure Front Door | Ataque DDoS | Médio | Potencial de interrupção. A Microsoft gerencia a proteção contra DDoS (L3 e L4) e o Azure Web Application Firewall bloqueia a maioria das ameaças. Risco potencial de efeito de ataques L7. | Potencial de interrupção parcial |
| SQL do Azure | Falha do serviço | Baixo | Interrupção total da carga de trabalho. Dependente da Microsoft para corrigir. | Total |
| SQL do Azure | Interrupção regional | Muito baixa | O grupo de failover automático realiza failover para a região secundária. Potencial interrupção durante o failover. RTOs (Recovery Time Objetives, objetivos de tempo de recuperação) e RPOs (Recovery Point Objetives, objetivos de ponto de recuperação) a serem determinados durante os testes de confiabilidade. | Potencial pleno |
| SQL do Azure | Interrupção da zona de disponibilidade | Baixo | Nenhum efeito | Nenhuma |
| SQL do Azure | Ataque malicioso (injeção) | Médio | Risco mínimo. Todas as instâncias SQL do Azure são vinculadas à rede virtual por meio de pontos de extremidade privados e os NSGs (grupos de segurança de rede) adicionam mais proteção de rede intravirtual. | Potencial baixo risco |
| Serviço de Aplicações | Falha do serviço | Baixo | Interrupção total da carga de trabalho. Dependente da Microsoft para corrigir. | Total |
| Serviço de Aplicações | Interrupção regional | Muito baixa | Efeito mínimo. Latência para usuários 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 | Interrupção da zona de disponibilidade | Baixo | Nenhum efeito. Os serviços de aplicativo foram implantados como zona redundante. Sem redundância de zona, há um potencial de efeito. | Nenhuma |
| Serviço de Aplicações | Ataque DDoS | Médio | Efeito mínimo. O tráfego de entrada é protegido pelo Azure Front Door e pelo Azure Web Application Firewall. | Nenhuma |
Ligações relacionadas
Lista de verificação de fiabilidade
Consulte o conjunto completo de recomendações.