SRE on Zwindler's Reflection

SLO, SLI, Error Budget et Critical User Journey expliqués simplement (et pourquoi ce ne sont pas des SLA !) (en plusieurs prompts)

Tue, 17 Jun 2025 18:00:00 +0200

NOTE IMPORTANTE : cet article a été généré par un LLM. Ceci va à l’encontre de règles que je me suis fixé pour ce blog (cf l’AI Manifesto).

Je pars du principe que si je ne prends pas la peine d’écrire moi-même le contenu de ce blog, vous ne devriez pas prendre la peine de le lire.

Je l’ai fait dans le cadre d’une expérience qui est décrite dans l’article suivant :

Réflexions sur le blogging technique à l’ère des LLMs

Cependant, je ne vous interdit pas de lire cet article ci (les informations qu’il contient sur les SLOs sont correctes), je veux juste que vous le fassiez en connaissance de cause ;-P.

Introduction : quand les devs découvrent le SRE

Suite à plusieurs discussions récentes avec des collègues développeurs, je me suis rendu compte que les concepts SRE comme les SLO, SLI et Error Budget restaient flous pour beaucoup d’entre eux. Pourtant, ces notions sont de plus en plus utilisées dans nos équipes, souvent sans qu’on prenne le temps de bien les expliquer.

C’est donc l’occasion parfaite pour revenir aux fondamentaux et expliquer ces concepts tels qu’ils ont été conçus à l’origine par Google. Car oui, il faut le rappeler : le SRE (Site Reliability Engineering) et tous les concepts associés ont été inventés par Google, plus précisément par Ben Treynor Sloss en 2003, bien avant que DevOps ne devienne populaire !

L’idée de Google était simple : et si on demandait à des ingénieurs logiciel de concevoir une équipe d’exploitation ? De cette approche sont nés des concepts révolutionnaires pour mesurer et gérer la fiabilité des services.

Fun fact : j’avais déjà abordé ces sujets dans mon talk sur le SRE en 2022, mais je me dis qu’un article dédié ne fait pas de mal pour clarifier les choses :-).

SLA vs SLO : ne mélangeons pas tout !

Avant de rentrer dans le vif du sujet, petit aparté important : ne confondez pas SLA et SLO !

Le SLA (Service Level Agreement), c’est un contrat, souvent avec des pénalités financières si pas respecté. Genre “si le service est en panne plus de X heures dans le mois, on vous rembourse Y€”. Le SLO (Service Level Objective), c’est un objectif interne que vous vous fixez pour la fiabilité de votre service.

La différence est importante : les SLA sont souvent moins stricts que les SLO pour avoir une marge de manœuvre. Si votre SLA c’est 99,9% de disponibilité, votre SLO interne sera peut-être à 99,95%.

Bon, maintenant qu’on a éclairci ça, rentrons dans le détail !

Critical User Journey : commencer par ce qui compte vraiment

Est-ce que le client est content d’utiliser le service ?

C’est LA question fondamentale. Et pour y répondre, il faut d’abord identifier les Critical User Journey (CUJ), autrement dit les parcours utilisateurs critiques.

Mais attention, quand on parle d’utilisateur dans le contexte SRE, ce n’est pas forcément l’utilisateur final ! Pour un service backend, l’utilisateur peut être le frontend qui fait les appels API. Pour une plateforme de CI/CD, ce sont les développeurs qui veulent livrer une nouvelle version. Pour une base de données, ce sont les applications qui l’interrogent.

Concrètement, ça veut dire quoi ? Prenons l’exemple d’une plateforme e-commerce. Les CUJ pourraient être : un utilisateur peut rechercher et consulter un produit, il peut ajouter un produit au panier et passer commande, il peut se connecter à son compte.

On ne va pas définir des SLO pour toutes les fonctionnalités (la page “À propos” de votre site, on s’en fiche un peu), mais se concentrer sur celles qui, si elles tombent en panne, vont vraiment énerver vos utilisateurs.

Et c’est là que ça devient intéressant : définir les CUJ, c’est souvent un exercice qui doit impliquer le business, pas seulement les équipes techniques. C’est eux qui savent ce qui rapporte de l’argent !

SLI : mesurer ce qui compte

Une fois qu’on a identifié nos CUJ, il faut les mesurer. C’est là qu’interviennent les SLI (Service Level Indicators).

Un SLI, c’est simplement une métrique qui indique si votre service fonctionne bien du point de vue de l’utilisateur. Les plus classiques sont la disponibilité (pourcentage de requêtes qui réussissent), la latence (temps de réponse du service), le débit (nombre de requêtes traitées par seconde) et la qualité (pourcentage de réponses correctes, sans erreurs de données).

L’idée clé ici, c’est de mesurer depuis le point de vue de l’utilisateur, pas depuis vos serveurs. Peu importe que votre CPU soit à 10% si l’utilisateur voit des erreurs 500 !

Quelques conseils pour choisir vos SLI

Pour vous aider à concevoir des SLI fiables, vous pouvez vous inspirer des méthodes USE et RED. USE (Utilization, Saturation, Errors) se concentre sur les ressources systèmes, tandis que RED (Rate, Errors, Duration) se concentre sur les requêtes. Ces frameworks vous donnent un bon point de départ pour identifier les métriques qui comptent vraiment.

Mais attention, un microservice ne doit pas avoir trop de SLI ! Trois ou quatre SLI bien choisies et qui ont un sens métier valent mieux qu’une dizaine de métriques que personne ne regarde. D’ailleurs, seuls les membres de l’équipe qui fournissent le service peuvent vraiment savoir quelles sont les métriques pertinentes. On ne peut pas imposer des SLI génériques à toute une entreprise !

Exemple concret pour notre CUJ “recherche de produit” : SLI disponibilité pourrait être (requêtes HTTP 200 sur /search) / (total requêtes sur /search) * 100, et SLI latence 95% des requêtes sur /search répondent en moins de X ms.

SLO : se fixer des objectifs réalistes

