As dúvidas mais frequentes sobre diferenças e interfaces entre Gestão de Eventos e Gestão de Incidentes da ITIL V3
Os processos de Gerenciamento de Eventos e Gerenciamento de Incidentes pertencem, ambos, ao livro da Operação de Serviços de TI, dentro da #ITIL. Neste artigo, irei cobrir algumas diferenças entre estes processos, focando nos pontos que costumam causar mais dúvidas entre os estudantes de ITIL.
Em primeiro lugar, farei um resumo de cada um dos processos. Se você está convicto de que conhece o escopo e objetivo de cada um, pule para o próximo tópico.
Gerenciamento de Eventos
Um evento pode ser definido como qualquer mudança de estado que tem importância para a gestão de um item de configuração (IC) ou serviço de TI. Em outras palavras, qualquer ocorrência dentro do escopo de TI que tenha relevância para a gestão dos serviços entregues ao(s) cliente(s).
Exemplos de eventos:- um usuário logou no sistema;
- um backup agendado não ocorreu;
- o sistema está sendo acessado pelo dobro de usuários do que o normal;
- um usuário não autorizado acessou um local da rede;
- um sistema está mais lento do que o normal;
- excesso de ligações por engano para o #Service Desk ;
- qualquer outro que tenha relevância para quem está gerindo os serviços de TI;
Como podemos perceber, um evento tem diversas naturezas, portanto devem ser categorizados por nomenclaturas como: normal; não usual, exceção, alerta, ou quaisquer outras classificações relevantes.
Os eventos são normalmente reconhecidos através de notificações criadas por ferramenta de monitoramento.
Propósito
O objetivo da gestão de eventos é gerenciar eventos durante todo seu ciclo de vida. Este ciclo de vida inclui atividades de detectar eventos, entendê-los e determinar a ação de controle apropriada é coordenado pelo processo de gestão de eventos.
Gerenciamento de Incidentes
Um "incidente" é definido pela ITIL como uma interrupção não planejada de um serviço de TI ou redução da qualidade de um serviço de TI. Um incidente é qualquer evento que causa interrupção no serviço.Propósito
O objetivo do gerenciamento de incidentes é restaurar a operação de serviço normal o mais rápido possível e minimizar o impacto adverso nas operações da área de negócio, garantindo assim que os níveis de qualidade de serviço acordados sejam mantidos. "Operação de serviço normal" é definida pela ITIL como um estado operacional, onde os serviços estão sendo entregues dentro do que foi acordado.
Dúvidas mais frequentes sobre a relação entre gestão de eventos e gestão de Incidentes
P1: Um evento pode se transformar em um incidente?
Assim que é detectado, um evento pode, desde já, ser classificado como um incidente. A depender da natureza do que seja detectado, o processo de gestão de eventos ou de gestão de incidentes deverá tratá-lo.
Ex: caso uma ferramenta detecte uma exceção que não se trate de um incidente, a gestão de eventos deverá contornar a situação. Caso comprometa a disponibilidade ou qualidade acordada para o serviço, entretanto, deverá ser tratado pelo processo de gestão de incidentes .
P2: Como diferenciar uma exceção de um incidente?
- Incidentes são registrados com esta nomenclatura se, e somente se, o ocorrido compromete a disponibilidade ou qualidade acordada do serviço entregue ao cliente : imagine, por exemplo, que você possui uma ferramenta de agendamento de rotinas de backup e ela falha em determinado instante. Neste ocorrido, você deve registrar um evento (uma exceção) e tratá-lo. Caso, entretanto, esta ferramenta entregue uma solução diretamente ao seu cliente, o registro deve ser feito de um incidente e não evento .
- Ainda parece complexo? Então lembre da regra: se o serviço está dentro do catálogo de serviços de TI com a área de negócio, então é um incidente , pois o usuário fim deste serviço irá ter suas atividades prejudicadas. Se você não acordou este serviço com o cliente, entretanto, significa que você tem um serviço de suporte (que provavelmente deve estar registrado em um catálogo técnico).
- Dica: lembre-se que, para a #ITIL , o serviço é tudo que entrega valor ao cliente . Se uma ferramenta, portanto é utilizada para atender alguma necessidade do cliente, esta deve ser registrada como um serviço prestado ao cliente. Caso contrário, não.
- Incidentes devem ser registrados quando o serviço passa a não atender a algum requisito que foi acordado: a melhor forma de explicar este aspecto é indo direto ao exemplo. Imagine que um sistema costuma suportar o acesso de 2 mil usuários simultâneos sem comprometer seus níveis de disponibilidade e performance . Em um determinado dia, o sistema foi acessado pelos mesmos 2 mil usuários e, para a surpresa de todos, apresentou problemas de performance , chegando a ficar indisponível diversas vezes ao dia. A situação só era contornada, neste dia, quando o número de usuários simultâneos era reduzido.
- Neste exemplo, deve ser registrado um incidente ? Muitos responderão SIM imediatamente. Entretanto, faltou uma informação importante antes de tirar esta conclusão: o requisito acordado com o cliente em relação ao número de usuários simultâneos. Caso, no acordo de TI com a área de negócio, o número de usuários simultâneos previstos seja inferior a 2 mil, o evento não deve ser considerado um incidente. Ele pode ser registrado, entretanto, como um evento não usual, pois o sistema costumava se comportar bem com o mesmo número de acessos. O processo de gestão de eventos pode trabalhar em uma forma de contornar isto e entregar a performance antes já obtida.
P3: Um usuário final pode pedir a abertura de um evento ao Service Desk ?
Não. Se você conseguir imaginar uma situação em que um usuário identifique e reporte um evento a equipe de TI, esta condição será uma exceção da exceção e não deve ser adotada como padrão.
Na regra geral, processos como gerenciamento de eventos e gerenciamento de problemas trabalham "nos bastidores de TI". Usuários solicitam registro de incidentes e requisições de serviço ao #Service Desk.
