CONSULTANT · OBSERVABILITÉ · SRE · PLATEFORME

Une plateforme fiable. Des services transparents.

Du cloud au bare metal, j’aide les équipes à améliorer la stabilité de leurs plateformes, diagnostiquer rapidement les problèmes de production et faire évoluer leur plateforme Kubernetes selon leur contexte spécifique.

Basé à Montréal · Québec et à distance

EXPÉRIENCE

01~200serveurs en production
02~10clusters orchestrés par Cluster API
03~4 Tologs / 3 semaines
04~600 Gométriques / 2 mois

COMMENT JE VOUS AIDE

Du symptôme à la résolution

Intervention ciblée, avec et pour votre équipe.

/01

Observabilité et fiabilité

De nombreux tableaux de bord existent, mais peu sont réellement utilisés. Certains problèmes prennent des jours avant d'être détectés si ce n'est pas le client qui le découvre en premier. J’aide à définir ce qu'est un service en santé, puis à mettre en place la visibilité qui confirme qu’il le reste.

/02

Monitoring

Différents outils, différents formats: Elastic, Datadog, Loki. Des téraoctets de données sont ingérés, mais filtrer pour trouver l'erreur recherchée reste laborieux. Je rassemble la télémétrie à un endroit cohérent, pour passer du signal d'alerte à la cause rapidement.

/03

Architecture GitOps

Les environnements divergent sans que ce soit visible. Il devient difficile de savoir quoi a été changé, quand et par qui. Je mets en place un état déclaratif, versionné et reproductible, qui rend les déploiements simples et sûrs.

/04

Alertes et incidents

Pager à 3h pour un avertissement qui pouvait attendre 9h. Les alertes superficielles vous fatiguent alors que certains problèmes restent silencieux. Les incidents ainsi que leurs investigations se répètent et leur résolution repose toujours sur la même personne. Je trie le signal du bruit, relie chaque alerte à une action claire et documente les méthodes dans des runbooks utilisables par toute l’équipe, humain comme agent.

EXPÉRIENCE

Des problèmes concrets, à l’échelle de la production.

Expériences présentées de façon anonymisée. Les migrations décrites ont été progressives.

CASE / 01OBSERVABILITÉ

Moderniser l’observabilité en production

Faire évoluer la gestion des métriques et des logs vers une solution centralisée, légère et rapide, adaptée à des volumes importants.

CONTEXTE

Une organisation exploitant environ 200 serveurs s’appuyait sur Nagios, Elastic et Prometheus, avec des connexions SSH ponctuelles pour consulter certains logs. Les différentes sources éparpillées compliquaient les investigations et l’évolution de la supervision.

INTERVENTION

Gestion d'une évolution progressive vers Prometheus et Thanos, puis VictoriaMetrics pour les métriques. Pour les logs, utilisation de Vector et évolution de Loki vers Quickwit. Point central de visualisation avec Grafana et routage des alertes avec Alertmanager. Ajout d'un processus de création et de résolution d'incidents et d'un catalogue de services à l'aide d'incident.io.

  • Environ 600 Go de métriques conservées sur une fenêtre de deux mois à travers plusieurs clusters VictoriaMetrics.
  • Environ 4 To de logs provenant de Kubernetes et de conteneurs LXC traités sur une fenêtre de trois semaines.
  • Centralisation des tableaux de bord, des métriques et des logs afin que tout soit accessible depuis Grafana.
  • Des alertes routées vers les bons intervenants plutôt qu'envoyées en masse à une seule personne.
ARCHITECTURE / TRANSITION

DÉPART

  1. Nagios
  2. SSH ponctuel
  3. Supervision fragmentée entre Elastic et Grafana
  4. Logs dispersés
  5. Alertes envoyées à une personne

DESTINATION

  1. 01Hôtes et services catalogués
  2. 02Visualisation centralisée par Grafana
  3. 03Cluster de monitoring
  4. 04Gestion d'incidents
