Blog/Artigos · Operações
Objetivo realista, error budget, burn rate e alerta multi-janela, com o SRE do Google, Alex Hidalgo e Nobl9.
Se o prumo mede se a parede está reta, a linha define até onde ela vai. Yeshayahu pareia os dois: o juízo é a linha, a justiça é o prumo. Em confiabilidade, o SLI é o prumo e o SLO é a linha. O erro que quase todo time comete é mirar a parede perfeita, 100% de disponibilidade, um alvo caro, impossível e desnecessário. O SLO, Service Level Objective, traça a linha honesta: quanto de confiabilidade é bom o suficiente para o usuário não reclamar, e nem um nove a mais.
Cada nove de disponibilidade a mais custa exponencialmente mais: sair de 99,9% para 99,99% pode multiplicar o investimento em redundância e engenharia. E o usuário raramente percebe a diferença, porque a rede dele, o wifi de casa e o celular já falham mais que isso. Perseguir 100% é gastar fortuna para melhorar um número que ninguém sente, enquanto features que o cliente quer ficam paradas.
O SLO inverte a pergunta: em vez de quão confiável dá para ser, pergunta quão confiável precisa ser para o usuário ficar satisfeito. A resposta quase nunca é 100%. O livro de SRE do Google fez essa ideia virar prática, e Alex Hidalgo, em Implementing Service Level Objectives, transformou em método detalhado. O SLO é um alvo deliberadamente abaixo do perfeito, porque a margem entre ele e 100% é onde mora a liberdade de inovar.
Aqui está a ideia mais poderosa do SRE. Se o SLO é 99,9%, então 0,1% de falha é permitido, e esse 0,1% é o error budget: um orçamento concreto de erro que o time pode gastar. Enquanto há budget, pode-se arriscar, lançar rápido, experimentar. Quando o budget se esgota, a prioridade vira estabilidade, e novos lançamentos param até a confiabilidade voltar ao alvo. O budget transforma uma briga eterna, inovar contra estabilizar, numa regra objetiva.
O error budget é o que resolve o conflito histórico entre desenvolvimento, que quer lançar, e operação, que quer estabilidade. Em vez de discutir por opinião, os dois olham o mesmo número: sobrou budget, o desenvolvimento tem liberdade; acabou, a operação tem prioridade. É uma política acordada com o produto, não uma imposição do SRE, e é isso que a torna sustentável. O número decide, ninguém precisa ganhar a discussão.
Alerta tradicional dispara por limiar instantâneo, e por isso mente nos dois sentidos: grita com um pico de dez segundos que não afeta ninguém, e fica calado numa degradação lenta que consome o budget do mês inteiro. A resposta madura é o burn rate: a velocidade com que se queima o error budget. Queimar rápido demais é o que importa, porque significa que, no ritmo atual, o budget do período acaba antes da hora.
O padrão de ouro, detalhado por Alex Hidalgo e adotado pelo Google, é o alerta multi-janela multi-burn-rate: combina uma janela curta e uma longa com taxas de queima diferentes, de modo que só dispara quando o problema é rápido e sustentado, não um espasmo momentâneo. Isso corta o alarme falso pela raiz e faz o pager tocar por degradação real. Ferramentas como o Nobl9 gerenciam SLO e budget como produto, mas a lógica do burn rate você precisa entender para configurar bem.
| Dia do mês | Queima saudável | Queima acelerada |
|---|---|---|
| 0 | 0 | 0 |
| 5 | 40 | |
| 10 | 30 | 85 |
| 14 | 100 | |
| 20 | 62 | |
| 30 | 92 |
O SLO só funciona quando é acordo, não decreto. Ele é a linha que engenharia e produto traçam juntos: o produto diz quanto de confiabilidade o negócio precisa, a engenharia diz quanto custa cada nível, e os dois assinam o alvo e a política de budget. SLO imposto pelo SRE sem o produto na mesa é ignorado no primeiro conflito de prazo; SLO acordado é respeitado porque os dois lados entendem a troca.
Na prática, poucos SLOs bem escolhidos valem mais que dezenas medíocres. Um por jornada crítica, com error budget e alerta por burn rate, e uma revisão periódica para reajustar o alvo cronicamente estourado ou folgado demais. Foi assim que, na CRDC, os nove SLOs com error budget substituíram o monitoramento de infraestrutura ruidoso: menos números, mas cada um significando algo que o cliente sente e que o time se compromete a defender.
O SLO é a linha que separa confiável de perfeito: um alvo abaixo de 100%, acordado com o produto, com error budget que decide quando inovar e quando frear, e alerta por burn rate que toca pelo que dói. O SRE do Google deu a ideia, Alex Hidalgo deu o método, e o Nobl9 dá a ferramenta. Poucos SLOs bem escolhidos valem mais que muitos medíocres. A IA projeta o budget, calibra o burn rate e informa a conversa com o produto, mas traçar a linha certa continua sendo acordo entre quem constrói e quem decide o negócio.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Operaçõesמִשְׁקָלֶת
Não se governa o que não se mede, e quase todo mundo mede a coisa errada. O SLI é a métrica que reflete a experiência real do usuário, com os quatro sinais de ouro, RED e USE.
Operaçõesנֶדֶר
O SLA é o compromisso externo com penalidade; o SLO é a meta interna mais dura que o protege. Entenda a hierarquia, a conta dos noves e por que o SLO sempre vem antes do SLA.
