1.2. Documenter toute activité

Si un administrateur système moyen avait le choix entre l'installation d'un tout nouveau serveur ou l'écriture d'un document de procédure sur la manière d'effectuer des sauvegardes de 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 reporte à 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."

À moins que vous ne fassiez partie de ces rares personnes dotées d'une incroyable mémoire photographique, vous ne pourrez pas vous rappelez 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 la moitié de l'histoire. 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 endommager à cause de votre compréhension incomplète de la situation.

"Si je m'en rappelle, ils ne me licencieront pas — 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 à prêter une attention toute particulière au rôle de tout employé. 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, 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 sur le système. 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é varie selon les sociétés dans laquelle vous travaillez.

Procédures

Les procédures représentent toute série d'actions, étape par étape, devant être suivie 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édure 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 à effectuer — 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 vous trouver dans une situation très confuse quant aux changements ayant étéapportés quelques mois en arrière.

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 utiles pourraient ressembler à l'extrait ci-dessous :

ECB, 12-June-2002 — Updated entry for new Accounting printer (to
     support the replacement printer's ability to print duplex)