View
3
Download
0
Category
Preview:
Citation preview
Concepcao de uma Plataforma de Gestao Integrada
para Sistemas de Suporte a Computacao Distribuıda
Sara Filipa Coutinho Barbas Valente(Licenciada)
Dissertacao para obtencao do Grau de Mestre emEngenharia Informatica e de Computadores
Juri
Presidente: Professor Doutor Jose Carlos Alves Pereira MonteiroOrientador: Professor Doutor Jose Luıs Brinquete BorbinhaOrientador: Professor Doutor Miguel Leitao Bignolas Mira da SilvaVogal: Professor Doutor Andre Ferreira Ferrao Couto e Vasconcelos
Novembro 2011
Agradecimentos
Em primeiro lugar agradeco aos meus orientadores, Goncalo Borges, Prof. Jose Borbinha e Prof.
Miguel Mira da Silva pela sua orientacao, apoio e disponibilidade durante este ultimo ano.
Gostaria tambem de agradecer ao LIP, em especial ao Prof. Mario Pimenta, a hipotese de
continuar a minha formacao.
Agradeco aos meus amigos Rodolfo, Daniel e Alberto a ajuda prestada.
Por fim um agradecimento muito especial a minha mae e ao Luıs Miguel pelo seu apoio
incondicional.
i
ii
Resumo
Actualmente gerir uma empresa ou instituicao seria impossıvel sem utilizar Tecnologias de In-
formacao. Fornecer servicos de qualidade que permitem ao utilizador uma solucao facil e trans-
parente no manuseamento da informacao e uma tarefa ardua para quem os providencia. E neste
domınio de elevada complexidade que a framework ITIL pode ajudar a encontrar solucoes capa-
zes de melhorar praticas na gestao, integracao e manipulacao da informacao. A framework ITIL
foca-se em descrever ”O QUE FAZER”e nao ”COMO FAZER”, explicando em detalhe todos os
processos mas nao indica como devem ser implementados.
Neste documento propusemos implementar os processos de Gestao de Configuracoes e Gestao
de Alteracoes considerados prioritarios para suportar as operacoes diarias decorrentes da gestao
da infra-estrutura de uma organizacao. Utilizando o metodo Action Research, esta tese foi
aplicada numa associacao cientıfica e tecnica de utilidade publica cujos projectos de investigacao,
desenvolvimento e implementacao sao centrados sobretudo no domınio das infra-estruturas de
computacao distribuıda e computacao grid.
Foi construıdo um sistema prototipo, sendo possıvel efectuar alteracoes relativas a infra-
estrutura de hardware de forma mais rapida, onde cada interveniente no fluxo de trabalho
conhece qual o estado da tarefa a realizar e existindo a garantia que no final da alteracao, essa
informacao e registada na CMDB de forma correcta e actualizada.
iii
iv
Abstract
Currently managing an enterprise or institution would be impossible without the use of In-
formation Technology. Providing quality services that allow the user an easy and transparent
handling of information is a daunting task for anyone who provides it. ITIL is a framework that
can help to provide solutions that improve practice management, integration and manipulation
of information. ITIL describes ”WHAT TO DO”and not ”HOW TO DO”, explaining in detail
all the processes but does not indicate how they should be implemented.
In this document we proposed to implement Change Management and Configuration Ma-
nagement processes considered to be a priority to support the daily management operations of
an organization.
Using Action Research Method, this thesis was applied to a scientific and technical associ-
ation of public utility whose research, development and implementation is also focused in the
field of managing a distributed computing infrastructure.
A prototype system was built, and now is possible to make faster changes on the hardware
infrastructure. There is also the guarantee that, by the end of the change, this information is
recorded in the CMDB correctly and updated.
v
vi
Palavras Chave
Keywords
Palavras Chave
ITIL
Implementacao ITIL
Gestao de Alteracoes
Gestao de Configuracoes
CMDB
Open Source
Keywords
ITIL
ITIL Implementation
Change Management
Configuration Management
CMDB
Open Source
vii
viii
Acronimos
AUGER The Pierre Auger Cosmic Ray Observatory
CC Centro de Calculo
CCTA Central Computer and Telecommunications Agency
CERN Organizacao Europeia para a Pesquisa Nuclear
CMDB Configuration Management Database
EGI European Grid Initiative
ESA Agencia Espacial Europeia
EXIN Netherlands IT Examinations Institute
FCCN Fundacao para a Computacao Cientıfica Nacional
GA Gestao de Alteracoes
GC Gestao de Configuracoes
IC Item de Configuracao
INGRID Iniciativa Nacional Grid
ITIL Information Technology Infrastructure Library
KPI Indicador Chave de Desempenho
LIP Laboratorio de Instrumentacao e Fısica Experimental de Partıculas
NASA National Aeronautics and Space Administration
RfC Request for Change
RT Request Tracker
SNOLAB Sudbury Neutrino Observatory Laboratory
TI Tecnologias de Informacao
ix
x
Indice
1 Introducao 1
1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Questoes de Investigacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Metodo de Investigacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Estrutura da Tese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Trabalho Relacionado 7
2.1 Gestao da Infra-estrutura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Gestao e Operacao da Infra-Estrutura de Rede . . . . . . . . . . . . . . . 7
2.1.2 Gestao e Operacao da Infra-Estrutura de Servicos Computacionais . . . . 10
2.1.2.1 Aplicacoes para Gestao de Desempenho . . . . . . . . . . . . . . 10
2.1.2.2 Produtos para Gestao de Eventos . . . . . . . . . . . . . . . . . 10
2.2 ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Areas Relevantes para a Gestao de um Centro de Calculo . . . . . . . . . 13
2.2.1.1 Suporte aos Servicos . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1.2 Benefıcios Resultantes do ITIL . . . . . . . . . . . . . . . . . . . 15
2.2.2 Gestao de Configuracoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Gestao de Alteracoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Suporte a Gestao de Processos ITIL . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3.1 Software para Gestao de Configuracoes . . . . . . . . . . . . . . . . . . . . 24
2.3.2 Software para Gestao de Alteracoes . . . . . . . . . . . . . . . . . . . . . 26
3 Problema 29
3.1 Contextualizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Causas e Problemas Principais nos Procedimentos do LIP . . . . . . . . . . . . . 30
3.3 Coleccao e Caracterizacao de Requisitos . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.1 Requisitos de Negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.2 Requisitos Nao Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.3 Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
xi
xii INDICE
4 Proposta 33
4.1 Sistema da Gestao de Alteracoes . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.1 Modelo de Actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.2 Estados das Alteracoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1.3 Categorias de Alteracoes e Criterios de Avaliacao . . . . . . . . . . . . . . 36
4.1.4 Identificacao de Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Sistema de Gestao de Configuracoes . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.1 Modelo de Actividades - Planeamento . . . . . . . . . . . . . . . . . . . . 41
4.2.1.1 Definicao dos Itens de Configuracao . . . . . . . . . . . . . . . . 41
4.2.1.2 Modelo da CMDB e Fluxo Operacional de Implementacao . . . 41
4.2.2 Modelo de Actividades - Identificacao . . . . . . . . . . . . . . . . . . . . 42
4.2.3 Modelo de Actividades - Especificacao . . . . . . . . . . . . . . . . . . . . 44
4.2.4 Modelo de Actividades - Controlo da Configuracao . . . . . . . . . . . . . 46
4.2.5 Modelo de Actividades - Auditoria e Verificacao . . . . . . . . . . . . . . 47
4.2.6 Identificacao de Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . 47
5 Concretizacao da Solucao 49
5.1 Request Tracker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.1 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.1.2 Modelo Logico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.1.3 Razoes da Adopcao do Request Tracker . . . . . . . . . . . . . . . . . . . 52
5.1.4 Configuracao do Request Tracker . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.4.1 Ticket Actuando como RfC . . . . . . . . . . . . . . . . . . . . . 54
5.1.4.2 Fluxo de Tarefas (Workflows) . . . . . . . . . . . . . . . . . . . 56
5.1.4.3 Ciclo de Vida de um Ticket . . . . . . . . . . . . . . . . . . . . 57
5.1.4.4 Insercao das Alteracoes na Gestao de Configuracoes . . . . . . . 62
5.2 Zenoss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2.1 Monitorizacao Orientada ao Modelo de Configuracao . . . . . . . . . . . . 62
5.2.2 Principais Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2.3 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.2.4 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2.5 Razoes da Adopcao do Zenoss . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2.6 O Zenoss como Gestor de Configuracoes no LIP . . . . . . . . . . . . . . . 68
5.2.7 Modelo de Actividades do Processo de GC e sua Concretizacao no Zenoss 68
6 Avaliacao 71
7 Conclusao 77
7.1 Trabalho a Desenvolver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
INDICE xiii
Bibliografia 79
A Simbologia Utilizada nos Diagramas do Processo da Gestao de Configuracoes 85
B Descricao dos Principais Casos de Uso do Sistema de Gestao de Alteracoes 87
C Descricao dos Principais Casos de Uso do Sistema de Gestao de Configuracoes 91
D Modelo Logico do Request Tracker 93
E Request Tracker Ticket Template 95
F Scrips Configurados no Request Tracker 97
G Estrutura do Ficheiro XML Gerado pelo Processo de Gestao de Alteracoes 99
xiv INDICE
Lista de Figuras
1.1 Fases da Investigacao-Accao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Exemplo de Ferramentas de Monitorizacao, Alerta e Reaccao para Varios Recur-sos e Servicos de um CC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Quadrante Magico que Permite Avaliar um Fabricante de Produtos APM [14]. . 11
2.3 Quadrante Magico de Produtos ECA [15]. . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Estrutura da Framework ITIL (ITIL V2) [11]. . . . . . . . . . . . . . . . . . . . . 13
2.5 Modelo de Suporte aos Servicos (ITIL V2) [11]. . . . . . . . . . . . . . . . . . . . 14
2.6 Gestao das Alteracoes e Outros Processos ITIL [14] . . . . . . . . . . . . . . . . . 19
2.7 Processo da Gestao de Alteracoes . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.8 Estados de um RfC [15] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9 Software para Gestao de Configuracoes [17]. . . . . . . . . . . . . . . . . . . . . . 25
2.10 Avaliacao do Software para Gestao de Configuracoes [17]. . . . . . . . . . . . . . 25
2.11 Avaliacao do Software para Gestao de Alteracoes [17]. . . . . . . . . . . . . . . . 27
4.1 Processo de Gestao de Alteracoes Adoptado. . . . . . . . . . . . . . . . . . . . . 34
4.2 Diagrama de Estados de uma Alteracao. . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 Casos de Uso do Sistema de Gestao de Alteracoes. . . . . . . . . . . . . . . . . . 39
4.4 Fases do Processo de GC, Proposto para o LIP. . . . . . . . . . . . . . . . . . . . 40
4.5 Fase de Planeamento da Configuracao Proposta para o LIP. . . . . . . . . . . . . 41
4.6 Diagrama Entidade-Relacao (ER) Ilustrando um Esquema de Definicao dos ICna CMDB Proposto por Baron et al.[28] . . . . . . . . . . . . . . . . . . . . . . . 43
4.7 Fase de Identificacao da Configuracao Proposta para o LIP. . . . . . . . . . . . . 44
4.8 Fase de Especificacao da Configuracao. . . . . . . . . . . . . . . . . . . . . . . . . 45
4.9 Fase de Controlo da Configuracao Proposta para o LIP. . . . . . . . . . . . . . . 46
4.10 Fase de Auditoria da Configuracao Proposta para o LIP. . . . . . . . . . . . . . . 47
4.11 Casos de Uso do Sistema de Gestao de Configuracoes . . . . . . . . . . . . . . . . 48
5.1 Arquitectura do RT [29]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2 Modelo Logico do RT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
xv
xvi LISTA DE FIGURAS
5.3 Numero e Estado de Tickets Existentes na Fila Hardware Change Request Criadosa Partir de 13 Janeiro de 2011. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4 Template de um Ticket no RT Configurado para Efectuar uma Alteracao. . . . . 57
5.5 Ciclo de Vida um Ticket no RT - Parte 1 . . . . . . . . . . . . . . . . . . . . . . 59
5.6 Ciclo de Vida um Ticket no RT - Parte 2 . . . . . . . . . . . . . . . . . . . . . . 60
5.7 Ciclo de Vida um Ticket no RT - Parte 3 . . . . . . . . . . . . . . . . . . . . . . 61
5.8 Vista de Alto Nıvel do Zenoss [34]. . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.9 Workflow: Monitorizacao Orientada ao Modelo de Configuracao [34]. . . . . . . . 63
5.10 Mapa de Rede. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.11 Arquitectura em Camadas do Zenoss. . . . . . . . . . . . . . . . . . . . . . . . . 65
5.12 Modelo de Domınio do Zenoss. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.13 Graficos de Desempenho Disponibilizados pelo Zenoss. . . . . . . . . . . . . . . . 70
B.1 Casos de Uso do Sistema de Gestao de Alteracoes . . . . . . . . . . . . . . . . . . 90
C.1 Casos de Uso do Sistema de Gestao de Configuracoes . . . . . . . . . . . . . . . . 92
Lista de Tabelas
2.1 KPIs para os Processos da GA e Gestao da Release [25]. . . . . . . . . . . . . . . 23
4.1 Criterios para Categorizacao de Alteracoes: A = Alteracao Principal, B = Al-teracao Significante, C = Alteracao Menor. . . . . . . . . . . . . . . . . . . . . . 37
4.2 Perıodo de Execucao para as Diferentes Categorias de Alteracoes . . . . . . . . . 37
4.3 Tipos de ICs definidos para o LIP e seus atributos. . . . . . . . . . . . . . . . . . 42
5.1 Relacao entre Pedido de Alteracao e Ticket. . . . . . . . . . . . . . . . . . . . . . 54
6.1 As Caracterısticas do RT Permitem Satisfazer os Requisitos de Negocio, Funcio-nais e Nao Funcionais estabelecidos. . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.2 As Caracterısticas do Zenoss Permitem Satisfazer os Requisitos de Negocio, Fun-cionais e Nao Funcionais estabelecidos . . . . . . . . . . . . . . . . . . . . . . . . 74
xvii
xviii LISTA DE TABELAS
Capıtulo 1
Introducao
1.1 Motivacao
A Internet e cada vez mais um veıculo privilegiado para a partilha e processamento de in-
formacao a escala global. Os problemas com que a ciencia moderna se depara sao de uma tal
complexidade, que requerem grande tempo de calculo, e geram um tal volume de dados que
se tornam incomportaveis de resolver em tempo util sem que se recorra a mecanismos de cola-
boracao globais. Algumas das grandes comunidades cientıficas actuais tais como o CERN e a
NASA foram as principais impulsionadoras de solucoes de computacao distribuıda destinadas
a resolver problemas de grande dimensao, organizando-se de forma a partilharem os recursos
computacionais de varias instituicoes atraves da Internet.
Alem da comunidade cientıfica tambem empresas grandes e influentes, como a Google, a
Amazon e a e-Bay, exploram ja modelos de computacao distribuıda e comecam a disponibilizar,
sob a forma de servicos acessıveis remotamente, a possibilidade de um utilizador requisitar tempo
de computacao ou espaco de armazenamento para as suas aplicacoes.
E hoje possıvel, para um utilizador, recorrer aos dois paradigmas de computacao distribuıda,
Grid Computing [1] [2] e Cloud Computing [3], e usufruir de grandes capacidades de armazena-
mento e processamento, de forma simples e transparente. O utilizador pode ainda ter acesso e
manobrar remotamente instrumentos cientıficos de grandes dimensoes sem ter que assegurar a
gestao e a manutencao dos mesmos. No entanto, a disponibilizacao de grandes infra-estruturas
de computacao distribuıda exige a operacao de uma vasta gama de recursos e servicos complexos.
Com a adopcao da computacao distribuıda, quer pelas empresas quer pelos investigadores,
muitos Centros de Calculo (CC) veem-se agora acrescidos de uma maior complexidade e res-
ponsabilidade. Para alem da gestao local das suas infra-estruturas, sao tambem parte de redes
mais abrangentes que podem ser privadas, nacionais ou mesmo globais. Neste contexto, sao
responsaveis pela gestao do equipamento (fısico e virtual) e pelos servicos que podem ser usados
1
2 CAPITULO 1. INTRODUCAO
por vastas comunidades de utilizadores, e que devem ser permanentemente monitorizados de
forma a garantir a qualidade de servico requerida pelos clientes da infra-estrutura.
A operacao e o controlo de um parque de equipamentos tao vasto e diverso como o existente
em qualquer CC actual e de extrema complexidade, dado o vasto numero de ferramentas, de
plataformas e de hierarquias entre recursos. Consequentemente, para diminuir o esforco de
operacao, e necessario compreender todos os componentes de um CC, por forma a identificar
onde e como se podem optimizar recursos.
Um CC e um espaco fısico que aloja varias componentes informaticas, e componentes nao
informaticas. Alem dos sistemas que possibilitam o servico prestado aos utilizadores (com-
ponentes informaticas), existem servicos que asseguram que todo o equipamento funciona de
forma correcta e num ambiente adequado (componentes nao informaticas). Ou seja, aos desafios
tecnicos e heterogeneos, ocorrentes na gestao dos variados servicos computacionais, prestados
pelo CC, outros desafios sao importantes: a adequada alocacao do espaco e dos equipamentos,
a monitorizacao das condicoes ambientais, a vigilancia do espaco, bem como a manutencao dos
equipamentos sao procedimentos de operacao tao validos como a operacao dos servicos para a
comunidade, e requerem a gestao de procedimentos de forma rapida e eficaz.
Os dispositivos da rede (ex: routers, hubs, switchers, etc) devem manter-se operacionais.
Tambem neste domınio ferramentas de monitorizacao sao utilizadas para detectar e produzir
alarmes de forma que a equipa tecnica possa ser notificada caso alguma anomalia na rede ocorra.
A monitorizacao do trafego de rede e tambem necessaria por uma questao de seguranca nas
organizacoes actuais. As organizacoes sofrem ataques aos seus dados e aos seus equipamentos,
a maioria deles atraves da rede. Monitorizar o trafego na rede e uma das preocupacoes de quem
gere um CC, que para alem da vertente de seguranca, pretende tambem controlar os gastos
economicos.
As infra-estruturas fısica e de rede de um CC servem o proposito de fornecer servicos aos
utilizadores. Alguns servicos sao transversais a qualquer tipo de organizacao, seja ela de grande,
media ou pequena dimensao. Exemplos desses servicos sao o DNS, o correio electronico, os
servicos web, os servicos de autenticacao, os servicos de bases de dados ou servicos de repositorios,
e cujo mau funcionamento poe em risco todas as camadas de servicos superiores tais como os de
computacao, de armazenamento e outros.
E neste domınio de elevada complexidade que e o da gestao de um CC, que surge a framework
ITIL (Information Technology Infrastructure Library Versao 2) [4] [5] [6] [7] [8] [9] frequentemente
referenciada como sendo o manual de boas praticas na gestao, integracao e manipulacao da
informacao gerada num CC.
O ITIL Versao 2 e uma compilacao vasta, organizada em diversas areas, sendo a area do
Suporte aos Servicos, que trata dos processos necessarios a manutencao das operacoes diarias,
a primeira que deve ser concretizada. Desta area fazem parte dois processos intrinsecamente
1.2. QUESTOES DE INVESTIGACAO 3
ligados: Gestao de Alteracoes e Gestao de Configuracao, tornando-se imprescindıvel relaciona-
los. A CMDB (Configuration Management Database) e um repositorio dos dados relacionados
com todas as componentes do sistema de informacao de uma empresa/instituicao e e uma parte
fulcral do processo de Gestao de Configuracoes.
1.2 Questoes de Investigacao
O proposito desta tese e compreender como se efectua a Gestao da Infra-estrutura Fısica e
de Rede de um CC: quais os processos envolvidos, quais sao prioritarios, quem sao as pessoas
responsaveis pela execucao de tarefas, como sao executadas essas tarefas e quais os recursos
envolvidos.
Faz parte ainda do ambito desta tese compreender que ferramentas existem no mercado e
de que forma conseguem automatizar e concretizar os processos encontrados.
Em suma, esta tese tem que averiguar como se pode efectuar uma alteracao numa instituicao
e como esta alteracao afecta os recursos existentes.
Em suma o objectivo e encontrar uma resposta para as seguintes questoes:
1. Questao 1: Como desenhar o processo de Gestao de Alteracoes para permitir, de uma
forma comum e coerente, gerir as alteracoes na infra-estrutura fısica, de rede e de servicos
do CC?
2. Questao 2: Como desenhar o processo de Gestao de Configuracoes e a CMDB, para que
as informacoes sobre a infra-estrutura, assim como as relacoes entre os seus diversos itens,
sejam conhecidas, estejam globalmente acessıveis e num estado actualizado?
3. Questao 3: Que ferramentas podem ser utilizadas e de que forma podem ser adaptadas
para concretizarem os processos de Gestao de Alteracoes e de Gestao de Configuracoes?
1.3 Metodo de Investigacao
O metodo de investigacao utilizado no desenvolvimento desta tese e o designado como Inves-
tigacao-Accao (Action Research) [10]. Este metodo de investigacao surgiu nos meados do
seculo XX e foi inicialmente utilizado nas ciencias medicas e sociais, quando se pretendia intro-
duzir uma nova terapeutica e analisar os efeitos daı resultantes. Desde os finais dos anos noventa
comecou tambem a ser adoptado na area dos sistemas de informacao.
Este metodo segue um abordagem orientada a mudanca, pressupondo que os processos so-
ciais complexos podem ser estudados atraves da introducao propositada de alteracoes (entropia
4 CAPITULO 1. INTRODUCAO
controlada), observando, a posteriori, os efeitos resultantes dos factores exteriormente injectados
no sistema. No metodo Investigacao-Accao, o investigador pretende experimentar uma teoria
com indivıduos em ambientes reais, avaliando continuamente os resultados e introduzindo cor-
reccoes ou novos dados, repetindo este processo ate atingir um resultado considerado correcto.
Para ser possıvel calcular o efeito da introducao propositada de uma alteracao e posteri-
ormente a sua avaliacao, e seguido um processo de investigacao sistematico e iterativo, cujo
conhecimento adquirido em cada iteracao pode ser colocado em pratica na iteracao seguinte.
O domınio ideal de accao para este metodo e caracterizado por:
• um ambiente onde o investigador intervem directamente no proprio sistema em estudo
como um actor do mesmo, passando a fazer parte do objecto da investigacao.
• o conhecimento obtido poder ser imediatamente aplicado
• um processo de pesquisa cıclico ligando teoria e pratica
A Investigacao-Accao deve estar definida por um plano de investigacao e um plano de accao,
ambos suportados por um conjunto de metodos e regras. Sao as chamadas fases do processo
metodologico. Assim, para se concretizar um processo de Investigacao-Accao, sera necessario
seguir quatro fases:
• Diagnosticar ou descobrir o problema.
• Construir o plano de accao.
• Propor a execucao do plano e observar o seu funcionamento.
• Reflectir, interpretar e integrar os resultados. Construir um novo plano.
1.4. ESTRUTURA DA TESE 5
As fases da Investigacao-accao assumem a configuracao apresentada na Figura 1.1.
Figura 1.1: Fases da Investigacao-Accao.
1.4 Estrutura da Tese
De seguida descreve-se a estrutura do documento:
1. O capıtulo 1 introduz e descreve o problema que se pretende solucionar e apresenta o
Metodo de Investigacao utilizado na sua resolucao.
2. O capıtulo 2 apresenta o Trabalho Relacionado, incluindo a apresentacao/avaliacao dos
produtos existentes de gestao da Infra-estrutura fısica e de servicos duma organizacao.
Descreve os processos de Gestao de Alteracoes e de Gestao de Configuracoes segundo a
metodologia ITIL, e compara os diversos softwares existentes no mercado com base nas
capacidades que possuem para concretizar esses mesmos processos.
3. No capıtulo 3 e apresentado um diagnostico da forma como sao efectuados os procedimentos
diarios para gerir o CC do LIP, e sao definidos os requisitos funcionais, nao funcionais e
de negocio a satisfazer.
4. No capıtulo 4 sao apresentados os processos de Gestao de Configuracoes e de Gestao de Al-
teracoes que o LIP deve adoptar para satisfazer os requisitos pretendidos. Os diagramas de
fluxo de processo incluıdos neste capıtulo utilizam a simbologia constante no Apendice A.
6 CAPITULO 1. INTRODUCAO
5. No capıtulo 5, e descrita a forma como as ferramentas seleccionadas (Request Tracker e
Zenoss) podem ser utilizadas para concretizar os processos definidos no capıtulo 4.
6. Conclusao e apresentacao de Trabalho Futuro.
Esta tese executa um ciclo do Metodo de Investigacao-Accao: a Fase de Planificacao e
constituıda pelos capıtulos 1, 2 e 3, a Fase de Accao e constituıda pelos capıtulos 4 e 5 e a Fase
de Reflexao e apresentada nos capıtulos 6 e tambem na Conclusao.
O Metodo de Investigacao-Accao indica que o investigador deve experimentar uma teoria
com indivıduos em ambientes reais. O Centro de Calculo do Laboratorio de Instrumentacao e
Fısica Experimental de Partıculas (LIP) e a organizacao onde se tenta responder as questoes
levantadas nesta tese. O contexto desta instituicao e explicado na Seccao 3.1.
Capıtulo 2
Trabalho Relacionado
2.1 Gestao da Infra-estrutura
Os Centros de Calculo (CC) sao responsaveis pela gestao do equipamento (fısico e virtual) e
pelos servicos que podem ser usados por vastas comunidades de utilizadores, e que devem ser
permanentemente monitorizados de forma a garantir a qualidade de servico requerida pelos
clientes da infra-estrutura.
Para fazer a gestao das multiplas componentes de um CC existem ferramentas que propiciam
uma operacao controlada dos recursos. Na Figura 2.1 apresentamos alguns dos servicos tıpicos
que funcionam sobre os diferentes tipos de infra-estruturas de CC: fısica, rede e de servicos.
A cada tipo de infra-estrutura e servico, e dependendo da funcionalidade a vigiar, tenta-se
configurar e adequar a ferramenta de monitorizacao e alerta que melhor encaixa na arquitectura
e topologia do CC. Na presente Seccao comparam-se algumas das ferramentas de monitorizacao
existentes, tanto open-source como comerciais, cuja funcionalidade e a monitorizacao da rede e
dos servicos existentes num CC.
2.1.1 Gestao e Operacao da Infra-Estrutura de Rede
A monitorizacao do trafego de rede e uma das tarefas mais importantes a realizar num CC de
forma a optimizar o fluxo de dados de acordo com os requisitos dos equipamentos e a largura de
banda disponıvel. Assume especial relevo na minimizacao de possıveis riscos de seguranca, ja que
os ataques aos dados e aos equipamentos, provem na sua maioria atraves da rede. Para efectuar
a monitorizacao utilizam-se sistemas de monitorizacao da rede cujo objectivo e fornecer uma
visao centralizada da rede e dos sistemas, para que os seus administradores consigam analisar
as condicoes e evitar/corrigir os problemas rapidamente e de forma eficiente.
Tres solucoes open-source (Nagios, OpenNMS, Zenoss) para gestao de sistemas sao avaliadas
no estudo realizado por Jane Curry [12].
7
8 CAPITULO 2. TRABALHO RELACIONADO
Figura 2.1: Exemplo de Ferramentas de Monitorizacao, Alerta e Reaccao para Varios Recursose Servicos de um CC.
O estudo conclui que o Nagios e uma ferramenta bem testada, fiavel e com uma grande
comunidade de utilizadores. As notificacoes sao simples de configurar, mas caso seja necessaria a
producao de analises baseadas em registos fornecidos pelo Nagios talvez esta nao seja a solucao a
escolher. O Zenoss e o openNMS sao produtos com funcionalidades de discovery, monitorizacao
da disponibilidade, gestao de problemas, gestao de desempenho e reporting. O Zenoss tem
tambem alguma capacidade de topology mapping e tem melhor documentacao que o OpenNMS.
O estudo revela que a arquitectura de eventos, alarmes e notificacoes do OpenNMS e bastante
confusa. A autora refere o Zenoss como a melhor escolha, esperando que a comunidade Zenoss
melhore alguns aspectos nomeadamente a documentacao.
No estudo, Monitoring Systems Comparison, de Scott Stone [13], comparam-se outras
tres solucoes capazes de monitorizar a rede: Hyperic, Lithium e o Zabbix. Todas possuem
um modelo hıbrido de licenciamento, ou seja tem uma versao gratuita de base e uma versao
comercial que presta suporte aos utilizadores consoante as suas preferencias. De seguida
enumeram-se as principais caracterısticas de cada um destes sistemas de Monitorizacao,
resultantes da avaliacao [13] efectuada.
2.1. GESTAO DA INFRA-ESTRUTURA 9
Hyperic: o ponto forte desta solucao e a monitorizacao do desempenho de aplicacoes, sendo
vasta a variedade de aplicacoes que esta ferramenta consegue monitorizar.Possui caracterısticas
de auto-discovery muito desenvolvidas permitindo:
• a auto-deteccao das aplicacoes a monitorizar e a configuracao automatica de certos
parametros de monitorizacao para valores de omissao bastante razoaveis, que a posteriori,
o administrador pode modificar consoante a sua vontade.
• uma instalacao semi-automatica com intervencao mınima do administrador de sistemas1
Quando e necessaria uma intervencao por parte do administrador, esta e facilitada por uma
interface web bem desenhada e escrita em java capaz de responder de forma rapida, na qual e facil
procurar informacao pois os sistemas e servicos sao organizados de forma automatica. Os graficos
com os dados do desempenho das aplicacoes sao faceis de interpretar, e com legendas apropriadas.
Nao possui funcionalidades para a geracao de relatorios, no entanto, caso a informacao fornecida
pela interface de utilizador seja insuficiente, e possıvel inquirir a base de dados SQL usando uma
report-generating engine. Na edicao comercial (Enterprise edition) incorpora caracterısticas de
gestao de alteracoes, ficheiros de log de monitorizacao e uma polıtica de alertas ”Policy-driven”.
Lithium: e uma solucao simples de monitorizacao do estado e desempenho do hardware
que utiliza exclusivamente o SNMP e que nao possui qualquer capacidade da monitorizacao
de aplicacoes. A versao gratuita, vem com diversos perfis pre-construıdos de SNMP para mo-
nitorizacao de hardware de rede tais como routers Cisco, switches Cisco, switches Foundry,
firewalls Cisco, entre outros. Tem duas interfaces separadas, uma web based, e outra que e uma
solucao nativa, mais agradavel e com mais funcionalidades. O Lithium tem diversos relatorios
pre-definidos que podem ser gerados, incluindo um relatorio que indica o uso da largura de
banda.
Zabbix: Zabbix e outro bom exemplo de software da monitorizacao da rede, embora nao
tao completo quando comparado com o Hyperic em termos de monitorizacao de aplicacoes.
E uma solucao hıbrida das duas solucoes descritas anteriormente: baseia as suas verificacoes
tanto em SNMP como em agentes especıficos do Sistema Operativo. No presente momento
nao possui Auto-Discovery embora tal funcionalidade esteja planeada. Duas das caracterısticas
mais agradaveis sao a capacidade de representacao grafica: pode criar um mapa de rede que
mostra a localizacao fısica e logica dos dispositivos de rede e as suas dependencias. Os graficos
de desempenho sao claros, concisos, e faceis de ler. A interface de utilizador de Zabbix e
completamente web based, sendo as caracterısticas de gerar relatorios similares ao Hyperic.
1Para fazer o deploy do Hyperic, o administrador tem somente que instalar a console/servidor do software nono de gestao e depois fazer o deploy dos agentes nos nos a ser geridos(controlados). O codigo dentro dos agentesfara o auto-discovery apropriado e regista-lo-a automaticamente no servidor
10 CAPITULO 2. TRABALHO RELACIONADO
2.1.2 Gestao e Operacao da Infra-Estrutura de Servicos Computacionais
As infra-estruturas fısica e de rede de um CC servem o proposito de dar suporte a servicos
prestados aos utilizadores sendo alguns servicos transversais a qualquer tipo de organizacao,
seja ela de grande, media ou pequena dimensao. Exemplos desses servicos sao o DNS, o correio
electronico, os servicos de autenticacao, os servicos de bases de dados ou servicos de repositorios,
e cujo mau funcionamento poe em risco todas as camadas de servicos superiores tais como os de
computacao, de armazenamento e outros. Para monitorizar estes servicos existem ferramentas
de monitorizacao que avaliaremos na presente Seccao.
2.1.2.1 Aplicacoes para Gestao de Desempenho
Aplicacoes para Gestao do Desempenho (Application Performance Management - APM), sao
aplicacoes que se focam na monitorizacao, desempenho e disponibilidade do servico de aplicacoes
de software. Segundo o estudo da Gartner de 2010 [14], no qual se analisam aplicacoes APM
(ver Figura 2.2), a gestao das operacoes de Tecnologias de Informacao (TI), realizadas pelos
administradores de sistemas, tornou-se cada vez mais dependentes de aplicacoes, complexas
de gerir. O estudo evidencia ainda que muitas vezes, uma organizacao sente necessidade de
”misturar e combinar”ofertas de diferentes fabricantes para assim conseguir uma solucao que
seja ajustada as suas necessidades.
2.1.2.2 Produtos para Gestao de Eventos
As organizacoes de Tecnologias de Informacao (TI) precisam de consolidar, analisar e responder
aos eventos oriundos das componentes da Infra-estrutura, para assim conseguirem melhorar os
servicos prestados. Existem no mercado varios produtos, uns emergentes e outros mais maduros,
que respondem a esta necessidade das organizacoes. Tais produtos sao denominados de Event
Correlation and Analysis - (ECA) e os seus objectivos principais sao ajudarem as organizacoes
a lidar com o diluvio de eventos que advem da infra-estrutura de TI pois conseguem eliminar
sinais de eventos duplicados, filtrar os eventos de acordo com as operacoes ou de acordo com
as prioridades e analisar os eventos conseguindo-se assim determinar a sua causa. Este tipo de
produtos executam uma gestao por excepcao, ou seja, produzem uma alerta so quando uma
excepcao ocorre, por exemplo em caso de falha ou de violacao de um limite estabelecido, o que
indica que a infra-estrutura nao esta a ter um comportamento normal. Este facto implica o
conhecimento pela organizacao do que e um comportamento ”normal”.
A Gartner efectuou um estudo [15] no qual avaliou alguns destes produtos, e cujas con-
clusoes se encontram ilustradas na Figura 2.3. Produtos posicionados no quadrante visionaries
possuem uma visao de futuro e sao geralmente tecnicamente focados. Reconhecem e conseguem
2.1. GESTAO DA INFRA-ESTRUTURA 11
Figura 2.2: Quadrante Magico que Permite Avaliar um Fabricante de Produtos APM [14].
responder as tendencias da gestao de eventos a longo prazo do mercado, faltando-lhes contudo
reconhecimento, e forca de mercado e de vendas.
No quadrante leaders estao colocados os produtos com elevado grau de visibilidade no mer-
cado e que conseguem oferecer aplicacoes altamente robustas e escalaveis capazes de prioritizar
eventos oriundos de ambientes fısicos e virtuais da infra-estrutura de TI. Possuem a visao es-
trategica que lhes permite atender de forma rapida aos requisitos, em constante evolucao.
Produtos novos no mercado de gestao de eventos, que se focam num segmento pequeno do
mercado, mas que conseguem atingir grande profundidade nas funcionalidades nas suas areas
de escolha estao colocados no quadrante niche players.
No quadrante challengers encontram-se produtos que tem um bom desempenho em muitas
organizacoes. Alguns sao grandes produtos em termos de dimensao e recursos financeiros, mas
aos quais por vezes falta visao, inovacao e percepcao da evolucao das tendencias do mercado.
Podemos concluir que e extremamente difıcil encontrar uma solucao que responda a todos
os requisitos de um CC, e que normalmente nao sao solucoes integradas, obrigando a utilizacao
de diferentes plataformas e interfaces, consoante o problema que se pretende resolver.
12 CAPITULO 2. TRABALHO RELACIONADO
Figura 2.3: Quadrante Magico de Produtos ECA [15].
Na tentativa de integrar toda a informacao gerada pelas ferramentas de gestao, configuracao
e monitorizacao dos diferentes recursos, varias organizacoes usam modelos de princıpios de
operacao que descreveremos na Seccao seguinte.
2.2 ITIL
A presente Seccao apresenta uma das solucoes que permite integrar, manipular e gerir a
informacao gerada num CC: a framework ITIL (Information Technology Infrastructure Li-
brary) [16] [4], sobre a qual nos debrucaremos mais profundamente. No entanto, existem outras
frameworks com objectivos similares tais como o COBIT [17] [18] e o CMMI [19].
A framework ITIL e uma compilacao de boas praticas de gestao de TI obtidas a partir de
organizacoes publicas e privadas. Foi desenvolvido originalmente pelo governo britanico atraves
da CCTA, e actualmente e mantido pelo EXIN.
Esta framework descreve os processos necessarios para gerir uma infra-estrutura de TI de
forma eficaz e eficiente, garantindo os nıveis de servico que os clientes tem que exigir e que os
prestadores de servico devem fornecer. Os principais objectivos desta framework sao reduzir cus-
tos, aumentar a disponibilidade, ajustar a capacidade, aumentar a eficiencia e eficacia e reduzir
2.2. ITIL 13
riscos. A documentacao ITIL foca-se em descrever ”O QUE FAZER”e nao ”COMO FAZER”.
A framework ITIL e baseada em processos em detrimento de uma estrutura hierarquica. Isto
significa que hierarquicamente poderemos ter uma pessoa de um departamento responsavel por
mais de um processo.
Ao longo dos anos, a framework ITIL foi evoluindo, e inclui as seguintes areas que se
estruturam como representado na Figura 2.4 [20].
Figura 2.4: Estrutura da Framework ITIL (ITIL V2) [11].
2.2.1 Areas Relevantes para a Gestao de um Centro de Calculo
Uma das areas de maior relevancia na gestao e operacao de um CC moderno e a Gestao de
Servicos que engloba a area do Suporte aos Servicos [20]. O Suporte aos Servicos, como ilustrado
na Figura 2.5, trata dos processos necessarios a manutencao das operacoes diarias e de suporte
aos servicos prestados pela organizacao.
2.2.1.1 Suporte aos Servicos
A area do Suporte aos Servicos fundamenta-se em cinco processos e uma funcao (Service Desk):
1. Gestao de Incidentes e o processo onde os incidentes sao detectados e resolvidos. Um
incidente e um evento que nao faz parte da execucao normal de um servico e que pode
causar uma interrupcao
2. Gestao de Problemas e o processo que detecta e remove da infra-estrutura de TI, atraves
da determinacao da origem e analise do problema, a ocorrencia de incidentes de modo a
maximizar a eficiencia. Tem como principal objectivo minimizar o impacto de incidentes
e problemas no negocio, prevenindo a sua ocorrencia e relatando os erros encontrados.
14 CAPITULO 2. TRABALHO RELACIONADO
Figura 2.5: Modelo de Suporte aos Servicos (ITIL V2) [11].
3. Gestao de Alteracoes e o processo que controla a mudanca de todos os Itens de Confi-
guracao (IC), garantindo que procedimentos apropriados sao seguidos quando e efectuada
uma mudanca.
4. Gestao da Release e o processo que apos uma alteracao ter sido aprovada pelo processo
da Gestao das Alteracoes, controla o armazenamento fısico e logico, gestao e distribuicao
de todo o hardware e software de forma a garantir que na infra-estrutura so existe software
e hardware devidamente aprovado e testado.
5. Gestao da Configuracao e o processo de rastreio de todos os itens existentes na infra-
estrutura incluindo hardware, software e documentacao bem como todas as relacoes exis-
tentes entre eles e que suportam os servicos. Este processo envolve identificar, registar e
descrever as componentes de TI, (IC), incluindo as versoes, relacoes e componentes. A
informacao de todas os IC deve ser mantida numa base de dados modular e flexıvel.
Service Desk e uma funcao que age como unico ponto de entrada entre o utilizador e
a organizacao de TI (SPOC - Single Point Of Contact), e cujo objectivo e ajudar a resolver
problemas e restaurar a normalidade das operacoes o mais rapido possıvel.
2.2. ITIL 15
2.2.1.2 Benefıcios Resultantes do ITIL
A mudanca e uma constante num CC. Rastrear, gerir e controlar as alteracoes e o seu potencial
impacto nos servicos prestados torna-se, portanto, imperativo. Esta e uma das principais razoes
pelas quais os gestores de um CC comecam a olhar para os processos desta framework.
Esta Seccao descreve os benefıcios resultantes da implementacao da framework ITIL num CC
que incluem uma melhor gestao dos recursos e a consolidacao dos dados existentes. A framework
ITIL permite ainda um melhor entendimento dos recursos disponıveis, rastrear das mudancas
na infra-estrutura do CC e quantificar o impacto de tais mudancas nos servicos fornecidos.
Com operacoes cada vez mais complexas e mais orientadas ao servico, os gestores sentem
necessidade de criar processos que lhes permitam manter uma ordem na execucao das tarefas.
A framework ITIL fornece uma disciplina, uma linguagem e processos comuns que depois de
implementados introduzem coerencia para todos os que trabalham num CC. O conceito principal
que devemos ter em conta e a uniformizacao: uniformizacao de um glossario e termos comuns,
que eliminem deficiencias de comunicacao entre o grupo de trabalho, e uniformizacao de processos
e metricas quantificaveis que permitam um servico de elevada disponibilidade.
Devido a enorme quantidade de servicos abrangidos pela metodologia ITIL, implementa-los
parece uma tarefa gigantesca. Quem ja o implementou afirma que a melhor maneira e comecar
com as areas mais problematicas de um CC, que sao as areas de Gestao de Problemas (GP),
Gestao de Alteracoes (GA) e Gestao de Configuracoes (GC).
Na Seccao seguinte analisa-se em detalhe um sistema de Gestao de Configuracoes e que
aspectos se devem ter em conta para atingir o sucesso, dado que esta e a pedra basilar de
qualquer plataforma de gestao integrada de recursos.
2.2.2 Gestao de Configuracoes
O processo da Gestao de Configuracoes [4] e responsavel por identificar, registar e relatar todas as
componentes de TI, nomeadamente as suas versoes, os seus constituintes e relacoes, pertencentes
a organizacao. Este processo e ainda responsavel por providenciar a todos os restantes processos,
informacao de configuracao, correcta e actualizada.
Objectivos:
Os objectivos do processo de GC sao:
• inventariar os recursos e configuracoes dentro da organizacao e tambem dos seus servicos,
• fornecer informacoes exactas da configuracao e da documentacao necessarias aos processos
de Gestao de Servicos,
16 CAPITULO 2. TRABALHO RELACIONADO
• fornecer uma base solida para os restantes processos que constituem o ITIL,
• Comparar os registos de configuracao com a infra-estrutura e corrigir eventuais excepcoes.
Configuration Management Database
Configuration Management Database (CMDB) e a designacao generica do repositorio de toda a
informacao relacionada com as componentes que existem numa organizacao de TI. Os registos
deste repositorio chamam-se Itens de Configuracao (IC), sendo um IC qualquer componente que
esta sob o controle do processo da Gestao de Configuracoes. A CMDB tambem inclui informacao
sobre a relacao entre os IC, sendo este o aspecto que distingue a CMDB de uma base de dados
tradicional.
Todos os IC sao univocamente identificados por nomes, numeros de versoes e outros atribu-
tos, variando em complexidade, tamanho e tipo. Um IC pode ser um servico ou pode consistir
em hardware, software e documentacao de um programa.
Actividades
Sao cinco as actividades que constituem o Processo de Gestao de Configuracoes, e que garantem
a qualidade e coerencia da informacao armazenada durante o desenrolar do processo:
1. Planeamento
Primeiro que tudo e necessario definir o ambito, a finalidade, os objectivos, prioridades e
procedimentos para o processo de GC. E nesta fase que os tipos e atributos dos itens de
configuracao sao definidos.
2. Identificacao
Todos os activos (IC) da infra-estrutura, necessarios para providenciar um servico, devem
ser identificados, etiquetados e inseridos num repositorio de dados. Para cada tipo de
recurso a profundidade da documentacao exigida deve ser definida. Para cada atributo de
um dado activo armazenado, uma razao valida tem que existir para legitimar o esforco de
recolher e de manter a informacao. O grau de detalhe, usado para manter os IC, e muito
importante para o sucesso da GC, dado que um grau de detalhe muito elevado aumentara
o esforco necessario para manter o repositorio de informacao e nao permitira um fluxo de
dados efectivo. Tambem, adicionar atributos em falta e moroso e produzira custos elevados
quando o sistema de GC estiver em producao.
3. Controlo
Esta actividade e responsavel por garantir que a insercao dos IC na base de dados e execu-
tada de forma controlada, isto e, que so IC autorizados e identificados podem ser inseridos.
2.2. ITIL 17
Faz parte desta actividade assegurar que nenhum IC e adicionado sem a existencia de do-
cumentacao apropriada, (por exemplo, um pedido de alteracao aprovado) e que, apos a
insercao, exista documentacao actualizada.
4. Status accounting
As alteracoes aos componentes devem ser documentadas e deve ser possıvel visualizar e res-
taurar versoes antigas de uma entrada e das suas relacoes com outras entradas. Juntamente
com a alteracao efectuada, a identificacao da pessoa responsavel pela sua implementacao
deve ser uma informacao a manter. Devem existir relatorios onde consta o estado presente
e passado de um IC.
5. Verificacao e Auditoria
Devem realizar-se verificacoes periodicas aos dados armazenados que assegurem a
existencia e exactidao da informacao guardada. E necessario provar que os IC e todos
os atributos existentes estao correctos, e que as alteracoes foram realizadas de acordo com
procedimentos estabelecidos. O repositorio de informacao deve conter apenas registos de
IC que realmente existem, sendo necessario avaliacoes regulares que removam informacao
desactualizada e/ou nao necessaria.
Metricas
Existem indicadores chave de desempenho (KPI - Key Performance Indicators) para medir cada
uma das actividades do processo de GC, existindo tambem KPI para medir todo o processo de
GC. Alguns dos KPI sao:
• Numero de pedidos de correccao da configuracao.
• Numero de pedidos de configuracao.
• Percentagem de pedidos de correccao de configuracao por numero de pedidos de confi-
guracao.
• Percentagem de componentes de TI configurados via metodos automatizados versus com-
ponentes de TI configurados manualmente.
• Percentagem de componentes registados com informacao de configuracao errada durante
um processo de auditoria.
Devem ser produzidos relatorios e registos regularmente que suportem as medidas descritas
anteriormente.
18 CAPITULO 2. TRABALHO RELACIONADO
2.2.3 Gestao de Alteracoes
As mudancas/alteracoes podem surgir como resultado da ocorrencia de problemas, mas tambem
advem de uma procura constante em minimizar as interrupcoes no servico e melhorar as
operacoes diarias das organizacoes de TI. Para conseguir estes objectivos, e necessario que as
organizacoes se assegurem que as mudancas se facam de forma controlada, ou seja, qualquer
alteracao a efectuar ou nao, tera que ser avaliada, priorizada, planeada, testada, implementada
e documentada. So assim, se consegue passar de um estado definido para outro estado definido.
Percebendo que e necessario gerir as mudancas, a framework ITIL propoe que as organizacoes
definam e implementem um processo denominado Processo de Gestao de Alteracoes.
Objectivos
A implementacao e definicao do processo de GA, deve ter em conta os seguintes objectivos:
• utilizar metodos e procedimentos padronizados
• registar as alteracoes na CMDB
• analisar riscos e avaliar o impacto das alteracoes: a framework ITIL enfatiza que o processo
contemple a avaliacao rigorosa dos riscos provenientes das alteracoes, e propoe que se
responda a sete questoes:
1. Raised - quem pediu a alteracao?
2. Reason - qual a razao para a alteracao?
3. Return - qual o retorno exigido da mudanca?
4. Risk - quais os riscos envolvidos?
5. Resources - que recursos sao necessarios?
6. Responsible - quem e responsavel por configurar, testar e implementar?
7. Relationship - que relacoes existem entre a alteracao que se pretende e outras al-
teracoes?
Nao e contudo, do domınio do processo da GA, a identificacao de componentes afectadas pela
alteracao, ou pela release de componentes que tenham sido alterados [11], estando estas tarefas
sob o domınio de outros processos existentes, nomeadamente os processos de GC e Gestao da
Release.
2.2. ITIL 19
O processo da GA e responsavel por procedimentos que lidam com a gestao de pedidos de
alteracao aos itens de configuracao (IC) presentes na CMDB. Esses procedimentos envolvem:
• Hardware
• Servicos
• Software
• Software de Sistema
• Aplicacoes de software em utilizacao
• Documentacao e procedimentos associados a manutencao, suporte e execucao dos sistemas
• Pessoas
O processo da GA e vital para manter os dados na CMDB actuais e precisos, e conjuntamente
com o processo de GC permitem avaliar o risco, custo e impacto das alteracoes. Por esta razao,
muitas organizacoes optam por implementar os processos da GA e GC simultaneamente, para
assim ganhar controle sobre a infra-estrutura. A CMDB interage com todos os processos, e
possui os activos da organizacao, mas tambem detem as fontes de informacao sobre os recursos
utilizados por cada servico e as suas dependencias. Quando uma mudanca precisa ser executada,
a CMDB mostra que componentes estao ligados ao componente alterado ou servico, sendo assim
possıvel conhecer as consequencias e os problemas associados a mudanca [22]. A Figura 2.6
ilustra a interaccao entre o processo da GA e outros processos da framework ITIL.
Figura 2.6: Gestao das Alteracoes e Outros Processos ITIL [14]
20 CAPITULO 2. TRABALHO RELACIONADO
Papeis no Processo de Gestao de Alteracoes
O processo de GA dita a criacao de um comite de pessoas, com diversas funcoes dentro da orga-
nizacao, responsaveis pela definicao do processo e por aprovar, avaliar e priorizar as alteracoes,
constituindo a autoridade de decisao, denominado Change Advisory Board - CAB. Na eventua-
lidade de ocorrencia de problemas, pode ser impossıvel reunir todas as pessoas que constituem o
CAB, pelo que convem que as organizacoes identifiquem um conjunto mais pequeno de pessoas
capazes de dar resposta a situacoes de emergencia. Ou seja, deve existir tambem um emergency
Committee - EC.
A framework ITIL propoe ainda a criacao de um outro papel: Change Manager - CM, cujas
principais responsabilidades consistem na definicao do objectivo do processo de GA e como
quantificar e medir a sua eficiencia. Tambem e da responsabilidade do Change Manager fazer
o alinhamento entre o o processo de GA e o processo de GC. Deverao efectuar-se planos que
assegurem que um correcto interface existe entre estes dois processos.
Actividades
A Figura 2.7 ilustra um exemplo de actividades envolvidas no Processo de Gestao de Alteracoes:
Figura 2.7: Processo da Gestao de Alteracoes
A abordagem as actividades do processo da GA podem depender das necessidades da or-
ganizacao e da natureza do negocio. No entanto, a seguinte cadeia de acontecimentos e na
2.2. ITIL 21
generalidade seguida:
1. E efectuado um Pedido de Alteracao (RfC - Request for Change). O pedido pode ser
efectuado por qualquer pessoa pertencente a organizacao, e e enviado por qualquer canal
de comunicacao ao dispor (email, formulario web proprio na intranet, telefone, etc.).
2. O CM examina o pedido.
3. O CM avalia, classifica, e categoriza o RfC, baseando-se no impacto e urgencia da alteracao
proposta. Se considerar que a alteracao e necessaria e exequıvel, efectua um planeamento
inicial da implementacao da alteracao.
4. O RfC e rejeitado ou aprovado para implementacao pelo CM ou pelo CAB. A necessidade
de aprovacao por parte do CAB depende da quantificacao do impacto da alteracao na
instituicao, da quantidade de recursos necessarios para efectuar a implementacao e do
risco relacionado com a implementacao da mudanca.
5. O CM planeia a implementacao, definindo as tarefas a executar, o esforco necessario,
determinando os recursos, o orcamento disponıvel, e os criterios de aceitacao. O tecnico
responsavel por implementar a mudanca define um plano de implementacao do ponto de
vista tecnico definindo uma solucao tecnica que engloba testes e uma plano de retrocesso.
6. A alteracao e efectuada de acordo com o plano de implementacao estabelecido.
7. A alteracao e testada verificando-se e avaliando-se o seu impacto. Posteriormente as al-
teracoes entram em producao. Este processo, Release to production, envolve uma avaliacao
final que consiste em ponderar se a mudanca e realizada ou nao, e se e necessario aplicar
o plano de retrocesso.
8. O sucesso da implementacao da alteracao e o seu impacto e revisto em cooperacao com o
CM. O RfC e toda a informacao relacionada e actualizada, e o RfC e concluıdo.
Estados de um RfC
De seguida descrevem-se possıveis estados de um RfC, segundo duas perspectivas: a seguida pela
framework ITIL e sugerida por Mattila [24]. A framework ITIL sugere que os estados dos RfC
sejam: logged, assessed,rejected, accepted and sleeping. Por sua vez, Matilla propoe os estados
ilustrados na Figura 2.8.
22 CAPITULO 2. TRABALHO RELACIONADO
Figura 2.8: Estados de um RfC [15]
Categorizacao das Alteracoes
A avaliacao de uma alteracao passa tambem por integrar a alteracao em categorias pre-
estabelecidas e acordadas dentro do CAB. A framework ITIL propoe que sejam categorizadas
da seguinte forma:
• Mudancas com grande impacto
• Mudancas com impacto Significante
• Mudancas com pouco impacto
Metricas
A framework ITIL refere que as mudancas devem ser avaliadas e que periodicamente devem
ser facultados documentos, que circulem na organizacao, onde conste essa avaliacao. Nesses
relatorios, sugere-se que se inclua a seguinte informacao:
• Numero de mudancas implementadas num determinado perıodo: no total, por IC, tipo de
configuracao, servico, etc.
• Categorizacao/decomposicao das razoes da mudanca (solicitada pelo utilizador, devida a
melhorias, servico para resolver problemas/incidentes, melhoria de procedimentos).
2.2. ITIL 23
• Numero de mudancas bem sucedidas.
• Numero de mudancas que nao se realizaram, juntamente com as razoes.
• Numero de incidentes atribuıdos a alteracoes.
• Numero de mudancas implementadas e que necessitaram de ser revistas.
• Elevadas incidencias de RfC relacionadas com IC.
• Comparacao com graficos de perıodos anteriores.
• Numero de RfC rejeitados.
• Proporcao de mudancas que nao foram bem sucedidas (relativamente ao numero total, e
descriminadas por IC).
Num caso de estudo no qual a framework ITIL foi implementada e bem sucedida [25],
os resultados constantes na Tabela 2.1, mostram de forma exacta e mensuravel melhorias na
Organizacao.
Anterior Posterior
KPI a Implementacao a Implementacao
ITIL ITIL
% de mudancas realizadas de acordo 25 80
com o planeado
% de mudancas efectuadas, mas nao 10 95
aprovadas
% de mudancas urgentes 60 35
% de mudancas falhadas 18 6
% de software em utilizacao sem 22 8
autorizacao
% de Releases falhadas 13 10
% Releases urgentes 32 20
Tabela 2.1: KPIs para os Processos da GA e Gestao da Release [25].
Um KPI e uma metrica que e usada para ajudar a gerir um Processo, um Servico de TI ou
uma Actividade. Muitas metricas podem ser utilizadas, mas so as mais importantes sao definidas
como KPIs e sao usadas para, de uma forma activa, gerir e reportar um Processo, Servico de TI
ou Actividade. Os KPIs devem ser seleccionados de forma a garantir que a eficiencia, eficacia,
e rentabilidade sao geridos.
Observando os valores dos KPIs, presentes na Tabela 2.1, anteriores e posteriores a imple-
mentacao do processo de GA, podemos constatar os ganhos obtidos pela organizacao: o numero
24 CAPITULO 2. TRABALHO RELACIONADO
de mudancas falhadas diminui, bem como a percentagem de mudancas urgentes. Tambem a
percentagem de software em utilizacao sem autorizacao diminui.
2.3 Suporte a Gestao de Processos ITIL
A framework ITIL foca a sua estrategia nos processos de gestao de TI, mas o objectivo, e que
muitos destes processos sejam concretizados em sistemas de software. Nao e do ambito da
framework ITIL orientar e divulgar a utilizacao de ferramentas, e alias nem deve faze-lo. A
framework ITIL tambem nao afirma que deva existir uma solucao unica que englobe todos os
processos. A verdade e que existem solucoes diferentes, de vendedores diferentes, open source e
comerciais, que se focam e especializam em determinados processos.
A seguinte avaliacao, baseia-se na comparacao de caracterısticas de produtos que vao de
encontro as actividades relevantes para os Processos de Suporte, nomeadamente a GC e GA, de
acordo com o descrito na framework ITIL V2 (A framework ITIL V3 foi lancado em 2007, mas a
framework ITIL V2 e extensamente usado e constitui um padrao para a maioria de organizacoes).
Este estudo foi realizado pela Microsoft e consta no artigo referido em [26].
Os produtos comparados sao a solucao oferecida pela Microsoft e algumas solucoes
oferecidas pela comunidade open source. Como veremos, encontrar-se-ao semelhancas, mas
tambem diferencas nas abordagens as questoes que a framework ITIL levanta.
Podemos, no geral, concluir que:
• Nenhuma solucao unica, de forma total, cobre todas as necessidades da framework ITIL.
• A solucao da Microsoft e relativamente completa, mas demasiado centrada no Windows,
e nao contempla todas as actividades presentes na framework ITIL.
• A comunidade open source foca-se em actividades tecnicas particulares da framework ITIL
em detrimento de um servico mais abrangente que englobe todo o processo ITIL.
2.3.1 Software para Gestao de Configuracoes
Na presente Seccao mostra-se e analisa-se algum software existente para concretizar o processo
de GC. Vejamos como cada software, se aproxima ou afasta da framework ITIL, ou seja, em que
medida, na sua implementacao, as actividades da GC (ver Seccao2.2.2) estao presentes.
Um dos objectivos da GC e fornecer uma base de conhecimento da configuracao do hard-
ware e software usados por uma organizacao, logo o software devera contemplar as seguintes
funcionalidades:
2.3. SUPORTE A GESTAO DE PROCESSOS ITIL 25
• Descobrir dispositivos na rede.
• Determinar o host de um sistema operativo.
• Averiguar que aplicacoes se encontram em utilizacao no sistema.
• Detectar alteracoes na configuracao.
Todos os produtos listados na figura 2.9 implementam estas funcionalidades mas, no entanto,
nenhum sozinho contempla todas as actividades da framework ITIL.
Figura 2.9: Software para Gestao de Configuracoes [17].
A Figura 2.10 fornece uma revisao da capacidade de cada produto para enderecar as acti-
vidades da framework ITIL (ver Seccao 2.2.2) para a GC.
Figura 2.10: Avaliacao do Software para Gestao de Configuracoes [17].
26 CAPITULO 2. TRABALHO RELACIONADO
Podemos concluir o seguinte: a comunidade open source oferece uma vasta gama de solucoes
para a GC, da qual o Zenoss e um bom exemplo, para monitorizacao da infra-estrutura e gestao
das aplicacoes, pois utiliza um CMDB para manter a informacao dos componentes existentes na
rede. Contudo, tem suporte limitado para aplicacoes empresariais tais como o SQL Server, o
que limita a sua capacidade para actividades tais como a de Verificacao e Auditoria. OneCMDB
possui funcionalidades de modelacao e descoberta, mas falta-lhe a capacidade automatizada de
Auditoria. CMDBuild, e um um projecto italiano de codigo aberto interessante, mas falta-lhe
documentacao em lıngua inglesa, o que restringe o seu uso.
Por sua vez, o Microsoft Systems Management Server (SMS), nao e uma CMDB com-
pleta, mas consegue descobrir e monitorizar sistemas para um leque extenso de informacao de
configuracao, tais como hardware, sistema operativo e versao e aplicacoes instaladas. Como
e dedicado a plataforma Windows e as suas aplicacoes, pode executar uma analise muito de-
talhada que permite armazenar uma vasta variedade da informacao dos sistemas geridos pela
organizacao.
2.3.2 Software para Gestao de Alteracoes
A menos que a mudanca seja controlada dentro de uma organizacao, os servicos estarao a merce
de modificacoes ad hoc aos routers, aos utilizadores, e ao software. As mudancas ad hoc podem
e custam o rendimento das organizacoes, e criam frustracao desnecessaria, como por exemplo,
utilizadores terem que esperar a conclusao de um melhoramento nao anunciado ou o rollback
de um patch falhado. Os produtos utilizados para concretizar o processo da GA dividem-se em
duas categorias: Software de Workflow ou Deployment.
1. Software de Workflow usado para definir e rever o processo aprovado. Quando um RfC
e emitido, o software de workflow distribui o RfC para as partes envolvidas para revisao,
teste e eventualmente instalacao, permitindo monitorizar o processo de alteracao. Um
exemplo de software open source que suporta workflow e o Request Tracker, mas muitos
produtos de Help Desk tambem possuem esta funcionalidade, possibilitando o seu uso para
monitorizar o processo de mudanca.
2. Software de Deployment, que diz respeito a automatizacao da implementacao da alteracao
ate esta ser atingida. Para ser possıvel atingir este objectivo, e necessario que o software
possua as seguintes funcionalidades:
• Instale actualizacoes de software e mudancas na configuracao.
• Detecte erros durante o processo de actualizacao.
• Registe e relate quem iniciou o conjunto de alteracoes.
2.3. SUPORTE A GESTAO DE PROCESSOS ITIL 27
Figura 2.11: Avaliacao do Software para Gestao de Alteracoes [17].
A Figura 2.11 fornece uma revisao da capacidade de cada produto para enderecar as acti-
vidades da framework ITIL para o processo da GA (ver Seccao 2.2.3).
Podemos concluir que algumas das ferramentas mais avancadas disponıveis sao open source,
tais como bcfg2, cfengine, radmind, e Webmin. Todas preveem determinados graus de controlo
sobre a instalacao das mudancas, embora ferramentas como o Webmin, utilizem um ecra de
configuracao manual, o que limita o seu uso em ambientes de grande dimensao. Ferramentas que
se centram na automatizacao, tais como o bcfg2 e cfengine, fornecem meios que asseguram de que
as configuracoes nao sao alteradas - toda a alteracao nao aprovada e revertida automaticamente
de volta ao original por um agente local do software. Por exemplo, se um servidor que e
definido como servidor web e nao tem o software Apache instalado, os pacotes de gestao de
alteracoes corrigem este desvio instalando e configurando o pacote Apache. Esta capacidade
de definir regras de configuracao e impor essas regras permite tanto ao bcfg2 como ao cfengine
implementar um mecanismo potente para a actividade de GA.
No entanto, as capacidades de produzir relatorios destes produtos e limitada. Apesar de
fornecerem relatorios das mudancas ocorridas no sistema, nao ha uma forma obvia de determinar
que sistemas estao ou nao sincronizados para alem de permitir que eles voltem a ficar sincroni-
zados. Isto limita a capacidade de auditoria de alteracoes nao autorizadas aos sistemas (embora
este aspecto seja mais importante para a GC). Por sua vez, a solucao SMS da Microsoft, usada
em ambientes windows tem as seguintes funcionalidades:
• Plano de Instalacao: relatorios que fornecem a informacao sobre hardware, software e
versao.
• Instalacao baseada em grupos: permite ao administrador de sistemas alocar software por
diversos. grupos, onde um grupo pode ser definido usando propriedades como hardware,
Active Directory(AD) e membros do grupo AD.
• Actualizacoes de patch: automatiza a instalacao de patches para servidores e aplicacoes
crıticas.
28 CAPITULO 2. TRABALHO RELACIONADO
Existem solucoes viaveis para concretizar o processo da GA em ambos os ambientes open
source e Microsoft. A comunidade open source tem providenciando solucoes tecnicas robustas
(bcfg2 e cfengine), mas muitas vezes nao implementa actividades essenciais, tais como planear
alteracoes (por exemplo, o software nao permite facilmente que um administrador estime o
impacto de uma mudanca). Por sua vez, o SMS da Microsoft oferece uma solucao mais abran-
gente, mas e limitado no seu alcance por causa de seu foco ser o ambiente Microsoft e os produtos
Windows. Assim, em qualquer empresa em que se executem sistemas Windows e UNIX devem
funcionar normalmente dois produtos de gestao de alteracoes em paralelo.
Capıtulo 3
Problema
3.1 Contextualizacao
O Laboratorio de Instrumentacao e Fısica Experimental de Partıculas (LIP), criado em 1986
quando Portugal aderiu ao CERN, e uma associacao tecnica e cientıfica, que tem por objectivo a
investigacao no campo da Fısica Experimental de Altas Energias e da Instrumentacao Associada.
As actividades de pesquisa do LIP, desenvolvidas no ambito de grandes colaboracoes interna-
cionais (CERN, ESA, SNOLAB, NASA, AUGER), tem como principais domınios de investigacao
a Fısica Experimental de Altas Energias e Astropartıculas, a Instrumentacao de Deteccao de
Radiacao, a Aquisicao e Processamento de Dados, a Computacao Avancada e as aplicacoes das
radiacoes a medicina.
Em Lisboa e Coimbra existem dois Centros de Calculo albergando a infra-estrutura de TI
da organizacao. Para alem da gestao destes dois CC, a equipa de Computacao Avancada do LIP
e tambem responsavel pela coordenacao da operacao da Iniciativa Nacional Grid (INGRID) [40],
no ambito do projecto europeu European Grid Initiative (EGI) [41], e opera o no central Grid
(NCG) instalado na Fundacao para a Computacao Cientıfica Nacional (FCCN).
No presente capıtulo apresenta-se a instituicao (LIP), identificam-se as principais causas e
problemas nos procedimentos efectuados nos CC da instituicao e finaliza-se com a descricao dos
requisitos que se pretendem implementar de modo a agilizar os processos realizados nos CC.
Apontar um caminho para melhorar a gestao destes dois centros de calculo e o proposito
deste trabalho.
29
30 CAPITULO 3. PROBLEMA
3.2 Causas e Problemas Principais nos Procedimentos do LIP
O LIP encontra-se envolvido em projectos cujas experiencias necessitam que se processem quan-
tidades massivas de dados digitais, e nas quais existem milhares de utilizadores. Esta situacao
implica que o pessoal tecnico e especializado do CC do LIP tenha que gerir uma vasta gama
de recursos computacionais. Em simultaneo, algumas parcerias que o LIP vem estabelecendo
aumentam por sua vez a area de actuacao do pessoal tecnico do CC do LIP, aumentando as
funcoes que os mesmo numero de tecnicos tem que desempenhar.
Ate a data, o LIP tem conseguido manter o nıvel de servico que satisfaz os utilizadores, mas
o pessoal tecnico encontra-se no limite do seu esforco.
Atraves de um grande numero de entrevistas aos funcionarios do LIP, e da analise das
operacoes diarias levadas a cabo por cada elemento, tentou-se identificar as responsabilidades
individuais, as responsabilidades conjuntas e o modo como a informacao flui no interior da
instituicao.
Apos a analise as respostas e procedimentos funcionais, chegou-se as seguintes conclusoes:
• cada funcionario e responsavel pela manutencao e operacao de determinados servicos.
Existem servicos que podem ser suportados por dois ou mais elementos,
• a documentacao sobre a operacao de cada servico e mantida numa wiki geral. O problema
e que essa wiki nao e actualizada com a regularidade desejada,
• as entradas e saıdas de componentes informaticas e realizada de acordo com uma base de
dados que se tornou obsoleta uma vez que deixou de estar actualizada,
• os registos de intervencoes sobre componentes e ainda mantido na forma de ficheiros de
texto em areas pessoais de alguns funcionarios,
• o planeamento das intervencoes e realizado de forma ad hoc, com uma avaliacao do impacto
precaria,
• o Modus operandi da instituicao, apesar de ainda conseguir satisfazer a qualidade de
servico pretendida, confronta-se com o obstaculo da nao escalabilidade resultante da gestao
de um parque informatico cada vez maior, mais complexo e distribuıdo, estando os seus
funcionarios no limite do seu esforco.
O modo de funcionamento do CC de Coimbra e semelhante ao funcionamento de Lisboa,
pelo que no primeiro ciclo do metodo Action Research so terei em consideracao o CC de Lisboa.
3.3. COLECCAO E CARACTERIZACAO DE REQUISITOS 31
3.3 Coleccao e Caracterizacao de Requisitos
O objectivo deste trabalho e a implementacao de um sistema que optimize procedimentos e
minimize o esforco na operacao/manutencao do equipamento.
Atendendo ao diagnostico elaborado, apresentado na Seccao anterior, tendo em conta o
contexto da instituicao LIP, foi estabelecido um conjunto de requisitos funcionais, nao funcionais
e de negocio que devem ser implementados de forma a agilizar e automatizar os processos
realizados pelo CC do LIP. Estes requisitos foram aprovados pelo LIP.
3.3.1 Requisitos de Negocio
R01. O sistema deve ser desenvolvido utilizando ferramentas open source.
R02. O sistema deve integrar, sempre que possıvel, tecnologia e software em producao no seio
da instituicao.
R03. O fluxo de informacao no desenrolar dos processos deve basear-se num sistema de noti-
ficacoes trocadas entre os varios intervenientes.
3.3.2 Requisitos Nao Funcionais
R04. A autenticacao no sistema deve ser efectuada via login/password ou via certificado digital.
R05. Os utilizadores so possuem permissoes para enviar notificacoes.
R06. O administrador do sistema possui permissoes para criar, apagar e manipular informacao
em todos os modulos do sistema.
3.3.3 Requisitos Funcionais
R07. Planeamento de intervencoes sobre componentes informaticos (adicao, substituicao e
remocao).
R08. Registo de accoes efectuadas sobre componentes informaticos incluindo intervencoes de
manutencao.
R09. Registo de accoes realizadas pelos utilizadores e pelo administrador do sistema.
R10. Efectuar procuras sobre as accoes efectuadas sobre determinado componente.
R11. Elaborar relatorios e estatısticas que possibilitem obter metricas para os varios compo-
nentes informaticos da instituicao.
32 CAPITULO 3. PROBLEMA
R12. Detectar e notificar a presenca de incoerencia nos dados.
R13. Existencia de uma interface de acesso para todos os utilizadores.
R14. Existencia de uma interface que permita consultar os dados guardados.
R15. Inventario actualizado do equipamento de hardware existente no CC do LIP.
Capıtulo 4
Proposta
Neste capıtulo sao apresentadas as propostas para os processos de GA e GC tendo em conta os
requisitos estabelecidos no ambito do LIP.
4.1 Sistema da Gestao de Alteracoes
Para gerir as alteracoes foi necessario definir um processo de GA, que se ajuste aos requisitos
da instituicao e que formalize estados de mudanca, nomeadamente de equipamentos e servicos.
O processo fixado e baseado na framework ITIL. Neste sentido, foi necessario criar criterios
ajustados a realidade da instituicao para categorizar as alteracoes, decidir os seus estados, fixar
metricas para avaliar as alteracoes e o seu impacto, e determinar as actividades relevantes no
fluxo de execucao do processo.
4.1.1 Modelo de Actividades
A Figura 4.1 ilustra o processo proposto de GA, e que e composto pelas seguintes actividades:
1. Criar um RfC (Request for Change).
2. Avaliar/Classificar um RfC.
3. Autorizar RfC.
4. Concretizar.
5. Testar um RfC.
6. Aceitar/Rejeitar RfC.
33
34 CAPITULO 4. PROPOSTA
Figura 4.1: Processo de Gestao de Alteracoes Adoptado.
Este processo propoe a existencia de quatro papeis a desempenhar na instituicao: Re-
questador (qualquer utilizador e funcionario da instituicao), Executante (os funcionarios que
executam as tarefas tecnicas de implementacao da alteracao), Coordenador (o responsavel pela
avaliacao da alteracao e pela coordenacao da implementacao) e o Comite de Peritos (CPE
que avalia e coordena alteracoes de grande impacto na instituicao).
O processo inicia-se com a criacao de um novo RfC, e pode ser realizado por qualquer
utilizador na organizacao. A alteracao e posteriormente catalogada pelo Coordenador: caso
4.1. SISTEMA DA GESTAO DE ALTERACOES 35
seja uma alteracao confirmada como standard, e automaticamente aprovada/aceite e pode ser
executada. E nesta altura, que tambem e definido o IC sobre o qual a alteracao e pretendida e
recolhida toda a informacao relacionada, considerada util para avaliacao da alteracao. Caso seja
uma alteracao considerada nao standard, o RfC tem que ser avaliado e classificado de acordo
com o modelo de classificacao de alteracoes proposto (ver Seccao 4.1.3). O Coordenador pode
dar seguimento a alteracao ou encaminhar o pedido para nova reavaliacao pelo CPE. Se o RfC
for rejeitado, o processo termina e o porque da decisao de rejeicao e guardado. Se o RfC e aceite,
o(s) Executante(s), executam a alteracao. O RfC entra entao numa fase de testes, e caso seja
considerado valido e nao causar problemas inesperados, a alteracao e finalmente aceite. Caso
contrario a alteracao e rejeitada.
4.1.2 Estados das Alteracoes
No desenrolar das varias actividades, um RfC passa por varios estados que se encontram ilus-
trados na Figura 4.2.
Figura 4.2: Diagrama de Estados de uma Alteracao.
• New - Quando um RfC e criado, este e o seu estado.
• Open - O RfC foi aceite para implementacao pelo Coordenador ou pelo CPE. Encontra-se
em implementacao pelo Executante.
• Testing - Depois de implementar a alteracao, o RfC entra numa fase de testes. Nesta fase
avalia-se se a alteracao e ou nao bem sucedida.
• Resolved - Este e um dos estados finais de um RfC. Significa que a alteracao foi comple-
tada e com sucesso.
• Rejected - O RfC foi avaliado pelo Coordenador ou por o CPE e foi decidido que nao
sera resolvido, mas por alguma razao, e valido que esta accao seja registada no sistema.
36 CAPITULO 4. PROPOSTA
4.1.3 Categorias de Alteracoes e Criterios de Avaliacao
Os objectivos da categorizacao das alteracoes e perceber qual o metodo de aprovar e autorizar
o pedido de alteracao (RfC) e ter um calculo previo do impacto da alteracao na instituicao.
Nesse sentido, para categorizar as alteracoes foi decidido adoptar o modelo definido pela Pink
Elephant,1 sendo fixadas as seguintes categorias:
1. Principal - Mudancas que envolvem:
• elevado tempo de preparacao/execucao
• impacto difıcil de avaliar
• metodos procedimentais nao conhecidos
• requerem obrigatoriamente uma avaliacao por parte do CPE
• avultados custos monetarios
2. Significante - Mudancas que implicam um tempo de preparacao e execucao longo. Re-
querem avaliacao por parte do CPE
3. Menor - Alteracoes que nao requerem aprovacao por parte do CPE e que requerem pouco
tempo de preparacao/execucao.
Para categorizar uma alteracao o Coordenador deve avalia-la de acordo com os criterios
apresentados na Tabela 4.1, e ter em consideracao o seguinte modelo de classificacao:
o valor mais elevado para todos os criterios estabelece a categoria da alteracao. Por exemplo,
cinco classificacoes C e um A significam automaticamente uma Alteracao Principal.
1Varios colaboradores da Pink Elephant sao co-autores do livro ITIL - Service Support da editora Best practicenomeadamente Michiel Berkhout, Brian Jonhson, Marc Van Goethem, Guus Velter
4.1. SISTEMA DA GESTAO DE ALTERACOES 37
Numero de utilizadores afectadosA. Todos os utilizadores
B. Dois ou mais grupos
C. Um grupo
Risco de nao implementar a alteracaoA. Elevado. Organizacao ficainoperacionalB. Medio. Parte das funcionalidadesnao serao disponibilizadasC. Baixo. Sem implicacoespara a organizacao
Recursos necessarios para preparar/implementarA. Todo o CCB. 3 tecnicosC. 1 - 2 tecnicos
Esforco de PreparacaoA. 2 dias ou maisB. 8 - 48 horasC. ≤ 8 horas
Esforco de ImplementacaoA. > 24 horasB. 1 - 24 horasC. ≤ 1 hora
Possibilidade de retrocessoA. DifıcilB. Moderada (1 - 2 horas)C. Facil
Tabela 4.1: Criterios para Categorizacao de Alteracoes: A = Alteracao Principal, B = AlteracaoSignificante, C = Alteracao Menor.
Sabendo qual o tipo de categoria, estabeleceram-se os seguintes tempos de implementacao:
Categoria da Alteracao Prazo de Execucao
Principal 30 dias uteis
Significante 14 dias uteis
Menor 0-3 dias uteis
Tabela 4.2: Perıodo de Execucao para as Diferentes Categorias de Alteracoes
4.1.4 Identificacao de Funcionalidades
O sistema de GA tem como objectivo principal gerir as alteracoes derivadas da Gestao do CC
do LIP. Para realizar este objectivo e necessario que este sistema disponibilize as seguintes
funcionalidades:
38 CAPITULO 4. PROPOSTA
• Criar novo pedido de alteracao. (Create New RfC )
O pedido de alteracao deve estar associado a:
– Item de Configuracao (IC)
– Requestador
– Executante(s)
– Categoria
– Prioridade
• Definir diferentes perfis de utilizador com permissoes e responsabilidades especıficas, no-
meadamente:
– Executante(s) - tem permissoes de visualizacao e modificacao parcelar de RfC relaci-
onados com tarefas sob a sua dependencia
– Coordenador - tem permissoes de visualizacao/modificacao de todos os RfC
– Requestador - pode unicamente visualizar o progresso (estado) do RfC que iniciou
• Permitir insercao de comentarios num dado RfC, por parte dos intervenientes na alteracao.
• Rejeitar, aceitar e testar um RfC.
• Definir perıodo de execucao de um RfC.
• Guardar um RfC.
• Consultar o registo historico de accoes efectuadas sobre um RfC.
• Definir o fluxo de informacao entre os varios intervenientes na alteracao.
• Visualizar metricas de desempenho utilizando um unico dashboard.
• Criar relatorios que contenham informacao sobre numero de pedidos de alteracao, numero
e percentagem de alteracoes, numero de pedidos rejeitados, numero de pedidos aprovados
e frequencia de mudanca de um dado IC.
• Definir procedimentos de retrocesso, caso uma alteracao cause problemas.
Na Figura 4.3 apresentam-se os casos de uso do sistema de GA. A descricao detalhada de
cada um dos casos de uso encontra-se no Apendice B, apresentando-se para cada um, os cenarios
principais e alternativos.
4.2. SISTEMA DE GESTAO DE CONFIGURACOES 39
Figura 4.3: Casos de Uso do Sistema de Gestao de Alteracoes.
4.2 Sistema de Gestao de Configuracoes
O estudo dos processos executados no interior do LIP mostrou que o fluxo de informacao e reali-
zado de forma inadequada, dada a quantidade de dados a manipular e os agentes envolvidos que
necessitam de aceder a essa informacao. Desta forma, mais do que um conjunto de tecnologias,
e necessario colocar em pratica um modelo comum de procedimentos e actividades que visem
centralizar a informacao, e agilizar a sua consulta ou alteracao de forma controlada.
O processo global de GC proposto para o LIP encontra-se representado na Figura 4.4, e e
constituıdo pelas actividades de:
• Planeamento: definicao do modelo de GC.
• Identificacao: responsavel por identificar a existencia de novas ocorrencias a introdu-
zir/remover na CMDB.
• Especificacao: constituıda por actividades que respondem a pedidos de alteracao estru-
turais da CMDB.
40 CAPITULO 4. PROPOSTA
• Controlo: constituıda por actividades que respondem a pedidos para alterar conteudos
da CMDB, nao envolvendo alteracoes estruturais na CMDB.
• Auditoria e Verificacao: constituıda por actividades que asseguram que os activos na
CMDB sao efectivamente os activos da instituicao.
As accoes constituintes da actividade de Planeamento sao mais orientadas ao inıcio do processo,
em que e necessario validar o proprio modelo adaptado para a CMDB e modifica-lo se necessario
for. As actividades de Identificacao, Especificacao, Controlo, Auditoria e Verificacao sao
constituıdas por accoes orientadas para a operacao diaria da infra-estrutura de computacao do
LIP, e em que o planeamento do modelo e posto a prova. Cada uma destas actividades encontra-
se descrita em detalhe na presente Seccao, e pressupoe a existencia de 2 papeis a desempenhar
na instituicao: Gestor da Configuracao, responsavel pela execucao das actividades de todas
as fases do sistema de GC, a excepcao das actividades da fase de Auditoria e Verificacao que
serao executadas pelo Auditor.
Figura 4.4: Fases do Processo de GC, Proposto para o LIP.
4.2. SISTEMA DE GESTAO DE CONFIGURACOES 41
4.2.1 Modelo de Actividades - Planeamento
A actividade de Planeamento ilustrada na Figura 4.5 e constituıda pela definicao dos IC, do
modelo para a CMDB e pelo fluxo operacional de implementacao da CMDB. Estes
tres aspectos sao enderecados por Baron et al. [28]
Figura 4.5: Fase de Planeamento da Configuracao Proposta para o LIP.
4.2.1.1 Definicao dos Itens de Configuracao
Os IC podem ser qualquer item que a organizacao queira gerir/controlar, incluindo itens in-
tangıveis tais como licencas, patentes, e itens de software e hardware. No caso especıfico do LIP,
o processo de GC pretende ser orientado a hardware com a agregacao da informacao sobre os
servidores de calculo, servidores de armazenamento e respectivas componentes, e dispositivos de
rede. A Tabela 4.3, esquematiza os varios tipos de IC (e seus atributos) identificados.
4.2.1.2 Modelo da CMDB e Fluxo Operacional de Implementacao
Segundo o modelo idealizado para a CMDB, o sistema deve ser composto por uma base de dados
com uma interface que permita ler, escrever e alterar os dados de configuracao armazenados.
Pretende-se que os dados da GC estejam organizados segundo um esquema (ver Figura 4.6) que
deve ter em conta os seguintes aspectos:
42 CAPITULO 4. PROPOSTA
AtributosItens de Configuracao
Gerais Particulares
Data de EntradaNomeData GarantiaModeloMarcaGrupoLocalizacaoNumero de SeriePart Number
MacAddress/Interfaces Rede
Servidor
IPsLocalizacao (Rack)Capacidade de MemoriaTipo(Armazenamento ouComputacao)MacAddress/Interfaces Rede
Controlador de ArmazenamentoIPCapacidade Caixas de ExpansaoCapacidade
DiscosLocalizacao (Servidor/Caixa de Expansao)MacAddress/Interfaces Rede
Router/SwitcherIPLocalizacao (rack)
Tabela 4.3: Tipos de ICs definidos para o LIP e seus atributos.
1. incluir uma entidade para registar os atributos dos IC (CI Attribute). Como esta entidade
esta separada das restantes entidades permite suportar qualquer tipo arbitrario de atributo
para um dado IC.
2. incluir uma entidade para rastrear relacoes entre IC (CI Relationship), o que possibilita o
suporte de complexas relacoes entre IC.
3. se possıvel, incluir entidades que agreguem informacao sobre procedimentos referentes ao
processo de GA e que levem a mudanca de atributos de IC. Convem referir que, dada a
complexidade inerente aos processos de GA e GC, ambos sao normalmente implementados
de forma independente nas instituicoes, e integrados a posteriori na CMDB atraves de
entidades especıficas que permitem relacionar um dado pedido de alteracao com dado IC.
O fluxo operacional na implementacao da CMDB implica:
1. Definir IC, tendo cada um ou mais atributos.
2. Guardar os atributos numa estrutura de dados (separada).
3. Identificar relacoes entre IC.
4. Guardar as relacoes identificadas numa estrutura de dados separada.
4.2.2 Modelo de Actividades - Identificacao
Apos o Planeamento, e segundo o modelo adoptado, segue-se a actividade de Identificacao,
que e responsavel por identificar a existencia de novas ocorrencias a introduzir na CMDB.
4.2. SISTEMA DE GESTAO DE CONFIGURACOES 43
Figura 4.6: Diagrama Entidade-Relacao (ER) Ilustrando um Esquema de Definicao dos IC naCMDB Proposto por Baron et al.[28]
O modelo pressupoe a possibilidade da informacao poder ser obtida/agregada atraves de fer-
ramentas (Discovery tools) que permitem obter de forma automatica informacao sobre novos
IC. No entanto, durante a operacao diaria da infra-estrutura, a insercao de um novo registo na
CMDB deve ter sempre origem a partir do sistema de GA.
A Figura 4.7 apresentas as diversas accoes envolvidas na fase de identificacao:
• 2.1) O Gestor da Configuracao identifica a existencia de novas ocorrencias a inserir/remover
da CMDB, como resultado das actividades de GA. Entre as ocorrencias possıveis temos:
1. Criar ou remover IC.
2. Criar ou remover atributos para um IC existente.
3. Criar ou remover instancias de IC existentes.
4. Modificar valores dos atributos de instancias dos IC.
44 CAPITULO 4. PROPOSTA
Figura 4.7: Fase de Identificacao da Configuracao Proposta para o LIP.
• 2.2) A priori, o processo da GA pode dar origem a qualquer tipo de ocorrencia (descrita
no ponto 2.1.), e o modelo deve estar adaptado para reagir em consonancia. A cada
nova ocorrencia, o Gestor da Configuracao deve avaliar o respectivo impacto na CMDB.
Ocorrencias do tipo 3 e 4 nao tem impacto estrutural no modelo adoptado para a CMDB
pelo que podem ser realizadas de imediato.
• 2.3) Ocorrencias do tipo 1 e 2 levam a alteracoes estruturais da CMDB, que uma vez
identificadas, levam a emissao de um RfC, e caso este seja aprovado, a actividade de
especificacao no processo de GC.
4.2.3 Modelo de Actividades - Especificacao
A actividade de Especificacao, ilustrada na Figura 4.8 e constituıda por accoes que respondem
a pedidos de alteracao estruturais da CMDB, permitindo que a mesma se adeque a um ambiente
em permanente mudanca, sendo o tipo de pedidos contemplados nesta fase os pedidos do tipo
1 e 2 da fase de Identificacao. Nesta fase pressupoe-se que a validacao do conteudo do pedido
ja foi executada durante o processo de GA pelo que a remocao de um IC inexistente, ou de um
atributo inexistente sao accoes que nao tem lugar durante esta actividade.
4.2. SISTEMA DE GESTAO DE CONFIGURACOES 45
Figura 4.8: Fase de Especificacao da Configuracao.
O processo de alterar o esquema da CMDB consiste nos seguintes passos:
• 3.1) O Gestor da Configuracao relaciona o IC com a baseline de configuracao.
• 3.2) O Gestor da Configuracao averigua se o IC existe na CMDB.
• 3.3) Caso nao exista, tem que alterar o esquema da CMDB de modo a suportar o novo IC
e os seus atributos e relacoes.
• 3.4) Caso o IC exista na CMDB, o Gestor da Configuracao avalia se se trata de um pedido
de remocao de um IC.
• 3.5) Se for um pedido de remocao, entao o Gestor da Configuracao remove o IC.
• 3.6) Se o IC existe e nao se trata de um pedido de remocao, o Gestor da Configuracao
averigua se e para remover ou criar atributos para esse IC.
46 CAPITULO 4. PROPOSTA
• 3.7) O Gestor da Configuracao cria os atributos do IC.
• 3.8) O Gestor da Configuracao remove atributos do IC.
4.2.4 Modelo de Actividades - Controlo da Configuracao
Na fase de Controlo da Configuracao (Figura 4.9), o Gestor da Configuracao responde a
pedidos para alterar conteudos da CMDB. O tipo de pedidos envolvidos nesta fase sao pedidos
do tipo 3 e 4 descritos na fase de Identificacao.
Figura 4.9: Fase de Controlo da Configuracao Proposta para o LIP.
• 4.1) O Gestor da Configuracao recebe um pedido para alterar conteudos na CMDB.
• 4.2) O Gestor da Configuracao avalia se o pedido e a criacao de uma nova instancia de um
IC.
• 4.3) Caso o pedido recebido nao seja para criar um instancia, o Gestor da Configuracao
avalia se se trata de um pedido para remover uma instancia.
• 4.4) O Gestor da Configuracao averigua se o pedido consiste na modificacao dos valores
dos atributos.
• 4.5) O Gestor da Configuracao cria uma nova instancia de um activo.
• 4.6) O Gestor da Configuracao remove a instancia.
• 4.7) O Gestor da Configuracao modifica o valor dos atributos do activo na CMDB.
4.2. SISTEMA DE GESTAO DE CONFIGURACOES 47
4.2.5 Modelo de Actividades - Auditoria e Verificacao
Na fase de Auditoria e Verificacao (Figura 4.10), realizada pelo Auditor realiza-se uma
comparacao entre os registos dos IC presentes na CMDB e os itens fısicos existentes.
Figura 4.10: Fase de Auditoria da Configuracao Proposta para o LIP.
Este sub-processo e constituıdo pelas seguintes accoes (figura 4.10):
• 5.1 O Gestor da Configuracao determina o ambito da auditoria.
• 5.2 O Gestor da Configuracao executa a auditoria (fazendo um rastreio do produto, usando
uma discovery tool, manualmente).
• 5.3 O Auditor avalia se existem diferencas entre os activos registados na CMDB e os activos
da instituicao.
• 5.4 Caso nao existam diferencas a auditoria termina.
• 5.5 Caso existam diferencas sao determinadas excepcoes e prioridades.
• 5.6 As diferencas dao origem a emissao de um novo RfC.
4.2.6 Identificacao de Funcionalidades
O sistema de GC tem como objectivo principal gerir da Gestao do CC do LIP. Para realizar este
objectivo e necessario que este sistema disponibilize as seguintes funcionalidades:
• introduzir/remover dispositivos de hardware de forma automatica e de forma manual.
• visualizar rede de dispositivos, suas relacoes e dependencias existentes.
48 CAPITULO 4. PROPOSTA
• visualizar eventos.
• criar relatorios que contenham informacao sobre desempenho e disponibilidade dos com-
ponentes informaticos.
• consultar o registo historico de accoes efectuadas sobre os dispositivos de hardware.
A Figura 4.11 apresenta os casos de uso do sistema de GC. A descricao de cada um dos
casos de uso, dos cenarios principais e alternativos encontra-se no Apendice C.
Figura 4.11: Casos de Uso do Sistema de Gestao de Configuracoes
Capıtulo 5
Concretizacao da Solucao
Para concretizar o sistema de GA e o sistema de GC no LIP, optou-se pela utilizacao de duas
tecnologias open-source: o Request Tracker (RT) e o Zenoss. O RT e utilizado para concre-
tizar o processo de GA e gerir o fluxo de trabalho na execucao de tarefas, e o Zenoss e utilizado
para concretizar o processo de GC.
Na presente seccao explica-se a escolha destas ferramentas e o modo como se adequam aos
modelos de GA e GC descritos nas Seccoes 4.1 e 4.2.
5.1 Request Tracker
O Request Tracker(RT), [29] e um sistema utilizado para coordenar tarefas e gerir solicitacoes
(pedidos) entre varios utilizadores. A primeira versao, editada em 1996, foi escrita por Jesse
James, que mais tarde formou a empresa Best Practical Solutions LLC para desenvolver e
distribuir o RT. Actualmente, encontra-se na versao 4.0 e e distribuıdo sob a licenca GNU
GPL [35]. O RT pode ser instalado sob as plataformas Unix, Linux, Windows e Mac OS e
pode interoperar com varias bases de dados: MySQL, POstgreSQL, ORACLE e SQLite. O RT
foi desenvolvido em Perl e pode utilizar os servidores Apache e web lighttpd [36] associado ao
modulo mod perl [37] e ao protocolo FastCGI [38] respectivamente.
No RT convencionou-se que cada pedido ou tarefa a executar e gerida atraves de um ou mais
tickets. A criacao e actualizacao de tickets pode ser levada a cabo atraves das varias interfaces:
1. uma plataforma web, disponıvel tanto para utilizadores registados como para utilizadores
convidados, facilmente configuravel que permite a adicao de campos personalizados. Pos-
sibilita a modificacao da interface web sem a necessidade de muito esforco e conhecimento,
utilizando o mecanismo de Callbacks. [39]
49
50 CAPITULO 5. CONCRETIZACAO DA SOLUCAO
2. uma interface de e-mail, muitas vezes a unica interface que alguns utilizadores convidados
tem permissoes para visualizar.
3. interface REST que permite o acesso a base de dados do RT a partir do exterior e cuja
comunicacao entre o cliente e a base de dados do RT se encontra encapsulada no protocolo
HTTP. O endereco URL base para todos os pedidos e: https://<localhost>/REST/1.0/.
4. uma CLI - Command Line Interface que permite manipular tickets e utilizadores numa
linha de comandos UNIX e melhor adaptada para tarefas de automatizacao e integracao
com outras ferramentas. Esta interface interage com o servidor do RT usando o protocolo
HTTP. [29]
Atraves de cada uma da interfaces anteriores, os utilizadores e administradores podem (de
acordo com as suas permissoes):
• Abrir um ticket.
• Atribuir tickets a pessoas (pessoas responsaveis pelos tickets).
• Rastrear alteracoes efectuadas a um ticket.
• Informar as partes interessadas sobre as alteracoes efectuadas ou sobre o estado de um ou
mais tickets.
• Accionar actividades baseadas na prioridade e/ou estado de um ticket.
• Encerrar ou fechar um ticket.
5.1.1 Arquitectura
A Figura 5.1 ilustra a arquitectura em camadas do RT, [29] que de forma sucinta consiste na
implementacao das seguintes camadas:
• Database : esta camada representa a capacidade que o RT possui de inter-operar com
varias bases de dados nomeadamente MySQL, POstgreSQL, ORACLE e SQLite.
• DBIx:Searchbuilder e a camada responsavel por estabelecer a ligacao entre uma
aplicacao orientada a objectos que e o caso do RT e a base de dados relacional adop-
tada.
5.1. REQUEST TRACKER 51
Figura 5.1: Arquitectura do RT [29].
• RT core libraries. O RT possui dois tipos principais de livrarias:
– RT application platform libraries - livrarias responsaveis, por exemplo, pela
conectividade a base de dados, pelo controlo de acessos, ligacoes e infra-estrutura de
registos.
– RT ticketing system libraries - livrarias que providenciam funcionalidades
proprias de um sistema de ticketing.
• Mason handler e um wrapper para o sistema Mason [42], uma framework para a cons-
trucao de aplicacoes web escrita em Perl. O Mason pode ser usado com o servidor
Apache HTTP via mod perl (para o qual o Mason providencia o seu proprio handler:
HTML::Mason::ApacheHandler) ou ainda ser usado no servidor lighttpd.
• HTTP Clients. O RT tem tres clientes HTTP que sao o Web Browser, Email gateway
e a CLI (Command-Line Interface).
5.1.2 Modelo Logico
O Modelo Logico do RT apresentado na Figura 5.2 e constituıdo por duas partes principais: uma
que e responsavel por gerir os utilizadores e as as suas permissoes, para assim poderem actuar
no sistema, e outra responsavel pela funcionalidades proprias de um sistema de Ticketing. A
unidade basica administrativa existente e a Fila (Queue), cuja estrutura permitir implementar
um fluxo de trabalho a ser realizado por varios intervenientes: as Filas sao contentores nos quais
se agrupam os tickets, se podem definir grupos de trabalho e definir condicoes e accoes a realizar
por diferentes intervenientes.
52 CAPITULO 5. CONCRETIZACAO DA SOLUCAO
Figura 5.2: Modelo Logico do RT.
O Modelo e a sua descricao podem ser consultados no Apendice D.
5.1.3 Razoes da Adopcao do Request Tracker
O RT foi adoptado pois e uma ferramenta amplamente utilizada na comunidade para gestao
e controlo de tarefas, tanto em ambientes integrados, como em ambientes geograficamente dis-
tribuıdos. Existe um bom suporte e apoio a configuracao, devido a vasta documentacao existente
e ampla comunidade de utilizadores. A sua estrutura bastante generica permite que o RT seja
configurado de acordo com os workflows e casos de uso necessarios para uma dada organizacao.
Para alem das vantagens enunciadas, o RT possibilita satisfazer a maioria dos requisitos no
contexto do LIP:
1. Cumpre requisitos de negocio: o RT e uma ferramenta open-source, que possui um meca-
nismo de notificacoes e que permite informar todas as partes envolvidas sobre o estado de
uma tarefa. E possıvel notificar atraves de email e sms, os varios intervenientes no desen-
rolar de actividades decorrentes da execucao de tarefas. Ou seja, cumpre os requisitos de
negocio R01 e R03 definidos.
2. Cumpre requisitos nao funcionais: o RT possui como caracterıstica um mecanismo de
5.1. REQUEST TRACKER 53
ACL (Access Control Lists) implementando diferentes permissoes para diferentes tipos de
utilizadores, isto e, utilizadores diferentes terao diferentes direitos de actuacao no sistema.
Este mecanismo permite satisfazer os requisitos nao funcionais R05 e R06 definidos. No
RT, a autenticacao no sistema e efectuada via login/password, permitindo satisfazer o
requisito R04.
3. Cumpre requisitos funcionais: o RT permite definir fluxos de trabalho entre varios in-
tervenientes, e registar essa informacao na sua base de dados, permitindo satisfazer os
requisitos R07 e R08. E uma ferramenta extremamente adaptavel as preferencias de uma
organizacao:
• o seu modelo de dados generico permite uma categorizacao segundo a utilizacao que
uma organizacao pretenda.
• O workflow e a logica de negocio que uma organizacao precisa, pode ser ensinada ao
RT.
O RT permite procurar tickets, segundo uma forma pre-estabelecida no interface web, ou
usando um query language denominada TicketSQL, possibilitando ao utilizador a definicao
da sua pesquisa, sendo assim cumprido o requisito R10. A partir desta funcionalidade
simples, o RT permite a definicao de Dashboards, ou seja, uma coleccao de informacao
obtida atraves de pesquisas pre-definidas. Desta forma, os administradores e utilizado-
res podem ser notificados periodicamente (diariamente, mensalmente) sobre o estado e o
numero de tickets numa determinada queue. O RT permite ainda a geracao on demand
de graficos (ver Figura 5.3), demonstrativos da evolucao das diversas tarefas ao longo do
tempo e do esforco comprometido na sua resolucao. Todas estas funcionalidades permitem
concretizar o requisito R11.
Figura 5.3: Numero e Estado de Tickets Existentes na Fila Hardware Change Request Criadosa Partir de 13 Janeiro de 2011.
54 CAPITULO 5. CONCRETIZACAO DA SOLUCAO
5.1.4 Configuracao do Request Tracker
Nesta Seccao apresenta-se como o processo de GA definido na Seccao 4.1 foi concretizado usando
o RT.
5.1.4.1 Ticket Actuando como RfC
Para a concretizacao do sistema de GA foi necessario ajustar funcionalidades do RT, e esta-
belecer convencoes que se adaptem ao formalismo de um pedido de alteracao, e as actividades
do processo. Uma das principais convencoes baseia-se na correspondencia entre um pedido de
alteracao e um ticket RT numa fila que visa alteracoes na infra-estrutura de hardware, sendo
por isso imediato que todas as alteracoes serao actividades sobre atributos de varios dispositi-
vos de hardware. O formulario de preenchimento destes tickets RT com campos pre-definidos
(CustomFields), foi desenvolvido de forma a satisfazer todos os requisitos que devem constar
num pedido de alteracao. Adicionalmente e possıvel explicitar sobre que item de configuracao
e sobre que atributo do item de configuracao vai ser executada a alteracao. Entre os principais
atributos a preencher temos informacao especıfica dos dispositivos tais como a sua identificacao,
localizacao, fabricante e tipo de produto, proprietario, entre outros.
A Tabela 5.1 sumariza os campos que constam no formulario de um ticket RT:
Formalismo RfC Ticket RT Preenchimento
Numero do RfC Ticket Id Automatico
Data de Criacao Created Automatico
Data Prevista Inıcio Starts Automatico
Data Inıcio Started Automatico
Data Prevista Fim Due Automatico
Descricao Subject Manual/Obrigatorio
Prioridade Priority Automatico
Urgencia Urgency Manual/Obrigatorio
Categoria Nıvel 1 Category level1 Manual/Obrigatorio
Categoria Nıvel 2 Category level2 Manual/Obrigatorio
Tipo da Alteracao Change Type Manual/Obrigatorio
Nome do Dispositivo Device Name Manual/Obrigatorio
Tipo de Dispositivo Device Type Manual/Obrigatorio
Tabela 5.1: Relacao entre Pedido de Alteracao e Ticket.
5.1. REQUEST TRACKER 55
Observacoes importantes relativamente aos campos existentes no ticket RT:
• Category level1
Indica se a categoria da alteracao e Standard ou Non standard.
• Category level2
Se a categoria da alteracao escolhida for do tipo Non Standard, entao este campo permite
indicar se a alteracao e Principal, Significante ou Menor. Se a categoria for Standard este
campo nao e aplicavel. A categorizacao da alteracao impoe uma data prevista para o fim
(Due) da tarefa.
• Urgency
A urgencia de uma alteracao pode ser classificada em: Not Urgent, Less Urgent, Urgent,
Very Urgent e Top Priority.
• Priority
A prioridade de uma alteracao depende da urgencia:
– caso uma alteracao seja classificada como Not Urgent a prioridade estabelecida e de
10/100.
– caso uma alteracao seja classificada como Less Urgent a prioridade estabelecida e de
30/100.
– caso uma alteracao seja classificada como Urgent a prioridade estabelecida e de
50/100.
– caso uma alteracao seja classificada como Very Urgent a prioridade estabelecida e de
70/100.
– caso uma alteracao seja classificada como Not Urgent a prioridade estabelecida e de
90/100.
• Due
Na Seccao 4.1.3 foram estabelecidos tempos de implementacao de tarefas de acordo com a
categoria de uma alteracao. Tal e concretizado no RT, no campo Due (Data Prevista do
Fim), que de acordo com a categoria da alteracao (Change Category (level 2) - Principal,
Significante, Menor) estabelece que a data prevista para o fim da tarefa sera 30, 14 e 3
dias uteis respectivamente.
• Change Type
No RT, foram configurados tres Tipos de Alteracao:
1. Add Hardware - alteracao que visa a introducao de um novo dispositivo de hardware
(nova instancia).
2. Change Hardware - alteracao que visa a modificacao de valores dos atributos de um
dispositivo de hardware existente.
56 CAPITULO 5. CONCRETIZACAO DA SOLUCAO
3. Maintain Hardware - alteracao que visa operacoes de manutencao de hardware ja
existente
• Device Name - Nome do dispositivo de hardware sobre o qual incide a alteracao
• Device Type - Tipo de dispositivo de hardware tais como: servidores, controladores de
armazenamento, caixas de expansao, discos, routers e switchers de acordo com o definido
na Tabela 4.3, Seccao 4.2.1.1.
5.1.4.2 Fluxo de Tarefas (Workflows)
Uma alteracao e constituıda por um conjunto de tarefas, independentes ou dependentes entre
si, realizadas por um ou mais intervenientes e que passa por varios estados, desde a sua criacao
ate a sua resolucao.
Um conceito importante no RT, e a definicao de transaccao, que representa um conjunto
de alteracoes efectuadas sobre um ticket. No contexto de uma transaccao, (ou seja, quando
um dado campo de um ticket e alterado), e possıvel definir accoes executadas em resposta a
dadas condicoes (Scrips). No modelo adoptado, tira-se partido desta funcionalidade do RT para
definir uma hierarquia de trabalho, e dependencia entre tarefas. Desta forma, nos tickets na
fila para gestao de alteracoes existem campos que dizem respeito a um conjunto de actividades
paralelas que necessitam de ser executadas visando o objectivo final.1. A execucao destas tarefas
e desencadeada atraves de campos especıficos do ticket, que quando accionados geram tickets
filhos, criando uma dependencia para com o ticket original: o ticket pai nao pode ser resolvido
sem que os tickets filhos sejam solucionados.
Na Figura 5.4 apresenta-se o template de um ticket no RT, onde constam campos referentes
ao pedido de alteracao, campos que descrevem o item de configuracao e campos especıficos
que quando accionados levam a execucao de um fluxo de trabalho previamente configurado. O
template deste ticket, e ainda apresentado no Apendice E.
1Na figura que ilustra o ticket, os campos que representam as tarefas a serem efectuadas sao: Configure DNS,Configure Nagios, Configure OS, Configure Amanda, Configure UPS, Configure Syslog
5.1. REQUEST TRACKER 57
Figura 5.4: Template de um Ticket no RT Configurado para Efectuar uma Alteracao.
5.1.4.3 Ciclo de Vida de um Ticket
De seguida enumeram-se os pontos chave, do ciclo de vida de um ticket :
58 CAPITULO 5. CONCRETIZACAO DA SOLUCAO
1. um pedido de alteracao e um ticket. O formulario inerente a um pedido de alteracao e
implementado atraves do preenchimento de um formulario web, com campos obrigatorios
ou automaticos de acordo com as escolhas do utilizador. Entre as mais importantes temos:
• a categoria de uma alteracao e obtida atraves da criacao de dois campos denominados
Change Category 1 e Change Category 2.
• a caracterizacao de um IC (e dos seus atributos) e realizada atraves da insercao de
campos em tickets agrupados numa fila.
• a urgencia e a prioridade
2. relacoes ente tickets permitem definir hierarquia e dependencia de tarefas para realizar
uma alteracao.
3. o preenchimento de certos campos de um ticket despoletam accoes (Scrips) que podem ser
a criacao de tickets filhos e notificacoes de utilizadores para a realizacao de sub-tarefas.
As Figuras 5.1.4.3, 5.1.4.3 e 5.1.4.3 explicam como um ticket e gerido durante o seu ciclo
de vida quando na instituicao se pretende efectuar uma alteracao que visa a instalacao de novo
Hardware, ou seja, uma alteracao cuja categoria e do tipo AddHardware.
5.1. REQUEST TRACKER 59
Ticket Template in Queue Hardware Change Request FASE DO PROCESSO RfC
1. Criação 2. Classificar e Avaliar RFC
RESPONSABILIDADE Owner Owner
INFORMAÇÃO MÍNIMA A SER PREENCHIDA E VALIDADA* (De acordo com o processo proposto para o LIP)
• Urgency • Starts (Automática) • Priority (Automática) • Subject • Change Category Level 1 • Change Category Level 2 • Change Type = Add Hardware • Device Name
STATUS New New WORKFLOW 1
CONDIÇES, ACÇÕES (Scrips) Scrip33: Change Priority according to Urgency Quando o Owner do Ticket preenche o campo Urgency, é estabelecido a prioridade da Alteração (Priority) Scrip34: Change Due Data according to Change Category Quando o Owner do Ticket preenche o campo Urgency, é estabelecido a data de início prevista para a alteração (Starts)
Figura 5.5: Ciclo de Vida um Ticket no RT - Parte 1
60 CAPITULO 5. CONCRETIZACAO DA SOLUCAO
Ticket Template in Queue Hardware Change Request FASE DO PROCESSO RfC
3. Autorizar a Alteração
4. Implementar Alteração
RESPONSABILIDADE Owner Executantes
INFORMAÇÃO A SER PREENCHIDA E VALIDADA (De acordo com o processo proposto para o LIP)
• Device Type • HWManufacturer • HWProduct • Part Number • Serial Number • Purchase Date
(Warranty) • Entry Date • Ownership • Location • Require Services:
(DNS, OS, Nagios, Amanda, Syslog, UPS Configuration)
• Completed Configure DNS
• Completed Configure OS
• Completed Configure Nagios
• Completed Configure Amanda
• Completed Configure Syslog
• Completed Configure UPS
(Após conclusão da tarefa)
STATUS open open WORKFLOW (cont.)
Figura 5.6: Ciclo de Vida um Ticket no RT - Parte 2
5.1. REQUEST TRACKER 61
Ticket Template in Queue Hardware Change Request FASE DO PROCESSO RfC
3. Testar a Alteração
4. Aceitar/Rejeitar a Alteração
RESPONSABILIDADE Owner Owner
INFORMAÇÃO MÍNIMA A SER PREENCHIDA E VALIDADA (De acordo com o processo proposto para o LIP)
Nada a registar • Se alteração aceite, nada a registar
• Comments (Se alteração não aceite, registar a razão)
STATUS testing resolved, rejected WORKFLOW (cont.)
CONDIÇES E ACÇÕES Scrip 29: Write XML template Quando o owner, aceita a alteração, o estado do ticket é alterado para resolved. Nesta altura é efectuada uma acção que cria um ficheiro XML com a descrição do novo dispositivo de Hardware.
Figura 5.7: Ciclo de Vida um Ticket no RT - Parte 3
62 CAPITULO 5. CONCRETIZACAO DA SOLUCAO
5.1.4.4 Insercao das Alteracoes na Gestao de Configuracoes
Um dos maiores desafios consistiu na definicao de uma estrategia que possibilite a interopera-
bilidade entre o processo de GA e GC. As alteracoes sobre determinado IC sao disponibilizadas
segundo um formato XML, gerado apos a resolucao do pedido de alteracao. Com o fecho de um
ticket, e despoletada uma accao que visa disponibilizar o registo da alteracao num servidor web
a ferramenta de GC num formato bem determinado. No Apendice B, apresenta-se a tıtulo de
exemplo a estrutura do ficheiro XML, que e gerado e onde consta a descricao do novo activo que
deve ser inserido na base de dados, pelo processo de GC.
A ferramenta de GC e capaz de aceder a esses conteudos, valida-los e de forma automatica
registar essa informacao relevante.
5.2 Zenoss
O Zenoss (Zenoss Core) [34] e um sistema para gestao de servidores e redes open source, ba-
seado no servidor de aplicacoes Zope (Zope [43] e um servidor, open source lancado em 1998,
de aplicacoes web orientado a objectos e escrito em Python). Como ilustrado na Figura 5.8,
atraves de um interface web, o Zenoss permite a gestao e configuracao do inventario (o Zenoss
monitoriza toda a infra-estrutura de TI, incluindo a rede, os servidores, os sistemas de aque-
cimento, ventilacao, ar condicionado e ate mesmo aplicacoes de software), a monitorizacao do
desempenho e da disponibilidade, e a gestao de eventos.
O desenvolvimento do Zenoss comecou em 2002 e em Agosto de 2005 a empresa Zenoss,
Inc foi fundada. Alem da versao Zenoss Core que e gratuita, a empresa vende a versao Zenoss
Enterprise baseada na versao Core.
O Zenoss possibilita um inventario actualizado dos equipamentos, e simultaneamente deduzir
o seu estado atraves da monitorizacao do seu desempenho e da sua disponibilidade. E portanto
uma ferramenta adequada para a gestao de um CC complexo e em constante mudanca.
5.2.1 Monitorizacao Orientada ao Modelo de Configuracao
Como ilustrado na Figura 5.9, a monitorizacao orientada ao modelo, efectuado pelo Zenoss,
inicia-se com a descoberta dos recursos existentes na infra-estrutura de TI (discover) [30],
que preenche o modelo da Base de Dados (IT Configuration Database)2 (model). A este mo-
delo construıdo e aplicado uma configuracao pre-definida (config) e a monitorizacao comeca
(monitor). Esta configuracao inicial pode contudo ser posteriormente afinada (tune).
2No modelo da base de dados constam os recursos descobertos, constituıdos por um inventario completo dosservidores, redes e aplicacoes de software existentes, ate ao nıvel de detalhe dos interfaces, servicos, processos, esoftware instalado existente.
5.2. ZENOSS 63
Figura 5.8: Vista de Alto Nıvel do Zenoss [34].
Figura 5.9: Workflow: Monitorizacao Orientada ao Modelo de Configuracao [34].
5.2.2 Principais Funcionalidades
As funcionalidades principais fornecidas pelo Zenoss (Core) sao:
• Visao exacta e em tempo real dos dispositivos, das redes e das dependencias e relacoes
existentes na infra-estrutura de TI:
1. o Zenoss encontra e identifica os dispositivos e redes (de forma manual e automatica),
e posteriormente constroi um mapa da rede (ver Figura 5.10).
2. possibilita estabelecer relacoes entre dispositivos e estabelecer ligacoes entre eles.
• Medir a disponibilidade de dispositivos de hardware (servidores, routers, etc.), e dos
servicos por eles providenciados (servicos de mail, web, transferencia de arquivos).
• Possibilidade de medir o desempenho usando metodos como o SNMP, WMI, comandos de
shell, e API. Apos efectuar a recolha dos dados, analisa-os de acordo com limites definidos
pelo utilizador, e disponibiliza-os atraves de graficos e relatorios.
64 CAPITULO 5. CONCRETIZACAO DA SOLUCAO
• Monitorizacao da gestao de eventos resultantes da ocorrencia de problemas provenientes
dos dispositivos. Atraves de um mecanismo de notificacoes e escalonamento, as pessoas
responsaveis pela sua resolucao apercebem-se do estado desses mesmos problemas.
• Fornece relatorios resultantes do cruzamento de informacao entre objectos e com varios
formatos e conteudos.
Figura 5.10: Mapa de Rede.
5.2. ZENOSS 65
Figura 5.11: Arquitectura em Camadas do Zenoss.
5.2.3 Arquitectura
A Figura 5.11 ilustra a arquitectura do Zenoss [32], constituıda por quatro camadas:
1. Coleccao - Collection Layer : compreende os servicos que coleccionam os dados para a
camada de dados. Estes servicos sao prestados por daemons que executam funcoes de
gestao de modelacao, monitorizacao e eventos.
2. Processamento - Processing Layer : camada responsavel pela gestao das comunicacoes entre
a camada dos dados e a camada responsavel por coleccionar os dados (Collection Layer).
3. Dados - Data Layer : A informacao relacionada com a configuracao e coleccao e guardada
nesta camada em 3 bases de dados separadas.
(a) ZenRRD - dados de desempenho dos sistema monitorizados.
ZenRRD utiliza RRDTool, um sistema de base de dados round-robin criado por
Tobias Oetiker sob a licenca GNU GPL. Foi desenvolvido para armazenar series de
dados numericos sobre o estado de redes de computadores, porem pode ser utilizado
no armazenamento de qualquer outra serie de dados como temperatura, uso de CPU,
etc. O RRD e um modo abreviado de se referir a Round Robin Database (base de
dados round-robin). O RRDTool tambem pode produzir graficos que permitem ter
uma ideia visual dos dados armazenados, os quais podem ser utilizados ou exibidos
por outros sistemas. A ferramenta Cacti e um outro exemplo disso, para alem do
Zenoss.
(b) ZenModel - Constitui o modelo nuclear da configuracao, constituıda por dispositivos e
pelas suas componentes, grupos e localizacoes. Este modelo sera explicado em detalhe
na Seccao 5.2.4.
(c) ZenEvents - Base de dados MySQL com os eventos gerados.
66 CAPITULO 5. CONCRETIZACAO DA SOLUCAO
4. Utilizadores -User Layer : Esta camada e um portal web no qual o utilizador pode realizar
as funcoes descritas na Seccao Funcionalidades.
5.2.4 Modelo
De seguida descreve-se o Modelo de Domınio do Zenoss (ver Figura 5.12), o qual permite carac-
terizar o equipamento de hardware e tambem o software existente numa instituicao/empresa.
Figura 5.12: Modelo de Domınio do Zenoss.
5.2. ZENOSS 67
1. Um dispositivo (device) e o objecto principal de monitorizacao no sistema. E definido
como uma combinacao de elementos de varias classes, entre as quais as de hardware e soft-
ware. Exemplos de dispositivos sao: servidores, routers, switchers. Todos os dispositivos
tem atributos proprios que os caracterizam: Device Name, Serial Number, IP Address,
Rack slot, Tag, Production State, Priority, Collector, Uptime, First Seen, Last Change,
Model Time, Locking, Memory Swap, Comments
2. Tanto os elementos de hardware como de software sao tambem eles classes de produtos,
com atributos proprios. Desta forma um produto e caracterizado pelos seguintes atributos:
um tipo (Hardware ou Software), Name, Manufacturer Name, Description, Part Number.
3. A classe software tem como atributos: Name, Manufacturer Name, e Installation Date.
4. Todo o dispositivo do sistema pertence a uma Device Class, um tipo especial utilizado
pelo zenoss para gerir como o sistema modela e monitoriza os dispositivos. Pertencendo a
uma device class, um dispositivo herda propriedades comuns a essa classe.
5. Event Class permitem obter informacao sobre o estado dos dispositivos. Esta informacao
e posteriormente guardada na base de dados ZenEvents.
6. Process Class [31] permite a definicao dos processos a monitorizar no sistema e a recolha
da informacao do desempenho e disponibilidade dos processos monitorizados na base de
dados ZenRRD
7. O Zenoss disponibiliza duas classes que permitem organizar os dispositivos da forma como
o utilizador ache adequada a sua funcionalidade. Essas duas classes sao a dos Grupos
(Groups) e Sistemas (Systems)
8. Location class permitem indicar o local do dispositivo.
Efectuando um paralelismo entre o diagrama entidade relacao que ilustra um esquema de
definicao de IC na CMDB proposto por baron et al. [28], Seccao 4.2.1 e o modelo de domınio
da CMDB do Zenoss podemos constatar que:
• um Configuration Item e um Device
• os atributos dos itens de configuracao (CI Attribute, Attribute, Attribute Type) correspon-
dem no Zenoss as seguintes classes: Location, System, Group, hardware, OperatingSystem.
• As relacoes entre IC (CI relationship) tambem existem no Zenoss, pois e possıvel estabe-
lecer relacoes entre devices.
Como se pode observar, o modelo oferecido pelo Zenoss permite ser adoptado para caracterizar
um activo com os atributos previamente identificados e constantes definidos aquando da fase de
Planeamento Seccao 4.2.1.
68 CAPITULO 5. CONCRETIZACAO DA SOLUCAO
5.2.5 Razoes da Adopcao do Zenoss
O Zenoss possibilita satisfazer os requisitos definidos pelo LIP, e constantes na Seccao 3.3 e
permite ser utilizado para manter os activos da instituicao e ser integrado com o sistema da
Gestao de Alteracoes. A parte relativa a integracao encontra-se descrita na Seccao abaixo. (Ver
tambem Seccao 5.1.4.4)
5.2.6 O Zenoss como Gestor de Configuracoes no LIP
Larry Klosteboer [33] indica duas abordagens que podem ser utilizadas para introduzir os dis-
positivos na CMDB: a primeira abordagem (waterfall) consiste em reunir o maximo de dados
possıveis de todo o ambiente e depois integrar e ligar os dados, obtendo assim um sistema de
GC completo. Esta e uma abordagem mais directa e activa mas quase sempre resulta numa
quantidade de dados muito elevada, o que torna a conclusao desta tarefa demorada. A segunda
abordagem (trickle) consiste em criar pontos de integracao em cada uma das areas-chave de
processos operacionais que possam lidar com os dados de configuracao.
Executando operacoes normais com estes pontos de integracao, os dados dos itens de con-
figuracao (IC) sao introduzidos na CMDB na medida em que vao sendo alterados ou a medida
que vao causando incidentes. Esta e uma abordagem muito menos arriscado, mas que atrasa
os benefıcios de ter uma imagem completa de gestao de configuracao. De acordo com o modelo
proposto para o processo de GC, a segunda abordagem de Larry Klosteboer foi adoptada: uma
modificacao de um dado IC ao abrigo do processo de GC surge sempre em resultado de um
pedido de alteracao certificado e aprovado, sendo posteriormente essa informacao (dados dos
itens de configuracao, IC e atributos) introduzida na base de dados do Zenoss.
5.2.7 Modelo de Actividades do Processo de GC e sua Concretizacao no
Zenoss
Identificacao, Especificacao e Controlo da Configuracao
O Zenoss fornece um modelo de domınio para o repositorio de itens de configuracao bastante
ajustado ao contexto deste trabalho. Apesar de ser possıvel estender este modelo com a criacao
inicial de novas classes de objectos, assume-se que essa necessidade surge naturalmente com o
decorrer das actividades de Identificacao e Especificacao de Configuracoes. Desta forma, cabe
ao Gestor de Configuracoes percorrer todas as actividades propostas para o processo de GC,
e avaliar de forma criteriosa que etapas devem ser levadas a cabo em cada actividade. Caso
seja verificada a necessidade de estender o modelo de domınio, o Zenoss proporciona metodos
(Zenpacks) de estender as funcionalidades da ferramenta, nomeadamente a criacao de novas
classes de objectos e metodos de monitorizacao dos mesmos.
5.2. ZENOSS 69
A actividade de Controlo da Verificacao deve apenas ser desencadeada pelo Gestor de Con-
figuracoes depois de se assegurar (percorrendo as outras actividades propostas) que nao existem
incoerencias entre a informacao que se pretende adicionar/modificar/remover e os conteudos da
CMDB.
A insercao da informacao no Zenoss pode ser levada a cabo de tres formas:
1. atraves do interface grafico
2. atraves do interpretador interactivo executado na linha de comando, denominado Zendmd
3. atraves de uma API dedicada
De forma a automatizar o processo de insercao de conteudos no Zenoss, desenvolveu-se uma
aplicacao em python que recorre as funcionalidades disponibilizadas pela API do Zenoss. A
aplicacao e presentemente capaz de inserir conteudos XML (ver Seccao 5.1.4.4) disponibilizada
pelo RT via http. O Gestor de Configuracao pode, de forma simples e semi-automatica, executar
a aplicacao na linha de comandos para iniciar ligacoes a base de dados e inserir novos dispositivos.
Como desenvolvimentos futuros pretende-se:
• estender a aplicacao para a remocao e modificacao de itens de configuracao.
• estender a aplicacao para a validacao automatica de conteudos, dando uma vertente au-
tomatica as actividades de Identificacao e Especificacao de Configuracao.
• a automatizacao da execucao da aplicacao, (varias vezes ao dia), alertando o Gestor de
configuracao sempre que exista a ocorrencia de problemas
Auditoria
A propria ferramenta Zenoss pode desencadear a actividade de Auditoria tendo em contas as
capacidades de descobrir e monitorizar dispositivos.
O Zenoss possibilita varias formas de descobrir/introduzir dispositivos e as suas compo-
nentes. O metodo mais simples e manualmente (manual discovery), atraves do interface do
utilizador, e aı o Gestor de Configuracoes pode especificar os varios atributos do dispositivo.
Esta solucao contudo quando se pretende introduzir um numero elevado de dispositivos nao e
a mais adequada. Uma outra forma de descoberta possıvel a utilizar, e indicar uma rede, e o
Zenoss consegue descobrir todos os dispositivos existentes nessa rede.
70 CAPITULO 5. CONCRETIZACAO DA SOLUCAO
Figura 5.13: Graficos de Desempenho Disponibilizados pelo Zenoss.
No Zenoss existe o conceito de evento, e que representa uma manifestacao de uma ocorrencia
importante no sistema. Os eventos podem ser gerados internamente (ex: quando um limite es-
tabelecido e ultrapassado) durante o processo de descoberta e monitorizacao, ou externamente,
(atraves de mensagens no syslog ou de armadilhas SNMP) capturadas por deamons especializa-
dos do Zenoss.
Aos eventos podem associar-se regras dedicadas que controlam como os eventos sao mani-
pulados assim que entram no sistema. Entre as regras e accoes possıveis de configurar, temos
as regras de alerta que permitem enviar emails ao administrador de sistema ou mesmo iniciar a
execucao de scrips pre-configuradas que minimizam o impacto de uma alerta.
Apos o processamento dos eventos (cujo historial e mantido separadamente numa base de
dados MySQL), sao apresentados sob a forma de uma consola de eventos na interface web. Os
varios estados possıveis para um evento sao: Critical, Error, Warning, Info, Debug e Clear.
Capıtulo 6
Avaliacao
Neste capıtulo sao discutidos os resultados atingidos avaliando-se se as questoes de investigacao
colocadas na Seccao 1.2 se encontram respondidas.
Questao 1: Como desenhar o processo de GA para permitir, de uma forma
comum e coerente, gerir as alteracoes na infra-estrutura fısica, de rede e de servicos
do CC?
Foi proposto um processo de GA, de acordo com a framework ITIL, tendo-se estabelecido
quais as suas principais actividades, quais os responsaveis pela sua execucao e quais os criterios
de categorizacao. Foram identificadas as principais funcionalidades de um sistema de GA que im-
plementa o processo proposto, e que esteja alinhado com as praticas comuns e com os principais
procedimentos da instituicao onde se insere.
Para poder desenhar o sistema de GA foi necessario o conhecimento da instituicao LIP:
saber o contexto no qual se enquadra e como sao efectuados os principais procedimentos no seu
CC.
Questao 2: Como desenhar o processo de Gestao de Configuracoes e a CMDB,
para que as informacoes sobre a infra-estrutura, assim como as relacoes entre os
seus diversos itens, sejam conhecidas, estejam globalmente acessıveis e num estado
actualizado?
Foi proposto um sistema de GC, definidas as principais actividades, quais os seus interveni-
entes e principais responsabilidades. Foram identificados os activos da instituicao que terao que
ser mantidos na CMDB, e qual o fluxo de implementacao da CMDB.
Questao 3: Que ferramentas podem ser utilizadas e de que forma podem ser
adaptadas para concretizarem os processos de Gestao de Alteracoes e de Gestao de
Configuracoes?
O sistema de GA foi concretizado atraves da ferramenta RT. A sua grande capacidade de
71
72 CAPITULO 6. AVALIACAO
ajuste a ambientes heterogeneos, a sua flexibilidade na configuracao de workflows, e a sua facili-
dade de configuracao permitiu a implementacao do processo de GA alinhado com a framework
ITIL. Apos a devida configuracao, as funcionalidades da ferramenta permitem satisfazer os re-
quisitos os requisitos apresentados na Seccao 3.3, e agora comparados na Tabela 6.1.
Requisito Caracterısticas do RT
Negocio1. Sistema desenvolvido utilizando * open-source, licenca GNUferramentas open-source GPL
2. Fluxo de informacao baseado num *Notificacoes via: email, smssistema de notificacoes entre os scripsvarios intervenientes
Nao Funcionais 1. Restricao e acesso Controlado *Sistema multiutilizador commecanismo de autenticacao
Funcionais1. Planeamento de intervencoes sobre *Permite adaptar o workflowcomponentes informaticos (adicao, as preferencias do utilizadorsubstituicao e remocao) *Permite criar relacoes de
dependencias entre tarefas
2. Registo de accoes efectuadas sobre *Capacidade de rastrear ocomponentes informaticos incluindo historico, Gestao deintervencoes de manutencao dependencias
3. Efectuar procuras sobre as accoes *TicketSQL Query Languageefectuadas sobre determinadocomponente
4. Elaborar relatorios e estatısticas *Dashboards,que possibilitem obter metricas para *Extensao RTX::Statisticsos varios componentes informaticos da *Graficos: on demandinstituicao
Tabela 6.1: As Caracterısticas do RT Permitem Satisfazer os Requisitos de Negocio, Funcionaise Nao Funcionais estabelecidos.
73
O Sistema de GC foi concretizado utilizando a ferramenta Zenoss. O seu modelo revelou-se
adequado ao contexto a implementar na instituicao, e as suas funcionalidades de monitorizacao
e auditoria revelaram-se uma mais valia na implementacao do processo de GC. A comparacao
das caracterısticas do Zenoss com os requisitos propostos encontra-se explicada na Tabela 6.2.
74 CAPITULO 6. AVALIACAO
Requisito Caracterısticas do Zenoss
Negocio1. Sistema desenvolvido utilizando * Versao Zenoss Core gratuitaferramentas open-source
2. Fluxo de informacao baseado num * Existencia de regras desistema de notificacoes entre os notificacao (notificacaovarios intervenientes por email e sms) que podem
ser definidas na ocorrenciade eventos definidos
Nao Funcionais 1. Autenticacao via login/password * Sistema multiutilizador commecanismo de autenticacao
2. Administrador com permissoes para * Manager : detem todos oscriar, apagar e manipular informacao em privilegios, ZenUser :todos os modulos do sistema permissoes de visualizacao
da informacao
Funcionais
3. Registo de accoes efectuadas sobre * Rastrear alteracoes feitascomponentes informaticos aos eventos, Controle de
alteracoes feitas amonitorizacao dos servicos
4. Registo de accoes realizadas pelos * Multiutilizador, Capacidadeutilizadores e pelo administrador de rastrear o historico dasdo sistema alteracoes
5. Efectuar procuras sobre as accoes * Procuras por dispositivo,efectuadas sobre determinado (nome, endereco IP)componente
6. Elaborar relatorios e estatısticas * Relatorios: do inventario global,que possibilitem obter metricas para do historico com as alteracoesos varios componentes informaticos da na rede, com os detalhes dosinstituicao dispositivos, dos problemas e da
disponibilidade da redeexistencia de graficos que avaliamdesempenho dos dispositivos(CPU, Free Memory)
7. Inventario actualizado do equipamento * Possui base de dados com umde hardware existente no LIP modelo do inventario e detalhes
de configuracao, capacidade dedescoberta automatica dedispositivos
Tabela 6.2: As Caracterısticas do Zenoss Permitem Satisfazer os Requisitos de Negocio, Funci-onais e Nao Funcionais estabelecidos
75
Como os activos presentes na CMDB sao provenientes de alteracoes relativas a infra-
estrutura de Hardware, e necessaria uma integracao estes dois processos. Para atingir este
objectivo e descrita um forma automatica da introducao de alteracoes provenientes do RT na
CMDB do Zenoss.
76 CAPITULO 6. AVALIACAO
Capıtulo 7
Conclusao
Neste capıtulo sao apresentadas as conclusoes e discutidas algumas possibilidades de desenvol-
vimento.
Esta tese teve como objectivo o estudo de um sistema que vise a optimizacao da operacao
e da gestao de um centro de calculo de um instituto de Fısica Experimental de Altas Energias
(LIP) cuja principal actividade e o fornecimento de servicos de computacao e armazenamento
a utilizadores locais, e a investigadores remotos integrados em infra-estruturas de computacao
distribuıdas. A proposta incidiu sobre a implementacao dos processos de Gestao de Alteracoes
e de Gestao de Configuracoes, de acordo com a framework ITIL, considerados prioritarios para
efectuar o suporte diario as operacoes da infra-estrutura.
Uma das fases mais importantes deste estudo consistiu em identificar os requisitos, e em
avaliar os mecanismos ”ad-hoc”executados pelos varios membros do centro de calculo, atraves
de uma serie de entrevistas e avaliacoes, e integra-los num procedimento global que minimize
possıveis interrupcoes com as actividades presentemente levadas a cabo.
O modelo para o processo de Gestao de Alteracoes desenvolvido consistiu em identificar um
modelo e um fluxo de actividades adequado, em identificar os papeis dos varios interlocutores
e os diferentes casos de uso, em estabelecer os estados das alteracoes, e em estabelecer criterios
para a categorizacao e avaliacao das alteracoes. Tendo em conta os requisitos disponibilizados, a
concretizacao da solucao foi desenvolvida sobre uma ferramenta denominada de Request Tracker,
cujas funcionalidades e fluxos foram ajustados de acordo com o modelo aqui proposto.
O modelo para o processo de Gestao de Configuracoes consistiu na identificacao das prin-
cipais actividades, dos interlocutores, dos casos de uso e dos itens de configuracao (hardware)
a serem guardados, tendo em vista a minimizacao da existencia de informacao inconsistente ou
incoerente. A introducao dos activos na CMDB e um passo importante do processo de GC. Sa-
bendo que obter uma lista dos activos da instituicao e das suas relacoes entre si, seria uma tarefa
difıcil de concretizar e bastante demorada, devido a enorme quantidade de activos existentes e
77
78 CAPITULO 7. CONCLUSAO
ao facto de estes estarem sob a responsabilidade de diferentes pessoas, optou-se pela abordagem
definida por Larry Klosteboer que sugere que devem ser criados pontos de integracao em cada
uma das areas-chave dos processos operacionais que possam lidar com os dados de configuracao.
Desta forma, em vez de se popular a CMDB com todos os activos de uma so vez, o que ori-
gina quase sempre uma CMDB desactualizada, optou-se por ir alterando a CMDB a medida
que os activos vao sofrendo revisoes. E possıvel, assim, manter uma CMDB permanentemente
actualizada. A ferramenta Zenoss foi a seleccionada para a concretizacao do modelo dado a
sua flexibilidade, extensibilidade e as suas propriedades de monitorizacao, muito adequadas a
actividade de auditoria.
A vantagens da implementacao destes dois processos no LIP sao obvias:
• O processo de GA possibilita determinar se uma dada alteracao e exequıvel e o seu impacto,
e estabelecer que o fluxo de tarefas realizado por varios intervenientes seja efectuado de
forma mais celere, possibilitando tambem, a cada interveniente no fluxo de trabalho, saber
qual o progresso da tarefa e os passos definidos para a sua execucao.
• O processo de GC possibilita que, aquando da ocorrencia de uma alteracao, se consiga
saber de forma correcta e actualizada quais os recursos existentes na instituicao.
A adopcao das ferramentas (Request Tracker e Zenoss) revelou-se uma boa escolha, pois
para alem de conseguirem implementar os processos definidos, permitem ir mais longe: o RT
permite a implementacao do processo de Gestao de Incidentes, e o Zenoss permite monitorizar
os activos constantes na sua CMDB, isto e, monitorizar a infra-estrutura de rede e hardware do
CC da instituicao.
A implementacao dos processos de GA e GC e um trabalho difıcil e longe de estar completo
em qualquer instituicao. A continuacao deste trabalho contemplara o aumento do ambito do
tipo de alteracoes permitidas, de forma a tornar o processo mais geral e abrangente a todo o
tipo de alteracoes com impacto na instituicao. A discussao deste topico seguir-se-a na seccao
seguinte.
7.1 Trabalho a Desenvolver
Relativamente ao processo de GA, e necessario aumentar o seu ambito de forma a permitir ou-
tros tipos de alteracoes, para alem daquelas ja contempladas e que dizem respeito a alteracoes
na infra-estrutura de hardware. Por exemplo e necessario gerir as alteracoes relativas ao soft-
ware existente. Esta generalizacao podera levar ao alargamento dos workflows ja existentes, ou
a possıvel definicao de novos workflows, o que podera resultar numa reestruturacao das confi-
guracoes implementadas ao nıvel do RT.
7.1. TRABALHO A DESENVOLVER 79
Novas alteracoes implicam a caracterizacao de novos itens de configuracao, com novos atri-
butos que poderao nao estar contemplados na CMDB do Zenoss. Desta forma, e tambem ne-
cessario contemplar a necessidade de expandir o Zenoss, e explorar as potencialidades oferecidas
atraves do seu modulo de Zenpacks de forma a implementar novas funcionalidades e permitir a
monitorizacao de novos tipos de dispositivos.
O mecanismo de integracao dos processos de GA e GC deve ser fortificado com o desen-
volvimento da aplicacao de integracao de forma a que algumas das actividades possam ser
desenvolvidas de forma automatica, isto e, sem intervencao humana.
Finalmente, o processo de Gestao de Configuracoes da muitas vezes origem a incidentes que
geram novas alteracoes. Desta forma, um patamar que ainda falta implementar e um modelo
de Gestao de incidentes que feche o ciclo estabelecido pelos modelos implementados.
80 CAPITULO 7. CONCLUSAO
Bibliografia
[1] Judith M. Myerson. Cloud Computing Versus Grid Computing. Service Types, Similarities
and Differences, and Things to Consider, 3 March 2009,
[2] Foster Ian, Kesselman Carl. The Grid2: Blueprint for a New Computing Infrastructure.
Elsevier Inc, 2004
[3] Chappell David. A Short Introduction to Cloud Platforms: An Enterprise-Oriented View.
Chappell and Associates. 2008.
[4] Office of Government Commerce. Itil Service Support. The Stationery Office. 2000.
[5] Office of Government Commerce. Itil Service Delivery. The Stationery Office. 2000.
[6] Office of Government Commerce. Planning To Implement Service Management. The Statio-
nery Office. 2000.
[7] Office of Government Commerce. Application Management. The Stationery Office. 2000.
[8] Office of Government Commerce. ICT Infrastructure Management. The Stationery Office.
2000.
[9] Office of Government Commerce. Security Management. The Stationery Office. 2000.
[10] Baskerville, Richard L. 1999. Investigating Information Systems with Action Research.
Commun. AIS, 2, 4.
[11] Office of Government Commerce. Best Practice for Service Support, Managing IT Services.
The Stationary Office. 2000
[12] Jane Curry. Open Source Management Options. White Paper, Skills 1st Ltd. September
30th, 2008.
[13] Scott Stone. Monitoring Systems Comparison White Paper. The Forbin Group. June 14,
2007.
[14] Will Capelli. Magic Quadrant for Application Performance Monitoring White Paper. Gart-
ner RAS Core Research Note, G00173116. 18 February 2010. RA2 02222 011.
81
82 BIBLIOGRAFIA
[15] David Williams, Debra Curtis. Magic Quadrant for IT Event Correlation and Analy-
sis White Paper. Gartner RAS Core Research Note, G00208774. 13 December 2010. RV3
A412152011.
[16] Long John: ITIL Version 3 at a Glance. Springer.
[17] COBIT student Book. IT Governance institute.
[18] Framework, Management Guidelines, Information Systems: Audit, Control Foundation and
Objectives. COBIT Steering Committee and the IT Governance Institute. IT Governance
Institute . COBIT R©, 2000, E.U.A.
[19] Mary Beth Chrissis, Mike Konrad, Sandra Shrum. CMMI for Development: Guidelines for
Process Integration and Product Improvement (3rd Edition). Addison-Wesley Professional,
20 March 2011
[20] ITIL course. Electronic Data Systems. 2004.
[21] ITIL Configuration Management Requirement Analysis and Prototype Implementation the-
sis. Jurgen Langthaler. Universidade de Tecnologia de Viena 2007
[22] Greiner, Lynn. ITIL: The International Repository of IT Wisdom. netWorker, 11(4), 9-11.
2007.
[23] Van Bon. Foundations of IT Service Management based on ITIL V3. Zaltbommel: Van
Haren Publishing. January 2007
[24] Mattila, Antti. Best Practices for Network Infrastructure Management - a Case Study of
Information Technology Infrastructure Library (ITIL). M.Phil. thesis. Helsinki University of
Technology. 2008.
[25] Spremic, M., Zmirak, Z., Kraljevic, K. IT and Business Process Performance Management:
Case Study of ITIL Implementation in Finance Service Industry. Pages 243-250 of: 30th
International Conference on Information Technology Interfaces. June 2008.
[26] ITIL: Microsoft and Open Source, White Paper. Microsoft Corporation, October 26, 2007.
[27] Filipe Crespo Martins. Implementing ITIL Change Management thesis. Instituto Superior
Tecnico, Universidade Tecnica de Lisboa. 2010
[28] Anthony L.A.Baron, Woodinville, WA (US); Nigel G. Cain, Redmond, WA, (US). CMDB
SCHEMA. United States Patent Application Publication. Pub. No.:US 2006/0004875 A1.
Pub. Date: Jan.5, 2006.
[29] Jesse Vincent, Robert Spier, Dave Rolsky, Darren Chamberlain, Richard Foley. RT Essen-
cials. O‘REILLY, 2005
BIBLIOGRAFIA 83
[30] Jane Curry. Zenoss Discovery and Classification White Paper. Skill 1st Ltd. February 2009
[31] Methods of monitoring processes with Zenoss White Paper, Jane Curry. Skill 1st Ltd.
February 2009
[32] Zenoss Enterprise Architecture Overview, White Paper. Copyright 2010 Zenoss, Inc.
[33] Klosterboer, Larry. Implementing ITIL Configuration Management. IBM Press, 2008
[34] Zenoss Developer’s Guide Version 3.0. Zenoss, Inc.
[35] http://www.gnu.org/copyleft/gpl.html, 2011
[36] http://www.lighttpd.net, 2011
[37] http://perl.apache.org/start/index.html, 2011
[38] http://www.fastcgi.com/devkit/doc/fcgi-spec.html, 2011
[39] http://requesttracker.wikia.com/wiki/CustomizingWithCallbacks, 2011
[40] http://www.gridcomputing.pt, 2011
[41] http://www.egi.eu, 2011
[42] http://www.masonhq.com, 2011
[43] www.zope.org, 2011
84 BIBLIOGRAFIA
Apendice A
Simbologia Utilizada nos Diagramas
do Processo da Gestao de
Configuracoes
85
86APENDICE A. SIMBOLOGIA UTILIZADA NOS DIAGRAMAS DO PROCESSO DA GESTAO DE CONFIGURACOES
Forma de decisao que indica um ponto de ramificacao (Simou Nao) no fluxo do processo, por exemplo, informacaoproveniente do cliente esta correcta?
Forma que indica que o processo continua num diagramadiferente; o numero indica a etapa do processo. Por exem-plo, o processo continua num diagrama diferente na etapa2.1
Forma que indica uma sequencia de accoes que executamtarefas especıficas embutidas dentro de um fluxo do pro-cesso externo, por exemplo, Gestao de Alteracoes.
Identifica bases de dados utilizadas nos fluxos de processo,por exemplo a CMDB.
Actividade a realizar no fluxo do processo, por exemplo,criar uma nova instancia na CMDB
Forma que indica fase inicial ou final do fluxo do processo.Por exemplo, Iniciar uma auditoria.
Forma que ilustra a sequencia de passos e a direccao dofluxo do processo.
Apendice B
Descricao dos Principais Casos de
Uso do Sistema de Gestao de
Alteracoes
1. Criar RfC - Cenario Principal
• Pre-condicoes: Coordenador registado e activado no sistema de GA
• Cenario:
(a) Preenchimento de campos personalizados obrigatorios
(b) Avaliacao do estado do RfC
(c) Categorizar o RfC
• Pos-condicoes : O RfC fica no estado new (em espera).
2. Criar RfC - Cenario Alternativo
• Pre-condicoes: Coordenador registado e activado no sistema de GA
• Cenario:
(a) Preenchimento de campos personalizados obrigatorios
(b) Avaliacao do estado do RfC
(c) Categorizar o RfC
• Pos-condicoes : Nao processar o RfC. Alteracao do estado do RfC para Rejected.
• Outra informacao: O coordenador reavalia o RfC que foi criado e decide nao prosse-
guir com a sua implementacao, guardando-se a informacao da razao desta decisao.
3. Processar RfC - Cenario Principal
• Pre-condicoes:
87
88APENDICE B. DESCRICAO DOS PRINCIPAIS CASOS DE USO DO SISTEMA DE GESTAO DE ALTERACOES
– Coordenador registado e activado no sistema de GA
– Existe RfC no estado new
• Cenario:
(a) Requisita servicos especıficos, preenchendo campos personalizados definidos
(b) Alteracao do estado do RfC para open
(c) Notificacao automatica das pessoas responsaveis pela execucao de tarefas
• Pos-condicoes: Novos RfC gerados, dependentes do RfC original, que detalha a tarefa
a ser implementada pelo executante
4. Fechar RfC - Cenario Principal
• Pre-condicoes:
– Coordenador devidamente registado e identificado no sistema
– Existencia de todos os RfC filhos no estado resolved
• Cenario: Coordenador avalia as alteracoes e decide que a alteracao entra em producao,
encerrando o RfC.
• Pos-condicoes: RfC resolved
5. Fechar RfC - Cenario Alternativo
• Pre-condicoes:
– Coordenador devidamente registado e identificado no sistema
– Existencia de todos os RfC filhos no estado resolved
• Cenario:
(a) Coordenador avalia as alteracoes efectuadas pelos executantes
(b) O coordenador decide nao aceitar as alteracoes, e indica a razao pela qual a
alteracao nao se ira efectuar.
• Pos-condicoes: RfC nao executado e alteracao do estado para rejected.
6. Consultar informacao - Cenario Principal
• Pre-condicoes:
– Executante devidamente identificado e registado no sistema
– Existencia de um novo RfC (RfC filho) derivado do RfC original que indica ao
executante qual a sua tarefa e qual o estado do RfC original
• Cenario: Visualiza qual a tarefa a desempenhar e o tempo que dispoe
• Pos-condicoes: Informacao consultada
7. Processar tarefas - Cenario Principal
89
• Pre-condicoes:
– Executante devidamente identificado e registado no sistema
– Existencia de um novo RfC (RfC filho) derivado do RfC original que indica ao
executante qual a sua tarefa e qual o estado do RfC original
• Cenario:
– Implementa as tarefas solicitadas
– Notifica o Coordenador que a tarefa esta concluıda
• Pos-condicoes: Tarefa concluıda e RfC filho no estado resolved
8. Processar tarefas - Cenario Alternativo
• Pre-condicoes:
– Executante devidamente identificado e registado no sistema
– Existencia de um novo RfC (RfC filho) derivado do RfC original que indica ao
executante qual a sua tarefa e qual o estado do RfC original
• Cenario:
– Nao Implementa as tarefas solicitadas
– Notifica o Coordenador que a tarefa nao esta concluıda
• Pos-condicoes: RfC filho nao fechado
90APENDICE B. DESCRICAO DOS PRINCIPAIS CASOS DE USO DO SISTEMA DE GESTAO DE ALTERACOES
Figura B.1: Casos de Uso do Sistema de Gestao de Alteracoes
Apendice C
Descricao dos Principais Casos de
Uso do Sistema de Gestao de
Configuracoes
1. Definir Modelo da CMDB - Cenario Principal
• Cenario:
(a) Definir IC e atributos
(b) Definir Modelo da CMDB
(c) Definir fluxo de implementacao da CMDB
• Pos-condicao: Modelo da CMDB
2. Alterar estrutura da CMDB - Cenario Principal
• Pre-condicao: Sistema de GA emite um RfC.
• Cenario: O RfC implica a necessidade de alterar a estrutura da CMDB pois e ne-
cessario adicionar IC ou atributos nao contemplados ate ao momento ou remover IC
ou atributos que se tornaram obsoletos.
• Pos-condicoes: Modelo da CMDB alterado.
3. Alterar Conteudos da CMDB - Cenario Principal
• Pre-condicoes: Sistema de GA emite um RfC.
• Cenario: O RfC implica a necessidade de alterar conteudos na CMDB.
• Pos-condicoes: Modelo da CMDB actualizado.
4. Realizar Auditoria a CMDB - Cenario Principal
91
92APENDICE C. DESCRICAO DOS PRINCIPAIS CASOS DE USO DO SISTEMA DE GESTAO DE CONFIGURACOES
• Cenario: O Gestor de Configuracao executa a auditoria, fazendo um rastreio dos IC,
seja manualmente seja usando uma ferramenta, avaliando se encontra diferencas entre
os activos registados na CMDB e os activos da instituicao.
• Pos-condicoes: Caso nao existem diferencas, a auditoria termina
5. Realizar Auditoria a CMDB - Cenario Alternativo
• Cenario: O Gestor de Configuracao executa a auditoria, fazendo um rastreio dos IC,
seja manualmente seja usando uma ferramenta, avaliando se encontra diferencas entre
os activos registados na CMDB e os activos da instituicao.
• Pos-condicoes: Existem diferencas entre os activos da instituicao e os activos regis-
tados na CMDB, sendo emitido um RfC para resolver esta diferenca.
Figura C.1: Casos de Uso do Sistema de Gestao de Configuracoes
Apendice D
Modelo Logico do Request Tracker
Na figura D esta representado o modelo de domınio do RT. As principais tabelas e entidades
encontram-se descritas a seguir:
• Users
A tabela Users e responsavel por guardar a informacao relativa aos utilizadores do RT, ou
seja, quem realiza accoes no sistema.
• Groups
A tabela Groups e constituıda por utilizadores e grupos aos quais podem ser concedidos
direitos, nomeadamente o direito de visualizacao de tickets, entre outros. Grupos podem
conter utilizadores e grupos, mas nao se podem conter a si proprios.
• Access Control List (ACL)
Tabela que permite estabelecer diferentes tipos de permissao entre as varias entidades
existentes no RT (tickets, queues, groups, users).
• Transactions
Tudo o que acontece a uma ticket e registado nesta tabela, desde a sua criacao ate a sua
eventual resolucao.
• CustomFields
Atraves dos CustomFields e possıvel que tickets e queues possuam meta-dados, confi-
guraveis pelos utilizadores. Existem varios tipos tipos de CustomFields no RT,1 e cada
um deles pode aceitar um valor unico ou multiplos valores.
1Tipos de CustomFields existentes no RT: Fill in wikitext area, Upload one image, Upload multiple images,Upload one file, Upload multiple files, Fill in one text area, Enter one value, Enter multiple values, Select or enterone box, Select one value, Select multiple values, Enter one value with autocompletition, Enter multiple valueswith autocompletition
93
94 APENDICE D. MODELO LOGICO DO REQUEST TRACKER
• Tickets
O RT e um sistema de Ticketing, sendo um dos seus principais objectos o Ticket. Tickets
sao agrupados em queues, e so podem pertencer a uma unica Queue. Tem os seguin-
tes atributos: ID, Queue, Owner, Subject, Priority, Time, Status, Told, Started, Due,
Resolved.
• Queues
Uma Queue e a unidade basica administrativa do RT. Cada ticket e categorizado e per-
tence a uma queue. Controlo de acessos, logica de negocio (Scrips, Templates, Actions),
notificacoes e campos personalizados sao configurados nas queues, podendo depois ser apli-
cados a tickets. Quando os tickets sao submetidos ao Request Tracker, sao enviados para
queues a fim de serem processados, constituindo uma forma de categorizar tickets por
areas funcionais.
• Scrips
Scrips sao o principal instrumento para configurar o comportamento, implementar work-
flows e estender a logica de negocio no RT. Cada scrip e um conjunto de Condicao, Accao,
Template e Stage. Se uma dada Condicao se verifica, entao o RT prepara a Accao para
ser executada. Trata-se de um mecanismo muito geral e flexıvel que pode ser criado via o
interface do RT ou entao criando modulos Perl para cada condicao e accao a realizar. Os
scrips podem ser aplicados a todas as filas a ou filas especıficas.
• Templates
Trata-se de texto e anexado a um scrip, quando uma dada accao e executada.
Apendice E
Request Tracker Ticket Template
95
96 APENDICE E. REQUEST TRACKER TICKET TEMPLATE
Apendice F
Scrips Configurados no Request
Tracker
97
98 APENDICE F. SCRIPS CONFIGURADOS NO REQUEST TRACKER
Apendice G
Estrutura do Ficheiro XML Gerado
pelo Processo de Gestao de
Alteracoes
99
Recommended