Concepção de uma Plataforma de Gestão Integrada para Sistemas de Suporte à Computação Distribuída

Transcrição

1 Concepção de uma Plataforma de Gestão Integrada para Sistemas de Suporte à Computação Distribuída Sara Filipa Coutinho Barbas Valente (Licenciada) Dissertação para obtenção do Grau de Mestre em Engenharia Informática e de Computadores Júri Presidente: Orientador: Orientador: Vogal: Professor Doutor José Carlos Alves Pereira Monteiro Professor Doutor José Luís Brinquete Borbinha Professor Doutor Miguel Leitão Bignolas Mira da Silva Professor Doutor André Ferreira Ferrão Couto e Vasconcelos Novembro 2011

2 Agradecimentos Em primeiro lugar agradeço aos meus orientadores, Gonçalo Borges, Prof. José Borbinha e Prof. Miguel Mira da Silva pela sua orientação, apoio e disponibilidade durante este último ano. Gostaria também de agradecer ao LIP, em especial ao Prof. Mário Pimenta, a hipótese de continuar a minha formação. Agradeço aos meus amigos Rodolfo, Daniel e Alberto a ajuda prestada. Por fim um agradecimento muito especial à minha mãe e ao Luís Miguel pelo seu apoio incondicional. i

3 ii

4 Resumo Actualmente gerir uma empresa ou instituição seria impossível sem utilizar Tecnologias de Informação. Fornecer serviços de qualidade que permitem ao utilizador uma solução fácil e transparente no manuseamento da informação é uma tarefa árdua para quem os providencia. É neste domínio de elevada complexidade que a framework ITIL pode ajudar a encontrar soluções capazes de melhorar práticas na gestão, integração e manipulação da informação. A framework ITIL foca-se em descrever O QUE FAZER e não COMO FAZER, explicando em detalhe todos os processos mas não indica como devem ser implementados. Neste documento propusemos implementar os processos de Gestão de Configurações e Gestão de Alterações considerados prioritários para suportar as operações diárias decorrentes da gestão da infra-estrutura de uma organização. Utilizando o método Action Research, esta tese foi aplicada numa associação científica e técnica de utilidade pública cujos projectos de investigação, desenvolvimento e implementação são centrados sobretudo no domínio das infra-estruturas de computação distribuída e computação grid. Foi construído um sistema protótipo, sendo possível efectuar alterações relativas à infraestrutura 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ção, essa informação é registada na CMDB de forma correcta e actualizada. iii

5 iv

6 Abstract Currently managing an enterprise or institution would be impossible without the use of Information Technology. Providing quality services that allow the user an easy and transparent handling of information is a daunting task for anyone who provides it. ITIL is a framework that can help to provide solutions that improve practice management, integration and manipulation of information. ITIL describes WHAT TO DO and not HOW TO DO, explaining in detail all the processes but does not indicate how they should be implemented. In this document we proposed to implement Change Management and Configuration Management processes considered to be a priority to support the daily management operations of an organization. Using Action Research Method, this thesis was applied to a scientific and technical association of public utility whose research, development and implementation is also focused in the field of managing a distributed computing infrastructure. A prototype system was built, and now is possible to make faster changes on the hardware infrastructure. There is also the guarantee that, by the end of the change, this information is recorded in the CMDB correctly and updated. v

7 vi

8 Palavras Chave Keywords Palavras Chave ITIL Implementação ITIL Gestão de Alterações Gestão de Configurações CMDB Open Source Keywords ITIL ITIL Implementation Change Management Configuration Management CMDB Open Source vii

9 viii

10 Acrónimos AUGER The Pierre Auger Cosmic Ray Observatory CC Centro de Cálculo CCTA Central Computer and Telecommunications Agency CERN Organização Europeia para a Pesquisa Nuclear CMDB Configuration Management Database EGI European Grid Initiative ESA Agência Espacial Europeia EXIN Netherlands IT Examinations Institute FCCN Fundação para a Computação Científica Nacional GA Gestão de Alterações GC Gestão de Configurações IC Item de Configuração INGRID Iniciativa Nacional Grid ITIL Information Technology Infrastructure Library KPI Indicador Chave de Desempenho LIP Laboratório de Instrumentação e Física Experimental de Partículas NASA National Aeronautics and Space Administration RfC Request for Change RT Request Tracker SNOLAB Sudbury Neutrino Observatory Laboratory TI Tecnologias de Informação ix

11 x

12 Índice 1 Introdução Motivação Questões de Investigação Método de Investigação Estrutura da Tese Trabalho Relacionado Gestão da Infra-estrutura Gestão e Operação da Infra-Estrutura de Rede Gestão e Operação da Infra-Estrutura de Serviços Computacionais Aplicações para Gestão de Desempenho Produtos para Gestão de Eventos ITIL Áreas Relevantes para a Gestão de um Centro de Cálculo Suporte aos Serviços Benefícios Resultantes do ITIL Gestão de Configurações Gestão de Alterações Suporte à Gestão de Processos ITIL Software para Gestão de Configurações Software para Gestão de Alterações Problema Contextualização Causas e Problemas Principais nos Procedimentos do LIP Colecção e Caracterização de Requisitos Requisitos de Negócio Requisitos Não Funcionais Requisitos Funcionais xi

13 xii ÍNDICE 4 Proposta Sistema da Gestão de Alterações Modelo de Actividades Estados das Alterações Categorias de Alterações e Critérios de Avaliação Identificação de Funcionalidades Sistema de Gestão de Configurações Modelo de Actividades - Planeamento Definição dos Itens de Configuração Modelo da CMDB e Fluxo Operacional de Implementação Modelo de Actividades - Identificação Modelo de Actividades - Especificação Modelo de Actividades - Controlo da Configuração Modelo de Actividades - Auditoria e Verificação Identificação de Funcionalidades Concretização da Solução Request Tracker Arquitectura Modelo Lógico Razões da Adopção do Request Tracker Configuração do Request Tracker Ticket Actuando como RfC Fluxo de Tarefas (Workflows) Ciclo de Vida de um Ticket Inserção das Alterações na Gestão de Configurações Zenoss Monitorização Orientada ao Modelo de Configuração Principais Funcionalidades Arquitectura Modelo Razões da Adopção do Zenoss O Zenoss como Gestor de Configurações no LIP Modelo de Actividades do Processo de GC e sua Concretização no Zenoss 68 6 Avaliação 71 7 Conclusão Trabalho a Desenvolver

14 ÍNDICE xiii Bibliografia 79 A Simbologia Utilizada nos Diagramas do Processo da Gestão de Configurações 85 B Descrição dos Principais Casos de Uso do Sistema de Gestão de Alterações 87 C Descrição dos Principais Casos de Uso do Sistema de Gestão de Configurações 91 D Modelo Lógico do Request Tracker 93 E Request Tracker Ticket Template 95 F Scrips Configurados no Request Tracker 97 G Estrutura do Ficheiro XML Gerado pelo Processo de Gestão de Alterações 99

15 xiv ÍNDICE

16 Lista de Figuras 1.1 Fases da Investigação-Acção Exemplo de Ferramentas de Monitorização, Alerta e Reacção para Vários Recursos e Serviços de um CC Quadrante Mágico que Permite Avaliar um Fabricante de Produtos APM [14] Quadrante Mágico de Produtos ECA [15] Estrutura da Framework ITIL (ITIL V2) [11] Modelo de Suporte aos Serviços (ITIL V2) [11] Gestão das Alterações e Outros Processos ITIL [14] Processo da Gestão de Alterações Estados de um RfC [15] Software para Gestão de Configurações [17] Avaliação do Software para Gestão de Configurações [17] Avaliação do Software para Gestão de Alterações [17] Processo de Gestão de Alterações Adoptado Diagrama de Estados de uma Alteração Casos de Uso do Sistema de Gestão de Alterações Fases do Processo de GC, Proposto para o LIP Fase de Planeamento da Configuração Proposta para o LIP Diagrama Entidade-Relação (ER) Ilustrando um Esquema de Definição dos IC na CMDB Proposto por Baron et al.[28] Fase de Identificação da Configuração Proposta para o LIP Fase de Especificação da Configuração Fase de Controlo da Configuração Proposta para o LIP Fase de Auditoria da Configuração Proposta para o LIP Casos de Uso do Sistema de Gestão de Configurações Arquitectura do RT [29] Modelo Lógico do RT xv

17 xvi LISTA DE FIGURAS 5.3 Número e Estado de Tickets Existentes na Fila Hardware Change Request Criados a Partir de 13 Janeiro de Template de um Ticket no RT Configurado para Efectuar uma Alteração Ciclo de Vida um Ticket no RT - Parte Ciclo de Vida um Ticket no RT - Parte Ciclo de Vida um Ticket no RT - Parte Vista de Alto Nível do Zenoss [34] Workflow: Monitorização Orientada ao Modelo de Configuração [34] Mapa de Rede Arquitectura em Camadas do Zenoss Modelo de Domínio do Zenoss Gráficos de Desempenho Disponibilizados pelo Zenoss B.1 Casos de Uso do Sistema de Gestão de Alterações C.1 Casos de Uso do Sistema de Gestão de Configurações

18 Lista de Tabelas 2.1 KPIs para os Processos da GA e Gestão da Release [25] Critérios para Categorização de Alterações: A = Alteração Principal, B = Alteração Significante, C = Alteração Menor Período de Execução para as Diferentes Categorias de Alterações Tipos de ICs definidos para o LIP e seus atributos Relação entre Pedido de Alteração e Ticket As Características do RT Permitem Satisfazer os Requisitos de Negócio, Funcionais e Não Funcionais estabelecidos As Características do Zenoss Permitem Satisfazer os Requisitos de Negócio, Funcionais e Não Funcionais estabelecidos xvii

19 xviii LISTA DE TABELAS

20 Capítulo 1 Introdução 1.1 Motivação A Internet é cada vez mais um veículo privilegiado para a partilha e processamento de informação à escala global. Os problemas com que a ciência moderna se depara são de 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 útil sem que se recorra a mecanismos de colaboração globais. Algumas das grandes comunidades científicas actuais tais como o CERN e a NASA foram as principais impulsionadoras de soluções de computação distribuída destinadas a resolver problemas de grande dimensão, organizando-se de forma a partilharem os recursos computacionais de várias instituições através da Internet. Além da comunidade científica também empresas grandes e influentes, como a Google, a Amazon e a e-bay, exploram já modelos de computação distribuída e começam a disponibilizar, sob a forma de serviços acessíveis remotamente, a possibilidade de um utilizador requisitar tempo de computação ou espaço de armazenamento para as suas aplicações. É hoje possível, para um utilizador, recorrer aos dois paradigmas de computação distribuí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íficos de grandes dimensões sem ter que assegurar a gestão e a manutenção dos mesmos. No entanto, a disponibilização de grandes infra-estruturas de computação distribuída exige a operação de uma vasta gama de recursos e serviços complexos. Com a adopção da computação distribuída, quer pelas empresas quer pelos investigadores, muitos Centros de Cálculo (CC) vêem-se agora acrescidos de uma maior complexidade e responsabilidade. Para além da gestão local das suas infra-estruturas, são também parte de redes mais abrangentes que podem ser privadas, nacionais ou mesmo globais. Neste contexto, são responsáveis pela gestão do equipamento (físico e virtual) e pelos serviços que podem ser usados 1

21 2 CAPÍTULO 1. INTRODUÇÃO por vastas comunidades de utilizadores, e que devem ser permanentemente monitorizados de forma a garantir a qualidade de serviço requerida pelos clientes da infra-estrutura. A operação e o controlo de um parque de equipamentos tão vasto e diverso como o existente em qualquer CC actual é de extrema complexidade, dado o vasto número de ferramentas, de plataformas e de hierarquias entre recursos. Consequentemente, para diminuir o esforço de operação, é necessário compreender todos os componentes de um CC, por forma a identificar onde e como se podem optimizar recursos. Um CC é um espaço físico que aloja várias componentes informáticas, e componentes não informáticas. Além dos sistemas que possibilitam o serviço prestado aos utilizadores (componentes informáticas), existem serviços que asseguram que todo o equipamento funciona de forma correcta e num ambiente adequado (componentes não informáticas). Ou seja, aos desafios técnicos e heterogéneos, ocorrentes na gestão dos variados serviços computacionais, prestados pelo CC, outros desafios são importantes: a adequada alocação do espaço e dos equipamentos, a monitorização das condições ambientais, a vigilância do espaço, bem como a manutenção dos equipamentos são procedimentos de operação tão válidos como a operação dos serviços para a comunidade, e requerem a gestão de procedimentos de forma rápida e eficaz. Os dispositivos da rede (ex: routers, hubs, switchers, etc) devem manter-se operacionais. Também neste domínio ferramentas de monitorização são utilizadas para detectar e produzir alarmes de forma que a equipa técnica possa ser notificada caso alguma anomalia na rede ocorra. A monitorização do tráfego de rede é também necessária por uma questão de segurança nas organizações actuais. As organizações sofrem ataques aos seus dados e aos seus equipamentos, a maioria deles através da rede. Monitorizar o tráfego na rede é uma das preocupações de quem gere um CC, que para além da vertente de segurança, pretende também controlar os gastos económicos. As infra-estruturas física e de rede de um CC servem o propósito de fornecer serviços aos utilizadores. Alguns serviços são transversais a qualquer tipo de organização, seja ela de grande, média ou pequena dimensão. Exemplos desses serviços são o DNS, o correio electrónico, os serviços web, os serviços de autenticação, os serviços de bases de dados ou serviços de repositórios, e cujo mau funcionamento põe em risco todas as camadas de serviços superiores tais como os de computação, de armazenamento e outros. É neste domínio de elevada complexidade que é o da gestão de um CC, que surge a framework ITIL (Information Technology Infrastructure Library Versão 2) [4] [5] [6] [7] [8] [9] frequentemente referenciada como sendo o manual de boas práticas na gestão, integração e manipulação da informação gerada num CC. O ITIL Versão 2 é uma compilação vasta, organizada em diversas áreas, sendo a área do Suporte aos Serviços, que trata dos processos necessários à manutenção das operações diárias, a primeira que deve ser concretizada. Desta área fazem parte dois processos intrinsecamente

