Gerencia de Serviços de TI

FACULDADES ASSOCIADAS DE SÃO PAULO
CURSO DE TECNOLOGIA EM INFORMATICA
GERENCIAMENTO DE SERVIÇOS
E CONTROLE DE FALHAS.
Gilliard Silva Delmiro – gillydickinson@gmail.com
Marcos de Benedicto – mbenedicto@gmail.com
SÃO PAULO
2006

RESUMO
Hoje em dia as empresas têm procurado excelência em serviços, como
existe um grande e rápido crescimento em empresas de telecomunicações foi
muito complicado adaptar a infra-estrutura e modificar o ambiente com a
velocidade em que o mercado exige.
É proposto neste projeto uma solução para integração de sistema e
direcionamento de esforços, apenas com a empresa sendo orientada ao
mesmo propósito é possível acompanhar o mercado e se manter com
qualidade. Diferente de demais propostas o que é sugerido neste projeto é que
para um crescimento com qualidade e excelência de serviços o primeiro passo
é organização interna e garantia de que no momento de alteração de infra-
estrutura a mesma seja encaixada nos processos e não o contrário.
Com as técnicas sugeridas é possível crescer o ambiente ou diminuir
mantendo a mesma qualidade de serviço, mantendo a relação entre áreas e
mantendo o conhecimento sempre ao alcance de todos.
2

PREFACIO
“Se minha teoria estiver certa, os suíços me chamarão de suíço, os alemães
me chamarão de alemão e os franceses me rotularão de grande cientista; se
minha teoria estiver errada os franceses me chamarão de suíço, os suíços me
chamarão de alemão e os alemães me acusarão de judeu”.- Albert Einstein
3

SUMÁRIO
Resumo........................................................................................................ 02
Prefácio........................................................................................................ 03
Sumário........................................................................................................ 04
Lista de Ilustrações..................................................................................... 05
Capitulo I – Introdução................................................................................ 06
1.1 Justificativa................................................................................... 07
Capitulo II – Revisão Bibliográfica............................................................ 09
2.1 Base de Conhecimento................................................................. 09
2.2 Banco de Dados Orientado a Objeto............................................ 09
2.3 Information Technology Infrastructure Library (ITIL)……………... 10
2.4 Configuration Management Data Base (CMDB)………………….. 11
2.5 Gerencia de Mudanças................................................................. 11
2.6 Change Management.................................................................... 12
2.7 Gerencia de Redes........................................................................ 12
2.8 Rede de Computador.................................................................... 13
2.9 Pooling........................................................................................... 13
2.10 Structured Query Language (SQL)……………………………….. 13
2.11 Interface……………………………………………………………… 14
2.12 Evento………………………………………………………………... 14
2.13 Management Information Base (MIB)......................................... 14
2.14 Sistema de Monitoração Nagios................................................. 15
2.15 Customer Relationship Management (CRM).............................. 15
2.16 Níveis de Escalonamento........................................................... 16
2.17 Network Operation Center (NOC)............................................... 16
2.18 Service Desk............................................................................... 17
Capitulo III – Gerenciamento...................................................................... 18
3.1 Estudo de Caso............................................................................ 18
3.2 Proposta........................................................................................ 20
3.3 Objetivos Gerais............................................................................ 22
3.4 Objetivos Específicos.................................................................... 22
3.5 Atividades de Pesquisa................................................................. 23
3.6 Execução...................................................................................... 25
3.7 Resultados Esperados.................................................................. 25
Capitulo IV – Conclusão.............................................................................. 28
Capitulo V – Referencia Bibliográfica........................................................ 29
4

LISTA DE ILUSTRAÇÕES
Figura 1 – Modelo Organizacional................................................................ 19
Figura 2 – Resultado proposto com o Modelo de Gerenciamento................ 19
Figura 3 – Modelo do Projeto Proposto......................................................... 21
Figura 4 – Relatório de Atendimento............................................................. 26
Figura 5 – Relatório de Disponibilidade......................................................... 27
5

CAPITULO I – INTRODUÇÃO
Com a atual demanda de tecnologia as redes de transmissão de dados
precisam evoluir quanto à qualidade e o gerenciamento de seus serviços, hoje
em dia a exigência de mercado obriga as empresas a acompanhar as
necessidades dos usuários.
“WIKIPEDIA (2006), a digitalização e a crescente integração e
diversificação dos serviços oferecidos, implicam numa maior
complexidade da rede e no aumento de capacidade dos equipamentos,
originando requisitos novos e mais complexos de gerência”. [1]
Estamos passando por uma fase em que as empresas se estabelecem
cada vez mais como provedores de serviços e as empresas que não se
adaptam a este novo conceito de atendimento e a demanda exigida pelos
usuários pode causar em certas situações um colapso ao negócio. Pensando
nesta demanda foi desenvolvido um projeto para garantir a qualidade na
solução de falhas relacionadas aos serviços de tecnologia. Além de garantir
controle do ambiente de rede o propósito deste projeto também é reduzir as
falhas e garantir que os serviços sejam restabelecidos no menor tempo
possível.
É muito comum que documentos e procedimentos não tenham um local
definido ou que áreas dentro da tecnologia da informação produzam
documentos independentes criando mais de uma solução para o mesmo tipo
de falha ou deixando o procedimento desatualizado no momento em que um
suporte o utiliza para solucionar uma falha.
6

