1 – INTRODUCTION

Voici une réalisation effectuée dans le cadre de la Licence ASR (Administration et Sécurité des Réseaux) au sein de l’Université de Toulon. Pour valider le diplôme, un stage d’une durée de trois mois et demi était à réaliser et j’ai été accueilli au sein de l’entreprise SEA TPI à La Ciotat (13).

SEA TPI est une entreprise de services numériques qui a été fondée il y a vingt-sept ans par Monsieur Albert PELFORT. Cette entreprise accompagne les entreprises dans la mise en œuvre de centres de services. Différents du centre d’appel ou du help desk, les centres de services sont capables de répondre à toutes les demandes des clients peu importe le niveau de complexité requis. 

SEA TPI se définit en 4 adjectifs : 

• Pionnière : cette entreprise favorise la création de nouveaux centres de services pour maîtriser pleinement les systèmes d’information.

• Humaine : c’est une entreprise qui a toujours été familiale.

• Agile : elle fait des choix techniques et humains pour se conformer au mieux aux besoins de ses clients.

• Collaborative : elle favorise le travail en équipe et met à disposition au sein de ses locaux, toute l’infrastructure nécessaire à cette collaboration, interne comme externe (salles de réunion réservables par chacun dans l’entreprise, box de discussions, multiples tableaux blancs pour les différents brainstormings, etc.).

La réalisation que je vais vous présenter se concentre sur le travail d’implémentation d’une CMDB (base de données de gestion de configuration) que j’ai réalisé chez SEA TPI. La CMDB est un composant fondamental d’une architecture ITIL (ensemble d’ouvrages qui recensent les bonnes pratiques du management du système d’information). Une base de données de gestion de configuration contient des informations sur les principaux composants du système d’information (appelés configuration items ou CI) et des détails sur les relations importantes entre eux. 

Le projet CMDB fut initié suite à la constatation d’un grand nombre d’erreurs présentes sur le parc applicatif en production de SEA TPI. En effet, dans le cadre des différentes demandes des clients, chaque semaine une dizaine de machines virtuelles peuvent être créées, supprimées ou simplement modifiées. Les équipes de SEA TPI peuvent commettre des erreurs dans la gestion du parc et c’est pourquoi certaines machines virtuelles peuvent être mal nommées. L’entreprise est dotée de conventions de nommages concernant le nom des machines virtuelles. Ces conventions de nommages prennent en compte le système d’exploitation de la machine, cependant, au fil de leur fonctionnement le système d’exploitation peut être altéré sans que le nom de la machine ne soit modifié. Cela peut créer un décalage entre les conventions de nommage et la réalité. Suite au manque d’application des conventions (et des procédures rédigées pour créer correctement des machines virtuelles) beaucoup d’entre elles sont mal recensées au sein du système d’information. 

Certaines machines virtuelles ne sont pas présentes dans les logiciels de supervision ou alors, elles sont mal configurées. D’autres sont inventoriées sous un nom différent de celui attribué en production au sein du logiciel d’hypervision Nutanix. Certaines machines virtuelles (VM) ne sont pas du tout présentes dans notre solution de backup (HYCU), ou ne sont pas inventoriées dans les serveurs DNS et ADDS (Active Directory Domain Services) de l’entreprise. Il y a douze logiciels qui concernent directement ou indirectement les machines virtuelles.

Suite à la découverte de cette problématique, le projet CMDB a été initié et nous avons dû, avec l’aide de mon responsable de stage, exprimer, développer et apporter des solutions à l’ensemble des erreurs constatées. 

2 – OBJECTIFS

Les objectifs de cette réalisation comportent des objectifs techniques et humains. 

Deux objectifs techniques principaux concernent cette réalisation : gagner en cohérence dans le parc applicatif grâce à l’ajout de CI (éléments de configuration) en créant des dépendances entre eux, et l’automatisation de la gestion de la cohérence dans le SI (Système d’Information).  

Deux objectifs humains concernaient cette réalisation : la découverte du fonctionnement d’une ESN et la mise en œuvre de la gestion de projets.

2.1 – LES OBJECTIFS TECHNIQUES

