2010 - 2019

Ingenieur architecte systeme Linux — INPI - Institut national de la propriete industrielle (~800 agents)

Courbevoie / Becon-les-Bruyeres



--- Apres Sungard - arrivee a l'INPI ---

Apres l'experience chez Sungard, integration de l'INPI - environ neuf ans sur la duree, experience tres riche. A l'arrivee : pas encore de virtualisation ni de conteneurs au sens ou on les pratique aujourd'hui ; les services etaient encore massivement installes sur machines dediees (approche " bare metal "). Linux n'etait pas encore majoritaire sur l'ensemble du parc : beaucoup de Windows et d'Unix proprietaires (HP-UX, AIX, Solaris). Les annees suivantes ont largement fait evoluer le paysage (virtualisation, Linux, automatisation - voir ci-dessous).



--- Referent technique - Linux, VMware et virtualisation ---

A l' INPI , j'ai accompagne en tant que referent technique toutes les installations logicielles sous Linux . J'etais aussi referent technique sur l'ensemble du perimetre VMware et, plus largement, de la virtualisation . C'est moi qui ai installe cette virtualisation a l'INPI : VMware vSphere de la 4.0 a la 6.0 , puis oVirt ( oVirt ), et plus tard les premiers environnements Kubernetes (" nuage " conteneurise) avec RancherOS comme socle pour monter ces clusters. J'ai aussi realise les premiers masters Linux de l'INPI (images / installateurs de reference pour deployer le socle), ainsi que les premiers referentiels de securite Linux (durcissement, regles et bonnes pratiques d'exploitation). Chaque fois qu'un projet devait etre installe sous Linux , j' accompagnais systematiquement le chef de projet (cadrage, deploiement, exploitation).



--- Normalisation du parc Linux et gestion de l'obsolescence (RHEL, SUSE) ---

A mon arrivee, le systeme d'information comportait de nombreuses distributions Linux differentes, aux cotes de plusieurs Unix . A l'INPI , j'ai pilote la gestion de l' obsolescence du parc Linux : recuperation des anciennes installations et report sur des plateformes a niveau - en faisant evoluer des socles tres anciens (par ex. RHEL 3 ) vers des versions supportables ( RHEL 5 , puis RHEL 7 selon les trajectoires). Au terme de la normalisation, le parc entreprise ne reposait plus que sur des installations SUSE Linux Enterprise Server : SUSE Linux Enterprise Server - une reussite notable au vu de l'heterogeneite de depart. Nous avons remplace l'ensemble des machines Unix par des systemes Linux et migre les applications d' Unix vers Linux , afin de ne conserver sur Unix que les bases de donnees Oracle .



--- Projet EPTOS - equipe eptosadmin (run, integration & architecture) ---

Premiere mission : integration de l'equipe eptosadmin du projet EPTOS ( European Patent and Trademark Office System ) - la suite logicielle de gestion portee par l' Office europeen des brevets (OEB / EPO) pour les offices membres. L'equipe ne se limitait pas au run et a la production : nous etions aussi responsables de l' integration et de l' architecture - en resume tout le volet technique , y compris l' infrastructure : installation des serveurs sous Linux , montage en baie en salle informatique, administration de la baie SAN , cablage et raccordement reseau , etc. Pour une synthese academique du programme EPTOS comme transfert de systeme de gestion des brevets depuis l'OEB : Marcuzzo Cavalheiro & Joia (2016), Public Administration & Development , DOI 10.1002/pad.1753 (etude de cas sur un office national en cooperation avec l'EPO ; meme famille de programme que les deploiements EPTOS). La suite reposait sur quatre applicatifs majeurs : Soprano (back-office ; tierce maintenance assuree notamment par Jouve , groupe rebaptise Luminess ), e-OLF (depot en ligne), PHOENIX (gestion documentaire), et Register (registre). Developpements en Java , servis via Tomcat , avec base de donnees MySQL ; le tout opere sous Linux . Les premieres mises en production etaient exclusivement en bare metal : la virtualisation n'etait pas encore deployee sur le site. A l'arrivee de VMware ( vSphere 4 ), nous avons ete parmi les premiers a migrer vers la virtualisation et a realiser les premieres conversions . Tout n'etait pas encore abouti : en debut de courbe, les outils de conversion P2V ne fonctionnaient pas pour tous les cas - il a fallu recourir a la creation d'images disque brutes (copie depuis la machine physique) pour les reintegrer en machine virtuelle lorsque la conversion standard echouait. Puis generalisation des pratiques (vSphere 5.x, etc.). Au depart, la virtualisation ciblait d'abord le perimetre EPTOS . Pour l' etendre a l'ensemble du systeme d'information , c'est notre equipe qui a porte le chantier : nous avions le plus d' experience sur la virtualisation. Plus precisement, EPTOS disposait d'une infrastructure dediee : sauvegardes, bases de donnees et switchs propres au perimetre - fonctionnement autonome par rapport au reste du SI. Vers la fin du projet, decision de converger avec l'infrastructure centrale pour les fonctions transverses, notamment supervision et sauvegarde . L'effort de normalisation realise dans le cadre d'EPTOS a ensuite ete reinvesti pour l'



