Disponibilidade : Alta disponibilidade

Service Level Management: White Paper de práticas recomendadas

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Este documento descreve o gerenciamento de nível de serviço e os SLAs (acordos de nível de serviço) para redes de alta disponibilidade. Inclui fatores críticos de sucesso para o gerenciamento em nível de serviço e indicadores de desempenho para ajudar a avaliar o sucesso. O documento também oferece detalhes significativos para os SLAs que seguem as orientações de melhores práticas identificadas pela equipe de serviços de alta disponibilidade.

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ço individual. Quando ocorria uma interrupção, a organização desenvolvia novos processos, recursos de gerenciamento ou infra-estrutura para evitar que uma interrupção específica ocorresse novamente. Contudo, devido a uma taxa mais alta e aos aumentos do requisito de disponibilidade da mudança, nós precisamos agora um modelo melhorado de impedir dinamicamente o tempo ocioso não planejado e de reparar rapidamente a rede. Muito o provedor de serviços e as organizações de empreendimento tentaram definir melhor o nível do serviço exigido 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 com sucesso construir níveis de serviço obteníveis e para manter SLA. Para se qualificar como um fator de sucesso crítico, um processo ou etapa do processo deve melhorar a qualidade do SLA e beneficiar a disponibilidade da rede em geral. O fator de sucesso crítico também deve ser medido de modo que a organização possa determinar o sucesso relativo ao procedimento definido.

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 os fatores 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 de operações de rede e os grupos de ferramentas necessárias podem realizar as seguintes métricas.

Nota: Para organizações sem SLA, nós recomendamo-lo executamos definições de nível de serviç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, o desempenho, o tempo de resposta do serviço reagente, os objetivos de definição de problema, e o agravamento de problema.

  • Reunião de revisão do serviço-nível da Rede de comunicação mensal para rever a conformidade do serviço-nível e para executar melhorias.

  • Os métricos de indicador de desempenho, incluindo a Disponibilidade, desempenho, tempo de resposta de serviço pela prioridade, cronometram para resolver pela prioridade, e pelos outros 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 grupos importantes:

  1. Definindo níveis de serviço de rede

  2. Criando e mantendo SLA

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

http://www.cisco.com/c/dam/en/us/support/docs/availability/high-availability/15117-highlevel.gif

Executando o gerenciamento de nível de serviço

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

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 metas para todos os funcionários da rede e podem ser usados como métrica na qualidade do serviço geral. Você também pode nos fornecer definições de nível de serviço como uma ferramenta para fazer o orçamento de recursos de rede e como evidência para a necessidade de financiar um QoS mais alto. Também proporcionam 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. A satisfação com o serviço pode ser regida por usuários com uma pequena diferenciação entre aplicativos, operações de servidor/cliente ou suporte de rede. Incluir no orçamento pode ser mais difícil porque o resultado final não é claro à organização, e finalmente, a organização de rede tende 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:

  1. Analise objetivos e limitação técnicos.

  2. Determine o orçamento de disponibilidade.

  3. Crie os perfis do aplicativo que detalham características de rede dos aplicativos críticos.

  4. Defina a Disponibilidade e as padronizações de desempenho e defina termos comuns.

  5. Crie uma definição de nível de serviço que inclua a Disponibilidade, o desempenho, o tempo de 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.

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

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 os objetivos e os requisitos técnicos. Algumas vezes, pode ajudar convidar outros colegas de técnicos de TI para participar dessa discussão porque esses indivíduos tem metas específicas relacionadas a seus serviços. Os objetivos técnico incluem a Disponibilidade dos níveis, a taxa de transferência, o tremor, o atraso, o tempo de resposta, os requisitos de escalabilidade, as introduções dos novos recursos, as introduções do aplicativo novo, a Segurança, a viabilidade, e mesmo o custo. A organização deve investigar as restrições para atingir essas metas fornecidas pelos recursos disponíveis. Você pode criar planilhas para cada objetivo, com uma explicação de restrições. Inicialmente, pode parecer como se a maioria dos objetivos não são realizáveis. Dê prioridade aos objetivos ou reduza as expectativas que ainda podem satisfazer os requisitos de negócios.

Por exemplo, você pôde ter uma Disponibilidade em nível de 99.999 por cento, ou os minutos 5 do 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 de alteração e limitações de capacidade de rede atual. Em consequência, você pode ajustar o objetivo a um nível mais realizável. O modelo de disponibilidade na próxima seção pode ajudá-lo a definir metas realistas.

Você também pode considerar fornecer maior disponibilidade em determinadas áreas da rede que tenham menos restrições. Quando a organização de rede publica padrões de serviço para disponibilidade, os grupos de negócios dentro da organização podem achar o nível inaceitável. Portanto, esse é um ponto natural para começar discussões sobre SLA ou modelos de financiamento/orçamentos que podem alcançar os requisitos comerciais.

Tente identificar todas as restrições e riscos envolvidos para alcançar o objetivo técnico. Priorize as restrições em termos do maior risco ou impacto sobre o objetivo almejado. Isto ajuda a organização a dar a prioridade a iniciativas de aprimoramento da rede e a determinar como facilmente a limitação pode ser endereçada. Há três tipos de restriçõ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 restrições de configuração são todas as limitações ou riscos associadas com a tecnologia atual, o hardware, os links, o projeto, ou a configuração. Limitações de tecnologia abrangem qualquer restrição imposta pela própria tecnologia. Por exemplo, nenhuma tecnologia atual permite o secundário-segundo tempo de convergência nos ambientes de rede redundante, que podem ser críticos para conexões de voz de sustentação atravé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 de hardware, na hierarquia, na modularidade, na Redundância, e no MTBF ao longo dos trajetos definidos na rede. As limitações do link de rede devem centrar-se sobre links de rede e Conectividade do portador para organizações de empreendimento. As limitações do link podem incluir a redundância de link e a diversidade, as limitações de meios, prendendo infra-estruturas, Conectividade do loop local, e conectividade de longa distância. As restrições de projeto relacionam-se ao exame ou ao projeto lógico da rede e incluem-se tudo do espaço disponível para o equipamento à escalabilidade da aplicação do protocolo de roteamento. Todos os 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 de rede 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 devem igualmente ser consideradas.

As práticas de ciclo de vida definem os processos e o Gerenciamento da rede usada para distribuir consistentemente soluções, detectam e reparam problemas, impedem a capacidade ou os problemas de desempenho, e configuram a rede de consistência e a modularidade. É necessário considerar essa área porque experiência e processos normalmente são os itens que mais 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 a funcionalidade do gerenciamento de rede como o gerenciamento de desempenho, gerenciamento de configuração, gerenciamento de falhas e segurança. Uma avaliação do ciclo de vida de rede está disponível dos serviços do (HAS) dos serviços de alta disponibilidade de Cisco NSA que mostram a Disponibilidade de limitações da rede atual associadas com as práticas do ciclo de vida de rede.

A carga de tráfego ou as restrições de aplicativo atuais referem simplesmente o impacto do tráfego e de aplicativos atuais.

Infelizmente, muitos aplicativos possuem restrições significativas que exigem gerenciamento cauteloso. O Jitter, o atraso, a taxa de transferência, e os requisitos de largura de banda para aplicativos atuais têm tipicamente muitas limitações. A maneira como o aplicativo foi escrito também pode criar restrições. A definição do perfil do aplicativo ajuda-o melhor a compreender estas edições; a próxima seção cobre esta característica. A Disponibilidade, o tráfego, a capacidade, e o total de desempenho atuais de investigação igualmente ajudam gerentes de rede a compreender expectativas e riscos atuais do serviço-nível. Isto é realizado tipicamente com um processo chamado a avaliação comparativa de rede, que ajuda a definir o desempenho da 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 o planejamento da capacidade e a tensão, mas pode igualmente ser usada para compreender edições do serviço-nível.

A planilha abaixo utiliza o método de objetivos/restrições acima mencionado, com o objetivo de exemplificar o impedimento de um ataque de segurança ou de um ataque de recusa de serviço (DoS). Você pode igualmente usar esta folha para ajudar a determinar a cobertura do serviço para ataques de segurança de minimização.

