Análise de modo de falha para aplicativos do Azure

A análise de modo de falha (FMA) é um processo para construir confiabilidade em um sistema, identificando possíveis pontos de falha. O FMA deve fazer parte das fases de arquitetura e projeto, para que você possa criar resiliência (a capacidade de resistir a falhas) e capacidade de recuperação (a capacidade de restaurar a funcionalidade após falhas) no sistema desde o início.

Aqui está o processo geral para conduzir um FMA:

1. Identifique todos os componentes do sistema. Incluir dependências externas, como fornecedores de identidade e serviços de terceiros.

2. Para cada componente, identifique possíveis falhas que possam ocorrer. Um único componente pode ter mais de um modo de falha. Por exemplo, você deve considerar falhas de leitura e falhas de gravação separadamente, porque o impacto e as possíveis etapas de mitigação serão diferentes.

3. Classifique cada modo de falha de acordo com seu risco geral. Considere estes fatores:

   • Qual é a probabilidade de falha? É relativamente comum? Extremamente raro? Você não precisa de números exatos; O objetivo é ajudar a hierarquizar a prioridade.
   • Qual é o impacto no aplicativo, em termos de disponibilidade, perda de dados, custo monetário e interrupção dos negócios?

4. Para cada modo de falha, determine como o aplicativo responderá e se recuperará. Considere compensações em custo e complexidade de aplicativos.

Como ponto de partida para seu processo de FMA, este artigo contém um catálogo de possíveis modos de falha e suas etapas de mitigação. O catálogo é organizado por tecnologia ou serviço do Azure, além de uma categoria geral para design no nível do aplicativo. O catálogo não é exaustivo, mas abrange muitos dos principais serviços do Azure.

Microsoft Entra ID

A autenticação do OpenID Connect falha.

Deteção. Os possíveis modos de falha incluem:

1. O Microsoft Entra ID não está disponível ou não pode ser acessado devido a um problema de rede. O redirecionamento para o endpoint de autenticação falha, e o middleware OpenID Connect lança uma exceção.
2. O inquilino do Microsoft Entra não existe. O redirecionamento para o endpoint de autenticação retorna um código de erro HTTP e o middleware OpenID Connect lança uma exceção.
3. O usuário não pode autenticar. Nenhuma estratégia de deteção é necessária; O Microsoft Entra ID lida com falhas de login.

Recuperação:

1. Intercepte exceções não tratadas pelo middleware.
2. Manipular eventos AuthenticationFailed.
3. Redirecionar o usuário para uma página de erro.
4. Reintentos do utilizador.

Pesquisa de IA do Azure

A gravação de dados na Pesquisa de IA do Azure falha.

Deteção. Detetar erros Microsoft.Rest.Azure.CloudException.

Recuperação:

O SDK do Search .NET tenta novamente automaticamente após falhas transitórias. Quaisquer exceções geradas pelo SDK do cliente devem ser tratadas como erros não transitórios.

A política de repetição padrão usa retirada exponencial. Para usar uma política de repetição diferente, chame SetRetryPolicy na classe SearchIndexClient ou SearchServiceClient. Para obter mais informações, consulte Tentativas automáticas.

Diagnósticos. Use a Análise de Tráfego de Pesquisa.

A leitura de dados da Pesquisa de IA do Azure falha.

Deteção. Detetar erros Microsoft.Rest.Azure.CloudException.

Recuperação:

O SDK do Search .NET tenta novamente automaticamente após falhas transitórias. Quaisquer exceções geradas pelo SDK do cliente devem ser tratadas como erros não transitórios.

A política de repetição padrão usa retirada exponencial. Para usar uma política de repetição diferente, chame SetRetryPolicy na classe SearchIndexClient ou SearchServiceClient. Para obter mais informações, consulte Tentativas automáticas.

Diagnósticos. Use a Análise de Tráfego de Pesquisa.

Cassandra

A leitura ou a gravação num nó falha.

Deteção. Pegue a exceção. Para clientes .NET, normalmente será System.Web.HttpException. Outro cliente pode ter outros tipos de exceção. Para obter mais informações, consulte Tratamento de erros do Cassandra da forma correta.

Recuperação:

• Cada cliente Cassandra tem as suas próprias políticas e capacidades de tentativa. Para obter mais informações, consulte Tratamento de erros do Cassandra da forma correta.
• Utilize uma configuração com reconhecimento de rack, com nós de dados distribuídos pelos domínios de falha.
• Despachar para várias regiões com consistência de quórum local. Se ocorrer uma falha não transitória, faça failover para outra região.

Diagnósticos. Registos de aplicações

armazenamento de Filas

A tentativa de escrever uma mensagem no armazenamento de filas do Azure falha de forma consistente.

Deteção. Após N novas tentativas, a operação de gravação ainda falha.

Recuperação:

• Armazene os dados em um cache local e encaminhe as gravações para o armazenamento mais tarde, quando o serviço estiver disponível.
• Crie uma fila secundária e grave nessa fila se a fila principal não estiver disponível.

Diagnósticos. Use métricas de armazenamento.

O aplicativo não pode processar uma mensagem específica da fila.

Deteção. Aplicação específica. Por exemplo, a mensagem contém dados inválidos ou a lógica de negócios falha por algum motivo.

Recuperação:

Mova a mensagem para uma fila separada. Execute um processo separado para examinar as mensagens nessa fila.

Considere usar filas de mensagens do Barramento de Serviço do Azure, que fornece uma funcionalidade de fila de mensagens mortas para essa finalidade.

Diagnósticos. Utilize o registo da aplicação.

Base de Dados SQL

Não é possível conectar-se ao banco de dados na região primária.

Deteção. A conexão falha.

Recuperação:

• Habilite a redundância de zona. Ao habilitar a redundância de zona, o Banco de Dados SQL do Azure replica automaticamente suas gravações em várias zonas de disponibilidade do Azure em regiões com suporte. Para obter mais informações, consulte Disponibilidade com redundância de zona.

• Ative a georreplicação. Se você estiver projetando uma solução de várias regiões, considere habilitar a replicação geográfica ativa do Banco de dados SQL.

  Pré-requisito: O banco de dados deve ser configurado para replicação geográfica ativa. Consulte Replicação geográfica ativa do Banco de dados SQL.

  • Para consultas, leia de uma réplica secundária.
  • Para inserções e atualizações, alterne manualmente para uma réplica secundária. Consulte Iniciar um failover planeado ou não planeado para o Banco de Dados SQL do Azure.

  A réplica usa uma cadeia de conexão diferente, portanto, você precisará atualizar a cadeia de conexão em seu aplicativo.

O cliente fica sem conexões no pool de conexões.

Deteção. Detetar erros System.InvalidOperationException.

Recuperação:

• Repita a operação.
• Como plano de mitigação, isole os pools de conexões para cada caso de uso, para que um caso de uso não possa dominar todas as conexões.
• Aumente o máximo de grupos de ligações.

Diagnósticos. Registos de aplicações.

O limite de conexão do banco de dados foi atingido.

Deteção. O Banco de Dados SQL do Azure limita o número de trabalhadores, logons e sessões simultâneos. Os limites dependem da camada de serviço. Para obter mais informações, consulte Limites de recursos do Banco de Dados SQL do Azure.

Para detetar esses erros, detete System.Data.SqlClient.SqlException e verifique o valor do código de erro SQL SqlException.Number . Para obter uma lista de códigos de erro relevantes, consulte Códigos de erro SQL para aplicativos cliente do Banco de dados SQL: erro de conexão de banco de dados e outros problemas.

Recuperação. Esses erros são considerados transitórios, portanto, tentar novamente pode resolver o problema. Se você encontrar esses erros de forma consistente, considere aumentar a capacidade do banco de dados.

Diagnósticos. - A consulta sys.event_log retorna conexões de banco de dados bem-sucedidas, falhas de conexão e deadlocks.

• Crie uma regra de alerta para falhas de conexão.
• Habilite a auditoria do Banco de dados SQL e verifique se há logins com falha.

Mensagens do Service Bus

A tentativa de leitura de uma mensagem de uma fila do Service Bus não é bem-sucedida.

Deteção. Intercepte exceções do SDK do cliente. A classe base para exceções do Service Bus é MessagingException. Se o erro for transitório, a IsTransient propriedade será true.

