Ce qu'un crash complet de notre production nous a appris

Verbatim

_ Bonjour à toutes et à tous. Je suis Jean-François. Je vais vous parler aujourd'hui de votre pire cauchemar, que j'ai vécu il y a deux ans. Vous êtes venus soit pour savoir jusqu'à quel point on peut souffrir en production... Je voudrais vous dire ce que nous en avons tiré, ce que ça nous a appris et comment on travaille aujourd'hui. Première chose : voici Les images qui seront utilisées dans les slides. Merci à tous les gens qui font de l'opensource. Ça permet d'avoir de jolis slides. C'est important. Je suis Jean-François. Vous me connaissez peut-être sur Twitter. J'ai fait beaucoup de projets sur la qualité logicielle. Je suis passionné par tout ce qui a trait à l'industrialisation, automatisant des tâches. Je travaille chez AlumnForce. AlumnForce est une boîte qui fait un réseau social pour les étudiants. Peut-être que la moitié de la salle l'utilisation de le connaître. Cela a été fondé il y a 15 ans. C'est là que ça devient important. Il y a 15 ans, on ne faisait pas du Web comme on le fait aujourd'hui. On s'autorisait à se connecter sur les serveurs et à modifier des trucs. On s'autorisait aussi à ne pas avoir de dépendance. Ça n'existait pas. Comme on travaille dans une entreprise qui a 15 ans de code PHP, ce n'est pas pareil que quand on démarre aujourd'hui un projet Symfony ou Laravel. On dit souvent qu'une boîte qui a du Legacy, c'est une boîte qui a réussi. On a vraiment bien réussi ! On arrive à merger du code très moderne. Ça explique un peu les contraintes.

En 2020, la situation, c'est ça. On a de grosses machines, d'à peu près 128 gigas de RAM, qui sont des superviseurs. On sait qu'il y a des problèmes. On voit qu'il y a du stress, des pics. On s'attend au pire. On se dit qu'il est temps de faire quelque chose. On a un infogéreur externe avec qui on travaille depuis 10 ans. Et quand on a des demandes d'évolution sur l'infrastructure, c'est à lui qu'on s'adresse. En 2020, on s'est dit qu'il était temps. Sauf qu'en 2020, en janvier, il y a quelqu'un qui a appuyé sur le mauvais bouton. On a tous passé une mauvaise journée. On s'est levés le matin, la prod était rouge. On regarde nos boîtes mail et notre hébergeur nous dit : "Pas de panique votre serveur est mort mais ne vous inquiétez pas, on l'a changé." On avait deux clusters. Ils étaient tous morts. Ça a été une journée extrêmement compliquée. On a du PHP, du MQRabbit, des serveurs DNS, on a tout perdu. La mauvaise nouvelle, c'est que le soir même, à 22h30, je reçois un coup de fil de notre infogéreur. Il me dit que tous les snapshots ne marchent pas, qu'on est en incapacité de remonter la production. On n'a pas les conf. On avait quand même un deuxième serveur, mais il n'était pas ISO. Il y a des gens qui venaient bidouiller des choses. On avait perdu de la config sur des projets bien Legacy, des projets non versionnés parce qu'on rapatriait et des clusters. On s'est demandé quoi faire, si on remonte au patron qu'il faut fermer la boîte, si on essaye de faire quelque chose. On a choisi d'essayer de faire quelque chose. Vous vous doutez qu'on a réussi. On était en situation de stress.