Risco ou restrição Tipo de restrição Impacto potencial
As ferramentas disponíveis da detecção DoS não podem detectar todos os tipos de ataques DoS. Tecnologia/elasticidade Alto
Não tenha o pessoal e o processo exigidos a reagir aos alertas. Práticas de ciclo de vida Alto
As políticas de acesso da rede atual não são no lugar. Práticas de ciclo de vida Médio
A conexão com o Internet atual da baixo-largura de banda pode ser um fator se o congestionamento de largura de banda é usado para o ataque. Capacidade de rede Médio
Atualmente a configuração de segurança a ajudar a impedir ataques nã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 pontos definidos. A informação teórica precisa é útil em diversas maneiras:

  • A organização pode usá-las como meta para disponibilidade interna e os desvios podem ser rapidamente definidos e remediados.

  • As informações podem ser usadas pelos planejadores de rede ao determinar a disponibilidade do sistema, ajudando a garantir que o projeto atenda aos requisitos de negó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, o link ou a falha do portador, o projeto de rede, o erro humano, ou a falta do processo. Você deve avaliar bem cada um desses parâ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 de disponibilidade. Use a medida de disponibilidade como linha de base para estimar o nível de serviço atual usado para uma definição de nível de serviço. Contudo, você pode estar interessado em comparar os dois para compreender a disponibilidade teórica potencial comparada ao resultado medido real.

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

  1. Disponibilidade

    • 1 – (tempo total de interrupção da conexão) / (tempo total de conexão em serviço)

    • 1 - [Sigma(num connections affected in outage i X duration of outage i)]/(conns numéricos no período de operação do serviço X)

  2. Indisponibilidade

    1 - 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 enlace ou de transporte, design da rede ou erro do usuário e falha no processo)

  3. Disponibilidade de hardware

    A primeira área a investigar é falha de hardware potencial e o efeito na indisponibilidade. Para determinar isso, a organização precisa compreender o MTBF de todos os componentes de rede e o MTTR para problemas de hardware para todos os dispositivos em um caminho entre dois pontos. Se a rede é modular e hierárquica, a disponibilidade de hardware será a mesma entre quase todos os dois pontos. A informação MTBF está disponível para todos os componentes Cisco e está disponível mediante solicitação a um gerenciador de conta local. O programa Cisco NSA HAS também usa uma ferramenta para ajudar a determinar a disponibilidade de hardware ao longo de caminhos de rede, mesmo quando há redundância de módulo, redundância de chassi e redundância de caminho no sistema. Um fato principal de confiabilidade de hardware é o MTTR. As organizações devem avaliar como rapidamente podem reparar o hardware quebrado. Se a organização não tem nenhum plano frugalmente e confia em um acordo 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 e nenhuma Redundância do acesso, a disponibilidade aproximada é 99.99 por cento com um MTTR de 4 horas.

  4. Disponibilidade de software

    A área de investigação seguinte falha falhas de software. Para finalidades da medida, Cisco define falhas de software como as inicializações lentas do dispositivo devido ao erro de software. Cisco fez o progresso significativo para a disponibilidade de software compreensiva; contudo, umas liberações mais novas tomam o tempo 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 em 99.9999 por cento de Disponibilidade. Isso é calculado com base nas partidas a frio reais nos Cisco routers usando seis minutos como o tempo de reparo (tempo para o roteador ser recarregado). As organizações que trabalham com várias versões devem obter uma disponibilidade ligeiramente inferior, devido à complexidade, à interoperabilidade e ao aumento de tempo no Troubleshooting. Espera-se que as organizações com as versões de software 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 experimentar ou não-disponibilidade significativa ou disponibilidade fechada para uma versão de distribuição geral.

  5. Ambiental e disponibilidade de energia

    Você também deve considerar problemas ambientais e de energia na disponibilidade. As questões ambientais relacionam-se à divisão dos sistemas de refrigeração necessários manter o equipamento em uma temperatura de funcionamento especificada. Muitos dispositivos Cisco fecharão simplesmente quando são consideravelmente fora da especificação um pouco do que arriscando dano a todo o hardware. Com a finalidade de um orçamento de disponibilidade, a potência será usada porque é a causa principal da indisponibilidade nesta área.

    Embora as falhas de energia sejam 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. O que uma organização deve avaliar é uma medida aproximada da disponibilidade de energia de seus dispositivos com base na experiência de sua área geográfica, de seus recursos de backup de energia e processo implementado para garantir energia com qualidade consistente a todos os dispositivos.

    Para uma avaliação conservadora, nós podemos dizer que uma organização com geradores de backup, sistemas do uninterruptible-power-supply (UPS), e processos de implementação das energias de qualidade pode experimentar seis 9s da Disponibilidade, ou 99.9999 por cento, visto que as organizações sem estes sistemas podem experimentar a Disponibilidade em 99.99 por cento, ou aproximadamente 36 minutos do tempo ocioso da máquina anualmente. Naturalmente você pode ajustar estes valores a uns valores mais realísticos baseados na percepção ou nos dados reais da organização.

  6. Link ou falha do portador

    O link e as falhas do portador são fatores principais a respeito da Disponibilidade nos ambientes de WAN. Mantenha na mente que os ambientes de WAN são simplesmente outras redes que são sujeitas aos mesmos problemas de disponibilidade que a rede da organização, incluindo a falha do hardware, a falha de software, 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 ser difícil. Mantenha na mente que os portadores igualmente têm frequentemente a Disponibilidade dos níveis da garantia que têm quase nenhuma base em um orçamento de disponibilidade real. Estes níveis da garantia às vezes simplesmente estão introduzindo no mercado e os métodos de vendas usados para promover o portador. Em alguns casos, estas redes igualmente publicam as estatísticas de disponibilidade que parecem extremamente boas. Mantenha na mente que estas estatísticas podem aplicar somente às redes central completamente redundantes e não fatoram na indisponibilidade devido ao acesso do loop local, que é um contribuinte principal à indisponibilidade nas redes de WAN.

    Criar uma avaliação da Disponibilidade para ambientes de WAN deve ser baseada na informação do portador real e no nível da Redundância para a conectividade de WAN. Se uma organização tem dependências com múltiplas entradas, fornecedores redundantes do loop local, acesso local do Synchronous Optical NETwork (SONET), e portadoras interurbanas redundantes com diversidade geográfica, a disponibilidade de WAN estará aumentada consideravelmente.

    O serviço de telefonia tem um orçamento de disponibilidade razoavelmente preciso para conectividade de rede não redundante em ambientes WAN. A conectividade de ponta a ponta para telefones tem uma disponibilidade aproximada do orçamento de 99.94 por cento usando uma metodologia do orçamento de disponibilidade similar a essa descrita nesta seção. Essa metodologia era usada com êxito em ambientes de dados com apenas uma leve variação e, no momento, é usada como um destino na especificação do cabo do pacote para redes a cabo de provedor de serviços. Se nós aplicamos este valor completamente a um sistema redundante, nós podemos supor que a disponibilidade de WAN será próxima a 99.9999-percent disponível. Naturalmente muito poucas organizações têm sistemas MACILENTOS completamente redundantes, geograficamente dispersados devido à despesa e à Disponibilidade, assim que julgamento apropriado do uso em relação a esta capacidade.

    As falhas do link em um ambiente de LAN são menos prováveis. Contudo, os planejadores podem querer supor uma quantidade pequena de downtime devido aos conectores quebrados ou fracos. Para redes de LAN, uma estimativa conservadora é a Disponibilidade aproximadamente 99.9999-percent, ou os aproximadamente 30 segundos pelo ano.

  7. Projeto de rede

    O projeto de rede é um outro contribuinte principal à Disponibilidade. os projetos NON-escaláveis, os erros de design, e o tempo de convergência de rede todos afetam negativamente a Disponibilidade.

    Nota: Para fins deste documento, o projeto NON-escalável ou os erros de design são incluídos na seguinte seção.

    O projeto de rede é limitado então a um valor mensurável baseado na falha de software e de hardware na rede que causa o novo roteamento de tráfego. Esse valor é normalmente chamado de "tempo de switchover de sistema" e é um elemento dos recursos do protocolo de autocorreção no sistema.

    Calcule a Disponibilidade simplesmente usando os mesmos métodos para cálculos do sistema. Contudo, isto é inválido a menos que o tempo de switchover da rede cumprir exigê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. Um exemplo pôde ser Voz sobre IP (VoIP) em um ambiente onde o tempo de switchover calculado ou real fosse 30 segundos. Neste exemplo, os usuários pendurarão simplesmente acima o telefone e tentá-lo-ão possivelmente outra vez. Os usuários certamente verão esse período de tempo como uma indisponibilidade, porém isso ainda não foi estimado na provisão de disponibilidade.

    Calcule a indisponibilidade devido ao tempo de switchover de sistema olhando a disponibilidade de software e hardware teórica ao longo dos caminhos redundantes, porque o switchover ocorrerá nesta área. Você deve saber o número de dispositivos que podem falhar e causar switchover no caminho redundante, o MTBF desses dispositivos e o tempo de switchover. Um exemplo simples seria um MTBF de 35,433 horas por cada um de dois dispositivos idênticos redundantes e um tempo de switchover de 30 segundos. Dividindo 35,433 por 8766 (as horas por ano calculadas a média para incluir anos de pulo), nós vemos que o dispositivo falhará uma vez cada quatro anos. Se nós usamos 30 segundos como um tempo de switchover, nós podemos então supor que cada dispositivo experimentará, 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 a 15 segundos pelo ano. Quando isto é calculado em termos dos segundos pelo ano, a quantidade de disponibilidade devido ao switchover pode ser calculada como a Disponibilidade 99.99999785-percent neste sistema simples. Esse número pode ser maior em outros ambientes devido ao número de dispositivos redundantes na rede em que o switchover é possível.

  8. Erro e processo do usuário

    Erro de usuário e problemas de disponibilidade de processo são as 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 a detecção de erros, de falhas de alteração, e de problemas de desempenho.

    As organizações simplesmente não desejam usar quatro vezes todas as outras indisponibilidades teóricas para determinar o orçamento de disponibilidade, embora evidências sugiram constantemente que esse é o caso em muitos ambientes. A próxima seção discute este aspecto da não disponibilidade de maneira mais completa.

    Desde que você não pode teoricamente calcular a quantidade de indisponibilidade devido ao erro de usuário e ao processo, nós recomendamo-lo removemos isto removido do orçamento de disponibilidade e que as organizações se esforçam para a perfeição. A uma advertência é que as organizações precisam de compreender o risco atual à Disponibilidade em seus próprios processos e níveis da experiência. Após entender melhor esses riscos e inibidores, os planejadores de rede podem fatorar certa quantidade de indisponibilidade devido a essas questões. O programa Cisco NSA HAS investiga esses problemas e auxilia as organizações a compreender a indisponibilidade potencial devido a problemas de processamento, erro do usuário ou de conhecimento especializado.

  9. Determinando o orçamento final de disponibilidade

    Você pode determinar o orçamento de disponibilidade geral multiplicando a disponibilidade de cada uma das áreas definidas anteriormente. Geralmente, isto é feito para ambientes homogêneos em que a conectividade é semelhante entre quaisquer dois pontos; por exemplo, um ambiente LAN modular hierárquico ou um ambiente 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 e sistemas UPS para todos os componentes de rede e controla corretamente a potência. A organização não usa VoIP e não deseja fatorar no tempo de switchover de software. As estimativas são:

    • Disponibilidade do trajeto do hardware entre dois pontos finais = 99.99 por cento de Disponibilidade

    • Disponibilidade do software usando o software GD como referência = disponibilidade de 99,9999 por cento

    • Ambiental e disponibilidade de energia com sistemas de backup = 99.999 por cento de Disponibilidade

    • Falha do link no ambiente de LAN = 99.9999 por cento de Disponibilidade

    • Tempo de switchover de sistema não fatorado = 100 por cento de Disponibilidade

    • Previsão perfeita para erros de usuário e disponibilidade do processo = 100 por cento de disponibilidade

    O orçamento de disponibilidade final que as organizações devem se esforçar para obter é igual a 0,9999 X 0,999999 X 0,999999 X 0,999999 = 0,999896 ou 99,9896 por cento de disponibilidade. Se nós fatoramos na não disponibilidade potencial devido ao usuário ou ao erro de processo e supomos que a indisponibilidade é 4X disponibilidade devido devido aos fatores técnicos, nós poderíamos supor que o orçamento de disponibilidade é 99.95 por cento.

    Esta análise de exemplo indica que a disponibilidade da LAN recairia em média entre 99,95 e 99,989 por cento. Esses números podem ser utilizados agora como uma meta de nível de serviço para a organização da rede de comunicação. Um valor adicional pode ser obtido pela medição da disponibilidade no sistema e da definição da porcentagem de indisponibilidade devido a cada uma das seis áreas acima. Isso permite que a organização avalie fornecedores, portadoras, processos e equipes corretamente. O número também pode ser utilizado para definir expectativas dentro da empresa. Se o número é inaceitável, a seguir os recursos adicionais do orçamento para ganhar os níveis desejados.

    Pode ser útil para gerentes de rede compreender a quantidade de tempo ocioso em toda a Disponibilidade particular do nível. O tempo de interrupção em minutos para um período de um ano, com qualquer nível de disponibilidade, é:

    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 da máquina. Para a definição de disponibilidade acima, isto é igual ao valor médio do tempo ocioso 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 define exigências do nível de serviço de rede para aplicativos individuais. Isso ajuda a garantir que a rede suporta requisitos de aplicativos individuais e serviços de rede em geral. Os perfis do aplicativo puderem igualmente servir como uma linha de base documentada para o apoio de serviço de rede quando ponto do aplicativo ou dos grupos de servidor à rede como o problema. Em última análise, os perfis de aplicativos ajudam a alinhar objetivos de serviço de rede com requisitos de aplicativos e de negócios comparando requisitos de aplicativos como desempenho e disponibilidade a objetivos de serviço de rede realísticos ou limitações atuais. É importante não apenas para gerenciamento em nível de serviço, mas também para o design da rede geral de cima para baixo.

