#5 — Autoscaling lag @ Doctolib

Pic de charge et gestion d'incident à Doctolib

Écouter l’épisode

Transcription

François: Bonjour à toutes et à tous et bienvenue dans post mortem. Je m’appelle François et aujourd’hui, on se retrouve pour un épisode sur le format phare du podcast puisque l’on va vraiment parler d’un incident survenu au cœur d’un service informatique et présenté comment celui-ci a été découvert, résolu, ce qui est un marché moins bien marché dans sa résolution et surtout les leçons tirées de cet événement. Pour discuter de cet incident, j’ai la chance de recevoir aujourd’hui Benoît Lafontaine, Engineering Director chez Doctolib, enchanté Benoît.

Benoit: Bonjour François. Merci beaucoup pour l’invitation.

François: Avant de zoomer sur l’incident, auquel tu as fait face avec ton équipe il y a il y a peu, est ce que tu pourrais nous résumer brièvement l’activité de Doctolib et vos principaux services?

Benoit: Bien sûr. Doctolib, c’est plus trop une startup, puisque cela a été commencé en 2013 par trois fondateurs et qui a pour but, une grande vision, de transformer le système de santé et de l’améliorer.

Benoit: Et pour ça, aujourd’hui, on a deux services phares. Le premier étant la prise de réservation en ligne pour les docteurs. Et à côté de ça, on a aussi tout ce qui est téléconsultation. Et derrière la prise de rendez-vous, la prise de réservation, c’est vraiment tout un agenda, un gros système d’agenda qu’on met à disposition aux praticiens et aux services de santé.

Benoit: Quelques chiffres pour vous présenter aussi la dimension de Doctolib. Aujourd’hui, on a une prise de rendez-vous jusqu’à 15 millions de rendez-vous par mois.

Benoit: Des gros pics de charge, c’est important parce qu’on va y revenir un petit peu après. Qui montent à peu près à 10 000 requêtes par seconde les lundis matin; les lundis matin étant notre pic d’activité de la semaine. Les gens attendent finalement le week end pour rappeler leur docteur s’ils sont tombés malades le week end. Et c’est une grosse partie du secrétariat aussi, toute la mise à jour de l’agenda des praticiens se fait en grande partie le lundi matin.

François: Par rapport à l’actualité, est-ce que vous avez eu des pics de demande étant donné la période sanitaire? Et avec le covid ? Est-ce que ça s’est traduit par une augmentation claire de la charge sur vos services de prise de rendez-vous ou téléconsultation, principalement ?

Benoit: Alors, lors de la première vague, c’est sûr qu’il y a eu un impact très fort sur notre service. Un premier en baisse puisque finalement, il y a beaucoup de gens lors de la première vague de confinement qui ont renoncé à aller vers leurs praticiens.

Benoit: Donc, une baisse d’activité et aussi des activités qui étaient soit fortement diminuées, soit quasiment à l’arrêt. Je pense notamment à tous les kinésithérapeutes, les ostéopathes. Donc, il y a eu une baisse de prise de rendez-vous et d’activité sur notre plateforme. Par contre, il y a eu une explosion complète de la téléconsultation puisque c’était vraiment une alternative qui était peu connue auparavant par des médecins que nous on essayait vraiment de pousser fortement et d’essayer d’augmenter la téléconsultation, le nombre de téléconsultation. Et là, par la force des choses, il y a beaucoup de médecins qui ont souhaité continuer leur activité et c’est une bonne chose et la meilleure façon de le faire dans les règles de l’art de la sécurité en ce moment, c’est finalement de le faire par téléconsultation lorsque c’est possible. On a fait quasiment x100 sur le nombre de téléconsultations qu’on pouvait faire sur une période donnée.

François: Alors on va voir que cette question d’élévation de charge est très importante dans la suite de notre discussion, puisque effectivement, c’est à la suite d’une élévation imprévue soudaine de charge que votre infrastructure a été soumise à une grosse pression qui a mené à un incident ou au moins à une dégradation de service.

François: Est-ce que tu peux nous parler un peu plus de cet incident, Benoît? A commencé peut être par la façon dont vous l’avez découvert ?

Benoit: Alors, dans un premier temps. Comment on s’est aperçu qu’il y avait un problème, notre équipe DevOps en charge de l’infrastructure et des serveurs a eu une alerte.

