Gestão de incidentes de TI: como estruturar a prática na sua operação

Autor: Pedro Tebaldi PM do KeepGreen

Publicado dez/2025Atualizado ago/2026

Em ambiente corporativo digital, a pergunta não é se um sistema vai falhar, mas quando. A diferença entre uma operação que entra em colapso e outra que absorve a falha com impacto mínimo raramente está na tecnologia. Ela está na estrutura da prática.

Antes de tudo, equipes imaturas tratam cada falha como incêndio a apagar no grito. Organizações maduras, por outro lado, operam com papéis definidos, política de priorização escrita e ferramentas integradas. O resultado é um fluxo previsível e auditável, que não depende de quem está de plantão naquela noite.

Este artigo trata da prática: como você organiza pessoas, políticas e ferramentas para responder a incidentes de forma consistente. O passo a passo operacional de um incidente específico, fase por fase, fica na resolução de incidentes, que é o artigo companheiro deste.

O que é a gestão de incidentes de TI?

A gestão de incidentes de TI é a prática que restaura a operação normal de um serviço após uma interrupção não planejada. Ela abrange registro, classificação, priorização, escalonamento, comunicação e encerramento. Por fim, vale a regra de ouro: o objetivo é minimizar o impacto no negócio, não descobrir a causa da falha.

Essa fronteira é o que mais confunde operações imaturas. Por isso, vale entender antes o que caracteriza um incidente de TI. Ou seja, como ele difere de problema, evento e requisição de serviço.

No vocabulário do ITIL 4, gestão de incidentes é uma prática, não um processo. A distinção importa: prática inclui pessoas, ferramentas, cultura e fluxos, enquanto processo descreveria apenas a sequência de passos. É por isso que estruturar a prática exige mais do que desenhar um fluxograma.

Restaurar não é o mesmo que resolver

O princípio que organiza toda a prática cabe em uma frase. Durante um incidente, o objetivo é colocar o serviço no ar, ainda que por meio de contorno temporário.

Um banco de dados travou às duas da manhã? Ou seja, a ação correta é reiniciar o serviço ou virar para o nó de backup. Descobrir por que ele travou é trabalho da gestão de problemas de TI, que roda em outro prazo e com outro time.

Tentar encontrar causa raiz no meio de uma crise é o erro que mais infla o tempo de resolução. Além disso, a investigação exige calma, dados históricos e hipóteses testadas com método. Nada disso existe com o telefone tocando e a diretoria pedindo previsão.

Por isso, a prática madura separa formalmente os dois registros. O incidente fecha quando o serviço volta. O problema abre em seguida, com prazo próprio, para alimentar a correção definitiva.

Os papéis de uma operação de incidentes

Prática sem dono vira improviso. A tabela abaixo reúne os papéis que sustentam uma operação de incidentes, do primeiro atendimento à coordenação de crise.

Cabe ressaltar um ponto sobre o incident commander. Em operações pequenas, esse papel costuma cair sobre o especialista mais experiente, que acaba coordenando e executando ao mesmo tempo. Isso funciona até o primeiro incidente grande, quando as duas funções entram em conflito.

Quando o incidente ultrapassa esse limite e passa a ameaçar receita ou reputação, a resposta migra para a gestão de crises de TI, que mobiliza executivos, jurídico e comunicação além do time técnico.

A política de priorização: urgência e impacto

Nem tudo é urgente. Por exemplo, tratar uma falha de impressora com a mesma prioridade de uma queda do ERP é erro de gestão, não de técnico.

A priorização madura combina duas variáveis. A urgência mede o quão rápido a resolução é necessária para evitar degradação maior. Já o impacto mede quantos usuários, processos de negócio ou receita são afetados.

Do cruzamento das duas nasce a prioridade, que por sua vez define prazo de atendimento, canal de acionamento e quem precisa ser acordado. Uma matriz de severidade bem construída transforma essa decisão em consulta a uma tabela, em vez de julgamento pessoal sob pressão.

O ganho não é burocrático. Quando o critério está escrito, o plantonista para de hesitar e o gestor para de ser acionado para arbitrar cada caso.

Escalonamento: níveis tradicionais e swarming

O modelo clássico de níveis N1, N2 e N3 organiza bem o volume, porém cria filas. O ticket passa de mão em mão. Além disso, cada transferência custa contexto e não apenas tempo.

Já o swarming propõe o contrário para incidentes críticos: especialistas de domínios diferentes atacam o caso simultaneamente, na mesma sala ou no mesmo canal. Some-se a isso a presença de um coordenador. Dessa forma, o tempo de ping-pong entre equipes praticamente desaparece.

Na prática, as duas abordagens convivem. Incidentes de severidade baixa e média seguem o fluxo por níveis, que é mais barato. Os de severidade alta disparam swarming imediato. A regra de qual disparar o quê deve estar na política, não na intuição do plantão.

Cabe ressaltar um efeito colateral do swarming: ele é caro. Reunir quatro especialistas em um incidente consome quatro agendas ao mesmo tempo. Por isso, reserve o modelo para o que realmente derruba serviço crítico.

Vale notar que o swarming só funciona com um responsável pela coordenação. Sem isso, o resultado é um grupo de especialistas competentes falando ao mesmo tempo. É o que descreve o capítulo sobre condução de crises do livro de SRE do Google.

As ferramentas que sustentam a prática

Vale destacar que a gestão manual por e-mail e planilha é insustentável em qualquer escala moderna. Dessa forma, a eficiência vem da integração entre quatro camadas.

O monitoramento detecta e abre o registro automaticamente via API, já populando o ticket com métricas, logs e evidências. Como resultado, isso elimina a etapa de interrogatório do usuário e reduz o tempo até o primeiro diagnóstico.

