Je suis Arnaud, freelance SRE et observabilité basé à Strasbourg. J’interviens auprès des équipes qui ont déjà de la production, mais qui la pilotent à l’aveugle : pas de SLO, des alertes que plus personne ne lit, et des incidents dont on ne tire aucun enseignement.
Mon parti pris : l’observabilité n’est pas un tableau de bord de plus. C’est la capacité à répondre à une question que vous n’aviez pas prévue, à 3 h du matin, sans redéployer.
Mes prestations SRE
- Instrumentation OpenTelemetry : métriques, traces distribuées et logs corrélés dans un seul contexte.
- Stack d’observabilité self-hostée (SigNoz, Prometheus) ou branchée sur votre outillage existant.
- SLI et SLO tenables, avec error budgets et une politique d’alerting qui ne réveille personne pour rien.
- Métriques DORA : mesure de votre performance de livraison et trajectoire de progression chiffrée.
- Postmortems blameless et culture de fiabilité : runbooks, revues d’incident, boucles d’amélioration.
Commencer par les SLO, pas par l’outil
Installer une stack d’observabilité avant d’avoir défini ce que « marcher correctement » veut dire pour votre produit, c’est acheter des instruments sans savoir quoi mesurer. Je démarre par les parcours critiques et les objectifs de fiabilité associés, puis j’instrumente ce qui sert à les vérifier. L’outillage suit le besoin. L’inverse coûte cher et finit ignoré.
Ce chantier se combine naturellement avec l’infrastructure Kubernetes et l’ingénierie DevOps : même chaîne, du commit à la production, puis de la production au retour d’expérience.
Pourquoi un SRE freelance à Strasbourg
Les éditeurs SaaS et PME tech du Grand Est atteignent souvent une taille où l’infrastructure fonctionne mais où plus personne ne sait dire si le service est fiable. Monter un pôle SRE interne est prématuré ; se passer de la démarche coûte en incidents et en nuits blanches. Une mission cadrée pose les fondations, et votre équipe les tient ensuite. En présentiel depuis Strasbourg ou en full remote partout en France.
Ressources et articles utiles
- SLO, SLI et error budget : mesurer la fiabilité
- SigNoz : l’observabilité open source
- Les 4 métriques DORA : mesurer sa livraison
- Le postmortem blameless
- Ember : monitoring temps réel avec Caddy et FrankenPHP
- Kubernetes : comprendre l’orchestration de conteneurs
Questions fréquentes
Quelle différence entre monitoring et observabilité ?
Le monitoring répond à des questions que vous aviez prévues : « le CPU dépasse-t-il 80 % ? ». L'observabilité permet de poser des questions que vous n'aviez pas anticipées : « pourquoi ces trois clients ont-ils vu des erreurs 500 mardi entre 14 h et 14 h 10 ? ». Cela suppose des traces, des métriques et des logs corrélés, pas trois outils qui s'ignorent.
Qu'est-ce qu'un SLO et un error budget ?
Un SLO est un objectif de fiabilité chiffré et assumé : par exemple 99,9 % des requêtes servies sous 300 ms sur 30 jours. L'error budget est ce qu'il vous reste à dépenser : à 99,9 %, vous avez droit à 43 minutes de dégradation par mois. C'est ce budget qui arbitre concrètement entre livrer plus vite et stabiliser.
Faut-il être sur Kubernetes pour mettre en place de l’observabilité ?
Non. OpenTelemetry s'instrumente aussi bien sur une application PHP derrière un simple Docker Compose que sur un cluster. La taille de l'infrastructure change le dimensionnement de la stack, pas la démarche.
Quelles sont les 4 métriques DORA et à quoi servent-elles ?
Fréquence de déploiement, délai de livraison, taux d'échec des changements et temps de rétablissement. Elles mesurent la performance de livraison d'une équipe sans juger les personnes, et donnent une base factuelle pour décider où investir.
Un postmortem blameless, ce n'est pas déresponsabilisant ?
Non, c'est l'inverse. Chercher un coupable garantit qu'on vous cachera le prochain incident. Chercher la faille systémique (l'alerte manquante, la doc fausse, le déploiement sans rollback) corrige les causes et rend l'équipe plus sûre d'elle.