Análise de modo de falha para aplicativos do Azure

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

Aqui está o processo geral para conduzir um FMA:

1. Identifique todos os componentes do sistema. Inclua dependências externas, como provedores de identidade, serviços de terceiros e assim por diante.

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 do fracasso. É 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.

Serviço de Aplicações

O aplicativo do Serviço de Aplicativo é desligado.

Deteção. Causas possíveis:

• Desligamento esperado

  • Um operador desliga o aplicativo; por exemplo, usando o portal do Azure.
  • O aplicativo foi descarregado porque estava ocioso. (Somente se a Always On configuração estiver desativada.)

• Desligamento inesperado

  • O aplicativo falha.
  • Uma instância de VM do Serviço de Aplicativo fica indisponível.

Application_End log detetará o desligamento do domínio do aplicativo (falha do processo suave) e é a única maneira de capturar os desligamentos do domínio do aplicativo.

Recuperação:

• Se o desligamento era esperado, use o evento de desligamento do aplicativo para desligar normalmente. Por exemplo, em ASP.NET, use o Application_End método.
• Se o aplicativo foi descarregado enquanto ocioso, ele é reiniciado automaticamente na próxima solicitação. No entanto, incorrerá no custo do "arranque a frio".
• Para evitar que o aplicativo seja descarregado enquanto estiver ocioso, habilite a Always On configuração no aplicativo Web. Consulte Configurar aplicativos Web no Serviço de Aplicativo do Azure.
• Para impedir que um operador desligue o aplicativo, defina um bloqueio de recursos com ReadOnly nível. Consulte Bloquear recursos com o Azure Resource Manager.
• Se o aplicativo falhar ou uma VM do Serviço de Aplicativo ficar indisponível, o Serviço de Aplicativo reiniciará automaticamente o aplicativo.

Diagnósticos. Logs de aplicativos e logs do servidor Web. Consulte Habilitar o log de diagnóstico para aplicativos Web no Serviço de Aplicativo do Azure.

Um determinado usuário repetidamente faz solicitações incorretas ou sobrecarrega o sistema.

Deteção. Autentique usuários e inclua ID de usuário em logs de aplicativos.

Recuperação:

• Use o Gerenciamento de API do Azure para limitar as solicitações do usuário. Consulte Limitação avançada de solicitações com o Gerenciamento de API do Azure
• Bloquear o usuário.

Diagnósticos. Registre todas as solicitações de autenticação.

Uma atualização incorreta foi implantada.

Deteção. Monitore a integridade do aplicativo por meio do portal do Azure (consulte Monitorar o desempenho do aplicativo Web do Azure) ou implemente o padrão de monitoramento do ponto de extremidade de integridade.

Recuperação:. Use vários slots de implantação e reverta para a última implantação em boas condições. Para obter mais informações, consulte Aplicativo Web básico.

Microsoft Entra ID

A autenticação do OpenID Connect falha.

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

1. Microsoft Entra ID não está disponível ou não pode ser alcançado devido a um problema de rede. O redirecionamento para o ponto de extremidade de autenticação falha e o middleware OpenID Connect gera uma exceção.
2. O locatário do Microsoft Entra não existe. O redirecionamento para o ponto de extremidade de autenticação retorna um código de erro HTTP e o middleware OpenID Connect gera 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. Detete exceções não tratadas do middleware.
2. Manipular AuthenticationFailed eventos.
3. Redirecionar o usuário para uma página de erro.
4. Tentativas do usuário.

Azure Search

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

Deteção. Erros de captura 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 back-off exponencial. Para usar uma política de repetição diferente, chame SetRetryPolicy a SearchIndexClient classe 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 do Azure falha.

Deteção. Erros de captura 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 back-off exponencial. Para usar uma política de repetição diferente, chame SetRetryPolicy a SearchIndexClient classe 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 gravação em um nó falha.

