Disponibilité : Haute disponibilité

Gestion de niveau de service : Livre blanc sur les pratiques recommandées

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document décrit la gestion de niveau de services et les accords de niveau de service (SLA) pour des réseaux à haute disponibilité. Cela inclut des facteurs de succès capital pour que la gestion et les indicateurs de performances de niveau de services aident à évaluer le succès. Le document fournit également le détail significatif pour les SLA qui suivent les indications des pratiques recommandées identifiées par l'équipe de service de haute disponibilité.

Aperçu de gestion des niveaux de service

Les organismes de réseau ont historiquement rencontré développer des spécifications du réseau en établissant les infrastructures réseau solides et en fonctionnant réactivement pour traiter des questions de service individuel. Quand une panne s'est produite, l'organisation établirait de nouveaux processus, capacités de Gestion, ou infrastructure qui pour empêcher une panne particulière de se produire de nouveau. Cependant, en raison d'un débit plus supérieur de modification et des exigences au niveau de la disponibilité croissantes, nous avons besoin maintenant d'un modèle amélioré pour empêcher proactivement l'interruption imprévue et pour réparer rapidement le réseau. Beaucoup le prestataire de service et les organisations d'entreprise ont tenté de définir mieux le niveau du service nécessaire pour atteindre des buts d'affaires.

Facteurs de succès capital

Des facteurs de succès capital pour le SLA sont utilisés pour définir des éléments principaux pour établir avec succès les niveaux de service accessibles et pour mettre à jour le SLA. Pour qualifier comme facteur de succès capital, un processus ou l'étape de processus doit améliorer la qualité de la Disponibilité de réseau de SLA et d'avantage en général. Le facteur de succès capital devrait également être mesurable ainsi l'organisation peut déterminer combien réussi elle a été relativement à la procédure définie.

Voyez mettre en application la Gestion de niveau de services pour plus de détails.

Indicateurs de performances

Les indicateurs de performances fournissent le mécanisme par lequel une organisation mesure des facteurs de succès capital. Vous passez en revue typiquement ces derniers sur une base mensuelle pour s'assurer que les définitions du niveau de service ou le SLA fonctionnent bien. Le groupe d'exploitations réseau et les groupes nécessaires d'outils peuvent exécuter les mesures suivantes.

Remarque: Pour des organismes sans SLA, nous vous recommandons exécutons des définitions du niveau de service et des examens de niveau de services en plus des mesures.

Les indicateurs de performances incluent :

  • Définition du niveau de service documentée ou SLA qui inclut la Disponibilité, la représentation, le temps de réponse du service réactif, les buts de la résolution des problèmes, et la retransmission des problèmes.

  • Téléconférence mensuelle d'examen de niveau de services de réseau pour passer en revue la conformité de niveau de services et pour implémenter des améliorations.

  • Les métriques de l'indicateur de performances, y compris la Disponibilité, représentation, temps de réponse de service par priorité, chronomètrent pour les résoudre par priorité, et d'autres paramètres SLA mesurables.

Voyez mettre en application le pour en savoir plus de Gestion de niveau de services.

Flux de traitement de la gestion du niveau de service

Le flux de processus à niveau élevé pour la Gestion de niveau de services contient deux groupes importants :

  1. Définir des niveaux de service réseau

  2. Création et mise à jour du SLA

Cliquez sur en fonction les objets dans le diagramme suivant pour visualiser les détails pour cette étape.

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

Mise en oeuvre de la Gestion de niveau de services

La mise en oeuvre de la Gestion de niveau de services se compose de seize étapes divisées en deux catégories principales suivantes :

Définir des niveaux de service réseau

Les gestionnaires de réseau doivent définir les principales règles par lesquelles le réseau est pris en charge, géré, et mesuré. Les niveaux de service fournissent des buts pour tout le personnel de réseau et peuvent être utilisés comme mesure de la qualité du service global. Vous pouvez également nous des définitions du niveau de service comme un outil pour économiser des ressources de réseau et comme preuves pour que la nécessité finance QoS plus élevé. Ils fournissent également une manière d'évaluer la représentation de constructeur et de transporteur.

Sans définition du niveau de service et mesure, l'organisation n'a pas des buts clairs. La satisfaction de service peut être régie par des utilisateurs avec peu de différentiation entre les applications, le serveur/exécutions de client, ou le support réseau. La budgétisation peut être plus difficile parce que le résultat final n'est pas clair à l'organisation, et en conclusion, l'organisme de réseau tend à être plus réactif, non proactif, en améliorant le modèle de réseau et de support.

Nous recommandons les étapes suivantes pour établir et prendre en charge un modèle de niveau de services :

  1. Analysez les objectifs et contrainte techniques.

  2. Déterminez la Disponibilité de budget.

  3. Créez les profils d'application détaillant des caractéristiques du réseau des applications stratégiques.

  4. Définissez la Disponibilité et les standards de performances et définissez les termes communs.

  5. Créez une définition du niveau de service qui inclut la Disponibilité, les performances, le temps de réponse de service, le moyenne temps aux résolutions des problèmes, la détection des pannes, les seuils de mise à jour, et le chemin d'escalade.

  6. Collectez les mesures et surveillez la définition du niveau de service.

Étape 1 : Analysez les objectifs et contrainte techniques

La meilleure manière de commencer analyser des objectifs et contrainte techniques est de faire un brainstorm ou rechercher des buts et des conditions requises techniques. Parfois il aide à inviter d'autres homologues techniques informatiques dans cette discussion parce que ces personnes ont des buts spécifiques liés à leurs services. Les buts techniques incluent la Disponibilité de niveaux, débit, jitter, retard, temps de réponse, conditions d'évolutivité, nouvelles introductions de caractéristique, nouvelles mises en place d'application, Sécurité, gestionnabilité, et même coût. L'organisation devrait alors étudier des contraintes à atteindre ces buts donnés les ressources disponibles. Vous pouvez créer des tableaux pour chaque but avec une explication des contraintes. Au commencement, il peut sembler comme si la plupart des buts ne sont pas réalisables. Commencez alors donner la priorité aux buts ou diminuer les attentes qui peuvent encore répondre à des exigences d'affaires.

Par exemple, vous pourriez avoir une Disponibilité de niveau de 99.999 pour cent, ou 5 minutes de temps d'arrêt par an. Il y a de nombreuses contraintes à atteindre ce but, tel que des points de défaillance unique dans le matériel, le matériel hors service du temps moyen de réparation (durée moyenne de reprise) dans les sites distants, la fiabilité de transporteur, les capacités proactives de détection des pannes, les débits élevés de modification, et les limites de capacité du réseau en cours. En conséquence, vous pouvez ajuster le but à un niveau plus réalisable. La Disponibilité de modèle dans la section suivante peut vous aider a fixé des buts réalistes.

Vous pouvez également penser à la fourniture plus facilement disponible dans certaines zones du réseau qui ont moins contraintes. Quand l'organisation de mise en réseau édite des normes de service pour la Disponibilité, les services dans l'organisation peuvent trouver le niveau inacceptable. C'est alors un point naturel pour commencer des discussions de SLA ou le financement/modèles de budgétisation qui peuvent réaliser les conditions requises d'affaires.

Travaillez pour identifier tous les contraintes ou risques impliqués en atteignant le but technique. Donnez la priorité aux contraintes en termes de plus grand risque ou incidence au but désiré. Ceci aide l'organisation à donner la priorité à des initiatives d'amélioration de réseau et à déterminer comment facilement la contrainte peut être adressée. Il y a trois genres de contraintes :

  • Technologie de réseau, résilience, et configuration

  • Pratiques en matière de cycle de vie, y compris la planification, la conception, l'implémentation, et l'exécution

  • Charge ou comportement de l'application de la circulation en cours

La technologie de réseau, la résilience, et les contraintes de configuration sont tous les limites ou risques associés avec la technologie, le matériel, les liens, la conception, ou la configuration en cours. Les limites de technologie couvrent n'importe quelle contrainte posée par la technologie elle-même. Par exemple, aucune technologie en cours ne tient compte des temps de convergence fraction de seconde dans les environnements de réseau redondant, qui peuvent être essentiels pour les connexions vocales soutenantes à travers le réseau. Un autre exemple peut être la vitesse crue que les données peuvent traverser sur les liens terrestres, qui sont approximativement 100 milles par milliseconde.

Les investigations de risque de résilience de matériel réseau devraient se concentrer sur la topologie, la hiérarchie, la modularité, la Redondance, et le MTBF de matériel le long des chemins définis dans le réseau. Les contraintes de liaison réseau devraient se concentrer sur des liaisons réseau et la Connectivité de transporteur pour des organisations d'entreprise. Les contraintes de lien peuvent inclure la Redondance et la diversité de lien, des limites de medias, câblant des infrastructures, la Connectivité de boucle locale, et la Connectivité de fond. Les contraintes de conception associent à l'examen médical ou à la conception logique du réseau et incluent tout de l'espace disponible pour le matériel à l'évolutivité de l'implémentation de protocole de routage. Toutes les conceptions de protocole et de medias devraient être considérées par rapport à la configuration, à la Disponibilité, à l'évolutivité, à la représentation, et à la capacité. Des contraintes de service réseau telles que le protocole DHCP (DHCP), le Système de noms de domaine (DNS), les Pare-feu, les convertisseurs de protocole, et les convertisseurs d'adresse réseau devraient également être considérées.

Les pratiques en matière de cycle de vie définissent les processus et la Gestion du réseau utilisé pour déployer uniformément des solutions, pour détecter et réparer des problèmes, pour empêcher la capacité ou les problèmes de performances, et pour configurer le réseau pour la cohérence et la modularité. Vous devez considérer cette zone parce que l'expertise et le processus sont typiquement les plus grands contributeurs à la non-disponibilité. Le cycle de vie du réseau se rapporte au cycle de la planification, de la conception, de l'implémentation, et des exécutions. Dans chacune de ces zones, vous devez comprendre la fonctionnalité de Gestion de réseau telle que la Gestion des performances, la gestion de la configuration, la Gestion de défaut, et la Sécurité. Une estimation de cycle de vie du réseau est fournie par des services de services à haute disponibilité NSA de Cisco (A) affichant des contraintes de disponibilité de réseau en cours associées avec des pratiques en matière de cycle de vie du réseau.

Les contraintes en cours de charge ou d'application de la circulation se rapportent simplement à l'incidence du trafic en cours et des applications.

Malheureusement, beaucoup d'applications ont des contraintes significatives qui exigent la Gestion soigneuse. Le jitter, le retard, le débit, et les bandes passantes nécessaires pour des applications en cours ont typiquement beaucoup de contraintes. La manière que l'application a été écrite peut également créer des contraintes. Le profilage d'application vous aide mieux à comprendre ces questions ; la section suivante couvre cette caractéristique. La Disponibilité, le trafic, la capacité, et la combinaison en cours de investigation de représentation aide également des gestionnaires de réseau à comprendre des attentes en cours et des risques de niveau de services. Ceci est typiquement accompli avec un processus appelé la création des bases du réseau, qui aide à définir des performances du réseau, la Disponibilité, ou des moyennes de capacité pendant un délai prévu défini, normalement environ un mois. Ces informations sont normalement utilisées pour la planification de capacité et tendre, mais peuvent également être utilisées pour comprendre des questions de niveau de services.

Le tableau suivant utilise le but/méthode ci-dessus de contrainte pour le but d'exemple d'empêcher une attaque de Sécurité ou l'attaque du déni de service (DOS). Vous pouvez également employer ce tableau pour aider à déterminer la couverture des services pour réduire des attaques de Sécurité.

Risque ou contrainte Type de contrainte Impact potentiel
Les outils disponibles de détection DOS ne peuvent pas détecter tous les types d'attaques DoS. Technologie/résilience Haute
N'ayez pas le personnel et le processus requis à réagir aux alertes. Pratiques en matière de cycle de vie Haute
Les stratégies en cours d'accès au réseau ne sont pas en place. Pratiques en matière de cycle de vie Support
La connexion Internet en cours de bas-bande passante peut être un facteur si l'encombrement de bande passante est utilisé pour l'attaque. Capacité du réseau Support
Actuellement la configuration de sécurité à aider à empêcher des attaques peut ne pas être complète. Technologie/résilience Support

Étape 2 : Déterminez la Disponibilité de budget

Une Disponibilité de budget est la Disponibilité théorique prévue du réseau entre deux points définis. Les informations théoriques précises sont utiles de plusieurs manières :

  • L'organisation peut utiliser ceci pendant qu'un but pour la Disponibilité interne et les déviations peut être rapidement défini et remédié à.

  • Les informations peuvent être utilisées par des planificateurs de réseau pour déterminer la Disponibilité du système pour aider à assurer la conception répondront à des exigences d'affaires.

