ITIL Gestion des mises en production Mode d'emploi
ITIL V2
La gestion des mises en production
Création : novembre 2004
Mise à jour : août 2009
A propos
A propos du document
Ce document de référence sur le référentiel ITIL a été réalisé en 2004 et la traduction des 2 livres ITIL
Service Support et Service Delivery a nécessité 4 mois de traduction et d
écriture.
Il est mis à la disposition de la communauté francophone ITIL pour diffuser les connaissances de base sur ce référentiel.
Ce document peut être utilisé de manière libre à condition de citer le nom du site (www.itilfrance.com) ou le nom de l auteur (Pascal Delbrayelle).
A propos de l'auteur
Pascal Delbrayelle intervient avec plus de 25 ans d'expérience comme consultant sur les projets d'une direction informatique ayant comme facteur de succès la mise en oeuvre des bonnes pratiques ITIL comme, par exemple, la mise en place d'un site de secours, la mise en place d'un outil de gestion des configurations ou la définition des normes et standards techniques des environnements de production.
Ces projets requièrent :
la connaissance des différents métiers du développement et de la production informatique
la pratique de la conduite de projets techniques de la direction informatique
la maîtrise de la définition et de la mise en place de processus pour rationaliser et adapter les méthodes de travail au sein de la direction informatique
A propos de mission et de formation
Si vous pensez que l expérience de l auteur sur le référentiel ITIL ou la formalisation de documents sur le sujet peut vous aider dans vos projets de production ou de mise en oeuvre des processus ITIL, n hésitez pas à le contacter pour toute question ou demande :
par mail : pascal.delbrayelle@itilfrance.com
par téléphone : +33 (0)6 61 95 41 40
Quelques exemples de mission :
Modélisation simple des processus de gestion des changements, des projets et des mises en production en vue de la sélection, l'achat et l'implantation d'un outil de gestion de projets avec planification, gestion des ressources, des budgets, des livrables et des connaissances
Accompagnement avec la réorganisation d'un DSI passant d'une organisation en silos techniques vers une organisation inspirée du référentiel ITIL et la mise en oeuvre d'outils pour institutionnaliser les processus ITIL
Accompagnement d'une DSI dans la formulation de l'appel d'offres au futur centre de services en se basant sur les processus et la fonction centre de services du référentiel ITIL
2
Sommaire
1 Objectif .......................................................................................................................................................... 5
1.1 Objectif ................................................................................................................................................... 5
1.2 Objectifs détaillés ................................................................................................................................... 5
2 Périmètre ....................................................................................................................................................... 5
2.1 Périmètre ............................................................................................................................................... 5
2.2 Changements contrôlés par le processus ............................................................................................... 5
2.3 Tous les livrables nécessitent d’être suivis .............................................................................................. 6
2.4 La Gestion des Mises en Production recommandée pour ........................................................................ 6
2.5 Activités et cycle de vie d’un Changement .............................................................................................. 6
3 Concepts de base .......................................................................................................................................... 6
3.1 Distribution ............................................................................................................................................. 6
3.2 Politique et préparation des Mises en Production .................................................................................... 7
3.3 Unité de Distribution ............................................................................................................................... 7
3.4 Déploiements ......................................................................................................................................... 7
3.5 Elaboration et configuration de la Distribution (Intégration) ...................................................................... 7
3.6 Homologation de la Distribution .............................................................................................................. 7
3.7 Scénarios de retour arrière ..................................................................................................................... 8
4 Bénéfices et problèmes possibles .................................................................................................................. 8
4.1 Quelques bénéfices d’une gestion combinée des Changements, des Mises en Production et des
Configurations .................................................................................................................................................... 8
4.2 Problèmes potentiels .............................................................................................................................. 8
5 Politique sur les Distributions et les Déploiements .......................................................................................... 9
5.1 Documentation préalable à la mise en place du processus ..................................................................... 9
5.2 Documentation sur le Déploiement des Distributions ............................................................................... 9
5.3 Procédures sur le Déploiement en production ......................................................................................... 9
5.4 Procédures sur les retours arrière ......................................................................................................... 10
5.5 Rôles et responsabilités dans le processus ........................................................................................... 10
6 Activités ....................................................................................................................................................... 10
6.1 Phase de préparation ........................................................................................................................... 10
6.2 Phase d’intégration ............................................................................................................................... 11
6.3 Phase d’homologation et d’acceptation ................................................................................................. 11
6.4 Phase de Déploiement ......................................................................................................................... 12
6.4.1 Le Déploiement par phases .......................................................................................................... 12
7 Métriques et indicateurs de performance ....................................................................................................... 13
7.1 Indicateurs de performance .................................................................................................................. 13
7.2 Métriques ............................................................................................................................................. 13
8 Interactions avec les autres processus .......................................................................................................... 13
8.1 Gestion des Configurations ................................................................................................................... 13
8.2 Gestion des Changements ................................................................................................................... 13
3
8.3 Logiciels livrés par les Etudes et les fournisseurs tiers .......................................................................... 13
8.4 Gestion des Problèmes et Centre de Services ...................................................................................... 14
4
1 Objectif
1.1 Objectif
Protéger l’environnement de production et ses services par l’utilisation de procédures formelles et par des
vérifications lors de l’implémentation des Changements
Les Changements sont intégrés dans les Distributions (Release) et implémentés en production par les Déploiements
(Release)
Il est recommandé une étroite collaboration avec la Gestion des Changements et la Gestion des Configurations pour s’assurer que :
la CMDB est à jour des Changements implémentés par les Déploiements
le contenu de ces Déploiements est intégré dans la DSL (Definitive Software Library)
La Gestion des Mises en Production est souvent budgétée par les grands projets plutôt que d’être intégrée dans les coûts d’exploitation courants
1.2 Objectifs détaillés
planifier et superviser le Déploiement d’un logiciel et du matériel associé
élaborer et implémenter les outils de distribution et d’installation des Changements
de s’assurer que les matériels et logiciels changés sont traçables, sûrs et que seules les versions correctes, autorisées et testées sont installées
de communiquer et de gérer les attentes des Clients pendant la planification et le déroulement des déploiements
de valider le contenu exact d’une Distribution et le scénario de Déploiement en liaison avec la Gestion des
Changements
d’installer les nouvelles versions logicielles et les matériels en production en respectant les procédures de la Gestion des Changements et des Configurations
de s’assurer que les distributions d’origine de tous les logiciels sont stockées et sécurisées dans la Bibliothèque des
Versions Logicielles Définitives (Definitive Software Library ou DSL) et que la CMDB est mise à jour
2 Périmètre
2.1 Périmètre
planification, conception, élaboration, configuration et homologation des matériels et logiciels pour créer un ensemble de composants destiné à être déployé en production (kit d’installation ou de déploiement)
planification et préparation du Déploiement d’un Changement à un ensemble d’Utilisateurs et de sites
communication, préparation et formation à un Changement
audits matériels et logiciels avant et après l’implémentation d’un Changement
déploiements des Changements
mise à jour de la CMDB et de la DSL
2.2 Changements contrôlés par le processus
applications développées en interne
logiciels externes (logiciels standards du marché ou développements spécifiques par des sociétés tierces)
logiciels utilitaires
logiciels systèmes
matériels et spécifications matérielles
5
manuels d’installation et utilisateur
2.3 Tous les livrables nécessitent d’être suivis
1. développement ou achat
2. adaptation et configuration
3. homologation et implémentation
4. exploitation dans l’environnement de production
2.4 La Gestion des Mises en Production recommandée pour
mise en place importante ou critique de matériels (surtout si impact sur les logiciels et applications)
donc exclu : installation d’un nouveau poste de travail
mise en place importante d’une première version ou d’une nouvelle version d’application
regroupement d’un ensemble de Changements dans des Déploiements de taille acceptable
2.5 Activités et cycle de vie d’un Changement
3 Concepts de base
3.1 Distribution
Ce terme désigne une collection de Changements autorisés sur l’infrastructure (corrections de problèmes et améliorations fonctionnelles)
La Distribution inclut le code logiciel et toute nouveauté et mise à jour matérielle pré-requise
Généralement, on distingue trois catégories :
1. Distributions logicielles majeures et mises à jour matérielles
contient : ajouts fonctionnels importants, quelques correctifs
normalement, annule et remplace tous les Distributions antérieures : mises à jour mineures, Distributions, correctifs urgents
2. Distributions logicielles mineures et mises à jour matérielles
contient : quelques ajouts ou modifications fonctionnelles mineures, des correctifs
normalement, annule et remplace tous les correctifs urgents passés depuis la dernière Distribution majeure ou mineure
3. Correctifs urgents logiciels et matériels
6
contient la correction d’un petit nombre de Problèmes connus
3.2 Politique et préparation des Mises en Production
La politique des Mises en Production couvre :
la numérotation des versions (numéro unique gérée ensuite par la Gestion des Configurations),
la fréquence des Déploiements en production (dépend de la taille et du nombre de systèmes, des contraintes utilisateurs et métiers),
le niveau de contrôle sur le détail de l’infrastructure au-dessus duquel il est nécessaire de gérer des Déploiements
Elle permet de préciser strictement les cas de Déploiements de correctifs urgents et de reporter les autres correctifs dans des Déploiements programmés et planifiés à l’avance (verrouiller toutes les possibilités de contourner)
3.3 Unité de Distribution
Il s'agit d'un ensemble d’Items de Configuration (éléments de l’infrastructure) qui ne peuvent être mis à jour qu’ensemble (pour des raisons pratiques et d’efficacité)
Si un Item de Configuration est impacté par un Changement, alors la Distribution correspondante contiendra tous les items de l’Unité de Distribution
Par exemple :
une application complète (même si un seul programme est modifié),
ou un programme de l’application (quelle que soit la correction, modification ou ajout apporté)
3.4 Déploiements
On distingue trois catégories de Déploiements :
1. Déploiement complet (full Release)
Tous les composants d’une Unité de Distribution sont reconstruits, homologués, distribués et installés en même temps
Plus consommateur de temps qu’un Déploiement delta (delta Release) ... en théorie
Les tests de non-régression concerne l’ensemble des composants (re)déployés
2. Déploiement delta (delta Release)
Seuls les composants concernés par la Distribution sont déployés (modifiés ou nouveaux).
Exemple : un programme d’une application considérée comme une Unité de Distribution
Plus rapide à déployer mais attention aux risques
3. Déploiement groupé (package Release)
S’il est possible de différer des Déploiements (complets ou partiels) sans perturbation significative de la production, il est recommandé de grouper ces Déploiements dans un seul appelé alors Déploiement groupé.
Le Déploiement groupé est aussi à utiliser lorsque plusieurs Déploiements complets ou partiels doivent être réalisés en même temps.
Par exemple : afin d’être sûr que tous les correctifs urgents déployés sur l’infrastructure par un outil de déploiement d’urgence soient bien déployés partout, un Déploiement groupé reprend tous ces correctifs urgents pour les redéployer sur l’infrastructure
(DIPATCH pour DIstribution de PATCHes)
La fréquence de ces régularisations est de une par mois
Il faut cependant faire attention à la taille du Déploiement groupé
3.5 Elaboration et configuration de la Distribution (Intégration)
La construction d’une Distribution doit respecter des procédures et doit être automatisée si possible
Elle comprend aussi les composants matériels
3.6 Homologation de la Distribution
7
Elle peut comprendre l’homologation fonctionnelle, l’homologation technique de l’application, l’homologation de l’intégration et les tests de performances
Ces homologations se font en relation avec la Gestion des Changements
3.7 Scénarios de retour arrière
Ils devraient être établis pour documenter la restauration de l’état précédent en cas d’échec du Déploiement
Le partage des responsabilités est le suivant :
Gestion des Changements : Chaque Changement devrait avoir son scénario de retour arrière
Gestion des Mises en Production : un Déploiement de retour arrière doit cumuler les scénarios de retour arrière de tous les Changements implémentés par une Distribution
Deux approches existent (à combiner éventuellement) :
complète réversibilité d’un Déploiement (retour exact à l’état précédent) : critique pour un Déploiement complet et préférable pour un Déploiement delta
mesures partielles à envisager si la réversibilité n’est pas pratique ou impossible à réaliser
4 Bénéfices et problèmes possibles
4.1 Quelques bénéfices d’une gestion combinée des Changements, des
Mises en Production et des Configurations
taux de réussite plus important dans les Déploiements
diminution du risque d’incompatibilité entre composants lors de Changements importants sur l’infrastructure
assurance que les logiciels et matériels en production sont connus et de qualité
meilleure stabilité de l’environnement de production car l’utilisation de Distributions diminue le nombre de mises en production
meilleure utilisation des ressources Utilisateurs pour tester (cohérence globale de l’ensemble des homologations)
minimisation des tests de non-régression
meilleure information à l’avance des Changements qui vont être déployés
audit complet des Changements mis en place
capacité pour absorber un taux important de Changements sur l’environnement de production sans impacter sur la qualité de service
meilleure détection des mauvaises versions et des copies non autorisées des logiciels
réduction des délais et temps de déploiement
transitions plus douces entre les environnements de développement et l’environnement de production
4.2 Problèmes potentiels
résistance initiale à la mise en place de nouveaux processus : campagne de sensibilisation à mener pour expliquer les avantages d’une Gestion des Mises en Production
contournement possible de la Gestion des Mises en Production (« installations sauvages ») à surveiller
utilisation possible de la procédure de Déploiement de correctif urgent pour installer des Distributions mineures voire majeures non urgentes
résistance à passer par des environnements d’homologation (passage direct de l’environnement de développement vers l’environnement de production)
meilleure approche d’installation sur des environnements distribués (synchronisation des installations)
quelques personnes (y compris la hiérarchie) peuvent voir la Gestion des Mises en Production comme lourde et coûteuse. Néammoins, elle représente presque toujours le seul moyen de s’en sortir efficacement avec les
Changements logiciels
absence de clarté dans les responsabilités et rôles dans le Déploiement entre les équipes de développement et de production
8
ressources insuffisantes pour homologuer les distributions ou trop de variantes en production pour pouvoir toutes les tester
plates-formes d’homologation pas assez puissantes augmentant les temps d’élaboration et d’homologation des
Distributions
plates-formes d’homologation non représentatives de l’environnement de production (tests incomplets)
5 Politique sur les Distributions et les Déploiements
5.1 Documentation préalable à la mise en place du processus
Un document de politique sur les Distributions et les Déploiements devrait être produit et contenir :
un guide sur le niveau de granularité des Distributions (Unités de Distribution) : par exemple, application complète, module ou programme
des conventions de nommage des Distributions et de numérotation des Versions
des définitions des Distributions majeures et mineures et une politique sur la gestion des correctifs urgents
des indications générales sur la fréquence des Distributions majeures et mineures
l’identification des périodes de neutralisation, par exemple : o la semaine précédent l’arrêté comptable mensuel pour les applications comptables o du 15/12 au 15/01 pour toutes les applications impliquées dans les bilans annuels
les livrables attendus pour chaque type de Distribution, par exemple : o manuel d’installation o notes de mise à jour (Release notes)
une politique sur les retours arrière en production et leurs tests en homologation
les responsabilités de l’équipe chargée des Distributions et des Déploiements dans les comités techniques sur l’architecture des applications
une description du processus de Gestion des Mises en Production
une documentation sur la DSL et les critères d’acceptation de tout nouveau logiciel dans cette DSL
Ces points sont parfois intégrés dans un document plus général à destination des Maîtrises d’Oeuvre : les Normes
d’Exploitabilité des applications en production
5.2 Documentation sur le Déploiement des Distributions
Une documentation sur le Déploiement des Distributions en production devrait contenir :
la copie/diffusion de la Distribution des environnements d’homologation/d’intégration vers la production (avec vérification de l’intégrité des kits copiés en production)
pour une mise à jour : la sauvegarde de l’ancienne version, la migration des données vers la nouvelle version
la désynchronisation dans certains cas de l’installation et de l’activation du logiciel :
par exemple : activation générale à une date/heure précise (contraintes légales) ou activation après démarrage d’une application ou base de données centrale
mécanisme de déclenchement de l’activation : central, inclus dans la Distribution elle-même, etc.
mécanismes à tester impérativement en homologation
5.3 Procédures sur le Déploiement en production
les scripts et paramétrages devraient être testés en homologation
objectif : avoir des composants fiables dans la diffusion/installation/activation des logiciels en production (déploiement simple, infaillible et sécurisé au maximum)
limiter les opérations locales au minimum (montage de bande, etc.)
prendre impérativement en compte la vérification de la bonne installation/activation du logiciel après l’opération
9
vérifier le bon état de fonctionnement de l’infrastructure de Déploiement avant une opération
5.4 Procédures sur les retours arrière
La Gestion des Changements nécessite un plan de retour arrière à chaque implémentation d’un Changement
Ces plans devraient être testés dans la phase d'homologation.
Parfois, il n’est pas possible de revenir en arrière en cas de problème (par exemple : contraintes calendaires légales rendant impossible l’utilisation des anciens programmes). Dans ce cas, il est recommandé d'avoir des procédures de minimisation du dysfonctionnement (retours arrière alternatifs) à tester également le plus possible.
5.5 Rôles et responsabilités dans le processus
Ils sont à définir à l’avance.
Les rôles les plus importants dans le processus sont :
Responsable des Changements (Change Manager)
Responsable des Déploiements (Release Manager)
Responsable des Homologations (Test Manager)
Dans les installations standards, prédéfinies et approuvées, il n'est pas nécessaire de faire intervenir la Gestion des
Changements (exemple : installation d’un nouveau poste de travail) qui peut être initié par le Centre de Services
Voici des exemples de rôles et responsabilité dans le processus :
Nature du
Déploiement
Développement :
Livré par
Homologation :
Accepté par
Homologation :
Livré à la production par
Production :
<Accepté et supporté par
Nouveau logiciel externe
Chef de projet
Etudes
Nouvelle application interne
Chef de projet
Etudes
Modification Base de
Données
Chef de projet
Etudes
Responsable homologation
Responsable Changement Responsable Exploitation
Responsable
Homologation
Responsable Changement Responsable Exploitation
Gestionnaire
Base de données (DBA)
Responsable Changement Gestionnaire Base de données (DBA)
Serveur Ingénieur système Responsable
équipe système
Responsable Changement Responsable équipe système
Application existante sur PdT
Chef de projet
Etudes micro
Poste de travail Logistique
Responsable support micro
Support micro
Responsable support micro
Responsable Changement
Responsable support micro
Responsable support micro
Responsable Changement
Responsable support micro
6 Activités
6.1 Phase de préparation
Cette phase comporte les éléments suivants :
définition et acceptation du contenu de la Distribution
définition et acceptation de la méthode de Déploiement (par phases, par unités géographiques, etc.)
production d’un calendrier détaillé du Déploiement
10
audit pour vérifier les matériels et logiciels en production
prévision des ressources (logistiques, humaines)
acceptation des rôles et responsabilités de chaque équipe
obtention des devis et négociations avec les fournisseurs pour l’achat de matériels, de logiciels et de services
production des plans de retour arrière
développement d’un Plan Qualité pour le Déploiement
acceptation du calendrier par les équipes de support et les Utilisateurs
En entrée du processus, nous trouvons :
cycle de vie du projet (Etudes)
livrables attendus
Demandes de Changement (RFCs ou Requests for Change) autorisées
document sur la politique des Distributions et des Déploiements
résumé des besoins métiers
contraintes et dépendances du Déploiement
Avis du CCC ou Comité Consultatif des Changements (CAB ou Change Advisory Board)
Cette phase produit un plan de tests détaillé et des critères d’acceptation de la Distribution pour Déploiement
6.2 Phase d’intégration
Il s'agit de l'élaboration, de la construction et de la configuration de la Distribution
Les éléments produits par cette phase sont :
instructions d’assemblage et de construction de la Distribution
bons de commande, licences et garanties pour les matériels et logiciels tiers
scripts d’installation et plans de tests associés
kit de la Distribution et manuel d’installation pour insertion dans la DSL
procédures de retour arrière
6.3 Phase d’homologation et d’acceptation
L’homologation de la Distribution devrait être réalisée par des équipes indépendantes de celles des Etudes et de la Production impliquées dans le contenu de cette Distribution
Les procédures de retour arrière devraient en faire partie
Cette phase inclut à la fois des tests fonctionnels et des tests techniques (installation, performances, etc.)
Chaque homologation devrait produire un document de résultats
Voici quelques recommandations sur les environnements de tests :
réinitialisables facilement
le plus possible à l’image des environnements de production
Si un avis négatif est rendu sur la Distribution, la replanification devrait être à la charge de la Gestion des Changements
En sortie du processus, nous trouvons :
composants validés de la Distribution
procédures validées d’installation et de retour arrière
défauts connus et acceptés qui vont être introduits en production avec la Distribution
résultats des homologations
documentation de support
instructions d’exploitation et d’administration
calendrier de formation pour les équipes de support et les Utilisateurs
11
documents d’acceptation de la Distribution signés par toutes les parties
autorisation d’implémenter la Distribution (au travers de la Gestion des Changements)
6.4 Phase de Déploiement
production d’un calendrier détaillé des événements
lister les Items de Configuration (CIs ou Configuration Items) à installer et à désinstaller ou démonter
édition d’un plan d’actions détaillé par site (en prenant en compte les décalages horaires pour un Déploiement world-
wide si besoin)
production des notes de mise à jour et des communications aux Utilisateurs
communication sur le calendrier de Déploiement
acquisition des nouveaux matériels et logiciels avec leur référencement (étiquetage du matériel par exemple)
planification des réunions de pilotage du Déploiement
Voici un exemple de politique de Déploiement sur des Postes de Travail :
6.4.1 Le Déploiement par phases
Les distributions peuvent être déployées en production :
en une seule fois (« big bang »)
en plusieurs passes (déploiement par phases)
Voici quelques exemples où il est nécessaire de déployer par phases :
diffusion et installation de la Distribution par phases (car lourd et long) et activation en une seule fois (contrainte légale)
implémentation graduelle du Changement par site (pour éviter les « explosions » au niveau des équipes de support)
Changements sur le matériel à implémenter avant un Déploiement logiciel
Ces exemples peuvent évidemment être combinés
L’implémentation graduelle d’une nouvelle version applicative n’est possible que si l’environnement de production peut supporter d’exploiter simultanément deux versions différentes de la même application
Ceci est un exemple de ce qu’il est nécessaire de prendre en compte très tôt dans le cycle de vie de l’application (au moment du design)
Il est recommandé d'éviter de faire un Déploiement « big bang » mais de procéder graduellement :
site(s) pilote(s) (1 ou 2 étapes sites alpha et beta)
12
puis déploiement par phases sur le reste des sites
7 Métriques et indicateurs de performance
7.1 Indicateurs de performance
distributions créées, testées et déployées dans les temps prévus et avec les budgets prévus (éviter le piège des retards de livraison par les Etudes)
très peu (idéalement aucun) de retours arrière dûs à des erreurs non détectées en homologation (mais il est possible de déployer volontairement une Distribution contenant des erreurs)
tous les composants de la DSL sont légaux et ont été validés
les Distributions sont déployées partout où cela était prévu
pas de retours non autorisés sur une version antérieure
pas de licences logicielles utilisées illégalement
pas de gaspillage en coûts de support (contrats, équipes) pour des logiciels non utilisés sur certains sites
7.2 Métriques
nombre de Distributions majeures et mineures par période
nombre de Problèmes liés à une mauvaise Distribution ou à un mauvais Déploiement (à mesurer les premiers mois) comme par exemple : « fichier manquant » ou « mauvaise version de fichier »
nombre de composants nouveaux, modifiés et supprimés par une nouvelle Distribution
nombre de Déploiements terminés dans les délais prévus (cela nécessite de publier avant Déploiement les délais prévus)
8 Interactions avec les autres processus
La Gestion des Mises en Production utilise les processus de contrôle de la Gestion des Configurations et de la
Gestion des Changements
8.1 Gestion des Configurations
nouvelles versions logicielles insérées dans la DSL et changements sur les matériels : à intégrer dans la CMDB
utilisation d’autres processus (audit des Configurations avant Déploiement)
possibilité de confondre en une seule équipe la Gestion des Configurations et des Déploiements avec ou sans la
Gestion des Changements
8.2 Gestion des Changements
Le CCC ou Comité Consultatif des Changements (CAB ou Change Advisory Board) est responsable (sur les conseils de la
Gestion des Mises en Production) de faire des recommandations sur le contenu des Distributions et leur calendrier de
Déploiement
La Gestion des Mises en Production exécute ensuite ce qui a été décidé par le CCC
Même si la Gestion des Mises en Production supervise la mise en place des Changements, elle reste sous le contrôle et l’autorité de la Gestion des Changements
8.3 Logiciels livrés par les Etudes et les fournisseurs tiers
Lorsqu’une application interne ou tiers a été acceptée, la Gestion des Mises en Production l’insère dans la DSL et la référence dans la CMDB
La Gestion des Mises en Production est responsable de la fabrication de la Distribution (de la DSL vers les environnements d’homologation)
Une fois les tests concluants, la Gestion des Mises en Production devrait être responsable du Déploiement de la Distribution en production
13
8.4 Gestion des Problèmes et Centre de Services
A la fin d’un Déploiement correct d’une nouvelle Distribution (ITIL ne précise pas quand se situe ce moment : à la fin du
déploiement ou à la fin d’une période de vérification appelée quelquefois VSR ou Vérification de Service Régulier), il est nécessaire :
de fermer les Problèmes et demandes d’améliorations correspondants
d’ajouter les nouveaux Problèmes Connus apportés par la Distribution (le Centre de Services doit pouvoir effectuer le support de la nouvelle version)
de former/d’informer la Gestion des Problèmes et le Centre de Services sur le contenu de la Distribution (et sur le
calendrier de Déploiement)
14

Link público atualizado
O link público para o seu chat foi atualizado.