Deteção. Pegue a exceção. Para clientes .NET, isso normalmente System.Web.HttpExceptionserá . Outro cliente pode ter outros tipos de exceção. Para obter mais informações, consulte Tratamento de erros Cassandra feito corretamente.

Recuperação:

• Cada cliente Cassandra tem suas próprias políticas e recursos de repetição. Para obter mais informações, consulte Tratamento de erros Cassandra feito corretamente.
• Use uma implantação com reconhecimento de rack, com nós de dados distribuídos pelos domínios de falha.
• Implante em 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

Serviço de Nuvem

As funções Web ou de trabalho estão sendo encerradas inesperadamente.

Deteção. O evento RoleEnvironment.Stopping é acionado.

Recuperação. Substitua o método RoleEntryPoint.OnStop para limpar normalmente. Para obter mais informações, consulte A maneira certa de lidar com eventos do Azure OnStop (blog).

Azure Cosmos DB

A leitura de dados falha.

Deteção. Captura System.Net.Http.HttpRequestException ou Microsoft.Azure.Documents.DocumentClientException.

Recuperação:

• O SDK tenta novamente automaticamente as tentativas falhadas. Para definir o número de novas tentativas e o tempo máximo de espera, configure ConnectionPolicy.RetryOptions. As exceções geradas pelo cliente vão além da política de repetição ou não são erros transitórios.
• Se o Azure Cosmos DB limitar o cliente, ele retornará um erro HTTP 429. Verifique o código de estado na DocumentClientException. Se você estiver recebendo o erro 429 de forma consistente, considere aumentar o valor da taxa de transferência da coleção.
  • Se você estiver usando a API do MongoDB, o serviço retornará o código de erro 16500 durante a limitação.
• Habilite a redundância de zona ao trabalhar com uma região que ofereça suporte a zonas de disponibilidade. Quando você usa redundância de zona, o Azure Cosmos DB executa automaticamente failover no caso de uma interrupção de zona. Para obter mais informações, consulte Obter alta disponibilidade com o Azure Cosmos DB.
• Se você estiver projetando uma solução de várias regiões, replique o banco de dados do Azure Cosmos DB em duas ou mais regiões. Todas as réplicas são legíveis. Usando os SDKs de cliente, especifique o PreferredLocations parâmetro. Esta é uma lista ordenada de regiões do Azure. Todas as leituras serão enviadas para a primeira região disponível na lista. Se a solicitação falhar, o cliente tentará as outras regiões da lista, na ordem. Para obter mais informações, consulte Como configurar a distribuição global no Azure Cosmos DB para NoSQL.

Diagnósticos. Registre todos os erros no lado do cliente.

A gravação de dados falha.

Deteção. Captura System.Net.Http.HttpRequestException ou Microsoft.Azure.Documents.DocumentClientException.

Recuperação:

• O SDK tenta novamente automaticamente as tentativas falhadas. Para definir o número de novas tentativas e o tempo máximo de espera, configure ConnectionPolicy.RetryOptions. As exceções geradas pelo cliente vão além da política de repetição ou não são erros transitórios.
• Se o Azure Cosmos DB limitar o cliente, ele retornará um erro HTTP 429. Verifique o código de estado na DocumentClientException. Se você estiver recebendo o erro 429 de forma consistente, considere aumentar o valor da taxa de transferência da coleção.
• Habilite a redundância de zona ao trabalhar com uma região que ofereça suporte a zonas de disponibilidade. Quando você usa redundância de zona, o Azure Cosmos DB replica de forma síncrona todas as gravações em zonas de disponibilidade. Para obter mais informações, consulte Obter alta disponibilidade com o Azure Cosmos DB.
• Se você estiver projetando uma solução de várias regiões, replique o banco de dados do Azure Cosmos DB em duas ou mais regiões. Se a região primária falhar, outra região será promovida para gravação. Você também pode acionar um failover manualmente. O SDK faz descoberta e roteamento automáticos, para que o código do aplicativo continue a funcionar após um failover. Durante o período de failover (normalmente minutos), as operações de gravação terão maior latência, pois o SDK localiza a nova região de gravação. Para obter mais informações, consulte Como configurar a distribuição global no Azure Cosmos DB para NoSQL.
• Como fallback, persista o documento em uma fila de backup e processe a fila mais tarde.

