Resolução de incidentes: as 6 fases do ciclo de resposta em TI

Autor: Pedro Tebaldi PM do KeepGreen| Revisão técnica: Ednilson Correa SRE

Publicado mar/2026Atualizado ago/2026

Incidentes em produção são inevitáveis. A diferença entre organizações de alta performance e as demais não está na ausência de falhas. Está na capacidade de conter o impacto e restaurar o serviço antes que a degradação vire crise para o usuário.

Resolução de incidentes é o conjunto de processos, ferramentas e práticas que determinam como o time responde quando algo quebra em produção. Em times maduros, isso não é improviso: é um roteiro com papéis definidos, runbooks documentados e métricas que sustentam a melhoria contínua.

Este guia cobre o ciclo completo, da detecção ao postmortem. Ele trata da execução caso a caso. A estrutura permanente que organiza papéis, políticas e ferramentas fica na gestão de incidentes de TI, que é o artigo companheiro deste.

O que é resolução de incidentes?

Resolução de incidentes é o processo de identificar, diagnosticar, conter e restaurar um serviço em degradação ou indisponibilidade. Ele engloba todas as atividades desde a detecção até a confirmação de que o serviço voltou ao normal. Em resumo, é tudo o que acontece entre o alerta e o encerramento do registro.

Vale separar dois verbos que costumam ser tratados como sinônimos. Restaurar é devolver o serviço ao usuário. Corrigir é eliminar a causa. O ciclo de resolução persegue o primeiro, sob pressão de tempo. O segundo vem depois, com calma.

Antes de tudo, convém ter clareza sobre o objeto. Se você quer entender o que caracteriza um incidente de TI, vale começar por ali. Ou seja, o que o distingue de evento, problema e requisição.

O ciclo completo de resolução de incidentes

As seis fases abaixo descrevem o caminho padrão de um incidente. Nem todo caso percorre as seis com o mesmo peso. Ainda assim, pular etapas costuma cobrar caro adiante.

Fase 1: detecção e alerta

A resolução começa antes de qualquer ação humana, na qualidade da instrumentação. Plataformas com detecção de anomalias e correlação de eventos identificam degradações antes que virem falha completa.

O indicador dessa fase é o tempo até detectar. Quando ele é alto, o sistema ficou degradado por minutos ou horas antes de qualquer alerta. Como resultado, todo o resto do ciclo já começa atrasado.

Fase 2: reconhecimento e triagem

Disparado o alerta, o plantonista faz o reconhecimento e sinaliza que está investigando. Em seguida vem a triagem, que responde três perguntas: qual o impacto no usuário, quais serviços estão afetados e se é preciso escalar agora.

A resposta a essas perguntas define a severidade. Uma matriz de severidade bem construída direciona o nível de resposta esperado. Dessa forma, a decisão não depende do julgamento de quem atendeu.

Na dúvida entre dois níveis, a regra prática é classificar para cima. Reclassificar para baixo depois custa pouco. Já descobrir tarde que o caso era mais grave custa reputação e SLA.

Fase 3: diagnóstico

Com o incidente reconhecido e classificado, o foco passa a ser identificar o que está causando a degradação. Aqui a instrumentação cobra a fatura: traces, logs correlacionados e métricas de latência, tráfego, erros e saturação são as fontes primárias.

Cabe ressaltar uma armadilha comum: diagnóstico não é análise de causa raiz. Nesta fase, você busca o suficiente para agir, não a explicação completa do fenômeno. Por isso, a investigação profunda fica para depois.

Fase 4: mitigação e remediação

A mitigação restaura o serviço o mais rápido possível, ainda que a causa continue viva. Rollback do último deploy, desativação de uma feature flag, redirecionamento de tráfego ou aumento temporário de capacidade são mitigações típicas.

Já a remediação elimina a causa em definitivo. Ela pode acontecer depois, sem a pressão do relógio. Portanto, separar as duas impede o time de perseguir a correção perfeita com o serviço fora do ar.

Vale destacar uma exceção: nem sempre o rollback é a mitigação correta. Quando o deploy alterou o esquema do banco, voltar à versão anterior pode corromper dados. Nesses casos, avançar com correção pontual costuma ser mais seguro.

Fase 5: comunicação durante o incidente

Em severidades altas, comunicar é responsabilidade separada de resolver. Quem está diagnosticando não deve ser interrompido a cada cinco minutos para dar previsão. Por isso times maduros designam alguém para coordenar e outra pessoa para falar com as partes interessadas.

Atualizações em cadência fixa reduzem a pressão sobre o time técnico. Além disso, elas preservam a confiança de quem está esperando. Vale notar que isso continua valendo quando a notícia é que ainda não há previsão.

Fase 6: fechamento e postmortem

Restaurado o serviço, o incidente fecha em seguida com o registro do que aconteceu, do que foi feito e do que ficou pendente. Para casos relevantes, entra o postmortem estruturado, que transforma o episódio em aprendizado do sistema.

O postmortem só funciona sem caça às bruxas. Quando o time teme punição, o relato empobrece. Como resultado, a organização perde exatamente o dado que precisava. É o que argumenta o capítulo sobre cultura de aprendizado do livro de SRE do Google.

Runbooks: o que transforma diagnóstico em checklist

Runbook é o roteiro escrito para um padrão de falha conhecido. Ele responde o que verificar, em que ordem e o que fazer em cada desfecho possível.