--- SUSE Linux Enterprise - migrations SLES 9 → 11 (EPTOS) ---

A l' INPI , nous avons gere les migrations de SLES 9 vers SLES 11 ( SUSE Linux Enterprise Server ) au fil de l'eau pour le perimetre EPTOS - planification des montees de version progressivement , sans tout basculer d'un seul coup.



--- Parcours d'equipe - production brevets, fusion Linux/Unix, diffusion EPTOS ---

D'abord rattache uniquement a une equipe dediee a la production du systeme d'information brevets , j'ai ensuite rejoint le reste de l'equipe systeme Linux / Unix (elargissement de mon perimetre). J'y ai reinvesti dans l' ensemble du SI les briques nouvelles mises en place pour le projet EPTOS (socles, outillages, pratiques de normalisation).



--- Salle serveurs - baies, KVM Raritan IP, volumes, cablage ---

Nous montions nous-memes en baie les machines et gerions l'exploitation des serveurs en salle serveur - notamment KVM over IP Raritan ( Raritan , consoles distantes), mises a jour de firmwares , creation de volumes disque cote serveurs / stockage, raccordements electriques et reseau , etc.



--- Disponibilite du depot - e-OLF, confidentialite et mises en production ---

L' INPI est un organisme de depot : le service de depot doit fonctionner en permanence . J'avais la responsabilite du volet depot des brevets , notamment e-OLF (depot en ligne - perimetre EPTOS), et la mise en place ainsi que l' exploitation de l' environnement securise pour les donnees soumises au secret jusqu'a leur publication eventuelle. Les mises en production etaient donc minutieusement preparees pour garder un temps de coupure aussi court que possible .



--- Physique vers virtuel (P2V) - VMware Converter, dd, methodes artisanales ---

Passer d'une installation sur machine physique a une installation sur machine virtuelle n'a pas ete de tout repos . La voie " standard " etait VMware Converter (conversion P2V), mais il existait des cas ou l'outil ne suffisait pas. Il a alors fallu creer des images disque brutes ( raw ) avec dd (copie secteur a secteur), puis parfois des chemins artisanaux : transfert par archives compressees et decompression sur la cible, reimport et ajustements manuels dans VMware lorsque la chaine Converter / import direct echouait.



--- Ordonnancement des flux (Dollar Universe) ---

Les volumes de donnees etaient importants : les sauvegardes constituaient un sujet critique - d'ou la necessite d'une fenetre de sauvegarde bien organisee - typiquement en fenetre de nuit / heures creuses, avec planification fine des plages rigoureusement orchestree avec Dollar Universe : Broadcom - Dollar Universe (workload automation). Les traitements automatises presentaient encore beaucoup d'erreurs : j'ai du tout corriger et fiabiliser l'ensemble des scripts shell et Python qui les supportaient.



