SRE ferramentas

SLI, SLO e SLA são três números diferentes

Um SLI é uma medição: eventos bons sobre eventos válidos — requisições respondidas em menos de 300 ms com status não 5xx, sobre todas as requisições que chegaram ao balanceador de carga. Um SLO é uma meta para essa razão ao longo de uma janela, como 99,9% em 30 dias corridos. Um SLA é um contrato que anexa dinheiro a uma meta geralmente mais frouxa. Confundir os três é como um time aciona alguém às 03:00 por um número que ninguém concordou em defender.

A parte difícil é a definição do SLI, não o percentual. Dois times que declaram 99,9% podem estar dizendo coisas diferentes, dependendo de o 429 contar como erro, de os health checks estarem no denominador e de a medição acontecer na borda da CDN ou dentro do serviço. Acerte numerador e denominador antes de discutir noves.

O SLO então produz o único número que muda comportamento: o error budget, 100% − SLO. A 99,9% em 30 dias você pode falhar 0,1% das requisições, ou ficar totalmente fora do ar por 43,2 minutos. É moeda — releases e migrações a gastam, uma janela nova a repõe, e um mês terminando em 100% normalmente significa que você entregou devagar demais.

Metas de disponibilidade em minutos reais

Noves são pouco intuitivos; minutos não são. Cada nove adicional divide a indisponibilidade permitida por dez.

Até 99,9%, um humano consegue notar, diagnosticar e corrigir dentro do orçamento. A 99,99% a franquia mensal é de 4,32 minutos — uma afirmação sobre failover automatizado, não sobre plantão.

Taxa de consumo: do SLO ao limiar de alerta

Taxa de consumo é a taxa de erro observada dividida pela taxa que o SLO permite. A identidade que importa é orçamento consumido = taxa de consumo × (janela ÷ período do SLO): ela transforma uma observação curta em uma afirmação sobre o mês inteiro.

Emparelhe cada limiar rápido com uma janela de confirmação mais curta (5 min a 14,4×, 30 min a 6×) para que o alerta se resolva quando o incidente se resolver. Consumos lentos pertencem a um ticket, não a um page.

Qual ferramenta responde qual pergunta

Recorra à Calculadora SLA quando você tem um percentual e precisa do equivalente em tempo: ela converte qualquer valor de 0 a 100 em indisponibilidade permitida por ano, por mês de 30 dias, por semana e por dia, com presets de 90% a 99,999%. É a ferramenta de revisão de contrato.

Use o Error Budget quando o número precisa guiar decisões de engenharia. Dê a ele um SLO, uma janela em dias e o tráfego esperado; ele devolve o orçamento como percentual, como indisponibilidade permitida e como uma contagem de requisições que podem falhar — 1.000 de um milhão a 99,9% em 30 dias, a figura que sobrevive a degradação parcial, coisa que um número de indisponibilidade não faz.

Primeiro, defina quais respostas são «ruins». Os Códigos HTTP são uma consulta código → significado — nome, classe e uma descrição de uma linha por código, filtráveis por número ou palavra-chave — então 400 («não foi possível entender a requisição») contra 422 («bem formada, mas semanticamente inválida») se resolve na hora. Eles marcam 307 e 308 como preservadores do método, mas não dizem nada sobre o que o 301 faz com um POST: clientes podem reescrevê-lo como GET e descartar o corpo, e é por isso que um endpoint POST movido permanentemente precisa de 308. Para ver o que um endpoint ao vivo devolve, os Cabeçalhos HTTP buscam a partir de api.sitekits.dev e reportam status final, saltos de redirecionamento, tempo de resposta e todo cabeçalho; o corpo nunca é recuperado, e destinos privados ou localhost são recusados pela proteção contra SSRF. Precisa de um corpo, cabeçalhos de autenticação ou um POST? O Testador REST API dispara do seu navegador direto ao destino, então a política de CORS dele se aplica. Mais no hub de HTTP, cuja matriz de redirecionamentos compara 301, 302, 303, 307 e 308 lado a lado.

