Vélocité, performance, expérience, scalabilité : comment font-ils ?

0:03 Déjà en 2019, il était venu parler au Tech.Rocks Summit et ça m'a été très apprécié. Voici Gregory Ouillon, CTO à Fiemier chez Nurelic. Nous sommes ravis d'accueillir à nouveau pour qu'il nous présente quelques clés et meilleures pratiques communes aux équipes qui surperforment. Bonjour à tous, je suis Gregory Mouillon, je suis le CTO pour l'Europe, le Moyen-Orient et l'Afrique de New Relic. New Relic, c'est une société qui est leader dans le monde de l'observabilité. Et donc le talk que je vais donner aujourd'hui, il est évidemment relatif au métier que je fais. C'est un métier dans lequel j'ai la chance de rencontrer des dizaines et des centaines d'équipes, de leaders techniques. Et ça m'a permis de dégager au fil des deux dernières années quelles sont les pratiques et les tendances qui font que des équipes performent au-delà des autres, quels sont les réflexes, quels sont les muscles, quelles sont les cultures qu'elles développent. Et évidemment, je vais le faire avec un biais qui est orienté sur la télémétrie et l'observabilité, car ça fait partie des conversations que j'ai avec ces entreprises.

1:11 Quand j'étais plus jeune ingénieur, j'avais un vrai problème avec cette phrase que j'entendais qui venait des Américains qui était« You cannot manage what you cannot control». Et en fait, j'attribuais ça un peu à une vue capitalistique, à une vue managériale, une vue un peu laborieuse, un peu... Taylorisé du monde. Et en tant que jeune ingénieur, j'aimais considérer que ce que je faisais, c'était plus de la science, c'était plus un art. Et donc, quelque part, l'intuition, l'art, prenait le pas sur la mesure. Mais depuis quelques années, peut-être en prenant un peu d'âge, j'ai aussi réalisé qu'en fait, il ne faut pas confondre contrôle et mesure. Et que pour atteindre la haute performance, comme dans la plupart des disciplines et même les sports de très haut niveau, il est essentiel pour pouvoir piloter de mesurer. C'est dans ce contexte-là que je vais poursuivre un peu mon raisonnement. Alors depuis quelques temps, on entend parler des héros, n'est-ce pas? Les héros modernes seraient les équipes de développement logiciel.

2:11 Pourquoi? Parce qu'en fait, on a eu cette pandémie, une circonstance incroyable, qui nous a amenés à repenser complètement le rôle des ingénieurs. D'un seul coup, ils sont devenus essentiels à faire que notre vie continue, qu'on puisse continuer à apprendre, que nos enfants puissent apprendre, qu'on puisse se rencontrer, qu'on puisse accéder à des biens de consommation et se les faire livrer. Donc en fait, tout a changé, mais ça veut dire aussi que ces héros modernes, il y a beaucoup d'attentes sur eux, encore plus qu'avant, en matière en particulier de ce qu'on attend de l'assiette d'attente qu'on peut avoir pour eux. On attend d'abord qu'ils aillent vite, qu'ils délivrent de l'innovation, qu'ils soient agiles, parce qu'en fait, on doit pouvoir s'adapter aux circonstances du marché. On attend aussi évidemment qu'ils maîtrisent l'expérience des clients. Maintenant, on n'achète plus les clients. services ou des produits, on achète des expériences. Donc c'est extrêmement important. Et la fondation de ça, c'est évidemment d'assurer une performance, une disponibilité, une fiabilité exemplaire.

