Escalando um Programa de On-Call Entre Muitas Equipes

A mudança central é passar do on-call centralizado para a propriedade de serviço (service ownership). A equipe que constrói um serviço cuida do seu próprio on-call. You build it, you run it. Um único time central de operações não consegue ser dono dos serviços de quinze equipes, porque quem recebe o page não tem poder para corrigir a causa raiz, então o ruído nunca vai embora. Então eu rotearia os alertas para a equipe dona com base em um label de serviço ou equipe, e garantiria que todo serviço tenha um dono nomeado. Nenhum serviço órfão, nenhum pager central capturando tudo. Depois eu padronizaria o que deve ser consistente e deixaria as equipes donas do resto. Padronizar: definições de severidade, o processo de incidente (quem declara um incidente, o papel de incident commander, comunicação), a ferramenta de paging e uma configuração golden-path de alerting, expectativas de runbook e a política de compensação. Deixe cada equipe dona da própria escala e dos próprios alertas dentro desse escopo. Consistência onde importa, autonomia onde não importa. A parte que a maioria das pessoas pula é a governança por métricas em vez de intuição. Eu acompanharia a saúde do on-call entre as equipes: - Pages por turno, especificamente pages fora do horário comercial por turno. Esse é o sinal de esgotamento. - Porcentagem de pages que foram acionáveis versus auto-resolvidos. - Tempo até o reconhecimento, além de MTTA e MTTR. - Alertas sem runbook anexado. - Satisfação do on-call por meio de uma pesquisa curta recorrente. Depois eu definiria limites que disparam uma revisão. Por exemplo, qualquer equipe acima de um determinado número de pages fora do horário comercial por semana ganha uma sessão dedicada para corrigir seu alerting, tratada como trabalho real com tempo alocado, não como uma cobrança. A saúde do on-call se torna algo com dono e dashboard, como um produto. Os casos extremos nessa escala: - Equipes pequenas demais para cobrir 24/7 sozinhas. Agrupe algumas equipes relacionadas em um rodízio compartilhado, ou use follow-the-sun entre regiões. Não finja que uma equipe de quatro pessoas consegue cobrir noites de forma sustentável para sempre. - Infraestrutura compartilhada. O time de plataforma é dono da plataforma, mas você precisa de limites bem definidos para que eles não se tornem o depósito de todo alerta vagamente relacionado a infra. Alertas devem rotear para o dono do serviço primeiro. - Cultura. Nenhuma dessas métricas funciona sem postmortems sem culpa (blameless). Se reportar um alerta barulhento ou uma noite ruim gera culpa, as pessoas escondem isso e os dados somem. O modo de falha que eu observaria com mais atenção: um time central silenciosamente permanecendo responsável pela confiabilidade de todo mundo. Isso quebra o loop de feedback em que a equipe que consegue corrigir o ruído é a equipe que o sente.