SLI, SLO e Error Budget: Confiabilidade Medida com Números

Pergunte a qualquer equipe se o sistema dela precisa ser confiável e a resposta será um sim óbvio. Pergunte quão confiável, com um número, e o silêncio revela o problema. "Confiável" sem métrica é um desejo, não um objetivo. E desejos não orientam decisões: quando chega a hora de escolher entre lançar uma funcionalidade nova e investir em estabilidade, "queremos ser confiáveis" não diz qual escolher. A engenharia de confiabilidade, o SRE, existe justamente para transformar esse desejo vago em números que decidem.

O tripé conceitual que faz isso são os SLIs, os SLOs e os error budgets. Popularizados pela prática de Site Reliability Engineering que o Google formalizou e descreveu publicamente a partir de 2016, esses conceitos são hoje vocabulário comum de qualquer operação séria. Mas são frequentemente mal usados, tratados como jargão para dashboards em vez de como ferramentas de decisão. Este artigo recupera o que eles realmente significam e por que, juntos, mudam a forma como uma equipe opera.

A confiabilidade perfeita é a meta errada#

Comece por uma verdade contraintuitiva: buscar 100% de confiabilidade é um erro. Não porque seja difícil, embora seja, mas porque é a meta errada.

O primeiro motivo é econômico. O custo de confiabilidade cresce de forma brutal perto do topo. Sair de 99% para 99,9% custa caro; sair de 99,9% para 99,99% custa muito mais; e cada nove adicional multiplica o esforço enquanto o ganho percebido pelo usuário encolhe. Em algum ponto, você está gastando fortunas para reduzir uma indisponibilidade que ninguém nota.

O segundo motivo é mais profundo: o usuário não percebe a diferença entre confiabilidade perfeita e quase perfeita, porque a cadeia inteira entre o seu sistema e ele já tem falhas. A rede do celular oscila, o Wi-Fi cai, o navegador trava. Se a jornada até o usuário já é, digamos, 99,9% confiável por fatores fora do seu controle, tornar o seu serviço 99,999% confiável é invisível: o gargalo está em outro lugar. Perseguir noves que o usuário não enxerga é queimar dinheiro por vaidade.

A conclusão do SRE é libertadora: existe um nível de confiabilidade bom o suficiente, e o trabalho é definir esse nível conscientemente e mirá-lo, em vez de perseguir uma perfeição cara e imperceptível. Esse alvo consciente é o SLO.

SLI: o que você mede#

Um Service Level Indicator, ou SLI, é uma medida quantitativa de algum aspecto do nível de serviço. É um número, tipicamente uma proporção de eventos bons sobre eventos totais, que expressa uma dimensão da experiência do usuário.

Os SLIs mais comuns capturam dimensões que o usuário sente diretamente. Disponibilidade: a fração de requisições que foram atendidas com sucesso. Latência: a fração de requisições respondidas abaixo de um limite de tempo aceitável. Taxa de erro: a fração de requisições que falharam. Qualidade ou frescor, em casos específicos, medindo se o dado servido está correto ou atualizado.

O que faz um bom SLI é ele medir a experiência real do usuário, não uma métrica interna conveniente. A ocupação de CPU de um servidor é uma métrica útil para operação, mas é um SLI ruim, porque o usuário não se importa com a CPU; ele se importa se a página carregou rápido e sem erro. Um bom SLI responde à pergunta "o usuário está tendo uma boa experiência?", e por isso costuma ser medido o mais perto possível do usuário, na borda por onde as requisições dele entram. Um detalhe técnico que importa: latência quase nunca deve ser medida pela média, que esconde os casos ruins; mede-se por percentis altos, como o p99, que captura o que os 1% de usuários mais azarados sentem.

SLO: o alvo que você promete a si mesmo#

Um Service Level Objective, ou SLO, é a meta que você define para um SLI ao longo de uma janela de tempo. Se o SLI é "a fração de requisições bem-sucedidas", o SLO é "99,9% das requisições devem ser bem-sucedidas ao longo de 30 dias".

O SLO é a peça central de todo o edifício, porque é a decisão consciente de "bom o suficiente" que discutimos. Ele não deve ser aspiracional nem tirado do ar; deve refletir o que o usuário realmente precisa e o que o negócio realmente consegue sustentar. Um SLO alto demais compromete a equipe a um esforço insustentável por uma confiabilidade que ninguém pediu; um SLO baixo demais entrega uma experiência ruim que os usuários vão sentir e reclamar. Acertar o SLO é acertar a promessa.

Vale distinguir o SLO do SLA, o Service Level Agreement, com que é frequentemente confundido. O SLA é um contrato com consequências, tipicamente financeiras, com um cliente externo: "se a disponibilidade cair abaixo de 99,5%, devolvemos parte do pagamento". A prática saudável é definir o SLO interno mais rigoroso que o SLA externo, deixando uma margem de segurança. Assim, quando você viola o SLO interno, ainda tem folga antes de violar o SLA e pagar a multa. O SLO é o alarme que dispara antes de a coisa virar prejuízo contratual.

Error budget: o número que muda decisões#

Aqui está a virada de chave, o conceito que transforma SLOs de dashboard em ferramenta de gestão: o error budget, ou orçamento de erro.

