Service Level Management: White Paper de práticas recomendadas · Indicadores de desempenho ... de...

Service Level Management: White Paper depráticas recomendadas

Índice

IntroduçãoVisão geral doi gerenciamento de nível de serviçoFatores de sucessão críticaIndicadores de desempenhoFluxo de processo de gerenciamento de nível de serviçoExecutando o gerenciamento de nível de serviçoDefinindo níveis de serviço de redeCriando e mantendo SLAIndicadores de desempenho do gerenciamento de nível de serviçoService Level Agreement ou definição nivelada de serviço documentadaMétricas de indicador de desempenhoRevisão do gerenciamento de nível de serviçoResumo de gerenciamento de nível de serviçoInformações Relacionadas

Introdução

Este documento descreve o gerenciamento de nível de serviço e os SLAs (acordos de nível deserviço) para redes de alta disponibilidade. Inclui fatores críticos de sucesso para ogerenciamento em nível de serviço e indicadores de desempenho para ajudar a avaliar osucesso. O original igualmente fornece o detalhe significativo para os SLA que seguem asdiretrizes de práticas recomendadas identificadas pela Alta disponibilidade da equipe do serviço.

Visão geral doi gerenciamento de nível de serviço

As organizações de rede encontraram historicamente requisitos de rede de expansão por infra-estruturas de rede contínuas de construção e trabalho reactivamente segurar edições do serviçoindividual. Quando ocorria uma interrupção, a organização desenvolvia novos processos,recursos de gerenciamento ou infra-estrutura para evitar que uma interrupção específicaocorresse novamente. Contudo, devido a uma taxa mais alta e aos aumentos do requisito dedisponibilidade da mudança, nós precisamos agora um modelo melhorado de impedirdinamicamente o tempo ocioso não planejado e de reparar rapidamente a rede. Muito o provedorde serviços e as organizações de empreendimento tentaram definir melhor o nível do serviçoexigido para conseguir objetivos do negócio.

Fatores de sucessão crítica

Os fatores de sucessão crítica para SLA são usados para definir os elementos chaves para comsucesso construir níveis de serviço obteníveis e para manter SLA. Para qualificar como um fatorde sucessão crítica, um processo ou a etapa do processo devem melhorar a qualidade do SLA ebeneficiar a disponibilidade da rede geralmente. O fator de sucesso crítico também deve sermedido de modo que a organização possa determinar o sucesso relativo ao procedimentodefinido.

Consulte Implementando gerenciamento em nível de serviço para obter mais detalhes.

Indicadores de desempenho

Os indicadores de desempenho oferecem o mecanismo pelo qual uma organização mede osfatores de sucesso importantes. Você revê tipicamente estes numa base mensal para assegurar-se de que as definições de nível de serviço ou os SLA estejam trabalhando bem. O grupo deoperações de rede e os grupos necessários das ferramentas podem executar o seguinte medidor.

Nota: Para organizações sem SLA, nós recomendamo-lo executamos definições de nível deserviço e revisões do serviço-nível além do que o medidor.

Os indicadores de desempenho incluem:

Definição de nível de serviço documentada ou SLA que incluem a Disponibilidade, odesempenho, o tempo de resposta do serviço reagente, os objetivos de definição deproblema, e o agravamento de problema.

●

Reunião de revisão mensal do serviço-nível dos trabalhos em rede para rever a conformidadedo serviço-nível e para executar melhorias.

●

Os métricos de indicador de desempenho, incluindo a Disponibilidade, desempenho, tempode resposta de serviço pela prioridade, cronometram para resolver pela prioridade, e pelosoutros parâmetros de SLA mensuráveis.

●

Consulte Implementando gerenciamento em nível de serviço para obter mais informações.

Fluxo de processo de gerenciamento de nível de serviço

O fluxo de processo de alto nível para o gerenciamento de nível de serviço contém dois gruposimportantes:

Definindo níveis de serviço de rede1.Criando e mantendo SLA2.

Clique sobre os objetos no seguinte diagrama para ver os detalhes para essa etapa.

Executando o gerenciamento de nível de serviço

Executar o gerenciamento de nível de serviço consiste em dezesseis etapas divididas nasseguintes duas categorias principal:

Definindo níveis de serviço de rede●

Criando e mantendo SLA●

Definindo níveis de serviço de rede

Necessidade das gerentes de rede de definir as regras principais por que a rede é apoiada,controlado, e medido. Os níveis de serviço fornecem objetivos para todos os pessoais da rede epodem ser usados como uma métrica na qualidade do serviço total. Você também pode nosfornecer definições de nível de serviço como uma ferramenta para fazer o orçamento de recursosde rede e como evidência para a necessidade de financiar um QoS mais alto. Tambémproporcionam uma forma de avaliar o desempenho de fornecedores e portadoras.

Sem uma definição e medição de nível de serviço, a organização não tem metas claras. Asatisfação com o serviço pode ser regida por usuários com uma pequena diferenciação entreaplicativos, operações de servidor/cliente ou suporte de rede. Incluir no orçamento pode ser maisdifícil porque o resultado final não é claro à organização, e finalmente, a organização de redetende a ser mais reativa, não dinâmica, em melhorar a rede e o modelo de suporte.

Nós recomendamos as seguintes etapas para construir e apoiar um modelo do serviço-nível:

Analise objetivos e limitação técnicos.1.Determine o orçamento de disponibilidade.2.Crie os perfis do aplicativo que detalham características de rede dos aplicativos críticos.3.Defina a Disponibilidade e as padronizações de desempenho e defina termos comuns.4.Crie uma definição de nível de serviço que inclua a Disponibilidade, o desempenho, o tempode resposta do serviço, o tempo médio para solucionar o problema, a detecção de defeito,os pontos iniciais da elevação, e o caminho de escalada.

5.

Recolha o medidor e monitore a definição de nível de serviço.6.

Passo 1: Analise objetivos e limitação técnicos

A melhor maneira de iniciar a análise de restrições e objetivos técnicos é discutir ou pesquisar osobjetivos e os requisitos técnicos. Algumas vezes, pode ajudar convidar outros colegas detécnicos de TI para participar dessa discussão porque esses indivíduos tem metas específicasrelacionadas a seus serviços. Os objetivos técnico incluem a Disponibilidade dos níveis, a taxa detransferência, o tremor, o atraso, o tempo de resposta, os requisitos de escalabilidade, asintroduções dos novos recursos, as introduções do aplicativo novo, a Segurança, a viabilidade, emesmo o custo. A organização deve investigar as restrições para atingir essas metas fornecidaspelos recursos disponíveis. Você pode criar planilhas para cada objetivo, com uma explicação derestrições. Inicialmente, pode parecer como se a maioria dos objetivos não são realizáveis.Comece então dar a prioridade aos objetivos ou abaixar as expectativas que podem aindacumprir exigências do negócio.

Por exemplo, você pôde ter uma Disponibilidade em nível de 99.999 por cento, ou os minutos 5do tempo ocioso da máquina pelo ano. Existem inúmeras limitações para alcançar este objetivo,como pontos únicos de falha no hardware, hardware quebrado em tempo médio ao reparo(MTTR), confiabilidade no portador, capacidades de detecção de falha pró-ativa, altas taxas dealteração e limitações de capacidade de rede atual. Em consequência, você pode ajustar oobjetivo a um nível mais realizável. O modelo de disponibilidade na próxima seção pode ajudá-loa definir metas realistas.

Você pode igualmente pensar sobre o fornecimento da disponibilidade mais alta em determinadasáreas da rede que têm menos limitações. Quando a organização de rede publica padrões deserviço para disponibilidade, os grupos de negócios dentro da organização podem achar o nívelinaceitável. Portanto, esse é um ponto natural para começar discussões sobre SLA ou modelosde financiamento/orçamentos que podem alcançar os requisitos comerciais.

Trabalhe para identificar todas as limitações ou riscos envolvidas em conseguir o objetivo técnico.Priorize as restrições em termos do maior risco ou impacto sobre o objetivo almejado. Isto ajuda aorganização a dar a prioridade a iniciativas de aprimoramento da rede e a determinar comofacilmente a limitação pode ser endereçada. Há três tipos das limitações:

Tecnologia de rede, elasticidade, e configuração●

Práticas de ciclo de vida, incluindo o planeamento, o projeto, a aplicação, e a operação●

Carga de tráfego ou comportamento de aplicativo atual●

A tecnologia de rede, a elasticidade, e as limitações da configuração são todas as limitações ouriscos associadas com a tecnologia atual, o hardware, as relações, o projeto, ou a configuração.As limitações de tecnologia cobrem toda a limitação levantada pela tecnologia própria. Porexemplo, nenhuma tecnologia atual permite o secundário-segundo tempo de convergência nosambientes de rede redundante, que podem ser críticos para conexões de voz de sustentaçãoatravés da rede. Um outro exemplo pode estar a uma velocidade crua que os dados possam

atravessar em links terrestres, que são aproximadamente 100 milhas por milissegundos.

As investigações do risco da elasticidade do hardware de rede devem concentrar-se na topologia,na hierarquia, na modularidade, na Redundância, e no MTBF do hardware ao longo dos trajetosdefinidos na rede. As limitações do link de rede devem centrar-se sobre links de rede eConectividade do portador para organizações de empreendimento. As limitações da relaçãopodem incluir a redundância de link e a diversidade, as limitações dos media, prendendo infra-estruturas, Conectividade do loop local, e conectividade de longa distância. As restrições deprojeto relacionam-se ao exame ou ao projeto lógico da rede e incluem-se tudo do espaçodisponível para o equipamento à escalabilidade da aplicação do protocolo de roteamento. Todosos projetos do protocolo e dos media devem ser considerados com relação à configuração, àDisponibilidade, à escalabilidade, ao desempenho, e à capacidade. As limitações do serviço derede tais como o protocolo de configuração dinâmica host (DHCP), o Domain Name System(DNS), os Firewall, os tradutores de protocolo, e os tradutores de endereço de rede devemigualmente ser consideradas.

As práticas de ciclo de vida definem os processos e o Gerenciamento da rede usada paradistribuir consistentemente soluções, detectam e reparam problemas, impedem a capacidade ouos problemas de desempenho, e configuram a rede para a consistência e a modularidade. Énecessário considerar essa área porque experiência e processos normalmente são os itens quemais contribuem para não-disponibilidade. O ciclo de vida da rede refere o ciclo do planeamento,do projeto, da aplicação, e das operações. Em cada uma dessas áreas, você deve entender afuncionalidade do gerenciamento de rede como o gerenciamento de desempenho, gerenciamentode configuração, gerenciamento de falhas e segurança. Uma avaliação do ciclo de vida de redeestá disponível dos serviços do (HAS) dos serviços de alta disponibilidade de Cisco NSA quemostram a Disponibilidade de limitações da rede atual associadas com as práticas do ciclo devida de rede.

As limitações atuais da carga de tráfego ou do aplicativo referem simplesmente o impacto dotráfego e de aplicativos atuais.

Infelizmente, muitos aplicativos têm as limitações significativas que exigem o gerenciamentocuidadoso. O Jitter, o atraso, a taxa de transferência, e os requisitos de largura de banda paraaplicativos atuais têm tipicamente muitas limitações. A maneira que o aplicativo foi escrito podeigualmente criar limitações. A definição do perfil do aplicativo ajuda-o melhor a compreenderestas edições; a próxima seção cobre esta característica. A Disponibilidade, o tráfego, acapacidade, e o macacão atuais de investigação do desempenho igualmente ajudam gerentes derede a compreender expectativas e riscos atuais do serviço-nível. Isto é realizado tipicamentecom um processo chamado a avaliação comparativa de rede, que ajuda a definir o desempenhoda rede, a Disponibilidade, ou as médias da capacidade por um período de horário definido,normalmente aproximadamente um mês. Esta informação é usada normalmente para oplanejamento da capacidade e a tensão, mas pode igualmente ser usada para compreenderedições do serviço-nível.

A seguinte folha usa o objetivo/método acima da limitação para o objetivo do exemplo de impedirum ataque de segurança ou um ataque de recusa de serviço (DOS). Você pode igualmente usaresta folha para ajudar a determinar a cobertura do serviço para ataques de segurança deminimização.

Risco ou restrição Tipo derestrição

Impactopotencial

As ferramentas disponíveis dadetecção DoS não podem detectartodos os tipos de ataques DoS.

Tecnologia/elasticidade Alto

Não tenha o pessoal e o processoexigidos a reagir aos alertas.