Crie perfis do aplicativo quando você introduz aplicativos novos à rede. Talvez seja necessário um acordo entre o grupo de aplicativos de TI, os grupos de administração de servidor e a rede de comunicaçã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 aplicativos de negócio podem incluir o email, a transferência de arquivo, a navegação na web, a imagem 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 do aplicativo. Os aplicativos novos podem exigir o uso de um analisador de protocolo e de um emulador de WAN com emulation do atraso caracterizar corretamente requisitos do aplicativo. Isso ajuda a identificar a largura de banda necessária, o retardo máximo para utilização do aplicativo e os requisitos de variação de sinal. É possível executar essa tarefa em um ambiente de laboratório desde que você tenha os servidores necessá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ório não serão precisados. Um perfil do aplicativo deve incluir os itens seguintes:

  • Nome do aplicativo

  • Tipo de aplicativo

  • Aplicativo novo?

  • Importância de negócios

  • Requisitos de disponibilidade

  • Protocolos e portas usados

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

  • Número e localização de 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 de negócio e os requisitos de rede como largura de banda, retardo e jitter. Além, a organização de rede 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 tempo ocioso de aplicativo total. Quando você completa o perfil do aplicativo, você pode comparar todos os recursos de rede e ajudar a alinhar os níveis de serviço de rede com os requisitos 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 para a organização. Estes podem ser definidos para diferentes áreas da rede ou de aplicativos específicos. O desempenho pode igualmente ser definido em termos do retardo round trip, do tremor, do throughput máximo, dos comprometimentos de largura de banda, e da escalabilidade total. Além do que o ajuste das expectativas do serviço, a organização deve igualmente ciao para definir cada um dos padrões do serviço de modo que o usuário e os grupos TI que trabalham com trabalhos em rede compreendam inteiramente o padrão do serviço e como se relaciona a suas exigências do aplicativo ou da administração de servidor. Usuário e grupos de TI também devem entender 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 dos riscos e das limitações atuais na rede, uma compreensão do comportamento de aplicativo, e uma disponibilidade teórica da análise ou a linha da base de disponibilidade.

  1. Defina o geográfico ou as áreas de aplicativo onde os padrões do serviço serão aplicados.

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

  2. Defina os Parâmetros padrão do serviço.

    A Disponibilidade e o retardo round trip são a maioria de padrões do serviço de rede comum. O throughput máximo, o compromisso de largura de banda mínima, o tremor, as taxas de erro aceitáveis, e as potencialidades de escalabilidade podem igualmente ser incluídos como necessários. Seja cuidadoso ao rever o parâmetro de serviço para métodos de medida. Independentemente de o parâmetro seguir para um SLA, a organização deve pensar sobre como o parâmetro de serviço poderá ser medido 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 das etapas precedentes para construir uma matriz de padrões do serviço. A organização igualmente precisará de definir as áreas que podem ser desconcertantes aos usuários e aos grupos TI. Por exemplo, o tempo máximo de resposta será muito diferente para um ping round trip do que para bater a tecla ENTER em uma posição remota para um aplicativo específico. A tabela a seguir mostra os destinos de desempenho dentro do Estados Unidos.

Área de rede Disponibilidade do alvo Método de medida Alvo médio do tempo de resposta de rede Tempo de resposta máximo aceitado Método da medida de tempo de resposta
LAN 99.99% Minutos de usuário impactado Menos de 5 ms 10 ms Resposta de ping round trip
WAN 99.99% Minutos de usuário impactado Abaixo de 100 ms (ping round trip) 150 ms Resposta de ping round trip
WAN crítico e extranet 99.99% Minutos de usuário impactado Abaixo de 100 ms (ping round trip) 150 ms Resposta de ping round trip

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 os processos pró-ativo e os recursos de gerenciamento de rede que você executa para conseguir meta de nível de serviço. O documento final é chamado tipicamente um plano de suporte das operações. A maioria de planos da sustentação do aplicativo incluem somente exigências de suporte reagente. Nos ambientes de alta disponibilidade, a organização deve igualmente considerar os processos do gerenciamento pró-ativo que estarão usados para isolar e resolver questões de rede antes que os atendimentos do serviço de usuário estejam iniciados. Acima de tudo, 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ço reagente 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á satisfazer as metas de disponibilidade e desempenho. Para conseguir isso, a organização deve criar o serviço tendo em mente as restrições técnicas, o orçamento disponível e os perfis de aplicativos atuais. Especificamente, a organização deve definir e construir um serviço que consistentemente e rapidamente identifique e resolva problemas dentro das épocas atribuídas pelo modelo de disponibilidade. A organização também deve definir um serviço que possa identificar e resolver rapidamente os problemas potenciais de serviços que afetarão a disponibilidade e o desempenho, se ignorados.

Você não conseguirá o nível de serviço desejado durante a noite. Deficiências, como pouca experiência, limitações do processo atual ou nível inadequado dos profissionais, podem impedir que a organização alcance seus padrões desejados ou atinja suas metas, mesmo após realizar os passos de análise de serviço anteriores. Não existe método preciso para fazer a correspondência exata do nível de serviço necessário com os objetivos desejados. Para acomodar para isto, a organização deve medir os padrões do serviço e medir os parâmetros de serviço usados para apoiar 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 a edição. Em muitos casos, os aumentos de realização do orçamento podem ser feitos para melhorar serviços de assistência e fazer melhorias necessárias conseguir os objetivos do serviço desejado. Com o tempo, a organização pode fazer vários ajustes, tanto na meta de serviço quanto na definição do serviço, a fim da alinhar os serviços de rede com os requisitos comerciais.