1.1 JUSTIFICATIVA
Hoje vimos que a demora na solução de uma falha ocorre principalmente
por desconhecimento da estrutura de tecnologia, falta de informação
centralizada, falta de padrão de atendimento e por informações desatualizadas.
“INFOLAB, existe falta de qualidade e demora no atendimento e na
resolução de problemas; Reincidência de problemas; Descentralização
de informações; Ausência de sistema de controle; Desconhecimento do
perfil e problemas do cliente; Controle manual do hardware e software”. [2]
O gerenciamento de rede baseado na gestão de falhas deve ser um
material de consulta para todas as empresas que pretendem evoluir seu
padrão de atendimento. Em relação a pesquisas anteriores este é um material
que unifica as técnicas do ITIL (Information Technology Infrastructure Library)
com ferramentas de monitoração, gerenciamento de mudanças e atendimento
ao cliente.
A demora e falta de qualidade do atendimento normalmente são
representadas por falta de conhecimento, informações desatualizadas, falta de
um local para armazenar eventos mais comuns e problemas de comunicação
entre áreas dentro da empresa. O ITIL prevê um modelo de base de
conhecimento, mas alem das metodologias do ITIL este projeto define
interfaces que atualizam automaticamente o núcleo do sistema conhecido com
KDB (Knowledge Data Base), este banco de dados mais inteligente que o
CMDB tem interfaces com sistemas de CRM (Customer Relationship
Management), monitoração e gestão de mudanças. Diferente do CMDB este é
um banco alimentado por interfaces automatizadas o que garante a integridade
e qualidade dos dados. A idéia destas interfaces é ser o mais simples possível
a fim de serem operadas por técnicos com o mais básico conhecimento de
tecnologia. Todo o controle de inserção de dados é feito por regras comuns e
definidas por técnicos especializados, o que garante a operação do dia-a-dia
sem a necessidade de técnicos de alto nível para uma operação.
7

São incorporados sistemas de controle onde o inventário e a topologia
da rede sempre serão atualizados automaticamente e podem ser extraídos por
interface de relatórios. Com o KDB (Knowledge Data Base) é possível ter um
perfil do problema, do usuário, soluções anteriores e grupos solucionadores.
8

CAPITULO II – REVISÃO BIBLIOGRÁFICA
Antes de iniciar o estudo sobre gerenciamento de redes, faz-se
necessária à apresentação de alguns conceitos básicos relacionados ou tema
deste projeto, os quais servirão de base para a compreensão dos textos
descritos no documento. Tais conceitos são apresentados a seguir.
2.1 Base de Conhecimento
“PG SOFTWARE EUROPE (2005), a base de conhecimento atua como
uma mídia efetiva de compartilhamento do conhecimento, aumentando a
produtividade do suporte pelo alinhamento do conhecimento coletivo.
Isto também ajuda com a redução significativa do tempo médio para
solução de problemas, devido aos técnicos encontrarem respostas aos
problemas rapidamente.” [3]
A base de conhecimento funciona como uma fonte única de informação,
é um banco de dados que recebe informações de interfaces. A base de
conhecimento é um local que alem das informações dinâmicas sobre o
ambiente funciona como um local de pesquisa para feed-back de atendimento
e analise de qualidade de suporte de IT.
Neste projeto é proposto um banco chamado KDB (Knowledge Data
Base), é constituído por três principais interfaces com os sistemas de
monitoração, gerenciamento de mudanças e atendimento a cliente, estas
interfaces atualizam e consultam diretamente do KDB sem que seja necessária
uma intervenção no banco de dados. Diferente do CMDB no KDB não é
necessária intervenção no banco, ele deve servir de back-end e sua
atualização sempre devem ser feitos pelas interfaces.
O KDB é um CMDB dinâmico e orientado a objetos, existe uma quarta
interface que é a interface de relatórios onde é possível solicitar informação,
por exemplo, de uma localidade, basta solicitar "LOCAL_1" e lá dentro irão
9

aparecer todos os servidores, roteadores, switches e serviços. Com esta
interface garantimos um inventário sempre atualizado do sistema.
2.2 Banco de Dados Orientado a Objeto
“ESKELSEN (2005), Um banco realmente OO deve permitir que você
faça suas consultas de forma orientada a objetos, como se estivesse
pesquisando em uma Array, List ou qualquer outro container de objetos.”
[4]
Os Bancos de Dados Orientados são banco de dados que trabalham
com a referencia de Objetos e Classes uma das principais diferenças para os
Bancos de Dados relacionais é que não existem tabelas e sim classes onde
são criados objetos, as classes funcionam como mascaras onde são definidos
os campos globais para identificação de um grupo de objetos, os objetos é o
produto final do BDOO onde são grupados por classes e mantém seu perfil
original.
2.3 Information Technology Infrastructure Library (ITIL)
“GODOY (200-?), ITIL é um grande aparato das “Melhores Práticas”
utilizadas pelos grandes Gestores de TI documentadas em 7 livros,
subdividida em 10 processos e uma função e que tem objetivo fazer com
que a TI foque no Negócio da Empresa e para que entregue os seus
Serviços aos seus clientes da melhor maneira possível e a um custo
justificável.” [5]
O ITIL é uma biblioteca de melhores práticas, são idéias de como
organizar a área de IT, implantações, métodos de controle, etc. O ITIL ajuda a
criar um padrão entre as empresas de ITIL para que a linguagem de infra
estrutura seja comum a todas as empresas de IT.
10