Le premier objectif de cette réalisation était donc d’apporter de la cohérence dans l’ensemble du parc applicatif. Toutes les machines virtuelles doivent être présentes dans la solution de virtualisation (Nutanix) et inventoriées dans une CMDB avec un ensemble de paramètres attitrés (système d’exploitation, types de sauvegarde, criticité, etc.). Ces éléments inventoriés sont appelés des éléments de configuration (appelé CI pour Configuration Item) auxquels il faudra ajouter différentes informations uniques pour chaque VM. Au-delà d’un aspect de recensement, la CMDB permet la mise en relation des différents éléments de configuration (CI) avec la création d’une hiérarchie de dépendance. Ainsi, il devient possible de constater les conséquences de l’indisponibilité d’une machine virtuelle et de visualiser les services qui cesseront de fonctionner suite à un incident. Cette démarche de recensement des éléments du système d’information englobe également l’ensemble des éléments physiques tels que les sites, salles, baies de brassage, équipements réseaux (routeurs, hyperviseurs, switchs, firewall, serveur de vidéosurveillance, etc.).

Le second objectif technique du projet était de déployer des automatismes au sein de la CMDB afin de maintenir l’ensemble du parc applicatif cohérent. Bien que n’étant pas développeur, j’ai eu pour mission de rédiger un document d’expression de besoins qui a été transmis à l’équipe DevOps de SEA TPI. Ce document devait être clair et concis pour favoriser la compréhension des équipes qui allaient être en charge de réaliser les différentes automatisations.

2.2 – LES OBJECTIFS HUMAINS

Le premier objectif a été de découvrir le fonctionnement d’une ESN (Entreprise de Services Numériques) et de ses collaborateurs ; en effet, je n’avais jamais intégré auparavant une entreprise avec autant d’informaticiens (environ 200) sur un seul site (La Ciotat). Il m’a fallu pour cela être très attentif aux interactions existantes entre les différents services.

Le second objectif de cette réalisation a été d’exercer mes compétences en matière de gestion de projet en informatique dans un contexte d’entreprise.

3 – CONTEXTE HUMAIN

Au cours des trois mois et demi de stage que j’ai réalisés chez SEA TPI, j’ai fait partie du service MCO (Maintien en Condition Opérationnelle). Ce service, sous la responsabilité de mon maître de stage Monsieur Julien CORNILLARD, est composé d’un ingénieur et d’un administrateur systèmes et réseaux, de deux alternants en cybersécurité et d’un stagiaire (moi). Pendant toute la durée de mon stage, j’ai été en relation avec chacun d’eux pour récolter toutes les informations nécessaires au projet CMDB. 

Mon maître de stage a été le chef du projet CMDB. Ensemble, nous avons réalisé de nombreuses réunions pour réfléchir sur les différents besoins du projet. Il a piloté le projet en m’indiquant les priorités et la nécessité de réaliser différentes tâches.

J’ai également échangé avec différents acteurs de l’entreprise (ingénieurs systèmes, ingénieurs DevOps, techniciens DevOps, administratrices des ventes et comptables). Ces séances de travail m’ont permis de récupérer et de transmettre un ensemble d’informations décisives dans le cadre du projet CMDB, comme des confirmations de certaines informations en lien avec la sensibilité d’une machine virtuelle ou la récupération d’informations en lien avec certains contrats. J’ai aussi consulté le DevOps chargé de réaliser les automatisations dans le cadre du projet CMDB. 

4 – CONTEXTE TECHNIQUE

Pour réaliser l’harmonisation des machines virtuelles de SEA TPI, nous avons utilisé la CMDB (base de données de gestion des configurations) présente dans le logiciel EasyVista.

EasyVista est un logiciel de type ITSM (gestion des services informatiques). Il permet aux informaticiens de SEA TPI d’inventorier l’ensemble des matériels informatiques, de gérer leurs incidents et de procéder à la gestion des changements au sein de l’entreprise. C’est ce logiciel qui accueillera la CMDB.

Voici une présentation de l’ensemble des logiciels qui interagissent avec la CMDB d’EasyVista. 

Schéma des solutions applicatives de SEA TPI

  

4.1 – Les logiciels de la zone socle

• ACTIVE DIRECTORY (AD)

Un serveur Active Directory (AD) permet la centralisation de l’authentification dans un parc applicatif Microsoft.

• DNS 

Un serveur DNS (Domain Name System) simplifie l’usage des adresses IP en les masquant derrière un nom de domaine public ou privé. Ce serveur permet de faire la relation entre un nom de domaine et une adresse IP.

