Pendant l'incident que j'ai raconté récemment, une pensée m'a traversé une fois la prod rétablie : et si je n'avais pas été là ? Injoignable, ou incapable de me rappeler les commandes que je venais de lancer, personne n'aurait pu reprendre. Le système ne tenait pas à un serveur fragile. Il tenait à moi.
En fiabilité, un point de défaillance unique (SPOF) est le composant dont la panne fait tomber tout le reste. Appliqué à une personne, c'est simple : si tu es le seul à savoir, ton absence est la panne. Ce jour-là, le SPOF, c'était moi.
Un plan n'est pas un état
Avant la migration, j'avais pourtant écrit un document. Il expliquait ce que j'allais faire : le plan, les étapes prévues. Sur le papier, j'étais couvert.
Sauf qu'un plan et un état, ce sont deux choses différentes. Mon document disait où je voulais aller, pas où j'en étais. En plein incident, la seule question qui compte, c'est la seconde : qu'est-ce qui a déjà été fait, quelles commandes ont tourné, comment revenir en arrière. Rien de tout ça n'était écrit : ça vivait dans ma tête, et ce qui n'existe que dans une tête ne se transmet pas.
Être irremplaçable est un piège
On croit souvent qu'être le seul à maîtriser un sujet est une position de force. C'est l'inverse. Tant que tu es le seul à savoir, tu es le maillon dont la défaillance bloque tout le monde : la moindre absence, maladie ou vacances, et plus personne ne peut avancer. Et ce n'est pas qu'un risque pour l'équipe, c'en est un pour toi : tu deviens irremplaçable au mauvais sens, celui qui empêche de déléguer et de passer à autre chose.
Ce que j'ai changé
J'ai repris mon document et je l'ai transformé, d'un plan en un état vivant. J'y ai ajouté ce qui manquait : le contexte et le pourquoi, l'état réel du système, les étapes déjà faites avec leurs commandes exactes, et la procédure de rollback. De quoi savoir à tout moment où on en est, et reprendre à froid.
J'ai aussi repris mes scripts. Ils marchaient, mais ils n'étaient pas lisibles, et surtout sans un mot sur le quoi et le pourquoi. Je les ai commentés, puis reliés au document : le document pointe vers le script, le script renvoie au document. Plus de boîte noire. N'importe qui peut désormais reprendre à froid.
Documenter, c'est aussi communiquer
Écrire ne suffit pas si personne ne sait au bon moment. La documentation est une communication asynchrone ; il y a aussi la communication tout court. La règle que j'en ai tirée : calibrer la communication à l'ampleur du changement. Prévenir tout le monde pour une modif mineure, c'est du bruit ; ne prévenir personne pour un changement à fort impact, c'est l'incident assuré. Avant de toucher un environnement de démo, par exemple, je préviens les équipes commerciales : une démo qui tombe en plein rendez-vous client, c'est leur problème avant d'être le mien. Qui est impacté décide qui tu préviens, et combien de temps à l'avance.
Ce que j'en retiens
Documenter, ce n'est pas de la perte de temps. C'est ce qui fait que le système, et l'équipe, ne dépendent ni de ma mémoire ni de ma présence. Et paradoxalement, cesser d'être indispensable m'a rendu plus utile : on te confie des choses plus importantes quand ce que tu fais ne repart pas avec toi.
J'ai même transformé ce document en modèle réutilisable, pour ne plus repartir d'une page blanche au prochain projet.