VIRÉ son premier jour de travail



Cette suite d'événements s'est passée plusieurs fois dans plusieurs entreprises. Elle commence exactement pareil mais finit complètement différemment.

Viré son premier jour de travail

C'est l'histoire d'un développeur junior, qu'on va appeler Fredo.

Fredo vient de finir ses études. Il a déjà fait des stages dans plusieurs entreprises, mais là, il vient de décrocher son premier vrai travail. Il a super hâte de commencer ! En plus, l'entreprise dans laquelle il commence sa carrière a une bonne réputation, une bonne taille et une quarantaine de développeurs.

Notre jeune Fredo commence sa première journée. On l'accueille, lui fait visiter les locaux, lui présente ses nouveaux collègues... Tout se passe très bien pour un premier jour : il peut déjà commencer à travailler.

Pour pouvoir travailler, il doit d'abord configurer son ordinateur. On lui fournit une documentation et il suit les instructions qui y sont inscrites. Il installe l'application de la compagnie qu'il va devoir améliorer, crée sa propre base de donnée, roule une série de tests pour s'assurer que tout fonctionne correctement, etc...

Rapidement, il configure tout et commence à programmer.

Mais, autour de lui, quelque chose est en train de se passer : des gens s'appelent, se mettent à hausser la voix, s'agitent. Fredo finit par comprendre que la situation est grave : l'application ne fonctionne plus et l'entreprise perd de l'argent.

