Ciclo de vida do incidente de TI: as 5 etapas, da detecção ao aprendizado
Autor: Pedro Tebaldi PM do KeepGreen
Revisão técnica: Ednilson Correa SREPense no último incidente do seu ambiente e responda quem descobriu primeiro. O monitoramento, o time de plantão, um usuário que ligou para o service desk ou o diretor que abriu o painel de vendas?
A resposta diz mais sobre a maturidade da operação do que qualquer fluxograma, porque expõe qual etapa do ciclo está falhando. Incidente não é evento isolado: ele é um processo com começo, meio e fim.
Cada etapa desse processo responde a uma pergunta diferente, tem uma métrica própria e falha de um jeito característico. Quando a operação enxerga essas partes separadas, ela ataca o tempo de resposta onde ele realmente se perde.
Este guia percorre as cinco etapas do ciclo, da detecção ao aprendizado. A estrutura permanente que organiza papéis, políticas e ferramentas fica na gestão de incidentes de TI, o artigo companheiro deste.
O que é o ciclo de vida de um incidente de TI
O ciclo de vida de um incidente de TI é a sequência que vai do primeiro sinal de degradação até a lição documentada. São cinco etapas: detecção, triagem, diagnóstico, resolução e aprendizado. A operação atravessa todas elas em cada ocorrência, mesmo quando não as nomeia, porque o alerta precisa virar decisão antes de virar correção.
Duas palavras costumam ser tratadas como sinônimo dentro desse percurso. Restaurar é devolver o serviço ao usuário enquanto o relógio corre. Corrigir é eliminar a causa, o que acontece depois e com calma.
O que separa uma equipe madura de uma equipe em pânico não é a quantidade de incidentes, já que sistemas distribuídos falham de qualquer forma. É o tempo que a operação leva para perceber, entender, resolver e aprender com cada um.
Antes de medir o ciclo, vale ter clareza sobre o objeto. Incidente se distingue de evento, de problema e de requisição porque degrada o serviço entregue ao usuário.
| Etapa | Pergunta que ela responde | Métrica | Erro que mais custa tempo |
|---|---|---|---|
| 1. Detecção | O sinal chegou por qual caminho? | MTTD |
Monitorar recurso solto em vez do serviço |
| 2. Triagem | Qual o impacto e quem assume? | MTTA |
Classificar tudo como P1 |
| 3. Diagnóstico | O que mudou no ambiente? | Tempo até a mitigação | Perseguir a explicação completa com o serviço fora |
| 4. Resolução | O serviço voltou a operar de forma estável? | MTTR |
Fechar o chamado porque o painel ficou verde |
| 5. Aprendizado | Isso volta a acontecer na semana que vem? | Taxa de reincidência | Pular o post-mortem por falta de tempo |
Na transmissão de 2 de setembro de 2026, Ednilson Corrêa percorre as cinco etapas com exemplos de ambientes que a equipe acompanha. Ele é coordenador de tecnologia da OpServices e atua como SRE das plataformas da empresa.
Etapa 1: detecção nas três camadas do ambiente
Detecção é o sinal que abre o ciclo. O mesmo problema aparece em três camadas, cada uma com profundidade diferente. É o que explica um painel inteiro verde enquanto o negócio está parado.
Enquanto a camada de infraestrutura mostra CPU, memória, disco e rede, a aplicação mostra erro 500, fila travada ou rotina que não executou. Por último, a experiência mostra o que o usuário vive: o checkout que não responde ou o login que não autentica.
O erro clássico da etapa é monitorar recurso solto em vez de serviço. Quando ninguém amarra os itens monitorados ao processo de negócio que eles sustentam, o gráfico continua verde enquanto o cliente desiste da compra.
A métrica da detecção é o tempo médio para detectar, que responde à pergunta da abertura. MTTD baixo significa incidente descoberto pelo monitoramento; MTTD alto significa incidente descoberto por reclamação.
Etapa 2: triagem, classificação e abertura formal do incidente
Triagem é a avaliação de gravidade que define a ordem de atendimento quando mais de um incidente chega junto. A analogia usada na transmissão é o pronto-socorro. Ele não atende quem chegou primeiro nem quem grita mais alto: atende quem corre mais risco.
Classificar por impacto e abrangência evita o sintoma mais comum dessa etapa. Quando tudo é P1, nada é P1. O ERP parado, a loja online fora do ar e um banco de dados lento disputam a mesma posição na fila.
Aqui também entram a deduplicação e a correlação de eventos. Quatrocentos alertas de um switch de borda são um incidente só. Já um único alerta do gateway de pagamento pode ser o incidente mais caro do dia.
A triagem declara o incidente formalmente para que impacto, severidade e responsável fiquem registrados desde o início. Uma matriz de severidade escrita tira essa decisão do julgamento de quem atendeu o chamado.
Fecha a etapa o escalonamento com prazo: se ninguém assumir em quinze minutos, o caso sobe de nível sozinho. A métrica é o MTTA, o tempo até alguém assumir o incidente de fato.
Etapa 3: diagnóstico e a mitigação que acontece no meio dele
Diagnóstico é a busca do que está causando a degradação. A primeira pergunta é sempre a mesma: o que mudou no ambiente nos últimos trinta minutos?
Alguém subiu um deploy? Um parceiro alterou uma integração? Houve pico de carga? Quando a resposta aponta uma mudança recente, o rollback vem antes da explicação completa, já que a versão anterior estava funcionando.
Há uma exceção conhecida. Quando o deploy alterou o esquema do banco, voltar à versão anterior pode corromper dados. Nesses casos, a correção pontual costuma ser mais segura.
Entre o diagnóstico e a resolução existe uma etapa que quase nunca aparece no fluxograma: a mitigação. Estancar o impacto vale mais do que um diagnóstico perfeito, porque o cliente comprando de novo é o objetivo daquele momento.
Monte a linha do tempo durante o incidente, porque quem deixa para reconstruir os fatos no post-mortem descobre que ninguém lembra a ordem. A análise de causa raiz completa fica para a etapa seguinte, com o serviço já no ar.
Etapa 4: resolução, do contorno ao serviço estável
Resolução é o retorno ao estado estável e validado, mesmo que o caminho tenha sido um rollback. Voltar atrás não é derrota, já que a versão anterior funcionava. O estudo do que quebrou acontece depois, com calma e em ambiente de teste.
O que sustenta a etapa é o runbook, já que sem roteiro escrito apenas uma pessoa resolve aquele problema. Como as falhas não esperam o horário comercial, o plantonista da madrugada precisa conseguir executar sozinho.
Comunicar o restabelecimento fecha o ciclo com quem foi afetado: quem avisou da queda avisa também da volta, pelo mesmo canal. Silêncio depois da normalização gera chamado duplicado e desconfiança na próxima ocorrência.
O erro que mais se repete aqui é achar que resolveu. O painel volta ao verde, o chamado fecha e o problema retorna cinco minutos depois. A equipe mitigou sem tratar a causa nem validar o resultado.
Etapa 5: aprendizado, post-mortem e taxa de reincidência
Aprendizado é a etapa que a TI mais pula, porque documentar é chato e o incidente já passou. É também a única que reduz o volume dos próximos, por isso tem o melhor retorno do ciclo inteiro.
O post-mortem precisa de linha do tempo, impacto quantificado, causa raiz e ações com dono e prazo. Sem dono e sem prazo, o documento vira arquivo morto que ninguém abre quando a falha se repete.
Quantificar o impacto inclui o custo que ninguém lança na planilha, porque a conta não para no tempo de indisponibilidade. Uma war room com dez pessoas por meia hora consome cinco horas de especialista. Quando dez pessoas são convocadas, é porque ninguém sozinho tinha a resposta.
Cultura sem culpado é requisito técnico, não gentileza. Quem teme punição esconde o que fez. O relato empobrece justamente onde estava a informação útil, como argumenta o capítulo sobre cultura de aprendizado do time de SRE do Google.
Quando estruturamos o Service Desk da Minasligas, a base de conhecimento conectada ao fluxo de chamados foi o que encurtou o atendimento seguinte. A solução registrada em um chamado passou a servir o próximo, junto com os painéis que expõem retrabalho e backlog por analista.
A métrica da etapa é a taxa de reincidência, que mostra se o aprendizado virou mudança no ambiente ou parou no documento. O post-mortem estruturado tem template, cadência e campos obrigatórios, o que evita cada analista inventar o próprio formato.
O guia completo de SRE, em 35 páginas.
Escrito pelo time da OpServices: fundamentos da engenharia de confiabilidade, o que faz um SRE, as métricas que medem confiabilidade de verdade e a rotina de um time — do primeiro conceito ao plantão.
Só o e-mail. Sem spam, e seus dados protegidos pela LGPD.
Runbook: o que escrever e onde guardar
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, porque a documentação explica como o sistema funciona. O runbook 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 etapa. Um diagnóstico que levaria trinta minutos de investigação exploratória vira uma sequência objetiva de verificações. Com ela, o plantonista de sobreaviso age sem depender do especialista daquele serviço.
Runbook bom nasce do post-mortem. Cada incidente relevante deveria terminar com uma pergunta: se isso acontecer de novo às três da manhã, o que a pessoa de plantão precisa saber?
Outro ponto é onde guardar. Roteiro que vive no computador de alguém não existe às duas da manhã. Deixe o documento no mesmo lugar em que o alerta chega, de preferência no corpo do próprio alerta.
O que estraga um runbook é o envelhecimento silencioso. Roteiro que aponta para painel desativado é pior do que a ausência de roteiro, porque consome tempo antes de falhar.
Preparação e remediação: as duas pontas do modelo do Google
O time de SRE do Google organiza o assunto em três blocos: preparar, responder, remediar com aprendizado.
As cinco etapas descritas aqui vivem dentro do bloco de resposta, entre as duas pontas que o material público da equipe descreve.
Preparação é o trabalho de todo dia: monitoramento alinhado ao ambiente, limiares calibrados, escala de plantão definida e runbooks vivos. Serviço crítico que ninguém monitora como serviço nunca gera detecção, portanto o ciclo começa quebrado na primeira etapa.
A gestão de mudanças entra aqui. Quando o ambiente ganha uma API nova, ela precisa entrar no monitoramento junto; quando um servidor é descomissionado, ele sai. Plataforma desatualizada em relação ao ambiente produz ruído e detecção tardia ao mesmo tempo.
Remediação é o que sai do post-mortem e volta para a preparação assim que o incidente fecha. Entram aí o limiar ajustado, o item que passou a ser monitorado, o teste que roda antes do deploy. É o que fecha o PDCA do ciclo e impede que ele seja apenas um registro de ocorrências.
Como descobrir em qual etapa está o seu gargalo
Raramente o ciclo inteiro está lento. O tempo costuma morrer em uma etapa só, enquanto o número agregado esconde qual delas, o que leva times a investir esforço na fase errada.
Duas perguntas resolvem a maior parte do diagnóstico. Quem detectou o último incidente? E em qual etapa o relógio ficou parado mais tempo antes de alguém agir?
O tempo médio de resolução engloba três ou quatro etapas de uma vez, por isso ele aponta sintoma, não causa. Medir cada etapa transforma um número agregado em quatro alavancas distintas, cada uma com custo próprio.
| Métrica | O que mede | Quando está alto, ataque |
|---|---|---|
| MTTD | Da falha começar até o alerta disparar | Cobertura de monitoramento, limiares e detecção de anomalias |
| MTTA | Do alerta disparar até alguém reconhecer | Escala de plantão, canal de acionamento e ruído de alertas |
| MTTR | Do reconhecimento até o serviço restaurado | Runbooks, opções de mitigação rápida e coordenação |
| Reincidência | Quantas vezes o mesmo padrão de falha retorna | Gestão de problemas e qualidade dos post-mortems |
O contexto muda a leitura do mesmo número, sobretudo quando o volume de incidentes se move. MTTR estável com volume de incidentes crescendo significa que a mesma equipe absorve mais trabalho no mesmo tempo, o que é melhora disfarçada de estabilidade.
Na direção contrária, volume caindo com MTTR parado é piora. Com menos ocorrências para tratar, a equipe deveria estar resolvendo cada uma mais rápido, de modo que o número parado denuncia gargalo em alguma etapa.
Um cuidado final vale para qualquer média. Um único incidente de doze horas distorce o mês inteiro, portanto acompanhe também a mediana e o percentil 90. As duas medidas descrevem melhor a rotina do plantão. As réguas públicas estão reunidas nos benchmarks de MTTR.
Por onde começar a reduzir o tempo de resposta
Comece pela detecção. Ganho na primeira etapa se propaga por todas as outras, isto é, cada minuto economizado ali entra inteiro no resultado final do ciclo.
Ataque o ruído em seguida. Filtrar, deduplicar e correlacionar antes de acionar reduz o volume que chega ao humano. Assim, o alerta importante recupera a urgência que tinha perdido no meio dos irrelevantes.
Depois disso, escreva runbook para os padrões que já se repetiram duas vezes. É o item de melhor retorno por hora investida, principalmente quando o roteiro nasce do post-mortem que documentou a última ocorrência.
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. É nesse intervalo que o MTTR costuma inflar sem ninguém perceber.
Meça antes e depois de cada mudança. Sem linha de base, ninguém sabe se o ganho veio da iniciativa ou de um mês mais calmo. A disciplina de medição aparece no manual de resposta a emergências da mesma equipe.
Milhares de alertas por dia. Só os que importam chegam até você.
O KeepGreen filtra o ruído do monitoramento com IA, correlaciona eventos e entrega ao plantão apenas incidentes reais: com causa raiz, contexto e próximo passo.
Conclusão
Embora o ciclo tenha cinco etapas, a lógica cabe em uma frase. Detectar cedo, triar com critério, diagnosticar sem manter o negócio parado, resolver antes de corrigir e registrar o aprendizado enquanto os fatos ainda estão frescos.
As duas pontas do modelo do Google mantêm o ciclo girando. Preparação é o que garante a detecção do próximo incidente. Remediação é o que torna esse próximo incidente menos provável.
Cada etapa tem alavanca própria, custo próprio e uma métrica que a descreve. Por isso a pergunta útil na reunião de operação não é como está o MTTR: é em qual etapa ele está sendo gasto hoje.
Quer descobrir onde o seu ciclo trava? Fale com um especialista da OpServices e avalie etapa por etapa, com os números do seu próprio ambiente.
Perguntas Frequentes
Quais são as 5 etapas do ciclo de vida de um incidente de TI?
Qual a diferença entre mitigar e resolver um incidente?
Como descobrir em qual etapa está o gargalo do ciclo?
MTTD cobre da falha ao alerta, o MTTA cobre do alerta ao reconhecimento e o MTTR cobre do reconhecimento ao serviço restaurado. Uma pergunta simples já indica o caminho: quem detectou o último incidente do ambiente? Quando a resposta é o usuário ou a diretoria, o gargalo está na detecção, independente do que o número agregado mostre.Por que não buscar a causa raiz durante o incidente?
O que é um runbook e por que ele reduz o tempo de diagnóstico?
