You Build It, You Run it, l'observabilité pour les devs

Merci.

Merci Anaïs.

Bonsoir, bonsoir à tous et à toutes.

Installez-vous, faites comme chez vous, mais n'oubliez pas que vous êtes chez moi. Vous devez le reconnaître, c'est ma quatrième conférence, à chaque fois que je commence comme ça. Bon, je suis un peu déçu, c'est la communauté PHP, je pensais que vous aviez tous des Lamborghini J'en ai pas vu devant.

Je pense que vous ne faites pas assez de statique. Top à la vachette c'est parti, je voudrais remercier l'AFUP pour l'invitation, pour les travaux colossaux qu'ils font.

Il faut savoir que nous on vit une conférence, eux ils en vivent une autre.

Donc ils viennent très tôt le matin et partent très tard.

Beaucoup de travail en amont, travail de l'ombre donc merci à eux.

Moi aussi je fais du PHP, j'ai pas de Lamborghini, pas encore, et du coup je fais du PHP depuis quelques années.

C'est une reconversion que j'ai faite.

Voilà, ça fait peut-être neuf, dix ans maintenant. J'étais chauffeur de taxi, problème de santé, et du coup il fallait que je change de job et je voulais faire un site internet pour qu'on puisse me réserver, pour avoir des clients.

Et à l'époque, lorsque tu Googlais « Comment faire un site dynamique ? » Tu tombais sur PHP.

Je ne sais pas si c'est encore le cas aujourd'hui, mais je suis tombé dans la marmite du PHP.

J'ai appris, j'ai progressé.

C'est ma quatrième conférence.

Si un jour on m'aurait dit que j'allais faire une conférence devant la communauté francophone de PHP, je n'y aurais pas cru. J'aurais dit garde ton argent, évite la drogue, achète des Haribo, c'est mieux pour toi ! Mais du coup on y est.

Et ça me fait dire que si vous avez des objectifs, si vous avez des envies, vous savez des choses.

Enfin, la plupart du temps, ce qui vous retient c'est dans votre tête, allez-y et on sait jamais sur un malentendu ça peut passer.

Donc je m'appelle Smaïne, ok.

Je suis développeur formateur.

Ça c'est tous les liens sur lesquels vous pouvez retrouver un peu mes travaux autour de l'écosystème PHP.

Le dernier lien, c'est les conférences que j'ai faites, donc celle-ci et les slides seront sur ce lien-là.

On va faire un petit jeu, c'est un rébus très très simple, ça n'a rien à voir avec la conférence.

Mais du coup, si vous devinez le rébus, vous tweetez.

Je dis pas sur X parce qu'il y a mon daron, il va regarder.

Donc sur Twitter, vous tweetez le rébus, vous me mentionnez, pas besoin de me suivre, je m'en fous des followers, mais juste vous me mentionnez pour que je vous retrouve et vous mettez bien le Forum PHP en hashtag et je vais tirer deux personnes qui auront deviné le rébus.

Je leur offrirai un bouquin tech de leur choix.

Donc juste mentionnez-moi comme ça je vous retrouve.

Donc c'est parti.

Je prends mon temps parce qu'en fait souvent je vais trop vite, et à la fin je me fais défoncer de questions.

Donc là je vais être tranquille. On va parler de run, on va parler d'observabilité.

J'ai eu un peu de peine pour vous, je vais vous éviter le gros bouquin, je vais faire un truc assez rapide : le run pour les nuls.

Oui, les dev sont nuls, quand ça ne marche pas, on est nuls et quand ça marche, on est les meilleurs.

Donc là j'ai mis le run pour les nuls, mais j'aurais pu mettre le run pour les devs.

Est ce que vous savez ce que c'est que l'observabilité ? Il y en a qui savent ici ? Est-ce que vous pouvez lever la main ceux qui savent c'est quoi l'observabilité ? C'est bien, il y en a pas mal, très très bien.

Donc moi je ne suis pas de la génération chatGPT, machin et tout ça.

Moi c'est France 3 et donc j'ai demandé au bon vieux Jamy c'est quoi l'observabilité ? Allô Jamy, dis moi, c'est quoi l'observabilité ? Alors, l'observabilité c'est la capacité à comprendre, à monitorer, à diagnostiquer un système d'information.

Jamy, merci mec ! Par contre, fais gaffe, t'as changé de tête et en plus t'as un gilet jaune derrière.

Et quand tu sors avec un gilet jaune, faut faire attention.

Ok, merci Jamy, mais pourquoi on aurait besoin de faire ça ? Ah oui, pourquoi on a besoin de savoir que si son système va bien ? Ça marche en local, c'est connu, ça marche.

En local, je pousse, en prod, ça doit marcher. Parce que everything fails all the time.

T'as capté l'accent ? Ça, ça veut dire que tout est amené à planter à un moment donné ou un autre.

C'est une phrase du CTO d'Amazon et il a raison.

Toutes les applications sont amenées à péter d'un moment donné à un autre.

Que ce soit n'importe quel GAFAM, ça plante.

Et d'ailleurs moi je suis un peu égoïste.

En fait, quand je vois que Slack plante ou lag, je suis content.

Je me dis mais attends, il y a des ingés à 300K là bas, ça plante ? Du coup moi ça plante, c'est pas très grave, tu vois.

Donc ça me rassure.

Et donc oui, tout est amené à planter, c'est vrai, oui.

Et du coup, et bien, on va mettre de l'observabilité en place pour être sûr que son système marche bien, et marche toujours bien.

Puis on va aussi mettre l'observabilité pour détecter les problèmes en amont.

Souvent, il y a des problèmes qui vont arriver et si on intervient à temps, si on les détecte, on peut éviter que ça parte en cacahuète.

