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

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 tempo de resposta 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

Um bom SLI tem três propriedades chave:

• 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 numa janela de 5 minutos" é um SLI

SLO - Service Level Objective

Objetivo interno que define que valor o SLI deve atingir. Expresso percentualmente por uma janela temporal escolhida.

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 tempo de resposta abaixo de 200 ms em 7 dias"
• "99,5 % das transações de pagamento passam com sucesso no mês calendário"

O SLO costuma ser mais rigoroso que o SLA para que tenhas margem. Se o SLA diz 99,9 %, o SLO interno deveria ser p.ex. 99,95 % - assim ficas com reserva para incidentes inesperados antes de violares o contrato.

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 o 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

O SLA tem consequências legais. O SLO, em contrapartida, é apenas um 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, e 0,1 % de 30 dias são 43 minutos por mês. Este é o teu error budget.

Implicações práticas:

• Se já gastaste 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 gastaste apenas 5 min de downtime, tens 38 min de budget para risco - podes permitir-te mudanças mais agressivas, testes A/B e experiências.
• O error budget resolve assim o conflito entre velocidade de inovação (dev team) e estabilidade (ops team). Ambos os lados 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: um SLO de 99,9 % significa 43 min de downtime por mês. O SLA dá uma margem ainda maior antes de qualquer penalização económica.

Resumo: tabela

Erros práticos

• Um SLO demasiado ambicioso. 99,99 % exige active-active redundancy em múltiplas regiões. Irreal para uma pequena empresa.
• Apenas um uptime SLO. O web pode estar "up" e mesmo assim inutilizável. Adiciona um latency SLO e um error rate SLO.
• Um SLA sem medição automática. Um relatório SLA calculado manualmente é pouco fiável. Investe em uptime tracking automatizado.
• Um SLO sem consequências. Se a violação de um SLO não interessa a ninguém, ninguém o leva a sério. Liga-o 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 os 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 um registo histórico de uptime com rollup de 30/90/365 dias. Uma base sólida para reporting de SLO.

Iniciar monitorização →