Chaos Engineering é "Verificação", Não "Destruição"
Quando a Netflix publicou o Chaos Monkey nos anos 2010, o chaos engineering foi recebido como "uma prática radical de destruir ambientes de produção aleatoriamente". O impacto cultural foi grande, mas ao mesmo tempo gerou equívocos — para destruir a produção de propósito, era necessária uma maturidade organizacional que estava fora do alcance da maioria das empresas.
O ponto de chegada em 2026 é claro. Chaos engineering não é "tecnologia de destruição", mas "disciplina de verificação de resiliência", e sua essência é "confirmar cientificamente se um design projetado para tolerar falhas funciona como esperado na prática". Formular uma hipótese, testar em pequena escala, observar e melhorar. Todo esse ciclo de PDCA é o chaos engineering. Enquadrar a prática como uma extensão do TPM (Total Productive Maintenance) e do FMEA (Failure Mode and Effects Analysis) — amplamente usados em empresas japonesas — facilita sua introdução.
Seleção de Ferramentas: Gremlin / LitmusChaos / Chaos Mesh
Em 2026, as principais ferramentas estão divididas em três. O Gremlin é o líder em SaaS comercial, com "controle de Blast Radius (escopo de impacto)" e "condições de Halt" como diferenciais que permitem implantação segura mesmo em organizações sem times de SRE. Dezenas de ataques padrão como latência de rede, pressão de CPU, esgotamento de I/O de disco e falha de zona estão disponíveis prontos para uso, e experimentos podem ser iniciados em poucos cliques via Web UI. É forte em casos onde o chaos engineering é necessário como requisito de conformidade regulatória, como em finanças e telecomunicações.
O LitmusChaos é um projeto CNCF Graduated, um OSS nativo do Kubernetes. Os Chaos Experiments são definidos como CRDs, e experimentos da comunidade podem ser importados do ChaosHub. A integração com GitOps é excelente: combinado com Argo CD, é possível montar um pipeline completo de "declarar experimentos no Git, executar com Argo Workflows, verificar métricas com Prometheus e, em caso de falha, rollback automático". Adequado para organizações com times de SRE maduros.
O Chaos Mesh é um projeto CNCF Incubating originado do PingCAP, especializado em injeção de falhas granulares no Kubernetes. Os CRDs como PodChaos, NetworkChaos, IOChaos, TimeChaos e DNSChaos são ricos, e é particularmente capaz de reproduzir "falhas de baixo nível difíceis com outras ferramentas", como desvio de NTP e envenenamento de DNS. O UX do Chaos Dashboard também é excelente, com curva de aprendizado menor que o LitmusChaos.
Execução no Kubernetes: Modelo de Três Camadas de Experimentos
Em ambientes Kubernetes, operar experimentos em três camadas se tornou o padrão. A primeira camada é o "nível de Pod". Usa-se PodChaos para matar um Pod de um Deployment específico e verificar se o HPA e as funcionalidades de retry/circuit breaker da service mesh funcionam como esperado. O escopo de impacto é mínimo e pode ser executado automaticamente todos os dias.
A segunda camada é o "nível de Node". Usa-se NodeChaos para drenar um nó dentro de uma AZ e verificar se o Pod Disruption Budget e a redistribuição funcionam corretamente. A frequência recomendada é semanal. A terceira camada é o "nível de região/AZ": usa-se NetworkChaos para bloquear a comunicação entre zonas e verificar o failover de configurações multi-AZ. Essa é a escala adequada para um game day trimestral.
Nas equipes de 2026, a primeira e segunda camadas são completamente automatizadas (integradas ao pipeline de CI), e apenas a terceira camada é mantida como game day com intervenção humana. A parte automatizada aciona o LitmusChaos a partir do GitHub Actions ou Tekton, e deve sempre incluir uma condição de halt que "interrompe automaticamente o experimento ao detectar violação de SLO" integrada ao dashboard de SLO.
Verificação de Failover Multi-Região
Para serviços com configuração multi-região, o "game day de troca de região" 1 a 2 vezes por ano se tornou uma prática praticamente obrigatória. O processo tem três etapas. Primeiro, redireciona-se gradualmente o tráfego DNS da região atual para a região secundária (10% → 50% → 100%). Verifica-se a cada etapa se o SLI não degradou, e em caso de degradação, faz-se rollback. Após a migração de 100%, desconecta-se intencionalmente a rede da região atual (partition com NetworkChaos) e observa-se por algumas horas se a região secundária aguenta sozinha.
Os problemas encontrados com frequência nesse game day são: (1) capacidade insuficiente na região secundária (como foi tratada com baixo tráfego no dia a dia, o limite do HPA está aquém do necessário); (2) picos de lag nas réplicas de banco de dados (as réplicas atrasam com a concentração de escritas); (3) restrições regionais de APIs de terceiros (algumas não podem ser chamadas de determinadas regiões, ou os rate limits são mais rígidos). São todos problemas difíceis de prever antecipadamente — sem o game day, eles só se manifestam em um desastre real.
Desafios Culturais em Empresas Japonesas: "Manutenção Programada" vs. "Caos em Produção"
A maior barreira na introdução do chaos engineering não é técnica, mas cultural. As empresas japonesas têm a cultura de "manutenção programada (notificação prévia e parada breve de serviço)", mas há forte resistência a "injetar falhas intencionais em um sistema rodando em produção". Reações de executivos do tipo "O que é isso de destruir a produção?" não são raras.
As três táticas práticas para superar essa barreira são as seguintes. Primeiro, começar com "caos em ambientes não produtivos". Executar PodChaos diariamente em staging e criar a cultura de verificar SLOs antes dos releases. Construir um histórico de 6 meses a 1 ano em um estado em que se pode afirmar "não fazemos em produção".
Segundo, ao introduzir em produção, aproveitar as "janelas de manutenção programada existentes". Executar chaos em pequena escala durante as janelas mensais de manutenção e posicioná-las como "parte da manutenção programada". Isso elimina a necessidade de criar um novo processo de aprovação em nível executivo.
Terceiro, fazer branding do game day como "treinamento". Ao chamá-lo de "simulação de resposta a incidentes" ou "exercício de BCP", ele recebe uma avaliação positiva dos departamentos de gestão de qualidade e auditoria interna. De fato, o game day pode ser usado como base para atender aos requisitos de exercício da ISO 22301 (continuidade de negócios) e dos critérios de segurança do FISC.
Maturidade e Próximos Passos
O Chaos Engineering Maturity Model (proposto por Casey Rosenthal, edição revisada de 2026) define a maturidade do Nível 1 (experimentos ad hoc) ao Nível 5 (produção totalmente automatizada e execução contínua). A maioria das empresas japonesas está na fase de transição do Nível 2 (experimentos periódicos em staging) para o Nível 3 (game day em produção). A migração para o Nível 4 (experimentos automáticos em produção) pressupõe que o trio de SLO, Error Budget e observabilidade esteja completo, e que o multi-window multi-burn-rate mencionado em artigos anteriores esteja funcionando como condição de facto.
Na KGA IT, ao diagnosticar a maturidade de SRE de clientes, projetamos um "roteiro de introdução ao chaos engineering" em unidades de 6 a 18 meses. A ordem para superar as barreiras culturais é mais importante do que a seleção tecnológica — e a escolha entre Gremlin e LitmusChaos é, na verdade, uma discussão para a segunda metade do processo.