• NUTANIX

Nutanix est la solution de virtualisation choisie par l’équipe MCO pour gérer l’ensemble des machines virtuelles de l’entreprise ainsi que de celles de ses clients. L’hypervision (le fait d’user de serveurs virtuels sur un hyperviseur physique) au sein de l’entreprise est scindée sur deux clusters. Un cluster permet d’éviter l’arrêt d’un service de production grâce à de la redondance entre ses différents nœuds.

Le premier cluster est basé dans un datacenter à Marseille comportant trois nœuds de 750 gigaoctets de mémoire vive et le second sur l’un des trois sites de SEA TPI.

• IPAM

IPAM (IP Address Management) est un logiciel de gestion d’adresses IP qui recense les adresses utilisées et libres dans les sous-réseaux d’une entreprise. Il permet ainsi de monitorer les effectifs d’adresses IP libres dans les réseaux et de contrôler et prévenir les sous-réseaux de l’entreprise en cas de sur-utilisation.

• HYCU

HYCU est un logiciel de BAAS (Backup As A Service). Dans le contexte de SEA TPI, celui-ci sauvegarde les backups de Nutanix sur AWS (Amazon Web Service).

• GUACAMOLE

Apache Guacamole est une passerelle de bureau à distance WEB supportant la plupart des technologies de prise en main à distance (RDP, VNC, SSH, etc.).

4.2 – Le logiciel de la zone industrialisation

• TALEND

Le logiciel Talend a été choisi par le service d’industrialisation pour réaliser de manière automatique la cohérence du parc applicatif. 

4.3 – Les logiciels de la zone sécurité

• FORTINET

Fortinet est un Firewall qui s’assure de la sécurité de l’entreprise grâce à des règles de sécurité.  

• NESSUS

Nessus est un logiciel de cybersécurité qui réalise des scans sur des hôtes définis. Il permet de se prémunir contre les attaques les plus courantes, mais aussi de se conformer aux différentes normes du numérique comme l’ISO 27001.

• IVANTI

Ivanti est un logiciel qui permet de simplifier et d’automatiser la gestion des correctifs pour les serveurs physiques et virtuels dans le centre de données.

• GRAYLOG

Graylog est un logiciel permettant le tri et le stockage des journaux d’événements des serveurs de l’entreprise via le protocole Syslog.  

4.4 – Le logiciel de la zone supervision

• Coservit

Coservit est une solution de supervision des équipements usant des différentes possibilités de surveillance de réseau standard (Ping, Simple Network Management Protocol, etc.).

5 – ENJEUX ET RISQUES

5.1 – ENJEUX

Le projet CMDB couvre deux enjeux majeurs : l’amélioration de la gestion du parc applicatif ainsi que la réduction des erreurs et des coûts.

• L’amélioration de la gestion des configurations

Grâce au projet CMDB, le parc applicatif deviendra complètement cohérent. Les DevOps pourront ainsi détecter les anomalies et procéder à des corrections. C’est un enjeu très complexe à atteindre concrètement, car il y aura toujours une situation qui diffère du standard, comme fréquemment en entreprise.

• La réduction des erreurs et des coûts

Augmenter la fiabilité permet de simplifier les interventions de la MCO. Avoir un monitoring à jour permet notamment d’éviter des oublis. La durée de chaque intervention peut ainsi se voir réduite de quelques minutes et ainsi entraîner une réduction des coûts. À l’échelle d’une entreprise de la taille de SEA TPI, cela est considérable. L’ amélioration de la visibilité sur les certificats est également un enjeu du projet CMDB.

5.2 – RISQUES

Cette réalisation peut générer différents risques. L’expression de besoins pourrait comporter des erreurs ou être mal comprise par l’équipe industrialisation ce qui engendrerait l’augmentation de la complexité technique due à l’ajout de la CMDB et diminuer la sécurité. 

Il est possible que l’expression de besoins comporte des erreurs ou qu’elle soit mal comprise par les techniciens DevOps, c’est pourquoi il est très important de favoriser la communication et les échanges entre les équipes impliquées pour éviter l’effet tunnel. 

