9.6 Engenharia do caos e testes de resiliência

Visão geral e motivação

A engenharia do caos é a prática disciplinada de rodar experimentos num sistema para construir confiança na sua capacidade de resistir a condições turbulentas em produção. O nome soa imprudente, e essa é a primeira coisa a desaprender. A engenharia do caos não é quebrar coisas ao acaso e torcer para aprender algo. É o oposto: um método controlado e guiado por hipóteses para injetar falhas realistas, de modo a descobrir fraquezas antes que os seus usuários o façam. Vocês já sabem que o seu sistema vai enfrentar falhas, porque todo sistema real as enfrenta. A única pergunta é se vocês encontram essas falhas numa terça à tarde, com uma reversão pronta, ou às 3 da manhã, na sua hora de maior movimento, sem ideia do que está acontecendo.

Para grandes equipes, isso importa porque a complexidade superou a capacidade de qualquer pessoa de raciocinar sobre ela por inspeção. Um serviço moderno é uma teia de dezenas ou centenas de componentes, cada um com seus tempos limite, novas tentativas, caches e modos de falha, e as interações entre eles produzem um comportamento emergente que nenhum diagrama de arquitetura prevê. Vocês podem revisar o código, desenhar as caixas e ainda assim ser pegos de surpresa quando uma dependência lenta dispara uma tempestade de novas tentativas que derruba um serviço três saltos adiante. A engenharia do caos é como vocês sondam essas interações de modo empírico, para que a sua resiliência seja algo verificado e não presumido.

Os contextos corporativo e governamental elevam as apostas e, cada vez mais, o mandato. Os reguladores financeiros hoje esperam que as empresas testem a resiliência operacional contra cenários severos mas plausíveis e provem que conseguem manter os serviços críticos funcionando durante a interrupção. Os órgãos governamentais rodam exercícios de continuidade de operações para que os serviços públicos essenciais sobrevivam a interrupções, desastres e ataques cibernéticos. Em ambos os mundos, “achamos que vai aguentar” não é uma resposta aceitável a um auditor ou a um cidadão. A engenharia do caos dá evidência. Este capítulo se apoia na engenharia de confiabilidade de sites (capítulo 9.1) e nos padrões de resiliência do capítulo 3.5 e se liga estreitamente à gestão de incidentes (capítulo 9.3) e à recuperação de desastres (capítulo 9.5).

Princípios fundamentais

Construam confiança, não criem caos. O objetivo é a resiliência verificada, não o espetáculo. Todo experimento responde a uma pergunta específica sobre como o sistema se comporta sob estresse.
Definam primeiro o estado estável. Vocês não detectam um problema sem uma definição clara e mensurável de como é o “saudável”.
Formem uma hipótese. Declarem o que esperam que aconteça antes de injetar uma falha. Uma surpresa é um achado. A ausência de uma também é um achado.
Minimizem e contenham o raio de impacto. Comecem pequeno, protejam os usuários reais e ampliem o escopo só à medida que a confiança cresce.
Prefiram a produção, com cuidado. As falhas se comportam de modo diferente sob tráfego, dados e escala reais. Mereçam o direito de testar lá.
Automatizem rumo à verificação contínua. Uma fraqueza que vocês consertam uma vez pode regredir. A resiliência testada continuamente permanece verdadeira.
A falha é uma professora, não um veredicto. Os achados melhoram o sistema. Nunca são motivo para culpar quem rodou o experimento.

Recomendações

Estabeleça os pré-requisitos antes de injetar uma única falha

