Capacité d'optimisation d'infrastructure : processus de gestion ITIL/COBIT - du niveau standardisé au niveau rationalisé

Sur cette page

Présentation Présentation
Exigence : processus d'opération, d'optimisation et de modification Exigence : processus d'opération, d'optimisation et de modification

Présentation

Des processus reposant sur les meilleures pratiques doivent être définis pour l'ensemble des tâches associées au modèle d'optimisation d'infrastructure. Le tableau suivant dresse la liste des principaux enjeux, des solutions applicables et des avantages liés à l'accession au niveau rationalisé de la capacité Processus de gestion ITIL/COBIT.

Enjeux

Solutions

Avantages

Enjeux métier

Les contrats de niveau de service (SLA) sont informels ou appliqués.

La gestion de la configuration informelle se compose de listes de vérification et de feuilles de calcul.

Enjeux informatiques

Gestion informelle des versions

Projets

Implémenter une gestion des niveaux de services sur l'ensemble des opérations informatiques

Implémenter une gestion des versions reposant sur les meilleures pratiques

Optimiser les processus d'administration système et réseau.

Implémenter une planification des tâches reposant sur les meilleures pratiques

Avantages métier

Des opérations informatiques proactives résolvent les problèmes de façon plus précoce, évitant ainsi de grever la productivité des utilisateurs

Avantages informatiques

Des services et outils automatisés libèrent des ressources afin d'implémenter de nouveaux services et d'optimiser les services existants.

Les contrats de niveau de service formels lient le service informatique à l'entreprise en améliorant sa crédibilité.

Le niveau rationalisé d'optimisation exige que votre organisation ait défini des procédures dans les domaines suivants : gestion des incidents, gestion et traitement des incidents, test d'applications, gestion des problèmes, assistance aux utilisateurs, gestion des configurations et gestion des changements.

Exigence : processus d'opération, d'optimisation et de modification

Public visé

Nous vous recommandons de lire cette section si vous ne disposez pas de processus de gestion des niveaux de service, de gestion des versions, d'administration des systèmes, d'administration du réseau et de planification des tâches.

Vue d'ensemble

L'optimisation d'infrastructure s'étend bien au-delà des simples produits et technologies. Les personnes et les processus participent en grande partie à la maturité du service informatique d'une organisation. Un certain nombre d'organismes de normalisation et de définition des meilleures pratiques traitent le thème des processus et des individus dans la gestion du service informatique. Microsoft Operations Framework (MOF) met en application une grande partie des connaissances contenues dans les normes ITIL (Infrastructure Library) et COBIT (Control Objectives for Information and related Technology) dont peuvent bénéficier les clients de Microsoft.

Phase 1 : analyse

Dans le cadre de la gestion des opérations, la phase d'évaluation vise à évaluer les capacités et les enjeux actuels de l'organisation. Pour prendre en charge le processus d'évaluation des opérations, Microsoft a développé l'évaluation de la gestion de service MOF dans le cadre du Plan d'amélioration continue MOF, avec une version en ligne plus légère appelée Outil d'auto-évaluation MOF.

Figure 16. Cycle de vie MOF d'amélioration continue

Figure 16. Cycle de vie MOF d'amélioration continue

L'évaluation de gestion de service MOF vise à améliorer la performance des personnes et des processus de gestion du service informatique, et à mettre en œuvre les technologies qui améliorent la valeur ajoutée. Toutes les recommandations découlant de cette évaluation sont détaillées et argumentées. Un plan d'amélioration continue MOF est même fourni, étayé par des indicateurs de performance clés afin de suivre les progrès réalisés à mesure que les améliorations sont apportées.

Phase 2 : identification

Les résultats de l'évaluation de gestion de service MOF constituent le socle de la phase d'identification. Bien souvent, l'évaluation permet d'identifier plusieurs domaines d'amélioration potentielle dans les opérations informatiques. Lors de la phase d'identification, nous prenons en compte ces résultats et hiérarchisons les projets d'amélioration en fonction des besoins de l'entreprise. Des outils et des aide-mémoire sont inclus dans le Plan d'amélioration continue MOF pour vous aider dans la définition des priorités.

Phase 3 : évaluation et planification

Dans le cadre de l'amélioration opérationnelle, la phase d'évaluation et de planification s'appuie sur les domaines d'amélioration identifiés et hiérarchisés. L'aide du programme d'amélioration du service MOF est d'ailleurs conçue pour faciliter cette phase. Ce programme se divise en deux domaines d'intérêt principaux : amélioration des processus MOF/ITIL et aide à l'amélioration du service. Cette aide est fournie via un outil qui assiste les utilisateurs dans l'identification de leurs difficultés spécifiques et propose des solutions, le tout étayé par des indicateurs de performance clés permettant de mesurer l'impact des améliorations apportées au processus.   

Processus recommandés pour l'accès au niveau rationalisé

Les recommandations de cette section reposent sur les problèmes courants décelés au niveau standardisé ainsi que les domaines d'amélioration recherchés par le niveau rationalisé. Il s'agit là de recommandations uniquement, lesquelles peuvent varier selon les spécifications de votre organisation ou de votre secteur d'activité.

Les domaines clés sont perfectibles bien que le niveau standardisé soit synonyme d'une utilisation plus intensive des outils de gestion et de surveillance des opérations et de l'infrastructure informatiques, en plus d'un environnement dans lequel les processus de gestion des changements, de gestion de la configuration et de gestion des versions sont standardisés et prévisibles. La gestion des niveaux de service s'avère rudimentaire avec les contrats de niveau de service informels ou uniquement appliqués. La gestion de la configuration est informelle et se compose généralement de listes de vérification et de feuilles de calcul tandis que la gestion des versions n'est pas correctement définie et manque de rigueur.

