Recomendações para resolver falhas transitórias

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.

Este artigo fornece diretrizes gerais para tratamento de falhas transitórias. Para obter informações sobre como implementar novas tentativas no código do aplicativo para lidar com falhas transitórias, consulte o padrão de repetição e, quando estiver usando os serviços do Azure, consulte as diretrizes de repetição para os serviços do Azure.

Falhas transitórias

As falhas transitórias podem ocorrer em qualquer ambiente, em qualquer plataforma ou sistema operacional e em qualquer tipo de aplicativo. Para soluções que são executadas na infraestrutura local local, o desempenho e a disponibilidade do aplicativo e seus componentes normalmente são mantidos por meio de redundância de hardware cara e muitas vezes subutilizada, e componentes e recursos estão localizados próximos uns dos outros. Essa abordagem torna a falha menos provável, mas falhas transitórias ainda podem ocorrer, assim como interrupções causadas por eventos imprevistos, como fonte de energia externa ou problemas de rede, ou por cenários de desastre.

A hospedagem em nuvem, incluindo sistemas de nuvem privada, pode oferecer maior disponibilidade geral usando recursos compartilhados, redundância, recuperação automática de falhas e alocação dinâmica de recursos em muitos nós de computação padrão. No entanto, devido à natureza dos ambientes de nuvem, falhas transitórias são mais propensas a ocorrer. Há vários motivos para isso:

• Muitos recursos em um ambiente de nuvem são compartilhados e o acesso a esses recursos está sujeito à limitação para proteger os recursos. Alguns serviços recusam conexões quando a carga sobe para um nível específico ou quando uma taxa de taxa de transferência máxima é atingida, para permitir o processamento de solicitações existentes e manter o desempenho do serviço para todos os usuários. A limitação ajuda a manter a qualidade de serviço para vizinhos e outros usuários que usam o recurso compartilhado.

• Os ambientes de nuvem usam um grande número de unidades de hardware de commodities. Eles fornecem desempenho distribuindo dinamicamente a carga entre várias unidades de computação e componentes de infraestrutura. Eles fornecem confiabilidade reciclando ou substituindo unidades com falha automaticamente. Devido a essa natureza dinâmica, falhas transitórias e falhas de conexão temporárias podem ocorrer ocasionalmente.

• Geralmente, há mais componentes de hardware, incluindo infraestrutura de rede, como roteadores e balanceadores de carga, entre o aplicativo e os recursos e serviços que ele usa. Essa infraestrutura adicional pode ocasionalmente introduzir latência de conexão adicional e falhas transitórias de conexão.

• As condições de rede entre o cliente e o servidor podem ser variáveis, especialmente quando a comunicação cruza a Internet. Mesmo em locais locais, cargas pesadas de tráfego podem diminuir a comunicação e causar falhas de conexão intermitentes.

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 os aplicativos hospedados na nuvem operem de forma confiável, você precisa garantir que eles possam 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á lendo do armazenamento pode ser diferente da resposta de um erro ao gravar no armazenamento. Muitos recursos e serviços têm contratos de falha transitória bem documentados. No entanto, quando essas informações não estão disponíveis, pode ser difícil descobrir a natureza da falha e se ela provavelmente será transitória.

• O aplicativo deverá ser capaz de repetir a operação se determinar que a falha provavelmente é transitória. Ele também precisa acompanhar o número de vezes que a operação é repetida.

• 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.

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

Implementando novas tentativas

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

• Muitos serviços fornecem um SDK ou uma biblioteca de clientes que contém um mecanismo transitório de tratamento de falhas. 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 tentam uma operação inválida, como uma atualização de banco de dados para um item que não existe ou uma solicitação para um serviço ou recurso que sofreu um erro fatal.