Vale distinguir runbook de documentação de arquitetura. O segundo explica como o sistema funciona. Já o primeiro diz o que fazer agora, em passos executáveis, sem exigir que o leitor entenda o desenho inteiro antes de agir.

O ganho aparece na terceira fase. Um diagnóstico que levaria trinta minutos de investigação exploratória vira uma sequência de verificações objetivas. Do mesmo modo, o plantonista de sobreaviso consegue agir sem depender do especialista que conhece aquele serviço.

Runbook bom nasce do postmortem. Cada incidente relevante deveria terminar com a pergunta: se isso acontecer de novo às três da manhã, o que a pessoa de plantão precisa saber? A resposta vira documento.

Outro ponto é onde guardar. Runbook que vive no computador de alguém não existe às duas da manhã. Portanto, deixe o roteiro no mesmo lugar em que o alerta chega, de preferência no corpo do próprio alerta.

Vale notar o que estraga um runbook: envelhecimento silencioso. Roteiro que aponta para painel desativado é pior do que a ausência de roteiro. Afinal, ele consome tempo antes de falhar.

Os erros que mais inflam o tempo de resposta

Boa parte do tempo perdido em incidentes não está no diagnóstico técnico. Na verdade, está em decisões de processo tomadas antes da crise. Ou seja, o relógio começa a correr contra você bem antes do alerta.

Caçar causa raiz durante a crise. É o erro mais caro de todos. A investigação exige calma e dados históricos, portanto ela pertence à etapa seguinte. Durante o incidente, a pergunta é como restaurar, não por quê.

Alerta sem contexto. Um alerta que diz apenas que algo caiu obriga o plantonista a reconstruir o cenário do zero. Isso custa minutos preciosos logo no início do ciclo.

Ruído no acionamento. Quando o plantão recebe dezenas de alertas irrelevantes por noite, o alerta que importa perde urgência. A fadiga de alertas atrasa o reconhecimento mesmo quando o time é competente.

Ninguém coordenando. Em incidentes grandes sem coordenação, especialistas competentes trabalham em paralelo na mesma hipótese. O manual de resposta a emergências do time de SRE do Google trata esse ponto como estrutural, não como detalhe.

Fechar sem registrar. Incidente resolvido e não documentado é aprendizado descartado. O próximo plantonista vai investigar tudo de novo.

Por fim, vale citar um erro de calendário: postergar o postmortem. Passada uma semana, os detalhes já sumiram da memória de quem atuou. Portanto, marque a sessão ainda durante a semana do incidente, mesmo que curta.

As métricas do ciclo de resposta

Três indicadores cobrem o ciclo inteiro. Medir os três em conjunto revela onde o tempo está sendo perdido, o que uma métrica isolada nunca mostra.

Repare que cada um deles delimita um trecho diferente da linha do tempo. Somados, eles descrevem o intervalo inteiro entre a falha começar e o serviço voltar. Por isso a leitura conjunta aponta o gargalo real.

O cuidado com o tempo médio de resolução merece destaque. Ele mente com facilidade: fechar tudo com contorno e nunca tratar a causa mantém o número bonito enquanto a falha volta todo mês. Por isso a linha de recorrência existe na tabela.

Outro cuidado é a média sem mediana. Um único incidente de doze horas distorce o mês inteiro e esconde o comportamento típico. Dessa forma, acompanhe também a mediana e o percentil 90, que descrevem melhor a rotina do plantão. As réguas públicas de comparação estão reunidas nos benchmarks de MTTR de 2026.

Como reduzir o MTTR de forma sistemática

Reduzir o tempo de resposta não é um projeto único. É a soma de ganhos pequenos em cada fase do ciclo.

Comece pelo começo. Ganho em detecção se propaga por todo o resto, isto é, cada minuto economizado ali entra inteiro no resultado final. Assim, melhorar a cobertura de monitoramento costuma render mais do que otimizar o diagnóstico.

Em seguida, ataque o ruído. Filtrar, deduplicar e correlacionar antes de acionar reduz o volume que chega ao humano. Como resultado, o alerta que importa recupera a urgência que tinha perdido.

Depois disso, invista em runbook. É o item de melhor retorno por hora investida, sobretudo para os padrões de falha que já se repetiram duas vezes.

Por fim, garanta opções de mitigação rápida. Rollback automatizado, feature flag e capacidade elástica encurtam a distância entre saber o que fazer e ter feito.

Acima de tudo, meça antes e depois de cada mudança. Sem a linha de base, você não sabe se o ganho veio da iniciativa ou de um mês com menos incidentes. Em síntese, trate a redução do tempo de resposta como experimento.

Conclusão

Resolução de incidentes eficaz não depende de engenheiros excepcionais. Ela depende de processo estruturado, instrumentação de qualidade e documentação que funcione sob pressão. Isto é, às três da manhã, com a pessoa menos experiente de plantão.

O ciclo tem seis fases, porém a lógica cabe em uma frase. Detectar cedo, reconhecer rápido, diagnosticar com roteiro, mitigar antes de corrigir, comunicar em cadência e registrar o aprendizado. Além disso, cada etapa tem uma alavanca própria, com custo e retorno diferentes.

Times que tratam incidente como oportunidade de melhoria, em vez de falha a esquecer, constroem sistemas progressivamente mais resilientes. Em síntese, o retorno aparece em tempo de resposta menor, impacto menor no usuário e menos horas de engenharia consumidas em trabalho reativo.

Quer estruturar o ciclo de resposta da sua operação? Fale com um especialista da OpServices e avalie onde o seu tempo está sendo perdido hoje.