Práticas deciclo devida

Alto

As políticas de acesso da rede atualnão são no lugar.

Práticas deciclo devida

Médio

A conexão com o Internet atual dabaixo-largura de banda pode ser umfator se a congestão da largura debanda é usada para o ataque.

Capacidadede rede

Médio

Atualmente a configuração desegurança a ajudar a impedir ataquesnão pode ser completa.

Tecnologia/elasticidade

Médio

Passo 2: Determine o orçamento de disponibilidade

Um orçamento de disponibilidade é a disponibilidade teórica prevista da rede entre dois pontosdefinidos. A informação teórica exata é útil em diversas maneiras:

A organização pode usar esta enquanto um objetivo para a Disponibilidade e desvios internospode rapidamente ser definido e remediado.

●

As informações podem ser usadas pelos planejadores de rede ao determinar adisponibilidade do sistema, ajudando a garantir que o projeto atenda aos requisitos denegócios.

●

Os fatores que contribuem à indisponibilidade ou o tempo de parada incluem a falha do hardware,a falha de software, a potência e as questões ambientais, a relação ou a falha do portador, oprojeto de rede, o erro humano, ou a falta do processo. Você deve avaliar bem cada um dessesparâmetros ao avaliar o orçamento geral de disponibilidade para a rede.

Se a organização mede atualmente a Disponibilidade, você não pode precisar um orçamento dedisponibilidade. Use a medida do disponibilidade como uma linha de base para calcular o nível deserviço atual usado para uma definição de nível de serviço. Contudo, você pode estar interessadoem comparar os dois para compreender a disponibilidade teórica potencial comparada aoresultado medido real.

A Disponibilidade é a probabilidade que um produto ou um serviço operarão quando necessário.Veja as seguintes definições:

Disponibilidade1 (tempo total de interrupção da conexão) / (tempo total de conexão emserviço)1 - [Sigma(num connections affected in outage i X duration of outage i)]/(connsnuméricos no tempo de funcionamento do serviço X)

1.

Indisponibilidade1 - Disponibilidade, ou total interrupção do tempo de conexão devido a(falha de hardware, falha de software, problemas ambientais e de energia, falha de enlaceou de transporte, design da rede ou erro do usuário e falha no processo)

2.

Disponibilidade de hardwareA primeira área a investigar é falha de hardware potencial e oefeito na indisponibilidade. Para determinar isto, a organização precisa de compreender o

3.

MTBF de todos os componentes de rede e o MTTR para problemas de hardware para todosos dispositivos em um trajeto entre dois pontos. Se a rede é modular e hierárquica, adisponibilidade de hardware será a mesma entre quase todos os dois pontos. A informaçãoMTBF está disponível para todos os componentes Cisco e está disponível mediantesolicitação a um gerenciador de conta local. O programa do Cisco NSA HAS igualmente usauma ferramenta para ajudar a determinar a disponibilidade de hardware ao longo doscaminhos de rede, mesmo quando a Redundância do módulo, a Redundância do chassi, e aredundância de caminho existem no sistema. Um fator principal da confiabilidade dehardware é o MTTR. As organizações devem avaliar como rapidamente podem reparar ohardware quebrado. Se a organização não tem nenhum plano frugalmente e confia em umacordo padrão de Cisco SMARTnet™, a seguir o tempo de substituição médio potencial éaproximadamente 24 horas. Em um ambiente de LAN típico com redundância central enenhuma Redundância do acesso, a disponibilidade aproximada é 99.99 por cento com umMTTR de 4 horas.Disponibilidade de softwareA área seguinte para a investigação falha falhas de software.Para finalidades da medida, Cisco define falhas de software como os coldstarts dodispositivo devido ao erro de software. Cisco fez o progresso significativo para adisponibilidade de software compreensiva; contudo, umas liberações mais novas tomam otempo medir e são consideradas menos disponível do que o software de distribuição geral.O software de distribuição geral, tal como a Versão do IOS 11.2(18), foi medido sobre em99.9999 por cento de Disponibilidade. Isto é calculado com base em coldstarts reais noRoteadores de Cisco que usa seis minutos como o tempo de reparo (hora para que oroteador recarregue). As organizações que trabalham com várias versões devem obter umadisponibilidade ligeiramente inferior, devido à complexidade, à interoperabilidade e aoaumento de tempo no Troubleshooting. Espera-se que as organizações com as versões desoftware mais recentes tenham uma indisponibilidade maior. A distribuição para a não-disponibilidade também é muito ampla, o que significa que os clientes podem experimentarou não-disponibilidade significativa ou disponibilidade fechada para uma versão dedistribuição geral.

4.

Ambiental e disponibilidade de energiaVocê também deve considerar problemas ambientaise de energia na disponibilidade. As questões ambientais relacionam-se à divisão dossistemas de refrigeração necessários manter o equipamento em uma temperatura defuncionamento especificada. Muitos dispositivos Cisco fecharão simplesmente quando sãoconsideravelmente fora da especificação um pouco do que arriscando dano a todo ohardware. Com a finalidade de um orçamento de disponibilidade, a potência será usadaporque é a causa principal da indisponibilidade nesta área.Embora as falhas de energiasejam um aspecto importante de determinar a disponibilidade da rede, esta discussão élimitada porque a análise das energias teóricas não pode exatamente ser feita. Queorganização deve avaliar é uma medida aproximada da disponibilidade de energia a seusdispositivos baseados na experiência em seus área geográfica, capacidades de backup deenergia, e processo executado para assegurar o poder de qualidade consistente a todos osdispositivos.Para uma avaliação conservadora, nós podemos dizer que uma organizaçãocom geradores de backup, sistemas do uninterruptible-power-supply (UPS), e processos deimplementação das energias de qualidade pode experimentar seis 9s da Disponibilidade, ou99.9999 por cento, visto que as organizações sem estes sistemas podem experimentar aDisponibilidade em 99.99 por cento, ou aproximadamente 36 minutos do tempo ocioso damáquina anualmente. Naturalmente você pode ajustar estes valores a uns valores maisrealísticos baseados na percepção ou nos dados reais da organização.

5.

Relação ou falha do portadorA relação e as falhas do portador são fatores principais arespeito da Disponibilidade nos ambientes de WAN. Mantenha na mente que os ambientesde WAN são simplesmente outras redes que são sujeitas aos mesmos problemas dedisponibilidade que a rede da organização, incluindo a falha do hardware, a falha desoftware, o erro de usuário, e a falha de energia.Muitas redes do portador têm executado jáum orçamento de disponibilidade em seus sistemas, mas obter esta informação pode serdifícil. Mantenha na mente que os portadores igualmente têm frequentemente aDisponibilidade dos níveis da garantia que têm quase nenhuma base em um orçamento dedisponibilidade real. Estes níveis da garantia estão introduzindo no mercado às vezessimplesmente e os métodos das vendas usados para promover o portador. Em algunscasos, estas redes igualmente publicam a Disponibilidade das estatísticas que parecemextremamente boas. Mantenha na mente que estas estatísticas podem aplicar somente àsredes central completamente redundantes e não fatoram na indisponibilidade devido aoacesso do loop local, que é um contribuinte principal à indisponibilidade nas redes deWAN.Criar uma avaliação da Disponibilidade para ambientes de WAN deve ser baseada nainformação do portador real e no nível da Redundância para a conectividade de WAN. Seuma organização tem facilidades múltiplas da entrada da construção, fornecedoresredundantes do loop local, acesso local do Synchronous Optical NETwork (SONET), eportadoras interurbanas redundantes com diversidade geográfica, a disponibilidade de WANestará aumentada consideravelmente.O serviço de telefonia tem um orçamento dedisponibilidade razoavelmente preciso para conectividade de rede não redundante emambientes WAN. A conectividade de ponta a ponta para telefones tem uma disponibilidadeaproximada do orçamento de 99.94 por cento usando uma metodologia do orçamento dedisponibilidade similar a essa descrita nesta seção. Esta metodologia foi usada com sucessoem ambientes dos dados com somente leve variação, e está sendo usada atualmente comoum alvo na especificação de cabo de pacote para redes de cabo do provedor de serviços.Se nós aplicamos este valor completamente a um sistema redundante, nós podemos suporque a disponibilidade de WAN será próxima a 99.9999-percent disponível. Naturalmentemuito poucas organizações têm sistemas MACILENTOS completamente redundantes,geograficamente dispersados devido à despesa e Disponibilidade, assim que use ojulgamento apropriado em relação a esta capacidade.As falhas do link em um ambiente deLAN são menos prováveis. Contudo, os planejadores podem querer supor uma quantidadepequena de downtime devido aos conectores quebrados ou fracos. Para redes de LAN, umaestimativa conservadora é a Disponibilidade aproximadamente 99.9999-percent, ou osaproximadamente 30 segundos pelo ano.

6.

Projeto de redeO projeto de rede é um outro contribuinte principal à Disponibilidade. osprojetos NON-escaláveis, os erros de design, e o tempo de convergência de rede todosafetam negativamente a Disponibilidade.Nota: Para fins deste original, o projeto NON-escalável ou os erros de design são incluídos na seguinte seção.O projeto de rede é limitadoentão a um valor mensurável baseado na falha de software e de hardware na rede quecausa o novo roteamento de tráfego. Esse valor é normalmente chamado de "tempo deswitchover de sistema" e é um elemento dos recursos do protocolo de autocorreção nosistema.Calcule a Disponibilidade simplesmente usando os mesmos métodos para cálculosdo sistema. Contudo, isto é inválido a menos que o tempo de switchover da rede cumprirexigências do aplicativo de rede. Se o tempo de switchover é aceitável, remova-o do cálculo.Se o tempo de switchover não é aceitável, a seguir você deve adicionar-lo aos cálculos. Umexemplo pôde ser Voz sobre IP (VoIP) em um ambiente onde o tempo de switchovercalculado ou real fosse 30 segundos. Neste exemplo, os usuários pendurarão simplesmente

7.

acima o telefone e tentá-lo-ão possivelmente outra vez. Os usuários certamente verão esseperíodo de tempo como uma indisponibilidade, porém isso ainda não foi estimado naprovisão de disponibilidade.Calcule a indisponibilidade devido ao tempo de switchover desistema olhando a disponibilidade de software e hardware teórica ao longo dos caminhosredundantes, porque o switchover ocorrerá nesta área. Você deve saber o número dedispositivos que podem falhar e causar switchover no caminho redundante, o MTBF dessesdispositivos e o tempo de switchover. Um exemplo simples seria um MTBF de 35,433 horaspor cada um de dois dispositivos idênticos redundantes e um tempo de switchover de 30segundos. Dividindo 35,433 por 8766 (horas pelo ano calculado a média para incluir anos depulo), nós vemos que o dispositivo falhará uma vez cada quatro anos. Se nós usamos 30segundos como um tempo de switchover, nós podemos então supor que cada dispositivoexperimentará, em média, 7.5 segundos pelo ano de indisponibilidade devido ao switchover.Desde que os usuários podem atravessar um ou outro trajeto, o resultado é dobrado então a15 segundos pelo ano. Quando isto é calculado em termos dos segundos pelo ano, aquantidade de Disponibilidade devido ao switchover pode ser calculada como aDisponibilidade 99.99999785-percent neste sistema simples. Isto pode ser mais alto emoutros ambientes devido ao número de dispositivos redundantes na rede onde o switchoveré um potencial.Erro e processo do usuárioErro de usuário e problemas de disponibilidade de processo sãoas principais causas da não-disponibilidade em redes de empreendimento e de portadora.Aproximadamente 80 por cento da indisponibilidade ocorrem devido às edições tais como adetecção de erros, de falhas de alteração, e de problemas de desempenho.As organizaçõessimplesmente não desejam usar quatro vezes todas as outras indisponibilidades teóricaspara determinar o orçamento de disponibilidade, embora evidências sugiramconstantemente que esse é o caso em muitos ambientes. A próxima seção discute esteaspecto da não disponibilidade de maneira mais completa.Desde que você não podeteoricamente calcular a quantidade de indisponibilidade devido ao erro de usuário e aoprocesso, nós recomendamo-lo removemos isto removido do orçamento de disponibilidadee que as organizações se esforçam para a perfeição. A uma advertência é que asorganizações precisam de compreender o risco atual à Disponibilidade em seus própriosprocessos e níveis da experiência. Uma vez que você compreende melhor estes riscos einibidores, os planejadores de rede podem desejar fatorar em alguma quantidade deindisponibilidade devido a estas edições. O programa Cisco NSA HAS investiga essesproblemas e auxilia as organizações a compreender a indisponibilidade potencial devido aproblemas de processamento, erro do usuário ou de conhecimento especializado.