A engenharia do caos é um multiplicador de força para um sistema maduro e um passivo para um imaturo. Antes de começar, vocês precisam de três coisas no lugar. Primeiro, a observabilidade, isto é, as métricas, logs e rastros que permitem ver o que o sistema está fazendo de fora, porque um experimento que vocês não conseguem observar não ensina nada. Segundo, objetivos de nível de serviço ou uma definição equivalente de saúde em estado estável (capítulo 9.1), para distinguir em tempo real um experimento bem-sucedido de um prejudicial. Terceiro, um caminho rápido e confiável de reversão ou de aborto, para que, no instante em que um experimento ameaça os usuários reais, vocês possam pará-lo e restaurar o serviço normal em segundos. Se vocês não conseguem medir o sistema, definir o seu estado saudável e puxá-lo de volta da beira do abismo, não rodem experimentos de caos ainda. Construam primeiro essas capacidades. Elas se pagam de qualquer jeito.

Defina o estado estável e forme uma hipótese de verdade

Todo experimento começa escrevendo como é o normal em termos mensuráveis: taxa de sucesso das requisições acima de 99,9 por cento, latência do checkout abaixo de 400 milissegundos no percentil 95, profundidade da fila abaixo de um limiar. Essa é a sua definição de estado estável, e deve refletir a saúde visível ao usuário, não o encanamento interno. Depois declarem uma hipótese em linguagem simples: “Se acrescentarmos 300 milissegundos de latência ao serviço de recomendações, a página do produto ainda será renderizada dentro do seu orçamento de latência, porque a página trata as recomendações como opcionais e expira após 200 milissegundos.” Agora vocês têm uma alegação falseável. Quando rodam o experimento, uma de duas coisas boas acontece. Ou o sistema se comporta como previsto e a confiança de vocês é merecida, ou não se comporta e vocês acharam uma fraqueza real a baixo custo, nos seus termos, com engenheiros observando.

Injete falhas realistas, não arbitrárias

As falhas que vocês introduzem devem espelhar as falhas que o sistema de fato sofre. A injeção de falhas, a introdução deliberada de erros para testar como um sistema responde, dá um cardápio tirado de incidentes reais de produção. Injetem latência para simular uma dependência lenta ou um enlace de rede saturado. Injetem erros, devolvendo HTTP 500 ou recusas de conexão, para simular um serviço a jusante com falha. Injetem esgotamento de recursos consumindo CPU, memória, disco ou descritores de arquivo, para ver como o sistema se degrada sob pressão. Injetem falha de dependência tornando inalcançável um banco de dados, cache, fila ou API de terceiros inteiro. Num sistema distribuído, em que os componentes rodam em máquinas separadas e se comunicam por uma rede não confiável, essas são as falhas que dominam as interrupções reais. A latência e a falha parcial, não as quedas limpas, são o que quebra as coisas na prática, então inclinem os experimentos para o meio bagunçado.

Verifique que os seus mecanismos de resiliência de fato funcionam

É aqui que a engenharia do caos justifica o seu lugar. O seu sistema está cheio de mecanismos que deveriam protegê-los: tempos limite que impedem um chamador de esperar para sempre, novas tentativas que disfarçam soluços transitórios, disjuntores que param de martelar uma dependência que falha e failover que troca para um standby quando o primário morre. Esses padrões, cobertos no capítulo 3.5, são a diferença entre um problema contido e uma interrupção em cascata. O problema é que raramente são testados nas condições para as quais existem. Um tempo limite fixado em 30 segundos quando o prazo do próprio chamador é de 2 segundos não faz nada. Uma nova tentativa sem recuo (backoff) transforma um serviço em dificuldade numa manada em debandada. Um disjuntor nunca exercitado pode estar mal configurado e nunca disparar, ou disparar sem parar. Os experimentos de caos são como vocês confirmam que cada um deles se comporta como projetado quando a falha contra a qual protegem de fato chega. Presumam que todo mecanismo de segurança não testado está quebrado até um experimento provar o contrário.

Comece com game days antes de automatizar