L'infrastructure rationalisée réduit au minimum les coûts de gestion des postes de travail et des serveurs et utilise des processus et stratégies suffisamment sophistiqués pour commencer à jouer un grand rôle dans le support et le développement des activités. La sécurité s'avère très proactive et les réponses aux menaces et enjeux sont rapides et contrôlées. L'approche de déploiement « zéro intervention » réduit les coûts, le temps requis pour les opérations de déploiement et les problèmes techniques. Le nombre d'images est minimal et le processus de gestion des ordinateurs de bureau nécessite peu, voire pas d'intervention humaine. Les entreprises disposent d'un inventaire matériel et logiciel bien précis et n'achètent que les licences et les ordinateurs dont elles ont besoin. La sécurité est extrêmement proactive, les stratégies et le contrôle strictement appliqués, des postes de travail au serveur, du pare-feu à l'extranet.

Microsoft propose Microsoft Operations Framework (MOF) comme modèle itératif de définition et d'amélioration des opérations informatiques. MOF définit les fonctions de gestion de services (ou SMF, Service Management Functions) comme des fonctions opérationnelles logiques au sein d'une organisation informatique. Les fonctions de gestion de service sont regroupées en quatre domaines ou quadrants : modification, exploitation, prise en charge et optimisation. Ce guide met l'accent sur les domaines à améliorer généralement présents dans les organisations du niveau d'optimisation standardisé :

  • gestion des niveaux de service ;

  • gestion des versions ;

  • administration du système ;

  • administration du réseau ;

  • planification des tâches.

En fonction de l'organisation, les améliorations apportées à ces fonctions de gestion de service peuvent ou non avoir une incidence optimale sur l'efficacité et l'amélioration opérationnelles. Nous conseillons à votre organisation d'effectuer sinon une 'auto-évaluation en ligne complète, du moins une évaluation de la gestion de service complète afin d'identifier les principaux domaines nécessitant des améliorations de processus ou de service.

Gestion des niveaux de service

La gestion des niveaux de service (SLM) est un processus critique permettant d'aligner les besoins de l'entreprise sur la prestation de services informatiques. L'interface qu'elle fournit permet aux autres SMF de proposer des solutions informatiques d'un coût abordable et conformes aux exigences de l'entreprise. Elle a pour principal objectif de proposer, d'assurer et d'améliorer les services informatiques.

La gestion des niveaux de service aligne et gère les services informatiques par l'intermédiaire d'un processus de définition, d'approbation, de mesure des opérations et de révision. La portée de la gestion des niveaux de service englobe la définition des services informatiques de l'organisation ainsi que l'établissement des contrats de niveau de service correspondants. L'exécution de ces contrats de niveau de service (SLA) passe par l'utilisation d'UC (Underpinning Contracts) et de OLA (Operating Level Agreements) pour la prestation interne ou externe de services. L'introduction d'une gestion des niveaux de service dans une entreprise ne s'accompagne pas de l'amélioration immédiate des niveaux de service proposés. Il s'agit d'un processus à long terme. Initialement, le service peut être amené à légèrement évoluer, mis au fil du temps, les objectifs étant atteints, puis dépassés, il s'améliore.

Pour implémenter une gestion des niveaux de service, une organisation doit préalablement évaluer les services proposés par le service informatique à ses clients et définir les contrats de service associés. Cette analyse contribue à établir la liste des services proposés par le service informatique. Forte des informations recueillies à l'issue de cet exercice, l'organisation peut alors développer et implémenter tous les avantages du processus de gestion des niveaux de service.

La gestion des niveaux de service implique que l'organisation informatique comprenne pleinement les services qu'elle offre. L'implémentation de la gestion des niveaux de service suit les étapes ci-dessous :

  • création d'un catalogue de services ;

  • développement de contrat de niveau de service ;

  • surveillance et création de rapports ;

  • révisions régulières des niveaux de service.

Les contrats de niveau de service sont développés conformément aux exigences et priorités des services documentés dans le catalogue de services, aux exigences spécifiées sous négociation des contrats de niveau de service, à la surveillance du service par rapport aux critères des contrats ainsi qu'à la création de rapports et à la révision de ces informations afin de souligner et de supprimer les dysfonctionnements des niveaux de performances du service.

Phase 4 : déploiement (gestion des niveaux de service)

Activités de configuration

Les activités de configuration se composent de plusieurs étapes d'appréciation menées au début du projet de gestion des niveaux de service. Ces étapes préliminaires permettent à l'entreprise de déterminer le besoin éventuel d'une gestion des niveaux de service et, le cas échéant, de vérifier qu'elle dispose des ressources nécessaires à son implémentation. Dans le cadre de ce processus, le service informatique établit une référence en prenant un instantané des services et des activités de gestion. La dernière étape consiste à analyser les informations recueillies lors des étapes précédentes et d'utiliser ces résultats pour planifier l'implémentation de la gestion des niveaux de service afin de permettre à l'entreprise d'en tirer le meilleur parti.

Création d'un catalogue de services

Le catalogue de services répertorie tous les services actuellement proposés, en récapitule les caractéristiques, décrit les utilisateurs de ces services et détaille les opérations de maintenance les concernant.

Un service est défini par la perception de l'organisation. Par exemple, un courrier électronique peut être un service, de même qu'une impression, quel que soit le nombre de composants requis pour proposer le service à l'utilisateur final.

