Étude de cas · SRE
Migrer l'observabilité d'une plateforme e-commerce vers Grafana Cloud sans trou de supervision
Une ETI du e-commerce avait décidé de consolider sa supervision sur Grafana Cloud et de quitter progressivement son outil de monitoring historique. Il fallait concevoir l'architecture cible, la décrire en code, migrer les alertes équipe par équipe et garder la production sous surveillance pendant la transition. Nous avons présenté un SRE senior, évalué sur ses migrations d'observabilité et sur sa pratique de l'IA ; il a rejoint l'équipe SRE à temps plein.
Par L'équipe Top Profil · Mis à jour le · 7 min de lecture
01
Le point de départ
L'entreprise exploite une plateforme e-commerce soumise à de fortes variations de charge, déployée sur Kubernetes dans un cloud public et exposée derrière un CDN. Ses services sont écrits principalement en Python et en Go, et livrés en continu avec ArgoCD. La supervision reposait sur un outil de monitoring commercial dont la couverture et le coût ne correspondaient plus aux besoins.
La direction technique avait décidé de consolider l'observabilité sur Grafana Cloud : métriques, alerting et tableaux de bord au même endroit, décrits en code. Il fallait choisir une architecture de collecte fondée sur OpenTelemetry, reprendre les alertes existantes sans en perdre, standardiser la façon dont chaque équipe les écrit et les reçoit, et maîtriser dès le départ le volume de données envoyé, qui fait la facture d'une plateforme managée.
L'équipe SRE en place n'avait pas la disponibilité pour mener ce travail de fond en plus de l'exploitation quotidienne. Le client nous a demandé un SRE senior, autonome sur Grafana, OpenTelemetry et Terraform, capable de cadrer puis d'exécuter la migration. Nous avons évalué et présenté un profil qui avait déjà conduit ce type de migration, y compris sur sa pratique de l'IA, critère éliminatoire chez nous.
02
Les enjeux
Migrer sans trou de supervision
L'ancien outil restait la référence des astreintes tant que ses alertes n'avaient pas été reprises dans Grafana. Chaque bascule devait être préparée équipe par équipe, avec une période de double run et des procédures de continuité.
Maîtriser la cardinalité et le coût
Sur une plateforme managée, chaque série de métriques collectée se paie, et les métriques de Kubernetes, du cloud et du CDN en produisent un très grand nombre si leurs labels ne sont pas filtrés. Le volume devait être mesuré et réduit avant la mise en production, puis surveillé en continu.
Rendre l'alerting exploitable
Une alerte n'a de valeur que si elle arrive au bon endroit, avec un lien vers le tableau de bord et le runbook, et si elle déclenche la bonne procédure d'incident. Les notifications, dispersées sur de nombreux canaux de messagerie, devaient être rationalisées.
Être prêt pour le pic de fin d'année
Pour une plateforme e-commerce, le pic commercial de fin d'année est le moment où l'alerting doit être irréprochable. Le bruit des alertes devait être mesuré et réduit avant cette échéance, sans masquer les signaux utiles.
03
La démarche, étape par étape
- 01
Cadrer l'architecture cible
Les premières semaines ont servi à comprendre l'existant, à prendre en main l'écosystème Kubernetes, ArgoCD et Grafana et à clarifier les objectifs. Le freelance a mené plusieurs preuves de concept avec Grafana Alloy et OpenTelemetry pour collecter les métriques du cloud, du CDN et de Kubernetes, en analysant performance, volumétrie et cardinalité. Les choix ont été consignés dans des documents d'architecture et de décision, validés avec l'équipe.
- 02
Déployer la collecte
L'architecture d'intégration finalisée, les collecteurs OpenTelemetry dédiés ont été déployés en préproduction et l'intégration Kubernetes implémentée. Un point bloquant est apparu sur les métriques du fournisseur cloud, qui ne portaient pas les labels personnalisés attendus ; il a été identifié et documenté avant d'aller plus loin. En parallèle, le routage et l'envoi des alertes ont été conçus et éprouvés par des preuves de concept.
- 03
Industrialiser l'alerting
L'alerting a ensuite été structuré : recensement des canaux de notification, clarification du routage, gabarits d'alertes standardisés pour des notifications lisibles. Les comptes de service, politiques d'accès et jetons Grafana ont été décrits dans des modules Terraform. Les alertes critiques ont été routées vers l'outil de gestion d'incidents, et une intégration avec l'outil de tickets ouvre automatiquement un ticket à partir d'une alerte. Des preuves de concept avec Grafana Faro ont exploré l'observabilité du front et des workers.
- 04
Migrer équipe par équipe et mettre la collecte du CDN en production
Une première équipe produit a été accompagnée dans la migration de ses alertes et de ses moniteurs de l'ancien outil vers Grafana, puis les alertes réseau ont suivi. Avec l'équipe infrastructure, l'exporter du CDN a été déployé en production, la collecte validée et la cardinalité maîtrisée. Un défaut sur les identifiants des règles d'alerte, qui produisait des liens invalides dans les notifications, a été identifié et corrigé.
- 05
Surveiller la chaîne de collecte et contenir les coûts
Le freelance a mis en place le self-monitoring de la chaîne OpenTelemetry, tableaux de bord et alertes compris, ainsi que des alertes sur la consommation de Grafana Cloud. L'analyse de la cardinalité a débouché sur des règles d'agrégation (Adaptive Metrics), documentées pour les équipes. Un module Terraform de gestion des sources de données a été développé, avec permissions, cache et authentification.
- 06
Fiabiliser et préparer le pic
Les derniers mois ont porté sur la robustesse : liens fiables vers les runbooks et les tableaux de bord depuis chaque alerte, réorganisation de la documentation, fiabilisation des recording rules et de leur synchronisation avec l'outillage d'infrastructure, migration de l'API d'alerting historique vers la nouvelle API. Les indicateurs de fatigue d'alerte ont été analysés pour mesurer le bruit avant le pic, et de nouveaux contrôles de qualité ajoutés au portail développeur interne.
04 · IA
L'IA dans la mission
Pendant la mission, le freelance a participé à un hackathon interne consacré à l'automatisation par IA et à l'observabilité.
Avant la mission, nous avons évalué sa pratique de l'IA comme pour chaque profil : les tâches qu'il confie à un assistant de code, la façon dont il les spécifie et, surtout, la manière dont il vérifie ce qui est produit avant de l'appliquer à une production. Un candidat incapable d'expliquer ce contrôle n'est pas retenu.
05
Ce que l'équipe a obtenu
- Une architecture d'observabilité cible formalisée et validée, avec ses documents de décision.
- Une collecte OpenTelemetry en place sur Kubernetes et sur le CDN, cette dernière en production avec une cardinalité maîtrisée.
- Un alerting standardisé : gabarits, routage clarifié, alertes critiques transmises à l'outil de gestion d'incidents, tickets automatiques, liens vers runbooks et tableaux de bord.
- Les alertes d'une première équipe produit et les alertes réseau migrées de l'ancien outil vers Grafana.
- Des modules Terraform pour les comptes de service, les politiques d'accès, les jetons et les sources de données Grafana.
- Un self-monitoring de la chaîne de collecte, des alertes sur la consommation de Grafana Cloud et des runbooks réorganisés.
FAQ
Vos questions sur cette mission
Dans ce cas, le cadrage et les preuves de concept ont pris environ deux mois, puis la collecte et l'alerting ont été industrialisés et les alertes migrées équipe par équipe. Après plus de huit mois, la mission se poursuit sur la fiabilisation. La durée dépend surtout du nombre d'équipes et d'alertes à reprendre.
Un SRE senior qui pratique Grafana, OpenTelemetry et Terraform en production, et qui a déjà vécu une migration d'outil de supervision. L'autonomie compte autant que la technique : il doit cadrer, documenter et accompagner les équipes dans leurs bascules. Un DevOps ou Cloud Engineer expérimenté peut prendre l'industrialisation Terraform.
Sur des situations vécues : une migration d'observabilité et ses compromis, un incident de production et ce que l'alerting en a montré, une décision sur la cardinalité des métriques. Puis sur sa pratique de l'IA : une tâche confiée à un assistant, la façon dont il l'a cadrée et ce qu'il a dû corriger. Le profil a été présenté au client avec notre compte rendu d'évaluation.
Les sources de données, les droits, les alertes et les tableaux de bord décrits en Terraform sont versionnés, revus et reproductibles d'un environnement à l'autre. Une alerte modifiée à la main dans l'interface se perd ; une alerte en code se relit, se teste et se restaure, et des équipes entières migrent sans ressaisie.
En mesurant la cardinalité dès les preuves de concept, en filtrant à la source les labels inutiles, en appliquant des règles d'agrégation aux métriques peu consultées et en surveillant la consommation par des alertes dédiées. Ici, ces alertes et leurs runbooks ont été mis en place avant que toutes les équipes ne basculent.
Étude rédigée par L'équipe Top Profil.
Publiée le , mise à jour le .
Un besoin proche de cette mission ?
Précisez votre contexte. Un expert Top Profil vous rappelle sous 1 jour ouvré.