Partilhar via

Recomendações para o processamento de falhas transitórias

  • Artigo

Aplica-se a esta Power Platform recomendação de lista de verificação de fiabilidade bem arquitetada:

RE:05 Fortaleça a resiliência da sua carga de trabalho implementando o processamento de erros e o processamento de falhas transitórias. Crie capacidades na solução para processar falhas de componentes e erros transitórios.

Este guia descreve as recomendações para processar falhas transitórias nas suas aplicações de cloud. Todas as aplicações que comunicam com serviços e recursos remotos devem ser sensíveis a falhas transitórias. Isto é especialmente verdadeiro para aplicações que são executados na cloud, onde, devido à natureza do ambiente e conectividade pela Internet, este tipo de falha provavelmente será encontrado com mais frequência. As falhas transitórias incluem a perda momentânea de conectividade de rede para componentes e serviços, a indisponibilidade temporária de um serviço e tempos limite que ocorrem quando um serviço está ocupado. Estas falhas são muitas vezes autocorretivas, pelo que, se a ação for repetida após um atraso adequado, é provável que tenha êxito.

Principais estratégias de design

As falhas transitórias podem ocorrer em qualquer ambiente, em qualquer plataforma ou sistema operativo e em qualquer tipo de aplicação.

Desafios

Falhas transitórias podem ter um efeito significativo na disponibilidade percebida de uma aplicação, mesmo tenha sido exaustivamente testada em todas as circunstâncias previsíveis. Para garantir que a sua carga de trabalho do Power Platform pode operar de forma fiável, precisa de garantir que pode responder aos seguintes desafios:

  • A aplicação deve ser capaz de detetar falhas quando estas ocorrem e determinar se as falhas provavelmente serão transitórias, duradouras ou terminais. É provável que diferentes recursos devolvam respostas diferentes quando ocorre uma falha, e estas respostas também podem variar dependendo do contexto da operação. Por exemplo, a resposta a um erro quando a aplicação está a obter dados a partir de um conector personalizado pode ser diferente da resposta quando a aplicação está a executar um fluxo de cloud e a aguardar a resposta.

  • A aplicação tem de ser capaz de repetir a operação se determinar que a falha provavelmente será transitória.

  • A aplicação tem de utilizar uma estratégia apropriada para repetições. A estratégia especifica o número de vezes que a aplicação deve tentar novamente, o atraso entre cada tentativa e as ações a tomar após uma tentativa falhada. O número adequado de tentativas e o atraso entre cada uma delas são muitas vezes difíceis de determinar. A estratégia varia consoante o tipo de recurso e as condições de funcionamento atuais do recurso e da aplicação.

Diretrizes gerais

As diretrizes a seguir podem ajudá-lo a estruturar mecanismos de processamento de falhas transitórias adequados para as suas aplicações.

Determinar se existe um mecanismo de repetição incorporado

Alguns serviços aos quais está a ligar podem já fornecer um mecanismo transitório de processamento de falhas. A política de repetição que utiliza está normalmente adaptada à natureza e aos requisitos do serviço alvo. Como alternativa, as interfaces REST para serviços podem devolver informações que o podem ajudar a determinar se uma nova tentativa é apropriada e quanto tempo esperar antes da próxima tentativa de repetição.

Deve utilizar o mecanismo de repetição incorporado quando um estiver disponível, a menos que tenha requisitos específicos e bem compreendidos que tornem mais apropriado um comportamento de repetição diferente.

Determinar se a operação é adequada para uma repetição

Efetue operações de repetição apenas quando as falhas são transitórias (normalmente indicadas pela natureza do erro) e quando existe, pelo menos, alguma probabilidade de a operação ter êxito quando repetida. Não vale a pena repetir operações que tentam uma operação inválida, como atualizar uma linha no Microsoft Dataverse que não existe ou para a qual o utilizador não tem permissão, ou chamar um ponto final de API que não existe.

Implemente repetições apenas quando puder determinar o efeito completo da sua execução e quando as condições forem bem compreendidas e puderem ser validadas. Lembre-se de que os erros devolvidos por recursos e serviços fora do seu controlo podem evoluir ao longo do tempo e poderá ter de rever a lógica de deteção de falhas transitórias.

Quando desenvolver os componentes ou serviços individuais que são chamados a partir das suas aplicações, certifique-se de que devolve códigos de erro e mensagens que ajudam os clientes a determinar se devem repetir operações falhadas. Considere indicar se o cliente deve repetir a operação; por exemplo, devolvendo um valor isTransient . Se criar um serviço Web, considere devolver os erros personalizados que estão definidos nos contratos de serviço.

