Saint-Gobain fiabilise ses applications critiques

Le groupe industriel a mis en place une solution d’APM (Application Performance Management). Objectif : surveiller la performance applicative de bout en bout. Selon Gartner, « les applications doivent devenir la fenêtre à travers laquelle on observe la performance des infrastructures. » D’où l’intérêt de mettre en place des solutions de mesure de cette performance.

Le GIE DSI Groupe, formé pour définir la stratégie informatique du groupe Saint-Gobain, spécialisé dans les matériaux et produits pour la construction (isolation, mortiers industriels, vitrages, céramiques, etc.), a mis en œuvre une solution d’APM (Dynatrace) pour améliorer les temps de réponse et les performances de ses applications critiques.

Objectifs pour les équipes de la DSI : disposer d’une vue de bout en bout des transactions à travers l’ensemble de leurs chaînes applicatives, mais aussi mesurer l’impact de leurs infrastructures sur les performances. « Notre plateforme de mutualisation d’applications métiers souffrait de problèmes de performance », se souvient Matthias Bourillon, responsable de la cellule d’administration technique du département Solutions Digitales chez Saint-Gobain, appartenant au GIE.

Ce département a pour mission de développer et de mettre à disposition des 193 000 salariés du groupe des solutions leur permettant de mieux communiquer et de mieux collaborer, en particulier un portail Intranet, des outils de gestion électronique de documents (GED), des plateformes collaboratives, un annuaire de groupe, un moteur de recherche et des applications métiers spécifiques…

Au total, près d’une centaine d’applications sont proposées aux salariés. « Notre entité gère une trentaine d’applications sur une plateforme mutualisée, 30 % étant des applications métiers, 70 % des applications transverses. L’une des difficultés, à l’origine des problèmes de performance, réside dans le vieillissement de la plateforme sous un JBoss d’ancienne génération, de moins en moins documentée. Il faut pourtant garantir la disponibilité des services et les performances dans des environnements de production qui sont complexes », précise Matthias Bourillon, qui souhaitait pouvoir tracer l’ensemble des requêtes utilisateurs, à travers des chaînes applicatives complexes (jusqu’à trois ou quatre back-ends) et disposer de données tangibles, pour anticiper les montées en charge et prévenir les incidents.


Qu’est-ce que l’APM ?

L’application performance monitoring (APM) est définie, selon Gartner, comme un processus qui comporte cinq caractéristiques :

  • Suivre, en temps réel, l’exécution du code logiciel qui compose une application.
  • Mesurer et assurer le reporting des ressources matérielles et logicielles.
  • Déterminer si une application s’exécute de la manière attendue par les utilisateurs.
  • Mesurer les temps de réponse.
  • Déterminer pourquoi une application ne s’est pas exécutée avec succès, ou pourquoi une ressource consommée a des temps de réponse inadaptés.

Compte tenu de l’étendue du parc applicatif, les risques de baisse de performances ou de dysfonctionnements sont en effet nombreux. « Des utilisateurs nous remontaient des incidents que nous ne parvenions pas toujours à reproduire et à diagnostiquer, mais il faut aller au cœur du serveur d’application pour comprendre les problèmes de performance, ce qui est quasiment impossible sans un outil d’APM », explique Matthias Bourillon.

Concrètement, un agent est installé sur le serveur d’application, avec des paramètres ajustés, et les informations sur les métriques sont envoyées au serveur Dynatrace, avec un tableau de bord pour chaque système critique. « Quand une application utilise des Web services et interroge des bases de données, cela nous permet d’identifier les composants qui posent problème. C’est évidemment un gain de temps », constate Matthias Bourillon.

Ce gain de temps se traduit, par exemple, par le fait que les équipes de la DSI, en se basant sur les informations fournies directement sur la console Dynatrace, s’évitent la pénible « élimination par itérations successives » pour identifier la cause des incidents. « Consulter les logs de l’ensemble des back-ends à la recherche de l’origine d’un ralentissement constituait une tâche titanesque, chronophage et parfois vaine, précise Matthias Bourillon, désormais, nous réussissons, en seulement quelques minutes, à identifier la cause d’incidents latents. »

Au départ, Saint Gobain s’est concentré sur l’analyse des temps de réponse pour les transactions vers les utilisateurs. « Nous avons ensuite élargi le périmètre à la consommation de CPU, de mémoire et d’espace disque. On peut ainsi déterminer des seuils d’alerte et surveiller le dimensionnement des infrastructures. C’est notamment utile pour identifier les lignes de code éventuellement responsables des problèmes de performance et cela facilite la communication entre les équipes d’exploitation et celles en charge des développements », détaille Matthias Bourillon.

