É o caos! Ou... Quase isso.

"Se seu laptop funciona a 10 anos, você presume que basicamente funcionará para sempre. Mas se você tem 1000 laptops, presume-se que eles vão começar a parar de funcionar em breve." - Mikolaj Pawlikowski, um evangelizador da Engenharia do Caos.

"É como uma vacina, que introduz um perigo para se criar imunidade". Provavelmente essa é a frase que melhor resume do que se trata esse tema relativamente novo chamado "Engenharia do Caos", da mesma forma que a imagem de vários micos pulando de galho em galho ou fio em fio, botando a mão em qualquer componente, parece ser bem interessante para se ilustrar o que seria essa técnica.

Tudo começou em 2008 na plataforma de streaming Netflix, quando a empresa decidiu iniciar a migração da sua infraestrutura local para a núvem (atualmente se não me engano a Netflix está quase que por completa na AWS), pois justamente naquele ano em agosto, aconteceu uma falha nos servidores locais impossibiltou o upload de filmes DVD (sim, em 2008 ainda não era o streaming que a gente conhece). A conclusão no Post Mortem foi de que o maior problema eram as bases enormes e seus recursos verticalmente escalados, onde movendo para a nuvem, isso se resolveria com a possibilidade de escalar recursos horizontalmente. Resumo da ópera, a migração demorou muito mais tempo do que o previsto, e os ganhos imaginados não foram lá grandes coisas já considerando o streaming como principal produto da empresa, até porque, naquela época "Cloud" era uma promessa e se hoje ainda temos quedas significativas nos serviços distribuídos rodando em máquinas super potentes, naquela época (até uns 5 anos atrás) as coisas eram piores. Acontece que isso somado a cultura da Netflix e como seus desenvolvedores e engenheiros trabalhavam, de forma bem autônoma e até sem padronização de código, sem normas e técnicas documentadas (diferentemente de empresas como a Google que cria padrões internos, os aperfeiçoa e os propaga) acelerou a busca por uma solução e criação de gerenciamento de criticidade dos sitemas produtivos, e assim surgiu a "Engenharia do Caos".

A primeira coisa criada foi o "Chaos Monkey" (Macaco do Caos), uma aplicação que basicamente, durante um momento aleatório durante o horário de trabalho, ela escolheria aleatoriamente uma instância de algum cluster, e de forma proposital, a desligaria, mas porquê? Bom, na SRE e no DevOps é dito que containers e instâncias morrem e isso acontece, até mesmo em produção, e a ideia era testar a resiliência do sistema em qualquer momento do dia. Melhor isso do que acordar de madrugada para atender chamados (acredite, isso é horrível, eu sei...). Isso evoluiu para aplicações que simulavam a queda de datacenters de uma região inteira da AWS (Chaos Kong), e com o tempo a ideia de Engenharia do Caos foi melhor estabelecida e desenhada, se tornando então uma matéria interessante para engenheiros de sistemas, e de maneira geral, ela foi modelada para ser uma ciência, envolvendo até princípios de Karl Popper em suas premissas e leis.

A ideia dessa ciência é muito interessante pois os sistemas modernos não escalam de forma linear, e a relação entre I/O, processamento, memória e armazenamento às vezes não depende do número de requisições diárias de uma aplicação apenas, nem mesmo se todas as funções forem síncronas. Hoje podemos considerar servidores como um commodity, por isso, fornecedores de serviços de núvem pública estão extremamente em alta, hoje até pequenas empresas com menos produtos e funções estão criando serviços de núvem, portanto, empresas de escala global como o caso da Netflix estão corretas na simulação de falhas catastróficas para garantir o serviço integral ao consumidor, pois, afinal de contas, os SLA's são um pouco desonestos, mas isso é papo para outro momento em um assunto de apenas SRE.