Porque é importante a engenharia do caos? Vejamos por que razão existe a Garantia da Qualidade (QA) desde logo.
De forma bastante simples, a QA existe porque, por muito que tentemos criar software perfeito, que faça sempre aquilo para que foi concebido e aquilo que deve fazer, a realidade parece não o permitir.
Os erros surgem sorrateiramente. As máquinas interpretam o nosso código de forma diferente daquela que pretendíamos. Acontecem imprevistos. A engenharia da qualidade existe para tentar encontrar esses problemas não intencionais antes de os nossos clientes o fazerem.
O que é a engenharia do caos?
A engenharia do caos é uma abordagem disciplinada para identificar potenciais falhas antes de estas se transformarem em interrupções de serviço. Com a engenharia do caos, concebemos experiências de injeção de falhas e comparamos aquilo que pensamos que irá acontecer com o que realmente acontece nos nossos sistemas. Literalmente, “provocamos falhas deliberadamente” para aprendermos a criar sistemas mais resilientes.
Have an account? Log In
Porque é importante a engenharia do caos?
Porque os sistemas estão a mudar. Tradicionalmente, a QA executa uma variedade de testes e tipos de testes para procurar proativamente estes problemas, muito antes de o código chegar à produção. Estes testes são executados no final de uma compilação e antes de o código ser implementado publicamente, normalmente num ambiente de preparação ou de testes, em vez de serem realizados através de testes em produção.
Até aqui, tudo bem, se estivermos a trabalhar com um modelo tradicional de desenvolvimento e de implementação de software. Os designs monolíticos e as implementações em máquinas pertencentes à empresa proporcionam um elevado grau de controlo. Este controlo contém uma estabilidade intrínseca. Isto torna estes ambientes de preparação e de testes semelhantes aos ambientes de produção e permite que os testes realizados neles sejam bem-sucedidos.
Os sistemas distribuídos são diferentes. A nuvem é diferente. Não controlamos a infraestrutura. Esta está em constante mudança. A infraestrutura muda de acordo com o nosso design, com serviços individuais e microsserviços, enquanto o balanceamento de carga adiciona ou remove nós de computação conforme necessário. Os sistemas de ativação após falha ajustam-se para garantir que os riscos são geridos. A mudança constante provoca comportamentos inesperados e emergentes. São comportamentos que nem sempre conseguimos prever, mas que podemos reproduzir e provocar através de uma forma de testes denominada engenharia do caos.
Os testes têm de se adaptar à medida que os sistemas mudam
Não conseguimos testar eficazmente tudo aquilo com que o nosso código de produção e o ambiente se irão deparar testando em qualquer outro ambiente. Podemos testar muitas coisas, atividades que a QA tradicional executa bastante bem e deve continuar a executar, embora talvez algumas possam agora ser realizadas através de automatização durante o processo de compilação. No entanto, a forma como temos realizado a QA não consegue testar como o nosso sistema distribuído irá reagir quando a rede entre um armazenamento de dados e vários nós de computação ficar sobrecarregada e a latência aumentar, por exemplo.
Os nossos testes automatizados e conduzidos por pessoas não têm em conta este ambiente de produção em rápida mudança, no qual os serviços são iniciados e encerrados em função da procura. A única forma de testar se um sistema distribuído continuará fiável perante comportamentos emergentes provocados pela alteração das condições de produção é fazer aquilo que todos os paradigmas de testes fazem: experimentá-lo e descobrir.
Como funciona a engenharia do caos: testar e aprender através das falhas
Todos temos objetivos de disponibilidade. Todos queremos melhorar o nosso desempenho. Para isso, temos de utilizar todos os recursos disponíveis para aprendermos o máximo possível sobre a forma como os nossos sistemas lidam com as falhas, quer se trate da incapacidade de um utilizador introduzir dados adequados num campo de formulário, quer da falha de um componente do sistema na nuvem em funcionar conforme esperado.
“O que acontece quando?” é uma pergunta que todos gostamos de fazer. Depois, experimentamos e descobrimos.
Uma vez que os nossos sistemas e designs de sistemas evoluíram de uma forma tão sem precedentes, também temos de evoluir os nossos métodos de testes para compreendermos melhor como os nossos sistemas distribuídos irão lidar com as falhas e como as falhas de componentes e dependências afetam todo o sistema. Os testes holísticos deste tipo são a razão de existir da engenharia do caos, pois permitem testar todo o nosso sistema tal como este existe em produção.
Um programa de engenharia do caos começa de forma pequena, testando coisas que já sabemos ou que pensamos saber:
- O nosso sistema de monitorização detetará ativamente uma latência de rede acima de um limiar específico?
- Isso acionará uma notificação para o engenheiro de serviço ou talvez uma mitigação automatizada?
- A nossa configuração sofreu alterações ao longo do tempo ou continuamos a iniciar nós de computação de acordo com as especificações?
Como se comporta cada instância do serviço perante testes ligeiros? Médios? Intensivos? Todas devem ser iguais e o nosso balanceamento de carga deve distribuir a carga adequadamente entre elas. O que acontece se uma instância começar a receber uma carga significativamente mais pesada do que as outras porque o nosso serviço de balanceamento de carga está a ter problemas?
More Articles
Os testes sistemáticos de sistemas caóticos trazem benefícios vitais
Testamos utilizando o método científico, começando por algo pequeno e agindo de forma intencional. Concebemos experiências iniciais para minimizar o raio de impacto, o conjunto de serviços e componentes que acreditamos poderem ser afetados, e para minimizar a magnitude dos parâmetros da experiência.
Assim que formos bem-sucedidos nesta fase, podemos decidir avançar passo a passo, aumentando a nossa confiança no sistema ou aumentando a nossa lista de melhorias prioritárias a implementar. Quando fazemos essas melhorias e voltamos a testar utilizando a mesma experiência de caos e os mesmos parâmetros, o sistema será aprovado e saberemos que é mais fiável do que era anteriormente.
Esta é a única forma de aprendermos como os nossos sistemas lidam realmente com as falhas em produção, onde os nossos clientes acabarão por experienciar os resultados. Se conseguirmos encontrar agora os pequenos problemas, antes de estes terem oportunidade de se propagarem e se transformarem em problemas graves, podemos garantir que ocorrem cada vez menos falhas sistémicas.
Isto torna a Engenharia do Caos uma ferramenta de fiabilidade extraordinária. É uma disciplina que nos ajuda a fazer, na nuvem e à escala, aquilo que costumávamos conseguir realizar em ambientes mais pequenos e controlados utilizando QA tradicional.
Em última análise, isto significa menos falhas e interrupções de produção em grande escala. De facto, quando a Engenharia do Caos é implementada e utilizada de forma consistente, as falhas de serviços e componentes que seria expectável ocorrerem no caos da nuvem não terão qualquer impacto nos nossos clientes. Na verdade, eles nem sequer saberão que ocorreu uma falha, e esse é o verdadeiro objetivo.
O que se segue?
Falei sobre engenharia do caos com mais detalhe num episódio do podcast The QA Lead com Jonathon Wright.
Nota do editor:
Pode manter-se a par de outros podcasts e artigos do The QA Lead ao subscrever a newsletter.
Também pode tornar-se membro para ter acesso ao fórum da comunidade The QA Lead, onde pode partilhar boas práticas com outros profissionais de QA e engenheiros de qualidade. Esperamos vê-lo por lá!
Leitura relacionada: AS 10 MELHORES FERRAMENTAS DE SOFTWARE DE ENGENHARIA DA QUALIDADE: UM GUIA COMPLETO