La création d'un catalogue de services est une étape importante en ce sens qu'elle crée un enregistrement officiellement reconnu. Dès lors qu'un catalogue de services relève d'un enregistrement officiel, ses modifications font l'objet d'un contrôle. Ceci est important car l'enregistrement n'est valable que s'il est conservé et précis.

Il existe plusieurs façons de créer un catalogue des services. Au moment de choisir la méthode qui vous convient le mieux, pensez à la manière dont vous souhaitez afficher et utiliser le catalogue de services. Un catalogue de services peut être stocké dans une base de données de gestion de la configuration (CMDB) sous forme de composant (le catalogue de services) ou de ses services. Les applications Microsoft, comme Microsoft Excel ou Microsoft Access, peuvent être utilisées pour enregistrer les services ainsi que des détails tels que les composants, les effets, les priorités, les contrats de niveau de service et autres informations. Si l'outil sélectionné permet l'intégration du catalogue de services à la base de données CMDB, sa valeur peut être renforcée par l'ajout d'informations au catalogue avec l'élément de configuration (IC) de la base de données CMDB. Il peut ensuite être utilisé pour renforcer la valeur de la fonction de gestion des changements, de la gestion des incidents SMF et des autres SMF à l'aide de la base de données CMDB.

Développement de contrats de niveau de service (SLA)

Un contrat de niveau de service est un contrat entre le fournisseur de service informatique et la communauté de clients/utilisateurs. Le contrat de niveau de service crée les exigences clients/utilisateurs des niveaux de service et définit les responsabilités de tous les participants.

Les étapes de création d'un contrat de niveau de service sont les suivantes :

  • Définir le type de contrat de niveau de service. Par exemple, s'agit-il d'un contrat de niveau de service interne, externe, de niveau opérationnel ou de niveau multiservice ?

  • Définir les contrats de niveau de service. Par exemple, quels niveaux de service seront proposés, y compris des éléments mesurables comme la disponibilité, la réactivité et les performances, l'intégrité et la précision ainsi que la sécurité.

  • Négocier et accepter des contrats de niveau de servie. Par exemple, déterminer si ce qui a été accepté peut être proposé moyennant un coût raisonnable à l'entreprise et au service informatique.

  • Documenter le contrat de niveau de service. Par exemple, consigner par écrit ce qui a été accepté et qui est impliqué.

Alignement des engagements SLA, OLA et UC

Les UC (Underpinning Contracts), des contrats légaux avec un fournisseur de service tiers sur lesquels reposent les livrables de service des SLA, ainsi que les OLA (Operational Level Agreements), des contrats internes prenant en charge les exigences des SLA, doivent disposer de mesures de service alignées à l'engagement SLA.

Surveillance des niveaux de service

La gestion des niveaux de service implique un cycle d'acceptation, de surveillance et de création de rapports sur les réalisations du service informatique ainsi que la prise de mesures appropriées visant à équilibrer les niveaux ce service par rapport aux besoins et coûts de l'entreprise.

Une fois les contrats de niveau de service acceptés et mis en place, l'étape suivante en matière de gestion des niveaux de service consiste à surveiller les performances des services par rapport aux critères spécifiés dans les objectifs des niveaux de service (SLO). Plusieurs méthodes permettent de surveiller la gestion des niveaux de service, mais il convient de bien vérifier qu'aucun critère n'entraîne la rupture du contrat de niveau de service ou s'en approche.

Révision du contrat de niveau de service

La révision du contrat de niveau de service correspond à l'une des quatre révisions de la gestion des opérations (OMR) MOF. Il s'agit là d'un point de contrôle de gestion clé intervenant à des intervalles spécifiés (comme indiqué dans le contrat de niveau de service). Cette révision permet de veiller à ce que l'entreprise et le service informatique puissent analyser les performances par rapport aux objectifs du niveau de contrat de service et de réviser le fonctionnement de ce contrat. La révision du contrat de niveau de service est conçue pour intégrer la gestion au processus de révision, en veillant à ce que l'intégration et la communication soient présentes depuis le service informatique et l'entreprise dans toutes les décisions futures relatives à la prestation du service.

Gestion des versions

La fonction Gestion des versions se charge du déploiement des modifications dans un environnement informatique. Après qu'une ou plusieurs modifications ont été développées, testées et intégrées aux versions à des fins de déploiement, la gestion des versions a pour objectif de veiller à l'implémentation de ces modifications. La gestion des versions permet également de présenter efficacement les modifications en les associant à une seule version et en les déployant simultanément.