Não comecem com uma plataforma automatizada que injeta falhas continuamente. Comecem com um game day: um exercício agendado e prático em que uma equipe se reúne, escolhe um cenário, injeta uma falha num ambiente controlado e observa em conjunto. Antes até disso, um exercício de mesa (tabletop), em que vocês conversam sobre um cenário num quadro branco sem tocar no sistema, revela lacunas em runbooks, alertas e propriedade com risco quase nulo. Os game days são a sua rampa de entrada. Constroem o músculo de formar hipóteses, conter o raio de impacto e ler o sistema sob estresse e constroem a confiança com a liderança e as equipes vizinhas de que vocês precisarão antes que alguém deixe rodar experimentos em produção. Também fortalecem diretamente a resposta a incidentes, porque as habilidades são as mesmas que os seus engenheiros de sobreaviso usam durante um incidente real (capítulo 9.3). Rodem os primeiros game days em staging, depois em produção em horários tranquilos com um raio de impacto pequeno e depois expandam.

Contenha o raio de impacto deliberadamente

A prática de segurança mais importante é limitar o dano potencial de cada experimento. Comecem pelo menor escopo que possa ensinar algo: uma instância, um por cento do tráfego, uma dependência não crítica, uma zona de disponibilidade. Definam as condições de aborto antes de começar, liguem-nas às métricas de estado estável e façam de parar o experimento uma única ação que qualquer pessoa observando possa disparar. Prefiram rodar em horário comercial, quando a equipe está alerta e escalada, não de madrugada, quando uma surpresa vira um incidente sem ninguém olhando. Ampliem o raio de impacto só quando experimentos menores rodaram limpos e a confiança de vocês é genuinamente maior. A disciplina da contenção é o que separa a engenharia do caos de uma interrupção que vocês mesmos causaram.

Evolua rumo à verificação contínua e automatizada da resiliência

Game days ocasionais acham fraquezas, mas os sistemas mudam todo dia, e uma correção do trimestre passado pode regredir em silêncio. O estado final maduro é a verificação contínua: um conjunto curado de experimentos de resiliência que rodam automaticamente, num pipeline ou numa agenda, de modo que uma regressão num tempo limite, numa política de novas tentativas ou num caminho de failover seja pega em dias e não durante a próxima interrupção real. É aqui que ferramentas como o Chaos Monkey da Netflix, que encerra instâncias aleatoriamente em produção para forçar os engenheiros a construir serviços que toleram a perda de instâncias, ganharam sua reputação. Automatizem apenas os experimentos que vocês já entendem e em que confiam por execuções manuais. O caos contínuo por cima de um sistema imaturo é um jeito de gerar incidentes, não confiança.

Ligue os experimentos à recuperação de desastres e ao aprendizado com incidentes

A engenharia do caos não vive sozinha. Os cenários maiores e mais raros, perder uma região inteira, fazer failover de um banco de dados, restaurar a partir de backup, pertencem aos testes de recuperação de desastres (capítulo 9.5), e um game day costuma ser o melhor veículo para exercitar esses planos em vez de deixá-los apodrecer como documentos não testados. Do outro lado, todo experimento que revela uma fraqueza deve alimentar o mesmo ciclo de aprendizado de um incidente real (capítulo 9.3): um relato sem atribuição de culpa, uma correção acompanhada e um experimento de acompanhamento para confirmar que a correção se sustenta. Quando os achados do caos, os exercícios de recuperação de desastres e as retrospectivas de incidentes fluem todos para um único backlog de trabalho de resiliência, vocês obtêm retornos compostos em vez de exercícios pontuais dispersos.

Compromissos: prós e contras

Decisão	Prós	Contras
Testar em produção	Tráfego, dados e escala reais. Os achados são verdadeiros	Risco aos usuários se a contenção falhar. Exige maturidade
Testar apenas em staging	Seguro, baixas apostas, fácil de começar	Perde o comportamento do mundo real. Falsa confiança
Game days manuais	Constroem habilidades e confiança. Baixo custo de ferramentas	Pouco frequentes. Os achados podem regredir sem ser notados
Caos automatizado contínuo	Pega regressões depressa. Escala	Exige primeiro ferramentas e observabilidade maduras
Raio de impacto amplo	Revela grandes fraquezas sistêmicas	Alto risco. Um erro vira incidente
Raio de impacto estreito	Seguro e controlável	Pode perder falhas emergentes entre serviços

