A Computaç˜Ao Distribu´Ida

Concep¸cão de uma Plataforma de GestãoIntegrada para Sistemas de Suporte àComputa¸cãoDistribu´ıda

Sara Filipa Coutinho Barbas Valente (Licenciada)

Disserta¸cãopara obten¸cãodo Grau de Mestre em Engenharia Informáticae de Computadores

J´uri

Presidente: Professor Doutor JoséCarlos Alves Pereira Monteiro Orientador: Professor Doutor JoséLu´ısBrinquete Borbinha Orientador: Professor Doutor Miguel LeitãoBignolas Mira da Silva Vogal: Professor Doutor AndréFerreira FerrãoCouto e Vasconcelos

Novembro 2011 Agradecimentos

Em primeiro lugar agrade¸coaos meus orientadores, Gon¸caloBorges, Prof. JoséBorbinha e Prof. Miguel Mira da Silva pela sua orienta¸cão,apoio e disponibilidade durante este últimoano.

Gostaria tambémde agradecer ao LIP, em especial ao Prof. MárioPimenta, a hipótesede continuar a minha forma¸cão.

Agrade¸coaos meus amigos Rodolfo, Daniel e Alberto a ajuda prestada.

Por fim um agradecimento muito especial àminha mãee ao Lu´ısMiguel pelo seu apoio incondicional.

i ii Resumo

Actualmente gerir uma empresa ou institui¸cãoseria imposs´ıvel sem utilizar Tecnologias de In- forma¸cão.Fornecer servi¸cosde qualidade que permitem ao utilizador uma solu¸cãofácile transparente no manuseamento da informa¸cãoéuma tarefa árduapara quem os providencia. E´ neste dom´ıniode elevada complexidade que a framework ITIL pode ajudar a encontrar solu¸cõescapa- zes de melhorar práticasna gestão,integra¸cãoe manipula¸cãoda informa¸cão.A framework ITIL foca-se em descrever ”O QUE FAZER”e não”COMO FAZER”, explicando em detalhe todos os processos mas nãoindica como devem ser implementados.

Neste documento propusemos implementar os processos de Gestãode Configura¸cõese Gestão de Altera¸cõesconsiderados prioritáriospara suportar as opera¸cõesdiáriasdecorrentes da gestão da infra-estrutura de uma organiza¸cão. Utilizando o método Action Research, esta tese foi aplicada numa associa¸cãocient´ıficae técnicade utilidade públicacujos projectos de investiga¸cão, desenvolvimento e implementa¸cãosãocentrados sobretudo no dom´ıniodas infra-estruturas de computa¸cãodistribu´ıdae computa¸cão grid.

Foi constru´ıdoum sistema protótipo, sendo poss´ıvel efectuar altera¸cõesrelativas àinfra- estrutura de hardware de forma mais rápida,onde cada interveniente no fluxo de trabalho conhece qual o estado da tarefa a realizar e existindo a garantia que no final da altera¸cão,essa informa¸cãoéregistada na CMDB de forma correcta e actualizada.

iii iv Abstract

Currently managing an enterprise or institution would be impossible without the use of In- formation Technology. Providing quality services that allow the user an easy and transparent handling of information is a daunting task for anyone who provides it. ITIL is a framework that can help to provide solutions that improve practice management, integration and manipulation of information. ITIL describes ”WHAT TO DO”and not ”HOW TO DO”, explaining in detail all the processes but does not indicate how they should be implemented.

In this document we proposed to implement Change Management and Conﬁguration 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 scientiﬁc and technical associ- ation of public utility whose research, development and implementation is also focused in the ﬁeld of managing a distributed computing infrastructure.

A prototype system was built, and now is possible to make faster changes on the hardware infrastructure. There is also the guarantee that, by the end of the change, this information is recorded in the CMDB correctly and updated.

v vi Palavras Chave Keywords

Palavras Chave

ITIL Implementa¸cãoITIL Gestãode Altera¸cões Gestãode Configura¸cões CMDB Open Source

Keywords

ITIL ITIL Implementation Change Management Conﬁguration Management CMDB Open Source

vii viii Acr´onimos

AUGER The Pierre Auger Cosmic Ray Observatory

CC Centro de C´alculo

CCTA Central Computer and Telecommunications Agency

CERN Organiza¸c˜aoEuropeia para a Pesquisa Nuclear

CMDB Conﬁguration Management Database

EGI European Grid Initiative

ESA AgˆenciaEspacial Europeia

EXIN Netherlands IT Examinations Institute

FCCN Funda¸cãopara a Computa¸cãoCient´ıficaNacional

GA Gest˜aode Altera¸c˜oes

GC Gestãode Configura¸cões

IC Item de Conﬁgura¸c˜ao

INGRID Iniciativa Nacional Grid

ITIL Information Technology Infrastructure Library

KPI Indicador Chave de Desempenho

LIP Laborat´oriode Instrumenta¸c˜aoe F´ısicaExperimental de Part´ıculas

NASA National Aeronautics and Space Administration

RfC Request for Change

RT Request Tracker

SNOLAB Sudbury Neutrino Observatory Laboratory

TI Tecnologias de Informa¸c˜ao

ix x ´Indice

1 Introdu¸cão 1 1.1 Motiva¸cão...... 1 1.2 Questõesde Investiga¸cão...... 3 1.3 Método de Investiga¸cão ...... 3 1.4 Estrutura da Tese ...... 5

2 Trabalho Relacionado 7 2.1 Gestãoda Infra-estrutura ...... 7 2.1.1 Gestãoe Opera¸cãoda Infra-Estrutura de Rede ...... 7 2.1.2 Gestãoe Opera¸cãoda Infra-Estrutura de Servi¸cosComputacionais . . . . 10 2.1.2.1 Aplica¸cõespara Gestãode Desempenho ...... 10 2.1.2.2 Produtos para Gestãode Eventos ...... 10 2.2 ITIL ...... 12 2.2.1 Areas´ Relevantes para a Gestãode um Centro de Cálculo ...... 13 2.2.1.1 Suporte aos Servi¸cos ...... 13 2.2.1.2 Benef´ıciosResultantes do ITIL ...... 15 2.2.2 Gestãode Configura¸cões...... 15 2.2.3 Gestãode Altera¸cões...... 18 2.3 Suporte àGestãode Processos ITIL ...... 24 2.3.1 Software para Gestãode Configura¸cões...... 24 2.3.2 Software para Gestãode Altera¸cões ...... 26

3 Problema 29 3.1 Contextualiza¸cão ...... 29 3.2 Causas e Problemas Principais nos Procedimentos do LIP ...... 30 3.3 Coleçcãoe Caracteriza¸cãode Requisitos ...... 31 3.3.1 Requisitos de Negócio ...... 31 3.3.2 Requisitos NãoFuncionais ...... 31 3.3.3 Requisitos Funcionais ...... 31

xi xii ´INDICE

4 Proposta 33 4.1 Sistema da Gestãode Altera¸cões ...... 33 4.1.1 Modelo de Actividades ...... 33 4.1.2 Estados das Altera¸cões...... 35 4.1.3 Categorias de Altera¸cõese Critérios de Avalia¸cão...... 36 4.1.4 Identifica¸cãode Funcionalidades ...... 37 4.2 Sistema de Gestãode Configura¸cões ...... 39 4.2.1 Modelo de Actividades - Planeamento ...... 41 4.2.1.1 Defini¸cãodos Itens de Configura¸cão ...... 41 4.2.1.2 Modelo da CMDB e Fluxo Operacional de Implementa¸cão . . . 41 4.2.2 Modelo de Actividades - Identifica¸cão ...... 42 4.2.3 Modelo de Actividades - Especifica¸cão ...... 44 4.2.4 Modelo de Actividades - Controlo da Configura¸cão...... 46 4.2.5 Modelo de Actividades - Auditoria e Verifica¸cão ...... 47 4.2.6 Identifica¸cãode Funcionalidades ...... 47

5 Concretiza¸cãoda Solu¸cão 49 5.1 Request Tracker ...... 49 5.1.1 Arquitectura ...... 50 5.1.2 Modelo Lógico ...... 51 5.1.3 Razõesda Adop¸cãodo Request Tracker ...... 52 5.1.4 Configura¸cãodo 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 Inser¸cãodas Altera¸cõesna Gestãode Configura¸cões ...... 62 5.2 Zenoss ...... 62 5.2.1 Monitoriza¸cãoOrientada ao Modelo de Configura¸cão...... 62 5.2.2 Principais Funcionalidades ...... 63 5.2.3 Arquitectura ...... 65 5.2.4 Modelo ...... 66 5.2.5 Razõesda Adop¸cãodo Zenoss ...... 68 5.2.6 O Zenoss como Gestor de Configura¸cõesno LIP ...... 68 5.2.7 Modelo de Actividades do Processo de GC e sua Concretiza¸cãono Zenoss 68

6 Avalia¸c˜ao 71

7 Conclus˜ao 77 7.1 Trabalho a Desenvolver ...... 78 ´INDICE xiii

Bibliograﬁa 79

A Simbologia Utilizada nos Diagramas do Processo da Gestãode Configura¸cões85

B Descri¸cãodos Principais Casos de Uso do Sistema de Gestãode Altera¸cões 87

C Descri¸cãodos Principais Casos de Uso do Sistema de Gestãode Configura¸cões91

D Modelo L´ogicodo Request Tracker 93

E Request Tracker Ticket Template 95

F Scrips Conﬁgurados no Request Tracker 97

G Estrutura do Ficheiro XML Gerado pelo Processo de Gestãode Altera¸cões 99 xiv ÍNDICE Lista de Figuras

1.1 Fases da Investiga¸cão-Açcão...... 5

2.1 Exemplo de Ferramentas de Monitoriza¸cão,Alerta e Reaçcãopara VáriosRecur- sos e Servi¸cosde um CC...... 8 2.2 Quadrante Mágicoque Permite Avaliar um Fabricante de Produtos APM [14]. . 11 2.3 Quadrante Mágicode Produtos ECA [15]...... 12 2.4 Estrutura da Framework ITIL (ITIL V2) [11]...... 13 2.5 Modelo de Suporte aos Servi¸cos (ITIL V2) [11]...... 14 2.6 Gestãodas Altera¸cõese Outros Processos ITIL [14] ...... 19 2.7 Processo da Gestãode Altera¸cões...... 20 2.8 Estados de um RfC [15] ...... 22 2.9 Software para Gestãode Configura¸cões[17]...... 25 2.10 Avalia¸cãodo Software para Gestãode Configura¸cões[17]...... 25 2.11 Avalia¸cãodo Software para Gestãode Altera¸cões[17]...... 27

4.1 Processo de Gestãode Altera¸cõesAdoptado...... 34 4.2 Diagrama de Estados de uma Altera¸cão...... 35 4.3 Casos de Uso do Sistema de Gestãode Altera¸cões...... 39 4.4 Fases do Processo de GC, Proposto para o LIP...... 40 4.5 Fase de Planeamento da Configura¸cãoProposta para o LIP...... 41 4.6 Diagrama Entidade-Rela¸cão(ER) Ilustrando um Esquema de Defini¸cãodos IC na CMDB Proposto por Baron et al.[28] ...... 43 4.7 Fase de Identifica¸cãoda Configura¸cãoProposta para o LIP...... 44 4.8 Fase de Especifica¸cãoda Configura¸cão...... 45 4.9 Fase de Controlo da Configura¸cãoProposta para o LIP...... 46 4.10 Fase de Auditoria da Configura¸cãoProposta para o LIP...... 47 4.11 Casos de Uso do Sistema de Gestãode Configura¸cões...... 48

5.1 Arquitectura do RT [29]...... 51 5.2 Modelo L´ogicodo RT...... 52

xv xvi LISTA DE FIGURAS

5.3 Númeroe Estado de Tickets Existentes na Fila Hardware Change Request Criados a Partir de 13 Janeiro de 2011...... 53 5.4 Template de um Ticket no RT Configurado para Efectuar uma Altera¸cão. . . . . 57 5.5 Ciclo de Vida um Ticket no RT - Parte 1 ...... 59 5.6 Ciclo de Vida um Ticket no RT - Parte 2 ...... 60 5.7 Ciclo de Vida um Ticket no RT - Parte 3 ...... 61 5.8 Vista de Alto N´ıvel do Zenoss [34]...... 63 5.9 Workflow: Monitoriza¸cãoOrientada ao Modelo de Configura¸cão[34]...... 63 5.10 Mapa de Rede...... 64 5.11 Arquitectura em Camadas do Zenoss...... 65 5.12 Modelo de Dom´ıniodo Zenoss...... 66 5.13 Gráficosde Desempenho Disponibilizados pelo Zenoss...... 70

B.1 Casos de Uso do Sistema de Gest˜aode Altera¸c˜oes...... 90

C.1 Casos de Uso do Sistema de Gestãode Configura¸cões...... 92 Lista de Tabelas

2.1 KPIs para os Processos da GA e Gest˜aoda Release [25]...... 23

4.1 Critériospara Categoriza¸cãode Altera¸cões: A = Altera¸cãoPrincipal, B = Al- tera¸cãoSignificante, C = Altera¸cãoMenor...... 37 4.2 Per´ıodo de Execu¸cãopara as Diferentes Categorias de Altera¸cões ...... 37 4.3 Tipos de ICs definidos para o LIP e seus atributos...... 42

5.1 Rela¸c˜aoentre Pedido de Altera¸c˜aoe Ticket...... 54

6.1 As Caracter´ısticasdo RT Permitem Satisfazer os Requisitos de Negócio,Funcio- nais e NãoFuncionais estabelecidos...... 72 6.2 As Caracter´ısticasdo Zenoss Permitem Satisfazer os Requisitos de Negócio,Fun- cionais e NãoFuncionais estabelecidos ...... 74

xvii xviii LISTA DE TABELAS Cap´ıtulo1

Introdu¸c˜ao

1.1 Motiva¸c˜ao

A Internet écada vez mais um ve´ıculo privilegiado para a partilha e processamento de informa¸cãoàescala global. Os problemas com que a ciênciamoderna se depara sãode uma tal complexidade, que requerem grande tempo de cálculo, e geram um tal volume de dados que se tornam incomportáveis de resolver em tempo útilsem que se recorra a mecanismos de colabora¸cãoglobais. Algumas das grandes comunidades cient´ıficasactuais tais como o CERN e a NASA foram as principais impulsionadoras de solu¸cões de computa¸cãodistribu´ıdadestinadas a resolver problemas de grande dimensão,organizando-se de forma a partilharem os recursos computacionais de váriasinstitui¸cões atravésda Internet.

Alémda comunidade cient´ıficatambémempresas grandes e influentes, como a Google, a Amazon e a e-Bay, exploram jámodelos de computa¸cãodistribu´ıdae come¸cama disponibilizar, sob a forma de servi¸cos acess´ıveis remotamente, a possibilidade de um utilizador requisitar tempo de computa¸cãoou espa¸code armazenamento para as suas aplica¸cões.

E´ hoje poss´ıvel, para um utilizador, recorrer aos dois paradigmas de computa¸cãodistribu´ıda, Grid Computing [1] [2] e Cloud Computing [3], e usufruir de grandes capacidades de armazenamento e processamento, de forma simples e transparente. O utilizador pode ainda ter acesso e manobrar remotamente instrumentos cient´ıficosde grandes dimensõessem ter que assegurar a gestãoe a manuten¸cãodos mesmos. No entanto, a disponibiliza¸cãode grandes infra-estruturas de computa¸cãodistribu´ıdaexige a opera¸cãode uma vasta gama de recursos e servi¸coscomplexos.

Com a adop¸cãoda computa¸cãodistribu´ıda,quer pelas empresas quer pelos investigadores, muitos Centros de Cálculo(CC) vêem-seagora acrescidos de uma maior complexidade e responsabilidade. Para alémda gestãolocal das suas infra-estruturas, sãotambémparte de redes mais abrangentes que podem ser privadas, nacionais ou mesmo globais. Neste contexto, são responsáveis pela gestãodo equipamento (f´ısicoe virtual) e pelos servi¸cosque podem ser usados

1 2 CAP´ITULO 1. INTRODUC¸ AO˜

por vastas comunidades de utilizadores, e que devem ser permanentemente monitorizados de forma a garantir a qualidade de servi¸corequerida pelos clientes da infra-estrutura.

A opera¸cãoe o controlo de um parque de equipamentos tãovasto e diverso como o existente em qualquer CC actual éde extrema complexidade, dado o vasto númerode ferramentas, de plataformas e de hierarquias entre recursos. Consequentemente, para diminuir o esfor¸code opera¸cão,énecessáriocompreender todos os componentes de um CC, por forma a identificar onde e como se podem optimizar recursos.

Um CC éum espa¸cof´ısicoque aloja váriascomponentes informáticas,e componentes não informáticas. Alémdos sistemas que possibilitam o servi¸coprestado aos utilizadores (componentes informáticas),existem servi¸cosque asseguram que todo o equipamento funciona de forma correcta e num ambiente adequado (componentes nãoinformáticas).Ou seja, aos desafios técnicose heterogéneos,ocorrentes na gestãodos variados servi¸coscomputacionais, prestados pelo CC, outros desafios sãoimportantes: a adequada aloca¸cãodo espa¸coe dos equipamentos, a monitoriza¸cãodas condi¸cõesambientais, a vigilânciado espa¸co,bem como a manuten¸cãodos equipamentos sãoprocedimentos de opera¸cãotãoválidoscomo a opera¸cãodos servi¸cospara a comunidade, e requerem a gestãode procedimentos de forma rápidae eficaz.

Os dispositivos da rede (ex: routers, hubs, switchers, etc) devem manter-se operacionais. Tambémneste dom´ınioferramentas de monitoriza¸cãosãoutilizadas para detectar e produzir alarmes de forma que a equipa técnicapossa ser notificada caso alguma anomalia na rede ocorra. A monitoriza¸cãodo tráfegode rede étambémnecessáriapor uma questãode seguran¸canas organiza¸cõesactuais. As organiza¸cõessofrem ataques aos seus dados e aos seus equipamentos, a maioria deles atravésda rede. Monitorizar o tráfegona rede éuma das preocupa¸cõesde quem gere um CC, que para alémda vertente de seguran¸ca,pretende tambémcontrolar os gastos económicos.

As infra-estruturas f´ısicae de rede de um CC servem o propósitode fornecer servi¸cosaos utilizadores. Alguns servi¸cossãotransversais a qualquer tipo de organiza¸cão,seja ela de grande, médiaou pequena dimensão. Exemplos desses servi¸cossãoo DNS, o correio electrónico,os servi¸cosweb, os servi¸cosde autentica¸cão,os servi¸cosde bases de dados ou servi¸cosde repositórios, e cujo mau funcionamento põeem risco todas as camadas de servi¸cossuperiores tais como os de computa¸cão,de armazenamento e outros.

E´ neste dom´ıniode elevada complexidade que éo da gestãode um CC, que surge a framework ITIL (Information Technology Infrastructure Library Versão2) [4] [5] [6] [7] [8] [9] frequentemente referenciada como sendo o manual de boas práticasna gestão,integra¸cãoe manipula¸cãoda informa¸cãogerada num CC.