Aussi, ça va nous permettre de détecter les problèmes de performance.

Si vos utilisateurs / utilisatrices vous remontent des problèmes de performance, souvent c'est trop tard et du coup, si vous avez des bons outils d'observabilité, vous pouvez tout de suite voir que vous n'avez pas trop de volume mais que ça commence à aller un peu en cacahuète.

Et du coup, si vous extrapolez, ça va plus marcher à un moment donné et donc l'observabilité va venir ici vous aider à voir qu'il y a des choses qui ne vont pas Pareil dans les process asynchrones.

Ça c'est le mot magique. Dès qu'il y a un truc qui est un peu lent, « Fous-le en asynchrone, ça prend 1h, mets-le en asynchrone ça prend 8h, mets-le en asynchrone ». Et du coup, avec des outils comme ça, tu peux savoir combien de temps ça va prendre et si ça devient trop long ou pas, et tu peux t'en occuper tranquillou Gilou.

Ensuite, ça va permettre aussi de capter les comportements bizarres.

Oui, nous on est des devs, on développe une application avec une super interface pour que ça marche avec un plan A : le bouton il est là, faut cliquer dessus.

Mais les users sont des singes, c'est connu, ils cliquent partout.

Tu vois, tu joues à mon app ou à Street Fighter, qu'est ce que tu fais ? Et du coup ça marche plus. Si tu as de l'observabilité, tu peux voir tout de suite que le comportement il n'est pas normal.

Les choses qui sont faites dans l'app ne sont pas normales.

Et en fait ça, si les clients ne te le remontent pas ou les clients ne te le remontent pas, tu ne le sauras pas.

Du coup tu mets en place de l'observabilité pour catcher ces comportements et les corriger.

Puis si tu es bien outillé, tu vas minimiser le risque de downtime parce que tu vas intervenir en amont, ça, je l'ai déjà dit.

Mais surtout, comme ça va planter à un moment donné, tu vas réduire le temps de downtime.

C'est ce qu'on appelle le MTTR.

Le Mean Time To Resolve, si tu es bien outillé, ça va planter, tu vas vite savoir d'où ça vient, pourquoi ça a planté et donc tu vas vite repartir, ton app va vite reprendre vie, et du coup ça va bien se passer.

Et si on additionne tout ça, qu'est ce qu'on obtient ? Parce que zéro plus zéro égal la tête à Toto.

Mais du coup, si j'additionne tout ça, j'ai un client content.

Si j'ai un client ou une cliente contente, les devs sont contents.

Ah oui, c'est eux qui payent la prod, c'est eux qui payent les salaires.

Donc du coup, moi les clients, il a pas de remontées, pas de bugs, il peut travailler tranquillement.

Donc la satisfaction client c'est la priorité des devs, c'est bien connu.

Et donc on va mettre tous ces outils en place pour que les clients soient contents nous arrêtent de nous casser la tête parce que ça ne marche pas très bien.

Alors comment on fait ça ? Parce que maintenant on a vu qu'est ce que c'était que l'observabilité, et pourquoi on en avait besoin ? Alors comment on va...

Quels sont les leviers qu'on a pour mettre ça en place ? Et bien il y a trois piliers.

Le premier pilier s'appelle les logs.

Le deuxième pilier, ce sont les métriques.

Je vais rentrer dans le détail après.

Le troisième, ce sont les traces.

Traces.

Le tracing, je crois qu'on peut le traduire en français celui-là.

Je fais un peu de latin. Rosae, Rosa, Rosae, ça date, donc voilà.

Ça, c'est ce qu'on appelle les trois piliers de l'observabilité. À la fin de la conférence, s'il vous plaît, retenez ce truc-là au moins, « Ton talk il était pourri, mais j'ai retenu ça ». Je vais être content, tu vois.

Donc les traces, les logs, les métriques sont les trois piliers de l'observabilité dans les bouquins, les articles, etc.

Mais comme c'est ma conférence, je fais ce que je veux, 49.3 démocratique, j'ajoute les alertes.

Oui parce que si ça part en cacahuète et que j'ai pas d'alerte et que je ne le sais pas, ça me sert à rien.

Alors les logs, qu'est ce que c'est que les logs ? C'est le truc le plus connu des devs.

Les logs ça va être du texte, tu vas avoir une date à un moment donné, un timestamp et tu vas avoir tout ce qui s'est passé dans l'app.

Donc souvent on a des logs système par rapport aux outils qu'on utilise, mais tu peux aussi avoir du log applicatif que tu as mis toi même dans ton dans ton Symfony, ton Laravel, tout ce que tu veux.

Et en fait ça, ça va t'aider à débugger et à voir que ça se passe pas bien.

Tes logs, tu vas pouvoir les exploiter avec différents outils.

Là, je montre un screen de Graylog.

Alors moi je suis pas commercial, j'ai rien à vendre.

Cette conférence n'est pas sponsorisée, donc si je parle d'outils, c'est pas parce qu'il est forcément meilleur qu'un autre.

Même si il fut un temps où j'étais en stage chez K par K, et qu'on appelait les gens, on devait tous s'appeler Mr Louis. Guette la tête de Mr Louis s'il te plaît ! Voilà, j'ai rien à vendre mais du coup Graylog c'est un outil qui est hyper sympa, c'est un Elasticsearch derrière, ça vous permet de faire de l'agrégation, de faire de la recherche sur des mots clés etc, et de voir que vous avez tant de temps, de messages etc qui contiennent ce contenu et c'est hyper pratique.

Et du coup, les logs il faut les exploiter, il ne faut pas les laisser pourrir dans un var/log/env.log.

