SLIs, SLOs e Error Budgets na Prática de SRE: Governança de Confiabilidade, OpenTelemetry e Alertas Multi-Burn-Rate em Alta Escala

A maior fricção entre times de Produto (que querem entregar features rapidamente) e times de Operações (que buscam estabilidade estrita) é resolvida por um único mecanismo matemático: o Error Budget (Orçamento de Erro). No modelo moderno de Site Reliability Engineering (SRE), confiabilidade de 100% é a meta errada para quase qualquer software: perseguir 100% de disponibilidade asfixia a inovação e encarece a infraestrutura exponencialmente sem benefício perceptível ao usuário final.

1. A Tríade do SRE: SLI, SLO e SLA Sem Ambiguidade

Muitas organizações usam essas três siglas como sinônimos intercambiáveis, gerando confusão operacional e alertas inúteis:

• SLI (Service Level Indicator): A métrica quantitativa observável em tempo real do nível de serviço prestado. Exemplo: 'A proporção de requisições HTTP válidas de checkout que retornam código 2xx em menos de 250ms medida na borda do ingress'.
• SLO (Service Level Objective): A meta interna acordada entre Produto, Engenharia e Negócios. Exemplo: '99,95% das requisições de checkout devem cumprir o SLI ao longo de uma janela móvel de 30 dias'.
• SLA (Service Level Agreement): O contrato jurídico formal com o cliente final, contendo penalidades financeiras ou devolução de créditos caso o serviço fique abaixo de um limite mais permissivo (por exemplo, 99,5%).

Quadro Comparativo: Monitoramento Clássico vs. Governança SRE Better2Better

2. O Que É o Error Budget e Como Ele Governa o Ciclo de Releases

Se o seu SLO de disponibilidade para o serviço de pagamento é de 99,9% em 30 dias, isso significa que seu Error Budget é de 0,1% (aproximadamente 43 minutos de indisponibilidade permitida por mês). Esse orçamento pertence tanto ao time de Produto quanto à Engenharia:

1. Enquanto houver Error Budget sobrando: Os desenvolvedores têm carta branca para experimentar, lançar novas funcionalidades, refatorar código e realizar deploys frequentes.
2. Se o Error Budget for totalmente consumido: Uma Política de Congelamento de Releases (Release Freeze) entra em vigor automaticamente. Nenhum novo recurso de produto vai para produção até o ciclo seguinte; 100% da capacidade dos squads de engenharia é redirecionada para corrigir débitos técnicos, criar testes automatizados e reforçar a infraestrutura.

3. Alertas Avançados: O Algoritmo Multi-Window Multi-Burn-Rate do Google SRE

Alertas ingênuos baseados em limiares estáticos (como 'erro > 1% nos últimos 5 minutos') sofrem de dois problemas fatais: ou disparam dezenas de falsos alarmes para picos transitórios irrelevantes, ou falham em acordar a equipe durante sangrias lentas que consom todo o orçamento em poucas horas.

O padrão de ouro implementado pela Better2Better é o Multi-Window Multi-Burn-Rate:

• Burn Rate 14.4x (Consumo de 2% do orçamento em 1 hora): Alerta de severidade máxima (Page / Ligação de emergência PagerDuty) com janelas de 1h e 5 minutos simultâneas.
• Burn Rate 6x (Consumo de 5% do orçamento em 6 horas): Alerta de severidade alta (janelas de 6h e 30 minutos).
• Burn Rate 1x (Consumo de 10% do orçamento em 3 dias): Notificação por ticket assíncrono (Slack/Jira) para análise em horário comercial sem perturbar o sono do plantonista.

4. Observabilidade Moderna: OpenTelemetry Distribuído e Semântica Unificada

A fragmentação de ferramentas de observabilidade é o maior desperdício de investimento em TI. Adotamos o padrão aberto OpenTelemetry (OTel):

Instrumentamos microsserviços heterogêneos (Go, TypeScript, Java, Python, Rust) com coletores OTel padronizados. Todo trace distribuído propaga o traceparent via W3C Trace Context em headers HTTP e mensagens Kafka, permitindo correlacionar uma requisição no frontend com o query SQL exato no banco de dados e as métricas de CPU do nó Kubernetes em uma única linha do tempo visual.

5. Implementação Prática: Regra de Alerta Multi-Burn-Rate em PromQL

Abaixo apresentamos a regra oficial de alerta para Prometheus/Grafana calculando a queima de Error Budget de disponibilidade:

groups:
  - name: slo_checkout_alerts
    rules:
      - alert: CheckoutErrorBudgetBurn14x
        expr: |
          (
            sum(rate(http_requests_total{job="checkout", status=~"5.."}[1h]))
            /
            sum(rate(http_requests_total{job="checkout"}[1h]))
          ) > (14.4 * (1 - 0.999))
          and
          (
            sum(rate(http_requests_total{job="checkout", status=~"5.."}[5m]))
            /
            sum(rate(http_requests_total{job="checkout"}[5m]))
          ) > (14.4 * (1 - 0.999))
        for: 2m
        labels:
          severity: page
        annotations:
          summary: "Checkout API está queimando Error Budget a 14.4x (2% do orçamento mensal consumido em 1 hora)"
          runbook_url: "https://wiki.better2better.com.br/sre/runbooks/checkout-burn-rate"

6. Cultura de Post-Mortem Sem Culpa (Blameless Post-Mortem)

Quando uma falha crítica acontece, a pior reação de uma liderança técnica é buscar um 'culpado humano' para punir. Humanos erram invariavelmente; se um único erro de digitação de um desenvolvedor conseguiu derrubar o sistema bancário, o culpado é a arquitetura frágil e a ausência de guardrails, nunca o indivíduo. Nossos relatórios de post-mortem focam na cronologia dos fatos, na eficácia da detecção e na criação de itens de ação preventivos prioritários.

7. Checklist de Maturidade SRE Corporativa

• [x] Todos os serviços críticos possuem SLIs mensurados na perspectiva do usuário final.
• [x] SLOs formalmente acordados com assinaturas de Produto, Engenharia e Diretoria.
• [x] Alertas reconfigurados para queima de Error Budget com eliminação total de alertas de CPU pontual.
• [x] Rastreamento distribuído OpenTelemetry com propagação W3C Trace Context habilitada.
• [x] Política formalizada de Release Freeze acionada automaticamente por esgotamento de orçamento.

8. Perguntas Frequentes sobre SRE, SLOs e Observabilidade (FAQ)