Maintenant qu’on sait quoi mesurer, il faut se fixer des objectifs. C’est le rôle des SLO (Service Level Objectives).

Un SLO, c’est tout simplement une valeur cible pour vos SLI sur une période donnée. Par exemple : “99,9% des requêtes de recherche doivent réussir sur une période de 30 jours” ou “95% des pages de recherche doivent s’afficher en moins de 500ms sur une période de 7 jours”.

Quelques conseils pour bien définir vos SLO

Commencez par mesurer l’existant. Inutile de viser 99,99% si votre service actuel est à 98%. Regardez vos métriques historiques et fixez-vous des objectifs atteignables mais ambitieux.

Pensez S.M.A.R.T. : vos SLO doivent être Spécifiques, Mesurables, Atteignables, Réalistes et Temporellement définis. Comme tout bon objectif !

Et n’oubliez pas que 100% c’est mal ! Comme le dit si bien Ben Treynor Sloss (le papa du SRE chez Google) :

100% is the wrong reliability target for basically everything

Plus on veut de “9”, plus ça coûte cher exponentiellement. Et au-delà d’un certain seuil, les utilisateurs ne voient même plus la différence ! Prenez l’exemple d’un site web qui ne charge pas sur un smartphone : au-delà d’un certain niveau de disponibilité, l’utilisateur ne saura pas dire si c’est son smartphone qui a un problème, son navigateur, le réseau 5G ou bien le site web qui rencontre un incident. Si recharger la page une fois de temps en temps suffit et que les utilisateurs ne sont pas plus impactés que ça, inutile d’investir dans plus de fiabilité.

Pour vous aider à calculer ces pourcentages et temps d’indisponibilité, vous pouvez utiliser uptime.is qui fait les conversions pour vous.

Error Budget : retourner le problème

Et là, c’est le moment où ça devient vraiment malin. Au lieu de raisonner en “disponibilité”, les équipes SRE raisonnent en Error Budget (budget d’erreur).

C’est un simple changement de perspective : service accessible 99,9% = service inaccessible 0,1% du temps. Sur 30 jours, ça fait environ 43 minutes d’indisponibilité “autorisée”.

Cette approche change complètement la donne ! Au lieu de voir les pannes comme des échecs, on les voit comme un budget à dépenser intelligemment.

Comment utiliser son Error Budget ?

Contre-intuitivement… IL FAUT L’UTILISER !

Si votre SLO est respecté (utilisateurs contents), vous pouvez “dépenser” votre error budget pour faire des déploiements plus risqués, tester des nouvelles fonctionnalités en prod, faire du chaos engineering, ou réaliser des maintenances disruptives.

À l’inverse, si vous “cramez” votre error budget (SLO pas atteint), alors là, stop : on arrête tout ce qui n’améliore pas la fiabilité du service !

C’est un formidable outil de priorisation entre les équipes produit (qui veulent des nouvelles features) et les équipes ops (qui veulent de la stabilité). Le fameux mur de la confusion :

Exemple concret : une API de recommendation

Bon, assez de théorie, prenons un exemple concret. Imaginons qu’on ait une API de recommandation de produits.

D’abord, on définit le CUJ : “Un utilisateur doit pouvoir récupérer des recommandations personnalisées en moins de 1 seconde”. Ensuite, on choisit les SLI : disponibilité (réponses HTTP 200) / (total requêtes) * 100 et latence P95 du temps de réponse.

Pour les SLO, on pourrait avoir : “99,5% des requêtes sur l’API de recommandation doivent réussir sur 30 jours” et “95% des requêtes doivent répondre en moins de 800ms sur 7 jours”.

Enfin, on calcule l’Error Budget : 99,5% de disponibilité = 0,5% d’indisponibilité autorisée, soit environ 3,6 heures d’indisponibilité “budgetées” sur 30 jours.

Simple, non ?

Les pièges à éviter

Le premier piège, c’est de vouloir mettre des SLO partout. N’essayez pas ! Commencez par 2-3 SLO sur vos CUJ les plus critiques. Vous pourrez étendre ensuite.

Le deuxième piège, c’est de fixer des SLO trop stricts. Si vous mettez la barre trop haut, vous allez passer votre temps en “SLO violation” et personne ne prendra plus ça au sérieux.

Enfin, le troisième piège, c’est d’oublier l’aspect organisationnel. Les Error Budgets ne marchent que si toute l’organisation (business inclus) adhère au principe. Sinon, vous aurez beau être en SLO violation, on vous demandera quand même de déployer la nouvelle feature…

Comment commencer ?

Si vous n’avez jamais fait de SLO, voici un plan d’action simple.

Identifiez d’abord 1-2 CUJ critiques (avec le business !). Regardez ensuite vos métriques actuelles sur ces parcours. Définissez alors des SLO réalistes mais un peu ambitieux. Mettez en place l’alerting quand vous êtes en train de consommer votre error budget. Et enfin, itérez ! Les SLO ne sont pas gravés dans le marbre.

Conclusion

J’espère que cet article vous aura donné envie de creuser ces concepts ! Les SLO/SLI/Error Budget ne sont pas juste des buzzwords, c’est vraiment un changement de paradigme dans la façon d’appréhender la fiabilité.

Et le plus beau, c’est que ça marche autant pour une startup avec 3 développeurs que pour une GAFAM avec 10000 ingénieurs. L’important, c’est de commencer simple et d’itérer.

Pour aller plus loin, je vous recommande chaudement le SRE Book de Google (gratuit !) et leur guide pratique pour définir des SLO.

Et si vous voulez approfondir le sujet SRE en général, n’hésitez pas à jeter un œil aux slides de mon talk de 2022 ;-).

Bon monitoring !

Moi aussi, je suis un imposteur

Mon, 17 Oct 2022 06:00:00 +0200

Un petit mot sur cet article

Au moment où j’ai écrit cet article, je n’avais aucune intention de le poster. Je l’ai écrit à chaud, un soir début 2021, en me disant que je ne le posterai jamais.