Por exemplo, uma organização pôde conseguir 99 por cento de Disponibilidade quando o objetivo era muito mais alto em 99.9 por cento de Disponibilidade. Ao examinar métricas de serviço e suporte, representantes da organização descobriram que a substituição do hardware estava demorando cerca de 24 horas, o que era muito mais do que a estimativa original, pois a organização havia orçado apenas quatro horas. Além, a organização encontrou que as potencialidades de gerenciamento pró-ativo estavam ignoradas e os dispositivos da rede redundante não estavam reparados para baixo. Igualmente encontraram que não tiveram os pessoais para fazer melhorias. Em consequência, após a consideração que abaixa os objetivos de serviço atuais, a organização incluída no orçamento para recursos adicionais precisou de conseguir o nível de serviço desejado.

As definições de serviço devem incluir definições e definições proativa do suporte reagente. As Definições reativa definem como a organização reagirá aos problemas depois que foram identificadas da reclamação de usuário ou dos recursos de gerenciamento de rede. As definições proativa 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 e elevações “à espera” quebrados. As seções a seguir fornecem exemplos de definições de nível de 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 um banco de dados de help desk e auditorias periódicas. Esta tabela mostra um exemplo da gravidade do problema para uma organização. Observe que a carta não inclui como segurar pedidos para o serviço novo, que pode ser segurado por um SLA ou por uma definição do perfil do aplicativo e por uma análise What-if adicionais do desempenho. Normalmente a gravidade 5 pode ser uma solicitação para o novo serviço, se controlado por meio do mesmo processo de suporte.

Severidade 1 Severidade 2 Severidade 3 Severidade 4
Site WAN crítico severa do usuário ou do segmento de servidor do impacto de negócios LAN para baixo para baixo Impacto de negócios alto com a perda ou a degradação, campus LAN no lugar da alternativa possível para baixo; 5-99 usuários afetaram o impacto MACILENTO internacional do desempenho crítico do local do local do WAN doméstico para baixo para baixo Alguma funcionalidade de rede específica é perdida ou degradada, como a redundância de LAN impactada desempenho do campus LAN da perda de redundância perdida Uma pergunta ou uma falha funcional que não tenham nenhum impacto de negócios para a organização

Após a definição da gravidade do problema, defina ou investigue o processo de suporte para criar definições de resposta de serviço. Geralmente, as definições da resposta do serviço exigem uma estrutura do suporte alinhado acoplada com um sistema de suporte de software do help desk para seguir problemas através das documentações de problema. O medidor deve igualmente estar disponível no tempo de resposta e no tempo de resolução para cada prioridade, no número de atendimentos pela prioridade, e na resposta/qualidade da resolução. Para definir o processo de suporte, é útil definir as metas de cada camada de suporte na organização e suas funções e responsabilidades. Isso é útil para que a organização compreenda os requisitos de recurso e os níveis de especialização para cada nível de suporte. As tabelas a seguir fornecem um exemplo de uma organização de suporte alinhado com diretrizes de resolução de problemas.

Nível de suporte Responsabilidade Objetivos
Apoio da série 1 As chamadas de suporte a tempo completo da resposta do apoio do help desk, as documentações de problema do lugar, trabalho no problema até 15 minutos, bilhete do documento e escalam para apropriar o apoio da série 2 Definição de 40% das chamadas recebidas
Apoio da série 2 Enfileire a monitoração, Gerenciamento de redes, documentações de problema do lugar da monitoração da estação para atendimentos da tomada do implementar dos problemas identificados do software da série 1, vendedor, e o agravamento da série 3 supõe a posse do atendimento até a definição Definição de 100% dos atendimentos a nível da série 2
Tier 3 Support Deve fornecer o apoio imediato à série 2 para todos os problemas da prioridade 1 concordam ajudar com todos os problemas não-resolvidos pela série 2 dentro do período de resolução de SLA Nenhuma posse direta do problema

A próxima etapa é criar a matriz para a definição de serviço da definição da resposta do serviço e do 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 de resposta e o tempo de recuperação do serviço impactam diretamente a disponibilidade da rede. Os horários de resolução de problemas também devem estar alinhados ao orçamento de disponibilidade. Se um grande número problemas da severidade elevada não são esclarecidos no orçamento de disponibilidade, a organização pode então trabalhar para compreender a fonte destes problemas e de um remédio potencial. Veja a seguinte tabela:

Severidade do problema Resposta do help desk Resposta da camada 2 Nível 2 no local Substituição de hardware Resolução de problemas
1 Escalada imediata à série 2, gerente de operações de rede 5 minutos 2 horas 2 horas 4 horas
2 Escalada imediata à série 2, gerente de operações de rede 5 minutos 4 horas 4 horas 8 horas
3 15 minutos 2 horas 12 horas 24 horas 36 horas
4 15 minutos 4 horas 3 dias 3 dias dias 6

Além do que a definição da resposta do serviço e do serviço, construa uma matriz de escalação. As ajudas da matriz de escalada asseguram-se de que os recursos disponíveis estejam centrados sobre os problemas que afetam severamente o serviço. Geralmente, quando os analistas são centrados sobre problemas da fixação, centram-se raramente sobre trazer recursos adicionais dentro no problema. Definição quando os recursos adicionais deverem ser ajudas notificadas para promover a consciência de problema no Gerenciamento e puderem geralmente ajudar a conduzir a dinâmico futuro ou às medidas preventivas. Veja a seguinte tabela:

Tempo transcorrido Severidade 1 Severidade 2 Severidade 3 Severidade 4
5 minutos Gerente de operações de rede, apoio da série 3, diretor de rede de comunicação      
1 hora Atualização para gerenciador de operações de rede, suporte de nível 3, diretor de rede de comunicação Atualização para gerenciador de operações de rede, suporte de nível 3, diretor de rede de comunicação    
2 horas Escale ao VP, atualização ao diretor, gerenciador de operações      
4 horas Notificação do CEO sobre a razão principal de consultas não resolvidas para o VP, o diretor, o gerente de operações, o suporte de nível 3 Escale ao VP, atualização ao diretor, gerenciador de operações    
24 horas     Gerente de operações de rede  
dias 5       Gerente de operações de rede

Até aqui, as definições de nível de serviços enfatizavam a forma como a organização de suporte a operações reage a problemas depois que eles são identificados. As empresas de operações têm criado, há anos, planos de suporte operacionais com informações similares às acima. Contudo, o que falta nesses casos é como a organização identificará problemas e que problemas identificarão. Umas organizações de rede mais sofisticadas tentaram resolver esta edição simplesmente criando os objetivos para o porcentagem de problemas que são identificados dinamicamente, ao contrário dos problemas de forma reativa identificados por relatórios do problema ou por queixa do usuário.

A tabela a seguir mostra como uma organização pode querer medir capacidades de suporte proativo e o total de suporte proativo.

Área de rede Razão de identificação do problema proativo Relação reativa da identificação do problema
LAN 80% 20%
WAN 80% 20%

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

Definições niveladas de serviço proativo

Mais metodologia abrangente para criar definições niveladas de serviço inclui mais detalhe em como a rede é monitorada e em como a organização de operações reage aos pontos iniciais da estação de gerenciamento da rede definida (NMS) em um 7 x 24 bases. Essa tarefa poderá ser considerada impossível devido ao número precipitado de variáveis de Base de Informação de Gerenciamento (MIB) e à quantidade de informações de gerenciamento de rede que são pertinentes ao funcionamento da rede. Podia igualmente ser extremamente caro e repleto de recursos. Infelizmente, essas objeções impedem que muitas pessoas implementem uma definição de serviço proativa que, por natureza, deve ser simples, bem fácil de seguir e aplicável apenas à melhor disponibilidade ou a riscos de desempenho na rede. Se uma organização considera então o valor em definições de serviço pró-ativo básicas, mais variáveis podem ser adicionadas ao longo do tempo 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 das operações. Da definição de serviço os estados simplesmente como o grupo de operações dinamicamente identificará e responderá à rede ou ligará abaixo das condições em áreas diferentes da rede. Sem esta definição (ou suporte de gerenciamento), a organização pode esperar 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 criaria uma definição de serviço para as condições de link/dispositivo desativado. O exemplo mostra uma organização corporativa que pode ter diferentes requisitos de notificação e resposta com base na hora do dia e área da rede.

Dispositivo de rede ou link para baixo Método de detecção notificação 8 5 x Notificação 7 x 24 definição 8 5 x Resolução 7 x 24
LAN central Dispositivo de SNMP e apuração de link, armadilhas O NOC cria a documentação de problema, pager de obrigação de LAN da página O pager de obrigação de LAN da página automática, pessoa encarregada do LAN cria a documentação de problema para a fila do LAN central Analista de LAN atribuído dentro de 15 minutos pelo NOC, reparo conforme a definição da resposta do serviço Prioridades 3 e da investigação e resolução imediatas das prioridades 1 e 2 fila 4 para a resolução pela manhã
WAN doméstico Dispositivo de SNMP e apuração de link, armadilhas O NOC cria a documentação de problema, pager de obrigação de WAN de página O pager de obrigação do WAN da página automática, pessoa de obrigação de WAN cria a documentação de problema para a fila MACILENTO Analista de WAN atribuído dentro de 15 minutes por NOC, reparo como definição de resposta por serviço Prioridades 3 e da investigação e resolução imediatas das prioridades 1 e 2 fila 4 para a resolução pela manhã
Extranet Dispositivo de SNMP e apuração de link, armadilhas O NOC cria a documentação de problema, pager de obrigação do parceiro de página O pager de obrigação do sócio da página automática, pessoa do dever do sócio cria a documentação de problema para a fila do sócio Analista de parceiro designado em 15 minutos pelo NOC; faça o reparo de acordo com a definição de resposta de serviço Prioridades 1 e investigação e resolução imediatas 2; Fila de prioridades 3 e 4 para resolução matinal

