Como este tema funciona na sua empresa
Gestão de incidentes é informal. Alerta chega (telefone, email, Slack), técnico atende, resolve ou remenda. Sem papéis definidos, sem escalação formal, sem documentação pós-incidente. Tempo de resolução é desconhecido. Desafio: caos quando múltiplos incidentes acontecem simultaneamente. Abordagem: começar com processo mínimo — designar incident commander, usar checklist simples, registrar causa raiz post-incident (nem que seja em Slack).
Processo estruturado mas não totalmente padronizado. Existe ferramenta de ticket, papéis (incident commander, comms lead), SLA de resposta. Post-mortem é eventualmente feito, mas sem rigor. MTTR é acompanhado mas não analisado. Desafio: processo criado mas não sempre seguido; comunicação durante incidente pode ser caótica. Abordagem: automatizar máximo que possível (alertas automáticos, assignment automático por skill), treinar em papéis, documentar lições aprendidas estruturadamente.
Operação madura. Ferramenta de incident management integrada, papéis bem definidos, SLA por severidade, post-mortem blameless estruturado. MTTR é métrica de desempenho de times. Desafio: escala (múltiplos incidentes em paralelo), coordenação entre times, otimização contínua. Abordagem: automação de detecção (AIOps), análise de causas raiz com dados, program de continuous improvement de MTTR.
Gestão de incidentes é o processo de detecção, resposta e resolução de interrupções não planejadas em serviços de TI. Compreende ciclo completo: detecção do alerta, triagem, diagnóstico, remediação, validação e análise pós-incidente (post-mortem) para aprendizado contínuo[1].
O ciclo completo de incidente: de alerta a aprendizado
Incidente passa por sete estágios sequenciais. Cada um tem propósito e responsável.
- Detecção e alerta: sistema de monitoramento detecta anomalia (CPU alta, serviço caiu, taxa de erro aumentou). Alerta é dispara automaticamente ou manualmente. Responsável: monitoring/operador.
- Triagem: classificar incidente: é real ou falso positivo? Qual severidade (P1 crítico, P2 alto, P3 médio, P4 baixo)? Criar ticket. Responsável: primeiro técnico a atender.
- Diagnóstico inicial: técnico N1 investiga. Consegue resolver? Se sim, pula para remediação. Se não, escala para N2. Documentar achados. Responsável: técnico N1/N2.
- Diagnóstico profundo: N2/N3 investiga causa raiz. Qual componente falhou? Quand começou? Existe correlação com mudança recente? Responsável: N2/N3.
- Remediação: aplicar fix temporário (workaround) ou fix permanente. P1 pode usar workaround temporário para restaurar serviço rápido, depois fix permanente. P2/P3/P4 podem esperar fix permanente. Responsável: técnico apropriado.
- Validação: confirmar que serviço está restaurado. Usuários podem acessar? Performance é normal? Responsável: técnico + usuário.
- Post-mortem (apenas para P1/P2): reunião para aprender. Qual foi causa raiz? Por que não foi detectado antes? Como prevenir repetição? Ação: documentar, criar change, treinar. Responsável: tech lead + equipe.
Papéis em incidente: clareza é tudo
Incidente requer coordenação. Definir papéis evita confusão ("quem está resolvendo?" "quem comunica?" "quem toma decisão?").
Incident Commander (IC): responsável geral. Toma decisões (escalation, who does what, when to stop trying fix e aceitar workaround). Não precisa ser técnico mais senior; precisa ser comunicador. Em P1, IC garante que problema é resolvido. IC não "faz" (não toca no servidor); IC "orquestra".
Technical Lead: especialista que diagnóstica e orienta remediação. Trabalha com N2/N3. IC se reporta a TL para decisões técnicas.
Comms Lead: responsável por comunicação com usuários/stakeholders. Envia updates: "estamos cientes", "causa é X", "estimativa Y". Reduz pânico e chamadas múltiplas sobre mesmo incidente.
Subject Matter Experts (SMEs): especialistas em componente específico (DBA para BD, network engineer para rede, etc). Chamados conforme necessário.
Detecção e triagem: primeira resposta é crítica
Alerta chega. Primeira ação: é real incidente ou falso positivo? Se real, qual severidade?
Triagem de severidade: usar matriz: impacto (quantos usuários?) x urgência (quanto tempo podem esperar?). P1 = crítico (muitos usuários, agora). P2 = alto (alguns usuários, horas). P3 = médio (poucos usuários, dias). P4 = baixo (cosmético).
Exemplo: servidor de email caiu = P1 (centenas de usuários, precisa agora). Impressora lenta = P3 (5 pessoas, podem esperar).
SLA é baseado em severidade. P1: responder em 15 min, resolver em 4h. P2: responder em 1h, resolver em 8h. P3: responder em 4h, resolver em 24h. P4: resolver quando possível.
Responsável por triagem: primeiro técnico. Deve ser rápido (5 min) mas preciso. Dúvida? Escalar.
Triagem informal. Técnico recebe alerta, avalia de cabeça. SLA não é formal mas velocidade é esperada (P1 = hoje, P3 = próxima semana). Escalation é "ligar para gerente" se técnico não consegue.
Triagem em ferramenta de tickets. Template com campos: severidade, impacto, urgência. SLA explícito por severidade. Escalation automática se SLA está em risco (ticket muda de cor, notifica gerente).
Triagem semi-automática. Sistema de monitoramento classifica severidade com base em impacto (quantos usuários), e sugere escalação. Técnico confirma ou ajusta. SLA é rastreado em tempo real e publicado em dashboard.
Diagnóstico e RCA: encontrando a causa
Encontrar causa raiz é o que mais consome tempo em incidente. RCA (Root Cause Analysis) é processo sistemático[2].
Técnicas simples de RCA:
- "5 Porquês": fazer pergunta "por quê?" 5 vezes. Ex: "Sistema caiu" ? "Por quê?" ? "Memória cheia" ? "Por quê?" ? "Leak de memória em aplicação" ? "Por quê?" ? "Deploy novo sem testes" ? "Por quê?" ? "Processo de QA foi pulado".
- Timeline: mapear eventos. "14:00 deploy liberado, 14:05 CPU sobe, 14:10 alerta dispara, 14:15 aplicação trava". Qual evento disparou problema?
- Correlação: o que mudou? Deploy? Config? Carga de dados? Problema correlaciona com mudança recente.
Responsável: N2/N3. Documentar achados para post-mortem.
Remediação: fix temporário vs. permanente
Duas abordagens: workaround rápido ou fix permanente. Para P1, velocidade importa.
Workaround (temporário): solução rápida que restaura serviço mas não resolve causa raiz. Exemplo: "reiniciar aplicação para limpar memória". Efeitiva? Sim. Resolve leak? Não. Usar para P1 para restaurar serviço em 30min, depois fix permanente é investigado.
Fix permanente: resolve causa raiz. Exemplo: "corrigir leak de memória no código". Mais demorado (horas/dias) mas resolve de verdade. Usar para P2/P3/P4 onde tempo permite.
Decisão: IC e TL decidem. Para P1: workaround agora, fix depois. Para P3: skip workaround, ir direto ao fix.
MTTR: métrica que importa
MTTR (Mean Time To Resolution) é tempo médio entre alerta e resolução. Métrica crítica de operação. Benchmarks: corporações visam 2-8h para P1, 8-24h para P2.
Acompanhar tendência mensal. Se MTTR sobe (6h ? 10h ? 14h), é sinal que processo está piorando ou técnicos estão menos experientes. Se desce (6h ? 4h ? 2h), é sinal que processo melhorou ou automação foi adicionada.
Usar MTTR para avaliar performance de times e para justificar investimentos. "Se investirmos em AIOps, reduzimos MTTR de 6h para 3h. ROI: Y."
Comunicação durante incidente: reduzindo pânico
Usuários pressionam. Gerência cobra. Comunicação clara é essencial. Comms Lead deve enviar updates a cada 15-30 min:
- "Estamos cientes do problema. Afeta: email. Impacto estimado: 500 usuários. ETA de resolução: 15:30. Continuaremos atualizando."
- "Investigação em progresso. Identificamos causa: servidor de email está fora de memória. Equipe está trabalhando em solução."
- "Serviço foi restaurado às 15:45. Acompanhamos performance nos próximos 30 min para garantir estabilidade."
Transparência reduz frustração. Falta de comunicação = multiplicação de rumores e pânico.
Post-mortem: aprendendo sem culpar
P1/P2 exigem post-mortem em 24-48h após incidente. Objetivo: aprender, não culpar. "Blameless retrospective" é termo importante.
Agenda (1h):
- Recapitulaçãodo que aconteceu (timeline)
- Causa raiz identificada
- Como foi detectado/resolvido
- Por que não foi detectado antes?
- Ações para prevenir repetição (monitoramento melhor, testes melhores, documentação, etc)
- Ações para detectar mais rápido se repetir (alertas)
Regra ouro: "blameless" significa focar em processo/sistema, não em pessoa. Não é "por que o técnico errou", é "por que o processo permitiu o erro".
Sinais de que sua operação de incidentes precisa melhorar
Se você se reconhece em três ou mais cenários, gestão de incidentes exige atenção.
- Incidentes levam mais de 4-6h para resolver (MTTR está alto)
- Mesma coisa quebra repetidamente (post-mortem não está gerando ações)
- Durante incidente, ninguém sabe quem está resolvendo ou comunicando (papéis não são claros)
- Usuários descobrem problema antes de TI receber alerta (monitoring é inadequado)
- Não há histórico de incidentes passados para aprender (documentação é fraca)
- Post-mortem vira "blame session" (cultura blameless não existe)
- Escalation é confusa (sem critério claro de quando escalar)
Caminhos para implementar gestão de incidentes
Começar simples e evoluir conforme necessidade e maturidade.
Você desenha processo, treina equipe, implementa com ferramentas que tem ou de baixo custo.
- Perfil necessário: gestor de operações com experiência em incident management, facilitador de processo
- Tempo estimado: 2-4 semanas para desenhar, documentar, treinar. Implementação 1-2 meses
- Faz sentido quando: você tem person disponível, quer controle total, quer aprender na prática
- Risco principal: processo desenhado mas não seguido, falta de disciplina, regressão após melhorias iniciais
Consultoria especializada em ITIL/incident management desenha processo, implementa ferramenta, treina equipe.
- Tipo de fornecedor: Consultoria ITIL, MSP com expertise em incident management, ou plataforma com serviço profissional (PagerDuty, Opsgenie)
- Vantagem: expertise, best practices, ferramenta + processo integrado, treinamento estruturado
- Faz sentido quando: operação é grande/complexa, quer implementar ferramenta avançada, quer garantir sucesso
- Resultado típico: processo desenhado em 1-2 semanas, ferramenta implementada em 2-4 semanas, operação otimizada em 3-6 meses
Precisa estruturar ou melhorar a gestão de incidentes de TI?
Se reduzir MTTR e estruturar resposta a incidentes é prioridade, o oHub conecta você gratuitamente com consultores de ITIL e fornecedores de plataformas de incident management. Em menos de 3 minutos, descreva sua necessidade e receba propostas, sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
Quais são os estágios de um incidente?
Detecção ? triagem (classificação de severidade) ? diagnóstico inicial (N1) ? diagnóstico profundo (N2/N3 identifica causa raiz) ? remediação (fix ou workaround) ? validação (confirma resolução) ? post-mortem (aprendizado para P1/P2).
Como reduzir o MTTR (Mean Time To Resolution)?
Automação de detecção (alertas disparam mais rápido), escalation automática (problema sobe para N2/N3 sem demora), monitoramento robusto (problema detectado antes do usuário), runbooks documentados (técnico não inventa a roda), e post-mortem que gera ações (evita repetição).
Qual é o papel do Incident Commander?
Orquestrador geral. Não resolve tecnicamente; toma decisões. Quando escalar? Qual decision fazer (workaround vs. fix)? Quando parar de tentar e aceitar degradação? IC comunica com executivos/usuários e coordena técnicos.
Como coordenar times para resolver incidentes rapidamente?
Papéis claros (IC, TL, comms), escalation automática, war room (call or canal Slack onde todos se juntam), comunicação sincronizada, e decisões rápidas de IC. Confusão = demora. Clareza = velocidade.
Como documentar e aprender com incidentes?
Post-mortem em 24-48h (não semana depois). Documentar: timeline, causa raiz, como foi resolvido, por que não foi detectado antes, ações para prevenir. Ações devem ser rastreadas. Sem tracking, post-mortem é vanidade.
Ferramentas para gerenciar incidentes de forma eficiente?
PagerDuty, OpsGenie, VictorOps, FireHydrant, ou módulo de ITSM (ServiceNow, Jira Service Desk). Ferramenta sozinha não resolve; processo + ferramenta + treinamento = sucesso.