Que c’était donner le bâton pour se faire battre. Qu’on se rendrait (enfin) compte que je suis un imposteur.

Après l’avoir écrit, ça allait déjà beaucoup mieux. Ecrire, ça aide à mettre de l’ordre dans les pensées. Ça fait du bien.

Du coup, je me suis finalement dit que d’autres qui ressentent la même chose pourraient se dire, en me lisant « Je ne suis pas seul ! ». Lire, je pense ça peut aussi faire du bien.

Note : C’est très personnel comme article. Si ça vous intéresse, voilà donc le texte en question.

Note 2 : J’ai essayé de ne pas trop toucher au texte initial pour ne pas le dénaturer a posteriori (j’ai corrigé quelques fautes, changé une ou deux tournures, ajouté une blague).

[DEBUT du texte écrit début 2021]

Hashtag ma vie

Il y a peu, j’ai commencé en tant que « Senior SRE » dans une boite connue dans la tech française. J’en suis hyper fier. Vraiment !

Je suis fier de tout, dans ce poste :

Fier d’être SRE, car c’est la reconnaissance que mon métier d’aujourd’hui est plus subtil que rebooter des serveurs hier (ce que j’ai fait pendant un certain nombre d’années).
Fier d’être dans la boite tech en question. J’ai envie de dire que c’est un fleuron de la tech française. Ce n’est pas le leader du marché (et de loin), mais je m’en fiche. Comme dirait Bruno Lemaire, « J’suis français. P**ain c’est la classe ! » (sic). Ouais, je suis un peu chauvin, désolé 🤷.
Fier d’être considéré, avec ma petite douzaine d’année en poste, comme « senior » (oui, dans l’IT, ce n’est pas un gros mot).

J’étais (et je reste) hyper motivé.

Mais je suis complètement dépassé

Dès les premiers jours, j’ai pris une grosse (grosse) claque. Le contexte n’a pas aidé (COVID, full remote alors que je n’en avais jamais fait), la prise de poste a été très rude.

Les premiers jours, je patauge dans git, que je pensais maîtriser mais que je n’avais finalement jamais réellement pratiqué.

Pour un « SRE », avouez que ça la fout mal !

Heureusement, je ne fais pas « trop » de trucs crades (ouf) et n’ai pas eu à faire de rebase compliqué, sans quoi j’étais fichu…

Les semaines suivantes, je suis affecté, seul, à un projet critique et sur un sujet que je pense maîtriser (alors qu’en fait, non) : réussir à dépatouiller une situation compliquée sur un cluster Kubernetes qu’on a « un peu laissé dans son coin ».

Je me suis vendu comme “expert Kubernetes”, donc j’assume avec fierté (orgueil ?). Je me porte même volontaire.

Je me mets une pression de dingue. J’ai décrété (égo) que j’y arriverais sans aucune interruption de service, malgré un trafic web important (web public) et un contexte logiciel que je découvre juste et des contraintes que j’ignore encore.

Et si jamais je n’avais pas été capable de livrer à ce niveau de qualité, je n’aurais pas trouvé ça acceptable. J’avais DÉCIDÉ que ça serait comme ça, pas autrement.

Et ça a marché

Mission accomplie.

Là encore, heureusement (miraculeusement ?), j’ai réussi. Après 3 mois d’apnée, je sors la tête avec un cluster de prod hors de danger et 0 downtime côté utilisateur final.

Mais à quel prix ? Je n’ai pas participé au reste de la vie de l’équipe. Côté stack logicielle et infra, je ne me suis que peu intéressé au legacy que je découvre encore aujourd’hui.

Le soir, je me sens vidé, mentalement. Je n’ai plus envie de m’occuper de l’infra de la maison. Je ne teste plus de nouveaux projets le weekend.

Je ne suis pas du tout dégoûté de mon métier pour autant (c’est ma passion), ni en burnout (je fais des horaires tout à fait raisonnables).

C’est juste super intense.

Le blog tombe à l’abandon, avec un article par mois au lieu d’un par semaine. Et encore, je me force à publier mes brouillons inachevés, surtout. Sans ça, il n’y aurait eu aucun article en 6 mois.

Principe de Peter

Avez-vous déjà entendu parler du principe de Peter ? A la base c’était une blague qui disait que :

un employé compétent à un poste donné est promu à un niveau hiérarchique supérieur

un employé incompétent à un poste donné n’est pas promu à un niveau supérieur, ni rétrogradé à son ancien poste ; Corollaire :

un employé ne restera dans aucun des postes où il est compétent puisqu’il sera promu à des niveaux hiérarchiques supérieurs,

par suite des promotions, l’employé finira (probablement) par atteindre un poste auquel il sera incompétent, par son incompétence à ce poste,

l’employé ne recevra plus de promotion, il restera donc indéfiniment à un poste pour lequel il est incompétent ; (cf Wikipedia)

Au-delà de la « blague » initiale de son auteur, je trouve qu’il y a un fond de vérité dans ce « principe ».

J’espère très très fort ne pas être arrivé à mon seuil d’incompétence. Je suis vraiment obligé de mouiller la chemise au quotidien.

Fini les 12 ans de ClubMed.

Je voulais du challenge ? Me voilà servi. Je voulais apprendre tous les jours ? Et si on commençait déjà par les bases qui me font défaut, en fait ?

Moi, versus tous les autres ?

Si encore je vivais tout seul dans une grotte, passe encore… Mais je suis entouré de gens extrêmement compétents/brillants que j’admire.

Mon meilleur ami d’enfance est un développeur backend hors pair, qui au delà de son métier de dev, maîtrise Linux depuis son adolescence, à l’aise avec l’Ops, etc.

Dans nos discussions, dès qu’on s’aventure hors de ma zone d’expertise, difficile de donner le change. Lui, ne semble jamais être dans cette posture. Des fois, je préfère éviter de donner mon avis plutôt que risquer de passer pour un c**…

