GERÊNCIA DE INCIDENTES UTILIZANDO UMA APLICAÇÃO OPEN
SOURCE SEGUINDO AS BOAS PRÁTICAS DA BIBLIOTECA ITIL V3
Paulo H. da Silva Franco1, Francisco J. A. de Aquino2
Resumo – Este artigo tem como objetivo apresentar
uma ferramenta que implemente o gerenciamento de
incidentes no setor de TI das organizações. Como
fundamentação
teórica
a
ferramenta
será
implementada visando seguir os conceitos abordados
na biblioteca ITIL V3. A biblioteca é definida
através dos principais processos e funções que as
boas práticas sugerem nos cinco livros da versão.
Após apresentado os objetivos básicos da Central de
Serviços, realiza-se uma pesquisa das principais
ferramentas de gerenciamento de incidentes
disponíveis no mercado. Como solução para o
problema apresentado é utilizada a aplicação
Ocomon, como provedora da solução para o registro
de ocorrências e demandas de um ambiente de TI.
Palavras-chave: ITIL, OCOMON, Open Source.
1. Introdução1
Os serviços praticados pela TI de uma
organização são cruciais para o crescimento da
empresa. Sabe-se que existe a necessidade de
prover suporte e condições para que os clientes e
usuários consigam desenvolver suas funções. A
inexistência de uma equipe que atenda estas
necessidades torna impossível a recepção dos
possíveis
incidentes
ocasionados
pelas
ferramentas e serviços desenvolvidos pela TI,
sejam eles causados pelas informações dos
usuários, sejam eles causados pela própria TI.
É fundamental para o ciclo de vida do
negócio que existam profissionais que tenham a
função de gerenciar este tipo de solicitação. Esta
equipe é apresentada como Central de Serviços,
que segundo o ITIL (Information Technology
Infrastructure Library) é uma função essencial
para o gerenciamento de serviços em TI.
Permite-se com a criação deste grupo que o
incidente seja acompanhado a partir do
momento em que é aberto até o momento em
que é entregue a solução. A não entrega da
resolução em tempo hábil ou fora das
necessidades,
impacta
diretamente
no
1
Paulo Franco é estudante de Telemática no Instituto
Federal de Ciência e Tecnologia do Ceará (IFCE). E-mail:
[email protected].
2
Francisco J. A. de Aquino é professor no IFCE. E-mail:
[email protected].
desempenho dos serviços utilizados pelos
usuários.
É essencial que este grupo esteja munido de
uma ferramenta que registre os incidentes.
Através desta, será possível determinar o tempo
de atendimento dos chamados, criar uma base de
conhecimento das soluções aplicadas para
resolução dos problemas, apontar os setores que
precisam de treinamento, determinar os serviços
que são providos pela TI, desta forma,
eliminando o esforço empenhado para aqueles
que não deverão ser providos, identificar
equipamentos ou softwares que estão gerando
problemas e uma série de informações que
conseqüentemente
auxiliarão
no
desenvolvimento da empresa.
Com embasamento nas principais funções e
processos ITIL V3, este artigo tem como
objetivo ajudar as empresas que desejam
implantar uma ferramenta open source para
gerenciamento de incidentes.
Para implantação da aplicação de
gerenciamento de incidentes, utilizaremos como
estudo de caso, o processo de parametrização do
software Ocomon.
2. ITIL
Durante a década de 1980, a prática de
gerenciamento de serviços em TI cresceu e
conseqüentemente a dependência do negócio a
tecnologia também. Sendo necessário dar
suporte aos serviços nascem as primeiras células
de Help Desk com o objetivo de entregar a
continuidade necessária dos serviços providos
pela TI. No mesmo tempo o governo da
Inglaterra cria um documento com as melhores
práticas utilizadas pelas organizações de maiores
sucessos em gerenciamento de serviço.
No começo da década de 1990 é produzida
uma série de livros pelo CCTA (Central
Computing and Telecommunications Agency)
atual OGC (Office of Government Commerce),
documentando o que é necessário para suporte
dos serviços aos usuários. Este conjunto de
livros é intitulado de IT Infrastructure Library
(ITIL). A Biblioteca cresceu e ficou composta
por 42 livros. Envolvendo conceitos da
computação e introdução aos conceitos de
processo esta biblioteca despertou o interesse
dos departamentos de TI da Inglaterra. O termo
“gerenciamento de serviços em TI” não era
conhecido até este momento, mas com o
compartilhamento das boas práticas a
popularidade do ITIL cresceu.
Entre 2000 e 2002, a biblioteca sofreu uma
completa revisão e reformulação, sendo as
práticas reunidas em 8 volumes. Focado no
suporte e entrega dos serviços a versão 2 do
buscou abordar o alinhamento dos processos do
negócio com os serviços de TI.
Em 2007 foi lançada a Versão 3. Com mais
objetividade apresenta-se o conceito de
gerenciamento de serviços focado no ciclo-devida do serviço. Estes conceitos são
apresentados em cinco livros e um guia
introdutório com os seguintes tópicos:
• Introduction to ITIL Service Management
Practices,
• Service Strategy (Estratégia de Serviço);
• Service Design (Desenho do Serviço);
• Service Transition (Transição do Serviço);
• Service Operation (Operação do Serviço);
• Service Improvement (Melhoria do Serviço
Continuada);.
A Figura 1 apresenta as publicações que
formam a biblioteca ITIL V3.
Figura 1. Biblioteca ITIL.
A preferência das organizações pelo ITIL se
deve aos seguintes pontos:
Não-proprietário: as boas práticas sugeridas
pelo ITIL poderão ser utilizadas por
qualquer organização pelo fato de não se
basear em nenhuma plataforma proprietária;
• Sem prescrições: ITIL oferece maturidade,
pois as práticas foram aplicadas em todos os
tipos de organizações de serviços. Podendo
ser aplicada em qualquer tipo de empresa do
setor privado ou público de pequeno, médio
ou grande porte;
• Melhores
práticas:
as
práticas
de
gerenciamento de serviços do ITIL são fruto
das experiências e idéias das maiores
lideranças na área de gerenciamento de
serviços em TI.
O software Ocomon obedecerá aos
princípios adotados pelo processo de
gerenciamento de incidentes descritos na fase de
operação do serviço.
Para isso, alguns pontos devem ser
definidos, pois como visto anteriormente o
serviço apresenta as fases de definição
estratégica e desenho que são anteriores a fase
de operação.
•
3. Central de Serviços
Considera-se que a implantação do objeto de
estudo deste artigo, a aplicação Ocomon, só será
realizada coerentemente se as políticas para
tratamento dos incidentes estiverem bem
definidas e acordadas com os usuários e a TI.
Para isso, é primordial que a Central de Serviços
(CS) possua sua política de atendimento
definida. A existência da CS é de vital
importância para organização, pois se torna o
ponto de contato único entre os usuários e o
departamento de TI. Desta forma, todos os
incidentes e requisições de serviços devem ser
tratados inicialmente por esta função. Seu
principal objetivo é o restabelecimento do
serviço o mais rápido possível.
A CS se baseia em três pilares (COHEN,
p.17) para uma boa eficiência:
• infra-estrutura (tecnologia);
• processos;
• pessoas.
Neste tópico, destaca-se a questão dos
processos. Por tanto, para implementação
adequada do software os pontos relativos aos
processos serão tratados a seguir.
3.1 Estrutura Organizacional
MAGALHÃES e PINHEIRO (2007)
definiram os seguintes fatores para a escolha do
tamanho da CS: tamanho da organização, o grau
de distribuição da estrutura organizacional e o
nível de heterogeneidade da infra-estrutura de
TI. Baseando-se nestas informações montaram
uma tabela como proposta de seleção, ver
Tabela 1.
Como apresentado na Tabela 1, existem três
tipos principais de estruturas:
• Central de Serviços Local: Este tipo tem
toda sua infra-estrutura localizada no mesmo
espaço físico dos usuários dos serviços de
TI. Isso permite uma maior visibilidade dos
acontecimentos.
• Central de Serviços Centralizada: Quando
toda a sua infra-estrutura estiver em um local
físico diferente da localização dos usuários
dos serviços de TI.
• Central de Serviços Virtualizada: Este tipo
de
arquitetura
está
distribuída
geograficamente.
• Atendimento 24 horas: algumas organizações por possuírem sedes em várias partes
do globo poderão ter o serviço de suporte
disponibilizado 24 horas.
• Grupos especializados: Através de gravações
telefônicas os grupos de incidentes serão
informados e o usuário selecionará para que
tipo deseja atendimento. A ligação
redirecionará o usuário para o especialista no
atendimento daquele incidente.
Tabela 1. Estrutura Organizacional e ITIL.
Na verdade, uma organização pode utilizar
uma estrutura que seja resultada da combinação
de mais de uma destas opções com o objetivo de
satisfazer
negócio.
plenamente
as
necessidades
do
3.2 Catálogo de Serviço e SLA’s
Após definido a estrutura que a CS
funcionará, é extremamente importante definir o
que a CS proverá de serviços aos usuários. A
partir disso, nasce à necessidade de criar um
catálogo especificando quais serviços o
departamento de TI está apto a prover ao
usuário.
Para a criação do catálogo de serviço é
necessário
consultar
o
processo
de
gerenciamento do catálogo de serviço no livro
Desenho do serviço (TAYLOR et. al ,p.101). O
objetivo processo é gerenciar as informações
contidas no catálogo do serviço.Estas
informações devem refletir todas as informações
relativas aos serviços que estão sendo
executados ou que estejam prestes a serem
executados. O Catálogo de Serviço deve incluir
a descrição do serviço, os status, dependências e
interfaces. Na Tabela 2 temos um exemplo das
informações que poderão ser abordadas no
catálogo.
Tabela 2. Informações do catálogo.
Uma vez definido o que será provido para os
usuários,
será
necessário
definir
as
responsabilidades e atribuições que os
provedores do serviço e os clientes deverão
cumprir. Para isso o gerenciamento de nível de
serviço, também na fase do Desenho do serviço
(TAYLOR et. al, p.109), mostra como
documentar negociações e acordos entre os
usuários e o departamento de TI. O objetivo é
garantir através de um acordo que o serviço seja
entregue com qualidade e em tempo hábil.
Este acordo é denominado SLA (Service
Level Agreement). Para criação de uma SLA
quatro fatores são essenciais: a descrição, o
objetivo, as medições e as penalizações.
(CARVALHEIRA, p.4).
A criação da SLA deve sempre ser feita
entre o departamento de TI e as áreas clientes do
serviço.
3.3 Níveis de Suporte
Os níveis de suporte são camadas
especializadas de técnicos que colaboram para
resolver os incidentes enviados para CS.
Uma organização deve assegurar que os
funcionários sejam atendidos por um número
suficiente de analistas e estes estejam sempre
disponíveis conforme a demanda.
Para definição dos níveis é importante que
sejam considerados alguns fatores (TAYLOR et.
al, p.205):
• Expectativas dos clientes e usuários;
• Número de clientes e usuários;
• Tipos de incidentes e requisições de
serviços;
• O período de tempo necessário para suporte
aos usuários (Zonas de tempo, jornada
padrão de trabalho e requisitos solicitados
fora do expediente);
• Tipos de comunicação com os usuários
(Telefone, e-mail, salas de bate-papo);
• Entendimento
dos
processos
e
procedimentos do negócio.
Todos estes itens devem ser cuidadosamente
estudados antes de qualquer decisão da definição
dos níveis.
A organização deve definir que faixas de
habilidades são necessárias para os níveis da CS.
A maioria dos departamentos de TI possui no
máximo 3 níveis de suporte.
O primeiro nível de suporte é constituído
pelos analistas da CS. Responsável pela
demanda dos incidentes e requisições de
serviços. É o ponto único de contato com a TI
(SPOC – Single Point Of Contact).
Tradicionalmente existem 3 estilos neste
nível (COHEN, p.43):
• Solucionador: o perfil destes analistas é
bastante desenvolvido em termos técnicos. O
objetivo é que o incidente seja solucionado
no momento do recebimento;
• Direcionador: a função deste analista é de
simplesmente registrar o incidente de uma
forma detalhada e encaminhar para o nível
responsável
•
Solucionador
+
Direcionador:
nesta
combinação o analista registra o incidente e
tenta resolver apenas com o auxílio da base
de incidentes e scripts de análise.
O segundo nível de suporte pretende resolver
os incidentes que não são resolvidos de forma
remota. Os técnicos deste grupo intervêm nos
incidentes que necessitam da presença física.
Geralmente os incidentes resolvidos por este
nível são problemas de hardware, infraestrutura
de rede e de banco de dados.
O terceiro nível de suporte é composto por
fabricantes de software e hardware, especialistas
externos e consultores. Os incidentes chegam a
este nível quando o suporte local necessita de
um auxílio externo para resolução do incidente.
4. Gerenciadores de Incidentes
O Gerenciamento de Incidentes inclui o
tratamento de qualquer evento que possa
interferir no provimento dos serviços aos
usuários. Um incidente é definido como uma
interrupção não planejada ou diminuição da
qualidade de um serviço de TI (TAYLOR et. al,
p.82).
Este processo possui alta visibilidade para o
negócio e conseqüentemente torna-se mais fácil
demonstrar seu valor quando comparado a
outros processos pertencentes ao livro Operação
do Serviço. É por este motivo que o
Gerenciamento de Incidentes torna-se o primeiro
processo a ser implementado na maioria das
organizações. Várias empresas resolveram prédefinir um fluxo padrão para gerenciamento do
incidente.
Cada etapa deste fluxo é definida a seguir:
• Identificação: os incidentes poderão vir
através de relatórios gerados pelo
gerenciamento de eventos, de uma
ferramenta via web, através de um e-mail ou
chamada telefônica de um usuário via
Central de Serviços.
• Registro: os incidentes devem ser totalmente
descritos com data e hora incluídas.
• Categorização: identifica qual o tipo de
incidente.
• Priorização: reflete a urgência e o impacto
do incidente. Nesta etapa é identificado se o
incidente é grave.
Diagnóstico Inicial: neste estágio a
utilização da base de conhecimento pode ser
feita e pode existir necessidade de identificar
o erro juntamente com o usuário.
• Escalada: a escalada funcional ocorre
quando o suporte mais técnico é necessário.
A escalada hierárquica é feita quando níveis
gerenciais mais elevados são acionados. O
usuário é mantido informado sobre o status
do incidente pela CS.
• Investigação: através de uma investigação
cronológica da ordem dos eventos,
estabelece exatamente o que aconteceu de
errado.
• Resolução e Recuperação: quando uma
solução em potencial é encontrada ela deve
ser aplicada e testada. A aplicação da
resolução do incidente pode envolver
suporte ou grupos especializados.
• Fechamento: a CS deve checar se o
incidente foi completamente resolvido e
verificar se os usuários estão satisfeitos com
o atendimento e se aceitam que o incidente
possa ser fechado.
Este fluxo geralmente é adotado pelas
empresas para gestão dos incidentes.
Para realizar o cumprimento deste
gerenciamento, é vital que a equipe de TI esteja
munida com um software que registre os
incidentes.
Um programa pra esta finalidade traz para
organização vários benefícios para empresa e o
departamento de TI:
• Gerencia os incidentes, desta forma, cria um
histórico de todos os atendimentos
registrados;
• Direciona as demandas para os níveis
responsáveis pela resolução do incidente;
• Controla os tempos de resposta e resolução e
os compara com os SLA’s;
• Cria-se um banco de conhecimento;
• Melhora a eficiência do setor de TI e
conseqüentemente a satisfação do usuário;
• É possível agendar taregas;
• Registrar as tarefas que foram aprovadas
pelos gestores e superiores da organização.
Pode-se constatar que muitos são os
benéficos com a aquisição de um software para
gerenciamento de incidentes.
•
Antes de escolher o objeto de estudo deste
artigo, realizou-se uma pesquisa dos principais
softwares existentes no mercado. É necessário
destacar que estes programas estavam em
ambientes
de
produção
nas
diversas
organizações visitadas.
Para que seja iniciada a escolha da
ferramenta, é imprescindível que informações se
deseja extrair do software, pois no mercado
existem muitas ferramentas para serem
utilizadas e adquiridas, no entanto a escolha
certa é aquela que se adapta as necessidades da
organização e o quanto a mesma está
disponibilizando para custear a aquisição do
produto.
Com isso, comprar funções que a
organização não utilizará é simplesmente uma
forma de desperdiçar investimentos que
poderiam ser alocados para outras questões da
TI. Os pontos considerados para aquisição da
ferramenta foram os seguintes:
• Abertura de chamado via web;
• Integração com o e-mail;
• Detalhe dos registros de ocorrências;
• Catálogo de Serviços;
• Relatório de acompanhamento dos
incidentes;
• Facilidade de utilização;
• Base de conhecimento;
• Configuração de SLA.
Para cada item foram atribuídos pontos. Seus
valores correspondiam a 0,50 e 100. Por tanto,
caso a ferramenta pesquisada não suportasse o
item avaliado o valor 0 era atribuído, caso o item
fosse parcialmente suportado era atribuído o
valor 50 e caso atendesse totalmente era dado o
valor 100. O resultado geral está descrito na
Tabela 3.
No resultado total da pontuação, o software
Ocomon obteve o segundo lugar na tabela. A
diferença de pontos entre o primeiro e segundo
colocado não foi tão significativa, podendo
constatar que houve empate técnico, sendo
assim, o critério de “desempate foi o valor dos
custos que seriam empregados para aquisição e
implantação da ferramenta. Como o Ocomon é
uma ferramenta defendida pelos princípios
opensorce o valor para aquisição é zero.
Além do Ocomon, os seguintes softwares
foram avaliados: Service Desk Plus, 0800Net,
TraumaZero. O resultado geral está descrito na
Tabela 3.
Tabela 3 – Resultado da Pesquisa
•
5. Ocomon
O gerenciador de incidentes Ocomon foi
criado em Março de 2002 como projeto pessoal
do programador Franque Custódio, tendo como
finalidade realizar o controle de chamados para
equipe de TI do Centro Universitário La Salle
(UNILASALLE).
O Ocomon foi criado obedecendo aos
conceitos opensource, isto é, ele pode ser
copiado, estudado e redistribuído sem restrições.
Atualmente o sistema está na versão 2.0RC6.
5.1. Instalação e parametrização
Todos os conceitos anteriormente definidos
serão de extrema importância para que a
parametrização dos cadastros seja feita
atendendo a realidade da CS da organização que
o Ocomon será utilizado.
Foram utilizados os seguintes programas
para instalação do sistema no ambiente servidor:
• Sistema Operacional Linux Slackware
12.0;
• Servidor Web: Apache 2.2;
• Linguagem: PHP 5;
• Banco de dados: Mysql 4.1;
• Navegador: Firefox 3.5.
Após a instalação e configuração de todos os
aplicativos anteriormente citado. Realiza-se a
parametrização das políticas e processos
desenvolvidos no desenho do serviço. Através
do usuário admin o sistema será parametrizado
de acordo com os passos a seguir:
• Níveis de Suporte - os níveis de suporte
estão caracterizados no sistema como Áreas.
• Catálogos de Serviços e SLA - os serviços
presente no catálogo serão configurados no
menu de Problemas.
• Perfis de Abertura de Chamado - A
definição dos campos que serão utilizados
para abertura do chamado é de grande
importância, pois serão através deles que os
indicadores
de
desempenho
serão
determinados para definir qualidade e tempo
de atendimento.
Criação dos usuários - para finalizar a
parametrização do sistema é necessário que
sejam cadastrados os usuários dos analistas
da CS com os perfis definidos anteriormente.
5.2 Utilização
Como todos os parâmetros foram definidos
o Ocomon está em condições para ser utilizado
pelos usuários. Utilizando o fluxo de
atendimento descrito no gerenciamento de
incidentes.
O processo é iniciado pela abertura do
chamado, seja ele enviado por e-mail, solicitada
por telefone, pelo batepapo on-line ou pelo
próprio sistema.
Conclusões
É imprescindível que a área de TI, possua
um software para gerenciamento de incidentes.
Após uma analise de mercado, constatou-se que
uma ferramenta destacava-se. O aplicativo
Ocomon, atende aos requisitos necessários para
uma gestão de incidentes conforme a biblioteca
ITIL. Para a utilização da ferramenta é
necessário que toda a TI esteja alinhada com as
políticas de atendimento desenhada e que todas
as áreas estejam bem definidas e com suas
atribuições bem especificadas.
Referências
COHEN, Roberto. Implantação de Help Desk e
Service Desk. São Paulo. Novatec, 2008.
MAGALHAES, Ivan L.; PINHEIRO, Walfrido Brito.
Gerenciamento de Serviços de TI na Prática: Uma
abordagem com base na ITIL®. São Paulo. Novatec,
2007.
TAYLOR, Sharon et. al. Service Design. Lodon.
OGC, 2007.
CARVALHEIRA, R. Acordos de nível de serviço
(Service Level Agreements – SLAs), 2003.
Disponível em: http://student.dei.uc.pt/~rnuno/.
Acesso em: 13 abr. 2010, 03:01:00.
TAYLOR,Sharon et. al. Service Operation. Lodon.
OGC, 2007.