Dans certains cas, automatiser des tâches engendre une diminution de la sécurité partielle ou globale de l’entreprise. Nous sommes souvent obligés de réaliser des choix suite à des contraintes techniques. C’est essentiellement dans la façon de stocker des mots de passe ou dans l’obligation d’ouvrir certains flux dans les firewalls de l’entreprise que ces failles se créent. Chaque nouveau système d’automatisation dans une entreprise peut s’avérer vraiment complexe à mettre en œuvre concernant l’aspect sécurité. 

6 – ÉTAPES DU PROJET

6.1 – GESTION DU PROJET

J’ai utilisé l’outil Monday (permettant la création de tableaux de suivi de projet) pour gérer le projet CMDB. Grâce à lui, j’ai pu organiser les différentes étapes du projet en listant les tâches à réaliser. Ces tâches devaient toutes être délimitées dans le temps (date de début et fin), affectées à une personne précise et être hiérarchisées (tâche parent/tâche enfant). Il était très important pour mon responsable que j’emploie cet outil, car il permet le suivi du projet partagé aux différents acteurs, et d’être ainsi en mesure de savoir quelles tâches ont déjà été réalisées. 

Conformément aux démarches de projets agiles, j’ai réalisé un diagramme de Gantt lors de mes premières semaines de stage. Celui-ci a permis aux différents services concernés par le projet de définir leurs plannings pour délivrer les différents livrables (appelés LOT) en temps et en heure. 

Diagrame Gantt du projet

Comme vous pouvez le constater, nous avons défini le 1er juillet 2022 comme date butoir des lots N°1 et N°2 de l’expression de besoins. Cette date a été choisie dans l’optique de me donner la possibilité de voir fonctionner les premiers automatismes avant la fin de mon stage.

Pour définir ces dates butoirs avec mon maître de stage, nous avons dû considérer la complexité des différentes productions demandées (nous détaillerons ces besoins dans la partie expression de besoins). Les lots 3 et 4 seront réalisés par d’autres acteurs après mon départ.

Chez SEA TPI en cas de changement d’infrastructure réseau ou applicative une validation est nécessaire peu importe le risque encouru. Pour cela, l’envoi d’une demande de permis de changement doit être effectué. Celle-ci doit comporter l’ensemble des informations permettant la validation de la modification. Un degré de risque devra être quantifié (par la personne émettrice de la demande) entre routine, normal et exceptionnel. Selon le degré de risque, la personne qui validera la demande de changement sera différente.  

6.2 – Définition des critères à respecter

Dans le cadre de ce projet, j’ai respecté ces trois critères : 

• Simplicité

La simplicité permet de favoriser la compréhension et la maintenabilité des éléments techniques retenus.

• Évolutivité

Des logiciels qui aujourd’hui sont en adéquation avec la CMDB pourront dans l’avenir être remplacés par d’autres. Il sera nécessaire de pouvoir faire des mises à jour et des modifications.

• Pérennité

La solution devra durer dans le temps. 

6.3 – Expression de besoins

Une expression de besoins est un recueil de besoins dans lequel le client formule à son prestataire technique son projet et ses attentes. Il comprend les détails de ce qui est déjà opérationnel dans son projet et ce qui doit être retravaillé et développé.

Dans le cadre du projet, j’ai rédigé une expression de besoins à l’attention de notre service d’industrialisation interne. J’ai ainsi été le médiateur entre le chef de projet (Monsieur Julien CORNILLARD) et d’autres services de l’entreprise qui ont dû intervenir pour que je puisse construire l’expression de besoins.

J’ai participé à de multiples réunions (dont une quinzaine avec mon maître de stage), toutes nécessaires pour comprendre concrètement quels étaient les objectifs d’industrialisation de chaque logiciel impliqué par le projet. J’ai ainsi pu constituer ce document de cinquante pages dédié à notre service d’industrialisation. 

Idéation

Dans un projet, la phase d’idéation est une étape dans laquelle l’ensemble des acteurs de celui-ci peuvent proposer des idées pour tenter de répondre aux besoins du client. Dans le contexte du projet CMDB, notre client était le service d’industrialisation de l’entreprise.

Durant les différents échanges avec mon maître de stage, nous avons étudié les possibilités techniques du logiciel EasyVista qui héberge la CMDB. Bien que Monsieur CORNILLARD avait déjà une idée globale d’EasyVista, j’ai procédé à l’analyse des différents éléments que ce logiciel pouvait recenser comme les contrats, les modèles de contrats, les CI (éléments de configurations), les modèles de CI, les liens entre CI, l’affectation de contrat à des CI afin de comprendre leurs interactions.