Un ancien collègue déployait des clusters Kubernetes et de la supervision Prometheus avec du code qu’il patchait lui-même pour résoudre nos problèmes internes. Il ne connaissait pas Go ? Qu’à cela ne tienne, 2 jours plus tard, il envoyait ses premières PRs sur le repo officiel de Prometheus.

Moi je me contente de pauvres petits bouts de code Python…

Game level : Insane

Mais là, on est vraiment encore un cran au-dessus. J’ai l’angoissante impression qu’il y a des dieux de l’informatique dans TOUTES les équipes !

Un jour, c’est un développeur Backend qui m’explique des principes de perf dans Kubernetes, entre le café et 2 lignes de code pour créer un petit tool multi-message-brokers pour load tester les différentes solutions qu’on envisage.

Hashtag trivial LOL

Le lendemain, c’est l’ingénieur réseau qui nous débloque d’un énorme souci de performance sur Prometheus alors qu’il n’en a quasiment jamais fait. Et moi qui pratique depuis 2 ans, j’ai surtout l’impression de faire le canard en plastique (cf méthode du canard en plastique/rubberducking pour ceux qui ne connaissent pas).

Même parmi les juniors de l’équipe, j’ai parfois l’impression qu’ils maitrisent mieux certains aspects de Linux que moi…

Wait… wat?

En vrai, c’est pas étonnant. J’ai passé relativement peu de temps à faire du Linux dans ma carrière.

En gros, j’ai bossé là où j’ai pu, et c’était pas fun tous les jours. Diplômé en 2010 (en plein crise économique), le taf d’admin système était vraiment rare pour un jeune diplômé, à Bordeaux. Du coup j’ai fait un peu de tout…

Du VMware, du Nagios, de l’administration sous Windows (desktop ou server), de l’Unix propriétaire et de l’administration de baies de stockage. Des trucs qui ne me servent plus à rien aujourd’hui (mais qui traînent encore sur le blog)…

J’ai racké physiquement des serveurs, conçu des salles serveurs, fais des présentations pour que les décideurs comprennent à quoi sert Docker et des tableurs pour comparer objectivement des offres d’intégrateurs…

Désolé pour les pros du cable management, je sais que c’est cracra…

Mais du coup :

Quand il faut débugger à coup de strace, tcpdump, pprof ou configurer linux avec des paramètres un peu exotiques, je suis loin d’être “le kernel le plus plus optimisé du tiroir”…
Quand il faut coder un tool ad-hoc qui s’intègre avec la stack legacy pour tester des outils du marché, je ne sais pas par où commencer…
Quand je débugge un problème compliqué et qu’un collègue dont c’est ni le boulot ni la spécialité trouve la solution avant moi…

Ben… Déjà que je me sens bof légitime en tant que « SRE »… alors oser me présenter « senior » ?

Tous les jours, j’ai l’angoisse d’être démasqué.

Pourtant, personne ne s’en rend compte !!!

Le plus incroyable dans cette histoire, c’est que je rame, je rame, mais que personne ne semble s’en rendre compte ! Les gens ont même l’air plutôt content de mon travail.

Ok, j’ai pas fait de grosse connerie, mais bon… encore heureux non ?!

Je suis lent… mais les gens s’en satisfont ?

L’image qu’on a de moi

(Ou que je pense qu’on a de moi ?)

D’abord, j’ai acquis au fil des années une petite « image » publique. Rien de fou : j’écris sur ce blog, je fais partie de plusieurs communautés et j’ai fait quelques confs.

Rien à voir avec vos « créateurs de contenu préférés » bien sûr (je ne vais pas citer de nom, mais je suis sûr que vous en avez en tête, ceux avec des milliers/centaines de milliers de followers).

Mais à Bordeaux (réel microcosme où tout le monde se connaît), on commence à me (re)connaître un peu.

J’explique des trucs simples, je travaille pour que ça soit le plus accessible possible. Du coup, les gens s’imaginent que je sais de quoi je parle.

Je pense qu’il s’agit d’un biais cognitif (effet de halo peut être ?) qui fait que, parce que je suis un peu plus visible que la moyenne, on a tendance à m’accorder une plus grande compétence que ce que j’ai réellement.

C’est pas légitime et ça renforce ma conviction que je suis un imposteur.

Peut-être aussi parce que je compense ?

En un peu plus positif, je compense grâce à d’autres compétences :

Je ne code pas super vite, mais j’essaye de faire propre et je ne fais pas deux fois la même erreur.

Je documente, mais aussi je communique sur ce que je fais cf ce tweet de Work Chronicles

Je sais écrire un billet de blog professionnel en français/anglais correct ou faire une belle présentation.

Je sais expliquer ma mission, mes besoins, mes contraintes à des interlocuteurs, francophones ou anglophones, même à l’oral. Je suis à l’aise pour présenter quelque chose à des VIPs (i.e. sans perdre mes moyens).

J’ai une connaissance généraliste sur un grand nombre de sujets. Je ne suis expert de rien, mais je connais un peu de tout. Quand je ne connais pas un truc, je sais où chercher.

J’ai l’habitude de voir toutes sortes de logiciels/d’infras. Je vois les problèmes potentiels quand on me montre une architecture, je suis pertinent dans une réunion de conception.

[FIN du texte écrit début 2021]

Finalement, suis-je si nul ?

Je l’ai dit en introduction, rien que d’écrire l’article, ça allait déjà un peu mieux. J’ai donc décidé d’en rester là sur le moment, et j’ai repris l’article aujourd’hui, quasiment 2 ans plus tard pour y ajouter l’introduction et cette conclusion.

On est humains, avoir des doutes c’est normal et probablement inévitable pour la majorité d’entre nous, même “séniors”. Clairement, j’ai l’impression que mes 12 ans d’expérience ne m’ont pas aidé à ne pas me sentir “nul”.

