GERÊNCIA DE INCIDENTES UTILIZANDO UMA APLICAÇÃO OPEN SOURCE SEGUINDO AS BOAS PRÁTICAS DA BIBLIOTECA ITIL V3 Paulo H. da Silva Franco 1, Francisco J. A. de Aquino 2 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ção 1 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: paulohenriquefranco@gmail.com. 2 Francisco J. A. de Aquino é professor no IFCE. E-mail: fcoalves_aq@ifce.edu.br. 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 plenamente as necessidades do negócio. 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.