Sistemas de software são complexos e dinâmicos, e estão cada vez mais distribuídos. A Engenharia de Caos (EC) surge como uma disciplina que formula e testa hipóteses, e analisa os resultados a fim de tornar os sistemas mais resilientes e estáveis. Talvez não seja possível evitar todas as falhas de um sistema, mas a EC vem para ajudar a identificar muitas das fraquezas do sistema antes que elas sejam ativadas por essas falhas.
Injetar um pouco de falha no sistema, ao longo do tempo o tornará mais resiliente. - Nora Jones.
Mas, o que é engenharia de caos e porque utilizá-la? E ainda, como estabelecer uma estratégia, e definir custo e impacto para aplicá-la?
Estas são algumas das questões discutidas por Nora Jones e Wesley Reisz no podcast 'Desenvolvendo, expandindo e amadurecendo a prática de engenharia de caos', gravado para o InfoQ.com.
Nora trabalha como engenheira de software na Netflix, na 'Equipe do Caos'. Ela também é co-autora do livro 'Chaos Engineering - Building Confidence in System Behavior through Experiments' (Engenharia de caos - Construindo Confiança no Comportamento do Sistema através de Experimentos), juntamente com alguns colegas da Netflix.
Apesar de estar na Netflix há menos de um ano, Nora começou a aplicar a EC há alguns anos, na empresa Jet, onde trabalhava em um sistema de segurança doméstica e automação residencial. Durante esse período, ela precisava criar diferentes cenários de falha em sensores, como por exemplo, se você tropeçar no sensor da porta ou da câmera de vídeo, a porta deveria ser fechada? O alarme deveria ser desligado? A ideia era criar diferentes cenários de falha para testar os alarmes.
Naquela época, o sistema da empresa não era estável, caía muitas vezes, e havia muitas chamadas noturnas ao pessoal que estava de plantão. Então, Nora começou a criar diferentes cenários de falha, e tomar nota não apenas dos resultados esperados, mas também registrar os inesperados, e com isso melhorar a confiabilidade do sistema, aumentar a produtividade, e mitigar falhas.
Engenharia de caos ou Testes do caos?
Nora explica que a EC é uma disciplina completa, trata-se de experimentos controlados, não apenas testes. Testes retornam resultados binários como Passou ou Falhou, mas eles não agregam novos conhecimentos . A EC define um método formal para gerar novos conhecimentos, formular hipóteses, executar uma variedade de passos, e analisar os resultados. Se a hipótese não funcionar, você tem que explorá-la um pouco mais.
Uma disciplina bem rigorosa
Como descrito anteriormente, a EC é uma disciplina completa. Ela traz vários benefícios como um todo, mas se não for planejada corretamente e se não houver uma estratégia por trás dela (por exemplo: formular hipóteses e determinar mecanismos de segurança que sustentem a expectativa do cliente), ela pode causar mais mal do que bem.
Assim, baseado em sua experiência na Jet e nas práticas desenvolvidas na Netflix, Nora e sua equipe chegaram à conclusão de que se fosse definido um processo baseado em suas experiências, isso ajudaria muito as pessoas que estão começando com EC a iniciarem com o pé direito.
O que é uma boa hipótese?
É como se fosse um experimento científico, explica Nora. Você formula a hipótese baseada na condição "Se X, então Y", e essa é a base dos experimentos a serem rodados. Você senta com o cliente e pergunta o que ele acha que deveria acontecer sob tais circunstâncias. Se não há a expectativa do serviço se manter resiliente sob tais condições, você tem que ser muito cauteloso, por exemplo rodando esses testes quando os engenheiros estiverem de plantão, e prontos para atender um chamado. Certifique-se também de que a falha pode ser minimizada por um mecanismo de segurança.
Outro bom exemplo é introduzir latência nos serviços, em vez de forçá-los a falhar. Uma hipótese baseada nessa condição seria: "Se falharmos uma chamada do serviço A para o serviço B, esperamos que o gatilho de recuperação seja iniciado." E então deve-se perguntar: o que acontece se o gatilho de recuperação não iniciar?
Ainda outro: "O que acontece se o serviço C, que não é um serviço crítico (tanto quanto sabemos) está fazendo chamadas para o serviço D? Isso afeta o negócio principal da empresa?"
Nora chama essa de hipótese 'surpresa', que é quando você descobre que um serviço que se assumia ser não-crítico, de fato o é.
Essa hipótese faz a gente pensar em como as empresas que têm centenas de microservices categorizados como Suporte níveis 1 e 2 definiram a criticidade desses serviços. Será que isso foi empiricamente testado, ou é apenas um palpite?
Como iniciar a engenharia de caos de forma segura?
Os experimentos devem começar com os objetivos comerciais em mente. Deve-se considerar os indicadores de performance (KPI), o que está monitorando os KPIs, e qual o custo se esses KPIs forem impactados.
Em uma empresa de segurança doméstica, por exemplo, o impacto pode ser que alguém não consiga trancar a própria porta - o que é um alto custo em relação à segurança. Já em uma empresa de comércio eletrônico que está começando, se ocorrer um erro quando um novo cliente tentar adicionar o cartão de crédito, esse cliente pode ser perdido permanentemente. Então, o custo de adquirir o cliente também tem que entrar no planejamento de falhas, exemplifica Nora.
Wesley pergunta como começar a EC para uma aplicação simples de carrinho de compras. Nora responde que como uma engenheira de caos, em termos de interação de componentes, ela injetaria latência ou falha entre chamadas, pois isso seria tão simples como lançar uma exceção aleatória entre dois serviços, ou inserir um time-out no código. Depois, ela perguntaria de onde vêm as chamadas ao carrinho de compras, e injetaria falhas entre essas chamadas originais e as demais requisições desencadeadas em cascata,inserindo essas falhas diretamente no código, em nível de funções ou classes, por exemplo.
Ela, conta ainda onde injetaria a falha:
"Eu classificaria essa aplicação do carrinho de compras como nível de suporte 1, ou um serviço crítico - se ele cair, pode resultar em dólares perdidos para o negócio. Então, eu aconselho começar com serviços de nível de suporte 2, e ver como o carrinho se comporta. Se ele cair, significa que esses serviços de fato eram nível 1, não 2. Você também deve perguntar qual é o maior impacto, onde os problemas estão acontecendo no momento e tentar ir mais fundo. (...)Terminar instâncias para ver se o serviço é resiliente, é um ótimo primeiro passo."
Para empresas já estabelecidas e que possuem uma carteira de clientes, se o sistema apresenta problemas que estão afetando os clientes no momento, é aí que a engenharia de caos deve começar: recriando os cenários de falha para entender como mitigar ou resolvê-los.
Outro ponto importante é começar a EC no ambiente de testes.
"Um dos primeiros experimentos de caos que rodamos derrubou o servidor de testes por uma semana; foi ótimo que não derrubamos o ambiente de produção por todos esse tempo!"
Mas, com o advento dos microservices não dá para reproduzir o mesmo nível e tipo de padrões de tráfego do ambiente de produção em um ambiente de testes. Ainda assim, para quem está começando, é um bom ponto de partida: sempre dá para descobrir alguns problemas e ganhar experiência e confiança no processo. Porém, uma vez que a equipe e o processo tenha amadurecido, é importante realizar os testes em produção também.
Desafios na adoção
Nora explica que a mudança de cultura é a parte mais difícil. As pessoas pensam que para a Netflix é relativamente fácil por ser uma empresa de streaming, então se o teste falhar os clientes continuarão assistindo ao conteúdo. Entretanto, existem empresas de alto custo que estão aplicando a EC também, como por exemplo, bancos (ING, Capital One) e empresas automobilísticas que que estão desenvolvendo carros auto-dirigidos (PolySync, JPL).
Ela conta que principalmente as pessoas da área de negócio ficam muito preocupadas com o custo e segurança - elas temem que os KPI sejam impactados e também que a EC esteja infringindo mais danos do que o necessário.
Mas aí é que entra o ponto chave da EC: causar pequenos danos ao longo tempo para evitar um dano gigantesco no futuro - e diminuir o tempo de gerenciamento de incidentes ou recuperação no futuro.
Engenharia de Confiabilidade do Site (SRE) e Modelo de Maturidade
Sobre a SRE, Nora comenta que as pessoas ainda não estão dando muita atenção a isso, mas conforme os sistemas tornam-se mais distribuídos, a necessidade da EC tende a aumentar, pois não dá para entender e gerenciar todas as interações dos componentes dos sistemas de cabeça. Para um engenheiro de confiabilidade do site, é bom saber que você não vai receber uma chamada de emergência no meio da noite já que possíveis falhas serão automaticamente tratadas.
Quanto ao Modelo de maturidade na Netflix - eles começaram com Chaos Monkey e o Chaos Kong, o que os ajudou a crescer em termos de tecnologia, e com a ferramenta ChAP - uma plataforma para automação da EC para ajudar na adoção dos serviços. A equipe cria os experimentos no ChAP, e o usuário aprova ou rejeita se quer rodar esses experimentos.
Para gerenciar as métricas de negócios, ele usam o Starts Per Second (SPS);
Facilitando a adoção pelas áreas técnica e de negócio
Nora conta que na Jet, eles começaram com pequenas interrupções, então não precisava de muito envolvimento dos engenheiros. Mas às vezes, quando havia um grande lançamento planejado, os gerentes de negócio lhe pediam para desligar os experimentos. Foi aí que ela percebeu que precisava falar mais e mais sobre isso:
"Se os serviços não resistirem à falha e uma simples instância, como eles vão resistir a muitos outros tipos de falhas que podem ocorrer em produção?"
Com o tempo as pessoas foram aceitando, e ninguém mais estava pedindo para desligar os experimentos.
Um outro fator importante, é envolver as pessoas:
"Se você está começando do zero, comunique-se."
Quando for executar sua primeira experiência, reúna os proprietários dos serviços em uma sala de guerra e faça com que todos monitorem os resultados do teste enquanto ele está sendo executado, porque se as coisas começam a dar errado e você não contou a ninguém, as chances de você conseguir o suporte dessas pessoas novamente são muito baixas.
A comunidade EC
Pra fechar, Nora comenta sobre o futuro da comunidade da engenharia de caos. O grupo ainda é pequeno mas está crescendo, e vários eventos começam a surgir. A própria Netflix está organizando uma comunidade de caos, onde as pessoas podem compartilhar suas histórias e experiências - cada vez mais pessoas estão adotando a prática da EC.
No QCon New York, em Junho de 2017, Nora deu a apresentação 'Escolha sua própria aventura: engenharia de caos'; e vem mais por aí! Kolton Andrus vai falar na trilha 'A arte da engenharia de caos', na QCon São Francisco, em Novembro de 2017. Você também pode encontrar o grupo da EC no google, em Chaos Community.