Comment Worldline a standardisé sa gestion des incidents IT
Le fournisseur de services de paiement a rationalisé la supervision de ses infrastructures en adoptant l’infrastructure as code et Pagerduty. La plateforme de gestion des réponses à incidents joue le rôle d’ombrelle par-dessus une vingtaine d’outils de supervision.
Premier processeur de paiement européen, Worldline a réalisé 4,6 milliards d’euros de chiffre d’affaires en 2023. Ce fournisseur technologique – aux 18 000 collaborateurs – investit 250 millions d’euros en R&D par an pour propulser les paiements des terminaux physiques et en ligne. Il dessert 1,4 million de clients.
Au vu de la nature du service principal délivré, le traitement de 43 milliards de transactions par an dans 170 pays, « le moindre incident et chaque seconde compte », déclare Julien Scotté, directeur des services partagés et services Cloud chez Worldline.
L’entité dirigée par Julien Scotté fournit diverses briques de services d’infrastructure accessibles par les responsables des différentes plateformes au sein de Worldline. Ces services peuvent être issus des fournisseurs de cloud ou du cloud interne de l’entreprise. Le groupe est aussi un hébergeur de données de santé. Il gère une offre de services à partir de trois data centers certifiés HDS (40 000 serveurs) installés en France.
Du fait de ce périmètre hétéroclite, le SI du groupe – qui a pris de l’ampleur au fil de rachats successifs – est supervisé à l’aide de nombreux outils d’observabilité. Or, Worldline cherchait à obtenir une vue unifiée des événements qui affectent son infrastructure et, finalement, mieux gérer les incidents.
Cette réflexion a débuté chez Ingenico, un spécialiste des prestations de paiement racheté par le groupe français en 2020 pour 7,8 milliards d’euros. En 2022, Worldline a cédé la marque et l’activité terminale de paiement d’Ingenico au fonds américain Appolo Global Management.
Rationaliser l’observabilité et la gestion des incidents
« Nous avons commencé à analyser le marché en 2019 afin de déterminer la manière dont nous pourrions rationaliser nos outils de monitoring », affirme l’ex-responsable de l’infrastructure chez Ingenico.
À l’époque, Ingenico a multiplié les outils open source et propriétaire, dont Grafana, Splunk, Dynatrace, Prometheus, etc.
« Au lieu de les remplacer, nous avons souhaité obtenir une vision agnostique en nous appuyant sur une solution ombrelle qui unifierait les événements, les logs, les métriques, etc. », indique Julien Scotté.
« Au lieu de les remplacer, nous avons souhaité obtenir une vision agnostique en nous appuyant sur une solution ombrelle qui unifierait les événements, les logs, les métriques, etc. ».
Julien ScottéDirecteur des services partagés et services Cloud, Worldline.
Lors de cette étude, le responsable se penche sur différentes solutions, dont OpsGenie (acquis par Atlassian en 2018), VictorOps (devenu Splunk On Call après son rachat en 2018), Grafana On Call ou PagerDuty.
« Nous avons fait le choix de PagerDuty pour sa modernité et surtout pour son habilité à accélérer notre transformation. L’idée était de rationaliser les événements et les outils de monitoring, mais aussi faire évoluer le modèle opérationnel associé en activant une transformation vers une approche DevOps », poursuit Julien Scotté.
En même temps qu’elle voulait unifier sa gestion de la réponse à incidents, l’équipe Ops d’Ingenico s’apprêtait à adopter l’infrastructure as code. HashiCorp Terraform est alors utilisé pour déployer les services sur les différentes machines et installer les sondes/agents des différents outils de supervision dont les événements sont intégrés dans PagerDuty. Plus généralement, il s’agit de bénéficier d’un moyen agnostique de déployer des services d’infrastructure et de les gérer.
L’infrastructure as code, synonyme de standardisation pour Worldline
« Après le rachat par Worldline, nous avons repris cette aventure. Or, en sus de notre cloud interne, nous avions désormais à gérer des déploiements sur le cloud public, principalement GCP et AWS », note Julien Scotté.
Derrière l’idée d’une solution ombrelle, il s’agit également de standardiser le panel d’outils de supervision. « Sans mentir, nous avons une bonne vingtaine d’outils de monitoring divers et variés, mais suivant l’infrastructure cible, privée ou publique, nous avons désormais les mêmes pour tout le monde », précise-t-il.
Par exemple, pour les infrastructures privées, les ingénieurs déploient Prometheus, l’agrégateur de logs Loki, Elasticsearch et Grafana. « Toute la télémétrie remonte dans Grafana qui elle-même est nativement envoyée à PagerDuty. Tout est industrialisé à l’aide de l’Infrastructure as code, que ce soit la définition des sondes, tableaux de bord, etc. Nous avons tout rationalisé ». Sur le cloud public, le choix des armes est un peu plus libre. Il faut dire que chaque fournisseur apporte son lot d’outils de monitoring, comme CloudWatch chez AWS.
Pour autant, la manière dont les événements sont ingérés, dont les événements sont orchestrés sont configurés « as a service ». Par défaut, tous les événements critiques liés aux ressources IT (CPU, RAM, disques, etc.) sont pris en charge et intégrés à une gestion standardisée pour les environnements sandbox, préproduction et production.
« Il ne faut pas être trop permissif, mais il est tout aussi important de ne pas tout verrouiller. L’infrastructure doit être gérée comme un service que les équipes DevOps peuvent utiliser sans s’en préoccuper », recommande le directeur des services partagés chez Worldline.
Par ailleurs, GitLab et PagerDuty sont connectés afin d’identifier les changements de code à la source d’un incident.
La plupart des 2500 ingénieurs et développeurs qui accèdent à PagerDuty chez Worldline n’utilisent même pas l’interface utilisateur au moment de traiter un incident. « Ils n’ont pas besoin de l’utiliser puisque PagerDuty est intégré avec Slack ». Par ailleurs, 700 parties prenantes, dont les product owners, les commerciaux ou les cadres dirigeants ont accès à des vues synthétiques. « Même notre PDG a l’application PagerDuty sur son téléphone. Dans une volonté de transparence, nous essayons de donner cette vue granulaire [de l’état du SI] à tous ceux qui en ont besoin ».
Deux ans pour adopter pleinement l’approche SRE
Cette industrialisation des pratiques SRE et DevOps chez Worldline ne s’est pas faite en un jour. « Un point crucial est d’éviter de permettre à tout le monde de modifier directement les flux dans l’interface PagerDuty », conseille Julien Scotté. « Nous avions donné la possibilité de le faire au début. C’était une erreur, car cela a engendré une incohérence dans notre gestion ».
Ainsi, selon le responsable, les nomenclatures de noms, les dépendances entre les services métiers et les services techniques, les plannings, les politiques d’escalade, et finalement le processus de bout en bout de gestion des incidents doivent être orchestrés de manière standard. En cela, l’IaC est la solution, martèle notre interlocuteur.
« Le temps de construire la brique Terraform et de constituer les équipes, nous avons pris environ 6 mois », évalue le directeur des services partagés.
Une fois que les systèmes sont connectés à PagerDuty, il faut que les algorithmes de l’éditeur « apprennent » le fonctionnement de l’infrastructure à surveiller. « L’expérience sur PagerDuty varie suivant les équipes. Par exemple, un responsable applicatif évoquait le fait que l’adoption de l’outil a pris trois mois », relate Julien Scotté. Les deux premiers mois, ce responsable a subi beaucoup de « bruits ». « Les personnes d’astreinte pouvaient être contactées trois à quatre fois dans la nuit parce que le système apprenait. Cela peut être pénible, mais le modèle d’Event Intelligence est très puissant une fois que cet apprentissage est terminé », note-t-il.
En tout et pour tout, Julien Scotté estime que l’organisation a mis environ deux ans avant d’être véritablement à l’aise avec la solution.
Outre l’infrastructure as code, le directeur des services partagés recommande d’utiliser les services analytiques de PagerDuty. « Il faut utiliser les indicateurs fournis par PagerDuty comme les MTTA (Mean Time To Acknowledge) et les MTTR (Mean Time To Recovery) ». Ces temps moyens de réaction et de résolution donnent une idée des performances des équipes, mais surtout de leur attitude face aux incidents.
« L’idée n’est pas d’adopter une approche punitive, mais plutôt d’insuffler une culture SRE (Site Reliability Engineering) : “you build it, you run it, you own it” ».
Julien ScottéDirecteur des services partagés et des services cloud, Worldline.
« L’idée n’est pas d’adopter une approche punitive, mais plutôt d’insuffler une culture SRE (Site Reliability Engineering) : “you build it, you run it, you own it” », souligne-t-il. « En clair, chaque équipe doit être pleinement responsable de son service de bout en bout. Cette philosophie est au cœur de notre transformation : encourager la maturité, l’autonomie et la responsabilité collective ».
L’IA générative au service de l’IT commence à faire ses preuves
Le directeur des services partagés est donc convaincu par les « forces de l’outil » PagerDuty, c’est-à-dire l’ingestion d’événements et l’orchestration des réponses à incidents. Désormais, le responsable et son équipe se penchent sur les fonctionnalités d’IA. « Nous gagnons un petit peu de temps avec l’explication contextuelle d’incidents qui se reproduisent, mais pour cela il faut que les ingénieurs laissent suffisamment de notes lors des résolutions », prévient-il.
En revanche, la génération automatique de post-mortem est un usage très apprécié chez Worldline. Du fait de l’intégration entre PagerDuty et Slack, il est possible d’obtenir automatiquement la chronologie des événements, des mises à jour de statut en provenance d’Atlassian, le tout lié aux notes prises pendant les interventions.
« En fin d’incident, la fonctionnalité de post-mortem [de PagerDuty Advanced] permet de rassembler toutes les données essentielles : notes, actions, timelines, et même des suggestions d’actions préventives basées sur les anomalies détectées », détaille Julien Scotté. « Par exemple, il m’est arrivé de constater qu’un incident identifié par la stack de monitoring avait généré une alerte qui n’a été reçue que 7 minutes plus tard, à cause d’un paramétrage inapproprié du “noise cancelling” ».
L’annulation de bruit concerne, ici, le travail effectué par les équipes SRE et la plateforme PagerDuty pour réduire les alertes considérées comme inutiles. Or certains événements d’apparence anodine peuvent cacher un incident. Il faut donc se pencher sur des éléments d’habitude ignorés, ce qui peut prendre du temps.
« Le post-mortem de PagerDuty incluait une remarque explicite sur ce point, suggérant des améliorations pour optimiser ce noise cancelling et éviter des délais de résolution similaires à l’avenir », termine-t-il. Le texte généré est donc utile, reste à l’éditeur de lier cela aux tâches et aux événements passés enregistrés dans la plateforme, selon Julien Scotté.
Worldline teste également Slack AI. Ce lot de fonctionnalités d’IA générative fournit notamment un moyen de résumer les conversations dans les canaux et donc de rattraper son retard concernant un incident qui aurait pu se produire. Comme une partie des éléments en provenance de PagerDuty sont partagés sur Slack, il y a un actuellement un chevauchement entre les deux outils. « J’ai pris le parti pris de PagerDuty : Slack AI n’est pas réellement conçu pour contextualiser des incidents, mais peut être utile dans la gestion de projets ».
Slack est également l’outil de prédilection afin de jouer le rôle de foire aux questions sur la gestion des processus et du changement de code. « Nous utilisons des bots pour fournir des réponses succinctes aux questions les plus fréquentes », renseigne le directeur. Il s’agit d’exploiter l’IA générative et une architecture RAG afin d’améliorer ce système.
« Ces bots s’appuieront sur des sources documentaires, comme Confluence ou d’autres bases de connaissances, pour effectuer un premier tri des informations et fournir des réponses initiales », annonce Julien Scotté. « Les équipes SRE, DevOps ou autres interviendront ensuite en second niveau si nécessaire ». Un projet qui réclame de collaborer avec Slack.
En revanche, l’IA générative n’est pas utilisée pour traiter les événements liés aux infrastructures les plus critiques de Worldline.
Pour approfondir sur Administration et supervision du Cloud
