Le retour d'expérience du mois
Projet de centralisation des événements : outil interne d’observabilité et de supervision transverseVladimir Kharlamoff, Responsable Supervision à l’AGIRC-ARRCO
Retour
Lors de la Matinale consacrée à l’Observabilité, Vladimir Kharlamoff, Responsable Supervision à l’AGIRC-ARRCO, a présenté le projet de centralisation des événements, basé sur un développement interne. L’AGIRC-ARRCO dispose désormais d’un outil d’observabilité et de supervision transverse, allant de l’infrastructure jusqu’aux processus métier, qui offre des tableaux de bord opérationnels en temps réel, accessibles aux Métiers, comme aux équipes IT.
Pour superviser notre SI « Retraite Complémentaire » qui réunit différents composants techniques et systèmes, nous avons connecté des outils comme un ordonnanceur TWS/IWS d’IBM, des solutions Prometheus qui collectent des données très fines dans le temps, des modules Splunk pour centraliser les logs, sans oublier des sondes Centreon, notre outil historique de monitoring.
Tous ces dispositifs génèrent des événements que nous voulions centraliser pour automatiser la création de tickets dans un outil ITSM. Il y a plus de 9600 gestionnaires qui utilisent nos applications retraite, il nous fallait donc un système d’observabilité performant pour maintenir le tout en condition opérationnelle.
Pour visualiser tout cela, nous avons déployé un portail Grafana qui restitue en temps réel tout ce qui se passe sur le SI. Ce portail est utilisé par les équipes en charge de notre cockpit de supervision, et il est également accessible à toutes les équipes de DSI, le développement, l’intégration, les recettes, jusqu’à la production, sans oublier le DSI lui-même, qui navigue sur notre portail afin de suivre l’avancement des sujets sensibles.
Le module permet également de neutraliser si besoin des alertes, par exemple lorsque nous réalisons des opérations de maintenance ou de montée de version, pour éviter l’envoi d’alertes multiples aux équipes en charge de ces serveurs.
Le module permet également de déclencher des remédiations de façon automatisées en fonction du type d’alerte remontée. Cette interface va piloter les actions de remédiation, et vérifier que l’incident a été résolu.
Les utilisateurs IT ou Métier peuvent suivre la gestion des événements et la gestion des neutralisations. Lorsqu’on voit qu’un incident va avoir des répercussions sur 3 ou 4 applications, on neutralise l’émission d’incidents venant de ces applications pour éviter la profusion de tickets redondants qui seraient envoyés aux équipes d’exploitation.
Nous visualisons également le ressenti utilisateur sur une frise chronologique. En affichant 3 des signaux les plus pertinents que sont les temps de réponse, les taux et volumes d’erreurs http, et les saturations que l’on pourrait subir sur un de nos systèmes OS ou outillage, nous pouvons suivre en temps réel les effets d’un incident, jusqu’à sa résolution, lorsque tout est repassé au vert.
Nous avons amélioré la tenue de nos engagements de qualité de service. Chaque année, nous dépassons notre objectif de 99,8% de disponibilité de nos applications.
Nous avons raccourci notre délai de résolution des problèmes. SI auparavant, nous pouvions passer jusqu’à une heure avant de comprendre d’où venait l’incident, aujourd’hui il ne suffit que de quelques minutes pour identifier l’origine du problème, sans devoir mener de recherche application par application.
Enfin, cet outil a facilité nos échanges avec les Métiers. Ils ont à leur disposition des tableaux de bord fonctionnels. Désormais, tout le monde peut accéder à l’information, la partager, cela a amélioré la collaboration entre équipes métier et équipe IT.
Vladimir, quelle a été la genèse de votre projet de centralisation des événements ?
Il y a 5 ou 6 ans, nous utilisions une solution de monitoring classique, qui allait contrôler l’état de nos éléments d’infrastructure toutes les 5 à 10 minutes. Dans le cadre d’une transformation majeure de notre SI, nous avons souhaité mettre en place des outils capables de surveiller les applications, les processus métier, en temps réel, de façon à ce que les Métiers, mais aussi nos équipes IT, puissent mieux piloter leurs activités.Pour superviser notre SI « Retraite Complémentaire » qui réunit différents composants techniques et systèmes, nous avons connecté des outils comme un ordonnanceur TWS/IWS d’IBM, des solutions Prometheus qui collectent des données très fines dans le temps, des modules Splunk pour centraliser les logs, sans oublier des sondes Centreon, notre outil historique de monitoring.
Tous ces dispositifs génèrent des événements que nous voulions centraliser pour automatiser la création de tickets dans un outil ITSM. Il y a plus de 9600 gestionnaires qui utilisent nos applications retraite, il nous fallait donc un système d’observabilité performant pour maintenir le tout en condition opérationnelle.
Pourquoi avoir choisi de développer une solution en interne ?
Il est exact que nous aurions pu nous appuyer sur des solutions du marché, prêtes à l’emploi. Mais à l’origine, notre besoin était de créer des tickets dans un outil ITSM à partir de événements remontés par tous nos outils existants. Nous avons fait le choix de développer en interne une interface en Python qui permet de transformer un événement en ticket ITSM. Au début, c’était un simple web service qui permettait de réaliser cette opération. Depuis, ce web service a largement évolué en fonctionnalités. Aujourd’hui, notre interface reçoit tous les événements du SI, peu importe la source, il créé des tickets lorsque c’est nécessaire, il enrichit ces tickets à partir d’informations contenues dans la CMDB, qui contient le référentiel de nos serveurs, de nos infrastructures, nos applications, jusqu’à nos processus métier comme le paiement des retraites, ou l’encaissement des cotisations.Pour visualiser tout cela, nous avons déployé un portail Grafana qui restitue en temps réel tout ce qui se passe sur le SI. Ce portail est utilisé par les équipes en charge de notre cockpit de supervision, et il est également accessible à toutes les équipes de DSI, le développement, l’intégration, les recettes, jusqu’à la production, sans oublier le DSI lui-même, qui navigue sur notre portail afin de suivre l’avancement des sujets sensibles.
Quels types d’événements suivez-vous ?
Nos événements proviennent de 5 sources principales :- L’infrastructure, sur laquelle nous suivons le statut de nos serveurs, équipements réseau et baies de stockage, et leur taux d’utilisation afin de détecter et anticiper l’atteinte des seuils de capacité.
- Les systèmes (Linux, Windows, z/OS) ainsi que des logiciels comme les serveurs d’applications ou de base de données, pour qui nous mesurons la performance et le statut.
- Nos applications sur lesquelles nous vérifions leur bon fonctionnement, leur taux d’erreurs et leurs temps de réponse
- Les processus métier
- Le suivi des batchs
Comment fonctionne cette interface de centralisation ?
En allant extraire les données extraites de la CMDB, nous créons des tickets plus pertinents en spécifiant sur quel serveur ou quelle application l’événement a été déclenché.Le module permet également de neutraliser si besoin des alertes, par exemple lorsque nous réalisons des opérations de maintenance ou de montée de version, pour éviter l’envoi d’alertes multiples aux équipes en charge de ces serveurs.
Le module permet également de déclencher des remédiations de façon automatisées en fonction du type d’alerte remontée. Cette interface va piloter les actions de remédiation, et vérifier que l’incident a été résolu.
Les utilisateurs IT ou Métier peuvent suivre la gestion des événements et la gestion des neutralisations. Lorsqu’on voit qu’un incident va avoir des répercussions sur 3 ou 4 applications, on neutralise l’émission d’incidents venant de ces applications pour éviter la profusion de tickets redondants qui seraient envoyés aux équipes d’exploitation.
Comment observez-vous les applications critiques ?
L’outil trace une carte de nos 140 applications utilisées par nos gestionnaires retraite, visualise toutes leurs interconnexions, et affiche leur état de santé respectif par un code couleur. En cas de besoin, on peut zoomer sur une application qui dysfonctionne, pour voir tous les liens qu’elle a avec d’autres applications et donc identifier les éventuels impacts potentiels sur d’autres applications et anticiper un effet domino.Nous visualisons également le ressenti utilisateur sur une frise chronologique. En affichant 3 des signaux les plus pertinents que sont les temps de réponse, les taux et volumes d’erreurs http, et les saturations que l’on pourrait subir sur un de nos systèmes OS ou outillage, nous pouvons suivre en temps réel les effets d’un incident, jusqu’à sa résolution, lorsque tout est repassé au vert.
Quels bénéfices a apporté ce projet d’observabilité ?
Il a transformé la façon de travailler des équipes IT et des métiers. Aujourd’hui nous avons une visualisation en temps réel de tout ce qui se passe sur le SI.Nous avons amélioré la tenue de nos engagements de qualité de service. Chaque année, nous dépassons notre objectif de 99,8% de disponibilité de nos applications.
Nous avons raccourci notre délai de résolution des problèmes. SI auparavant, nous pouvions passer jusqu’à une heure avant de comprendre d’où venait l’incident, aujourd’hui il ne suffit que de quelques minutes pour identifier l’origine du problème, sans devoir mener de recherche application par application.
Enfin, cet outil a facilité nos échanges avec les Métiers. Ils ont à leur disposition des tableaux de bord fonctionnels. Désormais, tout le monde peut accéder à l’information, la partager, cela a amélioré la collaboration entre équipes métier et équipe IT.
Autres articles sur le même thème
Le retour d'expérience du mois
HPC et maîtrise énergétique : challenge réussi chez EDF
Mag #23
Lire l'article
Le retour d'expérience du mois
Modern Management : OPmobility gère ses postes de travail dans le cloud
Anthony Piccolo, Architecte Modern Workplace chez OPmobility
Anthony Piccolo, Architecte Modern Workplace chez OPmobility
Mag #22
Lire l'article