As definições niveladas de serviço pró-ativo restantes podem ser divididas em duas categorias: erros de rede e capacidade/problemas de desempenho. Apenas uma pequena porcentagem das organizações de rede possui definições de nível de serviço nessas áreas. Em consequência, estas edições são ignoradas ou seguradas esporadicamente. Isso pode ser adequado para alguns ambientes de rede, mas ambientes de alta disponibilidade geralmente exigirão de gerenciamento proativo de serviços.

As organizações de rede de comunicação tendem a esforçar-se por vários motivos com as definições de serviço pró-ativo. Isso ocorre principalmente porque não executaram uma análise de 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 para definições de serviço pró-ativo e benefícios obscuros, especialmente porque os recursos adicionais podem ser precisados.

O segundo motivo envolve balancear a quantidade de gerenciamento proativo que pode ser feito com recursos existentes ou recém-definidos. Gere somente os alertas que tenham um possível impacto importante na disponibilidade ou no desempenho. Você deve igualmente considerar o Gerenciamento ou os processos da correlação de evento para assegurar-se de que os ticket de problema pró-ativo múltiplos não estejam gerados para o mesmo problema. O último motivo com o qual as organizações podem implicar é que criar um novo conjunto de alertas muitas vezes pode gerar uma inundação inicial de mensagens que anteriormente passaram despercebidas. O grupo de operações deve ser preparado para esta inundação inicial das edições e de recursos a curto 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 rede podem 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 avisos ambientais. Desenvolver uma definição nivelada de serviço começa com uma compreensão geral de como estas condições de problema serão detectadas, de que os olharão, e o que acontecerão quando ocorrem. Adicionar mensagens ou edições específicas à definição nivelada de serviço se a necessidade elevara. Também pode ser necessário um trabalho adicional nas áreas a seguir para 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 de trabalho 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 de modo eficaz os alertas definidos

  • Metodologias da correlação de evento para assegurar-se de que os ticket de problema 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 de evento a nível de suporte da série 1

A tabela a seguir mostra um exemplo de definição de nível de serviço para erros de rede que permite entender claramente quem é responsável pelos alertas de erro de rede proativos, como o problema será identificado e o que acontecerá quando ele ocorrer. A organização pode ainda precisar esforços adicionais como definidos acima para assegurar o sucesso

s.

Categoria de erro Método de detecção Limite Ação tomada
Erros de Software (travamentos causados por software) Revisão diária dos mensagens do syslog usando o visor de SYSLOG feito pelo apoio da série 2 Alguma ocorrência de prioridade 0, 1, e 2 sobre 100 ocorrências do nível 3 ou acima Revise o problema, crie bilhete de problema e envie caso uma nova ocorrência ou problema exija atenção
Erros de hardware (impactos forçados pelo hardware) Revisão diária dos mensagens do syslog usando o visor de SYSLOG feito pelo apoio da série 2 Alguma ocorrência de prioridade 0, 1, e 2 sobre 100 ocorrências do nível 3 ou acima Revise o problema, crie bilhete de problema e envie caso uma nova ocorrência ou problema exija atenção
Erros de protocolo (protocolos de IP Routing somente) Revisão diária dos mensagens do syslog usando o visor de SYSLOG feito pelo apoio da série 2 Dez mensagens por dia de prioridades 0, 1, e 2 sobre 100 ocorrências do nível 3 ou acima Revise o problema, crie bilhete de problema e envie caso uma nova ocorrência ou problema exija atenção
Erros de controle dos media (FDDI, POS, e Fast Ethernet somente) Revisão diária dos mensagens do syslog usando o visor de SYSLOG feito pelo apoio da série 2 Dez mensagens por dia de prioridades 0, 1, e 2 sobre 100 ocorrências do nível 3 ou acima Revise o problema, crie bilhete de problema e envie caso uma nova ocorrência ou problema exija atenção
Mensagens ambientais (potência e temp) Revisão diária dos mensagens do syslog usando o visor de SYSLOG feito pelo apoio da série 2 Alguma mensagem Crie a documentação de problema e a expedição para problemas novos
Erros de precisão (erros de entrada do link) Polling snmp nos eventos de limiar dos intervalos de 5-minuto recebidos pelo NOC Erro do erro de entrada ou de saída um em algum intervalo de 5-minuto em algum link Crie a documentação de problema para problemas e a expedição novos ao apoio da 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 de exceções, avaliação comparativa e tendência e análise “what if”. A definição nivelada de serviço define simplesmente os pontos iniciais do desempenho e do limiar de exceção de capacidade e os médios que iniciarão a investigação ou a elevação. Estes limiares podem, então, ser aplicados aos três processos de gerenciamento de desempenho e de capacidade de alguma maneira.

As definições de nível da capacidade e do serviço de desempenho podem ser divididas em diversas categorias: links de rede, dispositivos de rede, desempenho de ponta a ponta, e desempenho do aplicativo. Desenvolver definições niveladas de serviço nestas áreas exige o conhecimento técnico detalhado em relação aos aspectos específicos da capacidade de dispositivo, 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 e definiçõ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 o desempenho começa com uma compreensão geral de como estas condições de problema serão detectadas, de que os olharão, e o que acontecerão quando ocorrem. Você pode adicionar definiçõ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 a organizaçã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 criticalidade das informações de gerenciamento da rede equilibradas com a quantidade de trabalho proativo que o grupo de operações pode manipular efetivamente

  • Requisitos de treinamento para assegurar-se de que o pessoal de suporte compreenda as mensagens 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 de problema 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 de evento 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 enlace que fornece 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. Conforme definido anteriormente, podem ser necessários esforços adicionais da organização para garantir o sucesso.

Área de rede/media Método de detecção Limite Ação tomada
Backbone e links de distribuição do campus LAN Polling snmp em armadilhas da exceção dos intervalos RMON de 5-minuto no núcleo e nos links de distribuição utilização de 50% na utilização dos intervalos 90% de 5-minuto através da armadilha da exceção Notificação de E-mail ao grupo do email do desempenho aliás para avaliar a elevação do requisito de QoS ou do plano para questões repetidas
Links do WAN doméstico Eleição SNMP em intervalos de 5 minutos 75% de utilização em intervalos de 5 minutos Notificação de E-mail ao grupo do email do desempenho aliás para avaliar a elevação do requisito de QoS ou do plano para questões repetidas
Links de WAN do extranet Eleição SNMP em intervalos de 5 minutos utilização de 60% em intervalos de 5-minuto Notificação de E-mail ao grupo do email do desempenho aliás para avaliar a elevação do requisito de QoS ou do plano para questões repetidas

A tabela a seguir define definições niveladas de serviço para a capacidade de dispositivo e os limiares 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 muito importante pois problemas de recurso do plano de controle do dispositivo não verificados podem ter um impacto grave sobre a rede.

         
Cisco 7500 CPU, memória, bufferes Polling snmp na notificação rmon dos intervalos -5-minute para o CPU CPU em 75% durante intervalos de 5-minuto, 99% através da memória da notificação rmon em 50% durante bufferes dos intervalos de 5-minuto na utilização de 99% A notificação de E-mail ao grupo do email do desempenho e da capacidade aliás para resolver edições ou elevação RMON CPU do plano em 99%, documentação de problema do lugar e série 2 da página apoia o biper
Cisco 2600 CPU, memória Eleição SNMP em intervalos de 5 minutos CPU em 75% durante a memória dos intervalos de 5-minuto em 50% durante intervalos de 5-minuto Notificação de E-mail ao grupo do email do desempenho e da capacidade aliás para resolver edições ou elevação do plano
Catalyst 5000 Utilização de backplane, memória Eleição SNMP em intervalos de 5 minutos Backplane na memória da utilização de 50% na utilização de 75% Notificação de E-mail ao grupo do email do desempenho e da capacidade aliás para resolver edições ou elevação do plano
Switch ATM do ½ 1010 do ¿  de LightStreamï CPU, memória Eleição SNMP em intervalos de 5 minutos CPU na memória da utilização de 65% na utilização de 50% Notificação de E-mail ao grupo do email do desempenho e da capacidade aliás para resolver edições ou elevação do plano

A próxima tabela estabelece as definições de nível de serviço para desempenho e capacidade de ponta a ponta. Esses limiares geralmente se baseiam nos requisitos de aplicativo, mas também podem ser usados para indicar algum tipo de problema de desempenho de rede ou capacidade. A maioria de organizações com definições niveladas de serviço para o desempenho criam somente diversas definições de desempenho porque o desempenho de medição de cada ponto na rede a cada outro ponto exige recursos significativos e cria uma quantidade elevada de carga adicional de rede. Esses problemas de desempenho de ponta a ponta também podem ser obtidos em limiares de recurso de dispositivo ou enlace. Recomendamos definições gerais por área geográfica. Alguns locais ou links críticos podem ser adicionados caso necessário.

