Intégrer les alertes IT dans les processus de Service Management, un vrai plus
accueilinsightsIntégrer les alertes IT dans les processus de Service Management, un vrai plus
expert contentgovernance & service management

Intégrer les alertes IT dans les processus de Service Management, un vrai plus

Interview d’Olivier Hayard, Directeur du Knowledge management, par Blaise Guignard · juin 14, 2022

Retour d’expérience du déploiement du nouveau plugin Dynatrace de Servicenow, lessons learnt d’un projet innovant et primordial.

Avec Olivier Hayard, nous abordons les enjeux et gains de l’intégration de systèmes de monitoring avec une solution de service management. En effet, les systèmes d’information étant de plus en plus monitorés, le nombre d’alertes produites est croissant et donc l’intégration de ces alertes dans un processus de gestion d’incident devient critique pour favoriser un traitement rapide et harmonisé. Un exemple simple, la nuit et le week-end, il est bien que ces alertes puissent être traitées rapidement par les bonnes personnes.

Quelle est la raison de la mise en œuvre du nouveau plugin Dynatrace de ServiceNow ?

Olivier Hayard : Avant tout, il faut préciser qu’un ancien plugin d’alerting, fourni par Dynatrace, était en œuvre chez notre client. Le choix de le remplacer a été dicté par la combinaison du fait que celui-ci utilisait une ancienne version d’API et que, début novembre 2021, ServiceNow a mis à disposition un nouveau plugin, avec la même utilité, mais dans une architecture plus moderne. Pour être précis, il y avait deux nouveaux plugins Dynatrace proposés par ServiceNow :

  • L’un portant sur la synchronisation des configurations d’éléments de configuration
  • L’autre permettant la remontée les alertes

Dans quel contexte s’inscrit cette gestion des alertes IT ?

Olivier Hayard : Il y a 2 ans, un changement majeur est intervenu dans la gestion des opérations IT de notre client, imposant de nombreux changements tant au niveau de l’organisation, des processus, qu’au niveau technique.
Nous menons depuis deux ans un projet de refonte complet des processus ITSM et leur intégration dans ServiceNow : gestion des incidents, des incidents majeurs, des problèmes, des changements et des releases, ainsi que la gestion de la CMDB. La gestion de la demande est également un pan important du périmètre, en lien avec le portail ServiceNow.
En parallèle, dans le cadre de la maitrise de l’infrastructure, la solution Dynatrace a été choisie pour assurer le monitoring et l’alerting. Il est important de noter qu’en complément, certaines technologies ont leur propre système d’alerting,; ce qui, nous le verrons plus loin, a eu un impact sur certains choix réalisés. Le déploiement de Dynatrace concerne donc, dans notre contexte, principalement le parc de serveurs Windows et Linux (plusieurs centaines de machines).

Peux-tu nous expliquer quels étaient les objectifs recherchés par l’intégration de l’alerting ?

Olivier Hayard : Dans une organisation de ce type, le monitoring des systèmes est une évidence naturelle. L’harmonisation par contre ne coule pas de source. Les objectifs étaient de définir les règles permettant de déterminer à partir de quand un service risque d’être dégradé, ainsi que le moment d’intervention d’une équipe de support, idéalement de manière préventive mais aussi de façon réactive quand une alerte remonte une interruption de service.

Ces objectifs portaient sur deux types de monitoring :

  • Monitoring d’applicatifs métier : celui qu’un être humain serait en mesure de faire, par exemple détecter un temps de réponse plus long, une page indisponible ou une erreur de transaction.
    On parle dans ce cas de « Synthetic Monitoring ». On monitore le comportement d’une application, d’un service métier, par exemple une application d’e-banking.
  • Monitoring de serveurs et d’infrastructure : dans ce cas, le monitoring est beaucoup plus fin, grâce au déploiement d’agents sur l’ensemble des serveurs concernés (OneAgent). On peut alors monitorer un grand nombre d’éléments tel qu’un host, un processus sur une machine, un groupe de processus répartis sur plusieurs machines (Tomcat, base de données…) mais également le niveau de mémoire du serveur, les espaces disques disponibles, etc. On comprend bien que le nombre de OneAgent est potentiellement très grand et que le traitement doit donc être fait avec beaucoup de rigueur.

Concernant ces types d’alertes, applicatives et serveurs, des enjeux spécifiques avaient-ils été définis ?

Olivier Hayard : Oui, comme il y a deux plugins avec des fonctionnalités spécifiques, les enjeux le sont eux aussi. J’aimerais en citer 2 :

  1. La corrélation entre la CMDB et les éléments monitorés : l’enjeu est d’avoir le même niveau de granularité entre les composants que l’on monitore dans Dynatrace que les les éléments de configuration (CI) de la CMDB, qui elle est gérée dans ServiceNow. Si on monitore un composant mémoire, il faut que celui-ci soit présent dans la CMDB pour lier l’incident lié à ce CI. Dans notre cas, ces éléments sont corrélés tous les jours.
  2. La création d’incident : dans son cadre, Dynatrace crée des « problèmes » (qui ne correspondent pas au sens donné par ITIL) qu’il faut convertir, en fonction des éléments fournis par Dynatrace et de la paramétrisation, en incidents. L’enjeu est ici de déterminer les bons groupes de support, la priorité et l’urgence adéquates. Spécifiquement la nuit, quand il s’agit de réveiller la bonne équipe ! À l’inverse, on cherchera à ne pas déranger les gens pour de fausses alertes ou de faux positif. Au-delà d’être réveillé à 3h du matin sans bonne raison, l’enjeu est également le même durant la journée avec des pertes potentielles de productivité importantes.

