SRE na prática: SLOs, SLIs e error budgets para times pequenos

1. Por que times pequenos precisam de SRE (mesmo sem dedicar um engenheiro só para isso)

O mito de que SRE é privilégio de big techs como Google ou Netflix precisa ser desconstruído. Times pequenos — com 3 a 10 desenvolvedores — enfrentam os mesmos problemas de confiabilidade, mas com menos recursos para apagões noturnos e retrabalho. A diferença é que, sem uma abordagem estruturada, cada incidente vira uma crise que consome horas preciosas de desenvolvimento.

A boa notícia: você não precisa de um engenheiro dedicado a SRE. Precisa apenas de disciplina para aplicar os princípios certos. O foco deve ser reduzir toil (trabalho manual repetitivo) e priorizar confiabilidade sem criar burocracia. Ferramentas gratuitas como Prometheus, Grafana e Uptime Kuma já entregam 80% do que você precisa para começar.

2. Definindo SLIs práticos: o que medir quando você tem poucos recursos

Os quatro sinais de ouro do SRE — latência, tráfego, erros e saturação — podem ser simplificados drasticamente para times pequenos. Em vez de medir tudo, foque no que afeta diretamente o usuário final.

Exemplo de SLIs para uma API REST:

# SLI 1: Proporção de requisições com latência < 500ms (p95)
SLI_LATENCIA = total_requisicoes_menor_500ms / total_requisicoes

# SLI 2: Proporção de requisições sem erro HTTP 5xx
SLI_ERROS = total_requisicoes_ok / total_requisicoes

# SLI 3: Proporção de requisições com resposta completa (sem timeouts)
SLI_COMPLETUDE = total_respostas_completas / total_requisicoes

Para filas de mensagens:

# SLI 1: Proporção de mensagens processadas em até 30 segundos
SLI_PROCESSAMENTO = mensagens_processadas_em_30s / mensagens_enfileiradas

# SLI 2: Proporção de mensagens sem erro de processamento
SLI_ERRO_FILA = mensagens_processadas_com_sucesso / mensagens_processadas

Evite métricas "vaidade" como número de servidores ou uso de CPU global. Elas não refletem a experiência real do usuário. Seu banco de dados pode estar com 90% de CPU, mas se o usuário não sente lentidão, esse não é seu SLI mais importante.

3. SLOs realistas: como negociar com stakeholders sem prometer 99,999%

Definir SLOs (Service Level Objectives) baseados em dados históricos é o caminho mais seguro. Mesmo que você tenha apenas alguns meses de métricas, use esses dados como baseline.

Tabela de referência de downtime por mês:

Disponibilidade | Downtime mensal | Downtime anual
99,0%           | 7,2 horas       | 3,65 dias
99,5%           | 3,6 horas       | 1,83 dias
99,9%           | 43,8 minutos    | 8,76 horas
99,95%          | 21,9 minutos    | 4,38 horas
99,99%          | 4,4 minutos     | 52,6 minutos
99,999%         | 26 segundos     | 5,26 minutos

Ao negociar com stakeholders, traduza os números para linguagem de negócio: "99,9% significa que podemos ter até 43 minutos de falha por mês. Isso é suficiente para cobrir uma manutenção programada de 30 minutos e ainda sobra margem para imprevistos."

Exemplo de SLO realista para uma API de e-commerce:

SLO_LATENCIA: 95% das requisições completadas em < 500ms (janela de 30 dias)
SLO_DISPONIBILIDADE: 99,5% de uptime (janela de 30 dias)
SLO_ERROS: 99,9% das requisições sem erro 5xx (janela de 30 dias)

4. Error budgets na prática: quando acelerar e quando desacelerar

O error budget é o total de falhas permitidas dentro do SLO. Seu cálculo é simples:

Error Budget = (1 - SLO) * Total de eventos no período

Exemplo:
SLO de disponibilidade = 99,5%
Total de minutos no mês = 43.200 (30 dias)
Error Budget = (1 - 0,995) * 43.200 = 216 minutos de falha permitidos por mês

Gatilhos de ação práticos:

# Se o error budget consumido está em:
0-50%   → Deploys normais, sem restrições
50-80%  → Revisão de código mais rigorosa, testes extras
80-100% → Congelamento de deploys não críticos, priorização de bugs
>100%   → Incidente crítico: pare tudo, foque em restaurar confiabilidade

Para times pequenos, o error budget é uma ferramenta de negociação poderosa. Quando o budget está acabando, você pode justificar uma pausa técnica sem culpa: "Pessoal, nosso error budget de latência está em 85%. Precisamos de dois dias para investigar e corrigir antes de lançar a nova feature."

