Deez is la tech — S02E02 — En tête-à-tête avec des SRE : missions, quotidien et challenges

SRE. Trois lettres qui soulèvent autant d’intérêt que de questionnement.

SRE pour “Site Reliability Engineering”, ou ingénierie de fiabilité des sites dans la langue de Molière. Et c’est à cette discipline, aujourd’hui devenue un métier à part entière, que s’intéresse ce nouvel épisode du podcast Deez is la tech.

En quoi consiste le Site Reliability Engineering ? Quelle est la place du SRE en entreprise ? Quels sont les missions, tâches quotidiennes et défis d’un Site Reliability Engineer ? Quel est le profil idéal du SRE ? Apprenez-en plus ci-dessous grâce à nos trois invités !

Note: This post accompanies the release of the second episode of the second season of “Deez is la tech”, a podcast created by Deezer’s Product & Tech teams — in French only for now. You can still find English content on deezer.io though. Go check it out!

Résumé de l’épisode

Vingt ans après sa théorisation, le Site Reliability Engineering continue d’intriguer et reste un concept encore flou pour beaucoup. Derrière le sigle SRE se cachent, en effet, diverses définitions et réalités.

Mais qu’est-ce donc que le SRE ? Quel rapport avec DevOps ? Que font concrètement les Site Reliability Engineers chez Deezer et à quels défis sont-ils confrontés ? Enfin, comment devient-on SRE ?

Une fois n’est pas coutume, Loïc Doubinine (@ztec6) et Vincent Lepot (@neozibok), tous deux Senior Expert Backend SRE, sont les invités de cet épisode animé par Stéphane Bachelet (Senior Coach Agile) et Pauline Munier (Knowledge Manager). En compagnie de Denis GERMAIN (Senior Expert Infrastructure Engineer — @zwindler), ils rappellent les préceptes fondateurs du Site Reliability Engineering avant de détailler leur application au quotidien au sein des équipes de Deezer. Entre automatisation et évangélisation, et au moyen d’indicateurs et d’error budget notamment, le SRE se révèle être le véritable garant des bonnes pratiques des développeurs et des opérationnels, de la qualité logicielle et de la fiabilité du site.

Épisode également disponible sur Deezer | Apple Podcasts | Spotify | Amazon Music.

Transcription

[00:00:06.720] — Vincent : Bonjour et bienvenue dans Deez is la tech, le podcast qui n’pète ni les plombs, ni les crons ! Créé et animé par les équipes Product & Tech de Deezer, ce programme aborde des sujets relatifs aux mondes de la tech et du streaming musical, et vous fait occasionnellement découvrir les coulisses de certaines des fonctionnalités phares de Deezer. Rejoignez-nous chaque mois pour une nouvelle discussion entre collègues et pairs, en tout décontraction, mêlant partages d’expériences, bonnes pratiques et réflexions sur les tendances futures. Prêts pour un nouvel épisode ? Chaussez vos écouteurs, ça commence maintenant !

[00:00:43.150] — Stéphane : Le sigle “SRE” a le vent en poupe depuis quelques années et à en juger par les descriptions de postes sur le marché de l’emploi, son rôle et ses missions semblent différer d’une entreprise à l’autre. Il ne serait pas totalement erroné de dire qu’il y a quasiment autant de définitions du SRE qu’il n’y a d’entreprises en recherche. Qu’est-ce vraiment que le SRE et quels en sont les principes fondamentaux ? Quelle place occupe le SRE dans une entreprise, et plus particulièrement chez Deezer ? Quels outils utilise-t-on en tant que SRE et à quels défis fait-on face ? Enfin, comment devient- on SRE ? Je suis Stéphane Bachelet, Coach Agile chez Deezer, et avec ma collègue Pauline Munier, Knowledge Manager et productrice de ce podcast, nous accueillons aujourd’hui Loïc Doubinine, Denis Germain et Vincent Lepot afin de démystifier le rôle de SRE.

[00:01:29.900] — Pauline : Salut Denis ! On est ravi de t’accueillir dans Deez is la tech. Peux-tu te présenter en quelques mots ?

[00:01:35.550] — Denis : Je m’appelle Denis Germain, je suis Site Reliability Engineer chez Deezer. Je connais un petit peu le métier donc je me suis dit que ça pouvait être une bonne idée d’en parler.

[00:01:44.310] — Pauline : Merci ! À tes côtés se trouvent deux habitués du podcast car ils en sont, en temps normal, les animateurs. Je vous laisse en dire un peu plus sur vous.

[00:01:52.400] — Vincent : Bonjour ! Effectivement, ça fait bizarre d’être de l’autre côté. Vincent Lepot, je suis — je vais essayer de le dire aussi bien que Denis — Site Reliability Engineer Proxy — on pourra revenir un peu plus sur le “proxy” pendant le podcast — après avoir été développeur back-end pendant très longtemps.

[00:02:10.660] — Loïc : Moi, c’est Loïc Doubinine. Mon titre complet officiel, c’est Senior Expert Back End SRE, donc en gros, développeur SRE back-end.

[00:02:20.550] — Pauline : Merci à tous les trois de vous joindre à nous aujourd’hui pour parler de SRE ou SRE [prononcé en anglais] pour les bilingues. Déjà, qu’est-ce que le SRE ?

[00:02:29.630] — Denis : C’est une philosophie, une façon de travailler qui a été inventée par des gens chez Google. C’est assez vieux, ça date de 2003. En fait, il y avait un nouveau service, il fallait le maintenir en condition opérationnelle et ils ont demandé à un VP Engineering chez Google de s’en occuper. Chez Google, c’est surtout des software engineers. La personne en question avait un background de software engineer, pas d’opérationnel. Il s’est dit qu’il allait faire les choses un peu différemment, donc à contre-courant de ce qui se faisait à l’époque. Il a dit qu’il allait faire de l’infra comme le feraient des développeurs. Il y a tout un tas de préceptes qui ont été mis sur papier bien plus tard — en 2016 je crois — dans le “SRE Book” dont on va pouvoir parler. Grosso modo, c’est une philosophie un petit peu différente sur la façon dont on va gérer l’infrastructure, plus comme le ferait un développeur et pas comme le ferait un opérationnel — même si le terme est peut-être un peu exagéré dans l’écrit de Google.

[00:03:27.690] — Vincent : On a beaucoup entendu parler de “DevOps” pendant très longtemps et on va dire que le SRE est une manière de l’implémenter qu’a mis en place Google il y a effectivement, maintenant, quelques années — ça fait pas loin de 20 ans. C’est beaucoup autour de l’automatisation, du suivi d’indicateurs — des choses qui nous paraissent maintenant assez naturelles, on va dire, mais qui ne l’étaient pas quand Google a mis ça en place il y a une vingtaine d’années.

[00:03:52.390] — Loïc : En gros, c’est passer de serveurs gérés à la main, avec des commandes qu’on exécute à la main, soit pour un installer ou mettre à jour, ou généralement plus pour réparer quand ça s’est cassé la tronche, à une approche où l’on automatise, où ce sont des robots qui font ça pour nous et où l’on n’a limite plus besoin de le faire à la main et ça se fait tout seul.

[00:04:14.370] — Denis : Oui, l’ennemi numéro 1 de l’Ops, selon les personnes qui ont créé le SRE chez Google, c’est le travail répétitif, le travail manuel, le travail qui pourrait être automatisé, qui n’a pas de valeur ajoutée. Et ce travail-là, moi qui viens du monde de l’infra avant d’avoir fait du SRE, je l’ai connu. J’ai écrit des procédures pour installer des serveurs dans des Word, dans des documents Docs, où il fallait refaire tout le document dès qu’il y avait la moindre version qui changeait, où il fallait copier-coller les commandes à la main — la moitié du temps, on se plantait, on installait les mauvais trucs. C’était la cata ! Ce monde où les serveurs avaient des petits noms mignons — j’adore cette période mais ce n’était pas du tout efficace. On parle de “pet” versus “cattle”, donc on parlait d’animaux de compagnie avant et maintenant de “cattle”, c’est-à-dire du bétail : ce sont des vaches, elles ont des numéros sur l’oreille et quand il y en a une qui meurt, ce n’est pas grave, on en achète une autre et on la remplace.