O ITIL Versão2 éuma compila¸cãovasta, organizada em diversas áreas,sendo a área do Suporte aos Servi¸cos,que trata dos processos necessáriosàmanuten¸cãodas opera¸cõesdiárias, a primeira que deve ser concretizada. Desta áreafazem parte dois processos intrinsecamente 1.2. QUESTOES˜ DE INVESTIGAÇ AO˜ 3

ligados: Gestãode Altera¸cõese Gestãode Configura¸cão,tornando-se imprescind´ıvel relacioná- los. A CMDB (Configuration Management Database) éum repositóriodos dados relacionados com todas as componentes do sistema de informa¸cãode uma empresa/institui¸cãoe éuma parte fulcral do processo de Gestãode Configura¸cões.

1.2 Quest˜oesde Investiga¸c˜ao

O propósitodesta tese écompreender como se efectua a Gestãoda Infra-estrutura F´ısica e de Rede de um CC: quais os processos envolvidos, quais sãoprioritários,quem sãoas pessoas responsáveis pela execu¸cãode tarefas, como sãoexecutadas 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 altera¸cãonuma institui¸cão e como esta altera¸cãoafecta os recursos existentes.

Em suma o objectivo ´eencontrar uma resposta para as seguintes quest˜oes:

1. Questão1: Como desenhar o processo de Gestãode Altera¸cões para permitir, de uma forma comum e coerente, gerir as altera¸cõesna infra-estrutura f´ısica,de rede e de servi¸cos do CC?

2. Questão2: Como desenhar o processo de Gestãode Configura¸cõese a CMDB, para que as informa¸cõessobre a infra-estrutura, assim como as rela¸cõesentre os seus diversos itens, sejam conhecidas, estejam globalmente acess´ıveis e num estado actualizado?

3. Questão3: Que ferramentas podem ser utilizadas e de que forma podem ser adaptadas para concretizarem os processos de Gestãode Altera¸cõese de Gestãode Configura¸cões?

1.3 M´etodo de Investiga¸c˜ao

O método de investiga¸cãoutilizado no desenvolvimento desta tese éo designado como Inves- tiga¸cão-Açcão (Action Research) [10]. Este método de investiga¸cãosurgiu nos meados do séculoXX e foi inicialmente utilizado nas ciênciasmédicase sociais, quando se pretendia introduzir uma nova terapêuticae analisar os efeitos da´ıresultantes. Desde os finais dos anos noventa come¸coutambéma ser adoptado na áreados sistemas de informa¸cão.

Este método segue um abordagem orientada àmudan¸ca,pressupondo que os processos sociais complexos podem ser estudados atravésda introdu¸cãopropositada de altera¸cões(entropia 4 CAPÍTULO 1. INTRODUÇ AO˜

controlada), observando, àposteriori, os efeitos resultantes dos factores exteriormente injectados no sistema. No método Investiga¸cão-Açcão,o investigador pretende experimentar uma teoria com indiv´ıduosem ambientes reais, avaliando continuamente os resultados e introduzindo cor- reçcõesou novos dados, repetindo este processo atéatingir um resultado considerado correcto.

Para ser poss´ıvel calcular o efeito da introdu¸cãopropositada de uma altera¸cãoe posteriormente a sua avalia¸cão,éseguido um processo de investiga¸cãosistemáticoe iterativo, cujo conhecimento adquirido em cada itera¸cãopode ser colocado em práticana itera¸cãoseguinte.

O dom´ınioideal de açcãopara este método écaracterizado por:

• um ambiente onde o investigador intervémdirectamente no própriosistema em estudo como um actor do mesmo, passando a fazer parte do objecto da investiga¸cão.

• o conhecimento obtido poder ser imediatamente aplicado

• um processo de pesquisa c´ıclicoligando teoria e pr´atica

A Investiga¸cão-Açcãodeve estar definida por um plano de investiga¸cãoe um plano de açcão, ambos suportados por um conjunto de métodos e regras. Sãoas chamadas fases do processo metodológico. Assim, para se concretizar um processo de Investiga¸cão-Açcão,seránecessário seguir quatro fases:

• Diagnosticar ou descobrir o problema.

• Construir o plano de ac¸c˜ao.

• Propor a execu¸c˜aodo plano e observar o seu funcionamento.

• Reﬂectir, interpretar e integrar os resultados. Construir um novo plano. 1.4. ESTRUTURA DA TESE 5

As fases da Investiga¸cão-açcãoassumem a configura¸cãoapresentada na Figura 1.1.

Figura 1.1: Fases da Investiga¸cão-Açcão.

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 Método de Investiga¸cãoutilizado na sua resolu¸cão.

2. O cap´ıtulo2 apresenta o Trabalho Relacionado, incluindo a apresenta¸cão/avalia¸cãodos produtos existentes de gestãoda Infra-estrutura f´ısicae de servi¸cosduma organiza¸cão. Descreve os processos de Gestãode Altera¸cõese de Gestãode Configura¸cões 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´ıtulo3 éapresentado um diagnósticoda forma como sãoefectuados os procedimentos diáriospara gerir o CC do LIP, e sãodefinidos os requisitos funcionais, nãofuncionais e de negócioa satisfazer.

4. No cap´ıtulo4 sãoapresentados os processos de Gestãode Configura¸cõese de Gestãode Al- tera¸cõesque o LIP deve adoptar para satisfazer os requisitos pretendidos. Os diagramas de fluxo de processo inclu´ıdosneste cap´ıtuloutilizam a simbologia constante no ApêndiceA. 6 CAPÍTULO 1. INTRODUÇ AO˜

5. No cap´ıtulo5, ´edescrita a forma como as ferramentas seleccionadas (Request Tracker e Zenoss) podem ser utilizadas para concretizar os processos deﬁnidos no cap´ıtulo4.

6. Conclus˜aoe apresenta¸c˜aode Trabalho Futuro.

Esta tese executa um ciclo do Método de Investiga¸cão-Açcão: a Fase de Planifica¸cãoé constitu´ıdapelos cap´ıtulos1, 2 e 3, a Fase de Açcãoéconstitu´ıdapelos cap´ıtulos4 e 5 e a Fase de Reflexãoéapresentada nos cap´ıtulos6 e tambémna Conclusão.

O Método de Investiga¸cão-Açcãoindica que o investigador deve experimentar uma teoria com indiv´ıduosem ambientes reais. O Centro de Cálculodo Laboratóriode Instrumenta¸cãoe F´ısicaExperimental de Part´ıculas(LIP) éa organiza¸cãoonde se tenta responder àsquestões levantadas nesta tese. O contexto desta institui¸cãoéexplicado na Seçcão3.1. Cap´ıtulo2

Trabalho Relacionado

2.1 Gest˜aoda Infra-estrutura

Os Centros de Cálculo(CC) sãoresponsáveis pela gestãodo equipamento (f´ısicoe virtual) e pelos servi¸cosque podem ser usados por vastas comunidades de utilizadores, e que devem ser permanentemente monitorizados de forma a garantir a qualidade de servi¸corequerida pelos clientes da infra-estrutura.

Para fazer a gestãodas múltiplas componentes de um CC existem ferramentas que propiciam uma opera¸cãocontrolada dos recursos. Na Figura 2.1 apresentamos alguns dos servi¸cost´ıpicos que funcionam sobre os diferentes tipos de infra-estruturas de CC: f´ısica, rede e de servi¸cos. A cada tipo de infra-estrutura e servi¸co, e dependendo da funcionalidade a vigiar, tenta-se configurar e adequar a ferramenta de monitoriza¸cãoe alerta que melhor encaixa na arquitectura e topologia do CC. Na presente Seçcãocomparam-se algumas das ferramentas de monitoriza¸cão existentes, tanto open-source como comerciais, cuja funcionalidade éa monitoriza¸cãoda rede e dos servi¸cosexistentes num CC.

2.1.1 Gest˜ao e Opera¸c˜aoda Infra-Estrutura de Rede

A monitoriza¸cãodo tráfegode rede é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 minimiza¸cãode poss´ıveis riscos de seguran¸ca,jáque os ataques aos dados e aos equipamentos, provêmna sua maioria atravésda rede. Para efectuar a monitoriza¸cãoutilizam-se sistemas de monitoriza¸cãoda rede cujo objectivo éfornecer uma visãocentralizada da rede e dos sistemas, para que os seus administradores consigam analisar as condi¸cõese evitar/corrigir os problemas rapidamente e de forma eficiente.

Trêssolu¸cõesopen-source (Nagios, OpenNMS, Zenoss) para gestãode sistemas sãoavaliadas no estudo realizado por Jane Curry [12].

7 8 CAP´ITULO 2. TRABALHO RELACIONADO

Figura 2.1: Exemplo de Ferramentas de Monitoriza¸cão,Alerta e Reaçcãopara VáriosRecursos e Servi¸cosde um CC.

O estudo conclui que o Nagios éuma ferramenta bem testada, fiável e com uma grande comunidade de utilizadores. As notifica¸cõessãosimples de configurar, mas caso seja necessáriaa produ¸cãode análisesbaseadas em registos fornecidos pelo Nagios talvez esta nãoseja a solu¸cãoa escolher. O Zenoss e o openNMS sãoprodutos com funcionalidades de discovery, monitoriza¸cão da disponibilidade, gestãode problemas, gestãode desempenho e reporting. O Zenoss tem tambémalguma capacidade de topology mapping e tem melhor documenta¸cãoque o OpenNMS. O estudo revela que a arquitectura de eventos, alarmes e notifica¸cõesdo OpenNMS ébastante confusa. A autora refere o Zenoss como a melhor escolha, esperando que a comunidade Zenoss melhore alguns aspectos nomeadamente a documenta¸cão.

No estudo, Monitoring Systems Comparison, de Scott Stone [13], comparam-se outras trêssolu¸cõescapazes de monitorizar a rede: Hyperic, Lithium e o Zabbix. Todas possuem um modelo h´ıbridode licenciamento, ou seja têmuma versãogratuita de base e uma versão comercial que presta suporte aos utilizadores consoante as suas preferências. De seguida enumeram-se as principais caracter´ısticas de cada um destes sistemas de Monitoriza¸cão, resultantes da avalia¸cão[13] efectuada. 2.1. GESTAO˜ DA INFRA-ESTRUTURA 9

Hyperic: o ponto forte desta solu¸cãoéa monitoriza¸cãodo desempenho de aplica¸cões, sendo vasta a variedade de aplica¸cõesque esta ferramenta consegue monitorizar.Possui caracter´ısticas de auto-discovery muito desenvolvidas permitindo:

• a auto-deteçcão das aplica¸cões a monitorizar e a configura¸cão automática de certos parâmetrosde monitoriza¸cãopara valores de omissãobastante razoáveis, que àposteriori, o administrador pode modificar consoante a sua vontade.

• uma instala¸cãosemi-automáticacom interven¸cãom´ınimado administrador de sistemas1

Quando énecessáriauma interven¸cãopor parte do administrador, esta éfacilitada por uma interface web bem desenhada e escrita em java capaz de responder de forma rápida,na qual éfácil procurar informa¸cãopois os sistemas e servi¸cossãoorganizados de forma automática.Os gráficos com os dados do desempenho das aplica¸cõessãofáceisde interpretar, e com legendas apropriadas. Nãopossui funcionalidades para a gera¸cãode relatórios,no entanto, caso a informa¸cãofornecida pela interface de utilizador seja insuficiente, époss´ıvel inquirir a base de dados SQL usando uma report-generating engine. Na edi¸cãocomercial (Enterprise edition) incorpora caracter´ısticasde gestãode altera¸cões,ficheiros de log de monitoriza¸cãoe uma pol´ıticade alertas ”Policy-driven”.

Lithium: éuma solu¸cãosimples de monitoriza¸cãodo estado e desempenho do hardware que utiliza exclusivamente o SNMP e que nãopossui qualquer capacidade da monitoriza¸cão de aplica¸cões. A versãogratuita, vem com diversos perfis pré-constru´ıdosde SNMP para monitoriza¸cãode 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 éuma solu¸cãonativa, mais agradável e com mais funcionalidades. O Lithium tem diversos relatórios pré-definidosque podem ser gerados, incluindo um relatórioque indica o uso da largura de banda.

Zabbix: Zabbix éoutro bom exemplo de software da monitoriza¸cãoda rede, embora não tãocompleto quando comparado com o Hyperic em termos de monitoriza¸cãode aplica¸cões. E´ uma solu¸cãoh´ıbridadas duas solu¸cõesdescritas anteriormente: baseia as suas verifica¸cões tanto em SNMP como em agentes espec´ıficos do Sistema Operativo. No presente momento nãopossui Auto-Discovery embora tal funcionalidade esteja planeada. Duas das caracter´ısticas mais agradáveis sãoa capacidade de representa¸cãográfica: pode criar um mapa de rede que mostra a localiza¸cãof´ısicae lógicados dispositivos de rede e as suas dependências. Os gráficos de desempenho sãoclaros, concisos, e fáceisde ler. A interface de utilizador de Zabbix é completamente web based, sendo as caracter´ısticasde gerar relatóriossimilares ao Hyperic.

1Para fazer o deploy do Hyperic, o administrador tem somente que instalar a console/servidor do software no nóde gestãoe depois fazer o deploy dos agentes nos nósa ser geridos(controlados). O códigodentro dos agentes faráo auto-discovery apropriado e registá-lo-áautomaticamente no servidor 10 CAPÍTULO 2. TRABALHO RELACIONADO

2.1.2 Gest˜ao e Opera¸c˜aoda Infra-Estrutura de Servi¸cosComputacionais

As infra-estruturas f´ısicae de rede de um CC servem o propósitode dar suporte a servi¸cos prestados aos utilizadores sendo alguns servi¸costransversais a qualquer tipo de organiza¸cão, seja ela de grande, médiaou pequena dimensão.Exemplos desses servi¸cossãoo DNS, o correio electrónico,os servi¸cosde autentica¸cão,os servi¸cosde bases de dados ou servi¸cosde repositórios, e cujo mau funcionamento põeem risco todas as camadas de servi¸cossuperiores tais como os de computa¸cão,de armazenamento e outros. Para monitorizar estes servi¸cosexistem ferramentas de monitoriza¸cãoque avaliaremos na presente Seçcão.

2.1.2.1 Aplica¸c˜oespara Gest˜aode Desempenho

Aplica¸cõespara Gestãodo Desempenho (Application Performance Management - APM), são aplica¸cõesque se focam na monitoriza¸cão,desempenho e disponibilidade do servi¸code aplica¸cões de software. Segundo o estudo da Gartner de 2010 [14], no qual se analisam aplica¸cõesAPM (ver Figura 2.2), a gestãodas opera¸cõesde Tecnologias de Informa¸cão(TI), realizadas pelos administradores de sistemas, tornou-se cada vez mais dependentes de aplica¸cões,complexas de gerir. O estudo evidencia ainda que muitas vezes, uma organiza¸cãosente necessidade de ”misturar e combinar”ofertas de diferentes fabricantes para assim conseguir uma solu¸cãoque seja ajustada àssuas necessidades.

2.1.2.2 Produtos para Gest˜aode Eventos

As organiza¸cõesde Tecnologias de Informa¸cão(TI) precisam de consolidar, analisar e responder aos eventos oriundos das componentes da Infra-estrutura, para assim conseguirem melhorar os servi¸cosprestados. Existem no mercado váriosprodutos, uns emergentes e outros mais maduros, que respondem a esta necessidade das organiza¸cões. Tais produtos sãodenominados de Event Correlation and Analysis - (ECA) e os seus objectivos principais sãoajudarem as organiza¸cões a lidar com o dilúviode eventos que advêmda infra-estrutura de TI pois conseguem eliminar sinais de eventos duplicados, filtrar os eventos de acordo com as opera¸cõesou de acordo com as prioridades e analisar os eventos conseguindo-se assim determinar a sua causa. Este tipo de produtos executam uma gestãopor excep¸cão,ou seja, produzem uma alerta sóquando uma excep¸cãoocorre, por exemplo em caso de falha ou de viola¸cãode um limite estabelecido, o que indica que a infra-estrutura nãoestáa ter um comportamento normal. Este facto implica o conhecimento pela organiza¸cãodo que éum comportamento ”normal”.

A Gartner efectuou um estudo [15] no qual avaliou alguns destes produtos, e cujas con- clusõesse encontram ilustradas na Figura 2.3. Produtos posicionados no quadrante visionaries possuem uma visãode futuro e sãogeralmente tecnicamente focados. Reconhecem e conseguem 2.1. GESTAO˜ DA INFRA-ESTRUTURA 11

Figura 2.2: Quadrante Mágicoque Permite Avaliar um Fabricante de Produtos APM [14]. responder àstendências da gestãode eventos a longo prazo do mercado, faltando-lhes contudo reconhecimento, e for¸ca de mercado e de vendas.

No quadrante leaders estãocolocados os produtos com elevado grau de visibilidade no mercado e que conseguem oferecer aplica¸cõesaltamente robustas e escaláveis capazes de prioritizar eventos oriundos de ambientes f´ısicose virtuais da infra-estrutura de TI. Possuem a visãoes- tratégicaque lhes permite atender de forma rápidaaos requisitos, em constante evolu¸cão.

Produtos novos no mercado de gestãode eventos, que se focam num segmento pequeno do mercado, mas que conseguem atingir grande profundidade nas funcionalidades nas suas áreas de escolha estãocolocados no quadrante niche players.

No quadrante challengers encontram-se produtos que têmum bom desempenho em muitas organiza¸cões.Alguns sãograndes produtos em termos de dimensãoe recursos financeiros, mas aos quais por vezes falta visão,inova¸cãoe percep¸cãoda evolu¸cãodas tendênciasdo mercado.

Podemos concluir que éextremamente dif´ıcilencontrar uma solu¸cãoque responda a todos os requisitos de um CC, e que normalmente nãosãosolu¸cõesintegradas, obrigando àutiliza¸cão de diferentes plataformas e interfaces, consoante o problema que se pretende resolver. 12 CAPÍTULO 2. TRABALHO RELACIONADO

Figura 2.3: Quadrante M´agicode Produtos ECA [15].

Na tentativa de integrar toda a informa¸cãogerada pelas ferramentas de gestão,configura¸cão e monitoriza¸cãodos diferentes recursos, váriasorganiza¸cõesusam modelos de princ´ıpios de opera¸cãoque descreveremos na Seçcãoseguinte.

2.2 ITIL

A presente Seçcãoapresenta uma das solu¸cõesque permite integrar, manipular e gerir a informa¸cãogerada num CC: a framework ITIL (Information Technology Infrastructure Li- brary) [16] [4], sobre a qual nos debru¸caremosmais profundamente. No entanto, existem outras frameworks com objectivos similares tais como o COBIT [17] [18] e o CMMI [19].