Le processus de gestion des versions a pour objectif de veiller au déploiement le plus fluide possible des modifications dans l'environnement informatique. Dès lors, la gestion des versions permet de :

  • définir la stratégie correspondante, à savoir la conception, le plan et l'approche de déploiement d'une modification à la production en collaboration avec le comité consultatif sur les modifications (CAB) ;

  • déterminer le moment où chaque version est prête selon certains critères (qualité et package de la version, moment où l'environnement de production est prêt, plans de formation et de prise en charge, plans de déploiement et de sauvegarde, plan de gestion des risques).

La gestion des versions :

  • propose une version conditionnée de toutes les modifications déployées dans la production et ne déploie que les modifications approuvées par la gestion des changements ;

  • requiert la gestion des changements pour approuver les modifications et les suivre tout au long du processus de diffusion ;

  • veille à ce que les modifications soient rapportées à la gestion de la configuration en vue de leur enregistrement dans la base de données CMDB ;

  • requiert des informations de gestion de la configuration pour mettre en place et vérifier des environnements de tests valides lors de la phase de développement de la nouvelle version ;

  • requiert la gestion de la configuration pour analyser l'impact des modifications sur l'environnement informatique et proposer un magasin définitif pour le package de la version.

Phase 4 : déploiement (gestion des versions)

Planification des versions

La première étape du processus de diffusion correspond à la création d'un plan d'identification des activités et ressources nécessaires au déploiement d'une version dans l'environnement de production. Ce plan implique que vous définissiez les tâches à effectuer, le moment où elles doivent être terminées (échelle de temps) ainsi que leur ordre de priorité. Une fois ces différents points pleinement compris, le responsable de la diffusion peut établir un plan détaillé des activités et allouer au projet les ressources qui conviennent. Dans la gestion des versions, le responsable de la diffusion est chargé de créer un plan de version (projet) pour chaque RFC approuvée par la gestion des changements.

Génération de la version

Une fois le plan de la version approuvé, les membres de l'équipe de diffusion identifient et développent les processus, outils et technologies nécessaires au déploiement en production de la version. Plusieurs outils et technologies permettent de déployer les versions automatiquement même si le déploiement peut être effectué manuellement. Pour une optimisation du temps et des ressources, l'équipe de diffusion a tout intérêt à identifier les outils et technologies qui lui permettent d'automatiser au maximum le processus de déploiement.

Une fois le mécanisme de la version sélectionné, l'équipe de diffusion crée un package de version contenant les processus, outils et technologies nécessaires au déploiement en production de la version à l'aide du mécanisme sélectionné et sa suppression de la production, si nécessaire.

Le package de certaines versions peut ne contenir que quelques procédures documentées d'installation et de suppression.

Le package complet doit être testé en laboratoire pour permettre à l'équipe de diffusion de disposer d'un degré de confiance relatif à sa fonctionnalité en production. En supposant que les tests se déroulent bien, la version et le contenu du package sont ensuite soumis au contrôle de la gestion des changements.

Tests d’acceptation

Jusqu’à ce point, l’objectif des tests a été de confirmer que la version et son package fonctionnent correctement dans un environnement de développement. Les tests d'acceptations permettent aux développeurs et représentants de savoir comment la version et son package se comportent dans un environnement proche de l'environnement de production. Dans certains cas, des tests pilotes sont requis afin de susciter la confiance nécessaire au déploiement à l'échelle de l'organisation de la modification.

Bien que les tests simulés dans un environnement de production offrent à l'équipe de diffusion un certain degré de confiance, ils ne garantissent pas le bon fonctionnement de la version en production compte tenu de conditions différentes. Dès lors, il peut s'avérer nécessaire de lancer un certain nombre de tests contrôlés dans l'environnement de production afin de s'assurer que la version répond aux attentes. Le pilotage d'une version dans un environnement de production expose ce dernier à des risques et ne doit intervenir que si les procédures de récupération contenues dans le package ont été testées dans l'environnement correspondant.

Préparation de la version

Une fois les tests pilotes et test d'acceptation terminés, l'étape suivante consiste à préparer l'environnement de production pour la version, à passer au processus de préparation et à définir la mesure à prendre, c'est-à-dire son passage en révision de la préparation ou son retour au propriétaire des modifications ou au responsable de la diffusion.

Le responsable de la diffusion, le responsable des modifications et le propriétaire des modifications sont trois personnes principales à prendre part à la discussion relative à la révision de la préparation, mais les représentants d'autres groupes intéressés, comme les équipes des tests, le centre de services et la communauté des utilisateurs (en fonction de la nature et de la taille de la version) peuvent également y participer.

Bien qu'une version ait échoué à plusieurs tests, en laboratoire comme dans l'environnement de production, ces échecs ne suffisent pas nécessairement à empêcher son déploiement. Malgré les implications pour l'environnement de production, plusieurs raisons commerciales peuvent justifier le déploiement de la version.

Par exemple, sur un site de commerce d'entreprise à entreprise, une fonction, comme l'inscription automatisée, peut ne pas fonctionner. Il est facile de supprimer cette fonction et d'utiliser une solution de contournement manuelle. Dès lors, l'équipe peut choisir de poursuivre sans cette fonction.

Les expériences et leçons tirées des tests (en plus des solutions de contournement développées) sont capturées et documentées. Si des problèmes affectant la communauté des utilisateurs ou les niveaux de service ont été décelés lors des tests, il convient de débattre des solutions de contournement et problèmes envisagées avec les représentants du centre de services et de veiller à ce que ces solutions de contournement soient mises à la disposition du centre de services avant tout déploiement. D'autres RFC peuvent être lancées afin d'assurer le bon fonctionnement de la version comme prévu. Quoi qu'il en soit, le journal des modifications doit être mis à jour et la décision ainsi que toute autre information de prise en charge doivent y être consignées.

Déploiement de la version

Le processus de déploiement de la version dans l'environnement de production dépend du type et de la nature de la version ainsi que du mécanisme de diffusion sélectionné. Dans tous les cas, cependant, les rapports d'état, le cas échéant, les outils et les technologies permettant de suivre et de surveiller le processus de déploiement doivent être remis au responsable de la publication. Lors du déploiement, chaque fois que des modifications sont apportées aux composants informatiques, les modifications correspondantes doivent être apportées aux éléments de configuration et relations qui les modèlent dans la base de données CMDB.

Une fois la version déployée, le responsable de la diffusion en confirme le bon fonctionnement avant de poursuivre les déploiements. Pour certaines versions, le personnel technique peut obtenir cette confirmation à l'aide de plusieurs outils et technologies ; pour d'autres, le responsable de la diffusion doit demander au centre de services de contacter des utilisateurs pour connaître leurs impressions et commentaires.

Si la version ne répond pas aux attentes ou si son déploiement a été entaché de sérieux problèmes, la gestion des problèmes peut être nécessaire pour identifier et définir la cause de ces problèmes. Si un correctif ou une solution de contournement sont trouvés, ils doivent être documentés et une demande de modification doit être créée afin de permettre son déploiement dans l'environnement de production. Sinon, il peut s'avérer nécessaire de recourir aux procédures de suppression de la version de l'environnement.

Une fois la phase de déploiement de la version terminée, le processus de diffusion doit veiller à ce que les résultats et informations des solutions de contournement ou RFC résultant de la prise en charge de la version soient consignés. Si la version doit être supprimée, cela doit également être consigné, de même que les informations justifiant une telle décision.

Administration du système

La fonction Administration du système permet les activités suivantes : administration de la sécurité, analyse et contrôle du service, planification des tâches, administration du réseau, administration des services d'annuaire, administration des impressions et des sorties et gestion du stockage. La manière dont cette fonction est conçue, développée et implémentée dépend de la taille et de l'architecture de l'organisation. Les grandes organisations disposeront de modèles clairement définis tandis que les plus petites organisations auront tendance à consolider leurs fonctions afin de préserver l'intégrité et les capacités opérationnels de leurs systèmes.

La fonction d'administration système a pour objectif d'administrer un environnement informatique quotidiennement. Cela passe par la gestion et la mise à disposition d'une prise en charge opérationnelle de divers éléments de l'environnement de production.

La fonction d'administration système fournit des services administratifs prenant en charge les environnements informatiques qui contiennent du matériel centralisé et distribué.

La fonction d'administration système peut également fournir une assistance par l'administration fonctionnelle d'autres fonctions non directement responsables de l'implémentation et de la gestion. Cette assistance peut inclure :

  • des performances de premier niveau et une analyse des capacités de la fonction d'analyse et de contrôle du service ;

  • l'administration fonctionnelle quotidienne de gestion des comptes, comprenant notamment l'ajout, la suppression ou le déplacement de comptes ; les requêtes de ressources comme les imprimantes ou les privilèges d'accès de sécurité pour l'administration des services d'annuaire et l'administration de la sécurité ;

  • la gestion des ressources utilisées pour produire des rapports imprimés et sortis à des fins de gestion ;

  • les tâches administratives nécessaires à la sauvegarde et à la restauration des données critiques ;

  • la mise en place d'une stratégie de sécurité visant à protéger les données et les ressources du réseau partagé parmi lesquelles les fichiers, dossiers et imprimantes.

Phase 4 : déploiement (administration système)

Implémentation du modèle d'administration centralisée

Dans le modèle d'administration centralisée, la plupart des opérations et fonctions de prise en charge dont regroupées sur un ou plusieurs sites. Avec l'évolution des réseaux locaux, étendus, distribués et client-serveur, de plus en plus d'organisations ont mis en place une prise en charge centralisée des ressources, applications et solutions installées.

La bande passante vers les sites distants et les filiales est plus disponible et plus abordable. Les technologies de base prenant en charge l'informatique des filiales (protocoles de transmission, outils d'accès à distance, serveurs administrés à distance, etc.) ont été nettement améliorées au point de ne plus justifier leur propre personnel de support. Les entreprises sont de plus en plus capables de centraliser les fonctions de support requises afin d'assurer la disponibilité, la fiabilité, le support quotidien et la gestion des systèmes distribués sur les sites distants ou les filiales.