3:11 C'est la base, c'est la fondation. Et évidemment, on s'attend à ce que si les affaires marchent, s'il y a beaucoup de clients, on puisse monter à l'échelle, monter les échelles, les équipes, les architectures. Et on s'attend à ce que, au passage, il y ait quand même quelques économies d'échelle. Alors évidemment, ça fait beaucoup pour ces équipes qui doivent déployer du code fréquemment, rapidement, qui doivent adopter le DevOps, qui a fait ses preuves dans ce domaine. Ils doivent en même temps gérer la dette technique, moderniser les architectures, ils doivent adopter le cloud, partir en cloud natif. Et bien sûr, pendant ce temps, ils vont aussi régler les problèmes, les incidents, parce qu'il y en a toujours, parce qu'on doit admettre qu'il y en aura toujours. Et ce que je vais vous donner derrière, c'est un peu quelques enseignements des équipes que je rencontre sur ce qu'elles font peut-être mieux que les autres, ou quels muscles elles ont développés. Alors, que font-elles différemment ces équipes qui performent? Tout d'abord, elles ont définitivement adopté le shift left, c'est-à-dire de donner la main aux développeurs pour faire une grande partie des tests en test unitaire.

4:16 Et donc, quand ils vont shipper du code, ce code va être de bonne qualité, souvent typiquement des unit test coverage qui vont être de 60-70%, voire plus. Et qui va maintenant être une donnée de base. L'automatisation des tests. Mais maintenant, ce à quoi on assiste, c'est le shift right. Et je pense qu'il y a encore, dans pas mal d'équipes, un travail à faire pour accepter ça. Pod est très fragmenté, on a plusieurs équipes de dev, on a plusieurs microservices, potentiellement des dizaines, des centaines. On déploie ça dans des architectures extrêmement éphémères avec des containers, des clusters Kubernetes dans le cloud. Et donc, on a une fragmentation de l'architecture qui rend très difficile de recréer l'ensemble. de cette architecture en staging et de faire des tests de non-régression et de régression totalement exhaustifs. Donc en fait, on fait de plus en plus du smoke, on fait du load testing, on va faire peut-être du chaos engineering, mais tout ça est de plus en plus en production. Et je pense que ces équipes-là acceptent l'idée.

5:20 Qui de plus en plus vont finalement valider la dernière étape de la validité de leur code en production. Pourquoi? Parce que comme je l'ai dit, les environnements de staging deviendraient beaucoup trop coûteux, ce serait beaucoup trop long de valider une release entièrement en staging. Et puis c'est finalement en production qu'on rencontre les vraies conditions. Du trafic utilisateur, des vraies conditions d'avoir l'ensemble des services back-end disponibles. Et c'est là qu'on va avoir les premiers retours business, évidemment, sur la réalité de la performance. Donc ça, c'est le premier enseignement, accepter le shift right, accepter que les ingénieurs ont la clé de la prod, qu'ils vont valider en prod. Pour ça, ça implique qu'ils mesurent en permanence. Évidemment, leur site de dev, en log testing, en staging, mais aussi en preuve. La difficulté de mesurer, c'est que finalement, on s'appuie sur des architectures qui peuvent être très compliquées et un peu historiques.

6:20 Donc, ce que font ces équipes très bien aussi, c'est finalement de s'attaquer au musée des équipes de monitoring qu'ils ont. Ou un peu des eaux. Alors, de quoi je parle? On reste encore pour beaucoup avec une dette technique importante en monitoring parce que le monitoring s'est bâti par couches et par spécialités. On a eu le monitoring de passe de données, le monitoring réseau, on a eu l'APM, le Real User Monitoring. Et un peu chaque équipe a construit finalement sa base de connaissances et son outillage en fonction d'une répartition par couche. Et les équipes ont par ailleurs commencé à fragmenter leur télémétrie aussi en créant des puits de logs, par exemple, indépendants. Donc en fait, on a à la fois des outils qui sont historiquement parfois dépassés par rapport aux architectures, mais aussi des équipes qui ont sélectionné des outils best of breed dans leur domaine et qu'au bout d'un moment, ça devient un peu le zoo. Alors quels sont les problèmes de ça? C'est finalement, on a des télémétries qui sont disjointes, on a très peu de corrélation entre les différents éléments de télémétrie, donc on met plus longtemps pour résoudre les problèmes, tout simplement.

