Copy
Lettre d'information ITIL France n°27 - Janvier 2014

Lettre d'information n°27 - Janvier 2014

Appliquer ITIL en pratique : étude de cas

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

Mise en situation

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.
 

Proposez une problématique concrète à traiter

Vous avez sûrement en interne une problématique concrète et vous vous demandez ce que les bonnes pratiques ITIL conseillent.
Dans ce cas, n'hésitez pas à me contacter par mon site ou par les réseaux sociaux (LinkedIn et Viadeo) pour me soumettre votre problématique.

 

Bonne année 2014

Je vous souhaite mes meilleurs voeux de santé et de prospérité pour cette nouvelle année 2014.
Les pessimistes diront : pourvu qu'elle ne soit pas pire que 2013 et les optimistes diront : de toute façon, elle ne peut pas être pire.
Pour ma part, je dirai que les nouveaux budgets devraient aussi servir à optimiser et à rentabiliser ce qui est déjà en place dans l'entreprise, y compris les bonnes pratiques informatiques.

Dossiers pratiques récents

Deux nouveaux dossiers pratiques ITIL France depuis la dernière lettre d'information en juin 2013 :
- Lier composants techniques et services d’opérations dans la CMDB (oct. 2013)
- Dev-Ops à partir d'ITIL et d’une méthodologie projet (août 2013)

Les projets ITIL interminables

Par méconnaissance des contraintes classiques de projet, les projets ITIL sont souvent interminables jusqu'à ce que le DSI abrègent leurs souffrances en les arrêtant purement et simplement.
C'est dommage car il est toujours possible de les relancer afin de sauver ce qui a déjà été fait et de parvenir à un résultat positif.
Copyright © 2014 Pascal Delbrayelle Consultant, Tous droits réservés.
Email Marketing Powered by Mailchimp