L'administration centralisée considère généralement que la plupart, voire tous les systèmes et ressources informatiques gérés sont centralisés. Bien que cela se vérifie de plus en plus, il arrive que des solutions spécifiques (à savoir des applications personnalisées, des bases de données spécialisées, etc.) ne soient pas centralisées, mais distribuées aux sites distants ou filiales. Cette distribution de certaines applications et bases de données n'empêche pas l'adoption d'une approche centralisée du modèle administratif.

Implémentation du modèle d'administration centralisée/distante

Le modèle d'administration centralisée/distante rassemble la plupart des avantages du modèle d'administration centralisée. L'administration continue d'être centralisée (par exemple, le centre de données est central) et conserve donc le contrôle et la consolidation des ressources nécessaires à l'exécution de la fonction administrative.

Une part du contrôle et de la consolidation des ressources est cependant abandonnée compte tenu de l'exigence de maintien d'un centre de donnée distant avec au moins une présence administrative localisée. Les exigences de maintenance du système remède sur le système distribué peuvent inclure des mises à jour nécessitant le redémarrage de l'ordinateur ainsi qu'une sauvegarde sur bande et des obligations de stockage. D'autres exigences administratives locales peuvent exister en fonction de l'application ou du système spécifique géré ; vous devrez décider des responsabilités spécifiques nécessaires selon votre application technologique.

Le modèle d'administration centralisée/distante décrit les systèmes distribués sur les sites distants, le gros du contrôle administratif demeurant à l'emplacement central. Comme indiqué précédemment, le site distant ou régional doit désormais disposer d'un centre de données afin d'héberger les serveurs et unités de stockage. Cela implique des coûts d'infrastructure (usine physique, encombrement, électricité, câbles, chauffage, ventilation, climatisation et sécurité).

Si l'application technologie évolue au point que ce modèle ne soit plus viable (à savoir qu'il ne répond plus aux contrats de niveau de service) ou qu'il ne soit plus rentable, vous pouvez être amené à passer au modèle d'administration distribuée. Dans le modèle d'administration distribuée, les ressources informatiques ainsi que le personnel sont physiquement localisés à l'emplacement distant. Ce modèle est décrit à la section suivante.