[00:05:16.210] — Loïc : Tous les végétariens sont en train de se retourner !

[00:05:18.940] — Denis : Oui ! Malheureusement, ce sont les termes de l’industrie, mais c’est vrai que ce n’est pas très bien pour le bien-être animal.

[00:05:24.780] — Loïc : Mais par contre, on voit bien cette différence de taille. Il y a une dizaine ou une quinzaine d’années, on gérait un ou deux serveurs, ils étaient dans le placard derrière ou potentiellement dans le sous-sol parce qu’on voulait l’avoir pas loin et qu’il fallait mettre la clim. Maintenant, c’est dans des data centers, on parle de centaines et de centaines de machines. Ce n’est plus du tout la même chose. On ne peut plus humainement se permettre d’installer, de configurer ces centaines de machines probablement tous les jours. Avant, on le faisait pour un serveur. C’était possible parce qu’on le faisait une fois dans l’année, une fois dans l’année on faisait une petite campagne de mise à jour. On avait deux machines donc ça allait, c’était humainement gérable. Maintenant, ce n’est plus possible. On ferait ça toute la journée et on n’arriverait encore même pas à suivre les cadences — parce que les machines qu’on rajoute dans des data centers, c’est par palettes entières maintenant. Il faut que ça se fasse tout seul, et comme ça doit se faire tout seul, ça doit s’automatiser. Et les développeurs ont quand même apporté beaucoup de choses pour l’automatisation, avec beaucoup de préceptes — parce que c’est quelque chose que l’on fait depuis longtemps. C’est ce qui s’est infusé dans l’Ops, dans la gestion d’infrastructures, ce qui a justement amené à cette théorisation, de manière à mettre des mots et des règles sur cet entre-deux — entre ce que faisaient les développeurs et ce que faisaient les Ops — histoire d’avoir un langage commun — ce que l’on a souvent appelé DevOps, sans jamais le définir.

[00:06:51.680] — Denis : Oui, c’est ça. Ce que j’aime bien rappeler, c’est que DevOps est arrivé après le SRE. C’est assez amusant puisque nous — en tout cas en Europe — on l’a découvert bien après. C’est-à-dire que Google faisait déjà du DevOps bien avant le DevOps. Devops a été théorisé par un Belge, Patrick Debois, en 2008–2009 il me semble. C’est là où on parle des cycles courts, de tout tester, de donner plus d’autonomie aux développeurs, de rassembler les équipes… Et tous ces préceptes-là, on les retrouve aussi dans SRE. C’est pour ça que les gens confondent souvent un petit peu les deux, puisque les visions sont assez proches. Google avait essayé de brander un peu en disant “SRE implement DevOps”. C’est une façon de dire que c’est la même chose, mais fait différemment.

[00:07:39.400] — Stéphane : Et du coup, quelle est la place du SRE dans une entreprise de développement logiciel, et notamment chez Deezer ?

[00:07:46.140] — Vincent : Je dirais que ça va un peu dépendre des visions. Souvent, on imagine surtout que le SRE devrait être — en tout cas, c’est notre position, ce que l’on essaie de pousser mais ce qui est assez compliqué dans les organisations, c’est de se dire que le SRE devrait être au cœur de l’équipe. C’est-à-dire que contrairement à des équipes d’infrastructures vraiment très “platform” où l’on va avoir des gens qui s’occupent de racker des serveurs, de mettre à disposition des choses, etc., le SRE a plutôt comme vocation d’essayer d’être en accompagnement des équipes de développement et d’essayer de les accompagner dans le quotidien d’une application, dans la maintenance d’une application et d’essayer de les aider à suivre des métriques, à mettre en place de l’automatisation, etc.

[00:08:28.710] — Loïc : Oui, apporter des concepts pour les aider. Dans le développement, on a beaucoup de pratiques qui viennent naturellement parce qu’on a l’habitude, on va développer, on va coder, on va envoyer notre programme sur le serveur pour le faire tourner. Et comme on l’a dit, ça n’est plus possible aujourd’hui. Du coup, on a des nouveaux outils pour pouvoir mettre le code qu’on a compilé en production. Mais ces nouveaux outils viennent aussi avec leurs contraintes, leurs complexités, parce que l’on ne compile plus nous- mêmes les binaires que l’on envoie en production par exemple. Il y a toute une chaîne qui a été mise en place pour le faire, mais c’est une chaîne qui, pour un junior par exemple, ou pour un développeur qui ne connaît pas ces chaînes-là, nécessite d’être apprivoisée, d’être comprise et d’être un peu manipulée pour pouvoir être utilisée efficacement. Ça vient aussi avec certaines pertes : là où avant, le développeur pouvait potentiellement envoyer en prod et observer en production directement au travers de logs ou au travers d’accès directs parfois, maintenant on va avoir des outils intermédiaires pour faire du debugging, du monitoring, etc. Et pareil, il faut apprendre à les utiliser efficacement pour en tirer tout le bénéfice, pour se rendre compte que notre projet fonctionne bien — ou pas — quand on l’envoie en production.

[00:09:49.540] — Pauline : Comment se matérialise cet accompagnement, concrètement ?

[00:09:53.140] — Loïc : C’est la grande question, je pense. Il y a une part purement technique de connaissance et de capacité à être entre les deux milieux. On parle de DevOps et le mot en lui-même, c’est “Ops” et “Dev” accolés ensemble. L’idée, c’est d’avoir un set de compétences et de connaissances sur les deux aspects, sans forcément être parfait dans les deux. Il y aura toujours des experts des deux côtés et c’est normal. Par contre, avoir suffisamment de connaissances pour faire le pont permet justement d’avoir le dialogue. C’est ça, je pense, qui est le plus important. Comme disait Vincent, d’être dans les équipes et d’être capable de parler avec les équipes de développement. C’est donc avoir le dialogue, les mots, la pédagogie pour pouvoir discuter avec des développeurs, tout en ayant aussi la capacité d’avoir les mots, d’avoir la pédagogie, de discuter avec des opérationnels. C’est faire ce pont entre ces deux mondes qui… On a tendance à troller en disant qu’ils sont irréconciliables. Mais l’idée, c’est justement de les réconcilier, de faire en sorte que les deux avancent en même temps. Et donc, c’est être concrètement dans les équipes, transmettre les problématiques des Dévs aux Ops, transmettre les problématiques des Ops aux Dévs, transmettre les nouveaux concepts qui permettent à la fois aux Ops et aux Dévs de comprendre les deux autres aspects.

[00:11:08.710] — Denis : Le rôle du SRE, finalement, c’est d’être l’évangéliste de toutes les bonnes pratiques, aussi bien les bonnes pratiques de dév que les bonnes pratiques des opérationnels. Quand on va dans les équipes, on est un petit peu le consultant, on est un petit peu la personne qui va permettre de réparer les petits problèmes, de s’assurer que tout est bien sécurisé, que tout est bien surveillé, monitoré. C’est la personne qui va amener aux équipes le petit bout de compétence qui leur manque pour délivrer du logiciel de meilleure qualité, et donc plus fiable. Puisque c’est ça le but, c’est de rendre l’infrastructure et le site plus fiables.

[00:11:47.240] — Stéphane : Je reviens sur ce que tu disais tout à l’heure, Vincent. Tu as fait la différence entre SRE et SRE Proxy. Est-ce que justement, cette proximité s’apparente à… ?