Benoit: Donc ça, ça s’est bien passé pour le coup. On a des alertes avec Datadog, qui est un outil de monitoring avec un PagerDuty qui est un système aussi d’alerting. Donc on a, ce qu’on appelle chez nous un DutyOps. Notre DevOps qui est chargé de regarder si tout va bien, qui reçoit cette alerte-là et qui voit du coup un indicateur que l’on suit, c’est finalement le Request Queuing de notre plateforme. Alors Request Queuing, pour expliquer un petit peu, c’est qu’en fait, un serveur Web, c’est finalement quelque chose qui répond à une demande, donc où il y a un utilisateur qui fait une demande sur un serveur et le serveur va apporter une réponse.

Benoit: Un parallèle qui est assez simple à voir, c’est on imagine un guichet ou plein de guichet SNCF, par exemple. Vous arrivez, vous avez une demande, vous voulez émettre un billet, est-ce qu’il y a un guichet qui est libre ? Oui, j’y vais et j’accède à cette demande. On me donne une réponse. Alors, c’est exactement la même chose. Je veux faire une demande de prise de rendez-vous, via le site. Est-ce qu’il y a quelqu’un qui est disponible ? Si oui, on me donne la réponse très rapidement. Sinon, j’ai une file d’attente, Request Queuing, file d’attente. Et là, j’attends. Notre but, c’est que notre plateforme n’ait jamais de Request Queueing. On a vraiment envie que ce soit hyper performant et qu’on ait des réponses quasiment instantanées.

Benoit: Et là, en quelques dizaines de secondes. En fait, on a ce Request Queueing, ce temps d’attente qui augmente fortement. Ça, c’est un problème. Là, on se dit il y a un problème sur la plateforme et on va en crise chez nous qu’on appelle crisis. On aime bien les anglicismes, voilà, on part en crise.

Benoit: L’incident lui-même a commencé à 12h53, le 6 novembre 12h53. L’incident commence. La personne le détecte, analyse et lance notre gestion de crise. Ça dure trois minutes, à [12h ndlr]56, on a plusieurs personnes qui sont alertées par des SMS pour dire qu’il y a une crise parce qu’il y a un Request Queueing, un temps d’attente qui grandit trop fort.

François: Alors là, vous arrivez en période de crise. Et qu’est ce qui se passe ? Vous avez déjà les recettes en tête à appliquer pour ce genre d’incident ?

Oui, l’idée de notre cellule de gestion de crise, finalement, c’est de remettre toutes les personnes qui peuvent être pertinentes au même endroit. Aujourd’hui, c’est plutôt un broadcast sur toutes nos équipes techniques et en fonction du message, en fonction des disponibilités des gens. Les gens arrivent sur cette cellule et on a un petit moment de “Qu’est ce qui se passe ?”, où la personne qui a lancé la crise explique ce qui se passe et après, on s’assure qu’on ait les bonnes personnes pour pouvoir investiguer, mitiger et fixer ce problème-là. Ce qui se passe à ce moment-là, c’est qu’on est quelques-uns, on doit être une dizaine de personnes à regarder. Et il y a vraiment cette partie de qualification pour savoir, ok, Est-ce qu’on comprend d’où ça vient ? Est-ce qu’on comprend ce qui s’est passé ? Pour avoir la meilleure réaction, la plus rapide. Pour pouvoir mitiger et fixer le problème ? Donc là les premières choses qu’on fait, c’est de regarder est-ce qu’il y a eu un déploiement du code un petit peu avant ou des modifications sur notre infrastructure ? Il s’avère que non. On essaie d’expliquer, puisque d’habitude, ça n’arrive pas comme ça. Nous, on a la chance d’avoir un trafic qui est relativement prédictible, même si on a des pics. Comme je disais par exemple, le lundi matin, après, c’est hyper prédictible entre 10h et midi, il va y avoir du trafic. Entre 14h et 16h aussi, et on a après des choses qui descendent, qui croît très linéairement. Donc là, on s’aperçoit qu’il n’y avait pas eu de modification et en essayant d’expliquer, on cherche ce qui se passe. Il est presque 13 heures et on se dit, est-ce qu’il s’est passé quelque chose à la télé ?