Après avoir procédé à cette analyse d’EasyVista, j’ai rédigé un schéma d’utilisation du logiciel, puis, j’ai programmé et conduit plusieurs réunions avec Monsieur Romain GOFFI, expert EasyVista chez SEA TPI, ce qui m’a permis de comprendre le fonctionnement de certains aspects très complexes du logiciel. Je lui ai expliqué la direction que je souhaitais prendre dans le cadre de l’utilisation de la CMDB d’EasyVista. Il a alors validé la plupart de mes choix, mais a émis des réserves sur d’autres. Après m’être entretenu avec lui et avoir pris en compte ses observations, j’ai pu modifier les schémas d’utilisation. Cette méthodologie nous a permis de nous adapter aux différentes limites techniques du logiciel pour répondre au besoin initial.

Contenu de l’expression de besoins

L’expression de besoins que j’ai rédigée est composée d’une cinquantaine de pages dédiées à notre service d’industrialisation. Le projet CMDB comprend quatre lots (ensemble de produits/pièces/articles/objets issus d’une même fabrication). Durant mon stage, j’ai travaillé uniquement sur les deux premiers lots qui avaient comme échéances le 1er juillet 2022. Les deux autres lots ont été définis et réalisés par d’autres acteurs après mon départ.

Le projet consistait principalement à automatiser l’inventaire et le contrôle des différentes machines virtuelles au sein du parc applicatif. La rédaction de l’expression de besoins était nécessaire pour définir clairement le besoin d’industrialisation. Ce document contient l’ensemble des détails techniques nécessaires à l’interconnexion des différents logiciels de SEA TPI.

J’ai eu la consigne de réaliser un document clair, précis et concis afin de réduire le nombre de réunions nécessaires, ceci afin de limiter les interactions avec le service d’industrialisation pour recevoir les livrables plus rapidement.

LOT N°1 : intégration automatique des données de Nutanix vers EasyVista grâce à des déclencheurs

L’hyperviseur de SEA TPI est Nutanix. Il gère toutes les machines virtuelles de l’entreprise. L’objectif du projet était de faciliter la gestion des machines virtuelles, il fallait que nous comprenions l’utilité et la pertinence de chacune d’elles. Nous avons pour cela défini seize attributs qui allaient devoir être affectés au logiciel et complétés pour chacune des machines virtuelles de l’entreprise.

Dans le logiciel Nutanix, les attributs étaient stockés principalement sous forme d’étiquettes qui étaient affectées aux machines virtuelles et dans la CMDB, ces informations étaient stockées grâce aux fiches caractéristiques des éléments de configurations. 

 Afin de favoriser la compréhension de l’emplacement de stockage des attributs entre la CMDB et Nutanix, j’ai réalisé un tableau.

Tableau de correspondance d’attributs

Nutanix propose une solution d’appel API automatique en cas d’événements particuliers. Nous avons eu l’idée d’utiliser cette fonction afin de constamment tenir la CMDB à jour. 

Le principal besoin du premier lot était d’utiliser les déclencheurs du logiciel de virtualisation de l’entreprise afin de mettre à jour la CMDB. 

Dans le cadre de l’expression de besoins, nous avons retenu trois déclencheurs d’appels API : les machines virtuelles créées, les machines virtuelles clonées, et les machines virtuelles supprimées.

Le second besoin du premier lot était de lancer périodiquement (deux fois par jour) une routine de vérification de conformité. Celle-ci devait collecter l’ensemble des machines virtuelles présentes en production sur le logiciel Nutanix puis tester leur conformité avec les données présentes dans la CMDB. En cas d’anomalie, des alertes seraient générées dans le logiciel de visualisation de données Grafana.

Schéma fonctionnel du synchroniseur

LOT N°2 : mise en place de Cross-Check pour garantir une cohérence entre nos outils

Comme nous l’avons évoqué dans l’introduction du projet CMDB, l’idée était d’harmoniser notre parc applicatif en lien avec les machines virtuelles. Pour ce faire, j’ai défini différentes vérifications plus ou moins complexes à réaliser pour chaque logiciel qui recense ou interagit avec les machines virtuelles. J’ai, par exemple, défini que chacune des machines virtuelles devait être recensée dans le DNS de l’entreprise, mais également, qu’elles devaient être présentes dans le logiciel de supervision. Lors de la phase d’idéation, j’ai choisi la liste des seize attributs nécessaires. En utilisant cette liste, j’ai défini les attributs qui devront toujours être inventoriés sur les logiciels du parc informatique.  