8.

Determinando o orçamento final de disponibilidadeVocê pode determinar o orçamento dedisponibilidade total multiplicando a Disponibilidade para cada um das áreas previamentedefinidas. Isto é feito tipicamente para os ambientes homogêneos onde a Conectividade ésimilar entre todos os dois pontos, tais como um ambiente de LAN modular hierárquico ouum ambiente de WAN padrão hierárquico.Neste exemplo, o orçamento de disponibilidade éfeito para um ambiente de LAN modular hierárquico. O ambiente usa geradores de backup esistemas UPS para todos os componentes de rede e controla corretamente a potência. Aorganização não usa VoIP e não o deseja fatorar no tempo de switchover do software. Asestimativas são:Disponibilidade do trajeto do hardware entre dois pontos finais = 99.99 porcento de DisponibilidadeDisponibilidade de software usando a confiabilidade de software GDcomo a referência = 99.9999 por cento de DisponibilidadeAmbiental e disponibilidade deenergia com sistemas de backup = 99.999 por cento de DisponibilidadeFalha do link noambiente de LAN = 99.9999 por cento de DisponibilidadeTempo de switchover de sistema

9.

não fatorado = 100 por cento de DisponibilidadePrevisão perfeita para erros de usuário edisponibilidade do processo = 100 por cento de disponibilidadeO orçamento dedisponibilidade final que as organizações devem se esforçar para obter é igual a 0,9999 X0,999999 X 0,999999 X 0,999999 = 0,999896 ou 99,9896 por cento de disponibilidade. Senós fatoramos na não disponibilidade potencial devido ao usuário ou ao erro de processo esupomos que a indisponibilidade é a Disponibilidade 4X devido aos fatores técnicos, nóspoderíamos supor que o orçamento de disponibilidade é 99.95 por cento.Esta análise deexemplo indica que a disponibilidade da LAN recairia em média entre 99,95 e 99,989 porcento. Esses números podem ser utilizados agora como uma meta de nível de serviço paraa organização da rede de comunicação. Um valor adicional pode ser obtido pela medição dadisponibilidade no sistema e da definição da porcentagem de indisponibilidade devido acada uma das seis áreas acima. Isto permite que a organização avalie corretamentevendedores, portadores, processos, e pessoal. O número também pode ser utilizado paradefinir expectativas dentro da empresa. Se o número é inaceitável, a seguir os recursosadicionais do orçamento para ganhar os níveis desejados.Pode ser útil para gerentes derede compreender a quantidade de tempo ocioso em toda a Disponibilidade particular donível. A quantidade de tempo ocioso nos minutos por um período de um ano, dados toda aDisponibilidade do nível, é:Minutos do tempo ocioso da máquina em um ano = 525600 -(Disponibilidade do nível X 5256)Se você usa a Disponibilidade em nível de 99.95 por cento,este dá certo para ser igual a 525600 - (99.95 x 5256), ou 262.8 minutos do tempo ocioso damáquina. Para a Disponibilidade acima da definição, isto é igual ao valor médio do tempoocioso da máquina para todas as conexões no serviço dentro da rede.

Passo 3: Crie perfis do aplicativo

Ajuda que dos perfis do aplicativo a organização de rede de comunicação compreende e defineexigências do nível de serviço de rede para aplicativos individuais. Isso ajuda a garantir que arede suporta requisitos de aplicativos individuais e serviços de rede em geral. Os perfis doaplicativo puderem igualmente servir como uma linha de base documentada para o apoio deserviço de rede quando ponto do aplicativo ou dos grupos de servidor à rede como o problema.Finalmente, os perfis do aplicativo ajudam a alinhar objetivos de serviço de rede com o aplicativoou as exigências do negócio comparando requisitos do aplicativo tais como o desempenho eDisponibilidade com os objetivos de serviço de rede realísticos ou as limitações atuais. Isto éimportante não somente para o Service Level Management, mas igualmente para o projeto derede invertido total.

Crie perfis do aplicativo quando você introduz aplicativos novos à rede. Talvez seja necessárioum acordo entre o grupo de aplicativos de TI, os grupos de administração de servidor e a rede decomunicação para ajudar a aplicar a criação do perfil de aplicativo de serviços novos e existentes.Termine perfis do aplicativo para aplicativos de negócio e aplicativos de sistema. Os aplicativosde negócio podem incluir o email, a transferência de arquivo, a navegação na web, a imagemlatente médica, ou a fabricação. Aplicativos de sistema podem incluir distribuição de software,autenticação de usuário, backup de rede e gerenciamento de rede.

Um analista de rede e um aplicativo ou o aplicativo de suporte de servidor devem criar o perfil doaplicativo. Os aplicativos novos podem exigir o uso de um analisador de protocolo e de umemulador de WAN com emulation do atraso caracterizar corretamente requisitos do aplicativo.Isto ajuda a identificar a largura de banda necessária, o atraso máximo para a usabilidade doaplicativo, e as exigências do tremor. Isto pode ser feito em um ambiente de laboratório enquantovocê tem os servidores obrigatórios. Em outros casos, como com VoIP, os requisitos de rede que

incluem o tremor, o atraso, e a largura de banda são publicados bem e os testes de laboratórionão serão precisados. Um perfil do aplicativo deve incluir os itens seguintes:

Nome do aplicativo●

Tipo de aplicativo●

Aplicativo novo?●

Importância do negócio●

Requisitos de disponibilidade●

Protocolos e portas usados●

Largura de banda calculada do usuário (kbps)●

Número e lugar dos usuários●

Exigências de transferência de arquivo (que incluem o tempo, o volume, e os valores-limite)●

Impacto da parada de rede●

Atraso, tremor, e requisitos de disponibilidade●

O objetivo do perfil de aplicativo é entender requisitos de negócios para o aplicativo, a crítica denegócio e os requisitos de rede como largura de banda, retardo e jitter. Além, a organização derede de comunicação deve compreender o impacto do tempo ocioso de rede. Em alguns casos,você precisará os reinícios do aplicativo ou do server que adicionam significativamente ao tempoocioso da máquina total do aplicativo. Quando você completa o perfil do aplicativo, você podecomparar todos os recursos de rede e ajudar a alinhar os níveis de serviço de rede com osrequisitos de negócios e de aplicativos.

Passo 4: Defina a Disponibilidade e as padronizações de desempenho

A Disponibilidade e as padronizações de desempenho ajustaram as expectativas do serviço paraa organização. Estes podem ser definidos para áreas diferentes da rede ou dos aplicativosespecíficos. O desempenho pode igualmente ser definido em termos do retardo round trip, dotremor, do throughput máximo, dos comprometimentos de largura de banda, e da escalabilidadetotal. Além do que o ajuste das expectativas do serviço, a organização deve igualmente ciao paradefinir cada um dos padrões do serviço de modo que o usuário e os grupos TI que trabalham comtrabalhos em rede compreendam inteiramente o padrão do serviço e como se relaciona a suasexigências do aplicativo ou da administração de servidor. Usuário e grupos de TI também devementender como o padrão de serviço deve ser medido.

Resultados a partir de passos de definição de nível de serviço prévio auxiliarão a criar o padrão.Neste momento, a organização de rede de comunicação deve ter um entendimento claro dosriscos e das limitações atuais na rede, uma compreensão do comportamento de aplicativo, e umadisponibilidade teórica da análise ou a linha da base de disponibilidade.

Defina o geográfico ou as áreas de aplicativo onde os padrões do serviço serãoaplicados.Isto pode incluir áreas como LAN de campus, WAN doméstica, extranet ouconectividade de parceiro. Em alguns casos, a organização pode ter meta de nível deserviço diferentes dentro de uma área. Isso é comum para organizações provedoras deserviço ou empreendimentos. Nesses casos, não seria raro criar os padrões diferentes donível de serviço baseados em exigências do serviço individual. Eles podem ser classificadoscomo padrões de serviço ouro, prata e bronze dentro de uma área geográfica ou deserviços.

1.

Defina os parâmetros do padrão do serviço.A Disponibilidade e o retardo round trip são amaioria de padrões do serviço de rede comum. O throughput máximo, o compromisso delargura de banda mínima, o tremor, as taxas de erro aceitáveis, e as capacidades da

2.

escalabilidade podem igualmente ser incluídos como necessários. Seja cuidadoso ao revero parâmetro de serviço para métodos de medida. Independentemente de o parâmetro seguirpara um SLA, a organização deve pensar sobre como o parâmetro de serviço poderá sermedido ou justificado quando ocorrerem problemas ou desacordos de serviço.

Depois que você define as áreas de serviço e os parâmetros de serviço, use a informação dasetapas precedentes para construir uma matriz de padrões do serviço. A organização igualmenteprecisará de definir as áreas que podem ser desconcertantes aos usuários e aos grupos TI. Porexemplo, o tempo máximo de resposta será muito diferente para um ping round trip do que parabater a tecla ENTER em uma posição remota para um aplicativo específico. A tabela a seguirmostra os destinos de desempenho dentro do Estados Unidos.

Áreaderede

Disponibilidadedo alvo

Métododemedida

Alvomédiodotempoderesposta derede

Tempo derespostamáximoaceitado

Método damedida detempo deresposta

LAN 99.99%

Minutosdeusuárioimpactado

Sob aSenhora 5

10 msRespostade pinground trip

WAN 99.99%


Abaixode 100ms(pingroundtrip)


WANcrítico eextranet

99.99%


Abaixode 100ms(pingroundtrip)


Passo 5: Defina o serviço de rede

Esta é a última etapa para o Gerenciamento do nível de serviço básico; define o reativo e osprocessos pró-ativo e os recursos de gerenciamento de rede que você executa para conseguirmeta de nível de serviço. O documento final é chamado tipicamente um plano de suporte dasoperações. A maioria de planos da sustentação do aplicativo incluem somente exigências desuporte reagente. Nos ambientes de alta disponibilidade, a organização deve igualmenteconsiderar os processos do gerenciamento pró-ativo que estarão usados para isolar e resolverquestões de rede antes que os atendimentos do serviço de usuário estejam iniciados. Acima detudo, o documento final deve:

Descreva o reativo e o processo pró-ativo usados para conseguir o meta de nível de serviço●

Como o processo do serviço será controlado●

Como o processo do objetivo de serviço e do serviço será medido.●

Esta seção contém exemplos para que definições e as definições de serviço pró-ativo do serviçoreagente considerem para muitos o provedor de serviços e as organizações de empreendimento.O objetivo de desenvolver as definições do nível de serviço é criar um serviço que irá satisfazeras metas de disponibilidade e desempenho. Para realizar isto, a organização deve construir oserviço com as limitações, o orçamento de disponibilidade, e os perfis do aplicativo técnicosatuais na mente. Especificamente, a organização deve definir e construir um serviço queconsistentemente e rapidamente identifique e resolva problemas dentro das épocas atribuídaspelo modelo de disponibilidade. A organização deve igualmente definir um serviço que possarapidamente identificar e resolver as edições do serviço potencial que impactarão aDisponibilidade e o desempenho se ignoradas.

Você não conseguirá o nível de serviço desejado durante a noite. Deficiências, como poucaexperiência, limitações do processo atual ou nível inadequado dos profissionais, podem impedirque a organização alcance seus padrões desejados ou atinja suas metas, mesmo após realizaros passos de análise de serviço anteriores. Não há nenhum método preciso para combinarexatamente o nível de serviço requerido aos objetivos desejados. Para acomodar para isto, aorganização deve medir os padrões do serviço e medir os parâmetros de serviço usados paraapoiar os padrões do serviço. Quando a organização não está encontrando objetivos de serviço,deve então olhar para prestar serviços de manutenção ao medidor para ajudar a compreender aedição. Em muitos casos, os aumentos de realização do orçamento podem ser feitos paramelhorar serviços de assistência e fazer melhorias necessárias conseguir os objetivos do serviçodesejado. Ao longo do tempo a organização pode fazer diversos ajustes, ao objetivo de serviçoou à definição de serviço, a fim alinhar serviços de rede e exigências do negócio.

