SRE na prática: SLI, SLO e error budget sem mistério

SRE na prática: SLI, SLO e error budget sem mistério

SRE (Site Reliability Engineering) nasceu no Google e foi popularizado pelos livros gratuitos da própria empresa. A ideia-chave: confiabilidade é uma feature do sistema e precisa ser medida e orçada, não tratada como "o ideal é 100%". Três conceitos sustentam tudo — e um quarto (toil) explica por que automatizar é parte do trabalho.

SLI — o que você mede

Um SLI (Service Level Indicator) é uma medida quantitativa de como o serviço está se comportando. Os candidatos clássicos são disponibilidade, latência, taxa de erros, throughput e saturação.

Exemplo de SLI de disponibilidade: requisições bem-sucedidas / total de requisições.

SLO — a meta

Um SLO (Service Level Objective) é um alvo (ou faixa) para um SLI, ao longo de uma janela de tempo. Por exemplo: "99,9% das requisições bem-sucedidas em 28 dias".

Atenção: SLO não é SLA. O SLA é o contrato com o cliente (com penalidades); o SLO é a meta interna de engenharia, geralmente mais rígida que o SLA.

Error budget — o orçamento de falha

Aqui está a sacada que muda a cultura. O error budget = 1 − SLO.

• Um SLO de 99,9% dá um error budget de 0,1%.
• Se o serviço recebe 1.000.000 de requisições em quatro semanas, esse 0,1% equivale a um orçamento de 1.000 erros no período.

Enquanto há orçamento sobrando, o time pode arriscar — lançar features, fazer experimentos. Quando o orçamento se esgota, a error budget policy entra em ação: tipicamente congela-se o lançamento de features e o foco vira confiabilidade até voltar ao verde. Isso transforma a velha briga "produto quer velocidade × ops quer estabilidade" em um dado objetivo e compartilhado.

Toil — o trabalho que não escala

Toil é o trabalho operacional que é manual, repetitivo, automatizável, tático, sem valor duradouro e que cresce linearmente com o serviço. Exemplos: releases manuais, resets de senha repetidos, reconhecer o mesmo alerta todo dia, escalar infraestrutura na mão.

O Google recomenda manter o toil abaixo de ~50% do tempo de um SRE — o resto deve ir para engenharia que reduz toil futuro (automação, melhoria de plataforma). Se o toil domina, a operação não escala.

Por onde começar

1. Escolha 1 SLI que reflita a experiência do usuário (ex.: latência da rota crítica).
2. Defina um SLO realista (comece observando o comportamento atual, não chute 99,99%).
3. Calcule o error budget e combine a política: o que acontece quando ele acaba.
4. Liste seu toil e ataque o mais caro primeiro com automação.

Fontes

• Google SRE — Service Level Objectives (SRE Book): https://sre.google/sre-book/service-level-objectives/
• Google SRE — Implementing SLOs (Workbook): https://sre.google/workbook/implementing-slos/
• Google SRE — Error Budget Policy: https://sre.google/workbook/error-budget-policy/