APM superpowers (Application Performance Monitoring)

0:15 Bonjour à tous, je m'appelle Gilles Laborderie, je suis ravi de présenter ce meet-up aujourd'hui sur l'APM en partenariat avec Instana. Je suis VP Fontaine chez BlaBlaCar et aujourd'hui nous aurons plusieurs intervenants. Tout d'abord nous aurons Alexandre qui nous présentera la solution Instana. Et ensuite un retour d'expérience de la société OuiSNCF avec Nicolas et Anne qui nous expliqueront comment ils ont choisi l'outil et la mise en œuvre. Et puis pendant le meet-up, Tommy partagera ses dessins. Comme vous l'a dit Noémie, vous utilisez le widget pour poser vos questions. Je les surveillerai, on les posera en fin de meet-up et ensuite on pourra se retrouver pour nettoyer. Voilà, donc sans plus étendre, j'appelle Alexandre à venir sur scène nous présenter rapidement un stand-up. Merci Gilles. Merci Gilles. Donc pour ma part Alexandre, moi je suis responsable avant-vente chez Instana et je ne vais pas vous prendre trop de temps, je vais juste vous faire une

1:24 petite présentation de qui nous sommes et pourquoi. Comment nous sommes nés et ce que nous proposons. Donc, Instana, effectivement, le rôle d'Instana, c'est d'opérer de l'observabilité pour, en particulier, tout ce qui peut être les nouvelles applications, environnement, microservices, tout ce qui va tourner autour du cloud native. Pourquoi ça? Parce qu'il s'est passé beaucoup de choses depuis 2014. La naissance de Kubernetes aux alentours de 2015, une émergence forte de toutes les plateformes que l'on a vu arriver, même si certaines sont plus anciennes, mais c'est vraiment depuis les années 2014-2015 qu'on a vraiment vu l'émergence des plateformes cloud, que ce soit AWS, GCP, Azure, avec tous les services qu'ils peuvent proposer. Et surtout, un shift au niveau du développement des applications avec la croissance des plateformes microservices, de tout ce qui va concerner le CI-CD, de toutes les pratiques DevOps, tout ça pour apporter toujours pareil, plus de scalabilité, de modularité, d'intégration et potentiellement d'automatisation.

2:36 au sein de ce processus de développement pour continuer à développer des applications toujours de plus en plus performantes et puis surtout qui sont de plus en plus riches. Et pour concrètement observer tout ça, on a mis en place tout un ensemble de choses. On a mis en place, on a conservé notre monitoring traditionnel qu'on pouvait avoir lorsqu'on avait encore, pour les sociétés qui sont existantes depuis 10-15 ans, voire plus, Ce monitoring traditionnel sur base de Centréon, Zabix, Nagios, j'en passe et plein d'autres. Sauf que ce sont des solutions qui s'adaptent finalement assez mal. Au cloud, aux plateformes de containers, à tous les microservices, parce qu'il peut y avoir beaucoup de travail autour de ça. On a bien évidemment des logs, les logs qui restent indispensables. On travaille avec des outils comme une stack ELK, comme avec du Splunk. Toutefois, ce sont des solutions qui restent longues à mettre en place, qui doivent être souvent standardisées pour arriver à ce que tout le monde les comprenne.

3:42 Ça n'apporte pas nécessairement non plus de vision, ça donne une bonne vision au niveau de ce qui se passe au niveau applicatif, quand ça ne marche pas ou même quand ça marche, mais ça n'apporte pas nécessairement une vision sur l'intégralité du système. Quelles sont les dépendances entre mes services? Quelles sont mes dépendances vis-à-vis d'une infrastructure? Et souvent, ça requiert de l'inventivité. Quand on est passé d'une approche monolithique à une approche SOA, il a fallu qu'on mette en place des... des tags de suivi pour être capable de corréler les logs. Aujourd'hui, on démultiplie les microservices et la mise en place de ces tags, ça peut être relativement complexe à faire. Alors effectivement, aujourd'hui, il y a de l'open source aussi. Il y a beaucoup de technologies open source que nous-mêmes nous embrassons chez Instana. Le traditionnel Prometheus, on ne retrouve pas aujourd'hui une stack Kubernetes sans du Prometheus. On va retrouver des choses plus spécialisées dans le monde Java, avec des choses comme Drop Wizard, Micrometer, et puis surtout tous les outils du CNCF avec l'Open Tracing, Open Télémétrie, etc. Cependant, ça reste long, ça reste fastidieux à mettre en place.

4:45 Et puis, ce sont des outils séparés. De surcroît, ce sont des tâches de développement qui sont finalement peu valorisées. Si on demande à un développeur s'il préfère développer des endpoints Prometheus ou développer de la nouvelle fonctionnalité, j'ai assez peu de doutes sur... sur sa réponse. Et puis, bien évidemment, il y a des solutions d'APM. J'ai travaillé pour beaucoup d'entre elles. Ça fait quand même une quinzaine d'années que je suis dans ce milieu-là. Toutefois, ce sont des solutions, beaucoup de solutions qui sont d'ancienne génération, qui étaient très bien adaptées au monde SOA. Certains se sont renouvelés, d'autres un petit peu moins. Et souvent, ce sont des outils qui ne sont pas toujours faciles d'appréhension. Il y a parfois une difficulté lors de la mise en œuvre de la compréhension. L'adoption n'est pas toujours aisée. On retrouve très souvent des cellules d'experts qui sont les seuls à plus ou moins bien maîtriser le produit et qui de facto deviennent un petit peu des goulets d'étranglement dans l'analyse, la résolution des incidents. Et surtout, on est souvent sur des coûts qui peuvent être prohibitifs ou imprévisibles.

5:47 Vous avez des outils qui vont scaler leur pricing avec votre plateforme et ce n'est pas toujours totalement prévisible. Et aujourd'hui, on a besoin de cette prévisibilité sur les coûts directs et aussi les coûts induits pour la mise en œuvre. Et puis, certaines des solutions d'ancienne génération ne sont pas toujours adaptées au cloud ou au container. De facto, les enjeux de l'observabilité, c'est vraiment un défi organisationnel. Tout simplement, de plus en plus, on est sur une logique« you build it, you run it». Il faut arriver à comprendre ça. Il faut qu'un maximum de gens aient accès à ces ressources, ces données de monitoring, d'observation. Il faut gérer une complexité qui est fortement grandissante. On a de plus en plus de microservices. On va scaler ces plateformes au travers de Docker, de Kubernetes, d'OpenShift, de FAS, de PAS, de CAS, de tout ce qui peut exister chez les cloud providers. Et surtout, comme on est dans une logique et une approche de plus en plus automatisée au travers du CICD, il faut aussi gérer ces changements.

6:55 La gestion du changement va être quelque chose qui va devenir de plus en plus complexe. Je dois impérativement suivre mes releases, voir comment ça se passe, est-ce que Marie-Lise est meilleure que la précédente ou pas. Et tout ça sont vraiment les nouveaux enjeux que l'on a autour de l'observabilité. Du coup, Instana, c'est un outil qui a été créé justement pour ça, qui a été créé, j'aurais pu rajouter ce qui s'est passé depuis 2014-2015, c'est aussi la naissance d'Instana qui est née de ce terreau, de ces nouvelles problématiques d'observabilité. On va répondre à des défis organisationnels par un outil qui va être simple d'usage, qui va permettre de fédérer l'adoption des différentes équipes, que ce soit des populations Ops, DevOps, Dev ou peut-être même des acteurs du métier. Et le but, c'est vraiment de faire une adoption à des pratiques communes sans qu'il y ait cette friction de l'expertise, qu'on soit vraiment sur du consumerized product, c'est-à-dire que je puisse afficher un produit et tout de suite comprendre les données qui sont à l'intérieur.

