Recomendações para executar a análise do modo de falha
Aplica-se a esta recomendação de lista de verificação de confiabilidade do Azure Well-Architected Framework:
| RE:03 | Use a FMA (análise de modo de falha) 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 FMA (análise de modo de falha) para sua carga de trabalho. O FMA é a prática de identificar possíveis pontos de falha em sua carga de trabalho e os fluxos associados e planejar ações de mitigação adequadamente. 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 importante do FMA é que as falhas ocorrem independentemente de quantas camadas de resiliência você aplicar. Ambientes mais complexos sã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 ocorre uma falha.
Se você ignorar completamente o FMA ou executar uma análise incompleta, sua carga de trabalho correrá o risco de comportamento não previsto e possíveis interrupções causadas pelo 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 de carga de trabalho sejam degradados ou severamente afetados a ponto de não estarem disponíveis. |
| Atenuação | As atividades que você identificou para resolver problemas de forma proativa ou reativamente. |
| Detecção | Seus processos e procedimentos de monitoramento e alertas de aplicativos, dados e infraestrutura. |
Principais estratégias de design
Pré-requisitos
Examine 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 criticalidade.
Os dados coletados e os artefatos que você criou em seu trabalho fornecem uma descrição concreta dos caminhos de dados envolvidos em todos os fluxos. Para ter êxito em seu trabalho de FMA, a precisão e a minuciosidade em seus artefatos são essenciais.
Abordagem de FMA
Depois de determinar os fluxos críticos, você pode planejar os 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 planejar 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 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 criticalidade dos componentes, use as definições de criticalidade atribuídas aos fluxos. Considere o efeito de um mau funcionamento do 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. Decompor sua carga de trabalho e sobrepor fluxos fornece insights sobre 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 segredos/chaves, 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 obrigató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 Microsoft Entra ID 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.
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 a resiliência e a 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.
DDoS (negação de serviço distribuído) ou outro ataque mal-intencionado.
Configuração incorreta de aplicativo ou componente.
Erro do operador.
Interrupção de manutenção planejada.
Sobrecarga de componente.
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 o fluxo do cliente, o efeito de um modo de falha específico em um ou mais componentes poderá ser que todos os clientes não consigam concluir o check-out.
Considere a probabilidade de cada tipo de modo de falha. Alguns são muito improváveis, como interrupções de 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.
Atenuação
As estratégias de mitigação se enquadram em duas categorias amplas: criar mais resiliência e projetar para desempenho degradado.
Criar mais resiliência inclui adicionar redundância aos componentes, como infraestrutura, dados e rede, e garantir que o design do aplicativo siga as melhores práticas de durabilidade, por exemplo, dividir aplicativos monolíticos em aplicativos e microsserviços isolados. Para obter mais informações, consulte Recomendações de redundância e Recomendações para autopreservação.
Para projetar um desempenho degradado, identifique possíveis pontos de falha que podem desabilitar um ou mais componentes do seu 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, de modo 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 o 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 de dependências. As dependências fortes desempenham um papel fundamental na função e na disponibilidade do aplicativo. Se eles estiverem ausentes ou apresentarem um mau funcionamento, poderá haver 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 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 se alinhar aos 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 aplicativos para obter escalabilidade.
Se o ciclo de vida do aplicativo estiver intimamente associado 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 surgirem 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 sejam respondidos rapidamente o 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 comuns e graves o suficiente para garantir 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. A criação de estratégias de mitigação em torno delas 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 de FMA inicial, 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. 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 princípios de FMA a serviços comuns do Azure, consulte Análise de 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 de Serviço de Aplicativo do Azure com bancos de dados SQL do Azure e é apresentado pelo Azure Front Door.
Fluxo do usuário: entrada do usuário, pesquisa de produto e interação de carrinho de compras
| Componente | Risco | Probabilidade | Efeito/Mitigação/Observação | Interrupção |
|---|---|---|---|---|
| Microsoft Entra ID | Interrupção do serviço | Baixo | Interrupção completa da carga de trabalho. Dependente da Microsoft para corrigir. | Completo |
| Microsoft Entra ID | Configuração incorreta | Médio | Os usuários não podem entrar. Nenhum efeito downstream. O suporte técnico relata o 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. Dependente da Microsoft para corrigir. | 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 regiões não afetadas do Azure. | Nenhum |
| Porta da frente do Azure | Configuração incorreta | Médio | Configurações incorretas devem ser capturadas 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 para interrupção. A Microsoft gerencia a proteção contra DDoS (L3 e L4) e o Azure Firewall de Aplicativo Web 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 completa da carga de trabalho. Dependente da Microsoft para corrigir. | Completo |
| SQL do Azure | Interrupção regional | Muito baixa | O grupo de failover automático faz failover para a região secundária. Possível interrupção durante o failover. RTOs (objetivos de tempo de recuperação) e RPOs (objetivos de ponto de recuperação) 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 mal-intencionado (injeção) | Médio | Risco mínimo. Todas as instâncias SQL do Azure são associadas à rede virtual por meio de pontos de extremidade privados e NSGs (grupos de segurança de rede) adicionam mais proteção de rede intra-virtual. | Risco potencial baixo |
| Serviço de Aplicativo | Interrupção do serviço | Baixo | Interrupção completa da carga de trabalho. Dependente da Microsoft para corrigir. | Completo |
| Serviço de Aplicativo | Interrupção regional | Muito baixa | Efeito mínimo. Latência para usuários em regiões efetivadas. O Azure Front Door roteia automaticamente o tráfego para regiões sem efeito. | Nenhum |
| Serviço de Aplicativo | Interrupção da zona de disponibilidade | Baixo | Nenhum efeito. Os serviços de aplicativos foram implantados como com redundância de zona. Sem redundância de zona, há um potencial para 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 Azure Firewall de Aplicativo Web. | Nenhum |
Links relacionados
Lista de verificação de confiabilidade
Consulte o conjunto completo de recomendações.
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de