Área de rede/media Método de medida Limite Ação tomada
Campus LAN Nenhuns nenhum problema esperaram difícil medir o infra-estruturo de LAN inteiro Tempo de resposta de round trip de 10 milissegundos ou menos todas as vezes Notificação de E-mail ao grupo do email do desempenho e da capacidade aliás para resolver a elevação da edição ou do plano
Links do WAN doméstico Medição atual do SF ao NY e do SF a Chicago que usa somente o eco ICMP do Internet Performance Monitor (IPM) tempo de resposta round trip 75-millisecond calculado a média durante um período de 5-minuto Notificação de E-mail ao grupo do email do desempenho aliás para avaliar a elevação do requisito de QoS ou do plano para questões repetidas
San Francisco até Tóquio Medição atual de San Francisco a Bruxelas usando o IPM e o eco ICMP tempo de resposta round trip 250-millisecond calculado a média durante um período de 5-minuto Notificação de E-mail ao grupo do email do desempenho aliás para avaliar a elevação do requisito de QoS ou do plano para questões repetidas
San Francisco a Bruxelas Medição atual de San Francisco a Bruxelas usando o IPM e o eco ICMP tempo de resposta round trip 175-millisecond calculado a média durante um período de 5-minuto Notificação de E-mail ao grupo do email do desempenho aliás para avaliar a elevação do requisito de QoS ou do plano para questões repetidas

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

  • medidas e definições de nível de serviço podem ajudar a eliminar conflitos entre grupos.

  • as definições de nível de serviço dos aplicativos individuais são importantes quando o QoS está configurado para aplicativos chave e outro tráfego é 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 de rede e problemas de aplicativo ou servidor. Use sondas ou o software de agente de disponibilidade de sistema em execução nos Cisco routers e o Cisco IPM que controla o tipo de pacote e a freqüência de medição.

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

Aplicativo Método de medida Limite Ação tomada
Porta TCP 1529 Bruxelas do aplicativo de planejamento de recursos corporativos (ERP) ao SF Bruxelas a San Francisco usando o gateway de Bruxelas de medição do desempenho round trip da porta 1529 IPM ao gateway de SFO 2 tempo de resposta round trip 175-millisecond calculado a média durante um período de 5-minuto Notificação de E-mail ao grupo do email do desempenho aliás para avaliar a elevação do problema ou do plano para questões repetidas
Tóquio da porta TCP 1529 do aplicativo ERP ao SF Bruxelas a San Francisco usando o gateway de Bruxelas de medição do desempenho round trip da porta 1529 IPM ao gateway de SFO 2 tempo de resposta round trip 200-millisecond calculado a média durante um período de 5-minuto Notificação de E-mail ao grupo do email do desempenho aliás para avaliar a elevação do problema ou do plano para questões repetidas
Porta TCP 1702 Sydney do aplicativo de suporte de cliente ao SF Sydney a San Francisco usando o gateway de Sidney de medição do desempenho round trip da porta 1702 IPM ao gateway de SFO 1 tempo de resposta round trip 250-millisecond calculado a média durante um período de 5-minuto Notificação de E-mail ao grupo do email do desempenho aliás para avaliar a elevação do problema ou do plano para questões repetidas

Passo 6: Recolha o medidor e monitore-o

as definições de nível de serviço, por si só, são inúteis, a menos que a organização obtenha êxito de métricas e monitores. Em criar uma definição nivelada de serviço crítica, defina como o nível de serviço será medido e relatado. Medindo o nível de serviço determina se a organização está encontrando objetivos e igualmente identifica a causa de raiz da Disponibilidade ou dos problemas de desempenho. Igualmente considere o objetivo ao escolher um método medir a definiçã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 se conformam aos objetivos. Se não se conformam, determine a causa de raiz do problema e execute melhorias. Você também deve abranger as iniciativas e o progresso atuais no sentido de melhorar situações individuais.

Criando e mantendo SLA

as definições de nível de serviço são um excelente bloco de construção já que ajudam a criar um QoS consistente em toda a organização e ajuda a aprimorar a disponibilidade. A próxima etapa é os SLA, que são uma melhoria porque alinham objetivos de negócio e requisitos de custo diretamente para prestar serviços de manutenção à qualidade. O SLA bem-construído serve então como um modelo para a eficiência, a qualidade, e a sinergia entre a comunidade de usuário e o grupo de suporte mantendo processos claros e os procedimentos para questões de rede ou problemas.

Os SLA fornecem diversos benefícios:

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

  • Os SLAs ajudam a determinar as ferramentas e os recursos padrão necessários para atender às necessidades dos negócios. Decidindo quantos povos e que ferramentas se usar sem SLA é frequentemente uma suposição orçamental. O serviço pode estar com excesso de engenharia, o que leva ao gasto excessivo ou à subengenharia, que faz com que os objetivos comerciais não sejam atendidos. Ajustar os SLAs ajuda a alcançar esse nível ótimo de equilíbrio.

  • O SLA documentado cria um veículo mais explícito para a configuração das expectativas de 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 de definiçõ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.

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

Os peritos no desenvolvimento SLA TI identificaram três condições prévias a um SLA bem sucedido. Infelizmente, organizações que não alcançam esses objetivos podem esperar problemas com o processo SLA e devem considerar os possíveis problemas envolvidos com o processo SLA. Não executa SLA não é prejudicial se a organização de rede de comunicação pode 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:

  • Sua empresa deve ter uma cultura orientada para serviços.

    A organização deve colocar as necessidades dos clientes em primeiro lugar. É preciso um comprometimento completo com o 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 do cliente do serviço.

    Um outro indicador do serviço pode ser que a satisfação do serviço ou do apoio de estados da organização como um meta corporativa. Isto não é raro, pois as organizaçõ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 base nas necessidades do cliente e nos requisitos comerciais. Se as organizações não fizeram esta 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 a declaração de missão da empresa deve estar alinhada às iniciativas dos clientes e dos negócios, que impulsionam todas as atividades de TI, incluindo os SLAs. É muito comum que se crie uma rede para atender a um determinado objetivo, ainda que o grupo de rede de comunicação perca de vista esse objetivo e os requisitos de negócios subseqüentes. Nesses casos, um orçamento do grupo é atribuído à rede, que pode reagir de modo exagerado às necessidades atuais ou subestima brutamente a exigência, tendo por resultado 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 novos aplicativos, novos serviços e outros requisitos comerciais. A relação e o foco em visão geral comum no atendimento de metas corporativas estão presentes e todos os grupos funcionam como uma equipe.

  • Você deve comprometer ao processo SLA e ao contrato.

    O primeiro lá deve ser comprometimento para aprender o processo SLA desenvolver acordos efetivo. Segundo, você deve respeitar os requisitos de serviço do contrato. Não espere criar SLA poderosos sem a entrada e o comprometimento significativos de todos os indivíduos envolvidos. Este comprometimento deve igualmente vir de Gerenciamento e de todos os indivíduos associados 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, os elementos da administração de servidor, o apoio do help desk, os elementos de aplicativo, e o negócio ou as requisições de usuário. O Gerenciamento da cada área será envolvido normalmente no processo SLA. Este cenário funciona bem quando a organização está construindo SLAs básicos de suporte reativos. As organizações de empreendimento com requisitos de alta disponibilidade podem precisar a assistência técnica durante o processo SLA ajudar com edições como o orçamento de disponibilidade, as limitações de desempenho, a definição do perfil do aplicativo, ou as potencialidades de gerenciamento pró-ativo. Para mais aspectos de SLA do gerenciamento pró-ativo, nós recomendamos uma equipe técnica dos arquitetos de rede e dos arquitetos de aplicativo. A assistência técnica pode aproximar consideravelmente os recursos de disponibilidade e desempenho da rede e o que é necessário para alcançar objetivos específicos.

