SLO objetivos confiabilidade: o que é e como definir metas

O que é SLO e como definir objetivos realistas de confiabilidade

SLO (Service Level Objective) é uma meta interna de confiabilidade que a equipe de engenharia define para si mesma. Na prática, funciona como um contrato entre times: "nosso serviço de pagamento deve ter 99,9% de disponibilidade no trimestre" ou "a latência do checkout deve ficar abaixo de 500ms em 95% das requisições". O SLO traduz expectativas vagas de qualidade em números mensuráveis, que orientam decisões de arquitetura, priorização de bugs e investimento em infraestrutura.

Diferente do SLA (Service Level Agreement), que é um acordo formal com o cliente e costuma incluir penalidades, o SLO é uma meta interna, sem sanções contratuais. Ele existe para que a equipe saiba, com clareza, o que significa "confiável o suficiente" para o negócio. Sem SLO, cada engenheiro tem uma opinião diferente sobre o que precisa ser corrigido primeiro. Com SLO, a priorização deixa de ser baseada em opinião e passa a ser baseada em dados.

Por que SLO é diferente de SLA?

SLA é o compromisso externo, assinado com o cliente, que define o nível mínimo de serviço e as consequências se ele não for cumprido. SLO é a meta interna, geralmente mais rigorosa que o SLA, que a equipe usa para se autoavaliar. Um exemplo: o SLA promete 99,5% de disponibilidade mensal ao cliente, mas a equipe define um SLO interno de 99,9%. A folga entre os dois números é o orçamento de erro, a margem para falhas que não violam o contrato.

Essa distinção importa porque o SLO não é um instrumento de cobrança externa, é um guia de engenharia. Quando o time define um SLO mais apertado que o SLA, ele cria uma margem de segurança. Se o serviço operar dentro do SLO, o SLA dificilmente será violado. Se o SLO for mais frouxo que o SLA, a equipe corre o risco de só descobrir o problema quando o cliente já foi afetado.

Como definir um SLO realista?

Definir SLO realista exige três passos: escolher a métrica certa, medir o comportamento atual e calibrar a meta com base em dados históricos. A métrica precisa refletir a experiência real do usuário, não apenas a saúde do servidor. Disponibilidade de 99,9% significa pouco se a página demora 10 segundos para carregar. Por isso, a maioria dos SLOs modernos combina disponibilidade com latência ou taxa de erro.

O ponto de partida é observar o serviço em produção por algumas semanas. Qual é a disponibilidade atual? Qual é a latência no percentil 95? Qual é a taxa de erro em horário de pico? Sem essa linha de base, qualquer meta é um chute. Um serviço que hoje opera com 99,5% de disponibilidade não deve ter um SLO de 99,99% no mês seguinte. A meta precisa ser desafiadora, mas alcançável com o orçamento e a equipe disponíveis.

Um erro comum é copiar SLOs de empresas grandes, como 99,99%, sem considerar o contexto. Uma startup de pagamentos pode precisar desse nível de rigor, mas um site institucional com poucos visitantes não. O custo de manter 99,99% de disponibilidade, com redundância em múltiplas regiões e monitoramento contínuo, pode não se justificar para um serviço interno de baixa criticidade. O SLO deve refletir o impacto real da indisponibilidade no negócio.

Quais métricas usar em um SLO?

As métricas mais comuns em SLO são disponibilidade, latência, taxa de erro e throughput. Disponibilidade mede a porcentagem de tempo em que o serviço responde corretamente. Latência mede o tempo de resposta, geralmente no percentil 95 ou 99, porque a média esconde picos. Taxa de erro mede a proporção de requisições que falham. Throughput mede o volume de requisições processadas, útil para serviços que degradam sob carga.

A escolha da métrica depende do tipo de serviço. Uma API de pagamentos prioriza disponibilidade e taxa de erro, porque uma falha tem impacto financeiro direto. Um site de conteúdo prioriza latência, porque o usuário abandona se a página demora. Um serviço de processamento em lote prioriza a conclusão dentro de uma janela de tempo. Não existe métrica universal, existe métrica que reflete a promessa central do serviço.

Um exemplo prático: uma loja virtual define que o checkout deve ter disponibilidade de 99,8% e latência abaixo de 2 segundos em 95% das requisições. Esses dois números juntos dizem mais que qualquer métrica isolada. Se a loja ficar no ar, mas o checkout demorar 10 segundos, o usuário abandona o carrinho e a conversão cai. O SLO de latência captura esse risco que o SLO de disponibilidade não captura.

O que é orçamento de erro?

Orçamento de erro é a quantidade de falha que o serviço pode tolerar em um período sem violar o SLO. Se o SLO é 99,9% de disponibilidade mensal, o orçamento de erro é 0,1% do tempo, aproximadamente 43 minutos por mês. Esse orçamento funciona como uma moeda: quando a equipe quer lançar uma mudança arriscada, ela "gasta" o orçamento de erro. Se o orçamento acabou, as mudanças são adiadas até que a confiabilidade se recupere.

O orçamento de erro transforma a discussão sobre confiabilidade em uma decisão de trade-off explícita. Em vez de debater subjetivamente se uma mudança é arriscada, a equipe olha o orçamento restante. Se restam 20 minutos de falha permitida no mês e a mudança pode causar 30 minutos de indisponibilidade, a resposta é não. Se restam 40 minutos, a mudança pode seguir, desde que o time monitore de perto.