Por exemplo, uma organização pôde conseguir 99 por cento de Disponibilidade quando o objetivoera muito mais alto em 99.9 por cento de Disponibilidade. Ao olhar o medidor do serviço esuporte, os representantes da organização encontraram que a substituição de hardware tomavaaproximadamente 24 horas, muito mais por muito tempo do que a avaliação original porque aorganização tinha incluído no orçamento somente quatro. Além, a organização encontrou que aspotencialidades de gerenciamento pró-ativo estavam ignoradas e os dispositivos da rederedundante não estavam reparados para baixo. Igualmente encontraram que não tiveram ospessoais para fazer melhorias. Em consequência, após a consideração que abaixa os objetivosde serviço atuais, a organização incluída no orçamento para recursos adicionais precisou deconseguir o nível de serviço desejado.

As definições de serviço devem incluir definições e definições proativa do suporte reagente. Asdefinições reativas definem como a organização reagirá aos problemas depois que foramidentificadas da reclamação de usuário ou dos recursos de gerenciamento de rede. As definiçõesproativa descrevem como a organização identificará e resolverá os problemas da rede potencial,incluindo o reparo de componentes de rede, detecção de erros, e limites de capacidade eelevações “à espera” quebrados. As seções a seguir fornecem exemplos de definições de nívelde serviço reativo e proativo.

Reativar definições do nível de serviço

As seguintes áreas de nível de serviços são tipicamente medidas usando as estatísticas de umbanco de dados de help desk e auditorias periódicas. Esta tabela mostra o exemplo daseveridade de problema para uma organização. Observe que a carta não inclui como segurarpedidos para o serviço novo, que pode ser segurado por um SLA ou por uma definição do perfildo aplicativo e por uma análise What-if adicionais do desempenho. Tipicamente a severidade 5pode ser um pedido para o serviço novo se segurado através do mesmo processo do apoio.

Severidade 1 Severidade 2 Severidade 3 Severid

ade 4SiteWANcríticoseveradousuárioou dosegmento deservidordoimpactodenegóciosLANparabaixoparabaixo

Impacto de negóciosalto com a perda ou adegradação, campusLAN no lugar daalternativa possívelpara baixo; 5-99usuários afetaram oimpacto nodesempenho críticoMACILENTOinternacional do localdo local do WANdoméstico para baixopara baixo

Algumafuncionalidade de redeespecífica éperdida oudegradada,como aRedundânciaimpactadadesempenhodo campusLAN LAN daperda deredundânciaperdida

Umapergunta ouumafalhafuncional quenãotenhamnenhumimpactodenegócios para aorganização

Quando a severidade de problema foi definida, defina ou investigue o processo do apoio paracriar definições da resposta do serviço. Geralmente, as definições da resposta do serviço exigemuma estrutura do suporte alinhado acoplada com um sistema de suporte de software do help deskpara seguir problemas através das documentações de problema. O medidor deve igualmenteestar disponível no tempo de resposta e no tempo de resolução para cada prioridade, no númerode atendimentos pela prioridade, e na qualidade da resposta/definição. Para definir o processo desuporte, é útil definir as metas de cada camada de suporte na organização e suas funções eresponsabilidades. Isto ajuda a organização a compreender requisitos de recurso e níveis daexperiência para cada nível de suporte. As tabelas a seguir fornecem um exemplo de umaorganização de suporte alinhado com diretrizes de resolução de problemas.

Níveldesuporte

Responsabilidade Metas

Apoiodasérie1

As chamadas de suporte a tempo completoda resposta do apoio do help desk, asdocumentações de problema do lugar,trabalho no problema até 15 minutos,bilhete do original e escalam para apropriaro apoio da série 2

Definição de40%daschamadasrecebidas

Apoiodasérie

Enfileire a monitoração, Gerenciamento deredes, documentações de problema dolugar da monitoração da estação paraatendimentos da tomada do implementardos problemas identificados do software da

Definição de100%dosatendi

2série 1, vendedor, e o agravamento dasérie 3 supõe a posse do atendimento até adefinição

mentosa níveldasérie 2

Apoiodasérie3

Deve fornecer o apoio imediato à série 2para todos os problemas da prioridade 1concordam ajudar com todos os problemasnão-resolvidos pela série 2 dentro doperíodo da definição SLA

Nenhumapossediretadoproblema

A próxima etapa é criar a matriz para a definição de serviço da definição da resposta do serviço edo serviço. Isto define metas para o modo como os problemas são solucionados rapidamente,inclusive substituição de hardware. É importante ajustar objetivos nesta área porque o tempo deresposta e o tempo de recuperação do serviço impactam diretamente a disponibilidade da rede. Otempo de definição de problema deve igualmente ser alinhado com o orçamento dedisponibilidade. Se um grande número problemas da severidade elevada não são esclarecidos noorçamento de disponibilidade, a organização pode então trabalhar para compreender a fontedestes problemas e de um remédio potencial. Veja a seguinte tabela:

Severidadedoproblema

Resposta do helpdesk

Resposta dacamada 2

Nível 2nolocal

Substituiçãodehardware

Resolução deproblemas

1

Escalada imediataà série 2, gerentede operações derede

5minutos

2horas

2horas

4horas

2

Escalada imediataà série 2, gerentede operações derede

5minutos

4horas

4horas

8horas

3 15 minutos 2horas

12horas

24horas

36horas

4 15 minutos 4horas

3dias 3 dias dias 6

Além do que a definição da resposta do serviço e do serviço, construa uma matriz para oagravamento. As ajudas da matriz de escalada asseguram-se de que os recursos disponíveisestejam centrados sobre os problemas que afetam severamente o serviço. Geralmente, quandoos analistas são centrados sobre problemas da fixação, centram-se raramente sobre trazerrecursos adicionais dentro no problema. Definição quando os recursos adicionais deverem serajudas notificadas para promover a conscientização do problema no Gerenciamento e puderemgeralmente ajudar a conduzir a dinâmico futuro ou às medidas preventivas. Veja a seguintetabela:

Tempo

Severidade1 Severidade 2

Severidade

Severidade

transcorrido 3 4

5minutos

Gerente deoperaçõesde rede,apoio dasérie 3,diretor derede decomunicação

1 hora

Atualizaçãoparagerenciadordeoperaçõesde rede,suporte denível 3,diretor derede decomunicação

Atualização paragerenciador deoperações de rede,suporte de nível 3,diretor de rede decomunicação

2horas

Escale aVP,atualizaçãoao diretor,gerenciadordeoperações

4horas

Notificaçãodo CEOsobre arazãoprincipal deconsultasnãoresolvidaspara o VP,o diretor, ogerente deoperações,o suportede nível 3

Escale a VP,atualização aodiretor, gerenciadorde operações

24horas

Gerente deoperaçõesderede

dias 5 Geren

te deoperaçõesderede

Até agora, as definições niveladas de serviço focalizaram em como a organização de suporte dasoperações reage aos problemas depois que são identificadas. As empresas de operações têmcriado, há anos, planos de suporte operacionais com informações similares às acima. Contudo, oque falta nesses casos é como a organização identificará problemas e que problemasidentificarão. Umas organizações de rede mais sofisticadas tentaram resolver esta ediçãosimplesmente criando objetivos para a porcentagem dos problemas que são identificadosdinamicamente, ao contrário dos problemas identificados reactivamente por relatórios doproblema ou por queixa do usuário.

A tabela seguinte mostra como uma organização pode desejar medir capacidades do suporte pró-ativo e macacão do suporte pró-ativo.

Áreaderede

Razão de identificaçãodo problema proativo

Relação reativa daidentificação doproblema

LAN 80% 20%WAN 80% 20%

Este é um bom começo em definir mais definições do suporte pró-ativo porque é simples erazoavelmente fácil medir, especialmente se as ferramentas proativa gerenciem automaticamentedocumentações de problema. Isto igualmente ajuda as ferramentas de gerenciamento da rede dofoco/informação em problemas de resolução dinamicamente um pouco do que ajudando com acausa de raiz. Contudo, a questão principal com este método é que não define exigências desuporte pró-ativo. Isto geralmente cria intervalos nas capacidades de gerenciamento de suporteproativo e resulta em risco adicional à disponibilidade.

Definições niveladas de serviço proativo

Uma metodologia mais detalhada para criar definições niveladas de serviço inclui mais detalheem como a rede é monitorada e em como a organização de operações reage aos pontos iniciaisda estação de gerenciamento da rede definida (nanômetros) em um 7 x 24 bases. Isto podeparecer como umas tarefas impossíveis dadas o número completo de variáveis do ManagementInformation Base (MIB) e da quantidade de informação de gerenciamento de rede disponível queé pertinente às saúdes de rede. Podia igualmente ser extremamente caro e repleto de recursos.Infelizmente, estas objeções impedem que muitos executem uma definição de serviço pró-ativoque, por natureza, deva ser simples, razoavelmente fácil seguir, e aplicável somente à grandesDisponibilidade ou riscos de desempenho na rede. Se uma organização considera então o valorem definições de serviço pró-ativo básicas, mais variáveis podem ser adicionadas ao longo dotempo sem impacto significativo, enquanto você executa uma aproximação posta em fase.

Inclua a primeira área das definições de serviço pró-ativo em todos os planos de suporte dasoperações. Da definição de serviço os estados simplesmente como o grupo de operaçõesdinamicamente identificará e responderá à rede ou ligará abaixo das condições em áreasdiferentes da rede. Sem esta definição (ou suporte de gerenciamento), a organização podeesperar suporte variável, expectativas não realísticas de usuários e, enfim, uma disponibilidade

mais baixa de rede.

A tabela a seguir mostra como uma organização pôde criar uma definição de serviço paracondições da relação/dispositivo-para baixo. O exemplo mostra uma organização corporativa quepode ter diferentes requisitos de notificação e resposta com base na hora do dia e área da rede.

Dispositivoderedeourelaçãoparabaixo

Método dedetecção

notificação 8 5 x

Notificação 7 x24

definição8 5 x

7 x 24definições

LANcentral

DispositivodeSNMP eapuraçãodelink,armadilhas

O NOCcria adocumentaçãodeproblema, biperdo LAN-deverdapágina

O pagerdeobrigação dapáginaautomáticaLAN,pessoadodeverLANcria adocumentaçãodeproblema para afila doLANcentral

AnalistaLANatribuídodentro de15minutospeloNOC,reparoconformeadefiniçãodarespostadoserviço

Prioridades3 e dainvestigação eresoluçãoimediatasdasprioridades1 e 2 fila 4para aresoluçãopela manhã

WANdoméstico


O NOCcria adocumentaçãodeproblema, pagerdeobrigação deWAN depágina

O pagerdeobrigaçãoMACILENTO dapáginaautomática,pessoaMACILENTO dodevercria adocumentação

AnalistaMACILENTOatribuídodentro de15minutospeloNOC,reparoconformeadefiniçãodarespostado

Prioridades3 e dainvestigação eresoluçãoimediatasdasprioridades1 e 2 fila 4para aresoluçãopela manhã

deproblema para afilaMACILENTO

serviço

Extranet


O NOCcria adocumentaçãodeproblema, pagerdeobrigação doparceirodepágina

O pagerdeobrigação dosócio dapáginaautomática,pessoadodeverdo sóciocria adocumentaçãodeproblema para afila dosócio

Analistadeparceirodesignado em 15minutospeloNOC;faça oreparo deacordocom adefiniçãoderespostadeserviço

Prioridades1 einvestigação eresoluçãoimediatas2; Fila deprioridades3 e 4 pararesoluçãomatinal

As definições niveladas de serviço pró-ativo restantes podem ser divididas em duas categorias:erros de rede e capacidade/problemas de desempenho. Somente uma porcentagem pequena dasorganizações de rede tem definições niveladas de serviço nestas áreas. Em consequência, estasedições são ignoradas ou seguradas esporadicamente. Isso pode ser adequado para algunsambientes de rede, mas ambientes de alta disponibilidade geralmente exigirão de gerenciamentoproativo de serviços.

As organizações de rede de comunicação tendem a esforçar-se por vários motivos com asdefinições de serviço pró-ativo. Isso ocorre principalmente porque não executaram uma análisede requisitos para definições de serviço proativo com base nos riscos de disponibilidade,orçamento de disponibilidade e problemas de aplicativo. Isto conduz às exigências obscuras paradefinições de serviço pró-ativo e benefícios obscuros, especialmente porque os recursosadicionais podem ser precisados.