Determinar uma contagem de repetições e um intervalo adequados

Otimize a contagem de repetições e o intervalo para o tipo de caso de utilização. Se não repetir vezes suficientes, a aplicação não consegue concluir a operação e provavelmente irá falhar. Se repetir demasiadas vezes, ou com um intervalo demasiado curto entre tentativas, a aplicação poderá reter recursos por longos períodos, o que afeta negativamente o estado de funcionamento da aplicação.

Adapte os valores para o intervalo de tempo e o número de tentativas de repetição ao tipo de operação. Por exemplo, se a operação fizer parte de uma interação do utilizador, o intervalo deve ser curto e apenas algumas repetições devem ser tentadas. Ao utilizar esta abordagem, pode evitar que os utilizadores aguardem por uma resposta. Se a operação fizer parte de um fluxo de trabalho crítico ou de execução longa, em que cancelar e reiniciar o processo é dispendioso ou demorado, é adequado aguardar mais tempo entre tentativas e repetir mais vezes.

Tenha em mente que determinar os intervalos apropriados entre repetições é a parte mais difícil de estruturar uma estratégia bem-sucedida. As estratégias típicas utilizam os seguintes tipos de intervalo de repetição:

  • Intervalo exponencial. A aplicação aguarda um curto período de tempo antes da primeira repetição e, em seguida, aumenta exponencialmente o tempo entre cada repetição subsequente. Por exemplo, pode repetir a operação após 3 segundos, 12 segundos, 30 segundos e assim sucessivamente.

  • Intervalos fixos. A aplicação aguarda o mesmo período de tempo entre cada tentativa.

  • Repetição imediata. Às vezes, uma falha transitória é breve e a repetição imediata da operação é apropriada porque pode ter sucesso se a falha for removida durante o período que a aplicação leva a enviar o próximo pedido. No entanto, nunca deve haver mais do que uma tentativa de repetição imediata. Deve mudar para estratégias alternativas, como o intervalo exponencial ou ações de contingência, se a repetição imediata falhar.

Como orientação geral, utilize uma estratégia de intervalo exponencial para operações em segundo plano e utilize estratégias de repetição de intervalo fixo ou imediato para as operações interativas. Em ambos os casos, deve escolher o atraso e a contagem de repetições, para que a latência máxima para todas as tentativas de repetição esteja dentro do requisito de latência de ponto a ponto necessário.

Considere a combinação de todos os fatores que contribuem para o tempo limite máximo global de uma operação repetida. Estes fatores incluem o tempo que uma ligação falhada demora a produzir uma resposta, o atraso entre tentativas de repetição e o número máximo de tentativas. O total de todos estes tempos pode resultar em longos períodos de operação no geral, especialmente quando utiliza uma estratégia de atraso exponencial em que o intervalo entre repetições aumenta rapidamente após cada falha. Se um processo tiver de cumprir um contrato de nível de serviço (SLA) específico, o tempo global de operação, incluindo todos os tempos limite e atrasos, tem de estar dentro dos limites definidos no SLA.

Não implemente estratégias de repetição excessivamente agressivas. Estas são estratégias que têm intervalos demasiado curtos ou repetições muito frequentes. Podem ter um efeito adverso no recurso ou serviço de destino. Estas estratégias poderão impedir que o recurso ou serviço recupere do seu estado sobrecarregado e continuará a bloquear ou recusar pedidos. Este cenário dá origem a um ciclo vicioso em que são enviados cada vez mais pedidos para o recurso ou serviço. Consequentemente, a sua capacidade de recuperação é ainda mais reduzida.

Considere o tempo limite das operações quando escolhe intervalos de repetição para evitar iniciar imediatamente uma tentativa subsequente (por exemplo, se o período de tempo limite for semelhante ao intervalo de repetição).

Utilize o tipo de erro ou os códigos de erro e mensagens devolvidos do serviço para otimizar o número de repetições e o intervalo entre as mesmas. Por exemplo, algumas exceções ou códigos de erro (como o código HTTP 503, Serviço Indisponível, com um cabeçalho Repetir Após na resposta) podem indicar quanto tempo o erro pode durar ou que o serviço falhou e não responderá a nenhuma tentativa subsequente.

Evitar antipadrões

