O ITIL - Information Technology Infrastructure Library – foi desenvolvido pelo governo britânico no final da década de 1980. O ITIL descreve os processos que são necessários para dar suporte à utilização e ao gerenciamento da infra-estrutura de TI. Ele mostrou que possui uma estrutura útil em diversos setores tendo em vista a sua adoção em várias empresas de gerenciamento de serviços de TI. Em meados da década de 1990 o ITIL foi reconhecido mundialmente como um padrão de fato para gerenciamento de serviços.
Dentre os diversos processos de negócio tratados pelo ITIL, existem dois, que apesar de parecerem semelhantes, tem objetivos diferentes: Gerenciamento de Incidentes e Gerenciamento de Problemas.
O Gerenciamento de Incidentes têm por objetivo restaurar a operação normal do serviço o mais rápido possível e garantir, desta forma, os melhores níveis de qualidade e disponibilidade do serviço.
O Gerenciamento de Problemas tem por objetivo identificar e remover erros do ambiente de TI, através da busca da causa raiz dos incidentes registrados no Gerenciamento de Incidentes, a fim de garantir uma estabilidade máxima dos serviços de TI.
Segundo o ITIL, incidente é qualquer evento que não faz parte da operação padrão de um serviço e que causa, ou pode causar, uma interrupção do serviço ou uma redução da sua qualidade; enquanto problema é a causa desconhecida de um ou mais incidentes, ou seja, um incidente que não tem sua causa raiz identificada acaba se tornando um problema.
Enquanto o Gerenciamento de Incidentes tem como foco restabelecer o serviço o mais rápido possível, minimizando impactos na operação do negócio dentro dos níveis de serviços estabelecidos (para isso, pode ser usada, por exemplo, uma solução de contorno temporária), o Gerenciamento de Problemas é o processo responsável por controlar o ciclo de vida dos problemas, prevenindo sua ocorrência, eliminando incidentes repetitivos e reduzindo o impacto dos incidentes nos serviços, através da identificação da sua causa raiz.
O processo de Gerenciamento de Problemas vai cuidar, portanto, da resolução definitiva e da prevenção de falhas que causam incidentes e afetam o funcionamento normal dos serviços de TI.
Como exemplo, podemos usar a metáfora de uma goteira em casa num dia de chuva. Se começa a pingar água pela laje da casa, isto é um incidente. Para resolver o incidente de forma imediata, podemos colocar um balde d’água sob a goteira. Isto é uma solução de contorno, mas, não resolve a causa raiz do incidente. Depois que pára de chover, é possível identificar a causa raiz do incidente, que pode ser uma telha quebrada e tratar a solução definitiva do problema, efetuando a troca da telha, neste caso está sendo feito o gerenciamento do problema, pois, a causa raiz foi identificada e tratada.
Muito obrigado por este resumo perfeitamente elaborado.
ResponderExcluirParabéns pelo post
ResponderExcluirExcelente post.
ResponderExcluirEste comentário foi removido pelo autor.
ResponderExcluirparabéns. excelente explicação.
ResponderExcluir[]'s
Dúvida!!!! tendo eu que fazer uma preventiva de um backup, isso entraria em um problema certo? Ou ainda assim em outra categoria?
ResponderExcluirObrigado.
Preventiva de um backup? Seria um backup preventivo de outro backup? Se sim, estaria mais para um incidente ou Requisição de serviço.
ExcluirPrezados,
ResponderExcluirExcelente resumo. A idéia é esta mesmo, o incidente apaga o incendio e o problema resolve em definitivo. Mas eu acho válido que o problema gere uma base de conhecimento com solução de contorno para quem atual no fluxo de incidente. Para solucionador o problema pode existir limitação de recursos, então este precisa ser priorizado e a recorrencia dos incidentes pode ser utilizada como critério de priorização.
Wallace Oliveira
www.supravizio.com
Encontrei o blog através do google.
ResponderExcluirObrigado pela analogia elucidativa.
Ja tem um tempo que estou tetando entender o diferenca entre incidente X problema. Agora ja nao tenho mais duvidas.... Obrigada
ResponderExcluirExcelente Resumo , contribuiu bastante para sanar algumas dúvidas que eu tinha !!!
ResponderExcluirMuito obrigado pelo resumo. Com certeza utilizarei o exemplo da goteira!
ResponderExcluirÒtima explicação...........Parabéns
ResponderExcluirMuito claro. Legal!
ResponderExcluirMuito bom!
ResponderExcluirPoderiam me ajudar com uma dúvida. Aqui temos um incidente no sistema, em um relatório que está divergente porém leva mais tempo para corrigir e que não causa indisponibilidade. Abrimos um problema para a correção. Este incidente deve permanecer aberto, mesmo estourando SLA?
ResponderExcluirO mais comum é fechar o incidente aplicando um solução de contorno (fazendo uma query manual para gerar o relatório correto, por exemplo) e deixar o problema aberto até que se resolva a causa raiz. Mas, se não foi possível resolver o incidente nem com uma solução de contorno, ele deve ficar aberto mesmo estourando o SLA (neste caso nem precisaria abrir um problema).
ExcluirMuito bom!
ResponderExcluirÓtima explicação!
ResponderExcluirParabéns, ótimo conteúdo.
ResponderExcluir