Je ne vais pas parler de la journée et des trois semaines qui ont suivi et des 6 mois qui ont suivi. Je vais vous parler de ce que l'on a fait pour que ça ne se reproduise plus jamais. On devient extrémiste sur certains sujets. On va parler de documentation, de confiance, de résilience. On avait de la documentation. Merci aux gens qui étaient là avant nous. On a regardé la documentation sur la partie recouvrement. Jusqu'à quel point nous a-t-elle été utile ? La documentation ne sert à rien ! Il y a un message qui est important. Ce qu'on pressentait, ce que je connaissais, mais qu'on n'avait pas trop en termes de culture dans l'entreprise, c'est qu'avant de documenter, automatisez ! On avait 50 pages de documents Word sur comment installer des serveurs. Faites un script SH, c'est plus facile. Il faut juste le faire. Il n'y a pas d'excuses pour ne pas automatiser. Ça ne prend pas plus de temps. Il y a plein d'outils. Vous faites ça avec ce que vous voulez. Mais par pitié, automatisez. Il est interdit de faire quelque chose qui n'est pas automatisé. Une fois qu'on a fait ça, on arrive au recouvrement quotidien. C'est quelque chose de primordial. Quand vous avez des crash ou que vous préparez des plans de recouvrement, vous faites des documents qui disent qu'en cas de panne, il faut relancer le serveur. Mettez-vous en condition d'être en plan de recouvrement tous les jours. Toutes les nuits, on recouvre nos serveurs. On détruit tout, on reconstruit nos préprods. Comme ça, je sais que ça marche. C'est vraiment un aspect primordial. Faites-le très rapidement. Ça nécessite de l'investissement. Dès que vous avez un nouveau service, prenez l'habitude de le faire toutes les nuits. Une fois qu'on a faite tout ça, vous avez le droit d'avoir de la documentation. Cette documentation, on a appris qu'elle doit être la plus idiote possible. Il faut être très bête dans la documentation. En cas d'incident, il y a du stress, de la précipitation. Il faut définir précisément qui peut intervenir. On a des fiches de procédures, des sujets d'anomalie de code source, ce qu'on doit taper. Il ne faut pas avoir d'a priori.

Il ne faut pas se dire que la personne sait se connecter sur un serveur, etc. Il faut partir du principe que vous travaillez avec des escargots qui viennent de découvrir votre projet et qu'ils doivent intervenir dessus. Si vous êtes gentils, vous pouvez donner des explications du pourquoi, mais s'il y a une panne, on ne sait pas forcément. Automatisez, recouvrez de manière quotidienne et faites de la doc idiote. On avait des erreurs fondamentales sur la résilience que tout le monde fait. On a confondu résilience et redondance. Ce n'est pas parce que vous avez 5 serveurs dans un cluster que ça marche. On a eu une panne limitée avant-hier. On avait 3 nœuds. On s'est aperçu qu'avec une mauvaise configuration, une erreur sur un nœud engendrait une cascade sur 3 nœuds. La résilience, c'est de prendre vos 3 serveurs et d'en détruire 2, de crasher. Si vous résistez, vous pouvez être à peu près sereins sur le fait que ça marche. Si vous ne le faites pas, c'est comme si vous aviez qu'une seule machine. Ça nous a appris aussi quelque chose de fondamental : isoler les dégâts. On avait deux gros serveurs. Maintenant, nous en avons 180 ou 200. Tout est isolé. On a fait une isolation en grappes. En cas de panne, on a qu'une partie de nos clients qui sont impactés. Et des silos totalement différents. L'idée, ce sont des choses isolées. On a des silos sur plusieurs data centers, des silos en France, en Suisse... L'idée d'un silo, c'est de se dire qu'en cas de perte totale de cloud provider, le reste continue. Ce sont des changements de paradigme très compliqué. On a commencé il y a deux ans. On est encore dedans. On a réussi la partie grappes. On est à la quatrième partie silos depuis ce matin. Ce n'est pas facile, mais c'est fondamental. Il faut accepter les palais, mais limiter leur portée. On a un exemple de code source. Si ça ne marche plus, il faut offrir un service dégradé. Il faut informer le produit qu'il aura un service dégradé potentiel. L'idée, c'est de ne pas en une grosse page blanche. Les utilisateurs préfèrent qu'on leur explique qu'il y a un petit problème, mais qu'ils peuvent continuer à utiliser les sites. Deuxième erreur, nous l'avons tous fait : c'est d'être fiers d'avoir un uptime de 100 %. Ça ne sert à rien du tout d'avoir un uptime de 100 %. Si vous arrivez au 0,0001 % des cas où ça ne marche pas, si vous êtes en incapacité de reconstruire votre prod, vous n'êtes pas bien. Si vous avez des problèmes qui ne peuvent survenir qu'une fois sur 1 million, si vous avez un peu de trafic, une fois sur 1 million, ça arrive souvent. Ne soyez pas fiers de votre taille, mais soyez fiers de votre time et de votre capacité à le recouvrir si vous avez un problème. Il y a quelque chose que l'on a appris aussi, c'est qu'il n'y a pas d'évidences quand il s'agit de communiquer. Il y a des gens qui ont déjà vécu des situations de crise en production, dans la salle ? Beaucoup de monde ! Dans une crise, tout le monde est stressé. C'est vraiment flagrant. Il faut essayer d'introduire de la bienveillance entre autres et aussi certains automatismes.