22 1.2. QUESTÕES DE INVESTIGAÇÃO 3 ligados: Gestão de Alterações e Gestão de Configuração, tornando-se imprescindível relacionálos. A CMDB (Configuration Management Database) é um repositório dos dados relacionados com todas as componentes do sistema de informação de uma empresa/instituição e é uma parte fulcral do processo de Gestão de Configurações. 1.2 Questões de Investigação O propósito desta tese é compreender como se efectua a Gestão da Infra-estrutura Física e de Rede de um CC: quais os processos envolvidos, quais são prioritários, quem são as pessoas responsáveis pela execução de tarefas, como são executadas essas tarefas e quais os recursos envolvidos. Faz parte ainda do âmbito 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ção numa instituição e como esta alteração afecta os recursos existentes. Em suma o objectivo é encontrar uma resposta para as seguintes questões: 1. Questão 1: Como desenhar o processo de Gestão de Alterações para permitir, de uma forma comum e coerente, gerir as alterações na infra-estrutura física, de rede e de serviços do CC? 2. Questão 2: Como desenhar o processo de Gestão de Configurações e a CMDB, para que as informações sobre a infra-estrutura, assim como as relações entre os seus diversos itens, sejam conhecidas, estejam globalmente acessíveis e num estado actualizado? 3. Questão 3: Que ferramentas podem ser utilizadas e de que forma podem ser adaptadas para concretizarem os processos de Gestão de Alterações e de Gestão de Configurações? 1.3 Método de Investigação O método de investigação utilizado no desenvolvimento desta tese é o designado como Investigação-Acção (Action Research) [10]. Este método de investigação surgiu nos meados do século XX e foi inicialmente utilizado nas ciências médicas e sociais, quando se pretendia introduzir uma nova terapêutica e analisar os efeitos daí resultantes. Desde os finais dos anos noventa começou também a ser adoptado na área dos sistemas de informação. Este método segue um abordagem orientada à mudança, pressupondo que os processos sociais complexos podem ser estudados através da introdução propositada de alterações (entropia

23 4 CAPÍTULO 1. INTRODUÇÃO controlada), observando, à posteriori, os efeitos resultantes dos factores exteriormente injectados no sistema. No método Investigação-Acção, o investigador pretende experimentar uma teoria com indivíduos em ambientes reais, avaliando continuamente os resultados e introduzindo correcções ou novos dados, repetindo este processo até atingir um resultado considerado correcto. Para ser possível calcular o efeito da introdução propositada de uma alteração e posteriormente a sua avaliação, é seguido um processo de investigação sistemático e iterativo, cujo conhecimento adquirido em cada iteração pode ser colocado em prática na iteração seguinte. O domínio ideal de acção para este método é caracterizado por: um ambiente onde o investigador intervém directamente no próprio sistema em estudo como um actor do mesmo, passando a fazer parte do objecto da investigação. o conhecimento obtido poder ser imediatamente aplicado um processo de pesquisa cíclico ligando teoria e prática A Investigação-Acção deve estar definida por um plano de investigação e um plano de acção, ambos suportados por um conjunto de métodos e regras. São as chamadas fases do processo metodológico. Assim, para se concretizar um processo de Investigação-Acção, será necessário seguir quatro fases: Diagnosticar ou descobrir o problema. Construir o plano de acção. Propor a execução do plano e observar o seu funcionamento. Reflectir, interpretar e integrar os resultados. Construir um novo plano.

24 1.4. ESTRUTURA DA TESE 5 As fases da Investigação-acção assumem a configuração apresentada na Figura 1.1. Figura 1.1: Fases da Investigação-Acçã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ção utilizado na sua resolução. 2. O capítulo 2 apresenta o Trabalho Relacionado, incluindo a apresentação/avaliação dos produtos existentes de gestão da Infra-estrutura física e de serviços duma organização. Descreve os processos de Gestão de Alterações e de Gestão de Configuraçõ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ítulo 3 é apresentado um diagnóstico da forma como são efectuados os procedimentos diários para gerir o CC do LIP, e são definidos os requisitos funcionais, não funcionais e de negócio a satisfazer. 4. No capítulo 4 são apresentados os processos de Gestão de Configurações e de Gestão de Alterações que o LIP deve adoptar para satisfazer os requisitos pretendidos. Os diagramas de fluxo de processo incluídos neste capítulo utilizam a simbologia constante no Apêndice A.

25 6 CAPÍTULO 1. INTRODUÇÃO 5. No capítulo 5, é descrita a forma como as ferramentas seleccionadas (Request Tracker e Zenoss) podem ser utilizadas para concretizar os processos definidos no capítulo Conclusão e apresentação de Trabalho Futuro. Esta tese executa um ciclo do Método de Investigação-Acção: a Fase de Planificação é constituída pelos capítulos 1, 2 e 3, a Fase de Acção é constituída pelos capítulos 4 e 5 e a Fase de Reflexão é apresentada nos capítulos 6 e também na Conclusão. O Método de Investigação-Acção indica que o investigador deve experimentar uma teoria com indivíduos em ambientes reais. O Centro de Cálculo do Laboratório de Instrumentação e Física Experimental de Partículas (LIP) é a organização onde se tenta responder às questões levantadas nesta tese. O contexto desta instituição é explicado na Secção 3.1.

26 Capítulo 2 Trabalho Relacionado 2.1 Gestão da Infra-estrutura Os Centros de Cálculo (CC) são responsáveis pela gestão do equipamento (físico e virtual) e pelos serviços que podem ser usados por vastas comunidades de utilizadores, e que devem ser permanentemente monitorizados de forma a garantir a qualidade de serviço requerida pelos clientes da infra-estrutura. Para fazer a gestão das múltiplas componentes de um CC existem ferramentas que propiciam uma operação controlada dos recursos. Na Figura 2.1 apresentamos alguns dos serviços típicos que funcionam sobre os diferentes tipos de infra-estruturas de CC: física, rede e de serviços. A cada tipo de infra-estrutura e serviço, e dependendo da funcionalidade a vigiar, tenta-se configurar e adequar a ferramenta de monitorização e alerta que melhor encaixa na arquitectura e topologia do CC. Na presente Secção comparam-se algumas das ferramentas de monitorização existentes, tanto open-source como comerciais, cuja funcionalidade é a monitorização da rede e dos serviços existentes num CC Gestão e Operação da Infra-Estrutura de Rede A monitorização do tráfego de 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ção de possíveis riscos de segurança, já que os ataques aos dados e aos equipamentos, provêm na sua maioria através da rede. Para efectuar a monitorização utilizam-se sistemas de monitorização da rede cujo objectivo é fornecer uma visão centralizada da rede e dos sistemas, para que os seus administradores consigam analisar as condições e evitar/corrigir os problemas rapidamente e de forma eficiente. Três soluções open-source (Nagios, OpenNMS, Zenoss) para gestão de sistemas são avaliadas no estudo realizado por Jane Curry [12]. 7

27 8 CAPÍTULO 2. TRABALHO RELACIONADO Figura 2.1: Exemplo de Ferramentas de Monitorização, Alerta e Reacção para Vários Recursos e Serviços de um CC. O estudo conclui que o Nagios é uma ferramenta bem testada, fiável e com uma grande comunidade de utilizadores. As notificações são simples de configurar, mas caso seja necessária a produção de análises baseadas em registos fornecidos pelo Nagios talvez esta não seja a solução a escolher. O Zenoss e o opennms são produtos com funcionalidades de discovery, monitorização da disponibilidade, gestão de problemas, gestão de desempenho e reporting. O Zenoss tem também alguma capacidade de topology mapping e tem melhor documentação que o OpenNMS. O estudo revela que a arquitectura de eventos, alarmes e notificações do OpenNMS é bastante confusa. A autora refere o Zenoss como a melhor escolha, esperando que a comunidade Zenoss melhore alguns aspectos nomeadamente a documentação. No estudo, Monitoring Systems Comparison, de Scott Stone [13], comparam-se outras três soluções capazes de monitorizar a rede: Hyperic, Lithium e o Zabbix. Todas possuem um modelo híbrido de licenciamento, ou seja têm uma versão gratuita 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ção, resultantes da avaliação [13] efectuada.

28 2.1. GESTÃO DA INFRA-ESTRUTURA 9 Hyperic: o ponto forte desta solução é a monitorização do desempenho de aplicações, sendo vasta a variedade de aplicações que esta ferramenta consegue monitorizar.possui características de auto-discovery muito desenvolvidas permitindo: a auto-detecção das aplicações a monitorizar e a configuração automática de certos parâmetros de monitorização para valores de omissão bastante razoáveis, que à posteriori, o administrador pode modificar consoante a sua vontade. uma instalação semi-automática com intervenção mínima do administrador de sistemas 1 Quando é necessária uma intervenção por 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ção pois os sistemas e serviços são organizados de forma automática. Os gráficos com os dados do desempenho das aplicações são fáceis de interpretar, e com legendas apropriadas. Não possui funcionalidades para a geração de relatórios, no entanto, caso a informação fornecida pela interface de utilizador seja insuficiente, é possível inquirir a base de dados SQL usando uma report-generating engine. Na edição comercial (Enterprise edition) incorpora características de gestão de alterações, ficheiros de log de monitorização e uma política de alertas Policy-driven. Lithium: é uma solução simples de monitorização do estado e desempenho do hardware que utiliza exclusivamente o SNMP e que não possui qualquer capacidade da monitorização de aplicações. A versão gratuita, vem com diversos perfis pré-construídos de SNMP para monitorização de hardware de rede tais como routers Cisco, switches Cisco, switches Foundry, firewalls Cisco, entre outros. Tem duas interfaces separadas, uma web based, e outra que é uma solução nativa, mais agradável e com mais funcionalidades. O Lithium tem diversos relatórios pré-definidos que podem ser gerados, incluindo um relatório que indica o uso da largura de banda. Zabbix: Zabbix é outro bom exemplo de software da monitorização da rede, embora não tão completo quando comparado com o Hyperic em termos de monitorização de aplicações. É uma solução híbrida das duas soluções descritas anteriormente: baseia as suas verificações tanto em SNMP como em agentes específicos do Sistema Operativo. No presente momento não possui Auto-Discovery embora tal funcionalidade esteja planeada. Duas das características mais agradáveis são a capacidade de representação gráfica: pode criar um mapa de rede que mostra a localização física e lógica dos dispositivos de rede e as suas dependências. Os gráficos de desempenho são claros, concisos, e fáceis de ler. A interface de utilizador de Zabbix é completamente web based, sendo as características de gerar relatórios similares ao Hyperic. 1 Para fazer o deploy do Hyperic, o administrador tem somente que instalar a console/servidor do software no nó de gestão e depois fazer o deploy dos agentes nos nós a ser geridos(controlados). O código dentro dos agentes fará o auto-discovery apropriado e registá-lo-á automaticamente no servidor

29 10 CAPÍTULO 2. TRABALHO RELACIONADO Gestão e Operação da Infra-Estrutura de Serviços Computacionais As infra-estruturas física e de rede de um CC servem o propósito de dar suporte a serviços prestados aos utilizadores sendo alguns serviços transversais a qualquer tipo de organização, seja ela de grande, média ou pequena dimensão. Exemplos desses serviços são o DNS, o correio electrónico, os serviços de autenticação, os serviços de bases de dados ou serviços de repositórios, e cujo mau funcionamento põe em risco todas as camadas de serviços superiores tais como os de computação, de armazenamento e outros. Para monitorizar estes serviços existem ferramentas de monitorização que avaliaremos na presente Secção Aplicações para Gestão de Desempenho Aplicações para Gestão do Desempenho (Application Performance Management - APM), são aplicações que se focam na monitorização, desempenho e disponibilidade do serviço de aplicações de software. Segundo o estudo da Gartner de 2010 [14], no qual se analisam aplicações APM (ver Figura 2.2), a gestão das operações de Tecnologias de Informação (TI), realizadas pelos administradores de sistemas, tornou-se cada vez mais dependentes de aplicações, complexas de gerir. O estudo evidencia ainda que muitas vezes, uma organização sente necessidade de misturar e combinar ofertas de diferentes fabricantes para assim conseguir uma solução que seja ajustada às suas necessidades Produtos para Gestão de Eventos As organizações de Tecnologias de Informação (TI) precisam de consolidar, analisar e responder aos eventos oriundos das componentes da Infra-estrutura, para assim conseguirem melhorar os serviços prestados. Existem no mercado vários produtos, uns emergentes e outros mais maduros, que respondem a esta necessidade das organizações. Tais produtos são denominados de Event Correlation and Analysis - (ECA) e os seus objectivos principais são ajudarem as organizações a lidar com o dilúvio de eventos que advêm da infra-estrutura de TI pois conseguem eliminar sinais de eventos duplicados, filtrar os eventos de acordo com as operações ou de acordo com as prioridades e analisar os eventos conseguindo-se assim determinar a sua causa. Este tipo de produtos executam uma gestão por excepção, ou seja, produzem uma alerta só quando uma excepção ocorre, por exemplo em caso de falha ou de violação de um limite estabelecido, o que indica que a infra-estrutura não está a ter um comportamento normal. Este facto implica o conhecimento pela organização do que é um comportamento normal. A Gartner efectuou um estudo [15] no qual avaliou alguns destes produtos, e cujas conclusões se encontram ilustradas na Figura 2.3. Produtos posicionados no quadrante visionaries possuem uma visão de futuro e são geralmente tecnicamente focados. Reconhecem e conseguem

30 2.1. GESTÃO DA INFRA-ESTRUTURA 11 Figura 2.2: Quadrante Mágico que Permite Avaliar um Fabricante de Produtos APM [14]. responder às tendências da gestão de eventos a longo prazo do mercado, faltando-lhes contudo reconhecimento, e força de mercado e de vendas. No quadrante leaders estão colocados os produtos com elevado grau de visibilidade no mercado e que conseguem oferecer aplicações altamente robustas e escaláveis capazes de prioritizar eventos oriundos de ambientes físicos e virtuais da infra-estrutura de TI. Possuem a visão estratégica que lhes permite atender de forma rápida aos requisitos, em constante evolução. Produtos novos no mercado de gestão de eventos, que se focam num segmento pequeno do mercado, mas que conseguem atingir grande profundidade nas funcionalidades nas suas áreas de escolha estão colocados no quadrante niche players. No quadrante challengers encontram-se produtos que têm um bom desempenho em muitas organizações. Alguns são grandes produtos em termos de dimensão e recursos financeiros, mas aos quais por vezes falta visão, inovação e percepção da evolução das tendências do mercado. Podemos concluir que é extremamente difícil encontrar uma solução que responda a todos os requisitos de um CC, e que normalmente não são soluções integradas, obrigando à utilização de diferentes plataformas e interfaces, consoante o problema que se pretende resolver.

