Nos primeiros minutos de qualquer degradação, a pergunta que trava mais gente do que deveria não é como resolver o problema, é o quanto aquilo realmente importa. Rolando Bonaccorsi, diretor de operações da Vert Analytics, já viu equipes inteiras perderem tempo precioso discutindo se algo é grave o suficiente para acordar as pessoas certas, exatamente quando essa discussão deveria já ter sido resolvida antes de qualquer incidente acontecer.
Um roteiro simples e objetivo, elaborado com antecedência, não apenas elimina o debate no calor do momento, mas também transforma uma decisão emocional em um processo sistemático e repetível. Isso permite que qualquer pessoa de plantão, independentemente de sua experiência prévia com aquele sistema específico, possa aplicar a solução em questão de segundos. Ao ter um guia claro, as equipes podem agir com confiança e eficiência, evitando discussões improdutivas que consomem tempo valioso durante incidentes críticos. Essa abordagem estruturada garante que as decisões sejam tomadas de forma rápida e eficaz, minimizando o impacto de qualquer degradação no serviço.
Passo 1: pergunte se o serviço está completamente fora do ar
A primeira pergunta é a mais simples e a mais decisiva: o serviço está totalmente indisponível para todos os usuários, ou ainda funciona de alguma forma, mesmo que parcialmente degradado? Uma resposta afirmativa aqui já classifica automaticamente o incidente no nível mais alto de severidade, sem necessidade de qualquer análise adicional antes de mobilizar a resposta completa.
Se a resposta for não, o próximo filtro natural é verificar se existe perda de dados envolvida ou risco de segurança ativo, dois cenários que também justificam classificação máxima independentemente do número de usuários afetados. Esses dois critérios, indisponibilidade total e risco de dados, resolvem sozinhos boa parte das classificações mais urgentes.
Passo 2: meça quantos usuários realmente são afetados
Superado o primeiro filtro, a pergunta seguinte é quantitativa: qual fração da base de usuários sente o problema neste momento? Rolando Bonaccorsi recomenda estabelecer faixas percentuais claras com antecedência, por exemplo, acima de cinquenta por cento para o segundo nível de severidade, entre dez e cinquenta para o terceiro, e abaixo disso para o nível mais baixo da escala.
Esses números, definidos previamente e documentados em local acessível a toda a equipe de plantão, evitam debates subjetivos sobre o que conta como muitos usuários afetados, uma discussão que consome tempo justamente no momento em que menos tempo sobra disponível para qualquer discussão.
Passo 3: separe severidade de prioridade
Um erro recorrente é tratar severidade e prioridade como sinônimos, quando, na verdade, medem coisas diferentes. Severidade descreve o tamanho do dano agora; prioridade descreve a ordem em que o trabalho deveria ser feito, considerando também fatores de negócio que a severidade técnica sozinha não captura completamente.
Rolando Bonaccorsi cita um exemplo direto: um ambiente de testes completamente fora do ar tem severidade técnica alta, mas prioridade baixa, porque nenhum cliente real é afetado. Um bug cosmético que trava o botão de finalizar compra tem severidade técnica baixa, mas prioridade altíssima, porque impacta receita diretamente. Confundir os dois eixos gera decisões erradas de recurso.
Passo 4: escreva a régua antes da crise acontecer
Nenhum desses critérios funciona se existir apenas na cabeça de quem está de plantão naquele dia específico. A régua de classificação precisa estar documentada, acessível e conhecida por toda a equipe, revisada periodicamente para refletir mudanças reais na arquitetura e na criticidade de cada sistema ao longo do tempo.
Rolando Bonaccorsi considera esse documento tão importante quanto qualquer runbook técnico de resposta: equipes que decidem os critérios com calma, fora do calor de um incidente real, respondem mais rápido e com muito menos desgaste do que equipes que reinventam a régua de classificação a cada nova crise que aparece.
