Na mais recente Conferência Event-Driven Microservices em Amsterdã, Russ Miles afirmou que o maior desafio para um arquiteto é que ele não seja ignorado. Você tem ótimas ideias, como o uso de microserviços acionados por eventos, mas a reação das pessoas muitas vezes é que soa bem, mas é excessivamente complicado para as necessidades em questão. Normalmente Miles recebe essa reação quando sugere que as empresas considerem olhar para sistemas assíncronos orientados a eventos como uma forma de introduzir escala, redundância e tolerância a falhas. As palavras costumam fazer sentido para a empresa, mas com a mesma frequência são ignoradas.
O principal objetivo de Miles em seu trabalho é ter sistemas confiáveis. Confiabilidade para ele é uma medida do que o cliente quer; um sistema que é rico em recursos e sempre em execução. Isso significa que temos duas forças opostas que não coexistem facilmente, especialmente notáveis em sistemas complicados - inovação e mudança contínuas, versus um sistema que está sempre funcionando.
De acordo com Miles, o mais difícil para um arquiteto é fazer com que todos entendam que você está construindo sistemas resilientes, e Miles enfatiza que ele não está apenas falando sobre tecnologia, ele está se referindo a todo o sistema que inclui as pessoas, as práticas e os processos que o rodeiam. Considerando tudo isso, ele considera um pequeno milagre que os sistemas em produção sempre funcionem.
Miles refere-se a John Allspaw para definir resiliência. Se você construir sistemas com muita redundância, replicação, distribuição e assim por diante, você pode estar construindo sistemas robustos. Para Allspaw, resiliência é quando você também envolve pessoas. Da mesma forma, a engenharia do caos está além do uso de ferramentas - é sobre como as pessoas pensam e abordam um sistema.
Para Miles, a engenharia do caos é uma técnica para encontrar falhas antes que elas aconteçam, mas também uma forma de pensar que precisa ser alimentada sempre:
- Nunca deixe uma falha ser desperdiçada. Aprenda com as falhas quando elas acontecem.
- Tenha uma atitude pré-mortem. Você aprende com as falhas, mas é melhor explorar as fraquezas antes que elas ocorram.
- Seja colaborativo; você não realiza experimentos contra outros sistemas. Todos devem saber de antemão e concordar com o que você quer aprender.
- Comece minúsculo com um pequeno experimento. Se o sistema sobreviver, você pode optar por aumentar o escopo.
- Comece a trabalhar manualmente usando seu cérebro. Depois disso, você pode começar a automatizar usando as ferramentas disponíveis.
A coisa mais importante sobre a engenharia do caos para o Miles é que você deve fazer parte da equipe que trabalha no sistema. Você não pode ser alguém que quebra um sistema e depois fica esperando que outras pessoas consertem o problema. Você precisa ser parte da consequencia pelo problema causado e trabalhar com todos como uma equipe para corrigi-lo.
Miles viu empresas que têm um grupo de pessoas que quebram os sistemas para ganhar a vida, mas, em sua experiência, isso não funciona.
Miles aponta que, em sua mente, a engenharia do caos é simples. Existem apenas duas principais práticas para aprender, e ele enfatiza que não há necessidade de nenhum programa de certificação:
- Os dias de jogo, onde você reúne todas as equipes e muda alguma condição na produção em que todos concordaram que pode ser feito, e verifica como lidar com esta situação. Ele observa que os dias de jogo podem ser caros, já que eles tomam muito do tempo da equipe.
- Experimentos automáticos de caos são quando você automatiza os experimentos para poder explorar continuamente e procurar por pontos fracos.
Se você está pronto para começar a trabalhar com engenharia de caos na sua empresa, o primeiro conselho de Miles é não usar o termo. Não fale sobre quebrar coisas; em vez disso, fale sobre os incidentes que aconteceram e o que você pode aprender com eles e melhorar. Ele observa que você está em um loop de aprendizado tentando obter um sistema que gradualmente se torna mais e mais resiliente.
Em um resumo de seus pontos, Miles observou algumas regras do "Chaos Club" que devem ser seguidas:
- Não fale sobre o caos. Os conceitos estão se tornando mais comuns, mas o termo ainda pode afastar as pessoas. Comece a usá-lo quando as pessoas estiverem mais confortáveis.
- Aprenda sem quebrar as coisas. Você está tentando melhorar em todo o sistema sócio-técnicamente, encontrando e lidando com as fraquezas diante dos usuários.
- O caos não deveria ser uma surpresa.
- Se você souber que o sistema vai quebrar, não faça a experiência. Tente consertar as fraquezas que você já identificou antes de tentar encontrar novas fraquezas.
Ao trabalhar com sistemas baseados em eventos e construídos sob microserviços, uma das coisas mais difíceis é fazer com que os desenvolvedores entendam como se tornar um bom cidadão na produção. Isso inclui ter as exposições corretas de endpoint para declarar sua saúde e os pontos de contato certos para dizer se você está certo ou não. Um bom registro de logs é um aspecto importante e uma maneira de melhorar isso é fazer com que os desenvolvedores leiam seus próprios registros de log, por exemplo, durante um dia de jogo em que eles precisam entender o que o sistema fez por meio de seus próprios registros de log.
Ao praticar engenharia de caos, uma vantagem com sistemas originados em eventos é o observabilidade que ele traz. Para Miles, observabilidade significa a capacidade de depurar o sistema em produção sem alterá-lo. Se você está fazendo algum tipo de experimento de caos, a primeira coisa que você quer fazer é depurar o sistema para descobrir o que deu errado, e com um sistema baseado em eventos você tem um sistema de registro de logs, você sabe exatamente o que aconteceu e quando.
Miles concluiu afirmando que, pela primeira vez em sua carreira, há uma boa prática. Para os sistemas complexos e talvez caóticos que construímos hoje, a engenharia do caos é uma técnica para a qual ele quer dizer "apenas faça isto". Faça uma pequena quantidade, manualmente, como o dia de jogo ou o que for melhor para você. Se você se preocupa com a confiabilidade ou a resiliência de seus sistemas, ele acredita que é uma ferramenta para você.