31 12 CAPÍTULO 2. TRABALHO RELACIONADO Figura 2.3: Quadrante Mágico de Produtos ECA [15]. Na tentativa de integrar toda a informação gerada pelas ferramentas de gestão, configuração e monitorização dos diferentes recursos, várias organizações usam modelos de princípios de operação que descreveremos na Secção seguinte. 2.2 ITIL A presente Secção apresenta uma das soluções que permite integrar, manipular e gerir a informação gerada num CC: a framework ITIL (Information Technology Infrastructure Library) [16] [4], sobre a qual nos debruçaremos mais profundamente. No entanto, existem outras frameworks com objectivos similares tais como o COBIT [17] [18] e o CMMI [19]. A framework ITIL é uma compilação de boas práticas de gestão de TI obtidas a partir de organizações públicas e privadas. Foi desenvolvido originalmente pelo governo britânico através da CCTA, e actualmente é mantido pelo EXIN. Esta framework descreve os processos necessários para gerir uma infra-estrutura de TI de forma eficaz e eficiente, garantindo os níveis de serviço que os clientes têm que exigir e que os prestadores de serviço devem fornecer. Os principais objectivos desta framework são reduzir custos, aumentar a disponibilidade, ajustar a capacidade, aumentar a eficiência e eficácia e reduzir

32 2.2. ITIL 13 riscos. A documentação ITIL 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 áreas que se estruturam como representado na Figura 2.4 [20]. Figura 2.4: Estrutura da Framework ITIL (ITIL V2) [11] Áreas Relevantes para a Gestão de um Centro de Cálculo Uma das áreas de maior relevância na gestão e operação de um CC moderno é a Gestão de Serviços que engloba a área do Suporte aos Serviços [20]. O Suporte aos Serviços, como ilustrado na Figura 2.5, trata dos processos necessários à manutenção das operações diárias e de suporte aos serviços prestados pela organização Suporte aos Serviços A área do Suporte aos Serviços fundamenta-se em cinco processos e uma função (Service Desk): 1. Gestão de Incidentes é o processo onde os incidentes são detectados e resolvidos. Um incidente é um evento que não faz parte da execução normal de um serviço e que pode causar uma interrupção 2. Gestão de Problemas é o processo que detecta e remove da infra-estrutura de TI, através da determinação da origem e análise do problema, a ocorrência de 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ência e relatando os erros encontrados.

33 14 CAPÍTULO 2. TRABALHO RELACIONADO Figura 2.5: Modelo de Suporte aos Serviços (ITIL V2) [11]. 3. Gestão de Alterações é o processo que controla a mudança de todos os Itens de Configuração (IC), garantindo que procedimentos apropriados são seguidos quando é efectuada uma mudança. 4. Gestão da Release é o processo que após uma alteração ter sido aprovada pelo processo da Gestão das Alterações, controla o armazenamento físico e lógico, gestão e distribuiçã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ão da Configuração é o processo de rastreio de todos os itens existentes na infraestrutura incluindo hardware, software e documentação bem como todas as relações existentes entre eles e que suportam os serviços. Este processo envolve identificar, registar e descrever as componentes de TI, (IC), incluindo as versões, relações e componentes. A informação de todas os IC deve ser mantida numa base de dados modular e flexível. Service Desk é uma função que age como único ponto de entrada entre o utilizador e a organização de TI (SPOC - Single Point Of Contact), e cujo objectivo é ajudar a resolver problemas e restaurar a normalidade das operações o mais rápido possível.

34 2.2. ITIL Benefícios Resultantes do ITIL A mudança é uma constante num CC. Rastrear, gerir e controlar as alterações e o seu potencial impacto nos serviços prestados torna-se, portanto, imperativo. Esta é uma das principais razões pelas quais os gestores de um CC começam a olhar para os processos desta framework. Esta Secção descreve os benefícios resultantes da implementação da framework ITIL num CC que incluem uma melhor gestão dos recursos e a consolidação dos dados existentes. A framework ITIL permite ainda um melhor entendimento dos recursos disponíveis, rastrear das mudanças na infra-estrutura do CC e quantificar o impacto de tais mudanças nos serviços fornecidos. Com operações cada vez mais complexas e mais orientadas ao serviço, os gestores sentem necessidade de criar processos que lhes permitam manter uma ordem na execução das tarefas. A framework ITIL fornece uma disciplina, uma linguagem e processos comuns que depois de implementados introduzem coerência para todos os que trabalham num CC. O conceito principal que devemos ter em conta é a uniformização: uniformização de um glossário e termos comuns, que eliminem deficiências de comunicação entre o grupo de trabalho, e uniformização de processos e métricas quantificáveis que permitam um serviço de elevada disponibilidade. Devido à enorme quantidade de serviços abrangidos pela metodologia ITIL, implementá-los parece uma tarefa gigantesca. Quem já o implementou afirma que a melhor maneira é começar com as áreas mais problemáticas de um CC, que são as áreas de Gestão de Problemas (GP), Gestão de Alterações (GA) e Gestão de Configurações (GC). Na Secção seguinte analisa-se em detalhe um sistema de Gestão de Configurações e que aspectos se devem ter em conta para atingir o sucesso, dado que esta é a pedra basilar de qualquer plataforma de gestão integrada de recursos Gestão de Configurações O processo da Gestão de Configurações [4] é responsável por identificar, registar e relatar todas as componentes de TI, nomeadamente as suas versões, os seus constituintes e relações, pertencentes à organização. Este processo é ainda responsável por providenciar a todos os restantes processos, informação de configuração, correcta e actualizada. Objectivos: Os objectivos do processo de GC são: inventariar os recursos e configurações dentro da organização e também dos seus serviços, fornecer informações exactas da configuração e da documentação necessárias aos processos de Gestão de Serviços,

35 16 CAPÍTULO 2. TRABALHO RELACIONADO fornecer uma base sólida para os restantes processos que constituem o ITIL, Comparar os registos de configuração com a infra-estrutura e corrigir eventuais excepções. Configuration Management Database Configuration Management Database (CMDB) é a designação genérica do repositório de toda a informação relacionada com as componentes que existem numa organização de TI. Os registos deste repositório chamam-se Itens de Configuração (IC), sendo um IC qualquer componente que está sob o controle do processo da Gestão de Configurações. A CMDB também inclui informação sobre a relação entre os IC, sendo este o aspecto que distingue a CMDB de uma base de dados tradicional. Todos os IC são univocamente identificados por nomes, números de versões e outros atributos, variando em complexidade, tamanho e tipo. Um IC pode ser um serviço ou pode consistir em hardware, software e documentação de um programa. Actividades São cinco as actividades que constituem o Processo de Gestão de Configurações, e que garantem a qualidade e coerência da informação armazenada durante o desenrolar do processo: 1. Planeamento Primeiro que tudo é necessário definir o âmbito, a finalidade, os objectivos, prioridades e procedimentos para o processo de GC. É nesta fase que os tipos e atributos dos itens de configuração são definidos. 2. Identificação Todos os activos (IC) da infra-estrutura, necessários para providenciar um serviço, devem ser identificados, etiquetados e inseridos num repositório de dados. Para cada tipo de recurso a profundidade da documentação exigida deve ser definida. Para cada atributo de um dado activo armazenado, uma razão válida tem que existir para legitimar o esforço de recolher e de manter a informaçã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ço necessário para manter o repositório de informação e não permitirá um fluxo de dados efectivo. Também, adicionar atributos em falta é moroso e produzirá custos elevados quando o sistema de GC estiver em produção. 3. Controlo Esta actividade é responsável por garantir que a inserção dos IC na base de dados é executada de forma controlada, isto é, que só IC autorizados e identificados podem ser inseridos.

36 2.2. ITIL 17 Faz parte desta actividade assegurar que nenhum IC é adicionado sem a existência de documentação apropriada, (por exemplo, um pedido de alteração aprovado) e que, após a inserção, exista documentação actualizada. 4. Status accounting As alterações aos componentes devem ser documentadas e deve ser possível visualizar e restaurar versões antigas de uma entrada e das suas relações com outras entradas. Juntamente com a alteração efectuada, a identificação da pessoa responsável pela sua implementação deve ser uma informação a manter. Devem existir relatórios onde consta o estado presente e passado de um IC. 5. Verificação e Auditoria Devem realizar-se verificações periódicas aos dados armazenados que assegurem a existência e exactidão da informação guardada. É necessário provar que os IC e todos os atributos existentes estão correctos, e que as alterações foram realizadas de acordo com procedimentos estabelecidos. O repositório de informação deve conter apenas registos de IC que realmente existem, sendo necessário avaliações regulares que removam informação desactualizada e/ou não necessária. Métricas Existem indicadores chave de desempenho (KPI - Key Performance Indicators) para medir cada uma das actividades do processo de GC, existindo também KPI para medir todo o processo de GC. Alguns dos KPI são: Número de pedidos de correcção da configuração. Número de pedidos de configuração. Percentagem de pedidos de correcção de configuração por número de pedidos de configuração. Percentagem de componentes de TI configurados via métodos automatizados versus componentes de TI configurados manualmente. Percentagem de componentes registados com informação de configuração errada durante um processo de auditoria. Devem ser produzidos relatórios e registos regularmente que suportem as medidas descritas anteriormente.

37 18 CAPÍTULO 2. TRABALHO RELACIONADO Gestão de Alterações As mudanças/alterações podem surgir como resultado da ocorrência de problemas, mas também advêm de uma procura constante em minimizar as interrupções no serviço e melhorar as operações diárias das organizações de TI. Para conseguir estes objectivos, é necessário que as organizações se assegurem que as mudanças se façam de forma controlada, ou seja, qualquer alteração a 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ário gerir as mudanças, a framework ITIL propõe que as organizações definam e implementem um processo denominado Processo de Gestão de Alterações. Objectivos A implementação e definição do processo de GA, deve ter em conta os seguintes objectivos: utilizar métodos e procedimentos padronizados registar as alterações na CMDB analisar riscos e avaliar o impacto das alterações: a framework ITIL enfatiza que o processo contemple a avaliação rigorosa dos riscos provenientes das alterações, e propõe que se responda a sete questões: 1. Raised - quem pediu a alteração? 2. Reason - qual a razão para a alteração? 3. Return - qual o retorno exigido da mudança? 4. Risk - quais os riscos envolvidos? 5. Resources - que recursos são necessários? 6. Responsible - quem é responsável por configurar, testar e implementar? 7. Relationship - que relações existem entre a alteração que se pretende e outras alterações? Não é contudo, do domínio do processo da GA, a identificação de componentes afectadas pela alteração, ou pela release de componentes que tenham sido alterados [11], estando estas tarefas sob o domínio de outros processos existentes, nomeadamente os processos de GC e Gestão da Release.

38 2.2. ITIL 19 O processo da GA é responsável por procedimentos que lidam com a gestão de pedidos de alteração aos itens de configuração (IC) presentes na CMDB. Esses procedimentos envolvem: Hardware Serviços Software Software de Sistema Aplicações de software em utilização Documentação e procedimentos associados à manutenção, suporte e execução dos 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ções. Por esta razão, muitas organizações optam por implementar os processos da GA e GC simultaneamente, para assim ganhar controle sobre a infra-estrutura. A CMDB interage com todos os processos, e possui os activos da organização, mas também detém as fontes de informação sobre os recursos utilizados por cada serviço e as suas dependências. Quando uma mudança precisa ser executada, a CMDB mostra que componentes estão ligados ao componente alterado ou serviço, sendo assim possível conhecer as consequências e os problemas associados à mudança [22]. A Figura 2.6 ilustra a interacção entre o processo da GA e outros processos da framework ITIL. Figura 2.6: Gestão das Alterações e Outros Processos ITIL [14]

39 20 CAPÍTULO 2. TRABALHO RELACIONADO Papéis no Processo de Gestão de Alterações O processo de GA dita a criação de um comité de pessoas, com diversas funções dentro da organização, responsáveis pela definição do processo e por aprovar, avaliar e priorizar as alterações, constituindo a autoridade de decisão, denominado Change Advisory Board - CAB. Na eventualidade de ocorrência de problemas, pode ser impossível reunir todas as pessoas que constituem o CAB, pelo que convém que as organizações identifiquem um conjunto mais pequeno de pessoas capazes de dar resposta a situações de emergência. Ou seja, deve existir também um emergency Committee - EC. A framework ITIL propõe ainda a criação de um outro papel: Change Manager - CM, cujas principais responsabilidades consistem na definição do 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ão efectuar-se planos que assegurem que um correcto interface existe entre estes dois processos. Actividades A Figura 2.7 ilustra um exemplo de actividades envolvidas no Processo de Gestão de Alterações: Figura 2.7: Processo da Gestão de Alterações A abordagem às actividades do processo da GA podem depender das necessidades da organização e da natureza do negócio. No entanto, a seguinte cadeia de acontecimentos é na

40 2.2. ITIL 21 generalidade seguida: 1. É efectuado um Pedido de Alteração (RfC - Request for Change). O pedido pode ser efectuado por qualquer pessoa pertencente à organização, e é enviado por qualquer canal de comunicação ao dispor ( , formulário web próprio na intranet, telefone, etc.). 2. O CM examina o pedido. 3. O CM avalia, classifica, e categoriza o RfC, baseando-se no impacto e urgência da alteração proposta. Se considerar que a alteração é necessária e exequível, efectua um planeamento inicial da implementação da alteração. 4. O RfC é rejeitado ou aprovado para implementação pelo CM ou pelo CAB. A necessidade de aprovação por parte do CAB depende da quantificação do impacto da alteração na instituição, da quantidade de recursos necessários para efectuar a implementação e do risco relacionado com a implementação da mudança. 5. O CM planeia a implementação, definindo as tarefas a executar, o esforço necessário, determinando os recursos, o orçamento disponível, e os critérios de aceitação. O técnico responsável por implementar a mudança define um plano de implementação do ponto de vista técnico definindo uma solução técnica que engloba testes e uma plano de retrocesso. 6. A alteração é efectuada de acordo com o plano de implementação estabelecido. 7. A alteração é testada verificando-se e avaliando-se o seu impacto. Posteriormente as alterações entram em produção. Este processo, Release to production, envolve uma avaliação final que consiste em ponderar se a mudança é realizada ou não, e se é necessário aplicar o plano de retrocesso. 8. O sucesso da implementação da alteração e o seu impacto é revisto em cooperação com o CM. O RfC e toda a informação relacionada é 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õe os estados ilustrados na Figura 2.8.

41 22 CAPÍTULO 2. TRABALHO RELACIONADO Figura 2.8: Estados de um RfC [15] Categorização das Alterações A avaliação de uma alteração passa também por integrar a alteração em categorias préestabelecidas e acordadas dentro do CAB. A framework ITIL propõe que sejam categorizadas da seguinte forma: Mudanças com grande impacto Mudanças com impacto Significante Mudanças com pouco impacto Métricas A framework ITIL refere que as mudanças devem ser avaliadas e que periodicamente devem ser facultados documentos, que circulem na organização, onde conste essa avaliação. Nesses relatórios, sugere-se que se inclua a seguinte informação: Número de mudanças implementadas num determinado período: no total, por IC, tipo de configuração, serviço, etc. Categorização/decomposição das razões da mudança (solicitada pelo utilizador, devida a melhorias, serviço para resolver problemas/incidentes, melhoria de procedimentos).