Benoit: Est-ce qu’il y a quelque chose qui aurait pu expliquer finalement cette charge le trafic? Donc là, quelque chose qui est très important aussi dans cette gestion de crise, c’est vraiment d’appeler les gens. On est de plus en plus de boîtes avec des outils comme Slack, des messageries instantanées. Là, on a besoin d’avoir une réponse rapide. Donc on a aussi un petit annuaire, comme pas mal de boîtes aussi, on appelle les différentes personnes. Et quelqu’un nous dit, “Ah ben oui, effectivement, on est passé au journal télé de M6. On a eu une petite apparition”. Ce qui est intéressant, c’est que ça, avant, il y a très longtemps, notre service de presse appelait les services informatiques pour leur dire attention, on passe au journal télé de 8 heures, de 13 heures, et ça risque d’impacter notre trafic. Parce qu’enfaite, à chaque fois qu’on annonce Doctolib à la télé. On a un trafic très, très fort. Les gens ont le réflexe d’ouvrir le navigateur et d’aller voir Doctolib. Et c’est ce qui nous permettait avant, de prévenir ce genre de choses, pour allouer plus de ressources à notre trafic patient. Puisque, pour la petite histoire ; Nous, on sépare différents types de serveurs, notamment ceux qui vont fournir tout le service pour le docteur et celui qui va fournir tout le service pour les patients. Donc en prévision de ce genre de choses ; D’habitude, on réserve plus de ressources pour servir le trafic patient.

François: D’ailleurs, en parlant de trafic, est ce qu’à ce moment-là, vous arrivez à évaluer l’impact en termes de nombre d’utilisateurs, de potentiels patients / utilisateurs qui se connectent à la plateforme et qui sont confrontés à des temps d’attente supérieur à la normale?

Benoit: C’était un peu plus dur à dire en termes vraiment de patients. C’est plus dur à dire. Ce qu’on a comme métriques très techniques, c’est que, auparavant, on avait 1300 requêtes par seconde et là, en moins d’une minute, on passe à 2.000 requêtes par seconde. Donc, 60% de trafic en plus. On peut à peu près se dire que c’est 60% de patients en plus qui arrivent sur notre plateforme en moins d’une minute.

François: Du coup, ces moments où vous avez cette prise de conscience que vous êtes passé au JT, quelle est la stratégie une fois que vous avez cette information là pour mitiger l’impact de ce pic ou pour rétablir un service à la normal?

Benoit: Très bonne question et très intéressant puisque le temps qu’on ait cette information et qu’on vérifie est-ce qu’on a fait des déploiement? Non. Est-ce qu’on a changé quelque chose sur l’infrastructure ? Non. Est-ce qu’on pas ça à la télé ? Oui. Le temps qu’on ait fait ça, on re-regarde le monitoring. En fait, tout commence à se calmer. Alors on avait toujours du trafic entrant. Par contre, le temps d’attente se réduit naturellement. Pourquoi ? Il se réduit naturellement ? Parce qu’on a en place ce qu’on appelle de l’auto-scaling. Donc, quand il y a plus de charge sur notre infrastructure, en fait, on alloue automatiquement plus de serveurs. Ce qui faite que les serveurs sont eux-mêmes moins chargés et donc tout va bien. Donc, on a cette solution technique d’auto-scaling qui marche et qui, au bout de quelques minutes, au but de 4 minutes. Ça finalement résout tout seul le problème. Donc, qu’est ce qu’on a fait pour corriger vraiment le problème ? En fait, on n’a rien à faire. On a laissé notre infrastructure, scaler, monter en charge toute seule.

Benoit: Ce qu’on fait après ça, c’est vraiment d’essayer de comprendre ce qui s’est passé et voir comment est-ce qu’on peut le prévenir, le mitiger par la suite.

Benoit: En interne, on a tout un processus de post-mortem. C’est aussi pour ça que tu as cette émission nommée de la même façon. Donc dans notre processus de post-mortem, on a vraiment cette root cause analysis, analyse des causes profondes, qu’on essaie de formater en forme de 5 Pourquoi, donc toujours se poser des Pourquoi successifs, pour être à peu près sûr d’arriver à la cause profonde de ce problème, donc en déroulant ça. Finalement, pourquoi est-ce qu’on a eu ce temps d’attente qui a augmenté? Parce que tous nos serveurs étaient occupés, pourquoi ils étaient occupés, parce qu’on avait plus de trafic. Pourquoi on a plus de trafic, parce qu’on est passé à la télé.

Benoit: Autre partie des questions, c’est pourquoi, finalement, est ce que ce problème de passage à la télé pose un problème?