Tous les développeurs seniors essaient de comprendre le problème. Finalement, un des développeurs trouve et va voir le DSI (le Directeur des Systèmes d'Information) pour lui expliquer. Quelques minutes plus tard, Fredo voit le DSI s'approcher de lui et lui dire :

— T'as tout niqué dans la base de données de production. Tu prends tes affaires, tu dégages. Je veux plus jamais te revoir !

Frédo est interloqué : qu'a-t-il fait ? En fait, il se trouve que lorsqu'il a roulé les tests sur sa machine, il s'est trompé. Au lieu de copier/coller les informations de connexion à la base de donnée de sa machine, il a copié/collé celles de la base de donnée de production. Pour un premier jour, c'est vraiment pas terrible comme erreur...

Il essaie donc de se rattraper comme il peut. Il demande ce qu'il peut faire pour aider, pour se racheter. Mais non, c'est mort. Le DSI ne veut plus entendre parler de lui et lui dit qu'il va aller voir le département légal suite à l'impact que vient d'avoir ce gros problème sur la compagnie et ses revenus.

Abattu, le pauvre Fredo prend ses affaires, prend son laptop et rentre chez lui.

La source originale de l'histoire.

Des histoires similaires avec des fins différentes

Cette situation est arrivée dans plein, plein, plein d'entreprises différentes, et peut-être dans celle où vous travaillez en ce moment. En particulier, elle est arrivée dans de très grosses compagnies comme Amazon, DigitalOcean ou Gitlab.

Si on sait que cette situation est arrivée dans ces entreprises, c'est parce qu'elles ont publié des post-mortem publics où elles détaillent ce qu'il s'est passé, pour quelles raisons, et quelles sont les mesures qu'elles ont mis en place pour ne pas que ça se reproduise.

La très grosse différence entre ces compagnies, qui sont des leaders du cloud, et la compagnie de Fredo, c'est que ces compagnies partent du principe que leurs employés sont de bonne foi. S'ils font des erreurs, ils ne font pas fait exprès. Quelque chose n'était pas clair ou on leur a laissé faire quelque chose qu'ils n'étaient pas censés faire.

Ainsi, au lieu de vouloir fixer l'erreur humaine, ce qui paraît difficile, ces entreprises-là préfèrent régler le problème à travers les outils et les processus, pour minimiser les chances que le problème se reproduise.

Le cas de Gitlab

Dans le cas de gitlab, ils ont fait un livestream sur YouTube dans lequel des employés de Gitlab essayaient de trouver le problème et de le réparer. Les gens pouvaient regarder le livestream, commenter au fur et à mesure et les aider à trouver une solution. D'ailleurs, ils ont reçu de l'aide d'employés de PostgreSQL avec leurs bases de données.

Une fois l'incident résolu, ils ont pris certaines mesures :

• Ils ont optimisé leurs bases de données pour qu'elles puissent prendre plus de charge.
• Ils ont mis en place des outils de mitigation de spam parce que certains utilisateurs faisaient beaucoup plus de requêtes que ce qu'ils étaient censés faire.
• Ils ont mis en place un meilleur environnement de test pour tester les changements qu'ils font à la base de données plus facilement, et ne pas avoir à prier pour que ces changements fonctionnent une fois en production.
• Ils ont aussi amélioré le monitoring, la surveillance, pour s'assurer qu'on puisse attraper ces problèmes avant qu'ils deviennent trop graves.

Le post-mortem de Gitlab et leur livestream YouTube.

Le cas d'Amazon

Quand leur problème s'est produit en 2012, une des mesures qu'Amazon a prise a été de restreindre l'accès aux identifiants de connexion à la base de données. Par défaut, un petit groupe d'employés avait accès à ces identifiants. Ils ont fait en sorte que plus personne n'y ait accès, mais qu'ils puissent en faire la demande si besoin, réduisant les chances de les utiliser par erreur.

Ils ont aussi ajouté des processus de validation dans leur pipeline pour que des changements sur ce type de base de données soient vérifiés par une autre personne, pour encore une fois minimiser les chances d'erreur.

Ils ont aussi fait des modifications dans l'application pour la rendre moins dépendante de la base de donnée, pour que, dans le cas où cette base de donnée soit de nouveau indisponible, les parties de l'application qui n'en dépendent pas continuent de fonctionner, et minimiser l'impact de cette base de donnée sur leurs services.

Le post-mortem d'Amazon.

Le cas de DigitalOcean

Dans le cas de DigitalOcean, une de leurs mesures a été d'améliorer le réseau entre leurs serveurs de sauvegarde et leurs serveurs d'application pour pouvoir remettre en place les sauvegardes beaucoup plus rapidement. Ils leur avaient fallu 6h pour restaurer les sauvegardes parce que le réseau vers leur serveur de backup était saturé.

Ils ont aussi mis en place une meilleure procédure de test des backups pour s'assurer que lorsqu'ils font une sauvegarde, chaque sauvegarde est fonctionnelle.

Le post-mortem de DigitalOcean.

Ce que l'entreprise de Fredo a fait

Les cas de Gitlab, Amazon et DigitalOcean montrent que plein de mesures peuvent être prises, au niveau des outils ou des processus, pour mitiger ce genre de problèmes. Mais dans le cas de notre pauvre petit Frédo, qu'a-t-il dû se passer suite au problème ?

Le DSI, étant responsable de l'infrastructure, a évidemment dû rendre des comptes à sa hiérarchie. Quand on lui a demandé pourquoi le problème est arrivé, il a sûrement dû dire « c'est la faute du nouveau qui a foutu la merde », et quand on lui a demandé ce qu'il a fait pour ne plus que ça se reproduise, il a sûrement répondu « Je l'ai viré ».

Ce comportement est mauvais parce qu'il a pour seule conséquence d'instaurer une culture du blâme dans l'entreprise. C'est contre-productif. Maintenant, lorsque les gens feront une erreur, ils auront peur de l'avouer, auront tendance à la cacher, et il sera encore plus difficile de détecter les problèmes et de comprendre leur origine.

Ce que l'entreprise de Fredo aurait dû faire

Dans ce cas-ci, voici les questions qu'aurait pu se poser le DSI.

Premièrement, pourquoi les identifiants de connexion à la base de données de production sont disponibles à tous les employés et aux employés dont c'est le premier jour ? A priori, ils ne devraient pas avoir cette information. Seul un petit nombre d'individus devraient l'avoir, voire personne si possible.

Deuxièmement, pourquoi est-ce que ces informations de production se retrouvent dans une documentation pour installer une machine de développement ? Cette information n'a rien à faire là, et si elle n'y était pas, le problème n'aurait pas eu lieu.

Troisièmement, pourquoi y a-t-il une étape manuelle dans la mise en place de la machine du développeur ? Cette étape pourrait être automatisée (avec Docker par exemple) pour qu'une seule commande suffise à mettre en place tout l'environnement de développement. Plus besoin de copier-coller des informations. Le problème serait réglé.

Enfin, l'entreprise a eu beaucoup de mal à restaurer les données, ce qui a provoqué la panique ce jour-là. Ils pourraient donc se demander comment faire pour avoir des backups plus rapidement restaurables. Si un autre type de problème survient, ils pourront revenir à un état normal beaucoup plus rapidement et avec beaucoup moins de panique.

Ce qu'il faut retenir

Ce qu'on peut retenir de cette histoire, c'est qu'une culture sans blâme dans une entreprise est un des piliers de la culture devops, parce que c'est ce qui permet de comprendre les erreurs et d'améliorer le système.

La prochaine fois que quelqu'un fait une erreur ou que vous voyez du code qui ne vous plaît pas, ne jetez pas la faute au responsable. Plutôt, respirez et réfléchissez à ce qui a fait que cet incident ait eu lieu et quels sont les outils ou procédures à mettre en place pour ne plus qu'il se reproduise.



Voilà ! C'est tout pour aujourd'hui. Si vous découvrez la chaîne, je m'appelle Thomas, je travaille en tant que devops dans une grosse compagnie de jeux vidéos à Montréal, au Canada, et je fais des vidéos toutes les semaines sur des sujets de Linux, du cloud et du devops, comme aujourd'hui. Si ces sujets vous intéressent, je vous suggère de vous abonner.



Texte écrit par Lucas Willems