[00:11:57.190] — Vincent : C’est ça. Chez Deezer, on a séparé deux rôles qui sont normalement assez liés. Typiquement, comme le disait Loïc tout à l’heure, on est issu, lui et moi, du monde du dév. On est plus proche des équipes de développement, avec une appétence pour tout ce qui est système et tout ce qui est installation, mais c’est vrai que l’on ne vient pas forcément de l’ops. En ça, on retrouve un peu la démarche de Ben Treynor Sloss quand il a mis en place son équipe SRE chez Google il y a une vingtaine d’années. Nous, on est plutôt orienté dév et on n’a pas forcément vocation à s’occuper de la plateforme, à être d’astreinte par exemples — les SRE, normalement, ont cette notion d’astreinte. On a plus cet objectif d’être proche des équipes. Loïc et moi sommes normalement rattachés à certaines équipes en particulier, pour justement comprendre leurs problématiques, essayer de discuter avec eux, leur amener l’évangélisation autour de tous les principes du SRE — l’observabilité, la délivrabilité, etc. — là où pour l’instant, côté SRE, ils ont aussi en charge la plateforme — donc la mise à disposition de la plateforme — tout en n’étant pas complètement éloignés des développeurs. Voilà, on fait un peu ce pont à l’heure actuelle.

[00:13:12.450] — Denis : Oui, dans l’équipe dans laquelle je travaille, on est vraiment très proche des serveurs, très proche des stacks de bases de données ou des middlewares, et on s’apparente probablement plus à ce que l’on appellerait aujourd’hui une équipe “platform”, même si ce sont des labels que l’on colle sur des gens. Mais si certains d’entre vous ont lu le livre “Team Topologies”, ça serait plus une équipe platform, même si je me sens totalement SRE comme mes deux collègues. Eux sont peut-être plus ce que l’on appelle des SRE au jour le jour.

[00:13:44.050] — Vincent : Voilà, dans “Team Topologies”, on serait les “Enablers”.

[00:13:46.500] — Denis : Oui, les “Enablers”, exactement.

[00:13:57.530] — Stéphane : Quels outils utilise-t-on chez Deezer pour réaliser cette mission ?

[00:14:01.430] — Loïc : Il y en a plein. Il y a plein d’objectifs. Je pense qu’il faut découper en différents objectifs. On a parlé de fiabilité, on a donc besoin d’outils pour pouvoir mesurer cette fiabilité. Dans les outils que l’on a, il va y avoir des stacks de monitoring par exemple, où l’on va mettre en place les outils nécessaires pour que les équipes, quand elles produisent un logiciel, soient en mesure de savoir si ce logiciel fonctionne correctement, de remonter des statistiques, des logs, des outils comme ça. Si je donne deux ou trois noms, à Deezer, on utilise un truc qui s’appelle Prometheus pour tout ce qui est remonté de métriques, et on utilise la traditionnelle stack ELK — un peu tweaked on va dire — pour la remontée de logs. Et après, là où le rôle des SRE devient important, c’est sur le comment on utilise ces outils. Parce que les outils sont mis en place, comme le disait Denis, par l’équipe “platform”, les outils sont disponibles. Mais il ne s’agit pas juste d’envoyer des logs et puis c’est bon. Il faut les monitorer. Il faut envoyer les bons logs, il faut les monitorer de la bonne manière, il faut potentiellement mettre en place de l’alerting pour être au courant quand il y a un problème. Pour du log, ça peut être détecté quand un log en particulier arrive. Par exemple, si l’on gère une plateforme de paiement, on peut peut-être avoir le nombre de paiements refusés et être notifié si ce nombre de paiements refusés augmente significativement pendant une courte période de temps. C’est là où l’on va se rendre compte qu’après on va avoir plein d’autres questions. L’exemple que je viens de vous donner est un exemple très fonctionnel, c’est très produit. On a un produit : c’est faire du paiement. On a besoin de savoir si ce produit fonctionne pour faire du paiement. Mais là où les équipes vont avoir parfois des questions beaucoup plus techniques — avant même de savoir si le service fait du paiement correctement, il faut déjà savoir si le service répond, par exemple, aux requêtes qu’on lui envoie. Donc on va aussi avoir besoin de monitorer les temps d’accès, le nombre d’accès, les temps de réponse… Et l’idée, c’est que nous, on arrive avec tout un tas d’éléments de base qu’on va donner aux équipes pour qu’elles les suivent, de manière à ce qu’elles aient, presque clé en main, un jeu d’outils prêts à monitorer une application. Donc une équipe, demain, quand elle crée un nouveau service en interne, une nouvelle application, saura qu’il faut mesurer… On fait beaucoup de web services, donc ça veut dire mesurer le nombre d’appels HTTP, mesurer le temps de réponse, le nombre d’appels par retour HTTP, notamment le nombre d’erreurs, etc. On en parlera peut-être après, mais tout cela est déployé sur une plateforme Kubernetes, donc il faut aussi mesurer comment ça fonctionne sur la plateforme en elle-même — combien de nodes sont opérationnels, combien ont eu des crashs, etc. Notre objectif, c’est de fournir une espèce de base qui, une fois qu’elle est remplie, permet d’avoir une sorte d’état des lieux d’une application satisfaisant pour pouvoir dire si cette application est opérationnelle ou non, et dans le temps, est-ce qu’elle a été opérationnelle ou non de manière satisfaisante aussi. Parce qu’une application, ça vit. Les développeurs travaillent dessus et il y a des moments où elle peut très bien fonctionner, puis des moments où les développeurs vont faire beaucoup de changements et elle fonctionnera moins bien. C’est intéressant de le savoir et de savoir réagir en conséquence.

[00:17:28.840] — Denis : C’est super parce que tu introduis un autre point hyper important de la théorie du SRE, l’un des piliers du Site Reliability Engineering : c’est le fait que — et c’est aussi présent dans DevOps — les incidents, ça arrive et c’est normal. Et comme c’est normal et comme on sait que ça va arriver, il faut déterminer pour chacun de nos services — un service, ça va être un petit bout de logiciel, tu parlais du paiement tout à l’heure — pour chacune de ces briques logicielles qui composent notre produit, à partir de quand les utilisateurs vont déterminer que le service fonctionne mal. C’est le truc que j’ai eu le plus de mal à accepter quand je suis devenu SRE. C’est le fait que ça ne sert à rien de faire une plateforme la plus solide possible, qui ne plantera jamais, parce qu’elle finira toujours par planter. Il y aura toujours un moment où vous n’aurez pas prévu le truc, etc. Ça va planter. Et donc, tout ce temps d’ingénierie que l’on va mettre à essayer de fiabiliser un système qui, de toute façon, finira par planter, c’est du temps perdu. C’est de la fonctionnalité que vous ne pouvez pas donner à vos utilisateurs. Et en l’occurrence, là, mes utilisateurs ne sont pas les utilisateurs finaux, ce sont les développeurs. Une fois que l’on a dit ça, il faut que l’on prenne le problème à l’envers. À partir de quand mes utilisateurs décident-ils que le service ne marche pas bien ? En vrai, les utilisateurs peuvent être assez tolérants, plus qu’on ne le croit. Parce que moi, si je me connecte à Deezer sur mon téléphone portable et que Deezer plante, je vais me demander : “Est-ce que c’est mon smartphone qui bugue ? Est-ce que c’est l’appli qui bugue ? Est-ce que c’est la 4G qui bugue ? Ou est-ce qu’il y a vraiment un souci sur l’appli Deezer elle-même ou sur le site ?” Le temps que je me pose cette question, si le service a déjà été rétabli, je m’en fiche en tant qu’utilisateur. Si jamais j’ai passé trop de temps à fiabiliser ce système, c’est du temps que je n’ai pas passé à faire autre chose, à permettre à mes développeurs d’aller plus vite, à permettre de sortir de nouvelles fonctionnalités, des trucs qui sont différenciants, qui vont faire que du côté de la concurrence, ils vont être complètement largués et que les utilisateurs vont préférer notre produit. Donc, en fait, pour ceux qui connaissent un petit peu le Joueur Du Grenier — peut-être que parmi nos auditeurs, il y en a certains qui le connaissent — être SRE, finalement, c’est un petit peu le David Goodenough de l’infrastructure. On essaye de faire juste bien. Et j’en arrive à mes métriques dont on parlait tout à l’heure — désolé, c’était un petit peu long — pour chacun de mes services, je vais déterminer à partir de quand mes utilisateurs ne sont pas contents. Ça va être une métrique, je vais me fixer un objectif dessus. Si je veux que 99 % des requêtes répondent en moins de 40 millisecondes sur une période de temps donné — ce que l’on fait assez régulièrement — ça veut dire qu’il y a 1% des requêtes qui peuvent échouer, et ce n’est pas grave. Ça va être ce que l’on appelle notre “error budget”. On prend le problème à l’envers en fait, c’est-à-dire qu’au lieu d’essayer de viser un niveau de disponibilité, on vise un niveau d’indisponibilité. À partir de là, ça va être super intéressant parce que ça va nous permettre de faire tout un tas de choses dont on se privait avant. On va pouvoir faire des tests dangereux, on va pouvoir faire des maintenances qui vont provoquer des interruptions. Mais tout ça, ce n’est pas grave parce que si ça casse, tant que l’on est dans notre error budget, tant qu’on ne l’a pas cramé, ça veut dire que nos utilisateurs ne sont pas mécontents. Donc ils sont contents.

