“Cinco noves” na parede não é engenharia. É slogan. Cem por cento de disponibilidade é um objetivo que come o calendário, o orçamento e a coragem de publicar. SRE (Site Reliability Engineering) começa no lugar oposto: confiabilidade é o que o usuário sente, medido, com uma folga combinada para o sistema mudar.
Sem número, a discussão vira gosto: o time de produto quer soltar, o time de operação quer congelar. Com número, a discussão vira conta. Ainda há conflito. Pelo menos o conflito cabe numa reunião.
SLI, SLO, SLA — três camadas, três donos
SLI (indicador) é a métrica do que importa na ponta: proporção de requests boas, latência abaixo de um limiar, taxa de jobs que terminam certo, estoque de dados fresco. A fórmula típica é honesta: eventos bons dividido por eventos válidos. “Válidos” exclui o que você não promete — health check interno, cliente que mandou 400, manutenção anunciada, se o contrato for esse.
Escolher SLI é escolher o que o usuário percebe. CPU do servidor não é SLI de serviço. Tempo até o primeiro byte da API de checkout, para requests autenticadas na região X, pode ser. Poucos SLIs bons vencem dezenas de gráficos que ninguém usa para decidir.
SLO (objetivo) é a meta interna sobre o SLI, num período: 99,9% das requests mensais abaixo de 300 ms, 99,95% de disponibilidade do checkout. Não é contrato jurídico. É guia de ação: podemos soltar a feature? Precisamos parar e apagar incêndio? O SLO deve ser atingível. Meta heroica que estoura toda semana treina o time a ignorar o número.
SLA é o contrato com o cliente — reembolso, multa, cláusula. Quase sempre mais frouxo que o SLO. Se o SLA e o SLO são iguais, qualquer oscilação vira advogado. SRE usa o SLO para operar. O SLA é o chão legal, não o volante.
flowchart TD
A[Usuário sente] --> B[SLI]
B --> C[SLO interno]
C --> D{Orçamento de erro}
D -->|Ainda há folga| E[Pode entregar]
D -->|Folga acabou| F[Congela e conserta]
C --> G[SLA com cliente]
G --> H[Consequência contratual]
classDef ouro fill:#FBF5E4,stroke:#C9A227,color:#0B1F18,stroke-width:1.4px
classDef verde fill:#F3FAF7,stroke:#1E7A57,color:#0B1F18,stroke-width:1.4px
classDef fim fill:#14513B,stroke:#0F3328,color:#FBFAF6,stroke-width:1.4px
class A,B ouro
class C,D,G verde
class E,F,H fim
Orçamento de erro é permissão, não desculpa
Se o SLO de disponibilidade no mês é 99,9%, o orçamento de erro é 0,1% do tempo (ou das requests, conforme o SLI). Esse 0,1% não é falha moral. É a folga para deploy, manutenção, incidente e experimentação. Sem folga, a única política honesta seria nunca mudar o sistema. Produto morto também “não cai” — até o usuário ir embora.
Quando o orçamento está inteiro, o time entrega. Quando está no fim, o time para de queimar confiabilidade: freeze de feature, foco em causa, rollback mais agressivo. Quando estoura, o trabalho de confiabilidade vence o roadmap até o SLO se recuperar. Isso só funciona se produto e engenharia comprarem o número antes do incidente.
Orçamento apertado demais é outro erro. 99,99% em serviço que o usuário usa uma vez por semana, com cliente HTTP ruim e dependência de terceiros, estoura no primeiro timeout. Vocês gastam ouro para uma diferença que ninguém percebe. 99% em checkout de pagamento pode ser pouco. O valor é uma decisão de produto: quanto atraso e erro o negócio aceita em troca de velocidade de mudança?
Alertas devem seguir o orçamento, não o pico de CPU. Alertar cada blip treina cegueira. Alertar quando o gasto do orçamento está rápido demais — burn rate — dá tempo de agir antes do SLO do mês morrer. MTTR importa: orçamento pequeno some se você demora para ver e demora para resolver.
| Conceito | Pergunta que responde | Uso típico |
|---|---|---|
| SLI | O que medimos que o usuário sente? | Proporção de eventos bons |
| SLO | Qual meta interna neste período? | Guia de deploy e prioridade |
| SLA | O que está no contrato? | Multa, crédito, jurídico |
| Orçamento de erro | Quanta falha ainda cabe? | Permissão para mudar |
Disponibilidade é produto
“O site tem que estar sempre no ar” não é requisito. É medo. Requisitos de verdade soam assim: o checkout, no horário comercial do Brasil, responde 99,9% das tentativas em menos de 400 ms; o relatório gerencial pode esperar; a busca interna pode degradar. Cada frase implica um SLI, um SLO e um custo.
Cem por cento pede redundância que você não testa, processo que você não aguenta e recusa de mudança. Quatro noves em tudo é, na prática, dizer não para o calendário de produto sem dizer não. Melhor dizer não em voz alta, com número, num serviço que realmente precisa — e dizer sim no restante.
Responsabilidade compartilhada vale aqui como no restante da operação: quem desenvolve não “joga o pacote no muro”, quem opera não é o único dono da madrugada. O SLO é o objeto comum. Feature que queima o orçamento não é vitória de produto. Freeze eterno não é vitória de SRE.
Como começar sem o livro inteiro
- Escolha um serviço que o usuário percebe (não o cron interno).
- Defina um ou dois SLIs: disponibilidade e latência, com eventos válidos claros.
- Escolha um SLO atingível com a história dos últimos meses, não com o desejo do slide.
- Calcule o orçamento no período (mês é comum).
- Combine com produto o que acontece quando a folga acaba.
- Alerte burn, não ruído.
- Revise o SLO quando o produto mudar de verdade — não toda sprint, não nunca.
Se você não tem história, comece medindo. SLO de palpite é melhor do que slogan, pior do que SLO calibrado. Em poucas semanas o palpite vira dado.
Confiabilidade não é o oposto de entrega. É o orçamento que torna a entrega sustentável. SLI mostra. SLO mira. O erro combinado autoriza o próximo ship — ou o bloqueia a tempo, enquanto ainda há mês pela frente.
Quem coloca o sistema no ar na Programming One encontra a mesma pergunta: o que medimos, o que prometemos, o que o erro ainda permite.
Leia também: Jenkins, Docker e a pipeline que você explica e Escalabilidade vertical e horizontal.
Python One
Do primeiro print à API REST em produção.