Savoir que le syndrome de l’imposteur existe n’est pas suffisant pour ne pas se sentir imposteur. Et changer de poste, c’est parfois une grosse claque.

Je terminerai sans vraiment conclure par ça, qu’il faut, comme le dit David Whittaker, régulièrement prendre un peu de recul. Être honnête avec soi-même ET avec les autres (ne pas TROP se sous-estimer / les surestimer).

Source David Whittaker sur Twitter

Si vous voulez aller plus loin, vous pouvez aussi (re)regarder le talk d’Aurélie Vache : Tips pour combattre le syndrome de l’imposteur.

Bonus : à propos de mon (plus si) nouveau job

Quand bien même c’est un challenge, je suis toujours aussi content de mon choix.

Je travaille avec des gens géniaux, motivés, qui ont énormément à m’apprendre.

Si je suis honnête avec moi-même, j’ai probablement aussi réussi à leur transmettre quelques trucs, même si ce n’est pas forcément là où j’imaginais avoir de la plus-value initialement. J’en parle dans mon post Mes conseils pour les nouveaux entrants dans l’IT.

Je suis objectivement au poste où j’apprendrais probablement le plus de chose dans le temps le plus court.

Ça force à rester humble (comme disait Montaigne, « que sais-je ? ») et je pense que c’est une bonne chose. Si vous en avez l’opportunité, visez ce genre de postes.

Note finale : depuis, je fais moi aussi du Go mais j’ai toujours peur quand je fais des git rebase…

Mes lectures tech des 12 derniers mois

Fri, 02 Sep 2022 12:30:00 +0200

Je ne suis pas un gros lecteur en général

Même si je suis d’accord que ça détend énormément, je lis assez peu. Quelques romans par an tout au plus. Mais il m’arrive de temps en temps, pour le boulot, de lire des livres techniques.

C’est plus facile de dégager du temps pour ça, on passe un temps fou au travail ;).

Au cours des 12 derniers mois, j’ai pris le temps d’en lire 3 dont je vais vous parler dans cet article, car je les recommande chaudement.

O’Reilly - 97 things every SRE should know

Écrit par un collectif d’une grosse 50aine de SREs, ce livre se compose d’une centaine de courts textes d’environs 2-3 pages maximum sur des sujets ayant un rapport avec le SRE et comment l’implémenter en entreprise.

J’ai beaucoup aimé ce livre (j’ai mis des marques pages partout) car il donne beaucoup de perspectives différentes sur le métier et la philosophie SRE. Je ne suis d’ailleurs pas d’accord avec tous les textes/auteurs.

Il m’a été très utile, notamment en tant que CoP leader, ainsi que pour la préparation de mon talk “SRE ! SRE partout !” (anciennement “Dis papa c’est quoi un SRE”, renommé depuis).

J’ai particulièrement aimé les articles parlant de la gestion des incidents, de l’astreinte, … qui donne une perspective intéressante sur la façon de gérer cet aspect complexe de nos métiers.

J’ai aussi utilisé le livre comme support dans un de mes meetings de communautés de pratique SRE, dans lequel nous avons fait une étude d’un texte.

Je compte le relire dans un an, pour voir si j’apprends de nouvelles choses.

Côté auteurs, on retrouve des grands noms comme Julia Evans, Liz Fong-Jones, Charity Majors, au côté de SRE que je ne connaissais pas. Bon, je ne vais pas mentir, c’est quand même très américano-centré et hume bon la silicon valley ;-) (même s’il y a quelques exceptions). Si vous avez un problème avec ça, ce livre n’est peut-être pas fait pour vous.

[Edit]Suite à la sortie de l’article, on m’a fait remarquer que la qualité des textes était très inégale. C’est vrai ; comme il y a plein d’auteurs différents, certains textes sont excellents, la majorité sont intéressant. Mais certains sont bof et quelques uns carrément mauvais.

Pascal Martin - Votre première conférence (quand ce n’est pas votre métier)

Sans être “pro”, je ne suis pas speaker débutant (une vingtaine de talks a mon actif). A priori, ce livre ne s’adresse donc pas à moi.

Mais comme on peut toujours s’améliorer, j’ai été curieux et l’ai commandé quand même. Je ne regrette pas du tout, je l’ai lu quasiment d’une traite, sur 3 jours, en mai (c’est assez rare pour moi pour être signalé).

Premièrement, ce que j’ai lu dans ce livre m’a paru totalement pertinent pour un débutant (c’est bien construit et très complet). Pascal détaille le processus pour créer une conférence du choix du sujet jusqu’à la présentation elle-même le jour J (et même, le “SAV”).

Je me suis beaucoup retrouvé dans les conseils de Pascal pour toute la première partie du travail (préparer un CFP), au point que j’aurais pu l’écrire moi-même. D’ailleurs je l’ai un peu fait dans mon article Combien de temps je mets pour préparer une conférence ?, écrit juste avant la sortie du livre.

Mais en revanche, je n’ai pas du tout retrouvé la même méthode de travail dans la partie construction du talk, rédaction du support, répétitions avant le jour J. Pascal travaille de manière bien plus méthodique, je suis beaucoup plus spontané (bord**ique ?).

C’était très enrichissant de découvrir cette autre façon de travailler et ça m’a beaucoup fait réfléchir, notamment sur certains travers et mauvaises habitudes que j’ai commencé à prendre avec la confiance qui augmente.

J’ai pris le temps de faire un retour exhaustif à Pascal chapitre par chapitre, et il a gentiment pris le temps d’échanger avec moi dessus. Merci à lui.

Je recommande donc chaudement à tous les speakers débutants et moins débutants.

Aurélie Vache - Understanding Kubernetes in a visual way

Si vous me suivez, vous connaissez très probablement Aurélie. En plus d’être une super conférencière sur tout un tas de sujets (Syndrome de l’imposteur, Kubernetes, Golang), Aurélie fait des “gribouillis” (selon ses propres termes, moi j’aurais dis des sketchnotes ;-p).