2.4 Configuration Management Data Base (CMDB)
" CA (2006) ...CMDB apresenta uma visão unificada de todas as
informações dos itens de configuração, mapeando esses dados para os
serviços apropriados, simplifica e automatiza o gerenciamento de
mudanças e configurações e contribui para a disponibilidade dos
processos corporativos essenciais." [6]
“BMC (2005), o Configuration Management Database - CMDB é uma
idéia simples, mas de repercussões poderosas para o gerenciamento
corporativo.” [7]
O "Configuration Management Data Base" mais conhecido como CMDB
é um banco de dados proposto pela metodologia ITIL, este banco de dados
tem a responsabilidade de relacionar objetos, o que quer dizer isso, elementos
de redes a localidades, elementos de rede a grupos responsáveis, localidades
a equipamentos. Este banco de dados é à base de informações para
metodologia do ITIL, todas as informações do ambiente devem estar neste
banco que é considerado fonte única de informação. A diferença principal dele
para o KDB proposto no projeto são as interfaces entre sistema de monitoração
e gerenciamento de ambiente CRM e "Change Management", o KDB seria um
CMDB dinâmico. O grande problema do CMDB é a atualização, com este
projeto será proposta a solução.
2.5 Gerencia de Mudanças
"Para o Centro de Computação Eletrônica da USP, gerenciamento de
Mudanças é o processo de verificação e aprovação de pedidos de
mudança, e também a coordenação de mudanças aprovadas a serem
implementadas." [8]
11

O gerenciamento de mudança é uma proposta da metodologia de
melhores praticas do ITIL ela é responsável em colocar em questão as
mudanças no ambiente, analisa, valida e solicita aprovações do time de
liderança antes de serem implantadas. A ferramenta utilizada para este
gerenciamento é conhecida como “Change Management”.
2.6 Change Management
“De acordo com a Georgetown University, the complete set of processes
employed on a project to ensure that changes are implemented in a
visible, controlled and orderly fashion." [9]
O “Change Management” é uma ferramenta responsável em registrar
quais alterações estão sendo propostas ao ambiente e disponibilizar uma
interface para aprovação da mudança. Como o “Change Management” é
possível controlar melhora e divulgar quais as alterações propostas no
ambiente, com a aprovação é possível exigir testes para garantir que as
mudanças não causem impacto no ambiente produtivo.
2.7 Gerencia de Redes
“RNE (1997), ...as redes de computadores e os seus recursos
associados, alem das aplicações distribuídas, tem se tornado
fundamental e de tal importância para uma organização, que elas
basicamente "não podem falhar". [10]
Gerenciar uma rede é principalmente prevenir, identificar e corrigir falhas
antes que ocorra uma indisponibilidade dos serviços, alem de manter
estabilidade e performance de aplicações e serviços.
Existem diversas ferramentas para gerenciamento eficiente de uma rede
e diversos protocolos, o SNMP (Simple Network Management Protocol) é o
mais simples e um dos mais eficientes, a aplicação responsável pela
monitoração de rede proposta neste projeto utiliza o SNMP com um de seus
diversos protocolos de monitoração.
12

2.8 Rede de Computador
“RUSSEL (2002), se você simplesmente conecta quatro computadores
em casa, você tem o que é chamado de LAN (Local Area Network, ou
Rede Local). Se tudo está a uma caminhada de distância, então é
geralmente chamado de LAN, não importando quantas máquinas estão
conectadas, ou como você montou a rede.” [11]
Uma rede de computador é um conjunto de elementos computacionais
conectados por um meio comum, seja uma fibra óptica, fio de cobre ou até
mesmo a atmosfera, alem da conexão física é necessário que estes
computadores se comuniquem entre si por um protocolo comum. Atualmente o
protocolo mais utilizado é o TCP/IP.
2.9 Pooling
A informação que é útil para o monitoramento de rede é coletada e
armazenada pelos agentes, e disponibilizada para um ou muitos sistemas de
gerenciamento. Duas técnicas são usadas para disponibilizar a informação do
agente, que servirá para o gerenciamento: polling e comunicação de falhas.
Polling é uma interação de solicitações / respostas entre gerente e agente. O
gerente pode questionar qualquer agente (para o qual ele tem autorização) e
requisitar os valores de vários elementos de informação; os agentes
respondem com informações de sua MIB.
2.10 Structured Query Language (SQL)
"WIKIPEDIA (2006), Structured Query Language, ou Linguagem de
Consulta Estruturada ou SQL, é uma linguagem de pesquisa declarativa
para banco de dados relacional (bases de dados relacionais). Muitas
das características originais do SQL foram inspiradas na álgebra
relacional." [12]
13

