Custo de manter testes de carga contínuos no pipeline de desenvolvimento

Recentemente, uma grande plataforma de comunicação como o Slack vem investindo na integração de testes de carga contínuos no fluxo de trabalho de todos os engenheiros, não só na equipe de performance. Essa mudança visa tornar o teste de carga algo natural e parte do dia a dia, ao invés de uma tarefa reativa que só acontece na hora de um problema grave.

A ideia é que, ao incorporar testes de carga no pipeline, seja possível detectar impactos de mudanças antes que afetem a produção, reduzindo riscos e custos. Mas, na prática, isso pesa na infraestrutura e na equipe, já que esses testes demandam recursos e monitoramento constante. Além disso, a complexidade de automatizar esses testes de forma eficiente e confiável é um desafio à parte.

Eu acho que o maior ganho mesmo é na visão de longo prazo: ao transformar o teste de carga em uma rotina, a equipe consegue ajustar a escala, identificar gargalos cedo e evitar surpresas que custam caro lá na frente. Vocês têm experiências com isso? Como equilibram o custo de testes contínuos com a necessidade de manter a performance sob controle? Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco.