O Teste Caótico introduz o caos no seu sistema para fortalecê-lo. É uma metodologia sólida empregada por gigantes empresariais para evitar interrupções e falhas em todo o sistema.
Você está migrando seu banco de dados. O processo levou meses para tomar forma, centenas de horas investidas na construção de um pipeline de compatibilidade, dezenas de desenvolvedores revisando manualmente os dados, reuniões nos finais de semana para cumprir o prazo. E então, durante a migração, uma oscilação de energia derruba o sistema…
Ninguém poderia ter previsto isso, mas esse pequeno descuido poderia sabotar todo o projeto, ou pior ainda, causar danos irreparáveis ao seu banco de dados.
Os humanos foram projetados para serem cautelosos com o futuro, é uma ferramenta biológica projetada para nos manter vivos diante de novas experiências. Mas mesmo assim, raramente, ou nunca, tendemos a pensar no pior cenário possível.
Mas, nas palavras de Augustus De Morgan, “A primeira experiência já ilustra uma verdade da teoria, bem confirmada pela prática, tudo o que pode acontecer acontecerá se fizermos tentativas suficientes”. Se parece vagamente familiar, é porque De Morgan é frequentemente considerado um dos primeiros a falar sobre a lei de Murphy: “Tudo o que pode dar errado, dará errado”.
Altamente improvável não é impossível
Um amigo meu diz brincando “quando você vai ao vivo, a questão não é isso vai explodir? Em vez de, qual será a cor da explosão?” Brincadeiras à parte, há mais do que um pouco de verdade em suas palavras.
Os ambientes de desenvolvimento muitas vezes tentam recriar ambientes de produção o mais próximo possível da realidade ou vice-versa. Infelizmente, os sistemas informáticos são extremamente voláteis, por isso mesmo a menor diferença pode ter consequências de longo alcance, e isso é apenas a ponta do iceberg.
Os sistemas quebram, as conexões com a Internet têm latência, os servidores travam, os discos rígidos falham, os dados são corrompidos. Essas coisas acontecem e às vezes temos muito pouco controle sobre quando ou como. Lembrar de volta em 2011 quando centenas de usuários perderam seus dados devido a uma falha na AWS?
É provável que aconteça novamente? Não, mas é possível? Sim, e é por isso que os engenheiros sempre projetam sistemas à prova de falhas. Se a NASA não tivesse projetado um dispositivo à prova de falhas, a Apollo 11 teria caído na Lua devido a um erro de computador.
O código de erro 1202 da Apollo significava que o computador de bordo estava sobrecarregado de tarefas. Felizmente, os programadores da NASA previram essa possibilidade e criaram um sistema de backup que reinicializaria rapidamente o computador e liberaria memória para novos cálculos.
Minimizando o tempo de recuperação
A história do pouso na Lua é um excelente exemplo do que os engenheiros modernos chamam de MTTR, minimizando o tempo necessário para se recuperar de uma falha. Se as catástrofes não puderem ser evitadas, então a nossa solução é minimizar o tempo necessário para reativar os sistemas.
Vamos colocar desta forma: imagine que você tem duas empresas concorrentes, a empresa A está passando por diversas interrupções no sistema ao longo do dia, enquanto a empresa B sofreu uma única interrupção. Sem maiores informações, todos gostariam de ser empresa B.
Mas, digamos que o MTTR (tempo médio de recuperação) da empresa A seja algo em torno de 20 segundos, enquanto o da empresa B seja algo em torno de 4 a 6 horas. Se a Empresa A tivesse 20 interrupções ao longo do dia, teria um tempo de inatividade total de 6 a 10 minutos. De repente, a frequência das interrupções do sistema parece muito menos importante.
Como você minimiza o tempo de recuperação? Bem, uma das primeiras coisas a fazer é travar seu sistema propositalmente. Isso é chamado de falha controlada. Embora possa parecer contra-intuitivo, quando você pensa sobre isso, começa a fazer muito sentido.
Em uma falha controlada, você anuncia a data e a hora em que o sistema irá falhar, a falha em si não é revelada, então a equipe precisa diagnosticar o problema e colocar o sistema em funcionamento o mais rápido possível.
Enquanto isso acontece, monitoramos os dados do sistema antes, durante e depois da falha. O objetivo é ajudar no esforço de recuperação, mas também fornece dados para análise e melhoria subsequentes.
Esse tipo de exercício abre portas para novos insights, à medida que a equipe descobre os efeitos de falhas inesperadas no sistema. É uma mudança de perspectiva através da terapia de choque, pois de repente o sistema à prova de falhas revela quem ele realmente é frágil.
Com os insights desses exercícios, você pode criar novos procedimentos com uma compreensão mais clara de suas falhas. Embora o exercício possa ser estressante, o resultado vale a pena. E, francamente, pode ser um dos exercícios mais desafiadores intelectualmente para uma equipe de desenvolvimento.
Entre no teste caótico
Os exercícios de falha controlada são apenas a ponta do iceberg e uma introdução básica aos testes caóticos/engenharia caótica. Em sua essência, os testes caóticos consistem simplesmente em criar a capacidade de causar falhas contínuas, mas aleatórias, em seu sistema de produção.
A Chaotic Engineering foi uma estratégia central da gigante de streaming Netflix. A equipe de engenharia tinha uma grande variedade de “macacos do caos” ou falhas potenciais que poderiam surgir a qualquer minuto, desde latência até uma interrupção mundial do Amazon Web Services.
Essas falhas caóticas, por sua vez, forçam sua equipe a mudar do desenvolvimento defensivo para uma abordagem mais agressiva. Para ser mais preciso, é um método para desenvolver resiliência do sistema e da própria equipe.
Um sistema resiliente tem flexibilidade para se adaptar a circunstâncias catastróficas, por exemplo, uma plataforma de streaming que redireciona o seu tráfego quando uma mudança repentina na latência causa um atraso na transmissão de dados.
Uma equipa resiliente é flexível e de mente aberta, capaz de se adaptar rapidamente e desenvolver novas estratégias à medida que enfrentam problemas imprevistos. As equipes resilientes tendem a ver as emergências como oportunidades de crescimento e adaptação, em vez de temê-las ou sentir-se estressadas.
Resiliência é algo que pode ser construído, tanto em termos de sistema quanto de dinâmica de equipe, e testes caóticos impulsionam essa mentalidade. É um pouco como aqueles exercícios de combate a incêndio que fazíamos quando éramos crianças. Ao simular uma crise, nos acostumamos a ela e aprendemos a manter a calma quando as coisas ficam fora de controle.
Tenha em mente que este método é extremamente exigente para os desenvolvedores e não é recomendado para equipes recém-formadas ou para projetos de pequena escala. Isso é adequado para projetos com muitas peças móveis, nos quais um único bug pode ter consequências abrangentes.
O teste caótico é ativamente recomendado como um dos melhores métodos para avançar em direção à resiliência e ao MTTR e é usado por gigantes de software e engenharia como IBM.
Induza o caos para proteger seu negócio
Construir com o caos pode parecer um oxímoro, mas não se pode negar as evidências. A Netflix é de longe um dos sistemas mais sólidos do planeta, o que é uma prova de quão bons os testes caóticos podem ser quando bem feitos.
