Confiabilidade

Três serviços, três noves cada

• Numa cadeia de dependências, as disponibilidades se multiplicam: 0.999³ ≈ 99.7%.
• Ponta a ponta é pior do que qualquer componente isolado.
• Em paralelo é o contrário: duas réplicas com 99% → 1 − 0.01² = 99.99%.
• Por isso existem redundância e padrões de isolamento: para quebrar a cadeia de propagação de falhas.

Disponibilidade: duas alavancas

Disponibilidade = MTTF / (MTTF + MTTR)

• ↑ MTTF — prevenir falhas: projeto tolerante a falhas, testes, redundância.
• ↓ MTTR — recuperar mais rápido: resposta a incidentes, automação, runbooks.

Serviço de pedidos: MTTF 720 h, MTTR 2 h → 99,72%. Reinício automático em 1 min → 99,998%. Recuperar mais rápido foi o ganho mais barato.

Os "noves"

SLI → SLO → SLA

• SLI = eventos bons / eventos válidos, refletindo o que o usuário experimenta: disponibilidade (non-5xx / total), latência (% faster than 200 ms), durabilidade, atualidade.
• Coletado via Actuator/Micrometer, sondas sintéticas (Blackbox Exporter), logs de acesso ou no cliente.

SLO e o error budget

Um SLO é SLI ≥ threshold em uma rolling window (janela móvel) — ex.: Availability ≥ 99.9% em 28 dias.

Error budget = 1 − meta do SLO — a licença para assumir riscos da equipe.

99,9% em 28 dias → ≈ 40,3 minutos, ou 28.000 requisições com falha em 28 milhões.

Burn rate

burn rate = observed error rate ÷ (1 − SLO) — com SLO de 99,9%, 1,44% de erros = 14,4×.

• Alertas de burn rate alta pegam cedo os incidentes rápidos.
• Alertas de burn rate baixa pegam degradações lentas que, de outro modo, seriam invisíveis.

SLA vs SLO

SLAs reais: AWS EC2 99,99% ao mês, S3 99,9%, RDS Multi-AZ 99,95% — uma violação paga créditos de serviço, não as suas vendas perdidas.

Timeout e retry

• Timeout (connect + read) em toda chamada de saída, perto do P99.9 do downstream, dentro do orçamento de quem chama, por dependência.
• Retry só de falhas transitórias (timeouts, 503, 429) — nunca 4xx — com backoff exponencial: 1 s, 2 s, 4 s… até um teto.
• Adicione full jitter (random(0, backoff)) para que clientes que falharam juntos não repitam juntos — a thundering herd.
• Retry em uma camada: 3 camadas × 3 tentativas = 27 chamadas a um serviço em apuros.

Circuit breaker

Closed → (taxa de falhas > limite) → Open → (tempo de espera) → Half-Open → teste ok → Closed · teste falha → Open

Open = rejeita na hora, sem chamada de rede → um fallback degrada com elegância (dados em cache, 503 claro; nunca finja um pagamento). Resilience4j: @CircuitBreaker(name = "product", fallbackMethod = …), @Retry, @Bulkhead.

Bulkhead, rate limiting, health checks

Actuator: /actuator/health/liveness e /readiness. Nunca verifique o banco na liveness: uma oscilação do banco reiniciaria todas as réplicas de uma vez.

Defesa em profundidade

cliente → rate limiter → circuit breaker → bulkhead → timeout → retry + backoff → downstream

Os padrões não evitam falhas; eles limitam até onde uma falha se espalha.

Engenharia do caos

Experimentar no sistema para ganhar confiança de que ele suporta condições turbulentas em produção.

• Origem: ao migrar para a AWS, a Netflix criou o Chaos Monkey (2010) — mata instâncias aleatórias em produção, em horário comercial. Valeu a pena na pane de us-east-1 em abril de 2011.
• Veio o Simian Army (2011): Latency Monkey, Chaos Gorilla (uma Availability Zone inteira)… Antes, a Amazon fazia GameDays (Jesse Robbins).
• Princípios: hipótese sobre o estado estável · variar eventos reais · rodar em produção · automatizar · minimizar o raio de impacto.

"The best way to avoid failure is to fail constantly." — John Ciancutti, Netflix, 2010

Rodando um experimento

Hipótese do estado estável → Projeto da falha e do raio de impacto → Injeção → Observação dos SLIs → Análise → Melhoria, e repita com escopo maior.

• Exemplo da loja: 3 s de latência (Toxiproxy) entre order e product → espera-se que o breaker abra e GET /orders siga rápido.
• Aumente o raio de impacto: testes → staging/canário → 1% do tráfego → produção completa; aborto automático se um SLI cair.
• GameDay: exercício em equipe — briefing, execução, observação, debriefing sem culpados.
• Ferramentas: Chaos Monkey, Gremlin, LitmusChaos, Chaos Mesh, Toxiproxy, AWS FIS.

Pontos-chave

1. Disponibilidade = MTTF / (MTTF + MTTR); numa cadeia, as disponibilidades se multiplicam.
2. Cada nove a mais é 10× menos indisponibilidade e outra postura operacional.
3. Falhas em cascata se espalham por pools de threads esgotados — o principal risco dos microsserviços.
4. SLI mede, SLO define a meta, SLA é contrato; mantenha o SLO mais estrito que o SLA.
5. O error budget (1 − SLO, ≈ 40 min a cada 28 dias com 99,9%) e sua burn rate decidem entre funcionalidades e confiabilidade.
6. Timeout, retry + jitter, circuit breaker + fallback, bulkhead, rate limit, health checks — em camadas.
7. A engenharia do caos prova que os padrões funcionam — com raio de impacto pequeno e observabilidade primeiro.