7:57 Et surtout, fournir une assistance. à l'analyse pour la résolution des incidents, pour la compréhension de la plateforme. Tout cela en gérant la complexité. On l'a vu, Kubernetes, ça génère beaucoup de choses, ça génère surtout de la complexité. Et Instana va vous permettre de contextualiser toutes ces données-là qui viennent soit de l'infrastructure, soit des plateformes, soit des services, des applications, voire même de l'expérience utilisateur, pour avoir une vision vraiment complète de notre système d'information. Et surtout, gérer le changement. Comment je fais quand je fais des centaines de releases par jour pour m'adapter à tout ça? Je ne peux pas adapter mes stacks de monitoring en permanence. C'est long, c'est fastidieux, ça prend trop de temps. Justement, Instana va découvrir, monitorer automatiquement tous ses composants et surtout produire du feedback au pipeline de CICD, d'être capable de suivre ses releases et faire tout ce type de choses. Et surtout, on va offrir un pricing qui va être transparent, qui va être contenu, qui inclut absolument tout, il n'y a pas d'offre à tiroir, et surtout qui

9:06 réduit fondamentalement les coûts de développement et de maintenance du monitoring qui sont un des facteurs clés du coût du monitoring. Par exemple, quand on fait de l'open source, on a toujours tendance à sous-estimer toutes ces pratiques-là. Donc, pour résumer, Instana, c'est quoi? C'est vraiment embrasser toutes ces nouvelles technologies que l'on peut avoir autour de l'Agile, du DevOps, du CI-CD, de l'automatisation qu'on va pouvoir faire autour de ces nouveaux concepts que sont le cloud, les containers, les microservices, de telle manière à avoir toujours des cycles qui soient de plus en plus performants, de meilleure qualité et d'être capable d'avoir un pipeline qui soit toujours efficace à n'importe quel moment. Je ne vais pas vous en dire plus sur Instana. Je pense que le mieux, c'est encore de laisser parler ceux qui l'utilisent au quotidien. Donc, tout de suite, je vais appeler Nicolas et Anne à me rejoindre sur scène. Merci pour cette introduction, Alexandre. Et donc effectivement, Nicolas et Anne nous rejoignent.

10:08 Nicolas, voilà Anne, de la société OuiSNCF, et qui vont vous présenter leur retour d'expérience sur l'APM et Instana. Je vous laisse parler. Bonjour à tous. Alors Nicolas doit vous partager les slides. Oui, c'est bon. Est-ce que vous voyez bien les slides? C'est bon? Oui, d'ailleurs, je vous rappelle que si jamais vous voulez zoomer sur la vignette, elle apparaîtra en grand et on pourrait peut-être regarder plus rapidement et après revenir sur la vue composite avec les différentes caméras. Donc bonjour à tous, l'idée de cette intervention c'est d'essayer de vous partager un peu l'expérience qu'on a eu chez OuiSNCF sur la mise en place effectivement d'une solution d'APM avec un Stanar et donc de vous partager un peu finalement notre feedback autour

11:12 de, est-ce que ça nous a semblé pertinent au final de passer d'une multitude de solutions qu'on avait sur la partie monitoring vers une solution centralisée d'APM. Donc Nicolas, si tu peux nous montrer le sommaire, s'il te plaît. Voilà, donc on va se faire une rapide présentation un peu du groupe et de Nicolas et moi. Vous expliquer un peu quelle était notre situation initiale et ce qui nous a amené à réfléchir à la mise en place d'un APM. Ensuite, on va vous décrire un peu pourquoi on a choisi Instana spécifiquement comme solution. Quelques éléments autour de ce qu'on a vécu depuis qu'on l'a mis en place en avril 2020 comme problématique et comme bonne surprise, moins bonne surprise, et nos enjeux pour la suite, puisqu'on est encore dans cette phase de déploiement, d'adoption, et on a encore pas mal d'enjeux à adresser,

12:13 sur lesquels on s'appuiera aussi sur Instagram. Voilà, donc en termes de présentation du groupe, nous, chez OuiSNCF, on fait partie du groupe e-voyageurs SNCF. C'est donc un groupe qui met à disposition des applications, qui va gérer et mettre en place des applications pour aider à la mobilité. Autour des produits qui sont distribués par la SNCF. Ça se traduit en trois grandes maisons. La première, c'est Oui, c'est le site distributeur, le site web et les applications mobiles. Il y a également l'assistant, qui est une application multimodale qui permet d'avoir de l'information aux voyageurs et puis aussi de rechercher des trajets bout en bout à l'échelle, par exemple, d'une ville pour avoir les différentes solutions de transport disponibles. Et Rail Europe, c'est notre maison de distribution à l'international. Pour les voyageurs qui viennent de l'étranger et qui vont souhaiter faire des parcours en train en Europe.

13:20 Donc, pour vous donner quelques chiffres clés, c'est donc 120 millions de billets qu'on vend chaque année. 110 millions en France et 10 millions à l'international. Alors évidemment, c'est des chiffres 2019. Vous vous doutez que les chiffres 2020 ne sont pas tout à fait les mêmes au vu de la crise sanitaire. Pour autant, on est quand même sur une activité qui est autour des mobilités durables. Donc, on espère vivement que 2021 sera une période de reprise. Sur cette activité. On a 37 millions de personnes qui ont téléchargé les applications, oui, Assistant et Rail Europe. Donc, c'est quand même des applications qui sont extrêmement mobilisées et sur lesquelles on a des enjeux de QoS extrêmement importants. C'est 4,9 milliards de volume d'affaires. Donc, on est aussi sur des volumétries de business qui sont extrêmement importantes et qui mécaniquement mettent là aussi beaucoup d'enjeux autour de notre capacité de réactivité et de maîtrise de notre QoS via le monitoring, entre autres.

14:30 On a donc ensuite un certain nombre de partenaires qui sont présents aussi à l'international pour nous aider à distribuer tout ça. Et on existe depuis 20 ans. Et aujourd'hui, on est 1500 collaborateurs à travailler sur ces différents produits. On peut passer à la suite. Je ne sais pas s'il y a des questions. Je n'en vois pas pour le moment. Très bien. N'hésitez pas à en poser si vous avez des questionnements par rapport à ce qu'on vous raconte. On essaiera de vous répondre au fil de l'eau. Donc moi, je m'appelle Anne Mercian, je suis responsable de la partie suivi de production sur le site et les applications Oui, donc dans l'encadrement des équipes de support client de niveau 2, et puis surtout dans l'encadrement justement de nos process, de nos bonnes pratiques, de nos outils, pour nous permettre d'avoir un suivi de production qui réponde au niveau d'exigence très fort qu'on a. Nicolas, qui est avec nous, qui vous parlera aussi, bien évidemment, il est responsable des équipes DevOps qui travaillent sur le site et les applications.

15:32 Et pour vous donner aussi un peu un ordre d'idée de la taille de notre infra, aujourd'hui, on a à peu près 5000 VM. Pour l'infrastructure voyageur au total et 1200 en particulier sur la partie OuiSNCF web et mobile. Et juste, enfin, bonjour à tous, juste en petite précision, le petit schéma qui est à droite, la petite image incrustée, c'est tiré d'Instana sur notre compte de prod. Diverses trigrammes et noms d'applications ne vont strictement rien vous dire, ça c'est normal, mais en tout cas c'était juste pour incruster un petit exemple, la vue SIMS qui est côté Instana et qui nous permet de visualiser notre infrastructure, et coup de pas de bol, au moment où j'ai fait le screenshot, il y avait des machines qui étaient en jaune, comme c'est le cas en fait assez régulièrement, mais voilà, c'était juste pour la petite histoire. On passe à la suite. Donc voilà, pourquoi on a été amené à réfléchir à une solution d'APM et quelle était la situation antérieure?

