Blog/Artigos · Cloud e Plataforma
Experimento por hipótese, estado estável, blast radius controlado, a herança da Netflix e os game days, com fault injection e o AWS FIS.
O salmo diz: ainda que eu ande pelo vale da sombra da morte, não temerei o mal. A frase não é sobre evitar o vale; é sobre atravessá-lo sem medo, porque se conhece o caminho e se confia na proteção. Chaos Engineering é a engenharia dessa confiança. Todo sistema em produção vai enfrentar a falha, o nó que cai, a latência que dispara, a região que some, e a pergunta não é se, é quando. Chaos Engineering se recusa a esperar o vale chegar por acaso, de madrugada, em escala máxima. Ele entra no vale de propósito, em plena luz do dia, com o raio de dano controlado, para descobrir onde o sistema teme antes que o mal real o encontre desprevenido.
Todo diagrama de arquitetura promete resiliência: há redundância, há failover, há réplica em outra zona. E toda promessa de resiliência não testada é uma hipótese, não um fato. A verdade é que ninguém sabe se o failover funciona até ele ser exigido, e o pior lugar para descobrir que não funciona é o incidente real, às três da manhã, com o cliente sofrendo. Chaos Engineering nasce dessa humildade: a resiliência que você acha que tem só vira resiliência que você sabe que tem depois de provada sob falha.
A disciplina foi formalizada nos Principles of Chaos e tem um método científico no coração. Começa pela definição do estado estável, o comportamento normal medido, e não uma sensação. Depois formula uma hipótese, se este componente falhar, o estado estável se mantém. Então injeta a falha na realidade e observa se a hipótese se confirma. Quando ela se confirma, ganha-se confiança comprovada; quando não, encontra-se a fraqueza num ambiente controlado, com o time acordado e atento, e não no escuro do incidente. Chaos não é quebrar por quebrar; é experimentar para aprender.
Quando a hipótese falha, a fraqueza aparece no experimento controlado, com o time atento, e não na madrugada do incidente real.
A diferença entre Chaos Engineering e imprudência tem um nome: blast radius, o raio de dano do experimento. Um bom experimento é desenhado para que, se a hipótese estiver errada e algo quebrar, o estrago fique contido, numa instância, num pequeno percentual de tráfego, num ambiente isolado. Começa-se pequeno, prova-se seguro, e só então amplia-se. Entrar no vale da sombra não é se atirar no abismo; é caminhar com uma corda amarrada, sabendo até onde dá para ir e como voltar.
É por isso que todo experimento sério tem um botão de parar, o abort, que interrompe a injeção e restaura o estado no instante em que o dano ultrapassa o aceitável. E é por isso que o experimento acontece com o time observando, não agendado para rodar sozinho na primeira vez. A maturidade permite rodar caos contínuo e automático depois, quando a confiança já foi construída, mas o primeiro passo em cada novo território é manual, vigiado e com escopo mínimo. Coragem sem corda é temeridade; a corda é o que transforma a travessia do vale em experimento, e não em acidente.
Chaos Engineering saiu da teoria para a prática na Netflix, que ao migrar para a nuvem criou o Chaos Monkey, um programa que desliga instâncias em produção aleatoriamente, em horário de trabalho, de propósito. A lógica era brutal e brilhante: se o sistema tem que sobreviver a falhas de instância, então que ele as enfrente o tempo todo, sob observação, forçando os engenheiros a construir tudo resiliente por padrão, porque o macaco vai derrubar. Depois vieram os outros macacos, o Simian Army, cada um simulando um tipo de falha, até o Chaos Kong, que derruba uma região inteira.
A herança maior da Netflix não foi a ferramenta, foi a cultura. Fazer da falha um evento rotineiro e esperado, e não uma catástrofe rara e traumática, muda a engenharia inteira. Quando a falha de instância acontece o tempo todo por design, ninguém constrói nada que dependa de uma instância específica ficar viva, e o sistema fica resiliente por hábito, não por heroísmo. Hoje o mercado tem ferramentas maduras para injetar falha, incluindo o AWS FIS, o Fault Injection Service, gerenciado e integrado à nuvem, mas o princípio segue o da Netflix: normalizar a falha para que a resiliência deixe de ser aspiração e vire propriedade.
Nem todo caos é automático. O game day é o experimento como exercício coletivo agendado: o time se reúne, escolhe um cenário de falha, injeta e responde como responderia a um incidente real, tudo sob observação e com o abort à mão. O valor do game day vai além de testar o sistema; ele testa as pessoas e o processo. Descobre-se que o runbook está desatualizado, que só uma pessoa sabe fazer o failover, que o alerta que deveria disparar não dispara, que a documentação de recuperação aponta para um sistema que não existe mais.
Essas descobertas são impagáveis porque acontecem no ensaio, não na estreia. O game day transforma o incidente real de estreia aterrorizante em repetição de algo já ensaiado, e essa é a diferença entre um time que entra em pânico e um que executa o que já praticou. A regra que eu levo é simples: um plano de recuperação nunca exercitado é uma hipótese, não um plano. O game day é onde a hipótese vira plano, onde o vale é atravessado em grupo, com luz, para que a travessia real, quando vier, seja um caminho conhecido e não um abismo no escuro.
| Dimensão | O que o game day expõe | Por que importa |
|---|---|---|
| Sistema | o failover que não vira, a réplica que não assume | a resiliência do diagrama era só hipótese |
| Runbook | o procedimento desatualizado ou que aponta para o inexistente | na crise real não haveria tempo de descobrir |
| Pessoas | só um sabe fazer, e ele pode estar de férias | o conhecimento crítico não pode morar numa cabeça |
| Alerta | o sinal que deveria disparar e ficou mudo | sem sinal, a resposta começa tarde demais |
| Processo | quem decide, quem comunica, quem executa | o comando de incidente se ensaia, não se improvisa |
Chaos Engineering amadurece do medo à confiança rotineira. No começo é não testar, torcer para o failover funcionar. Depois vêm os game days manuais, o ensaio agendado com o time. No meio é o experimento automatizado em staging, com hipótese e blast radius. No topo é o caos contínuo em produção, com abort automático e a resiliência verificada o tempo todo, como a Netflix faz. Cada degrau troca um pedaço de fé não verificada por confiança comprovada, e o segredo é nunca pular a corda: sempre começar pequeno em cada novo território.
O caos não vive sozinho: ele testa a confiabilidade que os SLOs definem, exercita os planos de gestão de incidentes, e prova o disaster recovery que só no papel é garantia. É o método que transforma toda promessa de resiliência deste eixo, de multi-zona a multi-região, de hipótese em fato. Atravessar o vale da sombra de propósito, com corda e à luz do dia, é o que permite não temer o mal quando ele chega de verdade, porque o caminho já foi andado, o sistema já provou que aguenta, e o time já sabe o que fazer. A confiança que sobra depois do experimento é a única resiliência que se pode chamar de real.
Chaos Engineering atravessa o vale da sombra de propósito, à luz do dia e com corda, para não temer o mal quando ele chega de verdade. O método é científico, estado estável, hipótese, experimento, e o blast radius controlado com abort é o que separa disciplina de imprudência. A herança da Netflix foi normalizar a falha para a resiliência virar propriedade, e os game days provam que o plano de recuperação é plano, não hipótese. A IA propõe a hipótese e opera a corda. Mas decidir que risco de experimento o negócio aceita correr, e quando ampliar o raio, continua sendo julgamento de quem responde pela confiabilidade.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Cloud e Plataformaתֵּבָה
O desastre vem, e a arca se constrói antes dele, não durante. RTO e RPO definem quanto tempo e quanto dado você aceita perder, e daí saem quatro estratégias, de backup barato a multi-site caro. O plano de DR nunca testado não é plano, é esperança.
Operaçõesחֲצֹצְרֹת
No incidente, a prioridade é restaurar, não achar culpado. Papéis claros, severidade objetiva, comando único e postmortem blameless são o que transformam o caos em processo.
