Como você decide sobre o que alertar num serviço backend?

Alerte sobre sintomas que os usuários sentem, definidos como objetivos de nível de serviço: disponibilidade e latência medidas na borda, mais sinais de correção como pagamentos falhos ou uma fila que para de escoar. Acione plantão apenas quando um objetivo corre risco de não ser cumprido, usando a taxa de queima do orçamento de erro, para que um desvio lento vire um chamado e uma queima rápida acorde alguém. Mantenha alertas de causa como CPU alta em dashboards, não em plantão.

Eu parto do que um usuário notaria: requisições falhando, requisições lentas e as coisas específicas do domínio que são piores que ambas, como pedidos não confirmados ou um atraso de consumidor que só sobe. Isso vira objetivos com uma meta, digamos 99,9 por cento das requisições com sucesso e latência de percentil 95 abaixo de trezentos milissegundos, medidas no balanceador de carga e não dentro da aplicação, para eu contar as falhas que meu código nunca enxerga. Depois a severidade do alerta vem da taxa de queima: queimar o orçamento mensal de erro em uma hora aciona plantão imediatamente, enquanto uma queima lenta ao longo de dias vira um chamado. Métricas de causa como CPU, memória ou disco ficam em dashboards e em alertas de capacidade, porque uma CPU ocupada que ninguém sente não é um incidente. Todo acionamento precisa ser acionável, então ele aponta para um runbook, e qualquer alerta que disparou sem ação é revisado. Num time nós cortamos o volume de plantão em cerca de dois terços assim, e o ganho real foi que os alertas restantes passaram a ser levados a sério.