Vers une supervision IT de la performance métier du SI (1/2)

La maintenance des systèmes d’information en production est la tâche la plus coûteuse pour les DSI.

Dans un milieu hétérogène et complexe, la maîtrise du SI est donc un besoin vital pour la DSI mais également un but difficile à atteindre.

L’objectif de cet article en deux parties est de démontrer comment à partir d’une mise en place efficace de la supervision IT on peut construire des services apportant une réelle valeur au SI.

Dans la première partie, nous rappellerons ce qu’est la supervision sous sa forme la plus banalisé et comment l’utiliser pour atteindre un haut niveau de réactivité aux incidents.

Dans la deuxième partie, nous verrons que la supervision est un guide vers une meilleure connaissance de son SI et qu’elle peut aider à valoriser l’apport IT auprès  des directions métiers.

En langage simple, la supervision dans son contexte IT est « la surveillance du bon fonctionnement d’un système (d’information) ou d’une activité (métier) » (source Wikipedia).

Quels enjeux se cachent vraiment derrière la mise en place de la supervision IT ?

Le plus évident et celui qui motive la mise en place de la supervision en premier lieu est le contrat de service liant la DSI à son fournisseur (infogérant, hébergeur).

Le contrat de service fixe un certain nombre d’engagements à minima sur la disponibilité, la performance, le nombre d’incidents et la perte de données maximum acceptée.

Bien souvent ces SLA (service level agreement), DIMA (durée d’indisponibilité maximale acceptée), PDMA (perte de données maximum acceptée) sont fixés avant même la phase de BUILD du projet et ne prennent pas en compte la réalité de l’activité métier du SI ou ne sont pas exprimés suffisamment clairement :

• Plutôt que d'exiger que « les pages de l’application doivent s’afficher en moins de 3 sec », n’est-il pas préférable de demander à ce que « le système soit en mesure d’assurer 3000 consultations de dossiers clients quotidiennement durant la période d’accès transactionnel à la solution CRM du Callcenter »
• Lorsque l’on fixe une PDMA d’une journée, on s’expose à des discussions houleuses par la suite : que représente une journée dans le système (24h?, 8h ?)

En dehors de cet enjeu qui est nécessairement traité de par son caractère contractuel et financier, on trouve des enjeux qui ne sont pas clairement identifiés par les DSI ou qui ne font pas l’objet d’objectif donc d’allocation de budget pour la DSI.

Ils sont pourtant primordiaux car leur but est d’apporter de la valeur aux SI et de promouvoir l’IT auprès des directions générales cassant la vision « centre de coût » qui colle à un grand nombre de DSI.

Le premier de ces enjeux a attrait à la gestion des incidents et l’alerting.

Pour une majorité des SI sur lesquels j’ai travaillé, l’utilisateur final est le premier à détecter l’incident et à remonter une alerte au support utilisateurs. Il s’adresse à ce support, dans le meilleur des cas via l’interface Helpdesk. Commence alors l’investigation et la mobilisation d’experts :

• On n’arrive plus à se connecter à l’application
• J’arrive à me connecter aux serveurs
• Les process applicatif c’est OK
• La CPU et la mémoire c’est OK
• Ma base de données fonctionne bien
• C’est la faute aux développeurs !
• C’est la faute à l’infrastructure !
• Je viens d’aller boire un café avec l’équipe sécurité, le LDAP est tombé…

Bien ! Comment passe-t-on d’un mode réactif gangréné à un mode réactif fluide voir, soyons fous, à un mode proactif ?

Dans l’exemple cité, un outil donnant le statut de l’infrastructure (matériel, OS et process applicatif) dans l’écosystème de mon SI paraît être un bon point de départ. Cet outil n’a pas besoin d’être exhaustif, il est facile d’identifier les SPOF (single point of failure) de la solution qui implique une contrainte forte (pécuniaire donc) pour le métier. On définit alors un chemin critique et on identifie sur celui-ci le matériel (serveurs, réseau, stockage) et les process applicatif qui doivent être opérationnels pour permettre la bonne utilisation de la solution. Si l’un des process ou l’un des serveurs vient à manquer à l’appel, le service métier n’est plus correctement rendu, il faut alors remonter (grâce à des agents de surveillance) une alerte automatique. Si votre LDAP est tombé, vous le savez immédiatement. Lorsque l’utilisateur contact le support, ce dernier a déjà un train d’avance et le bon expert sur le pont. Rapidité, efficience et efficacité.

Et la proactivité dans tout cela ? Dans la solution présentée ci-dessus elle peut se matérialiser par un déclenchement d’alerte sur dépassement de seuil (mon filesystem est rempli à 90% prévoir de l’archivage ou de l’ajout de disques, mes ressources mémoires sont presque épuisées prévoir une réallocation ou l’arrêt/démarrage de certains process, …).

Mais ce mécanisme n’est qu’une première étape dans la mise en place d’une supervision efficace et utile.

Elle permet d’améliorer la gestion d’incident mais elle ne permet pas d’améliorer le système.

Nous verrons dans la deuxième partie de cet article comment utiliser la supervision pour proposer une amélioration continue de la qualité de service et également comment le faire savoir.