Skrypty operacyjne

Toute infrastructure a une couche de travail qui est ennuyeuse jusqu'au moment exact où elle devient critique. Un certificat qui expire un dimanche. Un backup qui tire dans le vide depuis un mois. Un secret poussé par accident dans un dépôt. Un port occupé qui ne devrait pas écouter. Rien de tout cela ne crie tant qu'il n'est pas trop tard.

Nous avons rassemblé ces contrôles dans une bonne douzaine de petits scripts et les avons cachés derrière une seule commande. Le but n'était pas technique mais humain : faire que l'hygiène de l'infrastructure cesse de dépendre du fait que quelqu'un ait pensé à s'en occuper. Car la mémoire, comme il s'avère en pratique, est le pire mécanisme de sécurité qu'on puisse choisir.

L'entretien de l'infrastructure est le genre de travail qu'on peut toujours faire demain. Ennuyeux tant que tout fonctionne, il cède donc poliment la place aux choses qui ont une échéance. Le problème, c'est qu'il n'en a pas lui-même - jusqu'à ce qu'il en ait soudain une, et une dure : le certificat expire aujourd'hui, le backup était nécessaire hier.

Ce n'est pas un problème technique. Chacun de ces contrôles peut se faire à la main en une minute. Le problème, c'est qu'ils exigent que quelqu'un s'en souvienne, régulièrement, en arrière-plan d'un autre travail - et c'est exactement ce que les gens font mal. Plus il y a de choses à retenir, plus sûrement l'une d'elles passe à la trappe, en général celle qui aurait justement attrapé quelque chose cette fois-ci.

Nous avons donc réduit toute la routine à une seule commande qui ne dépend de la mémoire de personne. Vous la lancez à la main avant un déploiement ou vous l'intégrez dans un planning et vous l'oubliez - et c'est précisément l'effet recherché.

Pour que quoi que ce soit puisse s'intégrer à la CI ou à cron, il faut que cela parle par un code de sortie, pas par un paragraphe de texte. Zéro veut dire propre, tout le reste veut dire : allez voir. C'est tout le contrat, et c'est justement sa simplicité qui rend l'outil automatisable sans le moindre truc.

La même commande a deux visages. Pour un humain, elle affiche un rapport lisible - ce qui a été vérifié, ce qui est passé, ce qui demande de l'attention. Pour une machine, elle renvoie du JSON qui se parse et se branche sur une alerte. Une entrée, deux formes de sortie, aucun texte destiné aux humains se faisant passer pour une interface pour machines.

La partie la plus difficile d'un tel outil, ce ne sont pas les contrôles eux-mêmes mais les seuils. Une alarme qui sonne toujours vaut autant qu'une alarme éteinte - les gens cessent simplement de la lire, et alors elle rate l'unique fois où quelque chose ne va vraiment pas. C'est la façon la plus courante dont le monitoring se tait : pas par panne, mais par bruit.

C'est pourquoi chaque contrôle a un seuil réglé de sorte que la commande se taise quand tout va bien. Un certificat qui expire dans six mois n'est pas une alarme. Un certificat qui expire dans une semaine, si. Un backup d'il y a une heure va bien, d'il y a un mois non. Les seuils existent pour que le silence signifie quelque chose.

Ce n'est pas un outil spectaculaire, et il n'a pas à l'être. Il n'y a pas de tableau de bord, pas de graphiques, rien à montrer sur une capture d'écran. Toute sa valeur tient à ce que la routine a cessé de dépendre de la mémoire de qui que ce soit - elle se lance d'elle-même, et quand elle se tait, ce silence signifie vraiment propre.

La différence, c'est que la classe de problèmes qui ne surgissaient qu'à la panne surgit désormais plus tôt - lors d'une simple passe avant un déploiement ou à heure fixe depuis cron. Un certificat qui expire prévient une semaine à l'avance, pas un dimanche à trois heures du matin. C'est tout le travail de cet outil : transformer un silence né de l'ignorance en un silence né de la certitude.