16:39 Comme vous l'imaginez, on a une infra qui est très conséquente, qui est hébergée on-prem aujourd'hui, et on a des enjeux business qui sont très forts. Donc, on avait un certain nombre d'outils à disposition pour faire du suivi, des tests automatisés de parcours utilisateurs, pour récupérer de la data, des métriques autour des erreurs rencontrées par nos clients et des taux d'erreur. Des types de problématiques qu'ils rencontraient et sur quel type de parcours avec Omniture. OSS, notre outil de test automatisé de parcours client, c'est un outil fait maison. On utilise également IP Label, qui sont des moniteurs de... De tests. Kibana pour la gestion de nos logs, Grafana pour la gestion de nos métriques, on utilise aussi évidemment Centréon pour la partie un peu plus supervision infra, CollectD, donc on a vraiment une multitude d'outils qui fonctionnent sur des modèles très différents, qui sont lourds à maintenir.

17:46 Et qui demande une maîtrise, effectivement, et Alexandre l'évoquait tout à l'heure, qui fait qu'on a quelques experts sur chacun de ces outils et que c'est un peu difficile. d'avoir une vision d'ensemble et de garder la maîtrise. Tu voulais ajouter quelque chose Nicolas? Oui, juste au-delà de la diversité des outils, il y avait aussi une diversité d'utilisations et de profils de gens qui utilisaient certains outils et pas d'autres. Je prends un exemple très concret, les équipes côté support qui sont chez Anne connaissent relativement peu Centrion parce que c'est là où on va avoir tout notre monitoring infrastructure. Et là, en fait, il s'avérait qu'en tout cas à ce moment-là de l'histoire, on a des gens qui savent qu'il y a une multitude d'outils. Qui ont l'habitude d'en utiliser certains et pas d'autres. Et du coup, ce qui se passe quand il y a un incident, on jongle entre les différents outils.

18:47 On essaie de choper de manière humaine la bonne information sur Centréon qui, corrélée à la bonne information sur Grafana, nous permet de dire« Ah oui, c'est un achat proxy qui est en train de... de nous claquer dans les doigts, donc on a un incident derrière. Voilà, c'est ce qui est mis dans la bullet point, c'est diversité d'outils, mais aussi une vraie vision métier versus une vision infrastructure. Et c'est sur ça qu'on a voulu travailler avec cette vision d'APM. Oui absolument, on avait effectivement un peu un fonctionnement en silo avec des équipes qui allaient voir l'alerting, le monitoring fonctionnel, et des équipes qui allaient voir l'alerting technique, infra, Et on cherchait effectivement la corrélation entre les deux. Et déjà, on ne la trouvait pas toujours. Et puis, il y avait des temps de réactivité qui étaient différents aussi. Et ça, ça contribue. Que notre temps de détection, notre temps de diagnostic soit important en fait, dans un contexte de perte de service, d'indisponibilité, absolument.

20:00 Et du coup, juste pour la deuxième étape, c'est la solution d'hypervision que j'évoque. Effectivement, en 2017, je n'ai pas trouvé les dates exactes, mais entre 2016 et fin 2017, il y a une solution d'hypervision qui a été lancée en interne. Donc l'objectif, c'était finalement présenter à travers un support... unique, alors exemple Grafana, essayer de centraliser et de corréler toutes les informations qu'on pouvait avoir de Domniture, de Centrion, de Kibana, etc. Et de remonter ça de manière automatisée et de corréler les événements. Je ne sais pas s'il y aura des questions précises sur la solution, j'espère que non parce que je ne serai pas capable d'y répondre vu que je n'y ai pas participé directement. Ce qu'on peut dire par contre d'un point de vue nous, clients de cette hypervision-là, c'est que le contrat n'était pas rempli en termes de... En termes de réactivité, en termes de corrélation, et surtout, ce qui ne changeait pas, c'est qu'il y avait toujours cette multitude d'outils qu'il fallait maintenir, tout de même, pour fournir les informations à cette solution d'hypervision.

21:11 Donc c'est quelque chose qui a été abandonné en interne, côté e-voyageur, courant 2018, je crois, quelque chose comme ça. Et ça a été un peu aussi le moment où on s'est dit, est-ce qu'il n'y a pas des gens qui font ça mieux que nous, finalement? avec les difficultés qu'on a listées en dessous et que Anne peut évoquer du coup. J'imagine qu'on est nombreux à se retrouver autour de ce diagnostic, même dans les gens qui participent au meet-up, commencer avec beaucoup d'outils et essayer de faire ça à la maison, entre guillemets. Donc une fois que vous avez eu toutes ces difficultés, Comment vous êtes orienté vers une solution plutôt éditeur pour adresser ces points, plutôt que d'agréger vous-même les services? En fait, ce qu'on a engagé comme démarche, c'était, ok, on était parti d'outils et on voulait faire en sorte que ça marche. On a plutôt pris la posture de se dire, de quoi on a besoin? C'est quoi nos besoins dans le fond?

22:14 Qu'est-ce qui est important pour nous? Les délais de détection, de la corrélation, des choses comme ça. Et en fait, en travaillant sur ces besoins-là, Finalement, de manière un peu naturelle, on s'est orienté sur plusieurs solutions éditeurs, ou en tous les cas, les quatre qui nous paraissaient les plus parlantes sur le moment. Je précise dès maintenant... Et peut-être que je le répéterai plusieurs fois, mais ce qui est important, c'est la temporalité de notre démarche qui était autour de fin 2018. Je précise ça parce qu'il y a certainement des constats qu'on a fait à l'époque qui sont peut-être toujours vrais à l'heure actuelle, ou d'autres qui ont évolué parce que les... toutes les solutions évoluent, que ce soit n'importe quel type d'éditeur. Donc voilà, les constats que je vais évoquer là, qui ont amené à notre choix côté Instana, et qu'on ne regrette pas à l'heure actuelle, c'était des constats qui étaient faits fin 2018.

23:17 Donc du coup, ce qu'il faut savoir, c'est qu'on avait étudié, on a rencontré, 4 éditeurs, Nurelik, Dynatrace, Instana, Datadog. Assez rapidement, on a fait, suite à ces entrevues et au fait d'avoir précisé nos besoins, on a rapidement écarté Dynatrace et Datadog. Pour diverses raisons, Datadog, c'était une solution qui était assez jeune. Qui apparaissait un peu trop, je ne sais pas si c'est le bon mot, mais un peu trop tech, parce qu'on voulait faire en sorte que toutes nos équipes, PO, testeurs, et tous les profils qui accompagnent nos features Team Agile, soient en capacité d'utiliser facilement un outil, et la facilité d'utilisation, la facilité d'accès à l'IHM, ce genre de choses, c'était quand même quelque chose d'assez important. C'est un peu en regard de ce que disait Alex tout à l'heure, on voulait vraiment basculer d'une solution d'experts vers une solution qui apporte finalement des réponses à tous les types de métiers qui tournaient autour d'un produit.

