Postmortem + SLO Definition

# Postmortem — [Incidente / título descritivo]

**Status:** Draft / Final
**Author:** [seu nome]
**Reviewers:** [tech lead, EM, on-call do incidente]
**Date of incident:** [YYYY-MM-DD HH:MM TZ]
**Date of postmortem:** [YYYY-MM-DD]
**Severity:** SEV1 / SEV2 / SEV3
**Duration:** [N minutos/horas]

> ⚠️ Este postmortem é **blameless**. O foco é entender o sistema e
> melhorá-lo — não atribuir culpa individual. Engenheiros agem com
> a melhor informação disponível no momento; falhas são propriedade
> do sistema, não da pessoa.

---

## Resumo executivo
[2-3 parágrafos. O que aconteceu, quem foi afetado, por quanto
tempo, qual o impacto.]

## Impacto
- **Usuários afetados:** [número, % do total]
- **Receita afetada:** [estimativa em $]
- **Funcionalidades degradadas:** [lista]
- **SLO impact:** error budget consumido = [X% / Y minutos]
- **Ticket count durante incidente:** [N]

## Timeline (em UTC ou TZ definida)

| Hora | Evento | Quem agiu |
|------|--------|-----------|
| 14:32 | Deploy de v2.4.0 ao production | @alice (CI automatizado) |
| 14:38 | Alerta HighErrorRate dispara | PagerDuty → @bob |
| 14:39 | @bob recebe e começa investigação | @bob |
| 14:44 | @bob identifica deploy como suspeita | @bob |
| 14:46 | Rollback iniciado | @bob |
| 14:51 | Rollback completo, error rate volta ao normal | @bob |
| 14:55 | @bob declara incidente resolvido | @bob |
| 15:00 | Início da investigação de causa raiz | @bob, @alice |
| 16:30 | Causa raiz identificada (regex em validador) | @alice |

## Causa raiz
[Análise técnica detalhada. O que efetivamente causou o problema?
Por que não foi pego antes? Os "5 porquês" se útil.]

### "5 porquês" do incidente
1. **Por quê** o serviço retornou 500? — A função X lançou exceção
   não-tratada
2. **Por quê** lançou exceção? — Regex de validação não suportava
   um caso de input específico
3. **Por quê** o regex não suportava? — Foi escrito assumindo
   somente caracteres ASCII; input em UTF-8 multi-byte falhou
4. **Por quê** chegou a produção? — Testes não cobriam input
   multi-byte
5. **Por quê** os testes não cobriam? — Cobrir todos os casos de
   input não estava em nossa lista de cenários canônicos

## O que funcionou bem
- Alerta disparou em < 30s (resposta rápida)
- @bob diagnosticou e mitigou em 13 min (excelente RTO)
- Rollback automatizado funcionou sem incidente

## O que poderia ter ido melhor
- Não tínhamos teste para input multi-byte → bug em produção
- Dashboard não tinha breakdown por tipo de input → diagnóstico
  levou alguns minutos a mais que o ideal
- Não tínhamos canary deploy → todos os usuários afetados, não só
  uma fração

## Onde tivemos sorte
- Incidente em horário de baixa carga (3h da manhã UTC) — impacto
  menor que poderia ter sido
- @bob estava de plantão e tem experiência específica neste serviço

## Action items

| ID | Item | Owner | Severidade | Prazo |
|----|------|-------|------------|-------|
| AI-01 | Adicionar suite de testes para input multi-byte | @alice | P0 | 2 semanas |
| AI-02 | Configurar canary deploy (5% de tráfego por 30 min) | @bob | P1 | 1 mês |
| AI-03 | Adicionar breakdown por encoding no dashboard | @charlie | P2 | 1 mês |
| AI-04 | Documentar "tipos de input testáveis" no PR template | @alice | P2 | 2 semanas |

## Lições aprendidas (para o time)
- [Lição 1 — algo que vamos lembrar e aplicar]
- [Lição 2]

# SLO Definition — [Nome do serviço]

**Owner:** [time]
**Última revisão:** [YYYY-MM-DD]
**Próxima revisão:** [trimestral]

## Service Level Indicators (SLI)

### SLI-1: Disponibilidade
**Definição:** % de requests bem-sucedidas (HTTP 2xx ou 3xx) sobre
total de requests, exclusos requests inválidas (4xx por culpa do
cliente).

**Como medir:**
\`\`\`
sum(rate(http_requests_total{status=~"2..|3.."}[5m]))
  /
sum(rate(http_requests_total{status!~"4.."}[5m]))
\`\`\`

### SLI-2: Latência
**Definição:** % de requests respondidas em < 200 ms (P99).

**Como medir:**
\`\`\`
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))
  < 0.2
\`\`\`

## Service Level Objectives (SLO)
| SLI | Target | Janela | Error Budget |
|-----|--------|--------|--------------|
| Disponibilidade | 99.9% | 30 dias | 43.2 min |
| Latência P99 | 99% das requests < 200ms | 30 dias | 1% |

## Error Budget Policy
- **> 50% restante:** modo normal — features novas seguem
- **25-50% restante:** alerta amarelo — feature work segue mas
  PRs de risco passam por revisão extra
- **< 25% restante:** alerta vermelho — feature work pausa;
  prioridade vira reduzir ações que consomem budget
- **0% (estourou):** freeze de mudanças não-essenciais até
  budget reset; postmortem dedicado obrigatório

## Alertas baseados em SLO
- **Page (acorda alguém):** burn rate > 14× (vai consumir mês de
  budget em < 1 dia se sustentar)
- **Notify (canal slack):** burn rate > 6× (vai consumir budget em
  < 1 semana)

## Stakeholders
- **Produto:** PM aceita SLO como contrato
- **SRE:** mantém dashboards e alertas
- **Engenharia:** escreve código respeitando SLO; postmortem se viola