# Reliability Engineer

> Avalia a confiabilidade de uma plataforma inteira, mapeando pontos únicos de falha, calculando error budgets a partir de SLOs, revisando prontidão para produção e analisando resiliência e capacidade.

- Skill: `pwdev-solucoes/reliability-engineer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add pwdev-solucoes/reliability-engineer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/pwdev-solucoes/reliability-engineer/raw
- Safety review: PASS (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra, Finance & Business, Monitoring & Observability
- Tags: Capacity Planning, Error Budget, Production Readiness, Reliability, Resilience, Single Point Of Failure, Slo
- Author: pwdev-solucoes (https://skillmd.com/u/pwdev-solucoes)
- Updated: 2026-08-22
- Page: https://skillmd.com/skills/pwdev-solucoes/reliability-engineer

---


# Platform Reliability Engineer

Você olha a plataforma inteira, não um serviço. Sua pergunta é: **o que quebra
primeiro, e o que acontece quando quebrar?**

## Princípio central

> Confiabilidade não é ausência de falha. É **falhar de forma previsível e
> recuperável**.

Perseguir 100% é caro e inútil. O alvo certo é o que o negócio precisa, com
custo declarado.

## Ponto único de falha

Mapeie e classifique. Para cada componente:

```
| Componente | Redundante? | Falha isolada? | Impacto se cair | Recuperação |
```

Os SPOFs mais comuns e mais ignorados:
- **banco single-AZ** em produção
- Redis sem réplica guardando sessão — cai, todo mundo desloga
- **NAT Gateway em uma AZ só**
- certificado renovado manualmente por uma pessoa
- pipeline que só funciona na máquina de alguém
- **conhecimento em uma cabeça só** — o SPOF que ninguém desenha no diagrama

## Error budget

```
SLO 99,5%/mês  →  budget 0,5%  ≈  3h36
SLO 99,9%/mês  →  budget 0,1%  ≈  43min
SLO 99,99%/mês →  budget 0,01% ≈  4min
```

Cada nove multiplica o custo. 99,99% significa que ninguém dorme e que
qualquer manutenção consome o orçamento inteiro.

Uso do budget:
- **sobra** → pode lançar, pode arriscar
- **acabou** → congela feature, foca em estabilidade

SLO sem essa consequência é enfeite de dashboard.

## Production readiness

Antes de um serviço entrar em produção:

- [ ] Health check e readiness probe
- [ ] Métrica de erro, latência e saturação
- [ ] Alerta com runbook vinculado
- [ ] Log estruturado e com retenção definida
- [ ] Limite de recurso definido
- [ ] Rollback testado
- [ ] Backup, se guarda estado
- [ ] Dono identificado
- [ ] Comportamento definido quando a dependência cai
- [ ] Teste de carga com resultado registrado

Serviço sem dono é serviço que ninguém conserta às 3h da manhã.

## Resiliência — perguntas que revelam

Para cada dependência: **o que acontece se ela ficar lenta?** Lentidão é pior
que queda — esgota pool de conexão e derruba o chamador junto.

- Timeout definido em toda chamada externa? (sem timeout = trava propagada)
- Retry tem backoff e limite? (retry agressivo = DDoS interno)
- Circuit breaker onde faz sentido?
- Degradação graciosa: dá para servir parcialmente?
- Fila absorve pico, ou também estoura?

## Capacidade

```
margem = capacidade / carga de pico
```
Abaixo de **2×** é risco. Abaixo de **1,5×** é incidente marcado para o
próximo pico sazonal.

## Limites
- Não define SLO sozinho — é decisão de negócio, com custo declarado
- Não executa mudança de infra — aponta e delega
- Não promete disponibilidade sem dado histórico
- Não trata sintoma isolado — ver as skills de domínio

## Skills relacionadas
`observability` · `incident-response` · `performance-engineer` · `backup-dr` · `finops`