SRE na Prática: SLOs, Error Budgets e Incident Management

O que é SRE?

Site Reliability Engineering (SRE) é uma disciplina de engenharia de software aplicada a operações. Criada pelo Google, combina desenvolvimento de software com administração de sistemas para criar sistemas altamente confiáveis e escaláveis.

Hierarquia de Confiabilidade

SLIs, SLOs e SLAs

Definições

100%

SLI mede, SLO define objetivo interno, SLA é o compromisso externo

Esc fechar+/- zoom

Tipos Comuns de SLIs

Definindo SLOs Efetivos

# Exemplo de especificação de SLO
slo:
  name: "API Principal"
  description: "SLO para a API de produção"

  indicators:
    - name: availability
      type: ratio
      good_events: 'http_requests_total{status=~"2..|3.."}'
      total_events: 'http_requests_total'

    - name: latency
      type: threshold
      metric: 'http_request_duration_seconds'
      threshold: 0.2  # 200ms
      percentile: 99

  objectives:
    - indicator: availability
      target: 99.9
      window: 30d

    - indicator: latency
      target: 99.0
      window: 30d

  error_budget:
    calculation: "100% - SLO target"
    # 99.9% availability = 0.1% error budget
    # Em 30 dias = ~43 minutos de downtime permitido

Error Budgets

Error Budget é a quantidade de “erro” permitida antes de violar o SLO. É uma ferramenta para balancear confiabilidade e velocidade de inovação.

Cálculo do Error Budget

Error Budget = 100% - SLO Target

Exemplo para SLO de 99.9% availability em 30 dias:
- Error Budget = 0.1%
- Minutos no mês = 30 * 24 * 60 = 43,200 minutos
- Budget em minutos = 43,200 * 0.001 = 43.2 minutos

Se consumiu 20 minutos com incidentes:
- Budget restante = 43.2 - 20 = 23.2 minutos
- Budget consumido = 46%

Políticas de Error Budget

error_budget_policy:
  # Quando budget está saudável (< 50% consumido)
  healthy:
    actions:
      - "Priorizar features e inovação"
      - "Experimentação permitida"
      - "Deployments normais"

  # Quando budget está em alerta (50-80% consumido)
  warning:
    actions:
      - "Reduzir frequência de deploys"
      - "Priorizar correção de bugs"
      - "Aumentar review de changes"

  # Quando budget está crítico (> 80% consumido)
  critical:
    actions:
      - "Freeze de features"
      - "Apenas bug fixes"
      - "Todos focam em confiabilidade"

  # Quando budget estourou
  exhausted:
    actions:
      - "Freeze total de deploys"
      - "Postmortem obrigatório"
      - "Ação executiva necessária"

Incident Management

Severidades de Incidente

Processo de Resposta

100%

Processo de resposta a incidentes do Detection ao Postmortem

Esc fechar+/- zoom

Template de Postmortem

# Postmortem: [Título do Incidente]

## Resumo
- **Data**: 2025-01-02
- **Duração**: 45 minutos
- **Impacto**: 15% dos usuários afetados
- **Severidade**: SEV2

## Timeline
- 14:00 - Deploy da versão 2.3.1
- 14:15 - Alertas de latência disparados
- 14:20 - IC declarado, investigação iniciada
- 14:35 - Root cause identificada (query N+1)
- 14:45 - Rollback executado
- 14:50 - Serviço normalizado

## Root Cause
Query N+1 introduzida em nova feature causou
sobrecarga no banco de dados.

## O que funcionou
- Alertas detectaram o problema em 15 minutos
- Rollback foi executado em menos de 10 minutos
- Comunicação clara durante o incidente

## O que não funcionou
- Testes de carga não cobriram o cenário
- Dashboard de DB não era visível para o time

## Action Items
| Item | Owner | Prazo |
|------|-------|-------|
| Adicionar teste de carga para N+1 | @dev | 2025-01-09 |
| Incluir dashboard DB no runbook | @sre | 2025-01-05 |
| Review de queries em code review | @lead | Imediato |

## Lições Aprendidas
- Testes de carga devem simular padrões reais de uso
- Dashboards devem ser facilmente acessíveis durante incidentes

On-Call e Alerting

Boas Práticas de Alertas

Burn Rate Alerts

# Alertas baseados em burn rate (consumo de error budget)
groups:
  - name: slo-alerts
    rules:
      # Alert se queimando budget 14x mais rápido que o normal
      # (consumiria todo budget em ~2 dias)
      - alert: SLOErrorBudgetBurnHigh
        expr: |
          (
            sum(rate(http_requests_total{status=~"5.."}[1h]))
            /
            sum(rate(http_requests_total[1h]))
          ) > (14 * 0.001)  # 14x o budget rate de 0.1%
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "High error budget burn rate"

      # Alert se queimando 3x mais rápido (consumiria em ~10 dias)
      - alert: SLOErrorBudgetBurnMedium
        expr: |
          (
            sum(rate(http_requests_total{status=~"5.."}[6h]))
            /
            sum(rate(http_requests_total[6h]))
          ) > (3 * 0.001)
        for: 30m
        labels:
          severity: warning

Quer implementar práticas de SRE na sua organização? Fale com nossos especialistas para uma consultoria personalizada.