SLOs e Error Budgets: da definição ao burn rate alert

# Definindo SLIs em Prometheus
# Métrica base: contador de requests por status
# Instrumentado pelo servidor HTTP automaticamente (ou manualmente):

from prometheus_client import Counter

REQUEST_COUNTER = Counter(
    'http_requests_total',
    'Total HTTP requests',
    ['method', 'handler', 'status_code']
)

# SLI de Availability: requests com 5xx são falhas
# PromQL:
availability_sli = """
  sum(rate(http_requests_total{status_code!~"5.."}[5m]))
  /
  sum(rate(http_requests_total[5m]))
"""

# SLI de Latência: requests abaixo de 300ms (histograma)
from prometheus_client import Histogram

REQUEST_LATENCY = Histogram(
    'http_request_duration_seconds',
    'HTTP request duration',
    ['handler'],
    buckets=[0.1, 0.3, 0.5, 1.0, 2.0, 5.0]
)

# PromQL para latency SLI:
latency_sli = """
  sum(rate(http_request_duration_seconds_bucket{handler="/checkout",le="0.3"}[5m]))
  /
  sum(rate(http_request_duration_seconds_count{handler="/checkout"}[5m]))
"""

# Prometheus alerting rules — multi-window multi-burn rate
# SLO: 99.5% availability no checkout em janela de 30 dias

groups:
  - name: slo.checkout.availability
    rules:
      # SLI: proporção de requests bem-sucedidos
      - record: job:slo_checkout_success_rate:ratio_rate5m
        expr: |
          sum(rate(http_requests_total{job="checkout",status!~"5.."}[5m]))
          /
          sum(rate(http_requests_total{job="checkout"}[5m]))

      - record: job:slo_checkout_success_rate:ratio_rate1h
        expr: |
          sum(rate(http_requests_total{job="checkout",status!~"5.."}[1h]))
          /
          sum(rate(http_requests_total{job="checkout"}[1h]))

      - record: job:slo_checkout_success_rate:ratio_rate6h
        expr: |
          sum(rate(http_requests_total{job="checkout",status!~"5.."}[6h]))
          /
          sum(rate(http_requests_total{job="checkout"}[6h]))

      - record: job:slo_checkout_success_rate:ratio_rate3d
        expr: |
          sum(rate(http_requests_total{job="checkout",status!~"5.."}[3d]))
          /
          sum(rate(http_requests_total{job="checkout"}[3d]))

      # P1: Burn rate 14.4× — incidente crítico
      # Janela curta (5m) E janela longa (1h) devem satisfazer
      # Reduz false positives de spikes breves
      - alert: CheckoutSLOBurnRateCritical
        expr: |
          (
            (1 - job:slo_checkout_success_rate:ratio_rate5m) > (14.4 * 0.005)
            AND
            (1 - job:slo_checkout_success_rate:ratio_rate1h) > (14.4 * 0.005)
          )
        for: 2m
        labels:
          severity: critical
          team: checkout
        annotations:
          summary: "Checkout SLO: burn rate crítico (14.4×)"
          description: |
            Error rate atual: {{ $value | humanizePercentage }}
            Budget consumido em: ~2 dias se continuar.
            Runbook: https://wiki/checkout-slo-runbook

      # P2: Burn rate 6× — degradação significativa
      - alert: CheckoutSLOBurnRateHigh
        expr: |
          (
            (1 - job:slo_checkout_success_rate:ratio_rate30m) > (6 * 0.005)
            AND
            (1 - job:slo_checkout_success_rate:ratio_rate6h) > (6 * 0.005)
          )
        for: 15m
        labels:
          severity: warning
          team: checkout
        annotations:
          summary: "Checkout SLO: burn rate elevado (6×)"

      # P3: Burn rate 3× — degradação lenta (só janela longa)
      - alert: CheckoutSLOBurnRateSlow
        expr: |
          (1 - job:slo_checkout_success_rate:ratio_rate3d) > (3 * 0.005)
        for: 1h
        labels:
          severity: warning
          team: checkout
        annotations:
          summary: "Checkout SLO: degradação silenciosa nos últimos 3 dias"

# Error Budget Policy — Checkout Service
Documento: v1.2 | Owner: SRE Platform | Aprovado: 2024-01-10

## SLO
- Availability: ≥ 99.5% em janela rolling de 30 dias
- Latência P95: ≤ 500ms em janela rolling de 30 dias

## Estados do Error Budget

### 🟢 Verde (> 50% budget restante)
- Time pode lançar features normalmente
- Deploy a qualquer momento dentro da janela de mudança (Ter-Qui 10h-16h)
- Post-deployment monitoring: 30 min

### 🟡 Amarelo (10-50% budget restante)
- Deploy limitado: máximo 1 feature/semana
- Código de alto risco (mudança de DB, integração externa) requer revisão adicional
- SRE co-aprova PRs de infra
- Post-deployment monitoring: 2h com rollback automático disponível

### 🔴 Vermelho (< 10% budget restante)
- Feature freeze: ZERO novos deploys de features
- Apenas hotfixes de confiabilidade e segurança crítica
- Daily standup inclui SRE lead obrigatoriamente
- Time de produto notificado e impacto comunicado em roadmap
- Revisão de causa raiz obrigatória antes de retornar ao amarelo

### 🚨 Budget esgotado (0%)
- Freeze total: apenas rollbacks e hotfixes de segurança P0
- Post-mortem obrigatório em 48h
- Plano de ação com milestones em 7 dias
- Escalonamento para VP Engineering se não resolver em 14 dias

## Exceções
- Patches de segurança crítica (CVE CVSS ≥ 9.0): sempre permitidos
- Releases regulatórios (compliance, LGPD): aprovação explícita de VP Eng + CTO

# Grafana dashboard: SLO tracker (JSON model resumido)
# Panels principais para um dashboard de SLO:

panels:
  # 1. SLO Gauge — "Estamos dentro do SLO?"
  - title: "SLO Compliance (30d)"
    type: gauge
    query: |
      sum(increase(http_requests_total{job="checkout",status!~"5.."}[30d]))
      /
      sum(increase(http_requests_total{job="checkout"}[30d]))
    thresholds: [0.995: green, 0.99: yellow, 0: red]

  # 2. Error Budget Remaining
  - title: "Error Budget Restante"
    type: stat
    query: |
      (
        sum(increase(http_requests_total{job="checkout",status!~"5.."}[30d]))
        /
        sum(increase(http_requests_total{job="checkout"}[30d]))
        - 0.995
      ) / 0.005 * 100
    unit: percent

  # 3. Burn Rate (1h)
  - title: "Burn Rate (1h)"
    type: timeseries
    query: |
      (1 - job:slo_checkout_success_rate:ratio_rate1h) / 0.005
    alert_threshold: 14.4

  # 4. Error rate breakdown por status code
  - title: "Errors por Status Code"
    type: timeseries
    query: |
      sum by(status_code) (
        rate(http_requests_total{job="checkout",status=~"5.."}[5m])
      )