O provedor de serviços SLA não inclui normalmente a entrada de usuário porque são criados com o único objetivo de ganhar uma margem competitiva em outros provedores de serviços. Em alguns 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 internos de funcionários internos. Outros provedores de serviço irão se concentrar nos aspectos técnicos da melhoria de disponibilidade, criando definições de nível de serviço forte que são medidas e gerenciadas internamente. Em outros casos, ambos os esforços ocorrem simultaneamente 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. Alguns objetivos 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 o nível de suporte, como esse nível será medido, a progressão do caminho para a reconciliação do SLA e questões gerais de orçamento. Os elementos de serviço para ambientes de alta disponibilidade devem incluir definições de serviços proativos e objetivos reativos. Os detalhes adicionais incluem o seguinte:

  • Suporte no local durante o horário de trabalho e procedimentos para obter suporte fora desse horário

  • Definições de prioridade, incluindo o tipo de problema, o tempo máximo começar o trabalho no 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 de status 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 adicionais baseadas em exigências e em crítica de negócio do grupo de usuário. A organização de rede deve escutar proximamente estas exigências do negócio e desenvolver as soluções especializadas que cabem na estrutura de suporte total. Caber na cultura total do apoio é crítico porque é importante não criar um serviço principal pretendido somente para alguns individual ou em 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 na necessidade de negócio. Consulte os exemplos de requisitos de SLA a seguir para obter mais informações sobre necessidades de negócios específicos.

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

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

  • Requisitos de desempenho

  • Definições e requisitos de QoS

  • 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 de site WAN. A solução de platina seria fornecida com serviços T1 gêmeos para a estação. Um portador diferente forneceria cada linha T1. A estação deveria ter dois roteadores configurados de forma que, se qualquer T1 ou roteador falhasse, ela não sofreria nenhuma interrupção. O serviço do ouro teria dois Roteadores, mas o Backup do Frame Relay seria usado. Essa solução pode ter largura de banda limitada pela duração da interrupção. A solução de prata teria apenas um roteador e um serviço de portadora. Qualqueras um soluções seriam consideradas para níveis da prioridade diferentes para bilhetes do problema. Algumas organizações podem exigir uma solução de platina ou ouro se uma prioridade 1 ou 2 for necessária para uma falha. As organizações de cliente podem então financiar o nível do serviço que exigem. A tabela a seguir exibe um exemplo de organização que oferece três níveis de serviço, dependendo da necessidade de negócios para conectividade extranet.

Solução Platinum Ouro Prata
Dispositivos Roteadores redundantes para conectividade de WAN Roteador redundante para backup no site central Nenhuma Redundância do dispositivo
WAN Conectividade T1 redundante, portadores múltiplos Conectividade T1 com Backup do Frame Relay Nenhuma redundância de WAN
Requisitos de largura de banda e explosão T1 redundante com compartilhamento de carga para intermitência NON-carga que compartilha, Backup do Frame Relay para aplicativos críticos somente; Frame Relay 64K CIR somente UP para T1
Desempenho Tempo de resposta round trip 100-ms consistente ou menos Tempo de resposta de 100 ms ou menos. Esperado 99,9% Senhora do tempo de resposta 100 ou 99% menos previsto
Requisito de disponibilidade 99.99% 99.95% 99.9%
Prioridade do help desk quando para baixo Prioridade 1: business-critical service down Prioridade 2: serviço com impacto sobre os negócios inativo Prioridade 3: conectividade de negócio para baixo

Etapa 10: Compreender os Objetivos e as Necessidades de Negócios dos Clientes

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

O desenvolvedor do SLA também deve compreender os objetivos de negócios e o crescimento da organizaçã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ção tem perfis do aplicativo em cada aplicativo, mas se não, considere fazer uma avaliação técnica do aplicativo determinar problemas relacionados à rede.

Etapa 11: Defina o SLA exigido para cada grupo

Os SLAs de suporte principais devem incluir unidades de negócios críticas e representação de grupo funcional, como operações de rede, operações de servidor e grupos de suporte a aplicativos. Esses grupos devem ser reconhecidos com base nas necessidades comerciais, bem como sua parte no processo de suporte. Tendo a representação de muitas ajudas dos grupos igualmente crie uma solução de suport do total equitativo sem a preferência ou a prioridade do grupo individual. Isso pode levar uma organização de suporte a fornecer o serviço principal a grupos individuais, um cenário que talvez determine a cultura global de serviços da organização. Por exemplo, um cliente pôde insistir que seu aplicativo é o mais crítico dentro do corporaçõ quando na realidade os custos de tempo ocioso para esse aplicativo são significativamente menos do que outro em termos de rendimento perdido, de produtividade perdida, e de boa vontade do cliente perdida.

As unidades de negócio diferentes dentro da organização terão exigências diferentes. Uma meta do SLA de rede deve ser o acordo quanto a um formato geral que acomode diferentes níveis de serviço. Estas exigências são geralmente Disponibilidade, QoS, desempenho, e MTTR. No SLA de rede, estas variáveis são seguradas dando a prioridade aplicativos de negócio para QoS potencial que ajusta, definindo prioridades do help desk para o MTTR de edições deimpacto diferentes, e desenvolvendo uma matriz de solução que ajude a segurar a Disponibilidade e requisitos de desempenho diferentes. Um exemplo de uma matriz da solução simples para uma fábrica da empresa pode olhar algo como a tabela a seguir. Você pode adicionar informações sobre disponibilidade, QoS e desempenho.

Unidade de negócio Aplicativos Custos de tempo ocioso Prioridade do problema quando desativado Requisito de servidor/rede
Fabricação ERP Alto 1 Maior redundância
Suporte ao cliente Cuidado de cliente Alto 1 Maior redundância
Planejamento Servidor de arquivo, projeto ASIC Médio 2 Redundância central LAN
Mercado Servidor de arquivos Médio 2 Redundância central LAN

Etapa 12: Escolha o formato do SLA

O formato do SLA pode variar de acordo com os desejos do grupo ou com os requisitos organizacionais. O seguinte é um esboço recomendado do exemplo para o SLA de rede:

  1. Finalidade do acordo

    • Participantes do acordo

    • Objetivos e objetivos de acordo

  2. Serviços fornecidos e produtos suportados

    • Serviço Help-desk e rastreamento de chamada

    • Definições de seriedade de problema com base no impacto comercial para as definições MTTR

    • Prioridades do serviço crítico para negócio para definições de QoS

    • Categorias de solução definidas baseadas na Disponibilidade e nos requisitos de desempenho

    • Requisitos de treinamento

    • Exigências do planejamento da capacidade

    • Requisitos de escalação

    • Relatórios

    • Soluções de rede fornecidas

    • Pedidos novos da solução

    • Produtos não suportados ou aplicativos

  3. Políticas empresariais

    • Apoio durante horas de negócio

    • definições do apoio de Após-hora

    • Cobertura de feriado

    • Números de telefone do contato

    • Previsão de carga de trabalho

    • Resolução de injustiça

    • Critério de qualificação de serviço

    • Responsabilidades de segurança de usuário e grupo

  4. Procedimentos de gerenciamento de problemas

    • Iniciação de chamada (usuário e automatizado)

    • Resposta do primeiro nível e relação do reparo do atendimento

    • Rastreamento de chamada e mantimento de registro

    • Responsabilidades de chamador

    • Diagnóstico de problemas e requisitos de fechamento de chamada

    • Detecção do problema de gerenciamento de rede e resposta do serviço

    • Categorias ou definições da solução de problemas

    • Manipulação de problema crônica

    • Tratamento de chamada do problema crítico/exceção

  5. Objetivos de qualidade de serviço

    • Definições de qualidade

    • Definições de medição

    • Metas de qualidade

    • Tempo médio iniciar a definição de problema pela prioridade do problema

    • Tempo médio para solucionar o problema pela prioridade do problema

    • Tempo médio substituir o hardware pela prioridade do problema

    • Disponibilidade da rede e desempenho

    • Controlando a capacidade

    • Controlando o crescimento

    • Relatório de Qualidade

  6. Equipe e orçamentos

    • Modelos de grupo

    • Orçamento das operações

  7. Acordo de Manutenção

    • Programação da revisão da conformidade

    • Relatório e revisão do desempenho

    • Reconciliação de métricas de relatório

    • Atualizações periódicas SLA

  8. Aprovações

  9. Acessórios e exibições

    • Diagramas de fluxo de chamadas

    • Matriz de escalada

    • Matriz da solução de rede

    • Exemplos de relatório

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 do grupo. O grupo de trabalho pode incluir usuários ou gerentes de unidades de negócios ou grupos funcionais ou representantes de uma base geográfica. Esses indivíduos comunicam problemas de SLA para seus respectivos grupos de trabalho. Os gerentes e os responsáveis pelas decisões que podem concordar com os elementos-chave SLA devem participar. Esses indivíduos podem incluir ser indivíduos administrativos e técnicos capazes de ajudar a definir questões técnicas relativas ao SLA e tomar decisões no nível de TI (por exemplo, gerente de helpdesk, gerente de operações de servidor, gerentes de aplicativos e gerente de operações de rede).

O grupo de trabalho SLA de rede também deve ser formado por uma ampla representação de aplicativos e negócios de forma a chegar a um acordo acerca de uma SLA de rede que abranja vários aplicativos e serviços. O grupo de trabalho deve ter a autoridade para classificar processos críticos para negócio e serviços para a rede, assim como Disponibilidade e requisitos de desempenho para serviços individuais. Estas informações serão usadas para criar prioridades para diferentes tipos de problemas que causam impacto aos negócios, priorizar tráfego crítico aos negócios na rede e criar 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 deve expressar os objetivos, as iniciativas e os cronogramas para o SLA. Em seguida o grupo deve desenvolver planos específicos da tarefa e determinar programações e calendários para desenvolver e executar o SLA. O grupo deve igualmente desenvolver o processo do relatório para medir o nível de suporte contra critérios do apoio. A etapa final está criando o acordo do esboço SLA.

