Il est 2 h 17 et le moniteur de votre application signale une latence élevée de la base de données. Avant que votre ingénieur d'astreinte ait fini de lire l'alerte, trois agents ont déjà répondu.
L'agent de performances double la capacité de la base de données. L'agent de gestion des coûts, voyant ce qui semble être un surprovisionnement, commence à consolider les instances de base de données. L'agent de routage redirige le trafic via le niveau base de données. Chaque décision est enregistrée. Chacun d’entre eux prend tout son sens isolément. Chacun correspond exactement à ce pour quoi l’agent a été conçu.
À 2 h 19, votre couche de base de données est en panne, non pas parce que quelque chose est cassé, mais parce que tout a fonctionné. Aucun agent n'affichera d'erreur dans ses journaux. Reconstruire une séquence de deux minutes dans laquelle chaque décision individuelle était correcte, mais la combinaison était catastrophique, prendra trois jours.
Voilà à quoi ressemblera la prochaine catégorie de pannes d’infrastructure.
C'est déjà en train d'arriver
Le mode de défaillance que les agents vont amplifier ne commence pas nécessairement par l’intelligence artificielle. Et trois incidents majeurs survenus l’année dernière le démontrent clairement :
- AWS DynamoDB DNS — Deux systèmes indépendants fonctionnaient chacun correctement. L’un d’entre eux a appliqué une configuration plus ancienne et a rencontré des retards. L'autre a appliqué une configuration plus récente et déclenché le nettoyage. Le système retardé a écrasé la configuration la plus récente au moment précis où le nettoyage l'a supprimée. L’échec vivait entièrement dans le timing entre eux.
- Azure Front Door — Un plan de contrôle a généré des métadonnées défectueuses, qu'un système automatisé a correctement bloquées. Le processus de nettoyage a fonctionné comme prévu mais a déclenché un bug dormant dans un troisième composant. L’échec est né de la séquence d’actions correctes.
- Cloudflare Bot Management — Une modification des autorisations a provoqué des résultats de requête en double. Le système de configuration les a traités correctement, produisant un fichier valide mais surdimensionné. Le proxy a correctement appliqué sa limite de taille et l'a rejetée. La sortie correcte d'un système dépassait la contrainte correcte d'un autre système.
Chaque défaillance était invisible depuis l’intérieur d’un système unique. Imaginez maintenant que le même schéma se reproduise entre des dizaines d’agents prenant des décisions simultanées à la vitesse d’une machine.
Au-delà de l'automatisation
L'infrastructure de gestion de l'automatisation n'est pas nouvelle. La mise à l'échelle automatique ajuste la capacité du serveur, Kubernetes déplace les charges de travail, les plates-formes AIOps redémarrent les services défaillants. Ces systèmes suivent des règles prédéterminées dans des limites étroites et bien définies.
Mais l’infrastructure définie par l’agent est différente. Il observe les conditions, pèse les compromis et prend des décisions à la vitesse de la machine. Et les organisations ne déploient pas un ou deux agents ; ils en ont des dizaines qui travaillent simultanément, prenant tous des décisions sur l'infrastructure partagée en quelques secondes. Les modèles d'interaction qui ont provoqué les échecs d'AWS, Azure et Cloudflare ne disparaissent pas dans cet environnement ; ils se multiplient de trois manières spécifiques.
- Plusieurs agents résolvant le même problème peuvent aggraver la situation. Un agent voit la file d'attente A débordée et détourne les tâches vers la file d'attente B. Un autre voit la file d'attente B débordée et redirige le trafic vers la file d'attente A. Tous deux réagissent correctement à ce qu'ils observent, mais ensemble, ils ont créé une boucle sans fin qu'aucun des deux ne peut résoudre seul – la même dynamique derrière les krachs éclair sur les marchés financiers et la destruction des ressources dans les systèmes à mise à l'échelle automatique.
- Les agents ne peuvent pas faire la différence entre les erreurs et les décisions. Lorsqu'un agent voit l'action d'un autre, il est confronté à une question à laquelle il ne peut pas répondre de manière fiable : le mouvement était-il intentionnel ou une erreur ? Si c’est intentionnel, l’inverser provoque le chaos. S'il s'agit d'une erreur, la corriger est tout l'intérêt. Sans coordination, les agents finissent par se battre ; l’un augmente la capacité, un autre la réduit et le premier l’augmente à nouveau. Chaque journal montre un comportement parfaitement rationnel. Ce qui ressemble de l’extérieur à un problème d’infrastructure est en réalité un échec de coordination.
- Les décisions locales deviennent des problèmes à l’échelle du système. Un agent gérant le service A affecte le service B. L'agent du service B répond, affectant le service C. Au moment où votre équipe commence à enquêter, les conditions à l'origine de chaque décision peuvent ne plus exister. L’autopsie, c’est comme résoudre un puzzle dont la moitié des pièces ont déjà changé de forme.
Le scénario de 2 h 17 touche les trois simultanément, et les journaux de personne ne montrent rien d'anormal. C’est le fil conducteur : ces échecs sont invisibles jusqu’à ce qu’il soit trop tard, à moins que vous ne regardiez les bonnes choses.
Compréhension fragmentée
Ajoutez suffisamment d'agents à un environnement de production et le nombre de modèles d'interaction potentiels n'augmente pas régulièrement ; cela s’aggrave avec chaque agent ajouté et chaque expansion de leur champ d’autorité.
La surveillance traditionnelle a été conçue pour un problème différent. L'utilisation du processeur, l'utilisation de la mémoire, la latence des requêtes et les taux d'erreur vous indiquent quand quelque chose au sein d'un même système tombe en panne. Ils n’ont pas été conçus pour vous montrer ce qui se passe lorsque plusieurs systèmes, se comportant tous correctement, interagissent de manière à produire collectivement un échec.
L’exigence est fondamentalement différente. La question n'est plus de savoir si le service A est sain, mais comment ses modifications déclenchent des actions dans les services B, C et D. Ce n'est pas seulement ce que l'agent a fait qui compte, mais aussi ce qu'il a examiné lorsqu'il a pris une décision.
Répondre à ces questions nécessite une visibilité qui couvre le réseau, le calcul, les applications et les données, avec une vue unifiée de la façon dont les actions dans un domaine se répercutent sur les autres en temps réel. Les incidents peuvent désormais être diagnostiqués non pas grâce à de meilleurs paramètres de composants, mais en observant comment les dépendances, le timing et les décisions individuelles peuvent se combiner en échec.
Les ingénieurs expérimentés en fiabilité des sites gèrent déjà une partie de ce risque grâce au gel des modifications, aux déploiements par étapes et aux contrôles du rayon de souffle. À la vitesse de l'agent, cette fenêtre se ferme. Les mêmes instincts s’appliquent, mais vous ne pouvez pas coordonner ce que vous ne pouvez pas voir.
Ce qui vient ensuite
L'infrastructure définie par l'agent n'est pas un risque à éviter, mais un changement à gérer. Les avantages sont réels : des temps de réponse plus rapides, une meilleure optimisation et une charge opérationnelle moindre.
Les pannes d'agent ne se produisent pas parce que les agents fonctionnent mal, mais parce qu'ils ont fonctionné comme prévu. L'assurance doit tenir compte de la manière dont les décisions correctes et indépendantes se combinent dans la production. Cela fait de la visibilité des interactions non pas un problème de surveillance à résoudre après le déploiement, mais une contrainte de conception. Vous le construisez avant la mise en ligne des agents, ou vous le déboguez à 2h17 du matin.
Joe Vaccaro est vice-président et directeur général de la plateforme et de l'assurance chez Cisco Systems Inc. Il a écrit cet article pour SiliconANGLE.