A tensão central é entre realismo e segurança. Os achados que vocês mais querem vêm da produção, porque é o único lugar onde o sistema enfrenta tráfego, dados e escala reais, mas a produção é exatamente onde um experimento mal feito prejudica os usuários. A solução não é escolher um lado. É conquistar o caminho até a produção aos poucos: provar os pré-requisitos, ensaiar em staging, depois rodar experimentos pequenos e bem contidos em produção, com condições de aborto ligadas a métricas ao vivo, e ampliar o escopo só conforme a evidência se acumula. A outra tensão recorrente, manual versus automatizado, se resolve do mesmo modo com o tempo. Comecem manual para construir entendimento e confiança e depois automatizem os experimentos em que passaram a confiar, para que a resiliência verificada uma vez permaneça verificada.

Perguntas para discutir com sua equipe

Estamos de fato prontos para rodar experimentos de caos, e como saberíamos? É tentador começar a injetar falhas porque soa sofisticado, mas a engenharia do caos num sistema inobservável, sem definição clara de saúde e sem reversão rápida é só indisponibilidade autoinfligida. Levem evidências honestas a esta discussão: vocês conseguem ver taxas de sucesso e latência das requisições em tempo real, têm uma definição combinada de estado estável e conseguem abortar um experimento e se recuperar em segundos? Para uma grande equipe, a resposta costuma diferir por serviço, então o resultado útil é um patamar de prontidão que um serviço precisa cruzar para ser elegível a experimentos. Em contextos regulados, esse patamar de prontidão vale também como um controle que vocês podem mostrar a um auditor. Se a resposta honesta é que vocês não estão prontos, o trabalho de caos mais valioso que vocês podem fazer neste trimestre é construir as capacidades de observabilidade e de reversão que os deixam prontos.
Qual é a nossa política de raio de impacto, e quem tem a autoridade de parar um experimento? Todo experimento de caos carrega algum risco para os usuários reais, e a diferença entre um achado valioso e um incidente que vocês causaram é quão bem o conteniam. Conversem sobre os limites concretos: que fração do tráfego, quantas instâncias, que ambientes, que horários do dia e que limiares de métricas abortam automaticamente a execução. Decidam de antemão quem acompanha cada experimento e quem guarda a chave de emergência de ação única, porque um experimento que ninguém consegue parar depressa não está contido. Para uma grande organização, essa política é o que permite que muitas equipes experimentem sem que alguma derrube por acidente uma dependência compartilhada. A resposta deve ser escrita, combinada com as equipes cujos serviços vocês podem afetar e tratada como pré-condição para rodar qualquer coisa em produção.
Quais mecanismos de resiliência acreditamos que nos protegem, e algum dia os testamos de fato? A maioria dos sistemas está cheia de tempos limite, novas tentativas, disjuntores, caches e caminhos de failover que foram configurados uma vez e nunca exercitados sob a falha para a qual existem. Façam uma lista dos mecanismos com que contam e perguntem, para cada um, quando foi verificado pela última vez que funciona sob uma falha injetada de verdade. A consideração contrária é o tempo: verificar cada mecanismo custa esforço de engenharia, e sempre há um prazo de funcionalidade. Levem a contraevidência a essa objeção, ou seja, o custo de uma interrupção passada que um disjuntor funcionando ou um tempo limite correto teria contido. A resposta deve transformar uma lista reconfortante de proteções presumidas num backlog priorizado de experimentos, começando pelos mecanismos cuja falha mais doeria.
O que precisa ser verdade antes de rodarmos um experimento em produção e não em staging, e quais serviços já mereceram esse direito hoje? Os achados que vocês mais querem vêm da produção, porque é o único lugar onde o sistema encontra tráfego, dados e escala reais, mas a produção também é o único lugar onde um experimento mal feito prejudica usuários de verdade. Para uma grande equipe, a realidade honesta é que serviços diferentes estão em níveis diferentes de prontidão, de modo que uma regra uniforme de “nenhum caos em produção” desperdiça o melhor aprendizado enquanto um “sim” uniforme convida a interrupções autoinfligidas. Levem evidências por serviço: a qualidade da sua observabilidade, se o estado estável é definido e alertável, quão rápida é a reversão e o histórico de experimentos limpos em staging que justificaria promovê-lo. Em contextos corporativos e governamentais, liguem o portão de produção a um controle documentado que nomeie quem aprova a promoção e que condições de aborto estão ligadas a métricas ao vivo, para que o auditor veja uma decisão deliberada e evidenciada e não uma equipe improvisando com usuários reais.
Quando um experimento de caos revela uma fraqueza, para onde vai esse achado, e como evitamos que apodreça sem ser tocado? Um programa que descobre fraquezas mas nunca as conserta é pior que nenhum programa, porque queima esforço, erode a confiança e ensina às pessoas que os experimentos são teatro. A pressão contrária é sempre o roteiro de funcionalidades: uma correção de resiliência raramente parece tão urgente quanto o próximo lançamento até a interrupção que ela teria evitado de fato chegar. Levem à discussão o estado atual do seu backlog de resiliência: quantos achados de caos estão abertos, quão velho é o mais antigo e se os achados de experimentos, exercícios de recuperação de desastres e retrospectivas de incidentes fluem para uma fila compartilhada ou se espalham pelas equipes. Combinem quem é dono de cada correção e quem roda o experimento de acompanhamento que confirma que ela se sustenta. Para uma organização grande ou regulada, nomeiem o fórum que revisa o backlog numa cadência fixa e tem a autoridade de priorizar uma correção de resiliência sobre uma funcionalidade, porque um achado que ninguém responde por fechar é um risco que vocês apenas documentaram e não removeram.
Estamos prontos para automatizar algum dos nossos experimentos em verificação contínua, e quais especificamente? Os game days ocasionais acham fraquezas, mas os sistemas mudam todo dia e uma correção do trimestre passado pode regredir em silêncio, então o estado final maduro é um conjunto curado de experimentos que rodam automaticamente e pegam regressões em dias. O perigo é automatizar cedo demais: o caos contínuo por cima de um sistema imaturo e com observabilidade fraca gera incidentes mais depressa que percepção. Levem a lista de experimentos que vocês rodaram manualmente vezes suficientes para confiar por completo, os controles de raio de impacto e as condições de aborto que os governariam sem supervisão e o monitoramento que pegaria uma execução automatizada dando errado às 3 da manhã quando ninguém está olhando. Para uma grande empresa ou agência pública, pesem o escrutínio adicional que a injeção de falhas sem supervisão convida: a aprovação da gestão de mudanças, o rastro de auditoria que cada execução automatizada precisa deixar e a responsabilização clara por um experimento agendado que coincide com um incidente real. Automatizem apenas os experimentos que vocês já entendem e mantenham o resto manual até ganharem a mesma confiança.