[00:20:34.990] — Vincent : Je pense que c’est un truc sur lequel on essaie de sensibiliser les personnes du Produit : tant que l’on est dans notre error budget — ce que tu dis — on peut casser des choses, on peut tenter des trucs, on peut innover même. C’est-à-dire que quand une feature doit sortir, tant que l’on reste dans cet error budget, on peut se permettre de faire des choses. Après, cet error budget est plus ou moins grand selon la criticité de l’application, de la feature, etc., évidemment, mais on peut innover. Par contre, dès que l’on dépasse cet error budget, c’est là que l’on vient dire : “OK, on a dépassé notre tampon, donc maintenant il faut fiabiliser le service.” Et c’est là qu’on peut avoir une discussion directement avec des personnes du Produit par exemple. C’est toujours un peu compliqué d’avoir des discussions entre Tech et Product, parce que l’on n’a pas forcément les mêmes enjeux, surtout quand on est côté plateforme. Là, on peut leur dire clairement — c’est même quelque chose que l’on négocie avec eux, c’est-à-dire que quand on va les voir, on leur dit… Ça m’est déjà arrivé, sur certains projets, de dire : “Écoute, on va mettre en place un certain nombre d’indicateurs. Dis-moi, toi — ce que tu disais, en fait, Denis — dis-moi, toi, à partir de quand on considère que la feature est vraiment dysfonctionnelle ? Et on se rend compte que parfois, et j’étais même très surpris, sur certains projets, de me dire : “Instinctivement, je me serais mis un objectif vraiment très haut par rapport à ce que le Produit attend.” Parce que l’on est sur une feature qui n’est pas forcément très attendue ou parce que l’on est sur le début, on est sur un POC, donc on peut se permettre de rater, on est sur une bêta, etc. Il y a plein de raisons qui peuvent faire que l’on ne se mette pas des objectifs très compliqués. Ça m’est arrivé d’avoir un objectif où j’avais mis un 9, c’est-à-dire avoir 90% de disponibilité — donc 10% potentiel d’indisponibilité — juste parce que c’était une future qui était, au lancement, pas critique. Et moi, j’étais parti sur un 99 ou un 99,9. C’est aussi l’intérêt de ce genre de métrique, de pouvoir justement échanger avec des gens du Produit et de se dire : “C’est quoi un service qui marche ? C’est quoi un service qui ne marche pas ?” Ce n’est pas juste : “Mon service doit répondre en moins de 100 millisecondes”. Non, c’est : “Dis-moi ce que tu attends de la feature et de la plateforme. Et derrière, on le décline en choses un peu plus “techniques”, de savoir en combien de temps doit répondre le service, quel est le taux d’erreur que l’on peut accepter, etc.

[00:22:43.060] — Loïc : Si on reprend l’exemple, on peut très bien imaginer mettre des budgets d’erreur totalement différents. Sur le paiement, par exemple, on pourrait se dire que ça reste important. On va mettre un budget d’erreur assez faible et peut-être que, comme le dit Vincent, sur une fonctionnalité expérimentale, voire une fonctionnalité que seulement 5% des utilisateurs utilisent, on va être plus tolérants. Ça permet de varier, et de manière indirecte, ça permet aussi de varier le coût. Parce que rendre fiable à 100% quoi que ce soit, ça a un coût théoriquement infini. À un moment donné, il faut réduire ce coût à quelque chose qui est soutenable pour l’entreprise ou l’entité qui produit le logiciel. Ça permet de faire varier ce coût et parfois, on peut aussi prendre des décisions qui ne sont, certes, pas en faveur de l’utilisateur. Je vais prendre un exemple un petit peu extrême. Je suis des blogueurs qui hébergent leurs blogs sur des Raspberry Pi alimentés par des panneaux solaires et dans leur budget d’erreur, c’est : pas de soleil, pas de blog. Certes, l’utilisateur final n’est pas content parce qu’il n’y a pas de soleil, il ne peut pas accéder au blog. Mais c’est considéré comme acceptable parce que l’on a fait varier les coûts — là, c’est un coût énergétique direct — pour dire : “Je n’ai pas de quoi assurer ou je ne souhaite pas — parce que c’est un souhait plus qu’une possibilité — assurer la disponibilité du service au-delà d’un certain coût.” Du coup, ça coupe. Sans forcément aller jusqu’à cet extrême — parce que là, on parle de blogs souvent libristes qui sont plus anecdotiques — pour un service donné, ça peut très bien se faire. Si on reprend l’exemple énergétique, l’année dernière, il y a eu des tensions énergétiques, notamment en France et en Europe. On peut très bien se dire que l’on change ses budgets d’erreur pendant cette période sur certains aspects pour conserver une partie de l’énergie — ce qui permet de couper des serveurs. Mais de manière indirecte, couper des serveurs, c’est réduire la fiabilité globale.

[00:24:51.550] — Pauline : On a évoqué différents concepts SRE : on a parlé de budget d’erreur, on a parlé d’automatisation des tâches répétitives. Est-ce qu’il y a d’autres concepts qui sont propres au SRE ?

[00:25:06.680] — Loïc : L’un des principes que l’on pousse à Deezer — et je ne saurais pas dire si c’est intrinsèque au SRE ou pas — c’est l’autonomisation des développeurs : le fait qu’un développeur ait de moins en moins — voire plus du tout — besoin d’une personne avec à la fois des privilèges d’autorisation et des connaissances techniques différentes des siennes — donc principalement des Ops généralement — pour faire évoluer, déployer, créer, tester… Et pour ça, on a besoin d’outils. Pour permettre cette autonomisation, on peut parler de Kubernetes, on peut parler de Docker notamment. Pour faire simple, il y a quelques années, ce qu’un développeur livrait, c’était du code source, peut- être parfois du binaire, mais bien souvent, l’objectif était de livrer une version d’un code source qui allait être buildé dans une CI (Continuous Integration), qui allait donc construire un build qui allait souvent être déployé par des Ops justement. On a un petit peu changé ça depuis quelques années. Le livrable est passé de code à une image Docker. L’intérêt de changer ça, c’est que l’image Docker vient à la fois avec le code ou le binaire, et une partie de l’infrastructure. Et il y avait notamment beaucoup de conflits. Nous, à Deezer, on est en PHP, donc les conflits les plus fréquents étaient par exemple : “sur mon environnement de développement, j’ai tel module qui est installé sur PHP, j’ai telle version de PHP, et en production pas du tout”, “je n’ai pas le module GD, il n’était pas installé en production” ou “ce n’était pas la bonne version”. Du coup, j’avais des problématiques de bugs qui étaient relativement fréquentes parce qu’il y avait des divergences entre mes environnements de production et de développement. Docker permet de résoudre beaucoup de ces problèmes-là parce que maintenant, ce que je donne à livrer contient toutes ces dépendances ou une grande partie de ces dépendances. Mais pour pouvoir faire ça, il y a eu besoin de déployer ces containers, ces images Docker, en production. Et c’est là où Kubernetes notamment — qui, maintenant, est quand même la réponse hégémonique à cette problématique d’orchestration d’images Docker — est venue résoudre, mettre une interface technique entre les Ops qui vont fournir la plateforme — plateforme qui rend le service de déployer des containers — et les développeurs qui vont être capables d’appeler cette plateforme, de l’utiliser pour pouvoir déployer des containers. Et ça va notamment leur permettre de déployer des containers sur des applications qu’ils connaissent, mais potentiellement des nouvelles applications aussi pour pouvoir faire des tests, pour tester des nouvelles fonctionnalités, pour tester des nouveaux éléments techniques, peu importe. Ça permet d’avoir un langage qui est à la fois technique et presque “humain”. On va parler beaucoup de containers, de tous les langages qui sont autour de Kubernetes, entre les Ops et les Dévs. Il y a des Dévs qui vont avoir la capacité de quasiment tout faire tous seuls. Et quand il y a besoin de discuter avec des Ops parce qu’il y a des trucs qui nécessitent plus de compréhension ou des trucs un peu exotiques, il y aura un langage qui permettra de discuter, qui sera beaucoup plus standardisé — standardisé, parce que techniquement mis en place dans un logiciel.

