SLO vs SLA: a diferença, os SLIs e o orçamento de erros

Um SLA (acordo de nível de serviço) é um contrato com um cliente que diz o que acontece quando um serviço não atinge um nível prometido, em geral um crédito de serviço. Um SLO (objetivo de nível de serviço) é a meta interna com que uma equipe opera o serviço; o livro de SRE recomenda defini-la mais rígida que o SLA, para que os problemas sejam resolvidos antes de o contrato ser violado. Um SLI (indicador de nível de serviço) é a medida em que os dois são escritos, como a parcela de requisições bem-sucedidas.

Os exemplos são ilustrativos; as fontes são o livro e o workbook de SRE do Google e o SLA de computação da AWS, conferidos em 1º de novembro de 2026.

O que significam SLI, SLO e SLA?

Service level indicator, service level objective e service level agreement: indicador, objetivo e acordo de nível de serviço. O indicador é o que você mede, o objetivo é o valor que você busca e o acordo é o que você promete a outra pessoa, com consequências.

O capítulo “Service Level Objectives” do livro de SRE define um SLA como “um contrato explícito ou implícito com seus usuários que inclui consequências por cumprir (ou não cumprir) os SLOs que ele contém”. O teste do capítulo é uma única pergunta: o que acontece se os SLOs não forem cumpridos? Se não há consequência explícita, você quase certamente está diante de um SLO.

O capítulo acrescenta que a maioria das pessoas quer dizer SLO quando diz SLA, e que uma violação real de SLA pode acabar num processo por quebra de contrato. Então, quando uma reunião virar uma discussão de SLA vs SLO, pergunte primeiro se há uma consequência, em geral dinheiro, prevista em contrato.

O livro de SRE aconselha manter uma margem de segurança: “um SLO interno mais rígido que o SLO anunciado aos usuários dá espaço para responder a problemas crônicos antes que fiquem visíveis externamente”. O capítulo “Embracing Risk” aplica a mesma ideia a um contrato: uma meta externa de 99,9% apoiada por uma interna mais exigente.

O que é um orçamento de erros?

É 100% menos o SLO: a parcela das requisições ou do tempo que pode falhar dentro da janela. Enquanto sobra orçamento, a equipe continua entregando; quando ele acaba, o trabalho de confiabilidade vem primeiro.

O capítulo “Implementing SLOs” do workbook de SRE faz a conta: com um SLO de 99,9%, um serviço que recebe 3 milhões de requisições em quatro semanas pode falhar 3.000 delas, então uma queda com 1.500 erros gasta metade do orçamento. O capítulo “Embracing Risk” do livro explica o propósito: a gestão de produto define o SLO, o monitoramento mede a disponibilidade real e a diferença é a margem de falta de confiabilidade que resta para o trimestre. Quando esse orçamento acaba, os deploys param ou desaceleram.

Quanto tempo de indisponibilidade 99,9% permite?

Cerca de 43 minutos numa janela de 30 dias. Cada nove a mais divide a margem por dez, então 99,99% deixa pouco mais de 4 minutos.

Multiplique os 43.200 minutos de uma janela de 30 dias pelo orçamento de erros. Lembre do aviso do workbook: cada nove adicional custa mais, enquanto o valor dele para os usuários tende a zero.

Como é um SLA de verdade?

Ele traz uma porcentagem medida, um período de cobrança, uma tabela de créditos e o que não conta. O SLA de computação da AWS é um exemplo público e curto.

O Amazon Compute Service Level Agreement (atualizado em 25 de maio de 2022; conferido em 1º de novembro de 2026) se compromete com uma Monthly Uptime Percentage de pelo menos 99,99% por região para instâncias EC2 distribuídas em duas ou mais Availability Zones, e 99,5% para uma instância isolada. A disponibilidade é 100% menos a parcela dos minutos em que o EC2 ficou indisponível. Pelo Region-Level SLA, abaixo de 99,99% o crédito é de 10% da fatura mensal de EC2 na região, abaixo de 99,0% é de 30% e abaixo de 95,0% é de 100%; para uma instância isolada, a faixa de 10% começa abaixo de 99,5%. Os créditos são aplicados a pagamentos futuros, precisam ser solicitados pelo suporte da AWS e são o remédio “único e exclusivo”, salvo disposição em contrário no contrato do cliente.