Schéma récapitulatif des attributs corrélés avec les applications de l’entreprise

Pour chacun des logiciels, j’ai réalisé un schéma fonctionnel des différents éléments à mettre en conformité. Certains logiciels ont été assez compliqués à inventorier à cause de contrôles plus avancés définis par mon responsable de stage. La conformité des machines virtuelles dans le monitoring a été très complexe, car elle prenait en compte les différents niveaux de criticité et en fonction de ces derniers, nous devions vérifier si différentes informations liées aux astreintes étaient renseignées. De plus, selon le type d’OS de la VM, sa criticité ou son statut, nous devions contrôler que la machine virtuelle recevait des rôles de supervision adaptés. Un rôle de supervision vérifie une partie applicative de la machine virtuelle monitorée. Si un incident est rencontré pendant la supervision (par exemple, si un seuil est dépassé), le rôle de supervision peut déclencher des actions comme l’appel d’une astreinte, la génération d’un mail ou une alerte dans un outil de monitoring.

6.4 – Intégration de données dans la CMDB

Comme évoqué précédemment, la CMDB ne comprendra pas uniquement les machines virtuelles et leurs attributs, mais recensera également l’ensemble des liens permettant de définir une hiérarchie entre les différents éléments inventoriés.

• Les équipements physiques

En me basant sur l’existant inventorié sur le logiciel IPAM (IP Address Management), j’ai intégré l’ensemble des baies de brassage et leurs équipements physiques. Ce travail a été anticipé durant la phase d’idéation du projet. J’ai réfléchi aux différentes possibilités d’inventaires dans EasyVista et j’en ai conclu que pour avoir le résultat escompté, il était nécessaire de créer des salles serveurs, des sites géographiques, et des baies. En reliant l’ensemble, cela constituerait toute une hiérarchie et donc, un inventaire des dépendances. Après avoir constitué cette hiérarchie, j’ai affecté les équipements (déjà existants ou nouvellement créés) aux différents éléments physiques inventoriés dans la CMDB, ceux-ci étant principalement des baies de brassage.

• Les attributs des machines virtuelles dans Nutanix

Avant que les différents lots ne soient mis en production, il fallait recenser l’ensemble des seize attributs des 250 machines virtuelles, ce qui représente un total de 4 000 cellules Excel.  

Pour procéder à ce recensement, j’ai constitué un tableau Microsoft Excel et j’y ai renseigné les différentes informations, cependant, je n’ai pas défini 4 000 informations manuellement. Grâce aux différentes réunions réalisées avec un des ingénieurs systèmes et réseaux de l’équipe MCO, j’ai pu apprendre la convention de nommage de l’entreprise. Celle-ci m’a permis de réaliser des actions de groupe. 

Ce fichier a nécessité plus de deux mois de récolte d’informations entre les différents services de SEA TPI pour finalement être complet.

Lorsque ce fichier a été terminé, j’ai procédé à la création dans Nutanix de tous les attributs et leurs différentes valeurs possibles. Je ne pouvais pas réaliser ce changement sans appliquer les procédures de l’entreprise et c’est pourquoi j’ai réalisé au préalable, une demande de changement. Cette demande comprenait toutes les informations nécessaires au valideur pour comprendre les enjeux qu’aurait la modification sur le système d’information. J’ai spécifié un degré de risque “Normal”, car il s’agissait d’un simple ajout dans un logiciel de production ne pouvant pas entraîner d’interruption de service.

Le service d’industrialisation a réalisé un import de l’ensemble de ces informations vers Nutanix pour que les lots 1 et 2 puissent fonctionner correctement.

• Les services, services VIP et super services 

Chaque élément de configuration (CI) impacte un élément de configuration parent et enfant. J’ai créé des types de CI “fictives”. Ces éléments de configuration avaient pour objectif de visualiser les services dépendants d’une machine virtuelle. Les CI “services” représentaient un des services que pouvaient fournir une machine virtuelle (Mariadb, Apache2, Logstash, Nginx, etc.). Ces CI avaient un impact sur des CI “services VIP” représentant des services avec redondance. Il fallait ensuite créer des CI « super-services » correspondants à des services plus globaux, par exemple, le site institutionnel (seatpi.com) qui dépend du bon fonctionnement du service VIP des firewalls, mais également des services HAProxy et Wordress.