O SQL é a linguagem mais comum para acesso a banco de dados, são
scripts de solicitação de informações de um banco de dados e emitem saida
para arquivos.
2.11 Interface
“WIKIPEDIA (2006), a interface possui implicitamente uma ligação com
as camadas de regras de negócio que verificam e validam o conteúdo
dos dados passados pela interface para, possivelmente, serem
persistidos na base de dados do sistema, ou seja, serem gravados no
banco de dados.." [13]
A interface gráfica tambem conhecida como GUI é uma tela grafica onde
serão feitas entradas de dados para inserção num banco de dados. A relação
entre aplicação e banco de dados tambem pode ser chamada de interface, por
exemplo, caso um sistema necessite de consulta em outros sistemas para
fazer inserção na base de conhecimento.
2.12 Evento
“PILEGGI (2002), nas aplicações de análise de risco, o evento inicial da
árvore de eventos é, em geral, a falha de um componente ou
subsistema, sendo os eventos subseqüentes determinados pelas
características do sistema”. [14]
Um evento no âmbito do projeto é uma alteração de estado de algum
elemento dentro de uma rede, quer dizer, o momento em que é registrada uma
falha ou uma recuperação de um elemento.
2.13 Management Information Base (MIB)
“UFRGS, ...a MIB (Management Information Base) é o conjunto dos
objetos gerenciados, que procura abranger todas as informações
14

necessárias para a gerência da rede, possibilitando assim, a
automatização de grande parte das tarefas de gerência..” [15].
A base de informação gerencial (MIB – Management Information Base) é
o nome conceitual para a informação de gerenciamento, incluindo os objetos
gerenciados e seus atributos, operações e notificações. Podem-se também
considerar as informações para a configuração do sistema como também
pertencentes a MIB.
2.14 Sistema de Monitoração Nagios
“Conforme REBELO, o Nagios é um aplicativo para monitoração de
serviços de rede, permite monitorizar vários serviços de rede e host para
ver se estão ativos,serviços como HTTP, SMTP, POP3,..." [16]
O sistema de monitoração Nagios é responsável por verificar a saúde da
rede, indicar falhas ou problemas de performance, neste projeto o Nagios alem
de fazer seu papel de monitoração de rede também faz interface com o KDB e
participa do sistema de gerenciamento de falhas como um braço muito
importante, alem do papel comum que seria notificar caso exista uma falha em
um elemento ou serviço de rede o Nagios também irá fazer inserção de dados
no KDB, dados que serão analisados pelo CRM e entrará no fluxo de
chamados do KDB, mais um ponto importante é que o Nagios pode servir de
referencia para futuras mudanças do ambiente, identificando quais pontos
sofrem falhas constantes.
2.15 Customer Relationship Management (CRM)
Para NAULT (2006) CEO da Atrion Networking Corporation, um sistema
de CRM deve assegurar a transição entre a implementação de IT e o
suporte ao produto: ”The project manager will clearly define this
transition and all the necessary steps to make it as smooth as possible.
Ongoing support used to mean "You have a problem, you call IT." It was
largely reactive.” [17]
15

O CRM é sistema utilizado para controle da qualidade dos sistemas
oferecidos pela área de IT, dentro do CRM é possível identificar chamados
relacionados à falhas num ambiente de rede, erros, problemas de performance,
preparar escalonamento e medir tempo de atendimento. Dentro do projeto
proposto o banco de dados do CRM é substituído pelo KDB onde estas
informações são compartilhadas não apenas com o CRM, mas com as outras
interfaces de implantação e monitoração.
2.16 Níveis de Escalonamento
Níveis de escalonamento são grupos separados por tarefas:
- o primeiro nível ou NOC normalmente são grupos que tem um turno
24x7, o primeiro nível é responsável em monitorar a rede verificar falhas
executar procedimentos de manutenção preventiva na rede e de tentar
solucionar 98% das falhas em menos de 30 minutos e 100% em 2 horas;
- o segundo nível é um grupo que tenta solucionar 95% dos problemas
em 2 horas após re-direcionamento do primeiro nível e 100% em 24 horas,
após a solução de uma falha os procedimentos são devidamente
documentadas na base de conhecimento (KDB), este grupo também é
responsável por identificar se um problema deve ser transferido ao terceiro
nível, para que seja feita uma alteração de infra-estrutura;
- o terceiro nível é responsável em programar uma alteração na infra-estrutura
e documentar devidamente a alteração na base de conhecimento (KDB).
2.17 Network Operation Center (NOC)
Para Indiana University (2001): “The NOC offers oversight of problem,
configuration and change management, network security, performance
and policy monitoring, reporting, quality assurance, scheduling, and
documentation. The NOC provides a structured environment that
16

