LARISSA GEOVANA FELISBERTO COLLOSSI
CHECKS:
DESENVOLVIMENTO DE UMA FERRAMENTA PARA A GESTÃO DA DISPONIBILIDADE DE SISTEMAS ONLINE
Palhoça 2013
CHECKS:
DESENVOLVIMENTO DE UMA FERRAMENTA PARA A GESTÃO DA DISPONIBILIDADE DE SISTEMAS ONLINE
Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Ciência da Computação da Universidade do Sul de Santa Catarina, como requisito parcial à obtenção do título de Bacharel em Ciência da Computação.
Orientador Prof. Msc. Luiz Otávio Botelho Lento.
Palhoça 2013
CHECKS:
DESENVOLVIMENTO DE UMA FERRAMENTA PARA A GESTÃO DA DISPONIBILIDADE DE SISTEMAS ONLINE
Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharel em Ciência da Computação e aprovado em sua forma final pelo Curso de Graduação em Ciência da Computação da Universidade do Sul de Santa Catarina.
Palhoça, 21 de novembro de 2013.
______________________________________________________ Professor e orientador Luiz Otávio Botelho Lento, Msc.
Universidade do Sul de Santa Catarina
______________________________________________________ Profa. Fernanda Oviedo Bizarro, Esp.
Universidade do Sul de Santa Catarina
______________________________________________________ Profa. Maria Inés Castiñeira, Dra.
Dedico esse trabalho à minha mãe, por me dar a vida, por acreditar em mim, por me ensinar a dar valor a tudo que possuo e conquisto, mas principalmente pelo amor incondicional.
Ao meu padrasto Luis, pelas caronas para a faculdade, pela paciência ao me acordar todos os dias pela manhã e pelo apoio.
Ao meu pai e à Girlane, pelo apoio e incentivo ao longo da minha caminhada. Às minhas sobrinhas Alice e Rafaela e minha afilhada Ana Clara, pelo espaço no sofá e companhia para ver desenhos.
À toda minha família, pela demonstração de apoio e carinho.
Ao professor Luiz Otávio Botelho Lento, meu orientador, pela confiança no meu trabalho, pelas contribuições, atenção e orientação essenciais.
Ao professor Osmar de Oliveira Braz Junior, por ser um exemplo de dedicação ao trabalho e uma fonte de inspiração.
À professora Maria Inês Castiñeira, pela dedicação e atenção ao longo desses anos.
Aos meus colegas de turma: André Meurer, Eduardo Jordano, Guilherme Alvarez, Jhonattan Amorin de Oliveira, Silmara Horstmann e tantos outros colegas que conheci ao longo da faculdade, agradeço pela amizade e principalmente pela paciência.
Ao Tatto pela amizade de uma década, broncas motivacionais e apoio na realização de um projeto que é tão meu quanto é dele, por acreditar na minha capacidade e por estar sempre disposto a me ajudar.
À toda equipe da ServerDo.in, pela oportunidade que me foi dada, pelos cafés e pelas risadas.
Aos meus amigos: Evandro, Thayse e Paula, por todo companheirismo e amor dedicado.
Aos meus amigos: André, Carlos, Mario, Mauricio e Mayara, pelo apoio, pelas conversas, pela motivação e amizade.
À dupla mais querida do estado: Filipe e Thiego, por me ajudarem a ver que no interior tem gente de valor, pelo carinho, pela atenção e pelo apoio.
Ao Google, por ser fonte de conhecimento e por me ajudar durante toda a minha trajetória até aqui.
E por fim a todos aqueles que de alguma forma contribuíram para a realização deste trabalho.
Garantir que um sistema online está disponível pode ser uma tarefa trabalhosa, é necessário realizar um constante monitoramento do serviço para garantir sua total entrega. O cenário se agrava quando não se tem apenas um serviço a ser monitorado, mas diversos serviços sendo executados e acessados de locais distintos. A disponibilidade de um serviço na internet atua diretamente na percepção do usuário sobre a empresa que disponibiliza esse serviço. Desenvolver uma forma de garantir que o sistema está disponível e comprovar, tanto para os usuários do sistema, quanto para seus clientes, é no mínimo complexo e dispendioso. No entanto, é mais dispendioso para uma empresa perder usuários por não conseguir atingir suas expectativas. O desenvolvimento de uma ferramenta de monitoramento de sistemas online auxilia na comprovação da disponibilidade de sistemas online, pode atuar na gestão de Acordos de Níveis de Serviço e auxiliar na manutenibilidade de sistemas online. Desenvolver essa ferramenta é atuar dentro de um cenário que exige a alta disponibilidade, já que para garantir a coleta de informações sobre o serviço a ferramenta deve estar sempre disponível. Tendo essas informações como premissa, o trabalho aqui apresentado objetivou modelar e implementar uma ferramenta que realize o monitoramento de sistemas online. Antes de iniciar a definição da ferramenta a ser desenvolvida, foi feita uma analise das ferramentas de monitoramento já existentes no mercado. Através do uso de tecnologias que garantiram a alta disponibilidade, como a replicação do banco de dados e distribuição geográfica do sistema, foi possível desenvolver uma ferramenta de monitoramento de sistemas online. A ferramenta desenvolvida possui as características essenciais das ferramentas analisadas e agrupou características únicas, que a difere das ferramentas analisadas. Por fim, após a validação da ferramenta, o resultado desse projeto foi uma ferramenta que cumpre o papel ao qual se destinou.
Figura 1 - Níveis de serviços comuns. ... 21
Figura 2 - Fluxograma das atividades metodológicas. ... 40
Figura 3 - Proposta: visão lógica. ... 41
Figura 4 - Proposta: visão física. ... 42
Figura 5 - Hyperspin - Cadastro de monitoramento. ... 44
Figura 6 - Hyperspin - Alerta de indisponibilidade e retorno... 45
Figura 7 - Hyperspin - Relatório diário. ... 45
Figura 8 - Monitor.us - Cadastro de monitoramento - passo um. ... 46
Figura 9 - Monitor.us - Cadastro de monitoramento - passo dois. ... 47
Figura 10 - Monitor.us - Alerta de indisponibilidade e retorno... 47
Figura 11 - Monitor.us - Relatório semanal. ... 48
Figura 12 - Sitealerta - Cadastro de monitoramento... 49
Figura 13 - Sitealerta - Alerta de indisponibilidade e retorno. ... 49
Figura 14 - Sitealerta - Relatório mensal. ... 50
Figura 15 - Uptime Robot - Cadastro de monitoramento. ... 51
Figura 16 - Uptime Robot - Alerta de indisponibilidade e retorno. ... 52
Figura 17 - Diagrama de Casos de Uso. ... 61
Figura 18 - Diagrama de atividades - Checagem de serviços... 66
Figura 19 - Diagrama de atividades - Emissão de alertas... 67
Figura 20 - Diagrama Entidade-Relacionamento. ... 68
Figura 21 - Infraestrutura global AWS. ... 70
Figura 22 - Banco de dados em cluster. ... 71
Figura 23 - Ferramentas tecnológicas. ... 73
Figura 24 - Aplicação web, utilizando o Gearman ... 78
Figura 25 - Fluxo de dados de monitoramento e alerta. ... 80
Figura 26 - Tela de login ... 81
Figura 27 - Tela de recuperação de senha ... 82
Figura 28 - Tela de registro de usuário ... 82
Figura 29 - Tela de dados do usuário ... 83
Figura 30 - Tela de listagem de perfil criado pelo do usuário ... 84
Figura 31 - Tela de cadastro de serviço ... 84
Figura 32 - Tela de listagem de serviços cadastrados com filtro aplicado ... 85
Figura 33 - Tela de cadastro de contato ... 86
Figura 34 - Tela de cadastro de usuário ... 86
Figura 35 - Tela de visualização de contato ... 87
Figura 36 - Tela de listagem dos contatos do usuário ... 87
Figura 37 - Tela de listagem de serviços monitorados ... 88
Figura 38 - Tela de gráfico do tempo de resposta. ... 89
Figura 39 - Tela de listagem de serviços com alertas ... 89
Quadro 1 - Comparações entre as ferramentas. ... 53
Quadro 2 - Requisitos funcionais - usuário. ... 55
Quadro 3 - Requisitos funcionais - perfil. ... 55
Quadro 4 - Requisitos funcionais - serviço. ... 56
Quadro 5 - Requisitos funcionais - contato. ... 56
Quadro 6 - Requisitos funcionais - monitoramento. ... 56
Quadro 7 - Requisitos não funcionais - usabilidade. ... 57
Quadro 8 - Requisitos não funcionais - confiabilidade. ... 57
Quadro 9 - Requisitos não funcionais - performance. ... 58
Quadro 10 - Requisitos não funcionais - suporte. ... 58
Quadro 11 - Regras de negócio. ... 59
Quadro 12 - CSU001 - Cadastrar usuário. ... 62
Quadro 13 - CSU002 - Recuperar senha. ... 62
Quadro 14 - CSU003 - Cadastrar perfil. ... 63
Quadro 15 - CSU004 - Cadastrar serviço. ... 64
Quadro 16 - CSU005 - Cadastrar contato. ... 64
1 INTRODUÇÃO ... 12 1.1 PROBLEMÁTICA ...13 1.2 OBJETIVOS ...14 1.2.1 Objetivo Geral ...14 1.2.2 Objetivos Específicos ...14 1.3 JUSTIFICATIVA ...14 1.4 ESTRUTURA DA MONOGRAFIA ...16
2 GERENCIAMENTO DE NÍVEL DE SERVIÇO ... 17
2.1 CONCEITOS E FUNDAMENTOS ...17
2.1.1 Componentes do SLM ...18
2.1.1.1 Requisitos de Nível de Serviço ... 18
2.1.1.2 Catálogo de Serviços ... 19
2.1.1.3 Acordo de Nível Operacional ... 19
2.1.1.4 Acordo de Nível de Serviço ... 20
2.1.1.4.1 Estruturas de ANS ...21
2.1.1.4.1.1 Baseado em serviço ... 22
2.1.1.4.1.2 Baseado em cliente ... 22
2.1.1.4.1.3 Baseado em multinível ... 22
2.1.1.4.2 Tipos...23
2.1.1.4.3 Componentes básicos do ANS ...24
2.2 POR QUE GERENCIAR ...25
2.3 ASPECTOS DO GERENCIAMENTO DE NÍVEL DE SERVIÇO ...27
2.3.1 Disponibilidade ...28
2.3.2 Desempenho ...29
2.3.3 Segurança ...30
2.3.4 Precisão ...31
2.3.5 Possibilidade de Recuperação ...32
2.4 RELATÓRIOS DE NÍVEIS DE SERVIÇO ...33
2.5 MONITORAMENTO DE SISTEMAS ...34 3 MÉTODO... 36 3.1 CARACTERIZAÇÃO DA PESQUISA ...36 3.2 CLASSIFICAÇÃO DA PESQUISA ...37 3.3 ATIVIDADES METODOLÓGICAS ...39 3.4 PROPOSTA ...41 3.5 DELIMITAÇÕES ...43 4 ANÁLISE DE FERRAMENTAS ... 44 4.1 HYPERSPIN ...44 4.2 MONITOR.US ...46 4.3 SITEALERTA ...48 4.4 UPTIME ROBOT ...51 4.5 CONCLUSÕES ...52
5 MODELAGEM DO SISTEMA PROPOSTO ... 54
5.1 ANÁLISE DE REQUISITOS ...54
5.1.1 Requisitos funcionais ...55
5.1.2 Requisitos não funcionais ...57
5.3 MODELAGEM DINÂMICA ...65
5.3.1 Diagramas de atividade ...66
5.4 MODELAGEM DE DADOS ...68
5.4.1 Diagrama de Entidade-Relacionamento ...68
5.5 ANÁLISE DA INFRAESTRUTURA TECNOLÓGICA ...69
5.5.1 A nuvem ...69
5.5.2 Banco de Dados em Cluster ...71
6 DESENVOLVIMENTO ... 73 6.1 FERRAMENTAS TECNOLÓGICAS ...73 6.1.1 PHP ...74 6.1.2 Yii Framework ...74 6.1.3 Eclipse ...75 6.1.4 Git ...75 6.1.5 Bootstrap ...76 6.1.6 NGINX ...76 6.1.7 VirtualBox ...77 6.1.8 Gearman ...77 6.2 HISTÓRICO DE DESENVOLVIMENTO ...79 6.3 APRESENTAÇÃO DO SISTEMA ...81 6.4 VALIDAÇÃO ...90
7 CONCLUSÕES E TRABALHOS FUTUROS... 93
1 INTRODUÇÃO
A integração e a agilidade dos processos de negócios exigem das empresas que estas saiam da estagnação. Elas precisam migrar para internet para que se tornem mais competitivas (SANTOS, 2006, p. 61). Hoje a internet se tornou de fácil uso, está disponível o tempo todo e sua abrangência é mundial (ABDALA; OLIVEIRA, 2003, p. 27). Segundo dados da organização Internet World Stats, em agosto de 2012, cerca de 30% da população mundial estava usando a internet.
Para entrar para o mundo digital, algumas empresas utilizam do Outsourcing, este é um processo no qual uma empresa é contratada para prover um conjunto de produtos ou serviços de modo cooperativo. A empresa contratante possui um contato contínuo com a empresa contratada, de maneira que esta sempre tenha que manter ou melhorar a qualidade do produto ou serviço entregue. Apesar de parecer uma espécie de terceirização, essa metodologia vai contra esta visão. Enquanto na terceirização a escolha do fornecedor é fruto de uma decisão operacional e o contrato é de simples regressão, no Outsourcing, o fornecedor é visto como um parceiro da empresa que o contrata e a decisão de contratação é estratégica (GOMES; RIBEIRO, 2004, p. 134).
Uma empresa alcançará o sucesso se escolher bem seus parceiros e souber gerir bem essa parceria. A ideia de Outsourcing é que a empresa acompanhe, gerencie e avalie os fornecedores, para garantir a eficácia e eficiência dos serviços e produtos entregues (BALDIN; BALDIN, 2011, p. 79).
Para Baldin e Baldin (2011, p. 79), as empresas não devem trabalhar somente com o Outsourcing, mas também com o Multisourcing. Ele permite que a empresa possa escolher os melhores em cada área, porque dificilmente uma empresa será excelente em tudo.
Conforme dito anteriormente, dificilmente uma empresa será excelente em tudo, portanto o Multisourcing é quase sempre a melhor opção. Porém ele torna a gestão um pouco mais difícil, uma vez que a empresa deverá acompanhar todos os serviços e produtos entregues, gerenciando mais de perto os seus múltiplos acordos de nível de serviço (BALDIN; BALDIN, 2011, p. 79).
Tanto no Multisourcing quanto no Outsourcing, a forma de ligação entre o contratado e o contratante é normalmente um Acordo de Nível de Serviço (ANS), ele é basicamente um contrato que define as características da entrega de um serviço, especifica várias métricas para medir o nível de qualidade do serviço. Dentre as métricas existentes,
existem duas que são comumente utilizadas: tempo de atividade (Uptime) e o tempo de resposta (Response Time) (HORWITZ, 2002, p. 209, tradução nossa). Essas métricas estão intimamente ligadas com a disponibilidade de um sistema online.
Esses acordos se tornam a ligação entre clientes que desejam ter seus serviços online e fornecedores que oferecem esses serviços. Deste modo, a comprovação e manutenção das métricas tornam-se fundamentais para os envolvidos nesses acordos.
1.1 PROBLEMÁTICA
Ao entrar no mundo digital, uma empresa não se torna mais competitiva se seu sistema ficar constantemente indisponível ou apresentar lentidão.
Para garantir que um serviço esteja disponível, uma empresa precisaria monitorar seu sistema constantemente, verificar se o serviço contratado está sendo entregue, verificar se as métricas estão de acordo com o definido no ANS e, caso não estejam, coletar dados para provar essa ausência de comprometimento com o que foi definido. O mesmo ocorre do lado do fornecedor, que precisa garantir a entrega do serviço, realizando um monitoramento contínuo dos seus sistemas e coletando dados que comprovem as métricas definidas no ANS.
O conceito de monitorar sistemas online, para garantir o acordado no ANS, não é relativamente novo. Em 2001, um artigo sobre o tema foi publicado na revista Network World. Warter (2001, p. 35, tradução nossa) já apontava a necessidade de fazer o controle de métricas de ANS para que as empresas tivessem a confirmação dos serviços que estavam contratando.
Partindo disso, a pergunta de pesquisa do projeto é o questionamento sobre a garantia no tempo de atividade e no tempo de resposta de um sistema online e estipular se ambos estão dentro do que foi definido no acordo de nível de serviço.
1.2 OBJETIVOS
A seguir, são apresentados o objetivo geral e os objetivos específicos do trabalho.
1.2.1 Objetivo Geral
Desenvolver um sistema de gerenciamento de disponibilidade de sistemas online em uma nuvem.
1.2.2 Objetivos Específicos
Os objetivos específicos apresentam-se a seguir:
x realizar a análise das ferramentas disponíveis no mercado;
x modelar e implantar o sistema em um ambiente de alta disponibilidade;
x desenvolver uma ferramenta que possa servir para comprovação de dados de disponibilidade entre cliente e fornecedor.
1.3 JUSTIFICATIVA
Em plena “Era da Informação”, é mais poderoso quem tem a melhor tecnologia da informação e quem também saiba utilizá-la da melhor forma. Este domínio pode ser obtido por uma pessoa, uma organização ou um país. A informação é a fonte de energia da empresa, é ela quem mostra os caminhos a serem seguidos (CHIAVENATO, 2006, p. 324). Se a
empresa não possui informação sobre seu próprio sistema ou se ele não está funcionando perfeitamente, ela não pode ser tão competitiva quanto às outras.
As mudanças no mundo digital são rápidas e constantes, ter a habilidade de construir uma empresa nesse meio, de forma complexa, é uma grande vantagem. O setor administrativo de uma empresa deve se adaptar a essa nova realidade e construir projetos baseados em alta tecnologia, almejando destacar-se entre as empresas que já estão inseridas nesse mercado (KALAKOTA; ROBINSON, 2001). Na internet, ganha quem tiver a melhor apresentação, o melhor preço, mas, principalmente, a confiança do cliente. Um sistema que fica indisponível ou apresenta lentidão, além de não parecer confiável, torna difícil a navegação.
Acordos de nível de serviço são fechados diariamente para garantir essa disponibilidade e, caso ocorra alguma indisponibilidade do serviço, fica inviável, tanto para o contratante quanto para o contratado, provar que esse problema feriu de alguma maneira o acordo firmado.
Partindo disso, a construção de um sistema de monitoramento surgiu da necessidade de intermediar duas empresas que firmam um acordo de nível de serviço. Acompanhar e armazenar dados sobre o que está ocorrendo com o serviço que foi contratado, tornando-se, assim, uma autoridade mediadora e imparcial.
Após alguns testes realizados nas ferramentas de monitoramento de serviços online disponíveis no mercado (os resultados serão apresentados no capítulo 4), a autora deste trabalho constatou que nem todos os erros simulados foram detectados por essas ferramentas, deixando margem para dúvidas quanto à fidelidade dos dados. Muitas dessas ferramentas possuíam características semelhantes, mas nenhuma se adequava perfeitamente ao que era esperado pela autora. Portanto, surgiu a necessidade de construir uma ferramenta que se encaixasse nessas diretrizes.
Além disso, há a motivação por parte da autora em transformar o projeto em um produto comercial, para empresas que desejam monitorar seus sistemas online, não só para comprovar o que foi definido num acordo de nível de serviço, mas também empresas que desejam acompanhar a disponibilidade de seus sistemas em tempo real.
1.4 ESTRUTURA DA MONOGRAFIA
Este trabalho apresenta a seguinte estrutura:
x Capítulo 1: é apresentada a introdução, a problemática, os objetivos gerais e específicos e a justificativa para o desenvolvimento deste trabalho.
x Capítulo 2: são apresentados conceitos sobre o gerenciamento de nível de serviço, acordos de nível de serviço, a importância de ambos dentro de um contexto organizacional.
x Capítulo 3: são apresentados os métodos utilizados na pesquisa, as características que ela possui e como ela foi realizada.
x Capítulo 4: são apresentadas as ferramentas analisadas, características e conclusões baseadas em testes.
x Capítulo 5: é apresentada a modelagem do sistema proposto.
x Capítulo 6: são apresentadas as ferramentas utilizadas para o desenvolvimento do sistema proposto e são apresentados os passos que foram seguidos para desenvolvimento do sistema proposto. Também é descrita a validação do sistema.
x Capítulo 7: são apresentadas as conclusões sobre o estudo feito, os resultados apresentados e considerações finais sobre o trabalho desenvolvido.
2 GERENCIAMENTO DE NÍVEL DE SERVIÇO
A quantidade de sistemas de missão crítica está aumentando, sistemas de missão crítica são sistemas que necessitam de alta disponibilidade e de alto desempenho. Sistemas de missão crítica são primordiais para a seguridade e manutenção da uma empresa. Existem empresas que possuem a sua estrutura baseada apenas em sistemas desse tipo. Empresas que atuam somente no comércio eletrônico, muitas vezes, são formadas apenas por sistemas e computadores, por exemplo. Enquanto outras empresas dependem desses sistemas para garantir seu pleno funcionamento, como empresas de linhas aéreas e empresas de telecomunicações (STURM; MORRIS; JANDER, 2001, p. 4-5).
Com a necessidade empresarial de obter a alta disponibilidade de sistemas de missão crítica, a tecnologia de informação (TI) passou de facilitadora do processo para ser essencial em sua constituição. Os gerentes de TI sempre prezaram por mensurar o desempenho do que estão oferecendo aos seus clientes e foi graças a esse cenário que surgiu a necessidade do gerenciamento do nível de serviço (STURM; MORRIS; JANDER, 2001, p. 4-5).
2.1 CONCEITOS E FUNDAMENTOS
Segundo Bon e Verheijen (2006, p. 115), o gerenciamento do nível de serviço (SLM, Service Level Management) pode ser definido como um processo de negociação, definição, medição, administração e melhoria na qualidade dos serviços de Tecnologia da Informação. Esse processo deve apresentar também um custo aceitável dentro de um ambiente no qual existem necessidades mudando constantemente, bem como a atualização das tecnologias empregadas, quando necessário. Ele tenta tornar harmoniosa a relação entre a oferta e a demanda de qualidade, a confortabilidade de uso por parte do cliente e relação de custos por serviço. Baseia-se na importância em informar tanto ao cliente quanto ao fornecedor que o serviço está sendo provido e recebido (BON; VERHEIJEN, 2006, p. 115).
Dentro de um processo de SLM, podemos definir dois papéis fundamentais: o do cliente e o do fornecedor. O cliente é aquele que contrata o serviço, ele é o responsável por
fazer acordos com empresas de TI para solicitar os serviços que sua empresa necessita, é preciso deixar claro que ele não é o utilizador final do serviço. Muitas vezes, o cliente é também uma empresa de TI que entrega algum tipo de serviço, o que a torna tanto cliente quanto fornecedora, criando uma complicada rede de relacionamentos. Já, na outra ponta do processo está o fornecedor, é ele quem faz acordos com o cliente, comprometendo-se a fornecer o que é solicitado nesses acordos (BON; VERHEIJEN, 2006, p. 115).
O processo de SLM pretende manter transparente a relação entre o cliente e o fornecedor. Envolve também a garantia de que as metas de entrega dos serviços estão sendo cumpridas, realizando o constante monitoramento da satisfação do cliente, na tentativa de aumentá-la. Ele tem como foco garantir a entrega do que o cliente deseja, mantendo o cliente o mais próximo possível a fim de conhecê-lo mais a cada dia. Esse processo também auxilia na proatividade por parte do fornecedor, podendo assim melhorar o serviço dentro do escopo do negócio, tendo o conhecimento para justificar o custo dessa melhoria (SILVA; GOMEZ; MIRANDA, 2010, p. 115).
2.1.1 Componentes do SLM
Para realizar o SLM, são necessários alguns componentes, como: Requisitos de Nível de Serviço, Catálogo de Serviços, Acordo de Nível Operacional e Acordo de Nível de Serviço.
2.1.1.1 Requisitos de Nível de Serviço
É um dos itens básicos do SLM. Segundo Bon e Verheijen (2006, p. 115), um requisito de nível de serviço (RNS) pode ser definido como um detalhamento da necessidade que o cliente possui e é a partir dele que são desenvolvidos, modificados ou iniciados os serviços. É dele quem provém uma estrutura básica para a construção de um Acordo de Nível de Serviço (detalhado no item 2.1.1.4). Portanto, para o processo de SLM, é necessário que
sejam levantados, documentados e acordados com o cliente quais são os RNS envolvidos, para poder definir o que irá suprir as necessidades do cliente (SILVA; GOMEZ; MIRANDA, 2010, p. 115).
2.1.1.2 Catálogo de Serviços
Ele é dividido em dois tipos: o de Catálogo de Serviços de Negócio e o Catálogo de Serviços Técnico. O Catálogo de Serviços de Negócio auxilia a prestadora de serviço a traçar um perfil sobre si e tornar-se, na visão do cliente, uma provedora de serviços em TI e não somente uma implementadora e mantenedora de tecnologia (BON; VERHEIJEN, 2006, p. 116).
Por ser um catálogo que será entregue ao cliente deve estar em linguagem clara, fora do âmbito técnico. Esse catálogo terá uma descrição em detalhes dos serviços e um resumo dos níveis de serviços ligados ao que o fornecedor pode oferecer. É uma ferramenta fundamental na comunicação cliente e fornecedor. Como esse catálogo atua no esclarecimento dos serviços, direcionando assim as expectativas do cliente, torna-se um documento facilitador para o processo entre o cliente e o fornecedor (BON; VERHEIJEN, 2006, p. 116).
Já, o Catálogo de Serviços Técnicos possui um detalhamento técnico dos serviços que serão entregues ao cliente, além das ligações com o serviço de suporte, as informações de configuração, os componentes e serviços adicionais que serão úteis para que se realize a entrega do serviço ao cliente (FERNANDES; ABREU, 2012, p. 268-269).
2.1.1.3 Acordo de Nível Operacional
Possui um detalhamento sobre a entrega de alguns itens de um determinado serviço, ele é um acordo interno com uma equipe de TI. O acordo de nível operacional (ANO) está diretamente associado ao Acordo de Nível de Serviço, ele direciona uma equipe a como
ela deve reagir de acordo com o que é necessário ser feito, possuindo os objetivos de cada participante da cadeia de suporte (BON; VERHEIJEN, 2006, p. 116).
2.1.1.4 Acordo de Nível de Serviço
Um Acordo de Nível de Serviço pode ser definido como um contrato no qual constam os parâmetros de negócios ou de suporte técnico em que um fornecedor proverá um serviço ao cliente. Nele constam medidas de desempenho e o que ocorre, caso a empresa não alcance essas medidas ou caso ocorram falhas. É um contrato que possui a identificação dos compromissos de todas as partes envolvidas, o fornecedor e o cliente. Apresentando responsabilidades, definições, quais processos precisam ser realizados, que produtos precisam ser entregues, a junção de acordos de níveis de serviços estabelecidos e as restrições que os cercam (ALBERTIN; SANCHEZ, 2008, p. 120).
Segundo Fernandes e Abreu (2008, p. 64-65), acordos de níveis de serviço servem para limitar as metas de performance. Para que o acordo seja determinado de modo responsável, ele precisa que alguns fatores sejam conhecidos, como:
x é necessário que se quantifique o desempenho atual comparado com o que foi requisitado pelo usuário e/ou cliente;
x é necessário que se estabeleça a capacidade que a infraestrutura possui (partindo da quantidade de pessoas que vão atender aos chamados e prestar os serviços necessários, até a parte física, como armazenamento e processamento de dados);
x é necessário que se defina a capacidade em entregar as aplicações dentro dos prazos definidos.
Com a coleta dessas informações, o ANS pode acabar influenciando diretamente a empresa fornecedora como um todo. Por causa dele, pode haver a necessidade de ampliar a infraestrutura ou necessidade de contratar mais pessoas para as tarefas necessárias. É essencial que, com esses dados em mãos, a empresa fornecedora pense no uso de novas metodologias, ferramentas e processos, que foquem o aumento da produtividade de desenvolvimento e manutenibilidade dos sistemas (FERNANDES; ABREU, 2008, p. 65).
Na figura 1, podemos ver um quadro com alguns tipos e os seus níveis de serviços:
Figura 1 - Níveis de serviços comuns.
Fonte: Fernandes e Abreu (2008, p. 65).
Conforme visto na figura, são diversos os tipos de serviços que podem ser acordados num ANS, alguns acabam sendo mais comuns como: serviços ligados a sistemas, que envolvem o desenvolvimento, manutenção e/ou a implementação de módulos, por exemplo: os serviços de suporte a usuários, como resolução de incidentes. Os serviços ligados à segurança da informação, a disponibilidade de uma aplicação ou da infraestrutura, por exemplo. E, ainda, há os serviços que envolvem a implantação de novas formas de realizar os processos dentro da empresa, como do CMMI (Capability Maturity Model Integration) ou de uma ISO, dentro de um prazo estabelecido (FERNANDES; ABREU, 2008, p. 64).
2.1.1.4.1 Estruturas de ANS
É necessário projetar a estrutura de ANS que mais se ajusta aos serviços. Adequando-se as necessidades da empresa que contrata, existem algumas estruturas básicas para isso, são elas: ANS baseado em serviço, ANS baseado em clientes e ANS multinível.
2.1.1.4.1.1 Baseado em serviço
Neste caso, o ANS cobre um serviço específico - por exemplo, pode ser estabelecido um ANS para serviços de e-mail de uma organização - que abrange todos os clientes desse serviço. Apesar de bastante simples, podem surgir dificuldades se os clientes possuírem requisitos específicos diferentes para o mesmo serviço, ou se as características da infraestrutura significar que haverá diferentes níveis de serviço (por exemplo, o escritório principal estará conectado através de uma rede de alta velocidade, enquanto os outros escritórios podem usar uma rede de baixa velocidade). Em tais casos, as métricas distintas devem estar dentro do acordo. Dificuldades também podem surgir na determinação de quem devem ser os responsáveis pela assinatura desse acordo (OFFICE OF GOVERNMENT COMMERCE, 2007, p. 67-68, tradução nossa).
No entanto, quando os níveis comuns de serviço são prestados em todas as áreas do negócio o ANS baseado em serviço, pode ser uma abordagem eficiente. Podem-se estipular múltiplas categorias de serviço, por exemplo, ouro, prata e bronze, que podem ser utilizados para aumentar a eficácia da ANS, baseado em serviço (OFFICE OF GOVERNMENT COMMERCE, 2007, p. 67-68, tradução nossa).
2.1.1.4.1.2 Baseado em cliente
Este é um acordo que cobre todos os serviços de um cliente. Por exemplo, o cliente do acordo pode ser um departamento financeiro, por exemplo, neste caso, o acordo envolverá o sistema financeiro, o sistema de contabilidade, o sistema de folha de pagamento, o sistema de faturamento, o sistema de compras e quaisquer outros sistemas de TI que eles usam. Os clientes, muitas vezes, preferem um acordo desse tipo, quando todos os seus requisitos são abordados em um único documento. Apenas um responsável é necessário, o que simplifica o processo (OFFICE OF GOVERNMENT COMMERCE, 2007, p. 67-68, tradução nossa).
Algumas empresas utilizam uma estrutura de ANS multinível, através dela é possível que o ANS seja mantido a um tamanho gerenciável, evitando duplicações desnecessárias e reduzindo a necessidade de atualizações frequentes. Essa estrutura possui três camadas (OFFICE OF GOVERNMENT COMMERCE, 2007, p. 68-69, tradução nossa) que são:
x nível corporativo: abrangendo todas as questões de gerenciamento de nível de um serviço genérico, que se adequada a todos os clientes da empresa. Estes problemas tendem a serem menos variáveis, de modo que atualizações são menos frequentes;
x nível de clientes: abrangendo todas as questões de gerenciamento de nível de serviço que são relevantes para um grupo de clientes em particular ou unidade de negócio, independentemente do serviço que está sendo utilizado;
x nível de serviço: abrangendo todas as questões de gerenciamento de nível de serviço relevantes para um serviço específico, em relação a um grupo de clientes específicos (um para cada serviço coberto pelo ANS).
2.1.1.4.2 Tipos
Existem, conceituando de modo amplo, três tipos de ANS. São eles: ANS da própria empresa, ANS externo e ANS interno. A seguir uma breve descrição de cada um dos tipos (STURM; MORRIS; JANDER, 2001, p. 56-57):
x ANS da própria empresa: Esse tipo de acordo envolve o setor de TI e outro setor da empresa, como o setor de RH, por exemplo. Mesmo que a empresa que fornece o serviço seja a mesma que receba o serviço é importante que se faça um acordo de âmbito legal e detalhado. Num acordo elaborado corretamente, ambos os setores serão beneficiados, acarretando o beneficio na empresa também.
x ANS externo: esse tipo de acordo envolve duas empresas, é o acordo que possui maior rigor e que necessita de muito cuidado ao ser elaborado. É recomendado realizar uma revisão legal nesse tipo de acordo. Algumas
empresas não realizam esse tipo de revisão, o que acarreta em um documento que não tem nenhuma valia.
x ANS interno: esse acordo é realizado dentro do setor de TI. Ele visa a medir o desempenho de cada um dos grupos que formam o setor de TI. É um acordo normalmente escrito em linguagem técnica, visto que os envolvidos estão familiarizados com os termos.
Mesmo que possuam diferentes tipos de ANS, o processo de construção é basicamente igual, o mesmo ocorre com o conteúdo do ANS. O que varia são as formalidades anexadas, a linguagem utilizada, as consequência em caso de não atingir as métricas definidas e os envolvidos no acordo (STURM; MORRIS; JANDER, 2001, p. 56).
2.1.1.4.3 Componentes básicos do ANS
Na documentação do ANS, é preciso constar alguns componentes básicos. São eles (STURM; MORRIS; JANDER, 2001, p. 61-76):
x partes do acordo: descreve quem é a empresa fornecedora do serviço e quem é a empresa contratante;
x prazo: um ANS deve ter um prazo de duração, é recomendado em média dois anos. Não inferior a dois anos, pois a elaboração denota de umas etapas trabalhosas que justificam esse prazo. E nem superior a dois anos, pois as tecnologias e as condições do negócio podem se alterar ao longo desse prazo; x escopo: descreve quais serviços estarão amparados pelo acordo. Nessa parte,
não deve haver nenhuma especificação dos níveis de serviço prestados;
x limitações: basicamente define as limitações do serviço, como carga de trabalho, volume de dados, topologia da infraestrutura entre outros;
x objetivos do nível de serviços: descreve os níveis de serviços que serão entregues, é nessa parte que se localizam as métricas utilizadas para análise da entrega de serviço. Aqui, comumente, se encontram normalmente as métricas de disponibilidade, desempenho e precisão do serviço. É indicado que se tenha de 5 a 10 objetivos, eles devem ser concisos;
x indicadores de nível de serviços: são eles que indicam o modo de medir os níveis de serviço, devem representar esses níveis. Lembrando que para estipular esses indicadores é fundamental pensar que o que indica se eles são válidos é a perspectiva do usuário;
x sem desempenho: descreve as consequências da não entrega dos serviços acordados, sejam punições ao fornecedor ou bonificações ao cliente;
x serviços opcionais: apresenta o serviços que não são comumente oferecidos, mas que podem ser necessários no futuro. Um exemplo simples seria uma empresa que não abre aos domingos, mas que no fim do ano abre. Nesse caso, seria necessário que o sistema funcionasse aos domingos também;
x exclusões: expõe quais os serviços não serão amparados pelo acordo, isso reduz que clientes deduzam serviços que, na verdade, não serão entregues; x relatórios: delineia os relatórios que serão entregues aos clientes com os
dados sobre os serviço para comprovação das métricas acordadas;
x administração: apresenta uma descrição dos processos do ANS e qual a responsabilidade da empresa sobre cada processo;
x revisões: descreve quando serão feitas as revisões, que visam a verificar se o serviço está de acordo com o definido ou se precisa alterar algo tanto no serviço, quanto no acordo;
x provações: nesta parte ficam as assinaturas dos responsáveis pelo acordo.
2.2 POR QUE GERENCIAR
O principal motivo de gerenciar é a satisfação do cliente. Um bom gerenciamento começa pela conversação entre os clientes e os gerentes de TI, é através dessa conversa que se destacam quais são os problemas que o cliente possui. É necessário que o cliente exponha claramente o que ele precisa e também o que ele espera do serviço. A partir disso, cliente e fornecedor combinam o que consideram um nível de serviço aceitável e a avaliação do desempenho do fornecedor, após a entrega do serviço, já pode ser iniciada (STURM; MORRIS; JANDER, 2001, p. 13).
A conversação deve continuar ao longo do processo, com relatórios periódicos. Mesmo com o gerenciamento de nível de serviço, isso não garante a satisfação do cliente e, muito menos, a entrega do serviço por parte do fornecedor. No entanto, através do gerenciamento, os fornecedores podem acompanhar a satisfação dos clientes, quando suas expectativas forem atendidas prontamente e também ajuda a ter o controle de quando o serviço não agradou ao cliente, de maneira que o fornecedor possa melhorar nesse aspecto (STURM; MORRIS; JANDER, 2001, p. 13).
Através do SLM também pode ser realizada uma delimitação das expectativas do cliente. O que o cliente espera de um serviço deve ser acordado e documentado. A delimitação da expectativa afeta diretamente o custo do serviço. É importante que se tenha em mente que quanto maior a expectativa do cliente, maior é a demanda de pessoal e de soluções utilizadas. A situação considerada perfeita é quando o cliente possui o serviço necessário dentro das suas capacidades orçamentárias (STATDLOBER, 2006, p. 36).
Ao não utilizar do SLM, deixa-se brechas para que o cliente crie expectativas, além do nível de serviço fornecido, neste caso deixando o mesmo insatisfeito com o serviço entregue. Com um bom SLM e expectativas delimitadas e documentadas no ANS, o fornecedor pode apresentar o que antes era um nível de serviço aceitável e abordar uma nova reestruturação do ANS, a fim de agregar as novas expectativas, partindo para uma nova negociação e inclusão de novos recursos para elevação dos níveis de serviço (STURM; MORRIS; JANDER, 2001, p. 13).
O SLM auxilia também no controle de recursos, ele é fundamental dentro da empresa fornecedora de serviços, ela necessita demarcar e ter noção dos serviços que oferece. A empresa fornecedora precisa saber sobre o desempenho e cargas de pico, para poder garantir a entrega do que foi acordado em ANS de todos os seus clientes. Também, precisa dominar o uso da infraestrutura e os componentes de TI que serão necessários, como a largura de banda, a capacidade de processamento e disco. Precisando prever a necessidade de realizar uma melhoria nesses recursos, esse tipo de controle está diretamente ligado ao SLM (BON; VERHEIJEN, 2006, p. 146).
Para ter um controle maior, é recomendada uma monitorização constante dos recursos. Através dos ANS a empresa pode mensurar os recursos necessários para manter todos os serviços sendo entregues dentro do exigido. Desta forma, a empresa não terá sobra excessiva de recursos nem falta do mesmo, a ponto de falhar nessa entrega (STURM; MORRIS; JANDER, 2001, p. 14).
O SLM pode não só ajudar na gerência direta de serviços como também no marketing da TI. Utilizando de um bom gerenciamento, a TI pode apresentar a comprovação de que está fazendo um bom trabalho, mantendo os níveis de serviço dentro do que foi estabelecido ou acima disto. Isso faz com que a TI perca aquela visão de que só está presente quando algo não está em pleno funcionamento e passa a estar presente durante todo o ciclo. A TI ganha uma visão de setor tão fundamental na empresa quanto qualquer outro, como o de contabilidade, por exemplo. Ela passa a ser vista com bons olhos, pois é ela quem mantém o sistema funcionando (STURM; MORRIS; JANDER, 2001, p. 14).
O SLM influencia diretamente no controle de custos da empresa fornecedora. Sem o SLM, a empresa fornecedora teria que estimar o que os clientes precisam sem ter nada como base, correndo o risco de estimar algo muito fora da real necessidade do cliente, tanto num nível acima quanto num nível abaixo do que o cliente precisa, gastando mais do que o necessário em infraestrutura. Em alguns casos, utilizar o SLM pode ser uma decisão difícil, ao implantar o SLM a empresa fornecedora possui um maior embasamento na hora de solicitar um acréscimo no valor de determinado serviço, por outro lado, o cliente pode provar que determinado investimento não possui real necessidade (STURM; MORRIS; JANDER, 2001, p. 14-15).
Por fim, podemos incluir o SLM como ferramenta auxiliar na estratégia defensiva da empresa fornecedora. Com um ANS bem definido, o cliente não poderá reclamar do mesmo, basta que a empresa fornecedora trabalhe dentro do que foi contratado (STURM; MORRIS; JANDER, 2001, p. 15).
2.3 ASPECTOS DO GERENCIAMENTO DE NÍVEL DE SERVIÇO
Há alguns aspectos no SLM que devem ser ponderados, aspectos que auxiliam na quantificação da qualidade dos serviços entregues (STURM; MORRIS; JANDER, 2001, p. 18-19). Esses aspectos serão explanados a seguir.
2.3.1 Disponibilidade
Disponibilidade é a métrica que atua diretamente na eficiência da TI, ela informa quanto os usuários conseguem acessar ao sistema. Dentro dessa métrica, podemos incluir a alta disponibilidade, que é um indicador mais detalhado da disponibilidade. Quando um sistema precisa trabalhar com alta disponibilidade, dizemos que é um sistema que está 100% operacional ou ainda um sistema que nunca falha. Esse tipo de sistema fica acessível por um longo tempo (BALTZAN; PHILLIPS, 2012, p. 125).
A alta disponibilidade de sistemas online é um padrão que vem sendo replicado por muitas empresas. As empresas fornecedoras de serviços em TI tentam alcançar altos níveis de alta disponibilidade, afinal, muitas empresas que contratam seus serviços têm operações e necessidades que devem estar disponíveis por todo o tempo (BALTZAN; PHILLIPS, 2012, p. 125).
A disponibilidade influi diretamente na experiência que o usuário tem com o sistema. Apesar da indisponibilidade de um serviço envolver o sistema como um todo, é necessário dividir a análise de disponibilidade em partes. Como, por exemplo, verificar a disponibilidade da rede, depois verificar a disponibilidade do banco de dados, ao invés de checar tudo de uma vez (STURM; MORRIS; JANDER, 2001, p. 19).
Para Sturm, Morris e Jander (2001, p. 20), “Disponibilidade de um serviço é a capacidade de concluir com êxito um serviço ou transação comercial integralmente [...]” para avaliar essa disponibilidade é essencial que se discrimine os serviços que estão envolvidos no processo.
Também é necessário fazer a análise dos componentes que envolvem o serviço. Sturm, Morris e Jander (2001, p. 20) explanam que: “A disponibilidade de componentes descreve quando um componente individual subordinado a um serviço está operacional [...]”. Fazendo uma análise individual dos componentes, partindo do usuário e voltando a ele, podemos definir se um sistema está disponível ou não.
Há dois fatores que influenciam diretamente na disponibilidade de um componente: tempo médio entre falhas (MTBF, ou Mean Time Between Failures) e tempo médio de recuperação (MTTR, ou Mean Time To Repair). O MTBF é o tempo médio que o componente fica disponível antes que sofra algum problema e pare de funcionar. Já o MTTR
é o tempo que o componente demora a voltar ao seu estado normal (seja por correção manual ou automática), ficando assim disponível novamente (FLYNN; MCHOES, 2002, p. 254).
É importante deixar claro que mesmo que o sistema fique disponível ao longo do tempo, o que realmente importa para o usuário final ou para o cliente que contratou o serviço é se ele está disponível no momento solicitado (STURM; MORRIS; JANDER, 2001, p. 20-21).
É necessário observar que dentro do SLM existem as chamadas janelas de manutenção, que são utilizadas para corrigir problemas, atualizar partes do sistema, entre outras coisas. Esse tipo de processo pode acarretar pausa temporária na entrega de serviço, portanto, não deve entrar na conta de indisponibilidade, visto que será discriminado dentro do ANS quando, como e com que frequência essas pausas podem ocorrer (STURM; MORRIS; JANDER, 2001, p. 20-21).
2.3.2 Desempenho
Desempenho é mensurar a agilidade do sistema em responder a uma determinada requisição (que pode ser um processo ou uma transação). A ausência de desempenho pode ser um enorme problema para uma empresa. Um usuário que navegue pelo sistema e encontre lentidão acabará migrando para outro site (BALTZAN; PHILLIPS, 2012, p. 126).
A quantificação de desempenho não é dada por valores absolutos, ela é apresentada em torno de uma média. Até que se crie um padrão de desempenho e, por fim, se compare o padrão aos demais parâmetros ou valores de comparação (FERNANDES; ABREU, 2008, p. 159).
É necessário que a avaliação do desempenho, assim como a de disponibilidade, seja do ponto de vista do usuário. O desempenho está relacionado com capacidade de respostas a comandos de maneira interativa, execução de processos em lotes e a níveis de carga de trabalho (STURM; MORRIS; JANDER, 2001, p. 20-26).
A medida de desempenho para usuários interativos é o tempo de resposta, é a quantidade de tempo que um sistema gasta no processamento da requisição de um usuário. Já, para o processamento em lote, que se inicia com ou sem a interferência de um usuário, a medida utilizada é o tempo de retorno. Alguns fatores podem alterar o valor dessas medidas
como o uso de recursos que a requisição faz ou então a quantidade de processos que são necessários para a sua conclusão, entre outros (FLYNN; MCHOES, 2002, p. 253).
Para o tempo de resposta, é interessante que ele se mantenha na média, um usuário não ficará contente com um tempo de resposta que oscile de ótimo a péssimo, em alguns casos a equipe de TI acaba aumentando esse tempo para que o usuário não sinta diferenças tão grandes e gradativamente vai reduzindo. Assim os usuários não criam expectativas em cima de tempos ótimos (STURM; MORRIS; JANDER, 2001, p. 22).
No processamento em lote, há uma fila de processos e somente, quando o último processo for finalizado, é que o sistema finaliza a requisição. Isso quer dizer que a soma de todos os tempos das tarefas que foram processadas é que define o tempo de retorno (PINEDO, 2012, p. 98, tradução nossa).
Há alguns tipos de processamento em lote que são cotidianos, como a fila de processos da impressora e alguns são específicos, como o cálculo da folha de pagamento. No segundo caso, usando uma contabilidade, como exemplo, o cálculo pode ter prazo máximo para que seja finalizado, isso é o que chamamos de prazo crítico e, nesse caso, o desempenho de processamento em lote será fundamental, podendo acarretar algum prejuízo para a empresa que contratou o serviço. É essencial que se gerencie processos em lote para que os mesmos não interfiram nos processos interativos (STURM; MORRIS; JANDER, 2001, p. 22-23).
2.3.3 Segurança
Em relação à segurança, basicamente há necessidade por parte da empresa fornecedora: realizar o controle de acesso, a análise de riscos, conforme sua criticidade e garantia da segurança da informação. A disponibilidade da informação deve estar de acordo com os requisitos de segurança definidos para o negócio (FERNANDES; ABREU, 2008, p. 308).
Sturm, Morris e Jander (2001, p. 256) explanam sobre a segurança em gerenciamento de nível de serviço, afirmam ser “as ações pertinentes à definição de quem pode acessar a um serviço, a natureza do acesso e os mecanismos aplicados para detectar, evitar e comunicar o acesso não autorizado”. Para isso, é fundamental que se crie uma política de segurança, essa política será mais essencial ao negócio, conforme a necessidade que o
mesmo possui da TI, afinal, qualquer evento que ocorra pode ser prejudicial à empresa. Para a criação dessa política de segurança, é necessário que se avalie alguns fatores (FERNANDES; ABREU, 2008, p. 74) como:
x o impacto no negócio: análise do impacto que uma falha na segurança possui sobre o negócio, quanto maior o impacto mais importância a política de segurança tem dentro do negócio;
x tendência a falhas: dentre as vulnerabilidades que o sistema possui qual a chance de ocorrerem falhas devido a essas vulnerabilidades. Se as vulnerabilidades não apresentam tanta criticidade dentro do sistema, deverá destacar-se menor tempo de análise sobre ela;
x adequação ao sistema: analisar quais métodos de controle devem ser implementados na estrutura a fim de que se adapte melhor aos riscos e vulnerabilidades do sistema.
2.3.4 Precisão
Basicamente, o que garante a precisão é a integridade. Não só os dados devem ser íntegros, mas a integridade de um sistema como um todo. Esse tipo de integridade é fiada pela junção dos componentes em seu estado adequado (TURBAN; WETHERBE; MCLEAN, 2002, p. 540).
Quando os dados vão de um ponto a outro sem que tenham seus valores modificados, podemos dizer que são dados íntegros. É fundamental que dados possuam integridade durante o processo ou transação. Podemos utilizar um exemplo simples para elucidar essa necessidade: numa transação financeira, deseja-se enviar R$100,00 para determinada conta, durante a transação, esse valor se altera para R$1.000,00, nesse caso a origem da transação será prejudicada (FOROUZAN, 2006, p. 713).
Para que se obtenha a integridade de dados, durante o SLM, é necessário que se revise todos os componentes que podem afetar esses dados, como estrutura de dados e o banco de dados. A implementação de backups e segmentos de recuperação reafirma a qualidade dessa integridade. A atualização constante desses dados, que podem estar distribuídos por diversos locais, é fundamental, pois garante que todos estejam trabalhando
com os dados corretos. Além disso, os processamentos em lote devem ser terminados o quanto antes, afinal, caso um processo esteja na fila e ele seja essencial para uma transação, o serviço pode ter sua integridade perdida (STURM; MORRIS; JANDER, 2001, p. 29-30).
2.3.5 Possibilidade de Recuperação
Quando ocorre um desastre, é essencial que os serviços sejam restaurados o quanto antes. É importante que a prioridade seja recuperar uma quantidade mínima de serviços, até que se consiga recuperar todos. Podemos definir um desastre como sendo um evento que afeta os serviços de TI a ponto de pará-los totalmente. É necessário uma análise de risco, levantando informações sobre as ameaças e vulnerabilidade que o sistema possui, e planejar soluções para a recuperação do sistema (SILVA; GOMEZ; MIRANDA, 2010, p. 193).
Existem três tipos de desastres (STURM; MORRIS; JANDER, 2001, p. 31-32) que são:
x defeito físico: quando um dispositivo ou componente do sistema apresenta falha, a substituição ou o conserto do dispositivo é a solução. Nesse tipo de problema, todos os serviços que utilizam o dispositivo serão afetados;
x erro lógico: quando algum erro ocorre durante uma transação, esse tipo de problema, normalmente, afeta somente o serviço em que o erro ocorreu. Esse tipo de erro pode se dar por um problema de lógica no programa, através da interação do usuário e/ou operador. A solução corretiva, normalmente, envolve um pouco mais de trabalho, no caso de uma falha lógica no programa será necessário descobrir em que momento ocorreu o erro, corrigir o problema e recuperar todos os dados até aquele ponto. Já, numa falha ocorrida devido à interação de um usuário, basta que se recuperem todos os dados até aquele ponto;
x desastre natural: esse tipo de erro afeta todos os serviços e dispositivos em determinada localização, por consequência afeta todos os serviços que se comunicam com os serviços afetados, podendo ocorrer um efeito cascata. Dependendo do desastre, somente, se a empresa possui a replicação de dados
em outra localização, o mesmo poderá ser recuperado. A métrica utilizada nesse tipo de situação é o tempo de recuperação. É a soma do tempo utilizado para interromper o processamento, deixar o ambiente estável, realizar a recuperação dos dados e reconstruir todas as transações perdidas. O tempo de recuperação infere sobre a disponibilidade do serviço. Antes de concluída, a recuperação ainda infere sobre precisão e a integridade dos dados (STURM; MORRIS; JANDER, 2001, p. 31-32).
2.4 RELATÓRIOS DE NÍVEIS DE SERVIÇO
No SLM, o uso de relatórios sobre os serviços é fundamental. Esses relatórios devem ser produzidos com certa frequência (semanalmente ou em períodos menores). É recomendado que os relatórios sejam gerados desde o começo da entrega do serviço, que apresentem também dados de problemas ocorridos, mesmo que, no começo do serviço, mostrando se alguma métrica do ANS ficou abaixo do acordado ou se chegou a níveis mínimos. Dificuldades são comumente encontradas no cumprimento dos objetivos de entrega de novos serviços, e esses relatórios podem auxiliar na correção preventiva e ao acompanhar, desde o inicio, evitarão problemas futuros. A frequência e o formato de relatório devem ser definidos e acordados com os clientes (OFFICE OF GOVERNMENT COMMERCE, 2007, p. 73, tradução nossa).
Os relatórios periódicos devem incorporar detalhes de desempenho em relação a todas as metas do ANS, juntamente com detalhes de todas as tendências ou ações específicas a serem tomadas para melhorar a qualidade do serviço. É interessante que se inclua gráficos nesses relatórios, para que, ao receber o relatório, o cliente já tenha uma visão geral de como as metas obtidas ficaram em relação às metas acordadas (OFFICE OF GOVERNMENT COMMERCE, 2007, p. 73, tradução nossa).
A produção de relatórios é um processo evolutivo e os recursos necessários para produzir os relatórios não devem ser subestimados. Este pode ser um processo extremamente demorado, se os relatórios não refletem a percepção do cliente em relação à qualidade do serviço, eles podem piorar a situação. É essencial que exista precisão de informações de todas as áreas e todos os processos sejam analisados e compilados em um relatório conciso e
abrangente sobre o desempenho do serviço, comparando o alcançado com o acordado (OFFICE OF GOVERNMENT COMMERCE, 2007, p. 73, tradução nossa).
O SLM deve identificar as necessidades de relatórios específicos e automatizar a produção desses relatórios, na medida do possível. Estes relatórios de serviços devem não só incluir detalhes sobre o desempenho atual em relação às metas, mas também devem fornecer informações históricas sobre o desempenho e tendências anteriores, de modo que o impacto das ações de melhoria possam ser verificadas (OFFICE OF GOVERNMENT COMMERCE, 2007, p. 73, tradução nossa).
2.5 MONITORAMENTO DE SISTEMAS
Sistemas de informação estão mais complexos, e a solução de problemas que apresentam deve ser dada quase que em tempo real. É necessário ter os dados, um conhecimento aprofundado da interpretação destes dados e uma pitada de habilidade. Leva-se um tempo para verificar se há algum problema e esse tempo pode ser muito grande. Os padrões de disponibilidade de sistemas continuam altos e são ampliados cada vez mais. Os sistemas devem estar preparados, caso contrário, a falta de informações levará à perda de tempo e, em alguns casos, perda de rendimentos (LIGUS, 2013, p.1).
O monitoramento tornou-se um termo genérico cujo significado depende do contexto. Mais amplamente, refere-se ao processo de possuir o conhecimento sobre o estado de um sistema. Isso pode ser feito de duas maneiras, proativas e reativas. O primeiro caso diz respeito acompanhar indicadores visuais, como a séries de tempo e painéis de controle, e, às vezes, é o que os administradores querem dizer com monitoramento. O modo reativo envolve formas automatizadas para entregar notificações aos operadores a fim de trazer ao seu conhecimento uma grave alteração no estado do sistema, o que é normalmente referido como alerta (LIGUS, 2013, p.1).
O monitoramento capacita os operadores a conseguir informações sobre complicações antes que se tornem problemas, ajuda a preservar a alta disponibilidade e oferecer uma alta qualidade de serviço. Ele também auxilia na tomada de decisões sobre o presente e o futuro, serve como entrada para a automação de infraestrutura e, mais importante, é uma ferramenta de aprendizagem indispensável (LIGUS, 2013, p.1).
Alguns benefícios do monitoramento são imediatos, como a detecção precoce com base em dados coletados, tomadas de decisões e a possibilidade de automação de processos. Mas o monitoramento desempenha um papel central na absorção de conhecimento do trabalho e promove a inovação. Não se pode gerenciar o que você não mensura, em alguns casos, o monitoramento pode se referir ao processo de medição, que pode ou não envolver interação humana (LIGUS, 2013, p.15).
A solução de monitorização amplamente difundida mantém todos com as mesmas informações. Relatórios de tempo em tempo permitem o repasse de ideias complexas que se alongariam, caso fossem descritas em texto plano. O monitoramento acrescenta um grande valor ao sistema e ajuda a promover a cultura de aprendizagem rápida e dispersão de informação (LIGUS, 2013, p.15).
O principal objetivo do monitoramento é obter informações em tempo real sobre o estado atual do sistema no contexto de seu desempenho recente. As informações extraídas ajudam a responder a muitas questões importantes, auxiliam na verificação de comportamento fora do padrão, permitem aprofundar e obter mais informações sobre um assunto que tenha sido relatado e ajuda a estimar a capacidade do sistema (LIGUS, 2013, p.15).
3 MÉTODO
O método científico é empregado por pesquisadores para adquirir conhecimento. Ele possui uma sequência lógica para o processo da descoberta científica (MONEY et al., 2007). Essa sequência lógica do método científico pode ser dividida da seguinte maneira (HUNT; SCHERMERHORN; OSBORN, 1999, p. 296):
x O problema: é especificada a questão ou problema para pesquisa
x A hipótese: são formuladas as hipóteses ou explicações nas quais as respostas serão ou não encontradas durante a pesquisa. Essas hipóteses vem de origens diferentes ou de uma experiência anterior e devem ser acompanhadas de uma revisão bibliográfica sobre o tema do problema.
x O projeto: é constituído um projeto de pesquisa, que é a definição da estratégia para dirigir a pesquisa e experimentar as hipóteses.
x O tratamento e análise de dados: os dados serão coletados, analisados e interpretados.
Por fim, pode-se dizer que o método cientifico é um conjunto de processos dirigidos por uma destreza crítica e criadora, direcionando para a descoberta do que é verdadeiro e para a constituição da ciência. A principal ferramenta do método cientifico é a pesquisa (CERVO; BERVIAN, 2004, apud KAHLMEYER-MERTENS et al., 2007, p. 15).
3.1 CARACTERIZAÇÃO DA PESQUISA
Pesquisa pode ser definida, de modo amplo, como uma ação em busca da resolução de um ou mais problemas. É na atividade de pesquisa que existe a busca, a indagação, a investigação, o questionamento do que é real. É ela quem nos vai permitir a construção do saber, a pesquisa ajuda a compreender o que é real dentro do questionamento e direciona nossas ações (PÁDUA, 2004, p. 31).
3.2 CLASSIFICAÇÃO DA PESQUISA
Quanto à natureza da pesquisa, Silva e Menezes (2005, p. 20) destacam que a pesquisa pode ser dividida em: pesquisa aplicada e pesquisa básica.
A pesquisa aplicada enfatiza a prática na resolução de problemas, ainda que a resolução de problemas nem sempre seja construída por uma situação negativa. A essência da resolução de problemas, através da pesquisa aplicada, é mostrar as respostas para dúvidas específicas relacionadas à ação, desempenho ou necessidades políticas (COOPER; SCHINDLER, 2003, p. 32).
A pesquisa básica, também conhecida como pesquisa pura, tem como objetivo responder as dúvidas de forma diferente da pesquisa aplicada. Ela possui o foco em questões complexas, dúvidas de natureza teórica, que possuem pouco impacto direto sobre as ações, desempenho ou decisões políticas (COOPER; SCHINDLER, 2003, p. 32).
Quanto à natureza, a pesquisa aqui apresentada é do tipo aplicada, pois ela envolve o desenvolvimento de um sistema para monitorar a disponibilidade de sistemas online e auxiliar no controle de métricas definidas em acordos entre fornecedores e clientes.
Quanto à abordagem do problema da pesquisa, ela pode ser realizada de duas formas: quantitativa e qualitativa (GRESSLER, 2003, p. 43).
A abordagem quantitativa envolve a constituição de hipóteses, explicações operacionais de variáveis, quantificação dos dados e informações coletadas, tratando esses dados através de métodos estatísticos. Esse tipo de abordagem tem como foco principal garantir a exatidão dos resultados, evitando, assim, distorções de análises e interpretações dúbias. Normalmente, nesse tipo de abordagem as hipóteses definidas possuem uma ligação entre a causa e o efeito, apoiando as conclusões em dados estatísticos, através de testes e comprovações (GRESSLER, 2003, p. 43).
A abordagem qualitativa não utiliza métodos estatísticos na execução de análises de resultados, essa é a principal diferença em relação à abordagem quantitativa. Essa abordagem é aplicada quando há necessidade de apresentar a complexidade de um problema, descartando a manipulação de variáveis e a ausência de estudos experimentais. Na abordagem qualitativa, todos os componentes de e suas interações devem ser ponderados, realizando um entendimento geral dos fenômenos envolvidos. Enquanto na abordagem quantitativa são utilizadas entrevistas fechadas e direcionadas, na abordagem qualitativa faz-se o uso de
entrevistas abertas e não direcionadas, coleta de depoimentos, auto-avaliação, histórias de vida, análise de discurso e estudo de casos (GRESSLER, 2003, p. 43).
Para o desenvolvimento de um sistema, a pesquisa qualitativa se aplica, neste caso ela é baseada na análise do ambiente em que o sistema estará sendo usado e análise das perspectivas dos usuários (KOWALTOWSKI; BREITMAN, 2007). Portanto, quanto à abordagem do problema da pesquisa, a pesquisa aqui apresentada é do tipo qualitativa visto que será desenvolvido um sistema com propósitos específicos.
Quanto aos objetivos da pesquisa, podem ser divididos em três (GIL, 1991, apud SILVA; MENEZES, 2005, p. 21) conforme segue:
x Pesquisa Exploratória: foca a aproximação maior do problema a ponto de formular hipóteses. Inclui levantamento bibliográfico; entrevistas com pessoas que passaram pelo mesmo problema; análise de exemplos que auxiliem o entendimento. De modo geral, toma as formas de Pesquisas Bibliográficas e Estudos de Caso;
x Pesquisa Descritiva: foca a descrição de características de uma população, fenômeno ou associação entre variáveis. Inclui técnicas padronizadas de coleta de dados: questionário e observação sistemática.. De modo geral, toma a forma de Levantamento;
x Pesquisa Explicativa: foca a identificação de fatores que podem contribuir ou determinar a ocorrência dos fenômenos. Tem como premissa explicar o motivo das coisas. Pode fazer uso de método experimental, caso das ciências naturais, e método observacional, caso das ciências sociais. De modo geral, toma as formas de Pesquisa Experimental e Pesquisa Expost-facto.
Segundo Kowaltowski e Breitman (2007, p. 29), “A pesquisa exploratória, além de descrever o fenômeno, faz propostas para novas teorias, ou novas observações, novas métricas para medir o fenômeno [...]”, portanto a pesquisa aqui apresentada se encaixa em uma pesquisa do tipo exploratória, tanto por apresentar novas teorias, quanto mencionar artigos, estudos e livros sobre tema abordado.
Quanto aos procedimentos técnicos, a pesquisa pode ser dividida em (THUMS, 2003, p. 109-112):
x Bibliográfica: caracteriza-se por uma coleta de informações sobre teorias, quadros de referência, autores ou revisões literárias. Não apresenta levantamento de dados, como entrevistas ou questionários;
x Documental: caracteriza-se por uma coleta de informações em documentos, voltada para a pesquisa histórica. Esses documentos podem ser atas de reuniões, assembleias, condomínios, entre outros documentos;
x Experimental: caracteriza-se pela realização de testes, influenciados por variáveis, em condições controladas e definidas pelo pesquisador, para obter o resultado do efeito dessa variável no objeto de estudo. Apresenta análises estatísticas em cima dos dados obtidos;
x Ex-post-facto: caracteriza-se pela pesquisa após um determinado fato, o qual queremos estudar e conhecer, ocorrer;
x Levantamento de dados: caracteriza-se pela investigação dos aspectos do comportamento humano dentro da sociedade. Aplica-se questionários para essa coleta de dados;
x Estudo de caso: caracteriza-se pela investigação de um caso específico, é um aprofundamento da realidade de determinada situação;
x Pesquisa-ação: caracteriza-se pela pesquisa que atua em conjunto a uma ação ou solução de um problema de determinado grupo, há um envolvimento direto entre quem realiza a pesquisa e os envolvidos no problema;
x Participante: caracteriza-se pela investigação em que o pesquisador é também um dos pesquisados, investiga a história e faz parte dela ao mesmo tempo.
Portanto, a pesquisa apresentada pode ser considerada do tipo Bibliográfica, pois apresenta coleta de informações em livros. Pode ser incluída também no tipo Estudo de caso, pois será implementado um sistema específico para determinada realidade.
3.3 ATIVIDADES METODOLÓGICAS
As atividades ou procedimentos metodológicos indicam como será realizada a pesquisa, quais os passos que o pesquisador irá seguir para a verificação das hipóteses da pesquisa (GERHARDT; SILVEIRA, 2009, p. 67).
O fluxograma, na figura 2, apresenta as atividades metodológicas que serão executadas para a realização da pesquisa.
Figura 2 - Fluxograma das atividades metodológicas.
Fonte: A autora (2013).
Caracterização de cada etapa:
x Elaboração da pesquisa bibliográfica: atividade que possui a pesquisa bibliográfica realizada para que se obtenha a base do que é necessário para uma melhor compreensão do problema.
x Levantamento de Requisitos: atividade que definirá o que é necessário para construir o sistema para solucionar o problema apresentado.
x Modelagem do sistema: atividade que apresentará um modelo do sistema, para auxiliar durante o desenvolvimento do mesmo.
x Escolha das ferramentas para o desenvolvimento do sistema: atividade que definirá quais tecnologias ou ferramentas serão utilizadas na construção da solução proposta.
x Desenvolvimento do protótipo do sistema: atividade que compreende o desenvolvimento do sistema.
x Validação: atividade em que serão avaliados todas as partes do sistema e será verificado se está de acordo com o proposto
x Testes: atividade em que serão realizados testes de todos os módulos do sistema, em ambiente de desenvolvimento.
x Implementação do sistema: atividade em que o sistema será posto para utilização no mercado.
x Testes: atividade em que serão realizados testes de todos os módulos do sistema, em ambiente de produção.
x Análise dos resultados: atividade em que serão analisados os resultados da aplicação do sistema em ambiente de produção.
3.4 PROPOSTA
Segundo Silva e Menezes (2005, p. 84), o foco do processo de pesquisa é a solução para o problema nela apresentado. A solução ou proposta apresentada na pesquisa aqui apresentada pode ser visualizada de duas formas: lógica e física.
A lógica é uma visão dos módulos do sistema, conforme a figura 3. Figura 3 - Proposta: visão lógica.
A seguir, a explicação de cada módulo:
x Usuário: entidade que realiza os cadastros e recebe os alertas dos serviços que apresentam algum problema.
x Cadastro: agrupa informações sobre usuários, serviços e contatos.
x Monitoramento: módulo que interage com o serviço a ser monitorado, com o alerta a ser emitido e com o módulo de cadastro para verificar qual serviço deve ser monitorado.
x Serviço monitorado: é a entidade ao qual se deseja obter informações de disponibilidade e desempenho.
x Alerta: módulo responsável por emitir informações ao usuário sobre problemas nos serviços cadastrados.
A física é a visão dos componentes físicos do sistema, conforme a figura 4. Figura 4 - Proposta: visão física.
Fonte: A autora (2013).
Na visão física, há a interação do usuário através de dispositivos como computadores, notebooks ou tablets. Esses usuários interagem com o sistema, que está localizado na nuvem. Mesmo possuindo o sistema em três locais distintos, a replicação
garante a sincronização dos dados fazendo com que o usuário possa acessar qualquer um dos três pontos e tenha a mesma visão do sistema.
O sistema interage de dentro da nuvem com os serviços cadastrados pelos usuários, monitorando e armazenando dados sobre a disponibilidade e desempenho desses serviços.
3.5 DELIMITAÇÕES
O foco do projeto é o desenvolvimento de uma ferramenta para monitoramento de sistemas online, apresentando relatórios com dados que servirão de prova da lentidão ou indisponibilidade de um serviço online, podendo ser utilizado tanto por um fornecedor de serviços, quanto por um cliente. No entanto, existem alguns tópicos desse processo que não serão abordados. Esse projeto exclui:
x monitoramento de componentes físicos, dentro ou fora do ambiente em que o sistema que está sendo monitorado se encontra;
x envio de alertas que envolvam custos financeiros, como alerta via voz ou SMS;
x monitoramento com tempo abaixo do limite mínimo pré-estabelecido;
x monitoramento com mais de três locais distintos, serão utilizados apenas três locais de monitoramento;
