Quando Tudo Falha: Explorando a Engenharia do Caos com o ChaosEngineeringMasterDeck

Fellipe Cotta — Mon, 19 Oct 2026 20:17:23 +0000

Nota de transparência: este artigo apresenta um cenário hipotético, elaborado para fins acadêmicos. O experimento, a arquitetura e os resultados descritos não foram executados nem medidos em uma infraestrutura real. Os valores numéricos são ilustrativos e servem para explicar como um teste de Engenharia do Caos poderia ser planejado e analisado.

1 Introdução ao Chaos Engineering: da prevenção à mitigação

Em sistemas distribuídos, falhas não são apenas uma possibilidade distante. Redes podem apresentar latência, bancos de dados podem ficar temporariamente indisponíveis, serviços externos podem responder lentamente e recursos computacionais podem se esgotar. Quando uma aplicação depende de vários componentes, uma falha localizada pode se propagar e afetar partes maiores do sistema.

A Engenharia do Caos (Chaos Engineering) é uma abordagem experimental usada para investigar como um sistema se comporta diante de falhas controladas. Em vez de esperar por um incidente real para descobrir fragilidades, a equipe formula hipóteses, introduz uma condição adversa de forma planejada e observa se o sistema continua operando dentro de limites aceitáveis.

Testes unitários, testes de integração e revisões de código continuam sendo fundamentais, mas eles não revelam necessariamente todos os efeitos que surgem quando componentes distribuídos interagem sob condições inesperadas. Por exemplo, uma dependência lenta pode manter requisições abertas por muito tempo, consumir threads e conexões e provocar uma falha em cascata.

Essa prática propõe uma mudança de mentalidade:

Abordagem centrada apenas na prevenção: tentar impedir todas as falhas e reagir quando elas acontecem.
Abordagem orientada à resiliência: reconhecer que falhas podem ocorrer e projetar, testar e monitorar mecanismos que limitem seus efeitos.

Isso não significa provocar falhas sem critério ou começar diretamente em produção. Os experimentos precisam ter objetivos claros, limites de impacto, monitoramento e um procedimento de interrupção. Para um primeiro teste, um ambiente isolado ou de pré-produção costuma ser uma opção mais segura. Experimentos em produção exigem controles operacionais e autorização apropriados.

22 Dissecando o ChaosEngineeringMasterDeck

A Engenharia do Caos precisa de método. Introduzir falhas aleatoriamente, sem hipótese nem limites, pode causar indisponibilidade sem produzir aprendizado útil.

Neste artigo, o ChaosEngineeringMasterDeck é tratado como um modelo conceitual de organização dos experimentos: um catálogo de cenários de falha, representados por “cartas”, acompanhado de um protocolo para planejar, executar e avaliar cada teste. Esta descrição é uma proposta para o estudo acadêmico, não uma afirmação de que exista uma ferramenta padronizada com essa implementação.

Cada carta pode conter a categoria da falha, o componente-alvo, a hipótese, as métricas de controle, o limite de impacto e os critérios para interromper o experimento. Para orientar a análise, o protocolo é dividido em cinco elementos.

2.1 Estado estável (Steady State)

É a descrição mensurável do funcionamento considerado normal. Não basta verificar se o servidor está ligado: é importante acompanhar indicadores técnicos e, quando pertinente, indicadores de negócio.

Neste cenário hipotético, o estado estável poderia incluir:

latência p99 do serviço de pedidos abaixo de 400 ms;
utilização do pool de conexões abaixo de 60%;
taxa de erros HTTP 5xx abaixo de 0,1%;
capacidade de registrar pedidos sem perda de dados.

Esses valores são metas ilustrativas para o cenário, não limites universais. Em um sistema real, eles precisariam ser definidos a partir dos requisitos e da linha de base observada.

2.2 Hipótese

A hipótese descreve o comportamento que se espera observar quando a falha for introduzida. Ela deve ser clara e verificável.

Hipótese do cenário: se o serviço de pagamentos apresentar latência elevada, o serviço de pedidos deverá limitar o tempo de espera, evitar a saturação de recursos e, quando o fluxo de negócio permitir, registrar o pedido para processamento posterior sem declarar que o pagamento foi concluído.

2.3. Variável de injeção

É a condição adversa introduzida no sistema. Exemplos incluem latência de rede, perda de pacotes, consumo elevado de CPU, encerramento de um contêiner ou indisponibilidade temporária de uma dependência.

