Solucionado
Quando um incidente ocorre, registramos o fato e damos início as atividades para retomada do serviço, mas como todo incidente, precisamos identificar o que está ocorrendo para chegar a uma ação que levará a uma solução de contorno ou mesmo definitiva. Minha dúvida é justamente neste período de tempo de compreensão do que está havendo. Deveríamos esperar algum tempo para abrir um problema, evitando assim que se abram vários tickets de problemas desnecessários?
Superficialmente, pode parecer que um “incidente” e um “problema” são a mesma coisa. Para profissionais fora do mundo da tecnologia da informação, qualquer uma das palavras pode ser usada para descrever uma situação que está causando impacto negativo nos negócios. Mas em TI, os dois termos são diferentes e precisam ser tratados e gerenciados de formas distintas.
O que é um incidente?
De acordo com o ITIL 4, um incidente é uma interrupção não planejada ou redução na qualidade de um serviço.
O que é um problema?
Um problema é a causa raiz de um ou mais incidentes. Uma vez que as linhas de escalonamento são ativadas e nenhuma solução é disponibilizada, é possível que seja necessária a abertura de chamado de um problema para áreas específicas investigaram a solução.
Distinguir entre incidentes e problemas é o mesmo que separar causa e efeito. Os problemas são a causa e os incidentes são o efeito.
As melhores práticas de ITIL indicam a maneira adequada de lidar com incidentes e problemas.
Gestão de Incidentes: A prática de minimizar o impacto negativo dos incidentes, restaurando a operação normal do serviço o mais rápido possível.
Gestão de Problemas: A prática de reduzir a probabilidade e o impacto dos incidentes, identificando as causas reais e potenciais dos incidentes e gerenciando soluções alternativas e erros conhecidos.
Gestão de Incidentes - Fluxo de Processos
Registro de Incidentes: A primeira etapa no gerenciamento de incidentes é relatar o incidente identificado. A equipe de TI deve capturar informações completas sobre o incidente usando um modelo de formulário para acelerar o processo de recuperação.
Classificação de Incidentes: Segmente os incidentes com a categoria e subcategoria adequada para facilitar a identificação. Personalize o formulário de incidente com os campos certos e configure regras automatizadas para classificação, priorização e atribuição de tíquetes.
Priorização de Incidentes: Estabeleça uma definição realista de SLA para atender aos compromissos do cliente.
Investigação e Diagnóstico: Quando um chamado de incidente é aberto, a equipe de TI realiza uma análise inicial e envia uma resolução ao usuário final. Se necessário deve-se escalar o chamado de incidente para equipes de nível II e nível III para investigação mais detalhada.
Resolução e fechamento de chamados de incidentes: Um dos principais objetivos de qualquer equipe de TI é resolver qualquer incidente o mais rápido possível. A comunicação eficiente sobre a resolução e o fechamento dos chamados resolvidos é muito importante.
Gestão de Problemas - Fluxo de Processos
Identificação proativa de problemas: Melhore a disponibilidade geral dos serviços identificando problemas de forma proativa para que possam ser resolvidos antes que futuros incidentes ocorram.
Diagnóstico e resolução de problemas: Identifique a causa raiz de um problema e aplique a solução mais apropriada.
Controle de problemas e erros: Monitore constantemente os problemas pendentes para que quando necessário, medidas corretivas possam ser introduzidas.
Encerramento e avaliação do problema: Certifique-se de que, após a solução de um problema, o registro contenha uma descrição histórica completa e que a base de conhecimento seja atualizada.
Revisão do problema principal: Analise a resolução do problema para garantir que as situações problemáticas tenham sido totalmente eliminadas. Identifique as ações preventivas (como mudanças no processo) que devem ser realizadas para evitar a recorrência do problema.
Relatórios de gestão de problemas: Informe todas as áreas de TI sobre os problemas pendentes, seus status e soluções existentes.
Fontes: CIO, Global Knowledge e IT Process Wiki
Wilson, boa tarde.
Caso tenho de ajudado com as suas dúvidas, por favor finalizar o tópico como solucionado.
Um abraço.
Eduardo
Wilson, boa noite.
Por favor finalizar o tópico como solucionado caso tenha te ajudado.
Um abraço. Bons estudos.
Eduardo
Olá Eduardo, só recebi a notificação de resposta agora. Sua resposta é bastante rica e conceitual, mas na prática ainda me resta a dúvida. Supomos que um erro 500 se apresenta quando um usuário tenta consultar um site e este incidente está em andamento a mais de 5 horas porque envolveu o desenvolvimento. Qual critério ou fato fará com que eu abra um ticket de problema? Por exemplo, qual seria a postura do time?
Prezado Wilson, bom dia.
Sugestão de abrir um novo tópico do forma registrando a sua dúvida, para que outra pessoa ou moderador posso te responder melhor.
Estou fazendo um trabalho voluntário para Alura. Vou tentar responder pelo que sei sobre o Erro 500, mas acho melhor pesquisar e estudar melhor.
O erro 500 é a falha que impede que sites sejam carregados pelo usuário. O problema pode ter diferentes origens, desde problemas de comunicação do servidor até dificuldades do navegador que faz o acesso do usuário. O importante é identificar as possíveis causas e saber como lidar com elas.
O erro 500 significa que há um problema com alguma das bases que faz um site rodar. Esse erro pode ser, basicamente, no servidor que mantém as páginas no ar ou na comunicação com o sistema de arquivos ,que fornece a infraestrutura para o site.
Quando há alguns desses problemas, automaticamente todas as páginas do site ficarão indisponíveis. É por isso que há uma completa inatividade, com a indisponibilidade podendo ser verificada de forma ampla, mesmo que o usuário tente acessar diferentes links do site.
Desse modo, o erro 500 é um problema que gera inacessibilidade aos usuários, o que configura um transtorno. A partir disso, cabe a busca pela solução para trazer de volta o site ao ar, especialmente se ele é mais do que um simples institucional informativo. De qualquer forma, gerar essa frustração no usuário nunca é uma boa ideia.
Bons estudos. Boa sorte.
Prezado Eduardo, o erro 500 foi só um exemplo. Uma situação hipotética para exemplificar a minha dúvida sobre quando abrir um ticket de problema tendo um incidente em aberto. É um dúvida sobre gerenciamento de incidente e problema.
Wilson, tentando contribuir para a discussão, segue minha visão sobre o tema:
Então, se o incidente não for crítico, eu esperaria para ver se ele se repete e, somente se isto ocorrer, abriria um problema para ser analisado, por exemplo, com a "root cause analysis" (espinha de peixe).