Benoit: Une partie de la réponse est de se dire que nos équipes de presse ne nous ont pas alertés. On est allé les voir ; Pourquoi vous ne nous avez pas alerté ? Parce qu’en fait, depuis à peu près un an, il n’y a plus de problème quand on passe à la télé. Avant, c’était problématique. Depuis un an, on vous appelle, vous allez l’air de dire que ce n’est pas si grave. Et les fois où on a oublié, ce n’était pas grave. Du coup, ça fait plusieurs mois que l’on ne vous prévient plus puisque ça n’a aucun impact. Donc là, la question, c’est : Mais pourquoi celui-là ? Cette apparition-là a eu un problème ? La première chose que je me suis dit, c’est de se dire que peut-être qu’on a fait quelque chose de différent. Peut-être qu’on a donné un call to action différent, peut-être qu’il y avait une URL particulière qui aurait pu provoquer, expliquer cette différence. Donc, il s’avère que la campagne télé est tout à fait banale. D’ailleurs, pour info, c’était une campagne télé pour dire aux gens d’aller se soigner parce que c’est hyper important dans cette période de ne pas renoncer aux soins. Sur la première vague, il y a eu des problèmes, des gens qui sont restés dans des états plus grave ou qui ont des suivis plus compliqués après. Donc, c’est hyper important d’aller se soigner. C’est vraiment une campagne de “soignez-vous”. Avec Doctolib, qui était mentionné, mais vraiment quelques secondes.

Benoit: Aucun call to action, aucune URL particulière et donc finalement un trafic pas différent de d’habitude qui arrivait sur des tailles similaires à ce qu’on observe le lundi matin. Mais pour le coup, juste en une minute, un jeudi, je crois, ce qui n’est pas habituel.

Benoit: Pourquoi est-ce que ça a été différent cette fois ci? Ce n’est pas parce que l’apparition était différente. Pourquoi ça a été changé ?

Benoit: On a été chercher un peu plus loin et c’est finalement cette introduction de l’auto scaling qui est une très bonne chose, parce que ça nous permet d’optimiser un peu les ressources de notre infrastructure et de s’adapter beaucoup plus automatiquement à des pics de charge et à des évolutions de charges dans le temps. Donc, on l’a mis en place. Et enfaite, le problème, c’est que le lundi matin, pour le coup, on alloue en prévision quelques petits serveurs et la montée en charge, surtout, est beaucoup plus douce. Et tout n’arrive pas en une minute. Les médecins, ils se réveillent tôt, mais voilà, la charge se répartit entre 7 heures et 10 heures. On a une progression de la charge sur nos serveurs. Et là, au moins d’une minute. Finalement, on a ça.

François: Ok, donc, finalement, l’auto scaling était quand même une réponse que vous aviez déjà dans votre boîte à outils pour prévoir ces montées de charge, pour pouvoir ces montées de charge prévisionnelles puisqu’on a une utilisation cyclique ou du moins facilement identifiable et répétables de vos services, avec des pics en matinée, puis ensuite en milieu d’après-midi. Donc, on a un cas d’usage parfait pour l’évolution de charge automatique. Si on peut prévoir la charge, on peut vraiment allouer efficacement les ressources. Et là, vous êtes confronté finalement à un problème qui est un pic de charge dans une très courte durée. La charge en tant que tel n’est pas si différente que les pics de charge. Que la valeur de la charge que vous pouvez retrouver dans d’autres période de la journée. Cependant, là, ça arrive en un seul coup. Est-ce que ça entraîne des questionnements sur la façon d’adresser ces pics de charge ? Vous vous dites “Non, C’est un incident transient, enfin ça n’arrive qu’une fois. Et finalement, est-ce vraiment nécessaire d’adresser ce genre d’incident ? Ou est-ce qu’on peut accepter le risque que ça représente ?

Benoit: Ça, ça vient juste après. Donc, avant de répondre à cette question, je continue sur l’analyse. Finalement, c’est ce qui va entraîner la réponse à ta question. Donc, en moins d’une minute on a ce problème, pourquoi est-ce que notre auto-scaling aujourd’hui, n’est pas capable de gérer une montée en charge aussi rapide ? Donc là, on passe vraiment d’une partie technique, désolé. En fait, on a résolu le problème en moins de 3 minutes. En moins de 3 minutes, comme je le disais tout à l’heure, en ne faisant rien, ça à résolu le problème. Et on est capable de gérer la charge sur les serveurs.

François: Enfin, en faisant rien, en ayant déjà au préalable réfléchi à ce genre de problématiques de montée de charge, en ayant une infrastructure capable d’augmenter le nombre de ressources allouées lorsqu’un pic de charge arrive.

Benoit: C’est ça.

Benoit: On laisse faire ce qu’on avait déjà fait avant, mais sur le moment, effectivement, on regarde ce qu’on a fait avant marcher. En moins de 3 minutes, ça marche. Le problème, c’est que là, comme je le disais, la montée en charge, s’est faite en moins d’une minute.

