Gestão de incidentes ITIL - processo e melhores práticas

Descubra como implementar um processo de gestão de incidentes eficaz: desde a detecao ate a resolução. Aprenda sobre priorização, métricas essenciais e as melhores práticas para minimizar o impacto nos serviços.

📅 ITIL® v5 Foundation | Online, 3 dias | 20-22 Abril

📅 ITIL® v5 Bridge Foundation (para quem tem ITIL 4 Foundation) | 1 dia | 26 Março · 7 ou 14 de Maio

📅 ITIL 4 Service Desk | 1 dia | 9 Abril

📅 ITIL Monitoring and Event Management | 1 dia | 30 Abril

O que é um incidente?

Definicao ITIL

"Uma interrupção não planeada de um serviço ou uma redução na qualidade de um serviço."

No contexto do ITIL, um incidente é qualquer evento que interrompe ou pode interromper a operação normal de um serviço de TI. O objetivo principal da gestão de incidentes é restaurar a operação normal do serviço o mais rapidamente possível, minimizando o impacto adverso nas operações de negócio.

Exemplos praticos de incidentes

  • Sistema de email em baixo - os utilizadores não conseguem enviar ou receber emails
  • Website muito lento - tempos de resposta superiores ao normal afetam a experiência do utilizador
  • Impressora sem funcionar - equipamento partilhado indisponível para o departamento
  • Aplicacao com erros - mensagens de erro impedem o trabalho normal
  • Rede indisponível - perda de conectividade afeta multiplos utilizadores

Incidente vs Problema vs Evento

É importante distinguir entre estes tres conceitos do ITIL:

Conceito Definicao Foco
Incidente Interrupcao ou redução de qualidade de um serviço Restaurar rapidamente o serviço
Problema Causa raiz de um ou mais incidentes Prevenir recorrencias futuras
Evento Qualquer mudança de estado significativa Monitorizar e detetar anomalias

A gestão de incidentes foca-se no efeito (o serviço está em baixo), enquanto a gestão de problemas investiga a causa (porque e que o serviço falhou).

Processo de gestão de incidentes

O processo de gestão de incidentes do ITIL consiste em 9 etapas que guiam a equipa desde a detecao inicial ate ao encerramento do ticket. Este fluxo estruturado garante que nenhum incidente e esquecido e que todos são tratados de forma consistente.

Fluxo do Processo de Incidentes

1
Identificação
Identification
2
Registo
Logging
3
Categorização
Categorization
4
Priorização
Prioritization
5
Diagnóstico inicial
Initial diagnosis
6
Escalação
Escalation
7
Investigação e diagnóstico
Investigation & diagnosis
8
Resolução e recuperação
Resolution & recovery
9
Encerramento
Closure

As 9 etapas em detalhe

1

Identificação

Identification

A primeira etapa consiste em detetar que existe um incidente. Esta detecao pode acontecer de várias formas: através de sistemas de monitorizacao automaticos, contacto direto de utilizadores, ou alertas de ferramentas de gestão.

Dica: Quanto mais cedo um incidente for detetado, menor será o seu impacto. Invista em monitorizacao proativa para identificar problemas antes dos utilizadores.
2

Registo

Logging

Todos os detalhes do incidente devem ser registados na ferramenta ITSM. Isto inclui: data/hora, utilizador afetado, descrição do problema, serviço impactado, e quaisquer mensagens de erro observadas.

Dica: Um bom registo é fundamental para análise posterior. Use templates para garantir que informação critica não e esquecida.
3

Categorização

Categorization

O incidente e classificado por tipo, serviço afetado e área técnica. Uma boa categorização facilita o encaminhamento para a equipa correta e permite análise de tendencias para identificar áreas problematicas.

Dica: Mantenha a arvore de categorias simples mas abrangente. Categorias demasiado detalhadas causam confusao; demasiado genericas não permitem análise util.
4

Priorização

Prioritization

A prioridade e definida usando a matriz Impacto x Urgência. O impacto mede quantos utilizadores ou serviços são afetados. A urgencia mede a rapidez com que a resolução é necessária.

Dica: Nao ceda a pressao para elevar artificialmente prioridades. Prioridades inflacionadas diluem o significado e prejudicam incidentes verdadeiramente criticos.
5

Diagnóstico inicial

Initial diagnosis

O service desk realiza uma análise de primeiro nível, consultando a base de conhecimento para soluções conhecidas. Muitos incidentes podem ser resolvidos nesta fase sem necessidade de escalacao.

Dica: Uma base de conhecimento bem mantida pode aumentar drasticamente a taxa de resolução no primeiro contacto.
6

Escalação

Escalation

Se o primeiro nível não consegue resolver, o incidente e escalado. A escalacao pode ser funcional (para equipas com mais conhecimento técnico) ou hierarquica (para gestão, em incidentes criticos).

Dica: Defina criterios claros para escalacao. Escalacoes tardias atrasam resoluções; escalacoes prematuras sobrecarregam equipas especializadas.
7

Investigação e diagnóstico

Investigation & diagnosis

Equipas especialistas analisam o incidente em profundidade, recolhem logs, testam hipóteses e identificam a solução. Toda a investigacao deve ser documentada no ticket.