Donc il faut aller regarder ce qui se passe dedans, il faut les utiliser. Les métriques, c'est le deuxième pilier puisque vous avez bien suivi, ça vous permet de traquer la performance de votre application et de votre système.

En fait, les métriques, ça vous permet d'observer la bonne santé de l'application.

En gros, moi je compare ça à des capteurs.

Quand vous avez quelqu'un qui est à l'hôpital en mauvais état et ferme les yeux, on lui met des capteurs.

On ne sait pas s'il est cané ou pas.

Du coup, si ça bouge, il est encore là, tu vois.

Et ton app sait pas si elle est canée mais si tu as des métriques, tu peux vite voir si ça marche bien ou pas, etc.

Donc tu vas mettre des métriques sur plein de choses.

Sur le nombre de 500. Tu vas mettre des métriques, sur le nombre de fois où ton endpoint il est appelé, sur la latence de ta base de données.

Tu vas mettre des métriques un peu partout dans ton app parce que ça va permettre de voir comment elle se comporte et comment elle vit.

Toi derrière tu vois une UI qui est affichée, tu sais pas que derrière, la base de données elle souffre, t'es pas au courant ? Du coup tu mets des métriques, par-ci, par-là, tac, tif, touf et ça marche bien.

Voilà à quoi ça ressemble des métriques.

Il y a de la latence, on voit la latence, on voit le nombre de fois que tes endpoints sont appelés, etc.

Le type des méthodes qui est fait, etc.

Et donc ça, en réalité, franchement, c'est de l'or, c'est une mine d'or, ça permet de comprendre comment se comporte ton app.

C'est comme quand tu as une bagnole, t'ouvres le capot, tu regardes, tu dis ah ouais, c'est ça qui se passe, c'est cool.

C'est la même chose avec les métriques.

Troisième pilier, c'est les traces.

Ça, c'est hyper important dans un monde de systèmes distribués.

Oui, oui, il y en a qui ont échappé aux microservices, mais ils se sont fait attraper quand même parce que tu as quand même besoin de faire appel à des services externes, donc tu dois quand même être au courant de comment ça se comporte.

Et donc le tracing, le tracing, trace, aidez-moi, ça te permet de suivre un peu le comportement de ton application si tu veux savoir combien de temps il a passé dans le contrôleur, combien de temps il a passé dans la base de données, dans tes workers asynchrones etc etc.

Et tu vas pouvoir comme ça identifier un peu les bottleneck et prendre des actions.

Et donc là j'ai pris un autre exemple bidon d'une doc je pense, et du coup on voit que j'ai passé tant de temps dans la route dans ce contrôleur là, que j'ai mis tant de temps en appelant cet endpoint-là, que mon select a pris tant de temps, etc etc.

Et ça, c'est le troisième pilier.

Le quatrième pilier, ce sont les alertes. Alerte générale ! Vous vous rappelez de Taxi ? Quelque chose ne va pas ? Oui, à quoi ça sert de mettre des métriques si on n'est pas prévenu lorsque ça ne va pas ? Ou d'avoir des logs si on ne sait pas qu'on en a trop, etc.

On ne va pas passer la journée devant l'écran c'est ce qu'on fait, mais je veux dire pas passer la journée devant l'écran à mater des métriques et à regarder que ça monte, ça descend.

Oui c'est bizarre, c'est trop haut.

Du coup on va mettre un système pour être alerté quand ça va pas, recevoir une notification.

Un truc qui dit attention, je sais pas moi, t'as eu tant de 500 sur les dix dernières minutes.

Attention, tu as eu tant de 400 sur cette route là.

Et surtout, si vous faites des API qui sont publiques ou privées, franchement, regardez le nombre de 400 que vous retournez. Ça va vous dire si votre API elle est bien documentée ou pas, ou si le front fait du caca parce qu'il valide pas en amont.

Ça, ça donne des bons tips, des bonnes informations sur vos API et je parle d'expérience.

Du coup, vous voulez être alerté quand il y a des choses qui ne vont pas et vous mettez en place de l'alerting.

Et une fois qu'on a dit tout ça, qui est responsable de faire tout ça ? Qui est responsable de mettre en place l'observabilité dans les équipes aujourd'hui ? Premier réflexe, c'est les SRE.

Les OPS, c'est eux ! C'est eux qui fournissent l'infra, c'est eux qui fournissent le Redis c'est eux qui mettent en place le MongoDB, la base de données etc etc.

C'est leur problème, ça ne marche pas, c'est toi.

Lui il va dire mais non, non, c'est toi le dev, tu fais du caca.

Depuis que tu as déployé, tu as fait 50 milliards de select etc.

sur ma base, ça ne tient pas. Il faut que tu optimises, il faut que tu mettes des index, il faut que tu fasses des trucs.

On va sortir, on va arrêter de se jeter la balle et faire du ping pong, on va arrêter ça, et on va bosser main dans la main.

Fusion ! DevOps.

Voilà, c'est ça qu'on aime.

On va bosser en équipe, main dans la main, c'est mignon, en harmonie.

On va harmoniser nos connaissances, nos compétences, nos process, nos outils. Et du coup, ça va être la responsabilité de tout le monde.

Je m'arrête sur DBZ, c'était quelque chose quand même.

Hein ? Non, maintenant ça a changé.

Maintenant, c'est quoi ? C'est Pat Patrouille ? Ah, c'est vrai.

Tu me diras si tu dois aller botter le derrière avec Chase.

Hum.

Vaut mieux avoir un bon Goku.

Un beau San Gohan bien énervé, hein ? Franchement ? Maintenant, je vais parler de Yousign.

You build it, you run it.

Alors c'est une vision dev, c'est à dire c'est au point de vue des dev, le boulot des dev chez Yousign par rapport à l'observabilité, c'est cette conférence.

