Pular para o conteúdo

apps/resiliency/chaos-engineering

111 · Resiliência & Tolerância a Falhas · ≈ 6 min de estudo

Chaos Engineering

Injeta uma falha controlada num serviço real para provar, com números, que o sistema mantém o comportamento esperado — ou descobrir que não mantém antes do incidente. Todo experimento tem hipótese de steady-state, baseline, blast radius mínimo e rollback automático por métrica. Use para validar timeout, retry, circuit breaker e fallback contra falha de verdade.

passos
6
arquivos
6
testes
0
tecnologias
4
Lógica puraTypeScriptBunElysiaStryker
Baixar cartão

Cenário

O banco quer saber se a liquidação de PIX aguenta degradação do serviço do BACEN. Hipótese: 99% dos PIX liquidam e o p99 fica abaixo de 400 ms. O primeiro experimento injeta 150 ms de latência em 20% dos PIX e a hipótese se mantém. O segundo injeta blackhole em 10%: o cliente só tem timeout, sem retry, a primeira janela cai para 90% de sucesso, a regra de abort desliga a falha sozinha e o experimento revela o que falta.

Planta

Sequência
8/8
loop[janela de 20 PIX]baseline sem falha1POST /settlements2settled3PUT /chaos (falha + blast radius)4POST /settlements5settled, lento, 5xx ou sem resposta6regra de abort na última janela7DELETE /chaos (rollback, sempre)8ExperimentoCliente PIXLiquidação BACEN
8

8 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Experimentos de falha em produção.

Esconde cada passo: lembre antes de tocar para revelar.

  1. 01

    experimentRun mede o baseline com a falha desligada; baseline fora da hipótese lança ErrorBaselineUnsteady e nada é injetado

  2. 02

    PUT /chaos liga a falha por feature flag em runtime — latência com jitter, erro 5xx ou blackhole —, sem deploy

  3. 03

    O blast radius é uma coorte fixa: chaosBucket (FNV-1a do id da transação) abaixo do percentual; a mesma transação está sempre dentro ou fora

  4. 04

    Os PIX rodam em janelas; após cada uma, abortTriggered compara a última janela com o limite de abort (95% de sucesso, p99 de 800 ms)

  5. 05

    DELETE /chaos roda no finally: o rollback acontece no fim, no abort e em exceção

  6. 06

    hypothesisHolds julga o resultado injetado contra a hipótese (sucesso e p99 por nearest-rank)

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • Prova a resiliência com falha real, não com configuração lida

  • Blast radius por coorte limita e torna reproduzível quem é afetado

  • Rollback automático por métrica encerra o experimento sem humano

  • Flag em runtime liga e desliga sem deploy

Custos

  • Exige observabilidade e métricas antes do primeiro experimento

  • A mesma coorte sofre em todo experimento com o mesmo percentual

  • Limite de abort mal calibrado aborta cedo demais ou tarde demais

  • O injetor fica no caminho de produção e precisa ser protegido

apps/resiliency/chaos-engineering

6 arquivos

src/

  • chaos_fault.tsTipos de falha, flag e blast radius por coorte de hash
  • steady_state.tsHipótese de steady-state, p99 e regra de abort por janela
  • bacen_settlement.tsServiço de liquidação em ElysiaJS com o injetor controlado por /chaos
  • experiment_chaos.tsBaseline, injeção por janelas, abort e rollback no finally
  • config_chaos.tsConfiguração validada do ambiente
  • demo.tsdemoExperimentos de latência (hipótese mantida) e blackhole (abortado)

Executar · só Bun

  1. bun install# dependências
  2. bun run demo# roda o cenário
  3. bun run test# testes unitários
  4. bun run test:mutation# mutação com Stryker
Requisitos
Bun

Por que se relacionam

Teste rápido

Qual padrão vem antes de Chaos Engineering?

Próximo projeto · Resiliência & Tolerância a FalhasThrottling
Esc

↑ ↓ navegarEnter abrir191 resultados