Diagnósticos. Registre todos os erros no lado do cliente.

Armazenamento de filas

Escrever uma mensagem no armazenamento de filas do Azure falha consistentemente.

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. Use o log do aplicativo.

Cache do Azure para Redis

A leitura do cache falha.

Deteção. Apanhar StackExchange.Redis.RedisConnectionException.

Recuperação:

1. Tente novamente em falhas transitórias. O Cache do Azure para Redis dá suporte à repetição interna. Para obter mais informações, consulte Diretrizes de repetição do Cache do Azure para Redis.
2. Trate falhas não transitórias como uma falha de cache e retorne à fonte de dados original.

Diagnósticos. Use o Cache do Azure para diagnóstico Redis.

A gravação no cache falha.

Deteção. Apanhar StackExchange.Redis.RedisConnectionException.

Recuperação:

1. Tente novamente em falhas transitórias. O Cache do Azure para Redis dá suporte à repetição interna. Para obter mais informações, consulte Diretrizes de repetição do Cache do Azure para Redis.
2. Se o erro não for transitório, ignore-o e permita que outras transações gravem no cache mais tarde.

Diagnósticos. Use o Cache do Azure para diagnóstico Redis.

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 a partir de uma réplica secundária.
  • Para inserções e atualizações, faça failover manualmente para uma réplica secundária. Consulte Iniciar um failover planejado ou não planejado 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. Erros de captura 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 pools de conexões.

Diagnósticos. Logs de aplicativos.

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ê acertar esses erros de forma consistente, considere dimensionar o 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 conexões com falha.
• Habilite a auditoria do Banco de dados SQL e verifique se há logins com falha.

Mensagens do Service Bus

A leitura de uma mensagem de uma fila do Service Bus falha.

Deteção. Capture 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 em falhas transitórias. Consulte Diretrizes de repetição do Service Bus.
2. As mensagens que não podem ser entregues a nenhum destinatário são colocadas em uma fila de mensagens mortas. Use essa fila para ver quais mensagens não puderam ser recebidas. Não há limpeza automática da fila de cartas mortas. As mensagens permanecem lá até que você as recupere explicitamente. Consulte Visão geral das filas de cartas mortas do Service Bus.

A gravação de uma mensagem em uma fila do Service Bus falha.

Deteção. Capture 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 usa back-off exponencial. Após a contagem máxima de tentativas ou o período de tempo limite máximo, o cliente lança uma exceção. Para obter mais informações, consulte Diretrizes de repetição do Service Bus.

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

• Dentro de uma região, a resiliência pode ser melhorada usando filas ou tópicos particionados. Uma fila ou tópico não particionado é atribuído a um armazenamento de mensagens. Se esse armazenamento de mensagens não estiver disponí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 ouve em 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 ouve em 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 MessageId propriedades 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.

• Habilite a deteção de duplicados, criando a fila com RequiresDuplicateDetection set como true. Com essa configuração, o Service Bus exclui automaticamente qualquer mensagem enviada com o mesmo MessageId que uma mensagem anterior. Tenha em atenção o seguinte:

  • 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 PeekLock o modo. 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 mortas do Service Bus.

Diagnósticos. Sempre que o aplicativo mover uma mensagem para a fila de mensagens mortas, escreva um evento nos logs do aplicativo.

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 de disjuntor para evitar armazenamento sobrecarregado.

