Je ne sais pas comment poser cette question, puisque je ne suis pas dans le domaine. Disons que vous êtes un administrateur réseau et que vous quittez votre emploi. Comment le nouvel employé peut-il savoir par où commencer ?
Cela dépend de la taille du réseau, du nombre d'utilisateurs, du nombre de nœuds (ordinateurs, serveurs, imprimantes, etc.) et de la taille de votre personnel informatique, entre autres.
Cela dépend aussi de votre objectif. Est-ce que vous documentez le réseau à des fins de formation et de maintenance, d'assurance/prévention des pertes, etc.
Personnellement, je documente mes réseaux de telle manière que je sais que je peux déduire toute information manquante en me basant sur ce qui a été dit. est documenté. D'un point de vue pratique, il y a un point de rendement décroissant lorsque votre documentation devient trop granulaire.
Une bonne règle de base que j'utilise est qu'il doit y avoir une documentation dans un endroit connu et suffisamment complète pour que, si je suis renversé par un bus ce soir, un autre administrateur puisse continuer à faire fonctionner le réseau principal pendant qu'il/elle complète les pièces manquantes au cours des jours/semaines suivants.
Voici un aperçu de ce que je considère comme le plus important dans l'un de mes réseaux. Pour mémoire, il s'agit d'un magasin fonctionnant uniquement sous Windows, avec environ 100 utilisateurs et 5 bureaux.
S'il y avait quelque chose d'étrange à propos d'une configuration ou d'un flux de travail qui ne serait pas immédiatement évident pour un nouvel administrateur, je rédigeais également une courte "note" à ce sujet.
Je trouve que c'est mieux d'incorporer tous les éléments suivants :
Notes supplémentaires sur les diagrammes... La répartition géographique est un moyen facile de segmenter, mais vous avez également besoin de vues logiques basées sur la fonction de l'installation. De plus, étiquetez comme un fou, en utilisant pleinement les polices de caractères et les couleurs.
La réponse de Kyle est un excellent conseil. Mais au minimum, vous pourriez probablement vous en sortir avec une liste :
Là où je travaille - nous avons été confrontés au même problème lorsque j'ai commencé à travailler ici. Au fur et à mesure que le nombre de serveurs et de services augmente, vous trouvez de plus en plus de documentation obsolète, et avec cela vient l'attitude inévitable du personnel de ne pas faire confiance à la documentation, au moins la documentation technique sur les noms de serveurs, les groupes de serveurs, les réseaux, etc.
Nous avons commencé à développer un projet open-source appelé hotwire pour aborder cette...
En combinant le système d'inventaire avec le système de construction, nous nous assurons que ce qui se trouve dans la base de données est cohérent avec ce qui se trouve dans nos centres de données, car nous devons maintenant entrer les données dans l'inventaire avant de pouvoir construire les serveurs.
Un programme client (funcwire) est ensuite installé sur tous les serveurs (dans le cadre du processus de construction) et surveille de manière dynamique le matériel du serveur, comme indiqué par Python-dmidecode et ce qui se trouve dans l'inventaire, de sorte que si quelque chose change, les administrateurs le sauront immédiatement.
Nous avons ensuite intégré notre système wiki afin que chaque serveur, rack, projet, modèle de matériel, etc. dans hotwire renvoie directement à la page wiki appropriée.
Nous avons donc "documenté" nos serveurs/réseaux/etc en utilisant hotwire + un wiki (nous utilisons confluence ici, mais tout wiki décent fera l'affaire). (Notez cependant qu'une fois que les serveurs sont construits - hotwire ne les modifie en aucune façon - la gestion continue se fait via cfengine).
J'utilise MikroTik Dude pour cartographier les choses automatiquement, c'est une application géniale si l'on considère qu'elle est gratuite. Elle peut également surveiller l'état actuel. Page Web de Dude
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
6 votes
Aussi : La documentation vous permet de prendre des vacances un jour, ainsi que de protéger l'entreprise si vous êtes trop malade ou blessé pour travailler.