En face de moi il y a des dev. Donc Yousign c'est une entreprise française qui fait de la signature électronique.

Ce slide-là, il est plus à jour mais j'avais la flemme d'en faire un nouveau.

Il date du mois de mai quand je suis venu à l'AFUP Day à Lyon.

Merci la Team Lyon, c'était trop cool, Ils sont là, et du coup à l'époque il y avait 12 000 clients.

Mais les affaires marchent ! Maintenant, on a 15 000 clients, trop cool.

4 millions de signatures par mois, peut-être même plus du coup maintenant.

Et tout ça, c'est en full PHP Symfony.

Pour ceux qui disent « Ouais PHP ça scale pas, etc » Peut-être qu'un jour je viendrai devant vous pour vous montrer comment on l'utilise nous, dans notre quotidien et comment ça nous aide.

Et ceux qui disent « PHP ça scale pas », c'est les mêmes qui disent « PHP est mort ».

Alors moi je peux vous dire ils vont mourir avant PHP, je serai peut être pas là pour le voir, mais je suis sûr et certain qu'ils vont caner avant PHP.

C'est sûr, je vous le dis.

Alors comment on est organisé chez Yousign ? On a sept squads. Une squad est composée de devs, s'il n'y a pas de dev, il n'y a pas de produit, d'un manager, d'un product manager, potentiellement d'un designer.

Et on va avoir des SRE, donc des Ops qui ont un rôle un peu transverse.

Ils ne sont pas affectés à des équipes.

Chaque squad est responsable d'un périmètre précis. Donc on va avoir une squad qui va s'occuper de la préparation du document que vous voulez faire signer.

Puis tu vas avoir une squad qui va s'occuper du process de signature du document, puis une squad qui va s'occuper de l'archivage, des documents, etc etc.

Et chaque squad est responsable et c'est là où c'est important, de son propre périmètre.

Chaque squad est autonome sur l'observabilité dans son périmètre.

C'est à dire que si vous mettez en production un nouvel endpoint ou une nouvelle fonctionnalité, c'est à vous en tant que dev d'aller penser à ça et d'aller observer.

Personne va vous dire « vous avez mis en place un nouvel endpoint, est-ce que vous avez regardé comment il se comporte, est ce que vous avez regardé s'il est performant ou pas ? » Donc c'est des réflexes qu'il faut avoir ou on sort du truc ou moi je mets en production et je ferme les yeux.

Non, tu mets en production, tu suis l'utilisation et tu suis comment c'est utilisé.

Chaque squad a un runner, on va voir ça après.

Et parmi les squad il y a l'agence DX.

La squad DX, il n'y a pas de Barracuda. Si, il y en a un, vous le connaissez peut-être, il s'appelle Benoit Galati.

Donc l'agence DX c'est une squad qui a un rôle transverse et donc si je donne une big picture, leur boulot c'est de s'occuper de tout ce qui est tech et tout ce qui touche un peu à toutes les squads.

Donc par exemple les upgrades des librairies PHP, l'upgrade de Symfony, les libs qu'on va utiliser, de faire en sorte qu'on a un process de release, que la CI elle tourne bien.

Et puis ce sont aussi des developer assistants.

En fait, maintenant je suis vieux et quand j'étais junior et que j'étais coincé sur un problème, j'avais peur de relever le problème.

Junior, on va dire que je suis nul etc.

Donc je pouvais rester deux jours sur le soucis.

Maintenant, je suis vieux, une demie heure ça ne marche pas.

« Pourquoi ça marche pas ? Qu'est ce qui se passe ? Venez m'aider ».

Donc ils nous aident pour ça aussi.

Et pourquoi je les mentionne ? C'est hyper important.

Nous on est une trentaine de devs, on partage un monolithe et donc on a des problèmes qui concernent tout le monde.

Et quand tu as des problèmes qui concernent tout le monde, personne ne s'en occupe, c'est connu.

Donc il faut une squad dédiée à ça et ils nous aident énormément.

Et aussi c'est un peu le bridge entre les SRE et les devs.

C'est à dire quand tu as une question qui est technique sur ta base de données, sur les workers que tu utilises, etc.

Avant d'escalader aux SRE, tu peux aller voir les devs.

Et donc si vous avez des équipes comme ça qui partagent la même code base, pensez à mettre en place ce genre d'équipe transverse.

Franchement, ça facilite ces developer experience, vraiment.

Nous, ça nous aide beaucoup.

Et là on va parler du runner.

Donc moi le runner, j'ai appris ce nom là chez Yousign.

Dans les bouquins, on parle d'On Call Engineer.

En fait, cette personne là, c'est la personne qui va être responsable d'intervenir en premier s'il y a un incident ou un incendie, comme vous voulez.

Donc elle va monitorer d'abord, elle va regarder que tout se passe bien ou pas, puis le cas échéant, elle va communiquer.

Puis s'il y a des problèmes, c'est elle qui va s'occuper de faire un hotfix.

Et potentiellement, on va écrire aussi un post-mortem.

On va voir ça après.

Et c'est elle qui peut avoir l'ownership sur ça.

Ça veut pas dire qu'elle ne va pas être aidée dans ses missions, mais si elle est de run, c'est ce qu'on attend d'elle, de cette personne.

Ça, c'est moi.

Pas en slip, n'abusez pas, en train de pleurer.

Voilà, en train de pleurer parce que c'est mon premier jour de run.

J'entendais souvent les gens dans l'équipe dire « Ouais, demain je suis de run, demain je suis de run » Ben demain aussi je suis de run, il y a quoi ? Et du coup, ça ne marche pas, il y a un problème et du coup je savais pas comment faire, je savais pas où regarder, je savais pas comment débugger, je connaissais pas toute la stack, tous les outils.