Benoit: Donc, derrière tout ça, il y a pas mal de choses un peu technique, mais bon. Bref, on a notre application qui doit se monter sur des Pods Kubernetes. Ces Pods Kubernetes, ils doivent se mettre sur des serveurs, lancer un Pod Kubernetes, ça se fait en moins d’une minute, en 40 secondes, à peu près. Là, sur le coup, ce qui nous a posé problème, c’est vraiment d’avoir des serveurs disponibles sur notre hébergeur. Ça, ça met plus de temps. Le temps de les allouer et le temps de les configurer. Tout ça, c’est automatique. Mais tout ça mis bout à bout, ça met 3 minutes. C’est pour ça qu’on a 3 minutes de période où on a eu un problème.

Benoit: Et donc après la question, c’est exactement celle que tu poses.

Benoit: Finalement, est-ce qu’on est content avec ces 3 minutes ou pas? Ou est-ce qu’on doit faire quelque chose ? Donc 3 minutes, pour nous, ce n’est pas acceptable. C’est ce qu’on se dit, que 3 minutes, ça ne va pas. Et il faut aller vers moins.

Benoit: Donc il y a des choses qu’on peut faire assez rapidement là-dessus. Typiquement, essayer de n’avoir que la partie Pod Kubernetes à faire et pas la partie serveur. Ça, c’est quelque chose qu’on va essayer de mettre en place. Enfin qu’on va mettre en place de toute façon. Ça va nous permettre de réduire le temps, pas d’indisponibilité, mais de perturbation on va dire, de trois minutes à une minute.

Benoit: Après, on peut aussi aller plus loin et se dire finalement, on réduit encore en allouant encore en réserve beaucoup plus de ressources, mais finalement, ça devient un problème parce que si finalement on se réserve le maximum de ce qu’on connaît. A quoi sert notre auto-scaling ? Plus à grand-chose. Et donc on n’est plus aussi élastique que ce qu’on voudrait. Donc on a cette question qui n’est pas encore totalement résolue, mais c’est est-ce qu’on accepte un temps de perturbation de 40 secondes ou pas ? Donc ça on va le faire plus tard. Je ne peux pas te donner la réponse maintenant. Par contre, en termes de mitigation, ce qu’on a fait, c’est de se dire on revient sur le process avec notre service de presse pour se dire ; Quand vous savez qu’on a des apparitions télévision, prévenez-nous un peu avant comme ça, on est capable de le prévoir.

François: Donc, en résumé, les deux actions principales qui ressortent du bilan du post-mortem en termes de mitigation / prévention, on a d’une part, d’un point de vue technique, ce nouvel action item à la roadmap qui est mise en place, réduire le temps de réparation de 3 minutes à 40 secondes, temps de déploiement d’un pod. Et d’un point de vue organisationnel, il y a également rétablir la communication entre L’équipe presse pour signaler des passages dans les médias avec l’équipe tech pour, peut-être, prévoir des pics de charge. Est-ce qu’il y a d’autres éléments en plus de ces deux actions?

Benoit: Oui, oui, oui. Il y en a un que j’ai failli oublier, mais qui est hyper important, c’est qu’aujourd’hui, la façon dont on fait notre auto scaling, En fait, il est positionné à un niveau assez haut de charge sur nos serveurs.

Benoit: On a un certain pourcentage de charges sur nos serveurs et aujourd’hui, quand ça dépasse 60%, on va allouer d’autres serveurs. Et donc entre 60% et 100%, on n’a plus beaucoup de marge, donc on n’est pas capable de gérer beaucoup plus de trafic.

Benoit: Donc quand on a des changements de trafic tel qu’on a eu vendredi. Ça ce n’est pas suffisant. Donc, une idée très simple pour le coup, c’est juste d’ajuster ce petit paramètre et de descendre de 60% à 30%, ce qui fait que naturellement, en plus, ça revient sur l’action d’avant. Cela va nous allouer plus de ressources au début un petit peu et surtout, on va pouvoir faire un petit x2, x2.5 sans finalement changer grand chose.

Benoit: Et ce serveur-là, ces serveurs existants, vont pouvoir tenir la charge sur cette montée pendant un peu plus de temps.

François: Voilà, en se disant finalement que l’objectif, c’est que le processeur entre 30% d’utilisation et 100% utilisation, au moment où ça commence à saturer. Et là où la machine ne puisse plus servir de requêtes. On ait eu le temps de déployer des machines supplémentaires pour venir combler cette charge.

Benoit: Exactement. Il y a une chose qu’on a fait aussi.

Benoit: Qui est important de noter, c’est que c’était un problème très infrastructure finalement. Mais ça ne nous empêche pas de regarder ce qu’on a fait sur le code.

