Nora Jones, engenheira sênior de caos na Netflix, falou sobre engenharia de caos no QCon New York 2017. Ela apresentou diferentes estágios na adoção da engenharia de caos e contou histórias sobre suas experiências passadas na Jet e Netflix.
Jones começou explicando a razão por trás da engenharia de caos. Engenharia de caos é sobre abraçar o fato de que falhas são inevitáveis e que cedo ou tarde elas acontecerão. Como Jones disse: computadores são complicados e eles irão falhar.
A maneira estabelecida de garantir a disponibilidade é através dos diferentes métodos de testes: testes unitários, testes de regressão e integração. A chaos engineering acrescenta um novo nível. Alguns consideram que apenas um dos dois grupos é necessário, enquanto Jones afirma que ambos são necessários para alcançar os níveis mais altos de disponibilidade.
Engenharia de caos é sobre fortalecer os sistema através de experimentos. Uma das primeiras ferramentas que abraçou essa filosofia é conhecida como Chaos Monkey (Macaco do Caos), uma ferramenta automática criada para testar a resiliência dos sistemas, desligando alguns servidores de forma aleatória. Apesar do Chaos Monkey ter vários anos de idade, a engenharia de caos começou a emergir com força mais recentemente.
Jones apresentou cinco fases para inserir o caos em uma organização. Cada fase é um aprimoramento da anterior, cobrindo cenários mais específicos e introduzindo novas ferramentas.
A primeira fase é uma pequena introdução do caos. Jones afirma que introduzir caos em uma organização que já é caótica é complicado. O caos induzido por experimentação se torna indistinguível do caos que vem de problemas e interrupções reais.
Então a pergunta se torna: Como começar o caos? Jones recomenda começar criando situações que já acontecem normalmente. Degradações e restarts são opções convenientes para se começar devagar. Por exemplo, restartar um servidor web ou banco de dados que sejam redundantes, reproduz uma falha esperada pela maioria dos sistemas. Começar num ambiente de QA também é recomendado como um jeito de começar devagar.
Jones também enfatizou a adoção através de diferentes fases. Desligar servidores em produção de propósito pode ser visto como uma idéia bem radical, tornando a adoção um tanto delicada.
A segunda fase é sobre causar falhas em cascata. Falhas em cascata são uma cadeia de falhas, começando com a falha de um sistema que resulta na falha de outra e assim por diante. Falhas em cascata costumam ficar imperceptíveis por um longo tempo, até que seja iniciada por um conjunto de circunstâncias incomuns.
Jones descreveu um experimento que ela fez na Jet. Seu time determinou o tipo de falha que eles queriam causar e executaram no ambiente de QA. O resultado foi que uma falha diferente da esperada aconteceu, resultando na indisponibilidade do ambiente de QA por uma semana. O Experimento se mostrou bem sucedido e revelou as potenciais falhas no ambiente de produção, além de enfatizar os benefícios dessa abordagem. Apesar de falhas sempre causarem inconvenientes, desenvolvedores e stakeholders precisam estar cientes de que essas falhas poderiam ser muito mais custosas se tivessem acontecido sem supervisão em um ambiente de produção.
A próxima fase é criar uma biblioteca de injeção de falhas. A biblioteca habilita a injeção do caos diretamente pelo código, permitindo um controle maior sobre experiências caóticas. Jones apresenta uma exemplo de biblioteca escrita em F# disponível no GitHub. O seguinte trecho de código, define uma função que atua como um ponto de entrada para injetar caos:
let chaos (name:string) (shouldChaos:unit -> bool) (chaos:Async) : AsyncFilter<_,_,_,_> = fun (service:AsyncArrow<_,_>) req -> async { if shouldChaos() then printfn "%s" name do! chaos return! service req }
A quarta fase é o caos contínuo com Chaos Automation Platform (ChAP). ChAP é projetado para superar as falhas do FIT, ambos sistemas criados pela Netflix. O objetivo do ChAP é de criar experiências de caos sobre tudo de forma contínua. ChAP tem foco em minimizar o raio de explosão. Concentrar falhas em instâncias dedicadas e adicionar orquestração ao FIT.
A quinta e última fase é injetar o caos em áreas alvo do sistema. Experiência na Jet, lidando com geo-replicação. Altamente dependente do Kafka e com alguns problemas com ele. O time estabeleceu uma lista de cenários específicos ao Kafka onde gostariam de testar o caos. A lição aprendida foi que, como afirmado anteriormente, falhas inseridas pelas experiências com caos são difíceis de serem diferenciadas de falhas regulares. Um ambiente estável é requerido antes de começar a rodar experiências de caos.
Como palavra final, Jones sugere definir a uma estratégia para a adoção da engenharia do caos. Essa estratégia, para ser efetiva, precisa ser adaptada a cultura da empresa. Por exemplo, isso funciona melhor com a adoção forçada ou ao contrário, as pessoas e times precisam ser convencidos.