Dica: Documente todas as acoes tomadas, mesmo as que não funcionaram. Esta informação e valiosa para resoluções futuras.
8

Resolução e recuperação

Resolution & recovery

A solução identificada e implementada é o serviço e restaurado. Isto pode envolver aplicar patches, reiniciar serviços, restaurar backups, ou outras acoes tecnicas necessarias.

Dica: Verifique sempre que o serviço está totalmente funcional antes de comunicar a resolução ao utilizador.
9

Encerramento

Closure

Apos confirmar com o utilizador que o problema está resolvido, o ticket é encerrado. A documentação final é completada é o incidente passa a fazer parte do histórico para análise futura.

Dica: Sempre que possível, solicite feedback do utilizador sobre a qualidade do atendimento. Esta informação ajuda a melhorar o serviço.

Matriz de priorização

A priorização de incidentes usa uma matriz 2x2 que combina Impacto (quantos utilizadores/serviços são afetados) com Urgência (quão rapidamente a resolução é necessária).

Impacto x Urgência = Prioridade

Alta Urgência
Baixa Urgência
Alto Impacto
Crítico P1
Alto P2
Baixo Impacto
Médio P3
Baixo P4

Exemplos de cada prioridade

  • P1 - Crítico: Sistema de faturacao em baixo, afetando todas as vendas
  • P2 - Alto: Servidor de ficheiros lento, afetando muitos utilizadores mas com workaround
  • P3 - Médio: Impressora de um departamento com problemas urgentes de impressao
  • P4 - Baixo: Pedido de informação ou problema menor com pouco impacto

Metricas-chave (KPIs)

Para medir a eficacia da gestão de incidentes, devem ser monitorizadas as seguintes métricas:

MTTR
Mean Time To Resolve
Tempo medio desde a detecao do incidente ate a resolução completa. Quanto menor, melhor a eficiência da equipa.
MTBF
Mean Time Between Failures
Tempo medio entre incidentes do mesmo tipo. Quanto maior, melhor a estabilidade do serviço.
FCR
First Contact Resolution Rate
Percentagem de incidentes resolvidos no primeiro contacto, sem necessidade de escalacao.
Volume
Incident Volume Trends
Tendencias no número de incidentes ao longo do tempo, por categoria e por serviço.
SLA
SLA Compliance
Percentagem de incidentes resolvidos dentro dos tempos acordados nos SLAs.
Satisfacao
Customer Satisfaction
Nivel de satisfacao dos utilizadores com o serviço de suporte recebido.

Melhores práticas na gestão de incidentes

Ponto único de contacto

O service desk deve ser o único ponto de entrada para todos os incidentes, garantindo registo consistente e visibilidade total.

Procedimentos de escalacao claros

Defina criterios e tempos de escalacao para cada nível de prioridade. Todos devem saber quando e para quem escalar.

Base de conhecimento integrada

Mantenha uma base de conhecimento atualizada com soluções para problemas conhecidos, acessivel durante o diagnóstico.

Revisoes pos-incidente

Para incidentes criticos, realize revisoes estruturadas para identificar licoes aprendidas e oportunidades de melhoria.

Melhoria continua

Use as métricas e análises de tendencias para identificar áreas de melhoria e reduzir o volume e impacto de incidentes ao longo do tempo.

Descarregue a template de registo de incidentes

Formulário profissional baseado em ITIL 4, em Word, pronto a usar na sua organização.

Ver todas as templates ITSM

Perguntas frequentes

Segundo o ITIL, um incidente é uma interrupção não planeada de um serviço ou uma redução na qualidade de um serviço. Exemplos incluem: sistema de email em baixo, website lento, impressora sem funcionar.

Um incidente é o sintoma ou efeito visivel (o serviço não funciona). Um problema é a causa raiz subjacente. A gestão de incidentes foca na restauracao rápida do serviço, enquanto a gestão de problemas investiga a causa para prevenir recorrencias.

A priorização usa a formula Impacto x Urgência. Alto Impacto + Alta Urgência = Crítico (P1). Alto Impacto + Baixa Urgência = Alto (P2). Baixo Impacto + Alta Urgência = Médio (P3). Baixo Impacto + Baixa Urgência = Baixo (P4).

MTTR (Mean Time To Resolve) é o tempo medio desde a detecao do incidente ate a sua resolução completa. É uma métrica chave para medir a eficiência da equipa de suporte é a qualidade do serviço.

O processo de gestão de incidentes ITIL tem 9 etapas: Identificação, Registo, Categorização, Priorização, Diagnóstico inicial, Escalação, Investigação e diagnóstico, Resolução e recuperação, e Encerramento.

Domine a gestão de incidentes

Aprenda a aplicar todas as práticas ITIL na gestão de serviços de TI com a certificação ITIL 4 Foundation.

Peça informações

Gestao de Problemas

Investiga as causas raiz dos incidentes e previne recorrencias futuras.

Ler artigo

Service Desk

O ponto único de contacto entre utilizadores é a área de TI.

Ler artigo

Práticas ITIL 4

Conheça todas as 34 práticas do ITIL 4 e como se interligam.

Ler artigo

ITIL 4 Foundation

Aprenda os conceitos fundamentais com a certificação Foundation.

Ver curso