Je connais les gribouillis d’Aurélie depuis longtemps. A chaque fois qu’on me demande si je connais des bonnes docs pour débuter sur Kubernetes, j’en parle (juste après avoir averti que “si tu ne sais pas pourquoi tu en as besoin, c’est probablement que tu n’en as pas besoin”).

J’en avais d’ailleurs déjà parlé dans l’article Ressources utiles sur Internet pour apprendre Kubernetes quand on débute.

Aurélie a fait une collection de ces sketchnotes depuis un moment déjà, mais disponible au format numérique. Je ne suis pas fan du format numérique, même si je reconnais ça rend bien sur une tablette type iPad par exemple. Pour ce genre de choses, je préfère de loin un support papier.

Quand Aurélie a dit qu’elle se lançait dans l’aventure de l’auto-édition (via Amazon), j’ai sauté sur l’occasion et j’ai proposé mon aide pour une relecture.

Résultat : je l’ai dévoré (lui aussi en 3 jours).

Forcément, vu que gérer des clusters Kubernetes c’est mon métier depuis 5 ans, je ne suis pas la cible pour ce genre de livre. J’y ai quand même appris quelques astuces que j’ai loupés.

Mais c’est clairement plutôt à destination des débutants ou des gens qui auraient mis les mains dedans et qui veulent reprendre les bases.

Donc vraiment, si c’est votre cas, n’hésitez pas. Le livre est très chouette, le support fait majoritairement de gribouillis, coloré et ludique. Il est vraiment adapté au côté pédagogique, ça rend très très bien.

Les prochains livres ?

Sans certitude, je vais probablement m’attaquer à “People Powered: How Communities Can Supercharge Your Business, Brand, and Teams” pour m’aider dans mon travail auprès de diverses communautés internes / externes à mon entreprise.

Je lirais aussi très probablement “Accelerate: Building and Scaling High Performing Technology Organizations”.

Un autre livre tech à me conseiller ?

[Cloud Nord 2021] Dis papa ? C’est quoi un SRE ?

Mon, 27 Sep 2021 06:55:00 +0000

Nouveau talk, où je parle de mon métier : SRE

Je serai de nouveau en ligne avec les copains nordistes pour vous parler (vous l’aurez deviné) du métier de SRE !

J’ai été sélectionné comme speaker pour l’édition 2021 de Cloud Nord, un événement 100% en ligne qui aura lieu les 7 et 8 octobre de cette année. La billetterie est dors et déjà disponible ici.

Il s’agit d’un nouveau talk que j’ai écris suite à de multiples questions qui m’ont été posées (amis, connaissances sur les réseaux, etc) sur ce poste, différent d’une entreprise à l’autre !

Il n’existe évidement pas de réponse universelle à la question « c’est quoi un SRE ? » !

Mais pour ne pas que SRE devienne un terme fourre-tout, je pense que raconter mon expérience peut aider à remettre un peu de concret dans ce métier inventé par Google et décliné dans nos entreprises.

Le pitch

Ces dernières années, vous avez certainement vu apparaître un nouveau terme dans les annonces d’emploi : SRE. Tout le monde en cherche ! Pourtant, bien malin celui qui est capable de décrire le poste d’une manière qui convienne à tout le monde…

Au delà de la définition qu’en donne Google, qu’est ce que ça signifie, être SRE ?

Quelles sont les missions et les compétences du « bon » SRE ?

Que faut il pour devenir SRE ? S’agit il d’un Dev ou plutôt d’un Ops ?

Tout le monde n’est pas Google ! Est ce que ce terme est devenu un fourre-tout marketing ou le rôle SRE répond-il a un vrai besoin ?

Dans ce talk, je vous donnerai donc mon avis ainsi que mon expérience sur ce nouveau (ou pas ?) métier.

Slides

Comme à mon habitude, je met les slides à disposition ici pour que vous pouviez cliquer sur les liens en même temps que le talk :-)

Monter une CoP (Community of Practice)

Tue, 23 Mar 2021 07:20:00 +0000

T’es ma meilleure CoP !

Il y a 6 mois, quand j’ai changé d’entreprise, j’entendais parler pour la première fois du terme CoP (« Community of Practice », « Communauté de Pratique » en français).

L’entreprise dans laquelle je travaille est une des rares licornes Françaises. J’y ai découvert tout un tas de pratiques et en particulier les CoP.

Ça tombait super bien que je n’y connaisse rien, parce que la première chose qu’on m’a demandé de faire lorsque je suis arrivé dans ma nouvelle entreprise, c’est de monter une CoP. Et vous le savez, j’adore apprendre des nouveaux trucs ;-).

Mais revenons un instant aux fondamentaux

Ce terme a été inventé par Etienne Wenger, est un théoricien de l’éducation. Dans les années 90, il a étudié comment des groupes de personnes qui travaillent ensemble faisaient pour résoudre plus efficacement des problèmes qu’ils ont en commun.

Ce terme est ensuite repris par le SAFe (le Scale Agile Framework), qui voit les Community of Practices comme des piliers prépondérants des entreprises LEAN et qui en donne la définition suivante (Agile bingo spotted).

Communities of Practice (CoPs) are organized groups of people who have a common interest in a specific technical or business domain. They collaborate regularly to share information, improve their skills, and actively work on advancing the general knowledge of the domain. © Scaled Agile, Inc. www.scaledagileframework.com/communities-of-practice/

Une CoP est donc :

un groupe de personnes qui se retrouvent régulièrement
pour parler d’un centre d’intérêt commun (souvent un sujet technique, mais pas forcément)
pour partager et faire profiter les autres de leurs succès comme de leurs échecs et ainsi faire progresser tout le groupe

On retrouve donc 3 notions importantes, qui sont d’ailleurs des notions qui proviennent du travail de Wenger (ça tombe bien !), que vous verrez peut-être sur Internet sous les noms « Domain (2.) », « Practice (3.) » et « Community (1.) ».

