Chaos Engineering: o caos em ambiente produtivo

A teoria do caos estabelece que uma pequena mudança ocorrida no início de um evento qualquer pode ter consequências desconhecidas no futuro. Quem não conhece a famosa frase (uma das versões) do efeito borboleta? “O bater de asas de uma borboleta no Brasil pode desencadear um tornado no Texas.”

Pautada nesse princípio a metodologia de Chaos Engineering, conceito criado e executado pela Netflix, além de outras grandes empresas, tem como base inserir perturbações em um ambiente sistêmico e avaliar seu comportamento em busca de aberrações, fraquezas e resultados imprevisíveis (não imaginadas em tempo de levantamento de requisitos não-funcionais). E claro, sendo realizado em ambiente PRODUTIVO, isso mesmo, no ambiente que seus clientes estão utilizando e em horário comercial.

A metodologia se baseia em alguns princípios:

Construa uma hipótese

Essa hipótese, apesar do nome, deve ser construída sobre o comportamento padrão do ambiente/sistema. Por exemplo: meus tempos de respostas estão sempre abaixo de 5s e a taxa de erro fica em torno de 1%. Ou melhor, hipóteses mais voltadas ao negócio: são finalizadas 500 compras por minuto. São fechadas mil propostas por hora.

Varie os eventos do mundo real

O que seriam eventos do mundo real? Eventos comuns que podem acontecer no dia-a-dia, tais como: queda de um nó do banco de dados, queda de uma máquina virtual, lentidão de rede, etc. Esses eventos devem ser simulados de propósito no ambiente.

Execute experimentos

Aqui é preciso ser criativo, pense em situações não comuns tais como: abrir centenas de conexões telnet num servidor, matar um serviço, tirar da tomada uma máquina (extrapolando um pouco), fazer login e logout massivamente e aleatoriamente.

Automatize experimentos para rodar continuamente e aleatoriamente

Agende os eventos e experimentos para rodarem automaticamente variando dia, horário e alvo.Minimize os impactos negativos. Não é um princípio original da metodologia, mas deve ser observado para que a experiência do cliente não seja afetada gerando desconforto, perda de receita ou algum outro impacto semelhante. A grande pergunta agora deve estar sendo feita: como aplicar esse conceito? devo usar Chaos Monkey ou alguma aplicação parecida?

Para quem não conhece, o Chaos Money é um sistema que aleatoriamente escolhe uma, ou mais, instâncias de máquina virtual ou sistema e a derruba. Claro que isso é feito em horário comercial, quando todos os profissionais técnicos estão presentes e podem atuar.

Então, caso sua empresa tenha uma esteira DevSecOps bem implementada, ou um processo de Ciclo de vida bem maduro, com continuous testing e Always testing, shift-left na veia do seu time, um excelente observabilidade do seu ambiente/sistema (com monitoramento, logs, traces etc), então você pode optar por ter um sistema na linha do Chaos Monkey.

Mas caso não seja esse o cenário, pode ser organizado um Chaos Day (mobilizando os profissionais) e traçar uma estratégia de Failure Injection Testing, seguindo os princípios já elencados, e observar o comportamento do seu ambiente, identificando os pontos de falha, os pontos de lentidão e os pontos sem cobertura de monitoramento/observação (tenho usado esse termo por conta do “Observability” oriundo do inglês). Com isso devem haver os devidos ajustes, seja para corrigir um erro, otimizar uma lentidão ou melhorar a observabilidade.

Pode parecer um pouco intimidador rodar um Chaos Egineering no seu ambiente, mas isso pode proporcionar um aumento no grau de confiabilidade (Reliability) do seu ambiente produtivo. E claro, isso deveria ser feito em ambientes maduros no ciclo de vida de uma aplicação/ambiente, pois o mote principal é identificar comportamentos inesperados, aqueles que não foram levantados no mapeamento de requisitos não-funcionais e quem sabe até identificar algum tipo de inconsistência funcional fruto das falhas injetadas de propósito no ambiente.

Caso seu grau de maturidade não seja tão alto pode-se optar por imputar falhas em momentos de baixa utilização e por um período muito curto (Minimize os impactos negativos).

Na Netflix chega-se a simular uma falha de toda uma região EC2 da Amazon. Além do já citado Chaos Monkey há também injeção de outras falhas; isso tem feito com que todos os engenheiros de sistema cada vez mais construam serviços/sistemas capazes de lidar com falhas, não importando quais. É busca pela resiliência, pela alta-disponibilidade, o cuidado com a experiência do usuário.

E então, vamos quebrar as coisas em produção de propósito?

* Ronaldo Sales é Bacharel em Ciências da Computação pela Unesp Rio Claro, na Yaman é gerente da Divisão de SRE & Automation Services