--- MySQL - maintenance, sauvegardes et restaurations ---

Il a ete necessaire de disposer d'un savoir-faire solide sur la maintenance des bases MySQL : en particulier la capacite a sauvegarder correctement des bases importantes (volumetrie, criticite metier), et surtout a pouvoir les restaurer de maniere fiable en exploitation. A l' INPI , nous avons beaucoup etudie des sujets avances dans le MCO MySQL : haute disponibilite , performance , securite et sauvegarde . Historiquement , le parc incluait aussi des bases MaxDB en complement de MySQL : MaxDB (moteur SAP, heritage de l'ecosysteme applicatif de l'epoque).



--- Evolution SI - SQL actif-actif (Galera, ProxySQL) et stockage (S3, Ceph) ---

Plus tard dans l' evolution du systeme d'information , pour des architectures plus solides et plus performantes , nous avons etudie la mise en place de SQL actif-actif : notamment des clusters MySQL Galera avec ProxySQL en couche d'acces : ProxySQL . Nous avons aussi etudie les futures solutions de stockage : stockage objet expose via le protocole S3 , et installation de clusters Ceph .



--- Conteneurs et orchestration (Docker, Kubernetes, Rancher) ---

Nous avons evidemment commence a migrer et a deployer des applications sous conteneurs avec Docker , et a etudier l' orchestration avec Kubernetes ; la premiere approche est passee par Rancher : Rancher .



--- Integration continue - Jenkins, Git, Ansible ---

Nous avons aussi mis en place des solutions d'integration continue - ou du moins les socles pour les porter : installation de Jenkins ( Jenkins ) branche sur Git , et les premiers playbooks Ansible .



--- Automatisation et industrialisation (Go, JavaScript, React) ---

Sur les volets automatisation et industrialisation , j'ai realise des developpements en Go , en JavaScript et avec le framework React : React .



--- Supervision et alertes sur les journaux (Nagios, Centreon, Prometheus / Grafana, Graylog, Elastic) ---

Le socle de supervision etait d'abord Nagios . Nous avons ensuite migre vers Centreon , puis, plus tard, vers une stack Prometheus et Grafana - en complement de Centreon (cohabitation et perimetres selon les besoins). Nous avons aussi explore les alertes basees sur les logs avec Graylog : Graylog - gestion centralisee des journaux et correlation pour l'exploitation. La creation de tableaux de bord avec Grafana a permis de completer les tableaux de bord techniques par un tableau de bord technico-fonctionnel de production . A l' INPI , nous avons aussi utilise l'ecosysteme Elastic autour d' Elasticsearch pour centraliser les logs applicatifs , avec Logstash (pipelines) et les modules Filebeat pour la collecte : Elastic Stack .



--- Agents et metrologie Java - Tomcat, JMX ---

Au niveau des agents et de l'exposition des metriques applicatives : une grande partie du parc etait en Java servie par Apache Tomcat (dont Tomcat 4 sur une partie du perimetre a l'epoque). Nous avons utilise le protocole JMX ( Java Management Extensions ) pour superviser et instrumenter les JVM et les composants serveur : Oracle - tutoriel JMX .



--- Proactivite - jobs de verification Selenium (production) ---

Pour renforcer la proactivite sur la resolution d'incidents , nous avons mis en place des jobs de verification avec Selenium : Selenium , afin de tester automatiquement les services en production (parcours critiques / controles de bout en bout).



--- Securite - Cyberwatch ---

A l'INPI , dans le cadre du CODIR informatique , j'ai lance le projet d'installation de Cyberwatch pour ameliorer la securite des installations Linux : gestion des vulnerabilites et controle de conformite sur le systeme d'information. L'etablissement a ete parmi les premiers a deployer la plateforme. J'ai accompagne ce deploiement pour la conformite vis-a-vis des referentiels de securite (cartographie des exigences, preuves et suivi des ecarts).



