Soutenance mémoire
Présentation du Service PFC
Le rôle du Service
Le Service PFC appartient au groupe ESC (Exploitation des solutions Cloud) dans le département Datacenter du CSP-IT-O (Centre des Services Partagés Informatique et Télécom Opérateur) de la DSP-IT (Direction des Services Partagés IT). Le Service est divisé en deux cellules qui sont l’Ingénierie en charge du support niveau 3 et de l’évolution de la solution et le Pilotage qui s’occupe du support niveau 2 et du pilotage de l’infogérant OBS qui exploite la solution.
Avant l’ouverture du Service PFC, les Pilotes d’Exploitation (PE) pouvaient se retrouver dans plusieurs cas pour approvisionner leurs serveurs informatiques . Soit le nouveau serveur n’était pas éligible à la virtualisation et dans ce cas il leur était possible d’obtenir une dérogation pour la mise en place d’un serveur physique, soit leur serveur l’était et il devait passer par le Service CONSER. Dans ce dernier cas, l’approvisionnement du serveur pouvait prendre plusieurs semaines et coûtait relativement cher.
La mise en place des PFC avait donc deux objectifs principaux :
Réduire le temps d’approvisionnement des serveurs
Réduire les coûts des ressources informatiques pour les clients de la DSP
Pour arriver à ces objectifs, et créer ce nouveau Service PFC, EDF a donc effectué un appel d’offre, avant la phase projet, auquel ont répondu, avec succès, l’intégrateur Telindus pour proposer le matériel et le logiciel et l’infogérant Orange Business Service (OBS) pour l’exploitation de la solution. Telindus a proposé d’utiliser les Vblock qui sont des armoires serveurs spécialisées dans la virtualisation vendues par VCE. Le Vblock regroupe donc les technologies Cisco pour le réseau, VMware pour le logiciel de virtualisation et EMC pour le stockage et un système de sauvegarde indépendant appelé AVAMAR. A partir de ce moment, il était possible pour EDF de commencer la phase projet qui a duré six mois et qui consistait à mettre en place ce nouveau Service PFC qui offre aux clients un Cloud privé de type IaaS. Le Service a donc pu ouvrir le 06 janvier 2014 et c’est donc à cette date que la mission a débuté.
La solution PFC est aussi en concurrence avec le service proposé par CONSER et la solution qui sera proposée par le projet CAP CLOUD. Pour le moment ce dernier n’est pas terminé, donc le choix des PE se portera soit sur PFC, soit sur CONSER. Pour approvisionner un serveur sur PFC, la machine doit répondre aux critères d’éligibilité maximum suivants :
6 vCPU
24 Go 2 de RAM
250 Go d’espace disque
Un serveur dépassant un de ces critères devra donc être approvisionné sur CONSER. Dans le cas contraire, le PE pourra utiliser PFC qui a pour avantage un temps très court de mise à disposition du serveur, de l’ordre de 10 minutes en moyenne, qui fait défaut à CONSER.
Objectif de la mission
La mission a pour principal objectif de rendre un service d’approvisionnement de serveur via un Cloud Privé de type IaaS aux Clients de manière efficace grâce à une équipe de Pilotes, de Coordinateurs et d’ingénieurs.
Problème d’accès au portail vCloud Director PFC
Les problèmes d’accès au portail sont habituellement liés à un problème de compte dans l’Active Directory ADAM. L’intervenant de la cellule Pilotage va donc vérifier le compte de la ou des personnes qui ne parviennent pas à se connecter. S’il s’agit de l’absence d’un compte, ce dernier est ajouté par l’intervenant de la cellule Pilotage. S’il s’agit d’un problème Active Directory général, l’incident est réorienté vers l’équipe en charge de l’AD ADAM. S’il s’agit d’un problème de profil VPN pour la connexion sécurisée à la machine située en ZSA (Zone Sécurisée d’Administration) qui héberge le portail vCloud, le PE est invité à se rapprocher de son correspondant informatique pour créer son profil VPN ou, si le profil existe déjà, une demande d’ouverture de flux est faite aux équipes Réseau par la cellule Pilotage.
Problème d’approvisionnement de serveurssur PFC
Pour les problèmes d’approvisionnement, il peut s’agir soit d’un non-respect de la procédure, auquel cas, le PE est invité à consulter la documentation, soit d’un problème du Workflow vCenter Orchestrator (vCO) de création des VM PFC. Dans ce dernier cas, l’incident est redirigé vers la cellule Ingénierie pour analyse par unexpert. Dans la plupart des cas d’un problème général de Workflow, les services vCO sont redémarrés par l’intervenant de la cellule Ingénierie et le PE est invité, par l’intervenant de la cellule Pilotage, à relancer un approvisionnement de son serveur.
Problèmes de suppression de serveurs sur PFC
Les problèmes de suppression surviennent habituellement quand le PE tente l’opération lorsque la vApp ou la VM qu’elle contient sont allumées. L’intervenant de la cellule Pilotage répond au PE en l’informant qu’il faut qu’il demande l’arrêt de la vApp et de la VM à son infogérant système. La cellule Pilotage pourra exceptionnellement éteindre la vApp et la VM à la demande du PE pour des contraintes de temps. Dans de rares cas, le problème peut être dû à un dysfonctionnement du Workflow vCO de suppression.
Problèmes d’accès aux serveurs sur PFC
Les problèmes d’accès au serveur peuvent être divers et variés. En général, l’intervenant de la cellule Pilotage s’assure qu’il n’y a pas de problème VMware au niveau de la VM. S’il y a une anomalie, il corrige le problème ou le redirige vers la cellule Ingénierie pour correction ce qui résout le problème. S’il n’y a pas de problème VMware ou que ce dernier est résolu mais que le PE rencontre toujours des difficultés, il peut s’agir d’un problème Système. Dans ce cas, l’incident est redirigé vers les équipes EEI et notamment le Support Serveurs.
Problèmes Réseau
Les problèmes Réseau regroupent les problèmes de configuration des VLAN sur PFC qui sont redirigés vers l’infogérantOBS, les problèmes Active Directory qui sont redirigés vers les équipes ADAM et les problèmes de flux VPN traités par les équipes Réseaux. Dans chacun des cas, c’est l’intervenant de la cellule Pilotage qui doit rediriger l’incident vers l’entité concernée.
Problème d’inventaire ou de facturation
L’inventaire du parc informatique EDF est géré par les équipes GAA. En principe, le serveur doit être ajouté dans l’outil de gestion de parc (SCOPE GP). Le lendemainde son ajout dans SCOPE GP, la machine apparaît dans Fisher qui est l’outil de facturation et la fiche du serveur peut être complétée par l’intervenant de la cellule Pilotage. Cette démarche est nécessaire pour que le PE puisse demander l’installation de l’outillage à son Infogérant Système. En cas de problème, soit la machine n’a pas été ajoutée dans SCOPE GP, soit elle ne l’a pas été dans Fisher. Dans ces deux cas l’intervenant de la cellule Pilotage doit contacter la cellule GAA pour qu’elle vérifiesi la machine est présente dans la Base de données SCOPE GP et l’ajoutele cas échéant. Si le problème provient plutôt de Fisher, il faut contacter son POA pour qu’il demande à ses équipes d’analyser le problème.
Ajout d’une nouvelle entité à l’infrastructure PFC
L’ajout d’une nouvelle entité (Plateau d’Exploitation ou Infogérant/Exploitant Système) à l’infrastructure PFC demande la réalisation de plusieurs actions techniques sur l’Active Directory, dans le portail vCloud Director, dans le Client du système de sauvegarde AVAMAR, dans les Templates des Souches PFC via des commandes REST et dans le Workflow vCO. Les cinq premières actions peuvent être prises en charge par l’intervenant de la cellule Pilotage et la dernière action doit être effectuée par un intervenant de la cellule Ingénierie. Les gestes techniques sont décrits dans des procédures présentes dans la Base PFC.
Ajout d’un Template d’une nouvelle Souche à l’infrastructure PFC
Les Templates des Souches PFC contiennent les systèmes d’exploitation et le « bundle système » (ensemble d’outils logiciels) de base des serveurs virtuels EDF Linux et Windows.
Ces Templates sont gérés par les équipes EEI. Suite au Projet PFC, la plupart des Souches étaient présentes. Cependant, il peut arriver qu’une entité demande une nouvelle Souche. Dans ce cas, si les équipes qui gèrent cette Souche (en général le demandeur) sont d’accord pour gérer cette Souche sur PFC, alors la Souche peut être ajoutée. Une fois cet accord obtenu, la cellule Ingénierie doit mettre à disposition du demandeur une VM de test pour mettre au point le Template avant sa mise en production. Cet ajout n’est justifié que si un nombre important de VM sont approvisionnées par la suite en utilisant ce Template. A noter que lors de l’approvisionnement d’une machine PFC, le Workflow vCO copie le Template qui est en fait une VM éteinte et le personnalise en fonction des choix de configuration qu’a effectués le PE pour son nouveau serveur (nombre de vCPU, quantité de RAM, espace disque, etc…).
Interaction avec l’Infogérant Orange Business Service (OBS)
L’infogérant OBS est garant du bon fonctionnement de l’infrastructure PFC excepté pour le Workflow vCO qui reste à la charge de la cellule Ingénierie PFC. Pour fonctionner l’infrastructure utilise de nombreuses VM d’infrastructure qui forment ce qu’EDF nomme l’IMP (Infrastructure Management Pod). OBS doit s’assurer que les VM d’infrastructure fonctionnent correctement et que le Service est opérationnel.
Motivation du Projet
Comme le montre la modélisation des processus métiers du Service PFC, ces derniers sont relativement complexes. Le système de gestion des connaissances actuel permet bien d’enregistrer le traitement des incidents et des demandes ainsi que les documents mais semble, cependant, insuffisant. En effet, il apparaît ici que la gestion de la connaissance se fait au fil de l’eau et de manière un peu anarchique. Dans ces circonstances, il sera compliqué, voire impossible, de réutiliser ces connaissances car elles seront trop difficiles à retrouver. La solution est de mettre en place un système de gestion des connaissances adapté auService PFC en utilisant les outils du Knowledge Management (KM). Souvent, la mise en place du KM reste une activité secondaire mais qu’il est indispensable de réaliser et c’est le cas pour le Service PFC chez EDF. Cependant, il convient de rester prudent car ce type de projet peut facilement échouer [1, p. 52]. En effet, le principal risque serait que les gens n’utilisent pas le système parce qu’il est inadapté, non convivial, trop compliqué à utiliser, trop lourd ou qu’il fait « doublon » avec le système existant.
Selon Jean Yves PRAX, il est très difficile de calculer de manière juste le Retour sur Investissement de la mise en place du KM [1, p. 12]. En effet, d’après lui, les bénéfices qui se traduisent généralement en temps gagné dans le traitement des processus métiers sont très variables d’une situation à l’autre. Cela s’explique par le fait que l’efficacité du KM dépend d’une combinaison de facteurs et qu’il n’est pas possible d’isoler le KM des autres facteurs. Bien qu’il ne soit pas évident de constater les avantages immédiatement, il est sûr qu’il y a un gain sur le long terme et ce dernier peut même être très important. Selon Alphonse CARLIER, le KM permet d’améliorer les performances, l’efficacité, le partage et ainsi favorise l’innovation [6, p. 108]. Dans notre cas, voici les avantages que pourront apporter la mise en place du KM :
Les demandes seront plus rapides à traiter puisque les informations nécessaires pour y répondre seront plus faciles à trouver.
Certaines demandes pourront être évitées car les PE pourront accéder aux informations plus facilement sans avoir besoin de solliciter le Service PFC.
Les incidents pourront être résolus plus rapidement. En effet, le classement des incidents et des solutions proposées correspondantes permettra de résoudre les nouveaux incidents du même type bien plus rapidement et simplement en se référant aux anciens incidents traités et enregistrés.
Les outils du Service PFC, très utiles à la cellule Ingénierie, seront plus faciles à trouver.
Cela fera gagner du temps et donc améliora la réactivité du Service
Les échanges entre les membres de l’équipe PFC seront améliorés notamment pour la mise à jour de la documentation et des procédures
Certaines procédures de la cellule Pilotage PFC seront simplifiées notamment celle qui consiste au classement des incidents et des demandes.
Le Reporting sera, lui aussi, simplifié
Les objectifs du projet sont donc d’améliorer la qualité deservice en mettant en place un système de partage des connaissances participatif etun système de stockage des documents et des outils formant une Base de connaissances adaptée au Service PFC accessible à travers un portail collaboratif.
Les messageries électroniques du Service PFC
Les acteurs du Service PFC communiquent énormément en interne ou vers l’extérieur avec les Clients, les infogérants, les intégrateurs, les fournisseurs et les autres Services d’EDF via la messagerie électronique. Chaque acteur du Service PFC dispose bien entendu de sa propre boîte aux lettres électronique mais pour les échanges importants nous préférons utiliser les boîtes aux lettres électroniques génériques (un acteur recevant sur sa boite aux lettres personnelle un mail destiné à tous les membres de la cellule ou de l’équipe le redirigera vers la boîte aux lettres générique de sa cellule). Le Service PFC dispose d’une boîte aux lettres générique par cellule et chacune d’elle peut contenir des informations importantes sur le traitement d’une demande ou d’un incident qui ne figure nulle part ailleurs.
La Base Lotus Notes PFC
Elle sert exclusivement au Service PFC. Elle contient des informations communes à tout le Service comme le suivi de la prestation, des informations spécifiques aux cellules Pilotage et Ingénierie, des fiches décrivant des procédures particulières, des documents de toutes sortes (contrats, PTE, procédures,…) et des informations concernant le Projet PFC. Cette Base n’est accessible totalement que par les membres de l’équipe.
La Base Lotus Notes RD&E
Il s’agit également d’une Base Lotus Notes mais qui contient, entre autre s, des informations sur plusieurs Services chez EDF. En général, toutes personnes ayant besoin d’informations sur un Service peut s’y connecter. La Base contient, bien sûr, des informations sur le Service PFC et notamment la Frequently Asked Questions (FAQ) qui est en quelque sorte l’ensemble des premières informations mises à disposition du PE avant la prise de contact avec notre Service.
SCOPE GS
EDF a mis en place un système de gestion des incidents et des demandes assez élaboré.
Ce système repose sur le logiciel HP OpenView ServiceCenter et est appelé SCOPE GS (Gestion de Service). Comme pour tous les Services d’EDF, les incidents et les demande s concernant le Service PFC passentpar cet outil pour une meilleure traçabilité (la facturation des infogérants se base d’ailleurs sur ce système). Chaque incident représente une entrée et les demandes sont subdivisées en articles.
Ce système contient donc de nombreuses informations sur le traitement des incidents et des demandes PFC qui n’ont pas été formulés par mail.
Les problèmes liés à l’existant
Le fait qu’il y ait cinq référentiels de gestion des connaissances différents n’est pas optimal et nuit donc aux performances du Service PFC. En effet, non seulement cela pose problème lors de la recherche d’une information précise qui peut s’avérer longue car il est difficile de déterminer où chercher mais, en plus, c’est une source d’erreur car la même information est souvent copiée dans plusieurs référentiels (des fois dans des versions différentes) et à long terme une erreur est inévitable. Il s’agit d’un problème de «versionning » des documents.
A cela s’ajoute les informations sur les incidents et les demandes traitées qui peuvent être présentes dans la boîte aux lettres générique Lotus Notes de la cellule Pilotage ou dans l’outil de gestion des incidents et des demandes SCOPE GS. Cette organisation ne permet pas de capitaliser facilement les connaissances acquises lors du traitement de ces demandes et incidents qui deviennent difficiles à retrouver et à réutiliser.
Concept sur la gestion des connaissances collectives
Les enjeux
Dès le moment de leur création, les entreprises commencent à accumuler des connaissances. L’ensemble de ces connaissances augmente rapidement avec le temps. Cependant, contrairement à ce qui pourrait être supposé, les entreprises peuvent perdre ces connaissances. En effet, ce n’est pas l’entreprise en tant que telle qui crée ses connaissances mais plutôt les personnes qui y travaillent. Certes, les entreprises peuvent essayer d’enregistrer ces connaissances sur des supports papiers ou numériques, cependant ce n’est pas suffisant car cela sous-entend que les connaissances peuvent toutes être stockées et réutilisées indépendamment des personnes qui en sont à l’origine.
Cette difficulté de conservation des connaissances vient du fait qu’il enexiste de plusieurs types dont certaines, comme le savoir-faire ne peuvent pas être enregistrées facilement et nécessitent d’être transmises d’une personne à une autredifféremment que par le biais de documents (par l’apprentissage par exemple). Les connaissances peuvent donc être perdues lors du départ d’un collaborateur. D’autre part, même lorsque personne ne quitte l’entreprise, il arrive souvent que les connaissances ne circulent pas de manière optimale voir pas du tout à cause, par exemple, d’un mauvais système communication ou de rétention d’informations.
|
Table des matières
Remerciements
Glossaire
1. Introduction
2. Présentation d’EDF
2.1. La société
2.2. Un acteur majeur de l’énergie européen
2.3. L’organisation
2.4. Les Services
2.5. La prestation chez EDF pour le Service PFC
3. Présentation du Service PFC
3.1. Le rôle du Service
3.2. Objectif de la mission
3.3. Rôle de l’opérateur PFC dans la mission exercée
3.4. Indentification des différents acteurs
4. Analyse du besoin
4.1. Modélisation des processus métiers existants
4.1.1. Interaction avec le Pilote d’Exploitation
4.1.2. Interaction avec l’Infogérant Orange Business Service (OBS)
4.1.3. Interaction avec l’Intégrateur Telindus
4.1.4. Interaction avec les autres Services EDF
4.1.5. Schéma des processus métiers
4.2. Motivation du Projet
5. Présentation des référentiels de gestion de connaissances existants
5.1. Les messageries électroniques du Service PFC
5.2. La Base Lotus Notes PFC
5.3. La Base Lotus Notes RD&E
5.4. PRODIS
5.5. SCOPE GS
5.6. Les problèmes liés à l’existant
6. Concept sur la gestion des connaissances collectives
6.1. Les enjeux
6.2. Le Knowledge Management
6.2.1. Définition
6.2.2. Qu’est-ce que la connaissance ?
6.2.3. Les modèles du Knowledge Management
6.2.4. Les méthodes de capitalisation de connaissances du KM
6.2.5. Les outils pour la mise en œuvre du Knowledge Management
6.2.6. Les communautés de pratiques et les communautés d’intérêt
6.2.7. Cartographie des connaissances
6.3. Gestion des connaissances dans une démarche ITIL
6.3.1. Présentation d’ITIL
6.3.2. Les recommandations d’ITIL sur la gestion des connaissances
6.4. Le Web sémantique
6.4.1. URI/IRI
6.4.2. XML
6.4.3. RDF
6.4.4. SPARQL
6.4.5. RDFS
6.4.6. OWL
6.4.7. Les applications du Web Sémantique
7. Lancement du projet
7.1. Estimation de la charge de travail
7.2. Planning prévisionnel
7.3. Estimation du retour sur investissement
7.4. Analyse de risques
7.4.1. Les risques techniques et technologiques
7.4.2. Les risques au niveau des délais
7.4.3. Les risques économiques
7.4.4. Les risques d’écarts par rapport aux objectifs initiaux
7.4.5. Les risques juridiques
7.4.6. Les risques humains
7.4.7. Matrice des risques
8. Comment gérer les documents et le contenu du Service PFC
8.1. Rôle des GED et CMS
8.2. Apport d’une solution de GED par rapport au système actuel
8.3. Solution de gestion documentaire et de contenu pour le service PFC
9. Comment capitaliser les connaissances du Service PFC
9.1. Apport d’une solution de gestion de contenu par rapport au système actuel
9.2. Solution de capitalisation des connaissances pour le service PFC
10. Architecture de la solution
10.1. Diagramme UML de cas d’utilisation du système
10.2. Exemples d’utilisation de la solution
10.3. Sécurité
10.3.1. Accès aux données
10.3.2. Préservation des données
11. Choix technologique de la solution
11.1. Etudes comparatives des différents outils du Marché
11.1.1. Choisir un moteur Wiki
11.1.2. Choisir une solution de GED
11.1.3. Choisir un portail d’entreprise
11.2. Les contraintes
11.2.1. Economique
11.2.2. Technologique
11.2.3. Contraintes de l’infrastructure actuelle
11.3. Choix définitif : la suite logicielle Alfresco
11.3.1. Motivation du choix
11.3.2. Architecture technique de la suite Alfresco
12. Mise en place du portail collaboratif au sein du Service PFC
12.1. Installation et configuration
12.1.1. Choix du système d’exploitation de la machine cible
12.1.2. Choix de la configuration du matériel de la machine cible
12.1.3. Les prérequis à l’installation
12.1.4. Paramètres d’installation
12.1.5. Configuration complémentaire suite à l’installation
12.1.6. Installation d’un module de monitoring
12.2. Transfert des données du système existant vers la nouvelle solution
12.3. Premier retour des utilisateurs avant la personnalisation de la solution
12.4. Personnalisation de la solution
12.4.1. Personnalisation du Wiki : création de modèles de fiches
12.4.2. Nommage des nouveaux articles
12.4.3. Rapprocher le Wiki intégré d’Alfresco de MediaWiki
12.4.4. Choix des Sites de collaboration
12.4.5. La fonctionnalité discussion pour les remarques des utilisateurs
12.4.6. Personnalisation de l’interface utilisateur
12.4.7. Personnalisation de l’espace documentaire
12.4.8. Gestion des documents obsolètes
12.5. Mise en place du processus de mise à jour et de maintenance
12.6. Conduite du changement
12.7. Perspectives d’évolutions fonctionnelles et métiers de la solution
13. Bilan et synthèse
13.1. Les résultats obtenus
13.2. Analyse de la démarche du projet
13.3. Analyse des difficultés rencontrées
14. Conclusion
Liste des figures
Liste des tableaux
Bibliographie et Webographie
Annexes
Procédure d’installation de la suite logicielle Alfresco
Procédure de mise à jour de la suite logicielle Alfresco
Fichiers de configuration de la suite Alfresco
Procédure pour gérer les documents obsolètes
Créer un nouveau thème pour le portail Alfresco Share
Tableau des rôles utilisateur dans Alfresco Share
Télécharger le rapport complet
