Agents dans les opérations cloud, en commençant par la fin ennuyeuse

Les opérations cloud semblent conçues pour l'automatisation : un volume d'événements énorme, des enquêtes répétitives, une expertise concentrée chez quelques personnes et un retard d'améliorations que personne n'atteint.

L’instinct est de pointer un agent vers le flux d’alerte et de le laisser décider. C’est l’application la plus susceptible d’échouer, pour une raison qui mérite d’être évoquée avant toute autre chose.

Pourquoi les décisions automatisées échouent ici en premier

Une alerte signifie différentes choses selon ce qui s'est passé en amont, ce qui est en cours de déploiement, quelle maintenance est planifiée et si ce modèle ressemble à quelque chose qui s'est avéré n'être rien le trimestre dernier.

La majeure partie de ce contexte ne figure pas dans l'alerte. C'est dans d'autres systèmes et dans la tête des ingénieurs. Un agent qui décide sans cela aura certainement tort, et deux erreurs de confiance suffisent à mettre fin à la confiance qui a rendu le projet possible.

Il n’y a pas non plus d’étape de révision naturelle. Au moment où une décision peut être révisée, elle a déjà eu des conséquences.

Où ça marche

Assemblage du contexte avant qu'un humain ne décide. Modifications récentes sur le chemin concerné, incidents passés associés, état de déploiement actuel, section du runbook pertinente. Cela supprime à jamais les dix minutes de chasse qui précèdent chaque véritable diagnostic, sur chaque incident.

Les délais post-incident, qui existent dans plusieurs systèmes et sont rédigés tardivement et mal.

Une revue des coûts et des capacités, mécanique, continue et définitivement dépriorisée.

Validation des modifications par rapport à la politique et aux incidents passés, en signalant plutôt qu'en bloquant.

La limite d'accès

Un agent capable de lire l’état de l’infrastructure et ne peut pas le modifier représente un risque fondamentalement différent de celui qui peut faire les deux. Cette limite appartient au point où l'action se produit, et non à l'invite.

Les informations d'identification sont résolues au moment de l'exécution à partir du coffre-fort de l'organisation, de sorte qu'aucune information d'identification d'infrastructure ne réside dans la configuration d'un agent et que la révocation est une action unique.

Instrumentez l’agent comme vous instrumentez tout le reste

Les équipes cloud sont généralement douées dans ce domaine et oublient de l'appliquer à l'agent lui-même. Coût attribué par agent. Centiles de latence plutôt que moyennes, car les exécutions des agents sont fortement asymétriques. Les tentatives sont comptées séparément des réussites, puisqu’il s’agit du même travail facturé deux fois.

Des évaluations à chaque exécution plutôt qu'un audit périodique, car la panne qui vous intéresse est celle qui est apparue progressivement.

Forme de départ

Assemblage de contexte sur une classe d’incident. Propriétaire désigné du côté des opérations. Critères d'évaluation construits à partir des incidents réels du dernier trimestre. En lecture seule pour commencer, et un budget qui bloque.

Élargissez-le lorsque les partitions sont ennuyeuses, pas lorsque la démo est impressionnante.

Suivant

Les pages Observabilité de l'IA et Surveillance des jetons couvrent l'instrumentation. Les pages du système d'orchestration d'agent couvrent la stratégie, les informations d'identification et l'évaluation.