Automatisation auto-réparatrice sans bouton d’autorisation : systèmes de contrôle fonctionnant à 3 h du matin
Concevoir une réparation automatique sans surveillance pour les routines planifiées des agents : un système de contrôle externe, des actions définies en fonction de leur réversibilité, des déploiements progressifs de type canary ainsi que des rapports d’état étayés par des preuves.
Sources: Routines That Repair Themselves
Lorsqu’une équipe exécute des dizaines de routines planifiées et de sessions d’agents, le souhait suivant devient évident : lorsque une routine rencontre une erreur en elle-même ou dans son environnement, elle devrait corriger la cause racine toute seule, ou lancer une session distincte pour ce faire, sans que quiconque doive valider chaque étape au milieu de la nuit. L’objectif est légitime. Le danger réside dans le fait que la manière la plus rapide d’y parvenir, en supprimant les contrôles de validation ou en automatisant les actions, transforme une petite panne en un incident affectant l’ensemble du réseau, avec en plus une annonce fausse de résolution. Ce guide montre comment obtenir une réparation véritablement automatisée sans supervision, tout en préservant la distinction essentielle : savoir si une action peut être annulée.
Que se passe-t-il lorsque les contrôles disparaissent ?
Deux modes de défaillance apparaissent sans cesse dans les opérations automatisées, et il convient d’en étudier les deux avant de développer quoi que ce soit.
Une commande correcte, exécutée à grande échelle
Imaginez une commande vocale ou de chat qui est transcritue de manière légèrement erronée et parvient à une voie d’automatisation ayant autorité sur le planificateur. En environ cinq secondes, elle désactive 146 tâches planifiées, y compris tous les mécanismes de surveillance qui auraient dû s’en apercevoir. Rien ne fonctionne mal : le système fait exactement ce qui lui est ordonné, instantanément et à grande échelle.
La solution consiste en une règle suffisamment simple à retenir : toute commande de masse, qui désactive toute une catégorie d’éléments ou qui ne peut être annulée reçoit une seule ligne de confirmation avant d’être exécutée. Cette ligne indique ce qui sera modifié et quel en sera le coût en termes de réinitialisation. La lecture de cette ligne ne prend qu’une seconde ; en revanche, se remettre d’un incident sans elle peut prendre une heure ou plus.
Un rapport de récupération rédigé selon l’intention
La deuxième défaillance est plus subtile. Après un tel incident, les notes de récupération indiquent quelque chose comme « 30 restaurés sur 30 ». Quelques jours plus tard, une vérification via le planificateur en temps réel révèle que 27 tâches restent désactivées, parmi lesquelles la sauvegarde de la configuration, le moniteur de synchronisation et le gardien de session. La ligne d’état avait été écrite en fonction de ce que l’opérateur souhaitait faire, et non en fonction de ce que le système affichait réellement.
Cela donne naissance à une règle stricte de rapportage : une phrase du type « N restaurés sur N » n’est autorisée qu’à côté de la sortie de commande qui affiche à nouveau cet état. Sans cette preuve, l’expression correcte est « la commande de restauration a été envoyée ».
C’est le risque majeur de la réparation automatique. Un opérateur qui déclare un succès sans vérifier le résultat est pire qu’aucun opérateur du tout, car cela transforme une panne en une panne accompagnée d’un message rassurant indiquant que tout va bien.
Cinq règles pour une réparation qui s’exécute en autonomie
1. Une routine ne peut pas être son propre correcteur
Lorsqu’une routine est défectueuse, sa logique de réparation automatique est généralement également endommagée, et les deux échouent silencieusement en même temps. La réparation doit se situer à un niveau supérieur : un processus distinct, de préférence sur une machine séparée, qui surveille la routine depuis l’extérieur.
Ce qu’il convient de surveiller, c’est l’ancienneté des résultats générés par la routine, et non son code de sortie. Une tâche qui se termine avec un statut 0 sans écrire aucun contenu semble parfaitement fonctionnelle selon toute vérification de code de sortie. Il est tout à fait possible qu’une tâche de ce type reste inaperçue pendant des semaines. Une vérification de fraîcheur (“le fichier de rapport a moins de 26 heures”, “la dernière ligne du tableau date d’aujourd’hui”) permet de détecter précisément les défaillances que les codes de statut cachent.
2. Classifiez les actions, pas les approbations
La demande derrière « personne ne peut valider la nuit » est raisonnable, mais un bot qui valide automatiquement n’est pas la solution adéquate. Il efface cette seule ligne qui compte vraiment, celle qui distingue les actions réversibles des actions irréversibles, et ce le plus rapidement possible, justement lorsque personne ne surveille. Il cache également une décision : quelqu’un a quand même jugé ces actions sûres, et le bot ne fait que dissimuler qui a pris cette décision et quand.
L’alternative viable consiste à classer les actions elles-mêmes en différents niveaux :
- Automatique, sans intervention humaine, à n’importe quelle heure : redémarrer un service bloqué, réenregistrer une tâche planifiée qui a échoué, supprimer un verrou obsolète, relancer une importation idempotente, reconstruire un index. Ce sont des actions limitées, réversibles et sûres à reproduire.
Avec cette organisation, le premier niveau fonctionne en totale autonomie pendant la nuit, le troisième niveau attend dans un rapport du matin, et personne ne clique sur rien à 3 heures du matin. Tout aussi important : rien d’irréversible ne se produit à 3 heures du matin.
En notant la classification, on rend la décision de confiance explicite, vérifiable et modifiable dans un seul fichier. Cela correspond au même niveau de confiance accordé par un outil d’autorisation de clic, stocké à un endroit où il est possible de procéder à des audits et des tests. Pour en savoir plus sur les niveaux de risque et les mécanismes d’approbation pour les agents en général, consultez notre guide sur les permissions, les mécanismes d’approbation et les niveaux de risque.
3. D’abord le groupe de test, puis l’ensemble
Un correctif appliqué simultanément à tous les nœuds constitue en soi un point unique de défaillance : si le correctif est erroné, il l’est partout en même temps. Préférez plutôt une mise en œuvre par étapes :
- appliquer le changement à un seul nœud
- vérifier en examinant l’état résultant, et non en se fiant à un code de retour
- l’appliquer à un deuxième nœud de type différent
- seulement ensuite le déployer pour tout le monde
Donnez un nom à l’opération de réversion avant de commencer, afin que le retrait des modifications soit une procédure connue et non une improvisation sous pression.
4. Ne créez pas de dispositif de réparation pour la première panne
Les machines d’auto-réparation se multiplient facilement, car chaque erreur isolée semble mériter son propre robot. Un seuil permet de contrôler cela. La première occurrence d’un problème se voit consigner sous forme d’une seule ligne datée dans un journal. Un mécanisme n’est créé que lorsque le même type de panne se produit pour la troisième fois, et uniquement s’il existe un utilisateur identifié qui en a besoin.
Sans une telle règle, les coûts supplémentaires peuvent augmenter de manière alarmante. Une équipe qui a mesuré son propre travail a constaté que 82 % de son activité était constituée de « meta-travail » : des machines conçues pour gérer d’autres machines. L’automatisation des réparations est précisément la catégorie la plus sujette à cette spirale.
5. Fournissez à chaque session générée des instructions autonomes
Une session lancée à 4 heures du matin par un organisme de surveillance ne dispose pas du contexte dont dispose le processus qui a détecté le problème. Fournissez-lui un résumé contenant :
- ce qui a défailli
- les preuves
- ce qui a déjà été essayé
- les limites de ce qu’elle peut modifier
- la définition de l’achèvement
Ces limites sont ce que les gens oublient. Sans elles, un agent zélé va volontiers corriger des éléments voisins sur lesquels personne n’a demandé d’intervention, ce qui transforme une correction ciblée en un changement étendu non examiné.
Lorsqu’un agent approuve un autre
Une suggestion courante consiste à permettre à un agent d’approuver un autre, par exemple dans une discussion partagée où un agent superviseur demande à un employé de procéder. Il existe des outils prêts à l’emploi pour initier des sessions de cette manière. Ce modèle fonctionne bien pour le premier niveau d’actions. C’est également exactement la façon dont les actions de troisième niveau sont acceptées à 3 heures du matin si rien ne les distingue. Une fois que les actions sont définies en fonction de leur réversibilité, l’approbation d’un agent par un autre devient sûre à utiliser, car le superviseur ne peut approuver que ce que la classification autorise déjà.
Points clés
- Mettre la réparation en dehors de l’objet à réparer, et évaluer son état en fonction de la fraîcheur des résultats plutôt que des codes de sortie.
- Remplacer le clic d’approbation par une classification écrite des actions en fonction de leur réversibilité et de leur impact.
- Exiger une confirmation en une ligne pour les commandes massives, applicables à toute la catégorie ou irréversibles, en indiquant leur portée et le coût d’annulation.