A framework ITIL éuma compila¸cãode boas práticasde gestãode TI obtidas a partir de organiza¸cõespúblicase privadas. Foi desenvolvido originalmente pelo governo britânico através da CCTA, e actualmente émantido pelo EXIN.

Esta framework descreve os processos necessáriospara gerir uma infra-estrutura de TI de forma eficaz e eficiente, garantindo os n´ıveis de servi¸coque os clientes têmque exigir e que os prestadores de servi¸codevem fornecer. Os principais objectivos desta framework sãoreduzir custos, aumentar a disponibilidade, ajustar a capacidade, aumentar a eficiênciae eficáciae reduzir 2.2. ITIL 13

riscos. A documenta¸cãoITIL foca-se em descrever ”O QUE FAZER”e não”COMO FAZER”. A framework ITIL ébaseada em processos em detrimento de uma estrutura hierárquica. Isto significa que hierarquicamente poderemos ter uma pessoa de um departamento responsável por mais de um processo.

Ao longo dos anos, a framework ITIL foi evoluindo, e inclui as seguintes ´areasque 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 Gest˜aode um Centro de C´alculo

Uma das áreasde maior relevânciana gestãoe opera¸cãode um CC moderno éa Gestãode Servi¸cosque engloba a áreado Suporte aos Servi¸cos[20]. O Suporte aos Servi¸cos, como ilustrado na Figura 2.5, trata dos processos necessáriosàmanuten¸cãodas opera¸cõesdiáriase de suporte aos servi¸cosprestados pela organiza¸cão.

2.2.1.1 Suporte aos Servi¸cos

A ´area do Suporte aos Servi¸cosfundamenta-se em cinco processos e uma fun¸c˜ao(Service Desk):

1. Gestãode Incidentes éo processo onde os incidentes sãodetectados e resolvidos. Um incidente éum evento que nãofaz parte da execu¸cãonormal de um servi¸coe que pode causar uma interrup¸cão

2. Gestãode Problemas éo processo que detecta e remove da infra-estrutura de TI, através da determina¸cãoda origem e análisedo problema, a ocorrênciade incidentes de modo a maximizar a eficiência.Tem como principal objectivo minimizar o impacto de incidentes e problemas no negócio,prevenindo a sua ocorrênciae relatando os erros encontrados. 14 CAPÍTULO 2. TRABALHO RELACIONADO

Figura 2.5: Modelo de Suporte aos Servi¸cos(ITIL V2) [11].

3. Gestãode Altera¸cões éo processo que controla a mudan¸cade todos os Itens de Confi- gura¸cão(IC), garantindo que procedimentos apropriados sãoseguidos quando éefectuada uma mudan¸ca.

4. Gestãoda Release éo processo que apósuma altera¸cãoter sido aprovada pelo processo da Gestãodas Altera¸cões,controla o armazenamento f´ısico e lógico,gestãoe distribui¸cão de todo o hardware e software de forma a garantir que na infra-estrutura sóexiste software e hardware devidamente aprovado e testado.

5. Gestãoda Configura¸cão éo processo de rastreio de todos os itens existentes na infra- estrutura incluindo hardware, software e documenta¸cãobem como todas as rela¸cõesexis- tentes entre eles e que suportam os servi¸cos. Este processo envolve identificar, registar e descrever as componentes de TI, (IC), incluindo as versões,rela¸cõese componentes. A informa¸cãode todas os IC deve ser mantida numa base de dados modular e flex´ıvel.

Service Desk éuma fun¸cãoque age como únicoponto de entrada entre o utilizador e a organiza¸cãode TI (SPOC - Single Point Of Contact), e cujo objectivo éajudar a resolver problemas e restaurar a normalidade das opera¸cõeso mais rápidoposs´ıvel. 2.2. ITIL 15

2.2.1.2 Benef´ıciosResultantes do ITIL

A mudan¸caéuma constante num CC. Rastrear, gerir e controlar as altera¸cõese o seu potencial impacto nos servi¸cosprestados torna-se, portanto, imperativo. Esta éuma das principais razões pelas quais os gestores de um CC come¸cama olhar para os processos desta framework.

Esta Seçcãodescreve os benef´ıciosresultantes da implementa¸cãoda framework ITIL num CC que incluem uma melhor gestãodos recursos e a consolida¸cãodos dados existentes. A framework ITIL permite ainda um melhor entendimento dos recursos dispon´ıveis, rastrear das mudan¸cas na infra-estrutura do CC e quantificar o impacto de tais mudan¸casnos servi¸cosfornecidos.

Com opera¸cõescada vez mais complexas e mais orientadas ao servi¸co,os gestores sentem necessidade de criar processos que lhes permitam manter uma ordem na execu¸cãodas tarefas. A framework ITIL fornece uma disciplina, uma linguagem e processos comuns que depois de implementados introduzem coerênciapara todos os que trabalham num CC. O conceito principal que devemos ter em conta éa uniformiza¸cão:uniformiza¸cãode um glossárioe termos comuns, que eliminem deficiênciasde comunica¸cãoentre o grupo de trabalho, e uniformiza¸cãode processos e métricasquantificáveis que permitam um servi¸code elevada disponibilidade.

Devido àenorme quantidade de servi¸cosabrangidos pela metodologia ITIL, implementá-los parece uma tarefa gigantesca. Quem jáo implementou afirma que a melhor maneira écome¸car com as áreasmais problemáticasde um CC, que sãoas áreasde Gestãode Problemas (GP), Gestãode Altera¸cões(GA) e Gestãode Configura¸cões(GC).

Na Seçcãoseguinte analisa-se em detalhe um sistema de Gestãode Configura¸cões e que aspectos se devem ter em conta para atingir o sucesso, dado que esta éa pedra basilar de qualquer plataforma de gestãointegrada de recursos.

2.2.2 Gestão de Configura¸cões

O processo da Gestãode Configura¸cões[4] éresponsável por identificar, registar e relatar todas as componentes de TI, nomeadamente as suas versões,os seus constituintes e rela¸cões,pertencentes àorganiza¸cão.Este processo éainda responsável por providenciar a todos os restantes processos, informa¸cãode configura¸cão,correcta e actualizada.

Objectivos:

Os objectivos do processo de GC s˜ao:

• inventariar os recursos e configura¸cõesdentro da organiza¸cãoe tambémdos seus servi¸cos,

• fornecer informa¸cõesexactas da configura¸cãoe da documenta¸cãonecessáriasaos processos de Gestãode Servi¸cos, 16 CAPÍTULO 2. TRABALHO RELACIONADO

• fornecer uma base s´olidapara os restantes processos que constituem o ITIL,

• Comparar os registos de configura¸cãocom a infra-estrutura e corrigir eventuais excep¸cões.

Conﬁguration Management Database

Configuration Management Database (CMDB) éa designa¸cãogenéricado repositóriode toda a informa¸cãorelacionada com as componentes que existem numa organiza¸cãode TI. Os registos deste repositóriochamam-se Itens de Configura¸cão(IC), sendo um IC qualquer componente que estásob o controle do processo da Gestãode Configura¸cões.A CMDB tambéminclui informa¸cão sobre a rela¸cãoentre os IC, sendo este o aspecto que distingue a CMDB de uma base de dados tradicional.

Todos os IC sãounivocamente identificados por nomes, númerosde versõese outros atributos, variando em complexidade, tamanho e tipo. Um IC pode ser um servi¸coou pode consistir em hardware, software e documenta¸cãode um programa.

Actividades

Sãocinco as actividades que constituem o Processo de Gestãode Configura¸cões,e que garantem a qualidade e coerênciada informa¸cãoarmazenada durante o desenrolar do processo:

1. Planeamento Primeiro que tudo énecessáriodefinir o âmbito, a finalidade, os objectivos, prioridades e procedimentos para o processo de GC. E´ nesta fase que os tipos e atributos dos itens de configura¸cãosãodefinidos.

2. Identifica¸cão Todos os activos (IC) da infra-estrutura, necessáriospara providenciar um servi¸co,devem ser identificados, etiquetados e inseridos num repositóriode dados. Para cada tipo de recurso a profundidade da documenta¸cãoexigida deve ser definida. Para cada atributo de um dado activo armazenado, uma razãoválidatem que existir para legitimar o esfor¸code recolher e de manter a informa¸cão.O grau de detalhe, usado para manter os IC, émuito importante para o sucesso da GC, dado que um grau de detalhe muito elevado aumentará o esfor¸conecessáriopara manter o repositóriode informa¸cãoe nãopermitiráum fluxo de dados efectivo. Também,adicionar atributos em falta émoroso e produzirácustos elevados quando o sistema de GC estiver em produ¸cão.

3. Controlo Esta actividade éresponsável por garantir que a inser¸cãodos IC na base de dados éexecu- tada de forma controlada, isto é,que sóIC autorizados e identificados podem ser inseridos. 2.2. ITIL 17

Faz parte desta actividade assegurar que nenhum IC éadicionado sem a existênciade documenta¸cãoapropriada, (por exemplo, um pedido de altera¸cãoaprovado) e que, apósa inser¸cão,exista documenta¸cãoactualizada.

4. Status accounting As altera¸cõesaos componentes devem ser documentadas e deve ser poss´ıvel visualizar e restaurar versõesantigas de uma entrada e das suas rela¸cõescom outras entradas. Juntamente com a altera¸cãoefectuada, a identifica¸cãoda pessoa responsável pela sua implementa¸cão deve ser uma informa¸cãoa manter. Devem existir relatóriosonde consta o estado presente e passado de um IC.

5. Verifica¸cãoe Auditoria Devem realizar-se verifica¸cões periódicas aos dados armazenados que assegurem a existênciae exactidãoda informa¸cãoguardada. E´ necessárioprovar que os IC e todos os atributos existentes estãocorrectos, e que as altera¸cõesforam realizadas de acordo com procedimentos estabelecidos. O repositóriode informa¸cãodeve conter apenas registos de IC que realmente existem, sendo necessárioavalia¸cõesregulares que removam informa¸cão desactualizada e/ou nãonecessária.

M´etricas

Existem indicadores chave de desempenho (KPI - Key Performance Indicators) para medir cada uma das actividades do processo de GC, existindo tamb´emKPI para medir todo o processo de GC. Alguns dos KPI s˜ao:

• Númerode pedidos de correçcãoda configura¸cão.

• Númerode pedidos de configura¸cão.

• Percentagem de pedidos de correçcãode configura¸cãopor númerode pedidos de configura¸cão.

• Percentagem de componentes de TI configurados via métodos automatizados versus componentes de TI configurados manualmente.

• Percentagem de componentes registados com informa¸cãode configura¸cãoerrada durante um processo de auditoria.

Devem ser produzidos relat´oriose registos regularmente que suportem as medidas descritas anteriormente. 18 CAP´ITULO 2. TRABALHO RELACIONADO

2.2.3 Gest˜ao de Altera¸c˜oes

As mudan¸cas/altera¸cõespodem surgir como resultado da ocorrênciade problemas, mas também advêm de uma procura constante em minimizar as interrup¸cõesno servi¸co e melhorar as opera¸cõesdiáriasdas organiza¸cõesde TI. Para conseguir estes objectivos, énecessárioque as organiza¸cõesse assegurem que as mudan¸casse fa¸camde forma controlada, ou seja, qualquer altera¸cãoa efectuar ou não,teráque ser avaliada, priorizada, planeada, testada, implementada e documentada. Sóassim, se consegue passar de um estado definido para outro estado definido.

Percebendo que énecessáriogerir as mudan¸cas,a framework ITIL propõeque as organiza¸cões definam e implementem um processo denominado Processo de Gestãode Altera¸cões.

Objectivos

A implementa¸cãoe defini¸cãodo processo de GA, deve ter em conta os seguintes objectivos:

• utilizar m´etodos e procedimentos padronizados

• registar as altera¸c˜oesna CMDB

• analisar riscos e avaliar o impacto das altera¸cões:a framework ITIL enfatiza que o processo contemple a avalia¸cãorigorosa dos riscos provenientes das altera¸cões,e propõeque se responda a sete questões:

1. Raised - quem pediu a altera¸c˜ao?

2. Reason - qual a raz˜aopara a altera¸c˜ao?

3. Return - qual o retorno exigido da mudan¸ca?

4. Risk - quais os riscos envolvidos?

5. Resources - que recursos s˜aonecess´arios?

6. Responsible - quem éresponsável por configurar, testar e implementar?

7. Relationship - que rela¸cõesexistem entre a altera¸cãoque se pretende e outras altera¸cões?

Nãoécontudo, do dom´ıniodo processo da GA, a identifica¸cãode componentes afectadas pela altera¸cão,ou pela release de componentes que tenham sido alterados [11], estando estas tarefas sob o dom´ıniode outros processos existentes, nomeadamente os processos de GC e Gestãoda Release. 2.2. ITIL 19

O processo da GA éresponsável por procedimentos que lidam com a gestãode pedidos de altera¸cãoaos itens de configura¸cão(IC) presentes na CMDB. Esses procedimentos envolvem:

• Hardware

• Servi¸cos

• Software

• Software de Sistema

• Aplica¸c˜oesde software em utiliza¸c˜ao

• Documenta¸cãoe procedimentos associados àmanuten¸cão,suporte e execu¸cãodos sistemas

• Pessoas

O processo da GA é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 altera¸cões.Por esta razão, muitas organiza¸cõesoptam 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 organiza¸cão,mas tambémdetém as fontes de informa¸cãosobre os recursos utilizados por cada servi¸co e as suas dependências.Quando uma mudan¸caprecisa ser executada, a CMDB mostra que componentes estãoligados ao componente alterado ou servi¸co,sendo assim poss´ıvel conhecer as consequênciase os problemas associados àmudan¸ca[22]. A Figura 2.6 ilustra a interaçcãoentre o processo da GA e outros processos da framework ITIL.

Figura 2.6: Gestãodas Altera¸cõese Outros Processos ITIL [14] 20 CAPÍTULO 2. TRABALHO RELACIONADO

Papéisno Processo de Gestãode Altera¸cões

O processo de GA dita a cria¸cãode um comitéde pessoas, com diversas fun¸cõesdentro da organiza¸cão,responsáveis pela defini¸cãodo processo e por aprovar, avaliar e priorizar as altera¸cões, constituindo a autoridade de decisão,denominado Change Advisory Board - CAB. Na eventua- lidade de ocorrênciade problemas, pode ser imposs´ıvel reunir todas as pessoas que constituem o CAB, pelo que convémque as organiza¸cõesidentifiquem um conjunto mais pequeno de pessoas capazes de dar resposta a situa¸cõesde emergência.Ou seja, deve existir tambémum emergency Committee - EC.

A framework ITIL propõeainda a cria¸cãode um outro papel: Change Manager - CM, cujas principais responsabilidades consistem na defini¸cãodo objectivo do processo de GA e como quantificar e medir a sua eficiência. Tambéméda responsabilidade do Change Manager fazer o alinhamento entre o o processo de GA e o processo de GC. Deverãoefectuar-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 Gest˜aode Altera¸c˜oes:

Figura 2.7: Processo da Gest˜aode Altera¸c˜oes

A abordagem àsactividades do processo da GA podem depender das necessidades da organiza¸cãoe da natureza do negócio. No entanto, a seguinte cadeia de acontecimentos éna 2.2. ITIL 21

generalidade seguida:

1. E´ efectuado um Pedido de Altera¸cão (RfC - Request for Change). O pedido pode ser efectuado por qualquer pessoa pertencente àorganiza¸cão,e éenviado por qualquer canal de comunica¸cãoao dispor (email, formulário web própriona intranet, telefone, etc.).

2. O CM examina o pedido.

3. O CM avalia, classifica, e categoriza o RfC, baseando-se no impacto e urgênciada altera¸cão proposta. Se considerar que a altera¸cãoénecessáriae exequ´ıvel, efectua um planeamento inicial da implementa¸cãoda altera¸cão.

4. O RfC érejeitado ou aprovado para implementa¸cãopelo CM ou pelo CAB. A necessidade de aprova¸cãopor parte do CAB depende da quantifica¸cãodo impacto da altera¸cãona institui¸cão,da quantidade de recursos necessáriospara efectuar a implementa¸cãoe do risco relacionado com a implementa¸cãoda mudan¸ca.

5. O CM planeia a implementa¸cão,definindo as tarefas a executar, o esfor¸conecessário, determinando os recursos, o or¸camento dispon´ıvel, e os critériosde aceita¸cão. O técnico responsável por implementar a mudan¸cadefine um plano de implementa¸cãodo ponto de vista técnicodefinindo uma solu¸cãotécnicaque engloba testes e uma plano de retrocesso.

6. A altera¸cãoéefectuada de acordo com o plano de implementa¸cãoestabelecido.

7. A altera¸cãoétestada verificando-se e avaliando-se o seu impacto. Posteriormente as altera¸cõesentram em produ¸cão.Este processo, Release to production, envolve uma avalia¸cão final que consiste em ponderar se a mudan¸caérealizada ou não,e se énecessárioaplicar o plano de retrocesso.

8. O sucesso da implementa¸cãoda altera¸cãoe o seu impacto érevisto em coopera¸cãocom o CM. O RfC e toda a informa¸cãorelacionada éactualizada, e o RfC é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 prop˜oeos estados ilustrados na Figura 2.8. 22 CAP´ITULO 2. TRABALHO RELACIONADO

Figura 2.8: Estados de um RfC [15]

Categoriza¸c˜aodas Altera¸c˜oes

A avalia¸cão de uma altera¸cão passa também por integrar a altera¸cão em categorias pré- estabelecidas e acordadas dentro do CAB. A framework ITIL propõeque sejam categorizadas da seguinte forma:

• Mudan¸cascom grande impacto

• Mudan¸cascom impacto Signiﬁcante

• Mudan¸cascom pouco impacto

M´etricas

A framework ITIL refere que as mudan¸casdevem ser avaliadas e que periodicamente devem ser facultados documentos, que circulem na organiza¸cão,onde conste essa avalia¸cão. Nesses relatórios,sugere-se que se inclua a seguinte informa¸cão:

• Númerode mudan¸casimplementadas num determinado per´ıodo: no total, por IC, tipo de configura¸cão,servi¸co,etc.

• Categoriza¸cão/decomposi¸cãodas razõesda mudan¸ca (solicitada pelo utilizador, devida a melhorias, servi¸copara resolver problemas/incidentes, melhoria de procedimentos). 2.2. ITIL 23

• N´umerode mudan¸casbem sucedidas.

• Númerode mudan¸casque nãose realizaram, juntamente com as razões.

• N´umerode incidentes atribu´ıdosa altera¸c˜oes.

• N´umerode mudan¸casimplementadas e que necessitaram de ser revistas.

• Elevadas incidˆenciasde RfC relacionadas com IC.

• Compara¸cãocom gráficosde per´ıodos anteriores.

• N´umerode RfC rejeitados.

