Performance

Engenharia do caos: a harmonia do desastre

Anisbert Suárez Batista

• 7 min read
Engenharia do caos: a harmonia do desastre

Como a computação em nuvem, os sistemas distribuídos e os microsserviços ocupam o centro das decisões arquitetônicas das empresas de software, nossos sistemas são mais complexos e as fragilidades sistêmicas são mais frequentes. Nesse sentido, garantir a confiabilidade das soluções, em todos os cenários possíveis, é um desafio.

Uma das disciplinas que nos últimos tempos tem se fortalecido no desenvolvimento de software para atacar esse problema é a Chaos Engineering ou Engenharia do caos, que propõe que nós mesmos quebremos nossas soluções de software para entender se elas se comportam adequadamente em situações estressantes.

A popular Lei de Murphy afirma: "Se algo pode acontecer, acontecerá", então temos que nos preparar para isso. Não vamos esperar por incidentes para aplicar padrões de resiliência ou aplicá-los bem em nossos sistemas de software para evitar que cronogramas produtivos falhem e usuários tenham uma experiência ruim.

Se nós mesmos experimentarmos as diferentes situações que tornam nossa infraestrutura ou arquitetura fraca, podemos tomar as medidas necessárias para fortalecê-las.

Vamos adicionar latências aos serviços para ver se os timeouts estão bem definidos; vamos desligar microsserviços não essenciais para ver se continuamos a oferecer um serviço através daqueles que são essenciais no fluxo de negócios; vamos estressar a CPU ou a RAM para ver se nossa infraestrutura responde conforme definimos em nossas políticas de dimensionamento ou se os circuit breakers são ativados devido a erros do tipo 5XX, apenas para citar alguns exemplos.

A origem do caos


A Engenharia do Caos não é nova. Surgiu em 2010 a partir de iniciativas da Netflix durante a migração da infraestrutura física para a nuvem (Rosenthal, & Jones, 2020). Apesar do exposto, muitas empresas ainda estão céticas e não a incorporam em seu conjunto de ferramentas para garantir a confiança de suas soluções, pelo quão intimidante pode ser para o negócio se não for realizada com responsabilidade e planejamento adequado. Por isso, é importante aprender com as lições aprendidas ou boas práticas de quem já padronizou testes de resiliência em seu know-how.

Felizmente, essa perspectiva está mudando. O suporte tecnológico de ferramentas comunitárias e licenciadas tem proporcionado amadurecimento e profissionalismo. Muitas funções o incorporaram em seu conjunto de competências de valor, como DEVOPS, SRE (Engenharia de Confiabilidade do Local), engenheiros de desempenho ou até funções (muitas empresas criaram posições diretas para engenheiros de caos).

A harmonia do desastre


Com a evolução da disciplina, foram definidos e refinados diversos princípios da Chaos Engineering, que estimulam o planejamento correto, mitigando riscos e ganhando objetividade. Esses princípios são declarados abaixo (Rosenthal, & Jones, 2020):

1) Constrói uma hipótese sobre o comportamento do estado estacionário

Antes de tudo, é importante entender o que é considerado um “estado estacionário”, definido como o comportamento normal das métricas mensuráveis ​​do sistema, sejam elas de desempenho ou de negócios.

Ou seja, quais são os valores esperados de latência, taxa de erros, consumo de CPU, taxa de requisições processadas, taxa de vendas geradas, taxa de sessões abertas em um período de tempo ou condições específicas, só para citar alguns exemplos. Propõe-se do ponto de vista de que serão iguais tanto no grupo de controle quanto no grupo experimental que levamos para validar.

Quando se realizam exercícios de experimentação para conhecer as condições atuais do nosso sistema, devemos partir da definição da hipótese que queremos validar. É definido como positivo com base no estado estacionário. Se validarmos, podemos dizer que estamos diante de uma solução confiável e se o experimento fornece argumentos para refutá-la, então encontramos um comportamento a investigar que pode ser uma oportunidade de melhoria, aprendendo sobre nosso sistema ou algum propriedade que não sabíamos.

Uma hipótese surge em duas partes fundamentais: a variável independente e a dependente, onde a primeira seria aquela que geramos para avaliar o resultado e a dependente seria o resultado esperado (Sampieri, 2007).

Um exemplo de hipótese de um experimento de Engenharia do Caos muito comum é: Se eu gerar uma latência de 500 ms para o microsserviço X, o serviço X dependente atingirá o tempo limite das solicitações feitas em 100 ms e tentará novamente em 10 ms. Os tempos de resposta aumentarão, mas as solicitações serão resolvidas com sucesso.

2) Varia eventos do mundo real

Para que os experimentos de caos forneçam resultados realistas e objetivos, as variáveis ​​que inserimos também devem ser: eventos do mundo real e específicos do fenômeno em estudo e na magnitude correta para o comportamento avaliado.

Um exemplo pode ser quando estamos em uma arquitetura baseada no nível de importância do serviço, digamos serviços essenciais e não essenciais. Queremos saber se realmente continuamos a vender sem problemas sem um determinado serviço não essencial. Para isso, devemos deixar claro que o serviço essencial, diante da indisponibilidade de sua dependência, receberá o erro 503 "Serviço não disponível". Não vale a pena simular a indisponibilidade por meio da latência inserida, pois isso aciona outros mecanismos de resiliência.