Et en fait quand tu comprends rien et que tu te sens inutile, t'es hyper frustré.

À la fin de la journée, tu as envie de pleurer et il y a une question qui se pose : qui peut-être runner donc du coup, qui peut avoir ce rôle-là dans les équipes ? Au tout début on avait un système qui était dans l'abstract de la conférence, qui était une licence to run où en gros tu étais un peu responsable, tu devais passer un QCM pour dire oui, t'as eu tant de % de bonnes réponses, tu peux donc être runner.

Mais en fait ça ne marchait pas très bien.

Du coup, on a changé le système, on est passé sur un système qui est plus straight forward qui est, tu veux être runner à partir du moment où tu en as envie et où tu as une expérience un petit peu sur la stack technique, sur les outils qu'on va utiliser.

Dans ce cas, tu peux faire du run tranquillement.

Ce qui peut vous aider là dedans, c'est moi, j'aime bien dire c'est en codant qu'on devient coderon, et bien c'est en runnant qu'on devient runner.

En fait, tu vas faire du pair run avec quelqu'un donc pendant une semaine, vous allez faire ensemble du shadow, il va y avoir des alertes, des choses à regarder.

Il va vous montrer les bons réflexes, comment utiliser les outils, où regarder, etc.

Mais il faut quand même des qualités pour faire du run.

Oui oui, on ne prend pas n'importe qui hein.

Capacité d'analyse. Parce que quand il y aura des problèmes et vous allez avoir des problèmes, il faut savoir dire si c'est grave ou pas.

Il faut savoir dire oui, c'est très très grave, non, c'est pas grave du tout, on s'en fout.

Et oui, c'est grave. D'où ça vient ? Il faut quand même une capacité d'analyse, Il faut du self-control, il faut du sang froid.

Parce que quand ça plante, il y a rien qui marche.

Ne pas se mettre en PLS.

Au secours ! Non.

Il faut quand même de l'analyse, avoir un peu de recul et se dire ok, ça plante, pourquoi je regarde où, etc.

Comment je fais ? Donc il faut avoir de la lucidité et pas s'énerver, garder le sang froid, etc.

Et il faut savoir aussi communiquer. C'est hyper important je pense, c'est un des grands défauts qu'on a nous en tant que devs, c'est qu'on ne sait pas très très bien communiquer et par communiquer, j'entends vulgariser.

Pourquoi ? Parce que lorsque vous avez un souci, il faut le remonter aux équipes non tech.

Donc imaginez que vous avez un problème.

Vous mettez en production des calls, une API Stripe par exemple, et vous avez oublié de mettre la variable d'environnement la variable d'environnement à jour sur l'environnement de prod.

Ça, ça ne vous est jamais arrivé, c'est sûr et certain.

Du coup ça ne marche pas. Et du coup, vous allez faire quoi ? Vous allez voir le service client.

« Oh, j'ai oublié de mettre à jour la var d'env, ça marche pas » Il va vous regarder, Il va saigner du nez, et il va dire quoi ? Qu'est ce qui se passe ? Donc vous dites « On a un problème de configuration. Dans dix minutes, ça va aller mieux » Voilà, il faut savoir vulgariser et communiquer avec les autres équipes et même si on est frustré, stressé, etc.

Ne pas répondre sèchement, prendre sur soi, etc.

Enfin, c'est hyper important.

Parmi les qualités.

Je vous ai remis le rébus.

J'espère que vous avez trouvé comme il est facile.

Donc n'oubliez pas Forum PHP l'hashtag et mon compte Twitter, comme ça je pourrais vous retrouver.

Du coup, ça c'est les devs.

Lorsqu'on fait du build, on est hyper content.

Le build c'est quoi ? Le build c'est quand on fait de la feature, de la fonctionnalité.

Nous on veut que faire ça.

La TMA, machin, oublie.

Nous on aime bien class new class hein ? On part d'un écran tout vide, l'IDE.

Il a montré comment on fait, Charles, avec PhpStorm pour ceux qui ont Mac ? Alt Shift Control hop lève les pieds et tac, ça marche ! Moi aussi j'ai un Mac, mais bon, c'est pas facile tous les jours, mais on est piqués.

Donc lorsqu'on fait du build, on est content, on aime bien, on part from scratch. Mais il faut aussi assumer le run.

Alors qu'est ce qui est bien lorsqu'on fait du run ? Y a quand même des avantages.

Qu'est ce qui est bien lorsqu'on fait du run ? C'est qu'on va progresser sur les soft skills et les hard skills.

Oui, parce qu'on va avoir des soucis qu'on n'est pas amené à avoir.

On va devoir utiliser les outils qu'on utilise au quotidien, mais peut être de manière plus profonde, on va devoir parler avec d'autres équipes, etc.

Donc franchement, intrinsèquement, vous allez progresser. puis on va être conscients un peu de ce qu'on délivre.

Oui, si quelqu'un fait une requête hyper crados, il met en prod et que ça plante, on peut pas dire oui mais ça a marché.

« Mais oui, j'avais cinq fixtures ».

En prod il y a 12 millions, c'est pas pareil, tu vois.

Donc si tu es amené à réparer ce genre de conneries, quand tu dev, tu fais attention, donc tu te dis ah ouais mais là c'est scalable avec user 1, user 2, user 3, les tests passent.

Est ce qu'avec user 1 million ça va fonctionner ? Donc tu vas quand même te poser des questions sur ton delivery et faire en sorte qu'inconsciemment tu vas être conscient.

