Dans la première partie du cours, je vous ai présenté le référentiel de bonnes pratiques ITIL. Les 5 ouvrages de ce référentiel contiennent les expériences d’apprentissage de professionnels et d’experts dans le domaine informatique.
Par la suite, je vous ai présenté les concepts clés que sont le cycle de vie d’un service, les processus, les fonctions et les rôles.
Enfin, vous avez découvert comment ITIL améliore la qualité d’un service IT en proposant 26 processus et 4 fonctions principales dans le cycle de vie d’un service informatique. Si un seul des termes cités ci-dessus vous paraît abstrait, foncez relire la première partie du cours. J’ai tout mon temps !
Dans cette seconde partie, je vous propose d’apprendre à garder le contrôle de votre SI, en établissant une procédure opérationnelle de gestion des changements. Vous commencerez par découvrir la terminologie utilisée lors du déploiement d’un SI, puis je définirai les activités nécessaires pour effectuer sereinement un changement. Enfin, je vous présenterai un outil opensource qui vous servira à modéliser l’ordinogramme d’un processus de gestion des changements.
Programme alléchant donc. Calez-vous confortablement dans votre fauteuil, on démarre tout de suite !
Les dangers d'un changement non contrôlé
En entreprise, il est assez courant de rencontrer des SI avec des dizaines, centaines, voire des milliers de serveurs, applications et autres éléments de configuration (carte réseau, base de données, switch, NAS…). Je vous épargne les liens et relations entre ces derniers.
Mon record personnel est de 2 380 serveurs pour environ 650 applications !
La conséquence naturelle d’un changement non contrôlé est un incident de production générant une rupture partielle du service, voire une indisponibilité totale du SI. Une procédure de gestion des changements va vous permettre de garder le contrôle sur votre SI en autorisant, priorisant, planifiant les actions nécessaires ; cela même avant d’exécuter toute action de changement (déploiement, modification ou suppression).
Pour bien comprendre et établir les activités essentielles de votre procédure de gestion des changements, il y a certains termes que vous devez maîtriser.
Commençons par définir le terme "procédure".
Procédure
Quelle est la différence entre procédure et processus ?
Souvenez-vous, dans la première partie du cours, nous avions défini un processus comme étant une suite d’activités qui s’exécutent afin de réaliser une tâche. Les étapes détaillées décrivant la manière dont les activités de processus seront exécutées vont se retrouver dans une procédure.
Changement
Un changement peut être défini de beaucoup de façons.
Non seulement un déploiement est considéré comme un changement, mais la modification et la mise hors service sont aussi des changements.
Voici quelques exemples de changements :
Une mise à jour applicative ;
Le remplacement d’une carte réseau ;
L’installation / désinstallation d’une application ou d'un service ;
L’externalisation d’un service vers un fournisseur externe ;
Une modification de l’infrastructure ou d'une procédure.
En entreprise, les changements surviennent pour une variété de raisons, ce qui permet de définir 3 types de changement.
Changement standard
C’est un changement relativement commun et présentant peu de risques. Ce type de changement est préautorisé, voire automatisé (ex. : la masterisation d’un ordinateur destiné à un nouvel employé).
Changement urgent
Ici, il s’agit de résoudre des erreurs, des incidents, mais aussi de s’adapter à des circonstances particulières. Un changement urgent doit être mis en œuvre assez rapidement.
Changement normal
Ce type de changement n’est ni standard, ni urgent. Il suit la procédure classique de changement. Contrairement au changement standard, il suit une chaîne d’approbation et de validation.
Tout changement doit être introduit par une une RFC.
Qu’est-ce qu’une RFC ?
La demande de changement—RFC
Quand le changement est majeur, on utilise une proposition de changement.
La proposition de changement
La proposition de changement est complète. Contrairement à une RFC, elle inclut un business case complet (enjeux, alternatives, budget…) ainsi qu’un calendrier pour la réalisation et la mise à jour du changement.
Avant d’être exécutées, les RFCs et les propositions de changements sont soumises à l’approbation d’un comité consultatif. Il s’agit du CAB.
Le comité consultatif—CAB
Le CAB donne le GO ou le NO-GO à tous les changements. Il valide aussi le planning et le calendrier de changement. Les membres du CAB peuvent donner leur accord, car ils ont une compréhension claire de l’ensemble des implications du changement.
Par exemple, le CAB validant la RFC concernant le remplacement du CRM utilisé par le service commercial, doit faire inclure des utilisateurs du nouveau CRM (le service commercial) et l’équipe technique (qui fournira un avis sur le choix de la solution informatique).
Le comité consultatif d’urgence—eCAB
Lorsque votre besoin de changement est urgent, et que vous manquez de temps, il est alors nécessaire d’identifier un groupe plus restreint de personnes. Ces personnes auront l’autorité pour prendre les décisions urgentes.
Le RACI
Pour être efficace, votre procédure de gestion des changements doit distribuer les rôles et responsabilités pour chacune des activités du processus. Pas toujours évident de savoir qui fait quoi. C’est ce à quoi répond le RACI. C’est une matrice, un tableau qui permet d’établir les rôles et responsabilités. Les rôles sont définis par chacune des lettres :
Réalisateur : ce sont les personnes qui exécutent l’activité de la procédure ;
Approbateur : c’est l’autorité, la personne qui rend des comptes sur l’activité. Il ne doit y avoir qu’une seule personne pour une activité donnée ;
Consulté : les personnes dont les conseils et opinions sont utiles ;
Informé : les personnes que vous devez tenir informées du déroulement des activités.
Elément de configuration—CI
Il est important de connaître l’ensemble des éléments de configuration de son SI et d’en tenir un inventaire précis des attributs et relations entre CIs. Cela va vous permettre de savoir que le serveur X est mutualisé avec telle ou telle application, et qu’une action sur ce serveur affectera un nombre précis d’éléments.
Base de données des éléments de configuration—CMDB
La CMDB, pour Configuration Management Database, ou base de données des éléments de configuration, contient les informations sur les CI. Vous y placerez tous les détails et attributs des CI de votre SI : inventaire du matériel, des logiciels, applications. Elle devra contenir aussi le détail des relations entre tous les CI de votre SI.
En résumé
Dans ce chapitre, je vous ai présenté le vocabulaire normalisé de la gestion des changements. Vous devrez retenir que :
Un changement se définit par l’ajout, la modification ou la suppression d’un service ou d’un composant de ce service ;
Il existe 3 types de changement : changement normal, changement standard et changement urgent. À la différence des changements normaux, les changements standard et urgents suivent une procédure spécifique ;
Une RFC est une demande de changement, initiant tout changement ;
Quand le changement est majeur, on utilise une proposition de changement, qui est une RFC incluant un business case complet ;
Le CAB un comité consultatif autorisant un changement après avoir passé en revue la RFC ;
Quand le besoin de changement est urgent, et que l’on manque de temps, on fait appel à l’eCAB ;
Le RACI définit qui fait quoi. Il permet d’établir les rôles et responsabilités pour chacune des activités d’un processus ;
Un CI, Configuration Item, est un élément de configuration de votre SI (software, hardware, documentation) ;
La CMDB, quant à elle, est le registre qui inventorie tous les CI de votre Si, ainsi que leurs relations.
Maintenant que vous avez acquis le vocabulaire, il temps de s’attaquer à l’élément déclencheur d’un changement, la RFC ! Dans le prochain chapitre, vous allez apprendre à rédiger une RFC, la qualifier, et la prioriser.