Inicialmente, o grupo de trabalho do SLA de rede deve se encontrar uma vez por semana para desenvolver o SLA. Depois que o SLA foi criado e aprovado, o grupo pode encontrar a revista mensal 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 etapa inclui:

  • Revendo o esboço

  • Negociando os índices

  • Editando e revisando o documento

  • 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 podem ser medidos. Tente apoiar os acordos de desempenho e disponibilidade com os de outras organizações relacionadas. Isto pode incluir definições de qualidade, definições de medição, e objetivos de qualidade. Lembre-se de que o serviço adicionado equivale a despesas adicionais. Certifique-se de que os grupos de usuário compreendem que os níveis adicionais do serviço custarão mais e os deixarão fazer a decisão se é uma exigência do negócio crítica. Você pode executar facilmente uma análise de custo em diversos aspectos do SLA, como tempo de substituiçã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 do processo SLA que ajudam a assegurar a consistência a longo prazo e os resultados. Nós recomendamos geralmente que todo o componente principal de um SLA seja mensurável e que uma metodologia de medição esteja posta no lugar antes da implementação do SLA. Então realize reuniões mensais entre o usuário e os grupos de suporte para rever as medidas, identifique causas de raiz do problema, e propõe soluções cumprir ou exceder o requisito de nível de serviço. Isto ajuda a fazer 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 uma organização pode avaliar seus SLA e seu Service Level Management total.

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

Os indicadores de desempenho do gerenciamento de Nível de Serviço fornecem um mecanismo para monitorar e melhorar os níveis de serviço como uma medida de sucesso. Isso permite que a organização reaja mais rapidamente aos problemas de serviço e compreenda mais facilmente problemas que afetam o serviço ou o custo de tempo ocioso em seu ambiente. Não medir definições niveladas de serviço igualmente nega todo o funcionamento pró-ativo positivo feito porque a organização é forçada em uma estância de reação. 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 requisito importante para o gerenciamento de nível de serviço, pois fornecem meios de compreender totalmente 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 uma análise de causa de raiz sobre os problemas e faz melhorias na qualidade, essa pode ser a melhor metodologia para melhorar a disponibilidade, o desempenho e a qualidade dos serviços disponíveis.

Por exemplo, considere o seguinte cenário real. A empresa X obtinha reclamações de usuário numerosas 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 locais MACILENTOS. A investigação mais próxima daquelas vistas revelou que a maioria dos problemas estavam em alguns locais MACILENTOS. A causa de raiz foi encontrada e a organização resolveu o problema. A organização define em seguida as metas de nível de serviço para disponibilidade e acordos realizados com o grupo de usuários. Problemas identificados das medições futuras rapidamente devido à NON-conformidade ao SLA. O grupo de rede de comunicação foi visto então como tendo o profissionalismo de nível superior, a experiência, e um ativo total à organização. O grupo foi efetivamente alterado de reativo para proativo em sua natureza e ajudou os resultados da empresa.

Infelizmente, a maior parte das organizações de rede atuais tem definições de nível de serviço limitadas e nenhum indicador de desempenho. Em consequência, passam a maioria de seu tempo que reage às reclamações de usuário ou aos problemas em vez dinamicamente de identificar 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 do SLA para determinar o êxito do processo de gerenciamento de nível de serviço:

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

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

  • Reuniões do Service Level Management da Rede de comunicação mensal para rever a conformidade do 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 do nível de serviços. As metas principais da definição do nível de serviço devem ser disponibilidade e desempenho porque são os requisitos principais para o usuário.

Objetivos secundários são importantes, pois ajudam a definir como os níveis de disponibilidade ou desempenho serão obtidos. Por exemplo, se a organização tem a disponibilidade agressiva e os destinos de desempenho, será importante impedir que os problemas ocorram e fixar rapidamente problemas quando ocorrem. Os objetivos secundários ajudam a definir os processos necessários conseguir a Disponibilidade e os níveis de desempenho desejados.

Metas secundárias reativas 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 de nível de serviço para objetivos principais, disponibilidade e desempenho deve incluir:

Objetivo

  • Como o objetivo será medido

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

  • Partes responsáveis por alvos de disponibilidade e desempenho

  • Processos não-compatíveis

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

A definição de nível de serviço para objetivos secundários reativos especifica como a organização responderá a problemas de rede ou de IT depois de identificados, incluindo:

  • Definições da prioridade do problema

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

  • 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 tempo concedido e ao que extensão aquela o responsável deve deixar cair suas tarefas atuais trabalhar nos problemas definidos. Como definições de nível do outro serviço, o documento do nível de serviço deve detalhar como os objetivos serão medidos, parties o responsável para a medida, e os processos não-compatíveis.

A definição de serviço para objetivos secundários pró-ativos define como a organização fornece suporte pró-ativo, incluindo a identificação de rede inativa, enlace inativo ou condições de inatividade do dispositivo, condições de erro de rede e limiares de capacidade de rede. Ajuste os objetivos que promovem o gerenciamento pró-ativo porque as ajudas do gerenciamento pró-ativo da qualidade eliminam problemas e as ajudas fixam problemas mais rapidamente. Normalmente, isso é feito definindo-se uma meta de quantos casos proativos serão criados e resolvidos sem notificação do usuário. Muitas organizações estabelecem uma bandeira no software do help desk para identificar por esse motivo casos pró-ativo contra casos reagente. O documento no nível de serviço deve conter também informações sobre como o objetivo será medido, as partes responsável pela medição e os processos de não conformidade.

Métricas de indicador de desempenho

Recomendamos sempre que toda meta de nível de serviço definido seja mensurável, permitindo à organização: medir os níveis de serviço, identificar problemas de serviço de causa principal que estejam impedindo o objetivo principal de disponibilidade e desempenho e fazer melhorias direcionadas a alvos específicos. Em geral, as métricas são simplesmente ferramentas que permitem aos gerentes de rede gerenciar a consistência do nível de serviço e fazer melhorias de acordo com os requisitos de negócios.

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

A Disponibilidade e o desempenho de medição são uma área negligenciada frequentemente no medidor do nível de serviço. As organizações bem-sucedidas com essas métricas usam dois métodos bastante simples. Um método é enviar os pacotes de ping do Protocolo de mensagens de controle da Internet (ICMP) de um local central na rede para as extremidades. Você também pode obter desempenho usando esse método. As organizações bem-sucedidas com esse método também agrupam dispositivos semelhantes em "grupos disponíveis", como dispositivos de LAN ou escritórios de campo domésticos. Isto é igualmente atrativo porque as organizações têm geralmente meta de nível de serviço diferentes para áreas geográficas ou críticos para negócio diferentes da rede. Permite que o grupo de métrica calcule a média de todos os dispositivos do grupo de disponibilidade para obter um resultado razoável.

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

Os objetivos de suporte reagente mensuráveis incluem:

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

  • 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 horário em que uma chamada foi inicialmente reportada (ou informada no banco 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

Essas métricas podem exigir influência de gerenciamento para a entrada consistente de problemas no banco de dados e para atualizá-los em tempo real. Em alguns casos, as organizações podem gerar automaticamente documentações de problema para eventos de rede ou pedidos do email. Isto ajuda a fornecer a precisão para identificar as horas inicial de um problema. Os relatórios gerados com base nesse tipo de métrica geralmente classificarão os problemas por prioridade, grupo de trabalho e separadamente para ajudar a determinar problemas em potencial.

Que mede o suporte pró-ativo processos é mais difícil porque o exige monitorar o funcionamento pró-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 de rede a um help desk, e quando relatam o problema, tomará claramente o tempo explicar o problema ou isolar o problema como sendo ligado à rede. Não todos os casos pró-ativo terão um efeito imediato na Disponibilidade e o desempenho devido à falha dos dispositivos redundantes ou dos links terá pouco impacto em utilizadores finais.

As organizações que implementam definições ou acordos de nível de serviço proativos o fazem por 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 casos reagente que são gerados por usuários. É uma boa ideia medir também a quantidade de casos pró-ativo na cada área. Essas categorias devem incluir dispositivos inativos, links inativos, erros de rede e violações de capacidade. Também é possível trabalhar um pouco utilizando a modelagem de disponibilidade e os casos proativos para determinar o efeito na disponibilidade 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 Level Management. Isso deve ser feito independentemente de os SLAs estarem ou não ocorrendo. Execute a revisão de gerenciamento do nível de serviço em uma reunião mensal com os responsáveis por medir e fornecer os níveis de serviço definidos. Os grupos de usuário podem igualmente estam presente quando os SLA são involvidos. O objetivo da reunião é revisar o desempenho 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 especificado

  • 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 conjunto atual de métricas.

Ao longo do tempo, a organização pode igualmente tender a conformidade do nível de serviço para determinar a eficácia do grupo. Este processo não é diferente de um círculo de qualidade ou processo de melhoria de qualidade. A reunião ajuda a abordar problemas individuais e determinar soluçõ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 modelo de suporte reagente para um modelo de suporte pró-ativo onde a disponibilidade da rede e os níveis de desempenho sejam determinados por exigências do negócio, não pelo grupo o mais atrasado de problemas. O processo ajuda a criar um ambiente de melhoria contínua de nível de serviço e de maior competitividade de negócios. O Service Level Management é igualmente o componente de gerenciamento o mais importante para o Gerenciamento de rede pró-ativo. Por este motivo, o Service Level Management é altamente recomendado em toda a fase do planejamento de rede e de projeto e deve começar com recentemente arquitetura de rede definida. Isto permite que a organização implemente soluções corretamente na primeira vez, com um mínimo de ociosidade ou retrabalho.


Informações Relacionadas


Document ID: 15117