• Propor¸cãode mudan¸cas que nãoforam bem sucedidas (relativamente ao númerototal, 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 mensur´avel melhorias na Organiza¸c˜ao.

Anterior Posterior KPI àImplementa¸cão àImplementa¸cão ITIL ITIL

% de mudan¸casrealizadas de acordo 25 80 com o planeado % de mudan¸casefectuadas, mas não 10 95 aprovadas % de mudan¸casurgentes 60 35 % de mudan¸casfalhadas 18 6 % de software em utiliza¸cãosem 22 8 autoriza¸cão % de Releases falhadas 13 10 % Releases urgentes 32 20

Tabela 2.1: KPIs para os Processos da GA e Gest˜aoda Release [25].

Um KPI éuma métricaque éusada para ajudar a gerir um Processo, um Servi¸code TI ou uma Actividade. Muitas métricaspodem ser utilizadas, mas sóas mais importantes sãodefinidas como KPIs e sãousadas para, de uma forma activa, gerir e reportar um Processo, Servi¸code TI ou Actividade. Os KPIs devem ser seleccionados de forma a garantir que a eficiência,eficácia, e rentabilidade sãogeridos.

Observando os valores dos KPIs, presentes na Tabela 2.1, anteriores e posteriores àimple- menta¸cãodo processo de GA, podemos constatar os ganhos obtidos pela organiza¸cão:o número 24 CAPÍTULO 2. TRABALHO RELACIONADO

de mudan¸casfalhadas diminui, bem como a percentagem de mudan¸casurgentes. Tambéma percentagem de software em utiliza¸cãosem autoriza¸cãodiminui.

2.3 Suporte `aGest˜aode Processos ITIL

A framework ITIL foca a sua estratégianos processos de gestãode TI, mas o objectivo, éque muitos destes processos sejam concretizados em sistemas de software. Nãoédo âmbito da framework ITIL orientar e divulgar a utiliza¸cãode ferramentas, e aliásnem deve fazê-lo. A framework ITIL tambémnãoafirma que deva existir uma solu¸cãoúnicaque englobe todos os processos. A verdade éque existem solu¸cõesdiferentes, de vendedores diferentes, open source e comerciais, que se focam e especializam em determinados processos.

A seguinte avalia¸cão,baseia-se na compara¸cãode caracter´ısticasde produtos que vãode encontro àsactividades 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 lan¸cadoem 2007, mas a framework ITIL V2 éextensamente usado e constitui um padrãopara a maioria de organiza¸cões). Este estudo foi realizado pela Microsoft e consta no artigo referido em [26].

Os produtos comparados são a solu¸cão oferecida pela Microsoft e algumas solu¸cões oferecidas pela comunidade open source. Como veremos, encontrar-se-ãosemelhan¸cas, mas tambémdiferen¸casnas abordagens àsquestõesque a framework ITIL levanta.

Podemos, no geral, concluir que:

• Nenhuma solu¸c˜ao´unica,de forma total, cobre todas as necessidades da framework ITIL.

• A solu¸cãoda Microsoft érelativamente completa, mas demasiado centrada no Windows, e nãocontempla todas as actividades presentes na framework ITIL.

• A comunidade open source foca-se em actividades t´ecnicasparticulares da framework ITIL em detrimento de um servi¸comais abrangente que englobe todo o processo ITIL.

2.3.1 Software para Gestãode Configura¸cões

Na presente Seçcãomostra-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 implementa¸cão,as actividades da GC (ver Seçcão2.2.2)estãopresentes.

Um dos objectivos da GC éfornecer uma base de conhecimento da configura¸cãodo hardware e software usados por uma organiza¸cão,logo o software deverá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 aplica¸c˜oesse encontram em utiliza¸c˜aono sistema.

• Detectar altera¸cõesna configura¸cão.

Todos os produtos listados na ﬁgura 2.9 implementam estas funcionalidades mas, no entanto, nenhum sozinho contempla todas as actividades da framework ITIL.

Figura 2.9: Software para Gestãode Configura¸cões[17].

A Figura 2.10 fornece uma revisãoda capacidade de cada produto para endere¸caras actividades da framework ITIL (ver Seçcão 2.2.2) para a GC.

Figura 2.10: Avalia¸cãodo Software para Gestãode Configura¸cões [17]. 26 CAPÍTULO 2. TRABALHO RELACIONADO

Podemos concluir o seguinte: a comunidade open source oferece uma vasta gama de solu¸cões para a GC, da qual o Zenoss éum bom exemplo, para monitoriza¸cãoda infra-estrutura e gestão das aplica¸cões,pois utiliza um CMDB para manter a informa¸cãodos componentes existentes na rede. Contudo, tem suporte limitado para aplica¸cõesempresariais tais como o SQL Server, o que limita a sua capacidade para actividades tais como a de Verifica¸cãoe Auditoria. OneCMDB possui funcionalidades de modela¸cãoe descoberta, mas falta-lhe a capacidade automatizada de Auditoria. CMDBuild, éum um projecto italiano de códigoaberto interessante, mas falta-lhe documenta¸cãoem l´ınguainglesa, o que restringe o seu uso.

Por sua vez, o Microsoft Systems Management Server (SMS), nãoéuma CMDB completa, mas consegue descobrir e monitorizar sistemas para um leque extenso de informa¸cãode configura¸cão,tais como hardware, sistema operativo e versãoe aplica¸cões instaladas. Como édedicado àplataforma Windows e àssuas aplica¸cões,pode executar uma análisemuito de- talhada que permite armazenar uma vasta variedade da informa¸cãodos sistemas geridos pela organiza¸cão.

2.3.2 Software para Gest˜aode Altera¸c˜oes

A menos que a mudan¸caseja controlada dentro de uma organiza¸cão,os servi¸cosestarãoàmercê de modifica¸cões ad hoc aos routers, aos utilizadores, e ao software. As mudan¸cas ad hoc podem e custam o rendimento das organiza¸cões,e criam frustra¸cãodesnecessária,como por exemplo, utilizadores terem que esperar a conclusãode um melhoramento nãoanunciado 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 éemitido, o software de workflow distribui o RfC para as partes envolvidas para revisão, teste e eventualmente instala¸cão,permitindo monitorizar o processo de altera¸cão. Um exemplo de software open source que suporta workflow éo Request Tracker, mas muitos produtos de Help Desk tambémpossuem esta funcionalidade, possibilitando o seu uso para monitorizar o processo de mudan¸ca.

2. Software de Deployment, que diz respeito àautomatiza¸cãoda implementa¸cãoda altera¸cão atéesta ser atingida. Para ser poss´ıvel atingir este objectivo, énecessárioque o software possua as seguintes funcionalidades:

• Instale actualiza¸cõesde software e mudan¸casna configura¸cão.

• Detecte erros durante o processo de actualiza¸c˜ao.

• Registe e relate quem iniciou o conjunto de altera¸c˜oes. 2.3. SUPORTE A` GESTAO˜ DE PROCESSOS ITIL 27

Figura 2.11: Avalia¸cãodo Software para Gestãode Altera¸cões[17].

A Figura 2.11 fornece uma revisãoda capacidade de cada produto para endere¸caras actividades da framework ITIL para o processo da GA (ver Seçcão 2.2.3).

Podemos concluir que algumas das ferramentas mais avan¸cadasdispon´ıveis são open source, tais como bcfg2, cfengine, radmind, e Webmin. Todas prevêemdeterminados graus de controlo sobre a instala¸cãodas mudan¸cas,embora ferramentas como o Webmin, utilizem um ecrãde configura¸cãomanual, o que limita o seu uso em ambientes de grande dimensão.Ferramentas que se centram na automatiza¸cão,tais como o bcfg2 e cfengine, fornecem meios que asseguram de que as configura¸cõesnãosãoalteradas - toda a altera¸cãonãoaprovada érevertida automaticamente de volta ao original por um agente local do software. Por exemplo, se um servidor que é definido como servidor web e nãotem o software Apache instalado, os pacotes de gestãode altera¸cõescorrigem este desvio instalando e configurando o pacote Apache. Esta capacidade de definir regras de configura¸cãoe 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 relatóriosdestes produtos élimitada. Apesar de fornecerem relatóriosdas mudan¸casocorridas no sistema, nãoháuma forma óbvia de determinar que sistemas estãoou nãosincronizados para alémde permitir que eles voltem a ficar sincroni- zados. Isto limita a capacidade de auditoria de altera¸cõesnãoautorizadas aos sistemas (embora este aspecto seja mais importante para a GC). Por sua vez, a solu¸cãoSMS da Microsoft, usada em ambientes windows tem as seguintes funcionalidades:

• Plano de Instala¸cão: relatóriosque fornecem a informa¸cãosobre hardware, software e versão.

• Instala¸c˜aobaseada em grupos: permite ao administrador de sistemas alocar software por diversos. grupos, onde um grupo pode ser deﬁnido usando propriedades como hardware, Active Directory(AD) e membros do grupo AD.

• Actualiza¸cõesde patch: automatiza a instala¸cãode patches para servidores e aplica¸cões cr´ıticas. 28 CAPÍTULO 2. TRABALHO RELACIONADO

Existem solu¸cõesviáveis para concretizar o processo da GA em ambos os ambientes open source e Microsoft. A comunidade open source tem providenciando solu¸cõestécnicasrobustas (bcfg2 e cfengine), mas muitas vezes nãoimplementa actividades essenciais, tais como planear altera¸cões(por exemplo, o software nãopermite facilmente que um administrador estime o impacto de uma mudan¸ca).Por sua vez, o SMS da Microsoft oferece uma solu¸cãomais abrangente, mas é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 gestãode altera¸cõesem paralelo. Cap´ıtulo3

Problema

3.1 Contextualiza¸c˜ao

O Laboratóriode Instrumenta¸cãoe F´ısicaExperimental de Part´ıculas(LIP), criado em 1986 quando Portugal aderiu ao CERN, éuma associa¸cãotécnicae cient´ıfica,que tem por objectivo a investiga¸cãono campo da F´ısicaExperimental de Altas Energias e da Instrumenta¸cãoAssociada.

As actividades de pesquisa do LIP, desenvolvidas no âmbito de grandes colabora¸cõesinterna- cionais (CERN, ESA, SNOLAB, NASA, AUGER), tem como principais dom´ıniosde investiga¸cão a F´ısicaExperimental de Altas Energias e Astropart´ıculas,a Instrumenta¸cãode Deteçcãode Radia¸cão,a Aquisi¸cãoe Processamento de Dados, a Computa¸cãoAvan¸cadae as aplica¸cõesdas radia¸cõesàmedicina.

Em Lisboa e Coimbra existem dois Centros de Cálculoalbergando a infra-estrutura de TI da organiza¸cão.Para além da gestãodestes dois CC, a equipa de Computa¸cãoAvan¸cadado LIP étambémresponsável pela coordena¸cãoda opera¸cãoda Iniciativa Nacional Grid (INGRID) [40], no âmbito do projecto europeu European Grid Initiative (EGI) [41], e opera o nócentral Grid (NCG) instalado na Funda¸cãopara a Computa¸cãoCient´ıficaNacional (FCCN).

No presente cap´ıtuloapresenta-se a institui¸cão(LIP), identificam-se as principais causas e problemas nos procedimentos efectuados nos CC da institui¸cãoe finaliza-se com a descri¸cãodos requisitos que se pretendem implementar de modo a agilizar os processos realizados nos CC.

Apontar um caminho para melhorar a gestãodestes dois centros de calculo éo propósito deste trabalho.

29 30 CAP´ITULO 3. PROBLEMA

3.2 Causas e Problemas Principais nos Procedimentos do LIP

O LIP encontra-se envolvido em projectos cujas experiênciasnecessitam que se processem quan- tidades massivas de dados digitais, e nas quais existem milhares de utilizadores. Esta situa¸cão implica que o pessoal técnicoe especializado do CC do LIP tenha que gerir uma vasta gama de recursos computacionais. Em simultâneo,algumas parcerias que o LIP vem estabelecendo aumentam por sua vez a áreade actua¸cãodo pessoal técnicodo CC do LIP, aumentando as fun¸cõesque os mesmo númerode técnicostêmque desempenhar.

Atéàdata, o LIP tem conseguido manter o n´ıvel de servi¸coque satisfaz os utilizadores, mas o pessoal técnicoencontra-se no limite do seu esfor¸co.

Atravésde um grande númerode entrevistas aos funcionáriosdo LIP, e da análisedas opera¸cõesdiáriaslevadas a cabo por cada elemento, tentou-se identificar as responsabilidades individuais, as responsabilidades conjuntas e o modo como a informa¸cãoflui no interior da institui¸cão.

Apósa análiseàsrespostas e procedimentos funcionais, chegou-se àsseguintes conclusões:

• cada funcionárioéresponsável pela manuten¸cãoe opera¸cãode determinados servi¸cos. Existem servi¸cosque podem ser suportados por dois ou mais elementos,

• a documenta¸cãosobre a opera¸cãode cada servi¸coémantida numa wiki geral. O problema éque essa wiki nãoéactualizada com a regularidade desejada,

• as entradas e sa´ıdasde componentes inform´aticas´erealizada de acordo com uma base de dados que se tornou obsoleta uma vez que deixou de estar actualizada,

• os registos de interven¸cõessobre componentes éainda mantido na forma de ficheiros de texto em áreaspessoais de alguns funcionários,

• o planeamento das interven¸cõesérealizado de forma ad hoc, com uma avalia¸cãodo impacto precária,

• o Modus operandi da institui¸cão,apesar de ainda conseguir satisfazer a qualidade de servi¸copretendida, confronta-se com o obstáculoda nãoescalabilidade resultante da gestão de um parque informático cada vez maior, mais complexo e distribu´ıdo,estando os seus funcionáriosno limite do seu esfor¸co.

O modo de funcionamento do CC de Coimbra ésemelhante ao funcionamento de Lisboa, pelo que no primeiro ciclo do método Action Research sóterei em considera¸cãoo CC de Lisboa. 3.3. COLECÇ AO˜ E CARACTERIZAÇ AO˜ DE REQUISITOS 31

3.3 Coleçcão e Caracteriza¸cãode Requisitos

O objectivo deste trabalho éa implementa¸cãode um sistema que optimize procedimentos e minimize o esfor¸cona opera¸cão/manuten¸cãodo equipamento.

Atendendo ao diagnósticoelaborado, apresentado na Seçcãoanterior, tendo em conta o contexto da institui¸cãoLIP, foi estabelecido um conjunto de requisitos funcionais, nãofuncionais e de negócioque 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 Neg´ocio

R01. O sistema deve ser desenvolvido utilizando ferramentas open source.

R02. O sistema deve integrar, sempre que poss´ıvel, tecnologia e software em produ¸c˜aono seio da institui¸c˜ao.

R03. O fluxo de informa¸cãono desenrolar dos processos deve basear-se num sistema de notifica¸cõestrocadas entre os váriosintervenientes.

3.3.2 Requisitos N˜aoFuncionais

R04. A autentica¸c˜aono sistema deve ser efectuada via login/password ou via certiﬁcado digital.

R05. Os utilizadores sópossuem permissõespara enviar notifica¸cões.

R06. O administrador do sistema possui permissõespara criar, apagar e manipular informa¸cão em todos os módulosdo sistema.

3.3.3 Requisitos Funcionais

R07. Planeamento de interven¸cõessobre componentes informáticos(adi¸cão, substitui¸cãoe remo¸cão).

R08. Registo de açcõesefectuadas sobre componentes informáticosincluindo interven¸cõesde manuten¸cão.

R09. Registo de ac¸c˜oesrealizadas pelos utilizadores e pelo administrador do sistema.

R10. Efectuar procuras sobre as ac¸c˜oesefectuadas sobre determinado componente.

R11. Elaborar relatóriose estat´ısticasque possibilitem obter métricaspara os várioscompo- nentes informáticosda institui¸cão. 32 CAPÍTULO 3. PROBLEMA

R12. Detectar e notiﬁcar a presen¸cade incoerˆencianos dados.

R13. Existˆenciade uma interface de acesso para todos os utilizadores.

R14. Existˆenciade uma interface que permita consultar os dados guardados.

R15. Invent´arioactualizado do equipamento de hardware existente no CC do LIP. Cap´ıtulo4

Proposta

Neste cap´ıtulos˜aoapresentadas as propostas para os processos de GA e GC tendo em conta os requisitos estabelecidos no ˆambito do LIP.

4.1 Sistema da Gest˜aode Altera¸c˜oes

Para gerir as altera¸cõesfoi necessáriodefinir um processo de GA, que se ajuste aos requisitos da institui¸cãoe que formalize estados de mudan¸ca,nomeadamente de equipamentos e servi¸cos. O processo fixado ébaseado na framework ITIL. Neste sentido, foi necessáriocriar critérios ajustados àrealidade da institui¸cãopara categorizar as altera¸cões,decidir os seus estados, fixar métricaspara avaliar as altera¸cõese o seu impacto, e determinar as actividades relevantes no fluxo de execu¸cãodo processo.

4.1.1 Modelo de Actividades

A Figura 4.1 ilustra o processo proposto de GA, e que ´ecomposto pelas seguintes actividades:

1. Criar um RfC (Request for Change).

2. Avaliar/Classiﬁcar um RfC.

3. Autorizar RfC.

4. Concretizar.

5. Testar um RfC.

6. Aceitar/Rejeitar RfC.

33 34 CAP´ITULO 4. PROPOSTA

Figura 4.1: Processo de Gest˜aode Altera¸c˜oesAdoptado.

Este processo propõea existênciade quatro papéisa desempenhar na institui¸cão: Re- questador (qualquer utilizador e funcionárioda institui¸cão), Executante (os funcionáriosque executam as tarefas técnicasde implementa¸cãoda altera¸cão), Coordenador (o responsável pela avalia¸cãoda altera¸cãoe pela coordena¸cãoda implementa¸cão)e o Comitéde Peritos (CPE que avalia e coordena altera¸cõesde grande impacto na institui¸cão).

O processo inicia-se com a cria¸cãode um novo RfC, e pode ser realizado por qualquer utilizador na organiza¸cão. A altera¸cãoéposteriormente catalogada pelo Coordenador: caso 4.1. SISTEMA DA GESTAO˜ DE ALTERAÇ OES˜ 35

seja uma altera¸cãoconfirmada como standard, éautomaticamente aprovada/aceite e pode ser executada. E´ nesta altura, que tambémédefinido o IC sobre o qual a altera¸cãoépretendida e recolhida toda a informa¸cãorelacionada, considerada útilpara avalia¸cãoda altera¸cão.Caso seja uma altera¸cãoconsiderada não standard, o RfC tem que ser avaliado e classificado de acordo com o modelo de classifica¸cãode altera¸cõesproposto (ver Seçcão4.1.3). O Coordenador pode dar seguimento àaltera¸cãoou encaminhar o pedido para nova reavalia¸cãopelo CPE. Se o RfC for rejeitado, o processo termina e o porquêda decisãode rejei¸cãoéguardado. Se o RfC éaceite, o(s) Executante(s), executam a altera¸cão.O RfC entra entãonuma fase de testes, e caso seja considerado válidoe nãocausar problemas inesperados, a altera¸cãoéfinalmente aceite. Caso contrárioa altera¸cãoérejeitada.

4.1.2 Estados das Altera¸c˜oes

No desenrolar das v´ariasactividades, um RfC passa por v´ariosestados que se encontram ilustrados na Figura 4.2.

Figura 4.2: Diagrama de Estados de uma Altera¸c˜ao.

• New - Quando um RfC ´ecriado, este ´eo seu estado.

• Open - O RfC foi aceite para implementa¸c˜aopelo Coordenador ou pelo CPE. Encontra-se em implementa¸c˜aopelo Executante.

• Testing - Depois de implementar a altera¸cão,o RfC entra numa fase de testes. Nesta fase avalia-se se a altera¸cãoéou nãobem sucedida.

• Resolved - Este éum dos estados finais de um RfC. Significa que a altera¸cãofoi comple- tada e com sucesso.

• Rejected - O RfC foi avaliado pelo Coordenador ou por o CPE e foi decidido que não seráresolvido, mas por alguma razão,éválidoque esta açcãoseja registada no sistema. 36 CAPÍTULO 4. PROPOSTA

4.1.3 Categorias de Altera¸cõese Critériosde Avalia¸cão

Os objectivos da categoriza¸cãodas altera¸cõeséperceber qual o método de aprovar e autorizar o pedido de altera¸cão(RfC) e ter um cálculopréviodo impacto da altera¸cãona institui¸cão. Nesse sentido, para categorizar as altera¸cõesfoi decidido adoptar o modelo definido pela Pink Elephant,1 sendo fixadas as seguintes categorias:

1. Principal - Mudan¸casque envolvem:

• elevado tempo de prepara¸c˜ao/execu¸c˜ao

• impacto dif´ıcilde avaliar

• m´etodos procedimentais n˜aoconhecidos

• requerem obrigatoriamente uma avalia¸c˜aopor parte do CPE

• avultados custos monet´arios

2. Significante - Mudan¸casque implicam um tempo de prepara¸cãoe execu¸cãolongo. Re- querem avalia¸cãopor parte do CPE

3. Menor - Altera¸cõesque nãorequerem aprova¸cãopor parte do CPE e que requerem pouco tempo de prepara¸cão/execu¸cão.

Para categorizar uma altera¸cãoo Coordenador deve avaliá-lade acordo com os critérios apresentados na Tabela 4.1, e ter em considera¸cãoo seguinte modelo de classifica¸cão: o valor mais elevado para todos os critériosestabelece a categoria da altera¸cão. Por exemplo, cinco classifica¸cõesC e um A significam automaticamente uma Altera¸cãoPrincipal.

1Várioscolaboradores da Pink Elephant sãoco-autores do livro ITIL - Service Support da editora Best practice nomeadamente Michiel Berkhout, Brian Jonhson, Marc Van Goethem, Guus Velter 4.1. SISTEMA DA GESTAO˜ DE ALTERAÇ OES˜ 37

A. Todos os utilizadores Númerode utilizadores afectados B. Dois ou mais grupos C. Um grupo A. Elevado. Organiza¸cãofica Risco de nãoimplementar a altera¸cão inoperacional B. Médio.Parte das funcionalidades nãoserãodisponibilizadas C. Baixo. Sem implica¸cões para a organiza¸cão A. Todo o CC Recursos necessáriospara preparar/implementar B. 3 técnicos C. 1 - 2 técnicos A. 2 dias ou mais Esfor¸co de Prepara¸cão B. 8 - 48 horas C. ≤ 8 horas A. > 24 horas Esfor¸co de Implementa¸cão B. 1 - 24 horas C. ≤ 1 hora A. Dif´ıcil Possibilidade de retrocesso B. Moderada (1 - 2 horas) C. Fácil

Tabela 4.1: Critérios para Categoriza¸cãode Altera¸cões:A = Altera¸cãoPrincipal, B = Altera¸cão Significante, C = Altera¸cãoMenor.

Sabendo qual o tipo de categoria, estabeleceram-se os seguintes tempos de implementa¸c˜ao:

Categoria da Altera¸c˜ao Prazo de Execu¸c˜ao

Principal 30 dias ´uteis

Signiﬁcante 14 dias ´uteis

Menor 0-3 dias ´uteis

Tabela 4.2: Per´ıodo de Execu¸c˜aopara as Diferentes Categorias de Altera¸c˜oes

4.1.4 Identiﬁca¸c˜aode Funcionalidades

O sistema de GA tem como objectivo principal gerir as altera¸cõesderivadas da Gestãodo CC do LIP. Para realizar este objectivo énecessárioque este sistema disponibilize as seguintes funcionalidades: 38 CAPÍTULO 4. PROPOSTA

• Criar novo pedido de altera¸c˜ao.(Create New RfC ) O pedido de altera¸c˜aodeve estar associado a:

– Item de Conﬁgura¸c˜ao(IC)

– Requestador

– Executante(s)

– Categoria

– Prioridade

• Definir diferentes perfis de utilizador com permissõese responsabilidades espec´ıficas,nomeadamente:

– Executante(s) - tem permissõesde visualiza¸cãoe modifica¸cãoparcelar de RfC relacionados com tarefas sob a sua dependência

– Coordenador - tem permissõesde visualiza¸cão/modifica¸cãode todos os RfC

– Requestador - pode unicamente visualizar o progresso (estado) do RfC que iniciou

• Permitir inser¸cãode comentáriosnum dado RfC, por parte dos intervenientes na altera¸cão.

• Rejeitar, aceitar e testar um RfC.

• Deﬁnir per´ıodo de execu¸c˜aode um RfC.

• Guardar um RfC.

• Consultar o registo históricode açcõesefectuadas sobre um RfC.

• Definir o fluxo de informa¸cãoentre os váriosintervenientes na altera¸cão.

• Visualizar m´etricasde desempenho utilizando um ´unico dashboard.

• Criar relatóriosque contenham informa¸cãosobre númerode pedidos de altera¸cão,número e percentagem de altera¸cões,númerode pedidos rejeitados, númerode pedidos aprovados e frequênciade mudan¸cade um dado IC.

• Deﬁnir procedimentos de retrocesso, caso uma altera¸c˜aocause problemas.

Na Figura 4.3 apresentam-se os casos de uso do sistema de GA. A descri¸cãodetalhada de cada um dos casos de uso encontra-se no ApêndiceB, apresentando-se para cada um, os cenários principais e alternativos. 4.2. SISTEMA DE GESTAO˜ DE CONFIGURAÇ OES˜ 39

Figura 4.3: Casos de Uso do Sistema de Gest˜aode Altera¸c˜oes.

4.2 Sistema de Gestãode Configura¸cões

O estudo dos processos executados no interior do LIP mostrou que o fluxo de informa¸cãoéreali- zado de forma inadequada, dada a quantidade de dados a manipular e os agentes envolvidos que necessitam de aceder a essa informa¸cão.Desta forma, mais do que um conjunto de tecnologias, énecessáriocolocar em práticaum modelo comum de procedimentos e actividades que visem centralizar a informa¸cão,e agilizar a sua consulta ou altera¸cãode forma controlada.

O processo global de GC proposto para o LIP encontra-se representado na Figura 4.4, e ´e constitu´ıdopelas actividades de:

• Planeamento: deﬁni¸c˜aodo modelo de GC.

• Identifica¸cão: responsável por identificar a existênciade novas ocorrênciasa introduzir/remover na CMDB.

• Especifica¸cão: constitu´ıdapor actividades que respondem a pedidos de altera¸cãoestru- turais da CMDB. 40 CAPÍTULO 4. PROPOSTA

• Controlo: constitu´ıdapor actividades que respondem a pedidos para alterar conteúdos da CMDB, nãoenvolvendo altera¸cõesestruturais na CMDB.

• Auditoria e Verifica¸cão: constitu´ıdapor actividades que asseguram que os activos na CMDB sãoefectivamente os activos da institui¸cão.

As açcõesconstituintes da actividade de Planeamento sãomais orientadas ao in´ıciodo processo, em que énecessáriovalidar o própriomodelo adaptado para a CMDB e modificá-lose necessário for. As actividades de Identifica¸cão, Especifica¸cão, Controlo, Auditoria e Verifica¸cão são constitu´ıdaspor açcõesorientadas para a opera¸cãodiáriada infra-estrutura de computa¸cãodo LIP, e em que o planeamento do modelo éposto àprova. Cada uma destas actividades encontra- se descrita em detalhe na presente Seçcão,e pressupõea existênciade 2 papéisa desempenhar na institui¸cão: Gestor da Configura¸cão, responsável pela execu¸cãodas actividades de todas as fases do sistema de GC, àexcep¸cãodas actividades da fase de Auditoria e Verifica¸cãoque serãoexecutadas pelo Auditor.

Figura 4.4: Fases do Processo de GC, Proposto para o LIP. 4.2. SISTEMA DE GESTAO˜ DE CONFIGURAC¸ OES˜ 41

4.2.1 Modelo de Actividades - Planeamento

A actividade de Planeamento ilustrada na Figura 4.5 éconstitu´ıdapela defini¸cãodos IC, do modelo para a CMDB e pelo fluxo operacional de implementa¸cãoda CMDB. Estes trêsaspectos sãoendere¸cadospor Baron et al. [28]

Figura 4.5: Fase de Planeamento da Conﬁgura¸c˜aoProposta para o LIP.

4.2.1.1 Defini¸cãodos Itens de Configura¸cão

Os IC podem ser qualquer item que a organiza¸cãoqueira gerir/controlar, incluindo itens in- tang´ıveis tais como licen¸cas,patentes, e itens de software e hardware. No caso espec´ıficodo LIP, o processo de GC pretende ser orientado a hardware com a agrega¸cãoda informa¸cãosobre os servidores de cálculo,servidores de armazenamento e respectivas componentes, e dispositivos de rede. A Tabela 4.3, esquematiza os váriostipos de IC (e seus atributos) identificados.

4.2.1.2 Modelo da CMDB e Fluxo Operacional de Implementa¸c˜ao

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 configura¸cãoarmazenados. Pretende-se que os dados da GC estejam organizados segundo um esquema (ver Figura 4.6) que deve ter em conta os seguintes aspectos: 42 CAPÍTULO 4. PROPOSTA

Atributos Itens de Configura¸cão Gerais Particulares MacAddress/Interfaces Rede IPs Localiza¸cão(Rack) Servidor Data de Entrada Capacidade de Memória Nome Tipo(Armazenamento ou Data Garantia Computa¸cão) Modelo MacAddress/Interfaces Rede Controlador de Armazenamento Marca IP Grupo Capacidade Caixas de Expansão Localiza¸cão Capacidade Númerode Série Localiza¸cão(Servidor/ Discos Part Number Caixa de Expansão) MacAddress/Interfaces Rede IP Router/Switcher Localiza¸cão(rack)

Tabela 4.3: Tipos de ICs deﬁnidos para o LIP e seus atributos.

1. incluir uma entidade para registar os atributos dos IC (CI Attribute). Como esta entidade est´aseparada das restantes entidades permite suportar qualquer tipo arbitr´ariode atributo para um dado IC.

2. incluir uma entidade para rastrear rela¸c˜oesentre IC (CI Relationship), o que possibilita o suporte de complexas rela¸c˜oesentre IC.

3. se poss´ıvel, incluir entidades que agreguem informa¸cãosobre procedimentos referentes ao processo de GA e que levem àmudan¸cade atributos de IC. Convémreferir que, dada a complexidade inerente aos processos de GA e GC, ambos sãonormalmente implementados de forma independente nas institui¸cões,e integrados àposteriori na CMDB atravésde entidades espec´ıficasque permitem relacionar um dado pedido de altera¸cãocom dado IC.

O ﬂuxo operacional na implementa¸c˜aoda CMDB implica:

1. Deﬁnir IC, tendo cada um ou mais atributos.

2. Guardar os atributos numa estrutura de dados (separada).

3. Identiﬁcar rela¸c˜oesentre IC.

4. Guardar as rela¸c˜oesidentiﬁcadas numa estrutura de dados separada.

4.2.2 Modelo de Actividades - Identiﬁca¸c˜ao

Apóso Planeamento, e segundo o modelo adoptado, segue-se a actividade de Identifica¸cão, que éresponsável por identificar a existênciade novas ocorrênciasa introduzir na CMDB. 4.2. SISTEMA DE GESTAO˜ DE CONFIGURAÇ OES˜ 43

Figura 4.6: Diagrama Entidade-Rela¸cão(ER) Ilustrando um Esquema de Defini¸cãodos IC na CMDB Proposto por Baron et al.[28]

O modelo pressupõea possibilidade da informa¸cãopoder ser obtida/agregada atravésde ferramentas (Discovery tools) que permitem obter de forma automáticainforma¸cãosobre novos IC. No entanto, durante a opera¸cãodiáriada infra-estrutura, a inser¸cãode um novo registo na CMDB deve ter sempre origem a partir do sistema de GA.

A Figura 4.7 apresentas as diversas açcõesenvolvidas na fase de identifica¸cão:

• 2.1) O Gestor da Configura¸cãoidentifica a existênciade novas ocorrênciasa inserir/remover da CMDB, como resultado das actividades de GA. Entre as ocorrênciasposs´ıveis temos:

1. Criar ou remover IC.

2. Criar ou remover atributos para um IC existente.

3. Criar ou remover instˆanciasde IC existentes.

4. Modificar valores dos atributos de instânciasdos IC. 44 CAPÍTULO 4. PROPOSTA

Figura 4.7: Fase de Identifica¸cãoda Configura¸cãoProposta para o LIP.

• 2.2) A` priori, o processo da GA pode dar origem a qualquer tipo de ocorrência(descrita no ponto 2.1.), e o modelo deve estar adaptado para reagir em consonância. A cada nova ocorrência,o Gestor da Configura¸cãodeve avaliar o respectivo impacto na CMDB. Ocorrênciasdo tipo 3 e 4 nãotêmimpacto estrutural no modelo adoptado para a CMDB pelo que podem ser realizadas de imediato.

• 2.3) Ocorrências do tipo 1 e 2 levam a altera¸cõesestruturais da CMDB, que uma vez identificadas, levam àemissãode um RfC, e caso este seja aprovado, àactividade de especifica¸cãono processo de GC.

4.2.3 Modelo de Actividades - Especiﬁca¸c˜ao

A actividade de Especifica¸cão, ilustrada na Figura 4.8 éconstitu´ıdapor açcõesque respondem a pedidos de altera¸cãoestruturais da CMDB, permitindo que a mesma se adeqúea um ambiente em permanente mudan¸ca,sendo o tipo de pedidos contemplados nesta fase os pedidos do tipo 1 e 2 da fase de Identifica¸cão.Nesta fase pressupõe-seque a valida¸cãodo conteúdodo pedido jáfoi executada durante o processo de GA pelo que a remo¸cãode um IC inexistente, ou de um atributo inexistente sãoaçcõesque nãotêmlugar durante esta actividade. 4.2. SISTEMA DE GESTAO˜ DE CONFIGURAÇ OES˜ 45

Figura 4.8: Fase de Especifica¸cãoda Configura¸cão.

O processo de alterar o esquema da CMDB consiste nos seguintes passos:

• 3.1) O Gestor da Configura¸cãorelaciona o IC com a baseline de configura¸cão.

• 3.2) O Gestor da Conﬁgura¸c˜aoaverigua se o IC existe na CMDB.

• 3.3) Caso n˜aoexista, tem que alterar o esquema da CMDB de modo a suportar o novo IC e os seus atributos e rela¸c˜oes.

• 3.4) Caso o IC exista na CMDB, o Gestor da Configura¸cãoavalia se se trata de um pedido de remo¸cãode um IC.

• 3.5) Se for um pedido de remo¸cão,entãoo Gestor da Configura¸cãoremove o IC.

• 3.6) Se o IC existe e nãose trata de um pedido de remo¸cão,o Gestor da Configura¸cão averigua se épara remover ou criar atributos para esse IC. 46 CAPÍTULO 4. PROPOSTA

• 3.7) O Gestor da Conﬁgura¸c˜aocria os atributos do IC.

• 3.8) O Gestor da Conﬁgura¸c˜aoremove atributos do IC.

4.2.4 Modelo de Actividades - Controlo da Conﬁgura¸c˜ao

Na fase de Controlo da Configura¸cão (Figura 4.9), o Gestor da Configura¸cão responde a pedidos para alterar conteúdos da CMDB. O tipo de pedidos envolvidos nesta fase sãopedidos do tipo 3 e 4 descritos na fase de Identifica¸cão.

Figura 4.9: Fase de Controlo da Conﬁgura¸c˜aoProposta para o LIP.

• 4.1) O Gestor da Configura¸cãorecebe um pedido para alterar conteúdosna CMDB.

• 4.2) O Gestor da Configura¸cãoavalia se o pedido éa cria¸cãode uma nova instânciade um IC.

• 4.3) Caso o pedido recebido nãoseja para criar um instância,o Gestor da Configura¸cão avalia se se trata de um pedido para remover uma instância.

• 4.4) O Gestor da Configura¸cãoaverigua se o pedido consiste na modifica¸cãodos valores dos atributos.

• 4.5) O Gestor da Configura¸cãocria uma nova instânciade um activo.

• 4.6) O Gestor da Configura¸cãoremove a instância.

• 4.7) O Gestor da Configura¸cãomodifica o valor dos atributos do activo na CMDB. 4.2. SISTEMA DE GESTAO˜ DE CONFIGURAÇ OES˜ 47

4.2.5 Modelo de Actividades - Auditoria e Veriﬁca¸c˜ao

Na fase de Auditoria e Verifica¸cão (Figura 4.10), realizada pelo Auditor realiza-se uma compara¸cãoentre os registos dos IC presentes na CMDB e os itens f´ısicosexistentes.

Figura 4.10: Fase de Auditoria da Conﬁgura¸c˜aoProposta para o LIP.

Este sub-processo éconstitu´ıdopelas seguintes açcões(figura 4.10):

• 5.1 O Gestor da Configura¸cãodetermina o âmbito da auditoria.

• 5.2 O Gestor da Conﬁgura¸c˜aoexecuta a auditoria (fazendo um rastreio do produto, usando uma discovery tool, manualmente).

• 5.3 O Auditor avalia se existem diferen¸casentre os activos registados na CMDB e os activos da institui¸c˜ao.

• 5.4 Caso n˜aoexistam diferen¸casa auditoria termina.

• 5.5 Caso existam diferen¸cass˜aodeterminadas excep¸c˜oese prioridades.

• 5.6 As diferen¸casdãoorigem àemissãode um novo RfC.

4.2.6 Identiﬁca¸c˜aode Funcionalidades

O sistema de GC tem como objectivo principal gerir da Gestãodo CC do LIP. Para realizar este objectivo énecessárioque este sistema disponibilize as seguintes funcionalidades:

• introduzir/remover dispositivos de hardware de forma autom´aticae de forma manual.

• visualizar rede de dispositivos, suas rela¸cõese dependênciasexistentes. 48 CAPÍTULO 4. PROPOSTA

• visualizar eventos.

• criar relatóriosque contenham informa¸cãosobre desempenho e disponibilidade dos componentes informáticos.

• consultar o registo históricode açcõesefectuadas sobre os dispositivos de hardware.

A Figura 4.11 apresenta os casos de uso do sistema de GC. A descri¸cãode cada um dos casos de uso, dos cenáriosprincipais e alternativos encontra-se no ApêndiceC.

Figura 4.11: Casos de Uso do Sistema de Gestãode Configura¸cões Cap´ıtulo5

Concretiza¸c˜aoda Solu¸c˜ao

Para concretizar o sistema de GA e o sistema de GC no LIP, optou-se pela utiliza¸cãode duas tecnologias open-source: o Request Tracker (RT) e o Zenoss. O RT éutilizado para concretizar o processo de GA e gerir o fluxo de trabalho na execu¸cãode tarefas, e o Zenoss éutilizado para concretizar o processo de GC.

Na presente seçcãoexplica-se a escolha destas ferramentas e o modo como se adequam aos modelos de GA e GC descritos nas Seçcões4.1 e 4.2.

5.1 Request Tracker

O Request Tracker(RT), [29] éum sistema utilizado para coordenar tarefas e gerir solicita¸cões (pedidos) entre váriosutilizadores. A primeira versão,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 versão4.0 e édistribu´ıdo sob a licen¸caGNU GPL [35]. O RT pode ser instalado sob as plataformas Unix, Linux, Windows e Mac OS e pode interoperar com váriasbases 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 módulomod perl [37] e ao protocolo FastCGI [38] respectivamente.

No RT convencionou-se que cada pedido ou tarefa a executar égerida atravésde um ou mais tickets. A cria¸cãoe actualiza¸cãode tickets pode ser levada a cabo atravésdas váriasinterfaces:

1. uma plataforma web, dispon´ıvel tanto para utilizadores registados como para utilizadores convidados, facilmente configurável que permite a adi¸cãode campos personalizados. Pos- sibilita a modifica¸cãoda interface web sem a necessidade de muito esfor¸coe conhecimento, utilizando o mecanismo de Callbacks. [39]

49 50 CAPÍTULO 5. CONCRETIZAÇ AO˜ DA SOLUÇ AO˜

2. uma interface de e-mail, muitas vezes a únicainterface que alguns utilizadores convidados têmpermissõespara visualizar.

3. interface REST que permite o acesso àbase de dados do RT a partir do exterior e cuja comunica¸cãoentre o cliente e a base de dados do RT se encontra encapsulada no protocolo HTTP. O endere¸coURL base para todos os pedidos é: https:///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 automatiza¸c˜aoe integra¸c˜ao com outras ferramentas. Esta interface interage com o servidor do RT usando o protocolo HTTP. [29]

Atrav´esde cada uma da interfaces anteriores, os utilizadores e administradores podem (de acordo com as suas permiss˜oes):

• Abrir um ticket.

• Atribuir tickets a pessoas (pessoas respons´aveis pelos tickets).

• Rastrear altera¸c˜oesefectuadas a um ticket.

• Informar as partes interessadas sobre as altera¸c˜oesefectuadas 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 implementa¸c˜aodas seguintes camadas:

• Database: esta camada representa a capacidade que o RT possui de inter-operar com v´ariasbases de dados nomeadamente MySQL, POstgreSQL, ORACLE e SQLite.

• DBIx:Searchbuilder é a camada responsável por estabelecer a liga¸cão entre uma aplica¸cãoorientada a objectos que éo caso do RT e a base de dados relacional adoptada. 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 responsáveis, por exemplo, pela conectividade àbase de dados, pelo controlo de acessos, liga¸cõese infra-estrutura de registos. – RT ticketing system libraries - livrarias que providenciam funcionalidades própriasde um sistema de ticketing.

• Mason handler éum wrapper para o sistema Mason [42], uma framework para a constru¸cãode aplica¸cõesweb escrita em Perl. O Mason pode ser usado com o servidor Apache HTTP via mod perl (para o qual o Mason providencia o seu própriohandler: HTML::Mason::ApacheHandler) ou ainda ser usado no servidor lighttpd.

• HTTP Clients. O RT tem trˆesclientes HTTP que s˜aoo Web Browser, Email gateway e a CLI (Command-Line Interface).

5.1.2 Modelo L´ogico

O Modelo Lógicodo RT apresentado na Figura 5.2 éconstitu´ıdopor duas partes principais: uma que éresponsável por gerir os utilizadores e as as suas permissões,para assim poderem actuar no sistema, e outra responsável pela funcionalidades própriasde um sistema de Ticketing.A unidade básicaadministrativa existente éa Fila (Queue), cuja estrutura permitir implementar um fluxo de trabalho a ser realizado por váriosintervenientes: as Filas sãocontentores nos quais se agrupam os tickets, se podem definir grupos de trabalho e definir condi¸cõese açcõesa realizar por diferentes intervenientes. 52 CAPÍTULO 5. CONCRETIZAÇ AO˜ DA SOLUÇ AO˜

Figura 5.2: Modelo L´ogicodo RT.

O Modelo e a sua descri¸c˜aopodem ser consultados no ApˆendiceD.

5.1.3 Raz˜oesda Adop¸c˜aodo Request Tracker

O RT foi adoptado pois éuma ferramenta amplamente utilizada na comunidade para gestão e controlo de tarefas, tanto em ambientes integrados, como em ambientes geograficamente distribu´ıdos.Existe um bom suporte e apoio àconfigura¸cão,devido àvasta documenta¸cãoexistente e ampla comunidade de utilizadores. A sua estrutura bastante genéricapermite que o RT seja configurado de acordo com os workflows e casos de uso necessáriospara uma dada organiza¸cão.

Para al´emdas vantagens enunciadas, o RT possibilita satisfazer a maioria dos requisitos no contexto do LIP:

1. Cumpre requisitos de negócio:o RT éuma ferramenta open-source, que possui um mecanismo de notifica¸cõese que permite informar todas as partes envolvidas sobre o estado de uma tarefa. E´ poss´ıvel notificar atravésde email e sms, os váriosintervenientes no desenrolar de actividades decorrentes da execu¸cãode tarefas. Ou seja, cumpre os requisitos de negócio R01 e R03 definidos.

2. Cumpre requisitos n˜aofuncionais: o RT possui como caracter´ıstica um mecanismo de 5.1. REQUEST TRACKER 53

ACL (Access Control Lists) implementando diferentes permissõespara diferentes tipos de utilizadores, isto é,utilizadores diferentes terãodiferentes direitos de actua¸cãono sistema. Este mecanismo permite satisfazer os requisitos nãofuncionais R05 e R06 definidos. No RT, a autentica¸cãono sistema éefectuada via login/password, permitindo satisfazer o requisito R04.

3. Cumpre requisitos funcionais: o RT permite definir fluxos de trabalho entre vários intervenientes, e registar essa informa¸cãona sua base de dados, permitindo satisfazer os requisitos R07 e R08. E´ uma ferramenta extremamente adaptável àspreferênciasde uma organiza¸cão:

• o seu modelo de dados genéricopermite uma categoriza¸cãosegundo a utiliza¸cãoque uma organiza¸cãopretenda. • O workflow e a lógicade negócioque uma organiza¸cãoprecisa, pode ser ensinada ao RT.

O RT permite procurar tickets, segundo uma forma pré-estabelecida no interface web, ou usando um query language denominada TicketSQL, possibilitando ao utilizador a defini¸cão da sua pesquisa, sendo assim cumprido o requisito R10. A partir desta funcionalidade simples, o RT permite a defini¸cãode Dashboards, ou seja, uma coleçcãode informa¸cão obtida atravésde pesquisas pré-definidas. Desta forma, os administradores e utilizadores podem ser notificados periodicamente (diariamente, mensalmente) sobre o estado e o númerode tickets numa determinada queue. O RT permite ainda a gera¸cão on demand de gráficos(ver Figura 5.3), demonstrativos da evolu¸cãodas diversas tarefas ao longo do tempo e do esfor¸cocomprometido na sua resolu¸cão.Todas estas funcionalidades permitem concretizar o requisito R11.

Figura 5.3: Númeroe Estado de Tickets Existentes na Fila Hardware Change Request Criados a Partir de 13 Janeiro de 2011. 54 CAPÍTULO 5. CONCRETIZAÇ AO˜ DA SOLUÇ AO˜

5.1.4 Conﬁgura¸c˜aodo Request Tracker

Nesta Seçcãoapresenta-se como o processo de GA definido na Seçcão4.1 foi concretizado usando o RT.

5.1.4.1 Ticket Actuando como RfC

Para a concretiza¸cãodo sistema de GA foi necessárioajustar funcionalidades do RT, e estabelecer conven¸cõesque se adaptem ao formalismo de um pedido de altera¸cão,e àsactividades do processo. Uma das principais conven¸cõesbaseia-se na correspondênciaentre um pedido de altera¸cãoe um ticket RT numa fila que visa altera¸cõesna infra-estrutura de hardware, sendo por isso imediato que todas as altera¸cõesserãoactividades sobre atributos de vários dispositivos de hardware. O formuláriode preenchimento destes tickets RT com campos pré-definidos (CustomFields), foi desenvolvido de forma a satisfazer todos os requisitos que devem constar num pedido de altera¸cão.Adicionalmente époss´ıvel explicitar sobre que item de configura¸cão e sobre que atributo do item de configura¸cãovai ser executada a altera¸cão.Entre os principais atributos a preencher temos informa¸cãoespec´ıficados dispositivos tais como a sua identifica¸cão, localiza¸cão,fabricante e tipo de produto, proprietário,entre outros.

A Tabela 5.1 sumariza os campos que constam no formul´ariode um ticket RT:

Formalismo RfC Ticket RT Preenchimento

Númerodo RfC Ticket Id Automático Data de Cria¸cão Created Automático Data Prevista In´ıcio Starts Automático Data In´ıcio Started Automático Data Prevista Fim Due Automático Descri¸cão Subject Manual/Obrigatório Prioridade Priority Automático Urgência Urgency Manual/Obrigatório Categoria N´ıvel 1 Category level1 Manual/Obrigatório Categoria N´ıvel 2 Category level2 Manual/Obrigatório Tipo da Altera¸cão Change Type Manual/Obrigatório Nome do Dispositivo Device Name Manual/Obrigatório Tipo de Dispositivo Device Type Manual/Obrigatório

Tabela 5.1: Rela¸c˜aoentre Pedido de Altera¸c˜aoe Ticket. 5.1. REQUEST TRACKER 55

Observa¸c˜oesimportantes relativamente aos campos existentes no ticket RT:

• Category level1 Indica se a categoria da altera¸c˜ao´e Standard ou Non standard.

• Category level2 Se a categoria da altera¸cãoescolhida for do tipo Non Standard, entãoeste campo permite indicar se a altera¸cãoéPrincipal, Significante ou Menor. Se a categoria for Standard este campo nãoéaplicável. A categoriza¸cãoda altera¸cãoimpõeuma data prevista para o fim (Due) da tarefa.

• Urgency A urgênciade uma altera¸cãopode ser classificada em: Not Urgent, Less Urgent, Urgent, Very Urgent e Top Priority.

• Priority A prioridade de uma altera¸c˜aodepende da urgˆencia:

– caso uma altera¸cãoseja classificada como Not Urgent a prioridade estabelecida éde 10/100. – caso uma altera¸cãoseja classificada como Less Urgent a prioridade estabelecida éde 30/100. – caso uma altera¸cãoseja classificada como Urgent a prioridade estabelecida éde 50/100. – caso uma altera¸cãoseja classificada como Very Urgent a prioridade estabelecida éde 70/100. – caso uma altera¸cãoseja classificada como Not Urgent a prioridade estabelecida éde 90/100.

• Due Na Seçcão4.1.3 foram estabelecidos tempos de implementa¸cãode tarefas de acordo com a categoria de uma altera¸cão.Tal éconcretizado no RT, no campo Due (Data Prevista do Fim), que de acordo com a categoria da altera¸cão(Change Category (level 2) - Principal, Significante, Menor) estabelece que a data prevista para o fim da tarefa será30, 14 e 3 dias úteisrespectivamente.

• Change Type No RT, foram configurados trêsTipos de Altera¸cão:

1. Add Hardware - altera¸cãoque visa a introdu¸cãode um novo dispositivo de hardware (nova instância). 2. Change Hardware - altera¸cãoque visa a modifica¸cãode valores dos atributos de um dispositivo de hardware existente. 56 CAPÍTULO 5. CONCRETIZAÇ AO˜ DA SOLUÇ AO˜

3. Maintain Hardware - altera¸cãoque visa opera¸cõesde manuten¸cãode hardware já existente

• Device Name - Nome do dispositivo de hardware sobre o qual incide a altera¸c˜ao

• Device Type - Tipo de dispositivo de hardware tais como: servidores, controladores de armazenamento, caixas de expansão,discos, routers e switchers de acordo com o definido na Tabela 4.3, Seçcão4.2.1.1.

5.1.4.2 Fluxo de Tarefas (Workﬂows)

Uma altera¸cãoéconstitu´ıdapor um conjunto de tarefas, independentes ou dependentes entre si, realizadas por um ou mais intervenientes e que passa por váriosestados, desde a sua cria¸cão atéàsua resolu¸cão.

Um conceito importante no RT, éa defini¸cãode transaçcão,que representa um conjunto de altera¸cõesefectuadas sobre um ticket. No contexto de uma transaçcão,(ou seja, quando um dado campo de um ticket éalterado), époss´ıvel definir açcõesexecutadas em resposta a dadas condi¸cões(Scrips). No modelo adoptado, tira-se partido desta funcionalidade do RT para definir uma hierarquia de trabalho, e dependênciaentre tarefas. Desta forma, nos tickets na fila para gestãode altera¸cõesexistem campos que dizem respeito a um conjunto de actividades paralelas que necessitam de ser executadas visando o objectivo final.1. A execu¸cãodestas tarefas édesencadeada atravésde campos espec´ıficosdo ticket, que quando accionados geram tickets filhos, criando uma dependênciapara com o ticket original: o ticket pai nãopode 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 altera¸cão,campos que descrevem o item de configura¸cãoe campos espec´ıficos que quando accionados levam àexecu¸cãode um fluxo de trabalho previamente configurado. O template deste ticket, éainda apresentado no ApêndiceE.

1Na figura que ilustra o ticket, os campos que representam as tarefas a serem efectuadas são:Configure DNS, Configure Nagios, Configure OS, Configure Amanda, Configure UPS, Configure Syslog 5.1. REQUEST TRACKER 57

Figura 5.4: Template de um Ticket no RT Conﬁgurado para Efectuar uma Altera¸c˜ao.

5.1.4.3 Ciclo de Vida de um Ticket

De seguida enumeram-se os pontos chave, do ciclo de vida de um ticket: 58 CAPÍTULO 5. CONCRETIZAÇ AO˜ DA SOLUÇ AO˜

1. um pedido de altera¸cãoéum ticket. O formulárioinerente a um pedido de altera¸cãoé implementado atravésdo preenchimento de um formulário web, com campos obrigatórios ou automáticosde acordo com as escolhas do utilizador. Entre as mais importantes temos:

• a categoria de uma altera¸cãoéobtida atravésda cria¸cãode dois campos denominados Change Category 1 e Change Category 2. • a caracteriza¸cãode um IC (e dos seus atributos) érealizada atravésda inser¸cãode campos em tickets agrupados numa fila. • a urgênciae a prioridade

2. rela¸cõesente tickets permitem definir hierarquia e dependênciade tarefas para realizar uma altera¸cão.

3. o preenchimento de certos campos de um ticket despoletam açcões(Scrips) que podem ser a cria¸cãode tickets filhos e notifica¸cõesde utilizadores para a realiza¸cãode sub-tarefas.

As Figuras 5.1.4.3, 5.1.4.3 e 5.1.4.3 explicam como um ticket égerido durante o seu ciclo de vida quando na institui¸cãose pretende efectuar uma altera¸cãoque visa a instala¸cãode novo Hardware, ou seja, uma altera¸cãocuja categoria édo tipo AddHardware. 5.1. REQUEST TRACKER 59

Ticket Template in Queue Hardware Change Request FASE DO PROCESSO 1. Criação 2. Classificar e Avaliar RFC RfC RESPONSABILIDADE Owner Owner

INFORMAÇÃO MÍNIMA • Urgency A SER PREENCHIDA E • Starts (Automática) VALIDADA* • Priority (Automática) (De acordo com o processo • Subject proposto para o LIP) • Change Category Level 1 • Change Category Level 2 • Change Type = Add Hardware • Device Name STATUS New New WORKFLOW 1

CONDIÇES, ACÇÕES (Scrips)

Scrip33: Change Priority according to Urgency Quando o Owner do Ticket preenche o campo Urgency, é estabelecido a prioridade da Alteração (Priority)

Scrip34: Change Due Data according to Change Category Quando o Owner do Ticket preenche o campo Urgency, é estabelecido a data de início prevista para a alteração (Starts)

Figura 5.5: Ciclo de Vida um Ticket no RT - Parte 1 60 CAPÍTULO 5. CONCRETIZAÇ AO˜ DA SOLUÇ AO˜

Ticket Template in Queue Hardware Change Request FASE DO PROCESSO 3. Autorizar a 4. Implementar Alteração RfC Alteração RESPONSABILIDADE Owner Executantes

INFORMAÇÃO A SER • Device Type • Completed PREENCHIDA E • HWManufacturer Configure DNS VALIDADA • HWProduct • Completed (De acordo com o • Part Number Configure OS processo proposto para o • Serial Number • Completed LIP) • Purchase Date Configure Nagios (Warranty) • Completed • Entry Date Configure Amanda • Ownership • Completed • Location Configure Syslog • Require Services: • Completed (DNS, OS, Nagios, Configure UPS Amanda, Syslog, UPS Configuration) (Após conclusão da tarefa) STATUS open open WORKFLOW (cont.)

Figura 5.6: Ciclo de Vida um Ticket no RT - Parte 2 5.1. REQUEST TRACKER 61

Ticket Template in Queue Hardware Change Request FASE DO PROCESSO 3. Testar a 4. Aceitar/Rejeitar a RfC Alteração Alteração RESPONSABILIDADE Owner Owner

INFORMAÇÃO MÍNIMA Nada a registar • Se alteração aceite, nada A SER PREENCHIDA E a registar VALIDADA • Comments (De acordo com o processo (Se alteração não aceite, proposto para o LIP) registar a razão) STATUS testing resolved, rejected WORKFLOW (cont.)

CONDIÇES E ACÇÕES Scrip 29: Write XML template Quando o owner, aceita a alteração, o estado do ticket é alterado para resolved. Nesta altura é efectuada uma acção que cria um ficheiro XML com a descrição do novo dispositivo de Hardware.

Figura 5.7: Ciclo de Vida um Ticket no RT - Parte 3

62 CAPÍTULO 5. CONCRETIZAÇ AO˜ DA SOLUÇ AO˜

5.1.4.4 Inser¸cãodas Altera¸cõesna Gestãode Configura¸cões

Um dos maiores desafios consistiu na defini¸cãode uma estratégiaque possibilite a interopera- bilidade entre o processo de GA e GC. As altera¸cõessobre determinado IC sãodisponibilizadas segundo um formato XML, gerado apósa resolu¸cãodo pedido de altera¸cão.Com o fecho de um ticket, édespoletada uma açcãoque visa disponibilizar o registo da altera¸cãonum servidor web àferramenta de GC num formato bem determinado. No ApêndiceB, apresenta-se a t´ıtulo de exemplo a estrutura do ficheiro XML, que égerado e onde consta a descri¸cãodo novo activo que deve ser inserido na base de dados, pelo processo de GC.

A ferramenta de GC écapaz de aceder a esses conteúdos,validá-lose de forma automática registar essa informa¸cãorelevante.

5.2 Zenoss

O Zenoss (Zenoss Core) [34] éum sistema para gestãode servidores e redes open source, baseado no servidor de aplica¸cõesZope (Zope [43] éum servidor, open source lan¸cadoem 1998, de aplica¸cões web orientado a objectos e escrito em Python). Como ilustrado na Figura 5.8, atravésde um interface web, o Zenoss permite a gestãoe configura¸cãodo inventário(o Zenoss monitoriza toda a infra-estrutura de TI, incluindo a rede, os servidores, os sistemas de aque- cimento, ventila¸cão,ar condicionado e atémesmo aplica¸cõesde software), a monitoriza¸cãodo desempenho e da disponibilidade, e a gestãode eventos.

O desenvolvimento do Zenoss come¸couem 2002 e em Agosto de 2005 a empresa Zenoss, Inc foi fundada. Alémda versãoZenoss Core que égratuita, a empresa vende a versãoZenoss Enterprise baseada na versãoCore.

O Zenoss possibilita um inventárioactualizado dos equipamentos, e simultaneamente deduzir o seu estado atravésda monitoriza¸cãodo seu desempenho e da sua disponibilidade. E´ portanto uma ferramenta adequada para a gestãode um CC complexo e em constante mudan¸ca.

5.2.1 Monitoriza¸cãoOrientada ao Modelo de Configura¸cão

Como ilustrado na Figura 5.9, a monitoriza¸cãoorientada 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 modelo constru´ıdoéaplicado uma configura¸cãopré-definida(config) e a monitoriza¸cãocome¸ca (monitor). Esta configura¸cãoinicial pode contudo ser posteriormente afinada (tune).

2No modelo da base de dados constam os recursos descobertos, constitu´ıdospor um inventáriocompleto dos servidores, redes e aplica¸cõesde software existentes, atéao n´ıvel de detalhe dos interfaces, servi¸cos,processos, e software instalado existente. 5.2. ZENOSS 63

Figura 5.8: Vista de Alto N´ıvel do Zenoss [34].

Figura 5.9: Workflow: Monitoriza¸cãoOrientada ao Modelo de Configura¸cão[34].

5.2.2 Principais Funcionalidades

As funcionalidades principais fornecidas pelo Zenoss (Core) s˜ao:

• Visãoexacta e em tempo real dos dispositivos, das redes e das dependênciase rela¸cões existentes na infra-estrutura de TI: 1. o Zenoss encontra e identifica os dispositivos e redes (de forma manual e automática), e posteriormente constróium mapa da rede (ver Figura 5.10). 2. possibilita estabelecer rela¸cõesentre dispositivos e estabelecer liga¸cõesentre eles.

• Medir a disponibilidade de dispositivos de hardware (servidores, routers, etc.), e dos servi¸cospor eles providenciados (servi¸cosde mail, web, transferˆenciade arquivos).

• Possibilidade de medir o desempenho usando métodos como o SNMP, WMI, comandos de shell, e API. Apósefectuar a recolha dos dados, analisa-os de acordo com limites definidos pelo utilizador, e disponibiliza-os atravésde gráficos e relatórios. 64 CAPÍTULO 5. CONCRETIZAÇ AO˜ DA SOLUÇ AO˜

• Monitoriza¸cãoda gestãode eventos resultantes da ocorrênciade problemas provenientes dos dispositivos. Atravésde um mecanismo de notifica¸cõese escalonamento, as pessoas responsáveis pela sua resolu¸cãoapercebem-se do estado desses mesmos problemas.

• Fornece relatóriosresultantes do cruzamento de informa¸cãoentre objectos e com vários formatos e conteúdos.

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´ıdapor quatro camadas:

1. Coleçcão- Collection Layer: compreende os servi¸cos que coleccionam os dados para a camada de dados. Estes servi¸cossãoprestados por daemons que executam fun¸cões de gestãode modela¸cão,monitoriza¸cãoe eventos.

2. Processamento - Processing Layer: camada responsável pela gestãodas comunica¸cõesentre a camada dos dados e a camada responsável por coleccionar os dados (Collection Layer).

3. Dados - Data Layer: A informa¸cãorelacionada com a configura¸cãoe coleçcãoé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 licen¸caGNU GPL. Foi desenvolvido para armazenar sériesde dados numéricossobre o estado de redes de computadores, porémpode ser utilizado no armazenamento de qualquer outra sériede dados como temperatura, uso de CPU, etc. O RRD éum modo abreviado de se referir a Round Robin Database (base de dados round-robin). O RRDTool tambémpode produzir gráficosque permitem ter uma ideia visual dos dados armazenados, os quais podem ser utilizados ou exibidos por outros sistemas. A ferramenta Cacti éum outro exemplo disso, para alémdo Zenoss. (b) ZenModel - Constitui o modelo nuclear da configura¸cão,constitu´ıda por dispositivos e pelas suas componentes, grupos e localiza¸cões.Este modelo seráexplicado em detalhe na Seçcão 5.2.4. (c) ZenEvents - Base de dados MySQL com os eventos gerados. 66 CAPÍTULO 5. CONCRETIZAÇ AO˜ DA SOLUÇ AO˜

4. Utilizadores -User Layer: Esta camada éum portal web no qual o utilizador pode realizar as fun¸cõesdescritas na SeçcãoFuncionalidades.

5.2.4 Modelo

De seguida descreve-se o Modelo de Dom´ıniodo Zenoss (ver Figura 5.12), o qual permite caracterizar o equipamento de hardware e tamb´emo software existente numa institui¸c˜ao/empresa.

Figura 5.12: Modelo de Dom´ıniodo Zenoss. 5.2. ZENOSS 67

1. Um dispositivo (device) éo objecto principal de monitoriza¸cãono sistema. E´ definido como uma combina¸cãode elementos de váriasclasses, entre as quais as de hardware e software. Exemplos de dispositivos são:servidores, routers, switchers. Todos os dispositivos têmatributos própriosque 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 sãotambémeles classes de produtos, com atributos próprios.Desta forma um produto é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 informa¸cãosobre o estado dos dispositivos. Esta informa¸cão éposteriormente guardada na base de dados ZenEvents.

6. Process Class [31] permite a defini¸cãodos processos a monitorizar no sistema e a recolha da informa¸cãodo 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 `asua funcionalidade. Essas duas classes s˜aoa dos Grupos (Groups) e Sistemas (Systems)