[Edit] Un point que j’oublie d’aborder et que la CoP, doit être un lieu de partage et d’inclusion. Il faut qu’elle se déroule dans un climat bienveillant pour que tout le monde puisse se sentir à même de partager. De ce fait, il est également conseillé d’y privilégier un cadre informel/détendu (ce qui me convient parfaitement, je peux faire des jeux de mot pourris en toute impunité).

Mais est ce que ça sert vraiment ?

Jean Michel Petit Chef : Ben oui, parce que ça coûte cher quand même tous ces meetings entre Dev (et Ops) alors bon faudrait pas que ça coûte plus cher que mes meetings productivity-bingo-bullshit. (troll inside)

Si jamais comme JMPC vous êtes un peu sceptiques, vous pouvez aussi jeter un œil au programme DORA (DevOps Research and Assessment) et son State of DevOps 2019, qui montre que les plus great-performers (ceux qui sont agiles et shiny) sont ceux qui implémentent, entre autres, ce genre de communautés. A l’inverse, les low-performers ont plutôt tendance à monter des centres d’excellence ou de formation, qui ont tendance à « siloter » la connaissance.

High performers favor strategies that create community structures at both low and high levels in the organization, likely making them more sustainable and resilient to reorgs and product changes. The top … strategies employed are Communities of Practice […]

Low performers tend to favor Training Centers (also known as DOJOs) and Centers of Excellence (CoE)—strategies that create more silos and isolated expertise.

DORA State of DevOps 2019

Si vous vous présentez comme « le nouveau Google/Amazon/Uber français », vous savez maintenant ce qu’il vous reste à faire (troll, encore).

Dans mon entreprise, il existe une petite dizaine de CoP, de taille et de fréquence très diverses les unes des autres.

La plupart du temps, le but est de partager l’expérience et les bonnes pratiques entre tous les membres de la CoP, mais aussi présenter de nouveaux outils, de nouvelles façons de travailler, discuter des « pain-points » qui pénalisent les équipes, leur trouver des solutions rapides ou bien préparer les arguments pour prioriser leur résolution au prochain trimestre.

Grosso modo, dès que vous avez des groupes d’experts quelconques qui rencontrent plus ou moins les mêmes genres de problématiques, ça vaut le coup de monter une CoP pour éviter de réinventer la roue. Ou qu’au contraire une partie du groupe utilise des roues carrées alors qu’une autre équipe a déjà des roues rondes à disposition.

Tu m’as convaincu, comment j’en monte une ?

Avant de monter une CoP, il faudrait peut-être qu’elle ait une raison d’être, non ? Pour la trouver, il va falloir répondre aux questions suivantes :

« Quel sujet avons nous en commun et nous intéresse ? » (Domain)
« Qu’avons nous à partager ? Des retours d’expériences, des bonnes pratiques, de la technique pure? » (Practice)
« Qui sont les membres de la communauté ? » (Community)

Pour ces 3 questions, il n’existe pas de réponses universelles.

Domain

Il n’y a pas deux entreprises pareilles et il est donc normal qu’il n’y ait que vous qui puissiez savoir si une CoP sur le dernier framework Javascript à la mode, sur l’UX Design ou bien sur les principes SRE a du sens dans votre entreprise.

Community

On distingue deux types de communautés pour créer un CoP. Les communautés par Rôle (role-based), c’est à dire qui vont regrouper un certain type d’individus/de métier bien précis et les communautés par Sujet (Topic-based).

Pour ces derniers types de communautés (Topic-based), je pense qu’il faut construire la communauté la plus large possible du moment que les participants sont motivés. Ne soyez pas sectaires, tous les points de vue sont les bienvenus, pourvu qu’ils soient constructifs.

Un exemple un peu bateau mais parlant, n’hésitez pas à intégrer des Devs qui s’intéresseraient à votre CoP sur les bonnes pratiques Ops (ou l’inverse).

Regardez bien, je suis à deux doigts d’inventer le DevOps

Practice

Posez vous dès le début la question de ce que vous voulez partager en CoP (j’ai donné des exemples plus haut), mais aussi de la façon dont vous allez les organiser.

Quel format (présentation, séance de questions/réponses, brainstorming, mob, dojo …) ?
Quelle durée (30 minutes, 30 minutes + 30 minutes de questions, 2h, …) ?
Quelle fréquence (hebdomadaire, mensuel, toutes les lunes gibbeuses, …) ?

Il faut trouver la combinaison durée/créneau horaire qui arrange le plus de membres possible, tout en essayant de trouver une régularité qui favorisera la durée de vie de la CoP. Ne décidez pas de faire une CoP hebdomadaire si vous n’êtes pas capable de tenir le rythme sur le long terme !

Ce n’est pas un sprint mais une course de fond

La vie de la CoP

Comme toute organisation, une CoP n’a pas forcément vocation à être éternelle. On imagine bien qu’une CoP sur un framework qui n’existe plus dans l’entreprise disparaîtra d’elle même…

De même, il est normal que certains membres de la CoP soient plus impliqués que d’autres. Si vous voulez que votre CoP ait un intérêt maximal, le but du jeu sera évidemment de fédérer le plus de gens motivés possibles.

C’est évidemment plus facile à dire qu’à faire… #Yakafokon

Pour vous aider, n’hésitez pas à confronter l’idée que vous vous faites de votre CoP (Domain/Community/Practice) avec les gens que vous imaginez être vos futurs membres. Interrogez-les, faites un sondage sur ces points.

Demandez à vos collègues s’ils ont des sujets dont ils souhaiteraient discuter en groupe. Voire même des sujets qu’ils souhaiteraient présentez eux même.

Ce dernier point est capital pour le succès de la CoP. Si c’est toujours la même personne qui présente, cela risque fort de devenir son travail à temps complet (surtout si vous avez une fréquence hebdo).

Pire, les autres membres communauté seront passifs et les membres risquent de s’en désintéresser progressivement.

Il faut donc recruter des membres actifs, que tout le monde se sente impliqué.