Cette phrase, inconsciemment, tu vas être conscient de ce que tu délivres, puis tu vas échanger avec d'autres équipes parce que tu vas aller voir quand ça va mal se passer.

Tu vas vouloir aller prendre de l'information, donner de l'information.

Donc tu vas sortir un peu des gens que tu côtoies dans ton quotidien, tu vas aller voir d'autres personnes, ça et ça, c'est vraiment cool.

Par contre, ce qui est pas cool.

C'est le dé-focus.

Juste avant, Aline nous disait que c'était hyper important d'être focus et elle a entièrement raison.

Et du coup, c'est vrai que ce qui est difficile lorsqu'on fait du run, c'est qu'il faut se dé-focus.

Vous êtes sur votre tâche puis il y a une alerte qui pop, vous allez regarder l'alerte.

Puis en fait c'était rien mais 2 h plus tard, vous avez trouvé que c'était rien, vous retournez sur votre IDE, vous vous dites « J'étais où là ? C'est quoi ce if ? Il sert à quoi ? » Moi je dis souvent que lorsqu'on dé-focus un dev, c'est comme les personnes qui sont venues ici en voiture avec leur GPS. Si elles se trompent de chemin, certes, le GPS, il va recalculer la route, vous allez y arriver, mais vous aurez perdu du temps.

Lorsqu'on est dev, c'est pareil, vous êtes sur une tâche, sur un truc.

Si on vous dé-focus, c'est mort, vous allez perdre beaucoup trop de temps.

Donc faire du context switching comme ça, aller sur l'alerte, souvent, c'est dans 95 %, même plus que ça, c'est souvent rien.

Il faut s'assurer que ce n'est rien.

Et du coup, ça fait perdre du temps, ça engendre de la fatigue et du stress.

C'est pour ça que ces rôles, il faut faire du Round-robin, donc des rôles tournants, c'est à dire une fois par semaine, vous changez de personne, sinon vous êtes crevé.

Et si c'est vraiment hard, si vous avez beaucoup, beaucoup d'erreurs, etc et que c'est le feu, je ne vous le souhaite pas, mais du coup tournez tous les deux ou trois jours.

Enfin, c'est hyper important de préserver sa santé mentale parce que des fois le run ça peut être stressant.

Qu'est ce qui se passe ? Je suis de run aujourd'hui ? On m'a pas dit, j'ai dit que j'étais au Forum PHP, il y a une erreur qui apparaît, il faut que je la catch.

Bon, on va regarder qu'est ce qui se passe lorsqu'il y a une erreur qui pop chez Yousign, comment on s'organise ? Déjà Sacha mets toi sur le côté parce que toi t'es pas un bon chasseur de Pokémon.

Moi j'ai chassé Mew. Mew, il a une tête de bug, je vais m'en occuper, t'inquiète.

Alors comment est ce que l'erreur est détectée ? Déjà, il y a du monitoring, donc on a beaucoup d'outils de monitoring et lorsqu'on va mettre en production des choses qu'on sait un peu sensibles, on va surveiller après la mise en production s'il y a eu des problèmes ou pas. Si on voit que ça commence à faire Stonk c'est bizarre, on a trop de latence, trop de trucs chelous, il faut qu'on intervienne.

Puis on peut recevoir aussi un message d'un client du support nous disant oui, depuis ce matin on reçoit des problèmes, les e-mails ne partent pas, etc etc.

Enfin peu importe.

Ou alors on a une alerte et là c'est ce qui s'est passé, on a reçu une alerte sur Slack. On utilise Opsgénie qui va nous permettre un peu de dispatcher les alertes, de suivre un peu le nombre d'alertes qu'on a, le temps qu'on met pour les résoudre, etc.

Et donc là, j'ai reçu une alerte et en fait, qu'est ce qui s'est passé ? J'ai une erreur 500 lorsque j'appelle telle route, telle API, etc.

Puis tout de suite, je vais avoir des éléments qui vont me permettre de qualifier l'alerte.

Avant d'entrer dans le détail de cette alerte je vais tout de suite voir si c'est un peu tendu ou s'il faut que je regarde ou pas, ou si je peux aller prendre un café.

Là, c'est une P2.

P2 ça veut dire que.. Ça va de P1 à P5.

P1 c'est pour les SRE, c'est que c'est très grave, il n'y a plus rien qui marche.

P2 c'est les dev, faut qu'on regarde, c'est pas hyper impactant, mais peut- être donc on va quand même jeter un œil.

Puis on va voir quelle équipe est concernée.

Là c'est nous la team PHP. Allons voir.

Il se trouve que c'est hyper grave ce qui se passe.

Il y a trop de remontées, ça ne marche pas, ça fait que de poper là, il faut qu'on s'en occupe.

Donc on va dans ce qu'on appelle la war room. C'est sur Discord, on a un channel qui s'appelle la war room. Quand il y a des gens dedans, ça sent pas très bon.

Donc on va dedans, on va discuter directement, oui parce que Yousign c'est une entreprise en full remote.

On a des bureaux à Caen et à Paris, mais la plupart des tech, nous on est tous en full remote et on a Discord toute la journée, et notamment ce channel pour échanger là.

Donc, on va dans ce channel et là on va y retrouver les devs ou les devs qui sont concernés.

Donc le runner, potentiellement le manager en bleu, potentiellement le Product Manager s'il veut comprendre ce qui s'est passé depuis la dernière release, un SRE s'il nous faut un robot parce que là c'est un peu technique et le service client qui veut prendre de l'info.

Puis t'as quelqu'un en rouge qui veut discuter. Et lui, on va faire en sorte qu'il s'en aille.

On va faire en sorte qu'elle s'en aille.