effectively coordinates operational activities with all customers and
vendors related to the function of the network..” [18]
O NOC é a central de comando de uma rede, responsável em detectar
eventos, corrigir ou escalonar falha. O NOC também é responsável pelo
acompanhamento da solução dos eventos e pela garantia de que os eventos
sejam devidamente solucionados e documentados para futuras consultas.
2.18 Service Desk
“De acordo com a empresa Allen, o Service Desk é uma central que
oferece soluções para usuários finais, através de diferentes tipos de
canais de comunicação, integrada com um Sistema de Gerenciamento
de Chamados que possibilita estudos e manutenções pró-ativas.”. [19]
O Service Desk é um centro de suporte a clientes, diferente do antigo
Help Desk o Service Desk não se limita apenas a solucionar problemas de
operação de IT ele também responsável por infra-estrutura deste de uma
tomada até um servidor com defeito, podem agir em diversas áreas da
empresa o Service Desk é uma inovação descrita na metodologia de melhores
práticas do ITIL.
17

CAPITULO III – GERENCIAMENTO
3.1 Estudo de Caso
Este projeto foi incentivado para melhorar o gerenciamento de serviços
de uma empresa especifica que atua no mercado Internacional com sede em
Reston (VA) e filial no Brasil, Chile, Argentina, Peru e México. Um total de 2500
funcionários na filial Brasileira o principal ponto de estudo, tem uma média de
270 elementos de rede entre servidores UNIX, Windows e equipamentos de
rede, tem um parque de 40 lojas e 7 filiais espalhadas pelas regiões sul,
sudeste, norte e nordeste. Com uma média de 5000 chamados abertos no Help
Desk mensalmente, 87% são solucionados no primeiro nível e do restante 99%
são solucionados no segundo nível em até 2 dias, para um atendimento mais
eficiente pelo menos 98% dos eventos deveriam ser resolvidos em primeiro
nível e 100% em segundo nível, no formato em que esta alguns chamados
passam para terceiro nível.
A empresa é organizada por três gestões, desenvolvimento, tecnologia e
operações a área de operação é responsável e, manter a estrutura ativa, a
área de tecnologia é responsável por projetos e implantações e a área de
desenvolvimento pela fabrica de software. São aplicados alguns softwares para
gestão de aplicações como CRM, Controles de Acesso e Monitoração de
sistemas, mas até hoje sem uma devida integração. A empresa trabalha por
setores sem que exista uma relação de colaboração entre as áreas o que
causa um problema sério de comunicação e em algumas situações duplo ou
triplo suporte para o mesmo problema.
Pela organização é possível entender como problemas de comunicação
ocorrerem, a gerencia operacional não participa efetivamente da implantação
projetos, portanto a expertise da implantação fica em outra gerencia o que
dificulta a manutenção do dia-a-dia; As implantações não são orientadas ao
serviço, não é feita a devida avaliação da necessidade de uma implantação; As
ferramentas atuais não contribuem para que exista a devida passagem de
conhecimento entre as áreas, o que causa uma dispersão de conhecimento.
18

Na Figura 1 é possível ver como esta estruturada a organização da
entre, áreas de Gerencia de Operação, Gerencia de Tecnologia e Gerencia de
Desenvolvimento.
Figura 1 - Modelo organizacional
Este projeto se propõe a manter a esta estrutura organizacional e criar
interfaces entre as gerencias de operações e tecnologia através da
centralização do sistema e base de conhecimento. A seguir é demonstrado o
desenho proposto para solução do problema. Figura 2:
Figura 2 – Resultado proposto com Modelo de Gerenciamento
19

O sistema proposto se encaixa como uma central de troca de
informações, experiências e analise, assim é possível garantir que o
conhecimento é passado entre áreas indiferente das gerencias.
Este modelo de projeto foi estudado com base na empresa descrita mas
pode ser utilizado em qualquer área de IT com necessidade de melhorar a
comunicação entre as áreas operacionais e de implementação.
3.2 Proposta
A proposta deste projeto é diminuir o tempo de atendimento e garantir a
qualidade na solução e eventos, para isso o projeto se propões a criar um
banco de dados vivo onde serão inseridos informações das três interfaces
(Monitoração, CRM e Change Management) com este sistema será possível
acompanhar as atualizações do ambiente, controlar eventos de falha, controlar
níveis de serviços, garantir que dados sejam disponíveis a todos, melhor a
comunicação entre equipes e ganhar tempo na resolução de falhas, talvez até
prevenir futuros problemas.
Hoje não é comum que as empresas tenham um local único para
registrar e localizar informações relevantes ao serviço tecnológico, a idéia é
unificar documentos e procedimentos de uma forma dinâmica, localizar falhas
na topologia de rede e garantir fluxo correto de eventos, registrar alterações e
evoluções na topologia, manter ambiente de monitoração atualizado e garantir
a integridade nas informações com o mínimo de intervenção humana possível.
O modelo proposto é mais bem visualizado no desenho a seguir onde
podemos identificar quais serão as interfaces que se relacionaram com o banco
de dados, as entradas e saídas do sistema e a interface de relatórios, também
é demonstrado no desenho o atendimento por níveis de escalonamento.
20