Perspectiva por setor

Startup. Velocidade e sobrevivência dominam, então não gastem nada numa plataforma de caos. Rodem um único game day de noventa minutos em staging contra a única dependência cuja falha de fato mataria vocês, em geral pagamentos, autenticação ou o repositório de dados primário. Injetem a falha com um proxy tosco ou um processo morto, vejam o que quebra, consertem o tempo limite ou o plano alternativo que faltava e sigam em frente. O ponto todo é pegar a interrupção óbvia e autoinfligida por pouco antes que um cliente a pegue, não construir uma disciplina que vocês não conseguem manter com equipe.

Pequena empresa. Sem especialista em confiabilidade e com orçamento apertado, tratem o teste de resiliência como um exercício periódico e deliberado e não como um programa que se mantém com equipe. Apoiem-se nos recursos de injeção de falhas que o seu provedor de nuvem ou as ferramentas gerenciadas já incluem em vez de comprar uma plataforma dedicada e concentrem os experimentos no punhado de dependências que um cliente notaria. Enquadrem como seguro: uma tarde gasta confirmando que os backups restauram e que o checkout se degrada com elegância é muito mais barata que a interrupção que prova que não.

Grande empresa. O problema é coordenar muitas equipes contra dependências compartilhadas em escala, então padronizem o patamar de prontidão, a política de raio de impacto e a ligação das condições de aborto que toda equipe precisa cruzar antes de rodar em produção. Encaminhem os achados de caos, os exercícios de recuperação de desastres e as retrospectivas de incidentes a um único backlog de resiliência com propriedade clara e usem game days trimestrais mais um conjunto curado de experimentos automatizados para satisfazer com evidências as expectativas de resiliência operacional. Governem quem pode afetar um serviço compartilhado para que o experimento de nenhuma equipe derrube a infraestrutura de que outras dependem.