« Ah ça va, tu as fait quoi hier ? Tu as mangé où ? Et tout ? Non, s'il te plaît, c'est un peu chaud donc merci » Maintenant, on a l'intelligence de le faire.

On fait en sorte qu'il n'y ait que des personnes qui ont de la plus-value qui soient dans cette pièce-là, dans cette room.

Et donc, comme c'est impactant et qu'on aime nos clients et qu'on veut prendre soin d'eux et qu'on est transparents, on publie une status page qui dit : « On a un souci, ne vous inquiétez pas, on est 10 X engineers à l'appel, on va s'en occuper, mais on a quand même un problème. » Et donc on va creuser, on va les fixer.

Et oui, il faut résoudre.

Le monde se divise en 2 : ceux qui ont Jira et Figma, et les dev qui ont un IDE, c'est ça ? Donc nous on creuse, voilà et eux regardent : « Ça avance ? Vous avez un ETA ? Vous avez corrigé ? » Et en fait ce qui se passe, c'est que le dev il est tout seul, le pauvre, il transpire, puis il partage son écran sur Discord et puis nous on l'aide.

C'est comme Fort Boyard : « À gauche là il y a un if, derrière, attention, la classe, stop, ajoute un test, t'es sûr ? Mais si, on a déjà fait ça, ça ne marche pas, machin etc. » Comme on 10x ingénieurs, on va résoudre, on va résoudre, ça va bien marcher, on va reprendre une activité normale et on va dire sur la status page, « Tout va bien, on a corrigé, vous pouvez reprendre une activité normale. » Mais quand même, il faut que ça nous serve.

Il faut que cet incident-là, il nous serve et donc on va créer un post-mortem.

Le post-mortem, c'est un document public ou privé, ça va dépendre des boîtes, sur lesquelles vous allez détailler tout ce qui s'est passé et comment vous en êtes arrivés là.

Donc nous, on a un template qui est assez bien fait, et on va détailler, expliquer qu'est ce qui s'est passé, quelle est la root cause, pourquoi on en est arrivé là, on a eu combien de temps de downtime, comment on a corrigé, etc etc.

Et quelles sont les prochaines étapes.

Le but du post-mortem, c'est de tirer les leçons.

C'est de faire en sorte que ça ne se reproduise plus.

Et donc on va avoir un follow up avec des actions.

Et fun fact, suite à deux post-mortem ou un post-mortem je sais plus, on a créé deux librairies. Dont une que j'ai dev parce que je suis rigolo, mais je suis aussi dev, qui a été téléchargée soixante mille fois.

Donc moi je me suis planté, j'ai cassé la prod pour que ça vous serve, c'est cool.

C'est ça la communauté, non ? Et donc on va prendre des actions, faire en sorte que ça ne se reproduise plus, etc.

En termes d'outils, encore une fois, je ne suis pas commercial, mais si vous voulez sponsoriser pour des confs, n'hésitez pas.

Du coup, je montre ce qu'on utilise au quotidien, en tout cas en tant que dev et ce qui nous suffit, nous à assurer l'observabilité et faire du run.

Donc Opsgénie, c'est le système d'alerting, Sentry vous devez connaître, Graylog je vous ai montré, Slack, communication écrite.

Discord n'est pas uniquement... Discord, c'est hyper cool.

Moi j'ai beaucoup travaillé en full remote et avant de rejoindre Yousign, c'était pareil, j'étais en full remote mais on n'avait pas, j'avais pas Discord.

Et quand je suis arrivé chez Yousign, j'ai découvert Discord.

En fait c'est trop cool parce que tu as toujours des gens sur les channels de ton équipe ou pas, sur lesquels tu peux échanger.

Et quand tu es tout seul chez toi, t'es content de retrouver d'autres personnes et d'échanger.

Puis Redash pour faire du readonly et mettre des alertes sur ta base de données donc c'est hyper pratique.

Tu vas dire que si ta base de données te retourne tel résultat, il y a un truc, ça ne va pas et il faut aller regarder ce qui se passe.

Puis Datadog aussi que vous devez j'imagine, connaître.

Je vais arriver à la fin. La clé.

La clé, c'est l'anticipation pour avoir un bon système, pour mettre en place l'observabilité, éviter les downtimes, réduire le temps de downtime si vous en avez et vous en aurez.

C'est l'anticipation en fait.

Quand ça va planter, il sera trop tard pour regarder et mettre des outils en place.

Donc il faut le faire en amont.

Et alors je vous donne deux trois trucs.

Déjà, il faut commencer par créer des dashboards si vous en avez pas et un peu vous les approprier.

C'est pas uniquement les SRE ou les Ops qui doivent avoir la main sur ces choses là.

Vous pouvez énormément les aider.

Eux, ils savent pas ce que vous développez, ils ne savent pas là où vous faites n'importe quoi, donc faut vraiment aller les aider et du coup apprendre le ownership sur ça.

La fusion DevOps, rappelez-vous.

Donc vous améliorez aussi les dashboards qui existent.

Moi chez Yousign j'ai fait plusieurs squad et j'ai un petit réflexe lorsque j'arrive dans une nouvelle squad, c'est de regarder s'ils ont assez au niveau des dashboards, si on est bons ou pas bons, etc.

Qu'est ce qu'on peut améliorer.

En fait, souvent ce qui se passe, c'est par mimétisme.

Donc si quelqu'un dans votre entreprise va mettre en place un dashboard, les autres le feront de manière copier coller, ce qu'on fait tous les jours.

Donc ils feront pareil mais pour les dashboards et du coup c'est pas très grave tant que c'est fait et que ça fonctionne.

