SLO vs SLA: Entendendo a Diferença
| Aspecto | SLO (Service Level Objective) | SLA (Service Level Agreement) |
|---|---|---|
| Definição | Meta interna de confiabilidade de um serviço | Contrato formal com clientes/stakeholders |
| Quem define | Equipe de engenharia | Negócio + engenharia + jurídico |
| Consequência de violação | Alerta interno, freeze de deploys, revisão | Penalidades contratuais, créditos, multas |
| Exemplo | ”99.9% availability em 30 dias" | "P1 incidents respondidos em 5 minutos” |
| CRD | ServiceLevelObjective | IncidentSLA |
A boa prática é definir SLOs mais rigorosos que os SLAs. Se seu SLA garante 99.9%, defina o SLO em 99.95%. Isso cria uma margem de segurança (error budget interno) que permite detectar degradações antes que o SLA seja violado.
ServiceLevelObjective CRD
OServiceLevelObjective define uma meta de confiabilidade para um serviço, com alertas baseados em burn rate e tracking de error budget.
Campos do Spec
Raiz
| Campo | Tipo | Obrigatório | Descrição |
|---|---|---|---|
service | string | Sim | Nome do serviço monitorado |
description | string | Não | Descrição legível do SLO |
indicator | SLOIndicator | Sim | Definição do indicador de nível de serviço (SLI) |
target | SLOTarget | Sim | Meta e janela temporal |
burnRateAlerts | []BurnRateWindow | Não | Configuração de alertas multi-window |
alertPolicy | SLOAlertPolicy | Não | Política geral de alertas |
SLOIndicator
Define o que medir. Otype determina a semântica e as queries Prometheus necessárias.
| Campo | Tipo | Obrigatório | Descrição |
|---|---|---|---|
type | string | Sim | availability, latency, error_rate, throughput |
prometheusQuery | PrometheusQuerySpec | Sim | Queries PromQL para calcular o SLI |
| Tipo | Good Events | Total Events | Cálculo |
|---|---|---|---|
availability | Requests com sucesso (2xx, 3xx) | Total de requests | good / total |
latency | Requests abaixo do threshold de latência | Total de requests | fast / total |
error_rate | N/A (invertido) | Requests com erro | 1 - (errors / total) |
throughput | Requests processados dentro do budget | Requests recebidos | processed / received |
| Campo | Tipo | Obrigatório | Descrição |
|---|---|---|---|
goodQuery | string | Sim | PromQL que retorna a taxa de eventos “bons” |
totalQuery | string | Sim | PromQL que retorna a taxa total de eventos |
- Availability
- Latency (P99 menor que 500ms)
- Error Rate
- Custom (Throughput)
SLOTarget
| Campo | Tipo | Obrigatório | Descrição |
|---|---|---|---|
percentage | float64 | Sim | Meta em porcentagem (ex: 99.9) |
window | duration | Sim | Janela temporal rolling (ex: 30d, 7d, 24h) |
BurnRateWindow
Cada entrada define uma janela de alerta baseada em burn rate.| Campo | Tipo | Obrigatório | Descrição |
|---|---|---|---|
name | string | Sim | Nome identificador do alerta |
shortWindow | duration | Sim | Janela curta de observação |
longWindow | duration | Sim | Janela longa de observação |
burnRateThreshold | float64 | Sim | Threshold de burn rate para disparar alerta |
severity | string | Sim | critical, high, medium, low |
notificationPolicy | string | Não | Nome da NotificationPolicy para routing |
SLOAlertPolicy
| Campo | Tipo | Padrão | Descrição |
|---|---|---|---|
multiWindowRequired | bool | true | Requer que AMBAS as janelas (short E long) excedam o threshold |
pageOnBudgetExhausted | bool | true | Envia page crítico quando error budget chega a 0% |
budgetWarningThresholds | []int | [50, 25, 10, 0] | Porcentagens de budget restante que disparam warnings |
Como Funciona o Cálculo (Google SRE Model)
O sistema implementa o modelo de multi-window, multi-burn-rate alerting descrito no livro “Site Reliability Engineering” do Google.Error Budget
O error budget é a quantidade máxima de “erro” permitida dentro da janela do SLO.| SLO Target | Error Budget | Downtime/30d |
|---|---|---|
| 99% | 1.0% | 7h 12min |
| 99.5% | 0.5% | 3h 36min |
| 99.9% | 0.1% | 43.2 min |
| 99.95% | 0.05% | 21.6 min |
| 99.99% | 0.01% | 4.32 min |
Burn Rate
O burn rate indica a velocidade com que o error budget está sendo consumido.Calcular error rate na janela
Usando as queries Prometheus, calcula-se a proporção de eventos bons vs total na janela especificada.
Verificar multi-window
Para disparar um alerta, AMBAS as janelas (short E long) devem exceder o threshold.
Multi-Window Alerting: Thresholds Padrão
Os thresholds padrão seguem a recomendação do Google SRE para um SLO de 30 dias:| Nome | Short Window | Long Window | Burn Rate | Severidade | Significado |
|---|---|---|---|---|---|
page-fast-burn | 1h | 6h | 14.4x | Critical | Budget se esgota em ~2 dias. Requer ação imediata. |
ticket-medium-burn | 6h | 3d | 6.0x | High | Budget se esgota em ~5 dias. Crie ticket urgente. |
ticket-slow-burn | 24h | 3d | 3.0x | Medium | Budget se esgota em ~10 dias. Investigue e planeje. |
monitor-gradual-burn | 72h | 30d | 1.0x | Low | Budget exatamente no ritmo sustentavel. Monitore. |
Exemplo Numérico Completo
Considere um SLO de 99.9% availability em 30 dias para o serviçoapi-gateway:
Error Budget Tracking
O status doServiceLevelObjective e atualizado periodicamente pelo reconciler:
| Campo | Tipo | Descrição |
|---|---|---|
currentValue | float64 | Valor atual do SLI (ex: 99.92%) |
errorBudgetTotal | float64 | Budget total (ex: 0.001 para 99.9%) |
errorBudgetRemaining | float64 | Budget restante |
errorBudgetRemainingPercent | float64 | Porcentagem restante do budget |
burnRate | float64 | Burn rate atual (janela mais curta) |
lastCalculatedAt | Time | Último cálculo |
condition | string | Met (dentro do SLO), AtRisk (budget < 25%), Violated (budget esgotado) |
| Budget Restante | Ação |
|---|---|
| 50% | Notificação informativa |
| 25% | Warning: congelar deploys não-essenciais |
| 10% | Alerta: foco total em estabilidade |
| 0% | Page crítico (se pageOnBudgetExhausted: true) |
IncidentSLA CRD
OIncidentSLA define contratos de tempo de resposta e resolução por severidade, com suporte a business hours e tracking de violações.
Campos do Spec
Raiz
| Campo | Tipo | Obrigatório | Descrição |
|---|---|---|---|
service | string | Sim | Nome do serviço coberto pelo SLA |
description | string | Não | Descrição do SLA |
responseTimes | []ResponseTimeConfig | Sim | Tempos máximos por severidade |
businessHours | BusinessHoursSpec | Não | Configuração de horário comercial |
violationPolicy | ViolationPolicySpec | Não | Ações em caso de violação |
ResponseTimeConfig
| Campo | Tipo | Obrigatório | Descrição |
|---|---|---|---|
severity | string | Sim | critical, high, medium, low |
maxResponseTime | duration | Sim | Tempo máximo para primeiro acknowledgement |
maxResolutionTime | duration | Sim | Tempo máximo para resolução completa |
Response time é medido como o tempo entre a criação do Issue (estado
Detected) e a primeira transição para Analyzing ou Remediating. Resolution time é medido entre Detected e Resolved.BusinessHoursSpec
| Campo | Tipo | Obrigatório | Descrição |
|---|---|---|---|
enabled | bool | Sim | Ativa contagem apenas em horário comercial |
timezone | string | Sim | Timezone IANA (ex: America/Sao_Paulo) |
startHour | int | Sim | Hora de início (0-23) |
endHour | int | Sim | Hora de fim (0-23) |
workDays | []int | Sim | Dias úteis (0=Domingo, 6=Sábado) |
holidays | []Holiday | Não | Feriados (clock parado nesses dias) |
Como o Clock de Business Hours Funciona
O SLA clock conta apenas durante horário comercial. Fora do horário, o clock é pausado automaticamente.Clock conta 15 minutos (sexta)
De 17:45 até 18:00 = 15 minutos de SLA clock.
Clock pausa às 18:00 (fim do horário comercial).
Fim de semana: clock pausado
Sábado e domingo inteiros: clock permanece pausado.
Tempo SLA acumulado: 15 minutos.
Segunda-feira: clock retoma
Clock retoma as 09:00 de segunda-feira.
Se o incidente é resolvido às 10:30 de segunda:
- Sexta: 15 minutos
- Segunda: 1h30 = 90 minutos
- Total SLA: 105 minutos (1h45)
ViolationPolicySpec
| Campo | Tipo | Descrição |
|---|---|---|
notificationPolicy | string | NotificationPolicy para enviar alertas de violação |
escalationPolicy | string | EscalationPolicy para escalar violações |
autoEscalateOnBreach | bool | Escalar automaticamente quando SLA e violado |
CompliancePercentage Calculation
| Severidade | Incidentes | Violações | Compliance |
|---|---|---|---|
| Critical | 5 | 1 | 80.0% |
| High | 15 | 2 | 86.7% |
| Medium | 40 | 0 | 100.0% |
| Low | 60 | 0 | 100.0% |
| Total | 120 | 3 | 97.5% |
Exemplos YAML Completos
SLO de 99.9% Availability com Burn Rate Alerting
SLA P1=5min Response / 1h Resolution (Business Hours)
Para severidade
critical, mesmo com business hours habilitado, considere criar uma regra separada com businessHours.enabled: false. Problemas P1 geralmente exigem resposta 24/7.SLO com PrometheusQuery Custom (Latency P99)
Grafana Dashboards
A plataforma AIOps disponibiliza 4 dashboards Grafana pré-configurados para visualização de SLOs e SLAs:SLO Overview
Painel unificado com todos os SLOs, valores atuais, error budget restante e burn rate. Inclui heatmap de burn rate por serviço.
Error Budget Burn-Down
Gráfico burn-down do error budget ao longo do tempo. Mostra tendência e projeção de esgotamento. Linhas de referência para cada threshold de warning.
SLA Compliance Report
Relatório de compliance por severidade e período. Tabela com cada incidente, tempos de resposta/resolução e status de compliance. Exportável para PDF.
Incident Timeline
Timeline de incidentes com detecção, análise, remediação e resolução. Correlação visual com SLO burn rate e SLA clock.
Prometheus Metrics
O sistema de SLOs e SLAs expõe métricas detalhadas:Métricas de SLO
| Métrica | Tipo | Labels | Descrição |
|---|---|---|---|
chatcli_slo_current_value | Gauge | slo, service, namespace, indicator_type | Valor atual do SLI (ex: 99.92) |
chatcli_slo_target_value | Gauge | slo, service | Meta configurada (ex: 99.9) |
chatcli_slo_error_budget_total | Gauge | slo, service | Error budget total (ex: 0.001) |
chatcli_slo_error_budget_remaining | Gauge | slo, service, namespace | Error budget restante |
chatcli_slo_error_budget_remaining_percent | Gauge | slo, service | Porcentagem restante do budget |
chatcli_slo_burn_rate | Gauge | slo, service, window | Burn rate por janela |
chatcli_slo_alerts_fired_total | Counter | slo, service, severity, alert_name | Total de alertas de burn rate disparados |
chatcli_slo_condition | Gauge | slo, service, condition | Estado atual (1=ativo): Met, AtRisk, Violated |
Métricas de SLA
| Métrica | Tipo | Labels | Descrição |
|---|---|---|---|
chatcli_sla_violations_total | Counter | sla, service, severity, violation_type | Total de violações de SLA |
chatcli_sla_compliance_percentage | Gauge | sla, service, severity | Porcentagem de compliance atual |
chatcli_sla_response_time_seconds | Histogram | sla, service, severity | Distribuição de tempos de resposta |
chatcli_sla_resolution_time_seconds | Histogram | sla, service, severity | Distribuição de tempos de resolução |
chatcli_sla_active_incidents | Gauge | sla, service | Incidentes ativos no momento |
chatcli_sla_business_hours_active | Gauge | sla, service | 1 se dentro do horário comercial, 0 se fora |
Próximo Passo
Notificações e Escalação
Sistema de notificações multi-canal e escalação automática
Workflow de Aprovação
Controle de mudanças com approval policies e blast radius
AIOps Platform
Deep-dive na arquitetura AIOps
K8s Operator
Configuração e CRDs do operator