SLO, SLA e SLI: o que são e como responder sobre eles em entrevista

O problema

Essas três siglas costumam aparecer em entrevistas de plataforma, backend, confiabilidade e times mais maduros de produto.

E muita gente responde mal por um motivo simples:

não separa bem as funções.

Então a resposta vira algo como:

• “SLA é disponibilidade”
• “SLO é a meta”
• “SLI é a métrica”

Tecnicamente isso aponta para o caminho certo.

Mas ainda é pouco.

Porque não mostra:

• por que isso existe
• como essas coisas se relacionam
• e como elas influenciam decisão de engenharia

O problema real é este:

muita resposta fica na definição curta e não chega no julgamento operacional.

Modelo mental

Pense assim:

SLI mede, SLO orienta e SLA compromete.

Essa frase já organiza quase tudo.

De forma simples:

• SLI é o indicador observado
• SLO é o alvo interno que o time tenta cumprir
• SLA é o compromisso formal, normalmente com consequência comercial ou contratual

Quando você entende essa ordem, para de tratar as três coisas como sinônimos com roupa diferente.

Quebrando o problema

SLI é o que você observa

SLI significa Service Level Indicator.

Na prática, pense nele como uma medida de comportamento relevante do sistema.

Exemplos:

• porcentagem de requests com sucesso
• latência p95 de um endpoint crítico
• taxa de mensagens processadas dentro de certo tempo
• sucesso de login sem erro

O ponto principal é:

SLI não é “qualquer métrica”.

É uma métrica que representa algo importante da experiência ou do serviço.

SLO é o alvo interno que guia decisão

SLO significa Service Level Objective.

É a meta que o time escolhe perseguir em cima de um SLI.

Exemplo simples:

• SLI: porcentagem de requests bem-sucedidos no checkout
• SLO: 99,9% de sucesso mensal no checkout

Aqui está a parte importante:

SLO não é só número bonito.

Ele existe para influenciar decisão.

Coisas como:

• vale lançar essa mudança agora?
• esse incidente já consumiu nossa margem?
• estamos gastando confiabilidade demais por velocidade?

Sem essa camada, o SLO vira só painel.

SLA é compromisso externo

SLA significa Service Level Agreement.

Normalmente é a parte mais formal:

• contrato
• promessa comercial
• compromisso com cliente
• consequência se não cumprir

Exemplos:

• créditos financeiros
• penalidade contratual
• obrigação de resposta

Por isso, SLA costuma ficar mais ligado a relação externa do que à operação diária do time.

Time maduro até olha para SLA, mas não deveria operar só por ele.

Porque esperar chegar no limite contratual para reagir já é tarde demais.

SLO costuma ser mais útil para engenharia do que SLA

Esse é um ponto muito bom em entrevista.

SLA importa.

Mas, no dia a dia, engenharia geralmente trabalha muito mais em torno de SLO.

Por quê?

Porque o SLO dá margem de manobra antes de o problema virar crise comercial.

Ele permite enxergar:

• degradação antes da quebra grave
• consumo de confiabilidade ao longo do tempo
• necessidade de reduzir risco antes de explodir um compromisso externo

Em outras palavras:

SLO ajuda o time a pilotar.

SLA só avisa quando o time já chegou perto do muro.

Sem SLI bom, o resto perde força

Esse erro também é comum.

Time define SLO sem ter indicador confiável.

Resultado:

• meta mal medida
• sensação falsa de saúde
• discussão vaga sobre confiabilidade

Se o indicador não representa bem a experiência ou o serviço, a meta em cima dele também perde valor.

Então a primeira pergunta útil muitas vezes é:

• esse SLI realmente captura o comportamento que importa?

Nem toda disponibilidade resume confiabilidade

Outro atalho ruim é reduzir tudo a uptime.

Sistema pode estar “no ar” e ainda assim:

• lento demais
• errando em um fluxo crítico
• falhando para um subconjunto importante de usuários
• acumulando atraso operacional invisível num dashboard simples

Por isso, resposta madura não trata confiabilidade como só um percentual de disponibilidade bruto.

Ela pensa em experiência relevante.

Em entrevista, a melhor resposta conecta conceito com uso

Não basta dizer:

• SLI é métrica
• SLO é objetivo
• SLA é acordo

Melhor é mostrar:

• um exemplo real
• por que o SLO seria definido assim
• como ele ajudaria numa decisão
• e por que o SLA não é a régua única do time

Isso faz a resposta sair do decorado.

Exemplo simples

Imagine um produto com checkout crítico.

Uma resposta fraca seria:

“SLI é a métrica, SLO é a meta e SLA é o contrato.”

Está certo, mas ainda superficial.

Uma resposta melhor:

“Eu pensaria primeiro no SLI que realmente representa a experiência crítica, por exemplo a taxa de sucesso do checkout ou a latência de confirmação do pagamento. Em cima disso, o time define um SLO interno, como 99,9% de sucesso mensal, para orientar decisão de release e priorização de confiabilidade. O SLA já seria o compromisso externo com cliente, possivelmente mais conservador e com consequência contratual. Na prática, engenharia opera pelo SLO para não descobrir o problema só quando o SLA já foi quebrado.”

Essa resposta mostra:

• diferença entre as três peças
• exemplo concreto
• uso operacional
• julgamento de engenharia

Erros comuns

• Tratar SLI, SLO e SLA como sinônimos.
• Achar que qualquer métrica já serve como SLI.
• Operar o time olhando só para SLA.
• Reduzir confiabilidade a uptime bruto.
• Decorar definição sem explicar por que isso muda decisão.

Como um senior pensa

Quem amadureceu costuma pensar assim:

“Confiabilidade boa precisa de uma forma clara de medir, uma meta interna que guie trade-off e um compromisso externo que não seja descoberto só no susto.”

Essa visão é útil porque conecta observabilidade com produto e operação.

Senioridade aqui não é saber a expansão das siglas.

É entender como elas influenciam:

• priorização
• release
• risco
• investimento em confiabilidade

O que o entrevistador quer ver

Quando esse tema aparece, o avaliador normalmente quer entender se você:

• diferencia bem indicador, objetivo e acordo
• sabe dar exemplo concreto de SLI e SLO
• entende por que times operam mais por SLO do que por SLA
• conecta confiabilidade com decisão real de engenharia
• evita resposta burocrática demais

Resposta forte costuma ter esta forma:

1. explico a diferença
2. dou exemplo de fluxo real
3. mostro como o SLO orienta decisão
4. explico o papel mais externo do SLA

Se isso aparece, a resposta já fica acima da média.

SLI, SLO e SLA não servem para parecer processo maduro. Servem para tornar confiabilidade mensurável e negociável.

Quando o time só lembra do SLA, geralmente já está reagindo tarde demais.