De um Experimento Único a Chaos Contínuo em Escala

Um ChaosEngine aplicado manualmente uma vez não vira um programa só por ser executado com mais frequência. Quatro coisas mudam. Primeiro, você encadeia falhas em cenários. O Litmus roda experimentos de chaos baseados em workflows do Argo, que sequenciam múltiplas falhas mais probes em uma única execução, por exemplo matar um pod e depois adicionar latência de rede, enquanto uma probe garante que o SLO se mantém o tempo todo. O ChaosCenter vira o control plane, e no Litmus 3.x você instala a infraestrutura de chaos (os agentes delegate) em cada cluster alvo e conduz as execuções de forma centralizada. Segundo, você coloca as definições sob GitOps. Guarde o ChaosEngine, o workflow e o YAML das probes em um repositório e faça o deploy com Argo CD, para que o chaos seja revisado, versionado e reprodutível em vez de aplicado via kubectl a partir do laptop de alguém. Terceiro, você agenda e cria gates. Rode experimentos em um cron com um ChaosSchedule para detecção contínua de drift, e integre-os ao seu pipeline de entrega como um gate de resiliência, em que uma queda no probeSuccessPercentage bloqueia a promoção. Reserve GameDays estruturados para os grandes cenários multi-time. Quarto, você observa. Exporte métricas de chaos para o Prometheus, sobreponha eventos de chaos nos seus dashboards de golden signals no Grafana, e use uma promProbe como auto-halt, para que um SLO em chamas encerre a execução e reverta a falha. O que eu faria diferente em escala é, em grande parte, uma questão organizacional: aplicar política de raio de impacto e RBAC via admission control para que ninguém consiga rodar com litmus-admin, dar a cada time um escopo por namespace, acompanhar uma pontuação de resiliência por serviço ao longo do tempo para mostrar a evolução à liderança, e tratar todo achado de chaos como um incidente com dono e correção, em vez de um dashboard que ninguém lê. O objetivo é capturar regressões automaticamente, não depender de heroísmo.