Illustration par Jérémy Molet

Certaines leçons valent bien un fromage, d’autres valent bien un article. Dans cette série d’articles rédigés sous forme de conte, nous vous proposons des histoires issues de situations rencontrées sur le terrain, et les leçons que nous en avons tirées. Car les bonnes pratiques ne peuvent s’établir qu’à l’aune des mauvaises, et que ces anecdotes, aussi incroyables soient-elles, sont véridiques et reflètent la réalité de certains systèmes d’informations.

Le rythme des journées

Il était une fois un majordome qui travaillait dans un beau et grand château. Le majordome s’affairait dur pour que le château soit bien organisé.

Pour rythmer les journées une horloge sonnait chaque heure de la journée. C’était pratique, à chaque heure il y avait une douce mélodie qui permettait au majordome de bien s’organiser sur ses différentes tâches.

Cette horloge avait un défaut que nul n’avait réussi à résoudre: à quatre heure du matin elle ne sonnait pas. Malheureusement l’horloger qui avait mis en place cette horloge était parti, et personne ne savait où elle était tant le château était grand.

Tout le monde s’affaira à chercher cette horloge: dans la bibliothèque, dans la salle à manger, dans l’entrée, mais impossible de la trouver. Impossible de savoir d’où venait cette mélodie bien pratique qui rythmait les jours.

Un jour que le majordome devait exceptionnellement gérer le linge et qu’il arrivait dans la buanderie quelle ne fût sa surprise en voyant cette horloge… ou plutôt devrait-on dire ces vingt quatre carillons!

En effet cet horloger coquin avait programmé un carillon pour que chacun joue de sa musique à chaque heure de la journée! N’en déplaise à cet horloger innovateur, le majordome a rangé ces carillons et mis en place une seule horloge dans l’entrée afin que chacun sache d’où venait sa douce mélodie bien rythmée.

La réalité derrière le conte

Un peu de contexte pour mieux comprendre : un ordonnancement des arrêts/redémarrages pour des EC2 et des RDS avait été mis en place sans être documenté.

Un jour, un ticket est arrivé pour signaler que les ressources ne démarraient pas le vendredi. Après avoir fait des recherches dans les services classiques, nous n’avons pas pu déterminer comment était fait cet ordonnancement sans CloudTrail actif et sans temps nécessaire pour l’analyse comparé à aller lancer manuellement les ressources.

Quelques jours après, par hasard, nous avons découvert un data pipeline, service dédié au traitement et au transfert de la donnée, avec dix règles définies : start lundi, stop lundi, …  

Innover de manière réfléchie

Ce petit conte adapté de ma vie de consultant m’a rappelé des fondamentaux à maintenir dans les différents contextes dans lesquels j’interviens.

Cela peut paraître évident, mais on peut parfois s’en éloigner pour des raisons plus ou moins valables. Innover oui, c’est un des fondements de notre métier, mais innover de manière réfléchie c’est mieux.

De la considération des nouveaux outils

Quand un outil existe: on ne réinvente pas la roue! On fait toujours une analyse de l’existant, on regarde ce que la communauté fait. Si on s’oriente vers une voie originale, on doit bien y réfléchir à deux fois, sinon les prochains intervenants vont non seulement se poser des questions, mais sans doute devoir dépenser du temps non négligeable pour comprendre ce qui a été mis en place.

De l’usage des outils

Quand un outil a un usage bien défini: on ne le détourne pas de son usage! Si un outil permet de faire une tâche programmée à heure fixe, cela n’en fait pas un ordonnanceur, d’autant plus si pour faire cette tâche de manière récurrente on est obligé de faire plusieurs fois cette tâche avec une fréquence propre. Cela peut sembler une bonne idée au début du projet, mais quel besoin ne change pas au cours de la vie d’un projet?

Du bon usage de la documentation

Quand on implémente quelque chose: on documente! Rien ne sert de faire une documentation où l’on raconte la génèse du projet (sauf si le client le demande bien sûr), mais on peut reprendre la méthode des 5 W de nos amis anglophones:

• Who: qui est la cible (l’équipe de dev, des ops, de la sécu, le métier, …)
• Why: pourquoi c’est mis en place (exporter la base de données, arrêter un service, …)
• What: qu’est-ce qui a été réalisé, généralement c’est ce à quoi on pense tout de suite puisqu’on sait ce qu’on a implémenté
• Where: où est-ce que cela a été implémenté (dans quel compte, dans quel outil ou service, dans quelle arborescence est-ce disponible, …)
• When: Quand est-ce que c’est exécuté (tous les matins, à chaque fois qu’il y a un événement, lors du déploiement d’une nouvelle version, …)

Localiser la documentation

Ecrire une doc c’est bien, mais il faut que les personnes susceptibles de lire cette doc sachent où la trouver! Soit il y a un référentiel documentaire dans lequel il faut faire l’effort de s’insérer, soit on est moteur pour mettre en place un petit référentiel (disque partagé, drive partagé, wiki, …). Le but d’une doc c’est de communiquer donc si vous la faites dans votre coin, elle ne servira pas à grand chose si ce n’est vous rendre incontournable, ce qui pourrait un jour ne plus être si intéressant pour votre client… ou vous-même!

S’adapter à l’éco-système

Enfin il faut garder des pratiques homogènes. Si dans l’environnement on utilise Jenkins ou Gitlab CI pour ordonnancer, même si CodePipeline permet de faire une bien meilleure implémentation, il faut peser le pour et le contre avant de s’y lancer tête baissée. Et si malgré tout on décide d’aller vers cette solution innovante, on n’oublie surtout pas tous les points précédents! 

Chasser le corbeau

On pourrait parodier La Fontaine pour conclure:

Mon bon Monsieur,

Apprenez que tout consultant

Vit aux dépens de celui qui l’écoute :

Cette leçon vaut bien un article, sans doute.

Le Corbeau, honteux et confus,

Jura, mais un peu tard, qu’on ne l’y prendrait plus.

Malheureusement dans notre cas, le corbeau est parti et est déjà sur une autre mission sans qu’on ait pu lui dire de ne pas recommencer. Evitons donc d’être le corbeau des prochains intervenants de notre projet.