Implémentation du modèle d'administration centralisée/déléguée

Ce modèle tente de tirer au mieux parti des modèles d'administration centralisée et distante avec les fonctions et avantages qui en découlent tout en bénéficiant de certains avantages du modèle d'administration distribuée. Ces avantages sont atteints en transférant un petit sous-ensemble spécialisé de tâches et de responsabilités vers les filiales locales et sites distants.

Comme avec le modèle d'administration centralisée, la principale fonction administrative ainsi que les effectifs administratifs se situent au centre de données (central) de l'entreprise ; la direction administrative et le contrôle émanent de cet emplacement. Les ressources centralisées continuent de gérer les serveurs réseau et services du centre de données ; ces ressources centralisées continuent également à administrer à distance des services sur le réseau chaque fois que cela s'avère possible, raisonnable et approprié.

Certaines circonstances dictent le besoin de distribuer des services, serveurs et ressources spécifiques ; dans ce cas, il peut être prudent et/ou plus efficace de permettre certaines tâches administratives aux emplacements régionaux ou distants. Cela se fait en déléguant une autorité très spécifique vers les ressources de l'emplacement distant. On entend par « autorité très spécifique » un petit sous-ensemble de droits administratifs et d'accès permettant aux administrateurs distants d'effectuer des tâches spécifiques et discrètes.

Implémentation du modèle d'administration distribuée

Contrairement aux autres modèles, l'administration distribuée repose sur les ressources de support des sites distants et des filiales. Les ressources des sites distants se chargent des fonctions de support de base (bien que critiques) nécessaires afin de préserver l'intégrité, la disponibilité et la fiabilité des systèmes distribués à ces sites.

Ils peuvent continuer d'être des pilotes en termes de maintenance des systèmes distribués aux emplacements distants. Certains de ces pilotes peuvent être liés aux performances, à la capacité d'évolution, à un type spécifique d'application, au coût ou à la disponibilité de la bande passante réseau inhérents à une solution centralisée.

Les ressources informatiques et les effectifs sont complètement distribués sur les sites distants et régionaux. Dès lors, l'organisation peut réaliser de bien meilleures performances en matière d'applications technologiques spécifiques.

Implémentation d'une administration distribuée du modèle de centres de données centralisés

La cinquième possibilité d'administration, appelée ici modèle « course du soleil » pourrait également être appelée centre de données centralisé.

« Course du soleil », dans ce contexte, signifie proposer un support 7 jours sur 7 et 24 heures sur 24 en transférant la responsabilité de ce support à différentes régions du monde, certains bureaux ouvrant quand d'autres ferment.

Ce modèle est en quelque sorte unique et moins implémenté que les quatre modèles de base décrits précédemment. Il est à noter, cependant, que les entreprises ont tenté et tentent toujours de mettre en place ce modèle au sein de leurs organisations.

Administration du réseau

La fonction de gestion de service d'administration réseau se concentre sur le fonctionnement des réseaux en tant que composants de l'infrastructure permettant aux systèmes informatiques et périphériques partagés de communiquer entre eux. Il s'agit du niveau de base de l'infrastructure informatique ; sans installations réseau, il n'y a pas d'infrastructure, juste un ensemble d'ordinateurs individuels.

La fonction de gestion de service d'administration réseau a pour objectif de proposer et de référence une importante base de processus afin d'administrer un environnement réseau quotidiennement. Cela passe par la gestion et la mise à disposition d'une prise en charge opérationnelle de divers éléments de l'environnement de production. Cette fonction a pour objectif de proposer des services de planification et de déploiement afin d'étendre les installations réseau existantes ainsi que des services de support pour remédier aux défaillances de l'environnement réseau. L'implémentation efficace de la fonction d'administration réseau permet aux organisations informatiques d'envisager les points suivants :

  • amélioration du déploiement de leur infrastructure réseau ;

  • amélioration des processus de dépannage ainsi que des processus de gestion des incidents connexes ;

  • renforcement de la fiabilité réseau ;

  • optimisation de la disponibilité de solutions et services informatiques.

Un réseau type se compose de matériel (câbles, routeurs, commutateurs, concentrateurs, serveurs physiques et autres composants) et de logiciels ou microprogrammes contrôlant la manière dont les composants matériels sont utilisés. Dans le modèle de mise en réseau décrit par le modèle OSI (Open Systems Interconnection), l'infrastructure informatique type se compose de plusieurs couches, des composants de base utilisés par tous les services en bas de la pile aux applications spécialisées situées tout en haut.

Les couches constituant le modèle OSI sont les suivantes (de haut en bas) :

  1. Application

  2. Présentation

  3. Session

  4. Transport

  5. Réseau

  6. Liaison (liaison de données)

  7. Vulnérabilité physique

L'administration réseau concerne généralement les trois premières couches qui se composent principalement du matériel. Au niveau transport, l'administration réseau et système a tendance à se chevaucher, ce qui comprend les protocoles de liaison et de mise en réseau permettant le transfert des données d'un point à un autre. Depuis la perspective MOF, la gestion de services comme DNS, WINS et DHCP offre les services de résolution de noms nécessaires aux services informatiques riches en fonctionnalités. En fonction de l'organisation, ces services noyau peuvent inclure des fonctions de service réseau. DNS, WINS et DHCP s'exécutant sur des serveurs, les serveurs réseau sont parfois inclus dans les composants matériels gérés par la fonction d'administration réseau.

Phase 4 : déploiement (administration du réseau)

