O que é um problema?
"Uma causa ou potencial causa de um ou mais incidentes."
No contexto do ITIL, um problema representa a causa subjacente de um ou mais incidentes. Enquanto a gestão de incidentes se foca em restaurar o serviço rapidamente, a gestão de problemas investiga porque e que o incidente aconteceu e como prevenir que volte a acontecer.
A gestão de problemas tem dois objetivos principais:
- Reativo: Investigar a causa raiz de incidentes que já ocorreram
- Proativo: Identificar e resolver problemas potenciais antes que causem incidentes
Exemplos praticos de problemas
- Servidor com memoria insuficiente - causa multiplas falhas de aplicacao ao longo do tempo
- Configuracao incorreta de firewall - provoca intermitencias de conectividade
- Bug no codigo da aplicacao - gera erros sempre que determinada funcao e usada
- Hardware defeituoso - causa falhas aleatorias dificeis de diagnosticar
- Capacidade de storage insuficiente - provoca lentidao crescente no sistema
Problema vs Incidente
Compreender a diferença entre problema e incidente é fundamental para aplicar corretamente as práticas do ITIL.
Incidente
O sintoma visivel
Foco: Restaurar rapidamente
"O email não funciona" - restaurar o serviço é a prioridade, mesmo com solução temporaria.
Problema
A causa raiz
Foco: Prevenir recorrencias
"O servidor de email tem memoria insuficiente" - eliminar a causa para que não volte a acontecer.
| Aspeto | Incidente | Problema |
|---|---|---|
| Definicao | Interrupcao ou redução de qualidade | Causa de um ou mais incidentes |
| Objetivo | Restaurar serviço rapidamente | Identificar e eliminar causa raiz |
| Urgência | Alta - resolver agora | Variavel - pode levar tempo |
| Solucao aceite | Workaround e aceitavel | Requer solução permanente |
| Metricas | MTTR, FCR | Problemas resolvidos, recorrencias |
Um único problema pode causar multiplos incidentes. Por exemplo, um bug numa aplicacao pode gerar dezenas de tickets de incidentes de diferentes utilizadores. Identificar o problema e corrigi-lo elimina todos esses incidentes de uma vez.
Processo de gestão de problemas
O processo de gestão de problemas do ITIL consiste em 8 etapas que guiam a equipa desde a detecao inicial ate ao encerramento com a solução permanente implementada.
Fluxo do Processo de Problemas
Detalhes das etapas principais
1. Detecao: Problemas podem ser detetados através de análise de tendencias em incidentes, alertas proativos de monitorizacao, ou informação de fornecedores sobre vulnerabilidades conhecidas.
2-3. Registo é Categorização: Documentar todos os detalhes relevantes, incluindo os incidentes relacionados, e classificar por área técnica e impacto potencial.
4. Investigação: Aplicar tecnicas de análise de causa raiz (ver seccao seguinte) para identificar a verdadeira origem do problema.
5-6. Erro Conhecido e Workaround: Quando a causa e identificada mas a solução permanente ainda não está disponível, documentar como erro conhecido com workaround.
7. Resolução: Implementar a solução permanente, tipicamente através de um pedido de mudança formal.
8. Encerramento: Confirmar que a solução foi eficaz e documentar licoes aprendidas.
Analise de causa raiz (RCA)
A Root Cause Analysis (RCA) é o conjunto de tecnicas utilizadas para identificar a verdadeira causa de um problema, indo alem dos sintomas superficiais. Existem várias tecnicas, cada uma adequada a diferentes situações.
5 Whys
5 Porques
Tecnica simples que consiste em perguntar "Porque?" repetidamente (tipicamente 5 vezes) ate chegar a causa raiz. Cada resposta gera uma nova pergunta.
Quando usar:
Problemas de complexidade moderada com uma cadeia causal relativamente linear.
Ishikawa
Diagrama de espinha de peixe
Diagrama visual que organiza potenciais causas em categorias (Pessoas, Processos, Tecnologia, Ambiente, etc.) para análise sistematica.
Quando usar:
Problemas complexos com multiplas causas potenciais em diferentes áreas.
Kepner-Tregoe
Analise estruturada
Metodologia estruturada que usa matrizes para comparar "O que é" vs "O que não e", identificando distinções que apontam para a causa.
Quando usar:
Problemas onde é preciso distinguir entre situações afetadas e não afetadas.
Fault Tree Analysis
Analise de arvore de falhas
Metodo top-down que usa diagramas logicos (AND/OR) para mapear todas as combinações de eventos que podem causar a falha.
Quando usar:
Sistemas complexos onde a falha pode resultar de combinações de eventos.
Exemplo pratico: 5 Whys
Vejamos um exemplo de aplicacao dos 5 Whys a um problema real:
- Porque é que a aplicacao falhou? - Porque o servidor ficou sem memoria.
- Porque é que o servidor ficou sem memoria? - Porque havia demasiados processos a correr simultaneamente.
- Porque havia demasiados processos? - Porque o job de limpeza noturno não executou.
- Porque é que o job não executou? - Porque o agendamento estava incorreto após uma atualizacao.
- Porque é que a configuracao foi alterada? - Porque o processo de mudança não incluiu validacao do agendamento.
Causa raiz: Falta de validacao de configuracoes críticas no processo de gestão de mudanças.
Acao corretiva: Adicionar checklist de validacao ao processo de mudança.
Base de erros conhecidos (KEDB)
A Known Error Database (KEDB) é uma base de dados que contém registos de erros conhecidos e respetivos workarounds. É uma ferramenta essencial para acelerar a resolução de incidentes.
Beneficios da KEDB
Uma KEDB bem mantida transforma o suporte de TI
Resolução mais rápida
O service desk pode aplicar workarounds conhecidos imediatamente, sem investigacao.
Consistencia no suporte
Todos os técnicos aplicam a mesma solução, garantindo qualidade uniforme.
Conhecimento preservado
O conhecimento não se perde quando colaboradores saem da equipa.
Estrutura de um registo de erro conhecido
Cada entrada na KEDB deve conter:
- ID único - Identificador para referencia
- Sintomas - Como o problema se manifesta (para facilitar a pesquisa)
- Causa raiz - A verdadeira causa identificada
- Workaround - Solucao temporaria passo-a-passo
- Solucao permanente - Se conhecida, ou status do desenvolvimento
- Incidentes relacionados - Links para tickets de incidentes
- Servicos afetados - Para ajudar na triagem
Workarounds
Um workaround é uma solução temporaria que reduz ou elimina o impacto de um problema quando a solução permanente ainda não está disponível.
Quando usar workarounds
Workarounds são apropriados quando:
- A causa raiz foi identificada mas a correcao permanente requer tempo
- A solução definitiva depende de terceiros (fornecedores, patches)
- O impacto do problema pode ser reduzido significativamente com passos simples
- A mudança necessária e demasiado arriscada para implementar imediatamente
Boas práticas para workarounds
- Documentar claramente - Passos detalhados que qualquer técnico possa seguir
- Comunicar limitações - O que o workaround não resolve
- Monitorizar utilização - Quantos incidentes estão a usar este workaround
- Definir data limite - Quando a solução permanente deve estar pronta
- Remover após resolução - Atualizar a KEDB quando o problema for corrigido
Metricas-chave (KPIs)
Para medir a eficacia da gestão de problemas, devem ser monitorizadas as seguintes métricas:
Melhores práticas na gestão de problemas
Analise proativa de tendencias
Nao espere por incidentes criticos. Analise regularmente tendencias e padroes para identificar problemas potenciais antes que causem impacto significativo.
Nao confunda sintoma com causa
Use tecnicas estruturadas de RCA para ir alem dos sintomas superficiais. A causa raiz pode estar vários níveis abaixo do que parece obvio.
Mantenha a KEDB atualizada
Uma KEDB desatualizada e pior que nenhuma KEDB. Defina processos claros para adicionar, atualizar e remover registos.
Integre com gestão de mudanças
Solucoes permanentes devem seguir o processo de gestão de mudanças para evitar criar novos problemas ao resolver os existentes.
Meca o impacto real
Quantifique quantos incidentes e horas de trabalho foram evitados por cada problema resolvido. Isto demonstra o valor da prática para a gestão.
Envolva as pessoas certas
Problemas complexos requerem perspetivas diversas. Crie equipas multidisciplinares para investigacoes de maior impacto.
Descarregue a template de registo de problemas
Formulário profissional com análise de causa raiz e registo de erros conhecidos, em Word.
Ver todas as templates ITSMPerguntas frequentes
Segundo o ITIL, um problema é a causa ou potencial causa de um ou mais incidentes. Enquanto um incidente é o sintoma visivel (serviço em baixo), o problema é a razao subjacente que o provocou.
O incidente é uma interrupção de serviço que requer restauracao rápida. O problema é a causa raiz dessa interrupção. A gestão de incidentes foca em restaurar o serviço rapidamente; a gestão de problemas foca em identificar e eliminar a causa para prevenir recorrencias.
A KEDB (Known Error Database) é uma base de dados que contém registos de erros conhecidos e seus workarounds. Permite que o service desk resolva incidentes mais rapidamente aplicando soluções já documentadas, mesmo antes da resolução permanente do problema.
Os 5 Whys é uma técnica de análise de causa raiz que consiste em perguntar "Porque?" repetidamente (tipicamente 5 vezes) ate chegar a causa raiz fundamental do problema. É simples mas eficaz para problemas de complexidade moderada.
Um workaround deve ser usado quando a solução permanente não pode ser implementada imediatamente mas existe uma forma de restaurar ou manter o serviço. É uma solução temporaria que reduz o impacto do problema enquanto a equipa trabalha na resolução definitiva.
Domina a gestão de problemas
Aprende 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