5. Monitoramento enxuto: dashboards e alertas que não viram barulho

O anti-padrão mais comum em times pequenos é alertar tudo que se move. Resultado: alertas viram barulho e ninguém presta atenção. A regra de ouro é: só alerte sobre algo que exija ação imediata.

Exemplo de dashboard minimalista com PromQL:

# Dashboard no Grafana (fictício, mas representativo)
# Painel 1: SLI de Latência (p95 nos últimos 5 minutos)
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))

# Painel 2: SLO de Latência (percentual dentro do alvo)
sum(rate(http_request_duration_seconds_bucket{le="0.5"}[5m])) 
/ sum(rate(http_request_duration_seconds_count[5m])) * 100

# Painel 3: Error Budget Restante (em %)
1 - (sum(rate(http_requests_total{status=~"5.."}[30d])) 
/ (sum(rate(http_requests_total[30d])) * 0.005))

Multi-window, multi-burn-rate alerts:

# Alerta de burn rate rápida (queima em 1 hora)
ALERT AltaBurnRate
IF (
  (1 - (sum(rate(http_requests_total{status=~"5.."}[1h])) 
  / sum(rate(http_requests_total[1h]))))
  < 0.995
)
FOR 5m
LABELS { severity = "critical" }
ANNOTATIONS { summary = "Error budget queimando rápido demais" }

Esse alerta só dispara se a taxa de erros se mantiver alta por 5 minutos consecutivos, evitando falsos positivos de picos isolados.

6. Iterando sem dados históricos: como começar do zero em um projeto legado

Se você está começando sem dados históricos, use a técnica de baseline. Colete métricas das primeiras duas semanas e use os percentis como SLO provisório.

Exemplo de baseline:

# Coleta inicial (2 semanas)
p50_latencia = 120ms
p95_latencia = 480ms
p99_latencia = 950ms

# SLO provisório (baseado no p95 real)
SLO_LATENCIA_PROVISORIO = 95% das requisições em < 500ms

# Após 1 mês, refine
p95_latencia_real = 430ms
SLO_LATENCIA_REFINADO = 95% das requisições em < 450ms

Ferramentas open source que já entregam métricas prontas:

  • cAdvisor: métricas de contêineres (CPU, memória, rede)
  • node_exporter: métricas do sistema operacional
  • blackbox_exporter: monitoramento de endpoints HTTP, TCP, ICMP
  • Uptime Kuma: monitoramento simples de uptime com notificações

7. Cultura de confiabilidade sem um time de SRE dedicado

Criar uma cultura de confiabilidade não requer reuniões intermináveis. Rituais leves funcionam melhor:

  • Daily de confiabilidade (5 minutos): "O error budget de latência está em 70%. Alguém viu algo estranho nos logs?"
  • Review semanal de error budget (15 minutos): "Na última semana consumimos 10% do budget. O pico foi na terça-feira, quando lançamos a versão 2.3."

Para engajar devs resistentes, mostre vitórias rápidas:

# Antes do SRE: incidente de latência alta a cada 3 dias
# Depois do SRE (2 meses): incidente a cada 2 semanas
# Redução de 75% no tempo gasto em incidentes

Documentação mínima: um runbook de 1 página contendo:

  • SLIs ativos e como acessá-los
  • SLOs acordados com stakeholders
  • Procedimentos de emergência (quem chamar, o que fazer)
  • Link para o dashboard principal

8. Próximos passos: quando escalar a abordagem de SRE

Sinais de que sua prática de SLOs está madura:

  • Redução consistente de incidentes mês a mês
  • Previsibilidade de deploys (sabe-se quando algo vai quebrar o budget)
  • Times começam a pedir mais SLIs, não menos

Quando evoluir:

  1. SLAs: transforme SLOs internos em acordos formais com clientes (apenas quando tiver 6+ meses de dados consistentes)
  2. SLOs multi-camada: serviço → plataforma → cliente (ex: API de pagamento → plataforma de e-commerce → loja do cliente)
  3. Ferramentas avançadas: adote OpenTelemetry para tracing distribuído e Grafana Stack completa (Loki + Tempo + Mimir) sem sobrecarga inicial — comece com um serviço piloto

Lembre-se: SRE para times pequenos não é sobre ferramentas caras ou equipes dedicadas. É sobre disciplina, métricas centradas no usuário e decisões baseadas em dados. Comece pequeno, meça o que importa e itere rápido.

Referências