Olivier Guandalini
ProjetsExpérienceContact

Expérience · 4 ans en production

Ce que je fais tourner en production

Ingénieur DevOps et SRE chez un éditeur de logiciels, dans l'équipe infrastructure interne. Je fais tourner plus de 400 serveurs Linux on-prem, et je contribue depuis 2026 à la plateforme Kubernetes de l'entreprise : la création de ses clusters sur vSphere, en code, et le déploiement de leurs composants en GitOps.

Au travail

Problèmes résolus

Chaque fois : le problème, ce que j'ai fait, et ce que ça a changé.

Survolez ou touchez un outil pour voir ce que c'est.

  1. Des clusters Kubernetes en 15 minutes

    • TerraformInfrastructure en codeDécrit l'infrastructure en code : un plan montre ce qui va changer avant de créer ou de détruire quoi que ce soit.
    • RancherOrchestrationGère les clusters Kubernetes depuis un seul endroit : les crée, les met à jour et contrôle qui y accède.
    • vSphereVirtualisationLa plateforme de virtualisation de VMware : des machines virtuelles sur un cluster de serveurs physiques, gérées depuis vCenter.
    • KubernetesOrchestrationFait tourner des conteneurs sur un groupe de machines, les relance quand ils tombent et répartit le trafic entre eux.
    • Argo CDGitOpsMaintient le cluster conforme à ce que décrit git : pour changer la plateforme, on change le dépôt, pas le cluster.
    Voir le détailMasquer le détail
    Le problème
    Sur vSphere, un cluster passait par des serveurs préparés à part, puis inscrits un à un dans Rancher.
    Ce que j'ai fait
    J'ai ajouté au projet Terraform de l'équipe une méthode native. Rancher pilote vCenter : il clone les modèles de VM, crée les pools de nœuds (rôles, labels, taints, nœuds de stockage) et gère les mises à jour progressives. Toute la topologie d'un cluster tient dans un fichier de variables. C'est ainsi que j'ai créé le cluster de l'usine logicielle, et je déploie en GitOps les composants de chaque cluster : Envoy Gateway, External Secrets branché sur Vault, kube-prometheus-stack, Longhorn, Datadog.
    Le résultat
    Un nouveau cluster en 10 à 15 minutes avec make apply, documenté pour l'équipe : l'architecture, le fonctionnement et un tutoriel pas à pas.

  2. Un dépôt Java sur le point de fermer

    • AnsibleInfrastructure en codeConfigure les serveurs à partir du code : playbooks et rôles décrivent l'état voulu, et Ansible y amène chaque machine, par SSH.
    • Eclipse TemurinEnvironnement d'exécutionLes builds Java du projet Eclipse Adoptium : gratuits, testés et tenus à jour des correctifs de sécurité.
    • DebianSystème d'exploitationUne distribution Linux réputée pour sa stabilité, sous de nombreux serveurs et sous Ubuntu.
    • CentOSSystème d'exploitationUne distribution Linux de la famille Red Hat, courante sur les serveurs d'entreprise.
    Voir le détailMasquer le détail
    Le problème
    La mise à jour quotidienne des paquets échouait sur le parc : le dépôt des JDK était abandonné, avec 8 mises à jour de sécurité de retard, et sa fermeture était programmée. Les développeurs voulaient en même temps passer en Java 21.
    Ce que j'ai fait
    Mon premier rôle Ansible : il installe Eclipse Temurin dans la version demandée, en JDK ou en JRE, sur Debian et CentOS. Puis la migration des projets, avec les applications back-office passées en Java 21.
    Le résultat
    Un seul rôle, utilisé aujourd'hui par 16 projets, de Java 8 à Java 25.

  3. Savoir avant les utilisateurs

    • PrometheusObservabilitéCollecte les métriques de chaque service dans le temps, et évalue dessus les règles d'alerte.
    • GrafanaObservabilitéDes tableaux de bord sur les métriques et les logs : ce que fait la plateforme, d'un coup d'œil.
    • DatadogObservabilitéUn service de monitoring hébergé : les métriques, logs, traces et SLO de chaque machine, avec des alertes là où l'équipe travaille.
    • AnsibleInfrastructure en codeConfigure les serveurs à partir du code : playbooks et rôles décrivent l'état voulu, et Ansible y amène chaque machine, par SSH.
    • JiraSuiviLe suivi de tickets des équipes : incidents, demandes et travaux, avec leur priorité et leur historique.
    Voir le détailMasquer le détail
    Le problème
    Sur plus de 400 serveurs, un incident doit se voir avant d'être signalé.
    Ce que j'ai fait
    Le monitoring en code : les jobs et règles d'alerte Prometheus et Alertmanager, les exporters déployés sur tout le parc par Ansible, des tableaux de bord Grafana pour les équipes. Des SLO et SLA dans Datadog, qui alertent sur Slack et dans Jira.
    Le résultat
    Les incidents sont détectés plus tôt, par l'alerte plutôt que par un signalement.

  4. Des secrets hors du code

    • VaultSecretsLe coffre à secrets de HashiCorp : mots de passe, clés et certificats gardés chiffrés, chaque accès contrôlé et tracé.
    • External SecretsSecretsRecopie les secrets d'un coffre comme Vault ou AWS Secrets Manager dans Kubernetes : aucun n'est écrit dans git.
    • KubernetesOrchestrationFait tourner des conteneurs sur un groupe de machines, les relance quand ils tombent et répartit le trafic entre eux.
    • AnsibleInfrastructure en codeConfigure les serveurs à partir du code : playbooks et rôles décrivent l'état voulu, et Ansible y amène chaque machine, par SSH.
    Voir le détailMasquer le détail
    Le problème
    Des identifiants de gateway d'API et de bases de données, à garder hors des dépôts, sur les serveurs comme dans Kubernetes.
    Ce que j'ai fait
    J'ai mis en place HashiCorp Vault pour les centraliser, et External Secrets pour les livrer aux applications sur Kubernetes. Sur les serveurs, les secrets des projets Ansible sont chiffrés avec Ansible Vault.
    Le résultat
    Deux mécanismes pour une seule règle : aucun secret en clair dans un dépôt.

  5. Des logs que les développeurs lisent seuls

    • ELKObservabilitéElasticsearch, Logstash et Kibana : les logs de chaque serveur collectés, indexés et cherchés au même endroit.
    • LogstashObservabilitéReçoit les logs, les découpe en champs, et les envoie à l'indexation.
    • KibanaObservabilitéL'interface web d'Elasticsearch : chercher dans les logs, construire des tableaux de bord, suivre un incident en direct.
    Voir le détailMasquer le détail
    Le problème
    Les développeurs n'ont pas accès aux serveurs, et doivent pourtant déboguer ce qui y tourne.
    Ce que j'ai fait
    Les logs applicatifs centralisés avec ELK : Filebeat sur les serveurs, un pipeline Logstash et un mapping par format de log, Kibana pour les chercher.
    Le résultat
    Les développeurs déboguent en autonomie, sans demander d'accès.

  6. Un assistant IA à mettre en production

    • PythonLangageLe langage des API et des scripts ici, et de l'essentiel de l'écosystème IA.
    • MistralIAUn fournisseur français de grands modèles de langage, appelé par son API.
    • QdrantIAUne base de données vectorielle : elle retrouve les passages les plus proches du sens d'une question, l'étape de recherche du RAG.
    • LangfuseIAL'observabilité des applications LLM : chaque requête tracée, avec ses prompts, sa latence et son coût en tokens.
    • MCPIALe Model Context Protocol : une façon standard pour les assistants IA d'appeler des outils et de lire les données d'autres systèmes.
    • OpenTelemetryObservabilitéLe standard ouvert de la télémétrie : une seule façon d'émettre traces, métriques et logs, quel que soit l'outil qui les lit.
    Voir le détailMasquer le détail
    Le problème
    Un assistant conversationnel à faire passer du code à la production, avec des besoins nouveaux : plusieurs fournisseurs de LLM, une base vectorielle, des connexions WebSocket longues.
    Ce que j'ai fait
    Depuis 2025, son déploiement : une API Python, plusieurs fournisseurs de LLM (Mistral, Cohere), la base vectorielle Qdrant et Langfuse pour suivre chaque requête, le tout déployé par un pipeline Ansible en deux phases, avec les secrets chiffrés par Vault ; une gateway OpenResty pour les WebSockets (TLS, connexions longues, CORS) ; un serveur MCP qui ouvre des services de données aux agents IA ; et depuis septembre, les traces et les logs avec OpenTelemetry, Tempo et Loki.
    Le résultat
    Une bêta en production.

  7. Former les suivants

    • AnsibleInfrastructure en codeConfigure les serveurs à partir du code : playbooks et rôles décrivent l'état voulu, et Ansible y amène chaque machine, par SSH.
    • PrometheusObservabilitéCollecte les métriques de chaque service dans le temps, et évalue dessus les règles d'alerte.
    • ELKObservabilitéElasticsearch, Logstash et Kibana : les logs de chaque serveur collectés, indexés et cherchés au même endroit.
    Voir le détailMasquer le détail
    Le problème
    Deux alternants DevOps à faire monter en compétence, sur une production critique.
    Ce que j'ai fait
    Leur tutorat pendant deux ans : Ansible, Prometheus, la suite ELK et la gestion de la production critique.
    Le résultat
    Tous deux sont devenus autonomes.