La première chose qui n'est pas facile, c'est la transparence. Vous vous rappelez peut-être de l'épisode du crash de Gitlab en 2017. Il y a quelqu'un de chez Gitlab qui a effacé la prod. Il s'est passé quelque chose de miraculeux. Ils ont ouvert un Google doc, ils ont fait un live Twitter et ils ont été totalement transparents sur ce qu'ils faisaient. Il y avait une caméra sur une partie de l'équipe. On les voyait réfléchir. Ils ont réussi à transformer un incident énorme en quelque chose où je me suis dit qu'ils sont forts, chez Gitlab. Ils ont réussi à transformer une panne en quelque chose de positif. On a un mantra qu'on répète tous les jours : en cas de problème, il faut avertir, contrôler, corriger. On a tout cet écueil de se dire qu'on va y arriver et que personne ne va le voir. On avertit car il peut y avoir besoin d'informations auprès des clients. Il ne faut pas masquer les choses sous le tapis, mais il faut être transparent. C'est primordial. Quand on est transparent, on gagne quelque chose qui est énorme : de la confiance. En cas d'incident, on a besoin de confiance. Sur la partie communication, il faut anticiper. Il ne faut pas donner la place un l'improvisation. Aujourd'hui, on a un plan de qualité. On a deux liens : incident de production infrastructure et incident de production ressource. On fait en sorte que tout soit ciblé. Il faut s'organiser au sein d'une équipe pour que dès qu'il y a un incident, on décide un rapporteur, qu'il crée un document, qu'il échange avec les équipes et qu'il corrige, valide et fait en sorte, après, que l'incident ne puisse plus jamais survenir. C'est très important. On a une personne qui est désignée pour ajouter des tests, pour que l'incident ne puisse plus se reproduire. Si la personne est en charge d'une résolution pour que l'incident ne puisse plus se reproduire, on a un bandeau rouge qui dit que cette personne se consacre exclusivement à faire en sorte que l'incident ne puisse plus jamais survenir. Petit à petit, on se donne une culture de faire en sorte que les incidents sont uniques. Sur la communication, dernier levier, c'est quelque chose qu'on a mis en place, qui a été utilisée une fois : il faut donner des moyens pour avoir des leviers d'alerte. Souvent, dans le stress, quelqu'un dit avec sa petite voix : "Moi, non !" On n'écoute pas forcément. Peut-être que des gens l'ont déjà vécu.

