As organizações com alta resiliência, maturidade digital e alta observabilidade por meio de dashboards e outras ferramentas devem adotar a engenharia de caos, pois podem tomar medidas imediatas em relação aos problemas que ocorrem por meio de testes. As organizações que não contam com essa observabilidade⁴ (link externo ao site ibm.com) podem levar muito tempo para resolver os testes que eles criam por meio da engenharia do caos.

A engenharia do caos também é essencial para organizações que usam a nuvem, sobretudo nuvem pública e aplicativos nativos da nuvem. A nuvem pública traz possíveis problemas de interrupção que exigem coordenação com o provedor de nuvem, o que cria uma abordagem diferente em relação ao enfrentamento de problemas locais. 

As empresas que usam a nuvem ainda costumam abordar incidentes de TI sem considerar como a nuvem e o software como serviço (SaaS) afetam esses incidentes de forma diferente, de acordo com a Constellation Research⁵ (link externo ao site ibm.com). 

Além disso, o crescimento do uso de microsserviços, que aumenta a quantidade de hosts ou contêineres em execução em um sistema, cria desafios únicos (link externo ao site ibm.com) que podem ser descobertos e resolvidos por meio de testes do caos. Ele transfere as complexidades do design do código para as operações do sistema, o que não elimina as complexidades, mas permite maior automação.

A engenharia do caos também ajuda as organizações a aumentar a velocidade de seus pipelines de integração contínua e entrega contínua (CI/CD). A incorporação da engenharia de caos à CI/CD, tal como foi feito pela Netflix⁶ (link externo ao site ibm.com), permite que as organizações automatizem testes contínuos e controlem seu possível impacto. 

Por fim, como as organizações se conectam cada vez mais a parceiros por meio de APIs, um eventual problema em seus sistemas pode ter um impacto indireto em outras organizações.

A implementação da engenharia do caos ajuda as organizações a entender os pontos fracos de sua arquitetura e corrigi-los, criando a possibilidade de prever falhas futuras. Uma engenharia do caos bem-sucedida ajuda as organizações a minimizar falhas técnicas de modo que não haja qualquer impacto significativo sobre o cliente. Permite também a criação de arquiteturas mais fortes e resilientes de sistemas complexos. Quando uma organização decide adotar a engenharia do caos, a próxima etapa é determinar se ela será executada no ambiente de produção ou pré-produção.

As equipes de DevOps contam com várias opções para realizar testes de engenharia do caos e testar diversos processos do sistema.

• Injeção de latência: de maneira intencional, as equipes de DevOps criam cenários que simulam uma conexão de rede lenta ou com falha. Isso inclui a introdução de atrasos na rede ou tempos de resposta mais lentos.
• Injeção de falha:  envolve a introdução intencional de erros no sistema para determinar como eles afetam outros sistemas dependentes e se eles interrompem os serviços. Entre os exemplos de injeção de falhas estão: induzir falhas no disco, encerrar processos, desligar um host ou introduzir aumento de energia ou temperatura. As injeções de falhas ajudam as organizações a identificar pontos singulares de falha, que podem provocar uma falha de todo o sistema caso algo aconteça com eles.
• Geração de carga: relacionado ao estresse intencional do sistema, enviando níveis de tráfego significativos muito além das operações normais. Isso ajuda os engenheiros de confiabilidade local (SREs) a entender eventuais gargalos no sistema, o que, por sua vez, permite que eles criem sistemas mais escaláveis. 
• Testes canários: envolve o lançamento de um produto ou recurso novo para um pequeno grupo de usuários. Assim, qualquer falha ou bug afetará apenas uma porcentagem dos visitantes, deixando o restante do público acessar o site já existente.

A criação do processo ideal de engenharia do caos exige vários princípios para garantir que uma organização tenha um sistema distribuído em escala. 

• Entender o sistema: envolve um conhecimento abrangente do sistema holístico, suas propriedades e funções emergentes e sua topologia, arquitetura, dependências, comportamento em estado de equilíbrio, resposta de saída e características como disponibilidade, latência e rendimento.
  
