Boas práticas de monitoramento de SLAs e SLOs

1. Fundamentos de SLAs, SLOs e SLIs

Para estabelecer um monitoramento eficaz, é essencial compreender a tríade fundamental: SLA (Service Level Agreement), SLO (Service Level Objective) e SLI (Service Level Indicator). O SLA é o contrato formal com o cliente, definindo penalidades e garantias. O SLO é a meta interna que a equipe almeja, geralmente mais rigorosa que o SLA. O SLI é a métrica real medida, como tempo de resposta ou taxa de erro.

A diferença prática: enquanto um SLA pode prometer 99,5% de disponibilidade, o time define um SLO interno de 99,9% para garantir margem de segurança. Os SLIs são os dados brutos que alimentam esses indicadores. Definir metas realistas exige análise de dados históricos de pelo menos 3 a 6 meses, identificando sazonalidades e picos de uso.

Por exemplo, um serviço de API que historicamente mantém 99,95% de disponibilidade pode ter SLO de 99,9% (folga de 0,05% para imprevistos). Metas irreais geram alertas constantes e perda de credibilidade no processo.

2. Escolha e definição de SLIs relevantes

Nem toda métrica merece virar SLI. As quatro categorias críticas são:

  • Disponibilidade: percentual de requisições bem-sucedidas
  • Latência: tempo de resposta em diferentes percentis
  • Throughput: volume de requisições processadas por segundo
  • Taxa de erro: proporção de requisições com código HTTP 5xx

A escolha deve refletir a experiência do usuário final. Para um serviço de streaming, latência p95 importa mais que p50. Para um sistema bancário, taxa de erro zero é prioridade.

Criação de janelas de medição: utilize janelas deslizantes de 30 dias para SLOs mensais, com agregação a cada 5 minutos. Percentis são cruciais — p50 mostra comportamento típico, p95 revela problemas de performance, p99 captura outliers que afetam usuários.

Exemplo de definição de SLI para latência:

SLI: Latência de resposta da API de pagamentos
Métrica: http_request_duration_seconds
Agregação: p95 em janela de 5 minutos
Meta: < 200ms para 99% das requisições

3. Estruturação de SLOs com burn rate e orçamento de erro

Orçamento de erro é a quantidade de falhas tolerada em um período. Para SLO de 99,9% em 30 dias, o orçamento é 0,1% do tempo total — aproximadamente 43 minutos de indisponibilidade.

Burn rate mede a velocidade de consumo desse orçamento. Se 10% do orçamento é consumido em 1 hora, o burn rate é 0,1/hora. Alertas proativos são acionados quando o burn rate ultrapassa limites, permitindo ação antes da violação.

Recomenda-se múltiplos SLOs por serviço: um SLO rigoroso (ex.: 99,99% para componentes críticos) e um relaxado (ex.: 99,5% para funcionalidades secundárias). Isso evita que problemas menores disparem alertas desnecessários.

Exemplo de cálculo de orçamento:

SLO: 99,9% em 30 dias
Total de segundos: 2.592.000
Orçamento de erro: 2.592 segundos (43,2 min)
Burn rate crítico: 5% do orçamento em 1 hora = 129,6 segundos consumidos

4. Implementação de monitoramento contínuo de SLOs

A implementação técnica exige coleta de SLIs em sistemas de série temporal. Prometheus é a ferramenta mais comum no ecossistema cloud-native, armazenando métricas com timestamps e labels.

Criação de consultas para SLOs em tempo real:

# Exemplo de query Prometheus para disponibilidade
sum(rate(http_requests_total{status=~"2..|3.."}[5m]))
/
sum(rate(http_requests_total[5m]))
* 100

Dashboards no Grafana permitem visualizar indicadores de saúde: gráfico de violações, burn rate atual, orçamento restante. Use cores semafóricas — verde para saudável, amarelo para atenção, vermelho para violação iminente.

Estrutura de dashboard recomendada:

Painel 1: SLO atual vs meta (gauge)
Painel 2: Burn rate por serviço (série temporal)
Painel 3: Orçamento de erro consumido (barra)
Painel 4: SLIs por percentil (tabela)