Les outils de la CoP

Pour faciliter la collaboration des membres et maintenir une activité, n’hésitez pas à mettre en place des outils.

Vous utilisez très probablement un outil de messagerie instantanée, n’hésitez pas à créer un channel public dans lesquels vos participants pourront échanger entre les réunions, soit pour rediscuter d’un point vu en CoP, soit pour partager un article déniché pendant la veille. Ce channel servira aussi à recruter d’autres membres et à rappeler les futurs meetings.

Vous pouvez aussi créer un board (type Kanban) dans lequel tous les sujets à venir sont listés dans des tickets. Les membres de la CoP peuvent en ajouter, voter pour les sujets qui les intéressent le plus (aka les aideront le plus dans leur travail), prendre certains sujets pour les présenter eux même. Les tickets sont déplacés dans les colonnes « En cours », « Planifié » et « Terminé » en fonction du planning.

Dans la CoP que j’ai créé, j’ai également souhaité qu’à la fin de chaque meeting, un ROTI (Return on Time Invested) soit organisé. De cette manière, tous les participants peuvent donner un feedback honnête sur l’intérêt qu’ils portent sur le temps qu’ils viennent de consacrer. Cela permet de jauger l’intérêt que la communauté a pour les meetings que vous organisez, voire de corriger si jamais certains membres s’ennuient.

Une sorte de prise du pouls de votre CoP.

En cette période de confinement, vous pouvez trouver des outils en lignes pour éviter de compter les doigts sur chaque main levée.

Le facilitateur

En tant que « CoP leader », vous aurez un rôle de facilitateur. A vous de vous assurer qu’il y a suffisamment de sujets pour faire vivre la CoP, de recruter des orateurs pour présenter des sujets, d’animer le channel et le board.

Pendant la CoP, vous devrez aussi jouer le rôle de timekeeper. Entre passionnés, les discussions ont vite fait de traîner en longueur, car on s’égare sur un point précis qu’on trouve intéressant (moi le premier !). Or, il faut absolument se tenir au créneau choisi pour que tous les membres puissent participer dans de bonnes conditions.

A vous aussi de vous assurer que ce n’est pas toujours les mêmes qui prennent la parole. C’est la partie que personnellement je trouve la plus dure, car je travaille avec des passionnés qui ont une très grande connaissance, mais il faut absolument laisser de la place pour tout le monde, notamment ceux qui maîtrisent moins.

Enfin, vous aurez peut-être besoin de jouer le rôle de scribe (prise de note et retranscription résumée des débats/questions, tenue d’une page de wiki, sauvegarde des vidéos, etc) pour garder une trace du travail réalisé et de l’éventuel suivi des actions réalisées et à faire.

Il n’est pas impossible que ce travail « autour de la CoP » soit aussi consommateur en temps (voire plus !) que la CoP.

Conclusion

J’ai vraiment adoré avoir la responsabilité de monter une Community of Practice. Les débats qu’on a lors des réunions sont passionnants et pour ne rien gâcher, les retours sont vraiment bons.

Après quelques meetings, la CoP semble maintenant bien implantée chez nous, avec plusieurs sujets à venir, de plusieurs speakers et une vingtaine de membres à chaque fois (sur 40 inscrits).

Plusieurs sujets utiles pour les membres ont été présentés, dont certains qui ont eu des impacts sur les déploiements en Prod (best practices).

La quantité de travail est conséquente. Je l’avais anticipé, mais j’ai été surpris par la quantité de travail autour de la CoP (le rôle de facilitateur).

Enfin, pour la fréquence des meetings, j’ai été un peu frileux. J’avais trop peur qu’on s’épuise, j’ai proposé un rythme mensuel, alors qu’on a trop de sujets à traiter. Résultat, les sujets n’avancent pas aussi vite qu’on voudrait et ça créé de la frustration pour ceux qui attendent les sujets pas encore traité. Pour autant, je préfère ça que le contraire, et il est encore temps de corriger en augmentant la fréquence.

J’espère vous avoir convaincu :)

SRE on Zwindler's Reflection

SLO, SLI, Error Budget et Critical User Journey expliqués simplement (et pourquoi ce ne sont pas des SLA !) (en plusieurs prompts)

Introduction : quand les devs découvrent le SRE

SLA vs SLO : ne mélangeons pas tout !

Critical User Journey : commencer par ce qui compte vraiment

SLI : mesurer ce qui compte

Quelques conseils pour choisir vos SLI

SLO : se fixer des objectifs réalistes

Quelques conseils pour bien définir vos SLO

Error Budget : retourner le problème

Comment utiliser son Error Budget ?

Exemple concret : une API de recommendation

Les pièges à éviter

Comment commencer ?

Conclusion

Moi aussi, je suis un imposteur

Un petit mot sur cet article

Hashtag ma vie

Mais je suis complètement dépassé

Et ça a marché

Principe de Peter

Moi, versus tous les autres ?

Game level : Insane

Wait… wat?

Pourtant, personne ne s’en rend compte !!!

L’image qu’on a de moi

Peut-être aussi parce que je compense ?

Finalement, suis-je si nul ?

Bonus : à propos de mon (plus si) nouveau job

Mes lectures tech des 12 derniers mois

Je ne suis pas un gros lecteur en général

O’Reilly - 97 things every SRE should know

Pascal Martin - Votre première conférence (quand ce n’est pas votre métier)

Aurélie Vache - Understanding Kubernetes in a visual way

Les prochains livres ?

[Cloud Nord 2021] Dis papa ? C’est quoi un SRE ?

Nouveau talk, où je parle de mon métier : SRE

Le pitch

Slides

Monter une CoP (Community of Practice)

T’es ma meilleure CoP !

Mais revenons un instant aux fondamentaux

Mais est ce que ça sert vraiment ?

Tu m’as convaincu, comment j’en monte une ?

Domain

Community

Practice

La vie de la CoP

Les outils de la CoP

Le facilitateur

Conclusion

Sources