Chez nous, on a mis en place un émoji, l'émoji KO. Un Zapier va envoyer plein de choses. C'est marqué : "Vous n'avez pas le droit de faire autre chose que de traiter ce sujet". Il faut offrir un levier ultime pour qu'on s'arrête avant de foncer dans le mur. Le sujet que j'ai appris et qui est extrêmement pénible pour mes collègues, c'est d'avoir confiance en rien. Je ne vais pas avoir confiance en votre hébergeur, vous ne devez pas avoir confiance dans votre code, dans la résilience. En rien. Je suis comme Saint-Thomas, je ne crois que ce que je vois. Si on perd notre adresse IP, un autre serveur va prendre le relais. On va le tester toutes les nuits. Je vais voir ce que tu me dis, qu'il est possible de faire en termes de production. C'est pénible pour les collègues, mais quand on ne le fait pas, on le paye. Un corollaire, c'est comme ça n'existe pas. Vous qui payez peut-être un hébergeur, un infogéreur pour gérer vos backups n'existent pas. Ils n'existent que s'ils remontent. Sur chacun des silos, on rejoue un backup de production et un backup de préproduction. Ça ne suffit pas. On a au moins ce niveau d'assurance qu'on est en capacité de remonter des backups. Les backups n'existent pas s'ils ne sont pas redondés. On est peut-être devenu un peu extrémiste là-dessus, mais nos backups sont au moins sur trois data center et deux cloud providers différents. C'est très important. Sur la confiance, il y a aussi quelque chose que l'on a appris. On fait beaucoup sur l'infra. On n'a plus le droit de faire la moindre action sur un serveur si on n'est pas à deux. C'est interdit. Si vous le faites, on vous tape sur les doigts.

Dans un monde idéal, j'espère que d'ici un an, on y arrivera, plus personne n'aura accès à la production. Ça me paraît totalement légitime. Il ne faut pas hésiter. On croit que ça coûte cher, mais ça coûte moins cher que quelqu'un qui est fatigué, qui se trompe. Dans ce que l'on a appris, c'est de réviser notre jugement sur ce qui est fini. Les "finis", c'est monitoré. En cas d'anomalie, c'est non reproductible et c'est documenté. C'est primordial, d'avoir ça. Ça a eu un impact sur la gestion de projet qui est non négligeable. Dans les JIRA, à chaque fois qu'on a une anomalie, on crée un deuxième ticket de nos reproductions d'anomalie. Ça a un enjeu important pour toute l'entreprise. Tout le monde doit être d'accord. Il faut quelqu'un qui supervise ça pour dire qu'une anomalie ne peut plus se reproduire. Là, c'est fini. On n'y arrive pas toujours, mais globalement, aujourd'hui, on est à 80 %. On a toujours 20 % qu'on n'arrive pas à faire en sorte de ne pas reproduire, mais on fait de notre mieux. Il faut se mettre en situation de revivre l'incident tous les jours. Dès que vous mettez une nouvelle brique métier, d'infrastructure, que vous faites un nouveau projet, mettez-le en situation d'échec, faites en sorte que rien ne marche, activez un pare-feu au hasard, crashez le système D. Ça paraît idiot, mais s'il y a un truc à retenir de la conférence, c'est ça, de jouer le plan de recouvrement tous les jours. Si j'ai à peu près confiance dans mon infra, c'est parce que je n'ai confiance en rien. Dernier point que l'on a appris, ou plutôt si on devait résumer un peu tout ça, c'est d'arrêter d'être fiers de votre uptime. Ça ne veut rien dire. Ça fait partie des vanity metrics sur tout ce que vous voulez. Un uptime de 99,999 %, ça ne sert à rien. Je me souviens de Pascal qui nous avait fait une conférence sur le sujet. C'est primordial, mais il y a les 0,0001 %.