7:28 On met longtemps pour résoudre les problèmes, on a des interprétations différentes par équipe de ce qui se passe, donc on a aussi du blame game, et on a plus de difficultés, ça coûte beaucoup plus cher de faire réconcilier toutes ces données. Aujourd'hui, 72% des équipes d'une enquête qu'on a réalisée vers 1000 personnes nous ont dit qu'ils avaient besoin d'accéder beaucoup plus que deux outils, jusqu'à 6 outils, 30% des équipes accédant à plus de 6 outils pour savoir ce qui se passe dans leur stack. Donc il faut savoir attaquer à cette technique. Alors la façon dont les équipes qui ont décidé d'adopter l'observabilité avancent, effectivement, c'est ce qu'on appelle le full stack instrumentation, donc déployer des agents de la télémétrie qui va collecter des logs, des métriques, des événements et des traces sur l'ensemble du stack, que ce soit toute la partie infra, cloud, cluster, VM, container, toute la partie software avec le code lui-même, mais aussi le middleware et le cloud middleware.

8:33 L'expérience utilisateur, très importante, mais aussi des données métiers et business. C'est en amenant toutes ces données au même endroit qu'on va être capable de comprendre comment le système se comporte de bout en bout, et s'il y a des problèmes qui surviennent, comment ces problèmes se manifestent et d'où ils proviennent. Donc en fait, cette direction de dire je vais consolider ma télémétrie, Quelle que soit la façon dont elle réalise, avec des vendors comme New Relic, que ce soit en open source, l'objectif c'est d'avoir cette compréhension de bout en bout en temps réel. Une des choses très importantes que font les équipes qui adoptent aujourd'hui ce cœur de la mesure, c'est aussi de l'incorporer dans leur philosophie« everything has code». Les équipes de dev se sont emparées aujourd'hui avec le DevOps de leur capacité à déployer leur code, mais aussi évidemment leurs infrastructures, leurs containers, au travers de tout ce qui est infrastructure as code, infrastructure. et elle commence maintenant à y incorporer toutes leurs stratégies de déploiement et de release, et aussi l'observabilité.

9:36 Donc le principe, il est évidemment de dire qu'on va chipper du code instrumenté. On va s'assurer que le code, quand il est développé, quand il est buildé, quand il est déployé, contient l'ensemble des instrumentations nécessaires qui seront déployées par le pipeline de CICD et qu'au travers de l'infrastructure immutable, on va... aussi à déployer toutes les alertes, les dashboards, les SLO, de sorte que n'importe quelle version, tout déploiement va être déployé avec les bons critères d'alerting et de dashboarding. Dès que l'infrastructure s'active et déploie le code, On a la télémétrie qui va arriver et dès lors on va pouvoir valider une version, quelle que soit sa stratégie de déploiement, et valider les paramètres non fonctionnels qui vont décider ou non de son acceptation et de son passage en production ou un rollback. On va ensuite évidemment pouvoir utiliser la plateforme pour alerter sur la qualité, sur les incidents et les alertes, et intégrer toute cette télémétrie avec les plateformes de collaboration et de ticketing.

10:47 Donc ça c'est très important, les équipes qui aujourd'hui maîtrisent le mieux leur cycle de développement automatisent aussi l'observabilité et développent tout comme du code. Un des points importants aussi que je vois chez les équipes, et je suis obligé d'y revenir, parce que je vois qu'il existe encore aujourd'hui dans la plupart des équipes un peu deux camps, deux histoires. Il y a l'histoire des sociétés et des équipes qui connaissent l'APM et l'Application Performance Management. Et puis il y a les équipes qui ont finalement émulé, recréé la capacité à maîtriser leur code, essentiellement en exploitant leur log et en monitorant leur infrastructure. Aujourd'hui, je pense que les équipes modernes doivent se doter d'outils d'APM, quelle que soit leur nature, qu'elles soient open source, vendor, propriétaire. Mais on maîtrise bien son architecture logicielle quand on maîtrise ses transactions, quand on maîtrise les Golden Signals. Et pour toutes les transactions fondamentales, tout ce qui touche à la latence, au débit, au taux d'erreur,

