La place des agents dans les opérations de télécommunications

Les opérations télécoms ont le profil qui pousse les gens à recourir à l'automatisation : un volume d'événements énorme, un tri répétitif, une expertise approfondie concentrée dans un petit nombre de personnes et un retard permanent de travail important mais pas urgent.

L’instinct est de diriger un agent vers le flux d’alerte. Nous suggérerions d’abord presque n’importe où ailleurs.

Pourquoi le tri des alertes n'est pas le bon premier projet

Les flux d’alertes ressemblent à des problèmes de classification et se comportent comme des problèmes de jugement. La même alerte signifie différentes choses selon ce qui s'est passé en amont vingt minutes plus tôt, quelle maintenance est programmée et si le schéma ressemble à celui qui s'est avéré nul l'hiver dernier.

Ce contexte réside dans la tête des ingénieurs et dans les systèmes qui ne sont pas connectés à l'alerte. Un agent qui passe un appel sans cette information se trompera en toute confiance, ce qui coûte cher, et s'il se trompe deux fois, personne ne lui fera confiance pour les cas où il avait raison.

Il existe également un problème structurel : le tri des alertes ne comporte aucune étape de révision naturelle. Au moment où quelqu’un révise la décision, elle a déjà eu des conséquences.

Où les agents travaillent bien ici

Préparation plutôt que décision. Rassembler le contexte dont un ingénieur a besoin avant de passer l'appel : modifications récentes sur le chemin concerné, incidents passés similaires, section du runbook pertinente, fenêtres de maintenance actuelles. Bien fait, cela supprime les dix minutes de chasse qui précèdent tout véritable diagnostic.

Rédactions post-incident. La chronologie existe sur plusieurs systèmes et son assemblage est un travail fastidieux qui est mal ou tardif. Un agent qui le rédige à partir du dossier, avec des citations, et laisse l’analyse à une personne, est tout simplement utile.

Validation du changement. Vérifier une modification de configuration proposée par rapport à la politique et aux incidents passés avant qu'elle ne soit appliquée, et signaler plutôt que bloquer.

Récupération de connaissances dans une documentation accumulée au fil des décennies dans des formats incohérents, où trouver la bonne section est véritablement difficile.

Le schéma est le même que partout ailleurs : les agents sont doués pour assembler et rédiger, et le jugement appartient à la personne.

Les contraintes qui façonnent le déploiement

Les données opérationnelles ne peuvent souvent pas quitter l'infrastructure de l'opérateur, ce qui fait du déploiement auto-hébergé ou en espace clos une hypothèse de départ plutôt qu'une option.

Les limites d’accès comptent plus que d’habitude. Un agent capable de lire l’état du réseau et ne peut pas le modifier représente un risque fondamentalement différent de celui qui peut faire les deux, et cette limite doit être appliquée là où l’action se produit plutôt que décrite dans une invite.

La piste d'audit n'est pas facultative. Lorsqu’un changement est examiné ultérieurement, l’enregistrement de ce qu’un agent a fait, de ce sur quoi il s’est appuyé et de quelle identité il a utilisé est ce qui sépare une explication d’une reconstruction.

Comment commencer

Choisissez la tâche de préparation, pas la tâche de décision. Donnez-lui un propriétaire nommé et un budget qui bloque. Rédigez des critères d'évaluation avant le lancement, en utilisant des incidents réels du dernier trimestre. Puis élargissez-le uniquement lorsque les partitions sont ennuyeuses.

Les équipes qui ont fait cela ont des agents toujours en activité un an plus tard. La plupart des équipes qui ont commencé par le tri ne le font pas.

Suivant

Les pages de télécommunications et de déploiement couvrent les options auto-hébergées et isolées. Les pages du système d'orchestration d'agent couvrent les couches de stratégie, d'audit et d'évaluation dont cela dépend.