Benoit: Une question qu’on s’est posée, c’est finalement est ce qu’on aurait pas introduit un problème de performance sur notre homepage ou les quelques actions que les gens font quand ils voient Doctolib à la télé? Est-ce qu’on n’a pas introduit quelque chose là-dedans? Il y a toujours cette question à se poser de ; Finalement, est-ce que notre code à nous, notre code applicatif, finalement, est assez optimisé ou pas? Puisque s’il n’est pas assez optimisé, c’est peut-être un problème qu’on voit d’un point de vue infrastructure, mais finalement, la root cause serait plutôt applicative, même si ça n’a pas abouti.

Benoit: On a été chercher, enfin, ça n’a pas abouti, si. On a été chercher, s’il y avait des root causes dans notre code applicatif et il s’avère que non, du coup on était plutôt contents.

François: Donc, maintenant qu’on a fait le tour de cet incident, est-ce que tu pourrais nous parler un peu de la façon dont vous gérez les incidents en interne à Doctolib? Si vous avez des outils et des process en particulier pour faire face dans ces cas de gestion de crise.

Benoit: Oui, tout à fait. Alors nous, ce qu’on fait, c’est qu’à chaque fois qu’il y a une crise, on appuie sur un bouton rouge. C’est ce qu’on essaye de mettre en place. On a développé en interne une application, DoctoCrisis, séparée de notre infra parce que si on a un problème sur l’infra, il faut quand même qu’on puisse gérer des crises. Donc si c’est mutualisé, ça ne va pas.

Benoit: C’est une petite application complètement séparée et n’importe qui dans Doctolib peut appuyer sur ce bouton rouge. Pour dire, je commence une Crisis avec potentiellement un commentaire ou pas. Qu’est-ce qui se passe quand la personne appuie sur ce bouton ? Ça envoie des notifications via Slack et par SMS à toute une partie de notre équipe technique, notamment des personnes chargées de l’infrastructure et les développeurs. On a vraiment envie que les développeurs, finalement, s’impliquent dans notre run. On a vraiment cette philosophie DevOps de Buid & Run pour essayer de faire ça bien, à Doctolib. Donc les gens sont notifiés. Qu’est-ce qu’on fait ? On se réunit tous sur un meet [Google meet (ndlr)]. Avant, on avait une salle dédiée, mais en ce moment, le meet est beaucoup plus efficace. Donc, tout le monde est sur un meet et là, on a trois rôles principaux qui sont définis et qui doivent être attribués. Une première qui est attribuée de façon automatique c’est l’Incident Manager. Le deuxième, c’est le Scribe et le troisième, le Communication Manager, donc le scribe. Le plus simple, c’est quelqu’un qui finalement retranscrit tout ce que les gens disent dans notre application DoctoCrisis. Pour pouvoir revenir après, et notamment lors des post-mortem sur ce qui s’est passé et de pouvoir s’apercevoir que à partir du moment où on a trouvé la cause et le moment où on l’a résolu, il s’est passé tant de temps de façon très précise. Pouvoir aussi déceler des choses telle que, telle personne avait dit ça et 15 minutes après, on s’aperçoit que personne n’avait pris en compte comment on pourrait améliorer ce processus-là.

François: C’est une personne qui est détachée à temps complet. Par exemple, on avait un ingénieur développeur et qui était sur son sprint, ses features, là détachée à temps complet pour la durée de la crise pour rejoindre cette cellule de crise ?

Benoit: C’est ça et là. Comment ça se définit ? Un certain nombre de personnes se sont auto-désignées pour faire du scribe.

Benoit: N’importe qui peut le faire, il y a aucune technicité à le faire. Mais il y a des gens qui aiment bien le faire aussi, parce que c’est une façon d’apprendre hyper efficace lors des incidents. En fait, on voit pas mal de choses et tous les gens qui sont script, finalement, découvrent et comprennent beaucoup de choses sur notre application. Donc, il y a pas mal de gens qui aiment bien faire ça et qui se portent volontaires pour avoir ce rôle. Donc dès qu’ils ont ce petit SMS ou qui voien la notification sur Slack. Ils viennent dans l’application s’inscire et dire, moi, je suis scribe, et commencer à taper tout ce que les gens sont en train de dire sur le meet.

Benoit: Deuxième rôle, le Communication Manager. Il y a quelques personnes qui sont identifiées, et leur rôle, c’est de gérer toute la communication interne et externe.

Benoit: Interne à Doctolib et externe, à l’extérieur, dans le monde entier.