Pour l'avoir vécu, je peux vous dire que ça met en péril une entreprise. On est 25 dans l'entreprise. Les enjeux sont très forts. C'est de votre responsabilité à tous en tant que développeurs ou en tant que techniques, de penser à ça. Pensez-y au maximum. Le message qui est important, je rabâche, mais c'est la confiance. N'ayez confiance en rien. C'est quelque chose qui a été très difficile. J'ai tendance à faire confiance, à me dire qu'on m'a dit quelque chose et que c'est vrai. Là où c'est difficile, c'est qu'il faut apprendre que ne pas faire confiance, ce n'est pas ne pas aimer la personne. Ne pas faire confiance, ce n'est pas remettre en cause le travail de la personne. Il y a une culture d'entreprise qui est difficile, de dire que ce n'est pas toi que je blâme, si je vérifie ton travail. C'est exactement comme des tests automatisés sur du code source. Attestent automatiser, c'est une recherche de défauts. On n'est pas censés se sentir vexé si dans une relecture de code, il manque un test. C'est la même chose à tous les niveaux de l'entreprise. Quelque chose que l'on a appris, on est très balbutiants là-dessus, aujourd'hui, on inclut le monitoring dans notre spécification technique. Quand on a un ticket, on a un template. Il y a les alertes Prometheus pour voir que la feature est opérationnel. Le service qui est livré l'est avec des sondes. On a beaucoup investi sur Prometheus. On a à peu près 2 500 sondes sur notre production, aujourd'hui. Comme on a une la règle qui dit que livrer, c'est monitorer, petit à petit, on rajoute une sonde. On a des sondes d'infrastructure et des sondes de métier. Prometheus, ça permet de rapatrier des informations depuis les serveurs et de les afficher dans des jolis graphes. On a fait le choix d'avoir des alertes métiers et techniques dans ce service. D'autres ne le font pas. Je ne suis pas sûr que ce soient pratiquement les alertes métiers, mais au final, on fait et ça marche bien. Une alerte métier, on est agrégateurs d'offres d'emplois, et on a des alertes pour dire que c'est bizarre, qu'on n'a pas eu beaucoup d'offres d'emplois récemment. On traite le sujet avant que ça devienne grave. Un point que j'ai évoqué, c'est la notion de rapporteur. Le rapporteur est primordial en cas d'incident. Chez nous, ce n'est pas encore très fluide. On a tendance à croire que les rapporteurs vont se manifester spontanément. Ce n'est pas vrai. On a eu un incident il y a deux jours, qui était très gênant. On n'avait pas de rapporteur. Quand il n'y en a pas, on a eu tous les écueils classiques. On a 25 % de l'entreprise qui intervient sur Slack. C'est coûteux, c'est désagréable. Dès qu'il n'y a pas de rapporteur, ça ne marche pas. La solution est de se dire que celui qui voit l'incident en premier désigne un rapporteur. C'est important, la notion de "laisse-moi bosser".

Chose très importante et qui est dure à accepter en situation de crise, c'est que tout le monde fait de son mieux. Ce n'est pas parce que vous ne voyez pas votre collègue travailler qu'il n'est pas lui aussi impacté et qu'il n'essaye pas de faire de son mieux pour résoudre l'incident. La personne qui est au support, au téléphone avec les clients, qui vous harcèle sur Slack pour savoir où ça en est, elle aussi vous énerve mais elle essaye de faire de son mieux parce qu'elle résout une crise auprès des clients. Il faut être bienveillant dans la crise. Il faut arrêter d'être tout de suite véhément et croire que les gens ne font pas de leur mieux. C'est primordial, la bienveillance en entreprise. Demandez-vous toujours pourquoi la personne vous pose la question. Et pour conclure, les gros problèmes ou les petits problèmes font partie de la vie de l'entreprise. Il est inévitable sur une durée de vie d'une entreprise de 15 ans que vous ayez un méga problème. Il ne faut pas avoir honte. Tout le monde a des méga problèmes. Mais avoir un méga problème et n'avoir rien fait pour être prêt à y faire face, c'est honteux. C'est honteux de se dire que j'ai du temps de travail disponible, mais je n'ai rien fait pour préparer le jour où j'aurai ce problème. Vous ne pouvez pas préparer tous les cas, mais vous devez avoir un plan pour savoir comment s'organiser. La seule manière d'être prêt, c'est de faire des choses désagréables, c'est écrire de la doc. C'est primordial. Ce sont des choses que personne n'aime faire. À moins que quelqu'un aime faire un plan de recouvrement ? Non ? À vous d'être prêts. Il faut vous tenir sur vos gardes. Merci à vous. J'espère avoir réussi à vous transmettre quelques informations de ce que l'on a appris suite à cette journée catastrophique, en 2020. N'hésitez pas à voter pour faire du feedback sur ce QR code. Je vous remercie.