Na maioria dos casos, evite implementações que incluam camadas duplicadas de código de repetição. Evite designs que incluam mecanismos de repetição em cascata ou que implementem novas tentativas em cada fase de uma operação que envolva uma hierarquia de pedidos, a menos que tenha requisitos específicos para o fazer. Nestas circunstâncias excecionais, utilize políticas que impeçam um número excessivo de repetições e períodos de atraso, e certifique-se de que compreende as consequências. Por exemplo, digamos que um componente faz um pedido a outro, que então acede ao serviço de destino. Se implementar repetições com uma contagem de três em ambas as chamadas, existem nove tentativas de repetição no total contra o serviço. Muitos serviços e recursos implementam um mecanismo de repetição incorporado. Deverá investigar como pode desativar ou modificar estes mecanismos se precisar de implementar repetições a um nível superior.

Nunca implemente um mecanismo de repetição interminável. É provável que isso impeça que o recurso ou serviço se recupere de situações de sobrecarga e faça com que a limitação e as ligações recusadas continuem por mais tempo.

Nunca efetue uma nova repetição imediata mais do que uma vez.

Evite utilizar um intervalo de repetição fixo quando aceder a serviços e recursos no Azure, especialmente quando tiver um elevado número de tentativas de repetição. A melhor abordagem neste cenário é uma estratégia de intervalo exponencial.

Testar a sua estratégia de repetição e a implementação

Teste completamente a sua estratégia de repetição num conjunto de circunstâncias o mais amplo possível, especialmente quando a aplicação e os recursos ou serviços de destino que utiliza estiverem sob carga extrema. Para verificar o comportamento durante o teste, pode:

  • injetar falhas transitórias e não transitórias no serviço. Por exemplo, enviar pedidos inválidos ou adicionar código que deteta pedidos de teste e responde com diferentes tipos de erros.

  • Crie um modelo do recurso ou serviço que devolve uma gama de erros que o serviço real pode devolver. Cubra todos os tipos de erros que a sua estratégia de repetição foi concebida para detetar.

  • Para serviços personalizados que crie e implemente, force a ocorrência de erros transitórios desativando ou sobrecarregando temporariamente o serviço. (Não tente sobrecarregar os recursos ou serviços partilhados no Azure.)

  • Ao testar a resiliência de uma aplicação Web cliente a falhas transitórias, utilize as ferramentas de programação do navegador ou a capacidade da estrutura de teste para simular ou bloquear pedidos de rede.

  • Execute testes simultâneos e de fator de carga elevado para assegurar que o mecanismo de repetição e a estratégia funcionam corretamente nestas condições. Estes testes também ajudam a assegurar que a repetição não tem um efeito adverso no funcionamento do cliente ou causa contaminação cruzada entre os pedidos.

Gerir configurações de política de repetição

Uma política de repetição é uma combinação de todos os elementos da sua estratégia de repetição. Define o mecanismo de deteção que determina se uma falha é provável que seja transitória, o tipo de intervalo a ser usado (como fixo ou exponencial), os valores reais do intervalo e o número de vezes a repetir.

Tire partido das estratégias de repetição incorporadas ou predefinidas, mas apenas quando forem adequadas ao seu cenário. Estas estratégias são tipicamente genéricas. Em alguns cenários, podem ser tudo o que precisa, mas noutros cenários não oferecem a gama completa de opções para se adequarem aos seus requisitos específicos. Para determinar os valores mais apropriados, precisa de executar testes para entender como as definições afetam a sua aplicação.

Registar e monitorizar falhas transitórias e não transitórias

Como parte da sua estratégia de repetição, inclua o processamento de exceções e outros instrumentos que registam tentativas de repetição. Uma falha e uma repetição transitórias ocasionais são esperadas e não indicam um problema. No entanto, um número regular e crescente de repetições geralmente é um indicador de um problema que pode causar uma falha ou que degrada o desempenho e a disponibilidade da aplicação.

Registe falhas transitórias como entradas de aviso, em vez de entradas de erro, para que os sistemas de monitorização não as detetem como erros de aplicação que podem acionar falsos alertas.

Considere armazenar um valor nas entradas de registo que indica se as repetições são causadas por uma limitação no serviço ou por outros tipos de falha, como falhas de ligação, para que possa distingui-las durante a análise dos dados. Um aumento no número de erros de limitação é muitas vezes um indicador de uma falha de design na aplicação ou da necessidade de adicionar capacidade premium ao ambiente.

Considere implementar um sistema de telemetria e monitorização que possa gerar alertas quando o número e a taxa de falhas, o número médio de repetições ou os tempos globais decorridos antes do sucesso das operações estiverem a aumentar.

Gerir operações que falham continuamente

Considere como processar operações que continuam a falhar em cada tentativa. Situações como esta são inevitáveis.

Embora uma estratégia de repetição defina o número máximo de vezes que uma operação deve ser repetida, isso não impede que a aplicação repita a operação com o mesmo número de repetições. Por exemplo, submeter um formulário na sua aplicação pode acionar um fluxo. A estratégia de repetição poderá detetar um tempo limite de ligação e considerá-lo uma falha transitória. O fluxo tentará novamente a operação um número especificado de vezes e, em seguida, desistirá. No entanto, quando o mesmo ou um novo utilizador tentar submeter o formulário novamente, a operação é tentada novamente, mesmo que possa continuar a falhar.

A aplicação pode testar periodicamente o serviço, de forma intermitente e com longos intervalos entre os pedidos, para detetar quando este fica disponível. Um intervalo adequado depende de fatores como a criticidade da operação e a natureza do serviço. Pode ser durar entre alguns minutos a várias horas. Quando o teste for bem-sucedido, a aplicação poderá retomar as operações normais e passar pedidos para o serviço recentemente recuperado.

Entretanto, pode conseguir executar algumas operações alternativas com base na esperança de que o serviço estará disponível em breve. Por exemplo, poderá ser apropriado armazenar pedidos para o serviço numa fila ou num arquivo de dados e repeti-los mais tarde. Ou poderá ter de devolver uma mensagem ao utilizador a indicar que a aplicação não está disponível.

Outras considerações

Quando estiver a decidir os valores para o número de repetições e os intervalos de repetição para uma política, considere se a operação no serviço ou recurso faz parte de uma operação de execução prolongada ou com vários passos. Pode ser difícil ou dispendioso compensar todas as outras etapas operacionais que já tiveram êxito quando uma falha. Neste caso, um intervalo longo e um grande número de repetições podem ser aceitáveis, desde que esta estratégia não bloqueie outras operações mantendo ou bloqueando recursos escassos.

Considere se a repetição da mesma operação pode causar inconsistências nos dados. Se algumas partes de um processo com vários passos forem repetidas e as operações não forem idempotentes, poderão ocorrer inconsistências. Por exemplo, se uma operação que insere um registo no Microsoft Dataverse for repetida, poderá causar valores incorretos na tabela. Ou, se repetir uma operação que envia uma notificação ao utilizador, este poderá receber mensagens duplicadas.

Considere o âmbito das operações que são repetidas. Por exemplo, poderá ser mais fácil implementar código de repetição a um nível que englobe várias operações e repetir todas se uma falhar. No entanto, isso pode resultar em problemas de idempotência ou operações de reversão desnecessárias.

Se escolher um âmbito de repetição que englobe várias operações, considere a latência total de todas quando determinar intervalos de repetição, quando monitorizar os tempos decorridos da operação e antes de gerar os alertas para falhas.

Facilitação do Power Platform

As secções seguintes descrevem os mecanismos que pode utilizar para gerir falhas transitórias.

Power Automate

O Power Automate inclui uma funcionalidade para repetir uma ação se falhar. Configure isto num nível por ação. Saiba mais sobre como reduzir o risco e planejar o tratamento de erros em um Power Automate projeto. O Power Automate também oferece ações para devolver erros e dados personalizados à aplicação ou fluxo de chamadas.

Alguns fluxos transitórios podem ser causados por limites de débito e pedidos. Saiba mais sobre os limites de fluxos automatizados, agendados e instantâneos e sobre os limites e alocações de pedidos.

Configure o tratamento de erros e exceções em fluxos de nuvem usando escopos e configurações de execução.

Power Apps

As aplicações de tela do Power Apps fornecem a capacidade de verificar o estado da ligação, permitindo-lhes comportarem-se de forma diferente se a aplicação estiver offline. Saiba como desenvolver aplicativos de tela com capacidade offline.

Também pode utilizar as funções Error, IfError, IsError e IsBlankOrError nas aplicações de tela para decidir o que fazer a seguir se ocorrer um erro.

Saiba mais sobre o processamento de falhas transitórias no Power Apps:

O Azure e conectores personalizados

Se a sua carga de trabalho se ligar aos serviços do Azure, saiba como processar falhas transitórias utilizando o Azure Well-Architected Framework.

Para gerir as respostas dos conectores personalizados a erros, siga as normas de codificação.

Application Insights

Utilize as integrações do Application Insights para registar erros no Power Automate e Power Apps:

Continuidade de negócios e recuperação de desastres para aplicativos SaaS Dynamics 365

Lista de verificação de fiabilidade

Consulte o conjunto completo de recomendações.

Lista de verificação de fiabilidade