it-swarm-eu.dev

Comment documentez-vous un réseau?

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?

66
Esteban Araya

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.

  • Informations d'identification de l'administrateur pour tous les serveurs. Évidemment, cela devrait être sécurisé.
  • Adresses IP et noms NetBIOS pour tout nœud du réseau avec une adresse IP statique, y compris les serveurs, les postes de travail, les imprimantes, les pare-feu, les routeurs, les commutateurs, etc.
  • Informations de base sur le matériel du serveur, telles que les étiquettes de service ou équivalent, la capacité totale du disque, la RAM totale, etc.
  • Rôles principaux de chaque serveur, tels que contrôleur de domaine, serveur de fichiers, serveur d'impression, serveur Terminal Server, etc.
  • Emplacement des bandes/lecteurs de sauvegarde.
  • Informations sur les numéros de compte et les informations d'identification pour des services tels que les fournisseurs de voix et de données de bureau à distance.
  • DNS externe pour les sites Web et le routage.

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.

55
Kyle Noland

Je trouve qu'il est préférable d'incorporer tous les éléments suivants:

  • Prose: Un aperçu général sous forme de paragraphe, qui aide à une vue d'ensemble initiale et peut également décrire l'évolution au fil du temps
  • Tableaux: listes tabulaires, à clé d'adresse, à environnement ou à machine (de préférence toutes les réponses ci-dessus)
  • Diagrammes: vous avez absolument besoin de diagrammes avec plusieurs niveaux de détail. Sur n'importe quel réseau de taille décente, il est tout simplement impossible de tout capturer sainement sur une seule page et de le rendre facilement digestible. Vous voulez un diagramme au niveau global, avec des périphériques d'infrastructure (routeurs, commutateurs, points de terminaison de tunnel, etc.), et un autre plusieurs pour les ressources de calcul dirigées par chacun de ces routeurs ou points de terminaison.

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.

11
Adam D'Amico

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.

5
Kara Marfia

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 ...

  • Système d'inventaire (serveurs, réseaux, etc.)
  • Builds de serveurs - RHEL Kickstart, SuSE AutoYaST, (TODO: Debian Preseed, Solaris Jumpstart)

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).

4
Xerxes

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

4
Sam Mackrill

La réponse de Kyle est un excellent conseil. À un strict minimum, vous pourriez probablement vous en sortir avec la liste:

  • Serveurs (incluent les noms d'hôte, les adresses IP et les rôles)
  • Matériel réseau (commutateurs, routeurs, pare-feu)
  • Archives des mots de passe principaux (mots de passe de domaine, mots de passe administrateur)
  • Un document approximatif décrivant les politiques du réseau et toutes les configurations étranges (inclure ici toutes les valeurs aberrantes telles que les machines qui ne font pas partie du ou des domaines)
4
kdmurray

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):

  • Documentation du centre de données.
  • Détails de l'appareil (y compris les détails HW/OS)
  • Gestion des adresses IP
  • Mappage des dépendances des applications
  • Relations avec les appareils - des bâtiments aux serveurs virtuels/lames.

Vous pouvez en savoir plus ici et nous apprécierions vos commentaires.

2
Raj J

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 ;).

2
Dan

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.

2
Netais LLC

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:

  • DokuWiki pour des conseils, des descriptions détaillées des configurations et
  • Tableaux (Patchport/MAC/IP/Nom d'hôte/Rôle/Recherche Admin pour tous les appareils, Réseaux/VLAN/VPN, Présentation du matériel, etc.)
  • RSS pour diffuser les modifications des pages wiki
  • Visio (meilleure entreprise M $ jamais achetée ...) pour dessiner des diagrammes de tout
  • KeePass pour les mots de passe, y compris les connexions pour les systèmes de tickets des fournisseurs
  • RackTables pour documenter l'emplacement et le patch des périphériques
  • Système de ticket, accessible aux clients
  • WhatsUp Gold et autres outils de surveillance et de génération de rapports
  • Listes de diffusion pour tenir les gens à jour

Si l'on traite avec beaucoup de réseaux IP, phpIP pourrait être une solution IPAM appropriée.

2
PEra

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.

2
sclarson

Je suggère http://opennetadmin.com . Il fait bon nombre des choses que les gens ont suggérées dans d'autres commentaires.

1
Matt P

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: 

  1. Contenu lié à l'inventaire tel que le numéro de série, la version du système d'exploitation, etc. 
  2. Contenus liés à la conception tels que le routage dynamique, la QoS, le filtrage du trafic 
  3. Contenu lié au chemin de trafic… 
  4. Contenu lié au fichier de configuration 
  5. Diagramme

Vous pouvez essayer de documenter votre résea sur le site Web.

1
user64604

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à.

  • Mots de passe pour tous les serveurs et périphériques (commutateurs, imprimantes, etc.)
  • Mots de passe pour tous les sites requis pour l'enregistrement - FAI, enregistrement de nom de domaine, garanties matérielles, autorités de certification, etc.
  • Carte des adresses IP utilisées - interne, externe, dmz, blocs de DHCP, etc.
  • Détails de chaque serveur: éléments standard comme le numéro de série, la quantité de disque, le ram, etc., mais nous avons également conservé un journal de tout ce qui a été fait dans la boîte, en commençant par les notes de configuration (o/s et installation de l'application), puis ll configuration et modifications ultérieures.

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é.

1
jedberg

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.

1
Scott

J'utilise des outils comme Microsoft Visio ou WhatsUp Gold pour cartographier la topologie du réseau si cela aide.

1
user3943

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.

0
zewsk