Governo. As regras de contratação, a transparência e a prestação de contas públicas moldam o trabalho. Os mandatos de continuidade de operações muitas vezes exigem exercícios regulares de qualquer modo, então rodem-nos como game days ao vivo que produzam achados genuínos e não como um fichário que ninguém abre, e mantenham um rastro de auditoria de cada experimento, seu raio de impacto e seu resultado. Onde ferramentas de injeção de falhas forem contratadas, exijam que se encaixem nas regras de segurança e de tratamento de dados e reservem os experimentos em produção nos serviços voltados ao cidadão para janelas aprovadas e rigidamente contidas. A evidência que um programa de caos produz é exatamente o que um órgão de supervisão ou auditor espera ver.

Exemplos

Startup. Uma startup de quinze pessoas roda um aplicativo web sobre um punhado de serviços e depende de uma API de pagamentos de terceiros. Ninguém tem tempo para uma plataforma de caos, então a equipe roda um game day de noventa minutos em staging. Formam uma hipótese: se a API de pagamentos começar a devolver erros, o checkout deve mostrar uma mensagem clara de nova tentativa e enfileirar o pedido em vez de cair. Injetam respostas 500 com um proxy simples e descobrem que o frontend trava indefinidamente porque a chamada do cliente não tem tempo limite. Acrescentam um tempo limite e um plano alternativo amigável, reexecutam o experimento para confirmar a correção e escrevem uma nota de dois parágrafos num documento compartilhado. Custo total: uma tarde e um bug muito real pego antes de um cliente tropeçar nele.

Grande empresa. Um banco global precisa demonstrar resiliência operacional aos reguladores contra cenários severos mas plausíveis. Sua equipe de confiabilidade roda um programa de game days trimestrais mais um conjunto de experimentos automatizados em produção. Um cenário faz o failover do banco de dados primário de transações para o standby numa janela de baixo tráfego, com um raio de impacto rigidamente contido e condições de aborto atreladas à taxa de sucesso das transações. A primeira execução revela que um serviço de reconciliação a jusante tem uma política de novas tentativas sem recuo, produzindo um pico de carga que atrasa a recuperação bem além do objetivo de tempo de recuperação do plano de recuperação de desastres (capítulo 9.5). O achado vai para o mesmo backlog das retrospectivas de incidentes, a política de novas tentativas é consertada com recuo exponencial e um experimento de acompanhamento confirma que o failover agora termina dentro da meta. Todo o exercício vira evidência para o regulador.

Governo. Uma agência nacional que opera um portal de benefícios voltado ao cidadão é obrigada a manter a continuidade de operações durante interrupções. Em vez de tratar o plano de continuidade como um fichário que ninguém abre, a agência roda um exercício anual de continuidade como um game day ao vivo. A equipe simula a perda de um data center primário e percorre o failover para um site secundário, enquanto, separadamente, injeta latência numa dependência de verificação de identidade para ver se o portal se degrada com elegância. Descobre que uma lacuna de monitoramento não testada deixou a equipe de sobreaviso cega à lentidão do serviço de identidade, de modo que os alertas dispararam tarde. A agência fecha a lacuna de observabilidade, atualiza seus runbooks e agenda o mesmo exercício para o ano seguinte, transformando uma exigência de conformidade em resiliência genuína e testada para um serviço público crítico.