8. Location class permitem indicar o local do dispositivo.

Efectuando um paralelismo entre o diagrama entidade rela¸cãoque ilustra um esquema de defini¸cãode IC na CMDB proposto por baron et al. [28], Seçcão4.2.1 e o modelo de dom´ınio da CMDB do Zenoss podemos constatar que:

• um Conﬁguration Item ´eum Device

• os atributos dos itens de configura¸cão(CI Attribute, Attribute, Attribute Type) correspon- dem no Zenoss àsseguintes classes: Location, System, Group, hardware, OperatingSystem.

• As rela¸cões entre IC (CI relationship) tambémexistem no Zenoss, pois époss´ıvel estabelecer rela¸cõesentre 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 Seçcão4.2.1. 68 CAPÍTULO 5. CONCRETIZAÇ AO˜ DA SOLUÇ AO˜

5.2.5 Raz˜oesda Adop¸c˜aodo Zenoss

O Zenoss possibilita satisfazer os requisitos definidos pelo LIP, e constantes na Seçcão3.3 e permite ser utilizado para manter os activos da institui¸cãoe ser integrado com o sistema da Gestãode Altera¸cões.A parte relativa àintegra¸cãoencontra-se descrita na Seçcãoabaixo. (Ver tambémSeçcão5.1.4.4)

