Recomendações para resolver falhas transitórias

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

Este guia descreve as recomendações para resolver falhas transitórias nos aplicativos de nuvem. Todos os aplicativos que se comunicam com serviços e recursos remotos devem ser sensíveis a falhas transitórias. Isso é especialmente verdadeiro para aplicativos executados na nuvem, em que, por causa da natureza do ambiente e da conectividade pela internet, esse tipo de falha provavelmente será encontrado com mais frequência. Entre as falhas transitórias estão a perda momentânea da conectividade da rede com componentes e serviços, a indisponibilidade temporária de um serviço e os tempos limite ocorridos quando um serviço está ocupado. Como essas falhas normalmente são autocorretivas, se a ação for repetida depois de um atraso indicado, ela será provavelmente bem-sucedida.

Estratégias-chave de design

As falhas transitórias podem ocorrer em qualquer ambiente, em qualquer plataforma ou sistema operacional e em qualquer tipo de aplicativo.

Desafios

As falhas transitórias podem ter um efeito significativo sobre a disponibilidade percebida de um aplicativo, mesmo que ele tenha sido muito testado em todas as circunstâncias previsíveis. Para garantir que a carga de trabalho do Power Platform possa operar de maneira confiável, você precisa garantir que ela possa responder aos seguintes desafios:

• O aplicativo deve ser capaz de detectar falhas quando elas ocorrem e determinar se elas provavelmente são transitórias, se são de longa duração ou se são falhas terminais. É provável que recursos diferentes retornem respostas diferentes quando uma falha ocorre, e essas respostas também podem variar de acordo com o contexto da operação. Por exemplo, a resposta para um erro quando o aplicativo está recuperando dados de um conector personalizado pode ser diferente da resposta quando o aplicativo está executando um fluxo da nuvem e aguardando a resposta.

• O aplicativo deverá ser capaz de repetir a operação se determinar que a falha provavelmente é transitória.

• O aplicativo deve usar uma estratégia indicada para repetições. A estratégia especifica o número de vezes em que o aplicativo deve repetir, o atraso entre cada tentativa e as ações a serem tomadas depois de uma tentativa com falha. O número indicado de tentativas e o intervalo entre cada uma muitas vezes são difíceis de determinar. A estratégia varia de acordo com o tipo de recurso e as condições operacionais atuais do recurso e do aplicativo.

Diretrizes gerais

As diretrizes a seguir podem ajudar você a projetar mecanismos do tratamento de falhas transitórias indicados para os aplicativos.

Determinar se há um mecanismo de repetição interno

Alguns serviços aos quais você está se conectando já podem oferecer um mecanismo para tratamento de falhas transitórias. A política de repetição usada por ele normalmente é personalizada para a natureza e os requisitos do serviço de destino. Como alternativa, interfaces REST para serviços podem retornar informações capazes de ajudar você a determinar se uma repetição é indicada e quanto tempo esperar até a próxima tentativa de repetição.

Você deve usar o mecanismo de repetição interno quando houver um disponível, a menos que tenha requisitos específicos e bem compreendidos que tornem um comportamento de repetição diferente mais indicado.

Determine se a operação é indicada para a repetição

Só realize operações de repetição quando as falhas forem transitórias (normalmente indicado pela natureza do erro) e quando houver pelo menos alguma probabilidade de que a operação será bem-sucedida quando repetida. Não adianta repetir operações que tentem uma operação inválida, como a atualização de uma linha no Microsoft Dataverse não existente ou para a qual o usuário não tem permissão ou chamar um ponto de extremidade de API que não existe.

Só implemente novas tentativas quando você puder determinar o efeito total de fazer isso e quando as condições forem bem compreendidas e puderem ser validadas. Lembre-se de que os erros retornados de recursos e serviços fora do controle podem evoluir com o tempo e talvez seja necessário revisitar a lógica de detecção de falhas transitórias.

Ao desenvolver componentes ou serviços individuais chamados pelos aplicativos, não se esqueça de retornar códigos de erro e mensagens que ajudem os clientes a determinar se eles devem repetir as operações com falha. Leve em consideração indicar se o cliente deve repetir a operação; por exemplo, retornando um valor isTransient. Se você criar um serviço Web, leve em consideração retornar erros personalizados definidos dentro dos contratos de serviço.

