Automatisez la résolution de tickets avec la GenAI

Automatisez la résolution de tickets avec la GenAI

Vive la GenAI !

Maintenant qu’on sait qu’elle est en train de transformer le métier der DevOps, et qu’il est possible de réaliser des revues de code d’une merge request, je vous propose cette semaine un nouveau cas d’usage.

Le quotidien d’un centre de services

Chez Skale-5, nous avons trois métiers :

  • La délégation de personnel.
  • Le build / migration d’infrastructures.
  • Le RUN.

Cette dernière activité possède un véritable centre de services, permettant à nos clients et nos DevOps d’échanger autour des activités qui sont récurrentes dans le cadre de l’infogérance 24/7 d’une plateforme.

  • Incidents.
  • Demandes de travaux (évolutions, améliorations, features…).
  • Demandes diverses.

Afin que SKALE-5 soit en mesure de fournir une qualité de service irréprochable à ses clients, certaines KPIs sont mesurées : nombre de tickets ouverts, temps moyen de résolution…

Le cycle de vie d’un ticket

Lorsqu’un acteur (client ou skaler) rédige un ticket, il lui confère :

  • Un titre.
  • Une description.

Le ticket est ensuite assigné à un membre de l’équipe qui va se charger de la qualifier : ajout de labels, d’estimation de charge de travail, commentaires additionnels, interaction avec le client…

Lorsque le ticket est qualifié, il sera ensuite réalisé.

Comment la GenAI peut améliorer les KPIs de mon centre de service ?

… En confiant à un LLM la réalisation de certains tickets… 🙂

Vous êtes prêts ? C’est parti !

Ceci est un exemple de ticket
Ceci est un exemple de ticket

Ci-dessus, un exemple de ticket que nous qualifierons de “grunt work” (désolé pour l’expression) :

  • Le client fait une demande que l’on rencontre tout à fait traditionnellement dans le monde de l’operate : augmenter les capacités d’une machine (ici, étendre un disque).
  • Un membre de l’équipe Operate doit se l’assigner, puis le réaliser. Pour ce faire, il va devoir :
    • Lire et comprendre le ticket.
    • Récupérer la dernière version du repository de code d’infrastructure.
    • Naviguer jusque dans les dossiers / fichiers concernés par la demande.
    • Ouvrir les fichiers concernés dans son IDE.
    • Modifiez-la ou les lignes concernées.
    • Faire un commit / pousser dans une branche temporaire.
    • Créer une merge request (qui sera potentiellement relue par un pair).
    • La merger, vérifier les pipelines de déploiement.
    • Updater le ticket.

Ça fait beaucoup de travail pour finalement étendre un disque, n’est-ce pas ?

Le terme Grunt Work est (IMHO) plutôt bien choisi, car personne n’a envie de faire ça toute la journée.

… Et ce genre de demande constitue plus de la moitié des tickets traîtés par notre centre de service.

Que se passerait-il si nous pouvions avoir automatiquement une Merge Request pour ce genre de ticket ?

Mais… Mais… Qu’est-ce que cette magie noire ?!
Mais… Mais… Qu’est-ce que cette magie noire ?!

Abracadra… Alakazam.. Zim.. Zoum !

image

Ceci est une merge request automatiquement postée par notre DevOpsBot.

Notre opérateur (de chair et d’os) n’a plus qu’à accepter (ou non) la solution proposée par l’agent virtuel.

Si la solution proposée convient → L’humain n’a plus qu’à merger et mettre à jour le ticket (le fermer).

Si la solution proposée ne convient pas → L’humain peut choisir de la compléter (repartir de la branche poussée automatiquement par DevOpsBot), ou de l’ignorer et proposer lui-même une solution.

Et ça marche avec tout ce qui relève de la simple demande !

un autre exemple de ticket
un autre exemple de ticket
un autre exemple de merge request poussée par la GenAI
un autre exemple de merge request poussée par la GenAI

Comment ça marche ?

Beaucoup d’orchestration.

Pour que notre agent virtuel puisse proposer une solution, il lui faut :

  • Le contenu du ticket (titre, description, meta-données).
  • Le repository d’infrastructure.
  • Un environnement dans lequel travailler.
  • Un ami de l’autre côté du miroir pour agir à sa place dans le monde réel (créer une MR, mettre à jour le ticket…).

Nous avons déjà automatisé cet orchestrateur et toutes les étapes du workflow. Pour avoir accès à notre “secret sauce” pas si secrète, n’hésitez pas à prendre contact avec nous et à demander une démo.

D’après nos benchmarks, le taux de réussite est proche de 100% pour les tickets les plus simples (changements monolignes).

Naturellement, plus le ticket est riche en détails, plus l’agent virtuel a des chances de proposer la solution du premier coup.

Conclusion

Grâce à la GenAI, nous pouvons désormais :

  • Systématiser (et à moindre coût) la proposition de solutions en face de chaque ticket 💡.
  • Laisser le libre arbitre à l’homme d’accepter une solution élaborée par l’agent virtuel 💪.
  • Gagner du temps de résolution non négligeable, et donc améliorer nos KPIs 🏆.
  • Rendre plus zen nos collaborateurs, car ils n’ont plus qu’à supplémenter la machine en réalisant seulement les tâches les plus complexes 🧘‍♂️.
  • Rendre plus autonomes nos clients sur certaines demandes, qui ne sont plus en attente du centre de service 🤝.

Je vous l’avais dit. Vive la GenAI ! 🎉

💡
Si ces use cases vous intéressent, programmez une démo !

Le virage de la GenAI est déjà entamé, et nous pouvons les déployer chez vous.

Merci pour votre lecture. Cet article vous a plu, partagez sur vos réseaux 😉

Hugo Claria - Le 26 mars 2024

image