É importante analisar o comportamento do sistema em situações de caos não segmentadas pela visão do desenvolvedor, mas a partir da experiência do usuário. Dependendo do objetivo do experimento, pode ir desde o ponto de vista do usuário final do fluxo de negócios, até a experiência do usuário do cliente ou serviços dependentes que consomem um determinado serviço sobre o qual queremos gerar a variação.


3) Execute experimentos en produção

Experimentar na produção? Gerar caos na produção? Não parece uma boa ideia a priori, mas sim, é, embora não para todos os casos. Estou ciente de que não é possível devido a alguns tipos de domínio de aplicação, regulamentações restritivas em ambientes produtivos ou possíveis barreiras técnicas.

Mas não vamos perder o foco de que o objetivo da Chaos Engineering é descobrir o caos inerente a sistemas complexos, não causar isto. Se sabemos que um experimento produzirá um resultado indesejado, não devemos realizá-lo. Não vamos dar um tiro no pé.

Como em qualquer prática de teste de software, nosso principal objetivo é mitigar o risco, reduzir a incerteza e aumentar a confiança. Às vezes nem sabemos que existem riscos e oportunidades de aprendizado. A avaliação do custo benefício de experimentar para refutar uma hipótese é algo que deve estar sempre presente.

Por outro lado, não é recomendável que, se você é uma empresa que nunca fez Engenharia de Caos, comece a experimentar diretamente na produção. Faz mais sentido que você faça isso previamente em ambientes de teste ou staging enquanto você prepara, aprende e estabelece as bases da infraestrutura tecnológica para isso. Depois de entender como a ferramenta de geração de caos funciona e quais são os comportamentos gerais esperados do seu sistema, você pode passar gradualmente para a produção.

Em geral, não é recomendável realizar caos em ambientes alternativos, pois são esperados diferenciais em relação ao ambiente produtivo, o que geraria ruídos no experimento e afetaria a confiança dos resultados.


4) Automatize os experimentos para que sejam executados continuamente

Experimentar soluções complexas propensas a fragilidades sistêmicas não é uma atividade que seja viável manualmente desenvolver, principalmente se aumentarmos e diversificarmos o conjunto de experimentos em busca de comportamentos desconhecidos e riscos potenciais.

A arquitetura dos sistemas de software, as tecnologias nas quais eles se baseiam, a infraestrutura na qual são implantados e as abordagens das equipes de desenvolvimento estão em constante mudança e evolução, de modo que novos estados estacionários justificam novas iterações de experimentação. Entendendo isso, comunidades e empresas têm visto um nicho de trabalho em ferramentas que automatizam não só a geração do caos para fins práticos, mas também a partir do gerenciamento e monitoramento centralizado do experimento.

Podemos citar ferramentas alternativas para esta prática como  Chaos Monkey, Toxiproxy, Chaos Mesh, Pumba, Litmus, Gremlin y AWS Fault Injection Simulator, entre outras. Alguns são mais maduros que outros, têm maior possibilidade de profissionalizar a disciplina, modalidade Open Source ou licenciada, abrangente ou segmentada por tipos de caos, mas abordarei tudo isso em publicações posteriores desta série.

5) Minimize o raio de explosão

Nenhuma das equipes que experimentam o caos deseja que o impacto vá além do planejado, mas diante de arquiteturas de centenas de microsserviços, é preciso entender detalhadamente todo o ecossistema de dependências existentes e como elas podem ser afetadas. Nem sempre é humanamente possível controlar todos os casos. Diante dessa incerteza, compartilho várias lições aprendidas que incorporei em meus processos de experimentação:

  • Parece básico, mas é altamente recomendável entender exatamente como funciona a ferramenta de geração de caos de baixo nível selecionada. Teste-o em ambientes seguros e avalie se atende ao comportamento esperado para o seu plano. Às vezes, damos por certo que aplicativos muito populares funcionam perfeitamente, que aplicam as variações da mesma forma que os demais usados, filtram usando os mesmos algoritmos ou apresentam as mesmas restrições, mas nem sempre é esse o caso. Portanto, ele testa e entende em profundidade o que realmente faz no nível de aplicativo, infraestrutura ou processo. A confiança na ferramenta e no uso que você vai dar é essencial.
  • Defina objetivos específicos e granulares, que serão representados na hipótese. Quanto mais delimitarmos os componentes objetivos avaliados, mais confiáveis ​​serão as conclusões. Devemos experimentar a seleção de um grupo de controle representativo (não necessariamente tudo deve ser considerado). Um exemplo seria quando você está em uma arquitetura multitenant, onde uma solução é a mesma para cada inquilino. Por que afetar o todo se com um deles posso tirar as mesmas inferências?
  • Limite o escopo do experimento a um caos por vez. Cada tipo de variável que incorporamos possui padrões de resiliência que são ativados de forma diferente. Isso cria confusão nas conclusões. O mesmo acontece quando uma hipótese é refutada no pior caso, o tempo de resolução e recuperação é significativo. Se desenvolvermos uma cadeia de experimentos, executaremos diferentes exercícios sob um estado estacionário não real.


Se você aplicar todas essas dicas, aplicará processos de Chaos Engineering maduros e previsíveis com maior probabilidade de sucesso.

Experimente e divirta-se no processo!

Referências

💡
As opiniões e comentários expressos neste artigo são de propriedade exclusiva de seu autor e não representam necessariamente o ponto de vista da Revelo.

A Revelo Content Network acolhe todas as raças, etnias, nacionalidades, credos, gêneros, orientações, pontos de vista e ideologias, desde que promovam diversidade, equidade, inclusão e crescimento na carreira dos profissionais de tecnologia.