42 2.2. ITIL 23 Número de mudanças bem sucedidas. Número de mudanças que não se realizaram, juntamente com as razões. Número de incidentes atribuídos a alterações. Número de mudanças implementadas e que necessitaram de ser revistas. Elevadas incidências de RfC relacionadas com IC. Comparação com gráficos de períodos anteriores. Número de RfC rejeitados. Proporção de mudanças que não foram bem sucedidas (relativamente ao número total, e descriminadas por IC). Num caso de estudo no qual a framework ITIL foi implementada e bem sucedida [25], os resultados constantes na Tabela 2.1, mostram de forma exacta e mensurável melhorias na Organização. Anterior Posterior KPI à Implementação à Implementação ITIL ITIL % de mudanças realizadas de acordo com o planeado % de mudanças efectuadas, mas não aprovadas % de mudanças urgentes % de mudanças falhadas 18 6 % de software em utilização sem 22 8 autorização % de Releases falhadas % Releases urgentes Tabela 2.1: KPIs para os Processos da GA e Gestão da Release [25]. Um KPI é uma métrica que é usada para ajudar a gerir um Processo, um Serviço de TI ou uma Actividade. Muitas métricas podem ser utilizadas, mas só as mais importantes são definidas como KPIs e são usadas para, de uma forma activa, gerir e reportar um Processo, Serviço de TI ou Actividade. Os KPIs devem ser seleccionados de forma a garantir que a eficiência, eficácia, e rentabilidade são geridos. Observando os valores dos KPIs, presentes na Tabela 2.1, anteriores e posteriores à implementação do processo de GA, podemos constatar os ganhos obtidos pela organização: o número

43 24 CAPÍTULO 2. TRABALHO RELACIONADO de mudanças falhadas diminui, bem como a percentagem de mudanças urgentes. Também a percentagem de software em utilização sem autorização diminui. 2.3 Suporte à Gestão de Processos ITIL A framework ITIL foca a sua estratégia nos processos de gestão de 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ção de ferramentas, e aliás nem deve fazê-lo. A framework ITIL também não afirma que deva existir uma solução única que englobe todos os processos. A verdade é que existem soluções diferentes, de vendedores diferentes, open source e comerciais, que se focam e especializam em determinados processos. A seguinte avaliação, baseia-se na comparação de características de produtos que vão de encontro às actividades relevantes para os Processos de Suporte, nomeadamente a GC e GA, de acordo com o descrito na framework ITIL V2 (A framework ITIL V3 foi lançado em 2007, mas a framework ITIL V2 é extensamente usado e constitui um padrão para a maioria de organizações). Este estudo foi realizado pela Microsoft e consta no artigo referido em [26]. Os produtos comparados são a solução oferecida pela Microsoft e algumas soluções oferecidas pela comunidade open source. Como veremos, encontrar-se-ão semelhanças, mas também diferenças nas abordagens às questões que a framework ITIL levanta. Podemos, no geral, concluir que: Nenhuma solução única, de forma total, cobre todas as necessidades da framework ITIL. A solução da Microsoft é relativamente completa, mas demasiado centrada no Windows, e não contempla todas as actividades presentes na framework ITIL. A comunidade open source foca-se em actividades técnicas particulares da framework ITIL em detrimento de um serviço mais abrangente que englobe todo o processo ITIL Software para Gestão de Configurações Na presente Secção mostra-se e analisa-se algum software existente para concretizar o processo de GC. Vejamos como cada software, se aproxima ou afasta da framework ITIL, ou seja, em que medida, na sua implementação, as actividades da GC (ver Secção2.2.2) estão presentes. Um dos objectivos da GC é fornecer uma base de conhecimento da configuração do hardware e software usados por uma organização, logo o software deverá contemplar as seguintes funcionalidades:

44 2.3. SUPORTE À GESTÃO DE PROCESSOS ITIL 25 Descobrir dispositivos na rede. Determinar o host de um sistema operativo. Averiguar que aplicações se encontram em utilização no sistema. Detectar alterações na configuração. Todos os produtos listados na figura 2.9 implementam estas funcionalidades mas, no entanto, nenhum sozinho contempla todas as actividades da framework ITIL. Figura 2.9: Software para Gestão de Configurações [17]. A Figura 2.10 fornece uma revisão da capacidade de cada produto para endereçar as actividades da framework ITIL (ver Secção 2.2.2) para a GC. Figura 2.10: Avaliação do Software para Gestão de Configurações [17].

45 26 CAPÍTULO 2. TRABALHO RELACIONADO Podemos concluir o seguinte: a comunidade open source oferece uma vasta gama de soluções para a GC, da qual o Zenoss é um bom exemplo, para monitorização da infra-estrutura e gestão das aplicações, pois utiliza um CMDB para manter a informação dos componentes existentes na rede. Contudo, tem suporte limitado para aplicações empresariais tais como o SQL Server, o que limita a sua capacidade para actividades tais como a de Verificação e Auditoria. OneCMDB possui funcionalidades de modelação e descoberta, mas falta-lhe a capacidade automatizada de Auditoria. CMDBuild, é um um projecto italiano de código aberto interessante, mas falta-lhe documentação em língua inglesa, 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ção de configuração, tais como hardware, sistema operativo e versão e aplicações instaladas. Como é dedicado à plataforma Windows e às suas aplicações, pode executar uma análise muito detalhada que permite armazenar uma vasta variedade da informação dos sistemas geridos pela organização Software para Gestão de Alterações A menos que a mudança seja controlada dentro de uma organização, os serviços estarão à mercê de modificações ad hoc aos routers, aos utilizadores, e ao software. As mudanças ad hoc podem e custam o rendimento das organizações, e criam frustração desnecessária, como por exemplo, utilizadores terem que esperar a conclusão de um melhoramento não anunciado ou o rollback de um patch falhado. Os produtos utilizados para concretizar o processo da GA dividem-se em duas categorias: Software de Workflow ou Deployment. 1. Software de Workflow usado para definir e rever o processo aprovado. Quando um RfC é emitido, o software de workflow distribui o RfC para as partes envolvidas para revisão, teste e eventualmente instalação, permitindo monitorizar o processo de alteração. Um exemplo de software open source que suporta workflow é o Request Tracker, mas muitos produtos de Help Desk também possuem esta funcionalidade, possibilitando o seu uso para monitorizar o processo de mudança. 2. Software de Deployment, que diz respeito à automatização da implementação da alteração até esta ser atingida. Para ser possível atingir este objectivo, é necessário que o software possua as seguintes funcionalidades: Instale actualizações de software e mudanças na configuração. Detecte erros durante o processo de actualização. Registe e relate quem iniciou o conjunto de alterações.

46 2.3. SUPORTE À GESTÃO DE PROCESSOS ITIL 27 Figura 2.11: Avaliação do Software para Gestão de Alterações [17]. A Figura 2.11 fornece uma revisão da capacidade de cada produto para endereçar as actividades da framework ITIL para o processo da GA (ver Secção 2.2.3). Podemos concluir que algumas das ferramentas mais avançadas disponíveis são open source, tais como bcfg2, cfengine, radmind, e Webmin. Todas prevêem determinados graus de controlo sobre a instalação das mudanças, embora ferramentas como o Webmin, utilizem um ecrã de configuração manual, o que limita o seu uso em ambientes de grande dimensão. Ferramentas que se centram na automatização, tais como o bcfg2 e cfengine, fornecem meios que asseguram de que as configurações não são alteradas - toda a alteração não aprovada é revertida automaticamente de volta ao original por um agente local do software. Por exemplo, se um servidor que é definido como servidor web e não tem o software Apache instalado, os pacotes de gestão de alterações corrigem este desvio instalando e configurando o pacote Apache. Esta capacidade de definir regras de configuração e impor essas regras permite tanto ao bcfg2 como ao cfengine implementar um mecanismo potente para a actividade de GA. No entanto, as capacidades de produzir relatórios destes produtos é limitada. Apesar de fornecerem relatórios das mudanças ocorridas no sistema, não há uma forma óbvia de determinar que sistemas estão ou não sincronizados para além de permitir que eles voltem a ficar sincronizados. Isto limita a capacidade de auditoria de alterações não autorizadas aos sistemas (embora este aspecto seja mais importante para a GC). Por sua vez, a solução SMS da Microsoft, usada em ambientes windows tem as seguintes funcionalidades: Plano de Instalação: relatórios que fornecem a informação sobre hardware, software e versão. Instalação baseada em grupos: permite ao administrador de sistemas alocar software por diversos. grupos, onde um grupo pode ser definido usando propriedades como hardware, Active Directory(AD) e membros do grupo AD. Actualizações de patch: automatiza a instalação de patches para servidores e aplicações críticas.

47 28 CAPÍTULO 2. TRABALHO RELACIONADO Existem soluções viáveis para concretizar o processo da GA em ambos os ambientes open source e Microsoft. A comunidade open source tem providenciando soluções técnicas robustas (bcfg2 e cfengine), mas muitas vezes não implementa actividades essenciais, tais como planear alterações (por exemplo, o software não permite facilmente que um administrador estime o impacto de uma mudança). Por sua vez, o SMS da Microsoft oferece uma solução mais 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ão de alterações em paralelo.

48 Capítulo 3 Problema 3.1 Contextualização O Laboratório de Instrumentação e Física Experimental de Partículas (LIP), criado em 1986 quando Portugal aderiu ao CERN, é uma associação técnica e científica, que tem por objectivo a investigação no campo da Física Experimental de Altas Energias e da Instrumentação Associada. As actividades de pesquisa do LIP, desenvolvidas no âmbito de grandes colaborações internacionais (CERN, ESA, SNOLAB, NASA, AUGER), tem como principais domínios de investigação a Física Experimental de Altas Energias e Astropartículas, a Instrumentação de Detecção de Radiação, a Aquisição e Processamento de Dados, a Computação Avançada e as aplicações das radiações à medicina. Em Lisboa e Coimbra existem dois Centros de Cálculo albergando a infra-estrutura de TI da organização. Para além da gestão destes dois CC, a equipa de Computação Avançada do LIP é também responsável pela coordenação da operação da 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ção para a Computação Científica Nacional (FCCN). No presente capítulo apresenta-se a instituição (LIP), identificam-se as principais causas e problemas nos procedimentos efectuados nos CC da instituição e finaliza-se com a descrição dos requisitos que se pretendem implementar de modo a agilizar os processos realizados nos CC. Apontar um caminho para melhorar a gestão destes dois centros de calculo é o propósito deste trabalho. 29

49 30 CAPÍTULO 3. PROBLEMA 3.2 Causas e Problemas Principais nos Procedimentos do LIP O LIP encontra-se envolvido em projectos cujas experiências necessitam que se processem quantidades massivas de dados digitais, e nas quais existem milhares de utilizadores. Esta situação implica que o pessoal técnico e 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 área de actuação do pessoal técnico do CC do LIP, aumentando as funções que os mesmo número de técnicos têm que desempenhar. Até à data, o LIP tem conseguido manter o nível de serviço que satisfaz os utilizadores, mas o pessoal técnico encontra-se no limite do seu esforço. Através de um grande número de entrevistas aos funcionários do LIP, e da análise das operações diárias levadas a cabo por cada elemento, tentou-se identificar as responsabilidades individuais, as responsabilidades conjuntas e o modo como a informação flui no interior da instituição. Após a análise às respostas e procedimentos funcionais, chegou-se às seguintes conclusões: cada funcionário é responsável pela manutenção e operação de determinados serviços. Existem serviços que podem ser suportados por dois ou mais elementos, a documentação sobre a operação de cada serviço é mantida numa wiki geral. O problema é que essa wiki não é actualizada com a regularidade desejada, as entradas e saídas de componentes informáticas é realizada de acordo com uma base de dados que se tornou obsoleta uma vez que deixou de estar actualizada, os registos de intervenções sobre componentes é ainda mantido na forma de ficheiros de texto em áreas pessoais de alguns funcionários, o planeamento das intervenções é realizado de forma ad hoc, com uma avaliação do impacto precária, o Modus operandi da instituição, apesar de ainda conseguir satisfazer a qualidade de serviço pretendida, confronta-se com o obstáculo da não escalabilidade resultante da gestão de um parque informático cada vez maior, mais complexo e distribuído, estando os seus funcionários no limite do seu esforço. 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ção o CC de Lisboa.

50 3.3. COLECÇÃO E CARACTERIZAÇÃO DE REQUISITOS Colecção e Caracterização de Requisitos O objectivo deste trabalho é a implementação de um sistema que optimize procedimentos e minimize o esforço na operação/manutenção do equipamento. Atendendo ao diagnóstico elaborado, apresentado na Secção anterior, tendo em conta o contexto da instituição LIP, foi estabelecido um conjunto de requisitos funcionais, não funcionais e de negócio que devem ser implementados de forma a agilizar e automatizar os processos realizados pelo CC do LIP. Estes requisitos foram aprovados pelo LIP Requisitos de Negócio R01. O sistema deve ser desenvolvido utilizando ferramentas open source. R02. O sistema deve integrar, sempre que possível, tecnologia e software em produção no seio da instituição. R03. O fluxo de informação no desenrolar dos processos deve basear-se num sistema de notificações trocadas entre os vários intervenientes Requisitos Não Funcionais R04. A autenticação no sistema deve ser efectuada via login/password ou via certificado digital. R05. Os utilizadores só possuem permissões para enviar notificações. R06. O administrador do sistema possui permissões para criar, apagar e manipular informação em todos os módulos do sistema Requisitos Funcionais R07. Planeamento de intervenções sobre componentes informáticos (adição, substituição e remoção). R08. Registo de acções efectuadas sobre componentes informáticos incluindo intervenções de manutenção. R09. Registo de acções realizadas pelos utilizadores e pelo administrador do sistema. R10. Efectuar procuras sobre as acções efectuadas sobre determinado componente. R11. Elaborar relatórios e estatísticas que possibilitem obter métricas para os vários componentes informáticos da instituição.

51 32 CAPÍTULO 3. PROBLEMA R12. Detectar e notificar a presença de incoerência nos dados. R13. Existência de uma interface de acesso para todos os utilizadores. R14. Existência de uma interface que permita consultar os dados guardados. R15. Inventário actualizado do equipamento de hardware existente no CC do LIP.