A segunda razão envolve equilibrar a quantidade de gerenciamento pró-ativo que pode ser feitacom recursos existentes ou novo-definidos. Gerencia somente aqueles alertas que têm o impactopotencial sério à Disponibilidade ou ao desempenho. Você deve igualmente considerar oGerenciamento ou os processos da correlação de evento para assegurar-se de que os ticket deproblema pró-ativo múltiplos não estejam gerados para o mesmo problema. O último motivo como qual as organizações podem implicar é que criar um novo conjunto de alertas muitas vezespode gerar uma inundação inicial de mensagens que anteriormente passaram despercebidas. Ogrupo de operações deve ser preparado para esta inundação inicial das edições e de recursos acurto prazo adicionais para fixar ou resolver estas circunstâncias previamente indetectados.

A primeira categoria de definições de nível de serviço pró-ativo é erros de rede. Os erros de redepodem mais ser subdivididos nos erros de sistema que incluem erros de software ou erros de

hardware, erros de protocolo, erros de controle dos media, erros de precisão, e avisosambientais. Desenvolver uma definição nivelada de serviço começa com uma compreensão geralde como estas condições de problema serão detectadas, de que os olharão, e o que acontecerãoquando ocorrem. Adicionar mensagens ou edições específicas à definição nivelada de serviço sea necessidade elevara. Também pode ser necessário um trabalho adicional nas áreas a seguirpara assegurar o sucesso:

Responsabilidades de suporte de nível 1, nível 2 e nível 3●

Equilibrando a prioridade da informação de gerenciamento de rede com a quantidade detrabalho pró-ativo que o grupo de operações pode eficazmente segurar

●

Requisitos de treinamento para garantir que a equipe de suporte técnico possa tratar demodo eficaz os alertas definidos

●

Metodologias da correlação de evento para assegurar-se de que os ticket de problemamúltiplo não estejam gerados para o mesmo problema de causa de raiz

●

Documentação em mensagens ou em alertas específicos que ajuda com identificação deevento a nível de suporte da série 1

●

A tabela a seguir mostra uma definição de nível do exemplo de serviço para os erros de rede quefornecem um entendimento claro de quem são responsável para alertas de erro de rede proativa,de como o problema serão identificados, e o que acontecerá quando o problema ocorre. Aorganização pode ainda precisar esforços adicionais como definidos acima para assegurar osucesso

s.

Categoria de erro

Método dedetecção Limite Ação realizada

Erros desoftware(impactosforçadospelosoftware)

Revisão diáriadosmensagensdo syslogusando ovisor deSYSLOG feitopelo apoio dasérie 2

Algumaocorrênciapara aprioridade 0,1, e 2 sobre100ocorrênciasdo nível 3 ouacima

Revise oproblema, criebilhete deproblema eenvie caso umanovaocorrência ouproblema exijaatenção

Erros dehardware(impactosforçadospelohardware)


Algumaocorrênciapara aprioridade 0,1, e 2 sobre100ocorrênciasdo nível 3 ouacima


Erros deprotocolo(protocolos de IPRoutingsomente)

Revisão diáriadosmensagensdo syslogusando ovisor deSYSLOG feito

Dezmensagenspelo dia dasprioridades 0,1, e 2 sobre100ocorrências

Revise oproblema, criebilhete deproblema eenvie caso umanovaocorrência ou

pelo apoio dasérie 2

do nível 3 ouacima

problema exijaatenção

Erros decontroledosmedia(FDDI,POS, eFastEthernetsomente)


Dezmensagenspelo dia dasprioridades 0,1, e 2 sobre100ocorrênciasdo nível 3 ouacima


Mensagensambientais(potênciae temp)


Algumamensagem

Crie adocumentaçãode problema ea expediçãopara problemasnovos

Erros deprecisão(erros deentradadarelação)

Polling snmpnos eventosde limiar dosintervalos de5-minutorecebidospelo NOC

Erro do errode entradaou de saídaum em algumintervalo de5-minuto emalgumarelação

Crie adocumentaçãode problemapara problemase a expediçãonovos ao apoioda série 2

As outras definições de nível da categoria de serviço pró ativo aplicam-se ao desempenho e àcapacidade. O desempenho real e o gerenciamento de capacidade incluem gerenciamento deexceções, avaliação comparativa e tendência e análise what if. A definição nivelada de serviçodefine simplesmente pontos iniciais da exceção do desempenho e da capacidade e os pontosiniciais médios que iniciarão a investigação ou a elevação. Estes limiares podem, então, seraplicados aos três processos de gerenciamento de desempenho e de capacidade de algumamaneira.

As definições de nível da capacidade e do serviço de desempenho podem ser divididas emdiversas categorias: links de rede, dispositivos de rede, desempenho de ponta a ponta, edesempenho do aplicativo. Desenvolver definições niveladas de serviço nestas áreas exige oconhecimento técnico detalhado em relação aos aspectos específicos da capacidade dedispositivo, da capacidade de mídia, das características de QoS, e dos requisitos do aplicativo.Por este motivo, nós recomendamos que os arquitetos de rede desenvolvem o desempenho edefinições niveladas de serviço capacidade-relacionadas com entrada do vendedor.

Como erros de rede, desenvolver uma definição nivelada de serviço para a capacidade e odesempenho começa com uma compreensão geral de como estas condições de problema serãodetectadas, de que os olharão, e o que acontecerão quando ocorrem. Você pode adicionardefinições de eventos específicos para a definição de nível de serviço, caso haja necessidade.Também pode ser necessário um trabalho adicional nas áreas a seguir para assegurar o sucesso:

Um entendimento claro de exigências de desempenho do aplicativo●

A investigação técnica detalhada nos valores de limiar que fazem o sentido para aorganização baseou em exigências do negócio e em custos total

●

Requisitos de upgrade orçamentais do ciclo e do out-of-cycle●

Responsabilidades de suporte de nível 1, nível 2 e nível 3●

A prioridade e o criticidade da informação de gerenciamento de rede equilibraram com aquantidade de trabalho pró-ativo que o grupo de operações pode eficazmente segurar

●

Requisitos de treinamento para assegurar-se de que o pessoal de suporte compreenda asmensagens ou os alertas e possa eficazmente tratar a condição definida

●

Metodologias ou processos da correlação de evento para assegurar-se de que os ticket deproblema múltiplo não estejam gerados para o mesmo problema de causa de raiz

●

Documentação em mensagens ou em alertas específicos que ajuda com identificação deevento a nível de suporte da série 1

●

A tabela a seguir mostra uma definição de nível do exemplo de serviço para a utilização do enlaceque fornece um entendimento claro de quem são responsável para alertas de erro de redeproativa, de como o problema serão identificados, e o que acontecerá quando o problema ocorre.Conforme definido anteriormente, podem ser necessários esforços adicionais da organizaçãopara garantir o sucesso.

Áreaderede/media

Método dedetecção Limite Ação realizada

Backboneelinksdedistribuição docampusLAN

Polling snmpem armadilhasda exceçãodos intervalosRMON de 5-minuto nonúcleo e noslinks dedistribuição

utilização de50% nautilizaçãodosintervalos90% de 5-minutoatravés daarmadilhada exceção

Notificação de E-mail ao grupo doemail dodesempenho aliáspara avaliar aelevação dorequisito de QoSou do plano paraquestões repetidas

RelaçõesdoWANdoméstico

Eleição SNMPem intervalosde 5 minutos

utilização de75% emintervalos de5-minuto

Notificação de E-mail ao grupo doemail dodesempenho aliáspara avaliar aelevação dorequisito de QoSou do plano paraquestões repetidas

RelaçõesdeWANdoextranet

Eleição SNMPem intervalosde 5 minutos

utilização de60% emintervalos de5-minuto

Notificação de E-mail ao grupo doemail dodesempenho aliáspara avaliar aelevação dorequisito de QoSou do plano para

questões repetidas

A tabela a seguir define definições niveladas de serviço para a capacidade de dispositivo e oslimiares de desempenho. Assegure-se de que você crie os pontos iniciais que são significativos eúteis em impedir problemas de rede ou problemas de disponibilidade. Essa é uma área muitoimportante pois problemas de recurso do plano de controle do dispositivo não verificados podemter um impacto grave sobre a rede.

Cisco7500

CPU,memória,bufferes

Pollingsnmpnanotificaçãormondosintervalos -5-minutepara oCPU

CPU em 75%durante intervalosde 5-minuto, 99%através damemória danotificação rmonem 50% durantebufferes dosintervalos de 5-minuto nautilização de 99%

Anotificaçãode E-mail aogrupo doemail dodesempenho e dacapacidadealiás pararesolveredições ouelevaçãoRMON CPUdo plano em99%,documentação deproblema dolugar e série2 da páginaapoia obiper

Cisco2600

CPU,memória

EleiçãoSNMPemintervalos de 5minutos

CPU em 75%durante a memóriados intervalos de5-minuto em 50%durante intervalosde 5-minuto

Notificaçãode E-mail aogrupo doemail dodesempenho e dacapacidadealiás pararesolveredições ouelevação doplano

Catalyst 5000

Utilizaçãodebackplane,memória


Placa traseira namemória dautilização de 50%na utilização de75%

Notificaçãode E-mail aogrupo doemail dodesempenho e dacapacidadealiás pararesolver

edições ouelevação doplano

SwitchATMdeLightStream®1010

CPU,memória


CPU na memóriada utilização de65% na utilizaçãode 50%

Notificaçãode E-mail aogrupo doemail dodesempenho e dacapacidadealiás pararesolveredições ouelevação doplano

A próxima tabela estabelece as definições de nível de serviço para desempenho e capacidade deponta a ponta. Estes pontos iniciais geralmente são baseados em requisitos do aplicativo maspodem igualmente ser usados para indicar algum desempenho ou problema de potencialidade dotipo de rede. A maioria de organizações com definições niveladas de serviço para o desempenhocriam somente um punhado de definições do desempenho porque o desempenho de medição decada ponto na rede a cada outro ponto exige recursos significativos e cria uma quantidadeelevada de carga adicional de rede. Esses problemas de desempenho de ponta a ponta tambémpodem ser obtidos em limiares de recurso de dispositivo ou enlace. Recomendamos definiçõesgerais por área geográfica. Algumas locais ou relações críticas podem ser adicionados casonecessário.

Áreaderede/media

Método demedida Limite Ação realizada

CampusLAN

Nenhunsnenhumproblemaesperaram difícilmedir o infra-estruturo de LANinteiro

Tempo deresposta deround trip de10milissegundos ou menostodas asvezes

Notificação deE-mail ao grupodo email dodesempenho eda capacidadealiás pararesolver aelevação daedição ou doplano

RelaçõesdoWANdoméstico

Medida atual deSF ao NY e deSF a Chicagoque usasomente o ecoICMP do InternetPerformanceMonitor (IPM)

tempo derespostaround trip 75-millisecondcalculado amédiadurante umperíodo de 5-minuto

Notificação deE-mail ao grupodo email dodesempenhoaliás paraavaliar aelevação dorequisito deQoS ou doplano para

questõesrepetidas

SanFranciscoatéTóquio

Medida atual deSan Francisco aBruxelas usandoo IPM e o ecoICMP

tempo derespostaround trip250-millisecondcalculado amédiadurante umperíodo de 5-minuto

Notificação deE-mail ao grupodo email dodesempenhoaliás paraavaliar aelevação dorequisito deQoS ou doplano paraquestõesrepetidas

SanFranciscoaBruxelas

Medida atual deSan Francisco aBruxelas usandoo IPM e o ecoICMP

tempo derespostaround trip175-millisecondcalculado amédiadurante umperíodo de 5-minuto

Notificação deE-mail ao grupodo email dodesempenhoaliás paraavaliar aelevação dorequisito deQoS ou doplano paraquestõesrepetidas

A área final das definições de nível de serviço é para desempenho do aplicativo. As definiçõesniveladas de serviço do desempenho do aplicativo são criadas normalmente pelo aplicativo oupelo grupo de administração de servidor porque o desempenho e a capacidade dos server elemesmo são provavelmente o fator o maior no desempenho do aplicativo. As organizações derede de comunicação podem realizar o benefício tremendo criando definições niveladas deserviço para o desempenho do aplicativo de rede porque:

as definições niveladas de serviço e a medida podem ajudar a eliminar conflitos entre grupos.●

as definições niveladas de serviço para aplicativos individuais são importantes se QoS estáconfigurado para os aplicativos chaves e o outro tráfego está considerado opcional.

●

Se você escolhe criar e medir o desempenho do aplicativo, é provavelmente o melhor se vocênão mede o desempenho ao server próprio. Então, isso ajuda a distinguir entre problemas derede e problemas de aplicativo ou servidor. Use pontas de prova ou a Disponibilidade do sistemado agente de software que são executado no Roteadores de Cisco e Cisco IPM que controla afrequência do tipo de pacote e da medida.

