Aula 8 • Projeto 9 • Sistemas de Informacao
Gerenciando a aplicacao em Nuvem

Engenharia do caos no CI para validar timeouts, queda de servicos e degradacao de conexoes com tratamento robusto de erros.

Chaos CI Timeouts Circuit Breaker Fallback Retry Bulkhead Testcontainers SLO
Prof. Afonso Brandao • 2 horas • Marco 2026
O que e CI (Continuous Integration)

Definicao objetiva

CI e a pratica de integrar codigo com frequencia e validar automaticamente build + testes a cada commit/merge.

  • Detecta erro cedo.
  • Reduz risco de integracao tardia.
  • Cria feedback rapido para o time.

O que um CI serio precisa ter

  • Pipeline reproduzivel (mesmos passos em todo commit).
  • Gates de qualidade (testes, cobertura, lint, SLO).
  • Evidencia auditavel (logs, artefatos, historico).
Commit Build Test Gate
Nesta aula, CI nao e so \"rodar teste\". E mecanismo de confiabilidade para impedir regressao antes de chegar em producao.
Como fica um CI no YAML do GitLab

Estrutura minima de .gitlab-ci.yml

stages:
  - validate
  - test
  - chaos
  - quality_gate

default:
  image: mcr.microsoft.com/dotnet/sdk:8.0

variables:
  DOTNET_CLI_TELEMETRY_OPTOUT: "1"

lint:
  stage: validate
  script:
    - dotnet format --verify-no-changes

unit_tests:
  stage: test
  script:
    - dotnet test tests/Unit

chaos_timeout:
  stage: chaos
  script:
    - dotnet test tests/Chaos --filter "Category=Timeout"

quality_gate:
  stage: quality_gate
  script:
    - ./scripts/check-slo.sh --max-error-rate 1 --max-p95 350
Conceitos-chave do GitLab CI: stages (ordem), jobs (execucao), rules (quando roda), artifacts (evidencia), gates (aprovacao/bloqueio).
O que e Engenharia do Caos

Definicao e objetivo

Engenharia do caos e provocar falhas controladas para validar se o sistema continua seguro, previsivel e recuperavel.

  • Nao e \"quebrar por quebrar\".
  • E validar resiliencia antes da producao.
  • Foco em evidencia, nao suposicao.

Ciclo pratico

  1. Definir hipotese de comportamento.
  2. Injetar perturbacao realista (timeout, 5xx, rede, server down).
  3. Medir impacto (erro, p95/p99, breaker, lag, DLQ).
  4. Corrigir e repetir continuamente.

Principios

  • Experimento pequeno e reversivel.
  • Guardrails claros (abort por limite).
  • Observabilidade antes do experimento.

O que deve provar

  • Retry sem tempestade.
  • Circuit breaker abrindo e recuperando.
  • Fallback e degradacao controlada.

Maturidade no CI

  • Chaos tests no pipeline.
  • Gate por SLO.
  • Deploy bloqueado se degradar alem do limite.
Ciclo de testes com Engenharia do Caos
CICLO CAOS 1. Definir hipótese 2. Injetar falha 3. Medir impacto 4. Corrigir e repetir Atender a um requisito mapeado Perturbação controlada SLO: erro, p95/p99, breaker, lag, DLQ Ajuste arquitetura e reteste
Pipeline de caos no CI

Stage A - Basico

  • Lint e unit tests.
  • Fail rapido para erros simples.

Stage B - Integracao

  • Testcontainers para DB, cache e broker.
  • Contratos reais de infraestrutura.

Stage C - Chaos

  • Timeout, queda de servico e falha de rede.
  • Gate por erro maximo e latencia p95.
Como tratar erros corretamente

Classificacao de erro

  • Transiente: timeout curto, throttling, rede oscilando.
  • Persistente: servico fora, credencial invalida, schema quebrado.
  • Negocio: validacao e regra invalida (nao fazer retry).

Politica por classe

  • Transiente: retry exponencial com jitter + timeout.
  • Persistente: circuit breaker + fallback + alerta imediato.
  • Negocio: resposta clara, sem reprocessamento.