Réaliser ces liaisons nous permet de générer des tableaux de surveillance comme celui-ci (masqué pour des raisons de confidentialité) :

Exemple d’un tableau de monitoring des CI de la CMDB

• Les contrats

J’ai intégré l’ensemble des contrats de SEA TPI liés aux équipements physiques et aux applications de l’entreprise dans la CMDB. Pour ce faire, j’ai participé à plusieurs réunions avec mon responsable pour lister l’ensemble des contrats concernés, mais il ne possédait pas toutes les informations nécessaires, c’est pourquoi, j’ai dû contacter l’administratrice des ventes de SEA TPI. Nous avons réalisé cinq réunions pour lister l’ensemble des contrats liés aux équipements physiques et aux applications de l’entreprise. Notons que dans la CMDB EasyVista comme dans beaucoup d’autres logiciels du même type, les contrats dépendent d’un fournisseur et d’une référence (numéro de contrat, clé de licence ou n’importe quel autre élément le caractérisant formellement). Avant d’intégrer l’ensemble des contrats, j’ai créé tous les fournisseurs dépendants sur la CMDB. 

7 – Difficultés rencontrées

La plus grande difficulté que j’ai rencontrée au cours de ce projet a été d’arriver à comprendre le fonctionnement du parc applicatif composé de nombreux logiciels. Cette compréhension était nécessaire pour pouvoir exprimer avec précision le besoin d’industrialisation, de plus, le logiciel EasyVista qui accueillait la CMDB était très complexe. Un grand nombre de réunions avec notre expert EasyVista ont été nécessaires pour pouvoir modeler le besoin voulu pour qu’il corresponde avec la CMDB. Ces réunions m’ont permis de comprendre au mieux le fonctionnement de ce logiciel et ainsi d’y intégrer nos éléments de configuration (CI) le plus efficacement possible.

Après ces premières difficultés, le projet a été freiné lors de l’inventaire des caractéristiques des machines virtuelles (IP, rôle, zone, criticité, etc.) car de nombreuses VM ont été très difficiles à inventorier. Les membres de l’équipe « Infrastructure » n’étaient pas en mesure d’arriver à qualifier certaines informations, comme trouver l’utilité de certaines machines virtuelles pour arriver à qualifier leur criticité ou bien le groupe de sauvegarde auquel elles devraient être affectées. Pour réussir à définir ces informations dont l’équipe ne disposait pas, j’ai contacté différents services (Red Team, Blue Team, Soc, etc.). Ces difficultés ont permis de refléter le problème qui a poussé mon maître de stage Monsieur Julien CORNILLARD à initier le projet CMDB.

Après ces premières difficultés, le projet a été freiné lors de l’inventaire des caractéristiques des machines virtuelles (IP ; rôle ; zone ; criticité ; etc.) car de nombreuses VM ont été très difficiles à inventorier. Les membres de l’équipe infrastructure n’étaient pas en mesure d’arriver à qualifier certaines informations ; comme trouver l’utilité de certaines machines virtuelles pour arriver à qualifier leur criticité ou bien le groupe de sauvegarde auquel elles devraient être affectées. Pour réussir à définir ces informations dont l’équipe ne disposait pas, j’ai contacté différents services (Red Team, Blue Team, Soc, etc). Ces difficultés ont permis de refléter le problème qui a poussé mon maître de stage Monsieur Julien CORNILLARD à initier le projet CMDB.

