Vraag Hoe documenteer je een netwerk?


Ik weet niet zeker hoe ik deze vraag moet stellen, omdat ik niet in het veld ben. Stel dat je een netwerkbeheerder bent en je verlaat je baan. Hoe weet de nieuwe man waar te beginnen?


64
2018-05-26 21:18


oorsprong


Ook: met documentatie kunt u op een dag vakantie nemen en het bedrijf beschermen als u te ziek of gewond raakt om te werken. - Kara Marfia


antwoorden:


Het hangt onder meer af van de grootte van het netwerk, het aantal gebruikers, het aantal knooppunten (computers, servers, printers, enz.) En de grootte van uw IT-personeel.

Het hangt ook af van je doel. Documenteert u het netwerk voor trainings- en onderhoudsdoeleinden, verzekering / verliespreventie, enz.?

Persoonlijk documenteer ik mijn netwerken op zo'n manier dat ik weet dat ik ontbrekende informatie kan ontlenen op basis van wat is gedocumenteerd. Vanuit een praktisch standpunt is er een punt van afnemende opbrengsten wanneer uw documentatie te korrelig wordt.

Een goede vuistregel die ik gebruik, is dat er documentatie op een bekende locatie moet zijn die zo grondig is dat als ik vanavond door een bus wordt geraakt, een andere beheerder het kernnetwerk kan laten draaien terwijl hij / zij de ontbrekende stukken vult over de komende paar dagen / weken.

Hier is een overzicht van wat ik denk dat het belangrijkste is over een van mijn netwerken. Voor de goede orde is dit een winkel met alleen Windows met ongeveer 100 gebruikers en 5 kantoren.

  • Beheerdersreferenties voor alle servers. Dit moet uiteraard veilig worden bewaard.
  • IP-adressen en NetBIOS-namen voor elk knooppunt op het netwerk met een statisch IP-adres, inclusief servers, werkstations, printers, firewalls, routers, switches, etc.
  • Basisinformatie over de serverhardware, zoals servicelabels of gelijkwaardig, totale schijfcapaciteit, totale RAM, enz.
  • Belangrijke rollen van elke server, zoals domeincontroller, bestandsserver, afdrukserver, terminalserver, enz.
  • Locatie van back-upbanden / stations.
  • Informatie over de accountnummers en referenties voor services zoals externe spraak- en gegevensproviders op kantoor.
  • Externe DNS voor websites en routing.

Als er iets vreemds aan de hand was met een setup of workflow die voor een nieuwe beheerder niet meteen duidelijk zou zijn, zou ik er ook een korte "korte" over schrijven.


55
2018-05-26 21:51



+1 voor het hit-by-a-bus-scenario. - romandas


Ik vind dat het het beste is om al het volgende op te nemen:

  • Probleem: een algemeen overzicht in alinea-indeling, dat helpt bij het eerste grote beeld en ook de evolutie in de tijd kan beschrijven
  • Tabellen: Tabellarische lijsten, hetzij adres-ingetoetst, omgeving-ingetoetst, of machine-ingetoetst (bij voorkeur al het bovenstaande)
  • Diagrammen: diagrammen met meerdere detailniveaus zijn absoluut nodig. Op elk netwerk van behoorlijke omvang is het gewoon onmogelijk om alles op één pagina netjes te vangen en het gemakkelijk verteerbaar te maken. U wilt één diagram op mondiaal niveau, met infrastructuurapparaten (routers, switches, tunneleindpunten, enz.) En nog een aantal voor de rekenbronnen die door elk van die routers of eindpunten worden gebruikt.

Aanvullende opmerkingen over diagrammen ... Geografische distributie is een eenvoudige manier om te segmenteren, maar u hebt ook logische weergaven nodig op basis van de installatiefunctie. Label ook als een gek, en maak volledig gebruik van lettertypen en kleuren.


10
2018-05-26 21:29





De meest effectieve en grondige manier om dit proces te starten is om het te bouwen vanuit een scenario voor noodherstel, bijvoorbeeld het gebouw ging in vlammen op en alles wat we hebben zijn de externe back-ups. Wat moeten we eerst kopen en hoe moet dit worden geconfigureerd?

Kyle heeft al veel details gegeven, maar ik vind dat de DR-aanpak me helpt om de dingen één voor één te nemen.


5
2018-05-27 12:52





