N'oubliez pas le support ! (1ère partie)

Mon, 06 Apr 2009 09:33:45 +0000

En ne préparant pas le support* d’un nouveau service** durant la phase projet, il y a de fortes chances que les équipes de production*** existantes ne soient ni compétentes ni préparées pour assurer le support au moment du lancement !

Et c’est pour ça que des développeurs se retrouvent à supporter une application ad vitam eternam après la fin du projet… alors que tout le monde préfèrerait déléguer cette tâche à une équipe dédiée au support, afin que les développeurs puissent faire ce qu’ils font de mieux : développer :P

La question à se poser est donc la suivante : “que faut-il faire (notamment durant le projet) pour être en mesure de supporter tel ou tel nouveau service quand il sera mis en production ?”

Je vous propose 9 pistes pour ne rien oublier ! Cette semaine, première partie de l’article avec les 4 premiers points :

l’audit et la sécurité de l’information
la planification des ressources
le modèle de support
la récupération de désastre

Audit IT et sécurité de l’information

Il s’agit essentiellement de documenter:

Les régulations éventuelles auxquelles sont soumises le service (Bâle 2 pour les banques, Sarbanes-Oxley pour les boites côtés à NYSE, …)
Le service (sa description, sa criticité pour l’entreprise), le système (l’architecture, les contrats de maintenance), les procédures (par exemple pour la gestion des changements en production)
Les personnes responsables (propriétaire du service, responsables de la production et du support, les signataires du SLA)
Les mesures de sécurité (DRP, continuité, …) et de gestion des accès (niveaux de permissions, approbation des demandes de droit, etc.)
Les audits à prévoir (fréquence, destinataires, etc.)

Comme bien souvent avec les audit, il s’agit de s’assurer que cette documentation existe et qu’elle représente la réalité.

Planification des ressources

Il s’agit d’anticiper :

Les besoins en ressources (matérielles et humaines, en fonction du type de contrat, du profil requis)
Les coûts engendrés (par ces différentes ressources lors des différentes phases avant et après le lancement)

L’objectif est de pouvoir budgéter ces sommes et les faire payer par le client (il faut donc aussi identifier le sponsor côté client).

Modèle de support

Une fois les ressources en place, on pourrait croire qu’il suffit de leur donner des choses à faire pour que tout se passe bien…

En réalité, il faut expliquer à chacun d’où viennent les demandes, ce qu’elles concernent (il n’y a rien de pire que de recevoir une demande dont on ne comprend pas de quoi il s’agit !), ce qui est attendu et à qui on peut faire appel quand on rencontre un problème qu’on ne sait pas résoudre (escalade fonctionnelle).

Ill s’agit donc d’organiser :

Les équipes et leurs rôles (par exemple en structurant les équipes en niveau 1-2-3)
Les types de demandes : les incidents, les demandes d’accès et les demandes d’amélioration ne suivent pas forcément le même parcours ; il faut l’expliciter pour que le niveau 1 oriente correctement les demandes
Les flux de traitement des demandes
Les responsabilités de chaque équipe (par exemple : qui doit rappeler l’utilisateur pour lui confirmer la résolution ? qui doit contacter le fournisseur en cas de problème de maintenance ?)

Sans ça, les demandes arriveront au mauvais endroit au mauvais moment, et les incidents ne seront pas résolus en temps et en heures.

Récupération de désastre

Scénario catastrophe : un avion s’écrase sur le Data Center. En combien de temps est-on capable de remettre en oeuvre le service auprès des utilisateurs ?

Les DRP (Disaster Recovery Plan - Plan de Récupération de Désastre) détaille les étapes à suivre pour remonter les serveurs, le réseau et les applications auprès des utilisateurs à partir de la sauvegarde la plus récente.

Pour arriver à ce résultat, il faut déterminer :

Le risque (scénarios potentiels/risques, impacts business, personnes clés, etc.)
une stratégie de récupération (DR site, Load Balancing, hot standby, etc.) et la valider avec le client
Le coût de la solution choisie, lancer les investissements
Les éléments à intégrer, afin de pouvoir rédiger le plan
Les modalités pour tester le plan de récupération à intervalles réguliers

Notons néanmoins que ce travail sera fait à l’échelle du Data Center, et pas dans le cadre d’un projet pour une seule application. Mais les besoins clients seront revus à chaque projet, et le SLA mis à jour en conséquence.

Fin de la première partie !

La semaine prochaine, la suite de cet article avec les 5 derniers points :

Les SLA/OLA
Les outils
La formation
La gestion des changements en production
La gestion de la connaissance

Glossaire simplifié

* support : le “support informatique” regroupe les équipes et les procédures visant à résoudre les incidents, et qui permettent aux utilisateurs d’obtenir de l’assistance.

** service : dans le contexte ITIL, un service est une fonctionnalité délivrée aux utilisateurs (messagerie, gestion commerciale, etc.) ; d’où l’expression “niveau de service”. Si vous n’êtes pas familier avec ITIL, vous pouvez remplacer le mot “service” par “application” - ça aura du sens dans la plupart des phrases.

*** production : la “production informatique” regroupe toutes les équipes et tous les matériels qui font que les services sont délivrés aux utilisateurs. Ce sont eux qui “font tourner le bouzin” chaque jour.

**** fournisseur de service : le “fournisseur de service” regroupe toutes les équipes informatiques engagées dans la délivrance, le support et la gestion du service pour le client. C’est en quelque sorte la DSI vue d’un point de vue client-fournisseur.