Maintenance réseau

Le fonctionnement de l'infrastructure réseau repose largement sur l'analyse de ses performances, son évaluation par rapport aux normes attendues et la génération de solutions en cas de baisse de ces performances. La plupart des composants matériels d'un réseau doivent fonctionner sans maintenance ou intervention automatisée selon les spécifications du fabricant en termes de temps moyen entre défaillance et autres critères de performances. La fonction de gestion de la capacité MOF fournit des détails sur la planification permettant à l'équipe de conception réseau d'en optimiser les performances.

Les composants serveur du réseau nécessitent cependant une attention régulière. Ces composants requièrent des sauvegardes régulières, le cas échéant, ainsi que des évaluations en termes de stockage ou de capacité conformément à la fonction de gestion du stockage.

Prise en charge réseau

La prise en charge réseau est étroitement alignée sur les activités du quadrant de support, notamment les fonctions de gestion des incidents et des problèmes. À l'aide du processus de résolution des incidents décrit dans la fonction correspondante, les spécialistes de la mise en réseau corrigent les erreurs, développent des solutions de contournement et préviennent les problèmes réseau. Bien que le processus générique de résolution des incidents soit décrit dans le document relatif à la fonction de gestion des incidents, les processus réseau en matière de dépannage sont détaillés dans les sections suivantes.

Planification des tâches

La fonction de planification des tâches permet d'assurer le traitement efficace des données à un moment prédéterminé et selon une séquence définie afin d'optimiser l'utilisation des ressources système et de minimiser l'impact sur les utilisateurs en ligne. Un processus par lots est une interaction système avec une base de données s'exécutant en arrière-plan et de manière séquentielle sans interaction d'un utilisateur final. L'exécution des processus par lots peut être lancée automatiquement ou manuellement. Les lots sont généralement exécutés après les horaires de travail lorsque l'interaction avec le système est moindre.

Les exécutions de lots requièrent généralement leur propre architecture car il s'agit de processus utilisant de nombreuses ressources, longs et répétitifs. Le processus implique généralement la lecture d'importants volumes d'une base de données, le traitement des données et le renvoi des résultats à une base de données. Ce processus s'effectue via l'exécution de scripts.

Les types de tâches par lots que les organisations exécutent sont les suivants :

  • rapports de gestion financière ;

  • rapports de marketing ;

  • rapports de gestion de la chaîne d'approvisionnement ;

  • rapports d'inventaire ;

  • rapports de facturation ;

  • traitement des comptes clients (facturation mensuelle, etc.) ;

  • sauvegardes automatisées du système et des données des applications ;

  • résumés de traitement du système et rapports de planification de la capacité.

Phase 4 : déploiement (planification des tâches)

Architecture par lots

L'architecture par lots se compose de processus et composants utilisés pour gérer efficacement le traitement des lots. L'architecture par lots a pour objectif d'optimiser le traitement (d'améliorer le temps de réponse et l'utilisation des ressources système) en exécutant des lots lors des heures creuses. L'architecture doit fournir au responsable de la capacité une interface facile à utiliser et permettre une approche standardisée et centralisée de la planification, de l'analyse, du contrôle et de la correction des erreurs des lots. Cette architecture doit être évolutive afin de répondre aux besoins futurs de l'organisation. Elle doit aussi être disponible, avec des temps d'arrêt réduits, et minimiser l'impact sur les opérations en ligne qui interviennent généralement en même temps que les opérations de lots. Certaines organisations peuvent choisir de se doter de composants de sauvegarde, comme le serveur d'événements, afin de permettre à toutes les tâches critiques d'aboutir.

Les composants de base de l'architecture par lots sont notamment le serveur de gestion, la base de données de capacité (CDB), le moniteur, l'imprimante, les serveurs des applications ainsi que les bases de données. En plus du moniteur relié au serveur de gestion, chaque serveur d'applications doit disposer d'un moniteur permettant l'affichage des activités de traitement par lots, ce qui facilite également l'analyse des erreurs au niveau local.

Traitement par lots

Avant d'aborder la question des exécutions par lots planifiées, il est important de bien comprendre la hiérarchie du traitement par lots ainsi que le contenu d'un script de lots. Une exécution de lots se compose de plusieurs tâches de lots planifiées à des fins d'exécution de manière récurrente. Une grande organisation peut lancer plusieurs exécutions de lots au cours d'une même journée, en fonction des ressources de traitement dont elle dispose. Chaque tâche de lots se décompose en plusieurs étapes contrôlant les activités spécifiques de l'exécution des tâches.

Une organisation traite généralement de nombreuses tâches de lots. Pour assurer une approche cohérente en termes d'exécution de chaque tâche, un squelette de tâches de lots doit être imaginé et contenir le code standardisé de chaque tâche ; les informations spécifiques aux tâches doivent être codées dans une zone désignée du squelette. Le squelette permet également de faciliter les exigences en matière de développement et de maintenance en standardisant le contenu et la structure de chaque script de tâche. Par exemple, tout type d'actions standardisées, comme la notification d'une exécution de lots réussie ou non ou l'archivage et la suppression de données de transaction, doit être inclus dans le code de chaque script exécuté.

Les exécutions de lots planifiées sont lancées par un outil de planification lors de la fenêtre prédéfinie, en général, lorsque les activités des utilisateurs du système sont à leur plus bas niveau. Une fois l'outil de planification programmé, l'interaction du responsable de la capacité ne doit pas être nécessaire sauf en cas d'erreur à laquelle l'outil ne peut remédier.