52 Capítulo 4 Proposta Neste capítulo são apresentadas as propostas para os processos de GA e GC tendo em conta os requisitos estabelecidos no âmbito do LIP. 4.1 Sistema da Gestão de Alterações Para gerir as alterações foi necessário definir um processo de GA, que se ajuste aos requisitos da instituição e que formalize estados de mudança, nomeadamente de equipamentos e serviços. O processo fixado é baseado na framework ITIL. Neste sentido, foi necessário criar critérios ajustados à realidade da instituição para categorizar as alterações, decidir os seus estados, fixar métricas para avaliar as alterações e o seu impacto, e determinar as actividades relevantes no fluxo de execução do processo Modelo de Actividades A Figura 4.1 ilustra o processo proposto de GA, e que é composto pelas seguintes actividades: 1. Criar um RfC (Request for Change). 2. Avaliar/Classificar um RfC. 3. Autorizar RfC. 4. Concretizar. 5. Testar um RfC. 6. Aceitar/Rejeitar RfC. 33

53 34 CAPI TULO 4. PROPOSTA Figura 4.1: Processo de Gesta o de Alterac o es Adoptado. Este processo propo e a existe ncia de quatro pape is a desempenhar na instituic a o: Requestador (qualquer utilizador e funciona rio da instituic a o), Executante (os funciona rios que executam as tarefas te cnicas de implementac a o da alterac a o), Coordenador (o responsa vel pela avaliac a o da alterac a o e pela coordenac a o da implementac a o) e o Comite de Peritos (CPE que avalia e coordena alterac o es de grande impacto na instituic a o). O processo inicia-se com a criac a o de um novo RfC, e pode ser realizado por qualquer utilizador na organizac a o. A alterac a o e posteriormente catalogada pelo Coordenador: caso

54 4.1. SISTEMA DA GESTÃO DE ALTERAÇÕES 35 seja uma alteração confirmada como standard, é automaticamente aprovada/aceite e pode ser executada. É nesta altura, que também é definido o IC sobre o qual a alteração é pretendida e recolhida toda a informação relacionada, considerada útil para avaliação da alteração. Caso seja uma alteração considerada não standard, o RfC tem que ser avaliado e classificado de acordo com o modelo de classificação de alterações proposto (ver Secção 4.1.3). O Coordenador pode dar seguimento à alteração ou encaminhar o pedido para nova reavaliação pelo CPE. Se o RfC for rejeitado, o processo termina e o porquê da decisão de rejeição é guardado. Se o RfC é aceite, o(s) Executante(s), executam a alteração. O RfC entra então numa fase de testes, e caso seja considerado válido e não causar problemas inesperados, a alteração é finalmente aceite. Caso contrário a alteração é rejeitada Estados das Alterações No desenrolar das várias actividades, um RfC passa por vários estados que se encontram ilustrados na Figura 4.2. Figura 4.2: Diagrama de Estados de uma Alteração. New - Quando um RfC é criado, este é o seu estado. Open - O RfC foi aceite para implementação pelo Coordenador ou pelo CPE. Encontra-se em implementação pelo Executante. Testing - Depois de implementar a alteração, o RfC entra numa fase de testes. Nesta fase avalia-se se a alteração é ou não bem sucedida. Resolved - Este é um dos estados finais de um RfC. Significa que a alteração foi completada 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álido que esta acção seja registada no sistema.

55 36 CAPÍTULO 4. PROPOSTA Categorias de Alterações e Critérios de Avaliação Os objectivos da categorização das alterações é perceber qual o método de aprovar e autorizar o pedido de alteração (RfC) e ter um cálculo prévio do impacto da alteração na instituição. Nesse sentido, para categorizar as alterações foi decidido adoptar o modelo definido pela Pink Elephant, 1 sendo fixadas as seguintes categorias: 1. Principal - Mudanças que envolvem: elevado tempo de preparação/execução impacto difícil de avaliar métodos procedimentais não conhecidos requerem obrigatoriamente uma avaliação por parte do CPE avultados custos monetários 2. Significante - Mudanças que implicam um tempo de preparação e execução longo. Requerem avaliação por parte do CPE 3. Menor - Alterações que não requerem aprovação por parte do CPE e que requerem pouco tempo de preparação/execução. Para categorizar uma alteração o Coordenador deve avaliá-la de acordo com os critérios apresentados na Tabela 4.1, e ter em consideração o seguinte modelo de classificação: o valor mais elevado para todos os critérios estabelece a categoria da alteração. Por exemplo, cinco classificações C e um A significam automaticamente uma Alteração Principal. 1 Vários colaboradores da Pink Elephant são co-autores do livro ITIL - Service Support da editora Best practice nomeadamente Michiel Berkhout, Brian Jonhson, Marc Van Goethem, Guus Velter

56 4.1. SISTEMA DA GESTÃO DE ALTERAÇÕES 37 Número de utilizadores afectados Risco de não implementar a alteração Recursos necessários para preparar/implementar Esforço de Preparação Esforço de Implementação Possibilidade de retrocesso A. Todos os utilizadores B. Dois ou mais grupos C. Um grupo A. Elevado. Organização fica inoperacional B. Médio. Parte das funcionalidades não serão disponibilizadas C. Baixo. Sem implicações para a organização A. Todo o CC B. 3 técnicos C. 1-2 técnicos A. 2 dias ou mais B horas C. 8 horas A. > 24 horas B horas C. 1 hora A. Difícil B. Moderada (1-2 horas) C. Fácil Tabela 4.1: Critérios para Categorização de Alterações: A = Alteração Principal, B = Alteração Significante, C = Alteração Menor. Sabendo qual o tipo de categoria, estabeleceram-se os seguintes tempos de implementação: Categoria da Alteração Principal Significante Menor Prazo de Execução 30 dias úteis 14 dias úteis 0-3 dias úteis Tabela 4.2: Período de Execução para as Diferentes Categorias de Alterações Identificação de Funcionalidades O sistema de GA tem como objectivo principal gerir as alterações derivadas da Gestão do CC do LIP. Para realizar este objectivo é necessário que este sistema disponibilize as seguintes funcionalidades:

57 38 CAPÍTULO 4. PROPOSTA Criar novo pedido de alteração. (Create New RfC ) O pedido de alteração deve estar associado a: Item de Configuração (IC) Requestador Executante(s) Categoria Prioridade Definir diferentes perfis de utilizador com permissões e responsabilidades específicas, nomeadamente: Executante(s) - tem permissões de visualização e modificação parcelar de RfC relacionados com tarefas sob a sua dependência Coordenador - tem permissões de visualização/modificação de todos os RfC Requestador - pode unicamente visualizar o progresso (estado) do RfC que iniciou Permitir inserção de comentários num dado RfC, por parte dos intervenientes na alteração. Rejeitar, aceitar e testar um RfC. Definir período de execução de um RfC. Guardar um RfC. Consultar o registo histórico de acções efectuadas sobre um RfC. Definir o fluxo de informação entre os vários intervenientes na alteração. Visualizar métricas de desempenho utilizando um único dashboard. Criar relatórios que contenham informação sobre número de pedidos de alteração, número e percentagem de alterações, número de pedidos rejeitados, número de pedidos aprovados e frequência de mudança de um dado IC. Definir procedimentos de retrocesso, caso uma alteração cause problemas. Na Figura 4.3 apresentam-se os casos de uso do sistema de GA. A descrição detalhada de cada um dos casos de uso encontra-se no Apêndice B, apresentando-se para cada um, os cenários principais e alternativos.

58 4.2. SISTEMA DE GESTÃO DE CONFIGURAÇÕES 39 Figura 4.3: Casos de Uso do Sistema de Gestão de Alterações. 4.2 Sistema de Gestão de Configurações O estudo dos processos executados no interior do LIP mostrou que o fluxo de informação é realizado de forma inadequada, dada a quantidade de dados a manipular e os agentes envolvidos que necessitam de aceder a essa informação. Desta forma, mais do que um conjunto de tecnologias, é necessário colocar em prática um modelo comum de procedimentos e actividades que visem centralizar a informação, e agilizar a sua consulta ou alteração de forma controlada. O processo global de GC proposto para o LIP encontra-se representado na Figura 4.4, e é constituído pelas actividades de: Planeamento: definição do modelo de GC. Identificação: responsável por identificar a existência de novas ocorrências a introduzir/remover na CMDB. Especificação: constituída por actividades que respondem a pedidos de alteração estruturais da CMDB.

59 40 CAPÍTULO 4. PROPOSTA Controlo: constituída por actividades que respondem a pedidos para alterar conteúdos da CMDB, não envolvendo alterações estruturais na CMDB. Auditoria e Verificação: constituída por actividades que asseguram que os activos na CMDB são efectivamente os activos da instituição. As acções constituintes da actividade de Planeamento são mais orientadas ao início do processo, em que é necessário validar o próprio modelo adaptado para a CMDB e modificá-lo se necessário for. As actividades de Identificação, Especificação, Controlo, Auditoria e Verificação são constituídas por acções orientadas para a operação diária da infra-estrutura de computação do LIP, e em que o planeamento do modelo é posto à prova. Cada uma destas actividades encontrase descrita em detalhe na presente Secção, e pressupõe a existência de 2 papéis a desempenhar na instituição: Gestor da Configuração, responsável pela execução das actividades de todas as fases do sistema de GC, à excepção das actividades da fase de Auditoria e Verificação que serão executadas pelo Auditor. Figura 4.4: Fases do Processo de GC, Proposto para o LIP.

60 4.2. SISTEMA DE GESTÃO DE CONFIGURAÇÕES Modelo de Actividades - Planeamento A actividade de Planeamento ilustrada na Figura 4.5 é constituída pela definição dos IC, do modelo para a CMDB e pelo fluxo operacional de implementação da CMDB. Estes três aspectos são endereçados por Baron et al. [28] Figura 4.5: Fase de Planeamento da Configuração Proposta para o LIP Definição dos Itens de Configuração Os IC podem ser qualquer item que a organização queira gerir/controlar, incluindo itens intangíveis tais como licenças, patentes, e itens de software e hardware. No caso específico do LIP, o processo de GC pretende ser orientado a hardware com a agregação da informação sobre os servidores de cálculo, servidores de armazenamento e respectivas componentes, e dispositivos de rede. A Tabela 4.3, esquematiza os vários tipos de IC (e seus atributos) identificados Modelo da CMDB e Fluxo Operacional de Implementação 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ção armazenados. Pretende-se que os dados da GC estejam organizados segundo um esquema (ver Figura 4.6) que deve ter em conta os seguintes aspectos:

61 42 CAPÍTULO 4. PROPOSTA Gerais Data de Entrada Nome Data Garantia Modelo Marca Grupo Localização Número de Série Part Number Atributos Particulares MacAddress/Interfaces Rede IPs Localização (Rack) Capacidade de Memória Tipo(Armazenamento ou Computação) MacAddress/Interfaces Rede IP Capacidade Capacidade Localização (Servidor/ Caixa de Expansão) MacAddress/Interfaces Rede IP Localização (rack) Itens de Configuração Servidor Controlador de Armazenamento Caixas de Expansão Discos Router/Switcher Tabela 4.3: Tipos de ICs definidos para o LIP e seus atributos. 1. incluir uma entidade para registar os atributos dos IC (CI Attribute). Como esta entidade está separada das restantes entidades permite suportar qualquer tipo arbitrário de atributo para um dado IC. 2. incluir uma entidade para rastrear relações entre IC (CI Relationship), o que possibilita o suporte de complexas relações entre IC. 3. se possível, incluir entidades que agreguem informação sobre procedimentos referentes ao processo de GA e que levem à mudança de atributos de IC. Convém referir que, dada a complexidade inerente aos processos de GA e GC, ambos são normalmente implementados de forma independente nas instituições, e integrados à posteriori na CMDB através de entidades específicas que permitem relacionar um dado pedido de alteração com dado IC. O fluxo operacional na implementação da CMDB implica: 1. Definir IC, tendo cada um ou mais atributos. 2. Guardar os atributos numa estrutura de dados (separada). 3. Identificar relações entre IC. 4. Guardar as relações identificadas numa estrutura de dados separada Modelo de Actividades - Identificação Após o Planeamento, e segundo o modelo adoptado, segue-se a actividade de Identificação, que é responsável por identificar a existência de novas ocorrências a introduzir na CMDB.

62 4.2. SISTEMA DE GESTÃO DE CONFIGURAÇÕES 43 Figura 4.6: Diagrama Entidade-Relação (ER) Ilustrando um Esquema de Definição dos IC na CMDB Proposto por Baron et al.[28] O modelo pressupõe a possibilidade da informação poder ser obtida/agregada através de ferramentas (Discovery tools) que permitem obter de forma automática informação sobre novos IC. No entanto, durante a operação diária da infra-estrutura, a inserção de um novo registo na CMDB deve ter sempre origem a partir do sistema de GA. A Figura 4.7 apresentas as diversas acções envolvidas na fase de identificação: 2.1) O Gestor da Configuração identifica a existência de novas ocorrências a inserir/remover da CMDB, como resultado das actividades de GA. Entre as ocorrências possíveis temos: 1. Criar ou remover IC. 2. Criar ou remover atributos para um IC existente. 3. Criar ou remover instâncias de IC existentes. 4. Modificar valores dos atributos de instâncias dos IC.

63 44 CAPÍTULO 4. PROPOSTA Figura 4.7: Fase de Identificação da Configuração Proposta para o LIP. 2.2) À 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ção deve avaliar o respectivo impacto na CMDB. Ocorrências do tipo 3 e 4 não têm impacto 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ções estruturais da CMDB, que uma vez identificadas, levam à emissão de um RfC, e caso este seja aprovado, à actividade de especificação no processo de GC Modelo de Actividades - Especificação A actividade de Especificação, ilustrada na Figura 4.8 é constituída por acções que respondem a pedidos de alteração estruturais da CMDB, permitindo que a mesma se adeqúe a um ambiente em permanente mudança, sendo o tipo de pedidos contemplados nesta fase os pedidos do tipo 1 e 2 da fase de Identificação. Nesta fase pressupõe-se que a validação do conteúdo do pedido já foi executada durante o processo de GA pelo que a remoção de um IC inexistente, ou de um atributo inexistente são acções que não têm lugar durante esta actividade.