11:50 à des définitions de saturation et éventuellement à l'abdex, qui est une façon de normaliser, déterminer la satisfaction client par rapport à une transaction. C'est pour moi fondamental, c'est la fondation même de la compréhension de la contribution de ces transactions à la santé de l'architecture digitale. Là, l'art de la mesure, c'est aussi pour ces équipes la capacité à comprendre quel est l'état normal, ce qu'on va appeler la baseline de leur architecture. Donc, on va mesurer une architecture pour comprendre son comportement nominal, ce qui ne veut pas dire que ce comportement est bon. Et on va passer à l'étape suivante, qui est une fois qu'on comprend sa baseline, on va déterminer pour des métriques clés qu'est-ce qui constitue finalement l'objectif, qu'est-ce qui serait décrit comme étant une bonne performance. C'est un exercice difficile et en particulier parce qu'on a souvent peu de références, peut-être un peu de compétition, faire un peu de benchmarking. Mais c'est vraiment le rôle des team leaders, c'est le rôle des SRE d'aider à définir quelles sont ces métriques qui décrivent au mieux l'architecture

12:57 de service, de bout en bout, et empêcher que les équipes, chacune part dans son coin en définissant ses propres métriques et finalement recréent au sein d'une seule plateforme. Leurs îlots de visibilité et repartent dans cette isolation et cette fragmentation. Donc cet exercice de définir quels sont les services à l'objectif est un art que maîtrisent les équipes qui sont leaders. Alors bien sûr, après il y a tout ce qui se passe en production, on a des incidents, il va falloir les résoudre et les équipes qui sont leaders aussi ont une capacité qui est très claire. C'est la capacité à savoir ce qui se passe dans leur stack et donc à résoudre les incidents le plus vite possible. Ça passe évidemment par le fait de les détecter et de les détecter autant que possible avant que ça ait des conséquences pour les clients et donc finalement d'apprendre qu'on a des incidents bien avant l'appel insatisfait et frustré. d'un client qui attend nos services. Donc pour ça, il y a tout l'outillage relatif. à ce qu'on appelle le champ de l'observabilité, full stack.

14:00 Mais ce qui est très important, c'est cette capacité à définir des alertes, utiliser la détection d'anomalies pour, de façon constante, détecter d'abord très rapidement les incidents, en général en moins d'une minute, pour ensuite pouvoir démarrer la phase d'investigation. Et cette phase d'investigation, elle va s'appuyer sur tous les outils du monitoring, du troubleshooting, de l'analyse, pour résoudre les problèmes. Et c'est parce qu'on a toutes les données au même endroit qu'on va aller beaucoup plus vite pour comprendre le contexte, corréler les informations, sur l'ensemble du stack et donc aller beaucoup plus rapidement au road cause analysis. Donc il y a des petites stats qu'on avait faites il y a quelques temps, on avait fait une étude qui démontre aujourd'hui que les équipes qui maîtrisent le mieux cette art de la détection, la résolution et qui utilisent l'observabilité de façon efficace apprennent les incidents de leur stack et pas de leur client. à ceux qui sont le plus en retard.

15:02 Ils ont beaucoup moins d'outage parce que finalement quand on a moins d'outage, quand on en résout plus vite, on va finalement en avoir moins assez rapidement. Et on est capable de résoudre ces incidents beaucoup plus vite. Puisqu'on a moins d'incidents, on va rentrer dans cette capacité qu'on va avoir à se préoccuper de déployer plus rapidement, plus fréquemment et avec un taux de succès de plus en plus élevé. Pour ça, les équipes qu'on voit qui sont vraiment en avance sont celles qui sont passées du déploiement before-after, où je déploie, j'ai un temps de maintenance, je déploie mon nouveau code, vers les architectures always-on, où on va être sur du blue-green, sur du canary, sur du rolling deployment, ou alors sur l'activation de feature, feature toggling ou dark. Donc toutes ces architectures qui vont permettre de n'introduire un changement que sur une partie de la base client, de façon maîtrisée, et d'être capable d'ajuster selon les besoins le taux de migration des clients vers la nouvelle version.

