Projetando uma Política de Escalonamento

Passo um: o principal é acionado por um canal que realmente vai acordá-lo, notificação push mais uma ligação telefônica escalonada, não só uma mensagem no Slack. A política inicia um temporizador de confirmação (ack), digamos, de 5 a 8 minutos. Passo dois: se o principal confirma, o escalonamento para e ele assume o caso. Se o temporizador expira sem confirmação, a política aciona automaticamente o secundário. Mesmo temporizador de confirmação. Passo três: se o secundário também não confirma, o escalonamento sobe para o gerente de plantão ou o gerente de engenharia. Para um incidente maior de verdade, é também nesse ponto que você criaria automaticamente um canal de incidente e traria um incident commander. Esse é o caminho feliz. Os modos de falha contra os quais eu realmente estou projetando são a parte interessante: - O primeiro respondente está dormindo ou sem sinal. É por isso que existe um secundário, e por isso a notificação escala de push para ligação telefônica em vez de depender de um único canal silencioso. - O alerta chega a um beco sem saída. Toda política precisa de um catch-all final, para que um alerta não confirmado eventualmente chegue a um gerente ou abra um incidente. Ele nunca deveria simplesmente parar. - O time errado é acionado. O roteamento deve enviar o alerta para o time dono do serviço com falha, com base em um label de serviço ou time, não para um único pager central. - Coisas não urgentes acionam humanos. O roteamento baseado em severidade importa muito aqui. Um SEV1 aciona imediatamente e notifica o gerente e o canal de incidente. Um SEV3 deveria virar um ticket ou uma mensagem no Slack, não uma ligação às 3h da manhã. Se não precisa de um humano agora, não é um acionamento. - Tempestades de alertas. Quando uma interrupção dispara cinquenta alertas, o agrupamento e a deduplicação reduzem isso a uma única notificação em vez de cinquenta ligações telefônicas. O caso extremo que eu destacaria: não deixe o escalonamento entrar em loop para sempre. Repita a cadeia uma vez, talvez duas, e depois passe para um catch-all garantido, como um processo de incidente maior. E todo acionamento deveria trazer um link para o runbook correspondente, para que a pessoa que você acordou às 3h da manhã tenha por onde começar em vez de uma tela em branco.