Aussi

Les outils, et où je les utilise

Au travail, en production

  • LinuxSystème d'exploitationLe système d'exploitation de presque tous les serveurs : le socle sur lequel tout le reste tourne.
  • DebianSystème d'exploitationUne distribution Linux réputée pour sa stabilité, sous de nombreux serveurs et sous Ubuntu.
  • CentOSSystème d'exploitationUne distribution Linux de la famille Red Hat, courante sur les serveurs d'entreprise.
  • vSphereVirtualisationLa plateforme de virtualisation de VMware : des machines virtuelles sur un cluster de serveurs physiques, gérées depuis vCenter.
  • vCloud DirectorVirtualisationLa couche de VMware pour les fournisseurs de cloud : un datacenter virtuel hébergé, avec ses propres réseaux et machines.
  • AnsibleInfrastructure en codeConfigure les serveurs à partir du code : playbooks et rôles décrivent l'état voulu, et Ansible y amène chaque machine, par SSH.
  • TerraformInfrastructure en codeDécrit l'infrastructure en code : un plan montre ce qui va changer avant de créer ou de détruire quoi que ce soit.
  • Kubernetes (RKE2)OrchestrationKubernetes dans RKE2, la distribution de Rancher : durcie pour la sécurité, faite pour les serveurs on-prem.
  • RancherOrchestrationGère les clusters Kubernetes depuis un seul endroit : les crée, les met à jour et contrôle qui y accède.
  • Argo CDGitOpsMaintient le cluster conforme à ce que décrit git : pour changer la plateforme, on change le dépôt, pas le cluster.
  • HelmDéploiementLe gestionnaire de paquets de Kubernetes : un chart transforme des valeurs en manifestes, installés et versionnés comme une release.
  • KustomizeDéploiementConstruit les manifestes Kubernetes à partir d'une base commune et de petits correctifs par environnement, sans templates.
  • DockerConteneursEmballe une application avec tout ce qu'il lui faut dans une image, qui tourne de la même façon sur n'importe quelle machine.
  • JenkinsCI/CDUn serveur d'automatisation pour la CI : des pipelines qui construisent, testent et livrent le code, configurés en code.
  • RundeckCI/CDLance des jobs d'exploitation à la demande ou planifiés, avec un contrôle d'accès et le journal de chaque exécution.
  • GitLabCI/CDUne forge git avec sa propre CI : des runners construisent, testent et déploient à chaque push.
  • VaultSecretsLe coffre à secrets de HashiCorp : mots de passe, clés et certificats gardés chiffrés, chaque accès contrôlé et tracé.
  • External SecretsSecretsRecopie les secrets d'un coffre comme Vault ou AWS Secrets Manager dans Kubernetes : aucun n'est écrit dans git.
  • Envoy GatewayTraficLa porte d'entrée du cluster, avec la Gateway API : elle route le trafic HTTP et HTTPS vers le bon service.
  • LonghornStockageDu stockage distribué pour Kubernetes : des volumes copiés sur plusieurs nœuds, pour que les données survivent à la perte de l'un d'eux.
  • PrometheusObservabilitéCollecte les métriques de chaque service dans le temps, et évalue dessus les règles d'alerte.
  • AlertmanagerObservabilitéReçoit les alertes de Prometheus, les regroupe, les met en silence et les envoie aux bonnes personnes.
  • GrafanaObservabilitéDes tableaux de bord sur les métriques et les logs : ce que fait la plateforme, d'un coup d'œil.
  • DatadogObservabilitéUn service de monitoring hébergé : les métriques, logs, traces et SLO de chaque machine, avec des alertes là où l'équipe travaille.
  • ELKObservabilitéElasticsearch, Logstash et Kibana : les logs de chaque serveur collectés, indexés et cherchés au même endroit.
  • OpenSearchObservabilitéUn moteur de recherche et d'analyse open source, né d'Elasticsearch, avec tableaux de bord et alertes.
  • OpenTelemetryObservabilitéLe standard ouvert de la télémétrie : une seule façon d'émettre traces, métriques et logs, quel que soit l'outil qui les lit.
  • OpenRestyTraficnginx avec Lua à l'intérieur : un serveur web et une gateway dont on peut programmer le comportement.
  • 3scaleTraficLa gestion d'API de Red Hat : clés, quotas et statistiques devant une API, avec une gateway qui les fait respecter.
  • QdrantIAUne base de données vectorielle : elle retrouve les passages les plus proches du sens d'une question, l'étape de recherche du RAG.
  • LangfuseIAL'observabilité des applications LLM : chaque requête tracée, avec ses prompts, sa latence et son coût en tokens.
  • OVHCloudUn hébergeur et fournisseur de cloud français.
  • BashLangageLe shell Unix, pour les scripts qui relient les outils entre eux.
  • PythonLangageLe langage des API et des scripts ici, et de l'essentiel de l'écosystème IA.

