Embed Size (px)
Citation preview
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
PROTÓTIPO DE MONITORAMENTO DE SLA BASEADO NOS SERVIÇOS DE CAPACIDADE E DISPONIBILIDADE DA ITIL
Área de Sistemas de Informação
por
Douglas Hinckel Martins
Marcello Thiry, Dr Orientador
São José (SC), julho de 2008
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
PROTÓTIPO DE MONITORAMENTO DE SLA BASEADO NOS SERVIÇOS DE CAPACIDADE E DISPONIBILIDADE DA ITIL
Área de Sistemas de Informação
por
Douglas Hinckel Martins
Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Marcello Thiry, Dr
São José (SC), julho de 2008
DEDICATÓRIA
À minha filha Letícia por renovar minha vida, minha esposa Mylene pelo amor e
companheirismo e aos meus pais pela educação
AGRADECIMENTOS
Agradeço primeiramente a Deus.
Aos meus pais, Rodolfo Paulo Martins e Laurina Hinckel Martins, que com amor e
disciplina me fizeram a pessoa que sou, e me ensinaram os valores a serem seguidos e
conquistados.
À minha esposa Mylene Joana Sodré Martins, pelo amor, companheirismo, pelo apoio
durante todos os momentos e por ter me dado uma filha linda chamada Letícia Sodré Martins,
nossa eterna princesinha.
À minha avó Malvina por toda a ajuda na minha criação e por todo o amor e carinho
recebido.
Ao meu primo Jucemar da Silva que me incentivou a entrar na vida acadêmica e por
todos os outros grandes conselhos recebidos.
Ao meu orientador Marcello Thiry pelos esclarecimentos, apoio para a realização
deste projeto e pela amizade.
Ao meu amigo David Graminho que não me deixou desanimar durante esta longa
caminhada dentro da Universidade.
À empresa Relativa Soluções, que por intermédio de Juano Del Prado e Carlos Wosti
me deram todo o suporte necessário para a realização deste trabalho.
Ao meu amigo Walter C. Jr. Pelo apoio durante o meu TCC-I.
Aos amigos e familiares que contribuíram de alguma maneira para a realização deste
trabalho.
Ao meu irmão Daniel pela ajuda na tradução dos questionários.
Ao Creed, Green Day, Oasis, Cake, Jet, AC/DC, Offspring, Beatles,... que me
acompanharam em tantas madrugadas e finais de semana.
SUMÁRIO
LISTA DE ABREVIATURAS .......................................................vii
LISTA DE FIGURAS ................................................................... viii
LISTA DE TABELAS ...................................................................... x
LISTA DE EQUAÇÕES .................................................................. xi
RESUMO .........................................................................................xii
ABSTRACT................................................................................... xiii
1. INTRODUÇÃO ............................................................................ 1
1.1. PROBLEMATIZAÇÃO .......................................................................... 3
1.1.1. Formulação do Problema ...................................................................... 3
1.1.2. Solução Proposta .................................................................................... 4
1.2. OBJETIVOS ............................................................................................. 5
1.2.1. Objetivo Geral ........................................................................................ 5
1.2.2. Objetivos Específicos ............................................................................. 5
1.3. DELIMITAÇÃO DO ESCOPO............................................................... 6
1.4. JUSTIFICATIVA ..................................................................................... 7
1.5. METODOLOGIA .................................................................................... 8
1.6. ESTRUTURA DO TRABALHO ............................................................. 9
2. FUNDAMENTAÇÃO TEÓRICA ............................................. 10
2.1. VISÃO GERAL DA ITIL ...................................................................... 10
2.1.1. História ................................................................................................. 10
2.1.2. Estrutura .............................................................................................. 11
2.1.3. Visão Geral da ITIL Versão Dois........................................................ 12
2.1.4. Gerenciamento de Serviços ................................................................. 13
2.1.5. Relacionamento dos Processos de Gerenciamento de Serviços ......... 15
2.2. GERENCIAMENTO DE NÍVEL DE SERVIÇO ................................. 16
2.2.1. Atividades ............................................................................................. 17
2.2.2. Catálogo de Serviços ............................................................................ 18
2.2.3. SLA ....................................................................................................... 19
2.2.4. Tipos de SLA ........................................................................................ 21
2.2.5. Estrutura de um SLA .......................................................................... 24
2.2.6. Monitorando o SLA ............................................................................. 25
2.2.7. Relatórios e Revisões............................................................................ 27
2.2.8. Benefícios .............................................................................................. 27
2.3. GERENCIAMENTO DE DISPONIBILIDADE ................................... 28
2.3.1. Elementos do Gerenciamento de Disponibilidade .............................. 30
2.3.2. Classificação dos Serviços de TI .......................................................... 31
2.3.3. Métricas de Disponibilidade ................................................................ 32
2.3.4. Cálculo da Disponibilidade .................................................................. 33
2.3.5. Relacionamento com o SLA ................................................................ 36
v
2.3.6. Benefícios .............................................................................................. 37
2.4. GERENCIAMENTO DE CAPACIDADE ............................................ 37
2.4.1. Processos de Gerenciamento ............................................................... 38
2.4.2. Atividade de Monitoramento .............................................................. 41
2.4.3. Atividades de Análise, Ajuste e Implementação ................................. 43
2.4.4. Banco de Dados de Capacidade .......................................................... 45
2.4.5. Gerenciamento da Demanda e Modelagem da Capacidade .............. 45
2.4.6. Dimensionamento dos Recursos e Planejamento da Capacidade ...... 47
2.4.7. Relacionamento com o SLA ................................................................ 48
2.4.8. Benefícios .............................................................................................. 49
2.5. CONSIDERAÇÕES DO CAPÍTULO ................................................... 49
3. DESENVOLVIMENTO ............................................................. 50
3.1. VISÃO GERAL ...................................................................................... 50
3.2. REQUISITOS ......................................................................................... 51
3.2.1. Funcionais ............................................................................................ 52
3.2.2. Não-Funcionais .................................................................................... 54
3.3. REGRAS DE NEGÓCIO ....................................................................... 55
3.4. CASOS DE USO ..................................................................................... 57
3.4.1. Monitoramento de SLA ....................................................................... 58
3.5. DIAGRAMA DE CLASSE .................................................................... 60
3.6. DIAGRAMA DE SEQÜÊNCIA ............................................................ 62
3.7. DIAGRAMA ENTIDADE-RELACIONAMENTO.............................. 63
3.8. TECNOLOGIAS UTILIZADAS ........................................................... 64
3.9. ESTRUTURA DO PROJETO ............................................................... 67
3.9.1. Projeto Agentes .................................................................................... 68
3.9.2. Projeto SLAWeb .................................................................................. 71
3.10. AMBIENTE DE TESTES ..................................................................... 75
3.10.1. Agentes ............................................................................................... 76
3.10.2. SLAs ................................................................................................... 76
3.11. TESTES E AVALIAÇÃO ..................................................................... 80
3.11.1. Testes .................................................................................................. 80
3.11.2. Avaliação ............................................................................................ 85
3.11.3. Questionário de Gerenciamento Capacidade .................................. 87
3.11.4. Questinário de Gerenciamento de Disponibilidade ......................... 91
3.11.5. Questinário de Gerenciamento de Níveis de Serviço ....................... 94
3.12. RESULTADOS ..................................................................................... 97
4. CONCLUSÕES ........................................................................ 100
4.1. TRABALHOS FUTURO ..................................................................... 102
REFERÊNCIAS BIBLIOGRÁFICAS ........................................ 103
APÊNDICES ................................................................................. 106
A CASOS DE USO ....................................................................... 107
A.1 CONTROLE DE ACESSO .................................................................. 107
vi
A.2 CADASTRO SLA ................................................................................. 108
A.3 CRIAÇÃO DE AGENTES .................................................................. 110
B DIAGRAMAS DE CLASSE .................................................... 112
B.1 CADASTRO DE SLA .......................................................................... 112
B.2 CRIAÇÃO DOS AGENTES ................................................................ 113
B.3 MONITORAMENTO .......................................................................... 113
B.4 FUNCIONAMENTO DOS AGENTES ............................................... 114
B.5 CONTROLE DE ACESSO .................................................................. 115
C DIAGRAMAS DE SEQÜÊNCIA ............................................ 116
C.1 CONTROLE DE ACESSO .................................................................. 116
C.2 CADASTRO DE SLA - CAPACIDADE ............................................. 117
C.3 CADASTRO DE SLA - DISPONIBILIDADE .................................... 118
C.4 CRIAÇÃO DOS AGENTES ................................................................ 119
C.5 FUNCIONAMENTO DO AGENTE CAPACIDADE ........................ 120
C.6 FUNCIONAMENTO DO AGENTE DISPONIBILIDADE ............... 121
D PROTÓTIPOS DE TELA ........................................................ 122
D.1 TELA CADASTRO DE SLA - CABEÇALHO .................................. 122
D.2 TELA CADASTRO DE SLA - ITENS DE DISPONIBILIDADE ..... 122
D.3 TELA CADASTRO DE SLA - ITEM DE CAPACIDADE ................ 123
D.4 TELA AGENTE DE CAPACIDADE.................................................. 123
D.5 TELA AGENTE DE DISPONIBILIDADE ........................................ 124
D.6 TELA MONITORAMENTO DE SLAS ............................................. 124
E FUNÇÕES SQL SERVER 2005 .............................................. 125
E.1 CALCULO CAPACIDADE CPU ATUAL ......................................... 125
E.2 CALCULO CAPACIDADE MEMORIA ATUAL ............................. 125
E.3 CALCULO CAPACIDADE DISCO ATUAL ..................................... 126
E.4 CALCULO CAPACIDADE CPU FORA LIMIAR ............................ 126
E.5 CALCULO CAPACIDADE MEMORIA FORA LIMAR ................. 127
E.6 CALCULO CAPACIDADE DISCO FORA LIMAR ......................... 127
E.7 CALCULO DISPONIBILIDADE HARDWARE ............................... 128
E.8 CALCULO DISPONIBILIDADE SOFTWARE ................................ 128
E.9 CALCULO INDISPONIBILIDADE HARDWARE .......................... 129
vii
LISTA DE ABREVIATURAS
ASP Active Server Pages BDC Banco de Dados de Capacidade CCTA British Central Computer and Telecommunication Agency CMDB Configuration Management Database COBIT Control Objectives for Information and related Technology DBA Database Administrator DLL Dynamic-Link Library EFQM European Foundation for Quality Management ER Entidade Relacionamento GCS Gerenciamento de Capacidade de Serviço GCN Gerenciamento de Capacidade do Negócio GCR Gerenciamento de Capacidade dos Recursos GITIM Government Information Technology Infrastructure Management IEC International Electrotechnical Commission IIS Internet Services Information ITIL Information Technology Infrastructure Library MMDTI Modelo de Métricas da Disponibilidade de TI MTBF Mean Time Between Failures MTBSI Mean Time Between System Incidents MTTR Mean Time To Repair OGC Office of Government Commerce OLA Operating Level Agreement SLA Service Level Agreement SLO Service Level Objective SLR Service Level Report TI Tecnologia da Informação TIC Tecnologia de Informação e Comunicações UC Underpinning Contract VM Virtual Machine
LISTA DE FIGURAS
Figura 1. Estrutura das principais publicações da segunda versão da ITIL ........................... 11
Figura 2. Posicionamento dos Processos da ITIL ................................................................. 13
Figura 3. Processos da Entrega de Serviços ......................................................................... 14
Figura 4. Escopo do Gerenciamento de Nível de Serviço ..................................................... 16
Figura 5. Atividades do Gerenciamento de Nível de Serviço ............................................... 18
Figura 6. Relacionamento entre clientes e os níveis de serviços ........................................... 20
Figura 7: Estrutura de suporte de um SLA. .......................................................................... 22
Figura 8. Responsabilidades do Gerenciamento de Disponibilidade ..................................... 29
Figura 9. Fórmula do Cálculo de Disponibilidade ................................................................ 34
Figura 10. Ciclo de Vida do Incidente ................................................................................. 34
Figura 11. Cálculo de disponibilidade total de uma infra-estrutura....................................... 36
Figura 12. Sub-Processos do Gerenciamento de Capacidade ............................................... 39
Figura 13. Atividades Interativas do Gerenciamento de Capacidade .................................... 41
Figura 14. Fluxo de Dados do Planejamento de Capacidade ................................................ 48
Figura 15. Arquitetura da Solução Proposta ......................................................................... 51
Figura 16. USC-OO Atores do Sistema ............................................................................... 58
Figura 17. USC-04 Monitoramento de SLA ........................................................................ 58
Figura 18. Diagrama de Classe - Classes de Entidade .......................................................... 61
Figura 19. Diagrama de Seqüência - Monitoramento de SLA .............................................. 62
Figura 20. Diagrama Entidade-Relacionamento ................................................................... 64
Figura 21. Ambiente de Trabalho do Visual Studio 2005 ..................................................... 65
Figura 22. Ambiente de Configuração do IIS 6. ................................................................... 66
Figura 23. Tela do VirtualBox da Sun ................................................................................. 67
Figura 24. Projetos do Visual Studio ................................................................................... 68
Figura 25. Estrutura Projeto Agentes ................................................................................... 69
Figura 26. Tela Agente Coletor ........................................................................................... 69
Figura 27. Agente Coletor de Capacidade ............................................................................ 70
Figura 28. Agente Coletor de Disponibilidade ..................................................................... 71
Figura 29. Protocolo dos Agentes Coletores: (a) Capacidade; (b) Disponibilidade ............... 71
Figura 30. Estrutura Projeto SLAWeb ................................................................................. 72
Figura 31. Função para Cálculo de Indisponibilidade de Software ....................................... 73
Figura 32. Tela de Login do Protótipo ................................................................................. 75
Figura 33. Lista de Agentes Coletores Criados .................................................................... 76
Figura 34. Lista de SLAs Criados ........................................................................................ 77
Figura 35. Configurações do SLA 001................................................................................. 78
Figura 36. Configurações SLA 002 ..................................................................................... 78
Figura 37. Configurações do SLA 003................................................................................. 79
Figura 38. SLA 001 (Item 1) - Qtde segundos indisponibilidade/hora .................................. 81
Figura 39. SLA 001 (Item 2) - Qtde segundos indisponibilidade/hora .................................. 82
Figura 40. SLA 002 - Qtde segundos indisponibilidade/hora ............................................... 83
ix
Figura 41. SLA 003 - Histórico de utilização dos recursos ................................................... 83
Figura 42. Monitoramento SLA........................................................................................... 84
Figura 43. SLA 001 - Detalhes do Contrato ......................................................................... 85
Figura 44. Detalhes monitoramento SLA 002 ...................................................................... 85
Figura 45. Gráfico de Resultados dos Questionários de Avaliação ...................................... 98
Figura 46. USC-O1 Efetuar Login ..................................................................................... 107
Figura 47. USC-02 Cadastro de SLA ................................................................................. 108
Figura 48. USC-03 Criação de Agentes ............................................................................. 110
Figura 49. Diagrama de Classe - Módulo Cadastro de SLA ............................................... 112
Figura 50. Diagrama de Classe - Módulo de Criação dos Agentes ..................................... 113
Figura 51. Diagrama de Classe - Módulo de Monitoramento ............................................. 113
Figura 52. Diagrama de Classe - Funcionamento dos Agentes ........................................... 114
Figura 53. Diagrama de Classe - Módulo Controle de Acesso ........................................... 115
Figura 54. Diagrama Seqüência - Controle de Acesso ....................................................... 116
Figura 55. Diagrama Seqüência - Cadastro de SLA – Capacidade ..................................... 117
Figura 56. Diagrama Seqüência - Cadastro de SLA – Disponibilidade ............................... 118
Figura 57. Diagrama Seqüência - Criação dos Agentes ...................................................... 119
Figura 58. Diagrama Seqüência - Funcionamento do Agente Capacidade .......................... 120
Figura 59. Diagrama Seqüência - Funcionamento do Agente Disponibilidade ................... 121
Figura 60. Protótipo de Tela de Cadastro de SLA – Cabeçalho .......................................... 122
Figura 61. Protótipo de Tela de Cadastro de SLA - Itens de Disponibilidade ..................... 122
Figura 62. Protótipo de Tela de Cadastro de SLA - Item de Capacidade ............................ 123
Figura 63. Protótipo de Tela de um Agente de Capacidade ................................................ 123
Figura 64. Protótipo de Tela de um Agente de Disponibilidade ......................................... 124
Figura 65. Protótipo de Tela de Monitoramento de SLAs .................................................. 124
Figura 66. Capacidade CPU Atual ..................................................................................... 125
Figura 67. Capacidade Memoria Atual .............................................................................. 125
Figura 68. Capacidade Disco Atual ................................................................................... 126
Figura 69. Qtde Capacidade CPU Fora Limiar .................................................................. 126
Figura 70. Qtde Capacidade Memoria Fora Limiar ............................................................ 127
Figura 71. Qtde Capacidade Disco Fora Limiar ................................................................. 127
Figura 72. Cálculo Disponibilidade Hardware ................................................................... 128
Figura 73. Cálculo Disponibilidade Software .................................................................... 128
Figura 74. Cálculo Indisponibilidade Hardware ................................................................. 129
x
LISTA DE TABELAS
Tabela 1: Diferenças entre o SLA e o OLA ......................................................................... 23
Tabela 2. Tempo de Indisponibilidade ................................................................................. 31
Tabela 3. Variáveis Técnicas de Monitoramento de Capacidade .......................................... 42
Tabela 4. Modelo de Exemplo de um BDC ......................................................................... 45
Tabela 5. USC-04 Monitoramento de SLA .......................................................................... 59
Tabela 6. Computadores utilizados no Ambiente de Testes.................................................. 75
Tabela 7. Tabela de Resultados dos Questionários de Avaliação......................................... 97
Tabela 8. USC-01 Efetua Login ........................................................................................ 107
Tabela 9. USC-02 Cadastro de SLA .................................................................................. 109
Tabela 10. USC-03 Criação de Agentes ............................................................................. 111
xi
LISTA DE EQUAÇÕES
Equação 1 ........................................................................................................................... 81
Equação 2 ........................................................................................................................... 82
Equação 3 ........................................................................................................................... 82
Equação 4 ........................................................................................................................... 82
xii
RESUMO
MARTINS, Douglas Hinckel. Protótipo de Monitoramento de SLA baseado nos Serviços de Capacidade e Disponibilidade da ITIL. São José, 2008. 143 f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação)–Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, São José, 2008.
Nos dias de hoje, para que uma organização consiga atender os seus objetivos estratégicos e a necessidade de seus negócios, ela torna-se mais dependente da área de TI. Por outro lado, a área de TI que não se preocupa com os objetivos estratégicos da área de negócios de uma organização, acaba assumindo um papel secundário neste cenário, servindo apenas como provedora de tecnologia. Para a empresa que deseja ter a sua área de TI provendo um suporte mais focado nos objetivos estratégicos da empresa, pode-se adotar as boas práticas de gerenciamento de TI contidas na ITIL. O elemento chave dentro deste processo é o SLA, um acordo escrito entre um provedor de serviços de TI e seu cliente, que define os objetivos e responsabilidades das duas partes. Tão importante quanto criar um SLA é monitorar seus objetivos com eficiência e eficácia, para que a entrega dos serviços e a imagem da organização não fique prejudicada. O objetivo deste trabalho é monitorar a capacidade da TI em atender a demanda dos negócios e a disponibilidade da sua infra-estrutura. O problema dentro deste processo é alocação de pessoas para a realização desta tarefa, a qual pode ser cara e ineficaz, devido à grande quantidade de itens que podem estar contidos dentro de um objetivo e que precisam ser monitorados constantemente. Além disso, falhas humanas podem prejudicar este processo. O protótipo desenvolvido é uma ferramenta para auxiliar a equipe de TI no monitoramento dos SLAs acordados com seus clientes, através do uso de agentes coletores de dados. Estes agentes são softwares que ficam monitorando constantemente os recursos de disponibilidade e capacidade da infra-estrutura de TI, transmitindo os seus dados até um servidor Web através de um WebService. Uma vez que os dados coletados estejam armazenados, a equipe responsável pode acompanhar seus contratos em qualquer lugar através da internet, contribuindo deste modo para o cumprimento dos objetivos dos SLAs e permitindo que a área de TI possa satisfazer as necessidades da área de negócios.
Palavras-chave: ITIL. SLA. Monitoramento.
xiii
ABSTRACT
Nowadays, for an organization to meet its strategic objectives and the need for their businesses, it becomes more dependent on the IT area. However, the IT area without any concern for the strategic objectives of the organization business, just assuming a secondary role in this scenario, serving only as a technology provider. Businesses that wish to have their IT area providing a support more focused on company strategic objectives, they can adopt the managing IT best practices contained in ITIL. The key element in this process is the SLA, a written agreement between an IT service provider and the IT customer(s), defining the key service targets and responsibilities of both parties. As important as creating an SLA is monitor their goals with efficiency and effectiveness, so that the services delivery and the organization image don’t be impaired. The goal of this paper is to monitor the IT capacity to meet the business demand and the IT infrastructure availability. The problem in this case is the IT staff allocation to fulfill this task, which can be expensive and inefficient, due to the large quantity of items that can be contained within a goal and that must be monitored constantly. In addition, human error can undermine this process. The developed prototype is a tool to assist the IT team in the SLAs agreed monitoring, through the use of data agents collectors. These are software agents that are constantly monitoring the capacity and availability of the IT infrastructure resources, transmitting its data to a Web server through a Web Service. Since the data collected are stored, the IT team can track their contracts anywhere via Internet, thus contributing to the SLAs objectives achievement and enabling the IT area to meet the business needs.
Keywords: ITIL. SLA. Monitoring.
1. INTRODUÇÃO
Na última década, o relacionamento entre empresas e consumidores vem mudando e há uma
preocupação eminente das empresas com as informações, com a qualidade dos serviços
prestados e principalmente com os prazos de entrega. As empresas estão cada vez mais
preocupadas com o nível de confiança que as suas marcas proporcionam aos seus clientes.
Devido a este fato, o relacionamento entre os clientes e os fornecedores de tecnologia está
mudando de forma benéfica (WOZEN, 2007).
O gerenciamento de serviços de TI (Tecnologia da Informação) é um instrumento que ajuda a
organização a tomar uma postura mais proativa no controle dos seus processos, evitando
deste modo a ocorrência de problemas na entrega e na execução dos seus serviços de TI. Seus
principais objetivos são alinhar os serviços de TI com a realidade da organização e de seus
clientes, prover uma melhoria na qualidade dos serviços oferecidos e reduzir os custos do
fornecimento de serviços de TI. Isto pode ser obtido alocando de maneira mais adequada os
recursos disponíveis e fazendo o seu gerenciamento de maneira mais integrada. A
importância da área de TI para o crescimento de uma organização torna a TI parte desta, e
conseqüentemente cria-se uma ligação estratégica entre a TI e as demais áreas de negócio
desta organização. Ao invés de produtos, ela passa então, a fornecer serviços, criando assim
uma relação de cliente-fornecedor, onde a área de TI atua como provedora de serviços e a
organização como cliente destes. Portanto, ela precisa determinar quais os serviços serão
fornecidos, a ligação deles com o alinhamento estratégico da organização e também
preocupar-se com a qualidade destes serviços para que eles estejam de acordo com os níveis
de qualidades solicitados pelo cliente (MAGALHÃES, et al., 2007).
A parceria com a área de negócio é atualmente um grande desafio das áreas de TI. Uma das
alternativas para o contorno destes problemas é a redução dos gastos com gerenciamento e
suporte de TI através do desenvolvimento de novos modelos de negócio para suportar e
melhorar a qualidade dos serviços prestados. Além disso, é interessante utilizar modelos
apropriados para cada negócio e que esses modelos utilizem de maneira eficiente as pessoas,
os processos, as ferramentas e as tecnologias envolvidas (MACFARLANE, et al., 2005).
2
Uma ferramenta que pode ser utilizada para auxiliar na confiança dos serviços prestados de
uma empresa é o Acordo de Nível de Serviço ou Service Level Agreement (SLA1). O SLA
tem como objetivo definir uma estrutura que garanta que cliente e provedor de serviço
utilizem os mesmos critérios de avaliação da qualidade do serviço prestado. Com o SLA, o
cliente pode assegurar legalmente a qualidade do serviço contratado e o provedor de serviço
pode atender à demanda e a qualidade de seus serviços com base nos compromissos do
contrato acordado (GOMES, et al., 2005).
Em um SLA, definem-se os objetivos, níveis de qualidade dos serviços e principalmente as
medidas que serão monitoradas. Os indicadores estão relacionados ao tempo de resposta,
disponibilidade, tempo de atendimento das solicitações e tempo de reparo em caso de ocorrer
algum problema. Estas medidas são exemplos relacionados à área de TI, e podem conter
muito mais parâmetros dependendo do nível de exigência do cliente e da disponibilidade do
fornecedor em atender todas essas exigências (TRAINNING, 2007).
Junto com a qualidade dos contratos entre empresas e clientes, está a qualidade da empresa
fornecedora dos serviços de TI. Para a empresa que deseja ter a sua área de TI provendo um
suporte focado nas estratégias de negócio da empresa, ela pode adotar as boas práticas de
gerenciamento de TI contidas na ITIL (Information Technology Infrastructure Library)
(OGC, 2003). A ITIL provê um abrangente e consistente conjunto de melhores práticas para a
identificação de processos da área de TI e o alinhamento dos seus serviços às necessidades da
organização, promovendo uma abordagem qualitativa para o uso econômico, efetivo, eficaz e
eficiente da infra-estrutura de TI (MAGALHÃES, et al., 2007).
Dentro do Serviço de Entrega (Service Delivery) da ITIL existem três processos que são
abordados neste TCC: Gerenciamento de Capacidade, Gerenciamento de Disponibilidade e o
Gerenciamento de Nível de Serviço. O Serviço de Entrega preocupa-se com o planejamento e
a melhoria da prestação de serviços de TI em longo prazo. O Serviço de Entrega possui ainda,
outros processos, tais como: Gerenciamento Financeiro para TI e Gerenciamento da
Continuidade dos Serviços de TI (MACFARLANE, et al., 2005).
1 SLA: No contexto deste TCC, será adotada a sigla SLA. Apesar de ser um acrônimo para o conceito na língua
inglesa, esta sigla é amplamente adotada na literatura, evitando confusão no entendimento do texto.
3
O Gerenciamento de Nível de Serviço tem o objetivo de manter e melhorar a qualidade dos
serviços de TI, ele é o responsável pelo gerenciamento dos SLAs. O processo de
Gerenciamento de Capacidade é responsável por garantir que a capacidade da infra-estrutura
de TI atenda à demanda pelos serviços de TI da organização, permitindo sua expansão, de
modo apropriado em termos de custo e prazo. O processo de Gerenciamento de
Disponibilidade tem por objetivo otimizar a capacidade da infra-estrutura de TI e ajudar esta
área a entregar um nível sustentado de disponibilidade a um custo aceitável que permita
satisfazer os objetivos do negócio, proporcionando às organizações a plena utilização dos
recursos da infra-estrutura (MAGALHÃES, et al., 2007).
Dentro deste contexto, este trabalho procura fazer uma contribuição para o gerenciamento
dos níveis de serviço da infra-estrutura de TI, através do monitoramento de seus itens de
disponibilidade e capacidade. Atualmente existem no mercado softwares para o
monitoramento da capacidade e disponibilidade de um recurso de TI2, mas essas informações
são destinadas geralmente à área técnica, e não estão relacionadas aos SLAs. Este trabalho
tem como principal objetivo o desenvolvimento de um protótipo que relacione essas
informações aos SLAs e que forneça informações gerenciais e objetivas para auxiliar os
gerentes de TI no acompanhamento de seus serviços prestados.
1.1. PROBLEMATIZAÇÃO
1.1.1. Formulação do Problema
Um dos principais objetivos dentro dos processos da ITIL é o acompanhamento contínuo dos
seus serviços. É importante que a utilização de cada recurso e serviço de disponibilidade ou
capacidade seja monitorado para garantir um uso otimizado dos recursos de hardware e
software, e com isso, os requisitos acordados nos SLAs possam ser alcançados.
Um problema que pode ser enfrentado pela equipe de TI é o controle de todos os itens
acordados em cada SLA firmado com seus clientes. Cada SLA é composto de acordos
internos e externos, e gerenciar os níveis de serviço requer um acompanhamento proativo
para evitar a quebra desses acordos. Uma equipe de TI pode ser posta para acompanhar cada
item para que eles fiquem em um limiar de acordo com os níveis exigidos. Pode ser uma
2 TeamQuest IT Service Analyzer é um exemplo deste tipo de software.
4
tarefa dispendiosa para uma equipe controlar os vários itens operacionais de todos os SLAs
acordados. O tempo investido por esta equipe no acompanhamento dos SLAs pode ser
revertido em acompanhamento da satisfação dos clientes e em planejamentos de alterações na
infra-estrutura para melhorar a prestação dos serviços prestados pela TI.
1.1.2. Solução Proposta
Para que uma empresa fornecedora de serviços de TI possa cumprir os acordos dos contratos
de maneira eficiente e eficaz, pode-se utilizar uma ferramenta para o monitoramento
constante de todos os itens acordados. Com este monitoramento dos itens dos contratos, as
chances de que eles sejam feridos e as empresas percam a sua credibilidade podem ser
reduzidos.
A solução proposta é o desenvolvimento de um protótipo de monitoramento da capacidade de
hardware dos computadores: memória, processador e disco rígido; e do monitoramento da
disponibilidade de hardware e software, ou seja, se um computador está inoperante, se um
determinado processo do sistema operacional não está ativo ou se um software não está mais
em execução. O monitoramento é feito através de agentes instalados em cada máquina
monitorada, e os dados coletados armazenados em uma única base de dados, criando desta
maneira, um histórico dos itens que compõem o SLA. A partir deste ponto o SLA pode ser
monitorado e as alterações sofridas em seus itens podem ser acompanhadas.
Um aplicativo de front-end3 é o responsável pelo cadastramento dos SLAs e seus parâmetros
de disponibilidade e capacidade. A partir destes dados, são montados os indicadores dos itens
de um SLA. Para os indicadores que estiverem ferindo algum SLA são exibidos alertas ao
usuário final através de indicativos na tela, avisos sonoros ou até mesmo envio de mensagem
de correio eletrônico à pessoa responsável. A visualização dos indicadores é feita através de
um Painel de Controle (Dashboard) que contem todos os parâmetros de um SLA específico.
Um Painel de Controle fornece informações instantâneas sobre o desempenho dos negócios
em forma de gráficos, medidores, tabelas e painéis. É uma ferramenta que auxilia nas
tomadas de decisões ao organizar e apresentar as informações de uma maneira fácil de
compreender. Gerentes e executivos que precisam de uma visão geral do negócio utilizam
3 Front-End: parte do sistema de software que interage diretamente com o usuário.
5
Painel de Controle por dispor de uma visualização intuitiva e oportuna dos dados
estratégicos, financeiros e operacionais (MICROSTRATEGY BRASIL, 2007).
O Painel de Controle também pode ser utilizado para auxiliar no gerenciamento dos projetos
de software. Informações como os riscos de um projeto, status atual e previsões das tarefas
que o compõem, podem ser acompanhados através de indicadores visuais e alertas
(TELELOGIC, 2007).
A arquitetura do protótipo é divida em três segmentos. Os primeiros deles, os Agentes, são
pequenos aplicativos de monitoramento de capacidade e disponibilidade. Estes Agentes serão
desprovidos de qualquer inteligência artificial, sendo apenas coletores de informações sobre o
funcionamento do hardware e do software de um determinado computador. De posse dos
dados adquiridos, eles são enviados para uma base de dados específica. Com a base
alimentada, os Painéis de Controle de cada SLA cadastrado podem mostrar a situação atual e
avisar se algo estiver fora do acordado.
1.2. OBJETIVOS
1.2.1. Objetivo Geral
Desenvolver um protótipo para o monitoramento de SLA.
1.2.2. Objetivos Específicos
� Identificar os itens de disponibilidade e capacidade do SLA que serão monitorados; (1)
� Definir as tecnologias necessárias para a modelagem e desenvolvimento de um ambiente
de monitoramento; (2)
� Definir um protocolo de comunicação que seja adequado para suportar o ambiente de
monitoramento; (3)
� Identificar os requisitos funcionais e não-funcionais do sistema; (4)
� Modelar o ambiente de monitoramento; (5)
� Desenvolver um protótipo para o ambiente de monitoramento; e (6)
� Avaliar o protótipo com relação aos requisitos estabelecidos e de acordo com a literatura.
(7)
6
1.3. DELIMITAÇÃO DO ESCOPO
Este trabalho compreende o desenvolvimento de um protótipo para o monitoramento de
SLAs. O seu foco não é o controle do SLA em sua totalidade, portanto, cabe a cada
organização dispor de uma equipe para efetuar o levantamento dos itens a serem
monitorados, através de informações gerenciais levantas, por exemplo, em seu Planejamento
Estratégico, Plano Diretor de Informática e no Plano de Contingência. Uma vez que as
informações de disponibilidade e capacidade sejam levantadas, a equipe responsável pode
utilizar o protótipo de monitoramento proposto para auxiliar no cadastro e acompanhamento
dos itens levantados de disponibilidade e capacidade de um SLA. Portanto, o objetivo da
ferramenta é auxiliar a equipe de gerenciamento de TI na criação e manutenção dos seus
SLAs, depois de realizado um levantamento e mapeamento dos objetivos estratégicos da
organização por parte das mesmas.
O protótipo desenvolvido tem o objetivo de coletar os dados informados, processá-los e
disponibilizá-los em forma de gráficos, para que a equipe de Gerenciamento de Nível de
Serviço possa acompanhar os SLAs produzidos por eles junto aos clientes. Os dados
coletados pelos agentes compreendem os itens de disponibilidade e capacidade da infra-
estrutura de TI com base nos respectivos serviços da ITIL versão dois produzidos pela OGC.
A versão três da ITIL foi lançada em 2007 e não fará parte da fundamentação teórica deste
trabalho, já que a quantidade de material disponível sobre o assunto ainda é relativamente
pequena.
Os itens de disponibilidade coletados pelos agentes estão divididos em dois grupos: a
disponibilidade de um recurso de hardware e de software. Os recursos de hardwares
monitorados têm seu foco voltado somente para computadores com arquitetura IBM-PC e
outros equipamentos que tenham implementado em seu software os protocolos TCP/IP. Os
recursos de softwares monitorados são limitados aos processos dos sistemas operacionais
Linux Ubuntu e Microsoft Windows. Os itens de capacidade coletados pelos agentes são
limitados aos itens dentro de um computador com arquitetura IBM-PC. Os itens são:
memória, processador e disco rígido.
7
1.4. JUSTIFICATIVA
Na última década a interdependência entre os processos do negócio e as operações de TI
chegou a um ponto em que, se a TI parar, os negócios param. A disponibilidade de uma TI
pode influenciar diretamente na satisfação do cliente e na reputação dos negócios. Este é o
motivo pelo qual o Gerenciamento de Disponibilidade é importante para garantir a entrega
dos serviços (OGC, 2003).
Em paralelo, tem-se o Gerenciamento de Capacidade, que é uma função das operações de TI
que fornece orientações sobre a forma de planejar, justificar, e gerenciar níveis adequados de
recursos necessários para uma determinada solução. Um planejamento impróprio da
capacidade pode levar a um desperdício de recursos, resultando em custos desnecessários,
falta de recursos, mau desempenho ou/e a indisponibilidade de um serviço TI (MICROSOFT
SMF, 2002).
O Gerenciamento de Nível de Serviço permite que o departamento de TI satisfaça as
expectativas empresariais e abre uma janela para confirmar essas expectativas. Por exemplo,
um departamento de TI pode querer prestar um serviço a 100%, 99,999%, ou mesmo a 70%
de disponibilidade, mas pode não ser capaz de explicar como é que chegou a este número. A
menos que essa expectativa seja documentada e acordada previamente em um SLA, o
departamento de TI pode focar em serviços não críticos, por exemplo, os recursos humanos,
investir em hardware, software e outros empreendimentos de alto custo, sem um beneficio
real para o negócio (TURNER, et al., 2002).
O trabalho de controlar os SLAs pode ser realizado por uma equipe, responsável por analisar
cada item acordado em cada SLA feitos com seus clientes. Este controle envolve um trabalho
de pro atividade pela equipe de TI, no sentido de não permitir que os níveis de serviços
acordados sejam feridos. Este trabalho poderia ser otimizado ao utilizar um recurso
computacional que ajudasse nesta tarefa de antecipação de problemas. Através de uma
ferramenta de monitoramento, a equipe de TI pode ficar mais focada no relacionamento com
o cliente e no trabalho de ajuste da infra-estrutura de TI, do que no controle em si dos itens
acordados em um SLA. Com isso, o monitoramento dos itens é feitos por um software que
pode lidar com inúmeros itens acordados, centralizando desta maneira o gerenciamento do
SLA em um único ponto de controle.
8
1.5. METODOLOGIA
Existem duas formas clássicas de classificação de pesquisas quanto à sua natureza, a pesquisa
básica, que objetiva criar novos conhecimentos para a ciência e a pesquisa aplicada que
objetiva criar conhecimentos para a aplicação prática e dirigidos a solucionar problemas
específicos geralmente de interesse local. De acordo com essa classificação, este trabalho é
de natureza aplicada, uma vez que será desenvolvido um protótipo para o monitoramento de
SLAs (SILVA, et al., 2001).
O trabalho de pesquisa ainda pode ser abordado de maneira Quantitativa ou Qualitativa. A
abordagem Quantitativa foca a quantificação de dados, opiniões, informações, o emprego de
recursos e técnicas estatísticas. A abordagem Qualitativa visa uma série de leituras sobre o
assunto da pesquisa e uma descrição minuciosa sobre o que diferentes autores e especialistas
escrevem sobre o assunto visando o estabelecimento de uma correlação entre eles gerando
assim um ponto de vista conclusivo (OLIVEIRA, 2001). Considerando a forma de
abordagem do problema deste trabalho, será adotada a pesquisa Qualitativa, devido à revisão
bibliográfica sobre o assunto a ser tratado.
A pesquisa pode ser classificada de acordo com o objetivo, sendo elas, a Pesquisa
Exploratória, Pesquisa Descritiva e a Pesquisa Explicativa (ANDRADE, 1999). Este trabalho
tem característica de uma Pesquisa com objetivo Exploratório, pois tem a finalidade de
proporcionar maiores informações sobre determinado assunto, a delimitação de um tema e a
definição de objetivos visando o descobrimento de um novo tipo de enfoque sobre
determinado assunto.
A pesquisa pode ainda apresentar os procedimentos técnicos, do tipo Bibliográfico,
Documental, Experimental, Ex-Post Facto, Estudo de Coorte, Levantamento, Estudo de
Campo, Estudo de Caso, Pesquisa-Ação e Pesquisa Participante (GIL, 2002). O trabalho
usará a Pesquisa Bibliográfica e Pesquisa-Ação. A Pesquisa Bibliográfica devido à
elaboração deste trabalho usando livros, artigos, periódicos e materiais disponibilizados na
internet. A Pesquisa-Ação será utilizada devido ao desenvolvedor e os investigados estarem
envolvidos de modo cooperativo para a solução de um problema através de uma ou mais
ações.
9
1.6. ESTRUTURA DO TRABALHO
O trabalho está organizado em 5 capítulos correlacionados, iniciando com esta introdução
sobre o tema proposto onde foi apresentado o tema a ser abordado neste trabalho por meio de
sua contextualização. Da mesma forma, foram estabelecidos os resultados esperados por
meio da definição de seus objetivos e apresentadas às limitações do trabalho permitindo uma
visão clara do escopo proposto.
O Capítulo II apresenta uma visão geral sobre a ITIL, além de uma visão mais detalhada
sobre o Gerenciamento de Nível de Serviço, Gerenciamento de Capacidade e Gerenciamento
de Disponibilidade pertencente ao Serviço de Entrega da ITIL. Esta conceituação tem como
objetivo estabelecer uma referência sobre o processo de criação de um SLA, incluindo as
atividades de monitoramento e revisão dos itens acordados entre o cliente e o provedor de
serviços de TI. Estes conceitos são utilizados para subsidiar o entendimento das práticas da
ITIL para o desenvolvimento de um protótipo de monitoramento dos itens acordados.
No Capítulo III é apresentada uma visão geral da solução proposta, bem como sua
modelagem através do uso dos conceitos da UML. Serão apresentados os requisitos
funcionais e não funcionais da solução proposta, seus casos de uso, protótipos de telas e
demais diagramas da UML.
No Capítulo IV é apresentado o projeto e as ferramentas utilizadas no desenvolvimento do
protótipo. Além disso, são relatados os testes efetuados de acordo com os requisitos
levantados no capítulo anterior. No final, é apresentada a avaliação do protótipo por um
profissional da área através da realização de um questionário sobre os gerenciamentos da
ITIL envolvidos neste projeto.
O Capítulo V contém as considerações finais do TCC, mostrando como os objetivos foram
alcançados, as dificuldades encontradas durante a realização deste trabalho, as metodologias
empregadas, as soluções utilizadas, ferramentas e técnicas aplicadas.
2. FUNDAMENTAÇÃO TEÓRICA
Este capítulo apresenta a base teórica de referência utilizada para o levantamento dos
requisitos e da elaboração da modelagem deste Trabalho de Conclusão de Curso. Como a
proposta constitui no desenvolvimento de um protótipo para apoio no monitoramento dos
SLAs com base na entrega de serviços da ITIL, este tema requer a busca de fundamentação
teórica em suas práticas. Este capítulo tem seu início na Seção 2.1, que faz uma apresentação
geral do que é a ITIL e de seus serviços. A Seção 2.2 apresenta o serviço de Gerenciamento
de Nível de Serviço, mostrando os itens de um SLA, como estes devem ser criados e
monitorados. A Seção 2.3 descreve o serviço de Gerenciamento de Disponibilidade,
mostrando a sua importância e os conceitos de disponibilidade. A Seção 2.4 apresenta o
serviço de Gerenciamento de Capacidade, descrevendo os objetivos e benefícios de se
monitorar a capacidade de uma infra-estrutura de TI. Este capítulo é concluído com a Seção
2.5, que apresenta as considerações a respeito dos temas abordados.
2.1. VISÃO GERAL DA ITIL
2.1.1. História
A ITIL foi desenvolvida originalmente para o setor público do Reino Unido na década de 80,
através da CCTA (British Central Computer and Telecommunication Agency), atualmente
denominada OGC (Office of Government Commerce) - que é a responsável por sua evolução
e divulgação, em conformidade com a norma ISO/IEC 20000 (International Standards
Organization/International Electrotechnical Commission). O objetivo inicial do governo
britânico era disciplinar e comparar as propostas dos prestadores de serviços de TI e controlar
as suas contratações, já que elas envolviam todos os setores do governo. Com isso, pretendia-
se criar padrões de atendimento dos processos, terminologia, desempenho, qualidade e custo.
Como a ITIL era um padrão aberto, várias instituições européias não governamentais
adotaram a ITIL motivados pela qualidade que ela proporcionava, além de facilitar o caminho
para obter a ISO 9000 e a EFQM (European Foundation for Quality Management). Em
seguida, os padrões da ITIL foram absorvidos pelo mercado norte-americano e atualmente
está sendo utilizado por organizações dos setores públicos e privados de vários países
(MAGALHÃES, et al., 2007).
11
2.1.2. Estrutura
A ITIL é constituída de um conjunto de boas práticas para o gerenciamento dos serviços de
TI, objetivando o uso eficaz e eficiente da sua infra-estrutura. Essas práticas podem servir
como referência, tanto para organizações que já possuem operações de TI e pretendem adotar
melhorias em seus processos operacionais e gerencias, quanto para aquelas que pretendem
criar novas operações. A utilização de forma adequada das práticas da ITIL objetiva o melhor
atendimento das necessidades dos clientes e de seus usuários. As suas publicações são
relacionadas com os aspectos considerados mais importantes no âmbito do gerenciamento de
serviços de TI. Esses aspectos têm relação entre si para que integrem as necessidades de
negócio com a infra-estrutura através de serviços, conforme a Figura 1. Como os serviços da
ITIL são projetados para a realidade da organização, o que é bom para um negócio, pode não
ser bom para outro (FERNANDES, et al., 2006).
Figura 1. Estrutura das principais publicações da segunda versão da ITIL Fonte: Pinheiro (2007)
A tarefa de atualizar e divulgar a ITIL ao redor do mundo é feita pela itSMF (Information
Technology Service Management Forum), que é um fórum internacional independente e
atuante em mais de 32 países, através de usuários, fornecedores, universidades e organizações
privadas e públicas. A primeira versão da ITIL foi denominada GITIM (Government
Information Technology Infrastructure Management) e desde então ela sofreu várias revisões,
de modo a acompanhar a evolução do mercado e da indústria das novas tecnologias. A partir
de 1999, surgiu a segunda versão da ITIL, composta por dez publicações: Introdução à ITIL,
Suporte aos Serviços, Entrega de Serviços, Planejando a Implementação da Gerenciamento
de Serviços, Gerenciamento de Segurança, Perspectivas de Negócio, Gerenciamento da Infra-
12
Estrutura TIC (Tecnologia de Informação e Comunicações), Gerenciamento de Aplicações,
Gerenciamento de Recursos de Software e Implementação em Pequena Escala. Esta versão é
atualmente aceita globalmente como uma estrutura de boas práticas para a Gerenciamento de
serviços de TI. No começo de 2007 a OGC publicou a terceira versão da ITIL, desta vez
composta por cinco publicações que incorporam as melhores práticas das versões anteriores,
são elas: Estratégias de Serviços, Desenho de Serviços, Transição de Serviços, Operação de
Serviços e Melhoria Contínua de Serviços. Por ser uma versão recente e com pouco material
disponível, o enfoque deste TCC estará voltado para a versão dois (OGC, 2003).
2.1.3. Visão Geral da ITIL Versão Dois
A ITIL pressupõe que os serviços de TI oferecidos a um cliente dependem de um processo
operacional gerenciado por um conjunto de processos de gerenciamento. Esses processos
estão separados em duas principais publicações dentro da ITIL conforme a Figura 2, que são
o Suporte aos Serviços e a Entrega de Serviços, comumente chamados de Gerenciamento
de Serviços ITIL. O primeiro é mais voltado para a parte operacional, que objetiva assegurar
o acesso dos usuários aos serviços que suportam as funções de negócio. O segundo abrange
os processos táticos do negócio, para assegurar qualidade da entrega dos serviços prestados.
As demais publicações da ITIL descrevem práticas adjacentes às práticas abordadas
anteriormente, algumas delas são (FERNANDES, et al., 2006):
� Planejando a Implementação da Gerenciamento de Serviços: descreve as etapas
necessárias para implementar ou melhorar o fornecimento de serviços de TI, fornecendo
orientações de forma prática para alinhar as necessidades de negócio à tecnologia e
também para avaliar se elas estão sendo atendidas pelos serviços;
� Gerenciamento da Infra-Estrutura TIC: descreve os aspectos de gerenciamento da TIC
identificando os requisitos de negócio, instalação, implantação, suporte técnico, testes e a
manutenção contínua dos componentes e serviços;
� Gerenciamento de Aplicações: abrange o ciclo de vida completo dos softwares
relacionados à implementação de serviços de TI, além das atividades de desenvolvimento
e de gerenciamento de serviços;
� Gerenciamento de Segurança: aborda os processos relacionados à confidencialidade,
disponibilidades de dados e sua integridade, além da segurança de componentes de
hardware e software, e de documentos; e
13
� Perspectivas de Negócio: visa facilitar a comunicação entre a área técnica e a área de
negócios, tratando de assuntos como continuidade de negócio, parcerias e outsourcing4.
Figura 2. Posicionamento dos Processos da ITIL Fonte: Magalhães e Pinheiro (2007)
2.1.4. Gerenciamento de Serviços
Os processos e suas atividades necessitam identificar todos os setores da área de TI aos quais
eles participam e quem são os responsáveis por sua coordenação. Desta maneira, é possível
trabalhar de modo mais eficaz e eficiente ao definir quais são as atividades do processo, que
entradas são necessárias e quais os resultados obtidos. Além disso, conduzir e medir essas
atividades aumenta a eficácia e incluindo modelos ao processo, é possível adotar medidas de
qualidade ao resultado. A soma destes fatores pode garantir a obtenção da melhor relação
custo/benefício para a organização. Os processos de gerenciamento de serviços de TI da ITIL
são a sua essência e são separados em duas publicações fundamentais: Suporte aos Serviços
e a Entrega de Serviços (MAGALHÃES, et al., 2007).
Os processos de Entrega de Serviços preocupam-se com a qualidade dos serviços prestados
pela área de TI ao cliente, e está organizado em cinco processos apresentados na Figura 3
(FERNANDES, et al., 2006):
� Gerenciamento do Nível de Serviço: seu objetivo é manter e melhorar a qualidade dos
serviços de TI através de planejamento, coordenação, elaboração, metas de desempenho e
4 Em português este termo significa terceirização, ou seja, é o repasse de uma atividade meio a terceiros.
Atividade meio é aquela que se presta a dar condições que uma empresa atinja seus objetivos sociais
14
responsabilidades mútuas, monitoramento de SLAs, de OLAs (Operating Level
Agreement) e de UCs (Underpinning Contract) com fornecedores de serviços externos;
� Gerenciamento de Disponibilidade: visa garantir que os serviços sejam projetados para
atender e resguardar a confiabilidade do negócio, minimizando os riscos de interrupção,
fazendo o uso de atividades de monitoramento físico, solução de incidentes5 e melhoria
contínua da infra-estrutura e da organização de suporte;
� Gerenciamento de Capacidade: assegura que a capacidade da TI acompanhe as
demandas evolutivas do negócio de forma eficaz e dentro do custo previsto, otimizando a
infra-estrutura necessária à prestação de serviços de TI;
� Gerenciamento da Continuidade dos Serviços de TI: seu objetivo é assegurar que os
recursos técnicos e os serviços possam ser recuperados dentro de prazo estabelecido
previamente; e
� Gerenciamento Financeiro para Serviços de TI: provê a sustentação econômica de um
serviço através de atividades orçamentárias, contábeis e de cobrança.
Figura 3. Processos da Entrega de Serviços Fonte: Fernandes e Abreu (2006)
Dentro do Suporte aos Serviços, os processos concentram-se em tarefas que são executadas
diariamente e que são necessárias para a manutenção dos serviços de TI já entregues e em
utilização pela organização. O Suporte aos Serviços é organizado em cinco processos
(MACFARLANE, et al., 2005):
5 Qualquer evento que não faz parte das operações padrões de um serviço de TI e que causa, ou pode causar,
uma interrupção, ou redução na qualidade deste serviço. Fonte: OGC (2003)
15
� Gerenciamento de Incidentes: seu objetivo é restabelecer a operação normal do serviço
o mais rápido possível e que cause o mínimo de transtorno ao negócio, assegurando a
manutenção dos níveis de disponibilidade e serviços pretendidos;
� Gerenciamento de Problemas: sua função é minimizar o impacto adverso de problemas
no negócio causados por erros e incidentes na parte de infra-estrutura e também evitar
proativamente que eles aconteçam;
� Gerenciamento da Configuração: fornece um modelo lógico da infra-estrutura de TI
por meio da identificação, controle, manutenção e verificação das versões de todos os
itens de configuração existentes;
� Gerenciamento de Mudanças: assegura que os métodos e procedimentos padronizados
sejam utilizados para um tratamento eficiente e rápido de todas as mudanças, eliminado
assim os impactos sobre os serviços; e
� Gerenciamento de Liberações: seu objetivo é ter uma visão total de uma mudança em um
serviço de TI e garantir que todos os aspectos técnicos ou não, de uma liberação, sejam
considerados em conjunto.
2.1.5. Relacionamento dos Processos de Gerenciamento de Serviços
Os processos da ITIL possuem um relacionamento de interdependência e atuam em conjunto
na resolução de eventos dentro de um ciclo de vida de um serviço de TI. Um exemplo pode
ser utilizado para ilustrar esses relacionamentos (FERNANDES, et al., 2006):
� Um usuário chama a central de serviços para efetuar uma reclamação da demora ao abrir
sua intranet;
� O processo de Gerenciamento de Incidentes classifica o chamado e o armazena;
� Se for uma falha conhecida, o processo de Gerenciamento de Problemas analisa as
causas e aciona o processo de Gerenciamento da Capacidade para auxiliar nas análises
mais detalhadas, já que o processo de Gerenciamento de Nível de Serviço alertou que
alguns indicadores ficaram abaixo do estabelecido;
� O Processo de Gerenciamento de Mudanças abre e direciona uma requisição de
mudança;
� O Gerenciamento Financeiro para Serviços de TI desenvolve um orçamento
informando o custo da atualização de hardware e software solicitados;
16
� O processo de Gerenciamento da Continuidade dos Serviços de TI e processo de
Gerenciamento de Mudanças asseguram que é possível recuperar a configuração a
partir da cópia de segurança existente e que o impacto da mudança não será significativo;
� O processo de Gerenciamento de Liberações informa ao processo de Gerenciamento
da Configuração os detalhes das novas liberações e das versões envolvidas, além de
controlar a implementação da mudança;
� O Gerenciamento da Disponibilidade verifica se as alterações da infra-estrutura de TI
atendam os níveis de disponibilidade e confiabilidades acordados; e
� O Gerenciamento da Configuração mantém seu banco de dados atualizado durante toda
a operação.
2.2. GERENCIAMENTO DE NÍVEL DE SERVIÇO
O objetivo do serviço de Gerenciamento de Nível de Serviço da ITIL é prover uma melhoria
contínua dos serviços de TI e de sua manutenção, para que estes serviços estejam alinhados
aos negócios da organização através de um ciclo contínuo de negociação, monitoramento,
informação e revisão dos serviços de TI (Figura 4). O Gerenciamento de Nível de Serviço
preocupa-se em documentar os objetivos (Service Level Objectives ou SLO6) acordados com
seus clientes através do SLA, além de controlar e revisar os níveis de serviços existentes a um
custo aceitável. O processo de Gerenciamento de Nível de Serviço abrange os dois lados
envolvidos nos acordos (MACFARLANE, et al., 2005):
� O Provedor: pode ser um setor interno de serviços, uma empresa de serviços externa ou
um fornecedor terceirizado; e
� O Receptor: o cliente que solicita os serviços e paga por eles.
Figura 4. Escopo do Gerenciamento de Nível de Serviço Fonte: Adaptado de OGC (2003)
6 SLO é cada objetivo acordado com o cliente que no final irá compor o SLA. Ex.: disponibilidade de um
servidor e capacidade de HD são os objetivos de um SLA. Fonte: OGC (2003)
17
Para implementar um Gerenciamento de Nível de Serviço a organização precisa
primeiramente avaliar quais serviços a área de TI oferece aos clientes da organização e
determinar quais os contratos de serviços existentes estão atualmente em vigor para esses
serviços. Essa avaliação disponibiliza para a área de serviços de TI toda uma gama de
serviços que ela precisa entregar. Com as informações obtidas, a organização pode então
desenvolver e implementar um processo de Gerenciamento de Nível de Serviço. Como este
processo requer um entendimento por parte da organização de TI dos serviços que ela oferece
a sua implementação segue os seguintes passos: criação de um catálogo de serviços,
desenvolvimento de SLAs, monitoramento e relatórios, e revisão dos níveis de serviço. O
SLA é construído de acordo com os requisitos e prioridades dos serviços documentados no
catálogo de serviços, dos requisitos negociados, do monitoramento dos serviços em oposição
aos critérios acordados, e dos relatórios e revisões destas informações para realçar e remover
falhas nos níveis de desempenho do serviço (TURNER, et al., 2002).
2.2.1. Atividades
O processo de Gerenciamento de Nível de Serviço pode ser definido como um ciclo de
qualidade total, conforme a Figura 5, e é composto das seguintes atividades (MAGALHÃES,
et al., 2007):
� Recepção da Demanda: Identificação dos objetivos do negócio e das demais áreas que
fazem uso dos serviços de TI;
� Identificação: quais serviços serão fornecidos no Catálogo de Serviços de TI, que é
composto pelos serviços de TI disponíveis, seus componentes, níveis de desempenho e
custos;
� Definição: após a identificação dos serviços, eles serão atendidos para garantir a
integração entre os diversos acordos e contratos em vigor, além da atual e futura
capacidade de atendimento da infra-estrutura de TI. O resultado desta atividade culmina
em um esboço dos termos a serem negociados com o cliente;
� Negociação: uma vez esboçado os termos de negociação, é negociado com os envolvidos
em cada acordo os termos finais e após a concordância entre as partes o contrato é
assinado;
� Monitoramento: acompanhamento da execução dos processos de suporte dos serviços de
TI, coletando, tratando e analisando os dados para o desenvolvimento de indicadores de
18
desempenho. Esta atividade precisa ser proativa para não deixar ferir nenhum acordo
dentro dos contratos estabelecidos;
� Comunicação: desenvolvimento de relatórios abordando o desempenho dos serviços
prestados, além de reuniões para discussão dos resultados alcançados; e
� Revisão: é formada pelas reuniões e programas de melhoria dos indicadores através da
revisão dos indicadores e metas estabelecidas nos SLAs.
Figura 5. Atividades do Gerenciamento de Nível de Serviço Fonte: Adaptado de Magalhães e Pinheiro (2007)
2.2.2. Catálogo de Serviços
Um serviço pode ser definido como uma ação efetuada por uma pessoa ou por uma máquina,
e é caracterizado como intangível, e seu consumo ocorre paralelamente à sua produção,
também não pode ser armazenado e é difícil ser produzido ou atendido em larga escala. Um
serviço de TI é formado por um conjunto de serviços distintos, tais como suporte ao usuário
ou de infra-estrutura e pode ser definido como um ou mais sistemas de TI que ativam um
processo de negócio. Para definir um serviço, então, é necessário que o cliente responda quais
serviços são necessários a ele e partir destes dados, um Catálogo de Serviços de TI pode ser
montado pela área de TI. Um serviço possui um ciclo de vida que é iniciado a partir de um
requisito da área de negócios. Este ciclo pode ser dividido nas seguintes fases
(MAGALHÃES, et al., 2007):
� Provisionamento: define serviços, políticas e SLAs;
� Ativação: aloca, configura e implementa;
19
� Operação, Gerenciamento e Garantia: mede e reporta os indicadores do SLA, garante a
disponibilidade e o desempenho, resolve problemas, gerencia mudanças e planeja
capacidade;
� Utilização, Contabilização e Cobrança: revisa e renegocia contratos; e
� Manutenção: modifica políticas, SLAs, define serviços e capacidade.
Nas últimas décadas a infra-estrutura de TI das organizações vêm crescendo e se
desenvolvendo, e pode não haver uma idéia clara de todos os serviços prestados aos seus
clientes. Para que uma imagem exata dos serviços prestados possa ser estabelecida,
recomenda-se a criação de um Catálogo de Serviços de TI. Nele estão listados todos os
serviços oferecidos, um resumo das suas características e detalhes de cada cliente. Um certo
trabalho deve ser despendido na confecção desta lista junto ao cliente: separar documentos
relevantes, procurar bibliotecas de programas, conversar com funcionários da TI e clientes,
procurar registros públicos e conversar com fornecedores. Se já existe na organização um
processo de Gerenciamento de Configuração, o CMDB7 (Configuration Management
Database) pode ser uma valiosa fonte de informações (OGC, 2003).
Um Catálogo de Serviços visa garantir o sucesso do Gerenciamento de Nível de Serviço,
através do cadastro de todos os serviços em uso dentro da organização. Um catálogo possui:
Serviços (em termos de negócios), componentes de TI usados na entrega dos serviços, a
prioridade dos serviços para os usuários do negócio, acordos de fornecimento e manutenção
pertencentes ao serviço de TI e contratos de suporte. As informações contidas no catálogo
devem ser gerenciáveis, realísticas e, além disso, SLAs devem ser estabelecidos para
monitorar, reportar e rever esses serviços (TURNER, et al., 2002).
2.2.3. SLA
Uma vez que o Catálogo de Serviços seja criado, os serviços listados nele podem ser
priorizados de acordo com sua importância para o negócio. A importância de um serviço
precisa ser balanceada como o custo de fornecimento do serviço. A negociação do custo
versus o benefício de cada serviço produzirá um conjunto de requisitos do cliente para os
serviços prestados. Estes requisitos são objetivos mensuráveis entre a TI e um ou mais de 7 Configuration Management Database: é um banco de dados gerenciado pelo serviço de Gerenciamento de Configuração, que contêm todos os detalhes dos itens de configuração de uma infra-estrutura de TI e o relacionamento entre eles. Fonte: OGC (2003)
20
seus clientes. Por exemplo, a TI pode querer entregar 99,9% de disponibilidade de serviço
para um negócio ou fornecer um tempo de resposta ao cliente em 15 minutos, e assim por
diante. Estes parâmetros mensuráveis estão documentados em um SLA (TURNER, et al.,
2002).
O SLA é um acordo escrito entre um provedor de serviço de TI e um cliente de TI conforme
a Figura 6, que define os serviços chave e as responsabilidades entre as partes envolvidas.
Um SLA não deve ser usado para tornar um cliente “refém” de seu provedor de serviços, e
sim formar uma parceria para que um acordo mutuamente benéfico seja alcançado, caso
contrário, o SLA pode cair em descrédito, evitando qualquer melhoramento na qualidade dos
serviços prestados (OGC, 2003).
Figura 6. Relacionamento entre clientes e os níveis de serviços Fonte: Adaptado de OGC (2003)
O SLA é o principal fator de sucesso do Gerenciamento de Nível de Serviço. Assim como o
ponto de referência para o desenvolvimento de um novo serviço é o contrato entre o
desenvolvedor e o cliente, o SLA é o ponto de referência para todas as tomadas de decisões e
atividades relacionadas ao serviço durante seu ciclo de vida. Ele define os contratos em
andamento entre o provedor de serviços e o cliente, e para isso, precisa ser transparente,
honesto, realístico e mensurável. Como um contrato negociado entre o provedor de serviço de
TI, e um cliente, o SLA define os limites do serviço, o nível do serviço, o relacionamento do
serviço com os objetivos da organização, sua disponibilidade, as responsabilidades do
21
provedor e do cliente, procedimentos de mudança e referenciais para medições. Como
qualquer contrato, a pessoa responsável pelo serviço deve definir quais são as suas
necessidades e disponibilizar os recursos para a criação, customização, e alteração do serviço
durante seu ciclo de vida. Do outro lado, o provedor de serviços deve avaliar a viabilidade e
os custos reais para alcançar seus requisitos. Para este tipo de contrato, a ITIL distingue ente
clientes e usuários. Clientes são os responsáveis na organização pelo pagamento dos
serviços de TI. Usuários são as pessoas que usam o serviço no dia-a-dia. O provedor do
serviço é responsável pela negociação dos termos de serviço junto ao cliente, coordenando os
requisitos dos usuários e gerenciando as suas expectativas (Reinvesting the IT Dollar: From
Fire Fighting to Strategic Services, 2001).
2.2.4. Tipos de SLA
O sucesso de um SLA pode ser o resultado de muitas horas de negociação, mas o relatório
final pode ser um único documento que oferece uma simples representação da complexidade
do serviço e da arquitetura dos componentes. Existem diferentes tipos de SLAs (Figura 7:
Estrutura de suporte de um SLA.), apesar do processo básico de criação e conteúdo ser o
mesmo. São eles (TURNER, et al., 2002):
� SLA Interno: é mais comum entre um departamento de TI e o departamento de negócios
e raramente têm conseqüências legais. Ele descreve o relacionamento, as expectativas e
os tempos de entrega dos serviços. Todo esforço deve ser feito para cumprir os níveis de
serviços documentados e assinados. As partes internas são responsáveis por aquilo que
fazem e por aquilo que não cumprem. Pode haver repercussões dentro da organização
quando um serviço acordado não é cumprido, apesar de não ser um contrato jurídico;
� SLA Externo: é mais formal do que o SLA interno. Os SLAs externos podem ser mais
estruturados do que o interno porque eles normalmente incluem despesas, bônus e
cláusulas penais. Para SLAs legais, eles devem ser assessorados por um profissional
jurídico interno ou externo. Os assuntos jurídicos são diferentes entre as organizações e
países, e SLAs não devem ser assumidos sem a confirmação das implicações jurídicas no
contrato. Isso inclui descrições de rescisão, bônus, penalidades e custos.
� Acordos de Nível Operacional ou OLA: é um SLA interno para atender as necessidades
operacionais e é invisível ao cliente ou usuário (A Tabela 1 apresenta as diferença entre
um OLA e um SLA). Um OLA raramente é legal, mas ajuda a área de TI a conhecer os
22
requisitos internos. Para uma OLA bem sucedida, os grupos de TI devem estar
conscientes e alinhados com os objetivos da organização. Isso pode resultar em boa
disponibilidade ou segurança dos dados, por exemplo, para o cliente; e
� Contratos de Apoio ou UC: contrato com um fornecedor externo para apoiar o SLA.
Pode prejudicar os SLAs se os requisitos do nível de serviço não são sincronizados uns
com os outros. Por exemplo, um SLA com tempo de resposta acordado para oito horas
quando houver uma indisponibilidade da telefonia, significa que o contrato em vigor com
um fornecedor externo de telefonia precisaria ser inferior a oito horas para que os
requisitos do SLA possam ser atingidos, já que ele depende diretamente do atendimento
deste fornecedor. Um novo contrato pode ser negociado em conformidade com um SLA
que está sendo acordado com a organização. No entanto, isto pode incidir em custo e deve
ser cuidadosamente considerado de acordo com os requisitos do SLA antes de ser
assinado.
Figura 7: Estrutura de suporte de um SLA. Fonte: OGC (2003)
Dentro de um SLA existem duas partes principais (MAGALHÃES, et al., 2007):
� Instrumento: é a relação legal entre um cliente e um prestador de serviços, que descreve
os serviços e os níveis de serviço com detalhes; e
23
� Processo: descreve os métodos utilizados pelo fornecedor para o suporte ao instrumento
do SLA. Eles precisam ser discutidos e definidos durante o acordo do instrumento, e cada
parte envolvida precisa estar ciente de todo o processo dos métodos que eles utilizarão.
Tabela 1: Diferenças entre o SLA e o OLA SLA OLA Descreve o serviço, termos e condições para o acordo entre TI e um ou mais clientes
Descreve os, requisitos e condições exigidas de um prestador de serviços internos de TI
Define a duração do SLA com um início e data de término
É revista freqüentemente para capturar mudanças diárias no serviço de entrega
Incide sobre as empresas e clientes É focada na TI interna Descreve as métricas específicas da empresa enviadas pela TI e à freqüência que são relatadas
Descreve as métricas dos componentes de serviço e a freqüência que eles são medidos pelo prestador de serviços internos
Descreve papéis e responsabilidades para o cliente e a TI
Descreve papéis e responsabilidades para a equipe de TI
Descreve as ligações entre a TI e os negócios do cliente
Descreve os vínculos diários entre a TI e os prestadores de serviços e clientes
Fonte: Adaptado de Turner, Dyer e Hunter (2002)
Um SLA se tornará aplicável após a definição da equipe que controlará o sistema e as suas
tecnologias. É desejável que esta equipe ofereça um ambiente para o suporte do
monitoramento, da notificação, do escalonamento e dos indicadores de nível de serviço. Os
SLAs podem ser classificados entre (MAGALHÃES, et al., 2007):
� Básico: quando somente um SLA está definido e em operação. Os dados dos indicadores
são estabelecidos e medidos manualmente para a geração do SLR (Service Level Report)
ou Relatório de Nível de Serviço. O objetivo de um SLA básico é geralmente justificar o
suporte técnico aos serviços prestados;
� Intermediário: os dados dos indicadores são coletados automaticamente, e existem mais
de um SLA em operação ao mesmo tempo. Também é utilizada a operação de
recuperação de custo, que relaciona os serviços que foram alcançados com os resultados
em termos de receita. SLA com vários níveis são criados, o que permite o aumento dos
níveis de serviço a um custo menor a longo prazo; e
� Avançado: os SLAs são parte do processo geral da organização, o que permite a alocação
dinâmica dos recursos internos e externos com o objetivo de melhorar a prestação dos
serviços de acordo com as mudanças do negócio.
24
2.2.5. Estrutura de um SLA
O conteúdo específico e as metas iniciais precisam ser incluídas dentro do SLA e acordadas.
Cada situação é única e o conteúdo varia de acordo com o tipo de SLA, mas existem várias
características em comum dentro de um SLA, tais como (OGC, 2003):
� Introdução:
� Partes envolvidas;
� Título e uma breve descrição do acordo;
� Assinaturas;
� Datas de início, fim e revisão;
� Escopo do acordo, o que é coberto e o que é excluído;
� Responsabilidades do provedor de serviço e do cliente; e
� Uma descrição dos serviços cobertos.
� Horas de Serviço:
� As horas requeridas para cada serviço (Ex.: 24x7, Segunda a Sexta das 09:00-18:00
Horas, etc.);
� Requisição de extensão de serviço;
� Horas especiais (Ex.: feriados); e
� Serviços agendados.
� Disponibilidade:
� Metas de disponibilidade dentro das horas acordadas, expressada normalmente em
porcentagem. Métricas e métodos devem ser estipulados;
� Podem ser expressos para todos os serviços, serviços de apoio·e/ou componentes
críticos; e
� Recomenda-se medir a indisponibilidade do serviço em termos de incapacidade do
cliente em prosseguir com as atividades do negócio. Por exemplo, as vendas são
afetadas imediatamente pela falha da TI em prover um serviço de suporte inadequado.
� Confiabilidade8: Geralmente expressa como a Média de Tempo Entre Falhas (MTBF ou
Mean Time Between Failure) ou a Média de Tempo Entre Incidentes do Sistema (MTBSI
ou Mean Time Between System Incidents).
� Suporte:
8 Este assunto será visto com mais detalhes na seção 2.3.4
25
� Horas de suporte (não podem ser confundidas com horas de serviços);
� Requisição de extensão de serviço;
� Horas especiais (Ex.: feriados);
� Metas de tempo de resposta para incidentes (tanto fisicamente quanto por outros
métodos como telefone, por exemplo); e
� Metas de tempo para resolver o incidente (respeitando a prioridade de cada incidente).
� Taxa de Transferência: Indicação da estimativa de volume de tráfego e atividades de
transferência (Ex.: número de transações processadas, número de usuários concorrentes,
quantidade de dados transmitidos pela rede). É importante a identificação dos problemas
de desempenho causados por excessivas taxas de erros fora dos padrões acordados.
� Tempo de Resposta da Transação: Metas de tempo de resposta médio ou máximo
(algumas vezes expressa como porcentagem – Ex.: 91% dentro de 2 segundos).
� Mudanças: Metas para a aprovação, manipulação e implementação de requisições de
mudança, geralmente baseadas na categoria ou urgência da mudança.
� Continuidade do Serviço de TI e Segurança:
� Uma breve menção dos Planos de Continuidade dos Serviços de TI e como invocá-
los, para cobrir qualquer problema de segurança do cliente (Ex.: cópias de segurança e
senhas);
� Detalhes de qualquer redução ou alteração nas metas de serviços caso alguma situação
adversa ocorra (se não existirem SLAs separados para cada situação).
� Custos: Detalhes de fórmulas de custos.
� Relatório de Serviço e Revisões: O conteúdo, freqüência e distribuição dos relatórios de
serviço, e a freqüência das reuniões de revisão. e
� Penalidades e Incentivos de Desempenho: Detalhes de qualquer acordo sobre incentivos
ou penalidades, baseadas na superação das metas estabelecidas para os níveis de serviços.
Os tópicos apresentados anteriormente são características básicas e provém um ponto de
partida para a criação de SLAs de acordo com a realidade de cada organização.
2.2.6. Monitorando o SLA
Quando os SLAs são acordados, o próximo passo dentro do Gerenciamento de Nível de
Serviço é o monitoramento do desempenho dos serviços de acordo com os critérios
especificados nos objetivos. Existem vários métodos de monitoramento de um SLA, mas o
26
ponto principal é se o desempenho de qualquer um dos critérios infringe ou está perto de
infringir o SLA. O bom desempenho de um monitoramento está em prevenir a ocorrência de
infrações ao introduzir ações específicas e definidas quando um SLA apresenta um risco. Se
uma ação fere o SLA, a função de monitoramento pode reportar isto através de relatórios ou
indicadores em tempo real (TURNER, et al., 2002).
Recomenda-se que nada deve ser incluído em um SLA a menos que possa ser monitorado e
medido. A inclusão de itens que não podem ser efetivamente monitorados quase sempre
resulta na eventual perda de confiança do Gerenciamento de Nível de Serviço. É importante
que o monitoramento esteja sintonizado com a real percepção do cliente do serviço e este
precisa estar atento no relato imediato dos incidentes ocorridos para ajudar no diagnóstico do
problema. Existem alguns problemas importantes que não podem ser monitorados por meios
mecânicos, tais como a satisfação do cliente. Por exemplo, mesmo quando existirem um certo
número de falhas nos serviços, os clientes ainda assim podem se sentir satisfeitos, porque
providências são tomadas para resolver os problemas. O oposto também ocorre, os clientes
podem estar insatisfeitos quando os acordos do SLA forem feridos. Recomenda-se que
algumas medidas sejam feitas para monitorar a percepção do cliente, tais como: contatos
telefônicos, questionários periódicos e reuniões de grupo (OGC, 2003).
Uma das tarefas do Gerenciamento de Nível de Serviço é observar nos sistemas disponíveis
para o monitoramento metas mensuráveis dentro do SLA, tais como segurança, desempenho
e disponibilidade, e se elas estão de acordo com a tecnologia utilizada para prover os
serviços. Após a definição destes critérios, recomenda-se definir limiares de alerta nos
monitoramentos. Os limiares estão relacionados com as métricas de desempenho de acordo
com o SLA e são definidas no nível correto para maximizar o desempenho e permitir que o
serviço atenda ou supere o SLA, se possível. Por exemplo, se a disponibilidade de um
servidor for de 98% para atender os critérios definidos nos objetivos, então configurar o
limiar para 98% não adicionaria nenhum valor à prestação do serviço. O resultado seria um
alerta somente quando o acordado no SLA já estivesse sido ferido. A questão é tentar garantir
que limiares e alertas sejam criados nos pontos onde as ações possam ser remediadas. No
caso, o limiar para o exemplo seria um alerta quando a disponibilidade atingisse um valor de
90% (TURNER, et al., 2002).
27
2.2.7. Relatórios e Revisões
Cada processo dentro da área de TI é acompanhado pela equipe de Gerenciamento de
Serviços e, portanto, recomenda-se a definição e criação de relatórios de Gerenciamento de
atividades desenvolvidas. Através desses relatórios é possível efetuar o suporte às atividades
de monitoramento, auditorias de atendimento e planejamento dos serviços (MAGALHÃES,
et al., 2007). Os relatórios incorporam detalhes de desempenho acordados nos SLAs e
também de cada ação realizada para melhorar a qualidade do serviço. Recomenda-se que
relatórios periódicos sejam produzidos e enviados aos clientes para que qualquer dúvida ou
desacordos possam ser resolvidos em reuniões de revisão de SLAs (OGC, 2003).
As reuniões de revisão de SLAs são uma oportunidade que a área de negócios e de TI têm
para avaliar o desempenho dos objetivos, revisar as operações, os relatórios, qualquer
problema nos serviços, futuras expectativas e outros tópicos relacionados aos serviços
prestados. É importante que os objetivos sejam cuidadosamente avaliados para garantir que
estejam de acordo com as estratégias a longo prazo da organização. O ponto chave para o
sucesso nas reuniões de revisão, é que ela seja vista como uma oportunidade de melhorar a
entrega dos serviços para ambos, TI e negócio (TURNER, et al., 2002).
2.2.8. Benefícios
Os benefícios decorrentes da implantação de um Gerenciamento de Nível de Serviço são
(MACFARLANE, et al., 2005):
� Visão mais nítida para o cliente e o provedor de serviços sobre as responsabilidades e
objetivos a serem seguidos;
� Monitoramento e revisão dos serviços podem permitir a identificação dos pontos fracos
para que medidas de correção possam ser tomadas;
� Um controle melhor dos fornecedores e dos SLAs, que são muito importantes para a
gerência desses relacionamentos;
� Os serviços de TI podem ser projetados para atender as futuras necessidades do negócio;
� Os SLAs podem ser utilizados pela área financeira ao mostrar ao cliente em que ele
realmente está investindo;
� A relação entre cliente e provedor de serviços tende a ser melhor; e
28
� O serviço de monitoramento pode permitir que áreas de fragilidade sejam identificadas, e
que ações de correção possam ser tomadas.
O aumento na qualidade e a redução das interrupções dos serviços que podem ser alcançados
através do uso de um Gerenciamento de Nível de Serviço podem conduzir a uma redução
significativa nos custos da organização com a área de TI. Menos tempo e esforço é perdido
pela equipe de TI em resolver pequenas falhas e os clientes podem a princípio executar suas
funções de negócio sem impactos adversos (OGC, 2003).
2.3. GERENCIAMENTO DE DISPONIBILIDADE
O objetivo do serviço de Gerenciamento de Disponibilidade da ITIL é otimizar a capacidade
da infra-estrutura de TI, dos serviços e prover à organização a entrega de um nível sustentável
de disponibilidade a um custo eficaz que permita aos negócios satisfazerem seus objetivos.
Isto pode ser alcançado ao determinar os requerimentos de disponibilidade do negócio,
comparando-os com a capacidade da infra-estrutura de TI em oferecer o suporte adequado à
organização. A avaliação e o monitoramento da disponibilidade de TI é uma atividade
fundamental para garantir que os níveis de disponibilidades sejam cumpridos de maneira
consistente. O Gerenciamento de Disponibilidade é um trabalho contínuo de observação e
otimização da disponibilidade da infra-estrutura de TI, para que sejam entregues serviços
voltados aos negócios em benefício de seus usuários (OGC, 2003).
Adotar um processo de Gerenciamento de Disponibilidade é permitir que os sistemas, as
aplicações, a infra-estrutura de rede e os serviços estejam disponíveis aos usuários quando
estes forem necessitados. E para isto, atribuem-se as seguintes responsabilidades (Figura 8)
ao serviço de Gerenciamento de Disponibilidade (MACFARLANE, et al., 2005):
� Otimizar a disponibilidade através da monitoração de seus elementos-chave;
� Determinar os requisitos de disponibilidade da área de negócio;
� Prognosticar e projetar de acordo com os níveis almejados de disponibilidade e
segurança;
� Coletar, analisar e manter os dados de disponibilidade e seus relatórios;
� Elaborar planos de disponibilidade;
29
� Garantir o cumprimento dos níveis de disponibilidade dos serviços de TI celebrados com
as áreas de negócio através dos SLAs e dos OLA`s; e
� Monitorar e rever constantemente estes acordos para a melhoria contínua da
disponibilidade dos serviços de TI.
Figura 8. Responsabilidades do Gerenciamento de Disponibilidade Fonte: Pinheiro (2007)
O Gerenciamento de Disponibilidade atinge duas áreas distintas, a primeira são os novos
serviços de TI que envolvem as fases de definição de requerimentos e de projeto. A segunda
área são os serviços de TI existentes que requerem um esforço de curto prazo para melhorar
os níveis de disponibilidade. Os novos serviços de TI provêm melhor oportunidade para
alcançar os objetivos em termos de custos, porque as considerações de disponibilidade podem
ser construídas já na fase inicial. Isto permite selecionar as tecnologias mais adequadas a
serem usadas na infra-estrutura de TI, provendo o nível requerido de maturidade operacional.
Além disso, os clientes de serviços de TI e as organizações têm uma melhor oportunidade
neste cenário para trabalharem mais próximos nas definições e nos níveis de disponibilidade
a serem providos pelos serviços de TI e também acordarem o nível de investimento
requerido. Já os serviços de TI existentes podem se beneficiar do histórico de serviços mal
sucedidos e de suas causas raízes (WESTOVER, et al., 2002).
Uma das estratégias para adquirir um aumento da disponibilidade dos serviços de TI é montar
uma infra-estrutura de TI com tolerância a falhas ou um sistema de alta disponibilidade. O
termo tolerância a falhas sofre algumas críticas entre o meio acadêmico, pois ele pode ser
entendido como um sistema que toleraria toda e qualquer falha em qualquer situação, o que é
improvável e pode conduzir a falsas expectativas. O sucesso de um processo de
Gerenciamento de Disponibilidade depende do atendimento das especificações de
determinados serviços de TI. Um defeito, do termo em inglês failure, é definido como um
desvio destas especificações e não pode ser tolerado e sim evitado. Um sistema com erro
pode ser assim definido, se o processamento após este erro levar a um defeito. Já a causa
física ou algorítmica deste erro é denominada falta, do termo em inglês fault, ou falha. Para
30
se evitar um defeito, então, utilizam-se técnicas de tolerância a falhas, já que elas são
inevitáveis. Por fim, falhas estão associadas ao universo físico, erros ao universo da
informação e defeitos ao universo do usuário do serviço de TI. O período de tempo ocorrido
entre a falha e o erro que a ocasionou é definido como latência de uma falha. Já o período
entre um erro até a ocorrência de um defeito, é denominado latência de erro. Com isso, tem-
se que o tempo total entre o surgimento da falha até a ocorrência do defeito é a soma dessas
duas latências (MAGALHÃES, et al., 2007).
2.3.1. Elementos do Gerenciamento de Disponibilidade
Dentro do Gerenciamento de Disponibilidade existem alguns elementos que devem ser
considerados (OGC, 2003):
� Disponibilidade (Availability): é sustentada pela confiabilidade e reparabilidade da infra-
estrutura de TI e pela eficácia do suporte de TI da organização. Ou seja, a disponibilidade
depende da: disponibilidade dos componentes; tolerância a falhas; qualidade de
manutenção e suporte; qualidade e padrões de implantação de procedimentos e processos
operacionais; segurança, integridade e disponibilidade de dados. Um serviço de TI que
cumpra suas metas de disponibilidade em um SLA possui como característica, baixa
freqüência de falhas e rápido retorno do serviço após a ocorrência de um incidente;
� Confiabilidade (Reliability): pode ser qualitativamente definida como um serviço de TI
livre de falhas operacionais. A confiabilidade de um serviço de TI é determinada pela
confiabilidade de cada componente dentro da infra-estrutura de TI na entrega de seu
serviço, ou seja, a probabilidade de que um componente irá falhar ao prover suas funções.
Também pode ser determinado pela habilidade de uma falha em um componente de TI ser
mascarada para permitir que as operações do negócio continuem normalmente;
� Reparabilidade (Maintainability): relata a habilidade de um componente dentro de uma
infra-estrutura de TI em voltar ao nível operacional após uma falha. Ela pode ser dividida
em sete estágios: antecipação de falhas; detecção de falhas; diagnóstico de falhas;
resolução de falhas; recuperação de falhas; restauração dos dados e dos serviços de TI;
níveis de manutenção preventiva aplicadas para evitar a ocorrência de falhas; e
� Segurança (Safety): é a confidencialidade, integridade e disponibilidade dos dados
associados a um serviço de TI. É a probabilidade de um serviço de TI ser operacional e
31
executar sua função corretamente, ou interromper suas funções sem comprometer os
outros serviços de TI e seus usuários.
2.3.2. Classificação dos Serviços de TI
Disponibilidade, dentro do contexto dos serviços de TI, é a probabilidade que um serviço e
seus recursos têm de estarem disponíveis em um determinado período de tempo. Deste modo,
se um serviço de TI possui uma disponibilidade de 99%, isto significa dizer que
estatisticamente falando, em um dado momento este serviço possui 1% de chance de estar
indisponível ao ser requisitado. Os serviços de TI que não implementam nenhum tipo de
controle que possam mascarar as suas falhas, podem ser caracterizados como um serviço de
Disponibilidade Básica. De modo empírico, pode-se dizer que este serviço possui uma
disponibilidade variável entre 99 e 99,9%. Se o serviço possui mecanismos para detectar,
recuperar e mascarar as suas falhas, ele pode ser classificado como um serviço de Alta
Disponibilidade. Desta maneira, sua disponibilidade empírica pode variar entre 99,9 a
99,99999%. Quando um serviço de TI aplica um mecanismo para mascarar tanto as paradas
planejadas quanto às falhas, ele é classificado como um serviço de Disponibilidade
Contínua. Neste serviço, o nível de disponibilidade é muito próximo dos 100%, tendo um
tempo de inoperância desprezível ou inexistente. A Tabela 2 mostra o tempo de
indisponibilidade por período (MAGALHÃES, et al., 2007).
Tabela 2. Tempo de Indisponibilidade
Disponibilidade (%)
Tempo Indisponível em um Ano
Tempo Indisponível em um Mês
99,9999999 0,03 segundos 0,003 segundos 99,999999 0,32 segundos 0,026 segundos 99,99999 3,15 segundos 0,259 segundos 99,9999 31,54 segundos 2,592 segundos 99,9995 2,63 minutos 12,96 segundos 99,999 5,26 minutos 25,92 segundos 90 36,50 dias 72,00 horas
Fonte: Magalhães e Pinheiro (2007)
32
2.3.3. Métricas de Disponibilidade
A organização de suporte de TI vem medindo e relatando suas perspectivas de
disponibilidade durante muitos anos. Tradicionalmente essas medidas foram concentradas em
cima de componentes de disponibilidade e não da visão dos negócios e dos usuários. Estas
métricas são baseadas na combinação de uma porcentagem de disponibilidade, tempo perdido
e freqüência de falhas. Alguns exemplos de métricas são as seguintes (OGC, 2003):
� Percentual de Disponibilidade e Indisponibilidade: é a forma mais simples de métrica
utilizada. Reporta a proporção de tempo que um componente está disponível para uso dos
negócios dentro do tempo de serviço acordado. Esta é uma métrica simples para a
medição da disponibilidade do hardware, aplicações de software e componentes de redes
de trabalho. Requer um baixo investimento em ferramentas de métrica e de relatórios.
Conseqüentemente, muitos SLAs são construídos com métricas de disponibilidade
baseadas em porcentagem (%) de disponibilidade;
� Duração: é a conversão da porcentagem de indisponibilidade em horas e minutos,
provendo uma medida mais “humana” e focada na melhoria do serviço;
� Freqüência de Falhas: usado para registrar o número de interrupções dos serviços de TI.
Ajuda a prover uma boa indicação de confiabilidade do ponto de vista do usuário. É
usado em combinação com a duração, gerando uma visão balanceada das interrupções
dos serviços e da duração do tempo perdido pelo negócio; e
� Impacto da Falha: esta é a medida real de um serviço indisponível. Depende de um
registro de incidentes “maduro” onde a inabilidade do usuário em sua tarefa é a peça mais
importante da informação capturada. Todas as outras medições sofrem um potencial
mascaramento dos reais efeitos da falha de um serviço.
A disponibilidade quando medida e reportada de maneira a refletir a experiência do usuário,
provê uma visão mais representativa na qualidade dos serviços de TI como um todo. Esta
metodologia empregada deve considerar o impacto causado pelos minutos perdidos pelos
usuários quando ocorrer uma indisponibilidade dos serviços de TI e o impacto nas transações
dos negócios. Com isso permite-se avaliar a perda de produtividade dos usuários afetados
pela indisponibilidade e o número de transações que não puderam ser processadas durante
este período de tempo. Dentro da perspectiva da área de negócio, um serviço de TI só pode
ser considerado disponível quando ele for capaz de executar todas as funções vitais
33
requeridas para conduzir a suas operações. Já para a visão dos serviços de TI, disponibilidade
é quando todos os componentes aos quais os negócios são dependentes estejam disponíveis.
Pretende-se com isso, garantir que SLAs e relatórios de disponibilidade sejam baseados em
métricas às quais são compreendidas tanto pela área de negócio quanto para a área de TI.
Através da medição das funções vitais da área de negócio, o impacto das falhas reflete as
conseqüências diretamente na área de negócios da organização (OGC, 2003).
Para avaliar a escala de métricas e perspectivas que devem ser consideradas ao estabelecer
uma métrica ou um relatório de disponibilidade, a ITIL propõe um Modelo de Métricas da
Disponibilidade de TI (MMDTI) – IT Availability Metrics Model (ITAMM). Este modelo
serve como guia para estabelecer o que deve ser medido e oferecer uma visão mais ampla da
disponibilidade dos serviços de TI. As métricas precisam ser significativas e terem valor
agregado se elas realmente trouxerem benefícios à área de TI e aos negócios da organização
(MACFARLANE, et al., 2005).
2.3.4. Cálculo da Disponibilidade
A definição de disponibilidade de um serviço de TI está relacionada com a porcentagem de
tempo em que o serviço de TI está operacional de acordo com monitoramento estabelecido.
Para auxiliar na formulação de metas de disponibilidade para componentes e serviços de TI, a
ITIL propõe uma fórmula básica para o cálculo de disponibilidade conforme a Figura 9. A
fórmula apresentada é bastante simples, mas suficiente para prover estimativas adequadas de
disponibilidade. Para estimativas mais elaboradas são necessários cálculos matemáticos mais
complexos. Um exemplo pode ser dado utilizando a fórmula proposta: Um serviço de TI
acordado em um SLA, requer 168 horas de disponibilidade, com 2 horas semanais de
indisponibilidade planejada para manutenção. Após a realização da manutenção semanal,
ocorre um erro que resulta em 3 horas de indisponibilidade não planejada. De acordo com a
fórmula apresentada, o resultado do cálculo de disponibilidade foi de 98,19% (OGC, 2003).
34
Figura 9. Fórmula do Cálculo de Disponibilidade Fonte: Adaptada de OGC (2003)
Métricas que refletem a confiabilidade e a reparabilidade de um serviço de TI e seus
componentes de suporte podem ser derivadas de um relatório de incidentes. Além disso,
relatórios baseados em incidentes podem gerar indicadores de melhorias ou tendências de
agravamento através das seguintes medidas, mostradas na Figura 10 (MAGALHÃES, et al.,
2007):
� MTBF ou Uptime: média de tempo decorrido desde o momento em que um serviço de TI
é completamente restaurado até a próxima ocorrência de uma falha no mesmo serviço ou
componente;
� MTBSI: média de tempo decorrido entre a ocorrência de uma falha e outra; e
� MTTR (Mean Time To Repair) ou Downtime: média de tempo decorrido desde a
ocorrência de um incidente até a sua resolução.
Figura 10. Ciclo de Vida do Incidente Fonte: Pinheiro (2007)
35
Recomenda-se que o Gerenciamento de Disponibilidade trabalhe junto com o Gerenciamento
de Incidentes e com o Gerenciamento de Problemas na análise dos incidentes de
indisponibilidade. Uma técnica para ajudar nesta análise é ter uma visão geral do ciclo de
vida de um incidente (WESTOVER, et al., 2002):
� Início do Incidente: é o momento em que as funções ou transações do negócio tornam-se
indisponíveis. Pode ser causado por uma falha em um componente de TI, falta de energia,
erro em uma aplicação ou erro humano, como desligamento de um servidor;
� Detecção do Incidente: é o momento em que a organização de TI toma conhecimento do
problema. Eficientes mecanismos de manipulação de eventos precisam ser
implementados para garantir que os incidentes sejam identificados o mais rápido possível;
� Diagnóstico do Incidente: é o momento em que a verdadeira causa é identificada em
oposição a quaisquer sintomas iniciais, através da identificação dos recursos apropriados
para se trabalhar nas causas do problema;
� Reparo do Incidente: é o momento onde as falhas ou defeitos são consertados, através
da substituição de algum componente de TI, da restauração da energia, implementação de
uma aplicação de emergência ou apenas da reinicialização do sistema;
� Recuperação do Incidente: é o momento em que qualquer recuperação é concluída,
através copias de seguranças, por exemplo, e seus componentes de TI estão prontos para
retomarem suas operações normais; e
� Restauração do Incidente: é o momento em que o serviço é normalizado e as funções e
transações de negócio tornam-se completamente disponíveis.
A porcentagem de disponibilidade para cada componente de TI dentro da infra-estrutura pode
ser diferente, exigindo um cálculo diferenciado para refletir sua disponibilidade total. A
porcentagem de disponibilidade para este tipo de configuração é baseada no produto do
percentual de disponibilidade de cada componente na infra-estrutura sugerido pela ITIL,
conforme a Figura 11 (OGC, 2003).
36
Figura 11. Cálculo de disponibilidade total de uma infra-estrutura. Fonte: OGC (2003)
2.3.5. Relacionamento com o SLA
Do ponto de vista da disponibilidade, o Gerenciamento de Nível de Serviço é o responsável
pela comunicação com o cliente e pela determinação dos serviços de TI cruciais para a
sobrevivência da empresa. O gerenciamento de Disponibilidade utiliza-se destas informações
para identificar os componentes chave da infra-estrutura de TI que suporta esses serviços
críticos e determina se eles possuem pontos de falha ou outros riscos de disponibilidade
(WESTOVER, et al., 2002).
Com a adoção de novos serviços de TI e a introdução de grandes mudanças na sua infra-
estrutura, as metas de disponibilidade e as métricas acordadas com o cliente poderiam ser
transformadas em um verdadeiro conjunto de critérios dos testes de aprovação estabelecidos
para ajudar a provar que quaisquer novos sistemas e suportes a serem implantados são
capazes de satisfazer as metas e os objetivos que foram definidos no SLA. Os seguintes itens
podem estar contidos na OLA (WESTOVER, et al., 2002):
� O impacto nos negócios quando há uma indisponibilidade;
� O custo da indisponibilidade ao longo do tempo;
� Horas de serviços exigidas e períodos críticos de serviço;
� Períodos onde a indisponibilidade é tolerável;
� Períodos de indisponibilidade programada (manutenção);
� Por quanto tempo uma indisponibilidade pode ser tolerada até sua restauração; e
� Como a disponibilidade é medida: definição de indisponibilidade.
Este trabalho é realizado em conjunto com o Gerenciamento de Nível de Serviço, já que é de
sua responsabilidade a documentação e negociação dos níveis de serviço com o cliente.
37
2.3.6. Benefícios
O principal benefício de um processo de Gerenciamento de Disponibilidade é que serviços de
TI com requerimentos de disponibilidade são projetados, implementados e gerenciados para
alcançarem seus objetivos constantemente. Além disso, o Gerenciamento de Disponibilidade:
oferece serviços projetados atendendo os requisitos da área de negócios a um custo
compatível; oferece suporte ao Gerenciamento de Nível de Serviço; transforma a área de TI
em uma prestadora de serviços proativa e não reativa; protege a imagem da organização;
melhora as operações atuais da área de TI e de negócios; torna a área de TI parte da área de
negócios, agregando valores para ambos (MAGALHÃES, et al., 2007).
2.4. GERENCIAMENTO DE CAPACIDADE
O serviço de Gerenciamento de Capacidade da ITIL é o processo de planejamento, análise,
dimensionamento e otimização da capacidade da infra-estrutura de TI para satisfazer a
demanda dos negócios em um tempo apropriado a um custo razoável. Ele possui um vasto
campo que reúne os negócios, os serviços e recursos necessários a fim de garantir uma
utilização otimizada dos recursos necessários para atingir os níveis de desempenho acordados
com o cliente. Otimizar, dentro deste contexto, refere-se ao uso do melhor lugar, tempo,
quantidade e preço. O Gerenciamento de Capacidade concentra-se nos procedimentos e
sistemas, incluindo a especificação, execução, acompanhamento, análise e ajuste da infra-
estrutura de TI. Os requisitos de capacidade são baseados em padrões qualitativos e
quantitativos estabelecidos pelo processo de Gerenciamento de Nível de Serviço e
especificadas dentro de um SLA ou OLA. O processo de Gerenciamento de Capacidade
baseia-se num conjunto de tarefas de monitoramento, análise, modelagem e otimização, para
alcançar os seus objetivos (MICROSOFT SMF, 2002).
Para o processo de Gerenciamento de Capacidade garantir que a capacidade da infra-estrutura
de TI corresponda à demanda dos negócios a um custo e prazo apropriado, ele engloba os
seguintes aspectos (MACFARLANE, et al., 2005):
� Monitoramento do desempenho e da capacidade dos serviços de TI e dos componentes de
suporte de sua infra-estrutura;
� Atividade de ajuste para fazer um uso eficiente dos recursos existentes;
38
� Entendimento da demanda atual feita pelos recursos de TI e fazendo previsões para
futuras requisições;
� Influencia sobre a demanda dos recursos de TI, atuando junto com o processo de
Gerenciamento Financeiro; e
� Produção de um Plano de Capacidade que habilite o provedor de serviços de TI a prover
serviços de qualidade acordados nos SLAs.
O processo de Gerenciamento de Capacidade pode ser visto como um jogo de equilíbrio, no
qual os seguintes aspectos são colocados na balança (MAGALHÃES, et al., 2007):
� Custo e Capacidade: visa garantir que a capacidade adquirida dos recursos de TI não
seja só justificada pelas necessidades dos negócios, mas também pela necessidade de
fazer um uso mais eficaz dos recursos de TI disponíveis; e
� Recursos e Demanda: visa assegurar que os recursos de TI disponíveis estão de acordo
com a demanda dos negócios, tanto no presente quanto no futuro. Também pode ser
necessário gerenciar ou influenciar a demanda para um recurso particular.
Um processo de Gerenciamento de Capacidade garante que todos os requisitos de capacidade
da organização sejam alcançados. Ele provê as informações necessárias para a utilização dos
recursos atuais e planejados de cada componente de TI para ajudar a organização a decidir
com confiança: quais componentes devem ser atualizados, quando atualizar e quanto isto irá
custar. Além disso, o Gerenciamento de Capacidade precisa entender os requisitos dos
negócios, as operações da organização, a infra-estrutura de TI e garantir que a capacidade
atual e futura desses requisitos seja provida a um custo aceitável. Novas tecnologias precisam
ser entendidas e usadas para entregar os serviços requeridos pela área de negócios. O
Gerenciamento de Capacidade precisa estar atento às rápidas mudanças da tecnologia e
aproveitá-las para garantir que os serviços de TI continuem a satisfazer as expectativas de
mudança da área de negócios (OGC, 2003).
2.4.1. Processos de Gerenciamento
O processo de Gerenciamento de Capacidade possui três sub-processos, que por sua vez,
possuem várias atividades conforme a Figura 12 (MAGALHÃES, et al., 2007). Estes
processos são:
39
Figura 12. Sub-Processos do Gerenciamento de Capacidade Fonte: Adaptado de OGC (2003)
� Gerenciamento de Capacidade do Negócio (GCN) ou Business Capacity Management
(BCM): é responsável pelo planejamento e atendimento no tempo correto das
necessidades futuras da área de negócios pelos serviços de TI. Essas necessidades futuras
vêm de planos de negócio que descrevem novos serviços de TI que a organização precisa
para alinhar com suas estratégias de negócio, além do crescimento e melhorias dos atuais
serviços de TI e planos de desenvolvimento da sua infra-estrutura. Para isso, alguns
conhecimentos são requisitados: níveis de serviços definidos em SLAs existentes;
requisitos de níveis de serviços contestados para o futuro; Planos de Capacidade e de
Negócio e métodos para o dimensionamento dos sistemas de TI;
� Gerenciamento de Capacidade de Serviço (GCS) ou Service Capacity Management
(SCM): é o responsável pelo desempenho dos serviços de TI prestado aos seus usuários e
pelo monitoramento dos níveis de desempenho acordados no SLA, além da obtenção,
registro, análise e criação de relatórios gerados com os dados obtidos. Os conhecimentos
requisitados são: níveis de serviços acordados em SLAs existentes; arquitetura dos
sistemas e da infra-estrutura de TI; desempenho e capacidade dos serviços de TI;
mecanismos de monitoramento, mensuração, diagnóstico, adaptação e gerenciamento da
demanda; e
40
� Gerenciamento de Capacidade dos Recursos (GCR) ou Resource Capacity
Management (RCM): é o responsável pelo gerenciamento dos ICs da infra-estrutura de
TI, para garantir que os serviços e os recursos disponibilizados para o suporte sejam
controlados e monitorados e que os dados coletados sejam armazenados, analisados e
reportados. Os conhecimentos requeridos são: as tecnologias atuais e suas utilizações;
futuras tecnologias e suas alternativas; capacidade dos sistemas e serviços de TI.
A principal diferença entre os sub-processos está nos dados monitorados e coletados, e pela
perspectiva de análise adotada por eles. Por exemplo, o nível de utilização de cada
componente na infra-estrutura é de interesse do Gerenciamento de Capacidade dos Recursos,
enquanto as taxas de transferência e tempos de resposta das transações são de interesse do
Gerenciamento de Capacidade do Serviço. Para o Gerenciamento de Capacidade do Negócio
as taxas de transferência dos serviços on-line precisam ser traduzidas em volumes de
negócios, por exemplo, em vendas faturadas. Certo número de atividades precisa ser
realizado de maneira contínua, formando um ciclo natural conforme a Figura 13.
Monitoramentos precisam ser estabelecidos sobre todos os componentes e para cada um dos
serviços. Os dados precisam ser analisados, reportados e as recomendações feitas
adequadamente. Algum tipo de mecanismo de controle pode ser posto em prática para agir
em cima das recomendações, transformando-as em serviços balanceados, alterando os níveis
de concorrência, e adicionando ou removendo recursos. O ciclo então inicia novamente,
monitorando quaisquer mudanças ocorridas para garantir que tenham tido um efeito benéfico
e coletando os dados para o próximo dia, semana ou mês (OGC, 2003).
41
Figura 13. Atividades Interativas do Gerenciamento de Capacidade Fonte: Magalhães e Pinheiro (2007)
2.4.2. Atividade de Monitoramento
O Gerenciamento de Capacidade envolve os requisitos dos níveis de operação internos e das
métricas associadas com cada parte da área de TI que contribuem para o SLA como um todo.
É importante que a utilização de cada recurso e serviço seja monitorada de forma permanente
para garantir que os recursos de hardware e software sejam usados da melhor maneira
possível e que todos os níveis de serviços acordados possam ser alcançados. A maioria das
tarefas de monitoramento são de curto prazo, não havendo um registro histórico do
comportamento dos serviços de TI. As informações coletadas podem ser registradas em um
Banco de Dados de Capacidade (BDC) ou Capacity Management Database (CDB). Ele
precisa conter pontos de informações que identifiquem tendências históricas e padrões. Os
dados devem ser recolhidos não só na utilização dos recursos totais, mas também em um
nível mais detalhado de carga de trabalho para cada recurso em particular. Isto deve ser
realizado em toda a infra-estrutura de TI, como por exemplo, em aplicações, servidores e
redes de trabalho (MICROSOFT SMF, 2002).
O monitoramento é uma atividade que exige um consumo maior dos recursos do processo de
Gerenciamento de Capacidade devido à realização constante e ininterrupta de suas tarefas,
para que ela possa suportar as demandas da área de negócios. Um aspecto importante dentro
deste processo é a determinação de quais recursos técnicos deverão ser monitorados, e isto é
42
feito na elaboração de um modelo de estudo de capacidade dos serviços de TI. A Tabela
3sugere algumas variáveis técnicas possíveis para a atividade de monitoramento
(MAGALHÃES, et al., 2007).
Tabela 3. Variáveis Técnicas de Monitoramento de Capacidade
Variável Técnica Limiar Alerta Crítico
Utilização de CPU
80% de utilização nos últimos 5 minutos
90% de utilização nos últimos 5 minutos
Utilização de Memória
70% de utilização de memória nos últimos 5 minutos
80% de utilização de memória nos últimos 5 minutos
Utilização de Rede
50% de utilização de segmento Ethernet compartilhado
65% de utilização de segmento Ethernet compartilhado
Taxa de Erro na Rede
1% de erros ao longo de 5 minutos
5% de erros ao longo de 5 minutos
Taxa de I/O de disco
1000 kbps de taxa de I/O 1400 kbps de taxa de I/O
Utilização de espaço em disco
80% de espaço ocupado 95% de espaço ocupado
Tempo de Resposta para aplicativos
3 segundos 7 segundos
Transações com Tempo de Resposta desejado
95% das transações abaixo de 5 segundos
80% das transações abaixo de 5 segundos
Fonte: Magalhães e Pinheiro (2007)
Muitos SLAs têm como alvo de mensuração o tempo de resposta do usuário, mas muitas
organizações têm dificuldade em atender essa requisição. Tempos de resposta dos usuários de
TI e serviços de rede podem ser monitorados e medidos de várias maneiras (OGC, 2003):
� Incorporando um código específico dentro de uma aplicação cliente e servidor: pode
ser usado para prover tempos de resposta de serviços fim-a-fim. Os números obtidos a
partir deste mecanismo dão os verdadeiros tempos de resposta percebidos pelos usuários
do serviço;
� Usando um sistema com emulação de terminal: esses sistemas consistem de sistemas
cliente com softwares de emulação de terminal e softwares de script especializados para a
geração e medição de transações e respostas. Esses sistemas geralmente provêm tempos
de resposta de serviços fim-a-fim, de transações ou de interações complexas. Neste
43
mecanismo são dados somente indicações de tempos de resposta e não os tempos de
resposta reais percebidos pelos usuários do sistema;
� Usando agentes de monitoração distribuídos: informações úteis sobre tempos de
resposta dos serviços podem ser obtidos através de sistemas de agentes distribuídos com
softwares de monitoramento em diferentes pontos da rede – inclusive na internet. Esses
sistemas podem ser usados, por exemplo, para gerar transações de vários lugares e
medições periódicas de um site da internet concebidas por usuários internacionais. Mas
novamente, são só indicadores dos tempos de resposta dos usuários; e
� Usando sistemas específicos de monitoramento passivo: este sistema baseia-se na
conexão de sistemas de monitoramento de uma rede específica, freqüentemente
referenciados como sniffers9 inseridos em pontos apropriados dentro da rede. Uma vez
registrado, este tráfego pode ser analisado para gerar informações detalhadas dos tempos
de resposta dos serviços. Mais uma vez, podem ser utilizados para dar uma aproximação
dos tempos de resposta reais dos usuários, embora sejam muito próximos da realidade,
dependem da posição do monitor dentro da própria infra-estrutura de TI.
2.4.3. Atividades de Análise, Ajuste e Implementação
Nesta atividade, os dados monitorados e coletados são analisados e usados para realizar
exercícios de ajuste e de estabelecimento de perfis. Estes perfis são importantes desde que
permitam a identificação apropriada e a adaptação dos limiares e alarmes dos níveis de
serviço. Quando estes relatórios de exceção ou alarme são levantados, eles precisam ser
analisados e reportados, e ações corretivas precisam ser tomadas. Recomenda-se que todos os
limiares sejam configurados abaixo do estabelecido no acordo de nível de operacional
(OLA). Ao fazer isso, o Gerenciamento de Capacidade pode tomar ações corretivas antes que
objetivos dentro dos OLAs sejam violados e os recursos sobrecarregados, culminando em
períodos de falha ou de baixo desempenho. Os dados coletados da atividade de
monitoramento precisam ser analisados para identificar alterações no comportamento e nos
níveis de serviço. Esses dados podem ser utilizados para pré-identificar as seguintes questões
sobre o uso dos recursos: distribuição inapropriada de carga de trabalho entre os recursos
disponíveis; projeto de aplicações ineficientes; aumento inesperado da taxa de transação; uso
9 Programas que permitem monitorar a atividade da rede e registrar o seu tráfego. Muito utilizado para roubar
senhas dentro da rede. Fonte: Figueiredo (2000)
44
ineficiente de memória; inapropriada estratégia de bloqueio; e contenção de dados, arquivos,
memória e processador (MICROSOFT SMF, 2002).
A análise dos dados monitorados pode identificar áreas de configuração que poderiam ser
ajustadas para a melhor utilização dos recursos do sistema ou o desempenho de um
determinado serviço. As técnicas de ajuste incluem (OGC, 2003):
� Balanceamento de Carga de Trabalho: transações podem chegar a um host ou a um
servidor vindo de um gateway específico, dependendo de onde a transação foi iniciada. A
distribuição dos pontos iniciais entre gateways podem proporcionar ajustes benéficos;
� Balanceamento de Disco: armazenamento de dados de maneira eficiente e estratégica,
por exemplo, segmentando os dados através de vários discos podem reduzir a contenção
de dados;
� Definição de uma estratégia de bloqueio: especifica quando bloqueios são necessários e
o nível apropriado (banco de dados, paginação, registro, arquivo) de retardo deste até uma
atualização for necessária, pode prover benefícios; e
� Ineficiente Uso de Memória: um processo pode utilizar recursos de maneira mais
eficiente quando os dados lidos em memória são manipulados lá, em vez de uma leitura
seqüencial através de arquivos. Alternativamente, muitos processos podem competir
pelos recursos de memória, e as excessivas podem levar a um aumento da utilização de
CPU e os atrasos nas atividades de swap da memória principal.
O objetivo desta atividade é aplicar quaisquer mudanças identificadas pelo monitoramento,
análise e ajuste dos dados. A implementação das mudanças resultantes destas atividades
devem ser realizadas através de um rigoroso processo de Gerenciamento de Mudança. Os
impactos nos ajustes no sistema têm maiores implicações nos clientes do serviço.
Implementando as mudanças de ajuste sob os procedimentos do Gerenciamento de Mudanças
resultam em: menor impacto negativo sobre os usuários do serviço, aumento da
produtividade do usuário, aumento da produtividade do pessoal de TI, redução do número de
alterações que precisam ser apoiadas e melhor gerenciamento e controle dos negócios críticos
dos serviços de aplicação (OGC, 2003).
45
2.4.4. Banco de Dados de Capacidade
O Banco de Dados de Capacidade (BDC) é o responsável pelo registro de todo o histórico de
capacidade da infra-estrutura de TI, sendo a base para elaboração de todos os relatórios de
capacidade atuais e de planejamento. É composto de várias bases de dados localizadas
fisicamente em diferentes locais e com diversos conteúdos, já que os dados são provenientes
de diferentes ferramentas de monitoramento da infra-estrutura de TI. A estrutura do banco de
dados permite o armazenamento dos seguintes itens: dados do negócio, dados dos serviços de
TI, dados técnicos, dados financeiros e dados de utilização (MAGALHÃES, et al., 2007).
O Banco de Dados de Capacidade contém os detalhes técnicos, dos negócios, e os dados do
Gerenciamento de Nível de Serviços necessários ao suporte dos processos de Gerenciamento
de Capacidade. Ele atua como um repositório central e é usado para armazenar e trocar
dados de capacidade e desempenho entre os três sub-processos do Gerenciamento de
Capacidade. Além disso, o BDC pode ser usado por outros processos como monitoramento,
Gerenciamento de Problema e Gerenciamento de Mudança. A Tabela 4 representa um
exemplo da estrutura de um Banco de Dados de Capacidade. (MICROSOFT SMF, 2002)
Tabela 4. Modelo de Exemplo de um BDC
Nome do Campo Descrição NomeItemCapacidade Nome do item TipoItemCapacidade Tipo – por exemplo, serviço ou recurso DescricaoItemCapacidade Texto livre para descrição UnidadeDeMedida Unidades como kilobyte, milisegundos, ... CustoUnidade Custo padrão de cada unidade CapacidadeMaxima Capacidade máxima possível alcançada pelo item LimiarAlerta Limiar atual de alerta do item ItensFilhosHierarquia Lista de itens de capacidade que este item depende ItensPaiHierarquia Lista de itens que dependem deste item HoraColetaDados A hora de coleta dos dados DataColetaDados A data de coleta dos dados
Fonte: Adaptada de Microsoft SMF (2002)
2.4.5. Gerenciamento da Demanda e Modelagem da Capacidade
O Gerenciamento da Demanda é uma importante interface entre a área de negócios e o
Gerenciamento da Capacidade, influenciando no uso dos recursos de TI. É indispensável para
46
a gerência da demanda compreender as necessidades dos negócios e principalmente das suas
demandas por serviços e recursos de TI (MACFARLANE, et al., 2005).
Esta atividade pode ser desenvolvida como um requisito de curto prazo, quando não existir
capacidade atual para suportar o trabalho que está sendo executado, ou, como uma política
deliberada de gerenciamento de TI, para limitar a capacidade exigida em longo prazo (OGC,
2003):
� O Gerenciamento da Demanda em Curto Prazo: pode ocorrer quando houver uma
falha parcial de um recurso crítico da infra-estrutura de TI. Por exemplo, caso tenha
havido uma falha em uma parte da memória de um processador, pode não ser possível
executar todos os serviços. No entanto um pequeno subconjunto deles pode ser
executado. O gerenciamento de capacidade deve estar ciente das prioridades do negócio
de cada um dos serviços, conhecer os recursos necessários de cada um (neste caso, a
quantidade de memória necessária para executar o serviço) e, em seguida, ser capaz de
identificar quais os serviços podem ser executados enquanto houver uma quantidade
limitada de memória disponível; e
� O Gerenciamento da Demanda em Longo Prazo: pode ser exigido quando é difícil
justificar um alto investimento em uma atualização de hardware. Por exemplo, muitos
processadores são intensamente utilizados por apenas algumas horas do dia, normalmente
entre 10:00-12:00 horas, e das 14:00-16:00 horas. Dentro deste período, o processador
pode estar sobrecarregado por apenas uma ou duas horas. Entre as 18:00-08:00 horas
estes processadores estão subutilizados. É possível justificar o custo de uma atualização
para fornecer recursos adicionais para apenas algumas horas ou é possível influenciar a
demanda e distribuir o processamento durante todo o dia, evitando assim a necessidade de
atualização?
O objetivo da modelagem dentro do Gerenciamento de Capacidade é criar modelos
matemáticos que emulem o comportamento de um sistema ou serviço de TI (MAGALHÃES,
et al., 2007). Esses modelos são:
� Simulação: é uma técnica para prever os impactos provocados por significativas
alterações no perfil da demanda e na infra-estrutura de um serviço de TI, utilizando a
47
modelagem de eventos discretos. Esta modelagem pode ser muito precisa na previsão dos
efeitos causados nas aplicações existentes e no dimensionamento de novas;
� Modelagem Analítica: tem o objetivo de reproduzir o comportamento real de algum
serviço, através do uso de um modelo matemático aproximado. Tipicamente este modelo
é construído usando pacotes de softwares que são alimentados com as informações dos
componentes e das cargas de trabalho a serem modeladas. Se os tempos de resposta
previstos pelo modelo forem bem próximos aos modelos reais, ele pode ser considerado
como uma representação exata de um sistema real; e
� Análise de Tendência: é o monitoramento dos serviços de TI em si. Permite a
identificação de pontos considerados de gargalo. Os dados coletados podem ser
armazenados em planilhas e gráficos utilizados para demonstrar de cada recurso ao longo
de um período, e como o seu comportamento pode alterar o futuro.
2.4.6. Dimensionamento dos Recursos e Planejamento da Capacidade
O principal objetivo do Dimensionamento dos Recursos é estimar os recursos necessários
para apoiar a mudança ou aquisição de novas aplicações e para assegurar o cumprimento dos
SLAs. Para atingir este objetivo, o dimensionamento tem que ser uma parte integrante dos
seus ciclos de vida. Durante as análises iniciais do sistema e do projeto, os níveis de serviço
devem ser especificados. Isto permite a aplicação empregar o desenvolvimento de tecnologias
e de produtos pertinentes, a fim de assegurar um projeto que satisfaça os níveis desejados de
serviço. É muito mais fácil e menos custoso atingir os níveis exigidos de serviço se o projeto
da aplicação considerar os níveis exigidos de serviço, no início do ciclo de vida da aplicação,
do que depois. O Dimensionamento dos Recursos deve ser ajustado à medida que o
desenvolvimento do processo avança. Os requisitos dos níveis de serviço no desenvolvimento
de aplicações planejadas não podem ser considerados de maneira isolada. Os recursos a
serem utilizados pela aplicação podem ser compartilhados com outros serviços existentes e
potenciais ameaças às metas dos SLAs devem ser reconhecidas e gerenciadas (OGC, 2003).
O Planejamento de Capacidade é parte fundamental do Gerenciamento de Capacidade e seu
objetivo é acompanhar o desenvolvimento do serviço de TI desde a validação dos requisitos
de negócio. O resultado do planejamento é um estudo formado pelos aspectos técnicos,
requisitos de qualidade do serviço e dos negócios de cada serviço de TI, chamado de Plano de
Capacidade. Com este plano é possível determinar quais mudanças poderão ser feitas para
48
que os serviços de TI correspondam aos requisitos dos negócios. A Figura 14 apresenta o
fluxo de dados de um Planejamento de Capacidade. Os dados são capturados através da
atividade de monitoramento, que usa para tal, agentes coletores de dados. Em cima dos dados
capturados são processadas as atividades de depuração, classificação e sumarização e por fim,
o armazenamento desses dados no BDC. Uma vez armazenados os dados, consultas são feitas
para a construção do Plano de Capacidade (MAGALHÃES, et al., 2007).
Figura 14. Fluxo de Dados do Planejamento de Capacidade Fonte: Adaptado de Magalhães e Pinheiro (2007)
2.4.7. Relacionamento com o SLA
Acordos entre o provedor e o consumidor de serviços de TI existem em muitas organizações
mesmo que informalmente. Revisar os SLAs é uma atividade primária no Gerenciamento de
Nível de Serviço. O Gerenciamento de Capacidade também ajuda a definir OLAs resultantes
dos requisitos de nível de serviço. Recomenda-se que a TI priorize os serviços de alertas para
prevenir a queda de desempenho antes que a disponibilidade seja afetada (MICROSOFT
SMF, 2002).
As expectativas dos clientes podem exceder a capacidade técnica da infra-estrutura de TI,
portanto é recomendável que elas sejam gerenciadas desde o início. O Gerenciamento de
Capacidade provê uma oportunidade de equilibrar estas expectativas com os custos e os
recursos disponíveis para atingir as metas de níveis de desempenho de maneira apropriada.
Recomendam-se também dividir os serviços prestados em categorias menores e gerenciáveis,
tais como: serviço, aplicação, banco de dados, sistemas operacionais, hardware e redes. Para
49
cada categoria define-se um requisito de nível operacional para tentar garantir o comprimento
do SLA (MICROSOFT SMF, 2002).
2.4.8. Benefícios
Com a implantação do Gerenciamento de Capacidade é possível obter um fornecimento de
serviços mais econômicos devido à eliminação da capacidade adicional desnecessária,
otimizando a utilização dos recursos. Outros benefícios encontrados podem ser a eliminação
de compras onerosas de última hora, a redução do risco de ocorrer problemas e falhas de na
capacidade da infra-estrutura, previsões de falhas mais precisas e confiáveis através do plano
de capacidade, melhores informações na aquisição de recursos de TI, melhor relação com os
clientes, melhor compreensão dos SLAs e maior controle e suporte proativo de falhas e
problemas (MACFARLANE, et al., 2005).
2.5. CONSIDERAÇÕES DO CAPÍTULO
Este capítulo apresentou o Gerenciamento de Nível de Serviço, Gerenciamento de
Disponibilidade e Gerenciamento de Capacidade. Os assuntos abordados em cada item
apresentado servirão de base para o levantamento dos requisitos e regras de negócio da
solução proposta (Capítulo III). A partir desses dados, pode-se então efetuar a modelagem do
protótipo, tendo como resultado os artefatos que servirão de base para o desenvolvimento do
projeto.
3. DESENVOLVIMENTO
Este capítulo apresenta o corpo conceitual utilizado como referência para o desenvolvimento
do projeto do Trabalho de Conclusão de Curso. Constitui-se na apresentação dos artefatos
modelados com base na fundamentação teórica apresentada no capítulo anterior. Como este
trabalho tem por objetivo a criação de um protótipo de monitoramento, a partir de agora, por
questões de padronização, a palavra sistema será adotada como sinônimo de protótipo.
O capítulo tem seu início na Seção 3.1. Nela é apresentada a visão geral da solução
desenvolvida. Na Seção 3.2 são levantados os requisitos funcionais e não-funcionais do
projeto com base na fundamentação teórica. A Seção 3.3 descreve as regras de negócio de
acordo com os requisitos levantados. Os casos de uso são apresentados na Seção 3.4 e os
diagramas de classe na Seção 3.5. A Seção 3.6 contém os diagramas de seqüência e a Seção
3.7 apresenta os diagramas de Entidade-Relacionamento. As ferramentas utilizadas durante o
desenvolvimento e suas justificativas são apresentadas na Seção 3.8. A estutura do projeto
realizado é detalhada através dos módulos e conceitos de programação utilizados durante a
implementação e estão descritos na Seção 3.9. Após o desenvolvimento, é montado o
ambiente de testes na Seção 3.10 para que um profisisonal da área possa avaliar e realizar os
testes no protótipo apresentados na Seção 3.11, utilizando os requisitos levantados no
Capítulo III e seus conhecimentos nas boas práticas da ITIL.
3.1. VISÃO GERAL
A solução proposta tem como objetivo desenvolver uma ferramenta de monitoramento dos
SLAs acordados entre os clientes e a área de TI, mais especificamente os itens de
disponibilidade e de capacidade. Para tanto, foi criada uma arquitetura conforme a Figura 15.
Nesta arquitetura, agentes coletores de dados são instalados em computadores dentro e fora
da rede local, obtendo deste modo as informações necessárias para garantir a entrega dos
serviços acordados. Uma vez que esses dados são coletados, eles são enviados para um
servidor web que processa e armazena essas informações. A comunicação entre os agentes e
o servidor é feita pela Internet ou pela rede local através de um WebService implementado
pelo servidor web, disponibilizando deste modo uma interface para que os dados dos agentes
possam ser enviados. Uma vez que esses dados são enviados, o WebService encaminha-os
para a base de dados, para que possam ser armazenados. No outro lado deste processo está o
51
usuário do sistema. Para que o monitoramento em si possa ser realizado, ele acessa uma
página web onde pode acompanhar seus SLAs e gerenciar os agentes.
Figura 15. Arquitetura da Solução Proposta
A comunicação entre os agentes e o WebService é unidirecional, ou seja, os dados coletados
são enviados do agente para o servidor, não sendo possível o caminho inverso. Deste modo,
caso ocorra uma falha interna ao agente, os dados de indisponibilidade e capacidade podem
sofrer inconsistências, já que o erro não está na infra-estrutura sendo monitorada e sim no
agente que não está cumprindo a sua função. Para tentar contornar este problema, os agentes
mantêm um histórico dos dados coletados dentro da máquina monitorada. Com isso, a equipe
de gerenciamento ao identificar a origem do problema e identificar a falha do agente, pode
recuperar estes dados e identificar a partir do histórico a última data e hora antes da falha
ocorrer.
3.2. REQUISITOS
A análise de requisitos está atrelada ao processo de descobrir quais são as funcionalidades
que o sistema deve ter e quais as suas restrições. Esta fase é importante, pois oferece uma
visão total do projeto, permitindo a visualização das partes relevantes (WAZLAWICK,
2004). Nesta seção serão apresentados os requisitos funcionais e não-funcionais da solução
proposta, baseados no Gerenciamento de Nível de Serviço, Gerenciamento de
Disponibilidade e de Capacidade apresentados no Capítulo II.
52
3.2.1. Funcionais
REF1. O sistema deve permitir que um usuário possa efetuar o login no sistema.
SLA
O SLA é o principal item dentro do Gerenciamento de Nível de Serviço. O estudo
apresentado na Seção 2.2 do Capítulo II auxiliará na identificação dos requisitos funcionais.
REF2. O sistema deve permitir o registro do nome, descrição e responsável pelo SLA.
SLA: Disponibilidade
O sistema deve permitir cadastrar os SLAs e informar a quantidade de horas de
indisponibilidade que determinado recurso monitorado pode sofrer. Com isso, as horas
planejadas de manutenção ou o funcionamento de alguns equipamentos só em determinado
horário podem ser feitos sem prejudicar o resultado real de indisponibilidade:
REF3. O sistema deve permitir o registro dos itens de disponibilidade.
REF4. O sistema deve permitir o registro das horas acordadas de cada item.
REF5. O sistema deve permitir o registro das horas de indisponibilidade planejada de
cada item.
REF6. O sistema deve listar os agentes coletores de disponibilidade disponíveis,
permitindo aos usuários escolher um.
REF7. O sistema deve calcular o valor percentual total de disponibilidade dos itens
cadastrados.
REF8. O sistema deve permitir o registro de um limiar de alerta.
REF9. O sistema deve permitir a exclusão de um item de disponibilidade.
SLA: Capacidade
REF10. O sistema deve permitir o registro do limiar de capacidade de uma CPU.
REF11. O sistema deve permitir o registro do limiar de capacidade de uma Memória.
REF12. O sistema deve permitir o registro do limiar de capacidade de um Disco
Rígido.
53
REF13. O sistema deve apresentar as partições disponíveis de um Disco Rígido.
REF14. O sistema deve listar os agentes coletores de capacidade disponíveis,
permitindo aos usuários escolher um.
REF15. O sistema deve permitir o registro de um limiar de alerta.
SLA: Configurações
REF16. O sistema deve permitir que o usuário informe o e-mail de destino do limiar de
alerta e/ou do não cumprimento do limiar acordado
REF17. O sistema deve permitir o registro dos dados de um servidor SMTP para o
envio dos e-mails de alerta e críticos.
REF18. O sistema deve permitir o envio de e-mail quando o limiar de alerta for
atingido.
REF19. O sistema deve permitir o envio de e-mail quando o limiar acordado
ultrapassar o valor acordado.
Agente Coletor de Dados
REF20. O sistema deve permitir o registro do nome e descrição do agente coletor.
REF21. O sistema deve permitir o registro do IP do servidor da base de dados.
REF22. O sistema deve permitir o registro do tempo de envio dos dados coletados.
REF23. O sistema deve permitir que o usuário inicie ou pare a atividade de
monitoramento e coleta de dados do agente.
REF24. O agente deve enviar os dados à base de dados no período determinado.
REF25. O sistema deve permitir alterar um agente existente.
Agente Coletor de Dados: Disponibilidade
REF26. O sistema deve permitir escolher o tipo de agente de disponibilidade de
hardware.
REF27. O sistema deve permitir escolher o tipo de agente de disponibilidade de
software.
REF28. O sistema deve listar os processos disponíveis no Sistema Operacional,
permitindo aos usuários escolher um para seu monitoramento de disponibilidade.
54
Agente Coletor de Dados: Capacidade
REF29. O sistema deve permitir escolher o item CPU, Memória e/ou Disco Rígido do
agente de capacidade.
Lista de SLAs em monitoramento
REF30. O sistema deve permitir listar o nome de cada SLA registrado.
REF31. O sistema deve permitir listar o status de alerta, crítico ou normal de cada SLA
registrado.
REF32. O sistema deve permitir listar o tempo total de indisponibilidade de cada SLA
registrado.
REF33. O sistema deve permitir listar o percentual de disponibilidade atual de cada
SLA registrado.
REF34. O sistema deve permitir listar o MTTR de cada SLA registrado.
REF35. O sistema deve permitir listar o MTBF de cada SLA registrado.
REF36. O sistema deve permitir alterar e excluir um SLA existente.
3.2.2. Não-Funcionais
RNF1. O módulo de cadastro e visualização de SLAs deve ser desenvolvido para a
plataforma web. Deste modo, o sistema pode ser acessado de qualquer lugar que
possua acesso a Internet. Apesar da segurança menor que a Internet trás, sua
facilidade e seus padrões bem definidos justificam a escolha (implementação).
RNF2. Os agentes serão implementados como um serviço do Sistema Operacional,
deste modo, o agente é configurado uma única vez, as demais vezes ele é reiniciado
junto com os serviços do Sistema Operacional. (implementação)
RNF3. A linguagem de programação web adotada deve ser a ASP .net, utilizando a
linguagem de programação C# nas classes de apoio dentro do servidor web. A escolha
é justificada pelo conhecimento mais aprofundado do acadêmico na linguagem e pela
obtenção gratuita de suas ferramentas (software).
RNF4. A linguagem de programação dos agentes independe de plataforma, desde que
possua meios de se comunicar com um WebService. (software).
RNF5. O servidor web adotado deve ser o IIS 5.1 ou superior, para atender ao
requisito RNF3 (software).
55
RNF6. O sistema deve ser compatível com as especificações da W3C de HTML e
Java Script (conformidade).
RNF7. As páginas web não devem levar mais do que 15 segundos para serem
carregadas em uma conexão de Internet compatível com 128 Kbps de transferência
(desempenho).
RNF8. O sistema não deve utilizar o recurso de pop-up dentro de suas páginas HTML
(usabilidade).
RNF9. A persistência de login e senha deve ser armazenada no servidor (segurança).
RNF10. O sistema gerenciador de banco de dados deve ser o Microsoft SQL Server
2005 Express (software).
RNF11. Os agentes devem ser instalados em computadores com os sistemas
operacionais Windows XP/Vista ou Linux Ubuntu 7.10 (software).
RNF12. A comunicação entre o agente e o servidor de banco de dados deve ser feita
utilizando Web Service (implementação).
3.3. REGRAS DE NEGÓCIO
Cada regra de negócio está associada a um requisito funcional, complementando as
necessidades de cada um deles, adicionando os atributos e conformidades necessárias para o
desenvolvimento da solução (WAZLAWICK, 2004):
RNE1. A aplicação deve ter dois atores: Gerente de SLA e Supervisor de SLA.
RNE2. As senhas serão sempre convertidas para letras maiúsculas.
RNE3. A senha deve ter tamanho mínimo de 6 caracteres e tamanho máximo de 14.
SLA
RNE4. Somente o Gerente de SLA pode criar/alterar/excluir um SLA.
RNE5. O usuário só pode registrar um SLA com dados de disponibilidade ou um só
com dados de capacidade. Um SLA não pode ter os dois dados em seu objetivo.
SLA: Disponibilidade
RNE6. As horas acordadas e de indisponibilidade planejada podem ter valor máximo
de 720, que corresponde ao produto da média de dias em um mês (30) com o número
de horas em um dia (24).
56
RNE7. Os agentes de disponibilidade listados para a escolha do usuário são aqueles
que estão cadastrados na base de dados.
RNE8. O valor percentual total de disponibilidade dos itens cadastrados é calculado a
partir do produto do percentual de cada item de disponibilidade inserido no SLA. O
item 2.3.4 exemplifica este cálculo.
RNE9. O limiar de alerta de disponibilidade deve ser inserido e registrado em forma
de um percentual, e deve ser menor que o limiar acordado com o cliente.
SLA: Capacidade
RNE10. O limiar de alerta de capacidade deve ser inserido e registrado em forma de um
percentual, e deve ser menor que o limiar acordado com o cliente.
RNE11. Os agentes de capacidade listados para a escolha do usuário são aqueles que
estão cadastrados na base de dados.
SLA: Configurações
RNE12. Os dados do servidor SMTP devem ser: endereço do servidor, e-mail de
origem, usuário e senha (caso o servidor exija autenticação).
Agente Coletor de Dados
RNE13. Os dados devem ser coletados pelo agente a cada segundo.
RNE14. Os dados coletados pelo agente devem ser registrados na máquina local e
enviados ao servidor de banco de dados a cada “n” segundos. O valor de “n” deve ser
informado pelo usuário durante o registro do SLA.
Agente Coletor de Dados: Disponibilidade
RNE15. Cada agente de disponibilidade pode monitorar somente um tipo de dado:
software ou hardware.
RNE16. Somente os agentes de disponibilidade de software têm a opção de escolher
um processo do Sistema Operacional para ser monitorado.
57
Agente Coletor de Dados: Capacidade
RNE17. Para agentes coletores de capacidade de CPU com mais de um núcleo de
processamento, o sistema deve fornecer a opção de escolher qual core deverá ser
monitorado. Para cada core deve se criado um agente diferente.
Lista de SLAs em monitoramento
RNE18. O sistema deve mostrar o status do SLA em forma de um ícone amarelo,
quando o este estiver dentro de um limiar crítico, vermelho para um SLA que não
cumpriu seu objetivo e verde para um SLA dentro dos limiares acordados.
RNE19. O tempo total de indisponibilidade, o MTTR e o MTBF de cada SLA
registrado devem ser apresentados no seguinte formato: HH horas MM Mins e SS
Segs.
RNE20. O percentual de disponibilidade atual de cada SLA registrado deve ser
calculado conforme a fórmula apresentada na Figura 9 da Seção 2.3.4.
RNE21. O cálculo das horas de um MTTR e um MTBF deve ser baseado na Figura 10
da Seção 2.3.4.
3.4. CASOS DE USO
Os processos de negócio da empresa mais relevantes são também chamados de casos de uso.
Eles cobrem as principais atividades do sistema que será desenvolvido, objetivando o
levantamento das informações sobre como o sistema interage com seus usuários
(WAZLAWICK, 2004). Nesta seção serão apresentados os atores do sistema, um diagrama
de caso de uso (Monitoramento de SLA) que representa o monitoramento dos SLAs e seu
detalhamento.
Os atores do sistema estão representados na Figura 16 e todos herdam suas funcionalidades
do ator-pai Operador. O Gerente de SLA representa o usuário que tem acesso total ao
sistema. Ele pode criar e excluir SLAs e ativar agentes coletores de dados. O Supervisor de
SLA tem seus privilégios limitados, pois seu objetivo é unicamente monitorar os SLAs
criados pelo Gerente de SLA. Ele também pode visualizar com detalhes um SLA criado.
58
Figura 16. USC-OO Atores do Sistema
3.4.1. Monitoramento de SLA
O caso de uso representado pela Figura 17 demonstra as permissões de acesso ao monitorar
os SLAs criados. O ator Operador, que representa ambos os usuários, Gerente e Supervisor,
pode acessar a lista de SLAs criados. Já o Gerente de SLA, além de visualizar a lista de SLAs
cadastrados, também pode alterar e excluir um SLA.
Figura 17. USC-04 Monitoramento de SLA
59
A Tabela 5 descreve o detalhamento do caso de uso representado pela Figura 17. A tabela
está estruturada em sete linhas:
� Descrição: breve comentário do objetivo do caso de uso.
� Atores: os usuários envolvidos no caso de uso.
� Requisitos associados: os requisitos funcionais e não-funcionais associados.
� Pré-condições: quais condições precisam ser satisfeitas para iniciar o caso de uso.
� Pós-condições: qual o estado no sistema após a execução do caso de uso.
� Fluxo principal e de Exceção: os passos que descrevem o seu uso e suas possíveis
alternativas e erros.
Tabela 5. USC-04 Monitoramento de SLA
Descrição: Permite que um operador possa visualizar todos os SLAs criados e acompanhar seu status de acordo com o acordado com o cliente.
Atores: Gerente de SLA, Supervisor de SLA
Requisitos associados: REF25-REF36,RNF7,RNF6
Pré-condições: O Gerente de SLA precisa estar logado no sistema. O Supervisor de SLA precisa estar logado no sistema.
Pós-condições: Uma lista de SLAs cadastrados é apresentada na tela.
Fluxos de Eventos Fluxo principal: 1. O sistema apresenta uma lista de SLAs cadastrado
ordenado pelo status. São apresentados os campos nome, status, indisponibilidade, disponibilidade, MTTR e MTBF. (Tela - Apêndice D.6)
2. O operador seleciona um SLA para visualizar. 3. O sistema apresenta a tela de cadastro do SLA com os
campos preenchidos.
Fluxo Exceção 1: O sistema permite ao Gerente de SLA excluir um SLA diretamente na tela: 1.1. O Gerente de SLA seleciona os indicadores e confirma. 1.2. O sistema exclui o(s) SLA(s) e volta para o item 1.
Foram apresentados nesta seção o digrama de atores e o caso de uso de monitoramento de
SLA. Os demais casos de uso estão detalhados no Apêndice 0:
� A.1 CONTROLE DE ACESSO: descreve o acesso dos usuários ao sistema.
� A.2 CADASTRO SLA: descreve a ação de cadastrar um SLA dentro do sistema.
60
� A.3 CRIAÇÃO DE AGENTES: é o processo de criação de um agente
3.5. DIAGRAMA DE CLASSE
O modelo conceitual é uma representação da visão que o usuário tem das informações
gerenciadas pelo sistema. Ele procura mostrar quais elementos de informação são tratados e
como eles são transformados pelo usuário a partir dos diferentes requisitos. Deste modo, o
modelo conceitual deve ser independente da solução física que virá a ser adotada e deve
conter somente elementos referentes ao domínio do problema. O resultado das análises feitas
durante a modelagem conceitual pode ser transportado para um diagrama de classes UML
(WAZLAWICK, 2004).
A Figura 18 representa as classes de entidade da solução proposta. Ela descreve o
relacionamento entre as entidades do sistema. Este modelo pode ser utilizado como base para
a criação do Diagrama de Entidade Relacionamento (ER). O Diagrama ER representa a
modelagem física das entidades descritas na Figura 18. Como este capítulo faz referência à
modelagem dos dados, o diagrama ER fará parte do TCC-II, quando a solução for
implementada e a base de dados for criada. As seguintes entidades foram identificadas a
partir dos casos de uso:
� Operador: esta é a entidade pai de um usuário. A partir desta classe, podem ser criados o
Gerente de SLA e o Supervisor de SLA. Seus atributos armazenam os dados do usuário.
� SLA: esta é a entidade pai, a partir desta classe podem ser criados o SLA de Capacidade
e de Disponibilidade. Seus atributos armazenam as configurações feitas dentro do
Cadastro de SLA (Apêndice A.2 - CADASTRO SLA).
� Item de Disponibilidade: dentro do SLA de Disponibilidade possui uma lista com todos
os itens de disponibilidade. Esta classe representa cada um destes itens. Seus atributos
armazenam os dados configurados dentro do Cadastro de SLA (Apêndice A.2 -
CADASTRO SLA).
� Agente: esta é a entidade pai, a partir desta classe podem ser criados os Agentes de
Disponibilidade e Capacidade. Esta classe armazena os dados coletados do ambiente a
ser monitorado.
61
Figura 18. Diagrama de Classe - Classes de Entidade
Nesta seção foi apresentado o diagrama de classe de entidade, os demais diagramas estão
apresentados no Apêndice B :
� B.1 CADASTRO DE SLA: relacionamento entre as entidades envolvidas no cadastro de
SLA.
� B.2 CRIAÇÃO DOS AGENTES: relacionamento entre as entidades envolvidas na
criação dos agentes coletores de dados de disponibilidade e capacidade.
62
� B.3 MONITORAMENTO: relacionamento entre as entidades envolvidas no
monitoramento dos SLAs.
� B.4 FUNCIONAMENTO DOS AGENTES: relacionamento entre as entidades envolvidas
no comportamento dos agentes coletores de dados de disponibilidade e capacidade
� B.5 CONTROLE DE ACESSO: relacionamento entre as entidades envolvidas na
autenticação do operador dentro do sistema.
3.6. DIAGRAMA DE SEQÜÊNCIA
O diagrama de seqüência é um modelo usado na análise de um sistema para representar o
comportamento dinâmico do sistema. Ele é formado a partir dos casos de uso e do diagrama
de classes. Os casos de uso representam o que é feito no sistema e por quem. O diagrama de
classes representa o que são as coisas do sistema. O diagrama de seqüência representa quem
faz o que com cada coisa e quando o faz (PESSÔA, et al., 2006). A Figura 19 demonstra o
diagrama de seqüência do monitoramento de um SLA. Ele representa interação entre o
operador e a página que lista todos os SLAs criados.
Figura 19. Diagrama de Seqüência - Monitoramento de SLA
63
Nesta seção foi apresentado o diagrama de seqüência do monitoramento de SLA, os demais
diagramas estão apresentados no apêndice C
� C.1 CONTROLE DE ACESSO: comportamento do controle de acesso.
� C.2 CADASTRO DE SLA - CAPACIDADE: comportamento do item de capacidade do
cadastro de SLA.
� C.3 CADASTRO DE SLA - DISPONIBILIDADE: comportamento do item de
disponibilidade do cadastro de SLA.
� C.4 CRIAÇÃO DOS AGENTES: comportamento da ativação de um agente coletor de
dados.
� C.5 FUNCIONAMENTO DO AGENTE CAPACIDADE: comportamento de um agente
coletor de capacidade, dentro do ambiente a ser monitorado.
� C.6 FUNCIONAMENTO DO AGENTE DISPONIBILIDADE: comportamento de um
agente coletor de disponibilidade, dentro do ambiente a ser monitorado.
3.7. DIAGRAMA ENTIDADE-RELACIONAMENTO
A Modelo de Entidade-Relacionamento define o documento freqüentemente usado pelo
Database Administrator (DBA) para organizar os requisitos da arquitetura do banco de
dados. Ele é fundamentado nos conceitos básicos de Entidade, Relacionamento e Atributo.
As Entidades representam as classes de objeto do mundo real, os Relacionamentos a
agregação entre duas ou mais entidades e os Atributos representam as propriedades
elementares das Entidades e/ou dos Relacionamentos (CAMPOS & VIEIRA, 2005). A Figura
20 apresenta o diagrama de Entidade-Relacionamento construído a partir das entidades
levantadas nos requisitos.
64
Figura 20. Diagrama Entidade-Relacionamento
Para este diagrama foram incluídas duas entidades novas em relação ao diagrama de classes
apresentado (Seção 3.5). A primeira entidade é denominada Historico_SLAs_Capacidade,
que é responsável pelo armazenamentos dos dados de capacidade vindos do WebService. A
outra entidade, denominada Historico_SLAs_Disponibilidade, também tem a mesma função
da anterior, porém os dados armazenados são o de disponibilidade. As tabelas aspnet_Users,
aspnet_Roles e aspnet_UsersInRoles são responsáveis pela autenticação dentro das páginas
Web, elas foram criadas para a utilização de componentes dentro do ambiente de
desenvolvimento e serão melhor explicadas no Capítulo IV.
3.8. TECNOLOGIAS UTILIZADAS
As tecnologias utilizadas no desenvolvimento do protótipo envolvem principalmente duas
ferramentas. Uma delas é o Microsoft Visual Studio 2005 Express (Figura 21Figura 21.
Ambiente de Trabalho do Visual Studio 2005), uma IDE de desenvolvimento para a
plataforma .net, onde foram implementados os módulos web e os agentes, utilizando a
linguagem de programação C# (C Sharp) e Active Server Pages (ASP). A outra ferramenta é
65
o Microsoft SQL Server 2005 Express, responsável pelo armazenamento dos dados. A
escolha das ferramentas deve-se à experiência de utilização do autor em seu meio
profissional. Ambas podem ser adquiridas de forma gratuita no site da Microsoft.
Figura 21. Ambiente de Trabalho do Visual Studio 2005
Para acomodar o WebService e as páginas Web foi utilizado o servidor Internet Information
Services (IIS) 6.0 (Figura 21Figura 22), que provê uma melhor integração com as tecnologias
citadas anteriormente para o desenvolvimento na plataforma .net.
66
Figura 22. Ambiente de Configuração do IIS 6.
Para o ambiente de testes montado para a avaliação do protótipo foram utilizados dois
computadores reais e dois computadores virtuais. Devido à falta de recursos disponíveis,
optou-se por adotar a utilização do conceito de máquina virtual ou virtualização. Uma
máquina virtual (VM) é como uma máquina abstrata, que permite que a máquina real seja
particionada de tal modo que diversos sistemas operacionais sejam executados ao mesmo
tempo. O software de máquina virtual cria um ambiente através de um monitor de máquina
virtual, que é um computador com seu próprio sistema operacional dentro de outro sistema
operacional (Host). Este monitor pode criar várias máquinas virtuais sem que nenhuma
interfira na outra e também não interfira no sistema real onde o software de máquina virtual
está instalado. A máquina virtual pode ser uma cópia do hardware da máquina real, fazendo
com que o sistema operacional na máquina virtual pareça estar executando diretamente sobre
um computador real. Cada máquina virtual trabalha como um PC completo, com BIOS e
Setup. (CAMPOS, 2003)
O software utilizado para a virtualização foi o Sun xVM Virtual Box 1.6. Sua escolha
justifica-se por ser um software gratuito e de uma empresa de renome com a Sun
Microsystems, fabricante do Java.
67
Figura 23. Tela do VirtualBox da Sun
3.9. ESTRUTURA DO PROJETO
O Visual Studio organiza os projetos dentro de uma hierarquia conforme a Figura 24. No
nodo pai da árvore está o nome da Solução (Solution), a partir dele são criados os demais
projetos. Uma Solução pode ser composta de diferentes tipos de projetos, como por exemplo,
Windows Application, Web Site e Mobile. A estrutura da solução implementada está
organizada em 5 (cinco) projetos:
� Agentes: é um projeto do tipo Windows Application, dentro dele estão organizadas as
classes responsáveis pela criação do Agente coletor de dados;
� SLAWeb: é um projeto do tipo Web Site, responsável pela criação das páginas ASP .net e
do WebService;
� DAL: este projeto é do tipo Class Library. Neste tipo de projeto são criadas classes de
negócios que quando compiladas viram um arquivo do tipo Dynamic-Link Library (DLL),
utilizado pelos demais projetos. No caso específico do projeto DAL, as suas classes são
responsáveis pelo acesso ao banco de dados, proporcionando uma interface de mais alto
nível para a troca de dados entre a interface e a base de dados;
� EntidadesSLA: este projeto Class Library é uma biblioteca que contém todas as
entidades levantadas no diagrama de classes (Seção 3.5) e no diagrama de Entidade-
Relacionamento (Seção 3.7). A partir de suas classes é possível criar objetos que refletem
as entidades da solução; e
68
� PCInfo: outro projeto do tipo Class Library, responsável pela captura dos dados de
capacidade do sistema operacional. Oferece interfaces para obtenção de dados de CPU,
Memória e Disco.
Figura 24. Projetos do Visual Studio
As próximas seções descreverão com mais detalhes o projeto Agentes (Seção 3.9.1) e o
projeto SLAWeb (Seção 3.9.2), já que os demais têm funções muito específicas e servem de
apoio para eles.
3.9.1. Projeto Agentes
No desenvolvimento do agente coletor de dados foram utilizadas duas threads10. A primeira
tem a função de coletar os dados de capacidade ou disponibilidade a cada segundo e a outra
de enviar esses dados para o WebService. À medida que a thread de coleta obtém os dados
selecionados, estes são armazenados em uma estrutura de dados do tipo Fila (Queue11). A
thread de envio consome esses dados e os envia para o WebService, de acordo com o tempo
informado pelo usuário. Paralelo a este processo, os dados coletados também são
armazenados no disco com o objetivo de criar um histórico local dos dados coletados. A
estrutura completa do projeto é apresentada na Figura 25.
10 É um procedimento executado independentemente do programa principal. Fonte: MIT (2000) 11 Estrutura de dados de comprimento variável, onde o primeiro elemento inserido é o último a ser eliminado ou retirado da pilha (First In Last Out). Fonte: VASCONCELOS (2004)
69
Figura 25. Estrutura Projeto Agentes
Uma vez executado o aplicativo Agente (Figura 26), este pode ser configurado para coletar
dados de capacidade ou de disponibilidade dos recursos computacionais. Além disso, o
usuário deve informar um identificador (ID) para o agente, o qual define a sua autenticação
junto ao WebService. Para um agente poder enviar seus dados, ele deve estar previamente
cadastrado no banco de dados. Os outros itens configuráveis são o tempo de envio, ou seja,
de quanto em quanto tempo a thread enviará os dados coletados ao servidor e também a
opção de poder iniciar o agente junto com o sistema operacional, permitindo que os dados
não sejam perdidos e conseqüentemente causem inconsistências no resultado do
monitoramento.
Figura 26. Tela Agente Coletor
70
Para os dados de capacidade (Figura 27), são apresentados três tipos de dados, conforme os
requisitos levantados: memória, processador e disco. Para computadores que possuem mais
de um processador ou processadores com mais de um núcleo, é apresentada uma lista
contendo os núcleos/processadores encontrados. Para a parte de disco também é apresentada
uma lista com as partições disponíveis.
Figura 27. Agente Coletor de Capacidade
Os agentes de disponibilidade (Figura 28) apresentam duas opções: software e hardware. No
primeiro, é apresentada uma lista com os processos do sistema operacional e no segundo,
somente a opção de hardware, pois os dados de disponibilidade contêm apenas informações
do tipo “estou ativo”.
71
Figura 28. Agente Coletor de Disponibilidade
Os dados ao serem coletados e enviados à fila de envio são formatados dentro de um
protocolo simples, criado para facilitar a comunicação entre os diversos tipos de agentes
(Windows, Linux, Mobile, etc.) e o WebService feito em .net. Portanto, ele não segue
nenhum modelo específico de protocolos de comunicação de redes. A estrutura dos
protocolos pode ser visualizada na Figura 29. Ambos os protocolos possuem como
informação inicial a data e hora da coleta, seguida de um caractere de separação “@” para os
campos de acordo com cada tipo de agente. O caractere de final de linha “$” indica que os
dados daquela data específica terminaram. O protocolo é inserido como uma única string
dentro da fila de envio, deste modo, os dados coletados são formatados dentro dos padrões
dos protocolos e concatenados para seu envio. Outras informações como o ID, são passadas
diretamente como parâmetro para o WebService.
Figura 29. Protocolo dos Agentes Coletores: (a) Capacidade; (b) Disponibilidade
3.9.2. Projeto SLAWeb
Dentro do projeto SLAWeb estão contidas todas as páginas web para o pleno gerenciamento
dos SLAs. Toda a parte de cadastro de agentes coletores, cadastro de usuários, cadastro de
72
SLAs, configurações de e-mail e monitoramento dos SLAs estão presentes neste projeto.
Além disso, dentro dele encontra-se o WebService responsável pelo recebimento dos dados
enviados pelos agentes coletores. A estrutura completa do projeto é apresentada na Figura 30.
Figura 30. Estrutura Projeto SLAWeb
Os dados que chegam dos diversos agentes espalhados pela rede interna ou pela internet são
recebidos pelo WebService denominado “wsServidorSLA”. Uma vez que os dados são
processados, a string contendo o protocolo de dados é quebrada de acordo com o caractere de
final de linha “$”. A partir deste momento, cada parte obtida é novamente separada, desta vez
pelo caractere“@”, e inserida dentro do banco de dados, representando uma informação de
disponibilidade ou capacidade em um determinado período de tempo.
Toda a análise dos dados de capacidade e disponibilidade é realizada em cima do banco de
dados que é alimentado pelos agentes coletores. Os cálculos são feitos utilizando funções do
SQL Server 2005 Express que são chamadas dentro de trechos de código da programação
embutida dentro da página de monitoramento. A vantagem de se trabalhar com dados depois
de armazenados, é a questão da segurança já intrínseca nos bancos de dados e a facilidade de
ser obter dados históricos de maneira mais rápida, através de consultas às tabelas do banco. A
desvantagem deste processo está na perda da agilidade obtida através de cálculos feitos em
tempo real diretamente na memória do computador.
73
A Figura 31 apresenta uma das funções utilizadas no projeto, denominada
“CalculoIndisponibilidadeSoftware”. Ela recupera os dados de um determinado SLA
informado no parâmetro da função, buscando pelos campos que têm a coluna “Ativo” com o
valor “0”, ou seja, quais horários o software ficou indisponível dentro do período do contrato
daquele SLA. Após isso, são calculados também os dados de indisponibilidade que não foram
coletados pelo agente, ou seja, caso o agente tenha sido fechado, intencionalmente ou não, os
dados não presentes na tabela são computados mesmo assim.
Figura 31. Função para Cálculo de Indisponibilidade de Software
As demais funções podem ser vistas no Apêndice E :
� E.1 CALCULO CAPACIDADE CPU ATUAL: calcula o valor atual do uso da CPU;
� E.2 CALCULO CAPACIDADE MEMORIA ATUAL: calcula o valor atual do uso da
Memória;
� E.3 CALCULO CAPACIDADE DISCO ATUAL: calcula o valor atual do uso do Disco;
� E.4 CALCULO CAPACIDADE CPU FORA LIMIAR: calcula a quantidade de vezes que
a CPU ultrapassou o valor permitido;
74
� E.5 CALCULO CAPACIDADE MEMORIA FORA LIMAR: calcula a quantidade de
vezes que a Memória ultrapassou o valor permitido;
� E.6 CALCULO CAPACIDADE DISCO FORA LIMAR: calcula a quantidade de vezes
que o Disco ultrapassou o valor permitido;
� E.7 CALCULO DISPONIBILIDADE HARDWARE: calcula o valor da disponibilidade
do hardware. Uso público;
� E.8 CALCULO DISPONIBILIDADE SOFTWARE: calcula o valor da disponibilidade
do software. Uso público; e
� E.9 CALCULO INDISPONIBILIDADE HARDWARE; calcula o valor da
indisponibilidade de hardware. Para uso dentro das funções de disponibilidade.
Para o sistema de autenticação do usuário dentro do protótipo foram utilizados componentes
embutidos no Visual Studio, denominado Login. Dentro deste componente existem várias
ferramentas para a automação das rotinas de autenticação e funções para níveis de permissão,
como LoginView que permite criar objetos específicos para cada tipo de usuário e
CreateUserWizard, que facilita a criação de usuários disponibilizando todas as interfaces e
funções de persistências dos dados do usuário. Ao utilizar estes componentes, são criadas
automaticamente tabelas dentro do banco de dados para o gerenciamento de toda a parte de
Login de um projeto do tipo ASP .net. Para este projeto (Figura 32) foram criadas duas
funções de usuário: Gerente e Supervisor para posteriormente criar os usuários em si. Como
determinado nos requisitos, a primeira função tem pleno acesso aos menus do protótipo e a
segunda somente à sua visualização.
75
Figura 32. Tela de Login do Protótipo
3.10. AMBIENTE DE TESTES
Como mencionado na Seção 3.8, foram montados 4 (quatro) computadores para realizar os
testes no protótipo desenvolvido. A Tabela 6 mostra uma lista dos computadores utilizados
nos testes realizados. Os dados apresentados mostram as informações mais relevantes desses
recursos. A primeira coluna mostra a identificação da máquina dentro do ambiente de testes.
A segunda coluna fornece as informações sobre a virtualização ou não de um determinado
recurso. A terceira coluna refere-se ao nome da máquina como apresentado dentro do Sistema
Operacional. A penúltima coluna apresenta o Sistema Operaciona em si e a última coluna
identifica quais agentes coletores de dados foram instalados para capturar as informações
necessárias.
Tabela 6. Computadores utilizados no Ambiente de Testes
Id. Virtual Nome SO Agente Coletor Comp. 1 Não SERVIDOR1 Windows Vista AG001 Comp. 2 Não SERVIDOR2 Windows XP SP2 AG002 Comp. 3 Sim VIRTUALPC-WINXP Windows XP AG003 Comp. 4 Sim VIRTUALPC-WINXP2 Windows XP AG004
76
3.10.1. Agentes
A lista dos agentes criados é apresentada conforme a Figura 33. O primeiro agente,
denominado AG001, foi criado para ser instalado no Computador de Teste 1. O agente
AG002 para o Computador de Teste 2 e assim por diante. Pode-se perceber pela Figura 33
que foram criados 3 agentes do tipo Disponibilidade e somente um com o tipo Capacidade.
Isso se deve ao fato de que foi criado um agente para cada SLA. Excetuando-se o primeiro
SLA, que foi configurado para receber dados de dois agentes (AG001 e AG002), os demais
têm somente um agente coletor associado.
Figura 33. Lista de Agentes Coletores Criados
3.10.2. SLAs
Após a criação dos indicadores, o próximo passo foi criar os SLAs que se utilizarão dos
agentes já cadastrados. Foram criados 3 SLAs conforme a Figura 34, um para cada tipo:
Contrato 001 do tipo Capacidade, Contrato 002 do tipo Disponibilidade de Hardware e o
Contrato 003 do tipo Disponibilidade de Software. Todos os SLAs cadastrados têm a mesma
vigência contratual. A data de inicio do contrato é de 01 de Junho até 01 de Julho. Já que os
requisitos do projeto indicavam um contrato de 30 dias.
77
Figura 34. Lista de SLAs Criados
Para o SLA Contrato 001 (Figura 35), do tipo Software, foram criados dois itens de
disponibilidade: o primeiro item possui uma disponibilidade acordada de 99,03%, tendo
como o responsável pela coleta de dados o agente denominado AG001; e o segundo item de
disponibilidade tem seu percentual acordado de 99,73%, sob responsabilidade do agente
AG004. Com isso, tem-se uma disponibilidade total, de acordo com as regras de negócio
deste projeto, de 98, 75% de disponibilidade acordada. O limiar de alerta ficou estabelecido
em 99%. Para efeitos de teste, o agente AG001 e AG004 coletaram dados referentes ao
processo “Explorer.exe” do sistema operacional Windows.
78
Figura 35. Configurações do SLA 001
Para o SLA Contrato 002 (Figura 36), do tipo Hardware, foi criado somente um item de
disponibilidade. O item possui uma disponibilidade acordada de 99,73%, tendo como o
responsável pela coleta de dados o agente denominado AG002. Com isso, tem-se uma
disponibilidade total igual a do item de disponibilidade acordada. O limiar de alerta ficou
estabelecido em 98%.
Figura 36. Configurações SLA 002
79
Para o SLA Contrato 002 (Figura 37), do tipo Capacidade foram configurados todos os itens
relevantes. O parâmetro “Minutos”, não referenciado no Capítulo III de Projeto, foi
identificado durante o desenvolvimento do protótipo. O dado de limiar em si não é suficiente
para expressar a capacidade. Então este novo campo foi criado para representar a intensidade
da capacidade, ou seja, por quanto tempo (em minutos) um item precisar estar acima do
limiar acordado para ser considerada uma quebra de contrato. O responsável pela coleta de
dados é o agente denominado AG003.
Figura 37. Configurações do SLA 003
Após os cadastros e configurações dos contratos, o ambiente para efetuar os testes com o
protótipo desenvolvido foi montado e pode ser então testado pelo profissional da área (Seção
3.11). Os agentes começaram a suas coletas a partir do dia 31 de maio, porém os dados só
foram relevantes a partir da primeira hora do dia 01 de junho, já que é a data do inicio dos 3
SLAs cadastrados para os testes. Como os dados são coletados a cada segundo, optou-se por
utilizar amostragem de um dia para reduzir a complexidade dos testes e facilitar a
visualização dos resultados. Com isso, a amostragem obteve 24 horas de coleta consecutivas
referentes ao dia 01 de junho de 2008.
80
3.11. TESTES E AVALIAÇÃO
O protótipo desenvolvido foi testado e avaliado pela empresa Relativa Soluções de
Florianópolis, que é uma empresa que presta consultorias e desenvolve produtos ITIL. Além
disso, ela é uma empresa membra da itSMF Brasil, que é responsável pela atualização e
divulgação da ITIL. O profissional envolvido na avaliação é Juano del Prado, sócio-diretor da
empresa. Ele é formado em engenharia eletrônica na CEFET-RJ, com diversos cursos na área
de TI, certificado em fundamentos ITIL, atuando a 24 anos na área de TI e dedicou-se nos
últimos 10 anos ao desenvolvimento, consultoria e treinamento em governança ITIL e
COBIT. Ele também é autor do software Relativa IT Manager, especializado nos processos
de Service Support e Service Delivery da ITIL. A escolha pela empresa Relativa justifica-se
pelo fato do acadêmico ser um colaborador da Relativa e também pelo fato da idéia inicial
deste protótipo ter surgido dentro da empresa.
3.11.1. Testes
Como os cadastros e configurações dos SLAs testados foram de responsabilidade do autor
deste trabalho (sob supervisão do avaliador) nas seções anteriores, os testes com o avaliador
obedeceram aos seguintes passos:
� O avaliador efetuou o login no sistema (protótipo);
� Visualizou a lista de agentes cadastrados;
� Visualizou a lista de usuários cadastrados;
� Visualizou a lista de SLAs cadastrados;
� Começou o monitoramento dos SLAs;
� Obteve os detalhes do SLA 001 e 002;
� Conferiu os dados dos gráficos produzidos;
� Conferiu os resultados de acordo com os requisitos e regras de negócio; e
� Preencheu o questionário de funcionalidade para uma ferramenta ITIL.
A Figura 38 apresenta os dados coletados no dia 01 de junho, desde as 00h00min até as
23h59min do item 1, para o SLA 001 de disponibilidade de software. Os valores exibidos
mostram a quantidade de segundos de indisponibilidade a cada hora. O gráfico apresenta um
valor máximo de 1398 segundos de indisponibilidade e mínimo de 1251 segundos. A média
para o período é de 1309,67 segundos. A soma dos segundos de indisponibilidade foi de
81
31432 segundos. Aplicando a fórmula apresentada na Figura 9 da página 34 para cálculo de
disponibilidade, obteve-se um resultado parcial (já que o contrato ainda estava vigente) de
98,78% de disponibilidade (Equação 1), onde o valor de 2566800 é a disponibilidade
acordada cadastrada de 713 horas convertidas para segundos.
Figura 38. SLA 001 (Item 1) - Qtde segundos indisponibilidade/hora
A Figura 39 apresenta os dados coletados no dia 01 de junho, desde as 00h00min até as
23h59min do item 2, para o SLA 001 de disponibilidade de software. O valor máximo
apresentado é de 1343 segundos de indisponibilidade e mínimo de 1261 segundos. A média
para o período é de 1305,13 segundos. A soma dos segundos de indisponibilidade foi de
31323 segundos. Aplicando a fórmula apresentada na Figura 9 da Página 34 para cálculo de
disponibilidade, obteve-se um resultado parcial de 98,79% de disponibilidade (Equação 2),
onde o valor de 2584800 é a disponibilidade acordada cadastrada de 718 horas convertidas
para segundos. Para que a disponibilidade do SLA 001 fosse testada, foi preciso ainda aplicar
o cálculo de disponibilidade total apresentado na Figura 11 da Página 36, resultando em um
valor total de disponibilidade de 97,578% (Equação 3).
Disponibilidade SLA 001.1 = ( (2566800-31483)/( 2566800) ) x 100 Equação 1
1150
1200
1250
1300
1350
1400
14500
0:0
0:0
0:0
00
01
:00
:00
:00
0
02
:00
:00
:00
0
03
:00
:00
:00
0
04
:00
:00
:00
0
05
:00
:00
:00
0
06
:00
:00
:00
0
07
:00
:00
:00
0
08
:00
:00
:00
0
09
:00
:00
:00
0
10
:00
:00
:00
0
11
:00
:00
:00
0
12
:00
:00
:00
0
13
:00
:00
:00
0
14
:00
:00
:00
0
15
:00
:00
:00
0
16
:00
:00
:00
0
17
:00
:00
:00
0
18
:00
:00
:00
0
19
:00
:00
:00
0
20
:00
:00
:00
0
21
:00
:00
:00
0
22
:00
:00
:00
0
23
:00
:00
:00
0
82
Disponibilidade SLA 001.2 = ( (2584800-31323)/( 2584800) ) x 100 Equação 2
Disponibilidade Total SLA 001 = (Equação 1 x Equação 2) / 100 Equação 3
Figura 39. SLA 001 (Item 2) - Qtde segundos indisponibilidade/hora
A Figura 40 apresenta os dados coletados no dia 01 de junho, desde as 00h00min até as
23h59min, para o SLA 002 de disponibilidade de hardware. O gráfico apresenta um valor
máximo de 220 e mínimo de 136 segundos. A média é de 166,75 segundos e a soma de 4002
segundos. Aplicando a fórmula apresentada na Figura 9 da página 34 para cálculo de
disponibilidade, obteve-se um resultado parcial de 99,845% de disponibilidade (Equação 4).
Disponibilidade SLA 002 = ( (2584800-4002)/( 2584800) ) x 100 Equação 4
1220
1240
1260
1280
1300
1320
1340
1360
00
:00
:00
:00
0
01
:00
:00
:00
0
02
:00
:00
:00
0
03
:00
:00
:00
0
04
:00
:00
:00
0
05
:00
:00
:00
0
06
:00
:00
:00
0
07
:00
:00
:00
0
08
:00
:00
:00
0
09
:00
:00
:00
0
10
:00
:00
:00
0
11
:00
:00
:00
0
12
:00
:00
:00
0
13
:00
:00
:00
0
14
:00
:00
:00
0
15
:00
:00
:00
0
16
:00
:00
:00
0
17
:00
:00
:00
0
18
:00
:00
:00
0
19
:00
:00
:00
0
20
:00
:00
:00
0
21
:00
:00
:00
0
22
:00
:00
:00
0
23
:00
:00
:00
0
83
Figura 40. SLA 002 - Qtde segundos indisponibilidade/hora
Os dados apresentados na Figura 41 referem-se ao SLA 003, de 01 de junho, no período da
00h00min até as 23h59min. Os pontos máximos observados foram de 66,25% para a CPU,
91,83% para a Memória e 92,40% para o Disco. Para os pontos mínimos os valores são de
58,74 de CPU, 52% para a Memória e 92,11% para o Disco. No cadastro deste SLA, foram
configurados 60 minutos para a intensidade da capacidade de CPU e Memória. O limiar de
alerta foi de 80% para CPU e 70% para Memória. O limiar crítico foi de 90% para CPU e
80% para Memória. O limiar de alerta para disco foi de 60% e o crítico de 70%. Para que o
SLA não seja cumprido, basta que as seguintes condições sejam satisfeitas: a porcentagem de
utilização de CPU permanecer mais de 60 minutos dentro do limiar de 90%; a porcentagem
de utilização de Memória permanecer mais de 60 minutos dentro do limiar de 80%; ou a
porcentagem de utilização de disco atingir o limiar de 70% de ocupação.
Figura 41. SLA 003 - Histórico de utilização dos recursos
0
50
100
150
200
250
0,00
20,00
40,00
60,00
80,00
100,00
00
:00
:00
:00
0
02
:00
:00
:00
0
04
:00
:00
:00
0
06
:00
:00
:00
0
08
:00
:00
:00
0
10
:00
:00
:00
0
12
:00
:00
:00
0
14
:00
:00
:00
0
16
:00
:00
:00
0
18
:00
:00
:00
0
20
:00
:00
:00
0
22
:00
:00
:00
0
CPU
Memória
Disco
84
Os dados apresentados até o momento foram coletados diretamente do banco de dados, que
por sua vez, foi alimentado pelos agentes coletores de cada SLA testado. A Figura 42 mostra
a tela apresentada ao avaliador no final do processo. O SLA 001 teve um limiar acordado de
98,752%, que no final do dia, já tinha quebrado o acordo firmado, apresentando um valor de
97,578%. O SLA 002, que teve um acordo de 99,72% de disponibilidade, foi o único até o
final da amostra que manteve o acordo do contrato. O SLA de capacidade 003 teve os seus 3
itens de configuração (CPU, Memória e Disco) acima do limite acordado durante 60 minutos,
o que feriu também o seu contrato firmado.
Figura 42. Monitoramento SLA
Existem dois cálculos que não puderam ser testados por serem, de certa forma, dispendiosos
ao ponto de vista de quem está testando. São os cálculos de MMTR (Downtime) e MTBF
(Uptime). Na tela de monitoramento existe um link para cada SLA do tipo Disponibilidade, a
qual leva para a página de detalhes do SLA. Dentro dela é apresentada a indisponibilidade
total em frações de horas, calculo do MTTR e do MTBF. A Figura 43 apresenta os cálculos
do SLA 001, ondem exitem dois itens de disponibilidade e a Figura 44 os cálculos do SLA
002.
85
Figura 43. SLA 001 - Detalhes do Contrato
Figura 44. Detalhes monitoramento SLA 002
Conforme os parágrafos anteriores, segundo o avaliador, os dados e o status mostrados na tela
foram os mesmos calculados através das equações e dos gráficos apresentados. Com isso, o
avaliador concluiu que os testes aplicados para a amostragem de 1 dia de coleta (ou 86400
segundos) satisfizeram os requisitos apresentados no Capítulo III para o monitoramento de
capacidade e disponibilidade. Por questões de tempo do avaliador da área, não foi possível
criar uma massa maior de testes, incluindo mais amostras em períodos diferentes.
3.11.2. Avaliação
Além dos testes com o protótipo desenvolvido, foi sugerido pelo profissional avaliador à
utilização de questionários utilizados para a certificação de empresas nas boas práticas da
ITIL, com o objetivo de avaliar melhor os seus requisitos. A empresa referência, segundo o
avaliador, é a Pink Elephant, que implementa no Brasil o selo de certificação PinkVERIFY,
responsável pela comprovação da compatibilidade de softwares com o modelo de referência
ITIL. A certificação prevê adequação às necessidades de nichos específicos, como
ferramentas especializadas em distribuição (Mudança e Liberações) ou monitoração de
serviços (Capacidade e Disponibilidade).
86
Segundo Pink Elephant (2008), o PinkVERIFY não mede a conformidade com o modelo
ITIL, já que a ITIL não é um padrão e sim um conjunto de melhores práticas que deve ser
adaptado de forma a endereçar as necessidades específicas de cada organização. Dessa forma
o PinkVERIFY avalia a compatibilidade da ferramenta com o modelo ITIL. Para adquirir o
selo é preciso então, preencher questionários que trazem os critérios de certificação. O
conteúdo é analisado, pelos consultores da Pink Elephant, que fazem uma auditoria e avaliam
a ferramenta do proponente, concedendo ou não o certificado ao final da etapa. A certificação
pode ser obtida em quatro níveis: Service Support, Service Support Enhanced, Service
Monitoring e Service Deployment.
Como o intuito deste protótipo não é adquirir uma certificação, optou-se então pela a
utilização do material da Pink Elephant para servir como modelo de referência na avaliação
conceitual do protótipo. Cada questionário é divido em três seções: Critérios Obrigatórios
(Mandatory Criteria), Critérios de Integração (Integration Criteria) e Critérios funcionais
(Functional Criteria). O primeiro refere-se aos requisitos básicos de um processo específico,
o segundo são os requisitos de integração com os outros serviços de gerenciamento da ITIL e
o terceiro são critérios não requeridos para a avaliação final do PinkVerify, mas são de
interesse da comunidade itSMF (PINK ELEPHANT, 2008).
Foram utilizados 3 questionários PinkVerify para a avaliação do protótipo pelo profissional:
� Capacity Management: faz parte do nível Service Monitoring e possui 14 perguntas de
Critérios Obrigatórios, 4 perguntas de Critérios de Integração e 3 perguntas de Critérios
Funcionais;
� Availability Management: também faz parte do nível Service Monitoring e possui 9
perguntas de Critérios Obrigatórios, 6 perguntas de Critérios de Integração e 3 perguntas
de Critérios Funcionais; e
� Service Level Management: faz parte do nível Service Support Enhanced e possui 8
perguntas de Critérios Obrigatórios, 4 perguntas de Critérios de Integração e 3 perguntas
de Critérios Funcionais.
87
As próximas seções apresentam os 3 questionários completos12 com as respostas do avaliador
com base nos testes aplicados na Seção 3.10. A Seção 3.11.3 apresenta o questionário de
Gerenciamento de Capacidade, a Seção 3.11.4 apresenta o questionário de Gerenciamento de
Disponibilidade e a Seção 3.11.5 apresenta o questionário de Gerenciamento de Nível de
Serviço.
3.11.3. Questionário de Gerenciamento Capacidade
Critérios Obrigatórios
1. A ferramenta facilita o registro de todos os dados de capacidade relevantes em um
repositório? Por exemplo: habilidade de armazenar Serviço, Sistema e componentes de
utilização de dados.
Sim. Os dados coletados por agentes dentro e fora da rede local e seus dados são
armazenados no banco de dados.
2. A ferramenta facilita a comparação entre os níveis de utilização contra os limiares
definidos pelo cliente? Por exemplo: Real vs. uso previsto pelo parâmetro dado por um
componente; Ex.: Uso da CPU.
Sim. O usuário pode definir no ato da configuração/cadastro um limiar de alerta. Ao
monitorar os dados, figuras em cores vermelho (crítico), amarelo (alerta) e verde (ok) que
identificam e servem de parâmetro de comparação com os dados atuais e informados.
3. A ferramenta facilita a comparação das métricas dos Processos de Negócio entre os
níveis de utilização dos clientes contra os limiares definidos? Por exemplo: Como será o
crescimento das expectativas dos recursos individuais impactantes nos negócios que
compõem o Serviço?
Não. Este requisito não faz parte do escopo do protótipo.
4. A ferramenta facilita as medidas de tempo de resposta fim-a-fim? Por exemplo: coleta
informações em todos os níveis de infra-estrutura para prover medidas de desempenho de um
serviço, como percebido pelo usuário final.
12
Os questionários originais em inglês podem ser baixados gratuitamente no site https://www.pinkelephant.com/pt-BR/ResourceCenter/PinkVerify/
88
Parcialmente. Coleta dados de CPU, Memória e Disco, que podem influenciar no
desempenho final de um serviço do usuário.
5. A ferramenta possui mecanismos para auto-regular o consumo dos recursos
(Footprint) no ambiente monitorado, evitando impactos adversos na produção?
Não. Este requisito não faz parte do escopo do protótipo.
6. A ferramenta facilita o monitoramento de diferentes plataformas ou domínios com o
intuito de facilitar o monitoramento de um sistema completo de TI? Por exemplo:
habilidade de selecionar itens de configuração (CI) específicos de uma série de domínios
técnicos para então agregar os dados de capacidade destes para um objeto de sistemas lógicos
no suporte de SLAs.
Parcialmente. O protótipo só pôde ser testado em ambiente Windows.
7. A ferramenta provê meios de facilitar o controle da freqüência e formato das
atividades monitoradas? Por exemplo: definindo a hora do dia em que a coleta ocorrerá, e
descartado períodos irrelevantes como finais de semana e horários não comerciais.
Parcialmente. Podem-se definir os períodos de indisponibilidade em horas totais durante a
vigência do SLA, mas não é permitido definir dias.
8. A ferramenta facilita as análises de tendência, provendo fácil acesso ao histórico de
dados de capacidade baseados em tempo?
Parcialmente. O protótipo não disponibiliza uma interface de visualização de relatórios, mas
os seus dados históricos estão totalmente acessíveis e podem ser utilizados por ferramentas
externas para a criação de relatórios.
9. A ferramenta facilita a modelagem de componentes chaves de acordo com o volume
dos processos de negócio? Por exemplo: Como um crescimento de 10% nos negócios teria
um impacto na infra-estrutura de apoio?
Não. Este requisito não faz parte do escopo do protótipo.
10. A ferramenta facilita a identificação de diferentes fontes de consumo para cada
carga de trabalho? Por exemplo, provendo o consumo de CPU para o Serviço A e o Serviço
B dentro do mesmo host?
89
Parcialmente. O consumo é identificado para cada host e não para serviços dentro do host
(computador).
11. A ferramenta facilita a coleta de dados para medir os níveis de capacidade dos
componentes da infra-estrutura usados para prover serviços?
Sim. São utilizados agentes coletores de dados que se comunicam com o servidor, que por
sua vez provêm ferramentas de monitoramento de CPU, Memória e Disco.
12. A ferramenta facilita a análise dos recursos de contenção ao longo de um período de
tempo indicado? Por exemplo, dando informações de qual recurso uma thread específica é
dependente para finalizar sua tarefa.
Não. Este requisito não faz parte do escopo do protótipo.
13. A ferramenta está de acordo com os padrões abertos, facilitando o acesso aos dados
de capacidade armazenados no CDB através de ferramentas externas de relatório? Por
exemplo, permitindo que os dados sejam pesquisados através de comandos SQL.
Sim. Os dados históricos de capacidade estão disponíveis através de comandos padrões SQL.
14. A ferramenta facilita a geração de relatórios? Por exemplo, provendo meios de criar
relatórios, disponibilizando templates embutidos, gráficos, etc.
Não. Este requisito não faz parte do escopo do protótipo.
Critérios de Integração (Gerenciamento de Incidentes)
15. A ferramenta facilita a integração com o monitoramento da capacidade, e também
com a criação de tickets de incidente dentro de uma ferramenta de gerenciamento de
incidente?
Não. Este requisito não faz parte do escopo do protótipo.
Critérios de Integração (Gerenciamento de Configuração)
16. A ferramenta facilita o monitoramento de serviços de TI no suporte de objetos e
projetos de modelo de dados do CMDB? A ferramenta deve facilitar a capacidade na
modelagem de sistemas de TI à medida que são definidos no CMDB. Por exemplo: Sistemas
90
de Aplicação = todos os hardwares e softwares necessários para a construção e entrega de
uma solução de TI ao cliente.
Não. Este requisito não faz parte do escopo do protótipo.
Critérios de Integração (Gerenciamento de Disponibilidade)
17. A ferramenta facilita a integração com a ferramenta de monitoramento de
disponibilidade, para correlacionar e comparar dados de capacidade e disponibilidade
coletados para os mesmo CIs?
Parcialmente. O protótipo foi modelado para criar um SLA pra Capacidade ou um pra
Disponibilidade, e não os dois itens em um único SLA.
Critérios de Integração (Gerenciamento de Nível de Serviço)
18. A ferramenta facilita o monitoramento de capacidade e de níveis de desempenho
ajudando no suporte aos acordos e metas dos SLAs?
Sim. É criado um SLA de capacidade com os limiares acordados e de alerta. Depois se
podem monitorar os limiares dentro do período de tempo acordado.
Critérios Funcionais
19. A ferramenta suporta grandes volumes de dados históricos sem prejudicar o uso das
informações armazenadas? Por exemplo, provendo mecanismos de otimização ou
compressão para armazenar grandes volumes de dados.
Parcialmente. O banco de dados SQL Server 2005 escolhido suporta grandes quantidades de
dados, porém não foi criado nenhum mecanismo de otimização ou compressão dos dados
armazenados.
20. A ferramenta facilita a modelagem, dimensionamento e teste de carga das
aplicações? Por exemplo, provendo flexibilidade, interface amigável, capacidade de
modelagem, a ferramenta suportará o desenvolvimento de critérios de capacidade para um
novo sistema ou um sistema modificado sendo incorporado ao ambiente de produção.
Não. Este requisito não faz parte do escopo do protótipo.
91
21. A ferramenta incorpora características para facilitar o planejamento e modelagem
dos componentes chaves de infra-estrutura? Por exemplo, apoiando a modelagem
preditiva e apoio nas questões do tipo “se”.
Não. Este requisito não faz parte do escopo do protótipo.
3.11.4. Questinário de Gerenciamento de Disponibilidade
Critérios Obrigatórios
22. A ferramenta facilita o monitoramento de itens de configuração (CI) de
disponibilidade individuais?
Sim. Foram criados agentes coletores de dados de disponibilidade de hardware, que enviam
o status de disponibilidade de cada item de configuração para o servidor, que realiza o
acompanhamento dos SLAs.
23. A ferramenta facilita o monitoramento de um sistema ou grupo de CIs
relacionados? Por exemplo, servidores NT rodando MS Exchange.
Sim. Foram criados agentes coletores de dados de disponibilidade de software (MS
Exchange), que enviam o status de disponibilidade de cada item de configuração para o
servidor, que realiza o acompanhamento dos SLAs.
24. A ferramenta facilita o monitoramento e o cálculo de disponibilidade dos serviços
fim-a-fim de TI percebidos pelo cliente? Por exemplo: Messaging, arquivo e impressora,
etc.
Sim. Qualquer processo do sistema operacional pode ser monitorado e sua disponibilidade
calculada.
25. Os arquivos de disponibilidade são armazenados de uma forma que sejam
facilmente acessíveis para análises históricas e relatórios?
Sim. Os dados históricos de disponibilidade são armazenados no banco de dados com sua
respectiva data e hora. Sendo acessível através de comandos SQL padrão.
26. A ferramenta facilita a criação de relatórios personalizados sobre dos itens de
configuração, sistema e disponibilidade de serviços?
92
Parcialmente. O protótipo não disponibiliza uma interface de visualização de relatórios, mas
os seus dados históricos estão totalmente acessíveis e podem ser utilizados por ferramentas
externas para a criação de relatórios.
27. A ferramenta incorpora ou tem vínculos com eventos e software de gerenciamento
de sistemas para monitorar vários níveis de infra-estrutura de TI como: camada de
rede, camada de hardware, camada de sistema operacional e camada de aplicação?
Parcialmente. O protótipo avaliado coleta dados somente na camada de aplicação.
28. É possível configurar limites automáticos e ativar alertas se os limiares de
disponibilidade são feridos?
Sim. Para cada SLA criado, pode-se configurar o envio de e-mails quando os limiares de
disponibilidade forem atingidos. Pode-se enviar um e-mail para limiares de alerta e para
quando o limiar acordado não for mais cumprido.
29. A ferramenta é capaz de solicitar uma intervenção humana baseada na quebra dos
limiares, oferecendo uma gama de opções dependendo do impacto e severidade do
evento?
Não. A única interação humana é no envio de e-mails quando os limiares de alerta e crítico
forem atingidos, ou no monitoramento em si dos SLAs através de ícones de status.
30. A ferramenta é capaz de medir os seguintes elementos? Tempo Médio de Reparo
(MTTR), Tempo Médio Entre Falhas (MTBF), Tempo Médio Entre Incidentes (MTBI),
número de degradação de serviços e tempos de manipulação/resolução de incidentes.
Parcialmente. Para cada item de disponibilidade é calculado o MTTR e o MTBF somente.
Os demais itens não foram implementados no protótipo avaliado.
Critérios de Integração (Gerenciamento de Incidentes)
31. A ferramenta provê vínculos com os alertas do sistema de monitoramento para
registrar degradações de disponibilidade como registros de incidente dentro da
ferramenta de gerenciamento de incidente?
Não. Este requisito não faz parte do escopo do protótipo.
93
32. A ferramenta de Gerenciamento de Incidentes permite a identificação de incidentes
causados por terceiros, facilitando a Gerenciamento de contratos de apoio com
provedores de serviço?
Não. Este requisito não faz parte do escopo do protótipo.
Critérios de Integração (Gerenciamento de Problemas)
33. A ferramenta facilita a identificação da confiabilidade da infra-estrutura através da
detecção de quais itens de configuração causam as repetidas degradações do serviço?
Parcialmente. Através do histórico de disponibilidade presente no banco de dados, podem-se
criar relatórios de degradações de serviços.
Critérios de Integração (Gerenciamento de Mudanças)
34. A ferramenta facilita as avaliações do gerenciamento de mudança em relação à
análise de risco e impacto dos serviços de disponibilidade? Exemplo: relacionamento de
CIs, partes críticas dos negócios, efeito sobre o SLA, ETC.
Não. Este requisito não faz parte do escopo do protótipo.
Critérios de Integração (Gerenciamento de Configuração)
35. A ferramenta facilita a identificação de CIs relacionados como se fosse parte de um
sistema maior de CIs? Exemplo: servidores NT rodando MS Exchange.
Parcialmente. Um conjunto de CIs de hardwares ou softwares pode formar um único SLA.
36. A ferramenta facilita a identificação de CIs relacionados, como se fosse parte de um
serviço de TI constituído de vários sistemas de TI? Exemplo: Messenger, arquivos e
impressoras, etc.
Parcialmente. Um conjunto de CIs de hardwares ou softwares pode formar um único SLA.
Critérios Funcionais
37. A ferramenta incorpora rápida recuperação e modelagem de disponibilidade?
Facilita a identificação de pontos únicos de falha dentro de um modelo de infra-
estrutura? Modela os efeitos sobre os níveis de disponibilidade quando novos CIs são
94
alterados, removidos ou adicionados? Compara (“se”) cenários com o intuito de identificar
as opções mais eficazes.
Não. Este requisito não faz parte do escopo do protótipo.
38. A ferramenta facilita a reparabilidade da infra-estrutura e a obtenção de serviços
através do registro, administração e monitoramento dos contratos de manutenção e
contrato relacionados aos CIs?
Não. Este requisito não faz parte do escopo do protótipo.
39. A ferramenta facilita a determinação do custo da indisponibilidade dos serviços?
Não. Este requisito não faz parte do escopo do protótipo, mas pode ser facilmente
implementável.
3.11.5. Questinário de Gerenciamento de Níveis de Serviço
Critérios Obrigatórios
40. A ferramenta facilita o registro de descrição e catalogação de serviços? Por exemplo:
habilidade de definir catálogo/lista de serviços, habilidade de definir atributos de elementos
de serviços padrões (descrição dos níveis de qualidade que podem ser monitorados e criados
relatórios).
Não. Este requisito não faz parte do escopo do protótipo.
41. A ferramenta facilita a associação de serviços para funções de negócios específicas
baseadas na utilização ou assinatura? Por exemplo: habilidade de construir um catálogo ou
uma lista de serviços para uma linha de negócios específica.
Não. Este requisito não faz parte do escopo do protótipo.
42. A ferramenta facilita a entrada de metas de SLAs em termos de requisitos
operacionais? Por exemplo: habilidade de registrar uma quantidade específica de níveis de
qualidade a serem monitorados.
Sim. O protótipo permite a entrada de metas através dos limiares acordados com o cliente.
95
43. A ferramenta gerencia o planejamento de um ciclo de revisões e tempo de vida de
um SLA?
Não. Este requisito não faz parte do escopo do protótipo.
44. A ferramenta facilita o desenvolvimento e monitoramento de contratos de apoio com
terceiros assim como OLAs internas?
Não. Este requisito não faz parte do escopo do protótipo.
45. A ferramenta facilita a verificação e consistência dos SLAs em seus relacionamentos
com os contratos de apoio e OLAs? Por exemplo, tendo certeza que os tempos de
resposta dos incidentes na OLA não são maiores do que o prometido no SLA com o
cliente?
Não. Este requisito não faz parte do escopo do protótipo.
46. A ferramenta automatiza o monitoramento dos limiares de entrega de serviços em
comparação aos definidos no SLA?
Sim. Após o cadastro dos limiares acordados com o cliente em um SLA, eles são monitorados
e seu status é exibido de acordo com os níveis de serviços definidos no contrato.
47. A ferramenta facilita a criação de relatórios dos requisitos de SLA? Por exemplo,
relatórios de realização de serviços em comparação aos SLAs, relatório de explicações de
quebra de contratos (SLA) e de exceções de serviços?
Parcialmente. O protótipo não disponibiliza uma interface de visualização de relatórios, mas
os seus dados históricos estão totalmente acessíveis e podem ser utilizados por ferramentas
externas para a criação de relatórios.
Critérios de Integração (Gerenciamento de Incidentes)
48. A ferramenta provê acesso ao Gerenciamento de Incidentes para suporte às
informações de ajustes de TI do SLA? Por exemplo, metas de resposta e resolução por
serviço ou cliente.
Não. Este requisito não faz parte do escopo do protótipo.
Critérios de Integração (Gerenciamento de Problemas)
96
49. A ferramenta provê informações do SLA para o Gerenciamento de Problemas?
Não. Este requisito não faz parte do escopo do protótipo.
Critérios de Integração (Gerenciamento de Mudanças)
50. A ferramenta provê acesso ao SLA para a Gerenciamento de Mudanças? Por
exemplo, acesso aos detalhes do SLA, janelas de implementação, períodos de blackout e
requisitos de disponibilidade.
Não. Este requisito não faz parte do escopo do protótipo, mas pode facilitar a obtenção dos
requisitos de disponibilidade através dos contratos cadastrados.
Critérios de Integração (Gerenciamento de Configuração)
51. A ferramenta facilita as ligações dos atributos de impacto do CI assim como CIs
críticos ou VIPs para SLAs?
Não. Este requisito não faz parte do escopo do protótipo.
Critérios Funcionais
52. A ferramenta facilita a captura de dados de várias fontes fornecendo uma visão
geral dos serviços de entrega fim-a-fim? Por exemplo, a habilidade de extrair estatísticas de
desempenho e relatórios das fontes de disponibilidade do sistema.
Parcialmente. Um SLA de disponibilidade, por exemplo, pode capturar dados de diversas
fontes para montar um único cenário de disponibilidade. O protótipo não disponibiliza uma
interface de visualização de relatórios, mas os seus dados históricos estão totalmente
acessíveis e podem ser utilizados por ferramentas externas para a criação de relatórios.
53. A ferramenta facilita a produção de sumários gráficos de serviço em tempo real,
incluindo a identificação de limiares não cumpridos?
Sim. O módulo de monitoramento do protótipo avaliado exibe uma lista de SLAs cadastrados
de disponibilidade e capacidade. Ao lado de cada SLA é exibido um indicador gráfico do tipo
semáforo, onde verde representa que o SLA está sendo cumprido, amarelo indica que o
limiar de alerta foi atingido e vermelho indica que os limiares acordados com o cliente não
foram ou não estão sendo cumpridos até aquele momento.
97
54. A ferramenta facilita a customização de relatórios para um público específico?
Parcialmente. O protótipo não disponibiliza uma interface de visualização de relatórios, mas
os seus dados históricos estão totalmente acessíveis e podem ser utilizados por ferramentas
externas para a criação de relatórios.
3.12. RESULTADOS
Através das respostas produzidas pelo avaliador da área, foram computados na Tabela 7 os
dados referentes à quantidade de respostas que atenderam, não atenderam ou atenderam
parcialmente os critérios de cada questionário aplicado. Pode-se perceber que o percentual de
critérios não atendidos no questionário de Nível de Serviço é maior do que os demais. Isto é
justificável pelo próprio escopo deste projeto, que é direcionado ao gerenciamento de
capacidade e disponibilidade da ITIL. Os percentuais de critérios atendidos de Capacidade e
Disponibilidade apresentam o menor índice já que o protótipo desenvolvido não é focado só
em um tipo de gerenciamento. O objetivo do protótipo é abranger, dentro de um SLA os itens
de Disponibilidade e Capacidade. E por isso, a porcentagem de critérios não atendidos é
significativa.
Tabela 7. Tabela de Resultados dos Questionários de Avaliação
Questionário Sim Parcial. Não Total % Atend % Parcial. % Não Gerenciamento de Capacidade
5 7 9 21 23,81 33,33 42,86
Gerenciamento de Disponibilidade
5 6 7 18 27,78 33,33 38,89
Gerenciamento de Nível de Serviço
3 3 9 15 20,00 20,00 60,00
Para que os percentuais de atendimento dos critérios fossem maiores, o protótipo teria que se
especializar em uma área específica dos gerenciamentos da ITIL. Cada gerenciamento em si
já é complexo o suficiente e pode ser convertido em um software com maior robustez,
atendendo de maneira plena os gerentes de disponibilidade, capacidade ou de níveis de
serviço. A Figura 45 apresenta um gráfico extraído da Tabela 7, ilustrando melhor os
resultados dos questionários PinkVERIFY aplicados nesta avaliação.
98
Figura 45. Gráfico de Resultados dos Questionários de Avaliação
Ainda contemplando os dados da Tabela 7, percebe-se uma média de critérios atendidos no
valor de 23,86%. Este valor corresponde à média dos 3 questionários, e analisando este
número, segundo o avaliador da área, pode-se considerar um valor significativo. Primeiro,
porque se trata de um protótipo e segundo porque, como comentando anteriormente, o
protótipo abrange um pouco de cada uma das áreas de gerenciamento contidas nos objetivos
específicos deste trabalho. Outro número que deve ser bastante considerado é o percentual
médio de critérios parcialmente atendidos. O valor deste número é de 28,88%, ou seja, para o
protótipo amadurecer e virar um produto comercialmente viável, ele pode concentrar os seus
esforços em atender esses requisitos. Isto tornaria o protótipo um produto com um pouco
mais da metade dos requisitos desejáveis no mercado para um software ser compatível com
as boas práticas da ITIL.
Como mencionado, pode-se considerar ao analisar os resultados obtidos através da aplicação
do questionário, que o protótipo atende a 23,86% dos requisitos necessários para que um
software ITIL seja considerado totalmente compatível com o determinado gerenciamento ou
serviço a que se propõe. Além disso, o protótipo atende parcialmente a 28,88% dos requisitos
dentro dos 3 gerenciamentos e precisa contemplar 47,25% dos requisitos para que o protótipo
possa ser considerado um software 100% ITIL no completo gerenciamento de Capacidade,
Disponibilidade e de Nível de Serviço.
0
1
2
3
4
5
6
7
8
9
Gerenciamento de
Capacidade
Gerenciamento de
Disponibilidade
Gerenciamento de
Nível de Serviço
Atende
Atende Parcialmente
Não Atende
99
Outro fator importante que foi levantado pelo avaliador da área, é que os questionários da
Pink Elephant são destinados a garantir a compatibilidade de produtos para cada
gerenciamento da ITIL. Se o protótipo fosse focado no completo gerenciamento da
Capacidade, por exemplo, o questionário de Capacidade teria um resultado mais significativo.
Com isso, a empresa que optar por adquirir o selo PinkVERIFY, tem no questionário um guia
de referência para que o seu software atinja a maturidade necessária. Sendo ela, referência no
mercado por ter um software que ajuda a área de TI no gerenciamento pleno de sua infra-
estrutura, sempre se guiando dentro das boas práticas empregadas na ITIL.
4. CONCLUSÕES
O objetivo deste Trabalho de Conclusão de Curso foi desenvolver, como solução proposta,
um protótipo de monitoramento de SLA através da utilização de agentes coletores de dados.
Para tanto, foram abordados dentro da fundamentação teórica (Capítulo II) os serviços de
gerenciamento de nível de serviço (Seção 2.2), gerenciamento de disponibilidade (Seção 2.3)
e gerenciamento de capacidade (Seção 2.4) da ITIL. A maior dificuldade encontrada durante
a confecção deste capítulo foi em relação às referências bibliográficas. Além de existirem
poucos materiais em língua portuguesa sobre a ITIL, os seus conteúdos são uma tradução
direta da publicação original (OGC, 2003). Devido a isto, muitos parágrafos dentro da
fundamentação teórica possuem referências vindas da OGC, já que o contexto do trabalho é
baseado na ITIL.
Os temas levantados pela fundamentação teórica foram de suma importância para o Capítulo
III, onde foram feitos os levantamentos dos requisitos (Seção 3.2) e das regras de negócio
(Seção 3.3) para a modelagem da solução (Objetivo 4). Com base nesses levantamentos,
foram criados os casos de uso (Seção 3.4), os digramas de classe (Seção 3.5) e de seqüência
(Seção 3.6), utilizando como referência a notação UML (Objetivo 5). Também foram criados
os diagramas de Entidade-Relacionamento (Seção 3.7). Além disso, os itens de um SLA que
foram monitorados no Capitulo IV puderam ser identificados (Objetivo 1).
Como solução para a comunicação com o servidor foi utilizado WebServices (Objetivo 3), já
que tornou-se um protocolo bastante utilizado, principalmente quando se trabalha com a
plataforma .net da Microsoft. Além disso, novos agentes podem ser criados e executados
utilizando qualquer ambiente de programação, desde que ele forneça mecanismos para a
comunicação com um protocolo WebService.
As ferramentas utilizadas (Seção 3.8) para o desenvolvimento do protótipo (Capítulo IV)
foram apresentadas e justificadas pelo domínio do acadêmico nas tecnologias propostas e por
serem ferramentas gratuitas (Objetivo 2). A partir das tecnologias envolvidas, o protótipo foi
desenvolvido (Objetivo 6) de acordo com os requisitos levantados. Para tanto, foram criados
os projetos dentro da IDE de desenvolvimento (Seção 3.9). Dois projetos se destacam por
suas principais funcionalidades. O primeiro é o Projeto Agentes, desenvolvido para coletar os
101
dados de capacidade e disponibilidade dos SLAs cadastrados. O segundo é o projeto web
onde estão as regras de negócio e o WebService.
Os desafios encontrados durante o desenvolvimento do projeto Agentes foram amenizados
pela escolha de uma linguagem nova (C#), pois o framework .net possui muitas bibliotecas
para a manipulação de diagnósticos do sistema operacional. O grande trabalho ficou a cargo
dos estudos e pesquisas para descobrir quais bibliotecas usar, quais métodos aplicar e reunir
todas essas funções em uma biblioteca própria, que pudesse ser utilizada por outros coletores
dentro do ambiente Windows. Um dos requisitos levantados foi a implementação de um
agente para rodar em máquinas Linux. Por questões de tempo e prioridades, o projeto acabou
não sendo desenvolvido. Para suprir esse requisito, os esforços foram concentrados em
aplicar uma boa avaliação para o protótipo.
O projeto Web foi o que levou o maior tempo de desenvolvimento. A criação inicial foi do
WebService para atender à demanda dos agentes coletores. O trabalho maior foi de preparar
as informações vindas pela internet, para que pudessem ser inseridas de forma íntegra até a
base de dados. As partes mais complexas deste projeto foram às rotinas de cálculo de
disponibilidade e capacidade. Boa parte do tempo deste projeto foi despendida em esboços e
testes em cima dos dados armazenados. Como o foco foi trabalhar com os dados todos em
banco, optou-se por utilizar as functions do SQL Server. Com isso, ganhou-se mais
desempenho nas consultas, já que os dados chegavam até as páginas web já processados. As
únicas rotinas que não puderam ser totalmente desenvolvidas no banco de dados foram os
cálculos de MTTR e MTBF exigidos nos requisitos do projeto. Estes cálculos dependem de
varredura na base de dados atrás de mudanças de status (uptime e downtime). Esta rotina
seria mais facilmente implementada se a estratégia adotada fosse a de ser trabalhar com os
dados à medida que fossem chegando pelo WebService.
Após o desenvolvimento do protótipo foi criado o ambiente de testes (Seção 3.10),
utilizando-se de máquinas virtuais para simular um ambiente maior do que o disponível.
Foram utilizadas 2 máquinas reais e duas máquinas virtuais. Feito isso, foram criados dentro
da base de dados os SLAs de teste, preenchidos com informações sem nenhum critério
específico, apenas baseado na possibilidade de criar dados para uma melhor avaliação do
protótipo. O desafio encontrado neste processo foi em relação ao ambiente empresarial e suas
102
questões de segurança e privacidade. Com isso, justifica-se a criação das máquinas virtuais,
para que se pudessem obter resultados mais próximos da realidade de uma organização.
Com o ambiente montado, foi convocado um profissional da área para testar e avaliar
(Objetivo 7) o protótipo desenvolvido em cima dos requisitos levantados. A maior
dificuldade neste processo foi à disponibilidade do avaliador para a realização deste processo,
e o curto tempo para o cumprimento de todos os passos desta etapa. Obteve-se dificuldade em
formalizar os processos de testes e desta maneira, alguns passos tomaram mais tempo do que
esperado. Para o levantamento dos dados da base, foram utilizados comandos SQL e gráficos
do Microsoft Excel, que juntos com as regras de negócio e os requisitos, serviram de guia
para o avaliador durante todo o processo. Como sugestão do próprio avaliador para o
enrequicimento do processo de testes, foram respondidos questionários utilizados pela
empresa Pink Elephant para certificar as empresas que mais utilizam as boas práticas da ITIL
dentro de seus sofwares. O questinário foi respondido em tempo relativamente curto, e mais
uma vez por questões de tempo e disponibilidade, as resposta tiveram que ser as mais
objetivas, o que não interferiu nos resultados obtidos.
Uma vez que todos os objetivos específicos foram alcançados, abrem-se oportunidades para a
continuação e aperfeiçoamento das técnicas e processos utilizados no desenvolvimento deste
protótipo. Na Seção 4.1 são apresentados os tópicos relacionados aos trabalhos futuros.
4.1. TRABALHOS FUTURO
Este trabalho pode ser continuado e aperfeiçoado com as seguintes sugestões:
� Aperfeiçoamento do SLA de disponibilidade, permitindo que a indisponibilidade
planejada possa ser configurada com horários não comerciais e finais de semana;
� Desenvolver Agentes coletores para ambientes não Windows, como por exemplo: Linux,
Roteadores e Celulares;
� Criar interfaces para pesquisa de dados de SLA;
� Criar interfaces para a criação de relatórios e gráficos de históricos de dados de
capacidade e disponibilidade; e
� Ampliar as possibilidades do SLA de capacidade, não restringindo somente CPU,
Memória e Disco;
REFERÊNCIAS BIBLIOGRÁFICAS
ANDRADE, Maria Margarida de. Introdução à metodologia do trabalho científico. 4. ed. São Paulo: Atlas, 1999. 153 p.
CAMPOS, Maria Luiza M.; VIEIRA, Arnaldo. Modelagem Entidade-Relacionamento. [S.I.]: Instituto Militar Engenharia, 2005. Disponível em: <http://www.comp.ime.eb.br/~yoko/bdI/ER.PDF>. Acesso em: 7 Maio 2007.
CAMPOS, V. R. A. Estudo comparativo de linguagens de programação. Salvador: [S.I.], 2003. Disponível em: <http://twiki.im.ufba.br/pub/MAT052/RelacaoMonografias/monografia.doc>. Acesso em: 27 Maio 2008.
FERNANDES, Aguinaldo Aragon; ABREU, Vladimir Ferraz de. Implantando a Governança de TI: da Estratégia à Gerenciamento dos Processos e Serviços. Rio de Janeiro: Brasport, 2006.
FIGUEIREDO, Antônio. Administração de Sistemas e Segurança: Sniffers. [S.I.]: UNICAMP, 2000. Disponível em: <http://www.ccuec.unicamp.br/revista/infotec/admsis/admsis8-1.html>. Acesso em: 14 Novembro 2007.
GIL, Antônio Carlos. Como Elaborar Projetos de Pesquisa. 4. ed. [S.I.]: Atlas, 2002. 175 p.
GOMES, Silvia Bogéa; FALBO, Ricardo de Almeida; MENEZES, Crediné Silva. Um Modelo para Acordo de Nível de Serviço em TI. [S.I.]: UFES, 2005. Disponível em: <http://www.inf.ufes.br/~falbo/download/pub/2005-Sbqs.pdf>. Acesso em: 17 Agosto 2007.
MACFARLANE, Ivor; RUDD, Colin. Gerenciamento de Serviços de TI. 5. ed. São Paulo: The IT Service Management Forum, 2005.
MAGALHÃES, Ivan Luizio; PINHEIRO, Walfrido Brito. Gerenciamento de Serviços de TI na Prática: Uma abordagem com base na ITIL. 1. ed. São Paulo: Novatec, 2007.
MICROSOFT SMF. Service Management Functions: Capacity Management. [S.I.]: Microsoft Corporation, 2002. Disponível em: <http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/smfcapmg.mspx> Acesso em: 28 Outubro 2007.
MICROSTRATEGY BRASIL; Scorecards and Dashboards. São Paulo: [S.I.], 2007. Disponível em: <http://www.microstrategy.com.br/Solutions/5Styles/scorecards_dashboards.asp>. Acesso em: 8 Agosto 2007.
104
MIT; Introduction to Programming Threads. Massachusetts: Institute of Technology, 2000. Disponível em: <http://www.mit.edu:8001/people/proven/IAP_2000/>. Acesso em: 18 Maio 2007.
OGC. ITIL Service Delivery. Norwich: Office Of Government Commerce, 2003. 1 CD-ROM.
OLIVEIRA, Silvio Luiz de. Tratado de Metodologia Ciêntifica: Projetos de Pesquisas, TGI, TCC, Monografias, Dissertações e Teses. São Paulo: Pioneira Thomson Learning, 2001. 320 p.
PESSÔA, Marcelo; SPINOLA, Mauro. Trabalho de Sistemas de Informação. [S.I.]: Departamento de Engenharia de Produção, 2006. Disponível em: <http://www.prd.usp.br/disciplinas/docs/pro2511-2006-Marcelo_Mauro/D06%20Instru%C3%A7%C3%B5es.pdf>. Acesso em: 15 Novembro 2007.
PINHEIRO, Flávio R. Curso ITIL Fundamentos: Preparatório Certificação ITIL Foundation. [S.I.]: TI Exames, 2007.
PINK ELEPHANT; PinkVerify: IT Management Tools. Toronto: [S.I.], 2008. Disponível em: < https://www.pinkelephant.com/NR/rdonlyres/76889D15-B44A-4716-A0DF-FBFADD5FC198/3295/PinkVERIFYServiceWhitepaperV32FINAL.pdf>. Acesso em: 2 Junho 2007.
STERN, Andrea. Reinvesting the IT Dollar: From Fire Fighting to Strategic Services, EDUCAUSE Quarterly, Sidney, v. 3, 2001. 7 p.
SILVA, Edna Lúcia; MENEZES, Estera Muszkat. Metodologia da pesquisa. 3. ed. Florianópolis: Laboratório de Ensino a Distância da UFSC, 2001.
TELELOGIC; Dashboard. 2007 Disponível em: <http://www.telelogic.com/products/dashboard/index.cfm>. Acesso em: 19 Agosto 2007.
TRAINNING; Utilizando o CobiT e o Balanced Scorecard como instrumentos para o Gerenciamento de Níveis de Serviço. 2007. Disponível em: <http://www.trainning.com.br/artigo_cobit_bsc.html>Acesso em: 7 Agosto 2007.
TURNER, Dinah; DYER, Jerry; HUNTER, Sheila. Service Management Functions: Service Level Management. [S.I.]: Microsoft Corporation, 2002. Disponível em: <http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/smfslamg.mspx>. Acesso em: 26 Outubro 2007.
VASCONCELOS, José Braga de; Algoritmos e Estruturas de Dados – I: Estruturas de dados lineares.Porto: Universidade Fernando Pessoa, 2004. Disponível em: <http://www2.ufp.pt/~jvasco/AED-Present-0405.pdf>. Acesso em: 15 Maio 2008.
105
VIANA, Paulo. O que é terceirização? São Paulo: SEBRAE, 2004. Disponível em: <http://www.sebraesp.com.br/principal/abrindo%20seu%20neg%C3%B3cio/produtos%20sebrae/artigos/listadeartigos/terceirizacao.aspx>. Acesso em: 14 Novembro 2007.
WAZLAWICK, Raul Sidnei. Análise e Projeto de Sistemas de Informação Orientados a Objeto. Rio de Janeiro: Elsevier, 2004.
WESTOVER, James; HANNA, Ashley. Microsoft Solutions for Management: Availability Management. [S.I.]: Microsoft Corporation, 2002. Disponível em: <http://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/smfavamg.mspx>. Acesso em: 14 Outubro 2007.
WOZEN; O Que é Service Level Agreement. Disponível em: <http://www.wozen.com.br/publique/cgi/cgilua.exe/sys/start.htm?infoid=41&sid=26>. Acesso em: 17 Agosto 2007.
APÊNDICES
107
A CASOS DE USO
A.1 CONTROLE DE ACESSO
Figura 46. USC-O1 Efetuar Login
Tabela 8. USC-01 Efetua Login
Descrição: Permite que um operador possa ter acesso ao sistema, através do fornecimento de uma conta e senha.
Atores: Gerente de SLA, Supervisor de SLA
Requisitos associados: REF1,RNF9
Pré-condições: Estar Cadastrado.
Pós-condições: O operador está logado no sistema.
Fluxos de Eventos Fluxo principal: 1. O sistema apresenta uma página solicitando a conta e a
senha do operador. 2. O operador preenche os dados (conta/senha) e confirma. 3. O sistema valida a conta e senha fornecidas. 4. O sistema apresenta a página principal.
Fluxo Exceção 1: Se no item 2, a conta ou a senha estiver em branco, o sistema apresenta mensagem "O login e a senha precisam estar preenchidos!" e retorna ao passo 1.
Fluxo Exceção 2: Se no passo 3, o login ou a senha não puderem ser validados, o sistema apresenta uma mensagem "Login ou senha incorreta!".
108
A.2 CADASTRO SLA
Figura 47. USC-02 Cadastro de SLA
109
Tabela 9. USC-02 Cadastro de SLA
Descrição: Permite que um Gerente de SLA possa cadastrar os dados de um SLA no banco de dados.
Atores: Gerente de SLA
Requisitos associados: REF2-REF19,RNF1,RNF7
Pré-condições: O Gerente de SLA precisa estar logado no sistema.
Pós-condições: Um SLA foi adicionado no banco de dados.
Fluxos de Eventos Fluxo principal: 1. O sistema apresenta os campos para preenchimento do
SLA. (Tela – Apêndice D.1) 2. O Gerente de SLA preenche os dados. 3. O sistema apresenta a opção de inserir o objetivo do SLA:
um item de capacidade ou uma lista de itens de disponibilidade.
4. O Gerente de SLA escolhe inserir itens de disponibilidade.
5. O sistema apresenta os campos para preenchimento das horas de disponibilidade e indisponibilidades planejadas do item. (Tela – Apêndice D.2)
6. O Gerente de SLA preenche os dados das horas acordadas com o cliente.
7. O sistema apresenta uma lista de agentes coletores de dados ativos.
8. O Gerente de SLA escolhe um Agente e confirma. 9. O sistema insere o item cadastrado na lista de itens de
disponibilidade do SLA. 10. O sistema calcula a disponibilidade total dos itens da lista. 11. O Gerente de SLA insere um limiar de alerta e dados de
configuração e confirma. 12. O sistema valida os dados e efetua a gravação do SLA.
Fluxo Exceção 1: No item 3 o Gerente de SLA opta por inserir no objetivo um item de capacidade: 5.1. O sistema apresenta os campos para preenchimento dos
dados de capacidade. (Tela – Apêndice D.3) 5.2. O Gerente de SLA preenche os campos. 5.3. O sistema apresenta uma lista de agentes coletores de
dados de capacidad que estão registrados no banco de dados.
5.4. O Gerente de SLA escolhe um Agente e confirma. 5.5. O sistema vai para o item 11.
Fluxo Exceção 2: No item 9 o Gerente de SLA pode optar em cadastrar mais itens de disponibilidade: 7.1. O sistema volta para o item 5.
Fluxo Exceção 3: No item 4 o Gerente de SLA pode optar em remover um item da lista: 4.1. O sistema remove o item da lista e vai para o item 10.
110
A.3 CRIAÇÃO DE AGENTES
Figura 48. USC-03 Criação de Agentes
111
Tabela 10. USC-03 Criação de Agentes
Descrição: Permite que um Gerente de SLA possa executar agentes de monitoramento em máquinas remotas.
Atores: Gerente de SLA
Requisitos associados: REF20-REF29,RNF2,RNF4
Pré-condições: O Gerente de SLA precisa estar logado no sistema. O sistema de monitoramento web deve estar ativo.
Pós-condições: Um agente está coletando dados da máquina e enviando esses dados para o servidor.
Fluxos de Eventos
Fluxo principal: 1. O sistema apresenta os campos para preenchimento da identificação do agente.
2. O Gerente de SLA preenche os dados. 3. O sistema solicita o preenchimento do IP do servidor. 4. O Gerente de SLA preenche o IP. 5. O sistema apresenta a opção de coletar dados de
disponibilidade ou de capacidade. 6. O Gerente de SLA opta por coletar dados de
disponibilidade. (Tela – Apêndice D.5) 7. O sistema apresenta a opção do tipo de coleta de
disponibilidade: software ou hardware. 8. O Gerente de SLA escolhe a coleta de software. 9. O sistema solicita lista todos os processos disponíveis no
sistema operacional para efetuar o monitoramento. 10. O Gerente de SLA seleciona o processo. 11. O sistema solicita o intervalo de envio dos dados
coletados para o servidor. 12. O Gerente de SLA informa o intervalo e confirma. 13. O agente está ativo.
Fluxo Exceção 1: No item 5 o Gerente de SLA opta por coletar dados de capacidade (Tela - Apêndice D.4): 5.1. O sistema permite escolher a coleta dos dados de CPU,
Memória e Disco Rígido. 5.2. O Gerente de SLA seleciona os itens. 5.3. O sistema vai para o item 11.
Fluxo Exceção 2: No item 7 o Gerente de SLA pode optar por coletar dados de hardware: 7.1. O sistema vai para o item 11.
Fluxo Exceção 3: No item 4 o Gerente de SLA preenche um IP inválido ou o IP preenchido não está ativo. 4.2. O sistema apresenta uma mensagem dizendo “não foi
possível se conectar ao servidor informado”.
112
B DIAGRAMAS DE CLASSE
B.1 CADASTRO DE SLA
Figura 49. Diagrama de Classe - Módulo Cadastro de SLA
113
B.2 CRIAÇÃO DOS AGENTES
Figura 50. Diagrama de Classe - Módulo de Criação dos Agentes
B.3 MONITORAMENTO
Figura 51. Diagrama de Classe - Módulo de Monitoramento
114
B.4 FUNCIONAMENTO DOS AGENTES
Figura 52. Diagrama de Classe - Funcionamento dos Agentes
115
B.5 CONTROLE DE ACESSO
Figura 53. Diagrama de Classe - Módulo Controle de Acesso
116
C DIAGRAMAS DE SEQÜÊNCIA
C.1 CONTROLE DE ACESSO
Figura 54. Diagrama Seqüência - Controle de Acesso
117
C.2 CADASTRO DE SLA - CAPACIDADE
Figura 55. Diagrama Seqüência - Cadastro de SLA – Capacidade
118
C.3 CADASTRO DE SLA - DISPONIBILIDADE
Figura 56. Diagrama Seqüência - Cadastro de SLA – Disponibilidade
119
C.4 CRIAÇÃO DOS AGENTES
Figura 57. Diagrama Seqüência - Criação dos Agentes
120
C.5 FUNCIONAMENTO DO AGENTE CAPACIDADE
Figura 58. Diagrama Seqüência - Funcionamento do Agente Capacidade
121
C.6 FUNCIONAMENTO DO AGENTE DISPONIBILIDADE
Figura 59. Diagrama Seqüência - Funcionamento do Agente Disponibilidade
122
D PROTÓTIPOS DE TELA
D.1 TELA CADASTRO DE SLA - CABEÇALHO
Figura 60. Protótipo de Tela de Cadastro de SLA – Cabeçalho
D.2 TELA CADASTRO DE SLA - ITENS DE DISPONIBILIDADE
Figura 61. Protótipo de Tela de Cadastro de SLA - Itens de Disponibilidade
123
D.3 TELA CADASTRO DE SLA - ITEM DE CAPACIDADE
Figura 62. Protótipo de Tela de Cadastro de SLA - Item de Capacidade
D.4 TELA AGENTE DE CAPACIDADE
Figura 63. Protótipo de Tela de um Agente de Capacidade
124
D.5 TELA AGENTE DE DISPONIBILIDADE
Figura 64. Protótipo de Tela de um Agente de Disponibilidade
D.6 TELA MONITORAMENTO DE SLAS
Figura 65. Protótipo de Tela de Monitoramento de SLAs
125
E FUNÇÕES SQL SERVER 2005
E.1 CALCULO CAPACIDADE CPU ATUAL
Figura 66. Capacidade CPU Atual
E.2 CALCULO CAPACIDADE MEMORIA ATUAL
Figura 67. Capacidade Memoria Atual
126
E.3 CALCULO CAPACIDADE DISCO ATUAL
Figura 68. Capacidade Disco Atual
E.4 CALCULO CAPACIDADE CPU FORA LIMIAR
Figura 69. Qtde Capacidade CPU Fora Limiar
127
E.5 CALCULO CAPACIDADE MEMORIA FORA LIMAR
Figura 70. Qtde Capacidade Memoria Fora Limiar
E.6 CALCULO CAPACIDADE DISCO FORA LIMAR
Figura 71. Qtde Capacidade Disco Fora Limiar
128
E.7 CALCULO DISPONIBILIDADE HARDWARE
Figura 72. Cálculo Disponibilidade Hardware
E.8 CALCULO DISPONIBILIDADE SOFTWARE
Figura 73. Cálculo Disponibilidade Software
129
E.9 CALCULO INDISPONIBILIDADE HARDWARE
Figura 74. Cálculo Indisponibilidade Hardware