24:20 Et concrètement, sur Datadog, on ne s'y retrouvait pas là-dessus. On a décidé du coup de poquer vraiment New Relic et Instana. Donc on a pris sur un périmètre autre. que celui de OuiSNCF qu'on va vous évoquer juste après, qui était une brique quand même assez importante autour de l'information voyageur. Donc on a poké New Relic et Instana, et le choix Instana qui a été réalisé s'est porté autour de plusieurs aspects. Premièrement, la facilité de déploiement. Et l'auto-découverte des applications. Concrètement, à cette époque-là, on est sur un parc, on a deux data centers, on est sur du on-premise. La facilité d'avoir un agent déployé sur une machine à travers un ERP. À travers plusieurs méthodologies, qui s'installe et qui vient découvrir automatiquement tout ce qui est installé sur votre machine. Ça peut être des process Java, du Node, de l'achat proxy, de la page. Il y a un catalogue applicatif, un catalogue techno qui est assez...

25:21 important. Et donc cette facilité de déploiement, on active l'agent, il envoie les données dans le côté SAS Instana et en fait là sur l'IHM, on va pouvoir observer au bout de 2-3 minutes, quelque chose comme ça, les premières métriques qui remontent, des métriques infra, des métriques métier, etc. Donc la facilité de déploiement, c'est un critère hyper important et assez impressionnant en fait sur le monde. La facilité d'accès à l'offre aussi. Une fois l'agent déployé, on n'avait pas de questions à se poser comparé à New Relic à l'époque encore une fois. On n'avait pas de questions à se poser sur« Ah oui tiens, il faut que j'active tel truc pour la vision infra, il faut que j'active tel truc pour le end user monitoring, il faut que j'active tel truc pour avoir une vue d'ensemble de tout ça, etc. » On a accès à l'offre complète. Dont Alexandre parlera beaucoup mieux si vous voulez des détails. Mais en tout cas, cette vue de bout en bout, on l'avait directement une fois l'agent déployé.

26:24 Troisièmement, la puissance de corrélation entre les alertes que j'ai appelées les infras et métiers, était hyper intéressante pour nous. C'est quelque chose qu'on recherchait beaucoup sur le site OuiSNCF. On a tout de suite, en termes d'incidents, des impacts financiers assez importants. Et c'est vrai que ce temps de corrélation, comme je disais tout à l'heure avec mon exemple, entre« tiens, j'ai une sonde sans tréon qui sonne», bon, ce n'est peut-être pas trop grave sur le moment, et 10 minutes après, j'ai du monitoring métier, ou mon robot fonctionnel qui est passé et qui a détecté qu'au bout de 3 K.O., il y avait vraiment un problème, et 3 fois 10 minutes, 30 minutes, on est rapidement dans des chiffres assez impressionnants. Cette puissance de corrélation était vraiment marquante. Et je précise, tout en paramétrant vraiment le minimum de choses, mis à part le déploiement du RPM sur la machine, finalement,

27:26 une bonne partie des choses, après on peut... On peut personnaliser des noms de services ou des choses comme ça, mais en tout cas, de manière automatique, on va naturellement avoir cette corrélation-là. Et puis, ce qui était vraiment intéressant pour nous, c'était cette expérience, cette expertise pour une vision cloud. À cette époque-là, on est au niveau débutant, voire... Foire en dessous sur la partie cloud, mais en tout cas, c'est une ambition de la société de basculer assez rapidement, en tout cas d'avoir une expertise assez rapide. sur ce sujet-là, et on ne se voyait pas finalement solliciter nos experts sans trayon, etc., pour coller à ce besoin. Nicolas, il y avait une question d'Alexandre Marleau qui demandait pourquoi vous avez exclu Dynatrace assez rapidement du POC. Tu nous as dit pourquoi vous avez écarté Datadog par rapport à la jeunesse de la solution. Tu peux nous en dire un peu plus sur Dynatrace, s'il te plaît?

28:28 Alors sur Dynatrace, il me semble, alors on était un peu tiraillé à l'époque parce que côté Dynatrace, il me semble qu'il y avait déjà un contrat côté OuiSNCF, donc notre maison mère. Donc c'est, j'allais dire, pour ça que Dynatrace est arrivé dans le... Dans la proposition. Alors, je n'ai pas participé à l'époque au différentiel, mais en tout cas, de ce que je m'en souviens, il y avait une certaine complexité au niveau du pricing. Le pricing final, le coût finalement qui était lié à notre infra était beaucoup plus important que ce qu'on nous proposait par ailleurs. Donc voilà, les principaux éléments, la partie coût forcément, on aime bien parler des éléments tech, mais à un moment donné, on en revient à ce genre d'éléments. Justement, si je peux rebondir sur ce sujet, la partie prix.

29:31 C'est intéressant parce qu'avec les APM et l'évolution des architectures comme c'était présenté tout à l'heure par Alexandre, historiquement, on payait des licences par serveur, par hôte, par processeur, etc. Tu parlais du choix d'Instana pour aussi suivre les ambitions cloud de OuiSNCF dans le futur. Donc comment en fait vous avez évalué le pricing d'un Stana ou d'un APM par rapport à votre architecture actuelle, votre infra actuelle on-premise, et par rapport au futur, au cloud, comment on fait? On price un APM quand on passe en mode virtualisé, quand on fait même du serverless peut-être. Est-ce que cette notion de hôte, de CPU ou de serveur a encore du sens? Oui, alors je laisserai peut-être la main à Alex sur la partie bascule côté cloud, mais en tout cas, je rappelle qu'à ce moment-là, on n'avait quasiment aucune expérience côté cloud, donc c'était compliqué pour nous de nous dire, tiens, on va se projeter avec notre infrastructure, comment on la projette côté cloud.

30:32 Sur le moment, à l'instant T, on était globalement un agent Instana égale une licence Instana égale une machine. Donc c'était relativement simple à calculer par rapport à nos plusieurs centaines de machines. Et du coup, derrière, je te laisserai la main du coup Alex pour la partie correspondance côté cloud. Une des forces d'Instana, c'est de proposer, comme je le disais tout à l'heure dans la présentation, un pricing simple, transparent et qui permet de se projeter, quelles que soient les conditions dans lesquelles on est. La plupart des outils qui sont mentionnés, à part Instana ici, sont des offres à tiroirs. En d'autres termes, vous avez le coût d'une licence de base et puis après vous ajoutez des options. Options qui peuvent varier en fonction de votre volumétrie, en fonction du nombre de métriques que vous collectez, de la dimensionnement de vos machines, tout un ensemble de paramètres qui font que pour un décisionnaire, il est assez difficile de se projeter là-dedans.

31:38 Instana, c'est un pricing simple qui inclut absolument toutes les fonctionnalités que nous proposons. Il n'y a pas d'option, il n'y a pas de pricing mystérieux qui va apparaître à un moment donné. Et qui est calibré aussi bien pour du data center que pour du cloud. Donc demain, Nicolas, il enlèvera un agent d'une de ses VM pour aller la porter soit dans du cloud, soit dans du serverless ou des choses comme ça. Il aura tout de suite une correspondance qui lui dira, avec ma licence host data center, je peux couvrir un host cloud type C2, par exemple, sur Amazon ou un GKE ou un GCP. Ou alors, je pourrais couvrir 10 containers Docker dans un environnement Kubernetes, ou je pourrais couvrir 10 fonctions Lambda avec toutes les fonctionnalités qui sont associées, ou 10 Fargate, ou 10 Cloud Run, etc.

