Accueil

ITIL®

Lean IT

Pratique

Plus

Crédit image : Pascal Delbrayelle

L'accès à l'environnement de production par l'équipe de développement dans le support de niveau 2 ou 3 des incidents

Publié le janvier 2014 par Pascal Delbrayelle

Dans le cadre de la gestion des incidents, une équipe de développement applicatif se connecte sur les bases de données de production pour établir un diagnostic au niveau 2 ou 3. Cet accès à l'environnement de production n'est pas très bien vécu des équipes d'exploitation.

Que propose ITIL® dans ce cas concret ?

La gestion des incidents : respect des objectifs

L’objectif principal du processus de gestion des incidents est de « rétablir le fonctionnement normal d’un service le plus rapidement possible ». L’un des moyens d'y parvenir est de tout faire pour que le maximum d’incidents soient traités au niveau 1 et ce, pour le diagnostic et la résolution.

Le centre de services, au niveau 1, doit pouvoir disposer d’une base d’informations la plus riche possible et de pouvoir retrouver facilement de l’information.

Si, pour une raison ou pour une autre, il faut escalader le diagnostic aux niveaux 2 et 3 (pas d’information utile identifiée, dépassement d’un délai, complexité de l’incident, etc.), cela va impliquer d’autres équipes qui vont devoir tout faire pour diagnostiquer rapidement. Cela inclut des moyens d’accès à l’environnement de production pour examiner un certain nombre de choses. Nous ne sommes plus dans la « simple » lecture de documents ou de fiches mais il faut bel et bien intervenir pour examiner les faits, et rapidement.

Donc, le bon fonctionnement du processus de gestion des incidents implique l’accès complet aux équipes de support à toutes les ressources nécessaires à l’établissement du diagnostic et à la résolution.

L'exploitation des services : respect des objectifs

Cependant, dans le cas d’une équipe de support qui est une équipe de développement, cela entre en conflit avec les objectifs d’autres processus ITIL®, notamment celui de la phase d’exploitation des services. L’un des objectifs est de faire fonctionner au quotidien l’environnement de production et de garantir la stabilité de la production et les niveaux de service convenus avec les organisations d'affaires. Or, l’environnement de production doit être uniquement géré par les équipes de production et il n’est pas question qu’une personne n'appartenant pas à ces équipes intervienne directement sur la production au risque de déclencher des dysfonctionnements.

En effet, si on donne la responsabilité à une équipe de garantir le bon fonctionnement de l’environnement de production, il faut en même temps leur donner la gestion et l’accès exclusif à cet environnement de production.

Concilier les deux

Dans ce cas, il faut concilier les deux en définissant des procédures très strictes d’accès à l’environnement de production par une personne extérieure. Voici quelques points à traiter dans cette optique :

  • utilisation de comptes et de mots de passe activés uniquement pour un accès ponctuel (traitement d’un incident par ex.)

  • accompagnement (ou présence) d’une personne de la production au côté de l’intervenant extérieur (ou tout au moins pouvoir tracer l’intervention, surtout en cas de modification et tenir informé la personne de la production)

  • s’engager sur la notion de respect de données confidentielles contenues dans les bases des données

  • établir petit à petit une relation de confiance entre les équipes de production et l'équipe de développement

Pour résumer, l’efficacité du processus de gestion des incidents nécessite l’accès aux données de production mais cela doit être fait en respectant des contraintes très strictes, notamment pour garantir la stabilité des environnements de production et la sécurité des données.

Le non respect de ces contraintes peut entraîner des réactions extrêmes comme interdire l’accès aux bases de production à l’équipe de développement. C’est sûr que, dans ce cas, l'équipe d'exploitation résout d’un coup tous les problèmes de stabilité et de sécurité liés aux interventions de l'équipe de développement mais cela se fait au détriment d’autres activités nécessaires au bon fonctionnement de l’ensemble.

Définir et utiliser un modèle d'incident

ITIL® prévoit le traitement particulier de certains types d’incidents (modèle d’incident). Dans le cas du traitement d’un incident qui semble lié à une erreur dans du code, on peut appliquer une procédure prédéfinie (c’est le modèle d’incident) incluant l’ouverture d’un droit d’accès aux bases de production déclenchée en même temps que le ticket est escaladé à l'équipe de développement. Ce droit d’accès doit ensuite être fermé à la clôture du ticket d’incident. Cette procédure prévoit aussi les conditions d’utilisation de ce droit d’accès par l'équipe de développement et le contrôle des équipes d'exploitation du respect de ces règles.

Cette procédure et son application stricte permettent de respecter les objectifs des autres processus ITIL® tout en conservant l’efficacité nécessaire pour traiter les incidents.