5. Configuração de alertas baseados em SLOs

Alertas devem ser proativos, não reativos. Duas abordagens principais:

Alertas por burn rate: acione quando X% do orçamento for consumido em Y minutos. Exemplo: 5% do orçamento em 1 hora indica problema acelerado.

Alertas por violação de SLO: dispare quando o SLO atual cair abaixo da meta acumulada. Exemplo: disponibilidade de 99,8% em janela de 7 dias quando meta é 99,9%.

Estratégia de escalonamento:

Nível 1: Alerta no canal de Slack da equipe (burn rate > 2%/hora)
Nível 2: Notificação PagerDuty (burn rate > 5%/hora)
Nível 3: Escalação para gerente (violação de SLO confirmada)

Exemplo de regra de alerta no Prometheus:

ALERT HighBurnRate
IF (slo_burn_rate > 0.05)
FOR 10m
LABELS { severity = "critical" }
ANNOTATIONS {
  summary = "Burn rate elevado no serviço {{ $labels.service }}",
  description = "Consumiu 5% do orçamento em 1 hora"
}

6. Revisão e ajuste periódico de metas

SLOs não são estáticos. Realize revisões trimestrais com stakeholders para analisar tendências. Se um serviço consistentemente atinge 99,99%, considere elevar o SLO para 99,995%. Se alertas falsos são frequentes, relaxe a meta.

Análise de desvios: utilize gráficos de tendência de SLIs nos últimos 6 meses. Identifique padrões sazonais (black friday, feriados) e ajuste janelas de medição.

Processo de revisão:

1. Coletar dados de SLIs dos últimos 3 meses
2. Calcular SLO real atingido
3. Comparar com SLO definido
4. Identificar desvios > 0,1%
5. Propor ajuste com justificativa
6. Aprovar em reunião de operações

Balanceamento: metas ambiciosas demais geram fadiga de alertas e perda de confiança. Metas frouxas demais não protegem o SLA. O ponto ideal está 0,1% a 0,5% acima do SLA, dependendo da criticidade.

7. Documentação e comunicação de SLOs

Mantenha um catálogo de SLOs por serviço, acessível a toda a organização. Inclua: nome do serviço, SLI usado, janela de medição, meta atual, histórico de violações.

Formato de catálogo:

Serviço: API de Pagamentos
SLI: Disponibilidade (requisições 2xx/3xx)
Janela: 30 dias deslizantes
SLO: 99,95%
Última violação: 2024-03-15
Proprietário: time-pagamentos

Comunique status de SLOs para áreas de negócio em linguagem não técnica. Use dashboards públicos com indicadores simplificados (verde/amarelo/vermelho). Para clientes externos, formalize SLAs contratuais com métricas auditáveis.

Relatórios mensais de conformidade:

Serviço | SLO Contratado | SLO Realizado | Conformidade
-------------------------------------------------------
API Pagamentos | 99,9% | 99,95% | OK
Serviço Login | 99,5% | 99,3% | Violado

8. Ferramentas e automação para gestão de SLOs

Ferramentas modernas integram observabilidade com gestão de SLOs:

  • Grafana: dashboards com painéis de SLO e alertas
  • Datadog: SLO tracking nativo com burn rate alerts
  • New Relic: SLOs baseados em NRQL queries
  • Prometheus + Alertmanager: stack open-source completa

Automatize a criação de SLOs via Infrastructure as Code. Exemplo com Terraform para Datadog:

resource "datadog_service_level_objective" "api_slo" {
  name        = "API Disponibilidade"
  type        = "metric"
  description = "SLO de disponibilidade para API principal"
  query {
    numerator   = "sum:http.success{service:api}.as_count()"
    denominator = "sum:http.total{service:api}.as_count()"
  }
  thresholds {
    target = 99.9
    timeframe = "30d"
  }
}

Geração de relatórios de auditoria: utilize scripts que extraem dados de SLOs e geram PDFs com conformidade mensal. Ferramentas como Grafana Reporting ou scripts Python com matplotlib automatizam esse processo.

Referências