Olivier Guandalini
ProjectsExperienceContact

Experience · 4 years in production

What I run in production

DevOps and SRE engineer at a software publisher, in the in-house infrastructure team. I run more than 400 on-prem Linux servers, and since 2026 I have been contributing to the company's Kubernetes platform: creating its clusters on vSphere, as code, and deploying their components through GitOps.

At work

Problems solved

Each time: the problem, what I did, and what it changed.

Hover or tap a tool to see what it is.

  1. Kubernetes clusters in 15 minutes

    • TerraformInfrastructure as codeDescribes infrastructure as code: a plan shows what will change before anything is created or destroyed.
    • RancherOrchestrationManages Kubernetes clusters from one place: creates them, upgrades them, and controls who reaches them.
    • vSphereVirtualizationThe virtualization platform of VMware: virtual machines on a cluster of physical servers, managed from vCenter.
    • KubernetesOrchestrationRuns containers across a group of machines, restarts them when they fail, and spreads the traffic between them.
    • Argo CDGitOpsKeeps the cluster in line with what git describes: to change the platform, you change the repository, not the cluster.
    Show the detailsHide the details
    The problem
    On vSphere, a cluster went through servers prepared on their own, then registered one by one in Rancher.
    What I did
    I added a native method to the team's Terraform project. Rancher drives vCenter: it clones the VM templates, creates the node pools (roles, labels, taints, storage nodes) and runs the rolling updates. A cluster's whole topology fits in one variables file. That is how I created the cluster of the software factory, and I deploy the components of every cluster through GitOps: Envoy Gateway, External Secrets wired to Vault, kube-prometheus-stack, Longhorn, Datadog.
    The result
    A new cluster in 10 to 15 minutes with make apply, documented for the team: the architecture, how it works, and a step-by-step tutorial.
  2. A Java repository about to shut down

    • AnsibleInfrastructure as codeConfigures servers from code: playbooks and roles describe the state wanted, and Ansible brings every machine to it, over SSH.
    • Eclipse TemurinRuntimeThe Java builds of the Eclipse Adoptium project: free, tested, and kept up to date with security fixes.
    • DebianOperating systemA Linux distribution known for its stability, under many servers and under Ubuntu.
    • CentOSOperating systemA Linux distribution of the Red Hat family, common on company servers.
    Show the detailsHide the details
    The problem
    The daily package update failed across the fleet: the JDK repository had been abandoned, 8 security updates behind, and its shutdown was scheduled. At the same time, the developers wanted to move to Java 21.
    What I did
    My first Ansible role: it installs Eclipse Temurin in the version a project asks for, JDK or JRE, on Debian and CentOS. Then the projects moved over, and the back-office applications went to Java 21.
    The result
    One role, used today by 16 projects, from Java 8 to Java 25.
  3. Knowing before the users do

    • PrometheusObservabilityCollects the metrics of every service over time, and evaluates the alerting rules on them.
    • GrafanaObservabilityDashboards over the metrics and the logs: what the platform is doing, at a glance.
    • DatadogObservabilityA hosted monitoring service: the metrics, logs, traces and SLOs of every machine, with alerts sent where the team works.
    • AnsibleInfrastructure as codeConfigures servers from code: playbooks and roles describe the state wanted, and Ansible brings every machine to it, over SSH.
    • JiraTrackingThe ticket tracker of the teams: incidents, requests and work, with their priority and their history.
    Show the detailsHide the details
    The problem
    Across more than 400 servers, an incident has to show before anyone reports it.
    What I did
    Monitoring as code: Prometheus and Alertmanager jobs and alerting rules, exporters rolled out to the whole fleet by Ansible, Grafana dashboards for the teams. SLOs and SLAs in Datadog, which alert in Slack and in Jira.
    The result
    Incidents are caught earlier, from the alert rather than from a report.
  4. Secrets out of the code

    • VaultSecretsThe secret store by HashiCorp: passwords, keys and certificates kept encrypted, with every access controlled and logged.
    • External SecretsSecretsCopies secrets from a store such as Vault or AWS Secrets Manager into Kubernetes, so that none is written in git.
    • KubernetesOrchestrationRuns containers across a group of machines, restarts them when they fail, and spreads the traffic between them.
    • AnsibleInfrastructure as codeConfigures servers from code: playbooks and roles describe the state wanted, and Ansible brings every machine to it, over SSH.
    Show the detailsHide the details
    The problem
    API gateway and database credentials, to keep out of the repositories, on the servers as in Kubernetes.
    What I did
    I set up HashiCorp Vault to keep them in one place, and External Secrets to hand them to the applications on Kubernetes. On the servers, the secrets of the Ansible projects are encrypted with Ansible Vault.
    The result
    Two mechanisms for one rule: no secret in clear text in a repository.
  5. Logs the developers read on their own

    • ELKObservabilityElasticsearch, Logstash and Kibana: the logs of every server gathered, indexed and searched in one place.
    • LogstashObservabilityReceives logs, cuts them into fields, and sends them on to be indexed.
    • KibanaObservabilityThe web interface of Elasticsearch: search the logs, build dashboards, follow an incident as it happens.
    Show the detailsHide the details
    The problem
    The developers have no access to the servers, yet they have to debug what runs there.
    What I did
    The application logs, gathered with ELK: Filebeat on the servers, a Logstash pipeline and an index mapping for each log format, Kibana to search them.
    The result
    The developers debug on their own, without asking for access.
  6. An AI assistant to take to production

    • PythonLanguageThe language of the APIs and scripts here, and of most of the AI ecosystem.
    • MistralAIA French provider of large language models, called through its API.
    • QdrantAIA vector database: it finds the passages closest in meaning to a question, the retrieval step of RAG.
    • LangfuseAIObservability for LLM applications: each request traced, with its prompts, its latency and its token cost.
    • MCPAIThe Model Context Protocol: a standard way for AI assistants to call tools and to read the data of other systems.
    • OpenTelemetryObservabilityThe open standard of telemetry: one way to emit traces, metrics and logs, whatever tool reads them.
    Show the detailsHide the details
    The problem
    A conversational assistant to take from code to production, with new needs: several LLM providers, a vector database, long-lived WebSocket connections.
    What I did
    Since 2025, its deployment: a Python API, several LLM providers (Mistral, Cohere), the Qdrant vector database and Langfuse to follow every request, all deployed by a two-phase Ansible pipeline with its secrets encrypted by Vault; an OpenResty gateway for the WebSockets (TLS, long-lived connections, CORS); an MCP server that opens data services to AI agents; and since September, traces and logs with OpenTelemetry, Tempo and Loki.
    The result
    A beta in production.
  7. Training the next ones

    • AnsibleInfrastructure as codeConfigures servers from code: playbooks and roles describe the state wanted, and Ansible brings every machine to it, over SSH.
    • PrometheusObservabilityCollects the metrics of every service over time, and evaluates the alerting rules on them.
    • ELKObservabilityElasticsearch, Logstash and Kibana: the logs of every server gathered, indexed and searched in one place.
    Show the detailsHide the details
    The problem
    Two DevOps apprentices to bring up to speed, on a critical production.
    What I did
    Mentoring them for two years: Ansible, Prometheus, the ELK stack and running a critical production.
    The result
    Both became autonomous.

