Incidentes X Problemas

Apesar de já ter sido muito discutido, este é um assunto que eu gosto muito de abordar.  Primeiro porque ainda percebo a dificuldade das pessoas em explicar a diferença entre estes dois importantes processos da biblioteca ITIL. E segundo porque já me deparei com a seguinte afirmação em alguns artigos: “um incidente que não tem sua causa raiz identificada acaba se tornando um problema.”

Este conceito é incorreto! Um incidente não se torna um problema! E neste post vou explicar o porquê.

Vamos começar separando os conceitos básicos de cada um.

Segundo o ITIL (2011):

• “Incidente: É uma interrupção não planejada de um serviço de TI ou uma redução da qualidade de um serviço de TI”.
• “Problema: é a existência de um erro cuja causa é desconhecida. É a causa desconhecida de um ou mais incidentes”.
• “Incidentes são causados por problemas que precisam ser resolvidos”.

Se Problema é a causa desconhecida de um ou mais Incidentes, logo um incidente não pode se tornar um problema pelo simples fato de que o incidente só ocorre porque já existe um problema, cuja a causa raiz é desconhecida.

Problemas causam Incidentes. Incidentes não causam problemas.

O processo de Gerenciamento de Incidentes tem por objetivo restaurar a operação do serviço normal o mais rápido possível e minimizar o impacto negativo sobre as operações de negócio.   Este processo tem grande importância para que os Acordos de Nível de Serviço sejam cumpridos.

O processo de Gerenciamento de Problemas tem por objetivo encontrar a causa  raiz de um ou mais incidentes de forma a eliminá-los da infraestrutura, evitando a recorrência dos incidentes e possibilitando o cumprimento dos Níveis de Serviço. Menos incidentes, maior disponibilidade.

Agora que já passamos pelos conceitos de cada um, vamos detalhar mais um pouco as diferenças entre estes dos dois processos.

Vou contar uma situação real para exemplificar os conceitos destes dois processos. Imaginem as seguintes situações:

Situação 1:

Você é um analista de infraestrutura que faz parte da gerência de incidentes. Todos os dias você executa uma rotina de inicialização dos serviços de rede dos departamentos.

Ao final do processo é gerado um relatório com os resultados.

Ao analisar o relatório, você repara que os servidores do departamento de Marketing não foram iniciados, gerando um log de erro.

Como você tem que resolver a situação imediatamente, você reinicia o switch que atende ao departamento de marketing.

No dia seguinte, o mesmo erro ocorre e os servidores do marketing não são inicializados automaticamente. Você então força a inicialização manual destes servidores.

E assim esta situação se repete por mais alguns dias.

Situação 2:

Você então não querendo perder tempo para fazer a inicialização manual e nem ficar reiniciando o switch toda hora, decide criar uma bat dentro da rotina de inicialização automática que faz com que reforce a ação naqueles servidores.

Situação 3:

O seu gerente analisa o relatório do mês e verifica os logs de erro dos servidores e te questiona sobre a situação. Você explica a situação e conta como fez para se “livrar” do erro.

Seu gerente então percebe que deve ser feita uma investigação aprofundada sobre a causa raiz do erro.  O gerente então aciona a Gerência de Problemas, que o orienta a registrar o problema, detalhando os erros ocorridos, as ações já executas e com o anexo do relatório com os logs de erro.

Situação 4:

A equipe de Gestão de Problemas entra em ação e inicia as análises de causa. Após algum tempo de investigação, a equipe descobre que o switch que atende ao servidor do departamento de Marketing está funcionando de forma instável. Como se trata de um equipamento muito antigo, a solução dada como definitiva é a troca do equipamento.

Situação 5:

O switch é trocado. Após realização de testes, os servidores são inicializados com sucesso. O registro do problema é encerrado e todas as ações documentadas.

Então:

Na situação 1: você tem um Incidente Recorrente

Na situação 2: você aplica uma Solução de Contorno

Na situação 3: você decide tratar a Causa Raiz do problema

Na situação 4: você tem o Erro Conhecido, que é um problema cuja causa já foi identificada, com a subsequente determinação de uma solução definitiva e/ou solução de contorno.

Na situação 5: você tem a aplicação da Solução Definitiva.

Como vimos, apesar de serem processos separados, o Gerenciamento de Problemas está ligado ao Gerenciamento de Incidentes. A gerência de incidentes sempre será input para a gerência de problemas durante a tratativa de um evento que cause indisponibilidade no ambiente.

Percebem que pela própria essência do processo, a resolução de um problema é tratada de forma aprofundada, diferente da gestão de incidentes? Isso porque tratar a causa raiz exige pesquisa, análises de causa (existem várias técnicas que auxiliam nas análises) e por isso demanda maior tempo para sua conclusão. Enquanto a gerência de incidentes deve “apagar o incêndio” imediatamente para normalizar o serviço. Por isso é muito importante que a gerência de problemas tenha uma equipe separada da gerência de incidentes.

Equipes separadas e registros separados!

É indicado que haja uma equipe específica para tratar dos problemas, com seus atores definidos, com rotinas de validações, priorizações junto à gerência, indicadores e divulgação dos resultados.

A TIEXAMES (2008) afirma que “nunca se deve utilizar o registro de um Incidente para tratar um Problema”. Ou seja, é necessário um registro para cada processo. Sobre este item, o ITIL (2011) recomenda que “o software da central de serviços (ferramenta de ITSM) seja capaz de vincular o registro do Incidente no registro do Problema, e vice-versa”.

Além de registros separados, mas que se relacionem (rastreabilidade), o importante é que as soluções de contorno devem ser documentadas na base de erros conhecidos para prover eficácia e agilidade no Gerenciamento de Incidentes.

Bem, espero ter ajudado na desmistificação da diferença entre Incidentes e Problemas.

Até o próximo post!