L’intelligence artificielle qui surveille nos applications critiques

automatisation-production

Chez EXTERN-IT nous avons mis en service une intelligence artificielle pour surveiller nos applications critiques en production. A partir des traces inscrites dans les journaux par un ensemble de serveurs, l’IA est capable de détecter des comportements anormaux et de révéler un dysfonctionnement ou une faille avant qu’ils ne puissent devenir trop graves ou complexes à corriger.

 

L’IA a été alimentée avec une année de données de l’un des progiciels de gestion que nous hébergeons.  Après son entraînement elle s’est avérée capable de repérer des dysfonctionnements réels et simulés et d’autres comportements inattendus, comme le redémarrage intempestif d’un service.

Pour être efficace, l’IA a besoin d’une base de données qui contient tous les logs et les journaux de tous les services. C’est une collecte longue qui doit être purgée des comportements anormaux déjà constaté sur la période concernée.  C’est sur cette base que le modèle apprend à reconnaître le comportement normal de l’application.

 

Lorsqu’un comportement anormal est identifié, l’IA alerte le service support sur un canal Teams avec le contenu qu’elle a identifié. Le service support peut alors analyser cette alerte. Si un défaut est identifié, sa détection précoce permet de minimiser les impacts. Ils sont traités avec un maximum de proactivité, avant même que l’utilisateur final n’en ait pris conscience.

detection-anomalie-ia

Ici par exemple, elle nous remonte un problème de dépendance qui traduit un redémarrage intempestif du système

En un mois de fonctionnement, le modèle a levé trois alertes, toutes pertinentes. Il nous a par exemple permis d’identifier et de résoudre rapidement une situation impactant la bonne diffusion des courriels depuis nos serveurs.

 

Mais le modèle d’intelligence artificielle ne doit pas rester figé, il doit pouvoir évoluer en même temps que les applications. Par exemple, lorsque l’IA remonte un comportement qui lui parait anormal, celui-ci peut, en réalité, être lié à une mise à jour récente de la solution. Dans ce cas, il est possible de lui indiquer que cette situation doit être considérée comme normale. Le modèle peut alors être ajusté rapidement pour neutraliser l’alerte.

D’autres routines ré-intégreront par la suite ce comportement dans le jeu de données qui permettra d’entrainer un nouveau modèle adapté à la nouvelle version de l’application.

 

Nous obtenons un modèle très flexible car il peut s’adapter à toute extension du périmètre ou même à des applications différentes.  Il pourrait aussi être appliqué à un contexte différent : flux inter-applicatif, trafic réseau, et d’autres traces collectées en volume.

*Article rédigé avec l’aide bienveillante de GPT-J, modèle de langage génératif.