32:38 Donc, on a un pricing qui, dès le départ, aujourd'hui, quand vous demandez une cote à Instana, vous savez exactement vous projeter. Quel que soit l'environnement vers lequel vous allez. D'accord, merci. Et là, du coup, si aujourd'hui, sur Anne et Nicolas, quand vous avez fait cette recherche de besoins, Tu expliquais qu'au départ, les outils étaient arrivés en premier. Et puis après, on s'est reposé à la question du besoin pour choisir une nouvelle solution. Comment vous avez pris en compte les différentes populations qui utilisent ce type de solution? Parce qu'avec l'essor des mouvements DevOps et du YouBuildIt, YouRunIt, comme nous le rappelait tout à l'heure Alexandre, Ces types d'outils ne sont pas que utilisés par des administrateurs, mais maintenant aussi développeurs. Par exemple, chez BlaBlaCar, en ce moment, on est aussi sur une étude d'outils pour mettre en place quelque chose qui va remplacer tous nos outils Kibana et Grafana, etc. Et l'expression de besoin et donc la consultation en interne que l'on fait,

33:42 Elle s'étend au-delà de l'équipe traditionnelle de SRE, mais elle inclut aussi tous les développeurs, qu'ils soient back et même front dans mes équipes. On les sollicite pour voir quels sont leurs besoins par rapport aux outils d'APM. Donc comment vous avez pris en compte les besoins de ces différentes populations pour le choix d'un APM? Tout simplement, on a réuni un certain nombre de personnes plutôt autour du monde de l'observabilité à la base pour vraiment lister les principaux besoins que je donnais tout à l'heure. Mais effectivement, dans un deuxième temps, on a été à la rencontre des... Des utilisateurs et des... des diverses populations. L'objectif, c'était deux choses. La première, c'était potentiellement découvrir des nouveaux outils qui sont des fois utilisés par... Je rigole parce que j'ai constaté ça dans la semaine par rapport à une équipe qui utilisait un outil pour faire de la perf sur sa brique, j'ignorais l'existence, mais bref.

34:45 Et en fait, d'une part, c'était connaître leur... Les potentiels outils qui étaient utilisés de leur côté sur leur périmètre, et puis aussi identifier tout simplement ce qui les intéresse, dans la gestion de ces typologies d'outils-là. C'est là où, par exemple, on a eu le besoin côté Product Owner de dire, ah ben moi, je caricature un peu, mais moi, ce qui m'intéresse, c'est de me dire, je mets une feature en prod, finalement est-ce que ma nouvelle feature elle a eu un effet bénéfique sur les diverses métriques fonctionnelles ou métiers qu'on peut drainer et si oui et sinon potentiellement rollbacker assez rapidement pour pas continuer la descente aux enfers et ça Ce qui a été rassurant pour nous sur le moment quand même, c'est de nous dire, ah bah tiens, il y a quand même effectivement des profils ou des besoins assez intéressants à aller creuser parmi toutes les populations.

35:55 Et c'est là en fait, on a été rencontrer PO, testeurs, développeurs, notre équipe autour des tests de charge aussi. Qui avaient des difficultés pour aller un peu connaître tous les environnements qu'on peut présenter au sein de OuiSNCF. Je vous le verrai un petit peu plus tard, mais on a à peu près 15 équipes. Agile qui bosse sur le site et l'application mobile, multiplié par X briques applicatives derrière, c'est vite l'enfer pour savoir à quel moment il y a un point de contention lors d'un test de charge. Et ce besoin-là, finalement, il a été exprimé assez clairement et ça a permis de mettre en lumière pas mal de points de difficulté au niveau des équipes. Et ce qui a été rassurant, c'est de se dire, finalement, tous ces problèmes-là, on peut les adresser, on l'espérait à l'époque en tout cas, avec un seul outil et on a pas mal progressé là-dessus pour le coup. Je ne sais pas si j'ai répondu.

36:57 On passe vite. Je vous laisse dans la présentation. En parallèle, vous pouvez poser vos questions dans le widget de Q&A sur votre interface. Parce que du coup, je pense qu'on va présenter et poser les questions en même temps. Sinon, on va avoir du mal à tenir dans le timing. Et juste pour répondre très rapidement à la question sur les environnements, on a les deux. Des tests de perf bouchonnés sur nos environnements et on a des tests qu'on appelle de pré-prod où là pour le coup on va s'interconnecter avec des partenaires qui nous fournissent les temps de réponse qu'on peut s'attendre sur des environnements de production, notamment côté SNCF. Et là, on va réaliser vraiment de la charge de bout en bout, telle qu'on peut l'attendre lors des pics à l'année qu'on observe sur le site en production. Je te laisse reprendre la main du coup, Anne, pour les... Oui, pour vous donner quelques éléments sur nos constats depuis qu'on s'est équipé d'un Stanarm.

38:04 Le premier, c'est que ça nous permet de faire une rationalisation d'outils. Donc, beaucoup des outils qu'on utilisait historiquement sont en cours de décommissionnement ou l'ont déjà été au profit d'Instana. Donc, on avait effectivement fait l'état des lieux au préalable pour analyser le besoin. Et maintenant qu'on l'a en live, je dirais qu'on a vraiment une démarche de tel outil, à quel besoin répond-il, comment on peut répondre à ce besoin dans Instana. Ou de mettre en place soit des dashboards, soit de l'alerting, soit des custom events pour avoir des métriques afin de remplacer ces outils. Donc on a déjà fait la rationalisation de plusieurs de nos outils et on va le poursuivre sur l'année à venir. On a conservé Kibana aujourd'hui. Parce que pour le moment, dans Instana, on n'a pas une vraie solution de centralisation des logs qui est proposée. Donc, on est obligé pour le moment de garder Kibana, sauf évidemment à ce qu'Instana mette en place cette solution et on se fera un plaisir de décommissionner Kibana avec.

39:11 Ça arrive. Après, ce qui est intéressant, c'est vraiment la synergie que ça a créé. Est-ce qu'on travaille tous sur le même outil, que ce soit côté delivery, release avec les devs, les PO, les testeurs, les DevOps et le support, donc depuis le delivery jusqu'à la prod, on a tous un outil unique et donc c'est extrêmement favorable pour avoir des échanges, pour corréler les événements et pour avoir un peu un langage commun autour de ça. Ça fluidifie pas mal d'analyses, d'avoir un outil unique qui permet de gagner un peu en cohérence. Donc ça, c'est un des éléments très positifs depuis qu'on l'a intégré. Pour autant, c'est à modérer avec le fait qu'il y a quand même une conduite du changement qui n'est pas anodine, qui doit vraiment être menée, qui doit être pilotée, sur lequel il faut avoir aussi un peu de ressources de pilotage et de temps à passer sur de l'onboarding, sur des présentations, des formations, de l'accompagnement équipe par équipe.

40:18 Nous, on a 18 feature teams, c'est plutôt des composants de team d'ailleurs, mais on avait 200 personnes à faire monter en compétences et à aider à adopter ce produit dans leur usage quotidien. Sans être passé en mode Big Bang. Donc, ils pouvaient évidemment continuer à utiliser tous nos autres outils du marché ou maison pendant ce temps-là. Et ça, ça demande quand même un peu de... Oui, un vrai accompagnement. Donc, on s'est heurté un petit peu à ça avec Nicolas parce qu'on le gérait tous les deux en plus de nos activités habituelles. Et c'est vrai que là, on est en train de travailler à dégager une ressource de chef de projet autour de ça pour nous aider à finaliser cette migration et aller au bout. En termes de gains évidents, c'est le délai de détection. Pour vous illustrer ça, à chaque fois qu'on a une indisponibilité de service sur une partie critique du tunnel de vente, on perd 10 000 euros par minute en volume d'affaires. Donc, 5 minutes qu'on peut gagner parce qu'on n'a pas un outil qui doit...