Figura 3 – Modelo do Projeto Proposto
Serão utilizadas técnicas modificadas do modelo ITIL (Information
Technology Infrastructure Library) para automatização do sistema, será
utilizado um banco de dados modelo CMDB (Configuration Management Data
Base) com as devidas modificações para que exista uma iteração maior com as
ferramentas "satélites" como o Nagios (Ferramenta de Monitoração), o CRM
(Customer Relationship Management ) e o sistema de gerenciamento de
mudanças.
O banco de dados proposto no projeto o KDB (Knowledge Data Base)
deve ser o ponto principal de registro e localização de informações, deve ser
alimentado pelas interfaces de relacionamento com o cliente, monitoração e
gestão de mudanças. Com a unificação das informações é mais simples
encontrar a solução de problemas, proporem novas idéias e identificar
eventuais alterações no ambiente. Para garantir a integridade dos dados
apenas as interfaces serão responsáveis em inserir dados na base de
conhecimento, estas interfaces serão o CRM, o "Change Management" e o
21

"Nagios", estas interfaces são responsáveis principalmente em garantir que o
suporte de primeiro nível tenha a documentação necessária para resolver 99%
das falhas de rede.
Por um outro lado o suporte de segundo nível também é responsável por
falhas que não foram solucionadas no primeiro nível, caso seja uma falha que
não necessite de alteração na topologia deve ser solucionados e
documentados de forma sucinta no sistema de CRM para que as próximas
falhas relacionadas sejam identificadas facilmente, caso seja identificado que o
problema necessita de uma alteração na topologia a falha é encaminhada ao
terceiro nível responsável em programar uma mudança e documentar a
alteração no sistema de gerenciamento de mudanças antes da efetivação da
mesma, esta mudança deve passar por um comitê gestor que deve avaliar o
impacto e liberar a execução, após a conclusão da mudança o sistema
conhecido como “Change Management” deve atualizar o KDB.
3.2 Objetivos Gerais
Em relação a objetivos gerais, O projeto visa preparar um modelo de
fluxo de serviço que atua desde detecção de um evento seja manual ou
sistemica até o encerramento e registro do evento, gestão de mudanças e
atualização automática do ecosistema de TI, o maior ganho será no tempo de
resolução de um chamado, concentração de informação de atendimento num
local comum, prevenção do evento, atualização dinâmica de topologia lógica e
física e centralização em informações gerenciais.
3.3 Objetivos Específicos
No estudo de caso a empresa em questão tem diversos problemas
quando a divulgação e atualização de informações. Os eventos, tempo de
atendimento, relação entre sistemas (produção, desenvolvimento e teste)
topologia e monitoração não são dinâmicos nem dos conhecidos de todos os
analistas envolvidos no suporte. O objetivo é melhorar a produtividade,
melhorar o trabalho em equipe mesmo com gerencias diferentes, organizar as
22

informações e fornecer relatórios gerenciais para garantir qualidade dos
serviços IT.
3.5 Atividades de Pesquisa
Do modelo ITIL será pesquisado o CMDB pelos responsáveis pela
implementação e a melhor plataforma para implementação deste banco de
dados (KDB) tendo em vista que será um banco de dados orientado a objeto,
terá interface comum com sistemas de monitoração, "Change Management" e
CRM. A idéia é que os objetos dentro deste banco de dados sejam comuns a
todos os ambientes.
A segunda fase com um prazo de trinta dias é pesquisar a maneira de
criar uma interface simples para administração do KDB onde não seja
necessária uma intervenção via SQL para que sejam criados usuários para que
seja possível limpar tabelas e demais tarefas administrativas, esta pesquisa
deve ser feita por um programador com conhecimento de programação e
banco de dados, a idéia e fechar o acesso ao banco de dados e criar uma
forma simples onde um operador não precise necessariamente ter
conhecimento em programação ou banco de dados para operar a interface.
A terceira fase com um prazo de noventa dias para conclusão e dividida
em quatro partes de trinta dias cada uma, caso seja executada serialmente,
também deve ser executada por um programador conhecimento de banco de
dados será:
- Pesquisa de como estruturar uma interface do KDB com o sistema de
"Change Management" o qual será responsável em alterar, incluir ou deletar
toda a alteração da rede. Esta interface deve prever fazer relação com o banco
de dados e com o sistema de CRM, todas as alterações exigidas pelo CRM
devem ser aprovadas pelo time de liderança e quando executadas devem
alterar os objetos do banco de dados e da topologia.
23