5.2.6 O Zenoss como Gestor de Conﬁgura¸c˜oesno LIP

Larry Klosteboer [33] indica duas abordagens que podem ser utilizadas para introduzir os dispositivos na CMDB: a primeira abordagem (waterfall) consiste em reunir o máximode dados poss´ıveis de todo o ambiente e depois integrar e ligar os dados, obtendo assim um sistema de GC completo. Esta éuma abordagem mais directa e activa mas quase sempre resulta numa quantidade de dados muito elevada, o que torna a conclusãodesta tarefa demorada. A segunda abordagem (trickle) consiste em criar pontos de integra¸cãoem cada uma das áreas-chave de processos operacionais que possam lidar com os dados de configura¸cão.

Executando opera¸cõesnormais com estes pontos de integra¸cão,os dados dos itens de configura¸cão(IC) sãointroduzidos na CMDB na medida em que vãosendo alterados ou àmedida que vãocausando incidentes. Esta éuma abordagem muito menos arriscado, mas que atrasa os benef´ıciosde ter uma imagem completa de gestãode configura¸cão.De acordo com o modelo proposto para o processo de GC, a segunda abordagem de Larry Klosteboer foi adoptada: uma modifica¸cãode um dado IC ao abrigo do processo de GC surge sempre em resultado de um pedido de altera¸cãocertificado e aprovado, sendo posteriormente essa informa¸cão(dados dos itens de configura¸cão,IC e atributos) introduzida na base de dados do Zenoss.

5.2.7 Modelo de Actividades do Processo de GC e sua Concretiza¸c˜aono Zenoss

Identifica¸cão,Especifica¸cãoe Controlo da Configura¸cão

O Zenoss fornece um modelo de dom´ıniopara o repositóriode itens de configura¸cãobastante ajustado ao contexto deste trabalho. Apesar de ser poss´ıvel estender este modelo com a cria¸cão inicial de novas classes de objectos, assume-se que essa necessidade surge naturalmente com o decorrer das actividades de Identifica¸cãoe Especifica¸cãode Configura¸cões. Desta forma, cabe ao Gestor de Configura¸cõespercorrer 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 métodos (Zenpacks) de estender as funcionalidades da ferramenta, nomeadamente a cria¸cãode novas classes de objectos e métodos de monitoriza¸cãodos mesmos. 5.2. ZENOSS 69

A actividade de Controlo da Verifica¸cãodeve apenas ser desencadeada pelo Gestor de Con- figura¸cõesdepois de se assegurar (percorrendo as outras actividades propostas) que nãoexistem incoerênciasentre a informa¸cãoque se pretende adicionar/modificar/remover e os conteúdosda CMDB.

A inser¸cãoda informa¸cãono Zenoss pode ser levada a cabo de trêsformas:

1. atravésdo interface gráfico

2. atrav´esdo interpretador interactivo executado na linha de comando, denominado Zendmd

3. atrav´esde uma API dedicada

De forma a automatizar o processo de inser¸cãode conteúdosno Zenoss, desenvolveu-se uma aplica¸cãoem python que recorre àsfuncionalidades disponibilizadas pela API do Zenoss. A aplica¸cãoépresentemente capaz de inserir conteúdosXML (ver Seçcão5.1.4.4) disponibilizada pelo RT via http. O Gestor de Configura¸cãopode, de forma simples e semi-automática,executar a aplica¸cãona linha de comandos para iniciar liga¸cõesàbase de dados e inserir novos dispositivos. Como desenvolvimentos futuros pretende-se:

• estender a aplica¸cãopara a remo¸cãoe modifica¸cãode itens de configura¸cão.

• estender a aplica¸cãopara a valida¸cãoautomáticade conteúdos,dando uma vertente au- tomáticaàsactividades de Identifica¸cãoe Especifica¸cãode Configura¸cão.

• a automatiza¸cãoda execu¸cãoda aplica¸cão,(váriasvezes ao dia), alertando o Gestor de configura¸cãosempre que exista a ocorrênciade problemas

Auditoria

A pr´opriaferramenta Zenoss pode desencadear a actividade de Auditoria tendo em contas as capacidades de descobrir e monitorizar dispositivos.

O Zenoss possibilita váriasformas de descobrir/introduzir dispositivos e as suas componentes. O método mais simples émanualmente (manual discovery), atravésdo interface do utilizador, e a´ıo Gestor de Configura¸cõespode especificar os váriosatributos do dispositivo. Esta solu¸cãocontudo quando se pretende introduzir um númeroelevado de dispositivos nãoé a mais adequada. Uma outra forma de descoberta poss´ıvel a utilizar, éindicar uma rede, e o Zenoss consegue descobrir todos os dispositivos existentes nessa rede. 70 CAPÍTULO 5. CONCRETIZAÇ AO˜ DA SOLUÇ AO˜

Figura 5.13: Gr´aﬁcosde Desempenho Disponibilizados pelo Zenoss.

