SRE na prática: SLIs, SLOs e a cultura de confiabilidade
"O sistema precisa estar sempre no ar" é um objetivo que parece nobre e é, na verdade, uma armadilha. Buscar 100% de disponibilidade é buscar o infinito: cada nove adicional de confiabilidade custa exponencialmente mais, e a partir de certo ponto o esforço para nunca falhar consome tanto que o produto para de evoluir. A engenharia de confiabilidade (SRE) nasceu no Google a partir de uma provocação madura: confiabilidade não é ausência de falhas a qualquer custo, e sim um alvo mensurável, negociado contra a velocidade de entrega. Esse deslocamento de mentalidade é o coração da prática.
Este guia trata de SRE como prática e cultura: como medir confiabilidade com SLIs e SLOs, como o error budget equilibra estabilidade e velocidade, como reduzir o trabalho repetitivo (toil), e como aprender com falhas sem procurar culpados. O foco é a disciplina de operar sistemas confiáveis, um tema que usa a telemetria da observabilidade, mas vai além dela, para as decisões e a cultura ao redor.
Medir confiabilidade: SLI e SLO
Não dá para gerenciar o que não se mede, e "o sistema está bom" não é uma medida. SRE começa transformando confiabilidade em números concretos.
Um SLI (Service Level Indicator) é uma métrica que reflete a experiência real do usuário. Não qualquer métrica, e sim as que importam para quem usa o produto: a porcentagem de requisições que respondem com sucesso, a latência do percentil 99, a taxa de erros. Um bom SLI mede o que o usuário sente, não o que é fácil de coletar.
Um SLO (Service Level Objective) é a meta para um SLI: o alvo que você se compromete a cumprir. Por exemplo, "99,9% das requisições respondem com sucesso ao longo de 30 dias". O SLO é a definição explícita de quão confiável o sistema precisa ser, decidida de propósito, não deixada ao acaso.
Existe ainda o SLA (Service Level Agreement), o contrato comercial com o cliente, geralmente com penalidades. A boa prática é manter o SLO interno mais rígido que o SLA, para que a equipe reaja e corrija muito antes de o compromisso comercial ser ameaçado.
| Sigla | O que é | Exemplo |
|---|---|---|
| SLI | A métrica medida | Porcentagem de requisições com sucesso |
| SLO | A meta interna para o SLI | 99,9% de sucesso em 30 dias |
| SLA | O contrato com o cliente | 99,5% ou reembolso |
O error budget: permissão para arriscar
Aqui está a ideia mais poderosa e contraintuitiva do SRE. Se o SLO é 99,9%, então 0,1% de falha é aceitável, de propósito. Esse 0,1% é o error budget (orçamento de erro): a quantidade de indisponibilidade que você tem permissão para gastar no período.
O error budget transforma uma tensão eterna em uma conversa objetiva. Engenharia quer lançar rápido; operações querem estabilidade. O orçamento de erro resolve o impasse com dados:
- Se ainda há orçamento, o time pode lançar com mais ousadia, correr riscos, experimentar. Falhas cabem no budget.
- Se o orçamento se esgotou, a prioridade muda automaticamente para estabilidade: menos lançamentos arriscados, mais foco em confiabilidade, até o sistema voltar a respeitar o SLO.
Isso acaba com a discussão baseada em opinião. A pergunta "podemos lançar essa mudança arriscada?" passa a ter uma resposta objetiva: "quanto do error budget ainda temos?". O orçamento de erro é o que torna a confiabilidade uma decisão compartilhada entre quem entrega e quem opera, em vez de uma queda de braço.
Toil: o inimigo a automatizar
Toil é o trabalho operacional manual, repetitivo, automatizável e sem valor duradouro: reiniciar um serviço na mão toda semana, aplicar a mesma correção repetidas vezes, executar um procedimento rotineiro passo a passo. Toil não é todo trabalho chato; é especificamente o esforço que uma máquina poderia fazer e que cresce à medida que o sistema cresce.
O problema do toil é que ele escala com o sistema e sufoca a equipe. Quanto mais serviços, mais reinícios manuais, mais tarefas repetidas, até o time gastar todo o tempo apagando incêndios e nenhum melhorando o sistema. Por isso o SRE trata a redução de toil como trabalho de primeira classe: medir quanto tempo é gasto nele e investir em automação para eliminá-lo. Um bom sinal de saúde é a equipe ter tempo para engenharia de verdade, não só para operar o que já existe.
Postmortems sem culpa
Falhas vão acontecer, é uma certeza estatística. O que separa um time que melhora de um que repete os mesmos erros é como ele reage à falha. O SRE adota o postmortem sem culpa (blameless): depois de um incidente, a equipe documenta o que aconteceu, por que aconteceu e como evitar a recorrência, sem procurar um culpado.
A razão é prática, não apenas gentil. Quando as pessoas temem punição, elas escondem erros, omitem detalhes e param de relatar quase incidentes, e o time perde justamente a informação de que precisa para melhorar. Um postmortem sem culpa parte do princípio de que as pessoas agiram com boa intenção diante do que sabiam, e foca no sistema que permitiu a falha: o alerta que faltou, o processo frágil, a documentação ausente. Cada incidente vira aprendizado que fortalece o sistema, não um julgamento que enfraquece a equipe.
On-call saudável
Alguém precisa estar de plantão para responder quando algo quebra fora do horário, o on-call. Feito errado, o on-call queima as pessoas: alertas demais, muitos deles falsos, noites sem dormir, rotatividade de talento. Feito certo, ele é sustentável e até valioso. Princípios de um on-call saudável:
- Alertas que importam. Só deve acordar alguém o que exige ação humana imediata. Alerta que não é acionável é ruído, e ruído leva à fadiga que faz ignorar o alerta real.
- Carga distribuída. O plantão gira entre a equipe, com escalas humanas, sem sobrecarregar sempre os mesmos.
- Tempo para se recuperar. Quem passou uma noite acordado por um incidente precisa de folga, não de um dia normal de trabalho em seguida.
- Cada incidente reduz o próximo. O aprendizado do postmortem elimina a causa, para que aquele alerta específico não acorde ninguém de novo.
Um on-call saudável é sinal de um sistema saudável: se o plantão vive tocando, o problema não é a escala de plantão, é a confiabilidade do sistema.
Quando adotar SRE
SRE não é para todo mundo desde o dia um. Uma startup com dois desenvolvedores não precisa de SLOs formais nem de um time de SRE; ela precisa é encontrar seu produto. A prática começa a valer a pena quando o sistema fica grande e crítico o bastante para que a confiabilidade seja um problema de negócio, e a operação, um custo real. Antes disso, adotar toda a cerimônia é overengineering. O ponto de virada costuma ser quando indisponibilidade começa a custar clientes e receita, e quando o toil consome tempo que deveria ir para o produto.
A boa notícia é que a cultura do SRE vale antes da estrutura. Medir a experiência do usuário, pensar em orçamento de erro, automatizar o repetitivo e aprender sem culpa são hábitos que qualquer time pode cultivar cedo, muito antes de contratar alguém com "SRE" no cargo.
Confiabilidade é uma decisão, não um acidente
SRE reformula a confiabilidade: em vez de um ideal vago de "nunca cair", ela vira um alvo medido, negociado contra a velocidade e sustentado por cultura. SLIs e SLOs dão a linguagem; o error budget equilibra estabilidade e entrega; a automação combate o toil; os postmortems sem culpa transformam falha em aprendizado; o on-call saudável protege as pessoas. Nada disso é sobre buscar a perfeição impossível, e sim sobre ser confiável o suficiente, de propósito, gastando esforço onde ele rende e liberando o time para construir. Um sistema em que a confiabilidade é decisão consciente, e não sorte, é o que permite crescer sem viver em pânico.
Sua confiabilidade é sorte ou decisão? Na ConstructorTI, ajudamos times a adotar a prática de SRE no ponto certo, com SLIs e SLOs que refletem o usuário, error budgets que equilibram velocidade e estabilidade, e uma cultura de aprendizado sem culpa. Se o on-call vive tocando ou a indisponibilidade começou a custar clientes, fale com a nossa engenharia e receba um diagnóstico da confiabilidade do seu produto.