3. Se N tentativas de repetição falharem, execute um fallback gracioso. 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 estava em um 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 do Azure.
3. Se as tentativas de repetição de N falharem, execute uma ação de fallback para degradar graciosamente. Por exemplo, se uma imagem de produto não puder ser recuperada do armazenamento, mostre uma imagem de espaço reservado genérica.

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 em um conjunto de disponibilidade, atrás de um balanceador 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 de disjuntor .
• Se a VM chamadora exceder seu limite de saída de rede, a fila de saída será preenchida. Se a fila de saída estiver consistentemente cheia, considere a expansão.

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

A instância da VM torna-se indisponível ou não íntegra.

Deteção. Configure uma sonda de integridade do Balanceador de Carga que sinalize se a instância da VM está íntegra. 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 Load Balancer interromperá o envio de novas conexões para a instância não íntegra.

Diagnósticos. - Use a análise de log do Load Balancer.

• Configure seu sistema de monitoramento para monitorar todos os pontos de extremidade de monitoramento de integridade.

O operador desliga acidentalmente uma VM.

Deteção. N/A

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

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

WebJobs

O trabalho contínuo para de ser executado quando o host SCM está ocioso.

Deteção. Passe um token de cancelamento para a função WebJob. Para obter mais informações, consulte Desligamento normal.

Recuperação. Habilite a Always On configuração no aplicativo Web. Para obter mais informações, consulte Executar tarefas em segundo plano com WebJobs.

Design da aplicação

O aplicativo não pode lidar com um pico de solicitações de entrada.

Deteção. Depende da aplicação. Sintomas típicos:

• O site começa a retornar códigos de erro HTTP 5xx.
• Serviços dependentes, como banco de dados ou armazenamento, começam a limitar as solicitações. Procure erros HTTP como HTTP 429 (Too Many Requests), dependendo do serviço.
• O comprimento da fila HTTP aumenta.

Recuperação:

• Dimensione para lidar com o aumento da carga.

• Reduza as falhas para evitar que falhas em cascata interrompam todo o aplicativo. As estratégias de mitigação incluem:

  • Implemente o padrão de limitação para evitar sobrecarregar os sistemas de back-end.
  • Use o nivelamento de carga baseado em fila para armazenar solicitações em buffer e processá-las em um ritmo apropriado.
  • Priorize determinados clientes. Por exemplo, se o aplicativo tiver níveis gratuitos e pagos, acelere os clientes no nível gratuito, mas não os clientes pagos. Consulte Padrão de fila de prioridade.

Diagnósticos. Use o log de diagnóstico do Serviço de Aplicativo. Use um serviço como o Azure Log Analytics, o Application Insights ou o New Relic para ajudar a entender os logs de diagnóstico.

Uma amostra está disponível aqui. Ele usa Polly para estas exceções:

• 429 - Limitação
• 408 - Tempo limite
• 401 – Não Autorizado
• 503 ou 5xx - Serviço indisponível

Uma das operações em um fluxo de trabalho ou transação distribuída falha.

Deteção. Depois de N tentar novamente, ele ainda falha.

Recuperação:

• Como um plano de mitigação, implemente o padrão Scheduler Agent Supervisor para gerenciar todo o fluxo de trabalho.
• Não tente novamente em tempos limites. Existe uma baixa taxa de sucesso para este erro.
• Trabalho em fila, para tentar novamente mais tarde.

Diagnósticos. Registre todas as operações (bem-sucedidas e falhadas), incluindo ações de compensação. Use IDs de correlação, para que você possa controlar todas as operações dentro da mesma transação.

Uma chamada para um serviço remoto falha.

Deteção. Código de erro HTTP.

Recuperação:

1. Tente novamente em falhas transitórias.
2. Se a chamada falhar após N tentativas, execute uma ação de fallback. (Aplicação específica.)
3. Implemente o padrão de disjuntor para evitar falhas em cascata.

Diagnósticos. Registre todas as falhas de chamada remota.

Próximos passos

Consulte Resiliência e 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.