Justificativa de negócio: motivações, ROI e TCO

O retorno da engenharia do caos vem das interrupções que nunca acontecem. Uma única grande interrupção de um serviço grande pode custar de dezenas de milhares a milhões em receita perdida, penalidades regulatórias, trabalho de remediação e dano à reputação que persiste muito depois de o serviço ser restaurado. Os experimentos de caos convertem essas surpresas imprevisíveis e caras em achados baratos e agendados que vocês consertam no seu próprio ritmo, com engenheiros observando e uma reversão pronta. Achar um tempo limite quebrado durante um game day controlado custa uma tarde. Achá-lo durante um incidente real custa uma interrupção, uma correria geral e a confiança dos usuários. A aritmética favorece o game day por larga margem.

O custo total de propriedade é modesto assim que os pré-requisitos existem, porque a engenharia do caos reutiliza os investimentos em observabilidade, alertas e reversão de que vocês precisam de qualquer jeito. Os custos honestos são o tempo de engenharia para rodar os experimentos, algumas ferramentas para injetar falhas e conter o raio de impacto e o trabalho cultural de deixar a liderança à vontade com a introdução deliberada de falhas. Esta última é a barreira real, e o caminho para vencê-la é começar em staging, mostrar achados que se traduzam em dinheiro ou risco e deixar alguns experimentos contidos em produção construírem confiança. Para defender o caso junto à liderança, enquadrem a engenharia do caos como um seguro que vocês conseguem medir: apresentem o custo dos incidentes recentes, mostrem quais deles um experimento de resiliência teria pego e proponham um programa que começa pequeno e se expande só à medida que se prova. Em contextos regulados e do setor público, acrescentem o ângulo de conformidade, porque os testes de resiliência operacional e os exercícios de continuidade são cada vez mais esperados, e um programa de caos é como vocês satisfazem essa expectativa com evidência e não com papelada.

Antipadrões e armadilhas

Caos sem observabilidade. Injetar falhas num sistema que vocês não conseguem ver é chutar com passos extras: vocês causarão dano e não aprenderão nada.
Sem definição de estado estável. Sem uma medida combinada de saúde, vocês não conseguem dizer se um experimento revelou um problema ou o causou.
Sem hipótese. Quebrar coisas ao acaso não é engenharia do caos. É vandalismo com nome chique e sem achados.
Raio de impacto sem contenção. Pular os experimentos pequenos e seguros e ir direto para a falha em toda a produção transforma um teste numa interrupção autoinfligida.
Sem caminho de aborto. Um experimento que vocês não conseguem parar na hora não é um experimento. É um incidente à espera de um gatilho.
Automatizar cedo demais. O caos contínuo por cima de um sistema imaturo gera incidentes mais depressa que percepções.
Achados que não levam a lugar nenhum. Descobrir uma fraqueza e nunca consertá-la desperdiça o exercício e erode a confiança em todo o programa.
Culpa depois de um experimento ruim. Punir o engenheiro que rodou um experimento que revelou uma falha real garante que ninguém rode o próximo.

Modelo de maturidade