A plataforma de ITSM centraliza o registro, o histórico e a rastreabilidade. Ademais, é onde vive a política de priorização, o SLA e a base de conhecimento que alimenta a resolução no primeiro contato.

A ferramenta de acionamento cuida do on-call: escala de plantão, roteamento por severidade, escalonamento automático quando ninguém responde e registro de quem foi acionado quando.

Por fim, a comunicação fecha o ciclo com o usuário. Nesse sentido, uma página de status pública informa o andamento em tempo real e derruba o volume de chamados duplicados durante a crise.

Acima de tudo, as quatro camadas precisam conversar por API. Quando o monitoramento detecta latência alta em um serviço, ele deve abrir o registro, classificar pela severidade configurada e acionar o plantonista correto. Nenhuma dessas etapas exige humano no meio.

Em operações mais maduras, entra ainda a auto-remediação. Um webhook dispara o script que reinicia o serviço, limpa a fila ou escala a instância. Se a ação resolve, o incidente fecha sozinho. Caso contrário, o acionamento humano segue normalmente.

Por fim, a integração com a gestão de mudanças fecha o desenho. Muitas correções exigem alterar a infraestrutura, portanto vale ter um fluxo de mudança emergencial já aprovado. Sem ele, o time escolhe entre violar a governança ou deixar o serviço fora do ar.

Como implantar a prática do zero

Implantação boa é incremental. Tentar subir a prática inteira de uma vez costuma terminar em documento que ninguém lê.

Passo 1: defina o que é incidente na sua operação

Escreva o critério que separa incidente de requisição de serviço. Sem isso, todo o resto sai medido errado, principalmente o indicador de disponibilidade.

Passo 2: escreva a matriz de priorização

Duas variáveis, quatro níveis, prazos explícitos por nível. Uma página basta. Ademais, uma página tem chance real de ser lida.

Passo 3: nomeie os papéis

Diga quem é o dono da prática e quem pode assumir a coordenação de uma crise. Vale insistir: nome de pessoa, não nome de área.

Passo 4: monte a escala de plantão

Defina cobertura, canal de acionamento e prazo de reconhecimento. Combine também o que acontece se o primeiro acionado não responder.

Passo 5: documente o roteiro da crise

Um plano de resposta a incidentes escrito antes vale mais do que qualquer improviso durante. Afinal, ninguém desenha fluxo de acionamento com o sistema fora do ar.

Passo 6: instrumente as métricas

Só depois que o fluxo roda é que os indicadores significam alguma coisa. Antes disso, você mede improviso.

Os níveis de maturidade da prática

Assim, saber em que estágio a operação está ajuda a escolher o próximo passo em vez de perseguir o ideal de uma vez.

A maioria das operações brasileiras de médio porte vive entre os níveis 2 e 3. Vale destacar o salto do terceiro para o quarto. É nele que a equipe deixa de descobrir a falha pelo usuário.

Outro ponto: a maturidade não sobe sozinha com a compra de ferramenta. Cada nível exige uma decisão de processo antes da decisão de tecnologia. Comprar plataforma de ITSM sem critério escrito de priorização apenas digitaliza a confusão que já existia.

Os KPIs que provam que a prática funciona

Você não gerencia o que não mede. Em resumo, quatro indicadores bastam para sustentar a conversa com a diretoria.

O MTTR mede o tempo médio da abertura ao fechamento e é o principal indicador de agilidade. Já o MTTA mede quanto a equipe demora para começar a trabalhar no chamado. MTTA alto aponta falta de gente ou falha no acionamento, não falta de competência técnica.

Do mesmo modo, a resolução no primeiro contato mostra a porcentagem de incidentes fechados ainda no N1. Quando ela sobe, o custo por chamado cai e a fila do especialista encurta.

Por fim, acompanhe os incidentes causados por mudanças. Esse número mede a qualidade do seu processo de deploy. Se ele for alto, a instabilidade vem de dentro, isto é, de fogo amigo.

Um alerta sobre o MTTR: ele mente com facilidade. Fechar incidentes com contorno e nunca abrir o problema correspondente mantém o indicador bonito enquanto a mesma falha volta todo mês.

Vale combinar também a cadência de revisão. Indicador que ninguém olha não muda comportamento. Uma revisão mensal com o dono da prática, somada a uma leitura trimestral com a diretoria, costuma bastar para operações de médio porte.

Nessa revisão, o que interessa é a tendência e não o número isolado do mês. Um MTTR que sobe três meses seguidos diz muito mais do que um pico pontual causado por um incidente atípico. Para situar seus números diante do mercado, consulte os benchmarks de MTTR e gestão de incidentes com publicador e ano de cada pesquisa.

Conclusão

A gestão de incidentes de TI é o sistema imunológico da operação. Quando bem estruturada, ela transforma crise em rotina e protege o valor entregue ao cliente. Quando ausente, transforma cada falha em improviso caro.

Três elementos sustentam a prática. O primeiro é gente: papéis nomeados, com um dono da prática fora da crise e alguém habilitado a coordenar dentro dela. O segundo é política: critério escrito do que é incidente e matriz de priorização que dispense julgamento pessoal. O terceiro é ferramenta: monitoramento, ITSM, acionamento e comunicação conversando entre si.

Nada disso é burocracia. Em síntese, é o que torna a resposta igual às três da manhã de domingo e às três da tarde de terça. O resultado independe de quem atendeu. Conforme a documentação oficial do framework, é justamente essa consistência que separa prática de esforço individual.

Quer estruturar essa prática na sua operação? Fale com um especialista da OpServices e avalie o estágio atual do seu processo.