A tabela a seguir mostra uma definição de nível de serviço simples para desempenho doaplicativo.

Aplicativo Método demedida Limite Ação realizada

Porta TCP1529Bruxelas

Bruxelas a SanFranciscousando o

tempo derespostaround trip

Notificação deE-mail aogrupo do email

doaplicativodeplanejamento derecursoscorporativos (ERP)a SF

gateway demedição deBruxelas dodesempenhoround trip daporta 1529 IPMao gateway deSFO 2

175-millisecondcalculadoa médiaduranteumperíodo de5-minuto

dodesempenhoaliás paraavaliar aelevação doproblema ou doplano paraquestõesrepetidas

Tóquio daporta TCP1529 doaplicativoERP a SF

Bruxelas a SanFranciscousando ogateway demedição deBruxelas dodesempenhoround trip daporta 1529 IPMao gateway deSFO 2

tempo derespostaround trip200-millisecondcalculadoa médiaduranteumperíodo de5-minuto

Notificação deE-mail aogrupo do emaildodesempenhoaliás paraavaliar aelevação doproblema ou doplano paraquestõesrepetidas

Porta TCP1702Sydneydoaplicativodesuportede clientea SF

Sydney a SanFranciscousando ogateway demedição deSydney dodesempenhoround trip daporta 1702 IPMao gateway deSFO 1

tempo derespostaround trip250-millisecondcalculadoa médiaduranteumperíodo de5-minuto

Notificação deE-mail aogrupo do emaildodesempenhoaliás paraavaliar aelevação doproblema ou doplano paraquestõesrepetidas

Passo 6: Recolha o medidor e monitore-o

as definições niveladas de serviço são sós sem valor a menos que a organização recolher omedidor e monitorar o sucesso. Em criar uma definição nivelada de serviço crítica, defina como onível de serviço será medido e relatado. Medindo o nível de serviço determina se a organizaçãoestá encontrando objetivos e igualmente identifica a causa de raiz da Disponibilidade ou dosproblemas de desempenho. Igualmente considere o objetivo ao escolher um método medir adefinição nivelada de serviço. Veja criando e mantendo SLA para mais informação.

Os níveis de serviço de monitoramento envolvem conduzir uma reunião da revisão periódica,normalmente cada mês, para discutir o serviço periódico. Discuta todo o medidor e se seconformam aos objetivos. Se não se conformam, determine a causa de raiz do problema eexecute melhorias. Você deve igualmente cobrir iniciativas atuais e progredir em melhorarsituações individuais.

Criando e mantendo SLA

as definições niveladas de serviço são um montagem de bloco excelente que ajudam a criar umQoS consistente durante todo a organização e ao ajudar a melhorar a Disponibilidade. A próximaetapa é os SLA, que são uma melhoria porque alinham objetivos de negócio e requisitos de custodiretamente para prestar serviços de manutenção à qualidade. O SLA bem-construído serveentão como um modelo para a eficiência, a qualidade, e a sinergia entre a comunidade de usuárioe o grupo de suporte mantendo processos claros e os procedimentos para questões de rede ouproblemas.

Os SLA fornecem diversos benefícios:

Os SLAs estabelecem responsabilidade em dois sentidos para serviço, o que significa que osusuários e os grupos de aplicativo também são responsáveis pelo serviço da rede. Se nãoajudam a criar um SLA para um serviço específico e a comunicar o impacto de negócios como grupo de rede, a seguir podem realmente ser responsávéis para o problema.

●

Os SLA ajudam a determinar os ferramenta padrões e os recursos necessários cumprirexigências do negócio. Decidindo quantos povos e que ferramentas se usar sem SLA éfrequentemente uma suposição orçamental. O serviço pode sobre-ser projetado, que conduzà sobre-despesa, ou sob-ser projetado, que conduz aos objetivos de negócio não satisfeitas.As ajudas de ajustamento SLA conseguem que nível ótimo equilibrado.

●

O SLA documentado cria um veículo mais claro para ajustar expectativas do nível de serviço.●

Para o desenvolvimento de SLAs após a criação de definições de nível de serviço,recomendamos os seguintes passos: Para o desenvolvimento de SLAs após a criação dedefinições de nível de serviço, recomendamos os seguintes passos:

7. Encontre as condições prévias para SLA.

8. Determine os partidos envolvidos no SLA.

9. Determine elementos de serviço.

10. Compreenda meta de necessidade dos negócios do cliente

11. Defina o SLA exigido para cada grupo.

12. Escolha o formato do SLA

13. Desenvolva grupos de trabalho de SLA

14. Realize reuniões de grupo de trabalho e esboce o SLA.

15. Negocie o SLA.

16. Meça e monitore a conformidade SLA.

Etapa 7: Condições prévias da reunião para SLA

Os peritos no desenvolvimento TI SLA identificaram três condições prévias a um SLA bemsucedido. Infelizmente, organizações que não alcançam esses objetivos podem esperarproblemas com o processo SLA e devem considerar os possíveis problemas envolvidos com oprocesso SLA. Não executa SLA não é prejudicial se a organização de rede de comunicaçãopode construir as definições niveladas de serviço que cumprem exigências do negócio gerais. Os

seguintes são condições prévias para o processo SLA:

Seu negócio deve ter uma cultura orientado ao serviço.A organização deve colocar asnecessidades dos clientes em primeiro lugar. É preciso um comprometimento completo como serviço, resultando em um entendimento total das necessidades e percepções do cliente.Pesquisas de satisfação de cliente da conduta e iniciativas adaptadas ás necessidades docliente do serviço.Um outro indicador do serviço pode ser que a satisfação do serviço ou doapoio de estados da organização como um meta corporativa. Isto não é raro, pois asorganizações de TI estão fortemente ligadas ao êxito geral da empresa.A cultura do serviço éimportante pois o processo SLA é fundamentalmente sobre como fazer melhorias com basenas necessidades do cliente e nos requisitos comerciais. Se as organizações não fizeramesta no passado, encontrarão o processo SLA difícil.

●

O cliente/iniciativas de negócios deve conduzir todas as atividades TI.A visão ou asinstruções da missão da empresa devem ser alinhadas com o cliente e as iniciativas denegócios, que conduzem então todas as atividades TI, incluindo SLA. Uma rede é postademasiado frequentemente no lugar para encontrar um objetivo particular, contudo o grupode rede de comunicação perde de vista esses objetivo e exigências do negóciosubsequentes. Nesses casos, um orçamento do grupo é atribuído à rede, que pode reagir demodo exagerado às necessidades atuais ou subestima brutamente a exigência, tendo porresultado a falha.Quando as iniciativas de clientes/empresas são alinhadas a iniciativas de TI,a organização da rede pode se ajustar mais facilmente às implementações de novosaplicativos, novos serviços e outros requisitos comerciais. A relação e o foco em visão geralcomum no atendimento de metas corporativas estão presentes e todos os grupos funcionamcomo uma equipe.

●

Você deve comprometer ao processo SLA e ao contrato.O primeiro lá deve sercomprometimento para aprender o processo SLA desenvolver acordos eficazes. Segundo,você deve respeitar os requisitos de serviço do contrato. Não espere criar SLA poderosossem a entrada e o comprometimento significativos de todos os indivíduos envolvidos. Estecomprometimento deve igualmente vir de Gerenciamento e de todos os indivíduosassociados com o processo SLA.

●

Passo 8: Determine os partidos envolvidos no SLA

Os SLA de rede do nível da empresa dependem pesadamente dos elementos de rede, oselementos da administração de servidor, o apoio do serviço de informações, os elementos doaplicativo, e o negócio ou as requisições de usuário. O Gerenciamento da cada área seráenvolvido normalmente no processo SLA. Esta encenação trabalha bem quando a organizaçãoestá construindo o suporte reagente básico SLA. As organizações de empreendimento comrequisitos de alta disponibilidade podem precisar a assistência técnica durante o processo SLAajudar com edições como o orçamento de disponibilidade, as limitações de desempenho, adefinição do perfil do aplicativo, ou as potencialidades de gerenciamento pró-ativo. Para maisaspectos do gerenciamento pró-ativo SLA, nós recomendamos uma equipe técnica dos arquitetosde rede e dos arquitetos do aplicativo. A assistência técnica pode muito mais proximamenteaproximado a Disponibilidade e os recursos de desempenho da rede e o que seria precisado dealcançar objetivos específicos.

O provedor de serviços SLA não inclui normalmente a entrada de usuário porque são criados como único objetivo de ganhar uma margem competitiva em outros provedores de serviços. Emalguns casos, o Gerenciamento superior criará estes SLA a muito requisito de alta disponibilidade

ou níveis de capacidade elevada para promover seu serviço e para fornecer objetivos internospara empregados internos. Outros provedores de serviço irão se concentrar nos aspectostécnicos da melhoria de disponibilidade, criando definições de nível de serviço forte que sãomedidas e gerenciadas internamente. Em outros casos, ambos os esforços ocorremsimultaneamente mas não necessariamente junto ou com os mesmos objetivos.

Escolher os partidos envolvidos no SLA deve então ser baseada nos objetivos do SLA. Algunsobjetivos possíveis são:

Encontrando objetivos de negócio do suporte reagente●

Fornecendo o mais de nível elevado da Disponibilidade definindo SLA dinâmicos●

Promovendo ou vendendo um serviço●

Etapa 9: Determine elementos de serviço

Geralmente, os principais SLAs de serviço/suporte possuem vários componentes, incluindo onível de suporte, como esse nível será medido, a progressão do caminho para a reconciliação doSLA e questões gerais de orçamento. Os elementos de serviço para ambientes de altadisponibilidade devem incluir definições de serviço pró-ativo assim como objetivos reativos. Osdetalhes adicionais incluem o seguinte:

Horas de negócio e procedimentos do suporte in situ para o apoio de fora-horas●

Definições de prioridade, incluindo o tipo de problema, o tempo máximo começar o trabalhono problema, tempo máximo resolver o problema, e procedimentos de escalação

●

Produtos ou serviços a serem suportados, classificados por ordem de gravidade de negócio●

Suporte para expectativas de experiência, expectativas de nível de desempenho, relato destatus e responsabilidades de usuário para a solução de problemas.

●

Edições e exigências geográficas ou da unidade de negócio do nível de suporte●

Metodologia e procedimentos de gerenciamento do problema (sistema call-tracking)●

Objetivos do help desk●

Resposta da detecção de erro de rede e do serviço●

Disponibilidade da rede da medida e o relatório●

Capacidade de rede e medida de desempenho e relatório●

Procedimentos da resolução de conflito●

Financiando o SLA executado●

O aplicativo conectado por rede ou o serviço SLA podem ter as necessidades adicionaisbaseadas em exigências e em crítica de negócio do grupo de usuário. A organização de rededeve escutar proximamente estas exigências do negócio e desenvolver as soluçõesespecializadas que cabem na estrutura de suporte total. Caber na cultura total do apoio é críticoporque é importante não criar um serviço principal pretendido somente para alguns individual ouem grupo. Em muitos casos, estas exigências adicionais podem ser colocadas em categorias da“solução”. Um exemplo pôde ser uma platina, um ouro, e uma solução de prata baseada nanecessidade de negócio. Consulte os exemplos de requisitos de SLA a seguir para obter maisinformações sobre necessidades de negócios específicos.

Nota: A estrutura de suporte, o caminho de escalada, os procedimentos do serviço deinformações, a medida, e as definições de prioridade devem pela maior parte permanecer amesma para manter e melhorar uma cultura do serviço consistente.

Requisitos de largura de banda e capacidades para a explosão●

Requisitos de desempenho●

Requisitos de QoS e definições●

Requisitos de disponibilidade e Redundância para construir a matriz de solução●

Monitoração e requisitos de relatório, metodologia, e procedimentos●

Critérios da elevação para elementos do aplicativo/serviço●

Exigências de financiamento do out-of-budget ou metodologia decarregamento●

Por exemplo, você pode criar categorias de solução para a Conectividade MACILENTO do local.A solução de platina seria fornecida com serviços T1 gêmeos para a estação. Um portadordiferente forneceria cada linha T1. A estação deveria ter dois roteadores configurados de formaque, se qualquer T1 ou roteador falhasse, ela não sofreria nenhuma interrupção. O serviço doouro teria dois Roteadores, mas o Backup do Frame Relay seria usado. Essa solução pode terlargura de banda limitada pela duração da interrupção. A solução de prata teria apenas umroteador e um serviço de portadora. Qualqueras um soluções seriam consideradas para níveis daprioridade diferentes para bilhetes do problema. Algumas organizações podem exigir uma soluçãoda platina ou do ouro se uma prioridade 1 ou o bilhete 2 é exigida para uma indisponibilidade. Asorganizações do cliente podem então financiar o nível do serviço que exigem. A tabela a seguirexibe um exemplo de organização que oferece três níveis de serviço, dependendo danecessidade de negócios para conectividade extranet.

