4 Gestion de la capacité
4.1 Principes du processus 4.1.1 But
Le but de la gestion de la capacité est de :
S’assurer que la capacité à un coût justifiable existe toujours dans tous les secteurs
informatiques et qu’elle correspond aux besoins convenus des organisations d’affaires, actuels et futurs, au moment opportun.
4.1.2 Objectifs
Les objectifs de la gestion de la capacité sont de :
Produire et maintenir un plan de capacité (Capacity Plan) approprié et à jour
Fournir les avis et conseils sur la capacité et la performance
S’assurer que la performance des services atteigne ou dépasse les objectifs convenus
Aider au diagnostic et à la résolution des incidents et problèmes de capacité et de performance
Evaluer l’impact de tout changement sur le plan de capacité et la performance de tous les services et ressources
S’assurer que des mesures d’amélioration de la performance des services sont lancées partout où cela est justifié financièrement
4.1.3 Un exercice d’équilibrage
En pratique, le processus doit trouver deux équilibres :
entre les coûts et les ressources nécessaires
entre l’offre de capacité et la demande
4.1.4 Le livrable du processus : le plan de capacité
Il s’agit d’un plan d’investissement qui devrait être produit sur une périodicité annuelle et sur la même période que les budgets et le cycle de vie des affaires.
Il est destiné à tous les secteurs des organisations d’affaires et informatique et il est géré par le fournisseur de services.
Il contient les informations suivantes :
les données de planification
l’utilisation actuelle des composants et des services
les plans de développement de la capacité informatique
14
4.1.5 La déclinaison en 3 processus
Ces trois processus présentent les mêmes objectifs et les mêmes activités mais ils portent sur des périmètres et des niveaux différents. Ils travaillent aussi sur des échelles de temps différentes.
4.1.5.1 Gestion de la capacité business
Processus proche des stratégies d’affaires et informatique, il s’agit de :
traduire les besoins et plans d’affaires en besoins de services et d’infrastructures informatiques
s’assurer que les besoins futurs des affaires sont quantifiés, conçus et mis en oeuvre au bon moment 4.1.5.2 Gestion de la capacité des services
En raison de la présence dans les accords de niveaux de service (SLA), accords de niveau opérationnel (OLA) et contrats [de sous-traitance] (UC) d’objectifs en termes de capacité et de performance de services fournis avec les indicateurs de performance dont les valeurs sont à produire, il est nécessaire d’avoir une vision de la capacité sur ce niveau.
Il consiste à gérer, contrôler et prévoir la performance de « bout en bout », la capacité d’utilisation et la charge des services informatiques.
4.1.5.3 Gestion de la capacité des composants
En raison du fait que le métier de base de l’informatique est de gérer et d’exploiter des composants d’infrastructures qui, assemblés, fournissent des services avec des niveaux de services à atteindre, il est nécessaire d’avoir une vision de la capacité sur ce niveau technique.
Il consiste à gérer, contrôler et prévoir la performance de « bout en bout », l’utilisation et la capacité des composants techniques.
Ces activités sont essentiellement couvertes par des outils techniques qui mesurent la performance des serveurs, des réseaux, etc.
15
4.2 Sous-processus et activités principales du processus 4.2.1 Activités réactives
4.2.1.1 Contrôle permanent
Il s’agit d’un cycle classique de supervision et de réaction en cas de dérive ou de possibilité d’amélioration.
Il s’agit de surveiller, mesurer, produire des rapports et revoir la performance actuelle des services et des composants.
4.2.1.2 Réactivité sur événement
Il s’agit de répondre à tous les événements de type « franchissement de seuil » liés à la capacité.
4.2.1.3 Réactivité sur incidents et problèmes
Il s’agit de réagir et d’assister les équipes de support face à des difficultés spécifiques de performance.
4.2.2 Activités pro-actives
Elles sont nombreuses :
Anticiper les difficultés de performance en mettant en place les actions nécessaires pour éviter leur apparition
Produire des tendances de l’utilisation actuelle des composants et l’estimation des besoins futurs et planifier les mises à niveau et les améliorations
Modéliser et identifier les tendances liés à des changements prévus dans les services informatiques et initier les changements nécessaires sur les services et composants
S’assurer que les mises à niveau sont budgétées, planifiées et mises en oeuvre avant l’apparition de difficultés
Rechercher activement l’amélioration de la performance partout où cela est justifiable financièrement
Régler et optimiser la performance des services et des composants
4.2.3 Le sous-processus de gestion de la demande
Ce sous-processus a pour principale source d’informations le processus stratégie de gestion de la demande (analyse prévisionnelle de la consommation des services qui seront fournis).
Son objectif est d’influencer la demande de services informatiques pour éviter un impact trop pénalisant d’une demande supérieure à la capacité disponible pendant les périodes de pointe ou les périodes de pannes).
16
Influencer la demande veut dire donner des informations, des préconisations voire inciter les utilisateurs et clients à déplacer leur consommation de services sur des périodes creuses.
Ceci facilite sur le court terme la gestion de la pénurie de composants techniques (capacité moindre consécutive à une panne).
Ceci est une alternative sur le long terme à la difficulté de justifier un gros investissement pour répondre à la demande pendant les périodes de pointe. Ceci permet aussi d’influencer ou d’étaler la demande.
4.2.4 Le sous-processus de modélisation et d’identification des tendances
Ce sous-processus couvre les activés suivantes :
établissement de bases de référence (baselines)
analyse des tendances
modélisation analytique
modélisation par simulation (tests de charge)
4.2.5 Le sous-processus de dimensionnement des applications
Ce sous-processus permet d’estimer les besoins en ressources pour soutenir un changement sur un service pour garantir l’atteinte des niveaux de service.
Ce sous-processus est initié à l’étape de conception d’un service et clôturé lorsqu’une application est acceptée en production.
17