Anti-padroes comuns

Retry infinito

Amplifica falha e derruba dependencia.

Timeout alto demais

Threads ocupadas e fila acumulando.

Circuit breaker ausente

Falha em cascata por toda a cadeia.

Regra pratica: timeout curto, retry limitado, breaker com janela clara e fallback observavel.
Circuit breaker na pratica
Estado Comportamento Meta operacional
Closed Fluxo normal, monitorando taxa de falha Operacao plena
Open Bloqueia chamadas para dependencia instavel Evitar saturacao e cascata
Half-open Permite poucas chamadas de teste Validar recuperacao gradual
Exemplo .NET com Polly
builder.Services.AddHttpClient("orders-api", client =>
{
    client.BaseAddress = new Uri("https://orders.internal");
    client.Timeout = TimeSpan.FromSeconds(2);
})
.AddPolicyHandler(Policy.TimeoutAsync<HttpResponseMessage>(2))
.AddPolicyHandler(Policy
    .Handle<HttpRequestException>()
    .OrResult(r => (int)r.StatusCode >= 500)
    .WaitAndRetryAsync(3, retry => TimeSpan.FromMilliseconds(200 * Math.Pow(2, retry))))
.AddPolicyHandler(Policy
    .Handle<HttpRequestException>()
    .OrResult(r => (int)r.StatusCode >= 500)
    .CircuitBreakerAsync(
        handledEventsAllowedBeforeBreaking: 5,
        durationOfBreak: TimeSpan.FromSeconds(30)));

// Fallback pode devolver resposta degradada com cache/local snapshot.
Chaos test no CI (conceito)
jobs:
  chaos-tests:
    steps:
      - run: dotnet test tests/Unit
      - run: dotnet test tests/Integration
      - run: dotnet test tests/Chaos --filter "Category=Timeout"
      - run: dotnet test tests/Chaos --filter "Category=ServerDown"
      - run: dotnet test tests/Chaos --filter "Category=ConnectionFlaky"
      - run: ./scripts/check-slo.sh --max-error-rate 1 --max-p95 350
Matriz de decisoes de resiliencia
Tipo de operacao Politica minima Fallback
Leitura nao critica Timeout curto + retry baixo Cache com staleness controlado
Comando critico Timeout + breaker + idempotencia Fila para reprocessamento seguro
Integracao externa Retry com jitter + breaker Resposta degradada + alerta
Operacao longa Assincrono + DLQ + observabilidade Status pendente e notificacao posterior
Indicadores obrigatorios no gate

Erro e latencia

  • Error rate por endpoint e dependencia.
  • p95/p99 antes e durante caos.

Resiliencia

  • Numero de aberturas do breaker.
  • Tempo medio em estado open.

Recuperacao

  • MTTR apos falha induzida.
  • Sucesso em half-open.
Atividade de sala
Teste funcional de Engenharia do Caos (modelo black box)
Direcionamento: escolher uma rota existente do projeto, induzir uma falha controlada e demonstrar que a aplicacao degrada com seguranca e recupera sem quebrar o fluxo principal.
Tempo: 40 minutos de implementacao + 20 minutos para apresentacao.

Plano de execucao do teste de caos

Etapa O que fazer Evidencia esperada
1. Definir alvo Escolher uma rota/operacao e dependencia critica (DB, API externa, broker). Descricao do caso de uso e do comportamento esperado sem falha.
2. Definir hipotese Especificar como o sistema deve reagir (timeout, retry, fallback, breaker). Criterio objetivo de sucesso/falha.
3. Injetar falha Executar chaos test (timeout, server down ou conexao intermitente). Log/print do experimento e erro provocado.
4. Validar resiliencia Comprovar degradacao segura e recuperacao controlada. Resposta funcional ao usuario + estado do breaker/retry/fallback.
5. Mostrar metricas Apresentar indicadores de gate no CI. Error rate, p95/p99 e pelo menos 1 metrica de resiliencia.
🏠 Home 📖 Material
1 / 1