DevOpsQuest
0 XP
Módulo 10 · Observabilidade e SRE

SLI, SLO, error budget e postmortem sem culpa

Avançado 50 min+25 XPSREGrafanaRunbooks

Objetivos desta aula

  • Definir SLI e SLO do CloudShop
  • Calcular e usar error budget
  • Conduzir incidente e escrever postmortem

SLI é a medida da experiência (proporção de requisições bem-sucedidas abaixo de 500 ms, por exemplo). SLO é a meta interna sobre esse indicador. SLA é o compromisso contratual, geralmente mais frouxo que o SLO. Confiabilidade deixa de ser opinião quando existe número.

Error budget é o complemento do SLO: com meta de 99,9% em 30 dias, você tem cerca de 43 minutos de falha permitida. Esse número orienta decisão: budget sobrando permite acelerar entregas; budget estourado obriga a priorizar estabilidade. É a ferramenta que encerra a discussão entre 'entregar rápido' e 'ficar estável'.

Incidente tem papéis (comandante, comunicação, investigação), registro de linha do tempo e foco em mitigar antes de entender. Depois vem o postmortem sem culpa: fatos, impacto medido, causas contribuintes, o que funcionou e ações com responsável e prazo. Culpar pessoa esconde falha de sistema e garante repetição.

1. SLI, SLO e SLA

  • SLI: a medida (ex.: % de requisições de checkout com sucesso em menos de 500 ms)
  • SLO: a meta interna (99,5% em 30 dias)
  • SLA: o contrato com o cliente, com multa — sempre mais frouxo que o SLO

2. Error budget

Um SLO de 99,5% permite 0,5% de falha: em 30 dias, cerca de 3h36min. Enquanto há orçamento, o time lança à vontade; quando acaba, prioriza estabilidade. Isso transforma briga entre produto e operação em regra combinada.

3. Alertas por burn rate

Em vez de alertar a cada erro, alerte quando o orçamento está sendo gasto rápido demais: queimar 2% em 1 hora (taxa 14,4) é página imediata; 10% em 3 dias é ticket.

4. Resposta a incidente

Papéis claros (comandante, comunicação, operação), canal único, linha do tempo registrada. Primeiro mitigar (rollback, desligar feature flag), depois investigar.

5. Postmortem sem culpa

Foco no sistema, não na pessoa: linha do tempo, impacto, causa raiz com 5 porquês, o que ajudou, o que atrapalhou e ações com dono e prazo. Se uma pessoa conseguiu derrubar produção com um comando, o problema é o processo que permitiu.

Na prática

SLO do CloudShop documentado

yaml

servico: cloudshop-api
janela: 30d
slis:
  - nome: disponibilidade
    definicao: proporcao de requisicoes com status < 500
    consulta: |
      sum(rate(http_request_duration_seconds_count{status!~"5.."}[30d]))
        / sum(rate(http_request_duration_seconds_count[30d]))
    slo: 99.9%
    budget: 43m 12s
  - nome: latencia
    definicao: proporcao de requisicoes abaixo de 500ms
    consulta: |
      sum(rate(http_request_duration_seconds_bucket{le="0.5"}[30d]))
        / sum(rate(http_request_duration_seconds_count[30d]))
    slo: 95%
politica:
  budget_esgotado: congelar entregas de funcionalidade e priorizar confiabilidade
  budget_saudavel: liberar deploys frequentes e experimentos controlados

Modelo de postmortem

markdown

# Postmortem — Indisponibilidade da API (2026-09-14)

**Impacto:** 22 minutos com 78% das requisicoes em erro; 41% do error budget mensal consumido.
**Deteccao:** alerta TaxaDeErroAlta em 14:03 (usuarios comecaram a falhar 14:01).

## Linha do tempo (UTC)
- 14:01 deploy v1.4.0 aplicado
- 14:03 alerta critico disparado
- 14:07 hipotese: pool de conexoes esgotado (traces mostram espera no banco)
- 14:16 rollback para v1.3.2 iniciado
- 14:23 metricas normalizadas

## Causas contribuintes
1. Nova rota abria conexao por requisicao sem devolver ao pool.
2. Teste de carga nao cobria essa rota.
3. Alerta de saturacao do pool nao existia.

## O que funcionou
- Rollback automatizado levou 7 minutos.
- Runbook de 5xx acelerou o diagnostico.

## Acoes
| Acao | Responsavel | Prazo |
|---|---|---|
| Corrigir vazamento de conexao e cobrir com teste | Aluno | 2026-09-16 |
| Alerta de saturacao do pool | Aluno | 2026-09-18 |
| Teste de carga nas rotas de escrita no CI | Time | 2026-09-30 |

**Sem culpa:** a pessoa seguiu o processo existente; o sistema permitiu que a falha chegasse a producao.

Cálculo do error budget

text

SLO 99,5% em 30 dias
30 dias = 43.200 min
Orçamento = 43.200 x 0,005 = 216 min (~3h36)
Incidente de 40 min -> restam 176 min (81% do orçamento)

Alerta de burn rate rápido

promql

(
  sum(rate(http_requests_total{route="/checkout",status=~"5.."}[1h]))
  / sum(rate(http_requests_total{route="/checkout"}[1h]))
) > (14.4 * 0.005)

Por que isso importa

SLO e postmortem são o vocabulário de SRE em entrevistas de nível pleno e sênior.

Erro comum

Definir SLO de 99,99% sem arquitetura nem orçamento para sustentá-lo.

Dica de produção

Alerte por burn rate do error budget, não por qualquer desvio: reduz drasticamente ruído.

Alerta de segurança

Postmortem pode conter dado sensível de cliente; publique versão interna e versão sanitizada.

Pergunta de entrevista

Explique error budget e como ele influencia a decisão de lançar uma funcionalidade.

Glossário

error budget
Quantidade de falha permitida pelo SLO em uma janela de tempo.
postmortem sem culpa
Análise focada em falhas de sistema e processo, não em pessoas.
Error budget
Quantidade de falha permitida pelo SLO em um período.
Burn rate
Velocidade com que o error budget está sendo consumido.
Blameless
Postmortem focado em causas sistêmicas, sem culpar pessoas.

Conexão com o CloudShop

Publicar o SLO do CloudShop e o postmortem do incidente do módulo.

Quiz da aula

  1. 1. SLO de 99,9% em 30 dias permite aproximadamente quanto de indisponibilidade?

  2. 2. SLO de 99,9% em 30 dias permite aproximadamente quanto de indisponibilidade?

  3. 3. O error budget acabou. O que o time deve fazer?

Minhas anotações

Salvo automaticamente neste navegador.

AnteriorPróxima