• Em geral, implemente novas tentativas somente quando você puder determinar o efeito total de fazer isso e quando as condições forem bem compreendidas e puderem ser validadas. Caso contrário, permita que o código de chamada implemente novas tentativas. 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 criar serviços ou componentes, considere implementar códigos de erro e mensagens que ajudam os clientes a determinar se eles devem tentar novamente as operações com falha. Em particular, indique se o cliente deve repetir a operação (talvez retornando um valor isTransient ) e sugerir um atraso adequado antes da próxima tentativa de repetição. Se você criar um serviço Web, leve em consideração retornar erros personalizados definidos dentro dos contratos de serviço. Embora os clientes genéricos possam não conseguir ler esses erros, eles são úteis na criação de clientes personalizados.

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 tentativas, o aplicativo poderá conter recursos como threads, conexões e memória por longos períodos, 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. Usando essa abordagem, você pode evitar fazer com que os usuários aguardem por uma resposta, que contém conexões abertas e pode reduzir a disponibilidade para outros usuários. Se a operação faz parte de um fluxo de trabalho longo ou crítico, em que cancelar e reiniciar o processo é caro ou demorado, é apropriado aguardar mais tempo entre tentativas e tentar novamente 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:

  • Retirada 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. Para melhorar ainda mais essa estratégia, você pode adicionar tremulação ao recuo exponencial. O tremulação introduz um atraso aleatório em cada tentativa de repetição, o que ajuda a impedir que vários clientes tentem novamente simultaneamente e causem um pico na carga

  • Intervalos incrementais. O aplicativo aguarda um pouco antes da primeira repetição e, em seguida, aumenta incrementalmente o tempo entre cada repetição subsequente. Por exemplo, ele pode repetir a operação após 3 segundos, 7 segundos, 13 segundos e assim por diante.

  • Intervalos regulares. O aplicativo aguarda o mesmo período entre cada tentativa. Por exemplo, ele pode repetir a operação a cada 3 segundos.

  • Tentativa imediata. Às vezes, uma falha transitória é breve, possivelmente causada por um evento como uma colisão de pacote de rede ou um pico em um componente de hardware. Nesse caso, repetir a operação imediatamente é apropriado porque ela poderá ter êxito se a falha for resolvida no tempo que leva para o aplicativo preparar e enviar a próxima solicitação. No entanto, jamais deve haver mais de uma tentativa de repetição imediata. Você deve alternar para estratégias alternativas, como recuo exponencial ou ações de contingência, se a nova tentativa imediata falhar.

  • Randomização. Qualquer uma das estratégias de repetição listadas anteriormente pode incluir uma randomização para impedir que várias instâncias do cliente enviem tentativas de repetição subsequentes ao mesmo tempo. Por exemplo, uma instância pode repetir a operação após 3 segundos, 11 segundos, 28 segundos e assim por diante, enquanto outra instância pode repetir a operação após 4 segundos, 12 segundos, 26 segundos e assim por diante. A randomização é uma técnica útil que pode ser combinada com outras estratégias.

• Como diretriz geral, use um recuo exponencial com estratégia de tremulação para operações em segundo plano e use estratégias de repetição de intervalo imediatas ou regulares 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 conta a combinação de todos os fatores que contribuem para o tempo limite máximo geral para uma operação repetida. Esses fatores incluem o tempo necessário para uma conexão com falha produzir uma resposta (normalmente definida por um valor de tempo limite no cliente), o atraso entre tentativas de repetição e o número máximo de tentativas. 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 conta 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 de tempo limite for semelhante ao intervalo de repetição). Além disso, considere se você precisa manter o período total possível (o tempo limite mais os intervalos de repetição) abaixo de um tempo total específico. Se uma operação tiver um tempo limite excepcionalmente curto ou longo, o tempo limite poderá influenciar quanto tempo esperar e com que frequência tentar novamente a operação.

• Use o tipo da exceção e todos os dados que ele contém, ou os códigos de erro e mensagens retornados do serviço, para otimizar o número de repetições e o intervalo entre eles. 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.

• Considere usar uma abordagem de fila de mensagens mortas para garantir que todas as informações da invocação de entrada não se percam depois que todas as tentativas de repetição tiverem sido esgotadas.

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 a 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 que exijam 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. Use um número finito de tentativas ou implemente um padrão como o Circuit Breaker para permitir que o serviço se recupere.

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

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

• Impedir que várias instâncias do mesmo cliente ou várias instâncias de clientes diferentes enviem novas tentativas simultaneamente. Se esse cenário provavelmente ocorrer, introduza a randomização nos intervalos de repetição.

Testar estratégias de re-tentativa e implementaçã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:

  • Inclua falhas transitórias em suas práticas de engenharia de caos e injeção de falhas introduzindo-as propositalmente em seus ambientes de produção e não produçã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.)

  • Use bibliotecas ou soluções que interceptam e modificam o tráfego de rede para replicar cenários desfavoráveis de seus testes automatizados. Por exemplo, os testes podem adicionar tempos extras de ida e volta, soltar pacotes, modificar cabeçalhos ou até mesmo alterar o corpo da solicitação em si. Isso permite o teste determinístico de um subconjunto das condições de falha, para falhas transitórias e outros tipos de falhas.

  • 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.

  • Execute testes de alta carga e 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. Ele define o mecanismo de detecção que determina se uma falha provavelmente é transitória, o tipo de intervalo a ser usado (como back-off regular, exponencial e randomização), os valores reais dos intervalos e o número de tentativas de repetição.

• Implemente novas tentativas em muitos lugares, mesmo no aplicativo mais simples e em cada camada de aplicativos mais complexos. Em vez de codificar os elementos de cada política em vários locais, considere usar um ponto central para armazenar todas as políticas. Por exemplo, armazene valores como o intervalo e a contagem de repetições em arquivos de configuração de aplicativo, leia-os em runtime e crie programaticamente as políticas de repetição. Isso facilita o gerenciamento das configurações e a modificação e ajuste dos valores para responder aos requisitos e cenários em mudança. No entanto, projete o sistema para armazenar os valores em vez de reler um arquivo de configuração todas as vezes e use padrões adequados se os valores não puderem ser obtidos da configuração.

