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”.
Efeito Borboleta – via Wikipedia
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 1000 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 (EC2 é o serviço de hospedagem de servidores da Amazon, sendo a região a divisão geográfica do serviço). 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? 🤔
Referência Principal: Ali Basiri, Niosha Behnam, Ruud de Rooij, Lorin Hochstein, Luke Kosewski, Justin Reynolds, Casey Rosenthal, “Chaos Engineering”, IEEE Software, vol.33, no. 3, pp. 3541, MayJune 2016, DOI:10.1109/MS.2016.60
*Por Ronaldo Sales – Bacharel em Ciências da Computação pela Unesp Rio Claro, na www.Yaman.com.br é Gerente da Divisão de SRE & Automation Services.