# REL 5 Como você projeta interações em um sistema distribuído para mitigar ou resistir a falhas?
Os sistemas distribuídos dependem de redes de comunicação para interconectar componentes (como servidores ou serviços). Sua carga de trabalho deve operar de forma confiável, apesar da perda de dados ou da latência nessas redes. Os componentes do sistema distribuído devem operar sem afetar negativamente outros componentes ou a carga de trabalho. Essas melhores práticas permitem que as cargas de trabalho resistam a tensões ou falhas, recuperem-se mais rapidamente delas e reduzam o impacto de tais prejuízos. Como resultado, o Mean Time To Recovery (MTTR – Tempo médio até a recuperação) é melhorado.
**Topics**
+ [REL05-BP01 Implementar uma degradação simples para transformar dependências rígidas aplicáveis em dependências flexíveis](rel_mitigate_interaction_failure_graceful_degradation.md)
+ [REL05-BP02 Controlar o fluxo de solicitações](rel_mitigate_interaction_failure_throttle_requests.md)
+ [REL05-BP03 Controlar e limitar as chamadas de repetição](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP04 Antecipar-se à falha e filas limitadas](rel_mitigate_interaction_failure_fail_fast.md)
+ [REL05-BP05 Definir tempos limite do cliente](rel_mitigate_interaction_failure_client_timeouts.md)
+ [REL05-BP06 Criar serviços sem estado sempre que possível](rel_mitigate_interaction_failure_stateless.md)
+ [REL05-BP07 Implementar medidas emergenciais](rel_mitigate_interaction_failure_emergency_levers.md)
# REL05-BP01 Implementar uma degradação simples para transformar dependências rígidas aplicáveis em dependências flexíveis
Quando as dependências de um componente não estão íntegras, o próprio componente ainda pode funcionar, embora de maneira prejudicada. Por exemplo, quando há falha em uma chamada de dependência, faça o failover para uma resposta estática predeterminada.
Considere um serviço B que é chamado pelo serviço A e, por sua vez, chama o serviço C.
![\[Diagrama mostrando que o serviço C falha quando chamado do serviço B. O serviço B retorna uma resposta degradada ao serviço A.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/graceful-degradation.png)
Quando o serviço B chama o serviço C, ele recebeu um erro ou tempo limite dele. O serviço B, sem uma resposta do serviço C (e os dados que ele contém), retorna o que pode. Esse pode ser o último bom valor armazenado em cache, ou o serviço B pode substituir uma resposta estática pré-determinada pelo que receberia do serviço C. Em seguida, ele pode retornar uma resposta degradada ao chamador, o serviço A. Sem essa resposta estática, a falha no serviço C seria feita em cascata por meio do serviço B para o serviço A, resultando em uma perda de disponibilidade.
De acordo com o fator multiplicativo na equação de disponibilidade para dependências rígidas (consulte [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html#dbedbedda68f9a15ACLX122)), qualquer queda na disponibilidade do C afeta gravemente a disponibilidade efetiva do B. Ao retornar a resposta estática, o serviço B atenua a falha em C e, embora degradada, faz com que a disponibilidade do serviço C pareça 100% (supondo que ela retorne de forma confiável a resposta estática sob condições de erro). Observe que a resposta estática é uma alternativa simples para retornar um erro e não é uma tentativa de recalcular a resposta usando meios diferentes. Essas tentativas em um mecanismo completamente diferente para tentar alcançar o mesmo resultado são chamadas de comportamento de fallback e são um antipadrão a ser evitado.
Outro exemplo de degradação tranquila é o *padrão de disjuntor*. Estratégias de repetição devem ser usadas quando a falha é transitória. Quando esse não for o caso, e a operação provavelmente falhar, o padrão do disjuntor impedirá que o cliente execute uma solicitação que provavelmente falhará. Quando as solicitações estão sendo processadas normalmente, o disjuntor está fechado e as solicitações passam. Quando o sistema remoto começa a retornar erros ou exibe alta latência, o disjuntor abre e a dependência é ignorada ou os resultados são substituídos por respostas mais simples, mas menos abrangentes (que podem ser simplesmente um cache de resposta). O sistema periodicamente tenta chamar a dependência para determinar se ela se recuperou. Quando isso acontece, o disjuntor é fechado.
![\[Diagrama mostrando o disjuntor em estados abertos e fechados.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/circuit-breaker.png)
Além dos estados fechado e aberto mostrados no diagrama, após um período configurável no estado aberto, o disjuntor pode fazer a transição para meio aberto. Nesse estado, ele tenta chamar o serviço periodicamente a uma taxa muito menor do que o normal. Esse teste é usado para verificar a integridade do serviço. Depois de vários êxitos no estado meio aberto, o disjuntor muda para fechado, e as solicitações normais são retomadas.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Implemente uma degradação simples para transformar dependências rígidas aplicáveis em dependências flexíveis. Quando as dependências de um componente não estão íntegras, o próprio componente ainda pode funcionar, embora de maneira prejudicada. Por exemplo, quando há falha em uma chamada de dependência, faça o failover para uma resposta estática predeterminada.
+ Ao retornar uma resposta estática, a workload atenua as falhas que ocorrem nas dependências dela.
+ [Laboratório do Well-Architected: nível 300: implementação de verificações de integridade e do gerenciamento de dependências para melhorar a confiabilidade](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
+ Detecte quando há probabilidade de falha na operação de repetição e impeça o cliente de fazer chamadas com falha com o padrão de disjuntor.
+ [CircuitBreaker](https://martinfowler.com/bliki/CircuitBreaker.html)
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: controlar o fluxo de solicitações de API para uma melhor produtividade](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [CircuitBreaker (resume “Circuit Breaker” do livro “Release It\$1”)](https://martinfowler.com/bliki/CircuitBreaker.html)
+ [Repetições de erros e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Michael Nygard “Release It\$1 Design and Deploy Production-Ready Software”](https://pragprog.com/titles/mnee2/release-it-second-edition/)
+ [A Amazon Builders’ Library: evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [A Amazon Builders’ Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [A Amazon Builders’ Library:desafios e estratégias de armazenamento em cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [A Amazon Builders’ Library: tempos limite, novas tentativas e recuo com tremulação](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vídeos relacionados:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
**Exemplos relacionados:**
+ [Laboratório do Well-Architected: nível 300: implementação de verificações de integridade e do gerenciamento de dependências para melhorar a confiabilidade](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL05-BP02 Controlar o fluxo de solicitações
O controle de utilização de solicitações é um padrão de atenuação para responder a um aumento inesperado na demanda. Algumas solicitações são atendidas, mas aquelas que ultrapassam um limite definido são rejeitadas e retornam uma mensagem indicando que foram limitadas. A expectativa dos clientes é que eles recuem e abandonem a solicitação ou tentem novamente com uma taxa mais lenta.
Seus serviços devem ser projetados para processar uma capacidade conhecida de solicitações que cada nó ou célula pode processar. Esta capacidade pode ser estabelecida por meio de teste de carga. É preciso acompanhar a taxa de chegada das solicitações e, se ela ultrapassar esse limite, a resposta adequada será indicar que a solicitação foi limitada. Isso permite que o usuário tente outra vez, possivelmente para um nó ou célula diferente que talvez tenha capacidade disponível. O Amazon API Gateway fornece métodos para controle de solicitações. O Amazon SQS e o Amazon Kinesis podem armazenar solicitações em buffer, suavizar a taxa de solicitações e aliviar a necessidade de controle de utilização para solicitações que podem ser abordadas de forma assíncrona.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Controle o fluxo de solicitações. Esse é um padrão de mitigação para responder a um aumento inesperado na demanda. Algumas solicitações são atendidas, mas aquelas que ultrapassam um limite definido são rejeitadas e retornam uma mensagem indicando que foram limitadas. A expectativa dos clientes é que eles recuem e abandonem a solicitação ou tentem novamente com uma taxa mais lenta.
+ Use o Amazon API Gateway
+ [Controlar o fluxo de solicitações de API para uma melhor produtividade](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: controlar o fluxo de solicitações de API para uma melhor produtividade](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Repetições de erros e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [A Amazon Builders’ Library: evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [A Amazon Builders’ Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [A Amazon Builders’ Library: tempos limite, novas tentativas e recuo com tremulação](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
+ [Controlar o fluxo de solicitações de API para uma melhor produtividade](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
**Vídeos relacionados:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP03 Controlar e limitar as chamadas de repetição
Use o recuo exponencial para tentar novamente após intervalos progressivamente mais longos. Introduza uma variação para tornar esses intervalos de repetição aleatórios e limite o número máximo de novas tentativas.
Os componentes típicos em um sistema de software distribuído incluem servidores, load balancers, bancos de dados e servidores DNS. Em operação, e sujeito a falhas, qualquer um deles pode começar a gerar erros. A técnica padrão para lidar com erros é implementar novas tentativas no lado do cliente. Essa técnica aumenta a confiabilidade e a disponibilidade do aplicativo. No entanto, em grande escala (e se os clientes tentarem repetir a operação com falha assim que ocorrer um erro) a rede poderá ficar rapidamente saturada com solicitações novas e repetidas, cada uma competindo pela largura de banda da rede. Isso pode resultar em uma *tempestade de repetições,* o que reduzirá a disponibilidade do serviço. Esse padrão pode continuar até que ocorra uma falha completa do sistema.
Para evitar tais cenários, algoritmos de recuo, como o *recuo exponencial* comum, devem ser usados. Os algoritmos de recuo exponencial diminuem gradualmente a taxa na qual novas tentativas são realizadas, evitando assim congestionamentos de rede.
Muitos SDKs e bibliotecas de software, incluindo os da AWS, implementam uma versão desses algoritmos. No entanto, **nunca presuma que exista um algoritmo de recuo, sempre teste e verifique se esse é o caso.**
O recuo simples não é suficiente porque, em sistemas distribuídos, todos os clientes podem recuar simultaneamente, criando clusters de chamadas de repetição. Marc Brooker, em sua publicação de blog [, Recuo exponencial e jitter](https://aws.amazon.com/blogs/architecture/exponential-backoff-and-italics%0djitter/), explica como modificar a função wait() no recuo exponencial para impedir clusters de chamadas de repetição. A solução é adicionar *jitter* na função wait(). Para evitar tentar novamente por muito tempo, as implementações devem limitar o recuo a um valor máximo.
Por fim, é importante configurar um *número máximo de repetições* ou tempo decorrido, após o qual uma repetição simplesmente falhará. Os AWS SDKs implementam isso por padrão, o que pode ser configurado. Para serviços mais baixos na pilha, um limite máximo de repetição zero ou um pode limitar o risco, mas ainda ser eficaz à medida que novas tentativas forem delegadas a serviços mais altos na pilha.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Controle e limite as chamadas de repetição. Use o recuo exponencial para tentar novamente após intervalos progressivamente mais longos. Introduza uma variação para tornar esses intervalos de repetição aleatórios e limite o número máximo de novas tentativas.
+ [Repetições de erros e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ Os SDKs da Amazon implementam repetições e recuo exponencial por padrão. Implemente uma lógica semelhante em sua camada de dependência ao chamar seus próprios serviços dependentes. Decida quais são os tempos limite e quando parar de tentar novamente com base no seu caso de uso.
## Recursos
**Documentos relacionados:**
+ [Amazon API Gateway: controlar o fluxo de solicitações de API para uma melhor produtividade](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Repetições de erros e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [A Amazon Builders’ Library: evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [A Amazon Builders’ Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [A Amazon Builders’ Library:desafios e estratégias de armazenamento em cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [A Amazon Builders’ Library: tempos limite, novas tentativas e recuo com tremulação](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vídeos relacionados:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP04 Antecipar-se à falha e filas limitadas
Se a carga de trabalho não puder responder a uma solicitação com êxito, gere uma falha rápida. Isso permite a liberação dos recursos associados a uma solicitação e permite que o serviço se recupere se estiver ficando sem recursos. Se a carga de trabalho puder responder com êxito, mas a taxa de solicitações for muito alta, use uma fila para armazenar as solicitações em buffer. No entanto, não permita filas longas que possam levar ao fornecimento de solicitações obsoletas que o cliente já tinha descartado.
Essa melhor prática se aplica ao lado do servidor, ou receptor, da solicitação.
Esteja ciente de que as filas podem ser criadas em vários níveis de um sistema e podem impedir seriamente a capacidade de recuperação rápida à medida que solicitações antigas obsoletas (que não precisam mais de uma resposta) são processadas antes de solicitações mais recentes. Esteja ciente dos locais onde as filas existem. Elas geralmente se ocultam em fluxos de trabalho ou em trabalhos registrados em um banco de dados.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Antecipe-se à falha e limite filas. Se a carga de trabalho não puder responder a uma solicitação com êxito, gere uma falha rápida. Isso permite a liberação dos recursos associados a uma solicitação e permite que o serviço se recupere se estiver ficando sem recursos. Se a carga de trabalho puder responder com êxito, mas a taxa de solicitações for muito alta, use uma fila para armazenar as solicitações em buffer. No entanto, não permita filas longas que possam levar ao fornecimento de solicitações obsoletas que o cliente já tinha descartado.
+ Implemente antecipação à falha quando o serviço estiver sob pressão.
+ [Falha rápida](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ Filas limitadas. Em um sistema baseado em fila, quando o processamento é interrompido, mas as mensagens continuam chegando, o débito de mensagens pode se acumular em uma lista grande de pendências, aumentando o tempo de processamento. Os resultados podem deixar de ser úteis por conta da demora na conclusão do trabalho, o que afeta principalmente a disponibilidade que o enfileiramento tinha que proteger.
+ [A Amazon Builders’ Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
## Recursos
**Documentos relacionados:**
+ [Repetições de erros e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [Falha rápida](https://www.martinfowler.com/ieeeSoftware/failFast.pdf)
+ [A Amazon Builders’ Library: evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [A Amazon Builders’ Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [A Amazon Builders’ Library:desafios e estratégias de armazenamento em cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
+ [A Amazon Builders’ Library: tempos limite, novas tentativas e recuo com tremulação](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vídeos relacionados:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP05 Definir tempos limite do cliente
Defina tempos limite adequados, verifique-os sistematicamente e não dependa de valores padrão, já que eles costumam ser muito altos.
Essa melhor prática se aplica ao lado do cliente, ou remetente, da solicitação.
Defina um tempo limite de conexão e um tempo limite de solicitação em qualquer chamada remota e, normalmente, em qualquer chamada entre processos. Muitas estruturas de trabalho oferecem recursos de tempo limite integrados, mas tenha cuidado, porque muitos deles têm valores padrão infinitos ou muito altos. Um valor muito alto reduz a utilidade do tempo limite porque os recursos continuam a ser consumidos enquanto o cliente aguarda o decorrer do tempo limite. Um valor muito baixo pode gerar maior tráfego no back-end e maior latência, porque muitas solicitações são repetidas. Em alguns casos, isso pode levar a interrupções completas porque todas as solicitações estão sendo repetidas.
Para saber mais sobre como a Amazon usa tempos limite, repetições e recuo com tremulação, consulte a [https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/?did=ba_card&trk=ba_card).
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Alto
## Orientações para a implementação
+ Defina um tempo limite de conexão e um tempo limite de solicitação em qualquer chamada remota e, normalmente, em qualquer chamada entre processos. Muitas estruturas de trabalho oferecem recursos de tempo limite integrados, mas tenha cuidado, porque muitos deles têm valores padrão infinitos ou muito altos. Um valor muito alto reduz a utilidade do tempo limite porque os recursos continuam a ser consumidos enquanto o cliente aguarda o decorrer do tempo limite. Um valor muito baixo pode gerar maior tráfego no back-end e maior latência, porque muitas solicitações são repetidas. Em alguns casos, isso pode levar a interrupções completas porque todas as solicitações estão sendo repetidas.
+ [AWS SDK: repetições e tempos limite](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
## Recursos
**Documentos relacionados:**
+ [AWS SDK: repetições e tempos limite](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/retries-timeouts.html)
+ [Amazon API Gateway: controlar o fluxo de solicitações de API para uma melhor produtividade](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)
+ [Repetições de erros e recuo exponencial na AWS](https://docs.aws.amazon.com/general/latest/gr/api-retries.html)
+ [A Amazon Builders’ Library: tempos limite, novas tentativas e recuo com tremulação](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)
**Vídeos relacionados:**
+ [Retry, backoff, and jitter: AWS re:Invent 2019: Introducing The Amazon Builders’ Library (DOP328)](https://youtu.be/sKRdemSirDM?t=1884)
# REL05-BP06 Criar serviços sem estado sempre que possível
Os serviços não devem exigir estado ou devem descarregar o estado de modo que não haja dependência entre solicitações de clientes diferentes em relação aos dados armazenados localmente no disco ou na memória. Isso permite que os servidores sejam substituídos quando necessário sem causar impacto na disponibilidade. O Amazon ElastiCache ou o Amazon DynamoDB são bons destinos para o estado descarregado.
![\[Nesta aplicação Web sem estado, o estado da sessão é descarregado para o Amazon ElastiCache.\]](http://docs.aws.amazon.com/pt_br/wellarchitected/2022-03-31/framework/images/stateless-webapp.png)
Quando os usuários ou serviços interagem com um aplicativo, eles geralmente executam uma série de interações que formam uma sessão. Uma sessão são dados exclusivos para usuários que persistem entre solicitações enquanto usam o aplicativo. Um aplicativo sem estado é um aplicativo que não precisa de conhecimento de interações anteriores e não armazena informações da sessão.
Depois de projetados para serem sem estado, você pode usar serviços de computação com tecnologia sem servidor, como o AWS Lambda ou o AWS Fargate.
Além da substituição do servidor, outro benefício dos aplicativos sem estado é que eles podem escalar horizontalmente, pois qualquer um dos recursos de computação disponíveis (como instâncias do EC2 e funções do AWS Lambda) pode atender a qualquer solicitação.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Crie aplicações sem estado. Os aplicativos sem estado permitem a escalabilidade horizontal e são tolerantes a falhas de um nó individual.
+ Remova o estado que realmente pode ser armazenado nos parâmetros de solicitação.
+ Depois de examinar se o estado é necessário, mova qualquer rastreamento de estado para um armazenamento em cache resiliente multizona ou armazenamento de dados, como o Amazon ElastiCache, o Amazon RDS, Amazon DynamoDB ou uma solução de dados distribuídos de terceiros. Armazene os estados que não puderam ser movidos para armazenamentos de dados resilientes.
+ Alguns dados (como cookies) podem ser inseridos em cabeçalhos ou parâmetros de consulta.
+ Faça a refatoração para remover o estado que pode ser inserido rapidamente nas solicitações.
+ Alguns dados talvez não sejam realmente necessários por solicitação e podem ser recuperados sob demanda.
+ Remova os dados que podem ser recuperados de forma assíncrona.
+ Escolha um armazenamento de dados que atenda aos requisitos de um estado necessário.
+ Considere um banco de dados NoSQL para dados não relacionais.
## Recursos
**Documentos relacionados:**
+ [A Amazon Builders’ Library: evitar fallback em sistemas distribuídos](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems)
+ [A Amazon Builders’ Library: evitar backlogs de fila insuperáveis](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs)
+ [A Amazon Builders’ Library:desafios e estratégias de armazenamento em cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies/)
# REL05-BP07 Implementar medidas emergenciais
Medidas emergenciais são processos rápidos que podem atenuar o impacto da disponibilidade na workload.
**Nível de exposição a riscos quando esta prática recomendada não for estabelecida:** Médio
## Orientações para a implementação
+ Implemente medidas emergenciais. Trata-se de processos rápidos que podem atenuar o impacto da disponibilidade sobre a carga de trabalho. Eles podem ser operados na ausência de uma causa raiz. Uma medida emergencial ideal reduz a carga cognitiva dos resolvedores a zero ao fornecer critérios de ativação e de desativação totalmente determinísticos. Geralmente, as medidas são manuais, mas também podem ser automatizadas
+ Exemplos de medidas incluem
+ Bloquear todo tráfego de robô
+ Servir páginas estáticas em vez de dinâmicas
+ Reduzir a frequência de chamadas a uma dependência
+ Limitar as chamadas de dependências
+ Dicas para implementar e usar medidas emergenciais
+ Quando as medidas forem ativadas, faça MENOS, e não mais
+ Simplifique, evite comportamento bimodal
+ Teste suas medidas periodicamente
+ Veja a seguir exemplos de ações que NÃO são medidas emergenciais
+ Adicionar capacidade
+ Chamar proprietários de serviços de clientes que dependem do seu serviço e solicitar que eles reduzam as chamadas
+ Fazer uma alteração no código e lançá-lo