Se o seu SLO é 99,9% de sucesso, então você está explicitamente dizendo que 0,1% de falha é aceitável. Esse 0,1% não é um fracasso a ser evitado a todo custo; é um orçamento. É a quantidade de indisponibilidade que você tem permissão de gastar dentro da janela. Num mês, 0,1% equivale a cerca de 43 minutos de falha permitida. Esse tempo é seu para usar.

A genialidade do error budget é o que ele destrava. O eterno conflito entre a equipe de desenvolvimento, que quer lançar rápido, e a de operação, que quer estabilidade, se dissolve num número compartilhado. Enquanto há orçamento de erro sobrando, a equipe pode lançar com agressividade, correr riscos calculados, experimentar, porque há margem para absorver eventuais falhas. Quando o orçamento se esgota, a prioridade muda automaticamente: chega de funcionalidades novas, o foco vira estabilizar até o orçamento se recuperar na próxima janela. A decisão de "lançar ou consolidar" deixa de ser uma discussão de opiniões e vira uma consequência do saldo do orçamento.

Isso também reformula a relação com as falhas. Um deploy que consome um pouco do orçamento de erro não é uma catástrofe; é o uso previsto de um recurso que existe para ser gasto. Gastar orçamento em experimentos que geram valor é bom uso. O que o error budget combate é gastá-lo sem retorno, em incidentes evitáveis, e correr sem saber quanto ainda resta. Ele dá visibilidade e disciplina sem transformar cada falha num drama.

Toil e a automação como consequência#

Há um conceito irmão que completa a filosofia do SRE: o toil, o trabalho operacional manual, repetitivo, sem valor duradouro, que cresce com o tamanho do sistema. Reiniciar um serviço na mão, aplicar o mesmo remendo toda semana, seguir um roteiro manual a cada deploy: isso é toil. É trabalho que precisa ser feito mas não deixa nada melhor para trás.

A prática de SRE trata o toil como algo a ser medido e limitado, tipicamente reservando uma parcela do tempo da equipe para trabalho de engenharia que elimina toil por automação, em vez de apenas executá-lo indefinidamente. A lógica é de sustentabilidade: se o toil cresce proporcionalmente ao sistema e a equipe não, chega o dia em que a equipe só apaga incêndios e nunca melhora nada. Automatizar o repetitivo é o que mantém a operação escalável e a equipe livre para o trabalho que muda o patamar.

Aqui os pilares se conectam. Medir SLIs com precisão depende de coletar os sinais certos, o que é exatamente o trabalho da observabilidade; sem dados bons, não há SLI honesto. Se essa base te interessa, vale entender como logs, métricas e traces fornecem a matéria-prima que alimenta cada indicador de nível de serviço.

Blameless: o postmortem que corrige sistemas, não pessoas#

Falta um pilar cultural sem o qual todo o aparato de números desmorona, e é o mais difícil de implantar porque mexe com incentivos humanos: a cultura blameless, sem culpados. Quando um incidente acontece, a reação instintiva de muitas organizações é procurar o responsável, o engenheiro que apertou o botão errado, e a lição termina em "tenha mais cuidado". Essa reação, por mais natural que seja, destrói a confiabilidade a longo prazo.

O problema é que culpar pessoas ensina apenas uma coisa: a esconder erros. Se relatar uma falha significa expor-se a punição, as pessoas passam a esconder falhas, e o sistema perde exatamente a informação de que precisa para melhorar. Além disso, culpar um indivíduo trata o sintoma e ignora a doença: se o sistema permitiu que um único erro humano causasse um incidente grave, o problema não é a pessoa, é o sistema que não tinha salvaguardas. A próxima pessoa cometeria o mesmo erro.

O postmortem blameless inverte isso. Depois de um incidente, a equipe escreve uma análise honesta focada em o que aconteceu, por que o sistema permitiu que acontecesse, e que mudanças estruturais impediriam a recorrência, tudo sem apontar dedos. A premissa é que as pessoas agiram razoavelmente com a informação que tinham, e que a falha revela uma fragilidade do sistema a ser corrigida. Isso gera duas coisas preciosas: relatos honestos, porque ninguém teme punição, e correções estruturais, porque o foco é o sistema. Cada incidente vira aprendizado que fortalece o todo, em vez de um culpado envergonhado e uma fragilidade intacta esperando a próxima vítima. Sem essa cultura, os SLOs e error budgets viram instrumentos de cobrança e medo, e a operação regride ao teatro de esconder problemas.

De sentimentos a engenharia#

Reunindo o tripé: o SLI é o que você mede, a experiência real do usuário traduzida em número. O SLO é o alvo consciente de "bom o suficiente" que você promete honrar. O error budget é a folga entre a perfeição e o SLO, um recurso a ser gasto com sabedoria, que transforma a tensão entre velocidade e estabilidade numa decisão baseada em saldo.

O que muda, no fundo, é a natureza das conversas. "O sistema está confiável?" vira "estamos dentro do SLO?". "Podemos arriscar esse lançamento?" vira "temos orçamento de erro para isso?". "Vale a pena investir em estabilidade?" vira "o orçamento está se esgotando cedo demais todo mês?". Confiabilidade deixa de ser um sentimento sobre o qual as pessoas discordam e vira um número sobre o qual elas decidem. É essa tradução, de desejo para engenharia, que faz do SRE mais do que um cargo novo: uma forma diferente e mais honesta de operar sistemas que precisam funcionar.