Neste caso, a variável escolhida é a latência artificial na comunicação com o serviço de pagamentos.

2.4 Raio de explosão (Blast Radius)

O Blast Radius define a extensão máxima do impacto permitido. Pode limitar o experimento a um serviço, a determinadas instâncias, a uma parcela do tráfego ou a um ambiente isolado.

Quanto menor e mais controlado for o raio inicial, mais fácil será identificar a causa de um comportamento inesperado e reduzir o risco para usuários.

2.5. Condição de aborto (Stop Condition)

A condição de aborto estabelece quando o teste deve ser interrompido. Ela pode considerar o aumento de erros, a elevação da latência, a saturação de recursos ou qualquer sinal de impacto além do limite aprovado.

O plano também deve definir como remover a injeção de falha, verificar a recuperação e comunicar a interrupção. Um teste de caos seguro precisa ter um caminho claro para parar.

3 Estudo de caso simulado: latência no serviço de pagamentos

Para aplicar o modelo, considere uma arquitetura hipotética de processamento de pedidos. O sistema utiliza microsserviços desenvolvidos em Java com Spring Boot, executados em Kubernetes na AWS EKS, com PostgreSQL para persistência e RabbitMQ para comunicação assíncrona.

O fluxo principal envolve um order-service, responsável pelos pedidos, e um payment-gateway-service, responsável pela integração com o pagamento. Uma dependência lenta pode fazer com que o serviço de pedidos mantenha requisições abertas, acumule trabalho e consuma recursos que seriam necessários para outras operações.

O objetivo do experimento proposto é avaliar se o sistema limita essa espera e preserva a capacidade de responder a outras requisições.

3.1 Carta selecionada

Identificação: NET-04

Nome: Latência em dependência crítica

Categoria: Rede e dependências síncronas

Atributo	Especificação proposta
Componente observado	Comunicação entre `order-service` e `payment-gateway-service`
Falha injetada	Latência artificial de 2.500 ms, com variação (jitter) de até 200 ms
Hipótese	O serviço de pedidos limitará o tempo de espera e evitará que a lentidão se propague para outros endpoints
Métricas	Latência p50/p95/p99, erros HTTP 5xx, threads ocupadas, conexões do pool e estado do Circuit Breaker
Duração máxima	5 minutos, caso todos os critérios de segurança sejam respeitados
Ambiente inicial recomendado	Ambiente de teste isolado, sem tráfego real de clientes

Os valores acima são parâmetros ilustrativos do estudo de caso. Uma execução real exigiria validar a configuração da ferramenta de injeção, os seletores dos componentes e a compatibilidade com a versão do ambiente.

3.2 Definição do Blast Radius

Para manter o experimento limitado, o plano considera um ambiente de teste isolado e uma instância canário do order-service. A injeção deve afetar apenas a comunicação definida para o teste, sem atingir outros serviços ou tráfego não relacionado.

O plano de execução deve confirmar previamente:

que o seletor identifica somente o componente-alvo;
que o tráfego de teste está separado do tráfego de usuários;
que a injeção pode ser removida imediatamente;
que as métricas e os alertas estão funcionando;
que existe um procedimento de aborto testado.

Em uma implantação real, a restrição a uma instância canário e a uma porcentagem específica de tráfego precisaria ser implementada e validada por mecanismos de roteamento e seleção adequados. Apenas declarar que o teste atinge 5% do tráfego não garante esse isolamento.

3.3 Exemplo ilustrativo de configuração

O trecho abaixo serve para demonstrar como um manifesto YAML pode ser apresentado no artigo. Ele não deve ser tratado como uma configuração pronta para execução: os seletores, o namespace e os campos necessários precisam ser ajustados e validados para o ambiente e a versão da ferramenta utilizados.

# Exemplo conceitual de injeção de latência
# Validar os seletores e os campos antes de qualquer execução.
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: payment-latency-injection
  namespace: test-canary
spec:
  action: delay
  mode: one
  selector:
    namespaces:
      - test-canary
    labelSelectors:
      app: payment-gateway-service
  delay:
    latency: "2500ms"
    correlation: "100"
    jitter: "200ms"
  duration: "5m"