Determine uma contagem e um intervalo de repetições indicados

Otimize a contagem de repetições e o intervalo para o tipo de caso de uso. Se você não repetir vezes o suficiente, o aplicativo não conseguirá concluir a operação e provavelmente vai falhar. Se você repetir muitas vezes ou com um intervalo muito curto entre as tentativas, o aplicativo poderá reter recursos por períodos longos, o que afeta negativamente a integridade do aplicativo.

Adapte os valores do intervalo de tempo e do 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 usuário, o intervalo deverá ser curto e só algumas tentativas deverão ser tentadas. Ao usar essa abordagem, você pode evitar fazer com que os usuários aguardem uma resposta. Se a operação fizer parte de um fluxo de trabalho crítico ou de execução prolongada, em que o cancelamento e a reinicialização do processo sejam caros ou demorados, convém aguardar mais tempo entre as tentativas e repetir mais vezes.

Lembre-se de que determinar os intervalos indicados entre as repetições é a parte mais difícil de projetar uma estratégia bem-sucedida. As estratégias típicas usam os seguintes tipos de intervalo de repetição:

• Intervalo exponencial. O aplicativo aguarda um pouco antes da primeira tentativa e, em seguida, aumenta exponencialmente o tempo entre cada tentativa subsequente. Por exemplo, ele pode repetir a operação após 3 segundos, 12 segundos, 30 segundos e assim por diante.

• Intervalos fixos. O aplicativo aguarda o mesmo período entre cada tentativa.

• Nova tentativa imediata. Às vezes, uma falha transitória é breve, e a repetição imediata da operação é indicada, pois poderá ser bem-sucedida se a falha for eliminada no tempo que o aplicativo leva para enviar a próxima solicitação. No entanto, jamais deve haver mais de uma tentativa de repetição imediata. Você deverá recorrer a estratégias alternativas, como intervalo exponencial ou ações de fallback, se a repetição imediata falhar.

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

Leve em consideração a combinação de todos os fatores que contribuem para o tempo limite máximo geral de uma operação repetida. Entre esses fatores estão o tempo necessário para uma conexão com falha produzir uma resposta, o atraso entre as tentativas de repetição e o número máximo de repetições. O total de todos esses tempos pode acarretar tempos de operação longos no geral, especialmente quando você usa uma estratégia de atraso exponencial em que o intervalo entre as repetições aumenta rapidamente após cada falha. Se um processo precisar atender a um contrato de nível de serviço (SLA) específico, o tempo total de operação, inclusive todos os tempos limite e atrasos, deverá estar dentro dos limites definidos no SLA.

Não implemente estratégias de repetição excessivamente agressivas. Essas são estratégias com intervalos muito curtos ou repetições muito frequentes. Elas podem ter um efeito adverso sobre o recurso ou o serviço de destino. Essas estratégias podem impedir que o recurso ou o serviço se recupere do estado sobrecarregado e vai continuar bloqueando ou recusando solicitações. Esse cenário acarreta um círculo vicioso, em que mais e mais solicitações são enviadas para o recurso ou o serviço. Consequentemente, a capacidade de recuperação é ainda mais reduzida.

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

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

Evitar antipadrões

Na maioria dos casos, evite implementações que incluam camadas duplicadas do código de repetição. Evite designs que incluam mecanismos de repetição em cascata ou que implementem uma repetição em cada estágio de uma operação que envolva uma hierarquia de solicitações, a menos que você tenha requisitos específicos para isso. Nessas circunstâncias excepcionais, use políticas que evitem um número excessivo de repetições e períodos de atraso e certifique-se de que você tenha compreendido as consequências. Por exemplo, digamos que um componente faça uma solicitação para outro, que acabe acessando o serviço de destino. Se você implementar a repetição com uma contagem de três em ambas as chamadas, haverá nove tentativas de repetição no total no serviço. Muitos serviços e recursos implementam um mecanismo de repetição interno. Você deverá investigar como pode desabilitar ou modificar esses mecanismos se precisar implementar novas tentativas em um nível superior.

Jamais implemente um mecanismo de repetição sem fim. É provável que fazer isso impeça o recurso ou o serviço de se recuperar de situações de sobrecarga e cause limitação e conexões recusadas para continuar por mais tempo.

