UNIVERSIDADE DO VALE DO ITAJAÍ
CARLOS EDUARDO NOBREGA
ACORDO DE NÍVEL DE SERVIÇO PARA REDES DE
COMPUTADORES
São José
2005
CARLOS EDUARDO NOBREGA
ACORDO DE NÍVEL DE SERVIÇO PARA REDES DE
COMPUTADORES
Trabalho de Conclusão de Curso apresentado ao
Curso de Ciências da Computação do Centro de
Educação da UNIVALI – São José, como
requisito para obtenção do Título de Bacharel em
Ciências da Computação.
Professor Orientador: Alexandre Moraes Ramos
São José
2005
CARLOS EDUARDO NOBREGA
ACORDO DE NÍVEL DE SERVIÇO PARA REDES DE
COMPUTADORES
Este trabalho de Conclusão de Curso foi considerado adequado para a obtenção do
título de Bacharel em Ciências da Computação e aprovado pelo Curso de Ciências da
Computação, da Universidade do Vale do Itajaí, Centro de Educação de São José.
São José, 5 de novembro de 2005.
______________________
Prof. Alexandre Moraes Ramos
UNIVALI – CE de São José
Orientador
_______________________
Prof. Carlos Alberto Schmitt
________________________
Prof. Paulo Roberto Riccioni Gonçalves
Dedico esta monografia ao amor incondicional de
minha mãe, a razão do meu pai, ao carinho e
confiança de minha irmã e a delicadeza de minha
namorada.
AGRADECIMENTOS
Agradeço ao esforço de toda minha família e dedicação na cultivação do meu Eu.
Agradeço a minha futura esposa Liandra Nazário por acreditar em mim, por ter paciência e
me fazer querer ser sempre uma pessoa melhor.
Agradeço aos meus poucos amigos que ainda me restaram dos tempos de rapaz moleque, em
especial Gustavo e Felipe por rirem e chorarem comigo.
As pessoas que contribuíram para fazer de mim, o profissional que sou hoje: Armando Araújo
Filho, Luiz Haroldo de Matos e André Mathias.
E por último ao meu orientador Prof. Alexandre Moraes Ramos e ao amigo e Rodrigo Hames
por terem me ajudado na árdua tarefa de trabalhar o tema deste TCC.
A todos estes, jamais esquecerei.
Não é melhor o que mais alto alcança, senão o que influído pela beleza circundante mais
intensamente sente.
(Grady Booch)
RESUMO
Na economia atual voltada à prestação de serviços, a grande preocupação das empresas
prestadoras de serviço de TI é a qualidade percebida pelo cliente, encontrando na competição
a necessidade de dirigir suas estratégias visando esta percepção e buscando comprovar os
valores agregados a sua entrega. Dentro das organizações, existe o contínuo desafio pela
entrega de adequados níveis de serviços julgados necessários para garantir os investimentos e
gastos na estrutura de TI e seus recursos.
A consagração de Acordos de Nível de Serviço se torna interessante por permitir que sejam
definidos os termos no qual serão estabelecidos os parâmetros de referência para a obtenção
da qualidade do serviço, possibilitando sua medição por meio da monitoria, pela definição das
expectativas e responsabilidades das partes, permitir o planejamento e a contínua procura pelo
ajuste dos níveis e parâmetros frente as reais necessidades referentes à sua entrega.
Sendo assim, este trabalho apresenta os principais conceitos e terminologias relevantes para
se dar início á formalização de um Acordo de Nível de Serviço. Aspecto importante do
presente trabalho, foi apresentar os desafios encontrados no mapeamento e definições do
serviço de rede contratado por um órgão público e a transcrição de suas métricas, passando
por uma proposta de gerenciar-la por meio deste acordo.
ABSTRACT
In the current economy directed to the rendering of services, the great concern for the IT
service providers today is the customer perceived quality, finding in competition the need to
aim their strategies to this perception and seeking to prove the delivery aggregated value.
Inside an organization, there is a continuous challenge to deliver the adjusted level of service
considered necessary to guarantee IT investments and structures expenses.
A Services Level Agreements consecration becomes interesting enabling definition of terms
on which parameters will be established as reference for the quality of service compliance,
turning possible its measurement by the monitor, for the expectations and responsibilities of
the parts definition, to allow the planning and continuous seek of the levels and parameters
adjustment against the real needs referring to its delivery.
Being thus, this work presents the main concepts and relevant terminologies to start the
formalization of a Service Level Agreement. An important aspect of the present work was the
attempt to present the mapping and the network service definition challenges, contracted by a
public agency and its metric transcription, going through a proposal to manage it by the
agreement.
LISTA DE ILUSTRAÇÕES
Figura 1: Hierarquia de atributos de qualidade ............................................
23
Figura 2: Estrutura da priorização de tráfego ..............................................
28
Figura 3: Estrutura da Garantia de Banda ...................................................
29
Figura 4: Estrutura da Gerência de Fila .......................................................
30
Figura 5: Estrutura do Shapping....................................................................
30
Figura 6: Utilização do Shapping ...................................................................
31
Figura 7: Estrutura do Interleaving...............................................................
32
Figura 8: Campo ToS do IP Precedence ........................................................
33
Figura 9: Participação do QoS no SLA. ........................................................
36
Figura 10: Relação entre Consumidor e Provedor estabelecida pelo SLA.
37
Figura 11: Participação do SLA no QoE.........................................................
39
Figura 12: Níveis de Desempenho de Acordos de Nível de Serviço.............
42
Figura 13: Parâmetros de QoS ..........................................................................
45
Figura 14: Modelo de Controle da Informação ..............................................
50
Figura 15: Consórcio da Nuvem entre diversas redes....................................
58
Figura 16: Rede em uma Nuvem FR .................................................................
59
Figura 17: Um único circuito FR pode possuir diversos DLCI Associados..
60
Figura 18: Estrutura da Garantia de Banda .....................................................
61
Figura 19: Métricas de Desempenho de Rede e a seleção Realizada..............
65
Figura 20: Alerta de perda de Conectividade referente a uma rede..............
67
Figura 21: Alerta sobre a perda de 100% dos pacotes de uma rede...............
67
Figura 22: Alerta de Warning referente ao RTA...............................................
67
Figura 23: Gráfico de Utilização de Banda do Canal FR principal da PMSC.
68
Figura 24: Relatório de Estados .........................................................................
70
Figura 25: Demonstrativo dos detalhes de alerta ..............................................
71
Figura 26: Demonstrativo dos detalhes de alerta 2............................................
71
Figura 27: Histórico de Disponibilidade ............................................................
72
Figura 28: Histograma dos alertas .................... ................................................
73
Figura 29: Gráfico de utilização de Banda .........................................................
74
Figura 30: Ciclo de entrega de um SLA .............................................................
75
LISTA DE QUADROS
Quadro 1: Soluções de SLA ................................................................................
43
Quadro 2: Exemplo de Indicadores para o serviço de VoIP.............................
54
LISTA DE TABELAS
Tabela 1: Cálculos de Disponibilidades........................................................
23
Tabela 2: Disponibilidade de um serviço .....................................................
24
Tabela 3: Níveis de Serviço e as métricas para monitoria..........................
66
SUMÁRIO
SUMÁRIO ............................................................................................................................... 13
1 INTRODUÇÃO.................................................................................................................. 15
1.1 CONTEXTUALIZAÇÃO ............................................................................................ 15
1.2 PROBLEMA ................................................................................................................. 16
1.3 OBJETIVOS ................................................................................................................. 17
1.3.1 Objetivo geral....................................................................................................... 17
1.3.1.1 Objetivos específicos .......................................................................................... 17
1.3.1.2 Escopo e delimitação do trabalho ....................................................................... 17
1.4 RESULTADOS ESPERADOS .................................................................................... 18
1.5 JUSTIFICATIVA ......................................................................................................... 18
1.6 METODOLOGIA......................................................................................................... 20
1.6.1 Caracterização da pesquisa .................................................................................. 20
1.6.2 Estrutura do trabalho ......................................................................................... 20
2 REVISÃO BIBLIOGRÁFICA .........................................................................................22
2.1 QUALIDADE DE SERVIÇO EM TI ......................................................................... 22
2.1.1 Qualidade em Sistemas Operacionais................................................................ 25
2.1.2 Qualidade em Banco de Dados............................................................................. 25
2.1.3 Qualidade em Redes de Telecomunicações ......................................................... 26
2.1.4 Qualidade em Rede TCP/IP ................................................................................. 26
2.2 QOS (QUALITY OF SERVICE) EM REDES DE COMPUTADORES E DE
TELECOMUNICAÇÃO.................................................................................................... 27
2.2.1 Controle de Tráfego .............................................................................................. 27
2.2.1.1 Priorização de tráfego ......................................................................................... 28
2.2.1.2 Garantia de Banda.............................................................................................. 28
2.2.2 Gerência de Fila..................................................................................................... 29
2.2.3 Traffic-Shapping e Ferramenta de Políticas...................................................... 30
2.2.4 Fragmentação e Interleaving............................................................................... 31
2.2.5 Classificação de um Pacote TCP/IP..................................................................... 32
2.2.6 Modelos de Classe de Serviço para tráfego - Internet...................................... 33
2.2.6.1 Serviços integrados ............................................................................................. 33
2.2.6.2 Serviços diferenciados ........................................................................................ 34
2.3 ACORDO DE NÍVEL DE SERVIÇO......................................................................... 36
2.3.1 Definição ............................................................................................................... 36
2.3.2 Qualidade de Experiência ................................................................................... 38
2.3.3 Evolução do SLA ................................................................................................... 39
2.3.4 Regras e Objetivos do Acordo de Nível de Serviço........................................... 40
2.3.4.1 Definir Papéis...................................................................................................... 41
2.3.4.2 Gerenciar Expectativas ....................................................................................... 41
2.3.4.3 Controlar Implementação e Execução ................................................................ 42
2.3.4.4 Prover Verificação .............................................................................................. 44
2.3.4.5 Permitir a comunicação....................................................................................... 45
2.3.4.6 Assegurar o retorno de investimento .................................................................. 45
2.3.5 Componentes de um SLA.................................................................................... 46
2.3.6 Definição do Serviço ............................................................................................ 47
2.3.6.1 O Uso de Fatores Críticos de Sucesso na definição do serviço .......................... 48
2.3.6.2 Fatores Críticos de Sucesso................................................................................. 48
2.3.6.3 Indicadores Chave de Desempenho .................................................................... 50
2.3.6.4 Indicadores Chaves de Metas.............................................................................. 50
2.3.6.5 Indicadores Chaves de Qualidade ....................................................................... 51
2.3.6.6 Mapeamento da Qualidade.................................................................................. 54
2.3.7 Três Aproximações para a gerência de SLA..................................................... 54
2.3.7.1 Aproximação de Seguradora ............................................................................... 55
2.3.7.2 Aproximação de Provisão ................................................................................... 55
2.3.7.3 Aproximação Adaptativa .................................................................................... 55
2.4 ESTUDO DE CASO – REDE DA POLÍCIA MILITAR DO ESTADO DE SANTA
CATARINA......................................................................................................................... 56
2.4.1 Introdução .............................................................................................................. 56
2.4.2 Cenário da Polícia Militar do Estado de Santa Catarina .................................. 57
2.4.3 Circuitos Frame-Relay........................................................................................... 57
2.4.3.1 CIR ..................................................................................................................... 60
2.4.3.2 Congestionamento............................................................................................... 61
2.4.3.3 Mapeamento do Serviço Frame-Relay ............................................................... 62
3 PROTÓTIPO DE ACORDO DE NÍVEL DE SERVIÇO ..............................................64
3.1 MONITORIA DOS PARÂMETROS DE QOS DO ACORDO DE NÍVEL DE
SERVIÇO ............................................................................................................................ 65
3.2 ATENDIMENTO DO SLA.......................................................................................... 69
3.3 CONSIDERAÇÕES FINAIS....................................................................................... 74
4 CONCLUSÃO.................................................................................................................... 77
5 APÊNDICES ...................................................................................................................... 85
APÊNDICE A - ACORDO DE NÍVEL DE SERVIÇO (SLA).........................................85
ANEXO 01 - Descrição das localidades físicas e lógicas abrangidas no presente
SLA.......93
ANEXO 02 - Tabela com descrição dos níveis de serviço.................................................95
1
INTRODUÇÃO
1.1 CONTEXTUALIZAÇÃO
De acordo com Prado (2000), nos últimos anos tem sido grande o crescimento da
terceirização de serviços na área de Tecnologia da Informação (TI), principalmente à medida
que tais serviços passaram a ser commodities 1 e permitiram a obtenção de ganhos de escala
por intermédio de fornecedores externos. Colaboram para este crescimento o aumento da
competitividade, a globalização dos mercados e a evolução da tecnologia empregada.
Entretanto, a terceirização de serviços de TI não é simples, e difere da terceirização de outros
serviços tradicionais, tais como limpeza, segurança, contabilidade etc. Processos e recursos
especializados devem ser bem definidos, divididos em objetos que possam receber atenção
considerando-se sua complexidade, para assim definir objetivos, responsabilidades e papéis.
A constante procura por qualidade daqueles que buscam a terceirização da área de TI leva os
provedores de serviço 2 a desenvolverem um detalhado processo, especificando, testando e
abrangendo todos os aspectos do serviço de TI a serem providos e entregues.
Provedores de serviço não devem ser somente capazes de satisfazer a demanda por padrões de
qualidade de seus consumidores, mas também de se comprometer com a qualidade do serviço
conforme os objetivos de seus negócios (considerando a relação custo/benefício). A partir da
qualidade do serviço requerido para se alcançar os objetivos do serviço prestado, deve ser
firmado um Acordo de Nível de Serviço – SLA (Service Level Agreement). Um SLA é gerado
com o intuito de se definir o serviço a ser prestado, englobando todos os aspectos a fim de se
ter um entendimento comum da natureza e do nível de serviço desejado.
Um SLA descreve as métricas quantitativas para medir a disponibilidade ou desempenho do
recurso computacional (exemplo: a disponibilidade mensal do servidor de e-mail não será
menor que 97%) ou baseado em eficiência e eficácia de um processo (exemplo: não menos
que 97% dos pedidos de criação de e-mail serão atendidos em vinte e quatro horas).
1
Commodities: Produtos de consumo mundial (economiabr.net)
Provedor de serviço é tratado neste trabalho tanto como um Provedor externo à empresa
(terceirizado) como um Provedor interno (departamento).
2
Os Acordos de Nível de Serviço (SLA) também podem constituir relações entre fornecedores,
departamentos e serviços que possuem interdependência, plausíveis de sofrer degradação com
a má qualidade do serviço.
1.2 PROBLEMA
As atuais normas e documentos descrevem o que deve ser feito, especificando entradas e
saídas de um SLA, mas não auxiliam ou definem como fazer para se obter estes dados, até
porque isto depende muito da natureza do objeto terceirizado.
Tecnicamente, extrair do lado operacional as regras do negócio e estabelecer métricas
realistas para a entrada e saída constitui uma das maiores dificuldades na elaboração de um
SLA. Esta incapacidade se agrava por não se poder estabelecer critérios de exigência, por não
conseguir controlar expectativas no que refere à implementação e execução das tarefas,
possibilitar a verificação, entre outros motivos (LEE e BEN-NATAN, 2002, p.5).
É certo que a tecnologia e a produtividade evoluem e determinado nível de desempenho, hoje
considerado bom, pode não ser no futuro. Considerando-se tal premissa, a confecção do SLA
deve ser feita em cima de métricas flexíveis que possam acompanhar esta evolução e permitir
que as empresas possam renegociar os SLAs, adequando-se às novas exigências e aos níveis
de complexidade em questão.
Atualmente, as empresas se utilizam de ferramentas de monitoria e, assim, definem acordos
baseados nas informações dessas ferramentas. Os Acordos de Nível de Serviço “são
geralmente baseados no que é fácil de medir, ao invés de no que deveria ser medido e falham
ao entregarem serviços sem relevância às necessidades” (MAURER, MATLUS e FREY,
2000, p.21).
Em muitos casos, não se leva em conta que um contrato mal elaborado pode trazer danos aos
envolvidos, seja pela entrega de serviços que não atendam às reais necessidades do
consumidor, seja pela incapacidade dos provedores de distinguirem seus serviços frente aos
concorrentes. De outro lado, ter somente um contrato e não saber se este está sendo cumprido
é outro problema, tornando necessário mapear o serviço com indicadores passíveis de serem
monitorados e alertar o consumidor das não conformidades dos aspectos do contrato.
O curso de Ciência da Computação da Universidade do Vale do Itajaí, em sua matriz
curricular, não explora em nenhuma disciplina o conteúdo relativo ao controle sobre os
serviços prestados pela área de Tecnologia da Informação. E trata-se de uma matéria
importante, na medida em que, se um profissional da área de TI não tiver conhecimentos
sobre estes acordos e sobre como realizar a devida monitoria dos recursos, poderá
superestimar ou subestimar os componentes computacionais necessários para atender a
qualidade exigida pelo cliente, não sendo capaz de controlar custos e justificar investimentos
na área.
1.3 OBJETIVOS
1.3.1 Objetivo geral
Realizar uma aplicação prática de um SLA em serviços de Tecnologia da Informação em
serviço de rede Frame-Relay.
1.3.1.1 Objetivos específicos
•
Levantar práticas comuns e normas internacionais, para servir de guia na aplicação;
•
Levantar os conceitos de Qualidade de Serviço;
•
Identificar as práticas de mercado e normas aplicadas pela IBM e CISCO e aplicá-las na
confecção de um SLA;
•
Confeccionar um SLA;
•
Realizar a monitoria dos indicadores técnicos (QoS) do SLA.
1.3.1.2 Escopo e delimitação do trabalho
O escopo deste trabalho visa a criação de um protótipo de Acordo de Nível de Serviço na área
de Telecomunicações, servindo como base para a confecção de futuros SLAs. Este trabalho
não tem como objetivo elaborar uma ferramenta que colete os dados para avaliação de
desempenho do serviço. Para isto, foram utilizado duas ferramentas de domínio público
chamadas NAGIOS e CACTI para a monitoria dos quesitos do desempenho de rede, não
considerando aspectos como suporte do Help Desk e tempos de reparos.
1.4 RESULTADOS ESPERADOS
Apresentar um protótipo de um Acordo de Nível de Serviço e sua monitoria, tendo como
resultado uma referência análoga para a definição de futuros SLAs. Este protótipo tomará
como referência as práticas de mercado (casos de sucesso da IBM e da CISCO) e normas
internacionais aplicadas à terceirização de serviços na área de Tecnologia da Informação.
1.5 JUSTIFICATIVA
A competitividade de uma empresa está diretamente ligada aos seus serviços de Tecnologia
de Informação (TI). Qualquer problema no serviço de TI pode causar sérios danos ao negócio.
Isto significa que os profissionais da área de TI vivem sobre constante pressão para garantir
adequados níveis de serviço aos usuários. Considerando-se a complexidade e a natureza
dinâmica dos serviços de TI, entregar e garantir altos níveis de serviços constitui um
permanente desafio.
Com o auxílio de um Acordo de Nível de Serviço, os profissionais de TI podem definir os
níveis de serviços adequados e gerenciar as expectativas que envolvam a prestação de
determinado serviço, além de melhor gerenciar os riscos e assegurar a infra-estrutura da TI,
focando a área nos objetivos da empresa.
Acompanhando a tendência das terceirizações, tendo em mente a constante necessidade de se
justificar os gastos da TI e alcançar o reconhecimento pela provisão de bons serviços, os
profissionais da Computação precisam tomar conhecimento da proposta e práticas atuais no
mercado na busca da entrega de melhores serviços.
O The Open Group (2004) junto ao Sage Research 3 realizou uma enquete e publicou em seu
SLA Management Handbook do ano de 2004 a perspectiva de mais de 150 empresas norteamericanas sobre o uso de Acordos de Níveis de Serviço na área de TI. Uma alta porcentagem
(60%) indicava possuir Acordos de Nível de Serviço internamente (entre departamentos),
outros 20% estariam planejando adquirir em breve. As razões mais comuns para se adotar um
SLA foram apontadas pelas empresas como:
3
É uma empresa dedicada a pesquisas de mercado e consultoria, focada exclusivamente em
produtos de tecnologia e provedores de serviço nos EUA.
•
Permitir melhor planejamento (69%);
•
Ajudar a reduzir ou controlar custos (61%);
•
Permitir a empresa a oferecer SLA para consumidores internos (55%);
•
Convencer a gerência a experimentar novos serviços e aplicações (52%).
•
Metade dos profissionais de TI disseram que serviços como e-mail, web hosting, e IP
VPNs, com garantias de um Acordo de Nível de Serviço possuem um valor 30%
maior daqueles que não o possuem;
•
42% dos profissionais de TI reportaram que obter um relatório do Acordo de Nível de
Serviço do seu provedor é extremamente valioso, e em porcentagem similar acreditam
que um crédito automático pelo não cumprimento de uma cláusula também adicionaria
valor.
•
Aproximadamente um terço dos entrevistados mudaram de provedor em resultado das
contestações com o Acordo de Nível de Serviço e outros ¼ deram fracas
recomendações de seus provedores para outros devido ao acordo.
•
Os acordos mais comuns de serem contestados entre as empresas e provedores, por
aplicação, incluem Web hosting (48%), IP VPN (31%) e e-mail (29%).
Empresas importantes no segmento de tecnologia salientam a importância do uso de Acordos
de Nível de Serviço, como escreve Sposito (2004), em sua reportagem para a Info Corporate,
in verbis:
“Um dos principais desafios do CIO 4 é traduzir métricas técnicas em
métricas que fazem sentido para o negócio", afirma Cassio Dreyfuss, vicepresidente e diretor de pesquisas do Gartner para a América Latina. "Ele
precisa mostrar para a organização que os investimentos em tecnologia estão
trazendo resultados palpáveis. E o SLA é uma medida de eficiência,
portanto, uma métrica de negócio", diz Dreyfuss.
"O SLA voltou à moda porque as demandas são maiores do que os recursos
de TI disponíveis. Se não houvesse escassez de recursos e o custo não fosse
um problema, o SLA não seria tão importante", diz João Cerqueira, gerente
da HP Consulting
"De que adianta o CIO ter um indicador mostrando que um roteador possui
99,99% de disponibilidade se ele não sabe para que o equipamento está
4
Chief Information Officer – Chefe do gabinete de Informação, responsável pelos serviços de
informação.
sendo usado e qual sua importância para o negócio?", afirma Antonio Celso
Leitão, gerente de soluções de storage, data center e segurança da IBM
Brasil.
"Até para poder justificar melhor os investimentos, o CIO deve saber
exatamente quem está precisando de mais recursos", afirma Gerson
Gonçalves, consultor da Computer Associates.
O uso do Acordo de Nível de Serviço deve ser definido de maneira que ferramentas de
monitorias possam ser utilizadas no auxílio à identificação de melhorias para o processo rumo
aos objetivos da empresa, apresentando o que monitorar na constante verificação de
processos, extraindo informações valiosas de eficiência, gerência de riscos e reduções de
custos, fazendo a TI participar do papel estratégico nas empresas, transformar estratégia em
ação.
A partir destes aspectos e dos que serão apresentados no item 2.3.4 - Regras e objetivos de um
Acordo de Nível de Serviço – é que este trabalho foi realizado, introduzindo e possibilitando
praticar o uso destes acordos de forma efetiva para um profissional de TI e também contribuir
na disseminação do assunto aos alunos do curso de Ciência da Computação da UNIVALI e
profissionais da área, haja vista que este tópico não é tratado formalmente na matriz curricular
deste Curso.
1.6 METODOLOGIA
1.6.1 Caracterização da pesquisa
A metodologia usada para o desenvolvimento deste trabalho de conclusão de curso
enquadrou-se nas classes de pesquisa exploratória. Trata-se de uma pesquisa exploratória
porque envolveu pesquisa bibliográfica, enquanto buscou também, ampliar e aprofundar os
conhecimentos. Estes auxiliaram na definição de objetivos do estudo e formaram o referencial
para elaborar a fundamentação. Por último foi realizado o Estudo de Caso para a aplicação
dos conhecimentos adquiridos na pesquisa.
1.6.2
Estrutura do trabalho
Este trabalho está organizado de forma a contemplar inicialmente, no item um, a apresentação
do conceito de qualidade e seu uso na tecnologia da informação; no item dois é apresentada a
necessidade de uso de mecanismos para a garantia da qualidade na rede enquanto no item
três, é apresentado os conceitos que envolvem o Acordo de Nível de Serviço.
No item quatro é apresentada a rede em que foi realizado o estudo de caso, apresentando a
tecnologia empregada e estabelecido no apêndice, o SLA proposto para a rede em estudo.
Por fim é realizada a monitoria dos parâmetros de QoS deste SLA para uma rede específica e
confrontadas as cláusulas deste SLA, fechando com as considerações e conclusão do trabalho
realizado.
2
REVISÃO BIBLIOGRÁFICA
2.1 QUALIDADE DE SERVIÇO EM TI
A Qualidade de Serviço está surgindo rapidamente em soluções de TI, motivada pelo
crescimento das aplicações em tempo real e nas expectativas por parte do cliente no uso da
tecnologia. A qualidade é definida pela NBR ISO 8402 (1994) como “Totalidade de
características de uma entidade que lhe confere a capacidade de satisfazer as necessidades
explícitas e implícitas”. A entidade é o produto e serviço em si, as necessidades explícitas são
as próprias condições e objetivos propostas pelo produtor, enquanto as necessidades
implícitas incluem as diferenças entre os usuários, a evolução no tempo, as implicações
éticas, questões de segurança e outras visões subjetivas.
À medida que mais e mais companhias resolvem conduzir seus negócios pela Internet, a
qualidade de serviço passa a se tornar um diferencial. Segundo dados que constam na
homepage da Embratel, “a qualidade e credibilidade de qualquer iniciativa na Internet baseiase no desempenho percebido pelo usuário final em sua interação com a aplicação que utiliza”.
Dependendo do tipo de serviço contratado e conduzido, com relação às expectativas por parte
do cliente, qualquer degradação no nível da qualidade do serviço, seja da telecomunicação, do
banco de dados ou da rede, será percebida e poderá gerar conseqüências negativas.
A qualidade é hierarquicamente disposta (Figura 1), englobando disponibilidade, estabilidade,
eficiência, eficácia e ergonomia, em nível de necessidade, por Maurer, Matlus e Frey (2000,
p.8). A fundação da qualidade de um serviço de TI é a disponibilidade, pois o grau de um
problema de atraso de tempo de resposta se torna irrelevante se o serviço não estiver
disponível quando e onde for preciso.
Figura 1 – Hierarquia de atributos de qualidade
Fonte: Maurer, Matlus e Frey (2000, p.8)
Considera-se disponibilidade a probabilidade que um produto ou serviço irá operar quando
necessário, expresso pela fórmula na tabela 1, onde up-times representa o tempo disponível e
down-times o tempo indisponível:
Tabela 1: Cálculos de Disponibilidades.
Fonte: Adaptado de THE OPENGROUP (2004).
Os resultados obtidos através do cálculo de disponibilidade devem ser expressos em
porcentagem, tendo em vista que a tabela 2 detalha o impacto das casas decimais tem em
relação ao tempo disponível ao longo de um ano.
Disponibilidade
Tempo Indisponível em um ano
medida
99,9999999
0,03 seg
99,999999
0,32 seg
99,99999
3,15 seg
99,9999
31,54 seg
99,999
5,26 min
99,99
52,56 min
99,9
8,76 hrs
99
3,65 dias
90
36,5 dias
Tabela 2: Disponibilidade de um serviço ao longo de um ano.
Fonte: Baseado em THE OPEN GROUP (2004).
Estabilidade por sua vez é considerada como a capacidade de manter o nível de desempenho
quando usado nas condições especificadas de um equipamento ou sistema(ISO 9241-11,
1998).
Eficiência é a capacidade de operar no nível de desempenho requerido em relação à
quantidade de recursos empregados, quando usados nas condições especificadas (ISO/IEC
9126, 1991).
Já a eficácia é a capacidade de executar uma tarefa de forma correta e completa. (ISO 924111, 1998).
Enquanto que a ergonomia é, segundo Wisner (1987, p.12) "o conjunto de conhecimentos
científicos relativos ao homem e necessários para a concepção de ferramentas, máquinas e
dispositivos que possam ser utilizados com o máximo de conforto, segurança e eficácia".
Assim, baseando-se nos cinco parâmetros de qualidade, o analista de sistemas deve, ao
escolher seus sistemas, dar atenção a cada um deles, pois impactarão na percepção dos
usuários em relação ao uso dos serviços disponibilizados.
2.1.1 Qualidade em Sistemas Operacionais
Os parâmetros do sistema operacional podem ter um grande impacto na percepção da
qualidade de serviço pelo usuário. Como exemplo, a prioridade das aplicações configuradas
em uma central de processamento (CPU) podem vir a limitar serviços disponibilizados em um
servidor como a taxa de atualização dos quadros de um sistema de vídeo, atraso na correção
ortográfica de livros.
Os limites básicos de um Sistema Operacional relatam um comportamento em tempo real.
Herrtwich (1991, p.279-284) apresenta requisitos de tempo real colocados no sistema
operacional para satisfazer aplicações multimídias como exemplo, questões críticas como
desempenho e reserva de recursos.
O tipo de desempenho mais importante é aquele percebido pelo usuário eventual do sistema.
É possível tornar um sistema operacional mais rápido sem mudar a implementação dos seus
componentes. Com o conhecimento apropriado do sistema operacional e do usuário (ou
aplicação) que irá usá-lo, o analista de sistemas pode rearranjar as ordens nas quais os
processos são chamados, fazendo com que o usuário perceba que o sistema está respondendo
mais rápido (SINGH, 2005, p.1).
Como artifícios para melhorar o desempenho de um Sistema Operacional (S.O.), o analista
também pode reservar recursos de disco, memória e processamento suficientes que julgue
necessário. Cada S.O. apresenta particularidades e necessidades de recursos diferentes.
Caberá ao analista de sistemas levantar essas necessidades e escolher entre os diversos
Sistemas Operacionais disponíveis no mercado o que melhor atende suas necessidades de
qualidade.
2.1.2 Qualidade em Banco de Dados
Os bancos de dados podem possuir um volume de objetos muito grande, manipulações e
visualizações dos objetos espalhados neste banco podem passar a ser uma tarefa de grande
custo tanto em relação ao uso de recursos como de tempo. Com o custo aumentado, latências
são geradas e um gerenciamento se faz necessário para garantir a qualidade requerida e a
entrega eficiente das informações.
Um sistema de banco de dados com desempenho suficiente para atender os serviços e
dimensionado para a demanda devem ser considerados, e estas informações devem ser
buscadas junto aos desenvolvedores do banco de dados.
2.1.3 Qualidade em Redes de Telecomunicações
No campo das redes de comutação de pacotes e rede de computadores, a qualidade de serviço
é referida como a probabilidade de uma rede atender um contrato de tráfego ou de um pacote
passar de um ponto a outro na rede. Já no campo da telefonia, a qualidade de serviço se refere
à falta de ruído e tons em um circuito, nível apropriado do som entre outros, podendo se
estender à telefonia móvel.
2.1.4 Qualidade em Rede TCP/IP
A rede mundial Internet está baseada no conjunto de protocolos definidos pela arquitetura
TCP/IP. As mensagens são enviadas em pacotes IP seguindo a filosofia do melhor esforço
(Best Effort); cada nó 5 na rede compartilha o total de banda entre os demais, concorrendo na
transmissão de dados. Quando a banda se esgota, pacotes começam a ser descartados de
maneira que não há distinção entre fluxos 6 de dados, não havendo garantia de que o serviço
será entregue (RFC 791, 1981, p.2).
A garantia de qualidade em uma rede TCP/IP se faz necessária em situações em que
importantes aplicações estarão disputando a rede com outros serviços e:
•
Não podem suportar a falta de disponibilidade de largura de banda;
•
É preciso certas garantias envolvendo a sensibilidade ao retardo das informações como
a de vídeo e voz;
•
5
Garantia de alocação de recursos de rede.
Qualquer dispositivo unido à rede.
Um fluxo pode ser definido de uma série de maneiras. Uma maneira comum refere a combinação
de um endereço de origem e destino, número de socket de origem e destino, e o identificador de
sessão. Também pode ser definido de modo mais geral como qualquer pacote vindo de uma certa
aplicação ou interface de rede. Este trabalho considera que um fluxo pode ser qualquer um destes.
6
Tais situações são previstas e tratadas total ou parcialmente pelo uso de QoS (Quality of
Service) nos dispositivos de rede tais como roteadores e switchs. Nestes equipamentos, o QoS
se faz necessário por não controlarem o tráfego e nem gerenciarem as filas de dados da rede.
Portanto, observa-se que o QoS é fundamental para se obter um serviço de rede com
qualidade, visto que um serviço que utiliza um hardware, sistema operacional e banco de
dados, dimensionados às necessidades pode sofrer na percepção do usuário sobre a qualidade
se a rede não puder fornecer certas garantias na entrega das informações.
A seguir, os conceitos QoS serão focados e mais explorados em aplicação para redes de
computadores e de telecomunicações.
2.2 QOS (QUALITY OF SERVICE) EM REDES DE COMPUTADORES E DE
TELECOMUNICAÇÃO
Geralmente o termo QoS – Quality of Service é usado em redes de telecomunicação e foi
definido pela União Internacional de Telecomunicações (1995, p.9) como “o efeito coletivo
do desempenho dos serviços, que determina o grau de satisfação do usuário” e pela Cisco
(2004a) como a “capacidade de uma rede de prover melhores serviços para o tráfego de redes
selecionadas, em diversas tecnologias incluindo Frame Relay, Asynchronous Transfer Mode
(ATM), Ethernet e redes 802.1, SONET e redes roteadas em IP”.
Tentando contornar a filosofia da rede TCP/IP de best-effort, o QoS se utiliza de mecanismos
de diferenciações em cima de fluxos de dados transmitidos em uma rede. Os pacotes podem
vir a serem descartados, sofrerem atrasos ou entregues fora de ordem, denegrindo a interação
do usuário com os sistemas e serviços disponibilizados na rede. Para contornar isso, o QoS
implementa o controle de tráfego,
gerência de fila, shapping e fragmentação com
interleaving. Os seguintes capítulos foram extraídos do Internetworking Technology
Handbook da Cisco.
2.2.1 Controle de Tráfego
Uma maneira de os elementos da rede manipularem a sobrecarga de recebimento de dados é
pelo uso de algoritmos de fila, separando o tráfego e determinando alguma maneira de
priorizá-lo no link de saída. Existem dois modelos para se realizar o controle sobre o tráfego:
um modelo é pela própria priorização do tráfego e o outro, pela limitação ou garantia de
banda.
2.2.1.1 Priorização de tráfego
Os pacotes são separados pelo roteador em diferentes filas podendo priorizar a entrega de
alguns sobre os outros. Pacotes são divididos em quatro filas distintas - alta, média, normal e
baixa -, de acordo com sua prioridade. Pacotes que não forem classificados neste mecanismo
de priorização seguem na fila normal, como mostra a figura 2.(CISCO, 2004a).
Figura 2: Estrutura da priorização de tráfego.
Fonte: Adaptado de Cisco (2004a, p.19).
O Atendimento às filas é feita, inicialmente, pela que possui o rank mais alto, a fila logo
abaixo é atendida assim que a fila superior estiver vazia e assim subsequentemente.
2.2.1.2 Garantia de Banda
A Garantia de Banda foi desenvolvida para permitir que várias aplicações compartilhem uma
rede com uma garantia mínima da utilização da banda. Assim, pode-se garantir que um
tráfego específico receba uma porção fixa da banda disponível e deixe o restante da banda
para outros tráfegos, como mostra a figura 3. (CISCO, 2004a).
Figura 3: Estrutura da Garantia de Banda.
Fonte: Adaptado de Cisco (2004a, p.19).
Cada fila recebe uma fatia da banda total disponível, o algoritmo para cada pacote atendido
calcula o seu consumo, quando a sua cota for gasta a próxima fila é atendida, assim até o
encerramento da entrega da fila.
2.2.2
Gerência de Fila
Pelo fato das filas de pacotes nos roteadores possuírem um tamanho finito e limitado em seus
buffers 7 , quando este limite se enche qualquer pacote adicional que tentar entrar na fila é
descartado. Este caso é chamado de Drop Tail. O problema desse descarte além de gerar
atrasos devido à necessidade da aplicação solicitar o pacote novamente é que o equipamento
de rede não possui a capacidade de prevenir este descarte mesmo que este pacote tenha sido
marcado como alta prioridade anteriormente (CISCO,2004a). Então, mecanismos de Gerência
de Fila (Figura 4) são realizados para alcançar dois propósitos:
•
Garantir que a fila jamais esteja cheia;
•
Permitir algum tipo de critério que descarte pacotes de baixa prioridade antes dos de
alta.
7
Parte da memória usada temporariamente para guardar dados.
Figura 4: Estrutura da Gerência de Fila.
Fonte: Adaptado de Cisco (2004a, p.19).
2.2.3 Traffic-Shapping e Ferramenta de Políticas
Segundo a Cisco (2004a), Outra maneira de se evitar a sobrecarga de um link é aplicando a
limitação do uso por meio de um Shapping ou de Políticas, prevenindo o bloqueio ou atraso
de um fluxo devido à sobrecarga do link.
O Shapping coloca em buffer pacotes que implicariam em excesso de fluxo e os libera de
forma a não sobrecarregar o link enquanto ferramentas de políticas simplesmente descartam o
fluxo excedente, como demonstrado na figura 5.
Figura 5: Estrutura do Shapping.
Fonte: Adaptado de Cisco (2004a, p.19).
Com um tráfego configurado em proporções, uma central com um link de 1.500kbps 8 evita a
sobrecarga pelo excesso de fluxo nos links menores de suas filiais, transmitindo para cada
uma delas aos poucos, o fluxo adequado.
Assim dispositivos de rede lentos podem ser ligados a dispositivos mais rápidos sem ser
sobrecarregados pelo excesso de fluxo como na figura 6.
Figura 6: Utilização do Shapping
Fonte: Baseado em Cisco (2004a, p.19)
2.2.4 Fragmentação e Interleaving
Segundo a Cisco (2004a), pode demorar para que o pacote alcance o seu destino, por este
permanecer em longas filas entre os diversos roteadores em seu caminho, ou tomar rumos
maiores na tentativa de evitar o congestionamento. Alternativamente, este pode tomar uma
rota direta. O atraso é altamente imprevisível. Para isto o QoS propõe a eficiência de link,
além da priorização de alguns pacotes sobre os outros, implementando a fragmentação e o
interleave 9 de link permitindo que grandes pacotes sejam quebrados em pacotes menores para
dar espaço ao interleaving de, por exemplo, um pacote de voz sensível ao retardo que está
sendo atrasado por grandes pacotes a sua frente, como mostra a figura 7.
8
9
Kilobytes per second – medida de tráfego de rede em milhares de bytes por segundo.
Interfoliamento.
Figura 7: Estrutura do Interleaving.
Fonte: Adaptado de Cisco (2004a, p.19).
Assim, pacotes grandes sofrendo esta fragmentação permitem que outros pacotes sejam
enviados para a fila de transmissão sem terem que aguardar que todo o pacote grande seja
transmitido.
2.2.5 Classificação de um Pacote TCP/IP
Segundo a Cisco (2005a, p.6), “para se prover preferência sobre alguns tipos de tráfego, a
identificação de pacotes deve ser feita e em seguida sua marcação pode ou não ser feita,
caracterizando estas duas etapas a classificação”. Quando um pacote é identificado, mas não
marcado, a classificação é dita como baseada em per-hop 10 , isto é, quando a classificação é
permitida somente no dispositivo aonde ela se encontra não sendo passado para o próximo
roteador.
Quando pacotes são marcados para o uso em outras redes e roteadores, bits no campo Tipo de
Serviço (Type of Service - ToS) no IP Precendence do cabeçalho IPv4 são usados para
classificar cada pacote e assim ser entregue a outros roteadores, como mostrado na figura 8.
10
Entre um roteador e outro.
Figura 8: Campo ToS do IP Precedence.
Fonte: Adaptado de Cisco (2004a, p.9).
Os 3 bits mais significativos (correspondendo aos bit 32, 64 e 128) do ToS constituem os bits
usados pelo IP Precendence. Provendo seis diferentes classes de serviço com prioridade de 0
a 7 (o valor 6 e 7 são reservados e não são usados) para os pacotes IPs. (RFC 1349, 1992, p.34)
2.2.6 Modelos de Classe de Serviço para tráfego - Internet
Existem dois modelos de classes de serviço para tráfego Internet que estão sendo
considerados e desenvolvidos pelo Internet Engineering Task Force - IETF, que se adequam
de acordo com o tipo de aplicação e arquitetura de rede. Estes modelos são: Integrated
Service – IntServ e Differentiated Service – DiffServ, respectivamente.
2.2.6.1 Serviços integrados
Também conhecidos como IntServ, o serviços integrados fornecem garantias de QoS
individualmente a cada fluxo. Para tal, efetuam absoluta reserva de recursos nos elementos de
rede intervenientes na comunicação. Os recursos são reservados em todos os roteadores
intermediários e no nó de destino usando protocolos de sinalização (controle) antes da
transmissão de dados. Recursos que forem reservados devem ser atribuídos aos pacotes do seu
respectivo fluxo. Finalmente, as características de tráfego negociadas no momento em que os
recursos foram alocados devem ser monitoradas, para que seja verificado se as premissas
assumidas quanto às características do tráfego foram respeitadas durante o período de
conexão (RFC 1633, 1994, p.3-5).
Propostas de implementação de arquiteturas IntServ sofrem críticas basicamente por uma rede
IP com vários nós, sofrer limitações pelo fato da alocação dos recursos serem feitas para cada
fluxo de dados, exigindo grande espaço de armazenamento e gerando sobrecarga de
processamento nos roteadores. A implementação de IntServ em uma rede grande, como a
Internet, com dezenas de milhares de usuários e com diversos fluxos por usuário, implica em
complexos roteadores com alto poder de processamento e memória. Cada nó possui um
estado para cada fluxo, aumentando a complexidade do sistema. O poder de processamento se
fará necessário, pois a tarefa de escalonamento dos pacotes para cada fluxo é complexa e
fundamental para a garantia da qualidade de serviço acordada. A outra desvantagem é a perda
de padrões para bilhetagem e tarifação, aplicações com RSVP 11 e IntServ são recomendados
apenas para redes de pequeno porte ou privadas.
2.2.6.2 Serviços diferenciados
De acordo com os problemas encontrados com a implantação do IntServ o IETF introduziu os
Serviços diferenciados também conhecidos como DiffServ. Uma segunda proposta na qual
fluxos são agregados em classes de serviço ou para um conjunto de fluxos de dados, de
acordo com suas características e tratados melhores uns que os outros.
Os pacotes IP são marcados como sendo de uma determinada classe de QoS. Os roteadores
reservam recursos para lidar com pacotes de cada classe. O DiffServ trata todos os pacotes
dos usuários de uma mesma classe usando os recursos alocados para aquela classe de QoS.
Assim, os recursos que possibilitam o envio de pacotes com uma determinada QoS são
compartilhados por todos os pacotes que estão marcados como sendo daquela classe. Este
conceito não garante uma qualidade absoluta como os protocolos fim-a-fim propostos na
arquitetura IntServ, porém permite uma razoável implementação de reserva de recursos em
grandes redes. (RFC 2474, 1998, p.2-3)
Estes modelos auxiliam a aliviar os problemas referentes ao congestionamento, entretanto
muitas vezes há trafego demais para a banda disponível e a solução se encontra na provisão
de maior recurso de banda.
11
RSVP é um protocolo padrão definido pela IETF (RFC 2205) que permite uma aplicação
dinamicamente reservar banda de rede. RSVP permite as aplicações a requisitarem por um QoS
específico para cada fluxo de dados (WHITE, 1997, p.100).
2.2.7
Considerações Finais
O provedor deve prover em sua rede e em seus servidores as aplicações que rodam um
desempenho desejado para o nível de serviço contratado. Com o uso de QoS o provedor pode
compartilhar recursos e tentar adaptar a locação para cada aplicação ou consumidor, de
maneira a melhor atender ao nível de acordo de serviço estipulado (VERMA, 1999, p.12).
Algumas garantias especificadas neste acordo podem exigir a reserva e a determinação de
recursos computacionais e principalmente de rede, de maneira que não pode ser garantida sem
o uso dos mecanismos apresentados pelo QoS. Se o provedor de serviço optar pela super
provisão de requisitos, o custo será aumentado devido a sua subutilização. Também estará
sujeito à baixa escalabilidade pelo fato de não se adaptar bem às mudanças ou crescimento de
uso ao menos que tenham sido antecipados inicialmente, contribuindo para a menor eficiência
do baixo custo (THE OPEN GROUP, 2004, p.11).
Outro fator que motiva o uso de QoS é de permitir a programação da aquisição de novos
recursos quando estes sistemas computacionais estiverem próximos de sua utilização máxima,
pois programas de monitoria acusarão a aproximação do esgotamento de recursos
computacionais diferenciados pelo QoS, como largura de banda na rede, poder de
processamento e alocação de disco.
Assim, o escopo do QoS associado ao SLA encontrado na figura 9, está ligado aos requisitos
de desempenho de um serviço de redes e telecomunicação, sendo este o mecanismo pelo qual
procura garantir os atendimentos de vazão, tempo de resposta, entre outros, que refletem na
percepção de desempenho do produto ou serviço.
Figura 9: Participação do QoS no SLA.
Fonte: Baseado no THE OPENGROUP (2004, p.107).
Os parâmetros de desempenho mínimos de um sistema computacional estabelecidos no SLA
podem ser reservados e controlados a partir do uso de ferramentas de QoS. Neste trabalho é
assumido que o provedor do serviço disponibilizará e tratará os recursos mínimos para o
atendimento do serviço em seus requisitos técnicos de desempenho, sempre reservando ou
diferenciando a computação exigida pelo cliente, sendo capaz de gerar relatório sobre a
utilização, disponibilidade e fatores explicitados em contrato para fins comprobatórios de
atendimento às expectativas.
2.3 ACORDO DE NÍVEL DE SERVIÇO
2.3.1 Definição
Maurer, Matlus e Frey (2000, p.1) definem de maneira ampla o Acordo de Nível de Serviço
(SLA – Service Level Agreement ) como:
Uma medida contratual que o consumidor do serviço utiliza para alcançar os
objetivos chaves de seu negócio. Este acordo define as expectativas das
partes, descreve o serviço que será entregue, contatos, especifica métricas
para qualificar a eficiência das atividades, funções e processos e como medir,
examinar, mudar e controlar.
De maneira semelhante, temos:
O SLA é o acordo formalmente negociado entre duas partes, às vezes
chamado de garantias de nível de serviço. Como descrito na figura 10, é um
contrato (ou parte deste) que existe entre o provedor de serviço e seu
consumidor, designado a criar um comum entendimento, prioridades,
responsabilidades etc. (THE OPEN GROUP, 2004, p.112).
Figura 10: Relação entre Consumidor e Provedor estabelecida pelo SLA.
Fonte: TeleManagement Forum (apud LEE, BEN-NATAN, 2002, p.4).
Por estas definições em sua forma mais básica, um acordo de nível de serviço (SLA) é um
contrato ou acordo que formaliza uma relação de negócio, ou parte desta relação, entre duas
partes. Em sua forma mais comum, esse acordo ou contrato é estabelecido entre um provedor
de serviço e um consumidor e define os papéis dos envolvidos, os padrões de atendimento e
os recursos financeiros.
Um acordo de nível de serviço trata de promessas que são traduzidas em cláusulas contratuais
que podem ser tanto genéricas como extremamente detalhadas, e genericamente incluirão
passos que devem ser tomados pelos provedores de serviço e clientes no evento de falha.
Promessas que abrangem a disponibilidade de um sistema, tempo de resposta para uma
requisição ser atendida e velocidades de transmissão de dados.
O objetivo de se empregar um SLA em uma corporação é de aprimorar a Qualidade de
Experiência (QoE - Quality of Experience) do serviço para seus clientes, sejam estes internos
ou externos à organização.
2.3.2
Qualidade de Experiência
Segundo o The OpenGroup (2004) a Qualidade de Experiência é um termo que permite a
subjetividade, assim como a objetividade das medidas de um QoS, desempenho e todos os
aspectos das interações (experiência) com o produto ou serviço, incluindo aspectos difíceis de
definir como:
•
Educação, conhecimento, maneira como um call center responde aos pedidos,
problemas etc.
•
Ergonomia de um produto, facilidade de uso, localização, qualidade da
documentação;
•
Imagem da marca;
•
Experiência com parceiros, distribuidores etc.
O The Open Group (2004, p.1) define QoE como:
termo coletivo para formar uma medida de qualidade de serviço ou produto,
e inclui todos os aspectos do serviço: seu desempenho, nível de satisfação do
cliente na total experiência, pré e pós venda, e a entrega do produto ou
serviço.
Estes aspectos envolvendo o QoE não devem ser tratados isoladamente, pois a
inconformidade de uma área pode ser balanceada com a superação de outras, como exemplo a
atuação de um suporte pode vir a contrabalancear uma pobre imagem da marca ou ao menos
em parte, amenizar, trazendo do ponto de vista do cliente, uma interação com o serviço de
qualidade positiva (THE OPEN GROUP, 2004, p.106).
Determinando este QoE, a organização é capaz de balancear os níveis de qualidade de serviço
contra os preços e as expectativas dos clientes, medida pelo uso de Quality-of-Service (QoS)
tecnicamente e em termos de satisfação do cliente. A figura 11, a seguir, descreve a
participação do SLA no QoE.
Figura 11: Participação do SLA no QoE.
Fonte: THE OPEN GROUP (2004, p.107).
Myerson (2004, p.1) defende que “o SLA oferece aos provedores de serviço uma maneira de
se distinguirem entre seus competidores no volátil e competitivo mercado atual”, trazendo
diversas ofertas para seus clientes ou chegando a personalizar seus produtos conforme a
necessidade dos mesmos.
2.3.3 Evolução do SLA
Segundo Myerson (2004, p.1), na década de 60, os SLAs eram procedimentos de operação
geral para se alcançar níveis de serviços definidos e a resposta para problemas no qual uma
certa organização estaria de acordo na compra ou aluguel de tempo de máquina em um
mainframe. Conforme os computadores foram entrando no mundo dos desktops e redes, a
noção de sistemas distribuídos foi concebida.
Durante a evolução da computação de mainframe para a computação distribuída, a
dependência dos sistemas de rede e da Internet foi aumentando e os efeitos dos atrasos na
rede foram influenciando as aplicações das companhias. Ao mesmo tempo, as exigências por
maior disponibilidade e tempo de resposta foram aumentando para garantir a contínua
operação dos negócios, e, em muitos casos, confiados a provedores de serviços externos para
proverem aplicações, acesso a Internet, rede, entre outros serviços. Como conseqüência, os
SLAs tiveram que sofrer aprimoramentos e aumentar sua complexidade para ampliar seu
escopo.
Com a maior participação de área de TI no papel estratégico das empresas, contribuindo para
o produto final, os gerentes executivos passaram a demandar por maior comprometimento da
TI e melhores níveis da entrega de serviços, forçando o departamento de TI e provedores de
serviço a medirem e gerenciarem seus QoS que estavam sendo entregues e consumidos (IBM,
2002a, p.1).
2.3.4
Regras e Objetivos do Acordo de Nível de Serviço
De acordo com o International Federation of Accountants (apud GREMBERGEN, HAES e
AMELINCKX, 2003) “o objetivo de um SLA é estabelecer metas mensuráveis de
desempenho a fim de se ter um entendimento comum da natureza e do nível de serviço
desejado”.
Com o atendimento dos níveis de serviços desejados, os SLAs aprimoram a Qualidade de
Experiência do serviço ou produto para os clientes, sejam eles internos ou externos à
organização, pois estes poderão ser considerados bons ou ruins apenas se este estiverem
claramente descritos.
Implementar um SLA que atenda tanto ao provedor quanto ao cliente é uma tarefa difícil,
segundo Grembergen, Haes e Amelinckx (2003, p.1):
a busca do acordo de soma-zero, ou seja, obtenção de serviços com alto nível
de qualidade a um custo mínimo (por parte do usuário) e concebidos com um
mínimo de esforço e margem de lucro máximo (por parte do fornecedor), é
crucial e ao mesmo tempo uma tarefa difícil para um SLA efetivo.
Para o provedor de serviço minimizar os riscos de não atender aos seus acordos, três
propostas de aproximação são apresentados no ítem 2.3.7 para se disponibilizar SLAs aos
clientes.
Segundo Lee e Ben-Natan (2002, p.5), um SLA deve ser capaz de:
•
Definir papéis;
•
Gerenciar expectativas;
•
Controlar implementação e execução;
•
Prover verificação;
•
Permitir a comunicação;
•
Assegurar retorno de investimento.
2.3.4.1 Definir Papéis
Um SLA não deve possuir ambigüidade, evitando mal-entendimentos e fornecendo uma visão
clara das prioridades do serviço e de sua disponibilidade. É importante o entendimento dos
respectivos papéis e responsabilidades definidos no acordo. Estes devem ser entendidos e
serem possíveis de serem identificados (quem é responsável também no caso de
intermediários), pois um provedor de serviço de um determinado SLA pode assumir o papel
de um consumidor em outro SLA e vice-versa.
2.3.4.2 Gerenciar Expectativas
Em geral, elaborar um SLA contratual é definir as expectativas do consumidor de acordo com
a entrega do serviço. Uma vez definidos, os termos e as condições no contrato SLA passam a
ser as qualidades do produto em relação ao consumidor. Estas qualidades garantidas permitem
ao consumidor planejar e operar seus negócios com uma razoável confiança na
disponibilidade e desempenho do serviço ou produto contratado.
Opções múltiplas de SLA (platinum, gold, silver, bronze e assim por diante) para um serviço
ou produto dão ao consumidor a oportunidade de equilibrar as prioridades competitivas
dentro de sua empresa e entender as relações de suas necessidades com a de outros. Essas
opções permitem ao consumidor alocar recursos financeiros apropriadamente, escolhendo
níveis mais altos de serviço, a adição de um custo para suas funções de missão crítica e
decidir por opções mais baratas e simples para o resto.
Figura 12: Níveis de Desempenho de Acordos de Nível de Serviço.
Fonte: Lee e Ben-Natan (2002, p.9).
Talvez a maior vantagem de um SLA esteja na capacidade de se definir expectativas e
requisitos para os processos que permitirão o sucesso do negócio, de forma que possa sofrer
alterações à medida que sua importância necessitar de maior atenção, justificando
investimentos e possibilitando à gerência controlar custos na área de TI.
2.3.4.3 Controlar Implementação e Execução
O SLA é um documento de referência para gerenciar a execução e garantir a entrega do
serviço ou produto e sua contínua entrega conforme suas especificações.
Consumidores exigirão a garantia da entrega do serviço pelo uso do SLA, nele as suas
expectativas estão claramente definidas sobre toda a duração da implementação e execução
do contrato, assim o provedor de serviços deve seguir o SLA e entregar o serviço nas devidas
expectativas.
Para o provedor de serviço, entregar o serviço contratado significa garantir que recursos
suficientes estarão disponíveis ao consumidor em conformidade ao que foi descrito ou
superando o compromisso. O provedor deve ter o entendimento sobre seus compromissos e
usar de artifícios para suportar suas responsabilidades. Com isto, o provedor pode se utilizar
de QoS na entrega do serviço e prover monitoria e relatórios que comprovem o atendimento
das cláusulas.
Lee e Ben-Natan (2002, p.10) defendem que apesar dos provedores de serviço já terem
alcançado mecanismos para melhorar as detecções de falhas, confiabilidade da rede, e reduzir
as quedas que afetam o serviço aumentando a redundância e minimizando os pontos de falha,
sempre irá existir uma falha crítica e até catastrófica que requererá imediata resposta de alta
prioridade. Junto com clássicas prioridades de serviço, o SLA apresenta uma nova variável na
fórmula de priorização, o impacto financeiro.
O uso de SLA força aos provedores priorizarem o trabalho para focar o risco de danos
financeiros, criando classes de SLA que irão, dependendo do risco financeiro, atender
situações de emergência de forma diferenciada. No caso, por exemplo, uma instituição
financeira poderá contratar um SLA que prevê um atendimento extremamente ágil, pelo risco
financeiro imposto pela inoperabilidade de um serviço, enquanto outro consumidor pode, no
mesmo serviço, contratar um SLA mais simples pelo fato do impacto financeiro da
indisponibilidade do serviço ser menor, como exemplificado no quadro 1.
Classes de SLA
Platinum
Gold
Silver
Dispositivos
Roteador com
redundância
Roteador de Backup
Nenhum dispositivo
redundante
WAN
Link T1 com
Redundância
Conexão T1 com Frame Relay de
Sem Redundância
Backup
Requerimentos
de Banda
Link T1 redundante
com balanceamento
de carga
Frame Relay de backup para
aplicações críticas; Frame Relay
com 64K de CIR
T1
Desempenho
Round Trip de
100ms ou menos
Round Trip de 100ms ou menos
com 99.9%
Round Trip de 100ms
ou menos com 99%
Requerimento de
99.99%
Disponibilidade
99.95%
99.9%
Prioridade do
Help Desk
quando fora do
ar
Prioridade 3 - Quando
Prioridade 2 - Quando Serviços de
conectividade fora do
Impacto fora do ar
ar
Prioridade 1 quando serviços
críticos fora do ar
Quadro 1: Soluções de SLA.
Fonte: Service Level Management (2002, p.27).
Assim, os provedores podem oferecer múltiplos contratos SLA com diferenciações para
alcançar diferentes exigências e orçamentos se não optarem pela personalização do contrato
frente às necessidades do cliente.
2.3.4.4 Prover Verificação
A verificação ou prova do atendimento dos requisitos do QoS é um componente crítico da
maioria dos SLAs como mostra a figura 13. Enquanto o SLA for executado, o provedor de
serviço irá contabilizar a desempenho de maneira a atender ao acordo e passar aos seus
clientes esta segurança através de relatórios comprobatórios.
Tornar o atendimento do QoS e SLA visíveis é importante para o consumidor e para o
provedor de serviço. Na visão do consumidor, o consumidor deve ser capaz de averiguar e
garantir que o serviço contratado está sendo entregue em atendimento ao estipulado no
acordo, o que se torna fundamental quando valores altos de contratos estão em jogo. Ao
mesmo tempo que a verificação está disponibilizando estas informações ao consumidor, é
transmitida uma maior sensação de segurança ao consumidor por permitir a pró-atividade do
provedor de agir em situações de contingência, contribuindo para a satisfação relativa ao
QoE.
Na visão do provedor, uma verificação pode oferecer informações valiosas sobre a eficiência
de sua rede de serviços ou suporte à organização pelo SLA. Com estas informações, o
provedor pode buscar a otimização dos fatores que envolvem o serviço, alcançando maior
pró-atividade, melhor uso de recursos e disponibilizando atenção aos seus clientes (LEE e
BEN-NATAN, 2002, p.11-13).
Figura 13 – Parâmetros de QoS.
Fonte: LEE, KIM e HONG (2003, p.3).
Existem produtos no mercado capazes de monitorar o desempenho de diversos dispositivos e
apresentar relatórios sobre o seu uso. Há também a possibilidade de se programar alarmes
cujo acionamento é dado quando algum requisito de desempenho não está sendo atendido.
2.3.4.5 Permitir a comunicação
Com um SLA, a empresa é capaz de aprimorar a comunicação entre o operacional,
administrativo, financeiro e até jurídico da empresa. O SLA define papéis e regras que as
partes devem cumprir. Quanto mais claros forem estes papéis e regras, mais clara será a
comunicação entre as partes.
O SLA também serve como um framework para o provedor de serviço e consumidor
apresentarem suas necessidades e expectativas, esclarecendo parâmetros que facilitam o
entendimento das partes, visto que um SLA apresenta um entendimento único em relação a
todos os aspectos do serviço.
Como exemplo, citamos o caso de um cliente, que pode identificar a necessidade e solicitar
um nível de serviço maior mediante o presente SLA, e expressa este sentimento pelas
métricas usadas no contrato; ambos os lados possuem a mesma linguagem para se referirem
ao serviço contratado e podem vir a redefinir as cláusulas mediante novas expectativas.
2.3.4.6 Assegurar o retorno de investimento
O consumidor se utiliza do SLA também para proteger a operação de seu negócio, vindo a
poder pagar mais para poder usufruir de maior conforto e segurança de seu negócio. Assim, a
habilidade de se calcular o retorno de investimento (ROI - return of investment) está se
tornando a razão chave de um SLA (LEE e BEN-NATAN, 2002, p.14).
O cálculo do ROI é considerado o aspecto financeiro que verifica o correto nível de QoS para
o negócio. Ao contrário da verificação do atendimento de um QoS, que é centrado no dia-adia do serviço, a verificação do ROI é feita periodicamente e é medido contra o impacto da
desempenho do QoS sobre os negócios da empresa, tentando responder qual o nível certo de
serviço da TI para poder suportar os objetivos da empresa, assim como quanto deve ser
investido nesta área, justificando o custo pelo benefício (COBIT, 2000, p.10).
A razão de se utilizar um SLA usualmente está ligado ao custo associado ao mesmo, e
impacta em qual nível de QoS deverá ser contratado. Cabe aos analistas do SLA proverem
justificativas que impulsionem o consumidor a contratarem certo nível de QoS. O consumidor
pode decidir que o nível atual de serviço é apropriado, superestimado, insuficiente
(necessitando de um upgrade no nível de serviço), ou até mesmo inaceitável.
2.3.5
Componentes de um SLA
A exata forma de um SLA dependerá das duas entidades que entrarão no contrato ou acordo.
É importante considerar os fatores que envolvem o acordo, tais como a legislação e todas as
regulamentações relevantes na atuação do contrato (THE OPEN GROUP, 2004, p. 35).
A linguagem e terminologia devem ser adequadas ao público-alvo, um glossário talvez se faça
necessário para explicar termos comuns, e, dependendo da linguagem empregada, o impacto
sentido no QoE pode ser negativo.
O formato do SLA pode variar de acordo com o grupo endereçado ou conforme as
necessidades da organização. O exemplo a seguir tenta ser genérico, baseando-se nas práticas
do mercado e literaturas levantadas.
•
Introdução - O SLA deve possuir um resumo dos motivos pelos quais o contrato estará
sendo estabelecido e especificar as partes envolvidas.
•
Requerimentos do Consumidor - Apresentar os requerimentos apresentados pelo
consumidor para o uso do serviço, deixando formalizado o que o serviço deve atender.
•
Resumo do serviço - Descrever o serviço incluindo a localização física e lógica das
interfaces entre as partes, quem possui qual parte desta interface e qualquer
informação que descreva o serviço.
•
Termo - Descrever o período de vigência do contrato.
•
Responsabilidades - Conter os detalhes sobre as responsabilidades das partes,
detalhando as expectativas do provedor e do consumidor.
•
Detalhes do serviço - Descrever a parametrização do serviço em termos de Indicadores
Chave de Desempenho, indicando o nível de aceitação e não conformidade do
desempenho.
•
Exceções - Exceções irão ocorrer e devem estar documentadas no SLA. Tempos de
downtime para manutenção ou rotinas de manutenção podem ser necessários e devem
estar descritos para evitar problemas.
•
Relatórios - Será necessário definir a periodicidade em que os parâmetros serão
coletados e medidos contra a conformidade. O método de apresentação (em papel, via
web, etc.) também pode vir a ser necessário. Desconformidades podem necessitar de
tempos diferentes (instantaneamente, a cada hora, etc.) ignorando os outros processos.
Uma amostra pode ser necessária junto ao SLA.
•
Penalidades - Os detalhes sobre as penalidades pela não conformidade devem ser
descritos.
•
Pedidos de Modificações - Esta seção descreve como uma requisição é feita ao SLA,
periodicidade e freqüência.
•
Rescisão - Especificação sobre a rescisão.
•
Leis - Seção que descreve as leis relevantes para serem consideradas no SLA.
•
Confidencialidade - Especificar a Confidencialidade das informações.
•
Garantias - Garantias cobertas pelo SLA.
•
Responsabilidade - Os direcionamentos de responsabilidades em caso de falha do SLA
devem ser apontados.
•
Assinaturas - Assinaturas de ambas as partes.
2.3.6
Definição do Serviço
Para se implementar ou monitorar qualquer serviço ou produto, é necessário o mapeamento
dos recursos que o envolvem, incluindo:
•
Hardware;
•
Software;
•
Pessoas, incluindo treinamento;
•
Licenças e Propriedade Intelectual;
•
Espaço físico;
•
Orçamento financeiro.
A dificuldade se encontra em mapear os parâmetros específicos de um serviço, convertendo
estes para parâmetros específicos de tecnologia (que são mais fáceis de serem medidos e
relatados). Para auxiliar este mapeamento, o Control Objectives for Information and related
Technology – Cobit , se utiliza de Fatores Críticos de Sucesso.
2.3.6.1 O Uso de Fatores Críticos de Sucesso na definição do serviço
O Cobit foi desenvolvido pelo IT Governance Institute como um padrão aberto para o
controle da tecnologia da informação. Construído por meio de pesquisas em cooperação com
indústrias, experts, analistas e acadêmicos do mundo todo, resulta em um framework que
responde às necessidades da gerência sobre o controle e medição da TI. O Cobit define 34
processos de TI, distribuídos em quatro domínios distintos:
•
Planejamento e Organização;
•
Aquisição e Implementação;
•
Entrega e Suporte;
•
Monitoramento.
No domínio Entrega e Suporte há uma ênfase sobre a importância de um modelo de SLA e a
necessidade de acordo nos componentes de um SLA para se gerir a Governância de TI
(COBIT, 2000, p.62). A Governância de TI mapeia todos os serviços prestados pela área para
poder assim controlar e monitorar a sua entrega. Este mapeamento é feito pelo Cobit,
apresentando o uso de Fatores Críticos de Sucesso, Indicadores de Desempenho e Indicadores
de Metas. Uma vez levantados, serão usados no auxílio da formalização dos componentes
contratuais do acordo.
2.3.6.2 Fatores Críticos de Sucesso
Para se prover gerência sobre um serviço é preciso, antes, poder conhecê-lo e medi-lo. Os
fatores críticos de sucesso (FCS) são usados no SLA para mapear estes serviços indicando
elementos-chave para se construir os níveis de serviço (COBIT, 2000, p.14). Para qualificar
um processo como um FCS, este deve ser capaz de melhorar a qualidade do SLA em
benefício do serviço. Os FCS também devem ser mensuráveis para a organização poder
determinar o quanto o fator contribuiu para o sucesso do procedimento, processo ou serviço
(CISCO, 2002, p.1).
FCS é assim descrito pelo Cobit (2000, p.8):
a definição dos eventos ou as ações de gerência mais importantes para se
alcançar o controle sobre os processos de TI. Estes devem ser guias de
implementação orientada à gerência e identificar as ações mais importantes a
se fazer, estrategicamente, tecnicamente, organizacionalmente e processual.
Os FCS lidam com as capacidades e habilidades e devem ser curtos, focados e orientados em
ações, alavancando os recursos, que são de importância primária no processo em
consideração (COBIT, 2000, p.14).
Como guia, o Cobit propõe o uso do padrão de Control Model (figura 14), seguindo o
princípio de que, ao ajustar a temperatura de uma sala (padrão) no condicionador de ar
(processo), este irá constantemente checar (comparar) a temperatura ambiente do quarto
(informação de controle) e irá sinalizar (agir/ação) ao sistema de aquecimento para prover
maior calor. Este modelo e seu princípio identificam um número de Fatores Críticos de
Sucesso que, usualmente, são aplicados a todos os processos, já que lidam com o que é o
padrão, quem ajusta, quem controla ou precisa agir etc. (COBIT, 2000, p.14).
Figura 14: Modelo de Controle da Informação.
Fonte: Adaptado de Cobit (2004, p.14).
Os FCS são encarados como o que é importante para um serviço ser entregue com sucesso, ou
seja, como exemplo em um serviço de voz sobre IP (VoIP). Um fator crítico de sucesso é que
o sinal seja compatível ao de um serviço de telefonia convencional. Esse FCS traz a
necessidade de levantarmos diversos requisitos técnicos que possibilitem o alcance desse
critério, identificados como Indicadores Chave de Desempenho.
2.3.6.3 Indicadores Chave de Desempenho
Os Indicadores Chave de Desempenho (ICD) são definidos pelo Cobit (2000, p.20) como: “o
que define meios para definir o quão bem um processo de TI está realizando no auxilio ao
objetivo a ser alcançado; são os principais indicadores que dizem se um objetivo vai ser
alcançado ou não”. Estes indicadores provêm um mecanismo, pelo qual uma organização
mede os FCS, e quando monitorados, podem identificar oportunidades para melhoria do
processo, influenciando diretamente o resultado final e o objetivo do processo.
Como exemplo, novamente, o serviço de voz VoIP: um dos FCS levantados foi a comparação
com o sinal da telefonia convencional. Para que esse objetivo seja alcançado, alguns
Indicadores Chave de Desempenho são levantados como a taxa de compressão do áudio e
atrasos na entrega dos pacotes de voz, expostos por métricas que quantificam estes
parâmetros a fim de mostrar o quão bem está sendo realizado para garantir o FCS.
Tipicamente, estes fatores são revisados em uma freqüência para garantir que os níveis de
serviço definidos no SLA estejam funcionando bem. Diversas ferramentas podem ser usadas
para realizar a extração dessas métricas e gerar relatórios que quantificam a disponibilidade,
desempenho, tempo de resposta, entre outros.
Esses indicadores direcionam indícios do sucesso antes do fato, ao contrário dos Indicadores
Chaves de Metas, que são somente medidos depois do fato. Comparados, o Indicador Chave
de Metas apresenta “o quê” está sendo atendido enquanto o ICD indica “o como” está sendo
feito para o atendimento da Meta ou Fator Crítico de Sucesso.
2.3.6.4 Indicadores Chaves de Metas
Estes são fatores que, segundo o Cobit (2000), definem medidas para serem reportadas à
gerência, obtidas depois do fato, sempre que o processo de TI alcance seu requerimento,
usualmente expresso em termos de critério de informação, como disponibilidade do serviço,
confirmações, relação de custo-eficiência e riscos.
Em comparação aos ICD, os Indicadores Chaves de Meta (ICM) medem o “quão bem” o
processo está executando, ou seja, o quão bem o capacitador (ICD) está executando de modo
a indicar que o objetivo do negócio será atendido. O ICM pode ser um ICD que está
relativamente ligado com o objetivo do negócio.
O Cobit (2000) expressa o Indicador Chave de Meta em termos de critério de informação que
o negócio necessita em ordem para alcançar seu objetivo. Geralmente, é expresso em termos
de:
•
Disponibilidade de um sistema e serviço;
•
Ausência de riscos de segurança e integridade;
•
Relação custo/benefício de uma operação ou processo;
•
Confirmação de confiabilidade, eficiência e conformidade.
Seguindo o exemplo do serviço de VoIP: o FCS é a entrega de um sinal de voz equivalente ao
convencional, impactando no controle dos ICD, como a taxa de compressão de áudio e atrasos
na entrega de pacotes de VoIP. Um ICM seria expresso como a porcentagem de ligações
realizadas com a qualidade de voz definida como de qualidade equivalente ao convencional,
número de ligações perdidas etc.
Cada organização deve ser capaz de identificar o grau de importância de cada critério de
informação, segundo seu ambiente e negócio, podendo mudar de grau dependendo do
objetivo que o processo se aplica.
2.3.6.5 Indicadores Chaves de Qualidade
Os Indicadores Chaves de Qualidade (ICQ) facilitam a extração dos ICD por serem genéricos,
podendo ser aplicados a serviços particulares, revelando um ou mais ICD. Estes indicadores
não são apresentados pelo Cobit por serem um simples facilitador para a obtenção de outros
indicadores, mas o The Open Group (2004) o utiliza sem mencionar os FCS, pois foca mais
no atendimento aos requisitos de desempenho e não no cumprimento de objetivos como o
Cobit.
Os ICQ podem possuir diferentes significados dependendo do serviço [e negócio], e são
genericamente apresentados e definidos pelo The Open Group (2004, p. 43) como:
•
Disponibilidade – A disponibilidade do serviço para uso quando for requerido seu uso;
•
Qualidade de Vídeo/Voz – A qualidade no contexto da capacidade de se poder
transmitir e interpretar a forma visual e de áudio;
•
Tempo de Resposta – O quão rápido o serviço responde a um estímulo interno ou
externo;
•
Round Trip Delay – O tempo que leva entre se fazer uma requisição e obter a resposta;
•
Delay – O atraso do sistema, podendo assumir atrasos de uma direção a outra;
•
Jitter - Variação dos atrasos em relação ao tempo;
•
Locking – Se a informação está trancada para leitura ou escrita a fim de garantir a
integridade dos dados;
•
Transaction Rate – Taxa em que o sistema ou serviço pode atender as requisições;
•
Goodput (carried) – A quantidade de informações válidas que são processadas;
•
Throughtput (Offered) – A quantidade de informação oferecida ao sistema;
•
Idle Time – O total de tempo que o sistema ou serviço está inativo;
•
Authorization – O sistema está disponível somente para recursos autorizados;
•
Confidencialidade – Informação só pode ser vista por aqueles que deveriam poder ver;
•
Integridade – Informação está disponível como requisitada e sem sofrer mudanças em
comparação à informação original. Perda de integridade também inclui a perda da
informação;
•
Non-repudiation – Informação é realmente da fonte apresentada e autorizada;
•
Espaço em Disco – Espaço em disco está disponível para as requisições pela duração
do serviço;
•
Help Desk – Um serviço de suporte está disponível para atendimento;
•
Treinamento – Treinamento é o bastante para a execução da tarefa;
•
Interoperabilidade – O serviço ou produto irá trabalhar com todos os sistemas e
serviços necessários;
•
Pick-up Time – Quanto tempo é necessário para um humano responder a requisição;
•
Time to Close – Quanto tempo é necessário para se fechar um suporte ou requisição de
informação;
•
Hold Time – Quanto tempo o suporte ou pedido de informação é segurado em uma fila
sem ser processado;
•
Connect Time – Quanto tempo demora para o serviço ser iniciado;
•
Graceful Degradation – Quando um sistema falha ou é sobrecarregado, ele falha de
maneira controlada e de forma gradual, atendendo aos pedidos de maior prioridade
enquanto for possível;
•
Revocation – Término ou recall da autorização para o uso do serviço ou produto.
Cada um destes indicadores é genérico e sua exata interpretação dependerá do contexto do
serviço na organização. Como exemplo (Quadro 2), um pequeno mapeamento de um
parâmetro de um serviço de VoIP foi realizado como demonstração:
Indicadores
Parâmetros
1- Fator Crítico de Sucesso
Sinal de voz comparado com o da telefonia convencional.
2- Indicador Chave de
Qualidade
Qualidade de voz
Tempo de Resposta
Jitter
3- Indicador Chave de
Desempenho
Taxa de compressão do áudio
sample rate do CODEC do áudio
Tempo de Resposta do pacote VoIP em milisegundos
Tempo de Jitter dos pacotes VoIP
4- Indicador de Meta
Número de ligações com voz sem qualidade
Número de ligações perdidas
Quadro 2: Exemplo de Indicadores para o serviço de VoIP.
Fonte: Baseado no THE OPEN GROUP (2004, p.104).
Este trabalho se utilizou dos Fatores Críticos de Sucesso, Indicadores de Desempenho e
Indicadores de Metas para mapear os serviços. Então, se utilizará do conceito de Indicador
Chave de Qualidade somente quando existir dificuldade de se extrair os Indicadores Chave de
Desempenho, não formalizando este primeiro indicador nos Acordos de Nível de Serviço.
2.3.6.6 Mapeamento da Qualidade
A partir da extração dos indicadores-chave de desempenho e atendimento dos fatores críticos
de sucesso, temos a medida do ICM. Dessa forma, é possível relacionar a qualidade do
serviço com a qualidade de experiência (QoE) percebida. Enquanto o SLA se refere às
definições, quantificações e relato sobre o serviço, o QoE está relacionado ao SLA, de
maneira a indicar que se o SLA está sendo atendido, mas a percepção do serviço pelo cliente
é pobre, os parâmetros limitados no SLA devem ser revistos. No caso do serviço de VoIP, o
número de ligações perdidas pode estar abaixo do que foi estipulado no SLA, mas mesmo
assim a percepção do usuário é pobre sobre a qualidade total do serviço, tornando necessária a
revisão da proposta.
O desafio dos SLAs é traduzir estas expectativas (métricas do QoE) em métricas que possam
ser definidas no SLA. Isso quer dizer que um SLA, por melhor que esteja sendo atendido,
pode vir a não atender as expectativas sobre a qualidade total do serviço. Assim, os
provedores de serviço podem optar por usar uma das três aproximações na gerência de SLA
para melhor garantir a QoE.
2.3.7 Três Aproximações para a gerência de SLA
É de interesse do provedor garantir que o serviço oferecido está atendendo ao que foi
contratado. Ao mesmo tempo, os clientes também querem a segurança do cumprimento de
seus requerimentos. O provedor, independentemente do tipo de serviço oferecido, procura
atender aos acordos de nível de serviço da melhor forma possível.
Comumente, são usadas três aproximações para se gerenciar um SLA. A primeira
aproximação toma o modelo de uma empresa de seguros, monitorando e suportando o SLA. A
segunda aproximação usa técnicas de configuração e provisão para suportar o SLA, enquanto
a terceira aproximação toma uma postura mais dinâmica e adaptativa (VERMA,1999, p. 6).
2.3.7.1 Aproximação de Seguradora
Na Aproximação de Seguradora, o provedor faz o seu melhor para satisfazer o nível de
desempenho, disponibilidade e outros objetivos especificados no SLA, de acordo com seus
procedimentos de operação padrão. Genericamente, o mesmo nível de serviço é oferecido
para todos os clientes.
O provedor de serviço mantém a monitoração em seus serviços para observar o quão bem está
atendendo as especificações contratuais, que são especificadas de maneira a não ocorrerem
violações no decorrer do contrato. Quando os limites são violados, o provedor se encarrega de
pagar as penalidades especificadas no contrato para o consumidor. O provedor sempre
computa os riscos financeiros associados às violações do SLA e a partir desses cálculos
assume se irá aceitar, ou não, o firmamento do contrato e provisão do serviço.
2.3.7.2 Aproximação de Provisão
Na aproximação de Provisão, o provedor tipicamente assina contratos com níveis
personalizados de serviço para cada cliente. O provedor, assim, teria que alocar os recursos
necessários em seu ambiente diferentemente para cada cliente. A determinação das
configurações necessárias para atender ao cliente é o passo crucial, depois de realizado o
restante, é tratado pelo provedor como a aproximação de segurador irá monitorar e pagar
eventuais violações de contrato.
Nesta aproximação, o QoS se faz importante, pois é pelo seu uso que a provisão de recursos
será feita.
2.3.7.3 Aproximação Adaptativa
Na terceira aproximação para o atendimento do SLA, o provedor acrescenta um novo aspecto
da configuração adaptativa à aproximação de provisão. Nesta aproximação, o provedor de
serviço dinamicamente modifica a configuração de seu sistema para suportar o cliente quando
a monitoria dos objetivos alertar a aproximação da violação de uma cláusula. Esta
aproximação reduz a probabilidade da violação das especificações do serviço, mas não a
elimina por completo.
Esta aproximação requer o uso intensivo de QoS e da monitoria pró-ativa dos recursos,
gerando alarmes que possam habilitar o provedor a agir na provisão de maiores recursos antes
que estes se esgotem.
2.4 ESTUDO DE CASO – REDE DA POLÍCIA MILITAR DO ESTADO DE SANTA
CATARINA
2.4.1 Introdução
Nos ítens anteriores, foram apresentados os conceitos inerentes à proposta deste TCC. Para
alcançar os objetivos pré-definidos, escolheu-se como objeto de estudo de caso a rede de um
órgão governamental do Estado de Santa Catarina, baseada na tecnologia Frame-Relay.
Para realizar tal estudo, inicialmente descreve-se o ambiente da rede e as características da
tecnologia Frame-Relay. Entretanto, saliente-se que o serviço oferecido a esta instituição não
é regido por um SLA. A seguir, apresenta-se uma proposta de SLA adotada para tal serviço, e
por fim, realiza-se a monitoria dos aspectos técnicos do SLA para averiguar a conformidade
dos quesitos e servir de referência para outros indicadores e sua descoberta.
Como estudo de caso para o desenvolvimento de um protótipo de um Acordo de Nível de
Serviço foi selecionada a contratação de serviços de redes Frame-Relay da Polícia Militar do
Estado de Santa Catarina. Esta organização contrata tais serviços para conectar os diversos
Batalhões e postos espalhados no Estado de Santa Catarina com o intuito de agilizar a troca
de informação.
Este serviço foi escolhido para o presente estudo por apresentar o seu atrativo custo-benefício
e disseminação, tomado, muitas vezes, por uma tecnologia barata de redes de computadores e
também por ser um exemplo de prestação de serviço na área de TI, que pode ser contratado
largamente à medida em que empresas migrem suas antigas estruturas de redes PPP 12 para a
Frame-Relay.
12
PPP - Point To Point Protocol, protocolo usado para conectar um ponto da rede a outro através de
uma linha serial.
Para entender o porquê desta tecnologia ser barata, é necessário entender como ela funciona
para melhor aproveitar o seu potencial e melhor firmar a estratégia em sua aquisição. Assim,
suas características serão apresentadas juntamente com a apresentação do cenário.
2.4.2 Cenário da Polícia Militar do Estado de Santa Catarina
A Polícia Militar do Estado de Santa Catarina – PMSC é um órgão de segurança pública e
utiliza a rede Frame-Relay para trafegar informações referentes ao COPOM, e-mails, e
serviços internos de Intranet, entre outros. Das atuais 108 redes, 60 destas se utilizam da
tecnologia Frame-Relay, ligando cada localidade ao Centro de Comunicação e Informática –
CCI, na Avenida Rio Branco em Florianópolis.
O CCI tem como objetivo dar todo o suporte à troca de informação de toda a corporação, de
maneira ágil, fornecendo desde a manutenção a equipamentos de informática como
disponibilizando serviços de rede e Internet. Grande parte desta troca de informação é feita
através da rede privada Frame-Relay, denominada FR.
O Fator Crítico de Sucesso deste serviço para a organização é a troca ágil de informações,
necessitando que estas redes possam transitar um grande fluxo de informações, estando
disponível quando necessário e de forma segura. Para atender tais necessidades, a equipe da
PMSC contratou um serviço de redes particulares em FR e busca o contínuo aprimoramento
de seus serviços. Este trabalho, então, teve como foco auxiliar esta organização a melhor
gerenciar suas redes e apresentar um protótipo de Acordo de Nível de Serviço para servir de
referência de qualidade e parâmetros para a monitoria de seu contínuo atendimento.
Uma vez estabelecidas as necessidades junto aos fatores e objetivos do serviço, foi iniciado o
entendimento de seus aspectos técnicos, como recomendado pela CISCO, se utilizando da
análise técnica e brainstorm dos aspectos técnicos referentes à tecnologia FR e serviço de
rede (CISCO, 2002, p.3).
2.4.3 Circuitos Frame-Relay
O Frame-Relay é uma tecnologia de comutação de pacotes de alto desempenho que opera nas
camadas físicas e de dados do modelo referencial OSI, que permite as estações
dinamicamente compartilhar as mídias de rede e a banda disponível, gerando um menor custo
e dispêndio de recursos de telecomunicações pelo compartilhamento dos custos de
implantação, manutenção e suporte entre todos os participantes desta nuvem (CISCO, 2004b,
p.1).
Figura 15: Consórcio da Nuvem entre diversas redes.
Fonte: Baseado em Cisco (2004b, p.1).
A figura 15 demonstra o exemplo de diferentes redes espalhadas no Estado de Santa Catarina
que se utilizam da mesma Nuvem Frame-Relay, compartilhando custos e melhor
aproveitando a estrutura espalhada pelo Estado, ao invés de cada uma destas redes contratar
dezenas de circuitos que percorressem todo o Estado e, por vezes, sem utilizar todo o
potencial do meio físico, que é de seu uso exclusivo.
Outra razão para o menor custo e atrativo para sua adoção é o fato de não mais ser necessário
contratar circuitos em linha privada – LP que percorram desde a origem até seu destino, como
na tecnologia PPP, utilizada anteriormente. Basta contratar em ambas as localidades um
circuito LP ou até mesmo uma linha ADSL ou discada, que leve ao Switch Frame-Relay (Fig.
16) mais próximo, que a conecte na nuvem. A partir desta nuvem, é possível começar a
compartilhar os recursos e ratear os gastos entre todos os participantes do consórcio.
Figura 16: Rede em uma Nuvem FR.
Fonte: Adaptado de Cisco (2004b, p.4).
O compartilhamento realizado na nuvem é possível pelo fato da uma rede Frame-Relay ser
estaticamente multiplexada, ou seja, por esta rede permitir diversas conecções lógicas
coexistirem em um mesmo meio físico. Mas apesar de diversas conecções poderem estar
usando o mesmo meio físico, somente um quadro de dados pode trafegar por vez. Assim, se
faz necessário que cada quadro carregue um identificador lógico, amarrando-o a sua conecção
lógica (Fig. 17) e permitindo a identificação da rede a qual pertence. Este identificador
anexado ao quadro é chamado de DLCI (termo técnico para Data Link Connection Identifier)
ou Identificador de Conexão do Link de Dado.
Figura 17: Um único circuito FR pode possuir diversos DLCI associados
Fonte: Adaptado de Cisco (2004b, p.5)
Assim, apesar de se utilizar do mesmo meio físico, diversos circuitos podem existir de
maneira virtual, sendo divididos logicamente através do uso do DLCI.
Como a tecnologia Frame-Relay permite que diversas redes coexistam no mesmo meio
físico, o compartilhamento da capacidade de vazão de dados deste meio acontecerá. Neste
compartilhamento, a alocação dinâmica da banda é feita através de sinalizações semelhantes
ao QoS, dependendo das necessidades atuais de cada rede e atributos contratados. Isso evita
que uma rede possa a vir a alocar todos os recursos para si e causar o atraso ou negação de
pedidos de pacotes de outras redes. Para isso, ao se contratar um serviço de Frame-Relay, o
consumidor deve optar pela velocidade total de banda de seu circuito, o CIR, apresentando o
quanto da capacidade de vazão de banda será reservado quando todos concorrerem pelo
mesmo meio.
2.4.3.1 CIR
O CIR é o acrônimo de Committed Information Rate, ou Proporção Garantida de Informação.
A tecnologia Frame-Relay é um protocolo HDLC, sincronizado a um clock e forçando que a
transmissão dos quadros seja contínua. Ao transmitir 1000 bytes, não seria possível enviar
500 bytes e aguardar para enviar os outros 500 bytes. É preciso que tudo seja enviado de uma
única só vez em um grande pedaço, por rajadas denominadas Bursts. O termo “Bursting
acima do CIR”, é usado quando a situação força que sejam enviadas mais informações do que
o CIR garantia, pela incapacidade de diminuir a velocidade do clock ou segmentar a
informação em pedaços menores, uma vez que a transmissão foi iniciada.
Assim, o CIR é, na verdade, a pior vazão de dado que a rede Frame-Relay procura garantir,
mas que a rede pode vir a ultrapassá-la sempre que um Burst acontecer ou houver recursos
disponíveis sem utilização. Afinal, algumas redes que estão sendo multiplexadas no meio
podem estar utilizando somente fração do que lhe é disponibilizado, deixando disponível a
outra parte para a compartilha.
Figura 18: Estrutura da Garantia de Banda
Fonte: Adaptado de Cisco (2004a, p.19)
A Figura 18 exemplifica três redes multiplexadas concorrendo com o total de banda
disponível, mas sempre (no caso da rede superior e da inferior) transmitindo no mínimo o que
o CIR garante, enquanto a rede no centro se comporta se utilizando de menor recurso, por
possuir um CIR ainda menor.
É importante para o consumidor saber que, apesar de poder contratar circuitos de alta
velocidade, a velocidade especificada pelo CIR é realmente garantida e mesmo nos horários
de maior movimento da nuvem (que gera congestionamento), será praticada. Este CIR pode
ser expresso de duas formas: mostrando a real velocidade do CIR, no caso um circuito 128/64
teria 128kbps de velocidade total sendo 64kbps garantida pelo CIR, ou então apresentando
um CIR de porcentagem pelo total de banda contratado.
2.4.3.2 Congestionamento
O congestionamento ocorre quando há mais dados agregados à rede do que a banda pode
suportar. Analogicamente, como se uma rodovia de três faixas convergisse a somente uma.
Para se escapar de uma via congestionada seria simples desviar para outra rodovia. O
problema é quando muitos outros também tentam desviar para a mesma rodovia, e alguém
terá que diminuir a velocidade. O problema reside no fato de que o Frame-Relay não permite
que os dados diminuam a velocidade por estarem sincronizados e atrelados ao clock. Então,
para evitar a colisão, há duas alternativas. Quando a rede detecta que uma colisão está prestes
a acontecer, esta sinaliza o roteador para diminuir a transmissão. Como não há como diminuir
a velocidade, o único meio é atrasar os próximos quadros de informação e aguardar até que o
CIR seja alcançado (o mínimo garantido) ou até receber um bit que sinalize que a rede está
novamente disponível. Assim, ressalte-se novamente a importância do CIR - um CIR de 0
(zero) acarretaria na espera até que a rede esteja totalmente disponível.
Se não for possível diminuir a velocidade da transmissão pelo atraso na entrega de alguns
quadros, o protocolo Frame-Relay é forçado a começar a descartar quadros quando o excesso
é detectado, e para decidir quais quadros serão descartados, o CIR é consultado. Uma vez que
a rede atinge o CIR garantido, irá considerar todo o fluxo excedente como de alta prioridade
de descarte, atribuindo ao bit DE (discard elegibility) do quadro Frame-Relay a possibilidade
de descarte. Quando um congestionamento ocorrer, os quadros marcados serão descartados
primeiro dos que não possuem o bit DE marcado, reduzindo a probabilidade de dados críticos
serem descartados durante os períodos de congestionamento (CISCO, 2004b, p.5). Uma rede
bem arquitetada irá descartar os quadros excedentes e garantir sempre que as redes utilizem o
que lhes fora garantido pelo CIR.
2.4.3.3 Mapeamento do Serviço Frame-Relay
Depois que a tecnologia e seus aspectos técnicos foram entendidos, iniciou-se o mapeamento
do serviço de Frame-Relay da Polícia Militar do Estado de Santa Catarina. Para isso, foi
consultada a documentação já existente no CCI e também foram entrevistados os responsáveis
pela manutenção das redes, trazendo informações como velocidades contratadas, CIRs, tempo
de atendimento, horários de funcionamento, entre outros dados. O segundo passo foi entender
as expectativas da organização e transfomá-las em indicadores de qualidade e desempenho,
para poder formalizar no Acordo as métricas dos indicadores que impactam no Fator Crítico
de Sucesso da organização.
O início da formalização do SLA foi dado definindo-se as expectativas da organização,
levantando indicadores de qualidade, tomando como base os indicadores apresentados nos
atributos do serviço de Intranet, Extranet e Internet Pública do The Open Group (2004, p.68)
e os parâmetros para um serviço de QoS em rede, de Lee, Kim e Hong (2003, p.4), que
direcionam ao atendimento do Fator Crítico de Sucesso de um serviço deste gênero, aderindo
a alguns indicadores selecionados entre os apresentados no ítem 2.3.6.5 – Indicadores Chaves
de Qualidade:
•
Disponibilidade;
•
Tempo de Resposta;
•
Goodput;
•
Help Desk;
•
Confidencialidade;
•
Interoperabilidade;
•
MTBF - Mean Time Between Failure;
•
MTRS - Mean Time to Restore Service.
3
PROTÓTIPO DE ACORDO DE NÍVEL DE SERVIÇO
O Acordo de Nível de Serviço foi construído a partir de levantamento de modelos de SLAs,
encontrados em algumas literaturas e guias de prática de mercado levantadas neste TCC,
seguindo as idéias apresentadas no ítem Acordo de Nível de Serviço. Os parágrafos contidos
neste acordo retratam um possível contrato, firmado entre a Polícia Militar do Estado de Santa
Catarina e um provedor de serviços em redes.
Como preocupação principal na confecção de um SLA, primeiramente foi elaborado o esboço
sobre as métricas técnicas referente ao serviço frame-relay, pois estas devem estar bem
definidas, tendo em vista que sem métricas claras, o SLA tenderá a falhar.
Neste trabalho determinou-se um protótipo de Acordo de Nível de Serviço por se tratar do
primeiro passo, dentre inúmeras iterações na confecção de um SLA, que apresente fidelidade
às características do serviço e às expectativas do cliente. O protótipo do Acordo de Nível de
Serviço por seguir uma formatação jurídica diferente do padrão deste trabalho, foi colocado
como apêndice pode ser conferido no Apêndice A.
O levantamento dos indicadores de desempenho foi definido por critérios e indicadores de
qualidade e desempenho genéricos, estipulados a partir da natureza do serviço e das
aplicações dos usuários, número de usuários e porte da rede, informações que foram extraídas
por meio de entrevista à equipe de informática da Polícia Militar do Estado de Santa Catarina
e documentação existente sobre o serviço.
Este SLA não é estático, ou seja, uma vez definido, não deve ser tomado como real descrição
das expectativas ou descrição do serviço. Na verdade, um SLA é dinâmico, e este protótipo é
o início de um ciclo de aprimoramentos, ajustando-se a cada revisão as métricas e cláusulas
estabelecidas para melhor se adequar à realidade das qualidades oferecidas e esperadas no que
se refere ao serviço, podendo ser também observada pela monitoria de seus parâmetros.
3.1 MONITORIA DOS PARÂMETROS DE QOS DO ACORDO DE NÍVEL DE
SERVIÇO
“A definição de níveis de serviço por si só são inúteis ao menos que a organização colete
métricas e prossiga com a monitoria” (CISCO, 2002, p.23).
Uma vez o Acordo firmado entre ambas as partes, a monitoria deve ser realizada a fim de
garantir o seu contínuo atendimento, além de possibilitar que ambas as partes saibam quando
os recursos oferecidos estão chegando perto de seus limites técnicos e quando passarão a não
mais atender as necessidades.
Foram monitorados neste trabalho os indicadores de desempenho da rede seguindo os
indicadores tradicionais de disponibilidade, perda de pacotes e tempo de resposta,
considerados por Maurer, Matlus e Frey (2000, p.21) as características mais importantes a
serem medidas. Estas também estão presentes dentro das apresentadas por Lee, King e Hong
(p.4) como os parâmetros de QoS para o mapeamento de métricas de rede para a monitoria de
SLA com a adição do parâmetro de utilização, pela capacidade e vazão de banda (Fig. 19).
Figura 19: Métricas de Desempenho de Rede.
Fonte: QoS Parameters to Network Performance Mapping for SLA Monitoring (2003).
A figura 19 demonstra as métricas de desempenho de rede, que, com exceção do jitter e atraso
one-way, foram monitoradas pelo sistema de monitoria de rede NAGIOS e CACTI,
transcritos neles as métricas de QoS. Com as métricas estabelecidas, ainda foi possível gerar
ações baseadas em limites atingidos, conhecidos como thresholds, configurando a ferramenta
NAGIOS, para gerar um alerta quando certos limites forem alcançados, gerando uma ação de
colorir em vermelho a rede respectiva no relatório web e enviar um e-mail para um analista de
redes para que este possa agir.
As métricas definidas e monitoradas neste trabalho foram:
Nível de Serviço
4
Link
1.55mbps
WAN
3
2
1
T1 Link
de Link
de Link
256kbps
Frame
Requerimentos
de
Banda / Goodput
Requerimento
Relay
com 128K de com 64K de com 32K de
100%
CIR
CIR
CIR
99.99%
99.9%
99.7%
99%
1%
3%
3%
5%
de
Round Trip de Round Trip de Round Trip de
Resposta / Atraso de Round Trip de 150ms
Pacotes
Relay Frame
de
Perda de Pacotes
Requerimento
Relay Frame
64kbps
de
Disponibilidade
Requerimento
128kbps
de
75ms ou menos menos
ou 300ms
ou 300ms
menos
menos
ou
Tabela 3: Níveis de Serviço e as métricas para monitoria.
Sempre que um destes parâmetros monitorados não respeitarem o especificado em contrato, o
sistema irá alertar o usuário ao colorir na tela de status uma das mensagens descritas abaixo:
- A medida da disponibilidade, através do uso da Ferramenta NAGIOS é realizada pelo uso do
comando ping 13 .Qualquer retorno diferente de OK, é tomado pela ferramenta NAGIOS como
serviço indisponível, gerando o alerta crítico em vermelho, como mostra a figura 20.
13
Ping – comando presente nos sistemas operacionais para se testar a conectividade de rede.
Figura 20: Alerta de perda de Conectividade referente a uma rede.
Fonte: NAGIOS instalado no CCI
- A Perda é medida através do uso da Ferramenta NAGIOS, se utilizando também do
comando ping, para obter a quantidade de pacotes perdidos dentro aqueles que foram
enviados em uma fração de segundo, sendo o desrespeito aos limites um alerta de impacto
warning caracterizando degradação da rede ou então crítico, se este vier a superar o limite em
250% do estipulado, como mostra a figura 21.
Figura 21: Alerta sobre a perda de 100% dos pacotes de uma rede.
Fonte: NAGIOS instalado no CCI
- O Atraso é medido pela ferramenta NAGIOS se utilizando do comando ping, obtendo a
média dos atrasos dos pacotes enviados para teste, alertando o administrador da rede que os
pacotes estão sofrendo atraso demasiado em sua entrega. Foi caracterizado este tipo de
desrespeito aos limites um alerta de impacto warning caracterizando degradação da rede ou
então crítico, se este vier a superar o limite em 250% do estipulado, como mostra a figura 22.
Figura 22: Alerta de Warning referente ao RTA.
Fonte: NAGIOS instalado no CCI
Estas mensagens também foram configuradas para alertar o consumidor por via de e-mail,
para que o analista responsável da rede possa agir o mais rapidamente, mesmo não estando
com acesso à ferramenta NAGIOS. Esta mesma ferramenta também possibilita o envio destes
alertas para o celular atravéz de ferramentas plug-in não utilizados neste trabalho.
Segue o corpo da mensagem de um alerta via e-mail.
Notification Type: PROBLEM
Service: Host Down
Host: CIRCUITO CAMBORIU
Address: 192.168.134.254
State: CRITICAL
Date/Time: Wed Oct 19 17:27:18 BRST 2005
Additional Info:
CRITICAL - 192.168.134.254: rta nan, lost 100%
A Utilização da rede é medida por outra ferramenta, chamada CACTI, que fornece um gráfico
que ilustra um histórico da demanda por vazão de dados na rede. Neste gráfico é possível se
obter a velocidade do circuito contratado (canto esquerdo superior do gráfico), as velocidades
atuais, médias e máximas praticadas no mês assim como se obter informações sobre os picos
e momentos de pouca demanda, como mostra a figura 23.
Figura 23: Gráfico de Utilização de Banda do Canal FR principal da PMSC.
Fonte: CACTI instalado no servidor de monitoria do CCI (2005).
Este gráfico é referente ao circuito principal da PMSC, com vazão de 2mbps e CIR de 50%. É
percebido a alta utilização desse circuito e grande quantidade de picos. Com a medida do
principal circuito estar sempre se utilizando do CIR (velocidade média esta igual a garantida
pelo CIR) é percebida a necessidade de se aumentar a velocidade deste link, visto que o
circuito este, é o que suporta todas as outras redes, e podendo ser ponto de gargalo para esta
rede. Antes desta comprovação a Polícia Militar do Estado de Santa Catarina já estava
estudando a aquisição de um circuito de maior velocidade, e agora reforçado pelo gráfico,
para um link tipo T1, que irá possibilitar uma melhor vazão dos dados para a nuvem Framerelay e possibilitar agregar novas redes.
Além dos alertas, a ferramenta NAGIOS também permite extrair relatórios referente a
determinado espaço de tempo, assim é possível, por exemplo, se obter um relatório mensal
sobre a situação do atendimento aos requisitos contratados e monitorados, observando se as
cláusulas do contrato foram atendidas e o usando como artifício comprobatório a cada final de
mês.
3.2 ATENDIMENTO DO SLA
Como exemplo de comprovação do atendimento ao SLA segundo os parâmetros técnicos do
QoS, foi tomado a rede de Joinville, com nível de serviço dois, segundo o cláusula segunda do
presente SLA, gerando relatórios que vêm a esclarecer a situação do mês de novembro e
indicando o sucesso, falha ou degradação referente ao nível de serviço contratado. Salienta-se
que neste trabalho apenas foram monitorados e confrontados ao SLA os requisitos técnicos
apresentados no QoS, os aspectos como o desempenho dos recursos humanos ao exemplo de
Help Desk, manutenção de equipamentos, entre outros, não foram averiguados.
A monitoria do presente SLA considerou três diferentes estados que o serviço de rede pode
apresentar, o estado OK, representando o perfeito funcionamento da rede, o estado de
Warning apontando degradação do nível de serviço e a indisponibilidade pelo estado de
Critical.
Cada mudança de estado representa um evento no sistema, gerando um alerta e apresentando
os valores dos parâmetros monitorados, demonstrando as possíveis irregularidades
encontradas na verificação das métricas coletadas contra o rigor estipulado em seus valores,
como apresentado no item 3.1 – Monitoria dos parâmetros de QoS do Acordo de Nível de
Serviço.
Além de gerar os alertas, a ferramenta NAGIOS possibilita gerar relatórios mensais sobre a
rede monitorada, mostrando o histórico dos alertas gerados ao longo do mês, possibilitando
fácil acompanhamento da quantidade de horas que a rede permaneceu em cada estado ao
longo do mês, como mostra a figura 24.
Figura 24: Relatório de estados.
Fonte: NAGIOS instalado no CCI
A figura 24 possibilita a averiguação do cumprimento do SLA, além de possibilitar o cálculo
das multas advindas do seu não cumprimento, mostrando o índice alcançado de
disponibilidade, somando-se o estado de perfeito funcionamento – OK, com o estado de
degradação – Warning. Valores que acumularam 99.7% de disponibilidade da rede no mês de
novembro de 2005, atendendo ao rigor estipulado na cláusula quinta do presente SLA.
O Estado de degradação classificado como Warning, também é tomado para fins de cálculo
de multas apesar de não representar a indisponibilidade do sistema como estipulado na
cláusula dez, parágrafo terceiro. Assim os 0.255% de Warning que tomaram 1h e 50m (uma
hora e cinqüenta minutos) acarretaram no desconto de 1,1% na fatura do mês seguinte para
esta localidade, podendo ser verificado pela cláusula dez, parágrafo primeiro.
Destaca-se que quando os parâmetros de Tempo de Resposta e Perda de Pacotes não são
respeitados, estes são classificados como degradação do sistema desde que não ultrapassem
250% do valor estipulado para seu limite, uma vez alcançado esse valor, a rede é tomada
como indisponível por possuir excessiva degradação, ação automaticamente tomada como
mostram as figuras 25 e 26.
Figura 25: Demonstrativo dos detalhes de alertas.
Fonte: NAGIOS instalado no CCI
A figura 25 demonstra dois estados de Warning referente ao atraso na entrega dos pacotes
(394.873 ms e 307.738 ms respectivamente) estando acima do limite caracterizado como em
perfeito funcionamento (300ms) mas abaixo dos 250% que o caracterizariam com o mesmo
peso da indisponibilidade da rede (750ms). Um estado Critical também esta presente na
figura 25 apontando a perda de 100% dos pacotes.
Figura 26: Demonstrativo dos detalhes de alertas 2.
Fonte: NAGIOS instalado no CCI
A figura 26 demonstra o atraso na entrega dos pacotes superando os 250% do limite da
degradação, classificando esta perda como de grau crítico, vindo a ser contabilizado assim,
como indisponibilidade da rede pelo período que permaneceu neste estado.
Apesar do relatório de estados ser o suficiente para se averiguar o cumprimento do SLA ao
longo do mês de novembro de 2005, pode vir a ser interessante identificar quando que o
estado crítical foi alcançado e por quanto tempo este persistiu para cada ocorrência. Para isso
a ferramenta apresenta um histórico dos estados critical, detalhando os momentos da
ocorrência, informando a data da ocorrência, o tempo de duração e o motivo para cada
ocorrência, pelo simples clique do mouse em cima do evento, como mostra a figura 27.
Figura 27: Histórico de disponibilidade.
Fonte: NAGIOS instalado no CCI
Também na ferramenta NAGIOS é possível apresentar um histograma informando a
quantidade de cada tipo de evento gerado na rede ao longo do mês, possibilitando verificar a
distribuição das ocorrências ao longo do mês. Como mostra a figura 28.
Figura 28: Histograma dos alertas.
Fonte: NAGIOS instalado no CCI
A figura 28 mostra a quantidade de eventos que foram detectados pelo sistema, ilustrando no
canto direito a ocorrência de vinte e quatro alertas “critical” e vinte e um alertas “warning” ,
além de mostrar a distribuição e informar o número máximo de ocorrência em um mesmo dia,
no campo MAX da referida tabela.
Após a verificação da ferramenta NAGIOS, é necessário averiguar o atendimento à utilização
e consumo do circuito contratado, pelo uso da Ferramenta CACTI.
O Nível de Serviço da rede de Joinville esta estabelecido em nível dois, segundo a cláusula
segunda do presente SLA, garantindo uma velocidade de 128kbps com um CIR de 64kbps
conforme cláusula quinta. O gráfico gerado pela ferramenta CACTI ilustrado na figura 29,
apresenta no canto esquerdo uma escala que se adapta a velocidade máxima praticada no
circuito para o referido mês. Neste caso observa-se este valor em 100k, que é o mesmo
indicado no campo Maximum na linha de Outbound, que representa a vazão de saída da rede.
Nota-se que o circuito em média (Average) ficou fixado em 21.01k, e o gráfico apresentou
pouco consumo desta banda e nenhuma limitação ao seu uso. A limitação no uso da banda
implicaria no nivelamento plano da linha de vazão junto ao limite, assim como o incorreto
dimensionamento da rede implicaria no transito médio estar sempre próximo do CIR (64kbps)
e diversos picos representando os Burstings tentando consumir mais banda do que o
garantido.
Figura 29: Gráfico de utilização de banda.
Fonte: NAGIOS instalado no CCI
Como conclusão deste gráfico nota-se que o circuito esta sendo subutilizado. Apesar disso, a
opção do consumidor foi escolher este nível de serviço para poder usufruir do maior rigor aos
parâmetros de disponibilidade não encontrados no nível inferior.
As multas decorrentes do presente SLA para a rede de Joinville, implicaria no desconto de
1.1% (um porcento e meio) na mensalidade do mês subseqüente, por disponibilizar a rede ao
longo do mês com uma hora e cinqüenta minutos de degradação, valor pequeno frente ao
valor embutido que os provedores agregariam ao valor de uma rede regida por um SLA como
forma de seguro.
3.3 CONSIDERAÇÕES FINAIS
As ações tomadas para a rede de Joinville representam a ação que deveria ser tomada para se
averiguar o atendimento ao presente SLA, sendo esta ação repetida para todas as outras redes
e feita mensalmente, afim de sempre identificar irregularidades e possíveis melhorias nos
ajustes aos níveis de serviço.
Este SLA baseia-se na pró-atividade do provedor de solucionar os problemas, não estipulando
prazos para a resolução dos problemas, visto que a demora para a resolução acarreta
diretamente na contabilização dos tempos de indisponibilidade e degradação da rede.
A Monitoria dos Indicadores de Desempenho da rede da Polícia Militar do Estado de Santa
Catarina faz parte de uma das iterações para a formação do SLA. Esta formalização não é um
processo estático e necessita de diversas iterações para o contínuo aprimoramento e
refinamento das métricas nelas descritas, até mesmo para evitar que sejam apresentados
demasiados alertas ou até mesmo alerta falso-positivos, este último tomando medidas tão
rígidas na monitoria que acuse problemas críticos que poderiam ser casos raros ocasionados
no exato segundo da averiguação da métrica.
“Discuta todas as métricas e quando estas conformam com os objetivos. Se elas não
conformarem, determine a razão principal do problema e implemente aprimoramentos”
(CISCO, 2002, p.23). Assim, o protótipo deve vir a ser reajustado seguindo a mudança dos
parâmetros no sistema de monitoria. Maurer, Matlus e Frey (2000, p.21) recomendam que
seja garantido que os processos estejam estáveis e que os resultados são alcançados revendo o
processo de monitoria a cada noventa dias e que sejam identificadas oportunidades para
futuros aprimoramentos.
Figura 30: Ciclo da entrega de um SLA.
Fonte: IBM (2002b, p.7).
A cada revisão, os níveis de serviço podem vir a ser reajustados, tomando que as expectativas
formadas hoje podem não ser suficientes amanhã. As novas identificações por padrões de
qualidade podem ser advindas pela evolução da tecnologia, como parte das novas exigências
e expectativas do cliente, e até mesmo por dados extraídos da monitoria que comprovam a
necessidade de maiores recursos, aspectos subestimados ou superestimados e possíveis erros
de aquisição e planejamento. Ainda, a cada revisão, é possível, para o consumidor e provedor,
estimar melhor os tempos e caminhos de resolução, alimentando o SLA com as experiências
ao longo de sua execução e tornando-o também, documento de referência para resolução de
problemas referentes ao serviço.
Um SLA não deve ser considerado concluído, seja este o protótipo inicial anterior à
contratação ou aquele já em uso. Deve-se buscar a mudança do modelo de suporte reativo
para um modelo de suporte pró-ativo, onde a disponibilidade e níveis de desempenho devem
ser determinados pelos requerimentos de negócio e não pelos últimos problemas técnicos
encontrados (CISCO, 2002, p.33).
Além dos indicadores monitorados neste TCC, uma completa gerência de Acordo de Nível de
Serviço necessitaria da monitoria também de outros indicadores. Este trabalho tomou as
métricas clássicas de desempenho de uma rede por serem indicadores tecnicamente
específicos, que puderam ser monitorados pela coleta de informações da camada de rede,
abstraindo-se os indicadores que completam a característica do serviço, como a atuação do
suporte, o desempenho da equipe técnica, tempos de reparos, entre outros, apresentados neste
trabalho. Tais indicadores que não fazem parte das métricas clássicas de desempenho
monitoradas neste SLA seriam:
•
Desempenho do Help-Desk, medido pelo uso de um sistema de acompanhamento de
chamadas.
•
MTBF – Tempo médio entre as falhas, para se ter a estatística da periodicidade das
falhas, podendo ser também acompanhado pelo mesmo sistema do Help-Desk;
•
MTRS – Tempo médio para restaurar o serviço, também acompanhado pelo sistema
de Acompanhamento de Chamados ou pela observação da duração dos eventos no
NAGIOS como apresentados na figura 27.
•
Desempenho de Segurança, acompanhados por sistemas de Intrusion Detection
Systems e Firewalls, gerando relatórios sobre invasões.
Em futuras iterações, na busca do aprimoramento também pode ser possível a identificação de
novos indicadores de qualidade não relacionados neste trabalho, em situações específicas,
variando em cada cenário, cabendo ao analista determinar se este faz parte do requerimento
do negócio, necessitando a sua formalização no SLA proposto.
4
CONCLUSÃO
Os benefícios de se adotar um SLA e a sua gerência vão além da provisão de maior
produtividade e melhores relações de terceirização. Os resultados desse processo provêm ao
receptor do serviço, meio de obter ganhos adicionais em seus negócios pelo aprimoramento
da competitividade, medição da produtividade e redução de custos. A primeira preocupação é
evitar ambigüidades e traçar objetivos os mais realistas possíveis, negociando as elevadas
exigências dos clientes com a tendência da subestimação de suas necessidades pelo provedor.
Um acordo com métricas, seguido de sua monitoração, é a segunda preocupação, definindo
que todos estão de acordo sobre os objetivos e como verificá-los, tornando a monitoria o fator
mais importante durante a manutenção do SLA, verificando-se o atendimento dos objetivos e
garantindo uma melhor relação de parceria.
Para que um SLA funcione, é preciso que todos os envolvidos estejam de “boa fé” e não se
utilizem do Acordo como meio de buscar culpados pelos insatisfatórios níveis de serviço e,
sim, como meio de prover o controle sobre a TI e direcioná-la às estratégias da empresa. Ao
direcionar o SLA como meio exclusivo de punição, os profissionais tendem a reagir de forma
negativa a sua adoção, adotando altos preços como meio de seguro pelas possíveis
penalidades ou até mesmo no boicote desde a sua confecção e manutenção, com receio de
passar informações relevantes ou na alimentação dos dados para as estatísticas do serviço.
Foi constatado que as penalidades, muitas vezes, financeiras, atribuídas aos SLAs existem
para servir como motivação do seu cumprimento e prevenir as falhas por provedores externos,
e não como meio de se punir os culpados e gerar ganhos através das apostas pelo não
cumprimento. Acredita-se que para provedores internos, uma lógica positiva surtiria melhor
efeito, tanto para sua adoção como para sua manutenção. Entende-se como lógica positiva as
bonificações de salários ou dias extras de férias para os funcionários responsáveis pela
garantia deste atendimento aos padrões de qualidade exigida, pois uma multa financeira ao
departamento de informática só acarretaria em menos recursos para investir no atendimento
dos níveis de serviço atuais e futuros.
Com a divulgação e maior oferta por Acordos de Nível de Serviço, Keller e Ludwig (2002)
apresentam a tendência de se delegar a monitoria do SLA para uma terceira parte, quando
nenhuma das partes envolvidas queira assumir a monitoria ou confiar na outra para realizar tal
função. Esta terceira parte agiria como suporte ao SLA patrocinado por uma ou ambas as
partes envolvidas no acordo. Não seria necessário realizar auditoria para o relatório desta
entidade, pela credibilidade associada a mesma, podendo, inclusive, esta terceira parte agir de
maneira legal sobre as cláusulas do contrato, até como ser responsável pela divulgação de
multas e faturas.
Pela falta de hábito de se estipularem tais Acordos de Nível de Serviço, este trabalho propôs
um protótipo, considerando-se as dificuldades de se obter reais contratos vigentes no
mercado. Baseou-se, então, em guias e referências publicadas por grandes organizações,
como IBM e CISCO, apresentando a monitoria dos indicadores clássicos referentes à
contratação de um serviço de rede como o Frame-Relay, apresentando este como primeiro
passo para a formalização deste, visto que diversas iterações devem ser realizadas afim de
ajustar os diversos parâmetros que podem vir a serem difíceis de se definir.
Apesar de um SLA apresentar um maior valor agregado, constatou-se que a grande maioria
prefere assumir o risco nas contratações de tais serviços, ao invés de pagar por outro com tais
garantias contratuais. Apesar disso, este trabalho propõe que mesmo que o consumidor não
esteja apto a adquirir um serviço agregado a um SLA, este poderia iniciar a criação de seus
protótipos e realizar a sua monitoria para melhor entender o serviço contratado e gerenciar as
suas próprias expectativas, recursos, programar orçamentos e justificar gastos. Nesse sentido,
este trabalho pode servir de guia introdutório para a confecção e possíveis negociações de um
futuro SLA.
Independente do tipo de negócio de uma empresa, os serviços de TI estão sofrendo mudanças
em suas responsabilidades, deixando de gerir serviços individuais para gerir serviços finais.
Tais acordos, então, podem auxiliar os executivos de informática junto aos seus gestores de
negócio a definirem os níveis de serviço a serem contratados ou oferecidos. Os conceitos
abordados neste trabalho podem ser estendidos a outros serviços de TI, tomando-se como
objetivo a garantia da qualidade do serviço.
Cabe salientar que apesar do SLA ser uma excelente forma de se contratar serviços, por
estabelecer parâmetros que devem ser atendidos pelo provedor de serviço, estes contratos
devem ser gerenciados efetivamente para evitar perdas e desgastes no relacionamento entre o
contratante e a contratada. A este propósito, Lee e Ben-Natan (2002, p.60) comentam em seu
livro que a criação de um SLA tornou-se um exercício na arte de manipular as palavras e
gerenciar riscos, escrevendo cláusulas de maneira a camuflar as violações e tornar os valores
das penalidades de pouca importância frente aos ganhos.
Assim, cabe destacar que “a melhor medida de um nível de serviço é a percepção do usuário e
sua satisfação” (MAURER, MATLUS e FREY, 2000, p.21).
GLOSSARIO E ACRÔNIMOS
RFC – Request for Comments
ISO – International Stardardization Organization
TI – Tecnologia da Informação
TCP – Transmission Control Protocol
IP – Internet Protocol
LAN – Local Area Network
WAN – Wide Area Network
PMSC – Polícia Militar do Estado de Santa Catarina
SLA – Service Level Agreement
VoIP – Voice Over IP
FR – Frame-Relay
QoE – Quality of Experience
QoS – Quality of Service
DLCI – Data Link Connection Identifier
SO – Sistema Operacional
REFERÊNCIAS
ARMITAGE, Greenville. Quality of service in IP Networks. EUA, New Riders. abr. 07 , 2000. ISBN:
1-57870-189-9.
COBIT. Management Guidelines. CobiT Steering Committee e IT Governance Institute. 3. ed. 2000.
ISBN 1-893209-12-1
CISCO, Service level Management, Best Practices White Paper. 2002. Document ID 15117.
Disponível em: http://www.cisco.com/warp/public/126/sla.pdf Acesso em: 15 maio 2005.
CISCO. International Technology Handbook, 2004a , Capítulo 49. Disponível em:
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/qos.htm#1020563 Acesso em: 13 maio
2005. ISBN 158705-001-3.
CISCO. International Technology Handbook, 2004b ,Capítulo 10. Disponível em:
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/frame.pdf Acesso em: 03 set. 2005. ISBN
158705-001-3.
ECONOMIANET. Commodities. Disponível em :
http://www.economiabr.net/economia/5_commodities.html. Acesso em 2 de novembro de 2005.
EMBRATEL. Garantia de Desempenho. Disponível em:
<www.embratel.com.br/Embratel02/cda/portal/0,2997,MG_P_1906,00.html> Acesso em: 19 maio
2005.
GREMBERGEN, Win Van, Ph, D.; HAES, Steven De e AMELINCKX, Isabelle. Using Cobit and
the Balanced Scorecard as Instruments for Service Level Management. Information Systems Control
Journal, Volume 4, 2003. Disponível em
http://www.isaca.org/Content/ContentGroups/Member_Content/Journal1/20033/Using_COBIT_and_t
he_Balanced_Scorecard_as_Instruments_for_Service_Level_Management.htm acessado em 23 de
abril de 2005.
HERRTWICH, R. G. The Role of Performance, Scheduling, and Resource Reservation in
Multimedia Systems, Operating Systems of the 90s and Beyond, A. Karshmer; J. Nehmer, Alemanha,
1991, ed. Springer-Verlag, p. 279-284.
IBM. Tivoli Service Level Advisor Product Profile, 2002a, Enterprise Management Associates, Inc.
Disponível em: http://www.900.ibm.com/cn/software/tivoli/products/download/analystreports/slaar.pdf Acesso em: 09 maio 2005.
IBM. Tivoli Service Level Advisor Handbook, 2002b. Disponível em
http://www.redbooks.ibm.com/redbooks/SG246611.html acessado em 10 de outubro de 2005
ISO/IEC 9126 : Information technology - Software Product Evaluation - Quality characteristics and
guidelines for their use ,1991.
ISO 9241-11 : Ergonomic requirements for office work with visual display terminals, 1998.
KELLER, Alexander; LUDWIG, Heiko. Defining and Monitoring Service Level Agreements for
dynamic e-Business. EUA. 2002. Disponível em
<http://www.research.ibm.com/people/a/akeller/Data/lisa2002_slides.pdf> Acesso em: 2 out. 2005.
LANDIS, Kenneth M. ; MISHRA, Somnath ; PORRELLO, Kenneth. Deloitte Development, Calling
a change in the outsourcing market. 2005. Disponível em:
<http://www.deloitte.com/dtt/cda/doc/content/us_outsourcing_callingachange.pdf > Acesso em: 16
abr. 2005.
LEE, John; BEN-NATAN, Ron. Integrating Service Level Agreements. EUA, Wiley Publishing,
2002. 424p. ISBN 0-471-21012-9
LEE, Hyo-Jin; KIM, Myung-Sup; HONG, James. QoS Parameters to Network Performance Metrics
Mapping for SLA Monitoring. 2003. Disponível em <http://www.knom.or.kr/knomreview/v5n2/4.pdf> Acesso em: 26 set. 2005.
MAURER, W; MATLUS R. e FREY N. A Guide to Successful SLA Development and Management.
EUA. GartnerGroup, 2000. 22 p. R-11-3353
MYERSON, Judith M. Use SLAs. Web Services context, 2004, Development works da IBM.
Disponível em: <www6.software.ibm.com/software/developer/library/ws-sla.pdf> Acesso em: 10
maio 2005.
NBR ISO 8402. Qualidade e Produtividade no setor de software. Glossário de Termos de
qualidade. Disponível em <http://www.mct.gov.br/Temas/info/Dsi/qualid99/99anexo2.htm> . Acesso
em 05 de junho de 2005.
PRADO, Edmir. Parada. Vasquez. Terceirização da Tecnologia da Informação: Uma avaliação dos
fatores que motivam sua adoção em empresas do setor industrial de São Paulo. Faculdade de
Administração, Economia e Contabilidade. Dissertação de Mestrado, USP, 2000.
RFC 2457. An Architecture for Differentiated Services. 1998. Disponível em
<http://www.ietf.org/rfc/rfc2475.txt> ou <ftp://ftp.ietf.rnp.br/rfc/rfc2475.txt> Acesso em: 28 maio
2005.
RFC 1633. Integrated Services in the Internet Architecture: an Overview .1994. Disponível em
<http://www.ietf.org/rfc/rfc1633.txt> ou <ftp://ftp.ietf.rnp.br/rfc/rfc1633.txt>. Acesso em: 28 maio
2005.
RFC 2474. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
.1998. Disponível em <http://www.ietf.org/rfc/rfc2474.txt> ou <ftp://ftp.ietf.rnp.br/rfc/rfc2474.txt>
Acesso em: 28 maio 2005.
RFC 1349. Type of Service in the Internet Protocol Suíte. 1992. Disponível em
<http://www.ietf.org/rfc/rfc1349.txt> Acesso em: 28 maio 2005.
RFC 791. Internet Protocol - IP, 1981. Disponível em: <http://www.ietf.org/rfc/rfc791.txt> Acesso
em: 28 maio 2005.
SINGH, Amit. Making An Operating System Faster. 2005. Disponível em
<http://www.kernelthread.com/mac/apme/optimizations/> Acesso em: 3 jun. 2005.
SAGE RESEARCH, Service Level Agreements Gain Increased Importance Among Enterprises.
Disponível em <http://www.sageresearch.com/sla_a.htm> Acesso em: 10 mar. 2005.
SPOSITO, Rosa . Entre o Controle e a Rendição. Revista INFO CORPORATE, Editora Abril, Ago.
2004. Disponível em http://info.abril.com.br/corporate/edicoes/11/dossie/conteudo_47954.shtml
Acesso em: 18 maio 2005.
THE OPEN GROUP, SLA Management Handbook, v. 4, Editora The Open Group, out. 2004. ISBN
1-931624-51-8 Document Number G045.
VERMA, C. Dinesh. IBM T. J Watson Research Center. Service Level Agreements on IP Networks,
1999. Disponível em <http://www.research.ibm.com/people/d/dverma/papers/SLAOverview.pdf>
Acesso em: 10 maio 2005.
WHITE, Paul. RSVP and Integrated Services in The Internet: A Tutorial, IEEE. Communications
Magazine, p.100-106, maio 1997.
WISNER, A. Por dentro do trabalho. Ergonomia: método & técnica. São Paulo: FTD/Oboré, 1987.