Dans mes projets, sur mon temps libre

  • AWS EKSCloudKubernetes géré par AWS : Amazon fait tourner le plan de contrôle, les nœuds font tourner les applications.
  • VPC, IAM, S3CloudLes bases d'AWS : un réseau privé (VPC), les identités et les droits (IAM), et le stockage d'objets (S3).
  • Secrets ManagerSecretsLe coffre à secrets d'AWS : des secrets gardés chiffrés, lus par les applications grâce à leurs droits IAM.
  • k3dOrchestrationUn cluster Kubernetes complet dans des conteneurs Docker, sur un portable : la même plateforme en local, gratuitement.
  • cert-managerSécuritéDélivre les certificats TLS dans Kubernetes, et les renouvelle avant qu'ils n'expirent.
  • SlothObservabilitéTransforme un SLO écrit en quelques lignes en règles Prometheus et en alertes de burn rate.
  • GitHub ActionsCI/CDLa CI de GitHub : à chaque pull request, elle lance les vérifications, construit et scanne ce qui part, et le déploie.
  • TrivySécuritéUn scanner de sécurité : il trouve les vulnérabilités connues dans les images, les paquets et la configuration.

Parcours

  1. Depuis 2023

    Ingénieur DevOps et SRE

    Un éditeur de logiciels, équipe infrastructure interne. D'abord en alternance, en CDI depuis octobre 2024.

  2. 2022 à 2023

    Ingénieur DevOps en alternance

    Une PME de l'adtech : des applications passées sur Docker et Kubernetes, un premier monitoring Prometheus et Grafana.

  3. 2021 à 2022

    Automaticien en alternance

    La branche énergie d'un grand groupe du BTP : la distribution électrique des ouvrages d'une ligne de métro.

Formation

  1. 2022 à 2024

    Mastère DevOps & Cloud, Sup de Vinci

    Mémoire : surveiller et diagnostiquer les problèmes en temps réel, pour résoudre vite les incidents.

  2. 2021 à 2022

    Licence professionnelle I2AP, IUT de Ville-d'Avray

    Informatique industrielle, automatisme et productique.

  3. 2019 à 2021

    DUT GEII, IUT de Ville-d'Avray

    Génie électrique et informatique industrielle.

LanguesFrançais, langue maternelle. Anglais, professionnel et technique.

Et sur mon temps libre

Les projets publics de ce site reprennent ces sujets de bout en bout, sur AWS et sur un portable : clonés en quelques minutes, documentés, vérifiés à chaque changement.

Voir les projetsFaire la visite guidée