Benoit: Pourquoi ça? Parce que quand on a des crises qui sont un petit peu impactante, il y a un réflexe que tout le monde va avoir. C’est finalement de demander des nouvelles. Alors, on en est où ? Qu’est-ce que je dois dire à mon docteur qui est en train de m’appeler ? Qu’est-ce que je dois répondre sur les Slack là où les gens me posent des questions ? Est-ce que je mets quelque chose sur notre site web pour prévenir les gens ? En fait, tout ça fait autant d’interruptions pour notre cellule de crise. C’est pour ça qu’on a mis ce petit proxy, pour prendre des informations de la cellule de crise pour savoir ce qui s’est passé et pour pouvoir donner ces informations centralisées à tout le monde dans Doctolib et aussi à ce qu’on doit dire à l’extérieur. Quand on doit le dire à l’extérieur, on a aussi notre service de com qui regarde et aussi qui valide un peu ce qu’on est en train de dire. Pour être sûr que on n’envoie pas des choses fausses à l’extérieur. Le Communication Manager c’est vraiment notre rampart face aux interruptions qui viennent de l’extérieur. Et le dernier rôle qui est l’Incident Manager, celui-là il est primordial dans la cellule de crise. C’est la personne qui essaie de garder le calme et de s’assurer qu’on avance bien dans la bonne direction et que les bonnes actions sont prises et avancent.

Benoit: Alors pourquoi? Quand on est en crise tout le monde a plein d’idées, envie de faire plein de choses. Souvent, si on ne fait rien, on se retrouve avec des gens qui sont plusieurs sur la même action et une action qui est complètement délaissée. Typiquement, les grands types d’actions qu’on essaie de faire : comprendre, donc l’investigation, trouver une mitigation. Même si on n’a pas trouvé, comment on peut descendre le niveau de criticité de la crise ? Et trouver aussi un fix. Si on a que des gens qui sont sur le fix, typiquement, et qu’on n’a personne qui cherche à mitiger le problème, on est plutôt sur des solutions moyen / long terme et pas sur la solution court terme. C’est hyper important d’être sûr que on a une personne au bon endroit. Pareil sur les possibilités de mitigation, il y a souvent plusieurs options qui sont possibles. Si on a la chance d’avoir plusieurs personnes, c’est bien d’avoir plusieurs équipes finalement pour aller voir différentes pistes.

Benoit: Et essayer d’éviter ce qu’on appelle des sur-crises, donc en essayant de bien faire, en essayant de résoudre les choses. Il est possible que si on n’y réfléchisse pas un petit peu, on provoque des sur-incidents. Ça, c’est le pire qu’on puisse faire. C’est à dire on a un incident, peut-être qu’il était important, peut-être pas si important que ça, et dans la précipitation, il est possible qu’on fasse les choses encore pires. Donc ça ç’est vraiment ce qu’on cherche à éviter à tout prix et ça c’est en grande partie le rôle de l’Incident Manager pour essayer de calmer un peu les ardeurs. Et d’être sûr qu’on a pris le temps de réfléchir à ce qu’on faisait.

Benoit: Il faut qu’on aille vite, mais pas trop vite. Typiquement, ce qui peut se passer. C’est quelqu’un qui dit Je pense que c’est ça, vite je vais faire un fix, et je vais le pousser en production. Ben là, il y a toujours une phase de, être sûr qu’il y a quelqu’un qui est bien revu le code, qu’on ait pu reproduire ça, au moins sur des environnements de staging rapides et essayer de ne pas aller trop vite, et pas d’entraîner des sur-incidents.

François: Là, on a vu que la partie gestion de l’incident en live, lorsqu’il se déroule. Maintenant, est-ce que tu peux nous parler un peu de la façon dont vous gérez vos postmortems. Donc une fois que l’incident est clos ? Comment est-ce que vous vous organisez pour vraiment capitaliser sur ce qui s’est passé, pour éviter que ça se reproduise ?

Benoit: Oui, tout à fait. Donc, notre process qu’on appelle de post mortem à la fin de la crise, quelque chose que l’on fait aussi, c’est de prendre un maximum de notes pendant que les gens sont encore dans cette petite cellule de crise.

Benoit: On a eu plusieurs fois des choses, on s’est dit quand on écrit le post-mortem quelques jours après, on a un petit peu oublié ce qui s’est passé. Je suis sûr qu’on avait une bonne idée, mais on l’a oublié. Ça c’est dommage. A la fin de la crise, on essaie de réunir toutes les notes importantes, toutes les questions qu’on s’est posées et les petits problèmes.

Benoit: Après vient notre processus de post-mortem.