41:24 Des données pour après les pousser sur un graphana pour qu'on puisse visualiser ou avoir une alerte sur un dysfonctionnement. c'est 50 000 euros de gagné en fait. Et ça, c'est vraiment quelque chose qu'on a constaté. Pour le coup, pour vous donner quelque chose de très actuel, on a eu des très forts pics de charges suite aux différentes allocutions gouvernementales autour des confinements, des déconfinements, puisque les gens très rapidement venaient sur le site pour soit annuler des billets, soit en reprendre. Et pouvoir voir extrêmement rapidement si on commençait à avoir une contention, ça nous permettait de réagir plus vite. Et on a vraiment vu la différence là sur tous ces événements que maintenant on pilote à l'aide de dashboards Instana, corrélés aux alertes Instana. Et ça, c'est évident qu'il y a un gain immédiat. Sachant que suite à la dernière allocution du président, le pic de charge c'était plutôt pour prendre des billets que les annuler, j'espère? C'était effectivement surtout de la vente, oui.

42:30 Non, pas de souci. Un élément important quand même sur les points positifs qu'on avait vu, qu'on avait comparé les différentes offres, c'est la possibilité côté InstaNA de visualiser les métriques, donc nombre d'appels sur une API, taux d'erreur, etc. À la seconde. Et ça, en termes de finesse de données et de réactivité, c'est vraiment quelque chose qui est assez appréciable. Bien évidemment, il y a des choses sur les X dernières semaines qui sont importantes. De visualiser côté dashboard et autres, mais comme je vous disais tout à l'heure, par exemple, un PO ou une FT qui suit, suite à une mise en prod, comment évolue son périmètre applicatif en termes de données métiers, ou d'infra d'ailleurs, c'est quelque chose de vraiment appréciable et on peut avoir un temps de réaction qui est... qu'on n'avait clairement pas avant. Une question qui est revenue aussi, c'est que vous avez synthétisé les points forts pour lesquels vous avez choisi un stana dans votre étude.

43:36 Alors, en toute transparence, est-ce qu'il y avait aussi des éléments de faiblesse sur un stana? Des points où Instagram était moins fort que les autres solutions. Rapidement, les points d'attention éventuellement que vous avez identifiés? Fin 2018, quand on a fait le topo, et même des... début 2019, il y avait quelque chose qui nous manquait assez cruellement, c'était la partie mobile, donc la partie visualisation, finalement côté client, à partir des applications mobiles. C'était déjà présent côté web, ce que je disais tout à l'heure avec le end-user monitoring, mais on n'avait pas de... En tout cas, Instana ne proposait pas la partie mobile, sachant qu'actuellement, la partie mobile, ça représente à peu près 60% de notre chiffre d'affaires versus le web. Et voilà, c'est quelque chose sur lequel on avait déjà pas mal échangé et qui était, je crois, déjà dans les...

44:39 Dans les bacs côté Instana. Depuis, ça s'est mis en place, depuis le premier trimestre, je crois, de cette année. Mais voilà, il y avait deux, trois fonctionnalités comme ça qui étaient... Les logs, à l'époque, étaient quelque chose d'assez... Marquant pour nous parce que historiquement, on se base beaucoup sur tout ce qui transite dans nos logs. Et c'est quand on parlait de culture tout à l'heure, on aborde aussi le sujet mis en lumière des faiblesses côté code, etc. Ne répondant pas aux standards. Finalement, en ce moment, on est en train de basculer dans un mode faisons confiance à nos API. Au code retour, à ces choses-là, versus ce qu'on avait historiquement l'habitude de faire, c'est-à-dire, allez, on blinde tout ce qu'on peut dans nos logs applicatifs, autant avoir 10 Tera par jour et peut-être qu'il y a une ligne qui nous satisfera.

45:40 Et je caricature à peine, c'est vraiment quelque chose qui était assez ancré chez nous. Et le fait finalement... Que la centralisation des logs ne soit pas proposée, je pense que ça, avec le recul, ça a été limite positif pour nous dans un premier temps, parce que ça nous a permis de nous remettre à plat des bonnes pratiques qui ne sont pas inventées par nous, des simples standards HTTP, des respects de headers HTTP qui transitent par les API et qui transitent dans tout notre SI. Toutes ces choses là c'est des choses que potentiellement ça aurait pas été un stade ça aurait été autre ça aurait été peut-être la même chose mais mais en tout cas avec un stade ça nous a permis de reposer toutes ces bases là et ça c'est quelque chose sur lequel on va vraiment capitaliser pour la suite. Juste petit commentaire sur ce sujet. De manière totalement agnostique, pas par rapport à Instana ou par rapport à n'importe quel outil, les outils d'APM

46:44 viennent souvent en friction avec les outils de log, parce que les logs permettent de voir les choses d'une certaine manière, les outils d'APM, que ce soit Nurelic, Dynatrace, voire même Introscope pour les plus anciens d'entre nous, ou AppDynamics ou Datadog, etc., permettent de voir des choses et finalement on peut s'affranchir d'une partie des use case que l'on pouvait avoir avec les logs. Et effectivement, comme l'exprime Nicolas assez bien, ça permet aussi de prendre conscience que le log ne fait pas tout, que souvent on utilise un lance-flamme pour tuer un moustique avec les logs, ou on collecte des teras et des teras de logs juste pour aller chercher une ligne qui sera probablement présentée différemment sous un outil d'APM, mais dont c'est le travail. Je sais que c'est difficile quand on a été perfusé au log de passer à un outil d'APM. Pour avoir travaillé chez Dynatrace, chez AppDynamics, j'ai travaillé avec différents outils aussi à côté. Ce n'est pas toujours facile de faire ce changement de paradigme.

47:49 Il n'a pas besoin d'être complet. C'est pour ça d'ailleurs qu'on va intégrer des logs sous peu dans la solution. Mais ça permet aussi de se déshabituer un petit peu à la manie de... de consommer du log en permanence où finalement on cherche un mot dans des millions de pages de log juste pour aller chercher une information. Juste pour enchaîner, tu veux continuer du coup? Oui, alors juste pour repréciser la partie d'avant, quand même pour nous, sur le dernier point précédent, sur la détection, Vraiment, il y a une vraie qualité justement, et c'est ce qui nous a plu dans Instana, sur la possibilité de mettre en lumière graphiquement ces éléments-là dans des dashboards. Parce qu'en fait, chez nous, on est particulièrement sensible au fait qu'une alerte technique, évidemment, elle peut mettre en lumière un problème qu'il faut corriger, mais très rapidement, on a besoin de voir quel est l'impact pour le client.

48:51 Et la mise en place de ces dashboards se suit vite en réel. Il nous permet de voir telle problématique qu'on est en train de voir sur cette machine. Ce que ça génère, c'est une chute des mises en panier. Sur le tunnel de vente. Et pouvoir faire cette corrélation-là au travers de ces interfaces graphiques, pour nous, c'était essentiel. Alors, on en attend plus et on travaille en étroite collaboration avec les équipes Instana là-dessus parce qu'on part d'un fonctionnement sous Grafana qui est extrêmement complet. Mais pour autant, il y a déjà à ce stade des possibilités graphiques qui sont très intéressantes pour avoir l'impact fonctionnel, l'impact métier. d'un problème technique. Donc ça, c'est important. Ça nous aide aussi à travailler effectivement sur le suivi de nos changes en production. Nous, comme je vous le disais, on a 18 composantes team qui sont en delivery continu. Donc on a en moyenne une cinquantaine d'actions qui sont faites sur la production chaque jour. Et ça, c'est uniquement sur nos infras parce qu'on a en plus des interventions de nos équipes d'hébergement, donc sur des parties réseau, etc., qui peuvent venir s'y ajouter.