64 4.2. SISTEMA DE GESTÃO DE CONFIGURAÇÕES 45 Figura 4.8: Fase de Especificação da Configuração. O processo de alterar o esquema da CMDB consiste nos seguintes passos: 3.1) O Gestor da Configuração relaciona o IC com a baseline de configuração. 3.2) O Gestor da Configuração averigua se o IC existe na CMDB. 3.3) Caso não exista, tem que alterar o esquema da CMDB de modo a suportar o novo IC e os seus atributos e relações. 3.4) Caso o IC exista na CMDB, o Gestor da Configuração avalia se se trata de um pedido de remoção de um IC. 3.5) Se for um pedido de remoção, então o Gestor da Configuração remove o IC. 3.6) Se o IC existe e não se trata de um pedido de remoção, o Gestor da Configuração averigua se é para remover ou criar atributos para esse IC.

65 46 CAPÍTULO 4. PROPOSTA 3.7) O Gestor da Configuração cria os atributos do IC. 3.8) O Gestor da Configuração remove atributos do IC Modelo de Actividades - Controlo da Configuração Na fase de Controlo da Configuração (Figura 4.9), o Gestor da Configuração responde a pedidos para alterar conteúdos da CMDB. O tipo de pedidos envolvidos nesta fase são pedidos do tipo 3 e 4 descritos na fase de Identificação. Figura 4.9: Fase de Controlo da Configuração Proposta para o LIP. 4.1) O Gestor da Configuração recebe um pedido para alterar conteúdos na CMDB. 4.2) O Gestor da Configuração avalia se o pedido é a criação de uma nova instância de um IC. 4.3) Caso o pedido recebido não seja para criar um instância, o Gestor da Configuração avalia se se trata de um pedido para remover uma instância. 4.4) O Gestor da Configuração averigua se o pedido consiste na modificação dos valores dos atributos. 4.5) O Gestor da Configuração cria uma nova instância de um activo. 4.6) O Gestor da Configuração remove a instância. 4.7) O Gestor da Configuração modifica o valor dos atributos do activo na CMDB.

66 4.2. SISTEMA DE GESTÃO DE CONFIGURAÇÕES Modelo de Actividades - Auditoria e Verificação Na fase de Auditoria e Verificação (Figura 4.10), realizada pelo Auditor realiza-se uma comparação entre os registos dos IC presentes na CMDB e os itens físicos existentes. Figura 4.10: Fase de Auditoria da Configuração Proposta para o LIP. Este sub-processo é constituído pelas seguintes acções (figura 4.10): 5.1 O Gestor da Configuração determina o âmbito da auditoria. 5.2 O Gestor da Configuração executa a auditoria (fazendo um rastreio do produto, usando uma discovery tool, manualmente). 5.3 O Auditor avalia se existem diferenças entre os activos registados na CMDB e os activos da instituição. 5.4 Caso não existam diferenças a auditoria termina. 5.5 Caso existam diferenças são determinadas excepções e prioridades. 5.6 As diferenças dão origem à emissão de um novo RfC Identificação de Funcionalidades O sistema de GC tem como objectivo principal gerir da Gestão do CC do LIP. Para realizar este objectivo é necessário que este sistema disponibilize as seguintes funcionalidades: introduzir/remover dispositivos de hardware de forma automática e de forma manual. visualizar rede de dispositivos, suas relações e dependências existentes.

67 48 CAPÍTULO 4. PROPOSTA visualizar eventos. criar relatórios que contenham informação sobre desempenho e disponibilidade dos componentes informáticos. consultar o registo histórico de acções efectuadas sobre os dispositivos de hardware. A Figura 4.11 apresenta os casos de uso do sistema de GC. A descrição de cada um dos casos de uso, dos cenários principais e alternativos encontra-se no Apêndice C. Figura 4.11: Casos de Uso do Sistema de Gestão de Configurações

68 Capítulo 5 Concretização da Solução Para concretizar o sistema de GA e o sistema de GC no LIP, optou-se pela utilização de 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ção de tarefas, e o Zenoss é utilizado para concretizar o processo de GC. Na presente secção explica-se a escolha destas ferramentas e o modo como se adequam aos modelos de GA e GC descritos nas Secções 4.1 e Request Tracker O Request Tracker(RT), [29] é um sistema utilizado para coordenar tarefas e gerir solicitações (pedidos) entre vários utilizadores. 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ão 4.0 e é distribuído sob a licença GNU GPL [35]. O RT pode ser instalado sob as plataformas Unix, Linux, Windows e Mac OS e pode interoperar com várias bases de dados: MySQL, POstgreSQL, ORACLE e SQLite. O RT foi desenvolvido em Perl e pode utilizar os servidores Apache e web lighttpd [36] associado ao módulo mod perl [37] e ao protocolo FastCGI [38] respectivamente. No RT convencionou-se que cada pedido ou tarefa a executar é gerida através de um ou mais tickets. A criação e actualização de tickets pode ser levada a cabo através das várias interfaces: 1. uma plataforma web, disponível tanto para utilizadores registados como para utilizadores convidados, facilmente configurável que permite a adição de campos personalizados. Possibilita a modificação da interface web sem a necessidade de muito esforço e conhecimento, utilizando o mecanismo de Callbacks. [39] 49

69 50 CAPÍTULO 5. CONCRETIZAÇÃO DA SOLUÇÃO 2. uma interface de , muitas vezes a única interface que alguns utilizadores convidados têm permissões para visualizar. 3. interface REST que permite o acesso à base de dados do RT a partir do exterior e cuja comunicação entre o cliente e a base de dados do RT se encontra encapsulada no protocolo HTTP. O endereço URL base para todos os pedidos é: 4. uma CLI - Command Line Interface que permite manipular tickets e utilizadores numa linha de comandos UNIX e melhor adaptada para tarefas de automatização e integração com outras ferramentas. Esta interface interage com o servidor do RT usando o protocolo HTTP. [29] Através de cada uma da interfaces anteriores, os utilizadores e administradores podem (de acordo com as suas permissões): Abrir um ticket. Atribuir tickets a pessoas (pessoas responsáveis pelos tickets). Rastrear alterações efectuadas a um ticket. Informar as partes interessadas sobre as alterações efectuadas ou sobre o estado de um ou mais tickets. Accionar actividades baseadas na prioridade e/ou estado de um ticket. Encerrar ou fechar um ticket Arquitectura A Figura 5.1 ilustra a arquitectura em camadas do RT, [29] que de forma sucinta consiste na implementação das seguintes camadas: Database: esta camada representa a capacidade que o RT possui de inter-operar com várias bases de dados nomeadamente MySQL, POstgreSQL, ORACLE e SQLite. DBIx:Searchbuilder é a camada responsável por estabelecer a ligação entre uma aplicação orientada a objectos que é o caso do RT e a base de dados relacional adoptada.

70 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ções e infra-estrutura de registos. RT ticketing system libraries - livrarias que providenciam funcionalidades próprias de um sistema de ticketing. Mason handler é um wrapper para o sistema Mason [42], uma framework para a construção de aplicações web escrita em Perl. O Mason pode ser usado com o servidor Apache HTTP via mod perl (para o qual o Mason providencia o seu próprio handler: HTML::Mason::ApacheHandler) ou ainda ser usado no servidor lighttpd. HTTP Clients. O RT tem três clientes HTTP que são o Web Browser, gateway e a CLI (Command-Line Interface) Modelo Lógico O Modelo Lógico do RT apresentado na Figura 5.2 é constituído por 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óprias de um sistema de Ticketing. A unidade básica administrativa existente é a Fila (Queue), cuja estrutura permitir implementar um fluxo de trabalho a ser realizado por vários intervenientes: as Filas são contentores nos quais se agrupam os tickets, se podem definir grupos de trabalho e definir condições e acções a realizar por diferentes intervenientes.

71 52 CAPÍTULO 5. CONCRETIZAÇÃO DA SOLUÇÃO Figura 5.2: Modelo Lógico do RT. O Modelo e a sua descrição podem ser consultados no Apêndice D Razões da Adopção do 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ção, devido à vasta documentação existente e ampla comunidade de utilizadores. A sua estrutura bastante genérica permite que o RT seja configurado de acordo com os workflows e casos de uso necessários para uma dada organização. Para além das 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ções e que permite informar todas as partes envolvidas sobre o estado de uma tarefa. É possível notificar através de e sms, os vários intervenientes no desenrolar de actividades decorrentes da execução de tarefas. Ou seja, cumpre os requisitos de negócio R01 e R03 definidos. 2. Cumpre requisitos não funcionais: o RT possui como característica um mecanismo de

72 5.1. REQUEST TRACKER 53 ACL (Access Control Lists) implementando diferentes permissões para diferentes tipos de utilizadores, isto é, utilizadores diferentes terão diferentes direitos de actuação no sistema. Este mecanismo permite satisfazer os requisitos não funcionais R05 e R06 definidos. No RT, a autenticação no sistema é efectuada via login/password, permitindo satisfazer o requisito R Cumpre requisitos funcionais: o RT permite definir fluxos de trabalho entre vários intervenientes, e registar essa informação na sua base de dados, permitindo satisfazer os requisitos R07 e R08. É uma ferramenta extremamente adaptável às preferências de uma organização: o seu modelo de dados genérico permite uma categorização segundo a utilização que uma organização pretenda. O workflow e a lógica de negócio que uma organização precisa, 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ção da sua pesquisa, sendo assim cumprido o requisito R10. A partir desta funcionalidade simples, o RT permite a definição de Dashboards, ou seja, uma colecção de informação obtida através de pesquisas pré-definidas. Desta forma, os administradores e utilizadores podem ser notificados periodicamente (diariamente, mensalmente) sobre o estado e o número de tickets numa determinada queue. O RT permite ainda a geração on demand de gráficos (ver Figura 5.3), demonstrativos da evolução das diversas tarefas ao longo do tempo e do esforço comprometido na sua resolução. Todas estas funcionalidades permitem concretizar o requisito R11. Figura 5.3: Número e Estado de Tickets Existentes na Fila Hardware Change Request Criados a Partir de 13 Janeiro de 2011.

73 54 CAPÍTULO 5. CONCRETIZAÇÃO DA SOLUÇÃO Configuração do Request Tracker Nesta Secção apresenta-se como o processo de GA definido na Secção 4.1 foi concretizado usando o RT Ticket Actuando como RfC Para a concretização do sistema de GA foi necessário ajustar funcionalidades do RT, e estabelecer convenções que se adaptem ao formalismo de um pedido de alteração, e às actividades do processo. Uma das principais convenções baseia-se na correspondência entre um pedido de alteração e um ticket RT numa fila que visa alterações na infra-estrutura de hardware, sendo por isso imediato que todas as alterações serão actividades sobre atributos de vários dispositivos de hardware. O formulário de 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ção. Adicionalmente é possível explicitar sobre que item de configuração e sobre que atributo do item de configuração vai ser executada a alteração. Entre os principais atributos a preencher temos informação específica dos dispositivos tais como a sua identificação, localização, fabricante e tipo de produto, proprietário, entre outros. A Tabela 5.1 sumariza os campos que constam no formulário de um ticket RT: Formalismo RfC Ticket RT Preenchimento Número do RfC Ticket Id Automático Data de Criação Created Automático Data Prevista Início Starts Automático Data Início Started Automático Data Prevista Fim Due Automático Descriçã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çã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ção entre Pedido de Alteração e Ticket.

74 5.1. REQUEST TRACKER 55 Observações importantes relativamente aos campos existentes no ticket RT: Category level1 Indica se a categoria da alteração é Standard ou Non standard. Category level2 Se a categoria da alteração escolhida for do tipo Non Standard, então este campo permite indicar se a alteração é Principal, Significante ou Menor. Se a categoria for Standard este campo não é aplicável. A categorização da alteração impõe uma data prevista para o fim (Due) da tarefa. Urgency A urgência de uma alteração pode ser classificada em: Not Urgent, Less Urgent, Urgent, Very Urgent e Top Priority. Priority A prioridade de uma alteração depende da urgência: caso uma alteração seja classificada como Not Urgent a prioridade estabelecida é de 10/100. caso uma alteração seja classificada como Less Urgent a prioridade estabelecida é de 30/100. caso uma alteração seja classificada como Urgent a prioridade estabelecida é de 50/100. caso uma alteração seja classificada como Very Urgent a prioridade estabelecida é de 70/100. caso uma alteração seja classificada como Not Urgent a prioridade estabelecida é de 90/100. Due Na Secção foram estabelecidos tempos de implementação de tarefas de acordo com a categoria de uma alteração. Tal é concretizado no RT, no campo Due (Data Prevista do Fim), que de acordo com a categoria da alteração (Change Category (level 2) - Principal, Significante, Menor) estabelece que a data prevista para o fim da tarefa será 30, 14 e 3 dias úteis respectivamente. Change Type No RT, foram configurados três Tipos de Alteração: 1. Add Hardware - alteração que visa a introdução de um novo dispositivo de hardware (nova instância). 2. Change Hardware - alteração que visa a modificação de valores dos atributos de um dispositivo de hardware existente.

75 56 CAPÍTULO 5. CONCRETIZAÇÃO DA SOLUÇÃO 3. Maintain Hardware - alteração que visa operações de manutenção de hardware já existente Device Name - Nome do dispositivo de hardware sobre o qual incide a alteração 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, Secção Fluxo de Tarefas (Workflows) Uma alteração é constituída por um conjunto de tarefas, independentes ou dependentes entre si, realizadas por um ou mais intervenientes e que passa por vários estados, desde a sua criação até à sua resolução. Um conceito importante no RT, é a definição de transacção, que representa um conjunto de alterações efectuadas sobre um ticket. No contexto de uma transacção, (ou seja, quando um dado campo de um ticket é alterado), é possível definir acções executadas em resposta a dadas condições (Scrips). No modelo adoptado, tira-se partido desta funcionalidade do RT para definir uma hierarquia de trabalho, e dependência entre tarefas. Desta forma, nos tickets na fila para gestão de alterações existem campos que dizem respeito a um conjunto de actividades paralelas que necessitam de ser executadas visando o objectivo final. 1. A execução destas tarefas é desencadeada através de campos específicos do ticket, que quando accionados geram tickets filhos, criando uma dependência para com o ticket original: o ticket pai não pode ser resolvido sem que os tickets filhos sejam solucionados. Na Figura 5.4 apresenta-se o template de um ticket no RT, onde constam campos referentes ao pedido de alteração, campos que descrevem o item de configuração e campos específicos que quando accionados levam à execução de um fluxo de trabalho previamente configurado. O template deste ticket, é ainda apresentado no Apêndice E. 1 Na 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

76 5.1. REQUEST TRACKER 57 Figura 5.4: Template de um Ticket no RT Configurado para Efectuar uma Alteração Ciclo de Vida de um Ticket De seguida enumeram-se os pontos chave, do ciclo de vida de um ticket:

77 58 CAPÍTULO 5. CONCRETIZAÇÃO DA SOLUÇÃO 1. um pedido de alteração é um ticket. O formulário inerente a um pedido de alteração é implementado através do preenchimento de um formulário web, com campos obrigatórios ou automáticos de acordo com as escolhas do utilizador. Entre as mais importantes temos: a categoria de uma alteração é obtida através da criação de dois campos denominados Change Category 1 e Change Category 2. a caracterização de um IC (e dos seus atributos) é realizada através da inserção de campos em tickets agrupados numa fila. a urgência e a prioridade 2. relações ente tickets permitem definir hierarquia e dependência de tarefas para realizar uma alteração. 3. o preenchimento de certos campos de um ticket despoletam acções (Scrips) que podem ser a criação de tickets filhos e notificações de utilizadores para a realização de sub-tarefas. As Figuras , e explicam como um ticket é gerido durante o seu ciclo de vida quando na instituição se pretende efectuar uma alteração que visa a instalação de novo Hardware, ou seja, uma alteração cuja categoria é do tipo AddHardware.

78 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 A SER PREENCHIDA E VALIDADA* (De acordo com o processo proposto para o LIP) Urgency Starts (Automática) Priority (Automática) Subject Change Category Level 1 Change Category Level 2 Change Type = Add Hardware Device Name STATUS New New WORKFLOW 1 CONDIÇES, ACÇÕES (Scrips) Scrip33: Change Priority according to Urgency Quando o Owner do Ticket preenche o campo Urgency, é estabelecido a prioridade da Alteração (Priority) Scrip34: Change Due Data according to Change Category Quando o Owner do Ticket preenche o campo Urgency, é estabelecido a data de início prevista para a alteração (Starts) Figura 5.5: Ciclo de Vida um Ticket no RT - Parte 1

79 60 CAPÍTULO 5. CONCRETIZAÇÃO DA SOLUÇÃO 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 PREENCHIDA E VALIDADA (De acordo com o processo proposto para o LIP) Device Type HWManufacturer HWProduct Part Number Serial Number Purchase Date (Warranty) Entry Date Ownership Location Require Services: (DNS, OS, Nagios, Amanda, Syslog, UPS Configuration) STATUS open open WORKFLOW (cont.) Completed Configure DNS Completed Configure OS Completed Configure Nagios Completed Configure Amanda Completed Configure Syslog Completed Configure UPS (Após conclusão da tarefa) Figura 5.6: Ciclo de Vida um Ticket no RT - Parte 2

80 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 A SER PREENCHIDA E VALIDADA (De acordo com o processo proposto para o LIP) Nada a registar Se alteração aceite, nada a registar Comments (Se alteração não aceite, registar a razão) STATUS testing resolved, rejected WORKFLOW (cont.) CONDIÇES E ACÇÕES Scrip 29: Write XML template Quando o owner, aceita a alteração, o estado do ticket é alterado para resolved. Nesta altura é efectuada uma acção que cria um ficheiro XML com a descrição do novo dispositivo de Hardware. Figura 5.7: Ciclo de Vida um Ticket no RT - Parte 3

81 62 CAPÍTULO 5. CONCRETIZAÇÃO DA SOLUÇÃO Inserção das Alterações na Gestão de Configurações Um dos maiores desafios consistiu na definição de uma estratégia que possibilite a interoperabilidade entre o processo de GA e GC. As alterações sobre determinado IC são disponibilizadas segundo um formato XML, gerado após a resolução do pedido de alteração. Com o fecho de um ticket, é despoletada uma acção que visa disponibilizar o registo da alteração num servidor web à ferramenta de GC num formato bem determinado. No Apêndice B, apresenta-se a título de exemplo a estrutura do ficheiro XML, que é gerado e onde consta a descrição do 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á-los e de forma automática registar essa informação relevante. 5.2 Zenoss O Zenoss (Zenoss Core) [34] é um sistema para gestão de servidores e redes open source, baseado no servidor de aplicações Zope (Zope [43] é um servidor, open source lançado em 1998, de aplicações web orientado a objectos e escrito em Python). Como ilustrado na Figura 5.8, através de um interface web, o Zenoss permite a gestão e configuração do inventário (o Zenoss monitoriza toda a infra-estrutura de TI, incluindo a rede, os servidores, os sistemas de aquecimento, ventilação, ar condicionado e até mesmo aplicações de software), a monitorização do desempenho e da disponibilidade, e a gestão de eventos. O desenvolvimento do Zenoss começou em 2002 e em Agosto de 2005 a empresa Zenoss, Inc foi fundada. Além da versão Zenoss Core que é gratuita, a empresa vende a versão Zenoss Enterprise baseada na versão Core. O Zenoss possibilita um inventário actualizado dos equipamentos, e simultaneamente deduzir o seu estado através da monitorização do seu desempenho e da sua disponibilidade. É portanto uma ferramenta adequada para a gestão de um CC complexo e em constante mudança Monitorização Orientada ao Modelo de Configuração Como ilustrado na Figura 5.9, a monitorização orientada ao modelo, efectuado pelo Zenoss, inicia-se com a descoberta dos recursos existentes na infra-estrutura de TI (discover) [30], que preenche o modelo da Base de Dados (IT Configuration Database) 2 (model). A este modelo construído é aplicado uma configuração pré-definida (config) e a monitorização começa (monitor). Esta configuração inicial pode contudo ser posteriormente afinada (tune). 2 No modelo da base de dados constam os recursos descobertos, constituídos por um inventário completo dos servidores, redes e aplicações de software existentes, até ao nível de detalhe dos interfaces, serviços, processos, e software instalado existente.

82 5.2. ZENOSS 63 Figura 5.8: Vista de Alto Nível do Zenoss [34]. Figura 5.9: Workflow: Monitorização Orientada ao Modelo de Configuração [34] Principais Funcionalidades As funcionalidades principais fornecidas pelo Zenoss (Core) são: Visão exacta e em tempo real dos dispositivos, das redes e das dependências e relaçõ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ói um mapa da rede (ver Figura 5.10). 2. possibilita estabelecer relações entre dispositivos e estabelecer ligações entre eles. Medir a disponibilidade de dispositivos de hardware (servidores, routers, etc.), e dos serviços por eles providenciados (serviços de mail, web, transferência de arquivos). Possibilidade de medir o desempenho usando métodos como o SNMP, WMI, comandos de shell, e API. Após efectuar a recolha dos dados, analisa-os de acordo com limites definidos pelo utilizador, e disponibiliza-os através de gráficos e relatórios.

83 64 CAPÍTULO 5. CONCRETIZAÇÃO DA SOLUÇÃO Monitorização da gestão de eventos resultantes da ocorrência de problemas provenientes dos dispositivos. Através de um mecanismo de notificações e escalonamento, as pessoas responsáveis pela sua resolução apercebem-se do estado desses mesmos problemas. Fornece relatórios resultantes do cruzamento de informação entre objectos e com vários formatos e conteúdos. Figura 5.10: Mapa de Rede.

84 5.2. ZENOSS 65 Figura 5.11: Arquitectura em Camadas do Zenoss Arquitectura A Figura 5.11 ilustra a arquitectura do Zenoss [32], constituída por quatro camadas: 1. Colecção - Collection Layer: compreende os serviços que coleccionam os dados para a camada de dados. Estes serviços são prestados por daemons que executam funções de gestão de modelação, monitorização e eventos. 2. Processamento - Processing Layer: camada responsável pela gestão das comunicações entre a camada dos dados e a camada responsável por coleccionar os dados (Collection Layer). 3. Dados - Data Layer: A informação relacionada com a configuração e colecçã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ça GNU GPL. Foi desenvolvido para armazenar séries de dados numéricos sobre o estado de redes de computadores, porém pode ser utilizado no armazenamento de qualquer outra série de 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ém pode produzir gráficos que 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ém do Zenoss. (b) ZenModel - Constitui o modelo nuclear da configuração, constituída por dispositivos e pelas suas componentes, grupos e localizações. Este modelo será explicado em detalhe na Secção (c) ZenEvents - Base de dados MySQL com os eventos gerados.

85 66 CAPÍTULO 5. CONCRETIZAÇÃO DA SOLUÇÃO 4. Utilizadores -User Layer: Esta camada é um portal web no qual o utilizador pode realizar as funções descritas na Secção Funcionalidades Modelo De seguida descreve-se o Modelo de Domínio do Zenoss (ver Figura 5.12), o qual permite caracterizar o equipamento de hardware e também o software existente numa instituição/empresa. Figura 5.12: Modelo de Domínio do Zenoss.

86 5.2. ZENOSS Um dispositivo (device) é o objecto principal de monitorização no sistema. É definido como uma combinação de elementos de várias classes, entre as quais as de hardware e software. Exemplos de dispositivos são: servidores, routers, switchers. Todos os dispositivos têm atributos próprios que os caracterizam: Device Name, Serial Number, IP Address, Rack slot, Tag, Production State, Priority, Collector, Uptime, First Seen, Last Change, Model Time, Locking, Memory Swap, Comments 2. Tanto os elementos de hardware como de software são também eles 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ção sobre o estado dos dispositivos. Esta informação é posteriormente guardada na base de dados ZenEvents. 6. Process Class [31] permite a definição dos processos a monitorizar no sistema e a recolha da informação do desempenho e disponibilidade dos processos monitorizados na base de dados ZenRRD 7. O Zenoss disponibiliza duas classes que permitem organizar os dispositivos da forma como o utilizador ache adequada à sua funcionalidade. Essas duas classes são a dos Grupos (Groups) e Sistemas (Systems) 8. Location class permitem indicar o local do dispositivo. Efectuando um paralelismo entre o diagrama entidade relação que ilustra um esquema de definição de IC na CMDB proposto por baron et al. [28], Secção e o modelo de domínio da CMDB do Zenoss podemos constatar que: um Configuration Item é um Device os atributos dos itens de configuração (CI Attribute, Attribute, Attribute Type) correspondem no Zenoss às seguintes classes: Location, System, Group, hardware, OperatingSystem. As relações entre IC (CI relationship) também existem no Zenoss, pois é possível estabelecer relações entre devices. Como se pode observar, o modelo oferecido pelo Zenoss permite ser adoptado para caracterizar um activo com os atributos previamente identificados e constantes definidos aquando da fase de Planeamento Secção

87 68 CAPÍTULO 5. CONCRETIZAÇÃO DA SOLUÇÃO Razões da Adopção do Zenoss O Zenoss possibilita satisfazer os requisitos definidos pelo LIP, e constantes na Secção 3.3 e permite ser utilizado para manter os activos da instituição e ser integrado com o sistema da Gestão de Alterações. A parte relativa à integração encontra-se descrita na Secção abaixo. (Ver também Secção ) O Zenoss como Gestor de Configurações no 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áximo de 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ão desta tarefa demorada. A segunda abordagem (trickle) consiste em criar pontos de integração em cada uma das áreas-chave de processos operacionais que possam lidar com os dados de configuração. Executando operações normais com estes pontos de integração, os dados dos itens de configuração (IC) são introduzidos na CMDB na medida em que vão sendo alterados ou à medida que vão causando incidentes. Esta é uma abordagem muito menos arriscado, mas que atrasa os benefícios de ter uma imagem completa de gestão de configuração. De acordo com o modelo proposto para o processo de GC, a segunda abordagem de Larry Klosteboer foi adoptada: uma modificação de um dado IC ao abrigo do processo de GC surge sempre em resultado de um pedido de alteração certificado e aprovado, sendo posteriormente essa informação (dados dos itens de configuração, IC e atributos) introduzida na base de dados do Zenoss Modelo de Actividades do Processo de GC e sua Concretização no Zenoss Identificação, Especificação e Controlo da Configuração O Zenoss fornece um modelo de domínio para o repositório de itens de configuração bastante ajustado ao contexto deste trabalho. Apesar de ser possível estender este modelo com a criação inicial de novas classes de objectos, assume-se que essa necessidade surge naturalmente com o decorrer das actividades de Identificação e Especificação de Configurações. Desta forma, cabe ao Gestor de Configurações percorrer todas as actividades propostas para o processo de GC, e avaliar de forma criteriosa que etapas devem ser levadas a cabo em cada actividade. Caso seja verificada a necessidade de estender o modelo de domínio, o Zenoss proporciona métodos (Zenpacks) de estender as funcionalidades da ferramenta, nomeadamente a criação de novas classes de objectos e métodos de monitorização dos mesmos.

88 5.2. ZENOSS 69 A actividade de Controlo da Verificação deve apenas ser desencadeada pelo Gestor de Configurações depois de se assegurar (percorrendo as outras actividades propostas) que não existem incoerências entre a informação que se pretende adicionar/modificar/remover e os conteúdos da CMDB. A inserção da informação no Zenoss pode ser levada a cabo de três formas: 1. através do interface gráfico 2. através do interpretador interactivo executado na linha de comando, denominado Zendmd 3. através de uma API dedicada De forma a automatizar o processo de inserção de conteúdos no Zenoss, desenvolveu-se uma aplicação em python que recorre às funcionalidades disponibilizadas pela API do Zenoss. A aplicação é presentemente capaz de inserir conteúdos XML (ver Secção ) disponibilizada pelo RT via http. O Gestor de Configuração pode, de forma simples e semi-automática, executar a aplicação na linha de comandos para iniciar ligações à base de dados e inserir novos dispositivos. Como desenvolvimentos futuros pretende-se: estender a aplicação para a remoção e modificação de itens de configuração. estender a aplicação para a validação automática de conteúdos, dando uma vertente automática às actividades de Identificação e Especificação de Configuração. a automatização da execução da aplicação, (várias vezes ao dia), alertando o Gestor de configuração sempre que exista a ocorrência de problemas Auditoria A própria ferramenta Zenoss pode desencadear a actividade de Auditoria tendo em contas as capacidades de descobrir e monitorizar dispositivos. O Zenoss possibilita várias formas de descobrir/introduzir dispositivos e as suas componentes. O método mais simples é manualmente (manual discovery), através do interface do utilizador, e aí o Gestor de Configurações pode especificar os vários atributos do dispositivo. Esta solução contudo quando se pretende introduzir um número elevado 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.

89 70 CAPÍTULO 5. CONCRETIZAÇÃO DA SOLUÇÃO Figura 5.13: Gráficos de Desempenho Disponibilizados pelo Zenoss. No Zenoss existe o conceito de evento, e que representa uma manifestação de 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ção, ou externamente, (através de mensagens no syslog ou de armadilhas SNMP) capturadas por deamons especializados do Zenoss. Aos eventos podem associar-se regras dedicadas que controlam como os eventos são manipulados assim que entram no sistema. Entre as regras e acções possíveis de configurar, temos as regras de alerta que permitem enviar s ao administrador de sistema ou mesmo iniciar a execução de scrips pré-configuradas que minimizam o impacto de uma alerta. Após o processamento dos eventos (cujo historial é mantido separadamente numa base de dados MySQL), são apresentados sob a forma de uma consola de eventos na interface web. Os vários estados possíveis para um evento são: Critical, Error, Warning, Info, Debug e Clear.