Jamais realize uma repetição imediata mais de uma vez.

Evite usar um intervalo de repetição fixo ao acessar serviços e recursos no Azure, especialmente quando você tiver um grande número de tentativas de repetição. A melhor abordagem nesse cenário é uma estratégia de intervalo exponencial.

Teste a estratégia e a implementação da repetição

Teste totalmente a estratégia de repetição em um conjunto de circunstâncias o mais amplo possível, especialmente quando o aplicativo e os recursos ou os serviços de destino usados por ele estiverem sob carga extrema. Para verificar o comportamento durante o teste, você pode:

• Injetar falhas transitórias e não transitórias no serviço. Por exemplo, envie solicitações inválidas ou adicione um código que detecte solicitações de teste e responda com diferentes tipos de erros.

• Crie um modelo do recurso ou do serviço que retorne uma série de erros que o serviço real pode retornar. Abranja todos os tipos de erros que a estratégia de repetição foi projetada para detectar.

• Para serviços personalizados criados e implantados por você, force a ocorrência de erros temporários desabilitando ou sobrecarregando temporariamente o serviço. (Não tente sobrecarregar nenhum recurso ou serviço compartilhado no Azure.)

• Ao testar a resiliência de um aplicativo Web cliente a falhas transitórias, use as ferramentas de desenvolvedor do navegador ou a capacidade da estrutura de teste de simular ou bloquear solicitações de rede.

• Realize testes de alto fator de carga e testes simultâneos para garantir que o mecanismo de repetição e a estratégia funcionem corretamente nessas condições. Esses testes também ajudam a garantir que a repetição não tenha um efeito adverso sobre a operação do cliente ou cause contaminação cruzada entre as solicitações.

Gerenciar configurações da política de repetição

Uma política de repetição é uma combinação de todos os elementos da estratégia de repetição. Ela define o mecanismo de detecção que determina se uma falha provavelmente é transitória, o tipo de intervalo a ser usado (como fixo ou exponencial), os valores de intervalo reais e o número de vezes que deve ser repetida.

Usufrua as estratégias de repetição internas ou padrão, mas só quando elas forem indicadas para o cenário. Essas estratégias costumam ser genéricas. Em alguns cenários, elas podem ser tudo aquilo de que você precisa, mas, em outros, não oferecem a linha completa de opções para atender às necessidades específicas. Para determinar os valores mais indicados, você precisa realizar testes para compreender como as configurações afetam o aplicativo.

Registrar e acompanhar falhas transitórias e não transitórias

Como parte da estratégia de repetição, inclua o tratamento de exceções e outra instrumentação que registre tentativas de repetição. Uma falha transitória ocasional e uma repetição são esperadas e não indicam um problema. No entanto, o número regular e crescente de tentativas costuma ser um indicador de um problema que pode causar uma falha ou que degrada o desempenho e a disponibilidade do aplicativo.

Registre falhas transitórias como entradas de aviso, em vez de entradas de erro, de maneira que os sistemas de monitoramento não as detectem como erros de aplicativo capazes de disparar alertas falsos.

Leve em consideração o armazenamento de um valor nas entradas de log que indique se as repetições são causadas por limitação no serviço ou por outros tipos de falhas, como falhas de conexão, de maneira que você possa diferenciá-las durante a análise dos dados. Um aumento no número de erros na limitação costuma ser um indicador de uma falha no design no aplicativo ou da necessidade de adicionar capacidade premium ao ambiente.

Leve em consideração a implementação de um sistema de telemetria e monitoramento capaz de gerar alertas quando o número e a taxa de falhas, o número médio de tentativas ou os tempos gerais decorridos antes das operações bem-sucedidas estiverem aumentando.

Gerenciar operações que falham continuamente

Leve em consideração como lidar com operações que continuem falhando a cada tentativa. Situações assim são inevitáveis.

Embora uma estratégia de repetição defina o número máximo de vezes em que uma operação deve ser repetida, ela não impede que o aplicativo repita a operação com o mesmo número de tentativas. Por exemplo, o envio de um formulário no aplicativo pode disparar um fluxo. A estratégia de repetição pode detectar um tempo limite de conexão e considerá-lo uma falha transitória. O fluxo vai repetir a operação um número especificado de vezes e depois desistir. No entanto, quando o mesmo usuário ou um novo usuário tenta reenviar o formulário, a operação é repetida, mesmo que possa continuar falhando.