Para obter mais informações, consulte Exceções de mensagens do Service Bus.

Recuperação:

1. Tente novamente nas falhas transitórias.
2. As mensagens que não podem ser entregues a nenhum destinatário são colocadas em uma fila de mensagens mortas. Use esta fila para ver quais mensagens não puderam ser recebidas. Não há limpeza automática da fila de mensagens não entregues. As mensagens permanecem lá até que você as recupere explicitamente. Consulte Visão geral das filas de mensagens mortas do Service Bus.

Ao escrever uma mensagem numa fila do Service Bus, ocorre uma falha.

Deteção. Intercepte exceções do SDK do cliente. A classe base para exceções do Service Bus é MessagingException. Se o erro for transitório, a IsTransient propriedade será true.

Para obter mais informações, consulte Exceções de mensagens do Service Bus.

Recuperação:

• O cliente do Service Bus tenta novamente automaticamente após erros transitórios. Por padrão, ele utiliza um método de "back-off" exponencial. Após atingir a contagem máxima de tentativas ou o tempo limite máximo, o cliente gera uma exceção.

• Se a cota de fila for excedida, o cliente lançará QuotaExceededException. A mensagem de exceção fornece mais detalhes. Remova algumas mensagens da fila antes de tentar novamente e considere usar o Circuit Breaker para evitar novas tentativas contínuas enquanto se excede a quota. Além disso, verifique se a propriedade BrokeredMessage.TimeToLive não está configurada como muito alta.

• Dentro de uma região, a resiliência pode ser melhorada usando filas particionadas ou tópicos. Uma fila ou tópico não particionado é atribuído a um sistema de armazenamento de mensagens. Se esse armazenamento de mensagens estiver indisponível, todas as operações nessa fila ou tópico falharão. Uma fila ou tópico particionado é particionado em vários armazenamentos de mensagens.

• Use a redundância de zona para replicar automaticamente as alterações entre várias zonas de disponibilidade. Se uma zona de disponibilidade falhar, o failover acontece automaticamente. Para obter mais informações, consulte Práticas recomendadas para isolar aplicativos contra interrupções e desastres do Service Bus.

• Se você estiver projetando uma solução de várias regiões, crie dois namespaces do Service Bus em regiões diferentes e replique as mensagens. Você pode usar a replicação ativa ou a replicação passiva.

  • Replicação ativa: o cliente envia todas as mensagens para ambas as filas. O recetor monitoriza ambas as filas. Marque mensagens com um identificador exclusivo, para que o cliente possa descartar mensagens duplicadas.
  • Replicação passiva: o cliente envia a mensagem para uma fila. Se houver um erro, o cliente voltará para a outra fila. O recetor monitoriza ambas as filas. Essa abordagem reduz o número de mensagens duplicadas enviadas. No entanto, o recetor ainda deve lidar com mensagens duplicadas.

  Para obter mais informações, consulte Exemplo de GeoReplication e Práticas recomendadas para isolar aplicativos contra interrupções e desastres do Service Bus.

Mensagem duplicada.

Deteção. Examine as propriedades MessageId e DeliveryCount da mensagem.

Recuperação:

• Se possível, projete suas operações de processamento de mensagens para serem idempotentes. Caso contrário, armazene IDs de mensagens que já foram processadas e verifique a ID antes de processar uma mensagem.

• Ative a deteção de duplicados, criando a fila com RequiresDuplicateDetection definido como verdadeiro. Com essa configuração, o Service Bus exclui automaticamente qualquer mensagem enviada com o mesmo MessageId que uma mensagem anterior. Observe os seguintes pontos:

  • Essa configuração impede que mensagens duplicadas sejam colocadas na fila. Isso não impede que um recetor processe a mesma mensagem mais de uma vez.
  • A deteção de duplicados tem uma janela de tempo. Se uma duplicata for enviada além dessa janela, ela não será detetada.

Diagnósticos. Registrar mensagens duplicadas.

O aplicativo não pode processar uma mensagem específica da fila.

Deteção. Aplicação específica. Por exemplo, a mensagem contém dados inválidos ou a lógica de negócios falha por algum motivo.

Recuperação:

Há dois modos de falha a considerar.

