Curso Kubernetes 27 — SLO/SLI, on-call e postmortem blameless

"Está no ar" não é SLO. SLO é um compromisso numérico com o usuário, com janela e consequência. Sem isso, toda discussão de confiabilidade vira opinião.

Este capítulo fecha a parte de operação: o que prometer, como medir, quando acordar alguém e como aprender sem caçar culpado.

Selo do curso: aplicado em ambiente com SLO de 99,5% mensal.

SLI, SLO e SLA

Termo	Definição	Exemplo
SLI	indicador medido	% de requests com status < 500 e latência < 500 ms
SLO	meta para o SLI	99,5% em 30 dias
SLA	contrato com consequência	99,5% com crédito/penalidade
Error budget	margem de erro	0,5% = ~3h36min por mês

SLO é interno e orienta decisões. SLA é externo e tem dinheiro envolvido. Nunca prometa SLA maior que o SLO que você mede.

Escolhendo o SLI

Poucos e bons. Para um portal:

1. Disponibilidade: proporção de requests bem-sucedidos.
2. Latência: proporção de requests abaixo do limite (não a média).
3. Qualidade de dado (quando crítico): jobs que processaram sem erro.

Evite:

• uptime de pod como SLI (o usuário não vê pod);
• média de latência;
• métrica que ninguém consegue medir neste trimestre.

Definindo o SLO

slo: disponibilidade-api
target: 99.5
window: 30d
sli:
  good: http_requests_total{status!~"5.."}
  total: http_requests_total

Cálculo em PromQL:

sum(rate(http_requests_total{job="portal-backend",status!~"5.."}[5m]))
/
sum(rate(http_requests_total{job="portal-backend"}[5m]))

Error budget queimado:

1 - (
  sum(rate(http_requests_total{job="portal-backend",status!~"5.."}[30d]))
  /
  sum(rate(http_requests_total{job="portal-backend"}[30d]))
) / 0.005

99,5% em 30 dias = 3h36min de indisponibilidade total equivalente.

Burn rate: alerta que vale acordar alguém

Alertar em "1 erro" gera fadiga. Alerta bom olha a velocidade de consumo do budget:

Burn rate	Janela	Ação
14,4x	1h	página (acorda)
6x	6h	ticket urgente
1x	3d	backlog

(
  sum(rate(http_requests_total{job="portal-backend",status=~"5.."}[1h]))
  /
  sum(rate(http_requests_total{job="portal-backend"}[1h]))
) > (14.4 * 0.005)

Isso derruba o ruído: 0,1% de erro em 5 minutos não acorda ninguém; 5% por uma hora sim.

On-call que funciona

• Rodízio semanal, com handoff escrito.
• Runbook por alerta: o que checar, o que fazer, como escalar.
• Acesso pronto: VPN, kubectl, dashboards, logs — testado antes do plantão.
• Um alerta, uma ação. Alerta sem ação é ruído.
• Página só para sintoma do usuário, não para CPU alta isolada.

Checklist de handoff:

- Incidentes abertos e estado
- Deploys na janela
- Alertas silenciados e por quê
- Riscos conhecidos (disco, capacidade, certificado)

Postmortem blameless

Premissa: pessoas agem com a informação que têm. O objetivo é corrigir sistema, não pessoa.

Estrutura:

1. Resumo (5 linhas).
2. Impacto: usuários, duração, SLO queimado.
3. Linha do tempo (minuto a minuto).
4. Causa raiz e fatores contribuintes.
5. O que funcionou (detecção, rollback, comunicação).
6. O que falhou.
7. Ações com dono e prazo.

Regras:

• Escrito em até 72h, com quem participou.
• Sem "falha humana" como causa final. A pergunta é: por que o sistema permitiu?
• Ação sem dono e data não existe.
• Compartilhado com o time inteiro.

Exemplo de causa mal escrita: "o operador apagou o PVC errado". Versão útil: "não havia proteção contra deleção de PVC de produção; o comando era destrutivo e sem confirmação; não havia backup recente do volume".

Ligando SLO a decisão

• Budget sobrando: pode acelerar mudanças.
• Budget queimando: priorize confiabilidade, congele feature arriscada.
• Budget estourado: revisão de arquitetura, não "trabalhar mais".

Isso transforma confiabilidade em conversa de produto — e tira o SRE do papel de bombeiro eterno.

Laboratório

1. Instrumente a API com contador de requests por status.
2. Crie as regras de SLI e um painel de SLO no Grafana.
3. Calcule o budget restante do mês.
4. Configure um alerta de burn rate 14,4x/1h.
5. Injete erros 500 por 10 minutos e veja o alerta disparar.
6. Escreva um postmortem simulado com linha do tempo e três ações.
7. Faça um handoff de plantão em 10 linhas.

Erros comuns

Sintoma	Causa
Alerta ignorado	threshold sem burn rate
SLO nunca cumprido	meta copiada de empresa maior
Postmortem vira culpa	foco em pessoa, não em sistema
Ação não executada	sem dono/prazo
SLI não mede usuário	métrica interna (pod up)
Budget infinito na prática	ninguém olha o painel
On-call sem runbook	conhecimento só na cabeça de um

Checklist

• [ ] SLI definido a partir da experiência do usuário.
• [ ] SLO com janela e target explícitos.
• [ ] Error budget calculado e visível.
• [ ] Alertas por burn rate, não por evento isolado.
• [ ] Runbook por alerta crítico.
• [ ] Rodízio e handoff documentados.
• [ ] Postmortem em 72h, blameless, com ações rastreadas.
• [ ] Revisão mensal de SLO e budget.

Glossário

• SLI: indicador medido.
• SLO: meta do indicador.
• SLA: contrato com consequência.
• error budget: margem de falha permitida.
• burn rate: velocidade de consumo do budget.
• blameless: análise sem culpa individual.
• handoff: passagem de plantão.

Próximo

Último capítulo: DR e capstone. RPO/RTO na prática, drills de restore e o fechamento do curso com o que levar para produção.

Próximo: Curso Kubernetes 28 — DR e capstone