[00:28:25.020] — Denis : Ce que j’ai trouvé vraiment intéressant avec l’arrivée de Docker — parce que tu en parles — c’est que c’est vraiment l’outil, je pense, qui a le plus aidé les développeurs à faire, avec du code, de l’infra. Parce que finalement, le Dockerfile — donc le fichier que livre le développeur — qu’est-ce que c’est ? C’est un fichier texte qui dit : “Qu’est-ce que je veux comme dépendance ? Où est-ce que je mets le binaire qui a été construit par ma CI ? Comment je package tout ça — donc le binaire et ses dépendances ou le code et ses dépendances, peu importe — et comment je l’envoie en production ?” Ça, c’était vraiment la première étape. Il y avait d’autres outils pour faire de l’infrastructure as code avant Docker, mais pas vraiment utilisés, en tout cas pas de manière hégémonique par les développeurs. Docker est arrivé autour de 2014, si je ne dis pas de bêtises, et a vraiment changé radicalement la façon dont les Dévs ont vu l’infrastructure. D’un coup, d’un seul, ils n’avaient plus besoin de demander — parce que ça aussi, je l’ai vécu — un serveur web qui mettait trois semaines à être livré par les Ops. Et le temps que les Ops livrent le serveur web dans leur catalogue de templates, la version était déjà obsolète. Donc ça, c’était fini, les développeurs avaient la main là-dessus. Le problème, c’est que les Ops, pendant un moment — moi compris — ont voulu mettre un coup de frein parce que derrière, qu’est-ce qu’on en fait de ce container ? C’est pour ça que des outils comme Kubernetes sont arrivés, comme tu le citais. Et là, on va encore plus loin dans la description de l’infrastructure. Non seulement, on décrit avec le Dockerfile l’appli et son environnement d’exécution, mais avec Kubernetes, on va beaucoup plus loin. On va déployer, on va décrire des load balancers, des reverse proxies, des disques, des réplicas — combien je veux en envoyer. Tout ça est géré par des API. C’est manipulé avec du YAML — on peut dire ce qu’on veut sur le YAML ou pas, mais il y a quelque chose de magique dans le fait de monter toute une infrastructure avec quelques dizaines ou quelques centaines de lignes de YAML. Pour quelqu’un qui vient du monde de l’infra, pour moi, c’est vraiment magique. C’est un truc incroyable ! Ça gère la haute dispo automatiquement… Donc, Kubernetes, c’est vraiment : donner la main, les clés du camion, de l’infrastructure aux développeurs. Ça vient avec d’autres contraintes parce que les bonnes pratiques de sécurité, les bonnes pratiques de fiabilité que les Ops avaient, les développeurs ne les ont pas forcément. Donc si on leur donne de l’autonomie, il faut aussi soit les éduquer, soit les guider. Et on en revient encore au rôle d’évangéliste du SRE. Il est là pour apporter toutes ces bonnes pratiques que n’ont pas forcément des développeurs parce que ce n’est pas leur métier, parce qu’ils n’ont pas besoin de savoir tout non plus et ils n’ont pas forcément intérêt d’ailleurs — il vaut mieux être bon en un seul domaine que nul en tout, c’est quand même mieux ! Donc Kubernetes est vraiment l’outil qui va nous permettre de donner de l’autonomie aux développeurs. Ça ne fait pas tout. Il y a encore des fois où les gens de l’infra — ou “platform”, peu importe comment on l’appelle — sont sur le chemin critique. Récemment, avec des collègues, on a fait un atelier Mikado où l’on a essayé de prendre toutes les tâches qu’il fallait pour créer une nouvelle application en tant que développeur, en se plaçant dans le contexte le plus défavorable possible. Toutes les tâches que l’on a vues, qui sont potentiellement pour certaines avec l’infrastructure sur le chemin critique, qui ralentissent la vélocité des développeurs, on a essayé de les automatiser, de les réduire, de les rendre plus simples, de manière à donner encore plus d’autonomie aux développeurs. Et plus on leur donne d’autonomie, moins on passe de temps à travailler là-dessus. C’est plus de temps pour mettre en place d’autres outillages, pour justement s’assurer que les bonnes pratiques, par exemple, sont respectées — notamment les bonnes pratiques de sécurité, avec de l’outillage qui va vérifier que les conteneurs ne tournent pas avec des privilèges trop importants, que l’infrastructure qui est déployée avec le YAML dans Kubernetes correspond bien à nos standards… Finalement, c’est un cercle vertueux. Le SRE est vraiment dans cette optique de ne pas perdre du temps sur des choses qui n’ont pas de valeur et de passer justement le plus de temps possible pour délivrer de la valeur pour les développeurs.

[00:32:29.260] — Loïc : Et les pratiques qu’avaient les Ops, notamment quand on parle de sécurité, c’est quand même un truc assez fondamental dans les équipes Ops de gérer la sécurité d’un service, ce n’est pas quelque chose qui est facile à faire et en plus, c’est quelque chose qui change du jour au lendemain parce qu’il y a des informations qui sont révélées parfois, qui nécessitent des opérations conséquentes sur beaucoup d’aspects de l’infrastructure. On peut penser aux failles Heartbleed et compagnie, ou à la plus importante peut-être récemment, Log4j, qui a nécessité que les Ops et les Développeurs se parlent et se synchronisent pour se débarrasser de cette vulnérabilité.

[00:33:09.180] — Denis : Qui était présente quasiment partout.