O aplicativo pode testar periodicamente o serviço, de maneira intermitente e com intervalos longos entre as solicitações, para detectar quando ele fica disponível. Um intervalo indicado depende de fatores como a gravidade da operação e a natureza do serviço. Pode ser qualquer coisa entre alguns minutos e diversas horas. Quando o teste é bem-sucedido, o aplicativo pode retomar as operações normais e transmitir solicitações para o serviço recém-recuperado.

Enquanto isso, é possível que você consiga realizar algumas operações alternativas com base na esperança de que o serviço esteja disponível em breve. Por exemplo, pode ser indicado armazenar solicitações do serviço em uma fila ou armazenamento de dados e repeti-las depois. Ou talvez você precise retornar uma mensagem ao usuário para indicar que o aplicativo não está disponível.

Outras considerações

Ao decidir sobre os valores do número de repetições e dos intervalos de repetição de uma política, leve em consideração se a operação no serviço ou no recurso faz parte de uma operação de execução prolongada ou multietapa. Pode ser difícil ou caro compensar todas as outras etapas operacionais que já tenham sido bem-sucedidas quando uma falha. Nesse caso, um intervalo longo e um grande número de repetições podem ser aceitáveis, desde que essa estratégia não bloqueie outras operações mantendo ou bloqueando recursos escassos.

Leve em consideração se a repetição da mesma operação pode causar inconsistências nos dados. Se algumas partes de um processo multietapa forem repetidas e as operações não forem idempotentes, poderão ocorrer inconsistências. Por exemplo, se uma operação que insere um registro no Microsoft Dataverse for repetida, isso poderá causar valores incorretos na tabela. Ou, se você repetir uma operação que envia uma notificação ao usuário, ele poderá receber mensagens duplicadas.

Leve em consideração o escopo de operações repetidas. Por exemplo, pode ser mais fácil implementar o código de repetição em um nível que abranja diversas operações e repetir todas se houver falha. No entanto, isso pode acarretar problemas de idempotência ou operações de reversão desnecessárias.

Se você escolher um escopo de repetição que abranja diversas operações, leve em consideração a latência total de todas elas ao determinar intervalos de repetição, ao monitorar os tempos decorridos da operação e antes de gerar alertas para falhas.

Facilitação do Power Platform

As seções a seguir descrevem os mecanismos que você pode usar para gerenciar falhas transitórias.

Power Automate

O Power Automate inclui um recurso para repetir uma ação se ela falhar. Configure isso em um nível por ação. Aprenda sobre como reduzir riscos e planejar o tratamento de erros em um Power Automate projeto. O Power Automate também oferece ações a fim de retornar erros e dados personalizados para o aplicativo ou o fluxo de chamada.

Alguns fluxos transitórios podem ser causados por limites da taxa de transferência e da solicitação. Saiba mais sobre os limites de fluxos automatizados, programados e instantâneos, além de limites e alocações de solicitação.

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

Power Apps

Os aplicativos de tela do Power Apps oferecem a capacidade de verificar o status da conexão, permitindo que eles se comportem de maneira diferente caso o aplicativo esteja offline. Aprenda a desenvolver aplicativos Canvas compatíveis com o modo offline.

Você também pode usar as funções Error, IfError, IsError e IsBlankOrError em aplicativos de tela para decidir o que fazer em seguida caso ocorra um erro.

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

• Visão geral do Mobile Offline
• Aplicativos móveis offline para Canvas

Azure e conectores personalizados

Se a carga de trabalho se conectar aos serviços do Azure, aprenda a lidar com falhas transitórias usando o Azure Well-Architected Framework.

Para gerenciar respostas de conector personalizadas para erros, siga os padrões de codificação.

Application Insights

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

• Configurar Application Insights com Power Automate (versão preliminar)
• Analisar logs gerados pelo sistema usando Application Insights em Power Apps

Informações relacionadas

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

Lista de verificação de confiabilidade

Consulte o conjunto completo de recomendações.