O manifesto é apresentado como referência didática. A seleção do alvo e a direção do tráfego devem corresponder à hipótese do experimento; não se deve presumir que esse exemplo, sem validação adicional, implemente sozinho todo o isolamento descrito.

3.4 Condições de aborto

Para este cenário, o teste seria interrompido se a taxa de erros ultrapassasse o limite definido pela equipe, se a latência de endpoints não relacionados aumentasse de forma significativa ou se os recursos se aproximassem de níveis críticos.

Como exemplo acadêmico, poderia ser definido um limite de 1% de erros HTTP 5xx durante a janela de observação. Em uma execução real, o limiar precisaria ser justificado pela linha de base e pelos objetivos de serviço. O plano também deveria incluir a remoção da injeção e a confirmação de que as métricas retornaram aos níveis esperados.

4 Observabilidade e padrões de resiliência

A observabilidade permite entender não apenas que houve degradação, mas onde ela começou, como se propagou e quais recursos foram afetados. Para o cenário proposto, três fontes de informação seriam úteis:

Métricas com Prometheus e Grafana: acompanhar latência p50, p95 e p99, taxa de erros, CPU, memória, threads ocupadas, conexões do pool e estado do Circuit Breaker.
Rastreamento distribuído com OpenTelemetry e Jaeger: identificar quanto tempo cada etapa da requisição consome e localizar a dependência que introduz a demora.
Logs centralizados, por exemplo com a stack ELK: investigar timeouts, exceções, tentativas repetidas e acionamentos de fallback.

As ferramentas citadas são exemplos de uma possível implementação. O cenário não pressupõe que elas tenham sido instaladas ou utilizadas em um ambiente real.

4.1 Comportamento esperado da arquitetura

O fluxo hipotético pode ser resumido assim:

[Cliente]
    |
    | POST /orders
    v
[order-service]
    |
    | chamada com limite de tempo
    v
[Circuit Breaker / TimeLimiter]
    |
    +---- chamada normal ----> [payment-gateway-service]
    |
    +---- falha ou timeout ---> [tratamento alternativo]
                                      |
                                      v
                              [RabbitMQ, se aplicável]
                                      |
                                      v
                          [processamento posterior]

O desenho representa uma possibilidade de arquitetura, não um resultado observado. A utilização de uma fila depende das regras de negócio e da garantia de que o pedido possa ser registrado com segurança antes da confirmação do pagamento.

4.2 Primeira etapa: identificar o risco das novas tentativas

No cenário proposto, uma chamada ao serviço de pagamentos demora 2.500 ms. Se o cliente realizar três tentativas sequenciais, cada uma com essa duração e sem considerar outros tempos de processamento, a espera acumulada pode chegar a aproximadamente 7,5 segundos.

Essa demora pode manter requisições ocupadas por tempo excessivo. Se muitas requisições se acumularem, o serviço pode sofrer saturação de threads e de conexões. O efeito exato dependeria da implementação, dos timeouts, do tipo de processamento e da concorrência.

Por isso, as novas tentativas (retries) precisam ser limitadas e configuradas em conjunto com os demais mecanismos de resiliência. Repetir uma chamada indiscriminadamente pode ampliar a sobrecarga justamente quando a dependência já está degradada.

4.3 Segunda etapa: aplicar mecanismos de resiliência

No cenário simulado, três mecanismos poderiam reduzir o impacto da falha.

TimeLimiter e timeout: estabelecer um tempo máximo de espera para a operação. Um limite ilustrativo de 1.000 ms faria com que a aplicação tratasse a chamada como excedida antes de aguardar os 2.500 ms completos, desde que o timeout estivesse corretamente aplicado à operação e que o cliente subjacente pudesse ser controlado conforme necessário.
Bulkhead: limitar os recursos dedicados às chamadas para a dependência problemática. Por exemplo, um limite hipotético de 15 execuções concorrentes poderia ajudar a impedir que essa integração consumisse todos os recursos disponíveis para outros endpoints. O valor correto dependeria de testes de carga e da capacidade do serviço.
Circuit Breaker e tratamento alternativo: interromper temporariamente chamadas a uma dependência considerada degradada, segundo critérios configurados, para evitar novas esperas desnecessárias. Um exemplo de configuração poderia avaliar uma janela de 20 chamadas e abrir o circuito quando a proporção de chamadas lentas ou com falha ultrapassasse o limiar estabelecido. A configuração real precisa definir quais eventos são contabilizados e como o circuito se recupera.