TECHNOLOGIES
PrometheusThanosVictoriaMetricsVectorLokiQuickwitGrafanaAlertmanagerincident.io
CASE / 02INGÉNIERIE DE PLATEFORME

Faire évoluer une plateforme legacy vers Kubernetes et GitOps

Remplacer progressivement une chaîne de déploiement sur mesure par une plateforme Kubernetes déclarative et reproductible.

CONTEXTE

Une plateforme de production reposait sur des conteneurs LXC, des paquets Debian personnalisés et des scripts Perl complexes. Son évolution, son apprentissage et sa reproduction demandaient beaucoup de travail manuel (SSH et scripts).

INTERVENTION

Contribution à une migration progressive vers Kubernetes bare metal, avec FluxCD, Helm et des pratiques GitOps. La gestion de secrets avec SOPS, les sauvegardes avec Velero et le stockage Ceph faisaient partie de l’écosystème. Expérience également avec une flotte d'environ dix clusters gérés avec Cluster API et Sveltos.

  • Transition graduel vers Kubernetes.
  • Déploiement d'un cluster de 6 nœuds dédié au monitoring centralisé de l'ensemble des serveurs.
  • Gestion d'environ 20 nœuds répartis à travers différents clusters.
  • Gestion d’une flotte d’environ dix clusters avec Cluster API et Sveltos.
  • Déploiement reproductible de l'infrastructure (CNI, DNS, ingress, stockage).
ARCHITECTURE / TRANSITION

DÉPART

  1. Conteneurs LXC
  2. Paquets Debian personnalisés
  3. Scripts Perl
  4. SSH

DESTINATION

    TECHNOLOGIES
    KubernetesFluxCDArgo CDHelmCluster APISOPSVeleroCeph

    OUTILS ET EXPERTISES

    De la technologie à la compétence

    DOMAIN / 01

    Observabilité et télémétrie

    Collecte, stockage et visualisation de métriques et de logs à grande échelle.

    • Grafana
    • Prometheus
    • Thanos
    • VictoriaMetrics
    • Loki
    • Quickwit
    • Vector
    • OpenTelemetry
    DOMAIN / 02

    Alertes et incidents

    Routage des alertes, paging et pratiques de gestion d’incidents pour relier les signaux utiles aux procédures de réponse.

    • Alertmanager
    • Grafana OnCall
    • incident.io
    DOMAIN / 03

    Plateforme et GitOps

    Orchestration et cycle de vie des clusters, déploiements déclaratifs, gestion des secrets et sauvegardes.

    • Kubernetes
    • Cluster API
    • Sveltos
    • FluxCD
    • Argo CD
    • Helm
    • Kyverno
    • Cilium
    • SOPS
    • Velero
    DOMAIN / 04

    Fondations et données

    Linux en production, bare metal, stockage distribué, bases de données et serveurs web.

    • Linux (Debian, Ubuntu, Arch, NixOS)
    • Bare metal
    • Ceph
    • PostgreSQL
    • ClickHouse
    • Nginx

    FAÇON DE TRAVAILLER

    Du pragmatisme, avec une sortie claire.

    01

    Pas de boîte noire

    Configuration versionnée, documentation utile et transfert de connaissances. L’objectif : donner à votre équipe les moyens de faire évoluer la solution.

    02

    Le bon compromis pour votre contexte

    Service géré, outil existant ou composant dédié : choix fondés sur les besoins, les compétences de l’équipe, le coût total et la charge d’exploitation.

    03

    Du signal, moins de bruit

    Des alertes associées à une action claire et une télémétrie utile au diagnostic — plutôt que davantage de tableaux de bord sans décision.

    PREMIÈRE CONVERSATION

    Un enjeu de plateforme ou de fiabilité à démêler ?

    Écrivez-moi quelques lignes sur votre contexte. Nous pourrons voir si mon expérience correspond à votre besoin.