[00:33:10.610] — Loïc : Oui, qui était vraiment à tous les étages, même si on n’utilisait pas de Java. Ça permet notamment d’améliorer la qualité de la sécurité en soi. Parce qu’encore une fois, les outils que l’on met en place sont automatisés et vont se mettre, de manière un petit peu “froide”, à tout analyser. Là où avant un opérationnel maintenait ses serveurs à jour, s’assurait de la sécurité et regardait, presque à l’œil nu, l’état de sa plateforme en termes de sécurité, maintenant on a des robots qui passent et qui, à la moindre librairie qui a une CVE (Common Vulnerability & Exposure) qui est déclarée quelque part — une librairie Python, Node, PHP, peu importe — remontent une alerte. On le sait quasiment tout de suite. Les Ops peuvent le savoir mais surtout, ça redescend quasiment directement — ou ça peut redescendre directement — jusqu’au développeur qui est concerné, qui a utilisé cette librairie qui a une vulnérabilité. Le développeur peut avoir une action dessus directement, sans même que l’Ops aille s’inquiéter réellement du sujet. Donc on a toujours les cas un peu génériques comme Log4j, qui était vraiment un cas exceptionnel, mais les vulnérabilités de sécurité ne sont pas vraiment ces exceptions-là, ce sont plutôt la myriade de vulnérabilités qui ont lieu partout dans un système complexe, qui sont très difficilement mesurables. Et en fait, on a même permis d’améliorer la sécurité là où c’est contre intuitif, parce que Kubernetes, avec Docker notamment, est souvent crié pour son aspect non sécuritaire d’un point de vue technique : ça ouvre beaucoup de failles de sécurité à plein d’endroits et ce sont des critiques qui sont réelles et justifiables — justifiées même — pour autant, ça permet de systématiser énormément de comblements de trous de sécurité par ailleurs. Donc la balance finale, l’apport en termes de sécurité, est probablement plus en faveur de ces outils-là, si traité convenablement et si les équipes Ops ont le temps de mettre en place ce qui est permis par l’autonomisation des développeurs — ça leur permet d’avoir le temps de mettre en place tous ces outils. À la fin, je pense que l’on a même une meilleure sécurité de nos plateformes malgré la complexité qui, elle, est incommensurable par rapport à ce que l’on avait il y a vingt ans.

[00:35:14.920] — Vincent : L’enjeu est de se dire que c’est de l’autonomie que l’on donne aux développeurs, mais par contre, c’est aussi de la responsabilisation. Et du coup, il y a aussi un accompagnement. Il faut vraiment aller vers eux pour leur dire : “Maintenant, c’est ton application.” C’est le fameux “You build it, you run it”, c’est-à-dire que vous créez les applications, vous les déployez, etc. mais par contre, vous gérez aussi les montées de version, ce qui tourne réellement en production, ce que vous envoyez avec votre application. C’est aussi un changement de mindset qui n’est pas toujours évident à faire passer. C’est vrai qu’il y a beaucoup de développeurs qui sont en mode : “moi, je veux juste délivrer ma feature, je clique sur le bouton, c’est en prod.” Oui, mais tout ça, ce sont des choses qu’il faut prendre en compte. Après, ce sont aussi des choses sur lesquelles ils ont plus de liberté. Typiquement, on parlait de montée de version — d’un framework, d’un socle technique, peu importe — ce sont des choses sur lesquelles ils ont la main, ce qui n’était pas le cas avant. Avant, comme le disait Denis, il fallait attendre, il fallait que le serveur soit livré, que la bonne version de PHP, par exemple, soit dessus, avec les bons modules, etc. Avant, c’était compliqué, ça demandait de la synchro entre équipes, etc. Maintenant, ce sont eux qui peuvent faire la montée de version dans leur coin, vérifier que ça marche et si ça marche, ils livrent en prod et c’est fini.

[00:36:29.660] — Stéphane : Je pense que vous avez commencé à les dresser un peu, mais si vous deviez résumer, quels sont les principaux challenges que vous avez à relever en tant que SRE et les pièges que vous avez à éviter ?

[00:36:50.260] — Vincent : Le premier, c’est vraiment le syndrome : “Non, je ne veux pas savoir comment ça tourne, je livre mon code et il faut que ça marche.” C’est vraiment le truc le plus compliqué à bypasser dans la logique des gens. On met toujours en balance ce côté : “Oui mais en faisant comme ça, tu auras plus de fluidité, tu pourras livrer plus souvent et tu seras maître de ton truc. C’est ton service, tu livres ce que tu veux, avec le socle que tu veux. Si tu veux passer en PHP+++ à la sortie du langage, libre à toi.” Ce qui n’était pas le cas avant. Avant, on ne sortait que sur des versions bien stabilisées, qui étaient maîtrisées par les équipes de la plateforme, etc. Donc le plus gros problème, c’est vraiment ça, le “moi, ça ne m’intéresse pas de savoir comment ça tourne, je livre ma feature et je veux que ça marche.” Et en même temps, quand ils avaient un problème en production avant, ils n’étaient pas capables de l’observer, ils n’avaient pas de capacité à suivre les régressions de leurs bugs, etc. Il y a beaucoup de choses qui ont été apportées par ces principes, à la fois du DevOps et du SRE, qui nous permettent d’avoir une espèce de levier pour dire : “On te donne les moyens d’aller plus loin et de faire ce que tu as envie de faire. Ça vient avec la “contrainte” avec de grands guillemets — puisque ce ne sont pas non plus des contraintes de fou — de suivre ce que tu envoies en production.”

[00:38:17.410] — Loïc : J’ai tendance à comparer ça à une évolution de nos métiers. Il y a une vingtaine d’années, le développeur faisait tout, de l’interface jusqu’à la gestion de la base de données quasiment. Maintenant, on a des équipes qui sont très spécialisées : on a des développeurs front-end web, des développeurs mobile iOS / Android, des développeurs back-end, parfois on a même des développeurs back-end Go / Python… Nos métiers ont évolué. Par contre, les principes SRE sont communs à tout le monde. On les applique de la même manière pour quasiment toutes les équipes — ou en tout cas, c’est l’objectif — parce qu’on veut les mêmes bénéfices. Mais ça vient avec les mêmes inconvénients, on va dire. Donc, effectivement, tous les corps de métier se sont vus avoir une évolution qui ne les concerne pas directement de prime abord, nécessaire pour travailler dans des environnements comme celui de Deezer, pour pouvoir assurer la qualité, la fiabilité et la sécurité notamment. Ce qui veut dire que dans une entreprise comme Deezer, qui doit gérer une plateforme et une application très complexes à l’échelle humaine, il faut impérativement monter en compétence sur certains aspects. On parlait notamment de certains outils qui sont devenus hégémoniques — Kubernetes en est un. On peut tout faire pour essayer de le rendre le plus facilement utilisable mais, comme je le disais, ça reste un langage commun avec les différents niveaux d’équipes ou de personnes, et même si l’on peut faire de l’abstraction, à un moment donné, ça restera le langage de discussion. L’équipe front-end, par exemple, va devoir déployer son application React, et pour la déployer et la rendre disponible à des clients, à un moment donné, il faut la mettre sur des serveurs et il va falloir que l’équipe front-end parle avec les Ops pour dire : “Où est-ce que je mets mon application ?” “Tu utilises Kubernetes et tu as les outils pour le faire.” Ça veut dire qu’il faut les apprendre, il faut les utiliser, alors même que l’on pourrait se dire qu’un développeur front-end n’a rien à faire avec un serveur. Mais en fait, c’est une approche qui est intrinsèque à son métier d’aujourd’hui. Certes, ce n’était pas comme ça il y a vingt ans, maintenant, ça l’est — ou en tout cas, ça l’est dans des contextes tels que des applications comme Deezer. Ce qui veut aussi dire qu’il y a des contextes qui ne nécessitent pas tout ça. Le SRE n’est pas…

[00:40:35.380] — Denis : Ce n’est pas une réponse universelle.

[00:40:36.530] — Loïc : Oui, voilà, c’est ça. Il faut à chaque fois l’adapter et on ne peut pas mettre en place, par exemple, un Kubernetes pour une application monolithique avec cinq utilisateurs pour faire un site vitrine d’une boucherie. Je pense que ce n’est pas très utile, pas forcément proportionné. Par contre, si vous êtes une plateforme qui héberge des sites web et que vous faites les sites de toutes les boucheries du monde, peut-être que ça devient intéressant et nécessaire de l’apprendre. J’ai tendance à comparer ça… Dans le passé du développeur, il y a un autre changement qui est devenu assez hégémonique, c’est celui de l’utilisation de gestionnaires de code, et notamment d’un gestionnaire de code en particulier. Il y a vingt ans, on uploadait nos fichiers, on avait des versions finales, des versions finales V2, etc., on envoyait tout ça par mail et par FTP. On a fait évoluer tout ça vers des gestionnaires de code comme SVN, CVS ou d’autres. Aujourd’hui, quoi qu’on dise, il y en a un qui a gagné, c’est Git. Il est utilisé partout et ça ne viendrait pas à l’idée d’un développeur Cobol, front-end ou PHP de dire : “Non, ce n’est pas mon métier, je n’ai pas à apprendre Git.” Ça fait partie des outils. J’ai besoin de connaître un minimum Git pour pouvoir travailler en tant que développeur aujourd’hui dans certains contextes. Si c’est un projet perso, peut-être que je n’en ai pas besoin, mais dans le contexte professionnel, c’est le cas.

