Nous allons dérouler dans ce chapitre le processus de gestion des changements dans GLPI jusqu’avant l’étape de clôture du ticket changement.
Découvrez le cycle de vie d’un ticket de demande de changement
La gestion des changements s’inscrit dans la suite de la gestion des incidents et de la gestion des problèmes pour traiter les erreurs connues.
La finalité de la gestion des changements est de prendre en charge le contrôle du cycle de vie de tous les changements dans l’objectif de permettre la mise en œuvre des changements :
en maîtrisant les impacts du changement ;
en limitant les risques de dégradation de services SI : c'est-à-dire sans provoquer d’incident ;
avec un minimum d’interruption de services SI pour mettre en production le changement.
Reprenons l’exemple vu dans la partie « Gérez les problèmes avec ITIL et GLPI » : Saturation de l'espace disque du serveur bureautique "Bur-75010", pour démarrer et compléter le cycle de vie du changement.
Créez le ticket de changement à partir d’un problème
Allons voir comment cela se passe dans GLPI pour créer (enregistrer) un ticket changement à partir d’un problème.
Cliquez sur le menu Assistance > Problèmes, affichez le problème, cliquez sur l’onglet (menu vertical à gauche) Changements, ne saisissez rien et cliquez sur le lien hypertexte Créer un changement à partir de ce problème.
GLPI bascule alors sur la saisie de la demande de changement, en préremplissant plusieurs champs avec les données déjà saisies dans le ticket problème. La création du ticket changement est ainsi plus rapide.
Vous pouvez bien sûr modifier les champs pour adapter le ticket à la situation actuelle.
Champs préremplis, à ne pas modifier (sauf si le contexte a évolué depuis la création initiale du problème) :
Date d’ouverture : date et heure ;
Statut : Nouveau ;
Catégorie : Serveur ;
Demandeur : Courgey Guy ;
Urgence : Moyenne ;
Impact : Haut ;
Priorité : Haute.
Champs vierges et champs à modifier :
Attribué à : saisir le nom du Change Manager. Ici : Pacte Alain ;
Titre : complétez en orientant le titre sur le (ou les) axes du changement à réaliser. Ajoutez ici « nouveaux paramétrages Espace Disque », ce qui donne le titre : Saturation de l'espace disque du serveur bureautique "Bur-75010" - Nouveaux paramétrages Espace Disque ;
Description : complétez en ajoutant des lignes après la(les) ligne(s) reprise(s) du ticket problème, pour donner les premières pistes à investiguer dans le cadre de la future analyse du changement :
Purger les fichiers volumineux, non modifiés depuis x mois,
Augmenter l’espace disque selon capacity planning,
Positionner des alertes de supervision adéquates, avant saturation de l’espace disque.
Cliquez sur le bouton Ajouter.
Le lien entre la demande de changement et un ou plusieurs tickets d’incident se fait dans GLPI via l’onglet Tickets.
Validez le ticket de changement
À ce stade, la validation de la demande permet d’éliminer les changements qui ne sont pas logiques, qui ne sont pas légitimes.
C’est un premier tri en amont pour supprimer les demandes qui ne sont pas cohérentes, ni applicables, ou encore qui sont en doublon (cas d’un ticket ouvert par une autre personne, pour le même sujet).
La suppression d’un ticket changement s’effectue en cliquant sur le bouton Mettre à la corbeille affiché lors de la consultation du ticket changement.
Analysez et évaluez le changement
Cette phase est au cœur du cycle de vie du ticket, car elle permet d’apprécier la justification du changement selon :
les risques de faire/ne pas faire ce changement ;
les gains business/métiers attendus par ce changement ;
les impacts sur le système d’information ;
et enfin le coût du changement.
Toutes ces informations sont saisies dans GLPI et permettront au comité consultatif de changement (CAB – Change Advisory Board) de décider d’approuver ou non la demande de changement.
Analysez l’impact du changement sur le système d’information
L’analyse de l’impact du changement s’appuie sur la gestion de configuration du SI.
Ainsi, la connaissance de l’ensemble des composants « touchés » par le changement permet de comprendre l’envergure (la criticité) du changement.
Saisissez chaque composant/matériel lié par le changement via l’onglet Eléments du ticket changement.
Complétez dans GLPI l’analyse en décrivant les impacts et la liste des contrôles à effectuer via l’onglet Analyse.
Impacts :
L'espace disque du serveur bureautique "Bur-75010" fait partie du cluster 'Bur-Paris" : le calcul de l'espace disque total est à prendre en compte.
La purge définitive de fichiers doit être précédée de l'archivage de ces fichiers.
La supervision doit adapter ses niveaux d'alerte de seuil de volumétrie de disques.
Liste de contrôles :
Niveau de l'espace disque disponible sur le cluster "Bur-Paris" dont fait partie le serveur bureautique "Bur-75010".
Niveau de l'espace disque disponible sur le serveur d'archivage.
Existence ou non d'une alerte Nagios sur le seuil de remplissage de l'espace disque (pour le cluster et pour le serveur incriminé).
Cliquez sur le bouton Sauvegarder.
Définissez la stratégie de déploiement
Saisissez ces 3 activités, via l’onglet Plans.
Plan de déploiement : Pas de possibilité de déploiement progressif, donc opérations de paramétrage à effectuer en une seule fois, le jour de la livraison en production.
Plan de repli (ou plan de remédiation, ou plan de retour en arrière) : Restaurer le paramétrage avant changement (récupération snapshot).
Liste de vérifications
Tests de validation de la solution :
Détecter les fichiers de taille supérieure à x Mo
Créer, Modifier, Supprimer, Déplacer de dossier un fichier
Compresser/décompresser un fichier sur plusieurs types (texte, tableur, image...)
Archiver un fichier/Restaurer un fichier archivé
Supervision : 2 niveaux d'alerte de volumétrie (Warning et Critical)
Tests de non-régression : vérifier le bon fonctionnement pour les autres partages du cluster "Bur-Paris".
Cliquez sur le bouton Sauvegarder.
Décrivez les tâches et les coûts du changement
De la même manière que pour un ticket d’incident, vous décrivez les différentes tâches à effectuer lors du changement, ainsi que les coûts estimés pour réaliser l’intégralité du changement.
Chacune de ces saisies s’effectue via l’onglet du ticket changement :
Concernant les changements complexes (par exemple la mise en place d’un nouveau module applicatif d’un ERP), il est nécessaire de relier le ticket changement à un ou plusieurs projets, via l’onglet Projets.
Approuvez la demande de changement
La demande de changement est enfin complète : toutes les informations permettant la décision d’autoriser ou non le changement sont décrites dans GLPI.
L’approbation du ticket changement dépend du type de changement :
changement standard : changement commun exécuté selon une procédure préétablie, dont le risque est sous contrôle (exemples : remplacement d'une imprimante, installation d’un poste de travail).
⇒ Ce type de changement est préautorisé : il n’y a pas d’action particulière à effectuer dans GLPI.changement urgent : changement qui doit être mis en œuvre dès que possible (situation de crise, patch de sécurité suite à cyber-attaque, …).
⇒ C’est le comité ECAB – Emergency Change Advisory Board – qui doit autoriser le déploiement en production du changement. La demande d’autorisation est saisie dans GLPI (voir la description de cette saisie ci-dessous) ;changement normal : tous les changements qui ne sont ni standard, ni urgents.
⇒ C’est le comité consultatif de changement (CAB – Change Advisory Board) qui donne son GO/NOGO sur le changement. La demande d’autorisation est saisie dans GLPI (voir description de cette saisie ci-dessous).
Allez hop, petit exemple pratique de saisie de la demande d’autorisation (approbation) du changement : à l’affichage du ticket changement, cliquez sur l’onglet : Validations.
Saisissez le Valideur ou le Groupe de valideurs (CAB) : Pacte Alain, ainsi qu’un commentaire précisant la demande d’autorisation : Changement Normal à autoriser par le responsable du CAB.
Cliquez sur le bouton Ajouter.
Le ticket passe de « Non soumis à validation » à « En attente de validation ».
Suivez la demande de changement dans GLPI et coordonnez la mise en œuvre
L’objectif maintenant est de s’assurer que la demande de changement est bien en cours de traitement : d’abord qu’elle a été autorisée, puis que les travaux (tâches, projets, plans…) sont lancés.
Le créateur du ticket est le responsable de la demande de changement.
À ce titre, il effectue le suivi et les relances si nécessaire, pour favoriser le déploiement du changement en production.
Il peut aussi seconder le responsable du CAB en termes de coordination entre les équipes Études/Projets et celles de l’infrastructure/Production (faire ce lien… why not dans une approche DevOps !)
Faites approuver la demande de changement
Après étude par le CAB ou l’ECAB (évaluation des risques, des impacts, des bénéfices, des coûts et des dépendances avec d'autres changements), le responsable du CAB (ici dans notre exemple monsieur Alain Pacte) se connecte à GLPI.
Il affiche le ticket changement, clique sur l’onglet Validations et indique « l’état de ma validation » en choisissant dans la liste déroulante : Acceptée.
Puis il clique sur le bouton Sauvegarder.
L’état de la demande passe à Acceptée :
Coordonnez la mise en œuvre
Suite à l’autorisation du changement, la phase pratique peut démarrer, d’abord par la planification des 2 phases du changement :
conception/réalisation/tests ;
mise en production (déploiement ou livraison en production) au moment opportun : soit en HO – heures ouvrées, soit en HNO – heures non ouvrées.
Les différents acteurs du changement prennent alors en charge sa mise en œuvre :
conception et paramétrages par les équipes techniques ;
développement ou intégration par les équipes applicatives ;
tests de validation finale par les utilisateurs.
À la mise en production, vous allez réaliser dans GLPI la saisie de la solution. Ouvrez le ticket changement, cliquez sur l’onglet Solution et décrivez précisément chaque action effectuée lors du changement :
Augmentation de l’espace disque de 200 Go (nouveaux volumes physiques).
Archivage puis purge des fichiers > 1 Go et non modifiés depuis 6 mois (opération quotidienne de nuit).
Compression quotidienne des fichiers de taille supérieure ou égale à 250 Mo (opération de nuit).
Supervision : paramétrage d'une nouvelle alerte Nagios sur le seuil de remplissage du volume Bur-75010 : Warning à 25 % d’espace disque disponible et Critique à 10 % d’espace disponible.
Afin de conserver et diffuser la connaissance, n’oubliez pas (comme pour les incidents et les problèmes !) d’ajouter la solution à la base de connaissances GLPI…
Un cas similaire pourrait se produire à l’avenir et il sera plus rapidement solutionné…
Puis cliquez sur le bouton Sauvegarder.
Le statut du ticket changement passe alors à « Appliqué ».
En résumé
Dans ce chapitre, nous avons :
parcouru le cycle de vie d’un ticket changement dans GLPI, celui-ci s’inscrivant dans la continuité de la gestion des incidents et de la gestion des problèmes ;
appris que le processus de gestion des changements permet de maîtriser les impacts du changement ;
compris que le CAB – comité consultatif de changement – décide d’exécuter le changement en fonction des informations saisies dans GLPI :
les éléments/composants touchés par le changement,
les impacts et la liste des contrôles à réaliser pendant l’analyse,
les plans de déploiement, de repli et de tests avant mise en production,
les tâches, les coûts et les projets liés au changement,
la demande d’approbation du changement par le CAB ;
vu la nécessité d’accompagner et suivre dans GLPI la mise en œuvre du changement, après que la demande ait été approuvée.
Dans le prochain et dernier chapitre, nous verrons comment clôturer le ticket de changement et comment visualiser quelques statistiques des changements effectués dans GLPI.