Solução Platinum Ouro Prata

Dispositivos

Roteadoresredundantes para aconectividade de WAN

Roteador redundantepara o backup na sitecentral

NenhumaRedundância dodispositivo

WAN

Conectividade T1redundante,portadoresmúltiplos

Conectividade T1 comBackup do FrameRelay

NenhumaRedundânciaMACILENTO

Requisitos delarguradebandaeexplosão

T1redundantecom ocompartilhamento decarga paraa explosão

NON-carga quecompartilha, Backupdo Frame Relay paraaplicativos críticossomente; Frame Relay64K CIR somente

UP paraT1

Desempenho

Tempo derespostaround trip100-msconsistenteou menos

Tempo de resposta de100 ms ou menos.Esperado 99,9%

Senhorado tempoderesposta100 ou99%menosprevisto

Requisito dedisponibilidad

99.99% 99.95% 99.9%

ePrioridade dohelpdeskquandoparabaixo

Prioridade1: serviçocrítico paranegóciopara baixo

Prioridade 2: serviçocom impacto sobre osnegócios inativo

Prioridade3:conectividade denegóciopara baixo

Etapa 10: Compreenda meta de necessidade dos negócios do cliente

Esse passo dá uma grande credibilidade ao programador de SLA. Compreendendo asnecessidades dos vários grupos de negócios, o original inicial SLA será muito mais perto daexigência do negócio e do resultado desejado. Tente compreender os custos de tempo ociosopara o serviço de cliente. Avaliação em termos de produtividade perdida, de rendimento, e de boavontade do cliente. Mantenha na mente que mesmo as conexões simples com alguns povospodem seriamente impactar o rendimento. Neste caso, seja certo ajudar o cliente a compreendera Disponibilidade e os riscos de desempenho que podem ocorrer de modo que a organizaçãocompreenda melhor o nível do serviço que precisa. Se você falta esta etapa, você pode obtermuitos clientes que exigem simplesmente a Disponibilidade 100-percent.

O desenvolvedor do SLA também deve compreender os objetivos de negócios e o crescimento daorganização para acomodar as atualizações de rede, a carga de trabalho e o orçamento. Éigualmente útil compreender os aplicativos que serão usados. Esperançosamente a organizaçãotem perfis do aplicativo em cada aplicativo, mas se não, considere fazer uma avaliação técnica doaplicativo determinar problemas relacionados à rede.

Etapa 11: Defina o SLA exigido para cada grupo

O apoio preliminar SLA deve incluir unidades de negócio e a representação de grupo funcionalcríticas, tal como operações de rede de comunicação, operações de servidor, e grupos de suportepara aplicativo. Estes grupos devem ser reconhecidos com base em necessidades de negócioassim como em sua parte no processo do apoio. Tendo a representação de muitas ajudas dosgrupos igualmente crie uma solução de suport total equitativa sem a preferência ou a prioridadedo grupo individual. Isto pode conduzir uma organização de suporte em proporcionar o serviçoprincipal aos grupos individuais, uma encenação que possa minar a cultura total do serviço daorganização. Por exemplo, um cliente pôde insistir que seu aplicativo é o mais crítico dentro docorporaçõ quando na realidade os custos de tempo ocioso para esse aplicativo sãosignificativamente menos do que outro em termos de rendimento perdido, de produtividadeperdida, e de boa vontade do cliente perdida.

As unidades de negócio diferentes dentro da organização terão exigências diferentes. Umobjetivo do SLA de rede deve ser acordo em um formato total que acomoda níveis de serviçodiferentes. Estas exigências são geralmente Disponibilidade, QoS, desempenho, e MTTR. NoSLA de rede, estas variáveis são seguradas dando a prioridade aplicativos de negócio para QoSpotencial que ajusta, definindo prioridades do serviço de informações para o MTTR de ediçõesdeimpacto diferentes, e desenvolvendo uma matriz de solução que ajude a segurar aDisponibilidade e requisitos de desempenho diferentes. Um exemplo de uma matriz da soluçãosimples para uma fábrica da empresa pode olhar algo como a tabela a seguir. Você podeadicionar informações sobre disponibilidade, QoS e desempenho.

Unidadedenegócio

Aplicativos

Custosdetempoocioso

Prioridadedoproblemaquandodesativado

Requisitodeservidor/rede

Fabricação ERP Alto 1

Maiorredundância

Suporteaocliente

Cuidado decliente Alto 1

Maiorredundância

Planejamento

Servidor dearquivo,projetoASIC

Médio 2

RedundânciacentralLAN

Mercado

Servidor dearquivos Médio 2

RedundânciacentralLAN

Etapa 12: Escolha o formato do SLA

O formato para o SLA pode variar de acordo com desejos do grupo ou exigências deorganização. O seguinte é um esboço recomendado do exemplo para o SLA de rede:

Finalidade do acordoParticipantes do acordoObjetivos e objetivos de acordo1.Serviços fornecidos e produtos suportadosServiço e rastreamento de chamada do serviçode informaçõesDefinições da severidade de problema baseadas no impacto de negóciospara definições MTTRPrioridades do serviço crítico para negócio para definições deQoSCategorias de solução definidas baseadas na Disponibilidade e nos requisitos dedesempenhoRequisitos de treinamentoExigências do planejamento dacapacidadeExigências do agravamentoRelatóriosSoluções de rede fornecidasPedidos novosda soluçãoProdutos ou aplicativos Unsupported

2.

Políticas de negócioApoio durante horas de negóciodefinições do apoio de Após-horaCobertura do feriadoNúmeros de telefone do contatoPrevisão de carga detrabalhoDefinição da queixaPreste serviços de manutenção a critérios dodireitoResponsabilidades de segurança de usuário e grupo

3.

Procedimentos de gerenciamento de problemasIniciação de chamada (usuário eautomatizado)Resposta do primeiro nível e relação do reparo do atendimentoRastreamentode chamada e mantimento de registroResponsabilidades do chamadorDiagnóstico deproblemas e requisitos de fechamento de chamadaDetecção do problema de gerenciamentode rede e resposta do serviçoCategorias ou definições da solução deproblemasManipulação de problema crônicaTratamento de chamada do problemacrítico/exceção

4.

Objetivos de qualidade de serviçoDefinições de qualidadeDefinições de mediçãoMetas dequalidadeTempo médio iniciar a definição de problema pela prioridade do problemaTempomédio para solucionar o problema pela prioridade do problemaTempo médio substituir ohardware pela prioridade do problemaDisponibilidade da rede e desempenhoControlando a

5.

capacidadeControlando o crescimentoRelatório da qualidadeEquipe e orçamentosModelos de grupoOrçamento das operações6.Manutenção do acordoProgramação da revisão da conformidadeRelatório e revisão dodesempenhoReconciliação do medidor do relatórioAtualizações periódicas SLA

7.

Aprovações8.Acessórios e exibiçõesDiagramas de fluxo de chamadasMatriz de escaladaMatriz dasolução de redeExemplos de relatório

9.

Passo 13: Desenvolva grupos de trabalho de SLA

O próximo passo é identificar os participantes no grupo de trabalho do SLA, inclusive o líder dogrupo. O grupo de trabalho pode incluir usuários ou gerentes das unidades de negócio ou osgrupos funcionais ou os representantes de uma base geográfica. Esses indivíduos comunicamproblemas de SLA para seus respectivos grupos de trabalho. Os gerentes e os responsáveispelas decisões que podem concordar com os elementos-chave SLA devem participar. Estesindivíduos podem incluir os indivíduos administrativos e técnicos que podem ajudar a definir asquestões técnica relativas ao SLA e a fazer decisões do -nível (isto é, gerente do help desk,gerente de operações de servidor, gerentes do aplicativo, e gerente de operações de rede).

O grupo de trabalho do SLA de rede deve igualmente consistir na representação larga doaplicativo e do negócio a fim obter o acordo em um SLA de rede que abrange muitos aplicativos eserviços. O grupo de trabalho deve ter a autoridade para classificar processos críticos paranegócio e serviços para a rede, assim como Disponibilidade e requisitos de desempenho paraserviços individuais. Estas informações serão usadas para criar prioridades para diferentes tiposde problemas que causam impacto aos negócios, priorizar tráfego crítico aos negócios na rede ecriar soluções futuras de rede padrão com base nos requisitos de negócios.

Passo 14: Realize reuniões de grupo de trabalho e esboce o SLA

O grupo de trabalho deveria criar inicialmente um estatuto do grupo de trabalho. O estatuto deveexpressar os objetivos, as iniciativas e os cronogramas para o SLA. Em seguida o grupo devedesenvolver planos específicos da tarefa e determinar programações e calendários paradesenvolver e executar o SLA. O grupo deve igualmente desenvolver o processo do relatório paramedir o nível de suporte contra critérios do apoio. A etapa final está criando o acordo do esboçoSLA.

Inicialmente, o grupo de trabalho do SLA de rede deve se encontrar uma vez por semana paradesenvolver o SLA. Depois que o SLA foi criado e aprovado, o grupo pode encontrar a revistamensal ou mesmo trimestralmente para atualizações SLA.

Etapa 15: Negocie o SLA

Os últimos passos na criação de uma SLA são a negociação final e a desconexão. Esta etapainclui:

Revendo o esboço●

Negociando os índices●

Editando e revisando o original●

Obtendo a aprovação final●

Este ciclo de revisão do rascunho, negociação do conteúdo e criação de revisões pode levar

múltiplos ciclos antes da versão final ser enviada ao gerenciamento para aprovação.

Da perspectiva da gerente de rede, é importante negociar os resultados realizáveis que podemser medidos. Tente apoiar os acordos de desempenho e disponibilidade com os de outrasorganizações relacionadas. Isto pode incluir definições de qualidade, definições de medição, eobjetivos de qualidade. Recorde que o serviço adicionado é equivalente à despesa extra.Certifique-se de que os grupos de usuário compreendem que os níveis adicionais do serviçocustarão mais e os deixarão fazer a decisão se é uma exigência do negócio crítica. Você podeexecutar facilmente uma análise de custo em diversos aspectos do SLA, como tempo desubstituição de hardware.

Passo 16: Medida e conformidade do monitor SLA

A conformidade SLA e os resultados de medição do relatório são os aspectos importantes doprocesso SLA que ajudam a assegurar a consistência a longo prazo e os resultados. Nósrecomendamos geralmente que todo o componente principal de um SLA seja mensurável e queuma metodologia da medida esteja posta no lugar antes da aplicação SLA. Então realize reuniõesmensais entre o usuário e os grupos de suporte para rever as medidas, identifique causas de raizdo problema, e propõe soluções cumprir ou exceder o requisito de nível de serviço. Isto ajuda afazer o processo SLA similar a todo o programa de melhoria de qualidade moderno.

A seguinte seção fornece o detalhe adicional em como o Gerenciamento dentro de umaorganização pode avaliar seus SLA e seu Service Level Management total.

Indicadores de desempenho do gerenciamento de nível deserviço

Os indicadores de desempenho do Service Level Management fornecem um mecanismo paramonitorar e melhorar níveis de serviço como uma medida do sucesso. Isso permite que aorganização reaja mais rapidamente aos problemas de serviço e compreenda mais facilmenteproblemas que afetam o serviço ou o custo de tempo ocioso em seu ambiente. Não medirdefinições niveladas de serviço igualmente nega todo o funcionamento pró-ativo positivo feitoporque a organização é forçada em uma posição reativa. Ninguém chamará dizer que o serviço étrabalhar grande, mas muitos usuários chamarão dizer o serviço em não cumprir suas exigências.

Portanto, os indicadores de desempenho do gerenciamento de nível de serviço são um requisitoimportante para o gerenciamento de nível de serviço, pois fornecem meios de compreendertotalmente os níveis de serviço já existentes e de realizar ajustes com base nas questões atuais.Essa é a base para o fornecimento de um suporte pró-ativo e realização de melhorias qualitativas.Quando a organização faz a análise de causa de raiz nas edições e faz melhorias de qualidade,esta então pode ser a melhor metodologia para melhorar a Disponibilidade, o desempenho, e aqualidade do serviço disponível.