16:07 Ils vont aussi s'imposer de traquer, d'envoyer des déploiements, des marqueurs de déploiement dans leurs outils pour aussi savoir à tout instant, pour tout le monde, quand ces déploiements se sont produits et donc d'attribuer des potentielles dégradations ou changements de comportement à ces déploiements. Ils vont aussi définir, et c'est souvent difficile, quels sont les critères qui permettent de dire Je passe, oui je vais en production. C'est d'autant plus facile d'être intransigeant dans un déploiement qu'on en fait souvent. Si on déploie tous les trois mois, on a très très très envie que cette release soit déployée et rentre en production. Et donc on va un peu couper dans les coins, on va faire des compromis, on va attendre trop longtemps à essayer de résoudre le problème plutôt que de faire un rollback. Si on fait 100 déploiements par jour, alors on peut très facilement faire un rollback, on peut même l'automatiser dans le cycle de release. Ensuite, les équipes qui performent ne sont pas celles qui ne passent que du temps sur leurs features, et on le sait, ce sont les équipes aussi qui s'attaquent à leurs dettes,

17:14 qui s'attaquent à leurs erreurs pour s'assurer qu'elles restent dans des zones acceptables en termes de taux d'erreur, en termes de taux d'incident, en termes de fiabilité et de performance. Et donc, elles ont cette capacité à engager avec leurs équipes produits en leur montrant des performances et des conséquences pour le business de certaines erreurs et de prioriser avec l'accord des équipes produits et business le fait que ces erreurs doivent être résolues parce qu'elles impactent la performance métier ou l'expérience client. Ça permet aussi d'avoir un dialogue beaucoup plus construit autour de ces problèmes qui sont en fait masqués par des incidents. On voit un incident se reproduire 100 fois dans la semaine, on le résout à chaque fois, mais en fait ce qu'on a dessous c'est un problème. Donc s'attaquer beaucoup plus fondamentalement au problème management de façon structurée, et évidemment derrière ça s'attaquer à la dette technique avec un dialogue beaucoup plus constructif avec les équipes produites. Ce que je vois aussi, c'est que finalement, beaucoup d'organisations ont un split qui est assez logique entre leurs équipes front et leurs équipes back.

18:20 Il y a des compétences spécifiques aux deux et il est très courant que les équipes front soient des équipes séparées, qui ont leurs outils séparés et qui conçoivent... En conséquence, l'expérience client comme un peu ce résumé aux optimisations et à la performance qu'ils peuvent fournir avec leur front. Et je vois trop souvent cette césure. Les équipes qui font de la performance sont capables de reconstruire l'expérience client bien au-delà de l'expérience front, en ayant toute la partie session tracing, distributed tracing, pour attribuer les contributeurs de friction, les contributeurs de performance à l'ensemble de la chaîne, qu'elles soient le front, les serveurs web, toute la partie processing et les microservices, ou les API backend, dernière partie tiers. Donc c'est cette aptitude à rejoindre, join the dots en anglais, je ne sais plus comment on dit en français, entre le front et le back, qui permettent de délivrer la vraie expérience client. Et ça permet aussi de relier vraiment les parcours clients à la performance technique.

19:25 Comprendre combien de fois l'affichage d'un catalogue pour l'expérience client, une sélection de catalogue, peut appeler une transaction peut-être mille fois qui va prendre 50 millisecondes et comprendre que cette transaction-là doit passer à 3 millisecondes et non plus à 50. Ce que je vois aussi beaucoup des équipes qui vraiment commencent à accélérer, c'est que finalement elles ont quitté le domaine de l'observabilité technique, qui vise à améliorer la performance, la disponibilité et la fiabilité, pour aller vers un dialogue beaucoup plus engagé avec les équipes métiers, en injectant des attributs. début ou des données métiers qui vous permettent de visualiser, de pivoter, d'analyser toutes les données de télémétrie en fonction d'impératifs métiers. Par exemple, la performance était la même pour différents tirs de loyauté d'un client. Les problèmes sont-ils les mêmes en fonction des classes de produits ou en fonction des pays? Donc c'est cette capacité à commencer à comprendre comment attribuer des problèmes de performance métier avec des performances techniques.