L'outil de planification lance toutes les exécutions de lots. Si l'exécution n'est pas lancée comme prévu, l'outil interrompt l'exécution et consigne l'erreur dans le journal des erreurs ; certains outils de planification peuvent tenter de relancer l'exécution de lots. Si l'initialisation est réussie, la première tâche de lots est exécutée. Le planificateur gère l'exécution des tâches sur chaque serveur d'application dévolu au traitement des lots. En l'absence d'erreurs lors de l'exécution de la tâche, l'outil consigne son bon déroulement dans le journal des lots, la tâche suivante est exécutée, et ainsi de suite.

Si une erreur intervient lors de l'exécution de la tâche, l'outil de planification cesse de traiter cette tâche et l'erreur est consignée dans le journal des erreurs. L'exécution d'une tâche de lots dépend du nombre d'entrées qui peut être à l'origine de la non-exécution d'une tâche. Par exemple, les entrées ci-dessous peuvent être requises :

  • disponibilité des données de production ;

  • exécution d'une tâche dont dépend la tâche de la file d'attente ;

  • disponibilité des ressources d'exécution de la tâche ;

  • priorité de la tâche et de la fenêtre de lots.

Des avertissements peuvent également être générés lors du traitement des tâches ; par exemple, lorsque la capacité du processeur ou de l'espace disque dépasse la valeur limite d'un serveur d'application traitant la tâche de lots. Ces avertissements ne doivent cependant pas empêcher la bonne exécution de la tâche de lots ; le responsable de la capacité doit gérer tous les avertissements au plus tôt pour éviter de futures défaillances de traitement. Si une erreur entraîne l'interruption d'une tâche, certains outils de planification tentent automatiquement de remédier au problème et relance le traitement de la tâche à l'endroit où il avait été interrompu. La récupération est utile lors du traitement de très longues tâches de lots car les tâches interrompues n'ont pas à être relancées depuis le début. Si cette récupération s'avère impossible, la tâche doit être redémarrée.

Si l'outil de planification ne peut redémarrer ou reprendre une tâche qui a échoué (ou a pu la redémarrer ou la reprendre à un endroit donné), le responsable de la capacité doit lancer manuellement les procédures de redémarrage ou de récupération.

Activités de planification des tâches

Idéalement, l'architecture par lots doit être configurée de manière à maintenir une interaction avec le responsable de la capacité à son minimum. Cependant, ce responsable doit effectuer de nombreuses tâches quotidiennes, parmi lesquelles les suivantes :

  • surveillance ;

  • analyse ;

  • réglage ;

  • implémentation ;

  • gestion des événements autant que nécessaires ;

  • gestion des requêtes ;

  • modification du planning ;

  • sauvegarde système ;

  • archivage ;

  • audit ;

  • renseignement du journal du responsable de la capacité ;

  • production de rapports.

Chacune de ces activités fait partie intégrante du processus de planification des tâches. Les activités de surveillance, d'analyse, de réglage et d'implémentation constituent un processus itératif. Les entrées du processus comprennent l'utilisation des ressources ainsi que les seuils OLA selon lesquels l'architecture par lots est analysée. D'autres activités sont exécutées afin d'optimiser les performances et l'utilisation de l'architecture. Les activités restantes sont exécutées en réponse à un événement, une requête ou une exigence.

Documentation et formation

Toutes les stratégies et procédures doivent être clairement documentées de manière à ce que le responsable de la capacité dispose d'une référence pour le guider dans ses activités quotidiennes. Cette documentation doit contenir des informations sur les procédures suivantes :

  • procédures de démarrage et d'arrêt des exécutions de lots ;

  • procédures de modification de la priorité des tâches ;

  • procédures de gestion des alertes et des erreurs ;

  • procédures de gestion des erreurs courantes ;

  • procédures d'analyse de la cause des erreurs ;

  • procédures de réaffectation des erreurs ;

  • procédures d'envoi de RFC ;

  • procédures de documentation des tâches du journal du responsable de la capacité ;

  • procédures relatives aux éléments à analyser et au moment de l'analyse ;

  • procédures de gestion des requêtes comme nécessaires, y compris la révision, le testing et l'exécution de ces requêtes.

Sans formation correcte, le responsable de la capacité ne sera pas en mesure de mener à bien les activités dont il est question dans le présent document. Ce responsable doit être correctement formé de manière à lui permettre de traiter et de corriger les erreurs au plus tôt. S'il est disponible, le responsable de la capacité doit suivre la formation du fournisseur sur l'outil de planification utilisé par l'organisation.

Informations complémentaires

Pour plus d'informations, rendez-vous sur le site de Microsoft Operations Framework.

Pour plus d'informations sur la manière dont les services informatiques de Microsoft utilisent Microsoft Operations Framework ainsi que les meilleures pratiques en matière de gestion des services informatiques, rendez-vous à l'adresse https://www.microsoft.com/technet/itshowcase/content/mofmmppt.mspx.

Point de contrôle : processus d'opération, d'optimisation et de modification

Tick

Exigence

 

Une gestion des niveaux de services a été implémentée sur l'ensemble des opérations informatiques.

 

Une gestion des versions reposant sur les meilleures pratiques a été implémentée.

 

Les processus d'administration système et réseau ont été optimisés.

 

Une planification des tâches reposant sur les meilleures pratiques a été implémentée.

Si vous avez suivi les étapes précédentes, votre organisation répond aux exigences minimales du niveau rationalisé pour les processus d'opération, d'optimisation et de modification du modèle d'optimisation d'infrastructure. Nous vous recommandons de suivre les meilleures pratiques en matière de gestion des ressources des opérations de Microsoft Operations Framework.