Also

The tools, and where I use them

At work, in production

  • LinuxOperating systemThe operating system of almost every server: the ground everything else runs on.
  • DebianOperating systemA Linux distribution known for its stability, under many servers and under Ubuntu.
  • CentOSOperating systemA Linux distribution of the Red Hat family, common on company servers.
  • vSphereVirtualizationThe virtualization platform of VMware: virtual machines on a cluster of physical servers, managed from vCenter.
  • vCloud DirectorVirtualizationThe VMware layer for cloud providers: a hosted virtual data centre, with its own networks and machines.
  • AnsibleInfrastructure as codeConfigures servers from code: playbooks and roles describe the state wanted, and Ansible brings every machine to it, over SSH.
  • TerraformInfrastructure as codeDescribes infrastructure as code: a plan shows what will change before anything is created or destroyed.
  • Kubernetes (RKE2)OrchestrationKubernetes in RKE2, the distribution by Rancher: hardened for security, made for servers on-prem.
  • RancherOrchestrationManages Kubernetes clusters from one place: creates them, upgrades them, and controls who reaches them.
  • Argo CDGitOpsKeeps the cluster in line with what git describes: to change the platform, you change the repository, not the cluster.
  • HelmDeploymentThe package manager of Kubernetes: a chart turns values into manifests, installed and versioned as one release.
  • KustomizeDeploymentBuilds Kubernetes manifests from a shared base and small patches for each environment, with no templates.
  • DockerContainersPacks an application with all it needs into an image, which runs the same way on any machine.
  • JenkinsCI/CDAn automation server for CI: pipelines that build, test and deliver the code, configured as code.
  • RundeckCI/CDRuns operations jobs on demand or on a schedule, with access control and a log of every run.
  • GitLabCI/CDA git forge with its own CI: runners build, test and deploy on every push.
  • VaultSecretsThe secret store by HashiCorp: passwords, keys and certificates kept encrypted, with every access controlled and logged.
  • External SecretsSecretsCopies secrets from a store such as Vault or AWS Secrets Manager into Kubernetes, so that none is written in git.
  • Envoy GatewayTrafficThe way into the cluster, through the Gateway API: it routes HTTP and HTTPS traffic to the right service.
  • LonghornStorageDistributed storage for Kubernetes: volumes copied across the nodes, so that the data outlives the loss of one.
  • PrometheusObservabilityCollects the metrics of every service over time, and evaluates the alerting rules on them.
  • AlertmanagerObservabilityReceives the alerts Prometheus fires, groups them, silences them, and sends them to the right people.
  • GrafanaObservabilityDashboards over the metrics and the logs: what the platform is doing, at a glance.
  • DatadogObservabilityA hosted monitoring service: the metrics, logs, traces and SLOs of every machine, with alerts sent where the team works.
  • ELKObservabilityElasticsearch, Logstash and Kibana: the logs of every server gathered, indexed and searched in one place.
  • OpenSearchObservabilityAn open-source search and analytics engine, born from Elasticsearch, with dashboards and alerting.
  • OpenTelemetryObservabilityThe open standard of telemetry: one way to emit traces, metrics and logs, whatever tool reads them.
  • OpenRestyTrafficnginx with Lua inside: a web server and gateway whose behaviour can be programmed.
  • 3scaleTrafficThe API management of Red Hat: keys, quotas and statistics in front of an API, with a gateway that enforces them.
  • QdrantAIA vector database: it finds the passages closest in meaning to a question, the retrieval step of RAG.
  • LangfuseAIObservability for LLM applications: each request traced, with its prompts, its latency and its token cost.
  • OVHCloudA French cloud and hosting provider.
  • BashLanguageThe Unix shell, for the scripts that tie the tools together.
  • PythonLanguageThe language of the APIs and scripts here, and of most of the AI ecosystem.