[00:41:57.600] — Denis : Cet exemple est assez drôle parce que cette critique de gens qui ne veulent pas apprendre Git, on la retrouve chez les opérationnels, justement. Je vois un peu un parallèle… D’une certaine manière, il y a les développeurs qui, avant, il y a très longtemps, connaissaient très bien l’infrastructure puisque, comme tu le disais, ils étaient obligés de faire tout, de la cave au grenier. On s’est ultra spécialisé. On a séparé les équipes, d’abord entre opérationnels, puis après développeurs. Et puis après développeurs, c’est devenu, comme tu dis, back-end, front-end, extrêmement spécialisé. Du coup, parfois, il y a des développeurs — pas forcément chez Deezer — qui disent : “Non, désolé, l’infrastructure, ce n’est pas mon boulot. Je n’ai pas envie de savoir sur quel port tourne mon application.” Au même titre que moi, parfois, j’entends aussi des opérationnels dire : “Non, je ne vais pas apprendre Git, je ne suis pas développeur.” En fait, si. On est dans un monde aujourd’hui où savoir manier Git fait partie des compétences que l’on attend aussi d’un opérationnel. Et à l’inverse, savoir manier les concepts basiques de l’infrastructure, des cloud providers ou autre — parce qu’on a parlé beaucoup de Kubernetes mais il y a d’autres façons de le faire — sont des choses qui sont aussi attendues des développeurs. Au moins de comprendre les concepts.

[00:43:09.160] — Loïc : Et l’équipe SRE est là pour aider, en gros. On est là pour faire monter en compétence tous les développeurs ou toutes les personnes qui le souhaitent sur ces concepts-là, de manière à ce qu’à la fin, les développeurs aient les compétences suffisantes pour pouvoir dialoguer avec une personne Ops au sujet des outils techniques qu’on utilise et des process qu’on peut avoir.

[00:43:29.810] — Vincent : Le mot-clé, c’est l’accompagnement. À la fois, on donne des guidelines, on essaie de donner des outils, etc. et en même temps, il faut accompagner les gens pour les amener à ce que l’application tourne réellement, et faire en sorte que, petit à petit, les équipes soient de plus en plus autonomes pour le faire, leur donner les outils pour qu’il y ait de moins en moins d’adhérence avec les équipes plateformes, les SRE, etc.

[00:43:52.540] — Pauline : Et justement, comment peut-on mesurer l’impact d’une équipe SRE ?

[00:43:56.920] — Denis : Si le site ne tombe pas trop souvent en panne ?

[00:43:59.210] — Vincent : C’est ça ! Dans “SRE”, il y a “reliability”.

[00:44:02.070] — Denis : Au-delà de la blague, si plus de choses sont automatisées, si on a plus d’indicateurs, si, quand le site tombe en panne, ce n’est pas la panique parce que tout a été documenté, parce qu’on a l’habitude que ça tombe en panne, la fiabilité viendra derrière. Mais globalement, les gens seront juste plus sereins. Alors, comment mesure-t-on le fait que les gens soient sereins ? Je ne vais pas être capable de répondre ! Je ne pense pas que l’on va pouvoir mettre un indicateur chiffré. Mais comme je le disais, c’est un cercle vertueux donc les choses ne font que s’améliorer si l’on respecte ces principes-là.

[00:44:35.230] — Vincent : Après, il existe des métriques qui essayent de montrer si l’on va dans un bon sens ou pas. Ce sont les fameuses “4 key metrics” qui sont poussées par Google. Je ne vais pas forcément rentrer dans le détail maintenant parce qu’on pourrait faire une émission complète sur le sujet. Mais globalement, il y a des métriques qui nous permettent de savoir si les envois en production sont fluides, le temps que ça prend et l’impact que ça a quand c’est mis en production, et quand il y a un incident, combien de temps il dure, en gros. À partir de ces indicateurs-là, on peut voir si on va dans un bon sens. Ce sont vraiment des indicateurs qui ont vocation à être là pour donner une espèce d’étoile du Nord qu’on essaie de suivre.

[00:45:11.860] — Loïc : Il y a un autre indicateur qui est pas mal, qui est très subjectif aussi, donc ce n’est pas du tout mesurable. C’est le fait que des équipes s’approprient l’application sur tous les aspects. Avant, à Deezer, quand il y avait un problème, comme tu le disais Denis, c’était “panique à bord”. Et de toute façon, c’était le problème des Ops. Donc il y avait une personne qui avait tendance à faire un rollback ou un revert, et après c’était le problème des Dévs. Aujourd’hui, on est passé à un mode un peu différent où les équipes, déjà, se rendent compte elles-mêmes qu’il y a un problème parce qu’il y a des alertes. On parlait de mesurer des choses et maintenant, les équipes savent quand il y a un problème. Elles le savent bien souvent avant les Ops — les Ops, parfois, ne le voient pas passer — et elles sont capables de réagir. Les équipes vont, de manière totalement autonome, voir qu’il y a un problème, l’analyser, apporter une solution. La solution peut être un rollback instantané ou ça peut être “on prend le temps”, justement vis-à-vis de ces questions d’error budget. Parce que oui, on peut avoir un truc qui est cassé en production, mais c’est cassé sur un petit bout… On peut prendre le temps — le temps peut être dix minutes, deux heures, ça dépend — pour passer un fix, par exemple. L’équipe le fait toute seule. Il n’y a plus besoin d’avoir ni un SRE ni un Ops pour que l’équipe fasse tout ce travail-là. Et on a déjà eu des situations où l’on a dû dire, par exemple, aux Ops : “Non, laissez les équipes, elles sont capables de le faire toutes seules. Vous n’avez pas besoin, vous n’avez plus besoin en tout cas, ni de les alerter, ni de leur mettre la pression.” Parce que l’équipe va se mettre la pression qu’elle doit se mettre toute seule vis-à-vis de ces notions d’error budget et d’indicateurs. Quelques équipes ont énormément changé à Deezer, par exemple. Il y a des équipes qui sont justement passées de ce mode absolument pas autonome à complètement autonome. Et ça se voit dans la gestion de crise mais aussi dans la gestion de mises à jour. On a quand même beaucoup de PHP à Deezer; il y a certains projets qui sont ce qu’on appelle du “legacy”, qui sont très compliqués à mettre à jour, notamment dans les montées de version de PHP en lui-même et de certains grands frameworks qu’on utilise, et il y a des équipes qui sont capables de le faire toutes seules en une journée ou deux. Elles n’ont besoin de personne. À un moment donné, c’est : “Ah, il y a une nouvelle version qui est sortie !” On communique entre nous parce qu’on est dans la même entreprise — il y a un peu de fluidité de communication entre les équipes — mais on voit tout de suite les équipes qui ont réussi ce changement parce que deux jours après : “Oui, c’est bon, on est sur la nouvelle version de PHP, ça tourne, c’est en prod, il n’y a pas de problème.” Ou même mieux : “On a eu ce problème-là, on vous le dit, n’ayez pas le même souci que nous.” Et on en a quelques- unes comme ça à Deezer maintenant.

[00:47:45.260] — Stéphane : Vous avez fait une belle description du métier de SRE et du coup, ma question, c’est : comment devient-on SRE ?