Benoit: A la fin de la crise, il y a un Post mortem Owner qui est désigné et qui est en charge d’écrire ce postmortem. Pas forcément, lui qui va tout écrire, mais qui va être en charge de le faire avancer.

Benoit: Il est désigné, il le fait. C’est quelque chose qui est hyper important, on a un SLA qu’on essaie de tenir, de se dire en moins de cinq jours on publie le document. Ce document-là, il est exactement structuré de la façon dont tu gère tes podcasts. Qu’est ce qui s’est passé ? Quel est l’impact utilisateur ? Comment on a détecté le problème ? Comment on l’a résolu immédiatement?

Benoit: Une description, un peu de ce qui s’est passé dans les détails. Après, ce qu’on a fait tout à l’heure, c’était la recherche des causes profondes. Notre “5 Pourquoi”. Une partie sur la gestion de crise elle-même. Qu’est-ce qui s’est bien passé ? Qu’est-ce qui s’est mal passé ? Et où est-ce qu’on a eu la chance. Je vais juste prendre des exemples pour illustrer. Une fois, on a eu la chance que dans cette crise-là, il y ait eu la bonne personne qui ait fait le commit. Qu’est ce qui s’est mal passé ? Typiquement, on a mis beaucoup trop de temps à se réunir et à se poser les bonnes questions. C’est le genre de choses que l’on essaie de faire, vraiment une réflexion sur la gestion de crise elle-même. Et à la fin de la dernière section qui est la plus importante finalement. C’est : Qu’est-ce que l’on fait pour éviter que le problème se reproduise ? On liste des actions qui sont dans notre Jira, notre gestion de tâches. Pour se dire et bien, pour prévenir il faut qu’on ait cette action, cette action. Et peut-être que dans ce qu’on a vu on a eu du mal à mitiger le problème. Donc dans le cas où un évènement similaire se reproduit on aura des actions de mitigations beaucoup plus rapide, beaucoup plus efficace.

François : Donc tu mentionnais un délai de 5 jours pour la publication des postmortems. De quelle façon est-ce que vous partagez ces post mortem au sein de Doctolib une fois qu’ils sont rédigés ?

Benoît : Alors aujourd’hui, tous ces postmortems sont sous formes de Google Docs. Et ces Google Docs sont dans un répertoire qui s’appelle Post Mortem, avec leur petit numéro. Donc on peut tous y accéder. En tout cas sur la publication, une fois que l’on est satisfait de notre document et qu’on est bien allé chercher les causes profondes du problème et qu’on a les bonnes actions, on publie ce postmortem, en interne, à toute l’équipe tech. Avant ça, on a aussi une étape de relecture, où on s’assure qu’il y ait au moins trois personnes, et souvent les gens liés de près ou de loin à la crise pour être sûr qu’on est allé au bout de ce postmortem et qu’on n’a pas fait ça juste pour le faire. On essaie vraiment d’avoir un regard critique sur ce qu’on écrit, sur l’analyse de nos causes profondes et sur les actions qu’on met en place.

François : Avant de conclure est-ce que tu aurais une ressource à conseiller à nos auditeurs pour la rédaction des postmortems ou la gestion de crise ?

Benoît : Alors j’en ai un, qui n’est pas spécialement relié au monde de la Tech, quoique, mais plutôt, justement à cette gestion de crise. J’aime beaucoup de podcast qui s’appelle Superfail, France Culture ou France Inter, je ne sais plus [Superfail est une émission de France Culture (ndlr)] mais qui parle justement d’échecs ou de problèmes qui sont arrivés. Et des fois justement, on a un aperçu de certains processus de gestion de crise dans certains secteurs et pas forcément tech d’ailleurs. Hyper intéressant.

François : Ça marche je mettrai la référence dans les notes de l’épisode. Encore une fois merci Benoît pour ton partage sur cet incident et votre fonctionnement interne pour la gestion des Post Mortem.

Benoît : Pas de problèmes, ça fait super plaisir d’être là.

François : Et je vous donne rendez-vous dans deux semaines pour un prochain épisode de Post Mortem.

Notes de l'épisode

Benoit Lafontaine, Engineering Director chez Doctolib, nous partage le post mortem d’un incident récent dû à une évolution soudaine de la charge sur la partie patient de leur service.

Malgré une architecture d’auto-scaling déjà en place, le service a été dégradé quelques minutes. Benoît revient également sur la façon dont la gestion d’incident est gérée chez Doctolib.

Ressources

Extrait audio d’un JT de M6, 19–45, disponible sur le kit presse du site doctolib.fr

Superfail, une émission de France Culture

Newsletter tech de Doctolib