- Pesquisa de como estruturar uma interface do KDB com o sistema de
CRM, o qual será responsável relacionar resoluções de eventos dentro do
KDB, registrar eventos direcionados ao segundo ou ao terceiro nível, bem
como registrar eventos identificados pelo sistema de monitoração ou eventos
relacionados e atendimentos a usuário. Esta interface sempre deve relacionar
um evento a um objeto e a um grupo no banco de dados, seja ele um servidor
de rede, um equipamento de rede ou um desktop.
- Pesquisa de uma interface do KDB com o sistema de monitoração, o
qual será responsável em testar, criar e remover eventos dentro do banco de
dados, neste momento será pesquisa uma forma do sistema de CRM ter uma
interface dinâmica para receber informações do sistema de monitoração.
- Pesquisa de uma interface com KDB para extração de relatórios, este
relatórios devem prever buscas por objetos, por exemplo, localidade, elemento
de rede, servidor ou grupo, esta pesquisa deve ser feita por um programador
com conhecimento em banco de dados.
A quarta fase com o prazo de trinta dias será a pesquisa por um
programador com conhecimento em banco de dados uma relação em que o
evento detectado pelo sistema de monitoração seja fechado pela interface do
CRM e sua resolução fique disponível no KDB para futuras consultas. A
interface deve atualizar o evento no banco de dados e relacionar o evento a
uma resolução. Este passo fecha o ciclo quando o evento estiver entre o
primeiro e o segundo nível.
Ultima fase com um prazo de 40 dias, neste ultimo passo será
pesquisado por um especialista de programação e banco de dados uma
relação em que se fecha o ciclo do sistema quando o evento passar para o
terceiro nível, a interface irá relacionar o evento de alteração da infra-estrutura
ao sistema de "Change Management" e descrever a alteração no KDB onde
este irá alterar os objetos e topologia de acordo com informação passadas pela
interface.
24

Com o resultado das pesquisas acima descritas o projeto esta pronto
para ser iniciado, os documentos gerados devem ser guardados como
documentação e como referencia para construção do modelo.
3.5 Execução
Para implantação do projeto de gerenciamento de serviços é sugerido
que o inicio seja pela estrutura do banco de dados, onde serão criadas classes
comuns entre os ambientes, após a estrutura do banco de dados é importante
que o CRM seja o primeiro a atualizar os dados deste banco de dados, logo
após o sistema de “Change Management” e depois o sistema de Monitoração.
É importante frisar que este ultimo, o sistema de monitoração receberá
atualização do banco de dados KDB, portanto no momento em que for feita
esta interface e banco deve estar atualizado em relação as demais interfaces.
3.6 Resultado Esperado
A conclusão da implantação deste projeto ocorre no momento em que
não será mais necessária nenhuma intervenção manual no banco de dados e
quando as interfaces enviarem e receberem informações do KDB, o sistema de
monitoração deve se atualizar automaticamente de acordo com
implementações pelo “Change Management”, o CRM deve receber alem das
solicitações de suporte por telefone informações do sistema de monitoração, o
segundo nível deve enviar solicitações de alteração de infra-estrutura ao
terceiro nível e todos os atendimentos e escalonamentos devem ser
registrados no KDB para geração de relatórios gerenciais.
Com a consolidação das interfaces e centralização da topologia é mais
simples minimizar eventuais alterações tecnológicas que o ambiente venha a
sofrer, com o controle e analise das falhas é possível eliminar ou diminuir o
tempo de recuperação e garantir a saúde dos serviços da rede.
Com a centralização destas informações de suporte é possível diminuir o
problema de comunicação entre as gerencias e garantir um suporte mais
25

eficiente. É possível analisar eventos para que não exista uma nova ocorrência,
ter todas as informações relativas às operações de IT da empresa em apenas
um local sendo possível à relação entre os objetos para definição de
estratégias de implantação e suporte.
Na Figura 4 é apresentado um relatório sobre os atendimentos atuais do
Help Desk, este relatório será a ferramenta para controle do projeto. Os
números de atendimento devem diminuir e a porcentagem dos valores de
atendimento de primeiro nível devem aumentar, com estes indicadores será
possível avaliar e controlar o desempenho do projeto.
Figura 4 – Relatório de Atendimento
Na Figura 5 é apresentado um relatório sobre a disponibilidade de aplicações,
para o controle do projeto a disponibilidade deve ficar sempre acima de
99,95%, assim garantimos que os serviços oferecidos por IT estão de acordo
com as expectativas dos clientes e com valores contratados em SLA. No
relatório são apresentados os dez principais ofensores e a disponibilidade, este
relatório é mensal e divulgado a toda a área de IT e seus clientes.
26

Figura 5 – Relatório de Disponibilidade
27

CAPITULO IV – CONCLUSÃO
Com este projeto concluímos que para um eficiente, consistente e
constante atendimento de suporte a informação deve ser precisa e estar
centralizada. Como a grande maioria das empresas esta sempre em expansão,
os ambientes são vivos e constantemente alterados tornando muito difícil
conseguir manter a qualidade das informações para um suporte eficiente. O
modelo adotado no projeto se molda a uma gerencia orientada a qualidade do
serviço. O núcleo do projeto, um banco de dados com múltiplas entradas e
saídas de dados consolida a informação garantindo que em qualquer condição
de implantação, correção ou suporte a integridade da informação seja
garantida.
Foram pesquisadas ferramentas de monitoração, atendimento a cliente e
gestão de mudanças, todos os sistemas que podem ter uma saída de dados
adaptada ao banco de dados, assim indiferente da fonte a informação sempre
deve se adaptar ao modelo, o que garante que todas as áreas envolvidas
possam guardar ou consultar informação de uma maneira comum a todos.
Mais uma vantagem neste modelo proposto é que não são exigidas
ferramentas para o projeto, pode ser modelado com ferramentas freeware e
implementado apenas com custo de mão de obra.
Concluímos que pela relação custo por beneficio é o melhor modelo para
empresas que estão constantemente em expansão e querem garantir a
automatização e qualidade no atendimento de seus clientes.
28