Créez vos propres alertes, n'attendez pas que le système vous propose des alertes, faites-le vous-même et mettez-vous dans le cas où, qu'est ce qui va se passer, qu'est ce qui pourrait m'aider lorsque ça va aller mal ? Qu'est ce qui peut m'aider à voir que ça va mal ? Donc posez vous ces questions là avant d'être dans le trou.

Une fois dans le trou, c'est fini.

Posez vous ces questions, écrivez des logs dans votre code applicatif et mettez des logs sur ce que vous faites et sur ce qui se passe.

Je vous jure, si vous écrivez des logs et que vous débuggez et que vous voyez les logs que vous avez écrit, vous allez vous remercier.

« J'ai été intelligent il y a une semaine quand j'ai mis ces logs-là, sinon j'aurais passé une semaine sur ce truc sans ces petits logs. » Donc écrivez des logs, n'en soyez pas avare. Documentez et mettez en place des process.

Alors oui, je sais, maintenant c'est no process, no estimate, yolo. Ayez des process, chaque seconde compte, lorsque l'application est down, lorsqu'elle a des soucis, chaque seconde compte.

Et on peut pas se poser la question de qu'est ce qu'on doit faire, où on doit regarder, etc.

Donc mettez en place des process pour que ce soit hyper fluide, puis expérimentez donc amusez-vous même à péter l'app et à voir comment vous allez réagir, comment vous allez faire.

Entraînez-vous si vous n'avez pas l'habitude, c'est un peu du Chaos Monkey, mais à votre échelle et testez.

Vaut mieux avoir trop de dashboards, trop d'alertes que pas du tout.

Donc faut en mettre en place et puis après épurer, corriger, etc.

Merci beaucoup.

Je n'ai pas encore totalement fini.

Les chats, c'est mignon uniquement quand on n'en a pas.

Je tiens à vous le dire et si vous avez des questions, je suis disponible.

Et surtout, c'est important de laisser du feedback, même mauvais.

Enfin voilà, donc n'hésitez pas à laisser du feedback.

Voilà, merci.

Merci beaucoup.

Merci beaucoup Smaïne, on a largement le temps de prendre des questions.

Oh mon dieu, je vais simuler un malaise la prochaine fois.

Merci pour la conf, tu mentionnais à un moment donné que les alertes, tu en avais souvent, où en fait t'allais voir et en fait c'était pas grand chose.

Et du coup, comment tu réévalues qu'une alerte en fait potentiellement, soit faut changer les critères pour l'alerte, soit voire carrément la supprimer.

Moi mon crédo c'est est-ce que j'ai une action à faire tout de suite ou pas ? Si j'ai pas d'actions à faire, pour moi, l'alerte elle a pas vraiment de sens en fait, tu vois.

L'alerte, c'est là où tu as une action à faire et du coup tu veux aller corriger ce qui se passe.

Ce qui fait que des fois tu as des alertes qui ne servent à rien.

Et ça aussi c'est un réflexe que j'ai eu moi, donc quand j'arrive dans une squad, en fait, il y a beaucoup d'alertes.

Franchement, il n'y a aucune action à faire côté dév donc du coup tu la supprimes et t'en entend plus parler quoi.

Donc voilà, de toute façon c'est simple, l'alerte tu vas la voir une fois, tu vas la corriger. Deux, trois ou quatre fois, elle va te saouler, c'est bon, cela ne sert à rien, vous êtes ok si j'enlève, oui on est ok, poubelle, On en parle plus.

Oui bonjour, merci pour la conférence, je continue sur le thème des alertes.

Les alertes sont configurées chez vous pour partir sur quelques channels ? SMS, Slack, e-mails. Est-ce vous avez aussi un runner qui change chaque semaine, est ce que vous le changez ? Est ce que c'est une adresse qui est dédiée pour une personne ou à plusieurs personnes ? Alors il y a la team développeur expérience qui n'est pas très loin qui pourra te répondre mieux que moi, mais nous elles sont routées, en tout cas en tant que devs, elles sont routées sur Slack vers les équipes concernées.

--Donc tu vas avoir un "squad-alert" et du coup c'est comme ça que ça va tomber.

J'imagine que nous c'est de la c'est de la P2 donc c'est moins grave.

Les P1 c'est quand le système est out.

Là à mon avis il y a des SMS qui partent et des emails aussi.

On reçoit aussi des e-mails lorsqu'il y a des alertes.

Bonjour, j'avais une petite question par rapport au post-mortem.

Tu disais que vous écriviez des actions à faire, comment vous faites pour en fait éviter qu'elles tombent dans l'oubli et que du coup en fait on fait juste rien ? Est ce que vous avez un suivi par rapport à ça ? Yes excellente question, mais du coup, c'est très bien que tu poses la question parce que ça rentre pas dans la conv, je sais pas trop où le mettre.

Mais oui, en fait quand tu fais un post mortem une fois par semaine, il y a une réunion des managers pour voir un peu faire l'état des post-mortem où on en est.

Et aussi tu vas avoir des actions à prendre et tu a des priorités un, deux, trois et quand tu as des actions qui sont prioritaires, quand c'est niveau 1 il faut les prendre tout de suite et les post-mortem, ils ne tombent pas dans l'oubli parce qu'à chaque fois on les remet sur la table, on en est où et pourquoi, etc.

Et le fait de faire ça souvent, c'est dû à des erreurs applicatives, des erreurs de code en fait.

Tu vois, si ce sont des erreurs du système, tu peux rien faire à part augmenter ta base etc.

Mais ce qui fait qu'en fait, comme on surveille à chaque fois ce qu'on fait, on est dans un cercle vertueux et dès qu'on a un souci, on sait d'où ça vient et donc on corrige assez rapidement.

Merci beaucoup.

On va stopper là pour les questions.

N'hésite pas, je suis disponible. Merci.

Merci à vous.