Les facteurs qui contribuent au temps de non-disponibilité ou de panne incluent la défaillance matérielle, la panne de logiciel, l'alimentation et les problèmes environnementaux, la panne de lien ou de transporteur, la conception de réseaux, l'erreur humaine, ou le manque de processus. Vous devriez étroitement évaluer chacun de ces paramètres en évaluant la Disponibilité globale de budget pour le réseau.

Si l'organisation mesure actuellement la Disponibilité, vous ne pouvez pas avoir besoin d'une Disponibilité de budget. Employez la Disponibilité de mesure comme spécification de base pour estimer le niveau de service en cours utilisé pour une définition du niveau de service. Cependant, vous pouvez être intéressé à comparer les deux pour comprendre la Disponibilité théorique potentielle comparée au résultat mesuré par effectif.

La Disponibilité est la probabilité qu'un produit ou un service actionnera quand nécessaire. Voyez les définitions suivantes :

  1. Disponibilité

    • 1 - (total) de temps de panne de connexion/(temps de connexion en service total)

    • 1 - [sigma (connexions numériques affectées dans la durée de panne i X de] de panne i)/(conns numériques dans le délai de fonctionnement de service X)

  2. Indisponibilité

    1 - Disponibilité, ou temps de connexion de panne de total dû à (défaillance matérielle, panne de logiciel, questions environnementales et d'alimentation, panne de lien ou de transporteur, conception de réseaux, ou erreur utilisateur et défaillance de processus)

  3. Disponibilité matérielle

    La première zone à étudier est défaillance matérielle potentielle et l'effet sur l'indisponibilité. Pour déterminer ceci, les besoins d'organisation comprendre le MTBF de toutes les parties du réseau et de la durée moyenne de reprise pour des problèmes matériels pour tous les périphériques dans un chemin entre deux points. Si le réseau est modulaire et hiérarchique, la disponibilité matérielle sera identique entre deux points presque quelconques. Les informations MTBF sont disponibles pour tous les composants de Cisco et sont disponibles sur demande à un gestionnaire de comptes locaux. Le NSA de Cisco A le programme utilise également un outil pour aider à déterminer la disponibilité matérielle le long des chemins réseau, même lorsque la Redondance de module, la Redondance de châssis, et la redondance de chemin existent dans le système. Un principal facteur de fiabilité de matériel est la durée moyenne de reprise. Les organismes devraient évaluer à quelle rapidité ils peuvent réparer le matériel hors service. Si l'organisation n'a aucun plan économiquement et se fonde sur un accord standard de Cisco SMARTnet?, alors le temps de remplacement moyen potentiel est approximativement 24 heures. Dans un environnement typique de RÉSEAU LOCAL avec la redondance centrale et aucune Redondance d'accès, la Disponibilité approximative est de 99.99 pour cent avec une durée moyenne de reprise de quatre heures.

  4. Disponibilité logicielle

    La prochaine zone pour l'enquête est défectueuse des pannes de logiciel. Pour la mesure, Cisco définit des pannes de logiciel comme coldstarts de périphérique dus à l'erreur logicielle. Cisco a accompli la progression significative vers la disponibilité logicielle de compréhension ; cependant, de plus nouvelles releases prennent du temps de mesurer et sont considérées moins disponible que le logiciel de déploiement général. Le logiciel de déploiement général, tel que la version IOS 11.2(18), a été mesuré à plus de 99.9999 pour cent de Disponibilité. Ceci est calculé a basé sur des coldstarts réels sur des Routeurs de Cisco utilisant six minutes comme temps de réparation (heure pour que le routeur recharge). On s'attend à ce que des organismes avec un grand choix de versions aient légèrement la disponibilité inférieure en raison de la complexité ajoutée, de l'Interopérabilité, et des temps de panne accrus. On s'attend à ce que des organismes avec les dernières versions de logiciel aient une non-disponibilité plus élevée. La distribution pour la non-disponibilité est également assez large, signifiant que les clients pourraient éprouver la non-disponibilité significative ou la Disponibilité près d'une version de déploiement général.

  5. Ambiant et disponibilité en matière d'alimentation électrique

    Vous devez également considérer les questions environnementales et d'alimentation dans la Disponibilité. Les problèmes environnementaux associent à la répartition des systèmes de refroidissement requis pour garder le matériel à une température de fonctionnement spécifiée. Beaucoup de périphériques de Cisco s'arrêteront simplement quand ils sont considérablement hors de spécification plutôt que risquant des dommages à tout le matériel. Afin d'une Disponibilité de budget, l'alimentation sera utilisée parce que c'est la principale cause de la non-disponibilité dans cette zone.

    Bien que les pannes d'alimentation soient un important aspect de déterminer la Disponibilité de réseau, cette discussion est limitée parce que l'analyse d'alimentation théorique ne peut pas être exactement faite. Quelle organisation doit évaluer est une mesure approximative de disponibilité en matière d'alimentation électrique à ses périphériques basés sur l'expérience de sa zone géographique, capacités de sauvegarde d'alimentation, et processus mis en application pour assurer la qualité d'alimentation cohérente à tous les périphériques.

    Pour une évaluation conservatrice, nous pouvons dire qu'une organisation avec des générateurs de sauvegarde, des systèmes de non interruptible-alimentation-approvisionnement (UPS), et des processus d'implémentation d'alimentation de qualité peut éprouver six 9s de Disponibilité, ou 99.9999 pour cent, tandis que les organismes sans ces systèmes peuvent éprouver la Disponibilité à 99.99 pour cent, ou approximativement 36 minutes de temps d'arrêt annuellement. Naturellement vous pouvez ajuster ces valeurs à des valeurs plus réalistes basées sur les données de la perception ou de l'effectif de l'organisation.

  6. Panne de lien ou de transporteur

    Les pannes de lien et de transporteur sont des facteurs importants au sujet de Disponibilité dans les environnements WAN. Maintenez dans l'esprit que les environnements WAN sont de simplement autres réseaux qui sont sujet à la même Disponibilité de questions que le réseau de l'organisation, y compris la défaillance matérielle, la panne de logiciel, l'erreur utilisateur, et la panne d'alimentation.

    Beaucoup de réseaux d'opérateur ont déjà exécuté une Disponibilité de budget sur leurs systèmes, mais obtenir ces informations peut être difficile. Maintenez dans l'esprit que les transporteurs ont également fréquemment la Disponibilité de niveaux de garantie qui ont peu ou pas de base sur une Disponibilité réelle de budget. Ces niveaux de garantie lancent parfois simplement et des méthodes sur le marché de ventes utilisés pour favoriser le transporteur. Dans certains cas, ces réseaux éditent également la Disponibilité de statistiques qui semblent extrêmement bons. Maintenez dans l'esprit que ces les statistiques peuvent s'appliquer seulement à de principaux réseaux complètement redondants et ne factorisent pas dans la non-disponibilité due à l'accès de boucle locale, qui est un acteur essentiel à la non-disponibilité dans les réseaux BLÊMES.

    La création d'une évaluation de Disponibilité pour des environnements WAN devrait être basée sur les informations de la porteuse réelles et le niveau de la Redondance pour la connectivité WAN. Si une organisation a de plusieurs équipements d'entrée de bâtiment, fournisseurs redondants de boucle locale, accès local de Réseau optique synchrone (SONET), et opérateurs interurbains redondants avec la diversité géographique, la Disponibilité BLÊME sera considérablement améliorée.

    Le service de téléphonie est une Disponibilité assez précise de budget pour la connexion réseau non-redondante dans les environnements WAN. La Connectivité de bout en bout pour des téléphones a une Disponibilité approximative de budget de 99.94 pour cent utilisant une Disponibilité de méthodologie de budget semblable à celle décrite dans cette section. Cette méthodologie a été utilisée avec succès dans des environnements de données avec seulement la légère variation, et actuellement est utilisée comme cible dans la spécification de PacketCable pour des réseaux câblés de prestataire de service. Si nous nous appliquons cette valeur à un système complètement redondant, nous pouvons supposer que la Disponibilité BLÊME sera proche de 99.9999-percent disponible. Naturellement très peu d'organismes ont les systèmes BLÊMES complètement redondants et géographiquement dispersés en raison des dépenses et la Disponibilité, ainsi utilisez le jugement approprié concernant cette capacité.

    Les pannes de lien dans un environnement de RÉSEAU LOCAL sont moins probables. Cependant, les planificateurs peuvent vouloir assumer un peu d'interruption liée aux connecteurs cassés ou lâches. Pour des réseaux de RÉSEAU LOCAL, une évaluation prudente est la Disponibilité approximativement 99.9999-percent, ou environ 30 secondes par an.

  7. Conception réseau

    La conception de réseaux est un autre acteur essentiel à la Disponibilité. les conceptions Non-extensibles, les erreurs de conception, et le temps de convergence sur le réseau tous affectent négativement la Disponibilité.

    Remarque: Aux fins de ce document, la conception non-extensible ou les erreurs de conception sont incluses dans la section suivante.

    La conception de réseaux est alors limitée à une valeur mesurable basée sur l'échec logiciel et matériel dans le réseau entraînant le reroutage du trafic. Cette valeur typiquement s'appelle le « temps de basculement système » et est un facteur des capacités autocuratives de protocole dans le système.

    Calculez la Disponibilité par simplement suivre les mêmes méthodes pour des calculs de système. Cependant, c'est non valide à moins que le temps de commutation de réseau réponde à des exigences d'application réseau. Si le temps de commutation est acceptable, retirez-le du calcul. Si le temps de commutation n'est pas acceptable, alors vous devez l'ajouter aux calculs. Un exemple pourrait être la voix sur ip (VoIP) dans un environnement où le temps de commutation prévu ou réel est de 30 secondes. Dans cet exemple, les utilisateurs arrêteront simplement le téléphone et l'essayeront probablement de nouveau. Les utilisateurs verront certainement cette période comme non-disponibilité, pourtant on ne l'a pas estimé dans la Disponibilité de budget.

    Calculez la non-disponibilité due au temps de basculement système en regardant la disponibilité logicielle et matérielle théorique le long des chemins redondants, parce que le basculement se produira dans cette zone. Vous devez connaître le nombre de périphériques qui peuvent échouer et entraîner le basculement dans le chemin redondant, le MTBF de ces périphériques, et le temps de commutation. Un exemple simple serait un MTBF de 35,433 heures pour chacun de deux périphériques identiques redondants et d'un temps de commutation de 30 secondes. Divisant 35,433 par 8766 (des heures par an ramenées à une moyenne pour inclure des années bissextiles), nous voyons que le périphérique échouera une fois tous les quatre ans. Si nous utilisons 30 secondes comme temps de commutation, nous pouvons alors supposer que chaque périphérique éprouvera, en moyenne, 7.5 secondes par an de non-disponibilité due au basculement. Puisque les utilisateurs peuvent traverser l'un ou l'autre de chemin, le résultat est alors doublé à 15 secondes par an. Quand ceci est calculé en termes de secondes par an, la quantité de Disponibilité due au basculement peut être calculée en tant que Disponibilité 99.99999785-percent dans ce système simple. Ceci peut être plus élevé dans d'autres environnements en raison du nombre de périphériques redondants dans le réseau où le basculement est un potentiel.

  8. Erreur utilisateur et processus

    L'erreur utilisateur et la Disponibilité de questions de processus sont les principales causes de la non-disponibilité dans l'entreprise et les réseaux d'opérateur. Approximativement 80 pour cent de non-disponibilité se produisent en raison des questions telles que ne pas détecter des erreurs, des pannes de modification, et des problèmes de performances.

    Les organismes ne voudront simplement pas utiliser quatre fois toute autre non-disponibilité théorique en déterminant la Disponibilité de budget, pourtant les preuves suggèrent uniformément que ce soit le cas dans beaucoup d'environnements. La section suivante couvre cet aspect de la non-disponibilité plus complètement.

    Puisque vous ne pouvez pas théoriquement calculer la quantité de non-disponibilité due à l'erreur utilisateur et au processus, nous vous recommandons retirons ceci retiré de la Disponibilité de budget et que les organismes essayent d'obtenir la perfection. L'une mise en garde est que les organismes doivent comprendre le risque en cours à la Disponibilité dans leurs propres processus et niveaux d'expertise. Une fois que vous comprenez mieux ces risques et inhibiteurs, les planificateurs de réseau peuvent souhaiter factoriser dans une certaine quantité de non-disponibilité due à ces questions. Le NSA de Cisco A le programme étudie ces questions et peut aider des organismes à comprendre la non-disponibilité potentielle devant traiter, l'erreur utilisateur, ou les questions d'expertise.

  9. Détermination du budget final de disponibilité

    Vous pouvez déterminer la Disponibilité globale de budget en multipliant la Disponibilité pour chacune des zones précédemment définies. Ceci est typiquement fait pour les environnements homogènes où la Connectivité est semblable entre deux points quelconques, tels qu'un environnement de LAN modulaire hiérarchique ou un environnement WAN standard hiérarchique.

    Dans cet exemple, la Disponibilité de budget est faite pour un environnement de LAN modulaire hiérarchique. L'environnement utilise des générateurs de sauvegarde et LÈVE des systèmes pour toutes les parties du réseau et gère correctement l'alimentation. L'organisation n'utilise pas le VoIP et ne souhaite pas factoriser dans le temps de commutation de logiciel. Les évaluations sont :

    • Disponibilité de chemin de matériel entre deux points d'extrémité = 99.99 pour cent de Disponibilité

    • Disponibilité logicielle utilisant la fiabilité de logiciel GD comme référence = 99.9999 pour cent de Disponibilité

    • Ambiant et disponibilité en matière d'alimentation électrique avec des systèmes de sauvegarde = 99.999 pour cent de Disponibilité

    • Joignez la panne dans l'environnement de RÉSEAU LOCAL = 99.9999 pour cent de Disponibilité

    • Temps de basculement système non factorisé = 100 pour cent de Disponibilité

    • L'erreur utilisateur et la Disponibilité de processus ont assumé des = 100 pour cent parfaits de Disponibilité

    Le budget final de disponibilité que les organismes devraient essayer d'obtenir des égaux 0.9999 x 0.999999 x 0.999999 x 0.999999 = 0.999896, ou 99.9896 pour cent de Disponibilité. Si nous factorisons dans la non-disponibilité potentielle due à l'utilisateur ou à l'erreur de processus et supposons que la non-disponibilité est la Disponibilité 4X due aux facteurs techniques, nous pourrions supposer que la Disponibilité de budget est de 99.95 pour cent.

    Cette analyse d'exemple indique alors que la Disponibilité de RÉSEAU LOCAL tomberait en moyenne entre 99.95 et 99.989 pour cent. Ces nombres peuvent maintenant être utilisés comme objectif du niveau de service pour l'organisation de mise en réseau. Vous pouvez gagner la valeur supplémentaire en mesurant la Disponibilité dans le système et la détermination quel pourcentage de non-disponibilité était due à chacune des six zones ci-dessus. Ceci permet à l'organisation pour évaluer correctement des constructeurs, des transporteurs, des processus, et le personnel. Le nombre peut également être utilisé pour placer des attentes dans l'entreprise. Si le nombre est inacceptable, alors des ressources supplémentaires en budget pour gagner les niveaux désirés.

    Il peut être utile que les gestionnaires de réseau comprennent le temps d'arrêt à n'importe quelle Disponibilité particulière de niveau. Le temps d'arrêt en quelques minutes pendant une période d'une année, indiquées n'importe quelle Disponibilité de niveau, est :

    Minutes de temps d'arrêt pendant une année = 525600 - (Disponibilité de niveau X 5256)

    Si vous utilisez la Disponibilité de niveau de 99.95 pour cent, ceci établit pour être égal à 525600 - (99.95 x 5256), ou 262.8 minutes de temps d'arrêt. Pour la Disponibilité ci-dessus de définition, c'est égal au temps d'arrêt moyen pour toutes les connexions en service dans le réseau.

Étape 3 : Créez les profils d'application

Aide de profils d'application que l'organisation de mise en réseau comprennent et définissent des conditions requises de niveau de service réseau pour des applications individuelles. Ceci aide à s'assurer que les conditions requises et les services réseau d'application individuelle de supports réseau globalement. Les profils d'application peuvent également servir de spécification de base documentée au support de service réseau quand point d'application ou de groupes de serveurs au réseau comme problème. Finalement, les profils d'application aident à aligner des objectifs des services réseau avec des conditions requises d'application ou d'affaires en comparant des conditions requises d'application telles que la représentation et la Disponibilité aux objectifs des services réseau réalistes ou aux limites en cours. C'est important non seulement pour la Gestion de niveau de service, mais également pour la conception de réseaux hiérarchisée globale.

Créez les profils d'application quand vous introduisez de nouvelles applications au réseau. Vous pouvez avoir besoin d'un accord entre le groupe d'applications, les groupes d'administration de serveur, et le réseau informatiques d'aider à imposer la création de profil d'application pour nouveau et des services existants. Profils complets d'application pour des applications métier et des applications système. Les applications métier peuvent inclure le courrier électronique, le transfert de fichiers, la navigation web, l'imagerie médicale, ou la fabrication. Les applications système peuvent inclure la distribution logicielle, l'authentification de l'utilisateur, la sauvegarde de réseau, et la Gestion de réseau.

Un analyste réseau et une application ou une application de support de serveur devraient créer le profil d'application. Les nouvelles applications peuvent exiger l'utilisation d'un analyseur de protocole et d'un émulateur de WAN avec l'émulation de retard de caractériser correctement des conditions requises d'application. Ceci aide à identifier la bande passante nécessaire, le délai maximal pour la facilité d'utilisation d'application, et les conditions requises de jitter. Ceci peut être fait dans un environnement de travaux pratiques tant que vous avez les serveurs priés. Dans d'autres cas, comme avec le VoIP, des spécifications du réseau comprenant le jitter, le retard, et la bande passante sont bien édités et l'essai en laboratoire ne sera pas nécessaire. Un profil d'application devrait inclure les articles suivants :

  • Nom d'application

  • Type d'application

  • Nouvelle application ?

  • Importance d'affaires

  • Exigences au niveau de la disponibilité

  • Protocoles et ports utilisés

  • Bande passante prévue d'utilisateur (Kbps)

  • Nombre et emplacement des utilisateurs

  • Conditions requises de transfert de fichiers (temps y compris, volume, et points finaux)

  • Incidence de panne de réseau

  • Retard, jitter, et exigences au niveau de la disponibilité

Le but du profil d'application est de comprendre des conditions requises d'affaires pour l'application, le degré d'importance pour l'entreprise, et les spécifications du réseau telles que la bande passante, le retard, et le jitter. En outre, l'organisation de mise en réseau devrait comprendre l'incidence du temps d'arrêt de réseau. Dans certains cas, vous aurez besoin des reprises d'application ou de serveur qui ajoutent de manière significative au temps d'arrêt global d'application. Quand vous vous terminez le profil d'application, vous pouvez comparer des capacités globales de réseau et aider à aligner des niveaux de service réseau avec des conditions requises d'affaires et d'application.

Étape 4 : Définissez la Disponibilité et les standards de performances

La Disponibilité et les standards de performances ont placé les attentes de service pour l'organisation. Ceux-ci peuvent être définis pour différents domaines d'applications de réseau ou de particularité. La représentation peut également être définie en termes de délai d'aller-retour, jitter, débit maximal, engagements de bande passante, et évolutivité globale. En plus de placer les attentes de service, l'organisation devrait également prendre le soin de définir chacune des normes de service de sorte que l'utilisateur et les groupes de service informatique fonctionnant avec le réseau comprennent entièrement le service standard et comment il associe à leurs conditions requises d'application ou d'administration de serveur. Les groupes d'utilisateur et de service informatique devraient également comprendre comment la norme de service pourrait être mesurée.

Les résultats des étapes précédentes de définition du niveau de service aideront à créer la norme. En ce moment, l'organisation de mise en réseau devrait avoir une compréhension claire des risques et des contraintes en cours dans le réseau, une compréhension du comportement de l'application, et une Disponibilité théorique d'analyse ou base de disponibilité.

  1. Définissez les domaines géographiques ou d'application où les normes de service seront appliquées.

    Ceci peut inclure des zones telles que le RÉSEAU LOCAL de campus, le WAN classique, l'extranet, ou la Connectivité de partenaire. Dans certains cas, l'organisation peut avoir des buts de niveau de service différent à moins d'une zone. Ce n'est pas rare pour l'entreprise ou les organisations du fournisseur de service. Dans des ces cas, il ne serait pas rare de créer des normes de niveau de service différent basées sur des exigences de service individuel. Ceux-ci peuvent être classifiés comme or, argent, et normes de service de bronze à moins d'une géographique ou de zone de service.

  2. Définissez les paramètres de norme de service.

    La Disponibilité et le délai d'aller-retour sont les normes de service réseau les plus communes. Le débit maximal, l'engagement de bande passante minimale, le jitter, les taux d'erreur acceptables, et les capacités d'évolutivité peuvent également être inclus comme nécessaires. Faites attention en passant en revue le paramètre de service pour des méthodes de mesure. Si le paramètre passe à l'SLA, l'organisation devrait penser à la façon dont le paramètre de service pourrait être mesuré ou justifié quand les problèmes ou les désaccords de service se posent.

Après que vous définissiez les zones de service et les paramètres de service, employez les informations des étapes précédentes pour établir une matrice des normes de service. L'organisation devra également définir les zones qui peuvent être embrouillantes aux utilisateurs et aux groupes de service informatique. Par exemple, le temps de réponse maximal sera très différent pour un ping en aller-retour que pour enfoncer la touche Enter à un site distant pour une application spécifique. Le tableau suivant affiche les objectifs de performances dans les Etats-Unis.

Région de réseau Disponibilité de cible Méthode de mesure Cible moyenne de temps de réponse du réseau Temps de réponse maximum reçu Méthode de mesure du temps de réponse
RÉSEAU LOCAL 99.99% Minutes d'utilisateur concernées Au-dessous de 5 ms 10 ms Réponse ping en aller-retour
WAN 99.99% Minutes d'utilisateur concernées Au-dessous de 100 ms (ping en aller-retour) 150 ms Réponse ping en aller-retour
WAN essentiel et extranet 99.99% Minutes d'utilisateur concernées Au-dessous de 100 ms (ping en aller-retour) 150 ms Réponse ping en aller-retour

Étape 5 : Définissez le service réseau

C'est la dernière étape vers la Gestion de niveau de service de base ; il définit les processus et les capacités d'administration de réseau réactifs et proactifs que vous implémentez pour atteindre des objectifs du niveau de service. Le document final s'appelle typiquement un plan de support d'exécutions. La plupart des plans de support d'application incluent seulement des conditions requises de support réactif. Dans les environnements à haute disponibilité, l'organisation doit également considérer les processus d'administration proactive qui seront utilisés pour isoler et des problèmes de réseau de résolution avant que des appels de service d'utilisateur soient initiés. De façon générale, le document final devrait :

  • Décrivez le processus réactif et proactif utilisé pour atteindre l'objectif du niveau de service

  • Comment le processus de service sera géré

  • Comment le processus de but de service et de service sera mesuré.

Cette section contient des exemples pour que des définitions et des définitions de service anticipé réactives de service considèrent pour des beaucoup le prestataire de service et les organisations d'entreprise. Le but en établissant les définitions du niveau de service est de créer un service qui atteindra la Disponibilité et les objectifs en matière de performances. Pour accomplir ceci, l'organisation doit établir le service avec les contraintes techniques en cours, la Disponibilité de budget, et les profils d'application à l'esprit. Spécifiquement, l'organisation devrait définir et établir un service qu'uniformément et rapidement identifie et résout des problèmes dans des périodes allouées par la Disponibilité de modèle. L'organisation doit également définir un service qui peut rapidement identifier et résoudre les problèmes potentiels de service qui affecteront la Disponibilité et la représentation si ignorés.

Vous ne réaliserez pas le niveau de service désiré du jour au lendemain. Les défauts tels que la basse expertise, les limites de processus en cours, ou les niveaux de personnel insuffisants peuvent empêcher l'organisation de réaliser les normes désirées ou les buts, même après l'analyse précédente de service fait un pas. Il n'y a aucune méthode précise pour apparier exactement le niveau de service exigé aux buts désirés. Pour faciliter pour ceci, l'organisation devrait mesurer les normes de service et mesurer les paramètres de service utilisés pour prendre en charge les normes de service. Quand l'organisation n'atteint pas des buts de service, elle devrait alors regarder pour entretenir des mesures pour aider à comprendre la question. Dans de nombreux cas, des augmentations de budgétisation peuvent être faites pour améliorer des services de support technique et pour apporter des améliorations nécessaires d'atteindre les buts désirés de service. Au fil du temps l'organisation peut faire plusieurs réglages, au but de service ou à la définition de service, afin d'aligner des services réseau et des conditions requises d'affaires.

Par exemple, une organisation pourrait réaliser 99 pour cent de Disponibilité quand le but était beaucoup plus élevé à 99.9 pour cent de Disponibilité. En regardant des mesures de service et support, représentants de l'organisation constatée que le remplacement de matériel prenait approximativement 24 heures, beaucoup plus longs que l'évaluation d'origine parce que l'organisation avait économisé seulement quatre. En outre, l'organisation fondent que des capacités de gestion anticipée étaient ignorées et vers le bas des périphériques de réseau redondant n'étaient pas réparés. Ils fondent également qu'ils n'ont pas eu le personnel pour apporter des améliorations. En conséquence, après avoir considéré diminuant les buts en cours de service, l'organisation économisée pour des ressources supplémentaires a dû réaliser le niveau de service désiré.

Les définitions de service devraient inclure des définitions de support réactif et des définitions proactives. Les définitions réactives définissent comment l'organisation réagira aux problèmes après qu'ils aient été identifiés de la plainte ou des capacités d'administration de réseau d'utilisateur. Les définitions proactives décrivent comment l'organisation identifiera et résoudra des problèmes potentiels de réseau, y compris la réparation des parties du réseau « de réserve » cassées, détection d'erreur, et des seuils et des mises à jour de capacité. Les sections suivantes fournissent des exemples de réactif et des définitions de niveau de service anticipé.

Définitions du niveau de service réactives

Les zones suivantes de niveau de service sont typiquement mesurées utilisant des statistiques de base de données de helpdesk et auditer périodique. Cette table affiche l'exemple de la sévérité du problème pour une organisation. Notez que le tableau n'inclut pas comment traiter des demandes du nouveau service, qui peut être manipulé par SLA ou profilage et représentation supplémentaires d'application ce qui-si analyse. Typiquement la sévérité 5 peut être une demande de nouveau service si manipulé par l'intermédiaire de la même chose prennent en charge le processus.

Sévérité 1 Sévérité 2 Sévérité 3 Sévérité 4
Site WAN critique grave d'utilisateur ou de segment du serveur de RÉSEAU LOCAL d'impact commercial vers le bas vers le bas Impact commercial élevé par la perte ou la dégradation, RÉSEAU LOCAL en place de campus de contournement possible vers le bas ; 5-99 utilisateurs ont affecté l'incidence des performances essentielle internationale de site du WAN de site de WAN classique vers le bas vers le bas Une certaine fonctionnalité réseau spécifique est perdue ou dégradée, comme la Redondance de RÉSEAU LOCAL affectée par représentation de RÉSEAU LOCAL de campus de perte de redondance perdue Une requête ou un défaut fonctionnelle qui n'ont aucun impact commercial pour l'organisation

Quand la sévérité du problème a été définie, définissez ou étudiez le processus de support pour créer des définitions de réponse de service. Généralement les définitions de réponse de service exigent une structure de support à plusieurs niveaux ajoutée à un système de support logiciel de centre d'assistance pour dépister des problèmes par l'intermédiaire des dossiers d'incident. Les mesures devraient également être disponibles à l'heure le temps de réponse et le temps de résolution pour chaque priorité, le nombre d'appels par priorité, et la qualité de réponse/résolution. Pour définir le processus de support, il aide à définir les buts de chaque niveau de support dans l'organisation et leurs rôles et responsabilités. Ceci aide l'organisation à comprendre les besoins en matière de ressources et des niveaux d'expertise pour chaque niveau de support. Le tableau suivant fournit à un exemple d'une organisation de support à plusieurs niveaux des instructions de résolution des problèmes.

Niveau de support Responsabilité Buts
Support du niveau 1 Les appels à plein temps de support de réponse de support de centre d'assistance, les dossiers d'incident d'endroit, travail sur le problème jusqu'à 15 minutes, ticket de document et font suivre s'approprier le support du niveau 2 Résolution de 40% d'appels entrant
Support du niveau 2 La supervision de file d'attente, Gestion de réseau, des dossiers d'incident d'endroit de surveillance de station pour la prise de mise en place de problèmes identifiée par logiciel appelle du niveau 1, constructeur, et la transmission des problèmes du niveau 3 assument la propriété de l'appel jusqu'à la résolution Résolution de 100% d'appels au niveau du niveau 2
Support du niveau 3 Doit fournir le support immédiat au niveau 2 pour tous les problèmes prioritaire 1 acceptent d'aider avec tous les problèmes non résolus par le niveau 2 au cours de la période de résolution de SLA Aucune propriété directe de problème

L'étape suivante est de créer la matrice pour la définition de service de résolution de réponse de service et de service. Ceci fixe des buts pour à quelle rapidité des problèmes sont résolus, y compris le remplacement de matériel. Il est important de fixer des buts dans cette zone parce que le temps de réponse et le temps de rétablissement de service affectent directement la Disponibilité de réseau. Des temps de résolution des problèmes devraient également être alignés avec la Disponibilité de budget. Si un grand nombre de problèmes de à sévérité élevée ne sont pas expliqués dans la Disponibilité de budget, l'organisation peut alors fonctionner pour comprendre la source de ces problèmes et solution potentielle. Voyez le tableau suivant :

Sévérité du problème Réponse de centre d'assistance Réponse du niveau 2 Niveau sur le site 2 Remplacement de matériel Résolution des problèmes
1 Transmission des problèmes immédiate au niveau 2, responsable informatique d'exploitations réseau 5 minutes 2 heures 2 heures 4 heures
2 Transmission des problèmes immédiate au niveau 2, responsable informatique d'exploitations réseau 5 minutes 4 heures 4 heures 8 heures
3 15 minutes 2 heures 12 heures 24 heures 36 heures
4 15 minutes 4 heures 3 jours 3 jours 6 jours

En plus de la réponse de service et de la résolution de service, établissez une matrice pour la transmission des problèmes. Les aides de matrice de transmission des problèmes s'assurent que des ressources disponibles sont concentrées sur les problèmes qui affectent sévèrement le service. Généralement quand des analystes sont concentrés sur des problèmes de fixation, ils se concentrent rarement sur apporter des ressources supplémentaires dedans sur le problème. Définir quand les ressources supplémentaires devraient être des aides annoncées pour favoriser la connaissance de problème en Gestion et peuvent généralement aider à mener à de futures mesures proactives ou préventives. Voyez le tableau suivant :

Temps écoulé Sévérité 1 Sévérité 2 Sévérité 3 Sévérité 4
5 minutes Responsable informatique d'exploitations réseau, support du niveau 3, directeur de réseau      
1 heure Mettez à jour au responsable informatique d'exploitations réseau, support du niveau 3, directeur de réseau Mettez à jour au responsable informatique d'exploitations réseau, support du niveau 3, directeur de réseau    
2 heures Faites suivre à VP, mise à jour au directeur, directeur des opérations      
4 heures L'analyse de cause principale à VP, directeur, directeur des opérations, support du niveau 3, non résolu exige la notification de Président Faites suivre à VP, mise à jour au directeur, directeur des opérations    
24 heures     Responsable informatique d'exploitations réseau  
5 jours       Responsable informatique d'exploitations réseau

Jusqu'ici, les définitions du niveau de service se sont concentrées sur la façon dont l'organisme de support d'exécutions réagit aux problèmes après qu'ils soient identifiés. Les organismes d'exécutions ont créé des plans de support opérationnel avec les informations semblables à ce qui précède pendant des années. Cependant, ce qui manque dans des ces cas est comment l'organisation identifiera des problèmes et quels problèmes elles identifieront. Des organismes de réseau plus sophistiqués ont tenté de résoudre ce problème en créant simplement des buts pour le pourcentage des problèmes qui sont proactivement identifiés, par opposition aux problèmes réactivement identifiés par le rapport sur les problèmes ou la plainte d'utilisateur.

La prochaine table affiche comment une organisation peut souhaiter mesurer les capacités de support proactif et la combinaison de support proactif.

Région de réseau Ratio d'identification proactif de problème Ratio d'identification réactif de problème
RÉSEAU LOCAL 80 % 20 %
WAN 80 % 20 %

C'est un bon début à définir plus de définitions de support proactif parce qu'il est simple et assez facile de mesurer, particulièrement si les outils proactifs génèrent automatiquement des dossiers d'incident. Ceci aide également les outils de gestion de réseau de foyer/informations sur résoudre des problèmes proactivement plutôt qu'aidant avec la cause principale. Cependant, le problème principal avec cette méthode est qu'il ne définit pas des conditions requises de support proactif. Ceci crée généralement des lacunes dans des capacités de Gestion de support proactif et des résultats dans le risque d'atteinte à la disponibilité supplémentaire.

Définitions de niveau de service anticipé

Une méthodologie plus complète pour créer des définitions du niveau de service inclut plus de détail sur la façon dont le réseau est surveillé et la façon dont l'organisation d'exécutions réagit aux seuils définis de la station de Gestion de réseau (NMS) sur des 7 x 24 bases. Ceci peut sembler comme une tâche impossible donnée le nombre pur de variables du Management Information Base (MIB) et de la quantité des informations de gestion réseau disponible qui sont ayant trait aux santés de réseau. C'a pu également être extrêmement cher et ressource intensif. Malheureusement, ces objections empêchent beaucoup de mettre en application une définition de service anticipé qui, par nature, devrait être simple, assez facile pour suivre, et applicable seulement à la plus grands Disponibilité ou risques en matière de performances dans le réseau. Si une organisation voit alors la valeur dans des définitions de service anticipé de base, plus de variables peuvent être ajoutées au fil du temps sans impact important, tant que vous implémentez une approche par étapes.

Incluez le premier domaine des définitions de service anticipé dans tous les plans de support d'exécutions. De service de définition les états simplement comment le groupe d'exécutions proactivement l'identifiera et répondra au réseau ou joindra en bas des conditions dans différentes zones du réseau. Sans cette définition (ou prise en charge de la gestion), l'organisation peut s'attendre au support variable, des attentes irréalistes d'utilisateur, et finalement diminuer la Disponibilité de réseau.

Le tableau suivant affiche comment une organisation pourrait créer une définition de service pour des états de lien/périphérique-vers le bas. L'exemple affiche une organisation d'entreprise qui peut avoir différentes conditions requises de notification et de réponse basées sur l'heure et la zone du réseau.

Périphérique ou lien de réseau vers le bas Méthode de dépistage notification 5 x 8 7 x 24 notifications résolution 5 x 8 7 x 24 résolutions
Principal RÉSEAU LOCAL Périphérique SNMP et interrogation de lien, déroutements Le centre d'exploitation du réseau crée le dossier d'incident, pagineur de Réseau local-intervention de page Le pagineur d'intervention de RÉSEAU LOCAL d'appel automatique par radiomessagerie, personne d'intervention de RÉSEAU LOCAL crée le dossier d'incident pour la file d'attente de LAN principal Analyste de RÉSEAU LOCAL assigné dans un délai de 15 minutes par centre d'exploitation du réseau, réparation selon la définition de réponse de service Priorités 3 et de recherche immédiate prioritaires 1 et 2 et de résolution file d'attente 4 pour la résolution de matin
WAN classique Périphérique SNMP et interrogation de lien, déroutements Le centre d'exploitation du réseau crée le dossier d'incident, appelle le responsable du réseau étendu par radiomessagerie Le pagineur BLÊME d'intervention d'appel automatique par radiomessagerie, personne BLÊME d'intervention crée le dossier d'incident pour la file d'attente BLÊME Analyste BLÊME assigné dans un délai de 15 minutes par centre d'exploitation du réseau, réparation selon la définition de réponse de service Priorités 3 et de recherche immédiate prioritaires 1 et 2 et de résolution file d'attente 4 pour la résolution de matin
Extranet Périphérique SNMP et interrogation de lien, déroutements Le centre d'exploitation du réseau crée le dossier d'incident, pagineur d'intervention de partenaire de page Le pagineur d'intervention de partenaire d'appel automatique par radiomessagerie, personne d'intervention de partenaire crée le dossier d'incident pour la file d'attente de partenaire Analyste de partenaire assigné dans un délai de 15 minutes par centre d'exploitation du réseau, réparation selon la définition de réponse de service Priorités 1 et 2 recherche immédiate et résolution ; Priorités 3 et file d'attente 4 pour la résolution de matin

Les définitions de niveau de service anticipé restantes peuvent être divisées en deux catégories : erreurs réseau et capacité/problèmes de performance. Seulement un petit pourcentage des organismes de réseau ont des définitions du niveau de service dans ces zones. En conséquence, ces questions sont ignorées ou traitées sporadiquement. Ceci peut être parfait dans quelques environnements de réseau, mais les environnements facilement disponibles exigeront généralement à Gestion cohérente de service anticipé.

Les organisations de mise en réseau tendent à lutter avec des définitions de service anticipé pour plusieurs raisons. C'est principalement parce qu'ils n'ont pas exécuté une analyse des besoins pour des définitions de service anticipé basées sur des risques d'atteinte à la disponibilité, la Disponibilité de budget, et des questions d'application. Ceci mène aux conditions requises peu claires pour des définitions de service anticipé et aux avantages peu clairs, particulièrement parce que les ressources supplémentaires peuvent être nécessaires.

La deuxième raison implique d'équilibrer la quantité d'administration proactive qui peut être faite avec les ressources existantes ou nouveau-définies. Générez seulement ces alertes qui ont l'impact potentiel sérieux à la Disponibilité ou à la représentation. Vous devez également considérer la Gestion ou les processus de corrélation d'événements pour s'assurer que de plusieurs dossiers d'incident proactifs ne sont pas générés pour le même problème. Les derniers organismes de raison peuvent lutter est cela qui crée un nouvel ensemble d'alertes proactives peuvent souvent générer une inondation initiale des messages qui sont précédemment allés non détectés. Le groupe d'exécutions doit être disposé pour cette inondation initiale des questions et des ressources à court terme supplémentaires à réparer ou résoudre ces conditions précédemment non détectées.

La première catégorie de définitions de niveau de service anticipé est des erreurs réseau. Des erreurs réseau peuvent être encore subdivisées en erreurs système qui incluent des erreurs logicielles ou des erreurs matérielles, des erreurs de protocole, des erreurs de contrôle de medias, des erreurs de précision, et des avertissements environnementaux. Débuts se développants d'une définition du niveau de service avec une compréhension générale de la façon dont ces conditions de problème seront détectées, de qui les regarderont, et ce qui se produiront quand elles se produisent. Ajoutez les messages ou les questions spécifiques à la définition du niveau de service si le besoin se fait sentir. Vous pouvez également avoir besoin de travail supplémentaire dans les zones suivantes pour assurer le succès :

  • Responsabilités de support du niveau 1, du niveau 2, et du niveau 3

  • Équilibrant la priorité des informations de gestion réseau avec la quantité de travail anticipé que le groupe d'exécutions peut efficacement manipuler

  • Les besoins de formation d'assurer le personnel de support peuvent efficacement traiter les alertes définies

  • Méthodologies de corrélation d'événements pour s'assurer que des plusieurs tickets de panne ne sont pas générés pour le même problème d'origine

  • Documentation sur les messages ou les alertes spécifiques qui aide avec l'identification d'événement au niveau de support du niveau 1

Le tableau suivant affiche une définition du niveau de service d'exemple pour les erreurs réseau qui fournissent une compréhension claire de qui est responsable des alertes anticipées d'erreur sur le réseau, de la façon dont le problème seront identifiés, et ce qui se produira quand le problème se pose. L'organisation peut encore avoir besoin d'efforts supplémentaires comme défini ci-dessus pour assurer le succès

s.

Catégorie d'erreur Méthode de dépistage Seuil Une mesure prise
Erreurs logicielles (crash forcés par le logiciel) Examen quotidien des messages de Syslog utilisant le visualiseur de Syslog fait par le support du niveau 2 Toute occurrence pour la priorité 0, 1, et 2 plus de 100 occurrences du niveau 3 ou en haut Passez en revue le problème, créez le dossier d'incident, et la répartition si nouvelle occurrence ou si le problème exige l'attention
Erreurs matérielles (crash forcés par le matériel) Examen quotidien des messages de Syslog utilisant le visualiseur de Syslog fait par le support du niveau 2 Toute occurrence pour la priorité 0, 1, et 2 plus de 100 occurrences du niveau 3 ou en haut Passez en revue le problème, créez le dossier d'incident, et la répartition si nouvelle occurrence ou si le problème exige l'attention
Erreurs de protocole (protocoles de Routage IP seulement) Examen quotidien des messages de Syslog utilisant le visualiseur de Syslog fait par le support du niveau 2 Dix messages par jour des priorités 0, 1, et 2 plus de 100 occurrences du niveau 3 ou en haut Passez en revue le problème, créez le dossier d'incident, et la répartition si nouvelle occurrence ou si le problème exige l'attention
Erreurs de contrôle de medias (FDDI, POS, et Fast Ethernet seulement) Examen quotidien des messages de Syslog utilisant le visualiseur de Syslog fait par le support du niveau 2 Dix messages par jour des priorités 0, 1, et 2 plus de 100 occurrences du niveau 3 ou en haut Passez en revue le problème, créez le dossier d'incident, et la répartition si nouvelle occurrence ou si le problème exige l'attention
Messages environnementaux (alimentation et temp) Examen quotidien des messages de Syslog utilisant le visualiseur de Syslog fait par le support du niveau 2 Tout message Créez le dossier d'incident et la répartition pour de nouveaux problèmes
Erreurs de précision (erreurs d'entrée de lien) Interrogation SNMP de cinq minutes aux événements de franchissement de seuil d'intervalles reçus par centre d'exploitation du réseau Entrée ou erreurs de sortie une erreur dans de cinq minutes l'intervalle sur tout lien Créez le dossier d'incident pour de nouveaux problèmes et répartition au support du niveau 2

L'autre catégorie de définitions de niveau de service anticipé s'applique à la représentation et à la capacité. La véritable Gestion de représentation et de capacité inclut la gestion d'exception, l'établissement des références et tendre, et ce qui-si analyse. La définition du niveau de service définit simplement des seuils d'exception de performances et de capacité et des seuils moyens qui initieront l'enquête ou la mise à jour. Ces seuils peuvent alors s'appliquer à chacun des trois processus de gestion de performances et de capacité d'une certaine façon.

Des définitions du niveau de service de capacité et de représentation peuvent être décomposées en plusieurs catégories : liaisons réseau, périphériques de réseau, performances de bout en bout, et performance des applications. Développer des définitions du niveau de service dans ces zones exige des connaissances techniques en profondeur concernant des aspects spécifiques de capacité des périphériques, de capacité de supports, de caractéristiques de QoS, et de conditions requises d'application. Pour cette raison, nous recommandons que les architectes de réseau développent la représentation et les définitions du niveau de service en rapport avec la capacité avec l'entrée de constructeur.

Comme des erreurs réseau, développant une définition du niveau de service pour des débuts de capacité et de représentation avec une compréhension générale de la façon dont ces conditions de problème seront détectées, de qui les regarderont, et ce qui se produiront quand elles se produisent. Vous pouvez ajouter des définitions d'événement spécifiques à la définition du niveau de service si le besoin se fait sentir. Vous pouvez également avoir besoin de travail supplémentaire dans les zones suivantes pour assurer le succès :

  • Une compréhension claire des exigences de performance des applications

  • L'enquête technique en profondeur sur les valeurs seuil qui semblent raisonnable pour l'organisation a basé sur des conditions requises d'affaires et des coûts globaux

  • Conditions requises budgétaires de cycle et de mise à jour de -de-cycle

  • Responsabilités de support du niveau 1, du niveau 2, et du niveau 3

  • La priorité et la criticité des informations de gestion réseau ont équilibré avec la quantité de travail anticipé que le groupe d'exécutions peut efficacement manipuler

  • Besoins de formation de s'assurer que le personnel de support comprennent les messages ou les alertes et peuvent efficacement traiter l'état défini

  • Méthodologies ou processus de corrélation d'événements pour s'assurer que des plusieurs tickets de panne ne sont pas générés pour le même problème d'origine

  • Documentation sur les messages ou les alertes spécifiques qui aide avec l'identification d'événement au niveau de support du niveau 1

Le tableau suivant affiche une définition du niveau de service d'exemple pour l'utilisation de lien qui fournit une compréhension claire de qui est responsable des alertes anticipées d'erreur sur le réseau, de la façon dont le problème seront identifiés, et ce qui se produira quand le problème se pose. L'organisation peut encore avoir besoin d'efforts supplémentaires comme défini ci-dessus pour assurer le succès.

Région/medias de réseau Méthode de dépistage Seuil Une mesure prise
Liens de fédérateur LAN et de distribution de campus Interrogation SNMP de cinq minutes aux déroutements d'exception de RMON d'intervalles sur des liens de noyau et de distribution utilisation de 50% dans de cinq minutes l'utilisation des intervalles 90% par l'intermédiaire du déroutement d'exception Notification par courrier électronique au groupe de courrier électronique de performances alias pour évaluer la condition requise de QoS ou la mise à jour de plan pour des problèmes récurrents
Liens de WAN classique Interrogation SNMP de cinq minutes à intervalles utilisation de 75% dans de cinq minutes des intervalles Notification par courrier électronique au groupe de courrier électronique de performances alias pour évaluer la condition requise de QoS ou la mise à jour de plan pour des problèmes récurrents
Liens WAN d'extranet Interrogation SNMP de cinq minutes à intervalles utilisation de 60% dans de cinq minutes des intervalles Notification par courrier électronique au groupe de courrier électronique de performances alias pour évaluer la condition requise de QoS ou la mise à jour de plan pour des problèmes récurrents

Le tableau suivant définit des définitions du niveau de service pour des seuils de capacité des périphériques et de représentation. Assurez que vous créez les seuils qui sont signicatifs et utiles en empêchant des problèmes de réseau ou la Disponibilité de questions. C'est un domaine très important parce que les questions non réprimées de ressource en avion de contrôle des périphériques peuvent avoir l'incidence sérieuse de réseau.

         
Cisco 7500 CPU, mémoire, mémoires tampons Interrogation SNMP à la notification de RMON d'intervalles -5-minute pour la CPU CPU à 75% pendant de cinq minutes les intervalles, 99% par l'intermédiaire de la mémoire de notification de RMON à 50% pendant de cinq minutes les mémoires tampons d'intervalles à l'utilisation de 99% La notification par courrier électronique au groupe de courrier électronique de performances et de capacité alias pour résoudre les problèmes ou la CPU de RMON de mise à jour de plan à 99%, le dossier d'incident et le niveau 2 d'endroit de page prennent en charge le pagineur
Cisco 2600 CPU, mémoire Interrogation SNMP de cinq minutes à intervalles CPU à 75% pendant de cinq minutes la mémoire d'intervalles à 50% pendant de cinq minutes les intervalles Notification par courrier électronique au groupe de courrier électronique de performances et de capacité alias pour résoudre des problèmes ou la mise à jour de plan
Catalyst 5000 Utilisation du fond de panier, mémoire Interrogation SNMP de cinq minutes à intervalles Le fond de panier à la mémoire d'utilisation de 50% à l'utilisation de 75% Notification par courrier électronique au groupe de courrier électronique de performances et de capacité alias pour résoudre des problèmes ou la mise à jour de plan
Commutateur ATM de LightStreamÝ 1010 CPU, mémoire Interrogation SNMP de cinq minutes à intervalles CPU à la mémoire d'utilisation de 65% à l'utilisation de 50% Notification par courrier électronique au groupe de courrier électronique de performances et de capacité alias pour résoudre des problèmes ou la mise à jour de plan

La prochaine table définit des définitions du niveau de service pour des performances de bout en bout et la capacité. Ces seuils sont généralement basés sur des conditions requises d'application mais peuvent également être utilisés pour indiquer un certain type de problème de performances du réseau ou de capacité. La plupart des organismes avec des définitions du niveau de service pour la représentation créent seulement une poignée de définitions de représentation parce que la représentation de mesure de chaque point dans le réseau à chaque autre point exige les ressources importantes et crée beaucoup de réseau supplémentaire. Ces questions de performances de bout en bout peuvent également être attrapées dans les seuils de capacité de la liaison ou de l'équipement. Nous recommandons des définitions générales par zone géographique. Quelques sites ou liens essentiels peuvent être ajoutés s'il y a lieu.

Région/medias de réseau Méthode de mesure Seuil Une mesure prise
RÉSEAU LOCAL de campus Aucun aucun problème n'a attendu difficile de mesurer l'infrastructure LAN entière temps de réponse 10-millisecond aller-retour ou moins à tout moment Notification par courrier électronique au groupe de courrier électronique de performances et de capacité alias pour résoudre la mise à jour de question ou de plan
Liens de WAN classique Mesure en cours de SF à NY et de SF vers Chicago seulement utilisant l'écho d'ICMP du moniteur de performances d'Internet (IPM) temps de réponse 75-millisecond aller-retour ramené à une moyenne au-dessus de cinq minutes de la période Notification par courrier électronique au groupe de courrier électronique de performances alias pour évaluer la condition requise de QoS ou la mise à jour de plan pour des problèmes récurrents
San Francisco vers Tokyo La mesure en cours de San Francisco vers Bruxelles utilisant l'IPM et l'ICMP font écho temps de réponse 250-millisecond aller-retour ramené à une moyenne au-dessus de cinq minutes de la période Notification par courrier électronique au groupe de courrier électronique de performances alias pour évaluer la condition requise de QoS ou la mise à jour de plan pour des problèmes récurrents
San Francisco vers Bruxelles La mesure en cours de San Francisco vers Bruxelles utilisant l'IPM et l'ICMP font écho temps de réponse 175-millisecond aller-retour ramené à une moyenne au-dessus de cinq minutes de la période Notification par courrier électronique au groupe de courrier électronique de performances alias pour évaluer la condition requise de QoS ou la mise à jour de plan pour des problèmes récurrents

Le dernier domaine pour des définitions du niveau de service est pour la performance des applications. Des définitions du niveau de service de performance des applications sont normalement créées par l'application ou le groupe d'administration de serveur parce que la performance et la capacité des serveurs elles-mêmes est probablement le plus grand facteur dans la performance des applications. Les organisations de mise en réseau peuvent réaliser l'avantage énorme en créant des définitions du niveau de service pour la performance d'application réseau parce que :

  • les définitions du niveau de service et la mesure peuvent aider à éliminer des conflits entre les groupes.

  • les définitions du niveau de service pour des applications individuelles sont importantes si QoS est configuré pour les applications principales et l'autre trafic est considéré facultatif.

Si vous choisissez de créer et performance des applications de mesure, il est probablement le meilleur si vous ne mesurez pas la représentation au serveur elle-même. Ceci aide alors à distinguer les problèmes de réseau et l'application ou les problèmes serveurs. Utilisez les sondes ou la Disponibilité du système d'exécution de logiciel agent sur les Routeurs et Cisco IPM de Cisco contrôlant la fréquence de type de paquet et de mesure.

Le tableau suivant affiche une définition du niveau de service simple pour la performance des applications.

Application Méthode de mesure Seuil Une mesure prise
Port TCP d'application de la planification des ressources d'entreprise (ERP) 1529 Bruxelles à SF Bruxelles à San Francisco utilisant la passerelle de mesure de Bruxelles de performances d'aller-retour du port 1529 IPM à la passerelle 2 SFO temps de réponse 175-millisecond aller-retour ramené à une moyenne au-dessus de cinq minutes de la période Notification par courrier électronique au groupe de courrier électronique de performances alias pour évaluer la mise à jour de problème ou de plan pour des problèmes récurrents
Port TCP d'application ERP 1529 Tokyo à SF Bruxelles à San Francisco utilisant la passerelle de mesure de Bruxelles de performances d'aller-retour du port 1529 IPM à la passerelle 2 SFO temps de réponse 200-millisecond aller-retour ramené à une moyenne au-dessus de cinq minutes de la période Notification par courrier électronique au groupe de courrier électronique de performances alias pour évaluer la mise à jour de problème ou de plan pour des problèmes récurrents
Port TCP d'application de support technique 1702 Sydney à SF Sydney à San Francisco utilisant la passerelle de mesure de Sydney de performances d'aller-retour du port 1702 IPM à la passerelle 1 SFO temps de réponse 250-millisecond aller-retour ramené à une moyenne au-dessus de cinq minutes de la période Notification par courrier électronique au groupe de courrier électronique de performances alias pour évaluer la mise à jour de problème ou de plan pour des problèmes récurrents

Étape 6 : Collectez les mesures et les surveillez

les définitions du niveau de service sont seuls sans valeur à moins que l'organisation collecte des mesures et surveille le succès. En créant une définition de niveau de service critique, définissez comment le niveau de service sera mesuré et signalé. Mesurant le niveau de service détermine si l'organisation répond à des objectifs et identifie également la cause principale de la Disponibilité ou des problèmes de performance. Considérez également le but en choisissant une méthode pour mesurer la définition du niveau de service. Voyez en créant et mise à jour du pour en savoir plus SLA.

Les niveaux de service de contrôle nécessite de mener une téléconférence d'examen périodique, normalement tous les mois, pour discuter le service périodique. Discutez toutes les mesures et si elles se conforment aux objectifs. S'ils ne se conforment pas, déterminez l'origine du problème et implémentez les améliorations. Vous devriez également couvrir des initiatives en cours et progresser en améliorant différentes situations.

Créant et mise à jour du SLA

les définitions du niveau de service sont un excellent module du fait elles aident à créer un QoS cohérent dans toute l'organisation et à aider à améliorer la Disponibilité. L'étape suivante est SLA, qui sont une amélioration parce qu'elles alignent des objectifs professionnels et des critères de coût d'entretenir directement la qualité. SLA bien-construit sert alors de modèle à l'efficacité, la qualité, et la synergie entre la communauté d'utilisateurs et le comité de soutien en mettant à jour des processus clairs et les procédures pour des problèmes de réseau ou des problèmes.

Le SLA fournissent plusieurs indemnités :

  • Le SLA établissent la responsabilité en deux étapes pour le service, signifiant que les utilisateurs et les groupes d'applications sont également responsables du service réseau. S'ils n'aident pas à créer SLA pour un service spécifique et à communiquer l'impact commercial avec le groupe de réseau, alors ils peuvent réellement être responsables du problème.

  • L'aide SLA déterminent les outils standard et les ressources requis pour répondre à des exigences d'affaires. Décidant combien personnes et quelles outils utiliser sans SLA est souvent une conjecture budgétaire. Le service peut sur-être machiné, qui mène au dépassement du budget, ou sous-être machiné, qui mène aux objectifs professionnels imprévisibles. Les aides de accord SLA réalisent ce niveau optimal équilibré.

  • SLA documenté crée un véhicule plus clair pour placer des attentes de niveau de service.

Nous recommandons les étapes suivantes pour la construction du SLA après que des définitions du niveau de service aient été créées : Nous recommandons les étapes suivantes pour la construction du SLA après que des définitions du niveau de service aient été créées :

7. Rencontrez les préalables au SLA.

8. Déterminez les parties concernées à SLA.

9. Déterminez les éléments de service.

10. Comprenez les besoins et les buts d'activité du client

11. Définissez SLA requis pour chaque groupe.

12. Choisissez le format de SLA

13. Développez les groupes de travail de SLA

14. Tenez les réunions de groupe de travail et dessinez SLA.

15. Négociez SLA.

16. Mesure et conformité de SLA de moniteur.

Étape 7 : Préalables de rassemblement au SLA

Les experts en matière de développement informatique de SLA ont identifié trois conditions préalables à l'SLA réussi. Malheureusement, les organismes qui ne répondent pas à ces objectifs peuvent s'attendre à des problèmes avec le processus de SLA et devraient considérer les problèmes potentiels impliqués du processus de SLA. Manquer pour implémenter le SLA ne porte pas préjudice si l'organisation de mise en réseau peut établir les définitions du niveau de service qui répondent à des exigences générales d'affaires. Ce qui suit sont des préalables au processus de SLA :

  • Votre entreprise doit avoir une culture orientée vers les services.

    L'organisation doit placer les besoins des clients d'abord. Vous avez besoin d'un engagement hiérarchisé prioritaire pour entretenir, ayant pour résultat une compréhension complète des besoins des clients et des perceptions. Enquêtes de satisfaction du client d'attitude et initiatives adaptées aux besoins du client de service.

    Un autre indicateur de service peut être que la satisfaction de service ou de support d'états d'organisation comme but entreprise. Ce n'est pas rare parce que des organismes informatiques sont maintenant en critique liés au succès global d'organisation.

    La culture de service est importante parce que le processus de SLA est fondamentalement au sujet d'apporter des améliorations basées sur les besoins des clients et des conditions requises d'affaires. Si les organismes n'ont pas fait ceci dans le passé, ils trouveront le processus de SLA difficile.

  • Le client/initiatives commerciales doit conduire toutes les activités informatiques.

    La vision de société ou les rapports de mission doit être alignée avec le client et les initiatives commerciales, qui pilotent alors toutes les activités informatiques, y compris le SLA. Trop souvent un réseau est mis en place pour atteindre un but particulier, pourtant le groupe réseau perd de vue ces but et conditions requises ultérieures d'affaires. Dans des ces cas, un budget de positionnement est alloué au réseau, qui peut réagir en exagération aux besoins en cours ou sous-estime excessivement la condition requise, ayant pour résultat la panne.

    Quand le client/initiatives commerciales sont alignés avec des activités informatiques, l'organisation de mise en réseau peut plus facilement être en accord avec le déploiement de nouvelles applications, les nouveaux services, ou d'autres conditions requises d'affaires. Les relations et le foyer global commun sur atteindre des buts entreprise sont présent et tous les groupes exécutent en équipe.

  • Vous devez investir dans SLA le processus et le contrat.

    Le premier là doit être engagement pour apprendre le processus de SLA pour développer des accords efficaces. En second lieu, vous devez honorer les besoins de services du contrat. Ne comptez pas créer le SLA puissant sans entrée et engagement significatifs de toutes les personnes impliquées. Cet engagement doit également provenir la Gestion et toutes les personnes associées avec le processus de SLA.

Étape 8 : Déterminez les parties concernées à SLA

Le réseau SLA de niveau d'entreprise dépendent largement des éléments de réseau, des éléments d'administration de serveur, support de helpdesk, des éléments d'application, et entreprise ou des exigences de l'utilisateur. Normalement la Gestion de chaque zone sera impliquée dans le processus de SLA. Ce scénario fonctionne bien quand l'organisation établit le support réactif de base SLA. Les organisations d'entreprise avec les besoins de plus haute disponibilité peuvent avoir besoin d'assistance technique pendant le processus de SLA d'aider avec des questions telles que la budgétisation, les limites de performances, l'application profilant, ou les capacités de gestion anticipée de Disponibilité. Pour plus d'aspects de SLA d'administration proactive, nous recommandons une équipe technique d'architectes de réseau et d'architectes d'application. L'assistance technique peut beaucoup plus étroitement approximatif la Disponibilité et les capacités en termes de performances du réseau et ce qui serait nécessaire pour atteindre des objectifs spécifiques.

Le prestataire de service SLA n'incluent pas normalement l'utilisateur entré parce qu'ils sont créés dans le seul but de gagner un avantage concurrentiel sur d'autres fournisseurs de services. Dans certains cas, la Gestion supérieure créera ces le SLA aux niveaux très facilement disponibles ou performants pour favoriser leur service et pour fournir des buts internes pour les employés internes. D'autres fournisseurs de services se concentreront sur les aspects techniques d'améliorer la Disponibilité en créant les définitions du niveau de service fortes qui sont mesurées et gérées intérieurement. Dans d'autres cas, les deux efforts se produisent simultanément mais pas nécessairement ensemble ou avec les mêmes buts.

Choisir les parties concernées à SLA devrait alors être basé sur les buts de SLA. Quelques buts possibles sont :

  • Répondre à des objectifs professionnels de support réactif

  • Fournissant le de plus haut niveau de la Disponibilité en définissant le SLA proactif

  • Favorisant ou vendant un service

Étape 9 : Déterminez les éléments de service

Le service/support primaires SLA aura normalement beaucoup de composants, y compris le niveau du support, comment lui seront mesurés, le chemin d'escalade pour la réconciliation de SLA, et les soucis globaux de budget. Les éléments de service pour des environnements à haute disponibilité devraient inclure des définitions de service anticipé aussi bien que des buts réactifs. Les détails supplémentaires incluent ce qui suit :

  • Heures de travail et procédures de support sur site pour le support de hors fonction-heures

  • Définitions des priorités, y compris le type de problème, l'heure maximum de commencer le travail sur le problème, l'heure maximum de résoudre le problème, et des procédures d'escalade

  • Produits ou services à prendre en charge, rangé par ordre degré d'importance pour l'entreprise

  • Soutien des attentes d'expertise, des attentes de niveau de performance, de l'enregistrement d'état, et des responsabilités d'utilisateur de résolution des problèmes

  • Questions et conditions requises géographiques ou d'unité commerciale de niveau de support

  • Méthodologie et procédures de Gestion de problème (appel-dépistant le système)

  • Buts de centre d'assistance

  • Réponse de détection d'erreur sur le réseau et de service

  • Disponibilité de mesure et enregistrement de réseau

  • Capacité du réseau et mesure des performances et enregistrement

  • Procédures de résolution de conflits

  • Le financement de SLA mis en application

L'application réseau ou le service SLA peut avoir les besoins supplémentaires basés sur des exigences et le degré d'importance pour l'entreprise de groupe d'utilisateurs. L'organisme de réseau doit écouter étroitement à ces conditions requises d'affaires et développer les solutions spécialisées cette adaptation en structure de support globale. S'insérer dans la culture globale de support est essentiel parce qu'il est important de ne pas créer un service de première classe destiné seulement à quelques personnes ou groupes. Dans de nombreux cas, ces conditions requises supplémentaires peuvent être placées dans des catégories de « solution ». Un exemple pourrait être un platine, un or, et une solution Silver basée sur le besoin d'affaires. Voyez les exemples suivants des conditions requises de SLA pour les besoins spécifiques d'affaires.

Remarque: La structure de support, le chemin d'escalade, les procédures de helpdesk, la mesure, et les définitions des priorités devraient en grande partie demeurer la même pour mettre à jour et améliorer une culture cohérente de service.

  • Bandes passantes nécessaires et capacités pour la rafale

  • Exigences de marche

  • Conditions requises et définitions de QoS

  • Exigences au niveau de la disponibilité et Redondance d'établir la matrice de solution

  • Conditions requises de surveillance et d'enregistrement, méthodologie, et procédures

  • Critères de mise à jour pour des éléments d'application/service

  • Conditions requises de -de-budget de financement ou méthodologie de croix-remplissage

Par exemple, vous pouvez créer des catégories de solution pour la Connectivité de site du WAN. La solution de platine serait équipée de services jumeaux de t1 au site. Un transporteur différent fournirait chaque ligne de t1. Le site aurait deux Routeurs configurés de sorte que si n'importe quel t1 ou routeur manquait le site n'éprouve pas une panne. Le service d'or aurait deux Routeurs, mais le Relais de trames de sauvegarde serait utilisé. Cette solution peut avoir la bande passante limitée pour la durée de la panne. La solution Silver aurait seulement un routeur et un opérateur. L'un de ces solutions seraient considérées pour différents niveaux de priorité pour des tickets de problème. Quelques organismes peuvent exiger une solution de platine ou d'or si une priorité 1 ou le ticket 2 est exigée pour une panne. Les organismes de client peuvent alors financer le niveau du service qu'ils exigent. Le tableau suivant affiche un exemple d'une organisation qui offre trois niveaux de service, selon le besoin d'affaires de connectivité extranet.

Solution Platine Or Argent
Périphériques Routeurs redondants pour la connectivité WAN Routeur redondant pour la sauvegarde au site central Aucune Redondance de périphérique
WAN Connectivité redondante de t1, plusieurs transporteurs Connectivité de t1 avec la sauvegarde en relais de trame Aucune Redondance BLÊME
Bandes passantes nécessaires et rafale T1 redondant avec le chargement partageant pour la rafale Non-chargement partageant, sauvegarde en relais de trame pour des applications stratégiques seulement ; Relais de trames 64K CIR seulement Jusqu'au t1
Représentation À temps de réponse 100-ms aller-retour cohérent ou moins Ms du temps de réponse 100 ou 99.9% moins prévus Ms du temps de réponse 100 ou 99% moins prévu
Exigence au niveau de la disponibilité 99.99% 99.95% 99.9%
Priorité de centre d'assistance quand vers le bas Priorité 1 : service capital pour l'entreprise vers le bas Priorité 2 : entreprise-affectant le service vers le bas Priorité 3 : Connectivité d'affaires vers le bas

Étape 10 : Comprenez les besoins et les buts d'activité du client

Cette étape prête le développeur de SLA beaucoup de crédibilité. En comprenant les besoins des divers services, le document initial de SLA sera beaucoup plus près de la condition requise et de l'effet désiré d'affaires. Essayez de comprendre le coût du temps d'arrêt pour le service à la clientèle. Évaluation en termes de perte de productivité, revenu, et bonne volonté du client. Maintenez dans l'esprit que même les connexions simples avec quelques personnes peuvent sérieusement affecter le revenu. Dans ce cas, soyez sûr d'aider le client à comprendre la Disponibilité et les risques en matière de performances qui peuvent se produire de sorte que l'organisation comprenne mieux le niveau du service qu'il a besoin. Si vous manquez cette étape, vous pouvez obtenir beaucoup de clients exigeant simplement la Disponibilité 100-percent.

Le développeur de SLA devrait également comprendre les buts d'affaires et la croissance de l'organisation afin de faciliter des mises à jour, la charge de travail, et la budgétisation de réseau. Il est également utile de comprendre les applications qui seront utilisées. Si tout va bien l'organisation a des profils d'application sur chaque application, mais sinon, envisagez de faire une évaluation technique de l'application pour déterminer les questions liées au réseau.

Étape 11 : Définissez SLA requis pour chaque groupe

Le support primaire SLA devrait inclure les unités commerciales essentielles et la représentation de groupe fonctionnel, telle que des exécutions de réseau, des fonctionnements du serveur, et des comités de soutien d'application. Ces groupes devraient être identifiés ont basé sur les besoins d'affaires aussi bien que leur partie dans le processus de support. En ayant la représentation de beaucoup d'aides de groupes également créez une solution globale équitable de support sans préférence ou priorité individuelle de groupe. Ceci peut mener un organisme de support dans fournir le service de première classe à différents groupes, un scénario qui peut miner la culture globale de service de l'organisation. Par exemple, un client pourrait insister que son application est la plus essentielle au sein de la société quand en réalité le coût du temps d'arrêt pour cette application est de manière significative moins que d'autres en termes de perte de recettes, perte de productivité, et bonne volonté du client perdue.

Les différentes unités commerciales dans l'organisation auront des demandes différentes. Un but de l'accord de services réseau devrait être accord sur un format global qui facilite des niveaux de service différent. Ces conditions requises sont généralement Disponibilité, QoS, représentation, et durée moyenne de reprise. À l'accord de services réseau, ces variables sont manipulées en donnant la priorité à des applications métier pour QoS potentiel accordant, définissant des priorités de helpdesk pour la durée moyenne de reprise de différentes questions réseau-les affectant, et développant une matrice de solution qui aidera à manipuler différentes exigences de Disponibilité et de marche. Un exemple d'une matrice de solution simple pour une entreprise de fabrication d'entreprise peut sembler quelque chose comme le tableau suivant. Vous pouvez ajouter les informations sur la Disponibilité, le QoS, et les résultats.

Unité commerciale Applications Coût de temps d'arrêt Priorité de problème quand vers le bas Serveur/spécification du réseau
Fabrication ERP Haute 1 La Redondance la plus élevée
Support technique Assistance à la clientèle Haute 1 La Redondance la plus élevée
Construction Serveur de fichiers, conception ASIC Support 2 Redondance centrale de RÉSEAU LOCAL
Commercialisation Serveur de fichiers Support 2 Redondance centrale de RÉSEAU LOCAL

Étape 12 : Choisissez le format de SLA

Le format pour SLA peut varier selon des souhaits de groupe ou des conditions requises organisationnelles. Ce qui suit est un contour recommandé d'exemple pour l'accord de services réseau :

  1. But d'accord

    • Interlocuteurs participant à l'accord

    • Buts et buts pour l'accord

  2. Services fournis et Produits pris en charge

    • Service de helpdesk et cheminement d'appel

    • Définitions de sévérité du problème basées sur l'impact commercial pour des définitions durée moyenne de reprise

    • Priorités de service capital pour l'entreprise pour des définitions de QoS

    • Catégories définies de solution basées sur des exigences de Disponibilité et de marche

    • Besoins de formation

    • Conditions requises de planification de capacité

    • Conditions requises de transmission des problèmes

    • Signaler

    • Solutions réseau fournies

    • Nouvelles demandes de solution

    • Produits ou applications non vérifiés

  3. Politiques d'entreprise

    • Support pendant des heures de travail

    • définitions de support d'Après-heure

    • Couverture de vacances

    • Numéro de téléphone du contact

    • Prévisions de charge de travail

    • Résolution de grief

    • Entretenez les critères d'autorisation

    • Responsabilités en matière de sécurité d'utilisateur et de groupe

  4. Procédures de gestion de problème

    • Initiation d'appel (utilisateur et automatisé)

    • Réponse et rapport de premier niveau de réparation d'appel

    • Cheminement et tenue des registres d'appel

    • Responsabilités d'appelant

    • Conditions requises de diagnostic et d'appel-fermeture de problème

    • Détection de problème de Gestion de réseau et réponse de service

    • Catégories ou définitions de résolution des problèmes

    • Manipulation de problème chronique

    • Gestion des appels essentielle de problème/exception

  5. Entretenez les objectifs de qualité

    • Définitions de qualité

    • Définitions de mesure

    • Objectifs de qualité

    • Moyenne heure d'initier la résolution des problèmes par priorité de problème

    • Moyenne temps à la résolution des problèmes par priorité de problème

    • Moyenne heure de remplacer le matériel par priorité de problème

    • Disponibilité et représentation de réseau

    • Gérer la capacité

    • Gérer la croissance

    • Enregistrement de qualité

  6. Personnel et budgets

    • Personnel des modèles

    • Budget d'exécutions

  7. Maintenance d'accord

    • Programme d'examen de conformité

    • Enregistrement et examen de représentation

    • Réconciliation des mesures d'état

    • Mises à jour périodiques de SLA

  8. Approbations

  9. Connexions et présentations

    • diagrammes d'Appel-écoulement

    • Matrice de transmission des problèmes

    • Matrice de solution réseau

    • Exemples d'état

Étape 13 : Développez les groupes de travail de SLA

L'étape suivante identifie des participants au groupe de travail de SLA, y compris un leader de groupe. Le groupe de travail peut inclure des utilisateurs ou des gestionnaires à partir des unités commerciales ou des groupes fonctionnels ou des représentants d'une base géographique. Ces personnes communiquent des questions de SLA à leurs groupes de travail respectifs. Les gestionnaires et les décideurs qui peuvent convenir sur les éléments principaux de SLA devraient participer. Ces personnes peuvent inclure les personnes gestionnaires et techniques qui peuvent aider à définir des problèmes techniques liés à SLA et à prendre des décisions niveau du service informatique (c.-à-d., gestionnaire de centre d'assistance, responsable informatique de fonctionnements du serveur, gestionnaires d'application, et responsable informatique d'exploitations réseau).

Le groupe de travail d'accord de services réseau devrait également se composer de la large représentation d'application et d'affaires afin d'obtenir l'accord sur l'accord de services réseau un qui entoure beaucoup d'applications et services. Le groupe de travail devrait avoir l'autorité pour ranger des processus critiques et des services pour le réseau, aussi bien que des exigences de Disponibilité et de marche pour des services individuels. Ces informations seront utilisées pour créer des priorités pour différents types entreprise-les affectant de problème, pour donner la priorité au trafic capital pour l'entreprise sur le réseau et pour créer de futures solutions réseau standard basées sur des conditions requises d'affaires.

Étape 14 : Tenez les réunions de groupe de travail et dessinez SLA

Le groupe de travail devrait au commencement créer une charte de groupe de travail. La charte devrait exprimer les buts, les initiatives, et les périodes pour SLA. Ensuite le groupe devrait développer des plans spécifiques de tâche et déterminer des programmes et des horaires pour développer et mettre en application SLA. Le groupe devrait également développer le procédé d'enregistrement pour mesurer le niveau de support contre des critères de support. La dernière étape crée l'accord de SLA d'ébauche.

Le groupe de travail de SLA de réseau devrait au commencement se réunir une fois par semaine pour développer SLA. Après que SLA ait été créé et approuvé, le groupe peut rencontrer le mensuel ou même la fois par trimestre pour des mises à jour de SLA.

Étape 15 : Négociez SLA

La dernière étape en créant SLA est négociation et d'approbation finaux. Cette étape inclut :

  • Examiner l'ébauche

  • Négociation du contenu

  • Éditant et mettant à jour le document

  • Obtenir l'approbation finale

Ce cycle d'examiner l'ébauche, de négocier le contenu, et de faire des révisions peut prendre de plusieurs cycles avant que la version finale soit envoyée à la Gestion pour approbation.

Du point de vue de gestionnaire de réseau, il est important de négocier les résultats réalisables qui peuvent être mesurés. Essayez de sauvegarder la représentation et la Disponibilité d'accords avec ceux d'autres organismes relatifs. Ceci peut inclure des définitions de qualité, des définitions de mesure, et des objectifs de qualité. Souvenez-vous que le service ajouté est équivalent aux dépenses supplémentaires. Assurez-vous que les groupes d'utilisateurs comprennent que les niveaux supplémentaires du service coûteront plus et les permettent de prendre la décision si c'est une condition requise essentielle d'affaires. Vous pouvez facilement effectuer une analyse des coûts sur beaucoup d'aspects de SLA tels que le temps de remplacement de matériel.

Étape 16 : Conformité de SLA de mesure et de moniteur

La conformité de SLA et les résultats de mesure de signaler sont de importants aspects du processus de SLA qui aident à assurer la cohérence à long terme et les résultats. Nous recommandons généralement que n'importe quel principal composant de SLA soit mesurable et qu'une méthodologie de mesure soit mise en place avant l'implémentation de SLA. Alors tenez les réunions mensuelles entre l'utilisateur et les comités de soutien pour passer en revue les mesures, identifiez les causes principales de problème, et proposez les solutions pour répondre ou dépasser à l'exigence de niveau de service. Ceci aide à rendre le processus de SLA semblable à n'importe quel programme d'amélioration moderne de qualité.

La section suivante fournit le détail supplémentaire sur la façon dont la Gestion dans une organisation peut évaluer son SLA et sa Gestion globale de niveau de service.

Indicateurs de performances de gestion des niveaux de service

Les indicateurs de performances de gestion de niveau de service fournissent un mécanisme pour surveiller et améliorer des niveaux de service comme mesure de succès. Ceci permet à l'organisation pour réagir plus rapide pour entretenir des problèmes et à comprennent plus facilement les questions qui affectent le service ou le coût de temps d'arrêt dans son environnement. La mesure des définitions du niveau de service réalise une inversion également n'importe quel travail anticipé positif effectué parce que l'organisation est forcée dans une position réactive. Personne n'appellera dire que le service est fonctionner grand, mais beaucoup d'utilisateurs appelleront dire le service en ne répondant pas à leurs exigences.

Les indicateurs de performances de gestion de niveau de service sont donc une exigence fondamentale pour la Gestion de niveau de service parce qu'ils fournissent les moyens de comprendre entièrement des niveaux de service existant et de faire des réglages basés sur les questions actuelles. Ce sert de base à fournir le support proactif et à apporter des améliorations de la qualité. Quand l'organisation fait l'analyse de la cause d'origine sur les questions et apporte des améliorations de la qualité, ceci alors peut être la meilleure méthodologie pour améliorer la Disponibilité, la représentation, et la qualité de service disponible.

Par exemple, considérez le vrai scénario suivant. La société X obtenait de nombreuses plaintes d'utilisateur que le réseau avait lieu fréquemment vers le bas pendant des longues périodes. En mesurant la Disponibilité, la société fondent le problème grave pour être quelques sites du WAN. La recherche plus approfondie de ces vues a indiqué que la plupart des problèmes étaient à quelques sites du WAN. La cause principale a été trouvée et l'organisation a résolu le problème. L'organisation a alors fixé des objectifs du niveau de service pour la Disponibilité et a conclu des accords avec des groupes d'utilisateurs. Les futures mesures ont identifié des problèmes rapidement en raison de la nonconformité à SLA. Le groupe réseau a été alors visualisé en tant que disposant d'une professionnalisme plus élevée, d'une expertise, et d'une ressource globale à l'organisation. Le groupe s'est efficacement déplacé de réactif à proactif en nature et a aidé la ligne inférieure de la société.

Malheureusement, la plupart des organisations de mise en réseau aujourd'hui n'ont limité les définitions du niveau de service et aucun indicateur de performances. En conséquence, ils passent la majeure partie de leur temps réagissant aux plaintes d'utilisateur ou aux problèmes au lieu proactivement d'identifier la cause principale et d'établir un service réseau qui répond à des exigences d'affaires.

Utilisez les indicateurs de performances suivants de SLA pour déterminer le succès du processus de gestion de niveau de service :

  • Définition du niveau de service documentée ou SLA qui inclut la Disponibilité, la représentation, le temps de réponse du service réactif, les buts de la résolution des problèmes, et la retransmission des problèmes

  • Les métriques de l'indicateur de performances, y compris la Disponibilité, représentation, temps de réponse de service par priorité, chronomètrent pour les résoudre par priorité, et d'autres paramètres SLA mesurables

  • Téléconférences mensuelles de Gestion de niveau de service de réseau pour passer en revue la conformité de niveau de service et pour implémenter des améliorations

Accord de niveau de service ou définition du niveau de service documenté

Le premier indicateur de performances est simplement un document détaillant SLA ou définition du niveau de service. Les objectifs principaux de la définition du niveau de service devraient être Disponibilité et représentation parce que ce sont les exigences de l'utilisateur primaires.

Les objectifs secondaires sont importants parce qu'ils aident à définir comment la Disponibilité ou les niveaux de performance sera réalisée. Par exemple, si l'organisation a la Disponibilité et les objectifs de performances agressifs, il sera important d'empêcher des problèmes de se produire et de réparer des problèmes rapidement quand ils se produisent. Les objectifs secondaires aident à définir les processus requis pour réaliser la Disponibilité et les niveaux de performance désirés.

Les objectifs secondaires réactifs incluent :

  • Temps de réponse du service réactif par priorité d'appel

  • Buts de la résolution des problèmes ou durée moyenne de reprise

  • Procédures d'escalade des problèmes.

Les objectifs secondaires proactifs incluent :

  • Détection de périphérique-vers le bas ou de lien-vers le bas

  • Détection d'erreur sur le réseau

  • Détection de capacité ou de problème de performances.

La définition du niveau de service pour des objectifs principaux, la Disponibilité, et la représentation devrait inclure :

Le but

  • Comment le but sera mesuré

  • Interlocuteurs responsables de mesurer la Disponibilité et la représentation

  • Interlocuteurs responsables de la Disponibilité et des objectifs de performances

  • Processus de nonconformité

Si possible, nous recommandons que les interlocuteurs responsables de la mesure et les interlocuteurs responsables des résultats soient différents empêcher un conflit d'intérêt. De temps en temps, lui que vous pouvez également avoir besoin pour ajuster des taux de disponibilité en raison de des erreurs ajoutez/mouvement/modification, erreurs non détectées, ou Disponibilité de problèmes de mesure. La définition du niveau de service peut également inclure un processus pour modifier des résultats pour aider à améliorer la précision et à empêcher les réglages inexacts. Voyez la section suivante pour que les méthodologies mesurent la Disponibilité et la représentation.

La définition du niveau de service pour des objectifs secondaires réactifs définit comment l'organisation répondra au réseau ou aux problèmes de la taille du service informatique après qu'ils soient identifiés, incluant :

  • Définitions des priorités de problème

  • Temps de réponse du service réactif par priorité d'appel

  • Buts de la résolution des problèmes, ou durée moyenne de reprise

  • Procédures d'escalade des problèmes

Généralement ces buts définissent qui sera responsable des problèmes n'importe quelle heure donnée et dans quelle mesure ces responsables devrait relâcher leurs tâches en cours de travailler sur les problèmes définis. Comme d'autres définitions du niveau de service, le document de niveau de service devrait détailler comment les buts seront mesurés, des interlocuteurs responsables de la mesure, et des processus de nonconformité.

La définition de service pour des objectifs secondaires proactifs définit comment l'organisation fournit le support proactif, y compris l'identification du réseau vers le bas, des états de lien-vers le bas ou de périphérique-vers le bas, des cas d'erreur réseau, et des seuils de capacité du réseau. Fixez les buts qui promeuvent l'administration proactive parce que les aides d'administration proactive de qualité éliminent des problèmes et les aides réparent des problèmes plus rapides. Ceci est normalement accompli en fixant un but de combien de cas anticipés sont créés et résolus sans notification d'utilisateur. Beaucoup d'organismes ont installé un indicateur en logiciel de centre d'assistance pour identifier des cas anticipés contre des cas réactifs à cet effet. Le document de niveau de service devrait également contenir les informations sur la façon dont le but sera mesuré, des interlocuteurs responsables de la mesure, et des processus de nonconformité.

Métriques de l'indicateur de performances

Nous toujours recommandons que n'importe quel objectif du niveau de service défini soit mesurable, permettant à l'organisation pour mesurer des niveaux de service, identifions les questions de service de cause principale qui empêchent l'objectif principal de la Disponibilité et de la représentation, et apporter les améliorations qui sont les cibles spécifiques visées. De façon générale, les mesures sont simplement un outil qui permet à des gestionnaires de réseau pour gérer la cohérence de niveau de service et pour apporter des améliorations selon des conditions requises d'affaires.

Malheureusement, beaucoup d'organismes ne collectent pas la Disponibilité, la représentation, et d'autres mesures. Les organismes attribuent ceci à l'incapacité de fournir la précision, le coût, le temps système de réseau, et les ressources disponibles complets. Ces facteurs peuvent affecter la capacité de mesurer des niveaux de service, mais l'organisation devrait se concentrer sur les buts globaux pour gérer et améliorer des niveaux de service. Beaucoup d'organismes ont pu créer le petit prix, les mesures de bas-temps système qui ne peuvent pas fournir la précision complète, mais satisfont ces objectifs principaux.

La Disponibilité et la représentation de mesure est une zone souvent négligée dans des mesures de niveau de service. Les organismes qui sont réussis avec ces mesures utilisent deux méthodes assez simples. Une méthode est d'envoyer des paquets de ping de Protocole ICMP (Internet Control Message Protocol) d'un principal emplacement dans le réseau aux périphéries. Vous pouvez également obtenir la représentation suivre cette méthode. Les organismes qui sont réussis avec cette méthode également groupent les périphériques similaires dans la « Disponibilité de groupes, » comme des périphériques de RÉSEAU LOCAL ou des bureaux sur site domestiques. C'est également attrayant parce que les organismes ont habituellement des buts de niveau de service différent pour différentes zones géographiques ou critiques du réseau. Ceci laisse le groupe de mesures pour faire la moyenne de tous les périphériques avec la Disponibilité de groupe pour obtenir un résultat raisonnable.

L'autre méthode réussie de calculer la Disponibilité est d'utiliser des dossiers d'incident et une mesure appelée les minutes d'utilisateur concernées (IUM). Cette méthode tabule le nombre d'utilisateurs qui ont été affectés par une panne et le multiplie par le nombre de compte rendu de la panne. Une fois exprimé en pourcentage des minutes totales pendant le délai prévu, ceci peut être facilement converti en Disponibilité. Dans l'un ou l'autre de cas, il peut également être utile d'identifier et mesurer la cause principale du temps d'arrêt de sorte que l'amélioration puisse plus facilement être visée. Les catégories de cause principale incluent des problèmes matériels, des problèmes logiciels, des problèmes de lien ou de transporteur, alimentation ou des problèmes d'environnement, des pannes de modification, et erreur utilisateur.

Les objectifs de l'assistance réactive mesurables incluent :

  • Temps de réponse du service réactif par priorité d'appel

  • Buts de la résolution des problèmes, ou durée moyenne de reprise

  • Temps de retransmission des problèmes

Les objectifs de l'assistance réactive de mesure en générant signale des bases de données de centre d'assistance, y compris les champs suivants :

  • Le temps où un appel a été au commencement signalé (ou entré dans la base de données)

  • Le temps où l'appel a été reçu par fonctionner individuel sur le problème

  • Le temps où le problème a été fait suivre

  • Le temps le problème était fermé

Ces mesures peuvent exiger de l'influence de Gestion d'écrire uniformément des problèmes dans les problèmes de base de données et de mise à jour en temps réel. Dans certains cas, les organismes peuvent générer automatiquement des dossiers d'incident pour des événements réseau ou des demandes de courrier électronique. Ceci aide à fournir la précision pour identifier l'heure de début d'un problème. Les états générés de ce genre de mesure trieront normalement des problèmes par priorité, groupe de travail, et personne pour aider à déterminer des éventuels problèmes.

Mesurant le support proactif des processus est plus difficile parce qu'il exige de vous de surveiller le travail anticipé et de calculer une certaine mesure de son efficacité. Peu de travail a été effectué dans cette zone. Il est clair, cependant, que seulement un petit pourcentage des personnes signalera réellement des problèmes de réseau à un centre d'assistance, et quand elles signalent le problème, cela prendra clairement du temps d'expliquer le problème ou d'isoler le problème en tant qu'étant lié au réseau. Non tous les cas anticipés exerceront un effet immédiat sur la Disponibilité et la représentation en raison de la panne des périphériques ou des liens redondants aura peu d'incidence sur des utilisateurs finaux.

Les organismes qui implémentent des définitions de niveau de service anticipé ou des accords font ainsi en raison des conditions requises d'affaires et du risque d'atteinte à la disponibilité potentiel. La mesure est alors faite en termes de quantité ou pourcentage des cas anticipés, par opposition aux cas réactifs qui sont générés par des utilisateurs. C'est une bonne idée de mesurer la quantité de cas anticipés dans chaque zone aussi bien. Ces catégories incluraient en bas des périphériques, vers le bas des liens, des erreurs réseau, et des violations de capacité. Un certain travail peut également être effectué utilisant la modélisation de Disponibilité et les cas anticipés pour déterminer l'effet en Disponibilité réalisée en mettant en application des définitions de service anticipé.

Examen de gestion des niveaux de service

Une autre mesure de succès de Gestion de niveau de service est l'analyse de la gestion de niveau de service. Ceci devrait être fait si le SLA sont en place. Exécutez l'analyse de la gestion de niveau de service lors d'une téléconférence mensuelle avec des personnes responsables de mesurer et de fournir les niveaux de service définis. Les groupes d'utilisateurs peuvent également être présents où le SLA sont impliqué. Le but de la téléconférence est alors de passer en revue la représentation des définitions du niveau de service mesurées et d'apporter des améliorations.

Chaque téléconférence devrait avoir un ordre du jour défini qui inclut :

  • Examen des niveaux de service mesurés pour la période donnée

  • Examen des initiatives d'amélioration définies pour différentes zones

  • Mesures en cours de niveau de service

  • Un examen de quelles améliorations sont nécessaires basées sur l'ensemble en cours de mesures.

Au fil du temps, l'organisation peut également tendre la conformité de niveau de service pour déterminer l'efficacité du groupe. Ce processus n'est pas à la différence d'un processus de cercle de qualité ou d'amélioration de la qualité. La téléconférence aide différents problèmes de cible et détermine des solutions basées sur la cause principale.

Résumé de gestion des niveaux de service

En résumé, la Gestion de niveau de service permet à une organisation pour se déplacer d'un modèle de support réactif à un modèle de support proactif où la Disponibilité et les niveaux de performance de réseau sont déterminés par des conditions requises d'affaires, pas par le dernier ensemble de problèmes. Les aides de processus créent un environnement d'amélioration continue de niveau de service et de compétitivité accrue d'affaires. La Gestion de niveau de service est également le composant de Gestion le plus important pour la Gestion de réseau proactive. Pour cette raison, la Gestion de niveau de service est fortement recommandée dans n'importe quelle phase de planification du réseau et de conception et devrait commencer par n'importe quelle architecture de réseau nouvellement définie. Ceci permet à l'organisation pour implémenter des solutions correctement la première fois, avec le moins temps d'arrêt ou reprise.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 15117