Pourquoi il ne faut pas toujours automatiser une tâche

Publié il y a 3 ans par Quentin

Il y a peu de temps, j'ai vu passer un article sur des automatisations abusives d'un administrateur système russe. Celui-ci avait fait un script pour envoyer automatiquement un SMS à sa femme si un shell était encore ouvert passé une certaine heure. De la même manière, il avait automatisé l'envoi de mail pour dire qu'il travaille de chez lui s'il n'avait pas ouvert un shell avant une certaine heure. Il avait aussi automatisé des réponses à certains mails qu'il avait régulièrement ou encore que la préparation de son café.

L'automatisation est une chose que j'aime beaucoup. Qu'y a-t-il de plus frustrant que de répéter une tache quand quelques lignes de code peuvent le faire pour nous ? Malheureusement, une bonne automatisation, ça demande du temps. La plupart du temps, les premières choses que l'on veut automatiser ce sont des choses critiques et chronophages. Pour cause, si ce sont des choses critiques, il vaut mieux être sûr que ce soit bien fait systèmatiquement.

Parfois, on a aussi envie d'automatiser une tache tout simplement ennuyeuse. On vous demande régulièrement cette même statistique issue de la base de données ? Automatisons-le. Quand un serveur tombe et qu'il faut le redémarrer ? Ça dépend. Cette statistique compliquée qu'on vous demande une fois par an ? Ça m'étonnerait qu'il faille l'automatiser.

Il ne faut pas tomber dans le piége de tout automatiser. XKCD avait fait un bon exemple de quand automatiser une tache en se basant sur des critères simples : Combien de temps je vais mettre pour optimiser, combien de temps je vais gagner par utilisation et combien de fois je vais l'utiliser. J'ai fait une page pour calculer ça avec vos propres valeurs si ça vous intéresse.

Il y a deux choses que ne prend pas en compte l'automatisation et qu'on oublie un peu trop souvent quand on automatise : Combien de temps pour vérifier le résultat de l'optimisation et combien de temps pour la corriger si il y a un problème.

On est rarement sûr à 100% du résultat d'une statistiques où d'un calcul. C'est pour ça que généralement on apprends en école primaire de faire des preuves. Quand vous automatisez une tache, il faut absolument que vous ayiez une preuve que le résultat escompté est arrivé (un peu comme avec les tests unitaires). Si vous n'avez pas de moyen de le faire, vous vous exposez à de gros problèmes sans même être au courant.

Je vais prendre un exemple simple qui est arrivé dans mon équipe. Un développeur décide d'activer le cache sur un espace de prod afin d'essayer de gagner un peu de performance. Il se rend compte que le cache crée de nombreux fichiers qui pourraient remplir rapidement le disque dur. Du coup, il fait un script pour vider ce dossier en tache cron. Il va faire un cd dans le dossier de cache puis un rm -rf *. Après ses tests, il a jugé que le cache n'avait pas une impact intéressante sur les performances et a donc désactivé le cache et supprimer le dossier. Sa cron s'est ensuite lancée. Elle a tentée le cd qui a raté(le dossier venait d'être supprimé), le script était donc toujours dans le même dossier (le dossier home du site). Il a ensuite simplement lancé le rm -rf * à l'endroit où il se trouvait. Le répertoire home fut vidé et le site avec. Heureusement il y avait un backup mais du coup le site n'était plus disponible pendant quelques minutes. On a eu peur d'un accès non autorisé au serveur avec avant de comprendre le problème. Moralité : Si le résultat du cd était vérifié dans le script, ça ne serait pas arrivé.

Quand on automatise, généralement, on utilise des APIs ou des logiciels qui peuvent venir à changer. Il n'est pas rare de la part de Facebook ou Twitter d'avoir des fermetures d'apis, des changements de fonctionnement ou simplement de nouvelles restrictions. Certes elles sont difficiles à prédire mais vous perdez tout le temps que vous avez gagné quand ça arrive si vous n'avez pas prévu le coup. Prevoyez aussi de toujours considérer les cas d'erreurs des API quand vous automatisez, ça vous permettra de savoir rapidement où votre automatisation à un problème si il y en a un.

Du coup, quand vous automatisez, il est toujours important d'avoir une trace du résultat, surtout si cette automatisation est une tache cron. Il m'est déjà arrivé d'avoir une tache cron qui plante qu'à certaines heures de la journée par exemple. Pire, une tache cron qui plante le jour du changement d'heure !

Bref automatiser c'est bien mais il faut faire attention à ne pas le faire pour ce qui n'en a pas besoin. Si un traitement long peut être automatisé alors on peut le faire mais seulement à condition qu'il y ait une vérification du résultat. Sinon, c'est accepter de travailler avec quelque chose de potentiellement pas bon.

La prochaine fois que vous allez faire une automatisation, posez-vous les questions suivantes :

  1. Est-ce que ça vaut le coup ?
  2. Est-ce que je peux vérifier le résultat ?
  3. Pourrais-je la maintenir à jour ?