Recomendações para executar a análise do modo de falha
Aplica-se a esta recomendação da lista de verificação de confiabilidade 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 melhores práticas para executar a análise do modo de falha (FMA) para sua carga de trabalho. FMA é a prática de identificar possíveis pontos de falha em sua carga de trabalho e nos 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 você a projetar uma nova carga de trabalho ou refatorar uma carga de trabalho existente para minimizar o efeito generalizado de 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 recuperar normalmente quando ocorrer uma falha.
Se você ignorar completamente o FMA ou realizar uma análise incompleta, sua carga de trabalho correrá o risco de comportamento imprevisto e possíveis interrupções causadas por um design 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 severamente afetados a ponto de ficarem indisponíveis. |
| Mitigação | As atividades que você identificou para resolver problemas de forma proativa ou reativa. |
| Detecção | Seus processos e procedimentos de monitoramento e alerta de infraestrutura, dados e aplicativos. |
Principais estratégias de design
Revise e implemente as recomendações para identificar fluxos. Supõe-se que você tenha identificado e priorizado fluxos de usuário e sistema com base na criticidade.
Os dados coletados e os artefatos criados em seu trabalho fornecem uma descrição concreta de seus caminhos de dados envolvidos em todos os fluxos. Para ter sucesso em seu trabalho FMA, a precisão e o rigor em seus artefatos são essenciais.
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 geração de ideias para o design, você 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. Neste estágio do seu trabalho de design, talvez você não conheça as tecnologias específicas que implantará, portanto, seu design pode ser semelhante ao exemplo a seguir.
Depois de criar seu design 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ê designou aos fluxos. Considere o efeito de um mau funcionamento de um componente em seus fluxos.
Identificar dependências
Identifique suas dependências de carga de trabalho para executar sua análise de ponto único de falha. A decomposição da carga de trabalho e a sobreposição de fluxos fornecem informações sobre as dependências internas e externas à carga de trabalho.
As dependências internas são componentes no escopo da carga de trabalho necessários para que a carga de trabalho funcione. As dependências internas típicas incluem APIs ou soluções de gerenciamento de segredo/chave, como o Azure Key Vault. Para essas dependências, capture os dados de confiabilidade, como SLAs de disponibilidade e limites de dimensionamento. 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 a ID do Microsoft Entra, e soluções de conectividade de 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 mal-intencionado.
Configuração incorreta de aplicativo ou componente.
Erro do operador.
Interrupção de manutenção planejada.
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 no usuário e o resultado esperado desse fluxo. Por exemplo, se você tiver um aplicativo de comércio eletrônico e estiver analisando o fluxo do cliente, 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 são muito improváveis, como interrupções em várias zonas ou 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: criar mais resiliência e projetar para desempenho degradado.
Criar 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 de 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 desabilite 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 sua transação.
Você também precisa planejar a mitigação em torno das dependências. As dependências fortes desempenham um papel fundamental na função e na disponibilidade do aplicativo. Se eles estiverem ausentes ou com 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 pode 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 os serviços de aplicativo para obter escalabilidade.
Se o ciclo de vida do aplicativo estiver intimamente acoplado ao ciclo de vida de suas dependências, a agilidade operacional do aplicativo poderá ser limitada, especialmente para novas versões.
Detecção
A detecção de falhas é essencial para garantir que você tenha identificado corretamente os pontos de falha em sua análise e planejado corretamente suas estratégias de mitigação. Detecção nesse contexto significa o monitoramento de sua infraestrutura, dados e aplicativos e alertas quando surgem problemas. Automatize a detecção o máximo possível e crie redundância em seus processos de operações para garantir que os alertas sejam sempre capturados e respondidos com rapidez suficiente para atender aos seus requisitos de negócios. Para obter mais informações, consulte as Recomendações para monitoramento.
Resultado
Para 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 graves o suficiente para justificar o gasto de tempo, esforço e recursos na criação de estratégias de mitigação. Por exemplo, pode haver alguns modos de falha que são muito raros na ocorrência ou detecçã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 exercício inicial do FMA, os documentos que você produzir serão principalmente planejamento teórico. Os documentos FMA devem ser revisados e atualizados regularmente para garantir que permaneçam atualizados com sua carga de trabalho. Testes de caos e experiências do mundo real ajudarão você a refinar suas análises ao longo do tempo.
Facilitação do Azure
Use o Azure Monitor e o Log Analytics para detectar 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 a engenharia do caos para ajudar você a avaliar, entender e melhorar a resiliência de aplicativos e serviços de 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 liderado pelo Azure Front Door.
Fluxo do usuário: entrada do usuário, pesquisa de produtos e interação com o carrinho de compras
| Componente | Risco | Probabilidade | Efeito/Mitigação/Nota | Interrupção |
|---|---|---|---|---|
| ID do Microsoft Entra | Interrupção do serviço | Baixo | Interrupção total da carga de trabalho. Correção dependente da Microsoft. | Completo |
| ID do Microsoft Entra | Configuração incorreta | Médio | Os usuários não conseguem fazer login. Sem efeito posterior. O suporte técnico relata problema de configuração para a equipe de identidade. | Nenhum |
| Porta da frente do Azure | Interrupção do serviço | Baixo | Interrupção total para usuários externos. Correção dependente da Microsoft. | Apenas externo |
| Porta da frente do Azure | 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 meio de regiões do Azure não afetadas. | Nenhum |
| Porta da frente do Azure | Configuração incorreta | Médio | Configurações incorretas devem ser detectadas 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 |
| Porta da frente do Azure | Ataque de DDoS | Médio | Potencial de interrupção. A Microsoft gerencia a proteção contra DDoS (L3 e L4) e o Firewall de Aplicativo Web do Azure bloqueia a maioria das ameaças. Risco potencial de efeito de ataques L7. | Potencial para interrupção parcial |
| SQL do Azure | Interrupção do serviço | Baixo | Interrupção total da carga de trabalho. Correção dependente da Microsoft. | Completo |
| SQL do Azure | Interrupção regional | Muito baixa | Failover automático do grupo para a região secundária. Interrupção potencial durante o failover. Objetivos de tempo de recuperação (RTOs) e objetivos de ponto de recuperação (RPOs) a serem determinados durante o teste de confiabilidade. | Potencial completo |
| SQL do Azure | Interrupção da zona de disponibilidade | Baixo | Sem efeito | Nenhum |
| SQL do Azure | Ataque malicioso (injeção) | Médio | Risco mínimo. Todas as instâncias do SQL do Azure são vinculadas à rede virtual por meio de pontos de extremidade privados e NSGs (grupos de segurança de rede) adicionam proteção adicional de rede intravirtual. | Potencial de baixo risco |
| Serviço de Aplicativo | Interrupção do serviço | Baixo | Interrupção total da carga de trabalho. Correção dependente da Microsoft. | Completo |
| Serviço de Aplicativo | Interrupção regional | Muito baixa | Efeito mínimo. Latência para usuários em regiões afetadas. O Azure Front Door roteia automaticamente o tráfego para regiões não afetadas. | Nenhum |
| Serviço de Aplicativo | Interrupção da zona de disponibilidade | Baixo | Nenhum efeito. Os serviços de aplicativos foram implantados como redundância de zona. Sem redundância de zona, há um potencial de efeito. | Nenhum |
| Serviço de Aplicativo | Ataque de DDoS | Médio | Efeito mínimo. O tráfego de entrada é protegido pelo Azure Front Door e pelo Firewall de Aplicativo Web do Azure. | Nenhum |
Links relacionados
Lista de verificação de confiabilidade
Consulte o conjunto completo de recomendações.