Journées Informatiques IN2P3/IRFU
28 Septembre au 2 Octobre 2008 à Obernai
Table Ronde : Les bonnes pratiques de gestion d'infrastructures et de production du logiciel.
Jean-Michel Barbet (SUBATECH)
Eric Legay (CSNSM)
Françoise Virieux (APC)

Synthèse de l'enquête “Bonnes Pratiques ASR”

Introduction

L'enquête « Bonnes Pratiques ASR » vise à étudier les méthodes de travail et les pratiques des Administrateurs des Systèmes et des Réseaux (ASR) au sein des laboratoires de l'IN2P3 et au Centre de Calcul. Il s'agit de recenser les bonnes pratiques des ASRs afin de les mettre en commun et en discuter lors de la session intitulée « Les bonnes pratiques de gestion d'infrastructures et de production de logiciel » dans le cadre des prochaines Journées Informatiques IN2P3/IRFU d'Obernai.

Cette enquête a été réalisée entre Juillet et Septembre 2008 auprès des responsables des services informatiques. Elle s'appuie sur un questionnaire mis en ligne sur un site Web en utilisant une application dédiée et sur l'interview au téléphone des personnes ayant rempli le questionnaire en ligne. Le but de l'interview est multiple : préciser les réponses peu claires ou incomplètes, recueillir la vision des responsables de services concernant les bonnes pratiques pour l'ASR et les éléments qui permettent d'améliorer le service pour les utilisateurs ou d'optimiser le fonctionnement du service.