--- Infrastructure, salles informatiques et PRI / PRA (VMware Site Recovery) ---

Au niveau de l' infrastructure , nous avons migre de salles informatiques a trois reprises pour toute la production . Apres ces chantiers, la securite et la continuite d'exploitation se sont largement appuyees sur la virtualisation VMware , en particulier sur la capacite a deplacer ou repliquer les machines virtuelles d'un datacenter a un autre via VMware Site Recovery Manager : VMware - Site Recovery Manager (PRA / replication inter-sites). C'est moi qui ai mis en place le dispositif de plan de reprise informatique ( PRI ) et le volet PRA associe, avec VMware Site Recovery Manager : mise a jour du tableau de production (inventaire et criticite), definition de l' ordre d'importance des systemes pour les bascules, et arbitrage sur ce qui devait etre integre pleinement au PRA (replication, orchestration avec Site Recovery) ou laisse hors perimetre .



--- SAN - hotes physiques et acces (iSCSI, Fibre Channel, NFS) ---

A l' INPI , j'ai du piloter le lien entre les hotes physiques et le SAN . Plusieurs technologies ont ete mises en oeuvre : iSCSI sur cable Ethernet , Fibre Channel , et NFS pour les usages adaptes au partage de fichiers sur le reseau. J'ai aussi eu l'occasion d'exploiter des SAN HP , notamment des baies HP 3PAR : HPE 3PAR . Pour le plan de reprise informatique ( PRI ) avec VMware Site Recovery Manager , il etait indispensable que le stockage soit compatible avec la replication et l'orchestration inter-sites VMware.



---  ---

MCO de larges parcs Linux (+500 VMs en phase mature) : CentOS, Red Hat, SUSE ; supervision : evolution Nagios → Centreon → Prometheus/Grafana (avec Centreon en complement) ; alerting logs (Graylog, Elasticsearch / Logstash / Filebeat) ; integration Apache, Tomcat, PHP, MySQL/Galera, MaxDB, Oracle ; Dollar Universe ; automatisation (bash, Python, Go, Java, PHP, Selenium, AutoIt, Node, React) ; stockage NFS, SAN HP 3PAR, Ceph, NetApp, Samba ; support niveau 2.



--- Projets ---

Virtualisation VMware vSphere 5.5, PRA (VMware Site Recovery Manager, replication inter-datacenters), evolution stockage (Ceph, Cassandra, S3), Puppet et Ansible, reflexion cloud / conteneurs / OpenStack, trois migrations de salles informatiques pour la production.



--- Synthese du perimetre - Linux, mise en production, scripts ---

Mon travail a l' INPI m'a permis d'intervenir sur un large perimetre : installation et maintenance des machines physiques ; hebergement via la virtualisation ; infrastructure de stockage ; puis installation et MCO des services en production - complete par les choix et evolutions du socle Linux , les mises en production , les retours arriere et les scripts d'exploitation pour le run (dans un SI ou Unix et autres environnements coexistaient encore). Sur la chronologie , nous avions deja reussi l'ensemble de l' automatisation et de la normalisation du perimetre avant l'arrivee d' Ansible et de Puppet , qui sont venus ensuite completer le dispositif. Mon experience a l' INPI m'a permis de consolider une experience validee et profonde de la production informatique sur des environnements critiques . J'y ai porte une attention particuliere aux bonnes pratiques pour conduire les mises en production : preparation poussee et plans de retour arriere systematiques.



--- Contexte (chronologie) ---

Agence publique, DSI ~40 agents, +500 postes Windows. Production applicative Java/PHP, Apache, MySQL ; administration SUSE, Red Hat ; +20 hotes ESX (HP DL560) ; Dollar Universe, scripts Bash/Python ; 3 baies SAN HP 3PAR (~180 To) ; deux salles (production et developpement). Assistance aux projets technico-fonctionnels, migration vers VMware, PRA, normalisation de l'infrastructure.

