Transição de SLOs teóricos para alertas práticos de burn rate que só acordam o engenheiro de plantão quando a experiência do usuário está se deteriorando ativamente.
Na busca por eliminar a fadiga de alertas, muitas equipes percebem que o monitoramento baseado em limites estáticos é fundamentalmente falho. Se você alerta quando as taxas de erro atingem 2%, mas o tráfego é tão baixo que 2% equivale a apenas uma única sonda sintética com falha, você acionou um engenheiro por uma anomalia estatística.
O substituto padrão da indústria para os limites legados é o alerta baseado em Objetivo de Nível de Serviço (SLO). Ao definir SLIs rigorosos, negociar Budgets de Erros e alertar exclusivamente sobre Burn Rates, os SREs garantem que só são acionados quando os usuários sofrem uma dor significativa e sustentada.
Uma das barreiras psicológicas mais difíceis de superar na engenharia é aceitar que uma aplicação não precisa de 100% de uptime. Buscar 100% de disponibilidade congela a velocidade de implantação de funcionalidades e dispara tempestades intermináveis de notificações por falhas microscópicas.
Normalmente, um alvo entre 99,9% (Três Noves, aproximadamente 43 minutos de inatividade por mês) e 99,99% é ideal. Os 0,1% restantes são o seu Budget de Erros. É uma tolerância de instabilidade aceitável. Se você está dentro do budget, os deploys continuam e o pager permanece silencioso. Se você esgotá-lo rápido demais, o pager toca para conter o sangramento.
Um Indicador de Nível de Serviço (SLI) é uma métrica estritamente definida e mensurável que representa a experiência do usuário. O livro do Google SRE define uma fórmula genérica que simplifica quase todos os cálculos de SLI:
Good Events / Total Events * 100
Vamos aplicar isso a uma API Web:
Se recebemos 10.000 requisições e 9.900 são rápidas e bem-sucedidas, nosso SLI é de 99%.
Imagine que você define um alerta de limite estático: Me acione se o SLI cair abaixo de 99% em uma janela de 5 minutos.
Você encontrará dois modos de falha:
Se o banco de dados travar completamente e seu SLI despencar para 0%, a janela de 5 minutos é muito lenta! Você precisava ser acionado 30 segundos após a falha, não 5 minutos depois.
Se um vazamento de memória lento faz consistentemente 1,5% das requisições falharem, seu SLI é de 98,5%. Como nunca cai drasticamente, o alerta nunca dispara. No entanto, ao longo de 30 dias, os usuários experimentam constantemente frustrações e você destrói silenciosamente seu budget de erros mensal.
A solução para esses modos de falha são os Alertas de Burn Rate. Em vez de verificar limites absolutos, você calcula a que velocidade seu Budget de Erros mensal está sendo consumido.
Um burn rate de 1 implica que o budget será exatamente esgotado em 30 dias.
Um burn rate de 14,4 implica que o budget será completamente esgotado em exatamente 2 dias.
Configuramos Alertas de Burn Rate de Múltiplas Janelas para capturar queimas rápidas e lentas:
Aqui está um exemplo de snippet PromQL para um alerta de queima rápida (taxa 14,4) em uma janela de 1 hora para um SLO de 99,9%. Gerar esses manualmente pode ser complexo, então ferramentas como Sloth ou Prometheus Operator são recomendadas.
sum(rate(http_requests_total{status=~"5.."}[1h]))
/
sum(rate(http_requests_total[1h]))
> (1 - 0.999) * 14.4Isso consulta exatamente o que importa: estamos consumindo nossa tolerância de falhas rápido demais para sobreviver ao mês?
Migrar de limites estáticos para alertas de burn rate de SLO exige um salto de maturidade na cultura de monitoramento. Ele abraça a realidade de que pequenas falhas são aceitáveis, enquanto garante resposta imediata diretamente proporcional à dor real do usuário.
Para construir SLIs com confiança, você precisa medir as verdadeiras bordas da sua infraestrutura. As verificações HTTP sintéticas globais e as sondas de anomalias DNS do Heimdall geram métricas SLI perfeitas, garantindo que quando o Heimdall reporta um objetivo com falha, você pode ter certeza absoluta de que o usuário está sendo impactado.
Junte-se a milhares de equipes que confiam no Heimdall para manter seus sites e APIs online 24/7. Comece com nosso plano gratuito hoje.
Comece a monitorar gratuitamente
Engenheiro de Confiabilidade de Sistemas (SRE) Sênior focado em disponibilidade, resposta a incidentes e construção de sistemas de monitoramento que antecipam problemas antes que os usuários percebam.