Nível 1, Iniciar: A resiliência é presumida, não testada. As falhas são descobertas em produção durante incidentes reais. Não há game days, nem injeção de falhas, e muitas vezes nem uma definição clara do que é saudável. A equipe aprende sobre suas fraquezas do jeito difícil, uma interrupção por vez.
Nível 2, Desenvolver: A equipe roda game days ocasionais, em geral em staging, com um cenário definido e uma hipótese. O estado estável é definido para alguns serviços-chave e existe observabilidade básica. Os achados são capturados e alguns são consertados, mas a prática é inconsistente entre as equipes e depende de campeões individuais e não de um método estabelecido.
Nível 3, Padronizar: Os experimentos de caos são uma prática documentada e de toda a organização, com políticas de raio de impacto, condições de aborto e critérios de prontidão impostos, que um serviço precisa cruzar antes de experimentar em produção. Os experimentos rodam em produção sob condições controladas, os achados fluem para um backlog compartilhado de resiliência ao lado das retrospectivas de incidentes e dos exercícios de recuperação de desastres e os mecanismos de resiliência são verificados e não presumidos. Toda equipe segue o mesmo manual.
Nível 4, Gerenciar: O programa é medido e controlado com dados em relação a linhas de base. Vocês acompanham a cobertura de resiliência (quais serviços críticos e quais mecanismos, como tempos limite, novas tentativas, disjuntores e failover, foram verificados sob uma falha injetada de verdade e há quanto tempo), a taxa em que os experimentos revelam achados, o tempo médio para fechar um achado de resiliência e com que frequência um mecanismo antes verificado regride. Essas métricas são revisadas numa cadência fixa, a promoção à produção é condicionada a evidências e não a opinião e os experimentos são priorizados pelo risco medido dos mecanismos ainda não verificados.
Nível 5, Orquestrar: Um conjunto curado de experimentos roda de forma contínua e automática, pegando regressões em dias, e o programa se adapta conforme o sistema e seu quadro de risco mudam. A engenharia do caos é integrada em toda a organização com os pipelines de entrega, o aprendizado com incidentes e os testes de recuperação de desastres, de modo que os novos serviços herdam a verificação de resiliência por padrão. A resiliência é uma propriedade continuamente verificada do sistema, e a liderança trata o programa como gestão de risco padrão, refinada com base em evidências, e não como uma iniciativa especial.

Ideias para discussão

Como vocês decidem qual serviço da organização merece primeiro o direito de rodar experimentos de caos em produção, e o que precisa ser verdade antes?
Quando um experimento de caos revela uma fraqueza séria, quem é dono da correção, e como vocês evitam que esse achado fique parado num backlog?
Onde fica a linha entre um experimento de caos, um exercício de recuperação de desastres e um game day no seu contexto, e a distinção chega a importar para como vocês os planejam?
Como vocês convenceriam um executivo cético de que injetar falhas deliberadamente na produção é mais seguro que o status quo de esperar por interrupções reais?
Qual é o primeiro experimento menor e mais valioso que a sua equipe poderia rodar no mês que vem, e o que impediria vocês de rodá-lo?
Como o teste de resiliência deve diferir entre um serviço público voltado ao cidadão, com mandato de continuidade, e uma ferramenta corporativa interna com poucos usuários?

Principais conclusões

A engenharia do caos é experimentação disciplinada e guiada por hipóteses para construir confiança na resiliência, não quebra aleatória.
Estabeleçam observabilidade, uma definição de estado estável e uma reversão rápida antes de injetar uma única falha.
Injetem falhas realistas (latência, erros, esgotamento de recursos, falha de dependência) e usem-nas para verificar que tempos limite, novas tentativas, disjuntores e failover de fato funcionam.
Comecem com exercícios de mesa e game days, contenham o raio de impacto deliberadamente e conquistem o caminho até a produção e a automação.
Liguem os experimentos aos testes de recuperação de desastres (capítulo 9.5) e ao aprendizado com incidentes (capítulo 9.3) para que os achados se componham num único backlog de resiliência.
Tratem os achados sem atribuição de culpa e consertem-nos. Um experimento cuja lição fica sem resposta é pior que nenhum experimento.

Referências e leitura complementar

Casey Rosenthal, Nora Jones, Chaos Engineering: System Resiliency in Practice
Russ Miles, Learning Chaos Engineering: Discovering and Overcoming System Weaknesses Through Experimentation
Mikolaj Pawlikowski, Chaos Engineering: Crash Test Your Applications
Ali Basiri et al., Chaos Engineering (IEEE Software, 2016)
Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, Site Reliability Engineering: How Google Runs Production Systems
Michael T. Nygard, Release It! Design and Deploy Production-Ready Software
Principles of Chaos Engineering, principlesofchaos.org