49:58 Et le fait de pouvoir avoir des release markers, la mise en place de maintenance Windows pour justement ne pas lever l'alerte quand on fait des déploiements et pouvoir les avoir en visibilité, ce qui permet très vite de voir que quand on a une chute d'appel sur une prod, c'est simplement qu'on a fait un passage en blue-green et on a le release marker qui mentionne qui a fait la mise en prod, sur quelle brique, etc. Ça, c'était un vrai plus pour pouvoir suivre notre change en production. Et évidemment, si on avait un incident qui faisait suite à une mise en production, on va tout de suite pouvoir corréler le dysfonctionnement à ce risque marqueur. Une innovation plus efficace, plus facile, C'est effectivement pour intégrer des nouvelles technos, pour explorer cette partie cloud. On en parlera dans les enjeux, mais on commence effectivement une démarche de migration. Et donc, ça permet effectivement de pouvoir appréhender ça très simplement. Effectivement, c'est facile d'installer des agences, c'est facile de voir le fonctionnement et de l'intégrer sur des nouvelles technos.

51:07 Par rapport aux EUM Web et Mobile, tu voulais peut-être en parler, Nico, sur le fait que par rapport aux frontes? Exactement. Avant notre démarche d'APM, la partie front, on était vraiment très pauvre, voire on n'avait quasiment aucune surveillance de cette partie-là. Donc la partie web dès le début, puis mobile depuis, comme j'ai dit, depuis... depuis le premier trimestre à peu près de cette année, on a fait un vrai gap par rapport à ce qu'on avait avant. En parallèle de ça, il y a des équipes, et notamment certains profils front, qui avaient envie de tester l'outil Sentry. Pour aussi challenger un petit peu les offres. On peut rester aussi ouvert à d'autres possibilités. Si je résume un petit peu notre sentiment à l'heure actuelle, la partie centris et on va dire la Rolls Royce pour nous, on s'est fait une conviction sur le fait que la qualité, le fait qu'Instana propose ce qu'il propose et le fait de le proposer aussi

52:15 au sein de toutes les autres fonctionnalités et d'avoir cette vue unifiée front-back, peut-être sur la partie front, il y a moins de fonctionnalités qu'avec Sentry, mais par contre, pour l'usage qu'on en a, C'est quelque chose qui nous satisfait entièrement. Le fait de pouvoir remonter les principales erreurs JS, le fait de nous alerter dessus, ça c'est quelque chose qui n'existait pas, je crois, fin 2018, il n'y avait pas d'alerting sur la partie front, je me souviens maintenant. C'est quelque chose qui a été mis en place depuis, mais en tout cas, ça nous satisfait pleinement pour les puristes. Sentry est quand même un cran au-dessus. Et à l'écoute de nos besoins, comme on l'a déjà dit, sur plusieurs exemples. Il y a une vraie écoute, on a pas mal échangé avec Alexandre et puis avec un technical account manager depuis le lancement de la licence officielle. On exprime nos besoins, le support aussi est assez réactif.

53:25 Juste un petit exemple qu'on voulait vous montrer, on parlait de l'effet Macron et des diverses fonctionnalités qui peuvent rassembler les différents types de profils qu'il peut y avoir dans une équipe ou dans une business unit. Globalement, ce qui était important pour les grands chefs, c'était quoi? C'était de se dire, finalement, comparer à la même période, c'est-à-dire, c'était mardi soir autour de 20h, comparer à la veille, par exemple, est-ce que je peux facilement visualiser que... La partie devis sur le... Alors ça, c'est que du web. La partie devis, comment elle a évolué par rapport à... Au moment où Emmanuel Macron parlait, la mise en panier, bien évidemment, ce qui peut intéresser, c'est la partie finalisation, derrière, il y a les paiements. Et pour la petite anecdote, puisque les journaux ne parlent que des plus 400% de ventes faits à ce moment-là.

54:26 Le petit pic là, c'est qu'on a eu un incident de prod assez conséquent. et je tairai les détails pour ne pas enfoncer les bonnes personnes. Et du coup, en fait, ce qui a été rigolo sur le moment, enfin rigolo, façon de parler, c'est que l'asset qui nous a créé cet incident de prod n'est pas sur un stana, Et finalement, alors ce n'est pas du tout ça qui a provoqué l'incident de fraude, bien sûr, mais du coup, en termes de suivi et de réactivité, finalement, c'est plutôt nous qui avons prévenu le fait que c'est... Prévenu le fait que c'est... En dessous de notre récit, commençait à avoir un problème plutôt que l'inverse. Et voilà, ça a été assez marquant sur le moment. Mais voilà, d'où le petit... Le double pic là qui est dommageable mais... Autre exemple, donc là je vous ai montré c'est la fonctionnalité de custom dashboard, vous créez vos petits widgets en fonction de ce qui vous parle.

55:29 En dessous il y a une notion de service, donc là on a VSH c'est notre API de de recherche et du coup on va potentiellement avoir les informations relativement classiques qu'on pourrait en attendre, nombre d'appels, nombre d'appels en erreur avec le taux, la latence moyenne avec les différents percentiles, etc. Une visualisation des différents codes HTTP, là je ne l'avais pas activé sur le screenshot, j'aurais bien voulu cliquer mais je n'avais pas mis le time shift pour pouvoir comparer. Et la petite fonctionnalité assez récente qui est assez plaisante, je ne sais pas si vous voyez les petits trucs mauves qu'il y a en dessous, mais grosso modo, Instana nous pousse des suggestions de création d'alertes au-delà de ce qu'il détecte automatiquement. Il va nous dire, tiens, sur cette période-là, peut-être que de créer une alerte sur un pic de latence dans telle condition, c'est une bonne idée. Il y a aussi une gestion un peu intelligente et poussée.

56:30 Et la troisième chose qui était là pendant l'allocution également, le petit nom de code ici qui est entouré en jaune, c'était la brique sur le moment qui nous posait problème. Donc on a une cartographie en live. De nos différents composants. Alors les noms ne vont absolument pas vous parler encore une fois, mais ce n'était pas forcément le but. Mais en tout cas, on peut visualiser à l'instant T de manière simple. Et je pense que, sans vouloir faire offense à qui que ce soit, tout le monde peut interpréter que là, le jaune, c'est qu'il y a peut-être un petit souci. La taille du... Du rond est aussi un peu plus grosse. Et ça, c'est des fonctionnalités en termes de cartographie. Je crois que ça fait depuis 15 ans qu'on essaie de créer quelque chose en interne qui nous permet d'auto-découvrir et cartographier notre récit. Et c'est relativement appréciable pour le coup. Assez rapidement parce que je crois qu'on a beaucoup débordé je crois. Oui Nicolas, justement j'allais demander en fait parce que c'est un sujet passionnant visiblement pour parler des heures.

57:31 On avait projeté 30 minutes, ça fait pratiquement une heure. Oui, pardon. Est-ce qu'il y a peut-être deux questions que j'aimerais vous poser qui ont été posées dans le chat et puis peut-être un mot de conclusion pour terminer la session. Donc la première question rapidement, c'est Samir Ben Saoud qui le pose, qui dit au-delà de la visibilité technique et de l'opération que fournit Instana, je crois qu'il en a parlé un petit peu, c'est comment Instana vous a aidé à avoir un petit peu plus de visibilité? avec des indicateurs métiers dont tu nous parlais par exemple, est-ce que tu peux répondre très rapidement ? Oui absolument, c'est effectivement l'un des enjeux forts qu'on avait sur la mise en place, c'était de pouvoir corréler une alerte technique, une alerte infra, à son impact sur le business, sur le tunnel de vente, sur nos fonctionnalités critiques. Et ça, c'est vraiment quelque chose qu'on arrive à voir avec la mise en place de ces dashboards, de ces alertes aussi en natif sur les services spécifiques qui sont sur la finalisation des différentes étapes du parcours de vente.