20:32 Quelques exemples intéressants. Donc Starbucks, 35 000 points de vente, a équipé tous ces points de vente avec l'observabilité, avec l'instrumentation de leur point of sale, donc l'infra, l'instrumentation de leur code de leur point of sale, et l'instrumentation business, capable de capturer la valeur en dollars des paniers, quels sont les produits commandés. Ce que ça leur permet de faire, c'est qu'en temps réel, sur ces 35 000 points de vente, ils peuvent savoir si la chute des ventes est liée directement à un problème applicatif, ou si par exemple dans un magasin spécifique, elle est liée à des circonstances, par exemple des travaux dans la rue, une manif, un bouchon. Et donc la capacité à mieux comprendre c'est qui agit. Accedo, qui est un leader mondial dans le domaine des plateformes de broadcast, utilise les réseaux sociaux pour récolter tous les mots-clés relatifs au broadcast de leurs clients, qui sont des grands éditeurs, des grands diffuseurs. de télé dans le monde, et pour récolter des alertes sur du sentiment négatif qui se développe, et être capable de déterminer avec leurs opérateurs que parce qu'un sentiment négatif se développe, il y a peut-être un problème sur les plateformes.

21:43 On a même des transporteurs, des acteurs de la mobilité et du taxi, qui sont capables d'injecter les données météo, parce qu'ils savent que s'il va pleuvoir, il y aura beaucoup plus de demandes de taxis, et donc ils doivent faire du pre-scaling de leur cluster Kubernetes lié à la météo. Donc qu'est-ce que nous disons? Nous disons que finalement, il y a un cercle virtueux, un team sport qui se crée, qui démarrent par la fondation. Si les équipes peuvent s'attaquer à leurs incidents, les comprendre parce qu'ils collaborent et ils ont une vue unifiée de leur stack, ils vont progressivement et très rapidement avoir beaucoup moins d'incidents et ils vont passer moins de temps à les résoudre. Tout ce temps-là, qu'on a beaucoup de mal à mesurer, est du temps qu'ils vont pouvoir passer à autre chose. Développer l'innovation, mais aussi améliorer la fiabilité de leur stack. Ils vont pouvoir faire un peu plus de pair programming pour les éléments du code qui sont critiques. Et ils vont rentrer dans ce cycle de vertu aussi du deploy fast, fail fast and measure.

22:47 Une fois qu'ils auront ça, Ça va créer un dialogue différent avec leurs équipes produits. Ils vont pouvoir commencer sur l'ensemble du stack à définir quels sont ces objectifs et ces métriques qui définissent la vraie performance. pour tout le monde, et pouvoir s'aligner en tant qu'équipe sur l'ensemble du stack, sur ces métriques qui comptent, et travailler ensemble à les délivrer. Ils vont pouvoir aussi beaucoup plus rapidement aligner la performance du code avec la performance applicative et l'expérience client. Une fois qu'ils auront tout ça, ils vont pouvoir s'attaquer aux problèmes de la productivité, évidemment, développer du code plus économique, optimiser les architectures pour délivrer la même performance, mais en consommant évidemment beaucoup moins de coûts cloud ou d'infrastructures. Donc ce cercle-là, c'est le cercle de la mesure, c'est le cercle de l'observabilité. Et des équipes qui se sont emparées de ce sujet comme un sujet, comme un muscle essentiel pour les athlètes des bops qui délivrent aujourd'hui la performance que nous connaissons.

23:51 Si j'ai piqué votre curiosité, vous pouvez aussi retrouver New Relic sur le stand virtuel. Venez nous voir. Et puis bien évidemment, si vous êtes aussi piqué d'observabilité, on a un fritier qui permet de découvrir l'observabilité de façon perpétuelle pour apprendre. Et puis là, bien sûr, on va maintenant rentrer dans le jeu des questions. Je suis là pour répondre aux questions de l'audience.