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á.
# Visão geral
## Comparando testes de resiliência com engenharia de caos
O teste de resiliência é determinístico. Ou seja, ele valida características conhecidas sobre mecanismos de resiliência, como disjuntores, novas tentativas, failovers ou fallbacks, que foram implementados em seu aplicativo. Ele confirma como esses componentes do aplicativo absorvem interrupções controladas com mínimo ou nenhum impacto sobre o usuário. Portanto, o teste de resiliência se concentra na validação de modos de falha conhecidos que são injetados nos componentes do aplicativo com o objetivo de produzir pass/fail resultados. Você deve executar testes de resiliência continuamente como uma etapa em seu pipeline para garantir que você não introduza regressões em sua postura de resiliência. Nos testes de resiliência, você geralmente não executa testes em componentes reais, mas APIs simula um determinado componente. Essa abordagem permite testes consistentes e reproduzíveis de cenários de falha em um ambiente controlado, tornando-a adequada para testes automatizados de integração e regressão de tubulações.
Em contraste, a engenharia do caos não é determinística. Ou seja, ele é baseado em hipóteses e verifica seu modelo mental sobre como o aplicativo e suas dependências (pessoas, processos e tecnologia) absorvem, se adaptam e, eventualmente, se recuperam de modos de falha imprevistos. Portanto, a engenharia do caos se concentra na end-to-end verificação de modos de falha desconhecidos, com o objetivo de detectar defeitos precocemente e remediá-los antes que se transformem em eventos de grande escala. A engenharia do caos promove o aprendizado contínuo e deve ser praticada por meio de um pipeline de caos separado ou de experimentos ad-hoc que permitem que você execute vários experimentos a qualquer momento sem bloquear a produtividade do desenvolvedor na implantação do código.
O processo de engenharia do caos geralmente começa com um dia de jogo do caos, que é um evento dedicado em que as equipes injetam intencionalmente falhas ou falhas controladas em seus aplicativos. O dia do jogo é progressivo: começa em ambientes de nível inferior (como desenvolvimento ou teste) e avança gradualmente para ambientes de nível superior (como preparação e pré-produção) à medida que aumenta a confiança. Ao percorrer sistematicamente esses ambientes, as equipes podem verificar se seus sistemas toleram adequadamente as falhas injetadas antes de chegarem à produção. Essa progressão metódica garante que, quando os experimentos de caos forem conduzidos em ambientes de produção, as equipes tenham adquirido uma confiança substancial nas capacidades de resiliência de seus sistemas. O processo do dia do jogo é uma abordagem proativa para identificar pontos fracos e vulnerabilidades na arquitetura e nas práticas operacionais de um aplicativo, ao mesmo tempo em que elimina o estresse do aprendizado durante uma interrupção inesperada na produção.
## O valor da engenharia do caos
Sistemas complexos são onipresentes no mundo atual. Eles desempenham um papel fundamental em muitos aspectos de nossas vidas, dos mercados financeiros aos cuidados de saúde. Esperamos que esses sistemas estejam sempre operacionais. No entanto, sistemas complexos geralmente são vulneráveis a eventos e comportamentos inesperados que podem ter consequências significativas. As organizações precisam planejar a disrupção em vez de se perguntar se isso acontecerá. Eles podem fazer isso aplicando testes de cenários em seus serviços comerciais críticos ou de missão crítica. É aqui que a engenharia do caos entra em ação.
A engenharia do caos oferece uma abordagem para gerenciar sistemas complexos que podem ajudar a mitigar riscos e melhorar a resiliência. O processo de preparação para experimentos de caos exige que as equipes desenvolvam hipóteses sobre o comportamento de seus sistemas, o que aprofunda sua compreensão de como os sistemas são construídos e como operam. Essa preparação geralmente revela lacunas mentais, percepções arquitetônicas e conhecimento operacional que, de outra forma, poderiam permanecer desconhecidos. Ao aprofundar a compreensão de como sistemas complexos reagem às falhas, a engenharia do caos promove maior transparência e responsabilidade no design e gerenciamento do sistema. Quanto mais frequentemente sua organização pratica a engenharia do caos, mais bem preparada ela se torna operacionalmente. A engenharia do caos ajuda você a estabelecer as melhores práticas para projetar aplicativos resilientes que possam sobreviver a falhas de componentes com o mínimo ou nenhum impacto no usuário. Isso garante que os aplicativos essenciais operem dentro dos níveis de serviço esperados e da tolerância ao impacto, ao mesmo tempo em que aprimora continuamente o conhecimento da equipe sobre seus próprios sistemas.
## Preparando-se para condições adversas
Ao criar AWS, você usa diferentes tipos de serviços, incluindo serviços zonais, como o Amazon Elastic Compute Cloud (Amazon EC2), serviços regionais, como o Amazon Simple Storage Service (Amazon S3), serviços globais, AWS Identity and Access Management como (IAM), serviços de software como serviço (SaaS) de terceiros e serviços locais. Cada tipo de serviço expõe diferentes domínios de falha que você precisa considerar. Como você se prepara para eventos autoinfligidos ou causados por terceiros sobre os quais sua organização não tem controle?
Para ajudar a entender como seu aplicativo pode responder a condições adversas, você pode usar [AWS Fault Injection Service (AWS FIS)](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html). AWS FIS é um serviço totalmente gerenciado para executar experimentos de injeção de falhas de forma controlada. Você pode usar esse serviço para injetar cenários AWS fornecidos, como interrupções de energia na zona de disponibilidade e problemas de conectividade entre regiões, ou criar seus próprios experimentos agrupando uma ampla variedade de ações de falha fornecidas pelo serviço. AWS FIS permite que suas equipes pratiquem e aprendam continuamente como seus aplicativos reagiriam a falhas comuns e corrigiriam defeitos à medida que os detectassem.
## Praticando engenharia de caos controlada
Os princípios fundamentais dos experimentos de caos controlado são:
+ Comece com um ambiente semelhante ao seu ambiente de produção.
+ Estabeleça uma hipótese e interrompa as condições para seu experimento.
+ Comece devagar.
+ Controle seus experimentos de caos.
+ Defina o escopo do impacto.
+ Conheça a linha de base do seu serviço.
+ Agende experimentos.
+ Corrija primeiro e depois experimente.
+ Monitore o experimento de perto.
+ Aprenda com seus resultados.
+ Priorize as descobertas, corrija e verifique.
+ Propague os aprendizados em toda a sua organização.
Para escalar com sucesso a engenharia do caos, você deve implementar experimentos de caos de forma controlada. Ao usar AWS FIS, você pode criar condições de parada usando os [ CloudWatchalarmes da Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html). Você pode incorporar essas condições em um modelo de experimento para garantir que os experimentos sejam interrompidos se estiverem fora dos limites e revertidos ao último estado conhecido. AWS FIS também fornece alavancas de segurança. Quando você aciona essas alavancas, AWS FIS interrompe e reverte todos os experimentos em execução na conta do Região da AWS, incluindo experimentos com várias contas, e impede o início de novos experimentos. Isso evita a injeção de falhas durante determinados períodos de tempo, como horários comerciais, eventos de vendas ou lançamentos de produtos, ou em resposta a alarmes de integridade de aplicativos. A alavanca de segurança permanece engatada até ser desengatada manualmente.
Ao conduzir um experimento de caos, você deve definir salvaguardas para evitar efeitos colaterais indesejáveis no ambiente, especialmente se houver a possibilidade de o experimento afetar os aplicativos que estão em produção. Ao planejar o experimento, antecipe quaisquer efeitos adversos que ele possa ter em outras aplicações no ambiente. Por exemplo, outros aplicativos podem receber mensagens errôneas do aplicativo que faz parte do experimento, enfrentar altos volumes de solicitações ou enfrentar contenção de recursos se compartilharem infraestrutura. Documente esses riscos e resolva quaisquer problemas conhecidos ou inaceitáveis antes de realizar o experimento.