Por exemplo, considere o seguinte cenário real. A empresa X obtinha reclamações de usuárionumerosas que a rede se realizava frequentemente para baixo por períodos de tempo extendido.Medindo a Disponibilidade, a empresa encontrou o problema principal para ser alguns locaisMACILENTOS. A investigação mais próxima daquelas vistas revelou que a maioria dosproblemas estavam em alguns locais MACILENTOS. A causa de raiz foi encontrada e aorganização resolveu o problema. A organização então ajustou meta de nível de serviço para aDisponibilidade e concedeu acordos com grupos de usuário. Problemas identificados futuros dasmedidas rapidamente devido à NON-conformidade ao SLA. O grupo de rede de comunicação foi

visto então como tendo um profissionalismo mais alto, uma experiência, e um ativo total àorganização. O grupo foi efetivamente alterado de reativo para proativo em sua natureza e ajudouos resultados da empresa.

Infelizmente, a maior parte das organizações de rede atuais tem definições de nível de serviçolimitadas e nenhum indicador de desempenho. Em consequência, passam a maioria de seutempo que reage às reclamações de usuário ou aos problemas em vez dinamicamente deidentificar a causa de raiz e de construir um serviço de rede que cumpra exigências do negócio.

Use os seguintes indicadores de desempenho SLA para determinar o sucesso do processo doService Level Management:

Definição nivelada de serviço documentada ou SLA que incluem a Disponibilidade, odesempenho, o tempo de resposta do serviço reagente, os objetivos de definição deproblema, e o agravamento de problema

●

Métricas do indicador de desempenho, incluindo disponibilidade, desempenho, tempo deresposta do serviço por prioridade, tempo para resolver por prioridade e outros parâmetrosSLA mensuráveis

●

Reuniões mensais do Gerenciamento do nível de serviço de rede para rever a conformidadedo nível de serviço e para executar melhorias

●

Service Level Agreement ou definição nivelada de serviço documentada

O primeiro indicador de desempenho é um mero documento que detalha o SLA ou a definição donível de serviços. As metas principais da definição do nível de serviço devem ser disponibilidadee desempenho porque são os requisitos principais para o usuário.

Os objetivos secundários são importantes porque ajudam a definir como a Disponibilidade ou osníveis de desempenho serão conseguidos. Por exemplo, se a organização tem a Disponibilidadee destinos de desempenho agressivos, será importante impedir que os problemas ocorram e fixarrapidamente problemas quando ocorrem. Os objetivos secundários ajudam a definir os processosnecessários conseguir a Disponibilidade e os níveis de desempenho desejados.

Os objetivos secundários reagente incluem:

Tempo de resposta do serviço reagente por prioridade de chamada●

Objetivos de definição de problema ou MTTR●

Procedimentos de agravamento de problema.●

As metas secundárias proativas incluem:

Detecção do dispositivo-para baixo ou da queda do serviço de links●

Detecção de erro de rede●

Detecção da capacidade ou do problema de desempenho.●

A definição nivelada de serviço para objetivos principais, Disponibilidade, e desempenho deveincluir:

Objetivo

Como o objetivo será medido●

Partidos responsáveis para medir a Disponibilidade e o desempenho●

Partidos responsáveis para a Disponibilidade e os destinos de desempenho●

Processos não-compatíveis●

Se possível, nós recomendamos que os partidos responsáveis para a medida e os partidosresponsáveis para resultados sejam diferentes impedir um conflito de interesse. De vez emquando, ele que você pode igualmente precisar de ajustar números de disponibilidade devido aadiciona/erros do movimento/mudança, erros não detectados, ou problemas da medida dodisponibilidade. A definição nivelada de serviço pode igualmente incluir um processo para alterarresultados para ajudar a melhorar a precisão e a impedir ajustes impróprios. Consulte a próximaseção para obter informações sobre metodologias para medir disponibilidade e desempenho.

A definição nivelada de serviço para objetivos secundários reagente define como a organizaçãoresponderá à rede ou aos problemas -largos depois que são identificados, incluindo:

Definições da prioridade do problema●


Objetivos de definição de problemas ou MTTR●

Procedimentos de escalada de problemas●

Geralmente, estes objetivos definem quem serão responsável para problemas todo o tempoconcedido e ao que extensão aquela o responsável deve deixar cair suas tarefas atuais trabalharnos problemas definidos. Como definições de nível do outro serviço, o original do nível de serviçodeve detalhar como os objetivos serão medidos, parties o responsável para a medida, e osprocessos não-compatíveis.

A definição de serviço para objetivos secundários pró-ativos define como a organização fornecesuporte pró-ativo, incluindo a identificação de rede inativa, enlace inativo ou condições deinatividade do dispositivo, condições de erro de rede e limiares de capacidade de rede. Ajuste osobjetivos que promovem o gerenciamento pró-ativo porque as ajudas do gerenciamento pró-ativoda qualidade eliminam problemas e as ajudas fixam problemas mais rapidamente. Isto é realizadonormalmente ajustando um objetivo de quantos casos pró-ativo são criados e resolvidos semnotificação de usuário. Muitas organizações estabelecem uma bandeira no software do help deskpara identificar por esse motivo casos pró-ativo contra casos reagente. O original do nível deserviço deve igualmente conter a informação em como o objetivo será medido, parties oresponsável para a medida, e os processos não-compatíveis.

Métricas de indicador de desempenho

Nós sempre recomendamos que todo o meta de nível de serviço definido seja mensurável,permitindo que a organização meça níveis de serviço, identificamos as edições do serviço dacausa de raiz que estão inibindo o objetivo principal da Disponibilidade e do desempenho, e parafazer as melhorias que são alvos específicos visados. Total, o medidor é simplesmente umaferramenta que permita que as gerentes de rede controlem a consistência do nível de serviço efaçam melhorias de acordo com exigências do negócio.

Infelizmente, muitas organizações não coletam dados de disponibilidade, desempenho e outrasmedições. As organizações atribuem esta à incapacidade fornecer a precisão, o custo, a cargaadicional de rede, e recursos disponíveis completos. Estes fatores podem ter um impacto nahabilidade de medição de níveis de serviço, mas a organização deveria focar os objetivos geraispara administrar e melhorar os níveis de serviço. Muitas organizações puderam criar barato, omedidor das baixo-despesas gerais que não pode fornecer a precisão completa, mas satisfazemestes objetivos principais.

A Disponibilidade e o desempenho de medição são uma área negligenciada frequentemente nomedidor do nível de serviço. Organizações que são bem sucedidas com estes métodos simplesdo uso dois do medidor razoavelmente. Um método é enviar os pacotes de ping do Protocolo demensagens de controle da Internet (ICMP) de um local central na rede para as extremidades.Você pode igualmente obter o desempenho usando este método. As organizações que são bemsucedidas com este método igualmente agrupam dispositivos como em “grupos dedisponibilidade,” como dispositivos de LAN ou escritórios de campo domésticos. Isto é igualmenteatrativo porque as organizações têm geralmente meta de nível de serviço diferentes para áreasgeográficas ou críticos para negócio diferentes da rede. Isto permite que o grupo do medidorcalcule a média de todos os dispositivos com o grupo de disponibilidade para obter um resultadorazoável.

O outro método bem-sucedido de calcular a disponibilidade é usar bilhetes de problemas e umamedida chamada IUM (usuários afetados por minuto). Este método tabula o número de usuáriosque foram afetados por uma indisponibilidade e multiplica-o pelo número de minutos daindisponibilidade. Quando expresso como uma porcentagem dos minutos totais no período detempo, isso pode ser facilmente convertido para disponibilidade. Em qualquer dos casos, podeigualmente ser útil identificar e medir a causa de raiz do tempo ocioso da máquina de modo que amelhoria possa mais facilmente ser visada. As categorias da Causa de raiz incluem problemas dehardware, problemas de software, problemas da relação ou do portador, potência ou problemasdo meio ambiente, falhas de alteração, e erro de usuário.

Os objetivos de suporte reagente mensuráveis incluem:


Objetivos de definição de problemas ou MTTR●

Tempo de escalada de problema●

Medida dos objetivos de suporte reagente gerando relatórios dos bases de dados do help desk,incluindo os seguintes campos:

O tempo onde um atendimento foi relatado inicialmente (ou participado no base de dados)●

A hora em que a chamada foi aceita por alguém trabalhando no problema●

O tempo onde o problema foi escalado●

O tempo onde o problema foi fechado●

Este o medidor pode exigir a influência do Gerenciamento incorporar consistentemente problemasaos problemas do base de dados e da atualização no tempo real. Em alguns casos, asorganizações podem gerar automaticamente documentações de problema para eventos de redeou pedidos do email. Isto ajuda a fornecer a precisão para identificar as horas inicial de umproblema. Os relatórios gerados deste tipo da métrica classificarão normalmente problemas pelaprioridade, pelo grupo de trabalho, e pelo indivíduo para ajudar a determinar problemaspotenciais.

Que mede o suporte pró-ativo processos é mais difícil porque o exige monitorar o funcionamentopró-ativo e calcular alguma medida de sua eficácia. Pouco trabalho foi feito nesta área. É claro,contudo, que somente uma porcentagem pequena dos povos relatará realmente problemas derede a um help desk, e quando relatam o problema, tomará claramente o tempo explicar oproblema ou isolar o problema como sendo ligado à rede. Não todos os casos pró-ativo terão umefeito imediato na Disponibilidade e o desempenho devido à falha dos dispositivos redundantesou das relações terá pouco impacto em utilizadores finais.

As organizações que implementam definições ou acordos de nível de serviço proativos o fazempor força de requisitos de negócios e potenciais riscos de disponibilidade. A medida é feita então

em termos da quantidade ou da porcentagem dos casos pró-ativo, ao contrário dos casosreagente que são gerados por usuários. É uma boa ideia medir também a quantidade de casospró-ativo na cada área. Estas categorias incluiriam abaixo dos dispositivos, para baixo asrelações, os erros de rede, e as violações da capacidade. Também é possível trabalhar um poucoutilizando a modelagem de disponibilidade e os casos proativos para determinar o efeito nadisponibilidade obtido com a implementação de definições de serviço proativo.

Revisão do gerenciamento de nível de serviço

Uma outra medida do sucesso do Service Level Management é a revisão do Service LevelManagement. Isso deve ser feito independentemente de os SLAs estarem ou não ocorrendo.Execute a revisão do Service Level Management em uma reunião mensal com os indivíduosresponsáveis para medir e fornecer níveis de serviço definido. Os grupos de usuário podemigualmente estam presente quando os SLA são involvidos. O objetivo da reunião é revisar odesempenho das definições do nível de serviço medido e fazer aperfeiçoamentos.

Cada reunião deve ter uma agenda definida que inclua:

Revisão dos níveis de serviço medidos para o período dado●

Revisão das iniciativas de aprimoramento definidas para áreas individuais●

Medidor atual do nível de serviço●

Um exame de que melhorias são precisadas com base no grupo atual de medidor.●

Ao longo do tempo, a organização pode igualmente tender a conformidade do nível de serviçopara determinar a eficácia do grupo. Este processo não é diferente de um círculo de qualidade ouprocesso de melhoria de qualidade. A reunião ajuda a abordar problemas individuais e determinarsoluções com base na causa raiz.

Resumo de gerenciamento de nível de serviço

Em resumo, o Service Level Management permite que uma organização mova-se de um modelode suporte reagente para um modelo de suporte pró-ativo onde a disponibilidade da rede e osníveis de desempenho sejam determinados por exigências do negócio, não pelo grupo o maisatrasado de problemas. As ajudas do processo criam um ambiente da melhoria do nível deserviço contínuo e da concorrência aumentada do negócio. O Service Level Management éigualmente o componente de gerenciamento o mais importante para o Gerenciamento de redepró-ativo. Por este motivo, o Service Level Management é altamente recomendado em toda afase do planejamento de rede e de projeto e deve começar com recentemente arquitetura de rededefinida. Isto permite que a organização execute soluções corretamente a primeira vez, commenos quantidade de tempo ocioso ou rework.

Informações Relacionadas

Suporte Técnico - Cisco Systems●

//www.cisco.com/en/US/customer/support/index.html?referring_site=bodynav

Service Level Management: White Paper de práticas recomendadas · Indicadores de desempenho ... de...

Documents

Transcript of Service Level Management: White Paper de práticas recomendadas · Indicadores de desempenho ... de...