Kyle's antwoord is goed advies. Op zijn minst een minimum, je zou waarschijnlijk wegkomen met vermelding van:

  • Servers (inclusief hostnamen, IP's en rollen)
  • Netwerkhardware (switches, routers, firewalls)
  • Hoofdwachtwoordarchieven (domeinwachtwoorden, admin-wachtwoorden)
  • Een globaal document dat het netwerkbeleid en eventuele vreemde opstellingen schetst (neem hier eventuele uitschieters op, zoals machines die geen deel uitmaken van het domein of de domeinen)

4
2018-05-27 01:43





Waar ik werk - we hebben hetzelfde probleem ondervonden toen ik hier voor het eerst begon. Naarmate het aantal servers en services toeneemt, vindt u steeds meer en meer verouderde documentatie, en daarmee komt de onvermijdelijke houding dat medewerkers geen vertrouwen hebben in documentatie, in ieder geval technische documentatie over servernamen, servergroepen, netwerken, enz.

We zijn begonnen met het ontwikkelen van een open-sourceproject genaamd hotwire dit behandelen...

  • Voorraadsysteem (servers, netwerken, enz.)
  • Server Builds - RHEL Kickstart, SuSE AutoYaST, (TODO: Debian Preseed, Solaris Jumpstart)

Door het voorraadsysteem te combineren met het buildsysteem, hebben we ervoor gezorgd dat de inhoud van de database consistent is met wat zich in onze datacenters bevindt, omdat we nu eerst de gegevens in de inventaris moeten invoeren om de servers te kunnen bouwen .

Een clientprogramma (funcwire) wordt vervolgens op alle servers geïnstalleerd (als onderdeel van het bouwproces), dat vervolgens de serverhardware dynamisch in de gaten houdt, zoals gerapporteerd door python-dmidecodeen wat er in de inventaris staat, dus als er iets verandert, zullen de admins dit onmiddellijk weten.

We hebben vervolgens ons wiki-systeem geïntegreerd, zodat elke server, rack, project, hardwaremodel, enz. In hotwire rechtstreeks links maakt naar de juiste wiki-pagina.

We hebben daarom onze servers / netwerk / etc "gedocumenteerd" met hotwire + een wiki (we gebruiken hier samenvloeiing, maar elke fatsoenlijke wiki zal het doen). (Merk echter op dat zodra de servers zijn gebouwd - hotwire deze op geen enkele manier wijzigt - doorlopend beheer wordt gedaan via cfengine).


4
2018-05-27 07:35



"Howtire" -link werkt niet; kan het ook niet via google vinden. Is het dood? - mark


Ik gebruik MikroTik Dude om dingen automatisch in kaart te brengen, dit is een geweldige applicatie gezien het gratis is. Het kan ook de huidige status controleren. Dude-webpagina


4
2018-05-27 08:29





Over het algemeen heb je een paar verschillende detailniveaus die vergelijkbaar zijn met abstracties in documentatie voor softwareontwerp. U documenteert ook algemene apparaatpraktijken / procedures / configuratie. Administratieve wachtwoorden zoals van toepassing.

In een ideale situatie is bijna alles wat de volgende persoon nodig heeft gemakkelijk toegankelijk en gedocumenteerd tussen uw richtlijnen en proceduurdocumenten + netwerklay-outdiagrammen.

De richtlijnen en proceduredocumenten moeten naar mijn mening gecentraliseerd zijn waar alle IT-documenten zich bevinden en de netwerkdiagrammen kunnen hun eigen mappenstructuur hebben voor meerdere locaties.

In het geval van veel satellietsites zoals een Walmart / Targer / Home Depot zou je een generiek document hebben voor alle filialen, en vervolgens een aantal gedetailleerde documenten van het hele bedrijf van de belangrijkste kantoorinterconnecties en dan zou je kunnen duiken naar Office LAN-documenten.


2
2018-05-26 21:28





Aanpak documenteren van een netwerk als ontwikkelaar benadert de ontwikkeling van een systeem ...

  • Overweeg de vereisten - dit is hierboven goed opgemerkt, maar overweeg WIE de doc-o gaat raadplegen en voor WELK DOEL. Auditors zullen verschillende artefacten zoeken en lezen dan een peer SysAdmin.

  • Doc-onderhoud doen - veel mensen hebben de waarde van diagrammen en kaarten genoemd, en als visueel denker ben ik het daar volledig mee eens. MAAR die dingen kunnen worden ongeldig gemaakt met een enkele handeling van het toevoegen / verwijderen van een host. Denk aan het 'juiste niveau' van doc-o - een die uw groep eigenlijk kan behouden.

  • Geef alles een datum en voeg opmerkingen toe over WAAROM je het netwerk hebt geconfigureerd zoals je dat hebt gedaan. Veel mensen vergeten een datum op te geven, maar de DATUM biedt een verwijzing naar de geschiedenis van het netwerk. Van onschatbare waarde voor het oplossen van problemen en het vermindert de inherente out-of-dateness van de meeste netwerkdiagrammen.

  • Offload documentatie in "processen" - vele malen solide en goed gemaakte build / deployment-procedures leiden uiteindelijk tot stroomlijning van "netwerkdocumentatie" omdat de details van machineconfiguratie en naamgeving beter worden beschreven in de procedures.

Key Takeaway: aanpak documentatie als een 'systeem'; het moet vanaf dag 1 waarde bieden en het heeft een inherente verantwoordelijkheid om het te onderhouden.


2
2018-05-27 16:58





Op onze site gebruiken we verschillende systemen om onze eigen en klantennetwerken te documenteren. We hebben geprobeerd en faalden met heel veel technieken / tools die niet schaalden, maar nu zijn we behoorlijk ingesteld op het volgende:

  • DokuWiki voor tips, gedetailleerde beschrijvingen van configuraties en
  • Tabellen (Patchport / MAC / IP / Hostnaam / Rol / Admin-Lookup voor alle apparaten, Netwerken / VLAN's / VPN's, Hardwareoverzicht, enz.)
  • RSS om veranderingen van wiki-pagina's te verspreiden
  • Visio (het beste bedrijf dat M $ ooit heeft gekocht ...) om diagrammen van alles te tekenen
  • KeePass voor wachtwoorden, inclusief aanmeldingen voor leverancierskaartsystemen
  • RackTables om te documenteren waar de apparaten zich bevinden en worden gepatcht
  • Ticket-systeem, toegankelijk voor klanten
  • WhatsUp Gold en andere hulpmiddelen voor monitoring en rapportage
  • Mailinglijsten om mensen up-to-date te houden

Als je met veel IP-netwerken omgaat, phpIP kan een geschikte IPAM-oplossing zijn.


2
2017-07-13 08:46