• Armazene os valores usados para criar as políticas de repetição em runtime no sistema de configuração do aplicativo para que você possa alterá-los sem precisar reiniciar o aplicativo.

• Aproveite as estratégias de repetição internas ou padrão que estão disponíveis nas APIs do cliente que você usa, mas somente quando elas forem apropriadas para o seu 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 de limitação geralmente é um indicador de uma falha de design no aplicativo ou a necessidade de mudar para um serviço premium que oferece hardware dedicado.

• Considere medir e registrar os tempos totais para operações que incluem um mecanismo de repetição. Essa métrica é um bom indicador do efeito geral de falhas transitórias nos tempos de resposta do usuário, na latência do processo e na eficiência dos casos de uso do aplicativo. Registre também o número de repetições que ocorrem para que você possa entender os fatores que contribuem para o tempo de resposta.

• 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 que uma operação deve ser repetida, ela não impede que o aplicativo repita a operação novamente com o mesmo número de tentativas. Por exemplo, se um serviço de processamento de pedidos falhar com um erro fatal que o coloca fora de ação permanentemente, a estratégia de repetição poderá detectar um tempo limite de conexão e considerá-lo uma falha transitória. O código repete a operação um número especificado de vezes e, em seguida, desiste. No entanto, quando outro cliente faz um pedido, a operação é tentada novamente, mesmo que ela falhe sempre.

  • Para evitar tentativas contínuas de operações que falham continuamente, considere implementar o Circuit Breaker pattern. Quando você usa esse padrão, se o número de falhas dentro de uma janela de tempo especificada excede um limite, as solicitações retornam ao chamador imediatamente como erros e não há nenhuma tentativa de acessar o recurso ou serviço com falha.

  • 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, você pode ser capaz de voltar para outra instância do serviço (talvez em um datacenter ou aplicativo diferente), usar um serviço semelhante que ofereça funcionalidade compatível (talvez mais simples) ou executar algumas operações alternativas com base na esperança de que o serviço estará 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 você pode redirecionar o usuário para uma instância alternativa do aplicativo, degradar o desempenho do aplicativo, mas ainda oferecer funcionalidade aceitável ou apenas retornar uma mensagem ao usuário para indicar que o aplicativo não está disponível no momento.

Otimizar a implementação de re-tentativa

• 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 realizadas com sucesso quando uma delas falha. Nesse caso, um intervalo muito longo e um grande número de tentativas 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 incrementa um valor for repetida, ela produzirá um resultado inválido. Repetir uma operação que envia uma mensagem para uma fila pode causar uma inconsistência no consumidor da mensagem se o consumidor não conseguir detectar mensagens duplicadas. Para evitar esses cenários, projete cada etapa como uma operação idempotente. Para obter mais informações, consulte padrões de idempotência.

• 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 engloba várias operações, leve em conta a latência total de todas elas ao determinar intervalos de repetição, quando monitorar os horários decorridos da operação e antes de gerar alertas para falhas.

• Considere como sua estratégia de repetição pode afetar vizinhos e outros locatários em um aplicativo compartilhado e quando você usa recursos e serviços compartilhados. Políticas de repetição agressivas podem fazer com que um número crescente de falhas transitórias ocorra para esses outros usuários e para aplicativos que compartilham os recursos e serviços. Da mesma forma, seu aplicativo pode ser afetado pelas políticas de repetição implementadas por outros usuários dos recursos e serviços. Para aplicativos comercialmente críticos, talvez você queira usar serviços premium que não são compartilhados. Isso oferece mais controle sobre a carga e a consequente limitação desses recursos e serviços, o que pode ajudar a justificar o custo extra.

Facilitação do Azure

A maioria dos SDKs de clientes e serviços do Azure fornece um mecanismo de repetição. No entanto, esses mecanismos diferem porque cada serviço tem diferentes características e requisitos e cada mecanismo de repetição é ajustado para o serviço específico. Esta seção resume os recursos do mecanismo de repetição para alguns serviços do Azure comumente usados.

Example

Consulte o padrão de aplicativo Web Confiável para .NET para obter um exemplo que usa muitos dos padrões discutidos neste artigo. Há também uma implementação de referência no GitHub.

Links relacionados

• Padrão de disjuntor
• Padrão de repetição.
• Padrão de limitação
• Padrão de transação compensatória
• Uma postagem no blog sobre padrões de idempotência
• Resiliência de conexão
• Injetar serviços fictícios
• Padrão de fila de mensagens mortas

Lista de verificação de confiabilidade

Consulte o conjunto completo de recomendações.