Calculadora de Error Budget

Visão geral

Um SLO é uma promessa expressa como razão: esta fração das requisições vai ter sucesso. O corolário útil dessa promessa é o resto — o error budget, a quantidade de falha que você tem permissão de acumular antes de ter quebrado o combinado.

Enquadrar confiabilidade como orçamento muda a conversa. «Não quebre nada» não é uma meta de engenharia, porque precifica risco em infinito e, portanto, proíbe lançar qualquer coisa. «Você tem 43 minutos de indisponibilidade neste mês e já gastou 12 deles» é uma meta contra a qual se pode planejar.

Esta calculadora converte um SLO em três números: o budget como porcentagem, a indisponibilidade permitida para a sua janela e — se você informar uma contagem de requisições — o número de falhas individuais que cabe dentro dele.

Como usar

1. Informe o SLO com o qual você está se comprometendo, em porcentagem.
2. Defina a janela em dias. 30 é o mês móvel usual; 7 funciona para um ciclo de feedback mais rápido; 90 acompanha uma revisão trimestral.
3. Opcionalmente, informe o volume de requisições daquela janela para obter a contagem de falhas.

Lendo os números

Error budget é simplesmente 100% − SLO. Ele parece trivialmente pequeno ao lado do SLO, e essa é justamente a questão: a diferença entre 99,9% e 99,99% é uma redução de dez vezes naquilo que você tem permissão de gastar, e é por isso que cada nove adicional custa muito mais que o anterior.

Indisponibilidade permitida é o budget aplicado à janela como tempo de relógio. É o número mais útil para conversar com gente de fora do time, porque «cerca de 43 minutos por mês» é concreto de um jeito que «99,9%» não é.

Requisições com falha permitidas é o mesmo budget aplicado a volume. É esse o número contra o qual se planeja, porque ele mapeia direto para o que você consegue observar nas suas métricas — uma contagem de respostas 5xx, ou de requisições acima do seu limite de latência.

Budget por tempo e por requisições não são a mesma coisa

Dois incidentes podem consumir budget de tempo idêntico e budget de requisições completamente diferente, e vice-versa.

Uma queda total de cinco minutos às 03:00 custa cinco minutos de indisponibilidade e pouquíssimas requisições. Uma degradação de um dia inteiro em que 0,5% das requisições falham quase não custa «indisponibilidade» por uma definição ingênua, e pode esgotar um mês de budget de requisições.

O que os usuários sentem é o segundo caso. Se você mede disponibilidade só como tempo, vai subcontar sistematicamente as falhas que mais irritam as pessoas, porque falhas parciais simplesmente não se registram como indisponibilidade.

A saída usual é definir o SLI como uma razão entre eventos bons e eventos válidos — requisições bem-sucedidas sobre requisições totais, ou requisições rápidas sobre requisições totais — e derivar um número baseado em tempo apenas para comunicação.

O que de fato consome o budget

O erro é tratar o budget como folga para incidentes. Na prática, ele é compartilhado com tudo que faz requisições falharem:

• Deploys. Mesmo um rollout limpo derruba conexões, a não ser que cada camada faça o esvaziamento corretamente.
• Manutenção planejada. Se é visível para o usuário, conta, tenha você anunciado ou não.
• Falhas de dependências. O seu budget é gasto pelos incidentes do seu provedor, e você não teve direito a voto.
• A longa cauda. Timeouts isolados, retentativas que se esgotaram, um nó ruim. Isso raramente se torna incidente, e vai somando.

É por isso que times que orçam 100% de consumo do error budget passam do limite. Planeje gastar uma fração dele em incidentes e deixe o restante para o custo ordinário de operar.

Exemplos

• 99,9% em 30 dias — cerca de 43 minutos. Um deploy ruim com rollback lento pode gastar a maior parte de um mês.
• 99,95% em 30 dias — cerca de 22 minutos. É o ponto em que rollback manual deixa de ser rápido o suficiente e você precisa de automação.
• 99,99% em 30 dias — cerca de 4 minutos. Alcançável apenas com failover multirregião que entra em ação sem humano no circuito.
• 99,999% em 30 dias — cerca de 26 segundos. Só a detecção normalmente demora mais que isso, então a arquitetura precisa tolerar falhas em vez de reagir a elas.

Cada degrau é, grosso modo, uma redução de dez vezes na falha permitida e uma mudança de patamar no custo. Escolha o SLO a partir do que os usuários realmente precisam, e não de quantos noves soam impressionantes — um pipeline interno de processamento em lote a 99,99% é dinheiro gasto em benefício de ninguém.

Observações

A janela é tratada como exatamente o número de dias que você informar, então um mês de 30 dias são 2.592.000 segundos. Meses de calendário diferem em até três dias, o que importa se você estiver conciliando com um contrato; uma janela móvel de 30 dias é a escolha operacional mais comum e contorna o problema.

A contagem de requisições com falha é truncada, não arredondada, porque uma falha parcial não é algo que se possa gastar.

Para disponibilidade expressa como número contratual com faixas de penalidade, use a calculadora de SLA. Ela responde a pergunta vizinha — quanta indisponibilidade uma dada promessa de disponibilidade permite — sem o lado do volume de requisições.