Au total, 21 unités y compris le Centre de Calcul ont été sollicitées et toutes ont rempli le questionnaire en ligne. 16 interview ont été conduites auprès des personnes ayant répondu au questionnaire (certains chefs de service ont délégué quelqu'un pour le faire). La durée d'une interview a été de l'ordre de 30 minutes environ, parfois plus.

Le Questionnaire

Le questionnaire a été établi sur la base des idées des personnes qui ont mené l'enquête. De ce fait les questions sont basées sur leur vision et leur expérience du métier d'ASR mais les interviews ont permis de sortir du cadre quand c'était nécessaire.

Le questionnaire a été organisé en six blocs de questions permettant d'aborder :

les méthodes pour prendre connaissance des besoins des utilisateurs

les outils pour gérer le parc et les éléments du système d'information

la documentation du travail et la communication au sein du groupe d'ASRs

la documentation destinée aux utilisateurs et la communication entre ASRs et utilisateurs

la gestion des demandes des utilisateurs

Les dispositifs de surveillance et d'alerte

On trouvera en annexe 1 le questionnaire complet.

Les résultats

Le format libre des réponses dans le questionnaire rend difficile une analyse automatique. Ainsi, ce sont principalement les notes prises pendant les interviews qui font l'objet de cette synthèse. Pour chaque section du questionnaire, nous listons les pratiques rencontrées et les outils employés, puis les problèmes rencontrés par nos collègues et leur remarques.

La section intitulée « Les ingrédients de la qualité vus par les ASRs » à la fin de ce document est une compilation des réponses à la question rituelle qui clôturait l'interview. Les réponses sont fournies quasiment brutes telles que nous les avons recueillies et nous n'avons pas cherché à les classer par ordre d'importance ou de priorité.

La synthèse des réponses

1 - Prendre connaissance des besoins des utilisateurs

Ce qui est fait :

La manière dont les besoins et demandes des utilisateurs parviennent au service informatique vont de la discussion de couloir ou de cafétéria à l'organisation de réunions périodiques dédiées. Les demandes parviennent également au service par message électronique ou bien via l'outil de gestion des demandes quand il existe. Certains utilisateurs préfèrent se déplacer pour rencontrer les ASRs. Par ailleurs, des besoins qui relèvent de l'informatique sont parfois exprimés lors de réunions plus générales au sein du laboratoire (conseil de laboratoire, conseil des chefs de groupes,...).

Dans près de la moitié des unités, il existe une instance nommée selon les cas “comité des utilisateurs” ou “conseil informatique” composée de représentants des équipes de recherche et des services techniques, parfois de certains groupes comme les thésards et de tout ou partie du service informatique. Le conseil informatique ou comité des utilisateurs se réunit une ou plusieurs fois par an. D'autres unités s'appuient sur des “correspondants informatiques” dans les équipes de recherche et les services techniques.

On trouve également des réunions ouvertes à tous les utilisateurs de type “Assemblée Générale” dédiées à l'informatique.

Dans toutes les unités à l'exception peut-être du CCIN2P3, la majorité des demandes des utilisateurs, du moins les demandes modestes, sont exprimées en direct, par téléphone ou par mail. Certains services informatiques mettent à la disposition des utilisateurs un formulaire web pour exprimer leurs demandes.

Remarques :

S'appuyer sur les demandes exprimées par les utilisateurs ne suffit pas toujours à améliorer le service ou la sécurité. Grâce à la veille technologique, le service informatique est mieux à même de prendre des initiatives et proposer des améliorations. Il est important que le service informatique joue ce rôle.

Il existe une relation étroite entre la qualité du service ASR et la sécurité informatique : sécurité des données, disponibilité des services.

Il est important d'être capable de répondre aux demandes des utilisateurs. Si le service informatique ne le fait pas, les utilisateurs « se débrouillent » et cela aboutit fréquemment à des entorses à la sécurité ou à une perte de contrôle du service informatique sur une partie du système d'information.

Au CC, le recueil des besoins est évidemment plus complet et plus formalisé. Il s'appuie essentiellement sur les réunions avec les expériences et les demandes via support.

Les besoins importants en calcul et en stockage sont progressivement transférés vers la grille et il ne reste que des demandes moins coûteuses ou plus modestes (postes de travail)

Les demandes importantes ou significatives devraient faire l'objet d'un document écrit ou d'un cahier des charges mais il est difficile d'obtenir un document écrit. Une façon de faire consiste à prendre le temps de rédiger la demande avec les demandeurs. Les projets de participation à la grille ont en majorité été discutés au niveau du laboratoire et ont fait l'objet de documents écrits. Il est important de garder des traces écrites des demandes des utilisateurs. A cet égard, le recueil par mail ou via le système de suivi des demandes présente des avantages.

La qualité des échanges entre les utilisateurs et les ASRs est très différente selon qu'il s'agit d'une réunion faisant intervenir les membres d'un comité ou des représentants motivés ou bien qu'il s'agit d'une réunion de type AG avec tous les utilisateurs. Les réunions avec l'ensemble des utilisateurs pratiquées par six unités sont progressivement abandonnées vu les problèmes posés (voir ci-dessous).

Les négociations concernant les projets d'une certaine taille peuvent se dérouler durant les séances du conseil informatique quand il existe. La validation des projets importants ou des demandes significatives relève en général du conseil de laboratoire. Les choix techniques sont le plus souvent laissés au service informatique, mais cette question n'était pas explicitement posée au niveau du questionnaire.

Problèmes rencontrés :

Les réunions de type AG avec l'ensemble des utilisateurs sont souvent peu suivies et les utilisateurs tendent à exprimer des besoins immédiats ou des problèmes mineurs au détriment d'une réflexion prospective sur les évolutions des besoins. On peut rencontrer aussi une certaine passivité des utilisateurs qui attendent les propositions du service informatique. De plus, les personnes qui assistent à ce type de réunion ne sont en général pas celles qui ont des problèmes.

Les réunions de comités d'utilisateurs qui ne sont pas imposées par la direction mais sont à l'initiative de quelques personnes peuvent s'espacer et disparaître si ces personnes perdent leur motivation à organiser ces réunions.

Lorsque le budget n'est pas disponible au moment du recueil des demandes, il faut parfois se livrer à une ré-estimation des coûts qui nécessite de consacrer beaucoup de temps.

Lorsqu'il y a des reliquats de budget en fin d'année, les dépenses de dernière minute sont très souvent des achats informatiques non prévus à l'origine et l'urgence qu'il y a à passer les commandes oblitère l'étude et la négociation. Ceci est particulièrement fréquent lorsqu'il s'agit de crédits non gérés par le service informatique. Au final, des solutions matérielles ou logicielles sont imposées aux ASRs et se révèlent parfois en opposition avec la stratégie du service informatique.

2 - Gérer le parc et les éléments du système d'information

Ce qui est fait :

Dans leur majorité, les unités disposent d'un outil ou de méthodes pour gérer les principaux éléments du système d'information. Les outils employés vont d'un ensemble de fiches dans un tableur jusqu'à une application basée sur un SGBDR.

Les principaux éléments gérés sont (par ordre décroissant de fréquence) : les serveurs, les postes de travail, les portables, les périphériques (imprimantes, scanners, etc.), les logiciels soumis à licence, les adresses réseaux, les utilisateurs, les consommables, les prises réseau, les adresses Ethernet, les comptes informatiques, les commandes, les contrats et garanties.

Les applications « maison » développées sur un SGBDR ou un progiciel sont relativement nombreuses puisque 10 unités ont déclaré utiliser ce type de solution. Le logiciel GLPI est en forte progression, utilisé ou en test dans 5 unités. Les documents de type tableur accessibles à tous les ASRs représentent également une proportion significative des solutions de gestion des actifs (6 unités). Enfin deux unités ont co-développé une solution nommée GASPER.

Vue la difficulté de tenir à jour les informations, l'intérêt des outils d'inventaire automatique, n'échappe à personne. L'un de ces outils est devenu très populaire et utilisé par près de la moitié des sites. Il s'agit de OCS-Inventory.

Remarques :

Pour être intéressant, un outil d'inventaire automatique doit être compatible avec le maximum de plateformes présentes au sein de l'unité.

On note également l'importance du bon contact avec le service financier pour les commandes et l'inventaire.

Dans un certain nombre d'unités, les adresses Ethernet (MAC) sont enregistrées dans le but d'engendrer automatiquement le fichier DHCP ou de servir de base à des méthodes de contrôle d'accès (VMPS par exemple) ou d'autentification (Radius).

Le suivi des comptes est un souci pour certains, d'autres le gèrent avec des applications maison et intègrent des alarmes pour les comptes expirés. Suivant le nombre de comptes à ouvrir et à fermer chaque année et le temps consacré à cette tâche, il peut être intéressant d'automatiser ces opérations afin de libérer du temps d'ASR. L'automatisation passe par la communication avec un ou plusieurs des annuaires les plus utilisés : LDAP, ActiveDirectory, NIS.

Les laboratoires qui accueillent de nombreux visiteurs ont, de même, intérêt à gérer l'affectation des machines et des bureaux. Au LPNHE, une application nommée GESPER permet de le faire et est rendue accessible aux services généraux responsables de l'accueil

Quel que soit l'outil choisi, il est important que tous les ASRs soient d'accord pour l'utiliser systématiquement et le tenir à jour.

Problèmes rencontrés :

Les principaux problèmes rapportés concernent la difficulté de conserver à jour les informations et le fait que ces informations sont fréquemment réparties entre plusieurs sources (base DNS IN2P3, annuaire LDAP IN2P3, fichiers comptabilité, etc.). Parmi les solutions évoquées pour le maintien à jour des informations, on relève le fait de nommer une personne responsable de la mise à jour et l'examen systématique des informations liées à une machine lors de chaque intervention.

Le suivi des licences des logiciels est plus difficile s'il y a délégation des droits d'installation aux utilisateurs (installations sauvages).

Concernant l'outil GLPI qui est assez fréquemment utilisé ou en test, on nous rapporte que certains plugins ne sont pas adaptés aux besoins et que l'outil est parfois trop lourd à mettre en oeuvre pour des besoins modestes. Les applications maison sont normalement par nature bien adaptées aux besoins mais perdent de leur généralité pour pouvoir être utilisées par d'autres unités et peuvent être très coûteuses lorsqu'il s'agit de les maintenir ou de les faire évoluer.

3 - Suivre les changements et partager les connaissances entre ASRs

Il est essentiel de conserver une trace des modifications apportées à un service pendant la période où il est exploité. La trace des modifications facilite considérablement le diagnostic des problèmes (cela marchait avant, maintenant cela ne marche plus : qu'est-ce qui a changé ?). L'enregistrement des modifications permet également de reproduire un service identique à partir d'un point de repère tacite (fin de l'installation standard d'une machine). Les changements apportés à une machine ou un service peuvent se décliner ainsi :

ajout ou suppression d'applications, d'utilitaires, logiciels, pilotes, etc.,

application de correctifs, de mises à jour (firmwares, système d'exploitation, applications),

modification de configuration,

correction de défaut matériel ou logiciel,

modification de la configuration matérielle.

En général, on ne conserve pas les traces de la même manière selon qu'il s'agit de serveurs jouant un rôle important, de postes de travail ou de portables. En particulier, il apparaît difficile de conserver des traces des modifications apportées à un ordinateur portable géré par l'utilisateur.

La connaissance des changements apportés au système d'information constitue une partie des informations qui doivent être partagées entre tous les ASR susceptibles d'intervenir. Les autres éléments à partager entre ASR sont au minimum :

l'architecture du système d'information, des schémas,

la façon dont un service particulier a été mis en oeuvre,

les procédures pour effectuer certaines tâches récurrentes ou pour résoudre un problème,

les contrats, les contacts, les numéros d'appel à la maintenance.

Ce qui est fait :

Dans la majeure partie des unités contactées (13 sur 21), les changements apportés aux machines de la classe “serveurs” font l'objet d'un enregistrement. C'est beaucoup plus rare pour les postes de travail (6 réponses) et les portables (4 réponses).

Le « cahier de manip » a longtemps été l'outil de base pour le suivi du petit nombre de serveurs d'une unité. Le nombre de serveurs par unité a considérablement augmenté et la possibilité d'enrichir les documents avec des liens externes plaide plutôt pour l'utilisation d'outils électroniques pour ce type de suivi, permettant en outre la consultation aisée par tous les ASRs.

Les outils employés vont des fiches de suivi (tableur ou texte) disponibles sur un répertoire partagé à des outils plus spécialisés tels « elog ». Les solutions de type WiKi sont également très employées, la facilité de mise à jour étant un critère important. Signalons également que le suivi des modifications peut être une extension d'une application de gestion des actifs à travers la gestion des interventions ou fiche « historique » d'une machine (GLPI).

Un certain nombre de sites s'appuient, pour maîtriser les changements apportés aux machines, sur des outils qui rentrent dans la catégorie de la « gestion de configuration ». Il s'agit des sites qui utilisent le logiciel Quattor ou qui enregistrent les fichiers de configuration des machines dans un logiciel de suivi de versions tel SVN (subversion).

Concernant le partage de l'information et des connaissances entre ASRs, le contact direct est évidemment une constante mais une majorité d'unités dispose d'un espace de documentation partagé entre tous les ASR sous une des formes suivantes :

répertoire partagé par le réseau,

WiKi dédié aux ASRs (visible ou pas des utilisateurs ou du monde entier),

d'un espace Web classique à accès restreint.

Les sites qui utilisent Quattor sont enclins à utiliser le logiciel Trac pour intégrer l'accès aux différentes versions de la configuration des machines, un WiKi et une gestion de tickets basique.

Le contenu de l'espace d'information destiné aux ASR ne faisait pas l'objet du questionnaire mais on y trouve classiquement :

des schémas de l'architecture du réseau ou de certains services,

les références des contrats de maintenance et les numéros à appeler,

des recettes, des trucs et astuces,

des éléments de la gestion des actifs (liste des machines, des adresses,...),

des procédures,

des mémentos et des howtos.

On y trouve la plupart des éléments importants cités ci-dessus mais parfois également des éléments du budget du service et les agendas des membres de l'équipe.

Un certain nombre d'unités intègrent dans cet espace de documentation des procédures listant les opérations à effectuer pour rendre un service ou réparer en cas de problème.

Cette documentation partagée peut être complétée de dispositifs aidant à retrouver l'information pertinente : application gérant les méta-données au LAPP, indexation automatique par mot-clés et recherche “Full Text”.

Une autre méthode de partage des connaissances entre ASRs repose sur l'organisation de réunion de service régulières. Ces réunions prennent les formes suivantes :

réunion quotidienne courte (15mn) permettant de savoir sur quel sujet travaille chacun,

réunion hebomadaire < 1heure (ou plus si le sujet estimportant),

réunion bi-mensuelle.

Bien entendu, comme la plupart des équipes d'ASR sont de taille modeste (sauf au CC), des réunions sont également organisées de manière impromptue si le besoin s'en fait sentir.

Sur au moins un site, on cite l'obligation qui est faite aux ASR de travailler en binôme sur tout projet relativement important, ceci afin d'avoir plus d'idées et d'éviter les dérapages (poursuite d'une voie déraisonnable).

Remarques :

Concernant le suivi des modifications : En fonction des méthodes employées pour installer et apporter des modifications à une machine, il peut exister une relation assez étroite entre le déploiement et la reconstitution de l'historique des modifications d'une machine. En particulier, l'historique d'une machine gérée par Quattor peut se reconstituer à partir des versions successives de sa définition (profile). Ceci est vrai en théorie mais en pratique, l'objet d'un outil comme Quattor est plus la reproductibilité d'une configuration donnée d'une machine et reconstruire un historique explicite n'est pas si aisé. On retrouve une situation analogue si on utilise un outil comme cfengine ou si on déploie des images comme avec AD/WDS pour le monde Windows. De même, un outil comme OSC Inventory nous fournit la configuration courante mais pas les évolutions successives.

Pour encourager la publication de documents et la documentation du travail, il doit être très simple et rapide de créer ou d'éditer des documents. Il est possible que le Web classique ne se prête pas à la mise en ligne de documents très évolutifs nécessitant de fréquentes mises à jour par des personnes différentes.

Les procédures permettent à un nouveau recruté d'être opérationnel plus rapidement. Si en plus certaines opérations sont automatisées (étape suivante), des personnes moins bien formées peuvent intervenir (personnel d'astreinte, autre...)

Problèmes :

Concernant le partage des informations et des connaissances : Le WiKi pour l'équipe est une bonne solution mais il faut motiver les gens pour le remplir (échecs fréquents). Même avec des systèmes faciles à utiliser (WiKis, SPIP), la production de documentation dépend trop de la bonne volonté des ASRs et de leur propension à documenter. Si on utilise plusieurs endroits (Web, WiKi, elog, trac), il devient difficile de savoir où trouver les informations.

S'il existe plusieurs groupes d'administrateurs réseau au sein du service informatique, il peut arriver que des outils ou bases d'information complètement distinctes soient utilisées, ce qui ne facilite pas une vue globale.

4 - Communiquer avec les utilisateurs, documentation pour les utilisateurs

Tout utilisateur des moyens informatiques d'une unité doit pouvoir prendre connaissance des caractéristiques et du fonctionnement du système d'information. Les utilisateurs doivent également être tenus informés des incidents qui ont un impact sur le service.

Ce qui est fait :

Dans toutes les unités contactées, il existe un service d'information alimenté par le service informatique et destiné aux utilisateurs. Les principales classes d'informations présentes sur ce service sont :

description des moyens informatiques et des services disponibles

mode d'emploi de certains services

ressources disponibles et limites

règles d'usage

contacts et interactions avec les membres du service

Les outils utilisés pour mettre ces éléments d'information à la disposition des utilisateurs sont majoritairement de type Web, natif, ou via des systèmes de gestion de contenu de type WiKi. On note toutefois le recours à des applications Web spécialisées en fonction du type de contenu (FAQoMatic par exemple pour des FAQs) et l'utilisation de logiciels de gestion documentaire tel EDMS.

L'information des utilisateurs quant à la vie du système d'information comprenant les évolutions et les incidents est réalisée presque exclusivement par messagerie électronique en utilisant des listes de diffusion permettant de s'adresser à l'ensemble du personnel du laboratoire. L'information par mail bénéficie d'une certaine rémanence si elle est reprise dans une rubrique « actualités » sur l'espace Web ou le WiKi dédié à l'information des utilisateurs. Les actualités du service informatique sont reprises par des tableaux d'affichage électroniques dans au moins trois établissements : au CC, au LAPP et à l'IPHC.

Remarques :

La documentation destinée aux utilisateurs est importante et il n'y en a jamais assez. La remarque sur la nécessité de faciliter la production de documents par les ASR vaut ici également.

Il est important qu'il existe un document qui présente l'ensemble des services disponibles. Ce document est particulièrement utile pour l'accueil des nouveaux utilisateurs. Il doit être complété par un ensemble de fiches plus détaillées permettant aux utilisateurs de tirer parti des services mis en oeuvre tout en respectant les règles d'utilisation.

Un mail de bienvenue ou une fiche imprimée peut indiquer l'URL du site interne destiné aux utilisateurs et en particulier le document de présentation.

Problèmes :

La gestion de l'obsolescence des documents utilisateurs ou internes à l'équipe ASR est un problème constaté par beaucoup. Au CC, on envisage des outils contrôlant la date de dernière mise à jour. Au LPC-Caen, les documents sont revus systématiquement et régulièrement, lors des évolutions matérielles et logicielles.

Il peut être tentant de faire en sorte que cette documentation soit accessible de l'extérieur pour les nomades mais dans ce cas, il faut être très vigilant sur l'exploitation possible des informations.

5 - Gérer les demandes des utilisateurs

Un outil de gestion des demandes des utilisateurs permet d'enregistrer toutes les requêtes des utilisateurs quelle qu'en soit la nature. Les buts d'un tel système sont multiples mais il s'agit essentiellement :

de ne pas oublier une demande

que toutes les personnes susceptibles d'intervenir puissent suivre les échanges

de conserver des traces des demandes et des solutions apportées

de gérer des priorités entre les différentes demandes

Lors des interviews, il a été demandé aux sites qui disposent d'un tel outil ou bien souhaitent en installer un quelles étaient leurs motivations pour installer un système de gestion des demandes des utilisateurs. La liste ci-dessous présente les réponses recueillies :

équipe ASR s'agrandissant

éviter de polluer les mails des personnes qui ne sont pas de service au support

éviter les interruptions incessantes (visites au bureau ou téléphone)

difficulté du suivi avec uniquement un alias de messagerie (oubli de la copie à l'alias, on ne sait pas si un problème est résolu,...)

Ce qui est fait :

Le sondage fait apparaître que 7 unités sur 21 ont installé un outil de gestion des demandes des utilisateurs qui est soit utilisé, soit encore en test. La liste des outils utilisés est la suivante :

OTRS : (test au LPSC et LPNHE, utilisé à l'IPNO)

RT (utilisé à Subatech), en test au LPNHE et au LAPP

Xoops/Xhelp : CCIN2P3

Outil « user.support » CCIN2P3 : encore utilisé dans un labo

Trac (installé, utilisation système de gestion de tickets envisagée)

GLPI

Certaines unités (4) ont recours uniquement à la messagerie pour gérer les demandes des utilisateurs. Le plus élémentaire est la définition d'un alias de messagerie qui fait suivre les demandes à une liste d'ASRs. Plus évolué, le partage de boîtes à lettres via le protocole IMAP permet de partager un classement des demandes.

Dans le questionnaire nous n'avons pas cherché à examiner en détail la manière dont les systèmes de gestion des demandes sont utilisés car chaque site a sa propre culture en matière d'assistance aux utilisateurs mais les interviews font apparaître deux types d'approches :

la méthode du « hot seat » : consiste à désigner l'un des ASR pour examiner en premier les demandes, essayer d'en résoudre le maximum et passer les autres aux collègues les plus compétents en fonction du problème (méthode choisie dans 2 laboratoires)

Le méthode « au bon vouloir » : laisser les ASRs se répartir les demandes et les traiter (méthode en application dans 5 laboratoires).

L'ensemble des échanges ayant abouti à la résolution d'un problème constitue une mine de renseignements lorsque des problèmes similaires se reproduisent ou bien pour alimenter des FAQs destinées aux utilisateurs. La possibilité de procéder à des recherches par mots-clés dans l'ensemble des tickets résolus est un avantage. Il apparaît que cette possibilité n'est disponible que dans 4 unités.

Remarques :

Le passage à Xoops/Xhelp au CC était motivé par la nécessité de communiquer avec le système de gestion de tickets de la grille : GGUS.

Une synthèse des systèmes de suivi des demandes serait utile à tous. Pascal Calvat a réalisé pour le Centre de Calcul une étude comparative des logiciels Request-Tracker, Mantis et OTRS qui pourrait servir de modèle. Il apparaît que beaucoup de laboratoires s'intéressent aux systèmes de gestion des demandes et il est intéressant de continuer ce travail de recensement et de comparaison des solutions disponibles.

Problèmes :

La fonction de « hotseat » est utilisée dans 2 laboratoires. Cette manière de procéder est proche de celle des centres d'assistance d'une certaine taille où on parle de « premier niveau » ou « front-line ». Cependant, si le nombres de personnes prenant ce tour de service est peu élevé, le tour de service revient trop souvent. Il semble que certains ASRs vivent ce rôle comme une punition.

Avec une BAL partagée, le statut d'une demande n'est pas assez explicite et cela rend le suivi difficile. Les demandes ne sont pas attribuées et les doubles réponses sont fréquentes. Le demandeur ne sait pas qui s'occupe de son ticket et le contenu de la BAL est vite trop dense.

Certains utilisateurs préfèrent téléphoner ou se déplacer (si urgent) plutôt que d'utiliser la messagerie ou le système de gestion des demandes. Si l'on désire que la majorité des demandes passent par l'outil de gestion des demandes, il faut inciter par divers moyens les utilisateurs à utiliser ces outils. Une des solutions consiste, pour les ASRs sollicités directement, à saisir la demande de l'utilisateur en sa présence. A ce sujet, les outils obligeant les utilisateurs à passer par une interface Web peuvent être plus difficiles à faire adopter par les utilisateurs que ceux reposant sur la messagerie.

A l'inverse, il arrive que ce soit les ASRs eux-mêmes qui préfèrent le contact direct et sont peu enclins à mettre en oeuvre un système de gestion des demandes des utilisateurs.

Il est important de remarquer également qu'un système de gestion de ticket permet dans une certaine mesure de suivre le travail des autres membres de l'équipe avec les avantages et les inconvénients que cela comporte. Une bonne entente au sein de l'équipe est donc essentielle pour le bon fonctionnement ce type d'outil.

6 - Mettre en oeuvre des dispositifs de surveillance et d'alerte

L'objectif est de détecter le plus tôt possible un problème ou une situation à risque afin d'intervenir avant que le fonctionnement du système d'information ne soit dégradé. Dans l'enquête, on a essayé de distinguer les problèmes liés à l'environnement physique : température, humidité, alimentation électrique, etc.) des problèmes liés aux dysfonctionnements matériels, logiciels ou liés à un problème de sécurité informatique.

Ce qui est fait :

La participation de plusieurs laboratoires à la grille de calcul (projets EGEE et LCG) a nécessité l'installation de fermes de calcul relativement puissantes et de ressources de stockages importantes. Il a fallu équiper en conséquence les salles machines en améliorant la climatisation et en renforçant la qualité et disponibilité des alimentations électriques (onduleurs). Compte-tenu de la puissance installée, une panne de climatisation conduit à une élévation rapide et importante de la température, risquant d'endommager le matériel. Il devient donc essentiel de détecter le plus rapidement possible des conditions environnementales anormales afin d'alerter les ASRs. Le risque d'incendie reste présent également ainsi que le risque d'inondation sur certains sites.

Les paramètres environnementaux faisant l'objet d'une surveillance sont, par ordre décroissant de fréquence :

détection des inondations,

détection incendie,

détection température élevée,

détection défaillance climatisation,

détection défaillance onduleur,

contrôle de l'alimentation électrique (puissance, équilibrage de charge, etc.).

Les dispositifs d'alerte associés permettent très souvent l'envoi de messages électroniques à une liste d'ASRs mais dans au moins 5 unités, le dispositif d'alerte est programmé pour envoyer des SMS ou appeler un ou plusieurs numéros de téléphone.

Sur certains sites, on va plus loin en provoquant un arrêt automatique du système d'exploitation (shutdown) de certaines machines lorsqu'un seuil est atteint (température, autonomie restante du onduleur inférieure à un certain temps).

Quelques laboratoires (au nombre de 4) disposent d'un système d'extinction automatique par gaz inerte .

Concernant la détection des problèmes de sécurité, tous les laboratoires sont équipé d'une machine avec le logiciel EXTRA permettant de détecter les trafics réseau anormaux.

Toutes les unités disposent également d'une solution anti-virus pour les postes de travail et les portables, mais toutes ne disposent pas d'une solution permettant la gestion centralisée de l'anti-virus avec remontée d'alertes.

Parmi les autres dispositifs installés dans les laboratoires capables d'alerter sur des évènements liés à un éventuel problème de sécurité, on peut également citer :

solution anti-virus au niveau réseau sur le traffic de messagerie, web ou FTP

solution détection des tentatives d'intrusion (niveau applicatif)

détection de la modification anormale du système d'exploitation (tripwire)

Les journaux systèmes jouent un rôle important dans la détection ou la recherche de traces d'un incident de sécurité. La centralisation des journaux des principaux serveurs les plus exposés facilite ce travail de détection ou de recherche. La centralisation des journaux est pratiquée dans de nombreux laboratoires mais les outils d'analyse de ces journaux restent assez peu répandus

De nombreux autres évènements courants dans la vie des systèmes sont susceptibles de se produire, de provoquer l'indisponibilité de certains services et d'impacter le fonctionnement de l'ensemble. En particulier : le remplissage de disques, la charge trop importante des processeurs, etc. Une très large majorité de laboratoires utilise à cet effet le logiciel NAGIOS.

Remarques :

Les systèmes de détection d'incendie sont souvent gérés avec les infrastructures par les établissements d'accueil (Campus, Ecole,...).

Au niveau des mécanismes d'alerte, il convient de distinguer :

les dispositifs qui se contentent d'une alarme visuelle ou sonore,

les dispositifs qui envoient des messages eléctroniques,

les dispositifs qui appellent des numéros de téléphone ou envoient des SMS,

les systèmes qui agissent (extinction, shutdown automatique, coupure d'alimentation électrique).

Problèmes :

Le réglage des dispositifs d'alerte et le choix des actions nécessitent une réflexion approfondie. Trop d'alertes endorment la vigilance. Lorsqu'on utilise Nagios pour surveiller beaucoup de paramètres (CPU, espace disque, mémoire, etc.) les alertes sont nombreuses et il faut éviter que Nagios n'envoie trop de messages électroniques.

Mettre en oeuvre un dispositif qui risque d'appeler les ASRs à leur domicile ou sur leur téléphone portable à tout moment du jour ou de la nuit, pendant les week-ends ou les vacances, est délicat, surtout lorsque rien n'est prévu dans les statuts des personnels.

Les ingrédients de la Qualité vus par les ASRs

Au delà du questionnaire, lors des interviews, la question suivante a été posée :

« Quels sont selon vous les trois éléments les plus importants pour obtenir une bonne qualité de service au niveau du service informatique d'un laboratoire ? »

La liste ci-dessous reprend les réponses que nous avons recueillies :

Bonne entente et bonne organisation entre les ASR du service

Documentation interne et pour les utilisateurs

Assez de personnel pour faire face aux missions (attention aux départs non remplacés)

Il faut documenter : des outils faciles à utiliser par les ASR pour documenter à chaud par ceux-là mêmes qui ont fait le travail.

Ne pas réinventer la roue : accéder à des listes de solutions déjà validées afin de gagner du temps, partager les expériences

Disposer de systèmes de supervision utilisables à distance pour découvrir rapidement les problèmes

Avoir un système de gestion des demandes pour mieux gérer les tâches de l'équipe et éviter les interruptions trop fréquentes

Avoir un système de centralisation des mots de passe (SSO)

L'assistance aux utilisateurs est la première chose à améliorer

Avoir une bonne gestion du parc permettant d'avoir une vue exacte et d'identifier immédiatement l'utilisateur d'une machine, sa localisation géographique et son historique

Maîtriser la topologie du réseau (bureaux, prises, etc.)

Etablir une bonne communication entre ASRs et utilisateurs : ouverture d'esprit, se mettre à la place des utilisateurs, éviter le jargon, comprendre les besoins

Unité au sein de l 'équipe : mêmes méthodes de travail, éviter la « balkanisation », choisir des standards et s'y tenir.

Faire en sorte que toutes les commandes de matériels ou logiciels informatiques passent par le Service Informatique afin de garantir la meilleure homogénéité du parc et de s'assurer que le Service Informatique est en mesure de fournir de l'assistance.

Etre présents auprès des utilisateurs, écouter, prendre en compte leurs problèmes, les former et les informer.

Compétence des ASR via la formation, la veille technologique, la pratique

Rigueur dans le travail

La communication avec les utilisateurs est importante, il faut organiser des réunions générales et même des séminaires pour présenter certaines technologies ou services.

Il faut inciter les utilisateurs à réfléchir à leurs besoins et autant que possible à les formaliser.

Conclusion

En se focalisant sur des pratiques et des outils permettant d'organiser ou de soutenir l'activité des Administrateurs des Systèmes et des Réseaux chargés de la gestion des infrastructures, cette enquête complète les autres sondages qui s'intéressent plutôt aux caractéristiques du système d'information.

Une autre originalité de cette enquête est le choix de l'interview comme complément au questionnaire. Cette formule est évidemment assez coûteuse en temps, qu'il s'agisse de celui des personnes interviewées ou de celui des intervieweurs. Néanmoins les interviews sont en général des moments d'interaction extrêmement riches et nous remercions sincèrement les personnes qui se sont prêtées à ce jeu malgré leur emploi du temps chargé.

Il est assez difficile de produire une synthèse de toutes ces conversations mais il est apparu essentiel d'essayer de ne pas perdre les données recueillies et de faire en sorte que ce document de synthèse puisse servir de base à des réflexions, des travaux ou des échanges ultérieurs.

Le tableau récapitulatif des réponses au questionnaire qui accompagne cette synthèse montre que de nombreux outils permettant d'améliorer le service aux utilisateurs et l'organisation du service informatique ont été mis en oeuvre dans les laboratoires de l'IN2P3. Il n'était pas possible de discuter en détail de l'intérêt, des avantages et des inconvénients de chaque solution mise en oeuvre mais c'est un sujet très intéressant qui mêle technique et aspects humains.

Certaines solutions sont en passe de devenir assez populaires dans les unités. Citons par exemple : OCS-Inventory, GLPI, Quattor, systèmes de gestion des demandes. Dans d'autres unités, on en est au stade de la réflexion ou de l'étude.

Il apparaît donc évident qu'il y a matière, à partir de ce sondage, à favoriser les échanges entres les personnes qui ont acquis de l'expérience dans la mise en oeuvre et l'utilisation des outils et celles qui envisagent de les mettre en oeuvre. Les outils de communication déjà en place sont là pour nous y aider : liste de diffusion ASR-L, le site Web du réseau RI3 et ses forums. Et pourquoi pas des rencontres de type Workshop avec des présentations et des discussions, sans négliger encore une fois les aspects humains qui soutendent toute démarche qualité.

Annexe 1 : Le Questionnaire

Recueil des besoins des utilisateurs

Comment prenez-vous connaissance des besoins des utilisateurs ?

Le recueil des besoins est-il une démarche formalisée ?

Organisez-vous des réunions avec les utilisateurs dans ce but ?(fréquence, fréquentation)

Certaines demandes font-elles l'objet d'une négociation et si oui, comment procédez-vous (arguments, exigences, etc.) ?

Gestion des actifs

On appelle "actifs" l'ensemble des biens matériels ou immatériels auquels on peut ajouter des éléments de configuration. Une première liste non exhaustive pourrait être : postes de travail, serveurs, imprimantes, autres périphériques, logiciels, licences, consommables, adresses réseau, comptes informatiques, prises réseau, commandes, contrats,...

Disposez-vous d'un système d'enregistrement ou de gestion pour des éléments de la liste ci-dessus ?

Si oui, quelle forme ce système revêt-il ? :
Outil maison ou commercial ?
Si outil maison : est-ce distribuable à d'autres établissements ?
Est-ce basé sur un SGBDR ? Lequel ?
Quels sont les éléments gérés par votre outil ?

Utilisez-vous un ou des outils d'inventaire automatique ?
Si oui, lesquels ?

Gestion des changements et documentation interne au service

Est-ce que vous enregistrez les évènements suivants (indiquez si c'est systématique et pour quelles classes de machines : serveurs, postes fixes, nomades) ? :
* ajout/suppression de logiciels
* modifications de configuration
* correction de problème de défaut

Sur quel outil vous appuyez-vous pour ces enregistrements ? :
* logiciels de gestion de conf : CVS, subversion, Trac ?
* journaux de bord manuels, éléctronique ?
* autre méthode

Comment se fait le partage des connaissances au sein de l'équipe des ASRs ?

Disposez-vous de procédures écrites pour certaines tâches,
si oui, lesquelles ?

Documentation pour les utilisateurs, Communication

Mettez-vous de la documentation à disposition des utilisateurs ?
Si oui, de quelle manière et avec quels outils ?

Avez-vous des méthodes pour gérer l'obsolescence et l'évolution de cette documentation ?

Quels sont les principaux éléments couverts par cette documentation ?

Comment les utilisateurs sont-ils tenus au courant de la vie du système d'information (évolutions, arrêts pour maintenance, incidents, etc.) ?

Gestion des demandes des utilisateurs

Disposez-vous d'un outil de gestion et de suivi des demandes des utilisateurs ?

Si oui, comment se fait l'affectation des tickets aux personnes chargées de leur prise en charge ?

Comment se fait le suivi des tickets ?

Disposez-vous d'un outil de recherche dans le corpus des tickets résolus ?

Surveillance et détection des problèmes

Disposez-vous de systèmes de détection de sinistres ou de conditions environnementales dégradées (innondation, incendie, élévation de température,...) ?

Disposez-vous de systèmes d'alerte pour des évènements susceptibles de compromettre la sécurité logique des équipements ou des données (intrusion, perte/modification de données, virus,etc.) ?

Disposez-vous de systèmes de surveillance et d'alerte permettant de détecter les problèmes pour les services importants ?

Quels services, quels outils, quel mécanisme d'alerte ?

Disposez-vous d'un système de centralisation des journaux systèmes ?

D'un système d'analyse de ces journaux ?

Test comparatif d'outils de gestion de tickets : http://cc.in2p3.fr/docenligne/645

Synthèse de l'enquête « Bonnes Pratiques ASR » JI2008 IN2P3/IRFU Obernai.	/16

Jean-Michel

2008-09-11T21:44:15