Para evidência de latência, abra uma exportação do DevTools no Visualizador HAR: método, status, tipo, tamanho e tempo por requisição, com 4xx/5xx destacados. Sanitize-a com o Sanitizador HAR antes de anexar a um ticket — authorization, cookie, x-api-key, parâmetros que parecem tokens e todos os corpos se tornam [REDACTED].

Agendas, janelas e relógios

O cron é onde o trabalho de confiabilidade quebra em silêncio. O Editor Crontab interpreta uma expressão de cinco campos e lista os próximos oito disparos no fuso horário local do seu navegador. Leia a tabela como duas coisas ao mesmo tempo: as faixas de campo que todo cron compartilha, e a gramática mais estreita que este editor de fato interpreta — inteiros combinados com *, listas, faixas e passos, e nada mais.

Tudo naquela última coluna falha com uma única mensagem — Invalid cron expression (expected 5 fields) — mesmo quando os cinco campos estão presentes, então 0 3 * * 7 parece um erro de contagem quando na verdade é um erro de vocabulário. Escreva domingo como 0. Macros de linha (@daily, @reboot) e dialetos de seis campos com segundos são recusados do mesmo jeito, e faixas invertidas também — escreva 22-2 como 22-23,0-2. Uma forma falha silenciosamente em vez disso: 5/15 é lido como o valor único 5, enquanto parsers no estilo Kubernetes o expandem para 5-59/15, então escreva a faixa por extenso.

Três coisas que a tabela não consegue mostrar. Na combinação de dias, o editor aplica a regra POSIX de casar com qualquer um dos dois — com dia-do-mês e dia-da-semana ambos restritos, 0 0 1 * 1 significa o dia 1º e toda segunda-feira — mas ele decide o que é restrito pelo texto, contando como não restrito qualquer campo de dia que comece com *. Um passo escapa desse teste: */3 em dia-do-mês é lido como não restrito, então 0 0 */3 * 1 é combinado por E e dispara apenas nas segundas que caem no dia 1º, 4º, 7º e assim por diante. Escreva esses dias como 1-31/3 para recuperar a regra de qualquer um dos dois. Passos dividem o campo, não o relógio — */7 nos minutos roda de :00 até :56 e então reinicia com uma lacuna de 4 minutos. E a pré-visualização usa o fuso do seu navegador, enquanto o relógio do host normalmente está em UTC.

Linhas de tempo de incidente exigem o mesmo rigor: o Unix Time lê valores abaixo de 1e12 como segundos e maiores como milissegundos, e o Conversor de Fuso Horário fixa um instante em 12 fusos IANA com o deslocamento de horário de verão correto antes de você anunciar uma janela de manutenção. Mais do kit de plantão: ferramentas para SREs.

Erros comuns

O mês do contrato não é o mês da calculadora

A calculadora usa um mês fixo de 30 dias e um ano de 365 dias. Por mês de calendário, um SLO de 99,9% permite 40,32 minutos em um fevereiro de 28 dias e 44,64 em julho — 10% de variação com a mesma redação.

A disponibilidade se multiplica ao longo da cadeia de dependências

Três dependências rígidas a 99,9% cada, em série, dão 0,999³ = 99,70%: cerca de 2,16 horas de indisponibilidade mensal, não 43,2 minutos. Sem redundância, você não pode prometer mais do que o produto do caminho crítico.

Orçamentos por tempo e por requisição não são intercambiáveis

A figura de indisponibilidade permitida assume 100% de taxa de erro enquanto está fora do ar. Uma degradação que falha 5% das requisições consome um orçamento de requisições de 99,9% a 50× enquanto quase não move um relógio de uptime movido por sondas sintéticas.

O intervalo da sua sonda é o piso da sua resolução

Uma verificação sintética de 60 segundos não consegue enxergar uma queda de 20 segundos, e cada sonda perdida registra aproximadamente um minuto — já 23% de um orçamento mensal de 99,99%. Acima de três noves, meça a partir dos logs de requisição, não de polling.