Como monitorar e acompanhar SLOs?

SLOs precisam ser monitorados continuamente, não revisados apenas em reuniões mensais. Ferramentas de observabilidade, como Prometheus, Grafana e Datadog, permitem calcular a disponibilidade e a latência em janelas móveis de tempo. O acompanhamento em tempo real permite que a equipe veja quando o orçamento de erro está acabando e tome ação preventiva antes de violar o SLO.

A revisão periódica, geralmente a cada trimestre, é igualmente importante. O SLO que fazia sentido há seis meses pode não fazer mais depois de uma mudança de arquitetura ou de um aumento no tráfego. A revisão deve analisar se a meta ainda reflete a experiência do usuário e se o orçamento de erro é adequado. SLO não é uma decisão de uma vez, é um processo contínuo de calibração.

Quais erros evitar ao definir SLOs?

O primeiro erro é definir SLOs sem dados históricos, criando metas que não refletem a realidade do serviço. O segundo é escolher métricas que não representam a experiência do usuário, como monitorar a saúde do servidor em vez da latência percebida. O terceiro é definir metas impossíveis de alcançar, o que desmoraliza a equipe e torna o SLO irrelevante. O quarto é tratar o SLO como um número fixo, sem revisão periódica.

Outro erro comum é ignorar os custos de alcançar o SLO. Manter 99,99% de disponibilidade exige infraestrutura redundante, equipe de plantão e ferramentas de monitoramento sofisticadas. Para um serviço interno, esse investimento pode não se justificar. O SLO deve ser definido com base no impacto no negócio, não em um ideal abstrato de perfeição. Faturar não é lucrar: o custo de uma confiabilidade excessiva pode corroer a margem.

Exemplo prático de definição de SLO

Uma empresa de SaaS de gestão financeira quer definir um SLO para seu dashboard principal. A equipe mede por duas semanas e descobre que a disponibilidade atual é de 99,7% e a latência no percentil 95 é de 1,8 segundos. Com base nesses dados, define um SLO de 99,85% de disponibilidade e latência abaixo de 2 segundos em 95% das requisições. O orçamento de erro é de aproximadamente 65 minutos por mês.

Esse SLO é desafiador, porque exige uma melhora de 0,15 ponto percentual, mas não é impossível. A equipe prioriza as correções que mais impactam a disponibilidade, como ajustes no banco de dados e cache de consultas frequentes. Após três meses, a disponibilidade sobe para 99,9%, superando o SLO. A revisão trimestral analisa se a meta deve ser elevada ou se o orçamento de erro deve ser usado para acelerar lançamentos.

Como o SLO se relaciona com o SLA?

O SLO deve ser definido com o SLA em mente, mas não precisa ser idêntico a ele. Na prática, o SLO costuma ser mais rigoroso que o SLA, criando uma margem de segurança. Se o SLA promete 99% de disponibilidade, um SLO de 99,5% garante que a equipe perceba problemas antes que o cliente seja impactado. Essa folga é o orçamento de erro que protege o relacionamento comercial.

Quando o SLA é violado, há consequências financeiras e jurídicas. Quando o SLO é violado, a consequência é interna: a equipe precisa priorizar a confiabilidade nas próximas semanas. O SLO é, portanto, uma ferramenta de gestão de risco. Ele não impede falhas, mas reduz a probabilidade de que uma falha se transforme em uma violação de SLA.

FAQ

O que significa SLO em TI?

SLO (Service Level Objective) é uma meta interna de confiabilidade que a equipe de TI define para um serviço. Ela pode ser medida em disponibilidade, latência, taxa de erro ou outra métrica relevante. O SLO orienta decisões de engenharia e priorização de correções.

Qual a diferença entre SLA, SLO e SLI?

SLI (Service Level Indicator) é a métrica medida, como o percentual de requisições bem-sucedidas. SLO é a meta definida para essa métrica, como 99,9% de disponibilidade. SLA é o contrato externo com o cliente, que pode incluir penalidades se o nível não for cumprido.

Como calcular um SLO?

Para calcular um SLO, é preciso primeiro medir o comportamento atual do serviço por algumas semanas. Depois, define-se a meta com base nessa linha de base e no impacto da indisponibilidade no negócio. O SLO é expresso como um percentual, como 99,9% de disponibilidade mensal.

O que é orçamento de erro em SLO?

Orçamento de erro é a quantidade de falha permitida em um período sem violar o SLO. Se o SLO é 99,9%, o orçamento é 0,1% do tempo, cerca de 43 minutos por mês. Esse orçamento é usado para decidir se mudanças arriscadas podem ser lançadas.

Quais métricas usar em um SLO?

As métricas mais comuns são disponibilidade, latência, taxa de erro e throughput. A escolha depende do tipo de serviço. APIs de pagamento priorizam disponibilidade, sites de conteúdo priorizam latência. O ideal é combinar mais de uma métrica para capturar a experiência do usuário.

SLO é obrigatório para todo serviço?

Não. Serviços de baixa criticidade, como um site institucional, podem não precisar de um SLO formal. O custo de monitoramento e engenharia para manter um SLO alto pode não se justificar. SLO faz sentido quando a indisponibilidade tem impacto financeiro ou operacional relevante.