concep˘c~ao de uma plataforma de gest~ao integrada para ... · concep˘c~ao de uma plataforma de...

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

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

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

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

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

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.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


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.


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


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.


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.


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,


• 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.


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]


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.


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


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].


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.


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.


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:


• 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.


• 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.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:


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.


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.


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.


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.


• 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.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.


• 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.


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


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.


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.


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.


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


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 :


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.


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



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.)




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.



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.


• 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.


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.


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.


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.


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.

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:




• 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:




• 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

concep˘c~ao de uma plataforma de gest~ao integrada para ... · concep˘c~ao de uma plataforma de...

Documents