[00:47:52.900] — Denis : Si l’on vient plutôt du monde opérationnel, je pense que ce qui est important, c’est déjà de s’intéresser au code, notamment de ses développeurs. Il faut avoir cette appétence pour le code, pour l’outillage, l’automatisation. Il va falloir tester, il va falloir apprendre. Il va falloir être pédagogue, empathique — parce qu’on ne rapproche pas les gens si l’on n’essaye pas de se mettre à leur place. Voilà, pédagogie, empathie, envie d’apprendre et envie de transmettre. Ça, c’est plus pour ce qu’on appelle les “soft skills”.

[00:48:27.940] — Vincent : Quand on fait le chemin inverse, il y a beaucoup de choses qui sont un peu identiques. Comme tu le disais, il faut de l’écoute, il faut de la curiosité, il faut essayer de s’intéresser à l’autre. Côté Dév, il faut avoir cette appétence de vouloir savoir comment ça tourne sous le capot. C’est vraiment l’envie d’ouvrir et de regarder, pas juste “j’envoie mon code et ça marche.” C’est “OK, ça marche, mais pourquoi ?” Moi qui suis un peu vieille école, comme vous le disiez, c’était un peu mon mode de fonctionnement quand j’ai commencé. C’est vrai que c’est peut-être moins vrai maintenant qu’on se spécialise et je pense que c’est vraiment ce critère-là qui fait qu’on peut se lancer dans ce genre de poste de SRE.

[00:49:02.550] — Loïc : Je pense que la clé, c’est la polyvalence — sans arriver à la caricature d’être nul en tout ! Un SRE n’est, pour moi, pas un spécialiste dans un truc en particulier. Il va avoir un domaine de prédilection. C’est pour ça que l’on a plusieurs profils ici : on a des gens qui sont plus orientés Ops, plus orientés Développeurs. Mais dans l’idée, on est en mesure de comprendre de manière assez fine le métier de l’autre. Ça veut dire qu’on est potentiellement allé s’y frotter. Peut-être pas directement — personnellement, je n’ai jamais été Ops, je n’ai jamais eu la responsabilité de gérer de l’infrastructure de production d’une entreprise mais je me suis intéressé sur comment ça marche et sur quels sont les outils qui sont mis en place, quelles sont notamment les contraintes, comment un Ops vit une astreinte… C’est un truc tout bête mais je n’ai jamais été d’astreinte, donc c’est difficile pour moi de me représenter ce que c’est que d’être d’astreinte. C’est quand même avoir le droit de vie ou de mort quasiment instantané sur une plateforme. L’objectif étant de la faire vivre !

[00:50:07.520] — Vincent : C’est un peu comme quand tu es réveillé par ton bébé qui vient de naître et qui demande son biberon.

[00:50:12.040] — Loïc : Je ne suis pas parent donc je ne peux pas non plus !

[00:50:13.760] — Vincent : Tu pourrais faire comme si tu n’avais rien entendu, mais en général, tu y vas !

[00:50:17.570] — Loïc : Voilà, en gros, c’est avoir une capacité, une empathie envers les autres métiers et s’y intéresser. Je pense que l’idéal, ce serait une personne qui soit aussi bien des deux côtés, mais c’est un idéal de trajectoire plus qu’une réalité — parce que je pense que ce n’est pas vraiment possible. C’est cette idée d’être capable de comprendre les deux mondes de manière suffisamment fine et profonde pour pouvoir, ensuite, l’expliquer aux autres. Un peu comme quand on dit qu’un professeur doit bien connaître son sujet pour pouvoir l’enseigner. C’est un peu la même chose. Quand on parle à des développeurs, on a à comprendre, un peu plus qu’un développeur, l’infrastructure — même si l’on n’a pas besoin de comprendre l’infrastructure au point d’un Ops parce qu’on n’a pas non plus à l’enseigner à un Ops, mais on a besoin d’en savoir un peu plus pour avoir la capacité de dire des choses qui sont justes, tout en étant pédagogue.

[00:51:08.610] — Pauline : Eh bien merci ! Je pense que l’on a fait un beau tour d’horizon du SRE et on va maintenant passer à la rubrique “Coups de cœur”.

[00:51:25.980] — Vincent : Un titre que j’ai écouté très récemment et que j’aime beaucoup… C’est de l’électronique, c’est un artiste qui s’appelle Spada, qui a sorti un titre qui s’appelle “Beirut”, que je trouve très sympa et que j’écoute dans le métro en bougeant un peu. C’est très rythmé. C’est le genre de rythme qui me fait vibrer en ce moment.

[00:51:46.390] — Denis : De mon côté, dans les découvertes que j’ai faites il n’y a pas longtemps, en cherchant la bande originale d’un film — de Kick Ass 2, pour dire le titre du film — je suis tombé sur une track qui s’appelle “Korobeiniki”. Il se trouve que c’est le même thème que Tetris à la guitare électrique. Sauf qu’en fait, c’est Tetris qui a repris une chanson traditionnelle russe qui s’appelle “Korobeiniki”.

[00:52:13.190] — Loïc : C’est l’origine de Tetris !

[00:52:14.830] — Denis : Exactement.

[00:52:16.000] — Loïc : D’accord. Moi, d’habitude, je partage plus du jazz, mais aujourd’hui, je vais partager un artiste français, de la variété française. Ça s’appelle Oscar les vacances. C’est un peu loufoque, un peu délire. Je vous recommande à tous d’aller écouter sur Deezer ce qu’il fait.

[00:52:33.320] — Stéphane : Pour ma part, Flow m’a poussé The Datsuns avec “Sittin’ Pretty”. C’est un titre qui bouge bien, qui est plutôt sympathique et que j’adore en ce moment.

[00:52:41.640] — Pauline : Et moi, je ne vais pas vous faire une reco de titre. Je vais faire une reco, ce sont mes “all-time favorite”, comme on dit. C’est un groupe qui s’appelle White Lies, c’est un groupe de rock anglais avec des influences post-punk. Tous leurs albums sont géniaux, en particulier le premier — pour moi, il n’y a rien à jeter dedans. Le premier, c’est “To Lose My Life”.

[00:53:01.586] — Vincent : Nice !

[00:53:01.820] — Pauline : Voilà ! Merci à tous les trois pour vos éclairages et vos partages d’expérience, et on se retrouve bientôt pour un nouvel épisode !

[00:53:10.010] — Vincent : Vous venez d’écouter un épisode de Deez is la tech et nous espérons que vous avez passé un bon moment en notre compagnie. N’hésitez pas à nous attribuer quelques étoiles si votre application de podcast le permet, et à nous faire part de vos retours via les réseaux sociaux et notre compte @DeezerDevs. Ceux-ci nous aideront à améliorer notre contenu afin de le rendre plus utile, enrichissant et plaisant à écouter. Enfin, n’oubliez pas que toutes les transcriptions de nos épisodes, ainsi que les coups de cœur de nos invités, sont disponibles sur notre blog deezer.io. À très vite pour un nouvel épisode et d’ici là, ne pétez ni les plombs, ni les crons !

Références

• Site Reliability Engineering : Wikipedia
• Livres sur le SRE par Google : SRE books
• DevOps : Wikipedia
• Team Topologies de Matthew Skelton et Manuel Pais
• Prometheus — toolkit open-source de monitoring et d’alerting système)
• Stack ELK : Elasticsearch, Logstash et Kibana — solutions open-source de monitoring et de gestion des logs
• Le joueur du grenier (chaîne YouTube) — David Goodenough
• Kubernetes — plateforme open-source de gestion de workloads et de services conteneurisés)
• Docker — plateforme permettant aux développeurs de concevoir, partager et déployer des applications à l’aide de conteneurs | Dockerfile
• Vulnérabilité Heartbleed
• Vulnérabilité Log4j : Wikipedia
• Git — logiciel open-source de gestion de versions décentralisé
• Coups de coeur :
  - “Beirut” de Spada & Mardraüs
  - “Korobeiniki” de Ozma
  - Oscar les vacances
  - “Sittin’ Pretty” de The Datsuns
  - “To Lose My Life” de White Lies