J’ai également rencontré des difficultés dans la configuration de la gestion des dépendances dans le logiciel EasyVista. Ces liens de dépendance que nous pouvons créer entre les différentes CI permettent notamment de simuler les conséquences qu’engendrerait la coupure de service d’un CI. Le dashboard que génère EasyVista sur les CI de services de la CMDB ne fonctionnait pas exactement de la manière attendue. Ce problème concernait uniquement l’affichage des services VIP (services en redondance) en cas d’indisponibilité d’une CI de Service. Dans le contexte d’un cluster, si l’une des deux CI de service venait à ne plus être disponible suite à un incident sur la machine virtuelle rattachée à ce même service, le service VIP ne devrait pas être impacté, car il y a justement une redondance permettant d’éviter l’interruption de la production en cas de panne. Dans ce contexte, l’affichage de ce tableau de bord du service VIP était défini comme en accident. Ce problème d’affichage ne pouvait pas être corrigé par notre expert EasyVista, car cela serait allé à l’encontre des trois principes du projet (simplicité, évolutivité, pérennité). La réponse à cette problématique, aurait demandé le développement de tout un plugin qui aurait complexifié EasyVista et aurait rendu le logiciel plus instable. Cela aurait été coûteux en temps et en argent pour un gain minimal. Cette solution n’a donc pas été retenue. Mon responsable Monsieur Julien CORNILLARD m’a informé que nous allions passer outre ce problème d’affichage au vu de la conséquence mineure qu’engendrerait cette problématique.

La dernière problématique que j’ai rencontrée dans le cadre de l’intégration de la CMDB chez SEA TPI a été la sous-évaluation de la charge de travail qu’engendrerait la phase d’intégration des contrats dans la base de données. Durant la phase de préparation, nous avions quantifié avec mon responsable une dizaine de contrats à intégrer dans le CMDB, toutefois, après avoir multiplié les réunions avec différents acteurs de SEA TPI, j’en ai inventorié et répertorié 92. Cette augmentation soudaine de la charge de travail à réaliser m’a vraiment posé problème pour rendre le projet dans les temps.

8 – FIN DU PROJET ET PERSPECTIVES D’AVENIR

Le projet CMDB est actuellement en production chez SEA TPI. Les automatisations seront continuellement améliorées par l’équipe d’industrialisation en fonction des mises à jour des différents logiciels de l’entreprise. Certains scripts devront être modifiés et d’autres ajoutés pour permettre à la CMDB de suivre en temps réel l’état du parc applicatif et de ses changements (mise à jour d’un logiciel, suppression d’un logiciel et ajout d’un logiciel).

Dans la préparation de mon stage, M. CORNILLARD a souhaité que les deux premiers lots soient achevés avant la fin de mon stage et j’ai pu mener à bien cette mission. Pour permettre la continuité du projet après mon départ de l’entreprise, nous avons eu une réunion avec mon collègue Monsieur Nicolas MASARO qui allait me remplacer. Pour que le partage de compétences se déroule au mieux, j’avais rédigé un plan de réunion pour les deux rendez-vous prévus (d’une heure chacun). Lors de ces entretiens, je lui ai expliqué l’ensemble des enjeux impliqués et des méthodes utilisées. Je lui ai aussi montré des exemples concrets du fonctionnement des logiciels (principalement Nutanix et EasyVista).

Nous avons parcouru l’expression de besoins pour relire les besoins d’automatisation de chaque logiciel. Monsieur Nicolas MASARO m’a posé beaucoup de questions auxquelles j’ai pu répondre, et j’ai rédigé à son attention deux procédures afin d’y décrire les actions les plus courantes dans le cadre de la CMDB, sur les deux outils principaux (Nutanix et EasyVista).

La suite du projet a été confiée à Monsieur Nicolas MASARO qui a eu pour mission de préparer et d’examiner les besoins des lots N°3 et N°4.

9 – CE QUE JE RETIENS

Effectuer ces quatorze semaines de stage a été très formateur pour moi. Ce stage a été très riche en apport de connaissances et je garde un très bon souvenir de cette expérience en tant que membre d’une équipe MCO, car c’était mon premier stage dans une entreprise exclusivement concentrée sur le numérique.

Je me suis épanoui pendant ce projet qui a été le point central de mon stage. 

Ce stage a fait croître mes compétences techniques, mais aussi extra-techniques en gérant le projet CMDB, car pour cela, j’ai interagi avec les autres services de l’entreprise et conduit des réunions ce qui a développé mes compétences relationnelles et en communication. 

J’ai répondu aux attentes de SEA TPI de par les documentations que j’ai produites ainsi que par la rédaction et la livraison de l’expression du besoin pour le service industrialisation. 

Je suis très heureux d’avoir pu travailler sur un projet qui a permis à une entreprise de gagner en cohérence et en simplicité de gestion.

Le fait que le projet soit poursuivi par M. MASARO est très gratifiant pour moi, car cela témoigne d’un réel intérêt de l’entreprise à assurer la continuité du travail que j’ai effectué.