SLI vs SLO vs SLA: diferenças e como configurá-los

Em resumo: SLI é o que medes, SLO é que objetivo queres alcançar, SLA é o compromisso contratual. Estes termos do livro Google SRE estão entre as frases mais usadas na operação de serviços web - e frequentemente misturadas.

SLI - Service Level Indicator

Métrica concreta com que quantificas a fiabilidade do serviço. Exemplos:

• % de pedidos que terminaram em HTTP 2xx ou 3xx nos últimos 30 dias
• % de pedidos com response time abaixo de 500 ms
• % de emails entregues corretamente (delivered, não bounced)
• Proporção de transações de pagamento bem sucedidas sobre todas as tentativas

Propriedades chave de um bom SLI:

• Mensurável - existe um método concreto de recolha de dados
• Relevante para o utilizador - reflete a experiência real do cliente, não uma métrica técnica interna
• Específico - "uptime" é demasiado vago; "% de pedidos bem sucedidos para /api/v1/orders em janela de 5 minutos" é um SLI

SLO - Service Level Objective

Objetivo interno, que valor o SLI deve atingir. Expresso percentualmente por janela temporal.

Exemplos:

• "99,9 % dos pedidos para /api/orders têm de terminar em HTTP 2xx em 30 dias"
• "95 % dos pedidos têm de ter response time abaixo de 200 ms em 7 dias"
• "99,5 % das transações de pagamento passam com sucesso no mês calendário"

SLO é mais alto que SLA para teres buffer. Se SLA diz 99,9 %, o SLO interno deveria ser p.ex. 99,95 % - para teres reserva para incidentes inesperados.

SLA - Service Level Agreement

Compromisso contratual com os clientes. Define o que acontece quando não cumpres o SLO - tipicamente:

• Service credits - devolves parte da mensalidade (10-50% conforme tamanho da violação)
• Termination rights - o cliente pode rescindir o contrato sem sanção
• Obrigação de reporting - tens de publicar postmortem e relatórios de uptime

SLA tem consequências legais. SLO é objetivo interno.

Error budget

Conceito chave de SRE: downtime que podes permitir-te sem violar o SLO.

Exemplo: SLO = 99,9 % de uptime em 30 dias. São 0,1 % de downtime permitido. 0,1 % de 30 dias = 43 minutos por mês. Este é o teu error budget.

Implicações práticas:

• Se já tens 35 min de downtime no mês, restam 8 min até "violação do SLO". A equipa deveria ser conservadora nos próximos deploys.
• Se tens 5 min de downtime, tens 38 min de budget para riscos - podes fazer mudanças mais agressivas, testes A/B, experiências.
• Error budget resolve o conflito entre velocidade de inovação (dev team) e estabilidade (ops team). Ambos seguem o mesmo número.

Exemplo prático: API e-commerce

SLI: % de pedidos HTTP a POST /api/checkout que terminaram em 2xx, medidos em buckets de 1 minuto nos últimos 30 dias.

SLO: ≥ 99,9 % de pedidos bem sucedidos em janela rolling 30-day.

SLA (para clientes Enterprise):

• ≥ 99,5 % uptime no mês calendário
• A 99,0-99,5 % = 10% de credit da mensalidade
• A 95,0-99,0 % = 25% credit
• A < 95,0 % = 50% credit + direito de rescindir o contrato

Error budget: 99,9 % SLO significa 43 min de downtime / mês em budget. SLA dá ainda maior buffer antes da penalização económica.

Resumo: tabela

Erros práticos

• SLO demasiado ambicioso. 99,99 % exige active-active redundancy em múltiplas regiões. Irreal para pequena empresa.
• Apenas uptime SLO. O web pode estar "up" e mesmo assim inutilizável. Adiciona latency SLO e error rate SLO.
• SLA sem medição automática. Um relatório SLA calculado manualmente é pouco fiável. Investe em uptime tracking automatizado.
• SLO sem consequências. Se a violação do SLO não interessa a ninguém, ninguém se preocupa com ele. Liga a deploy freeze, on-call escalation, etc.

Conclusão

O framework SLI/SLO/SLA não é burocracia de papel - é a linguagem com que a equipa de engineering comunica com business stakeholders sobre fiabilidade. Sem estes termos a discussão sobre estabilidade torna-se subjetiva ("o nosso web é instável"). Com eles é numérica ("nos últimos 30 dias atingimos 99,87 % SLI, que está abaixo do nosso 99,9 % SLO - aqui está o plano de ação").

Mede o SLI em tempo real

O ePulz.io fornece registo histórico de uptime com rollup de 30/90/365 dias. Base para reporting de SLO.

Iniciar monitorização →