Comparada com a tabela acima, a faixa de 10% do Region-Level SLA vai de cerca de 4 minutos a 7 horas de indisponibilidade num mês de 30 dias. Um SLA limita o que o fornecedor deve; evitar que as quedas prejudiquem seus usuários é tarefa dos seus próprios objetivos.

Como escolher SLIs de latência e disponibilidade?

Meça a latência como percentil e a disponibilidade como eventos bons divididos por todos os eventos, o mais perto possível do usuário. Médias e números só do servidor escondem as requisições de que as pessoas reclamam.

Latência. O livro de SRE prefere percentis à média, porque uma média pode ficar estável enquanto as requisições mais lentas ficam bem mais lentas. O workbook escreve SLIs de latência como uma razão, por exemplo as chamadas concluídas em menos de 100 ms divididas por todas as chamadas. Então “99% das chamadas de checkout em menos de 400 ms” é o mesmo que “p99 do checkout abaixo de 400 ms” na janela, o que vai direto para um teste. Nosso artigo sobre latência de cauda explica por que o p99 importa assim que uma página chama vários serviços.

Disponibilidade. A disponibilidade por tempo conta os minutos no ar, como faz o SLA da AWS. A disponibilidade por requisições conta as requisições bem-sucedidas: “Embracing Risk” descreve um serviço com 2,5 milhões de requisições por dia e uma meta diária de 99,99%, que pode devolver 250 erros e ainda cumprir a meta.

Onde os SLOs dão errado?

Quase sempre por excesso de objetivos, metas de 100% e indicadores medidos onde os usuários não estão. Cada um deixa um número que ninguém usa para agir, ou um que parece bom enquanto os usuários sofrem.

• SLOs demais. O livro de SRE aconselha ter o mínimo possível: se citar um SLO nunca ajuda a ganhar uma discussão sobre prioridades, provavelmente ele não vale a pena.
• Metas de 100%. O workbook diz que 100% é a meta errada: componentes falham, mudanças são a principal fonte de quedas e um SLO de 100% só deixa tempo para reagir.
• Medir só no servidor. Métricas do servidor deixam passar problemas que os usuários sentem, como um script lento na página. O workbook sugere medir no balanceador de carga ou no cliente.

O que o teste de carga tem a ver com SLOs?

Um SLO dá ao teste de carga seus critérios de aprovação, e um teste no pico esperado mostra se o SLO de latência se sustenta antes de esse tráfego chegar. O monitoramento em produção só conta depois.

O livro de SRE observa que mais requisições por segundo (QPS) costumam trazer latências maiores e que é comum os serviços terem um penhasco de desempenho a partir de certo limiar de carga. Um teste de carga pode encontrar esse penhasco se rodar no pico esperado, com um mix realista de requisições, e medir o mesmo SLI que o SLO usa. Defina cada limite de aprovação do teste um pouco mais rígido que o SLO, como descreve nosso guia de critérios de aprovação de um teste de carga. Uma execução dura minutos, então não consegue medir a disponibilidade mensal.

A LoadFocus, que publica este site, avalia testes de carga com limites de aprovação salvos no teste: Max P95 e Max P99 do tempo de resposta, uma taxa de erros máxima e uma vazão mínima, para testes cloud, JMeter e k6. O monitoramento de APIs dela tem relatórios de SLA e SLO que definem uma meta de SLO por monitor e mostram a disponibilidade, o orçamento de erros consumido e um status OK ou Breached.

FAQ

O que significa SLO? Service level objective, ou objetivo de nível de serviço: um valor-alvo para um nível de serviço medido, como 99,9% das requisições bem-sucedidas em quatro semanas. Ele é definido internamente, por produto e engenharia, e, sozinho, não traz nenhuma multa contratual.

Dá para ter um SLO sem um SLA? Sim. O livro de SRE cita a busca do Google como um serviço importante sem SLA público que, mesmo assim, é gerido com SLIs e SLOs.

Um SLO deveria ser de 100% em algum caso? Não. Um objetivo de 100% não deixa orçamento de erros, então qualquer falha o viola e nenhuma mudança fica segura para entregar.

Leituras relacionadas

• Critérios de aprovação de um teste de carga: como definir
• Latência de cauda: o que é e como medir
• Pontuação Apdex: o que é e como calcular
• Vazão vs latência: como se relacionam sob carga

As afirmações técnicas deste artigo não foram revisadas de forma independente.