NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
Linuxtopia - CentOS Enterprise Linux Introduction a l'administration systeme - Documentez de toute activit�
Red Hat Enterprise Linux 4: Introduction � l'administration syst�me
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)