In my projects, on my own time

  • AWS EKSCloudKubernetes managed by AWS: Amazon runs the control plane, the nodes run the workloads.
  • VPC, IAM, S3CloudThe basics of AWS: a private network (VPC), identities and permissions (IAM), and object storage (S3).
  • Secrets ManagerSecretsThe secret store of AWS: secrets kept encrypted, read by the applications through their IAM permissions.
  • k3dOrchestrationA whole Kubernetes cluster in Docker containers, on a laptop: the same platform locally, for free.
  • cert-managerSecurityIssues TLS certificates inside Kubernetes, and renews them before they expire.
  • SlothObservabilityTurns an SLO written in a few lines into the Prometheus rules and burn-rate alerts it needs.
  • GitHub ActionsCI/CDThe CI of GitHub: on every pull request, it runs the checks, builds and scans what ships, and deploys it.
  • TrivySecurityA security scanner: it finds the known vulnerabilities in images, packages and configuration.

Path

  1. Since 2023

    DevOps and SRE engineer

    A software publisher, in-house infrastructure team. An apprentice first, permanent since October 2024.

  2. 2022 to 2023

    DevOps engineer, apprentice

    An adtech SME: applications moved to Docker and Kubernetes, a first Prometheus and Grafana monitoring.

  3. 2021 to 2022

    Automation engineer, apprentice

    The energy branch of a large construction group: the electrical distribution of a metro line's structures.

Education

  1. 2022 to 2024

    MSc-level degree in DevOps and Cloud, Sup de Vinci

    Thesis: monitoring and diagnosing problems in real time, to resolve incidents fast.

  2. 2021 to 2022

    Professional bachelor's degree in industrial IT, IUT de Ville-d'Avray

    Industrial computing, automation and production.

  3. 2019 to 2021

    Two-year degree in electrical engineering and industrial IT, IUT de Ville-d'Avray

    A French technical degree, the DUT GEII.

LanguagesFrench, native. English, professional and technical.

And on my own time

The public projects on this site take the same subjects end to end, on AWS and on a laptop: cloned in minutes, documented, checked on every change.