No Zenoss existe o conceito de evento, e que representa uma manifesta¸cãode uma ocorrência importante no sistema. Os eventos podem ser gerados internamente (ex: quando um limite estabelecido éultrapassado) durante o processo de descoberta e monitoriza¸cão,ou externamente, (atravésde 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 sãomani- pulados assim que entram no sistema. Entre as regras e açcõesposs´ıveis de configurar, temos as regras de alerta que permitem enviar emails ao administrador de sistema ou mesmo iniciar a execu¸cãode scrips pré-configuradasque minimizam o impacto de uma alerta.

Apóso processamento dos eventos (cujo historial émantido separadamente numa base de dados MySQL), sãoapresentados sob a forma de uma consola de eventos na interface web. Os váriosestados poss´ıveis para um evento são: Critical, Error, Warning, Info, Debug e Clear. Cap´ıtulo6

Avalia¸c˜ao

Neste cap´ıtulosãodiscutidos os resultados atingidos avaliando-se se as questõesde investiga¸cão colocadas na Seçcão1.2 se encontram respondidas.

Quest˜ao1: Como desenhar o processo de GA para permitir, de uma forma comum e coerente, gerir as altera¸c˜oesna infra-estrutura f´ısica,de rede e de servi¸cos do CC?

Foi proposto um processo de GA, de acordo com a framework ITIL, tendo-se estabelecido quais as suas principais actividades, quais os responsáveis pela sua execu¸cãoe quais os critérios de categoriza¸cão.Foram identificadas as principais funcionalidades de um sistema de GA que implementa o processo proposto, e que esteja alinhado com as práticascomuns e com os principais procedimentos da institui¸cãoonde se insere.

Para poder desenhar o sistema de GA foi necessárioo conhecimento da institui¸cãoLIP: saber o contexto no qual se enquadra e como sãoefectuados os principais procedimentos no seu CC.

Questão2: Como desenhar o processo de Gestãode Configura¸cõese a CMDB, para que as informa¸cõessobre a infra-estrutura, assim como as rela¸cõesentre 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 intervenientes e principais responsabilidades. Foram identificados os activos da institui¸cãoque terãoque ser mantidos na CMDB, e qual o fluxo de implementa¸cãoda CMDB.

Questão3: Que ferramentas podem ser utilizadas e de que forma podem ser adaptadas para concretizarem os processos de Gestãode Altera¸cõese de Gestãode Configura¸cões?

O sistema de GA foi concretizado atrav´esda ferramenta RT. A sua grande capacidade de

71 72 CAP´ITULO 6. AVALIAC¸ AO˜

ajuste a ambientes heterogéneos, a sua flexibilidade na configura¸cãode workflows, e a sua facili- dade de configura¸cãopermitiu a implementa¸cãodo processo de GA alinhado com a framework ITIL. Apósa devida configura¸cão,as funcionalidades da ferramenta permitem satisfazer os requisitos os requisitos apresentados na Seçcão3.3, e agora comparados na Tabela 6.1.

Requisito Caracter´ısticasdo RT

1. Sistema desenvolvido utilizando * open-source, licen¸caGNU Neg´ocio ferramentas open-source GPL

2. Fluxo de informa¸cãobaseado num *Notifica¸cõesvia: email, sms sistema de notifica¸cõesentre os scrips váriosintervenientes

NãoFuncionais 1. Restri¸cãoe acesso Controlado *Sistema multiutilizador com mecanismo de autentica¸cão Funcionais 1. Planeamento de interven¸cõessobre *Permite adaptar o workflow componentes informáticos(adi¸cão, àspreferênciasdo utilizador substitui¸cãoe remo¸cão) *Permite criar rela¸cõesde dependênciasentre tarefas

2. Registo de açcõesefectuadas sobre *Capacidade de rastrear o componentes informáticosincluindo histórico,Gestãode interven¸cõesde manuten¸cão dependências

3. Efectuar procuras sobre as ac¸c˜oes *TicketSQL Query Language efectuadas sobre determinado componente

4. Elaborar relatóriose estat´ısticas *Dashboards, que possibilitem obter métricaspara *ExtensãoRTX::Statistics os várioscomponentes informáticosda *Gráficos: on demand institui¸cão

Tabela 6.1: As Caracter´ısticasdo RT Permitem Satisfazer os Requisitos de Neg´ocio,Funcionais e N˜aoFuncionais estabelecidos. 73

O Sistema de GC foi concretizado utilizando a ferramenta Zenoss. O seu modelo revelou-se adequado ao contexto a implementar na institui¸cão,e as suas funcionalidades de monitoriza¸cão e auditoria revelaram-se uma mais valia na implementa¸cãodo processo de GC. A compara¸cão das caracter´ısticasdo Zenoss com os requisitos propostos encontra-se explicada na Tabela 6.2. 74 CAPÍTULO 6. AVALIAÇ AO˜

Requisito Caracter´ısticasdo Zenoss

1. Sistema desenvolvido utilizando * Vers˜aoZenoss Core gratuita Neg´ocio ferramentas open-source

2. Fluxo de informa¸cãobaseado num * Existênciade regras de sistema de notifica¸cõesentre os notifica¸cão(notifica¸cão váriosintervenientes por email e sms) que podem ser definidas na ocorrência de eventos definidos

NãoFuncionais 1. Autentica¸cãovia login/password * Sistema multiutilizador com mecanismo de autentica¸cão

2. Administrador com permissõespara * Manager: detémtodos os criar, apagar e manipular informa¸cãoem privilégios, ZenUser: todos os módulos do sistema permissõesde visualiza¸cão da informa¸cão

Funcionais 3. Registo de açcõesefectuadas sobre * Rastrear altera¸cõesfeitas componentes informáticos aos eventos, Controle de altera¸cõesfeitas à monitoriza¸cãodos servi¸cos

4. Registo de açcõesrealizadas pelos * Multiutilizador, Capacidade utilizadores e pelo administrador de rastrear o históricodas do sistema altera¸cões

5. Efectuar procuras sobre as ac¸c˜oes * Procuras por dispositivo, efectuadas sobre determinado (nome, endere¸coIP) componente

6. Elaborar relatóriose estat´ısticas * Relatórios:do inventárioglobal, que possibilitem obter métricaspara do históricocom as altera¸cões os várioscomponentes informáticosda na rede, com os detalhes dos institui¸cão dispositivos, dos problemas e da disponibilidade da rede existênciade gráficosque avaliam desempenho dos dispositivos (CPU, Free Memory)

7. Inventárioactualizado do equipamento * Possui base de dados com um de hardware existente no LIP modelo do inventárioe detalhes de configura¸cão,capacidade de descoberta automáticade dispositivos

Tabela 6.2: As Caracter´ısticasdo Zenoss Permitem Satisfazer os Requisitos de Neg´ocio,Funci- onais e N˜aoFuncionais estabelecidos 75

Como os activos presentes na CMDB sãoprovenientes de altera¸cõesrelativas àinfra- estrutura de Hardware, énecessáriauma integra¸cãoestes dois processos. Para atingir este objectivo édescrita um forma automáticada introdu¸cãode altera¸cõesprovenientes do RT na CMDB do Zenoss. 76 CAPÍTULO 6. AVALIAÇ AO˜ Cap´ıtulo7

Conclus˜ao

Neste cap´ıtulos˜aoapresentadas as conclus˜oese discutidas algumas possibilidades de desenvolvimento.

Esta tese teve como objectivo o estudo de um sistema que vise a optimiza¸cãoda opera¸cão e da gestãode um centro de cálculode um instituto de F´ısicaExperimental de Altas Energias (LIP) cuja principal actividade éo fornecimento de servi¸cosde computa¸cãoe armazenamento a utilizadores locais, e a investigadores remotos integrados em infra-estruturas de computa¸cão distribu´ıdas. A proposta incidiu sobre a implementa¸cãodos processos de Gestãode Altera¸cões e de Gestãode Configura¸cões,de acordo com a framework ITIL, considerados prioritáriospara efectuar o suporte diárioàsopera¸cõesda infra-estrutura.

Uma das fases mais importantes deste estudo consistiu em identificar os requisitos, e em avaliar os mecanismos ”ad-hoc”executados pelos váriosmembros do centro de cálculo,através de uma sériede entrevistas e avalia¸cões,e integrá-los num procedimento global que minimize poss´ıveis interrup¸cõescom as actividades presentemente levadas a cabo.

O modelo para o processo de Gestãode Altera¸cõesdesenvolvido consistiu em identificar um modelo e um fluxo de actividades adequado, em identificar os papéisdos váriosinterlocutores e os diferentes casos de uso, em estabelecer os estados das altera¸cões,e em estabelecer critérios para a categoriza¸cãoe avalia¸cãodas altera¸cões.Tendo em conta os requisitos disponibilizados, a concretiza¸cãoda solu¸cãofoi 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 Gestãode Configura¸cõesconsistiu na identifica¸cãodas principais actividades, dos interlocutores, dos casos de uso e dos itens de configura¸cão(hardware) a serem guardados, tendo em vista a minimiza¸cãoda existênciade informa¸cãoinconsistente ou incoerente. A introdu¸cãodos activos na CMDB éum passo importante do processo de GC. Sa- bendo que obter uma lista dos activos da institui¸cãoe das suas rela¸cõesentre si, seria uma tarefa dif´ıcilde concretizar e bastante demorada, devido àenorme quantidade de activos existentes e

77 78 CAP´ITULO 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 integra¸cãoem cada uma das áreas-chave dos processos operacionais que possam lidar com os dados de configura¸cão. Desta forma, em vez de se popular a CMDB com todos os activos de uma sóvez, o que ori- gina quase sempre uma CMDB desactualizada, optou-se por ir alterando a CMDB àmedida que os activos vãosofrendo revisões. E´ poss´ıvel, assim, manter uma CMDB permanentemente actualizada. A ferramenta Zenoss foi a seleccionada para a concretiza¸cãodo modelo dado a sua flexibilidade, extensibilidade e as suas propriedades de monitoriza¸cão,muito adequadas à actividade de auditoria.

A vantagens da implementa¸cãodestes dois processos no LIP sãoóbvias:

• O processo de GA possibilita determinar se uma dada altera¸cãoéexequ´ıvel e o seu impacto, e estabelecer que o fluxo de tarefas realizado por váriosintervenientes seja efectuado de forma mais célere,possibilitando também,a cada interveniente no fluxo de trabalho, saber qual o progresso da tarefa e os passos definidos para a sua execu¸cão.

• O processo de GC possibilita que, aquando da ocorrênciade uma altera¸cão,se consiga saber de forma correcta e actualizada quais os recursos existentes na institui¸cão.

A adop¸cãodas ferramentas (Request Tracker e Zenoss) revelou-se uma boa escolha, pois para alémde conseguirem implementar os processos definidos, permitem ir mais longe: o RT permite a implementa¸cãodo processo de Gestãode Incidentes, e o Zenoss permite monitorizar os activos constantes na sua CMDB, isto é,monitorizar a infra-estrutura de rede e hardware do CC da institui¸cão.

A implementa¸cãodos processos de GA e GC éum trabalho dif´ıcile longe de estar completo em qualquer institui¸cão. A continua¸cãodeste trabalho contemplaráo aumento do âmbito do tipo de altera¸cõespermitidas, de forma a tornar o processo mais geral e abrangente a todo o tipo de altera¸cõescom impacto na institui¸cão. A discussãodeste tópicoseguir-se-ána seçcão seguinte.

7.1 Trabalho a Desenvolver

Relativamente ao processo de GA, énecessárioaumentar o seu âmbito de forma a permitir outros tipos de altera¸cões, para alem daquelas jácontempladas e que dizem respeito a altera¸cões na infra-estrutura de hardware. Por exemplo énecessáriogerir as altera¸cõesrelativas ao software existente. Esta generaliza¸cãopoderálevar ao alargamento dos workflows jáexistentes, ou àposs´ıvel defini¸cãode novos workflows, o que poderáresultar numa reestrutura¸cãodas configura¸cõesimplementadas ao n´ıvel do RT. 7.1. TRABALHO A DESENVOLVER 79

Novas altera¸cõesimplicam a caracteriza¸cãode novos itens de configura¸cão,com novos atributos que poderãonãoestar contemplados na CMDB do Zenoss. Desta forma, étambémne- cessáriocontemplar a necessidade de expandir o Zenoss, e explorar as potencialidades oferecidas atravésdo seu módulode Zenpacks de forma a implementar novas funcionalidades e permitir a monitoriza¸cãode novos tipos de dispositivos.

O mecanismo de integra¸cãodos processos de GA e GC deve ser fortificado com o desenvolvimento da aplica¸cãode integra¸cãode forma a que algumas das actividades possam ser desenvolvidas de forma automática,isto é,sem interven¸cãohumana.

Finalmente, o processo de Gestãode Configura¸cõesdámuitas vezes origem a incidentes que geram novas altera¸cões. Desta forma, um patamar que ainda falta implementar éum modelo de Gestãode incidentes que feche o ciclo estabelecido pelos modelos implementados. 80 CAPÍTULO 7. CONCLUSAO˜ Bibliografia

[1] Judith M. Myerson. Cloud Computing Versus Grid Computing. Service Types, Similarities and Diﬀerences, 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] Oﬃce of Government Commerce. Itil Service Support. The Stationery Oﬃce. 2000.

[5] Oﬃce of Government Commerce. Itil Service Delivery. The Stationery Oﬃce. 2000.

[6] Oﬃce of Government Commerce. Planning To Implement Service Management. The Statio- nery Oﬃce. 2000.

[7] Oﬃce of Government Commerce. Application Management. The Stationery Oﬃce. 2000.

[8] Oﬃce of Government Commerce. ICT Infrastructure Management. The Stationery Oﬃce. 2000.

[9] Oﬃce of Government Commerce. Security Management. The Stationery Oﬃce. 2000.

[10] Baskerville, Richard L. 1999. Investigating Information Systems with Action Research. Commun. AIS, 2, 4.

[11] Oﬃce of Government Commerce. Best Practice for Service Support, Managing IT Services. The Stationary Oﬃce. 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 Conﬁguration Management Requirement Analysis and Prototype Implementation thesis. 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 T´ecnico,Universidade T´ecnicade 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 Classiﬁcation White Paper. Skill 1st Ltd. February 2009

[31] Methods of monitoring processes with Zenoss White Paper, Jane Curry. Skill 1st Ltd. February 2009

[33] Klosterboer, Larry. Implementing ITIL Conﬁguration 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 ApˆendiceA

Simbologia Utilizada nos Diagramas do Processo da Gestãode Configura¸cões

85 86APENDICEˆ A. SIMBOLOGIA UTILIZADA NOS DIAGRAMAS DO PROCESSO DA GESTAO˜ DE CONFIGURAC¸ OES˜

Forma de decisãoque indica um ponto de ramifica¸cão(Sim ou Não)no fluxo do processo, por exemplo, informa¸cão proveniente do cliente estácorrecta?

Forma que indica que o processo continua num diagrama diferente; o n´umeroindica a etapa do processo. Por exemplo, o processo continua num diagrama diferente na etapa 2.1

Forma que indica uma sequênciade açcõesque executam tarefas espec´ıficasembutidas dentro de um fluxo do processo externo, por exemplo, Gestãode Altera¸cões.

Identiﬁca bases de dados utilizadas nos ﬂuxos de processo, por exemplo a CMDB.

Actividade a realizar no ﬂuxo do processo, por exemplo, criar uma nova instˆancia na CMDB

Forma que indica fase inicial ou ﬁnal do ﬂuxo do processo. Por exemplo, Iniciar uma auditoria.

Forma que ilustra a sequênciade passos e a direçcãodo fluxo do processo. ApêndiceB

Descri¸cãodos Principais Casos de Uso do Sistema de Gestãode Altera¸cões

1. Criar RfC - Cen´arioPrincipal

2. Criar RfC - Cen´arioAlternativo

• Pré-condi¸cões:Coordenador registado e activado no sistema de GA • Cenário: (a) Preenchimento de campos personalizados obrigatórios (b) Avalia¸cãodo estado do RfC (c) Categorizar o RfC • Pós-condi¸cões: Nãoprocessar o RfC. Altera¸cãodo estado do RfC para Rejected. • Outra informa¸cão:O coordenador reavalia o RfC que foi criado e decide nãoprosse- guir com a sua implementa¸cão,guardando-se a informa¸cãoda razãodesta decisão.

3. Processar RfC - Cen´arioPrincipal

• Pr´e-condi¸c˜oes:

87 88APENDICEˆ B. DESCRIC¸ AO˜ DOS PRINCIPAIS CASOS DE USO DO SISTEMA DE GESTAO˜ DE ALTERAC¸ OES˜

– Coordenador registado e activado no sistema de GA – Existe RfC no estado new • Cenário: (a) Requisita servi¸cosespec´ıficos,preenchendo campos personalizados definidos (b) Altera¸cãodo estado do RfC para open (c) Notifica¸cãoautomáticadas pessoas responsáveis pela execu¸cãode tarefas • Pós-condi¸cões:Novos RfC gerados, dependentes do RfC original, que detalha a tarefa a ser implementada pelo executante

4. Fechar RfC - Cen´arioPrincipal

• Pré-condi¸cões: – Coordenador devidamente registado e identificado no sistema – Existênciade todos os RfC filhos no estado resolved • Cenário:Coordenador avalia as altera¸cõese decide que a altera¸cãoentra em produ¸cão, encerrando o RfC. • Pós-condi¸cões:RfC resolved

5. Fechar RfC - Cen´arioAlternativo

• Pré-condi¸cões: – Coordenador devidamente registado e identificado no sistema – Existênciade todos os RfC filhos no estado resolved • Cenário: (a) Coordenador avalia as altera¸cõesefectuadas pelos executantes (b) O coordenador decide nãoaceitar as altera¸cões,e indica a razãopela qual a altera¸cãonãose iráefectuar. • Pós-condi¸cões:RfC nãoexecutado e altera¸cãodo estado para rejected.

6. Consultar informa¸c˜ao- Cen´arioPrincipal

• Pré-condi¸cões: – Executante devidamente identificado e registado no sistema – Existênciade um novo RfC (RfC filho) derivado do RfC original que indica ao executante qual a sua tarefa e qual o estado do RfC original • Cenário:Visualiza qual a tarefa a desempenhar e o tempo que dispõe • Pós-condi¸cões:Informa¸cãoconsultada

7. Processar tarefas - Cen´arioPrincipal 89

• Pré-condi¸cões: – Executante devidamente identificado e registado no sistema – Existênciade um novo RfC (RfC filho) derivado do RfC original que indica ao executante qual a sua tarefa e qual o estado do RfC original • Cenário: – Implementa as tarefas solicitadas – Notifica o Coordenador que a tarefa estáconclu´ıda • Pós-condi¸cões:Tarefa conclu´ıdae RfC filho no estado resolved

8. Processar tarefas - Cen´arioAlternativo

• Pré-condi¸cões: – Executante devidamente identificado e registado no sistema – Existênciade um novo RfC (RfC filho) derivado do RfC original que indica ao executante qual a sua tarefa e qual o estado do RfC original • Cenário: – NãoImplementa as tarefas solicitadas – Notifica o Coordenador que a tarefa nãoestáconclu´ıda • Pós-condi¸cões:RfC filho nãofechado 90APENDICEˆ B. DESCRIÇ AO˜ DOS PRINCIPAIS CASOS DE USO DO SISTEMA DE GESTAO˜ DE ALTERAÇ OES˜

Figura B.1: Casos de Uso do Sistema de Gestãode Altera¸cões ApêndiceC

Descri¸cãodos Principais Casos de Uso do Sistema de Gestãode Configura¸cões

1. Deﬁnir Modelo da CMDB - Cen´ario Principal

• Cenário: (a) Definir IC e atributos (b) Definir Modelo da CMDB (c) Definir fluxo de implementa¸cãoda CMDB • Pós-condi¸cão:Modelo da CMDB

2. Alterar estrutura da CMDB - Cen´arioPrincipal

• Pré-condi¸cão:Sistema de GA emite um RfC. • Cenário: O RfC implica a necessidade de alterar a estrutura da CMDB pois éne- cessárioadicionar IC ou atributos nãocontemplados atéao momento ou remover IC ou atributos que se tornaram obsoletos. • Pós-condi¸cões:Modelo da CMDB alterado.

3. Alterar Conte´udosda CMDB - Cen´arioPrincipal

• Pré-condi¸cões:Sistema de GA emite um RfC. • Cenário:O RfC implica a necessidade de alterar conteúdosna CMDB. • Pós-condi¸cões:Modelo da CMDB actualizado.

4. Realizar Auditoria `aCMDB - Cen´arioPrincipal

91 92APENDICEˆ C. DESCRIC¸ AO˜ DOS PRINCIPAIS CASOS DE USO DO SISTEMA DE GESTAO˜ DE CONFIGURAC¸ OES˜

• Cenário:O Gestor de Configura¸cãoexecuta a auditoria, fazendo um rastreio dos IC, seja manualmente seja usando uma ferramenta, avaliando se encontra diferen¸casentre os activos registados na CMDB e os activos da institui¸cão. • Pós-condi¸cões:Caso nãoexistem diferen¸cas,a auditoria termina

5. Realizar Auditoria `aCMDB - Cen´arioAlternativo

Figura C.1: Casos de Uso do Sistema de Gestãode Configura¸cões ApêndiceD

Modelo L´ogicodo Request Tracker

Na ﬁgura D est´arepresentado o modelo de dom´ıniodo RT. As principais tabelas e entidades encontram-se descritas a seguir:

• Users A tabela Users éresponsável por guardar a informa¸cãorelativa aos utilizadores do RT, ou seja, quem realiza açcõesno sistema.

• Groups A tabela Groups éconstitu´ıdapor utilizadores e grupos aos quais podem ser concedidos direitos, nomeadamente o direito de visualiza¸cãode tickets, entre outros. Grupos podem conter utilizadores e grupos, mas nãose podem conter a si próprios.

• Access Control List (ACL) Tabela que permite estabelecer diferentes tipos de permiss˜aoentre as v´ariasentidades existentes no RT (tickets, queues, groups, users).

• Transactions Tudo o que acontece a uma ticket éregistado nesta tabela, desde a sua cria¸cãoate àsua eventual resolu¸cão.

• CustomFields Atravésdos CustomFields époss´ıvel que tickets e queues possuam meta-dados, confi- guráveis pelos utilizadores. Existem váriostipos tipos de CustomFields no RT,1 e cada um deles pode aceitar um valor únicoou múltiplos valores.

1Tipos de CustomFields existentes no RT: Fill in wikitext area, Upload one image, Upload multiple images, Upload one ﬁle, Upload multiple ﬁles, Fill in one text area, Enter one value, Enter multiple values, Select or enter one box, Select one value, Select multiple values, Enter one value with autocompletition, Enter multiple values with autocompletition

93 94 APENDICEˆ D. MODELO LOGICO´ DO REQUEST TRACKER

• Tickets O RT éum sistema de Ticketing, sendo um dos seus principais objectos o Ticket. Tickets sãoagrupados em queues, e sópodem pertencer a uma única Queue. Têmos seguintes atributos: ID, Queue, Owner, Subject, Priority, Time, Status, Told, Started, Due, Resolved.

• Queues Uma Queue éa unidade básicaadministrativa do RT. Cada ticket écategorizado e pertence a uma queue. Controlo de acessos, lógicade negócio(Scrips, Templates, Actions), notifica¸cõese campos personalizados sãoconfigurados nas queues, podendo depois ser aplicados a tickets. Quando os tickets sãosubmetidos ao Request Tracker, sãoenviados para queues a fim de serem processados, constituindo uma forma de categorizar tickets por áreasfuncionais.

• Scrips Scrips sãoo principal instrumento para configurar o comportamento, implementar workflows e estender a lógicade negóciono RT. Cada scrip éum conjunto de Condi¸cão,Açcão, Template e Stage. Se uma dada Condi¸cãose verifica, entãoo RT prepara a Açcãopara ser executada. Trata-se de um mecanismo muito geral e flex´ıvel que pode ser criado via o interface do RT ou entãocriando módulos Perl para cada condi¸cãoe açcãoa realizar. Os scrips podem ser aplicados a todas as filas a ou filas espec´ıficas.

• Templates Trata-se de texto éanexado a um scrip, quando uma dada açcãoéexecutada. ApêndiceE

Request Tracker Ticket Template

95 96 APENDICEˆ E. REQUEST TRACKER TICKET TEMPLATE ApˆendiceF

Scrips Conﬁgurados no Request Tracker

97 98 APENDICEˆ F. SCRIPS CONFIGURADOS NO REQUEST TRACKER ApˆendiceG

Estrutura do Ficheiro XML Gerado pelo Processo de Gest˜aode Altera¸c˜oes