Cela améliore également la communication entre les différentes équipes qui suivent le cycle de vie d’une application, grâce, notamment, aux fichiers de session, afin de partager l’ensemble des données relatives à un problème pour en faciliter l’analyse. « Nous disposons désormais de métriques et de tableaux de bord qui nous permettent, par exemple, d’optimiser le dimensionnement de nos serveurs, pour mieux anticiper les montées en charge, ou encore de remonter des anomalies de configuration, via des diagrammes de visualisation des flux de données en temps réel », poursuit Matthias Bourillon, qui envisage d’étendre le périmètre de la solution Dynatrace aux environnements de développement et de tests.


Six raisons pour s’équiper d’une solution d’APM

  1. Contrôler en temps réel l’état de santé du SI et de toutes ses composantes (réseaux, serveurs, bases de données, services Web, applications…).
  2. Être plus réactif en cas d’incident et anticiper les dysfonctionnements (être alerté en temps réel, identifier rapidement l’origine des dysfonctionnements, réduire les temps d’indisponibilité…).
  3. Rationaliser l’exploitation des infrastructures IT (automatisation de la surveillance du SI).
  4. Contrôler les processus de l’entreprise numérique qui impactent les métiers.
  5. Améliorer la qualité (satisfaire les utilisateurs et les clients).
  6. Aller au-delà des indicateurs de disponibilité.

 

Les trois angles de la santé applicative d’un SI
Domaine d’analyse Comment faire ? Exemples d’indicateurs
disponibilité
  • Mesurer le taux de disponibilité de l’application, pour une période donnée, en fonction des horaires d’ouverture de l’application et en s’appuyant sur des méta-indicateurs
  • Graphe de disponibilité (dans le temps)
  • Durées de disponibilité / indisponibilité
La performance
  • Identifier les composants considérés comme critiques ou représentatifs de la performance de l’application
  • Déterminer une performance nominale attendue, par composants
  • Mesurer les temps de réponse et la performance de chaque composant, pondérée par un coefficient
  • Graphe historique de performance
  • Taux de service : part du temps où l’application délivre la performance attendue
Les risques
  • Mesurer le risque pesant sur l’application en s’appuyant sur le nombre d’incidents constatés
  • Nombre d’incidents
  • Courbe de tendance

Notre avis

A l’heure du « tout connecté », où de plus en plus de services sont accessibles en permanence depuis le Web ou les mobiles, la moindre défaillance d’un composant peut être lourde de conséquences et se traduire par une perte de chiffre d’affaires ou des pénalités à verser aux clients. Les entreprises sont en effet de plus en plus dépendantes de leurs systèmes d’information. L’étude annuelle réalisée par le Clusif (Club de la sécurité de l’information français) révèle que 81 % des DSI et RSSI (responsables sécurité des SI) considèrent que la dépendance de leur organisation, à l’égard des systèmes d’information, est forte et jugent « lourde de conséquences une indisponibilité de moins de 24 heures de leurs outils informatiques ». Ce degré de dépendance a d’ailleurs augmenté de façon significative, il n’était « que » de 55 % au début des années 2000. Un autre enseignement important des études menées par le Clusif est que l’essentiel des risques ne provient pas, comme on pourrait le croire, à l’image de leur médiatisation, d’actes de malveillance ou de piratage, mais de problèmes matériels. Ainsi, la vulnérabilité des entreprises est bien davantage liée aux erreurs d’utilisation, à des pertes de services essentiels (énergie) ou à des pannes d’origine interne.

Si le besoin d’implémenter une solution d’APM paraît logique, l’efficacité du déploiement est conditionnée à quatre éléments :

  • La supervision monitoring doit être centrée sur les applications, avec une priorité sur la mesure de l’expérience utilisateur.
  • L’idée selon laquelle un système mesure les événements dans une infrastructure est relativement de manière statique doit être remplacée par l’idée selon laquelle le monitoring doit relier, de manière dynamique et en temps réel, les événements entre eux, y compris avec le recours à des analyses probabilistes.
  • Il convient d’aller au-delà d’une mesure de la performance reposant sur des événements prédéfinis pour des observations de manière continue, afin d’analyser le comportement d’un système.
  • La séparation entre le monde du développement d’applications et celui des opérations doit être remise en cause, par exemple avec une approche de type DevOps. Ainsi, les données collectées peuvent être très utiles aux développeurs et à ceux qui testent les applications, à travers une communauté d’expertise.