CAPITULO V – REVISÃO BIBLIOGRÁFIA
[1] Wikipedia, Outubro/2006. Principio da Gerência de Redes. Documento
digital HTML disponível em <http://pt.wikipedia.org/wiki/Princ
%C3%ADpios_da_Ger%C3%AAncia_de_Redes>. Acesso em
Setembro/2006.
[2] InfoLab, Help Desk. Documento digital HTML disponível em
<http://www.infolab.com.br/helpdeskweb/index.html>. Acesso em
Setembro/2006.
[3] PG Software Europe. Base de Conhecimento. Documento digital
disponível em
<http://www.opmanager.com.pt/opmanager/knowledgebase-with-
opmanager.html> Acesso em Novembro/ 2006
[4] Eskelsen, Cássio, Dezembro/2005. db4o - Banco de Dados Orientado
a Objetos. Documento digital disponível em <
http://www.linhadecodigo.com.br/artigos.asp?id_ac=875&pag=1>
. Acesso em Novembro/2006
[5] Godoy, Leandro. ITIL - Information Technology Infrasctructure
Library. Documento digital HTML disponível em
<http://www.blogmind.com.br/archives/11/itil-o-que-e-isso-e-para-que-
serve/96> . Acesso em Novembro/2006.
[6] CA ISLANDIA, N.Y., Julho/2006. CMDB - ITIL. Documento digital HTML
disponível em <http://www.ca.com/br/cainf02.htm>. Acesso em
Setembro/2006.
[7] BMC, Network Magazine, Maio/2005. CMDB - Configuration
Management Data Base. Documento digital PDF disponível em
<http://www.cscbrasil.com.br/folhetos/2005/Lamina_BMC
%20Atrium_premio.pdf> Acesso em Outubro/2006
[8] USP, Centro de Computação e Eletrônica, Fevereiro/2005. ITIL -
Gerência de Mudanças. Documento digital MS PowerPoint disponível
em
<http://www.usp.br/cce/qualidade/downloads/IIIEncontroGerentes_parteII
.pdf?PHPSESSID=44c0d105c0a32feb8e44400c785a94fe#search=
%22gerencia%20de%20mudan%C3%A7as%22>. Acesso em
Setembro/2006.
[9] Georgetown University, University Information Services UIS. Change
Management. Documento digital HTML disponível em
<http://uis.georgetown.edu/departments/eets/dw/GLOSSARY0816.html>.
Acesso em Setembro/2006.
29

[10] NewsGeneration, RNP–Rede Nacional de Ensino e Pesquisa
Agosto/1997 Gerencimento de Rede Documento digital HTML
disponível em <http://www.rnp.br/newsgen/9708/n3-2.html>. Acesso em
Outubro/2006
[11] Russel, Rusty, Agosto/2002 Redes de Computadores. Documento
digital HMTL disponível em <http://br.geocities.com/cesarakg/conceitos-
rede-HOWTO-2.html>. Acesso em Outubro/2006
[12] Wikipedia, Novembro/2006. SQL - Structured Query Language.
Documento digital HTML disponível em
<http://pt.wikipedia.org/wiki/SQL>. Acesso em Setembro/2006.
[13] Wikipedia, Novembro/2006. Interface. Documento digital HTML
disponível em <http://pt.wikipedia.org/wiki/Interface>. Acesso em
Setembro/2006.
[14] Pileggi, Valneo, Outubro/2002. Técnicas de Analise de Eventos.
Documento digital no formato MS Word disponível em
<http://professores.unisanta.br/valneo/apoio/tecnicasdeanalisederisco.do
c>. Acesso em Setembro/2006.
[15] Otsuka, Joice Lee UFRGS, de BRISA. Makron Books do Brasil, 1993
Gerenciamento de Redes- Uma abordagem de Sistemas Abertos.
Documento digital HTML disponível em
<http://penta.ufrgs.br/gr952/trab1/2conceit.html>. Acesso em
Outubro/2006
[16] Rebelo, João . Nagios. Documento digital HTML disponível em
<http://linuxeiros.planetaclix.pt/software/nagios.html>. Acesso em
Setembro/2006.
[17] Nault, Charles, October/2006. CRM Customer Relationship
Management. Documento digital em
<http://www.destinationcrm.com/articles/default.asp?ArticleID=6361>.
Acesso em Novembro/2006
[18] Indiana University, March/2001. NOC - Network Operation Center.
Documento digital HTML disponível em <
http://www.indiana.edu/~uits/telecom/noc/index.html>. Acesso em
Novembro/2006.
[19] Allen Informática. Service Desk. Documento digital disponível em
<http://www.allen.com.br/faq.asp?fase=resp&id=3&fid=11> Acesso em
Outubro/2006
30

Gerencia de Serviços de TI

Mais conteúdo relacionado

Semelhante a Gerencia de Serviços de TI

Mais de Ohio University

Gerencia de Serviços de TI