La prod est tombée !!!

Aujourd’hui, je vais raconter quatre histoires : quatre cas où la prod est tombée, avec à chaque fois un contexte et des réactions différentes.

Histoire n°1

Cette première histoire commence de manière assez classique¹ : le client passe un coup de téléphone au chef pour lui signaler que la prod est tombée et qu’il faudrait investiguer au plus vite.

Le chef se tourne vers son développeur, lui signale le problème et demande « qu’est-ce que je peux faire pour toi ? ». Le développeur répond que son chef peut commencer par « gérer le client » et qu’au besoin, il lui fera signe, en fonction des résultats de ses recherches.

Le développeur a résolu le problème assez rapidement. Le chef a répondu au client qui est venu aux nouvelles une ou deux fois entre-temps.

Point fort : le développeur a pu faire son boulot en paix, efficacement, sans que personne ne le dérange. En cas de problème, il pouvait appeler à l’aide ou demander des renseignements complémentaires.

Histoire n°2

La seconde histoire correspond à la mise en production d’un site grand-public, qui s’est déroulée un week-end. Au moment de valider le système de paiement utilisé par l’application, l’équipe s’est rendue compte que celui-ci ne fonctionnait pas² – et après prise de renseignements, impossible de l’activer avant le lundi (et bien sûr, impossible de décaler de deux jours la mise en production).

Après discussion entre le développeur expérimenté et le développeur qui avait initialement branché le système de paiement dans l’application, ainsi que le chef et le client, il a été décidé de mettre en place une solution de contournement³.

Il était presque midi, les pizzas sont arrivées à ce moment là et le gros de l’équipe est parti déjeuner en salle de pause, pendant que le développeur restait à son poste, mangeant sa pizza d’une main en gardant le clavier sous l’autre, occupé à dé-brancher un premier système de paiement et à en brancher un autre passant par la solution de contournement retenue.

Point fort : l’équipe (développeurs + chefs + clients) a fait confiance au développeur : il a pu faire son boulot dans de bonnes conditions⁴, tout en ayant eu du soutien lors de la phase de recherche de solution.

Histoire n°3

Cette troisième histoire commence par un site grand-public tombé, en raison d’un pic de consultations brutal.

Arrive un grand-chef⁵ qui ordonne aux développeurs de débrancher leurs PC fixes et d’aller dans le bureau des administrateurs système, à l’autre bout du bâtiment – notez qu’il s’agit de PC fixes (donc, il faut vraiment tout débrancher, y compris écran et clavier et souris, trouver un chariot, …). Une fois arrivés à l’autre bout du bâtiment, le grand-chef ordonne de re-brancher le tout (ce qui inclut trouver une ou deux multi-prises, des chaises, de faire de la place sur un bureau, de tout rebrancher et rallumer…).

Une fois les développeurs et administrateurs système laissés entre eux, finalement, chacun des deux développeurs ayant fait le voyage s’est mis en pair avec un administrateur – sans toucher aux PCs qui avaient été déplacés. Une dizaine de minutes après, une piste était trouvée. Quelques minutes supplémentaires et une bidouille temporaire était en place pour corriger le problème au plus vite.

Bien sûr, il a ensuite fallu faire le trajet inverse, en débranchant les PCs (et rendant les chaises et multi-prises à leurs propriétaires dans d’autres bureaux), les re-posant sur le chariot, re-traversant le bâtiment, puis en rebranchant les PCs à l’autre bout, …

Point fort : les développeurs et administrateurs système ont mis en commun leurs compétences respectives (et connaissance de l’application / de la plate-forme l’hébergeant) pour rapidement trouver l’origine du problème et apporter une solution⁶.

Questions bonus : combien de temps a été perdu avant de vraiment s’attaquer à la résolution du problème ? Et avant de recommencer à bosser ensuite ?

Histoire n°4

Cette quatrième et dernière histoire commence elle aussi de manière assez classique : la prod est tombée, sur un site grand-public, sans raison apparente (pas de pic de consultation majeur), et les développeurs recherchent ce qui pourrait expliquer cette chute.

Le N+3⁷ a été appelé par des gens importants, la pression monte. N+2 décide donc qu’il faut faire une réunion, avec N+1 et le lead-dev du projet. Cette réunion dure un moment, pendant lequel les autres développeurs continuent à fouiller – mais ils ont moins d’expérience que le lead-dev sur ce type de situation, connaissent moins bien que lui les points sensibles de l’application et n’osent pas mettre en œuvre seuls les pistes qui avaient été évoquées avant la réunion. Pendant cette réunion, le lead-dev propose un truc (genre modifier un paramétrage) pour essayer de calmer le feu. Le N+2 est d’accord, mais indique qu’il ne faut pas en parler à N+3.

A l’issue de cette réunion, le lead-dev retourne à son équipe, la proposition technique est mise en place et le site web a l’air de re-fonctionner de manière correcte. Le lead-dev profite de l’accalmie pour aller chercher un café.

Dans la salle de pause, le lead-dev est rejoint par le N+3 qui lui dit « j’ai vu que les graphes munin redescendaient, viens dans mon bureau et dis-moi ce que tu as fait ». N’ayant pas réellement le choix, le lead-dev suit le N+3 et explique la modification apportée (en se disant qu’il ne devrait pas mais n’a pas trop le choix – N+2 avait dit qu’il ne fallait pas que N+3 sache, mais le développeur ne fait pas de politique. Et, en même temps, la proposition en question a rétabli le bon fonctionnement du site, hein).

Après cela, le lead-dev se prend un commentaire du N+2 en mode « je t’avais dit de ne pas en parler à N+3 », suivi de l’interrogation de N+1 « mais tu lui as dit ? »…

L’objectif⁸, après avoir lu cette histoire, est double : déterminer combien de temps a été perdu avant de résoudre le problème… Et estimer l’humeur et le niveau de motivation du lead-dev après cet incident – ainsi que son envie de continuer à bosser là.

Question bonus à laquelle personne n’a su répondre : pourquoi le N+3 a-t-il accès aux graphes de monitoring des serveurs et essaye-t’il de les analyser ? Et surtout, pourquoi est-ce qu’il ne se fie pas à ses équipes, qui ne lui font donc pas non plus confiance en retour ?

Et maintenant ?

Après ces quelques histoires, quelle situation vous convient le mieux, quand la prod est tombée ?

Pour ma part :

• Être à deux à se mettre sur le problème, en pair (sur la même machine ou non – mais proches l’un de l’autre, pour échanger des idées et savoir ce que l’autre a fouillé ou envisage), permet d’aller plus loin dans l’analyse et de recouper les idées.
• Mélanger les compétences (« dev » et « ops ») est un gros plus.
• Et enfin, à mes yeux : le rôle d’un chef dans ce type de situation est de faciliter les choses pour son équipe, en absorbant la pression et en lui permettant de travailler sans être interrompu par des éléments perturbateurs (clients, hiérarchie, chef lui-même) – tout en étant disponible au besoin et en se tenant au courant (par exemple, en étant connecté sur l’outil de messagerie instantanée utilisé par l’équipe, en écoutant ce qu’il se dit – et pas en allant interrompre les développeurs toutes les trois minutes façon « c’est urgent, vous en êtes où ? » !

Et vous, des souvenirs de jours où la prod est tombée ?