1.2. Documentez de toute activité

Si un administrateur système moyen avait le choix entre l'installation d'un tout nouveau serveur et l'écriture d'un document de procédure sur la manière d'effectuer des sauvegardes système, il choisirait à chaque fois la première option. Dans tous les cas de figure, vous devez documenter vos activités. De nombreux administrateurs système reportent à plus tard la mise à jour des documents nécessaires pour un certain nombre de raisons :

"Je pourrai toujours le faire plus tard."

Malheureusement, ce n'est généralement pas le cas. Même si l'administrateur système pense vraiment être en mesure de faire la mise à jour ultérieurement, la nature du travail d'administrateur système est telle que les tâches quotidiennes sont généralement trop chaotiques pour "le faire plus tard." Pis encore, plus cette tâche est reportée, plus le nombre d'informations oubliées augmente et moins le document final sera détaillé (est par conséquent, moins il sera utile).

"Pourquoi tout mettre par écrit, je m'en rappellerai bien."

À moins que vous ne fassiez partie de ces rares personnes dotées d'une incroyable mémoire photographique, vous ne pourrez pas vous rappeler des informations nécessaires. Pis encore, vous ne vous rappellerez que de la moitié des faits, sans même vous rendre compte qu'il vous manque une bonne partie de la situation. Dans de telles circonstances, vous perdrez un temps considérable à essayer soit de réapprendre ce que vous avez oublié, soit de réparer ce que vous aurez endommagé à cause de votre compréhension incomplète de la situation.

"Si je m'en rappelle, je ne serai pas licencié — Je bénéficierai de la sécurité de l'emploi !"

Alors que cette approche pourra vraissemblablement fonctionner pendant un certain temps, elle se traduira au long terme par une sécurité de l'emploi réduite — et non — accrue. Imaginez un instant ce qui pourrait se produire en cas d'urgence. Il se peut que vous ne soyez pas disponible ; les documents que vous aurez rédigés permettront peut-être d'éviter une catastrophe en donnant à une autre personne les moyens de résoudre la situation en votre absence. De plus, n'oubliez jamais que c'est dans les cas d'urgence que la direction à tendance à analyser les choses de manière détaillée. Dans de telles conditions, il est préférable que votre travail de documentation fasse partie de la solution plutôt que de voir votre absence faire partie du problème.

De plus, si vous faites partie d'une petite entreprise en expansion, il y a de fortes chances qu'un autre poste d'administrateur système soit créé dans le futur. Comment cette personne pourra-t-elle vous assister si toutes les informations sont dans votre tête ? Pis encore, toute absence de documentation de votre part pourrait vous rendre si indispensable que toute promotion pourrait être pour cette raison même, considérée avec réticence. Vous pourriez même finir par travailler pour la personne recrutée à l'origine pour vous épauler.

Dans de telles circonstances, vous verrez certainement les avantages de maintenir la documentation relative aux systèmes. Ce point nous amène à la question suivante. Que devriez-vous documenter ? Ci-après figure une liste partielle des aspects devant faire l'objet de documentation :

Politiques

Les politiques sont rédigées pour établir de façon claire et formelle la relation que vous entretenez avec votre communauté d'utilisateurs. Elles définissent clairement à vos utilisateurs, la manière selon laquelle leurs requêtes de ressources et/ou d'assistance sont traitées. La nature, le style et la méthode selon lesquels ces politiques sont disséminées parmi votre communauté varient de société à société.

Procédures

Les procédures décrivent, étape par étape, les différentes actions devant êtres effectuées afin d'accomplir une certaine tâche. Parmi les procédures à documenter peuvent figurer entre autres, les procédures de sauvegarde, les procédures de gestion des comptes utilisateur, les procédures de rapportage de problèmes. Tout comme pour l'automatisation, si une procédure est suivie plus d'une fois, il est toujours bon de la documenter.

Changements

Une grande partie de la carrière d'un administrateur système évolue autour de changements devant être effectués — comme la configuration du système visant à maximiser les performances, l'amélioration des scripts, la modification de fichiers de configuration, etc. Tout ces changements devraient faire l'objet de documentation sous une forme ou sous une autre. Dans le cas contraire, vous pourriez avoir une idée très confuse quant à une modification que vous avez effectuée il y a quelques mois.

Bien que certaines sociétés utilisent des méthodes plus complexes pour effectuer un suivi des changements, dans bien des cas, il est suffisant d'inclure un simple historique de révision au début du fichier faisant l'objet de modifications. Toute entrée faisant partie de l'historique de révision devrait comporter au strict minimum les éléments suivants :

  • Le nom ou les initiales de la personne effectuant les modifications

  • La date à laquelle la modification a été effectuée

  • La raison pour laquelle la modification a été effectuée

Ces éléments, spécifiés dans des entrées concises mais informatives, pourraient ressembler à l'extrait ci-dessous :

ECB, 12-Juin-2002 — Entrée mise à jour pour la nouvelle imprimante du service comptabilité (pour permettre la prise en charge de la capacité d'impression en duplex de l'imprimante de remplacement)