• O recetor deteta a falha. Nesse caso, mova a mensagem para a fila de mensagens mortas. Mais tarde, execute um processo separado para examinar as mensagens na fila de mensagens mortas.
• O recetor falha no meio do processamento da mensagem — por exemplo, devido a uma exceção não tratada. Para lidar com esse caso, use o modo PeekLock. Neste modo, se o bloqueio expirar, a mensagem fica disponível para outros recetores. Se a mensagem exceder a contagem máxima de entrega ou o tempo de vida, a mensagem será automaticamente movida para a fila de mensagens mortas.

Para obter mais informações, consulte Visão geral das filas de mensagens não entregues do Service Bus.

Diagnósticos. Sempre que a aplicação mover uma mensagem para a fila de mensagens não entregues, escreva um evento nos logs da aplicação.

Armazenamento

Falha ao gravar dados no Armazenamento do Azure

Deteção. O cliente recebe erros ao escrever.

Recuperação:

1. Tente novamente a operação, para recuperar de falhas transitórias. A política de repetição no SDK do cliente lida com isso automaticamente.

2. Implemente o padrão Circuit Breaker para evitar sobrecarregar o armazenamento.

3. Se N tentativas de repetição falharem, execute uma alternativa elegante. Por exemplo:

   • Armazene os dados em um cache local e encaminhe as gravações para o armazenamento mais tarde, quando o serviço estiver disponível.
   • Se a ação de gravação estivesse num escopo transacional, compense a transação.

Diagnósticos. Use métricas de armazenamento.

A leitura de dados do Armazenamento do Azure falha.

Deteção. O cliente recebe erros ao ler.

Recuperação:

1. Tente novamente a operação, para recuperar de falhas transitórias. A política de repetição no SDK do cliente lida com isso automaticamente.
2. Para armazenamento RA-GRS, se a leitura do ponto de extremidade primário falhar, tente ler a partir do ponto de extremidade secundário. O SDK do cliente pode lidar com isso automaticamente. Consulte Replicação do Armazenamento Azure.
3. Se as tentativas de nova execução de N falharem, execute uma ação alternativa para reduzir o impacto de modo controlado. Por exemplo, se não for possível recuperar uma imagem de produto do armazenamento, mostre uma imagem genérica de substituição.

Diagnósticos. Use métricas de armazenamento.

Máquina virtual

A conexão com uma VM de back-end falha.

Deteção. Erros de conexão de rede.

Recuperação:

• Implante pelo menos duas VMs de back-end num conjunto de disponibilidade, atrás de um equilibrador de carga.
• Se o erro de conexão for transitório, às vezes o TCP tentará enviar a mensagem novamente.
• Implemente uma política de repetição no aplicativo.
• Para erros persistentes ou não transitórios, implemente o Padrão Circuit Breaker.
• Se a VM que efetuar a chamada exceder o seu limite de saída de rede, a fila de saída será preenchida. Se a fila de saída estiver constantemente cheia, considere a expansão.

Diagnósticos. Registar eventos nos limites dos serviços.

Uma instância de VM torna-se indisponível ou não saudável.

Deteção. Configure uma sondagem de saúde do Balanceador de Carga que indique se a instância da VM está saudável. A sonda deve verificar se as funções críticas estão a responder corretamente.

Recuperação. Para cada camada de aplicativo, coloque várias instâncias de VM no mesmo conjunto de disponibilidade e coloque um balanceador de carga na frente das VMs. Se a sonda de integridade falhar, o balanceador de carga deixará de enviar novas conexões para a instância com falha.

Diagnósticos. - Utilize a análise de logs do Load Balancer.

• Configure o seu sistema de monitorização para monitorizar todos os pontos de monitorização da integridade.

O operador desliga acidentalmente uma VM.

Deteção. N/A

Recuperação. Defina um bloqueio de recursos ao nível de ReadOnly. Consulte Bloquear recursos com o Azure Resource Manager.

Diagnósticos. Use os logs de atividade do Azure.

Próximos passos

Consulte Identificar dependências no Azure Well-Architected Framework. A recuperação de falhas na construção do sistema deve fazer parte das fases de arquitetura e projeto desde o início, a fim de evitar o risco de falha.