Severidade de incidentes: como definir níveis, matriz e resposta

São três horas da manhã e dois alertas chegam ao mesmo tempo: o site de vendas caiu e um relatório interno travou. Qual deles acorda o engenheiro de plantão? Sem uma escala clara de severidade, essa decisão vira opinião. Na prática, cada analista responde de um jeito e o incidente crítico espera na fila junto com o trivial.

A severidade de incidentes existe para eliminar esse improviso. Com níveis bem definidos, a operação sabe em segundos o que exige resposta imediata. Da mesma forma, sabe o que espera o expediente e o que vai para o backlog.

Neste guia, você vai entender o que é severidade e como ela se diferencia de prioridade. Além disso, vai ver o que significa cada nível de SEV1 a SEV4 e como transformar a classificação no gatilho central da resposta.

O que é severidade de incidentes?

A severidade de incidentes é a escala que mede a gravidade do impacto de uma falha sobre serviços, usuários e negócio. Ou seja, ela define o nível de resposta que a operação aciona. Cada nível (SEV1, SEV2, SEV3, SEV4) carrega tempos de reação, responsáveis e rituais de comunicação pré-combinados.

Na prática, a severidade funciona como um contrato operacional. Antes do incidente acontecer, a equipe já decidiu o que é crítico, o que é degradação tolerável e o que pode esperar. Por isso, a classificação retira a decisão mais difícil do momento de maior estresse.

Essa padronização sustenta toda a gestão de incidentes de TI: sem níveis claros, escalação, SLAs e comunicação viram negociações caso a caso.

Severidade, prioridade, impacto e urgência: qual a diferença?

Severidade mede a gravidade técnica do incidente; prioridade define a ordem de atendimento na fila. Impacto indica a amplitude da falha (quantos usuários, serviços ou áreas) enquanto urgência indica a velocidade exigida. Na matriz clássica do ITIL, impacto e urgência se combinam para produzir a prioridade.

Os conceitos se cruzam, mas não são sinônimos. Um erro de formatação na home tem severidade baixa (nada quebrou de fato), porém prioridade alta: a marca está exposta a todos os visitantes.

Em contrapartida, uma falha que corrompe dados de um único cliente tem severidade alta e prioridade que depende do contexto do negócio. Vale destacar: severidade descreve o dano; prioridade decide quem é atendido primeiro.

Os níveis de severidade na prática (SEV1 a SEV4)

Quatro níveis cobrem a operação da maioria das empresas. Menos que isso mistura crise com rotina; mais que isso gera debate na triagem. A tabela abaixo traz a referência de cada nível com resposta típica e exemplos reais.

Os tempos exatos variam por negócio, mas a lógica é universal: quanto maior a severidade, menor o tempo até a primeira resposta humana. Esse tempo é medido pelo MTTA, a métrica que denuncia quando a escala existe no papel mas não na prática.

Como classificar um incidente na triagem

A classificação acontece na triagem, nos primeiros minutos após o alerta. A regra de ouro das operações maduras é simples: classifique rápido, sem debate. Uma decisão de severidade boa em 2 minutos vale mais que uma decisão perfeita em 20.

Duas perguntas resolvem a maioria dos casos. Primeiro: existe solução de contorno para o usuário? Se não existe e o serviço é essencial, o incidente tende a SEV1. Segundo: quantos usuários ou serviços estão afetados agora? Impacto amplo sem contorno é crise; impacto restrito com contorno é rotina.

Além disso, severidade não é tatuagem: reclassifique conforme a investigação avança. Um SEV2 que se revela perda de dados sobe para SEV1; um SEV1 com contorno aplicado pode descer. Nesse sentido, o responsável pela triagem (analista de plantão ou coordenador do NOC) tem autoridade para decidir sem pedir permissão.

Um cuidado importante: a qualidade da triagem depende da qualidade dos alertas. Operações afogadas em ruído classificam mal, como mostra o guia sobre fadiga de alertas.

Severidade como gatilho da operação

O valor da severidade de incidentes aparece no que ela dispara automaticamente. Cada nível deve estar amarrado a três engrenagens da operação.

Escalação e plantão: SEV1 aciona a escalação de alertas completa e acorda o time de on-call; SEV3 espera o expediente. Sem esse vínculo, ou tudo acorda todo mundo, ou nada acorda ninguém.

Comunicação: a severidade define quem é informado e com qual frequência. Um SEV1 exige atualizações regulares para a liderança e comunicação ao cliente; um SEV4 vive apenas no backlog do time.

A propósito, o capítulo de resposta a emergências do Google SRE reforça que papéis e comunicação pré-definidos valem mais que heroísmo individual.

SLA e pós-incidente: cada nível carrega seu prazo de resolução do incidente. Nos níveis altos, o encerramento alimenta a gestão de problemas de TI, que investiga a causa raiz para o incidente não voltar.

Erros comuns ao definir níveis de severidade

O primeiro erro é a inflação de severidade: na dúvida, tudo vira SEV1. O efeito é o mesmo do alarme que dispara à toa, pois o time para de correr. Se um em cada vinte incidentes do trimestre vira SEV1, a régua está frouxa.

O segundo é o excesso de níveis. Escalas com seis ou sete degraus geram discussões intermináveis na triagem sobre diferenças que não mudam a resposta. Se dois níveis disparam as mesmas ações, eles são um nível só.

O terceiro erro é definir severidade sem amarrar gatilhos. Ou seja, nível que não muda quem é acionado, em quanto tempo e quem é comunicado é apenas etiqueta decorativa no chamado.

Por fim, ignorar o monitoramento: a severidade nasce no alerta. Ferramentas que já entregam o evento classificado, correlacionado e com contexto encurtam a triagem drasticamente.

Não por acaso, dados do levantamento anual do Uptime Institute mostram que falhas de TI e rede responderam por 23% dos outages impactantes em 2024: volume que exige classificação disciplinada.

Como implantar a matriz de severidade na sua operação

Antes de tudo, defina os quatro níveis com exemplos reais da SUA operação: pegue os últimos 20 incidentes e classifique-os em retrospecto. Esse exercício revela as ambiguidades antes que elas apareçam às três da manhã.

Em seguida, amarre os gatilhos: para cada nível, documente tempo de primeira resposta, cadeia de escalação, canal e frequência de comunicação. Publique a matriz onde a triagem trabalha, não num documento perdido na intranet.

Depois disso, revise trimestralmente. Compare a severidade atribuída na abertura com a real apurada no encerramento: divergências recorrentes indicam critérios mal calibrados ou treinamento pendente.

Conclusão

A severidade de incidentes é a régua que transforma o caos das três da manhã em procedimento. Quando cada nível carrega tempos, responsáveis e comunicação pré-definidos, a operação responde no reflexo. Assim, ninguém gasta os primeiros minutos da crise decidindo se aquilo é crise.

O caminho de implantação é curto: quatro níveis com exemplos do seu ambiente, gatilhos amarrados a escalação e comunicação, revisão trimestral da régua. O resultado aparece no MTTA dos incidentes críticos e na tranquilidade dos que não são.

Se você quer estruturar a classificação de severidade com monitoramento que já entrega o evento triado e explicado, fale com nossos especialistas.