• Aceitar as falhas: de início, parece paradoxal que os engenheiros de software permitam que um incidente aconteça quando eles estão programados para evitar tais ocorrências. No entanto, interrupções nos serviços de TI sempre acabam acontecendo, então é melhor que isso ocorra em um ambiente controlado. Assim, será possível identificar a solução preventivamente, e não quando a equipe da organização estiver fora do expediente ou se deparar com um problema específico que nunca tinha enfrentado antes.
• Estabelecer um comportamento em estado de equilíbrio: primeiro, a equipe de engenharia deve definir como o sistema se comporta durante a execução correta, para identificar como os testes afetam esse estado de equilíbrio.
• Identificar incidentes do mundo real: os testes de engenharia do caos devem se aproximar o máximo possível daquilo que pode acontecer em um dia normal, em vez de criar situações improváveis. Falhas de rede e infraestrutura, código incorreto, problemas de energia e sobrecarga de tráfego são possíveis ocorrências.
• Criar um dia especial: a engenharia do caos pode estudar o ambiente em um dia especial, onde vários testes ocorrem durante um dia específico para maximizar os recursos, de modo a identificar e resolver o máximo de problemas possível. 
• Usar automação: organizações de todos os portes podem usar a engenharia do caos por meio da automatização de testes, que seriam muito trabalhosos se as empresas os realizassem manualmente. Isso reduz a carga das equipes de TI durante o processo de engenharia do caos. Formulação do teste, injeção de falha e provisão da infraestrutura são aspectos da experimentação que as organizações podem automatizar
• Atentar-se para o alcance dos estragos: um engenheiro do caos deve se esforçar para minimizar o alcance dos estragos para que o dano real aos clientes seja o menor possível. Veja algumas formas de minimizar esse alcance:
  • Visar um subconjunto de serviços: a engenharia do caos, sobretudo em um cenário de produção, não deve interromper fundamentalmente o serviço de uma organização. O direcionamento a um subconjunto específico de serviços pode minimizar o impacto de um incidente, garantindo que ele não derrube todo o sistema.
  • Execute o teste por um tempo finito: ele deve ter um início e um fim. O objetivo do teste é criar um incidente e resolvê-lo, em vez de deixá-lo em execução sem controle por muito tempo.
  • Execute o teste fora do tráfego de pico: as organizações devem tentar evitar a execução dos testes durante os horários de pico, a menos que queiram avaliar especificamente como a alta capacidade afeta o sistema durante um incidente. 
  • Execute o teste no ambiente de desenvolvimento: a maneira mais fácil de garantir que não haja interrupção alguma do serviço de experiência do cliente é sua execução no ambiente de pré-produção. No entanto, isso significa que as condições serão diferentes do ambiente de produção, possivelmente dando uma visão falsa do que está acontecendo. Para minimizar o problema, seus ambientes de pré-produção e produção devem se assemelhar o máximo possível. 
  • Faça testes em todos os componentes: a experimentação do caos é um processo interminável, pois o sistema de uma organização está sempre mudando. Um dos objetivos deve ser testar "tudo"; examinar todos os componentes, camadas, serviços e suas dependências em todo o processo.

Organizações que utilizam engenharia do caos devem decidir se é melhor usar testes de caos em seus ambientes de produção ou pré-produção. Há várias razões pelas quais a engenharia do caos é mais benéfica em ambientes de produção. Ambientes de produção fornecem o cenário mais preciso para entender como um incidente afeta a experiência do cliente. Outra razão é que o ambiente de pré-produção pode não ter exatamente as mesmas configurações do ambiente de produção, o que cria certa variabilidade nos testes.

Por exemplo, um incidente em um ambiente de pré-produção talvez não crie uma resposta realista, pois não tem os mesmos níveis de tráfego que o ambiente de produção. Também pode não ter as mesmas configurações de segurança que aquele ambiente. 

Algumas organizações temem causar problemas intencionalmente em seu local de produção, por isso realizam os testes no local de pré-produção ou desenvolvimento. Isso garante que eventuais problemas não afetem a experiência do cliente no modo de produção . Para mitigar esse problema, algumas organizações começam em ambientes de pré-produção para entender o processo antes de migrar para o ambiente de produção.

As organizações escolherão o ambiente a ser usado com base em sua tolerância ao risco. Em última análise, a engenharia do caos visa testar problemas reais em grande escala. É por isso que os ambientes de produção fornecem a imagem mais precisa do que está acontecendo e do que precisa ser corrigido.