Se a regra de negócio permitir, o sistema poderá registrar o pedido como pendente e encaminhar o processamento do pagamento para uma fila. A resposta ao cliente deve deixar claro que o pagamento ainda não foi confirmado. Um HTTP 202 Accepted pode indicar que a solicitação foi aceita para processamento, mas não significa que a transação financeira foi concluída.

4.4 Exemplo didático em Java

O trecho seguinte ilustra a ideia de delimitar uma chamada e tratar uma falha. Ele é esquemático e não constitui uma implementação completa: assinaturas de fallback, execução assíncrona, configuração do Resilience4j e integração com a fila precisam ser ajustadas ao projeto.

@CircuitBreaker(
    name = "paymentService",
    fallbackMethod = "queuePaymentForLater"
)
@Bulkhead(
    name = "paymentService",
    type = Bulkhead.Type.THREADPOOL
)
@TimeLimiter(name = "paymentService")
public CompletableFuture<PaymentResponse> processPayment(
        OrderRequest request) {
    return CompletableFuture.supplyAsync(
        () -> paymentClient.charge(request)
    );
}

Em uma implementação real, o método de fallback deve ter uma assinatura compatível com o método protegido e com a exceção recebida. Também é necessário garantir que o pedido seja persistido de forma consistente, que a mensagem possa ser processada com segurança e que falhas de publicação na fila sejam tratadas.

4.5 Resultados hipotéticos e critérios de avaliação

Como o experimento não foi executado, não existem medições reais a relatar. A tabela abaixo descreve resultados que seriam desejáveis e as evidências que precisariam ser coletadas para verificar a hipótese.

Indicador	Comportamento de risco esperado antes dos ajustes	Resultado desejado após os ajustes
Latência da chamada de pagamento	Espera prolongada devido à dependência lenta	Chamada limitada pelo timeout configurado
Uso de threads	Acúmulo de requisições em espera	Concorrência limitada pelo Bulkhead
Circuit Breaker	Pode demorar a abrir se os critérios forem inadequados	Abre conforme a configuração e os sinais observados
Endpoints independentes	Podem ser afetados pela saturação de recursos compartilhados	Mantêm desempenho dentro dos objetivos definidos
Processamento do pedido	Risco de falha ou resposta ambígua	Estado pendente e processamento posterior, se permitido pela regra de negócio

Para comprovar esses resultados em um teste real, seria necessário comparar métricas antes, durante e depois da injeção, registrar as configurações usadas e verificar a recuperação após a retirada da falha. Até que isso seja feito, os itens da coluna final devem ser entendidos como objetivos de validação, não como resultados comprovados.

5 Conclusão

O cenário simulado demonstra como a Engenharia do Caos pode ajudar a investigar fragilidades em sistemas distribuídos. Uma dependência lenta pode causar efeitos que vão além do componente afetado, especialmente quando novas tentativas, timeouts e limites de concorrência não são coordenados.

O ChaosEngineeringMasterDeck, entendido aqui como um catálogo conceitual de experimentos, oferece uma maneira organizada de documentar hipóteses, variáveis de injeção, estado estável, raio de explosão e condições de aborto. Esse processo transforma um teste de falha em uma atividade planejada, observável e orientada ao aprendizado.

Entre os benefícios esperados estão:

Melhor diagnóstico: métricas, rastreamento e logs ajudam a localizar gargalos e entender a propagação de falhas.
Maior isolamento: limites de concorrência e de impacto reduzem a chance de uma falha localizada afetar todo o sistema.
Recuperação mais previsível: timeouts, Circuit Breakers e tratamentos alternativos podem tornar o comportamento diante de falhas mais controlado.
Colaboração entre desenvolvimento e operações: critérios compartilhados aproximam as decisões de arquitetura, monitoramento e resposta a incidentes.

Esses benefícios dependem de planejamento, implementação correta e validação. O exercício apresentado não comprova que uma arquitetura real tenha resistido ao teste; ele demonstra como um experimento poderia ser estruturado e quais evidências seriam necessárias para avaliar sua eficácia.

A resiliência não deve ser presumida apenas porque uma aplicação utiliza ferramentas ou padrões conhecidos. Ela precisa ser avaliada por meio de hipóteses claras, observação sistemática e testes seguros, com resultados documentados de forma honesta.

DEV Community: Fellipe Cotta