_ On a 7 minutes pour les questions. Allez-y.

_ Bonjour. Merci pour la conférence. Bravo de vous être relevés face à cet incident majeur. J'avais une question sur la partie monitoring. J'imagine que c'est comme tout le reste. Je voulais savoir si vous avez fait face à des niveaux d'alerting et comment vous avez géré.

_ On a trois Slack avec trois niveaux d'alerte. On est encore en train de l'ajuster tout simplement parce qu'on est en train de mettre en place de l'astreinte. À chaque fois qu'on a un critical qui est polluant, on l'élimine. On a réussi à éliminer le plus gros. Là où on ne sait pas encore déterminer, c'est jusqu'à quel point on doit considérer que l'on a une alerte. Est-ce qu'un cluster jaune, ça doit nécessiter une intervention ou une alerte ? On n'a pas encore réussi à décider ça. Si on prend un cas que j'ai eu ce matin, on a eu une alerte qui n'est pas gênante. Un de nos serveurs est tombé. On a l'alerte parce qu'il est mort, mais le client s'en moque. Avant qu'il soit impacté, les autres doivent tomber. On n'a pas encore réussi à trouver.

_ Merci, Jean-François.

_ Quel a été l'impact sur le produit sur tout ce que vous avez mis en place ? Est-ce qu'il y a eu autre chose ? Est-ce que vous êtes dans la boucle aussi de conception par rapport aux impacts et ce que vous avez mis en place ?

_ On essaye. Ce n'est pas évident. L'impact est plus sur la planification et sur la manière dont on gère notre process en interne. L'impact est vraiment énorme. L'impact produit que l'on a eu, c'est surtout d'essayer de limiter les spofs. On a commencé à concevoir des produits différemment mais pilotés par la technique. On a sorti des composants techniques. Aujourd'hui, on a l'e-mailing qui est isolé, on a des briques commerces. Ce sont des choses qu'on a sorties comme des micros services. Il y a eu un impact quand on se rend compte qu'en faisant ça, ça ouvre des portes pour le produit. C'est plus la technique qui dit que maintenant qu'on a ça, vous pouvez imaginer ceci pour le produit. C'est plus dans ce sens qu'on a eu un impact.

_ J'ai une question. Est-ce que le KO Engineering, vous y pensez ?

_ On est sur un hébergeur qui a beaucoup de problèmes. On n'a pas besoin de faire nos propres tests. Mais on commence à le faire. On n'est pas dans des stratégies vraiment organisées. On ne vise pas d'outils pour ça. On est plus à couper un service. On a des sessions où on fait ça mensuellement. On n'est pas assez matures pour entrer dans un outillage aussi loin.

_ Y a-t-il d'autres questions ?

_ Merci. Par rapport au process mis en place, qu'elle a été le temps qu'il a fallu pour que tout le monde intègre tout et que ça devienne des automatismes ?

_ Ça fait deux ans qu'on a eu cet incidents. Ça fait 4 ans que j'ai commencé à mettre en place des protocoles. C'est de longue haleine. Si on prend la documentation, c'est des objectifs d'équipe qu'on a. Ce sont des choses qui avancent petit à petit. On a des outils d'arriver à X % qui se construisent. Ça prend des années pour que ça devienne des réflexes. Faire des tickets, c'est devenu des automatismes. Les gens au support en avaient marre d'avoir toujours les mêmes pannes. Je pense qu'il faudra encore deux ou trois ans pour que ça devienne une culture qui fasse partie de l'ADN de l'entreprise.

_ Merci, Jean-François.

Description

Informations complémentaires

Vidéo

Le speaker

Jean-François LÉPINE

Tweets

Commentaires

Verbatim