90 Capítulo 6 Avaliação Neste capítulo são discutidos os resultados atingidos avaliando-se se as questões de investigação colocadas na Secção 1.2 se encontram respondidas. Questão 1: Como desenhar o processo de GA para permitir, de uma forma comum e coerente, gerir as alterações na infra-estrutura física, de rede e de serviços 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ção e quais os critérios de categorização. Foram identificadas as principais funcionalidades de um sistema de GA que implementa o processo proposto, e que esteja alinhado com as práticas comuns e com os principais procedimentos da instituição onde se insere. Para poder desenhar o sistema de GA foi necessário o conhecimento da instituição LIP: saber o contexto no qual se enquadra e como são efectuados os principais procedimentos no seu CC. Questão 2: Como desenhar o processo de Gestão de Configurações e a CMDB, para que as informações sobre a infra-estrutura, assim como as relações entre os seus diversos itens, sejam conhecidas, estejam globalmente acessíveis e num estado actualizado? Foi proposto um sistema de GC, definidas as principais actividades, quais os seus intervenientes e principais responsabilidades. Foram identificados os activos da instituição que terão que ser mantidos na CMDB, e qual o fluxo de implementação da CMDB. Questão 3: Que ferramentas podem ser utilizadas e de que forma podem ser adaptadas para concretizarem os processos de Gestão de Alterações e de Gestão de Configurações? O sistema de GA foi concretizado através da ferramenta RT. A sua grande capacidade de 71

91 72 CAPÍTULO 6. AVALIAÇÃO ajuste a ambientes heterogéneos, a sua flexibilidade na configuração de workflows, e a sua facilidade de configuração permitiu a implementação do processo de GA alinhado com a framework ITIL. Após a devida configuração, as funcionalidades da ferramenta permitem satisfazer os requisitos os requisitos apresentados na Secção 3.3, e agora comparados na Tabela 6.1. Requisito Negócio Características do RT 1. Sistema desenvolvido utilizando * open-source, licença GNU ferramentas open-source GPL 2. Fluxo de informação baseado num *Notificações via: , sms sistema de notificações entre os scrips vários intervenientes Não Funcionais 1. Restrição e acesso Controlado *Sistema multiutilizador com mecanismo de autenticação Funcionais 1. Planeamento de intervenções sobre *Permite adaptar o workflow componentes informáticos (adição, às preferências do utilizador substituição e remoção) *Permite criar relações de dependências entre tarefas 2. Registo de acções efectuadas sobre *Capacidade de rastrear o componentes informáticos incluindo histórico, Gestão de intervenções de manutenção dependências 3. Efectuar procuras sobre as acções *TicketSQL Query Language efectuadas sobre determinado componente 4. Elaborar relatórios e estatísticas *Dashboards, que possibilitem obter métricas para *Extensão RTX::Statistics os vários componentes informáticos da *Gráficos: on demand instituição Tabela 6.1: As Características do RT Permitem Satisfazer os Requisitos de Negócio, Funcionais e Não Funcionais estabelecidos.

92 73 O Sistema de GC foi concretizado utilizando a ferramenta Zenoss. O seu modelo revelou-se adequado ao contexto a implementar na instituição, e as suas funcionalidades de monitorização e auditoria revelaram-se uma mais valia na implementação do processo de GC. A comparação das características do Zenoss com os requisitos propostos encontra-se explicada na Tabela 6.2.

93 74 CAPÍTULO 6. AVALIAÇÃO Requisito Negócio Características do Zenoss 1. Sistema desenvolvido utilizando * Versão Zenoss Core gratuita ferramentas open-source 2. Fluxo de informação baseado num * Existência de regras de sistema de notificações entre os notificação (notificação vários intervenientes por e sms) que podem ser definidas na ocorrência de eventos definidos Não Funcionais 1. Autenticação via login/password * Sistema multiutilizador com mecanismo de autenticação Funcionais 2. Administrador com permissões para * Manager: detém todos os criar, apagar e manipular informação em privilégios, ZenUser: todos os módulos do sistema permissões de visualização da informação 3. Registo de acções efectuadas sobre * Rastrear alterações feitas componentes informáticos aos eventos, Controle de alterações feitas à monitorização dos serviços 4. Registo de acções realizadas pelos * Multiutilizador, Capacidade utilizadores e pelo administrador de rastrear o histórico das do sistema alterações 5. Efectuar procuras sobre as acções * Procuras por dispositivo, efectuadas sobre determinado (nome, endereço IP) componente 6. Elaborar relatórios e estatísticas * Relatórios: do inventário global, que possibilitem obter métricas para do histórico com as alterações os vários componentes informáticos da na rede, com os detalhes dos instituição dispositivos, dos problemas e da disponibilidade da rede existência de gráficos que avaliam desempenho dos dispositivos (CPU, Free Memory) 7. Inventário actualizado do equipamento * Possui base de dados com um de hardware existente no LIP modelo do inventário e detalhes de configuração, capacidade de descoberta automática de dispositivos Tabela 6.2: As Características do Zenoss Permitem Satisfazer os Requisitos de Negócio, Funcionais e Não Funcionais estabelecidos

94 75 Como os activos presentes na CMDB são provenientes de alterações relativas à infraestrutura de Hardware, é necessária uma integração estes dois processos. Para atingir este objectivo é descrita um forma automática da introdução de alterações provenientes do RT na CMDB do Zenoss.

95 76 CAPÍTULO 6. AVALIAÇÃO

96 Capítulo 7 Conclusão Neste capítulo são apresentadas as conclusões e discutidas algumas possibilidades de desenvolvimento. Esta tese teve como objectivo o estudo de um sistema que vise a optimização da operação e da gestão de um centro de cálculo de um instituto de Física Experimental de Altas Energias (LIP) cuja principal actividade é o fornecimento de serviços de computação e armazenamento a utilizadores locais, e a investigadores remotos integrados em infra-estruturas de computação distribuídas. A proposta incidiu sobre a implementação dos processos de Gestão de Alterações e de Gestão de Configurações, de acordo com a framework ITIL, considerados prioritários para efectuar o suporte diário às operações da infra-estrutura. Uma das fases mais importantes deste estudo consistiu em identificar os requisitos, e em avaliar os mecanismos ad-hoc executados pelos vários membros do centro de cálculo, através de uma série de entrevistas e avaliações, e integrá-los num procedimento global que minimize possíveis interrupções com as actividades presentemente levadas a cabo. O modelo para o processo de Gestão de Alterações desenvolvido consistiu em identificar um modelo e um fluxo de actividades adequado, em identificar os papéis dos vários interlocutores e os diferentes casos de uso, em estabelecer os estados das alterações, e em estabelecer critérios para a categorização e avaliação das alterações. Tendo em conta os requisitos disponibilizados, a concretização da solução foi desenvolvida sobre uma ferramenta denominada de Request Tracker, cujas funcionalidades e fluxos foram ajustados de acordo com o modelo aqui proposto. O modelo para o processo de Gestão de Configurações consistiu na identificação das principais actividades, dos interlocutores, dos casos de uso e dos itens de configuração (hardware) a serem guardados, tendo em vista a minimização da existência de informação inconsistente ou incoerente. A introdução dos activos na CMDB é um passo importante do processo de GC. Sabendo que obter uma lista dos activos da instituição e das suas relações entre si, seria uma tarefa difícil de concretizar e bastante demorada, devido à enorme quantidade de activos existentes e 77

97 78 CAPÍTULO 7. CONCLUSÃO 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ção em cada uma das áreas-chave dos processos operacionais que possam lidar com os dados de configuração. Desta forma, em vez de se popular a CMDB com todos os activos de uma só vez, o que origina quase sempre uma CMDB desactualizada, optou-se por ir alterando a CMDB à medida que os activos vão sofrendo revisões. É possível, assim, manter uma CMDB permanentemente actualizada. A ferramenta Zenoss foi a seleccionada para a concretização do modelo dado a sua flexibilidade, extensibilidade e as suas propriedades de monitorização, muito adequadas à actividade de auditoria. A vantagens da implementação destes dois processos no LIP são óbvias: O processo de GA possibilita determinar se uma dada alteração é exequível e o seu impacto, e estabelecer que o fluxo de tarefas realizado por vários intervenientes 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ção. O processo de GC possibilita que, aquando da ocorrência de uma alteração, se consiga saber de forma correcta e actualizada quais os recursos existentes na instituição. A adopção das ferramentas (Request Tracker e Zenoss) revelou-se uma boa escolha, pois para além de conseguirem implementar os processos definidos, permitem ir mais longe: o RT permite a implementação do processo de Gestão de 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ção. A implementação dos processos de GA e GC é um trabalho difícil e longe de estar completo em qualquer instituição. A continuação deste trabalho contemplará o aumento do âmbito do tipo de alterações permitidas, de forma a tornar o processo mais geral e abrangente a todo o tipo de alterações com impacto na instituição. A discussão deste tópico seguir-se-á na secção seguinte. 7.1 Trabalho a Desenvolver Relativamente ao processo de GA, é necessário aumentar o seu âmbito de forma a permitir outros tipos de alterações, para alem daquelas já contempladas e que dizem respeito a alterações na infra-estrutura de hardware. Por exemplo é necessário gerir as alterações relativas ao software existente. Esta generalização poderá levar ao alargamento dos workflows já existentes, ou à possível definição de novos workflows, o que poderá resultar numa reestruturação das configurações implementadas ao nível do RT.

98 7.1. TRABALHO A DESENVOLVER 79 Novas alterações implicam a caracterização de novos itens de configuração, com novos atributos que poderão não estar contemplados na CMDB do Zenoss. Desta forma, é também necessário contemplar a necessidade de expandir o Zenoss, e explorar as potencialidades oferecidas através do seu módulo de Zenpacks de forma a implementar novas funcionalidades e permitir a monitorização de novos tipos de dispositivos. O mecanismo de integração dos processos de GA e GC deve ser fortificado com o desenvolvimento da aplicação de integração de forma a que algumas das actividades possam ser desenvolvidas de forma automática, isto é, sem intervenção humana. Finalmente, o processo de Gestão de Configurações dá muitas vezes origem a incidentes que geram novas alterações. Desta forma, um patamar que ainda falta implementar é um modelo de Gestão de incidentes que feche o ciclo estabelecido pelos modelos implementados.

99 80 CAPÍTULO 7. CONCLUSÃO

100 Bibliografia [1] Judith M. Myerson. Cloud Computing Versus Grid Computing. Service Types, Similarities and Differences, and Things to Consider, 3 March 2009, [2] Foster Ian, Kesselman Carl. The Grid2: Blueprint for a New Computing Infrastructure. Elsevier Inc, 2004 [3] Chappell David. A Short Introduction to Cloud Platforms: An Enterprise-Oriented View. Chappell and Associates [4] Office of Government Commerce. Itil Service Support. The Stationery Office [5] Office of Government Commerce. Itil Service Delivery. The Stationery Office [6] Office of Government Commerce. Planning To Implement Service Management. The Stationery Office [7] Office of Government Commerce. Application Management. The Stationery Office [8] Office of Government Commerce. ICT Infrastructure Management. The Stationery Office [9] Office of Government Commerce. Security Management. The Stationery Office [10] Baskerville, Richard L Investigating Information Systems with Action Research. Commun. AIS, 2, 4. [11] Office of Government Commerce. Best Practice for Service Support, Managing IT Services. The Stationary Office [12] Jane Curry. Open Source Management Options. White Paper, Skills 1st Ltd. September 30th, [13] Scott Stone. Monitoring Systems Comparison White Paper. The Forbin Group. June 14, [14] Will Capelli. Magic Quadrant for Application Performance Monitoring White Paper. Gartner RAS Core Research Note, G February RA

101 82 BIBLIOGRAFIA [15] David Williams, Debra Curtis. Magic Quadrant for IT Event Correlation and Analysis White Paper. Gartner RAS Core Research Note, G December RV3 A [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 [21] ITIL Configuration 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), [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 [25] Spremic, M., Zmirak, Z., Kraljevic, K. IT and Business Process Performance Management: Case Study of ITIL Implementation in Finance Service Industry. Pages of: 30th International Conference on Information Technology Interfaces. June [26] ITIL: Microsoft and Open Source, White Paper. Microsoft Corporation, October 26, [27] Filipe Crespo Martins. Implementing ITIL Change Management thesis. Instituto Superior Técnico, Universidade Técnica de Lisboa [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/ A1. Pub. Date: Jan.5, [29] Jesse Vincent, Robert Spier, Dave Rolsky, Darren Chamberlain, Richard Foley. RT Essencials. O REILLY, 2005

102 BIBLIOGRAFIA 83 [30] Jane Curry. Zenoss Discovery and Classification White Paper. Skill 1st Ltd. February 2009 [31] Methods of monitoring processes with Zenoss White Paper, Jane Curry. Skill 1st Ltd. February 2009 [32] Zenoss Enterprise Architecture Overview, White Paper. Copyright 2010 Zenoss, Inc. [33] Klosterboer, Larry. Implementing ITIL Configuration Management. IBM Press, 2008 [34] Zenoss Developer s Guide Version 3.0. Zenoss, Inc. [35] [36] [37] [38] [39] [40] [41] [42] [43]

103 84 BIBLIOGRAFIA

104 Apêndice A Simbologia Utilizada nos Diagramas do Processo da Gestão de Configurações 85

105 86APÊNDICE A. SIMBOLOGIA UTILIZADA NOS DIAGRAMAS DO PROCESSO DA GESTÃO DE CONFI Forma de decisão que indica um ponto de ramificação (Sim ou Não) no fluxo do processo, por exemplo, informação proveniente do cliente está correcta? Forma que indica que o processo continua num diagrama diferente; o número indica a etapa do processo. Por exemplo, o processo continua num diagrama diferente na etapa 2.1 Forma que indica uma sequência de acções que executam tarefas específicas embutidas dentro de um fluxo do processo externo, por exemplo, Gestão de Alterações. Identifica bases de dados utilizadas nos fluxos de processo, por exemplo a CMDB. Actividade a realizar no fluxo do processo, por exemplo, criar uma nova instância na CMDB Forma que indica fase inicial ou final do fluxo do processo. Por exemplo, Iniciar uma auditoria. Forma que ilustra a sequência de passos e a direcção do fluxo do processo.