Quand une alerte est remontée, on comprend bien qu’on a très peu de temps pour réagir, donc plus les informations envoyées par Dynatrace sont pertinentes, mieux c’est. Plus les informations et liens documentés dans la CMDB sont pertinents, corrects et complets, plus le groupe de résolution sera adéquat. Et donc, plus la probabilité de résoudre l’alerte avant l’émergence d’un incident est grande (augmentation des interventions préventives). Par exemple si on a une alerte sur un serveur et si ce serveur est membre d’un cluster, cette information est très importante.

L’intelligence consiste donc à déterminer si une alerte doit être remontée sous forme d’incident, car Dynatrace va consolider les alertes et créer ainsi un incident regroupant les alertes liées entre elles. Il est aussi primordial de pouvoir déterminer les impacts métier, les services qui risquent d’être interrompus, le risque de customer facing ou les risques légaux.

En synthèse, une bonne gestion des risques, des impacts et de l’urgence sont les clés d’une implémentation réussie. Ces éléments sont assurés par les liens et les informations de la CMDB de ServiceNow.

Avez-vous utilisé une démarche spécifique et quelle durée et implication faut-il considérer pour mener à bien ce type d’intégration ?

Olivier Hayard : Nous avons opté pour une approche Agile de type Scrum : le paramétrage, et la personnalisation de ces plugins se prêtent particulièrement bien à une gestion agile par lots. Et nous avons retenu une démarche en deux phases, une première dite de préparation et une seconde de réglage :

  1. Phase 1 : Préparation
    Au début tous les problèmes Dynatrace sont remontés pour permettre de paramétrer l’intégration.
    Il faut créer des cas pour valider que les CI (Configuration Item) sont bien corrélés, que les informations fournies sont justes, que les groupes sont correctement déterminés, que les priorités sont correctement calculées (que les bonnes règles sont en place).
    Cette phase a duré 2 mois environ et a impliqué entre 10 et 20 personnes.
  2. Phase 2 : Réglage
    La mise en production s’est faite par groupe et par domaine

    • Côté synthétic : déploiement application par application, de la plus critique à la moins critique. Chaque mois on ajoute un groupe d’applications et le travail se fait avec les équipes applicatives.
    • Côté serveur : déploiement par équipe de support (par domaine). Mise en route équipe par équipe, car l’organisation de support (par exemple piquet, shift, processus) est à définir et mettre en œuvre lors de cette phase 2.

Dans notre cas, pour donner un ordre de grandeur , nous avons environ 20 alertes Dynatrace par heure, ce qui donne, après traitement, 3 à 4 incidents par jour, de tous types d’urgence et d’importance.

Après ces phases de préparation et de réglage, quels ont été les premiers constats ?

Olivier Hayard :

  1. Première constatation, la qualité de la CMDB : sur 100’000 CI, une centaine a dû être corrigée manuellement, ce qui est très peu. En effet, un point très important à mentionner est que l’« Identification Reconciliation Engine – IRE », le moteur de réconciliation des CI, a donné entière satisfaction. De façon résumée, la CMDB a plusieurs sources, dont le plugin de Dynatrace, et tout l’enjeu est de permettre à ServiceNow de déterminer, quand il reçoit des informations de l’une de ces sources, s’il s’agit du même CI ou s’il s’agit d’un CI différent. Et aussi de déterminer quel système a le droit de mettre à jour les données dans la CMDB. Une partie importante du travail a été investie sur cet IRE avec un résultat très probant, une fondation absolument nécessaire au bon déroulement de ce type de projet.
  2. Deuxième constatation : après moins de deux mois, les applications critiques de la banque sont couvertes avec des interventions préventives de plus en plus efficaces. Le temps disponible pour intervenir est plus grand, avec comme conséquence directe une amélioration du traitement de la root cause, soit au sens ITIL de l’investigation et la résolution des problèmes.
  1. La réussite de cette intégration a-t-elle eu des conséquences sur d’autres systèmes d’alertes IT ?

Olivier Hayard : Dynatrace a été le pionnier, le premier système de monitoring à être intégré dans ServiceNow, intégration facilitée par la présence d’un plugin de très bonne qualité. Mais au vu des excellents résultats obtenus, il a été décidé d’interfacer les autres systèmes de monitoring avec ServiceNow. Par exemple Tivoli et certains systèmes de monitoring de sécurité.
Il est devenu une évidence que si j’ai une alerte, au-delà d’un certain seuil, elle doit être remontée dans ServiceNow et être traitée selon les processus de Service Management mis en place (incidents, incidents majeurs, problèmes, changements…)

S’il fallait retenir deux enseignements, quels seraient-ils ?

Olivier Hayard : D’une part, les équipes de support, réticentes à la base, typiquement pour la mise à jour de la CMDB, ont rapidement compris l’intérêt et les bénéfices que cela représentait. Alors que la mise à jour de la CMDB était vue initialement comme une tâche administrative contraignante, sa valeur est désormais mieux perçue.

D’autre part, une autre bonne pratique est confirmée par ce projet, à savoir le fait de traiter l’Event Mangement dans les outils de monitoring respectifs. Ce choix est important et il doit être fait sans ambiguïté. La gestion des évènements doit se faire soit dans les outils de Service Management, soit dans les outils de monitoring, mais elle doit être faite !

plus d'insights

5 pratiques pour réussir un projet de gestion de contenus informationnels


expert contentgovernance & service management

juin 14, 2022

Discovering the world of RPA


expert contentquality assurance & testing

juin 07, 2022

Les enseignements d’un projet de gestion de contenus informationnels en échec


expert contentgovernance & service management

mai 17, 2022

contactez-nous