58:35 Et donc, on arrive très facilement à faire cette corrélation-là et à mettre en face un problème technique avec son impact client pour aussi chercher des solutions de contournement, faire de l'accompagnement de la relation client quand on a ces dysfonctionnements qui sont en cours. Donc absolument, on peut corréler le business avec le… D'accord. Avec le technique. Merci. Et après, il y a Nadem qui nous pose deux questions. Une petite question technique, je la pose à Alexandre, sur des problèmes éventuels pour détecter des bots, des user agent bots sur le web, j'imagine. Est-ce que c'est toujours le cas? Pas particulièrement, non. On peut effectivement simplement filtrer et raffiner les informations qui préviennent des user agent bots. C'est un cas d'usage qu'on a mis en place chez OuiSNCF sur des problèmes éventuels pour détecter des bots, des user agent bots sur le web, j'imagine.

59:40 Est-ce que c'est toujours le cas? Pas particulièrement, non. On peut effectivement simplement filtrer et raffiner les informations qui préviennent des user agent bots. C'est un cas d'usage qu'on a mis en place chez OuiSNCF sur des problèmes éventuels pour détecter des bots, des user agent bots sur le web, j'imagine. Mais dans un contexte totalement différent. Pas sur les user bots en particulier, mais sur la capacité de récupérer ce type d'informations pour aller la ventiler et être capable de faire des recherches et isoler certaines populations. Ça fait partie des fonctionnalités. Ça sera un peu trop long à expliquer techniquement parlant parce que ça touche au tracing, ça touche aux applications de perspective et à beaucoup de choses autour de ça. C'est le type de use case qu'on a pu mettre en place sur les plateformes de test justement pour les aider à mieux isoler leurs... test et pouvoir faire ce chose. Donc, ce n'est pas du tout une problématique. Sur l'autre sujet, la validation de la partie hotspot, temps de réponse, etc., là, on est plus dans des notions de profiling des composants applicatifs. Ce sont des choses qui ont été rajoutées ces derniers mois avec la capacité de profiler en permanence, en temps réel et en production, tout l'ensemble des composants que l'on peut avoir, que ce soit du Java, que ce soit du Python, du Node.js, du PHP, etc. On a un profiling permanent qui va nous permettre à posteriori ou même en temps réel d'aller regarder ce qui peut se passer au niveau de tous ces hotspots de code et de faire ces analyses de stack d'appel pour faire une optimisation éventuelle.

1:00:50 Alors attention parce que cette partie profiling, elle a beaucoup de sens dans les opérations sur des monolithes où effectivement les opérateurs historiques que peuvent être Abdinamix, Nurelik, Dynatras avaient une certaine manière de le faire. Voilà, c'est aujourd'hui de moins en moins nécessaire avec l'émergence des microservices puisque finalement quand on donne les éléments à un développeur en lui disant voilà quel a été le point d'entrée, voilà quels ont été les vecteurs de sortie de ton service, il sait immédiatement où regarder puisqu'on n'est plus sur un monolithe qui va passer par des centaines de couches mais uniquement par une API qui va traiter, qui a été développée pour traiter une ou deux, trois fonctions et simplement les... Entrée-sortie suffit généralement à faire ça, mais on a quand même rajouté ce profil. Très bien, merci beaucoup. Dernière question peut-être de Cédric de Saint-Martin qui parle de la fonctionnalité de navigation entre les dashboards qui permet d'aider la corrélation entre les problèmes. Est-ce que c'est quelque chose que vous avez constaté, Nicolas? Est-ce que c'est quelque chose qui vous parle et qui est utilisé?

1:01:54 Oui, complètement. Comme je disais tout à l'heure, la partie corrélation d'incidents se matérialise par... Sur l'IHM, un espace incident, vous avez le mode, il y a eu un incident sur telle API, il va potentiellement vous corréler ça avec un incident infra, une issue infra, une issue métier, etc. Et à partir de là, vous pouvez très bien les naviguer pour avoir un peu plus de précision, par exemple sur les X API qui ont été incriminés, et aller voir un peu plus précisément l'historique par rapport à ce micro-service ou autre. Donc complètement, c'est quelque chose qu'on utilise beaucoup. Ok, en conclusion, merci au passage à Tommy, qui a visiblement été très inspiré par à la fois l'outil et le texte. Merci Tommy. Dernière question pour conclure cette présentation, Anne et Nicolas.

1:02:55 Comme je disais, je pense qu'il y a des participants de ce meet-up, beaucoup de gens qui seront connus un petit peu dans la... situation de OuiSNCF il y a quelques années, avec une profusion d'outils, maisons, etc. Cette envie de centraliser, d'avoir un outil qui fait tout et qui représente tout. Donc, si vous pouviez donner en un mot, en fait, votre conseil, un conseil pour les entreprises qui cherchent leur solution d'APM, comment ne pas rater ce choix et comment aborder ce projet. Très bonne question. Moi, je parlerais quand même de la conduite du changement. C'est important de l'incarner, c'est important de bien piloter le suivi de l'adoption et la conduite du changement au sein des équipes pour que ça soit le plus rapide possible. Si on veut bénéficier de cet effet rationalisation, etc., il faut qu'on réussisse à rapidement aborder l'ensemble des typologies de personnes sur le projet.

1:04:01 Imagine s'il faut décommissionner après tous les outils, il y a beaucoup de populations qui ont leurs habitudes et qu'il faut convaincre de leur donner leurs habitudes. Pour basculer sur un nouvel outil, c'est toujours un moment clé effectivement. Nicolas, un petit conseil toi de ton côté? Moi je reviendrai sur le côté identification des besoins à la base. Et je crois que le sujet des logs il est assez parlant finalement de quoi on a besoin dans notre quotidien. Pour avoir ce... le niveau d'exigence qui nous est fixé ou qu'on se fixe à nous-mêmes. Bien évidemment, il y a beaucoup d'outils qui ont l'ambition de fournir la meilleure chose possible. Après, potentiellement, on parlait du profiling, c'est quelque chose à l'heure actuelle qu'on utilise relativement peu. Je ne sais pas, très clairement, ce serait une bonne idée de le faire. Mais en l'occurrence, c'est un exemple qui montre qu'on s'est focussé sur la partie incident, sur la partie suivi bout en bout web. C'est nos besoins à nous.

1:05:02 Et je pense que quand on lance une démarche comme ça, comme dans tout projet informatique, j'allais dire, ça permet de ne pas se tromper sur la suite et d'aller à l'essentiel pour pouvoir avancer concrètement sur des choses qui nous concernent le plus possible. Je crois que revenir sur l'expression des besoins auprès des futurs utilisateurs et préparer l'accompagnement en changement, c'est deux conseils qui ne peuvent pas être mauvais dans tout projet informatique, que ce soit pour choisir un APM ou un autre. Merci à tous, à Nicolas, Alexandre pour la présentation, merci à Tommy aussi pour les dessins. Et puis, je rappelle sur scène Noémie pour la conclusion de ce meet-up. Merci. Merci beaucoup à toi.