Alarmes bem projetados: poucas notificações, cada uma com um próximo passo

Objetivo

Um conjunto de alarmes em que cada notificação desencadeia uma ação e ninguém aprende a ignorar o pager.

Pré-requisitos

O capítulo «Monitoring Distributed Systems» do livro Google SRE apresenta os quatro sinais dourados (latência, tráfego, erros e saturação), distingue sintomas («o que está quebrado») de causas («por quê») e exige que toda chamada seja acionável («Every page should be actionable»). O SRE Workbook descreve alarmes baseados na taxa de consumo do error budget («burn rate»). Na prática, são necessários indicadores de nível de serviço medidos na borda do usuário, um sistema de alarmes com tempo de espera antes de disparar (no Prometheus, a cláusula for, complementada por keep_firing_for contra a oscilação durante a recuperação) e um caminho de escalonamento documentado.

Passos

1. Para cada serviço, defina os sintomas que os usuários percebem: taxa de erros, percentis de latência, disponibilidade, atualidade dos dados. Somente eles podem acordar alguém. Causas como CPU alta ou disco 80 por cento cheio viram tickets ou painéis em dashboards.
2. Derive os limiares das metas: o Workbook indica, como ponto de partida para acordar alguém, o consumo de 2 por cento do error budget em uma hora ou de 5 por cento em seis horas; uma taxa mais lenta (10 por cento em três dias) gera um ticket em vez de uma chamada.
3. Dê a cada regra um tempo de espera (for: 10m), para que um único valor atípico não dispare o alarme, e acrescente uma regra que dispare quando o próprio sistema de medição deixar de fornecer dados.
4. Inclua em cada alarme, nas anotações, um link para o runbook, os dashboards afetados e o primeiro passo de verificação.
5. Mantenha a urgência como label (severity: page versus ticket) e direcione o roteamento de acordo com ela; à noite, só o primeiro nível alcança uma pessoa.
6. Toda semana, revise todos os alarmes disparados: cada alarme que não levou a nenhuma ação é ajustado ou apagado; cada incidente que não foi precedido por um alarme ganha um.

Resultado esperado

Poucas chamadas, cada uma com um próximo passo claro; os incidentes são percebidos pelo monitoramento antes dos usuários; a equipe de plantão confia no pager.

Limites e base de verificação

Alarmes de sintomas detectam tarde as degradações graduais; alguns indicadores antecipados de baixa urgência (tamanho da fila, previsão de «disco cheio em dois dias») os complementam. Os princípios seguem os capítulos citados do SRE, e a mecânica segue a documentação citada do Prometheus; não está comprovado aqui se uma equipe se dessensibiliza, nem a partir de qual taxa de alarmes isso ocorre.