Je ne sais pas comment poser cette question, car je ne suis pas sur le terrain. Supposons que vous êtes un administrateur réseau et que vous quittez votre emploi. Comment le nouveau type sait-il 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. Documentez-vous 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ériver toute information manquante en fonction de ce que est documenté. D'un point de vue pratique, il y a un point de rendements décroissants lorsque votre documentation devient trop granulaire.
Une bonne règle de base que j'utilise est qu'il devrait y avoir une documentation dans un endroit connu qui soit suffisamment approfondie pour que si je suis frappé par un bus ce soir, un autre administrateur puisse garder le réseau principal en marche pendant qu'il remplit les pièces manquantes sur le prochains jours/semaines.
Voici un aperçu de ce que je pense être le plus important sur l'un de mes réseaux. Pour mémoire, il s'agit d'une boutique Windows uniquement avec environ 100 utilisateurs et 5 bureaux.
S'il y avait quelque chose d'étrange dans une configuration ou un flux de travail qui ne serait pas immédiatement évident pour un nouvel administrateur, j'écrirais également un bref "bref" à ce sujet.
Je trouve qu'il est préférable d'incorporer tous les éléments suivants:
Remarques supplémentaires sur les diagrammes ... La distribution géographique est un moyen facile de segmenter, mais vous avez également besoin de vues logiques basées sur la fonction d'installation. Aussi, étiquetez comme un fou, en utilisant pleinement les polices et les couleurs.
La façon la plus efficace et la plus approfondie de démarrer ce processus est de le construire à partir d'un scénario de reprise après sinistre - par exemple le bâtiment a pris feu et tout ce que nous avons, ce sont les sauvegardes hors site. De quoi aurons-nous besoin pour acheter en premier et comment devra-t-il être configuré?
Kyle a déjà donné de grands détails, mais je trouve que l'approche DR m'aide à prendre les choses une par une.
Où je travaille - nous avons rencontré le même problème lorsque j'ai commencé 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 pour le personnel de ne pas faire confiance à la documentation, au moins la documentation technique sur les noms de serveur, les groupes de serveurs, les réseaux, etc.
Nous avons commencé à développer un projet open source appelé hotwire pour résoudre ce problème ...
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 d'abord saisir les données dans l'inventaire afin de pouvoir construire les serveurs. .
Un programme client (funcwire) est ensuite installé sur tous les serveurs (dans le cadre du processus de construction) qui garde ensuite dynamiquement un œil sur le matériel du serveur tel que rapporté par python-dmidecode , et ce qui est dans l'inventaire, donc si quelque chose change, les administrateurs le sauront immédiatement.
Nous avons ensuite intégré notre système wiki pour que chaque serveur, rack, projet, modèle matériel, etc. dans les liens hotwire soit directement relié à la page wiki appropriée.
Nous avons donc "documenté" nos serveurs/réseau/etc en utilisant hotwire + un wiki (nous utilisons ici la confluence, mais tout wiki décent fera l'affaire). (Notez cependant qu'une fois les serveurs 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 étant donné qu'elle est gratuite. Il peut également surveiller l'état actuel. Page Web Mec
La réponse de Kyle est un excellent conseil. À un strict minimum, vous pourriez probablement vous en sortir avec la liste:
Kyle Noland et d'autres affiches ont beaucoup expliqué comment documenter. Nous travaillons sur la création d'un logiciel Web standard (hébergé en interne par vous) qui facilite la tâche des administrateurs réseau et système pour documenter leur réseau.
Nous avons les aspects suivants couverts dans le logiciel au moment de la rédaction (avril 2012):
Vous pouvez en savoir plus ici et nous apprécierions vos commentaires.
Pour plus de tutoriels sur comment/quoi documenter, il y a networkdocumentation.com .
Pour quelques bons exemples, voir ratemynetworkdiagram.com . par exemple. Celui-ci est assez bon , et celui-ci est génial ;).
Approche documentant un réseau en tant que développeur approche du développement d'un système ...
Tenez compte des exigences - cela a été bien noté ci-dessus, mais considérez que l'OMS va consulter le doc-o et POUR QUEL BUT. Les auditeurs rechercheront et liront différents artefacts qu'un SysAdmin homologue.
Faire de la maintenance de documents - de nombreuses personnes ont mentionné la valeur des diagrammes et des cartes, et en tant que penseur visuel, je suis entièrement d'accord. MAIS ces choses peuvent être invalidées par un seul acte d'ajout/suppression d'un hôte. Pensez au "bon niveau" de doc-o - celui que votre groupe peut réellement maintenir.
Datez tout et incluez des notes indiquant POURQUOI vous avez configuré le réseau comme vous l'avez fait. Beaucoup, beaucoup de gens oublient d'inclure une date - mais la DATE fournit un pointeur sur l'histoire du réseau. Inestimable pour la résolution de problèmes et il atténue la mise à jour inhérente de la plupart des diagrammes de réseau.
Déchargez la documentation dans des "processus" - plusieurs fois, des procédures de construction/déploiement solides et bien conçues finissent par rationaliser la "documentation réseau" car les détails de la configuration et de la dénomination des machines sont mieux décrits dans les procédures.
À retenir: la documentation sur l'approche en tant que "système"; elle doit apporter de la valeur dès le premier jour et comporte une responsabilité inhérente à son maintien.
Sur notre site, nous utilisons plusieurs systèmes pour documenter nos propres réseaux et ceux de nos clients. Nous avons essayé et échoué avec beaucoup de techniques/outils qui n'ont pas évolué, mais maintenant, nous sommes tout à fait prêts avec les éléments suivants:
Si l'on traite avec beaucoup de réseaux IP, phpIP pourrait être une solution IPAM appropriée.
Généralement, vous disposez de différents niveaux de détails similaires aux abstractions dans la documentation de conception de logiciels. Vous documentez également les pratiques/procédures/configuration générales des appareils. Mots de passe administratifs, le cas échéant.
Dans une situation idéale, presque tout ce dont la prochaine personne peut avoir besoin est facilement accessible et documenté entre vos documents de directives et de procédure + les schémas de configuration du réseau.
À mon avis, les documents de lignes directrices et de procédures devraient être centralisés où que se trouvent tous les documents informatiques, et les diagrammes de réseau peuvent avoir leur propre structure de dossiers pour plusieurs emplacements.
Dans le cas de nombreux sites satellites comme un Walmart/Targer/Home Depot, vous auriez un document générique pour toutes les succursales, puis quelques documents détaillés de la société sur les interconnexions du bureau principal, puis vous pourriez plonger dans les documents LAN du bureau.
Je suggère http://opennetadmin.com . Il fait bon nombre des choses que les gens ont suggérées dans d'autres commentaires.
Cartographier et documenter votre réseau peut être un bon moyen de transférer les informations nécessaires. MS Visio est un outil de diagramme, mais il est statique et vous devez y consacrer beaucoup de temps. J'ai trouvé que NetBrain est un outil de diagramme de réseau idéal pour ce faire. Il peut documenter le réseau instantanément et la documentation peut être exportée vers Visio ou Word. Je peux personnaliser le contenu que je veux tout en documentant mon réseau. Le contenu personnalisé comprend:
Vous pouvez essayer de documenter votre résea sur le site Web.
Comme mentionné, cela dépend d'un certain nombre de facteurs ...
Mon objectif était d'avoir suffisamment de documentation pour que je puisse (conceptuellement, au moins) tout remettre à un collègue et dire "à bientôt dans 3 semaines", et savoir que tous les détails importants étaient là.
Je n'ai jamais réussi à le faire complètement, mais je visais à documenter tous les principaux processus de routine - comment les serveurs étaient installés, comment et ce qui était surveillé, la configuration et la suppression des comptes, la sauvegarde, etc.
Il n'est généralement pas documenté, mais si vous êtes gentil, vous le faites généralement dans un programme comme Visio ou un équivalent open source. Les informations les plus importantes sont les équipements connectés à quoi et les mots de passe pour toute console de gestion. Le reste peut généralement être deviné.
Dans ma carrière précédente en tant que responsable informatique, mon classeur de documentation comprenait un diagramme Visio de tous les appareils, une liste des allocations de plage d'adresses IP, toutes les clés de produit pour Windows/Office/Acrobat, des instructions sur ce qui doit être installé sur de nouveaux des ordinateurs avec des instructions étape par étape, un inventaire complet du matériel jusqu'au niveau des composants et enfin la liste des numéros de téléphone d'urgence: assistance technique du FAI, assistance technique du fabricant du routeur, etc.
J'utilise des outils comme Microsoft Visio ou WhatsUp Gold pour cartographier la topologie du réseau si cela aide.
MS Visio est un bon moyen de documenter un réseau, mais ce n'est pas une solution gratuite. Gliffy est un produit sympa si vous cherchez à garder vos coûts bas.
Les diagrammes de réseau typiques montrent comment les informations circulent à travers vos appareils (et généralement vers Internet). Ainsi, vous devriez avoir des informations dans votre diagramme sur l'emplacement de vos ordinateurs, imprimantes, WAP, téléphones IP (le cas échéant), commutateurs et routeurs et comment ils sont connectés. Les adresses IP peuvent également être incluses avec le nom de votre appareil. Cela est utile si vous souhaitez consulter votre diagramme pour obtenir des informations à la volée.