As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Estratégias comuns de mitigação Para começar, considere usar mitigações *preventivas* para evitar que o modo de falha afete a história do usuário. Você deve então pensar em mitigações *corretivas*. As mitigações corretivas ajudam o sistema a se autorrecuperar ou a se adaptar às mudanças nas condições. Confira uma lista de mitigações comuns para cada categoria de falha que se alinham às propriedades de resiliência. | | | **Categoria de falha** | **Propriedades de resiliência desejadas** | **Mitigações** | | --- |--- |--- | | Pontos únicos de falha (SPOFs) | Redundância e tolerância a falhas | Implemente [redundância](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html): por exemplo, usando várias instâncias do EC2 sob controle do Elastic Load Balancing (ELB). Remova as dependências do [ambiente de gerenciamento do serviço global da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-service-types.html#global-services) e use-as somente em planos de dados de serviço global. Use a [degradação normal](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation.html) quando um recurso não estiver disponível, para que seu sistema fique estaticamente estável até um único ponto de falha. | | Carga Excessiva | Capacidade suficiente | As principais estratégias de mitigação são [limitação de taxa](https://aws.amazon.com/builders-library/fairness-in-multi-tenant-systems), [descarte de carga](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload) e priorização do trabalho, [trabalho constante](https://aws.amazon.com/builders-library/reliability-and-constant-work), [backoff exponencial e repetição com jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) ou simplesmente não repetição, [colocando o serviço menor sob controle](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control), [gerenciando a profundidade da fila](https://aws.amazon.com/builders-library/avoiding-insurmountable-queue-backlogs), [escalabilidade automática](https://aws.amazon.com/autoscaling/), [evitando caches frios](https://aws.amazon.com/builders-library/caching-challenges-and-strategies) e [disjuntores](https://brooker.co.za/blog/2022/02/16/circuit-breakers.html). Você também deve considerar seu plano de capacidade e pensar nos limites futuros de capacidade e escalabilidade, os dois relacionados aos recursos da AWS e aos limites do seu sistema, que você pode atingir. | | Latência excessiva | Saída oportuna | Implemente [tempos limite](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) configurados adequadamente ou tempos limite adaptáveis (alterando os valores de tempo limite com base nas condições de latência atuais e previstas para permitir que uma dependência lenta progrida em vez de desistir de solicitações lentas). Implemente [recuos exponenciais e repetição com jitter](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/), bem como hedging, usando tecnologias como [TCP de vários caminhos](https://en.wikipedia.org/wiki/Multipath_TCP) ao se conectar a serviços em nuvem de ambientes on-premises e experimentar latência em rotas específicas, usando [interações assíncronas com sistemas com acoplamento fraco](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_prevent_interaction_failure_loosely_coupled_system.html), [armazenando em cache](https://aws.amazon.com/builders-library/caching-challenges-and-strategies) e [sem desperdiçar o trabalho](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/). | | Configuração incorreta e bugs | Saída correta | A principal forma de detectar erros funcionais repetíveis no software é testar rigorosamente por meio de mecanismos como [análise estática](https://en.wikipedia.org/wiki/Static_program_analysis), [testes de unidade](https://en.wikipedia.org/wiki/Unit_testing), [testes de integração](https://en.wikipedia.org/wiki/Regression_testing), [testes de regressão](https://docs.aws.amazon.com/prescriptive-guidance/latest/load-testing/welcome.html), [testes de carga](https://aws.amazon.com/blogs/architecture/chaos-engineering-in-the-cloud/) e [testes de resiliência](https://en.wikipedia.org/wiki/Integration_testing). Implemente estratégias como [infraestrutura como código (IaC)](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/infrastructure-as-code.html) e [automação de integração e entrega contínuas (CI/CD)](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments) para ajudar a mitigar ameaças de configuração incorreta. Use técnicas de implantação, como [implantações canárias](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/) [one-box](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/canary-deployments.html), implantações fracionárias alinhadas à delimitação de isolamento contra falhas ou [implantações azul/verde](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/blue-green-deployments.html) para reduzir configurações incorretas e bugs. | | Destino compartilhado | Isolamento de falhas | Implemente a [tolerância a falhas](https://aws.amazon.com/builders-library/minimizing-correlated-failures-in-distributed-systems) em seu sistema e use delimitações de isolamento contra falhas lógicas e físicas, como vários clusters de computação ou contêineres, várias contas da AWS, várias entidades principais do AWS Identity and Access Management (IAM), várias zonas de disponibilidade e talvez várias Regiões da AWS. Técnicas como [arquiteturas baseadas em células](https://youtu.be/swQbA4zub20) e [shuffle sharding](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding) também podem melhorar o isolamento de falhas. Considere padrões como [acoplamento fraco](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_prevent_interaction_failure_loosely_coupled_system.html) e [degradação ordenada](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_failure_graceful_degradation.html) para evitar falhas em cascata. Ao priorizar histórias de usuários, você também pode usar essa priorização para distinguir entre histórias de usuários que são essenciais para a função principal da empresa e histórias de usuários que podem ser degradadas de forma ordenada. Por exemplo, em um site de comércio eletrônico, você não gostaria que o widget de promoções no site afetasse a capacidade de processar novos pedidos. | Embora algumas dessas mitigações exijam um esforço mínimo para serem implementadas, outras (como a adoção de uma arquitetura baseada em células para isolamento preditivo de falhas e falhas mínimas de destino compartilhado) podem exigir uma reformulação de toda a workload e não apenas dos componentes de uma história de usuário específica. Conforme analisado anteriormente, é importante ponderar a probabilidade e o impacto do modo de falha em relação às compensações que você faz para mitigá-lo. Além das técnicas de mitigação que se aplicam a cada categoria do modo de falha, você deve considerar as mitigações necessárias para a recuperação da história do usuário ou de todo o sistema. Por exemplo, uma falha pode interromper um fluxo de trabalho e impedir que os dados sejam gravados nos destinos pretendidos. Nesse caso, poderá ser necessário um conjunto de ferramentas operacionais para reorientar o fluxo de trabalho ou corrigir os dados manualmente. Você talvez também precise criar um mecanismo de verificação em sua workload para ajudar a evitar a perda de dados quando ocorrerem falhas. Ou talvez você precise criar um andon cord para pausar o fluxo de trabalho e parar de aceitar novos trabalhos para evitar mais danos. Nesses casos, você deve pensar nas ferramentas operacionais e nas barreiras de proteção necessárias. Por fim, você deve sempre presumir que os humanos cometerão erros ao desenvolver sua estratégia de mitigação. Embora as práticas modernas de DevOps busquem automatizar as operações, os humanos ainda precisam interagir com suas workloads por vários motivos. Uma ação humana incorreta pode causar uma falha em qualquer uma das categorias do SEEMS, como remover muitos nós durante a manutenção e causar uma sobrecarga ou configurar incorretamente um sinalizador de recurso. Esses cenários são, na verdade, uma falha nas barreiras de proteção preventivas. Uma análise da causa raiz nunca deve terminar com a conclusão de que “um humano cometeu um erro”. Em vez disso, deve abordar as razões pelas quais os erros foram possíveis em primeiro lugar. Portanto, sua estratégia de mitigação deve considerar como os operadores humanos podem interagir com os componentes da workload e como evitar ou minimizar o impacto dos erros do operador humano por meio de barreiras de proteção.