Documentatie hoe gaan jullie daar mee om ?

[Ran-D]

Hoi allen,

ik zal maar meteen de deur in huis vallen, ik ben werkzaam bij een bedrijf waar laat ik het aardig brengen. Mijn voorganger qua documentatie zeer weinig heeft gedaan. Kortom er is gewoon geen documentatie alle documentatie zit in zijn hoofd. Op deze manier trachtte hij zich blijkbaar onmisbaar te maken. Wat de reden ook moge zijn ik zit met de gebakken peren. Ik heb de omgeving inmiddels redelijk onder controle en ben inmiddels al begonnen met een klein beetje documentatie. Ik zal het jullie eerlijk bekennen ik heb ook een broertje dood aan documenteren. Maar heb gezien deze nare ervaring toch maar besloten. De dingen op de correcte manier te doen. Ik heb natuurlijk wel wat opzetjes gemaakt voor mijn documentatie. Maar ik ben toch benieuwd naar de wijze waarop jullie met de documentatie omgaan. Wellicht dat ik iets over het hoofd heb gezien en daar van kan leren. Dus als jullie bv jullie voorbeeld sjablonen met mij zouden willen delen, dan zou ik dat zeer waarderen. Of bv een korte opsomming van jullie inhoudsopgave dat is eigenlijk ook al goed. Ik wil er gewoon zeker van zijn dat ik alle relevante gegevens in mijn documentatie verwerk. Daar kan de input van derden goed bij helpen. 2 weten immers meer als 1.

alvast bedankt

[RazorBlade72nd]

Meestal houd ik een mappenstructuur aan waarbij ik zo veel mogelijk de fysieke ICT structuur aanhoud. De eerste map gaat dus over het gebouw en bevat voornamelijk gegevens van contact personen die te maken hebben met (de toegang tot) het gebouw zoals gegevens van de technische dienst, beveiligingsbedrijf, etc. Daar binnen zit dan de map van de server ruimte. Hierin zitten meestal weer andere contact gegevens in zoals de leverancier van de airco, blusinstallatie, etc. Binnen de map van de server ruimte zitten weer wat meer mappen: servers, switches, UPS'en, etc. De map van de servers bevat vervolgens per server een map waarin een document zit over de eigenschappen van de server. Verder zit er in iedere server map een document met wijzigingen en storingen. Dit is een soort van logboek waarin ik bij houd wat er met de server is gedaan. Het zelfde geldt voor de netwerkapparatuur waarbij ik een map heb per switch, router, etc. Naast deze hele boomstructuur heb ik ook nog een map met procedures. Hierin staan standaard procedures van handelingen die je regelmatig verricht.

Ik realiseer me dat je soms in de knoei komt met deze structuur omdat sommige informatie op meerdere plaatsen moet komen te staan. Als dat zo is dan maak ik meestal een snelkoppeling. Ook zijn er zaken die gewoon niet helemaal passen in deze structuur. In dat geval probeer ik toch zo goed mogelijk een plaatsje te geven.

Meestal kom ik echter vaak maar tijdelijk ergens en dan kom ik in een team van beheerders en dan is er meestal al een documentatie structuur en dan houd ik die gewoon aan. Zeker als ik ergens net ben dan vind ik het belangrijkste als ik weet met wie ik te maken heb. Welke gebruikers maken gebruik van welke server, wie is de applicatiebeheerder/leverancier.

[Ran-D]

bedankt hier heb ik wat aan.

[DiedX]

Op dit moment ben ik bezig mijn eigen infrastructuur te documenteren. Ik heb op een fileserver een OneNote-document staan, en zorg ervoor dat ik vanaf mijn management-server daarbij kan.

Zodra ik wat gedaan heb, pak ik snel de OneNote-documentatie erbij, en schrijf ik wat ik gedaan heb. OneNote heeft een fijne structuur qua links.

Volgens mij is het trefwoord: gewoon doen. Maar ik (ook) weet als geen ander hoe lastig het is...

[hans_lenze]

Meestal een uitsplitsing in doelen.

Een document met alle contact gegevens van leveranciers en belangrijke personen binnen het bedrijf.
Een Visio tekening van het netwerk (met tabbladen voor logisch netwerk, rack-indeling, WAN verbindingen, VLAN inrichtingen enz).
Een Excel sheet met ALLE in gebruik zijnde IP adressen/reeksen binnen het netwerk (dit document is ook leidend als er een IP moet worden uitgedeeld).
Een Keepass database met de inloggegevens van belangrijke accounts, websites, beheer consoles, switches, alle service accounts, routers, firewalls, AD Restore Mode wachtwoorden voor elke DC, RADIUS shared secrets, certificaten inclusief private key enz.

In de Keepass database staat ook beschreven hoe externe toegang mogelijk is. Het wachtwoord van de Keepass database is bekend bij collega's/leidinggevenden in geval van calamiteiten en/of persoonlijk ongerief. Elke beheerder heeft een tweetal accounts, een persoonlijk account en een beheer account dat geen roaming profile heeft en standaard niet interactief kan inloggen op de werkplek van de beheerder (om misbruik te voorkomen). Het wachtwoord van de domein\administrator is in een envelop in de kluis geplaatst. Dit account is dus niet beschikbaar voor beheer.

Op de fileserver een map met documentatie met in elk geval per server een map met daarin een installatie beschrijving inclusief contact gegevens van de applicatie beheerders en leveranciers (applicatie beheerders mogen ook in deze map en zijn verantwoordelijk voor de inhoud hiervan). In deze map staat ook een logbestand dat bij het inloggen op de server automatisch wordt geopend. Simpelweg een log entry toevoegen en op save klikken is genoeg om de historie redelijk bij te kunnen houden. Gebruik van dit logbestand verschilt per applicatie beheerder maar neemt toe na problemen.

[MagicTempest]

Brr, ik word nu al bang van een excel document met IP adressen. Als je in een kleine omgeving werkt is dat misschien nog wel te doen, maar over het algemeen lopen die dingen altijd achter. Veel beter is een echt IPAM systeem. Iets wat actief bij kan houden welke IP adressen daadwerkelijk in gebruik zijn.

Kijk bijvoorbeeld eens naar Solarwinds IPAM. Deze gebruikt ICMP, SNMP en ARP tabellen om uit te zoeken welke adressen in gebruik zijn. Veel beter dan een excel document. Het kost echter vaak wel geld.

Met alle documentatie is belangrijk om eerst te kijken wat nodig is. Documenteer niet te weinig, maar ook niet teveel. Documentatie moet namelijk bijgehouden worden en als je teveel documenteert dan ben je uiteindelijk meer tijd kwijt aan het bijhouden van documentatie dan het daadwerkelijk wijzigen van de omgeving.

Documenteer complexe procedures ook aan de hand van checklists. (Dit kun je ook voor alle procedures doen en kan handig zijn in het geval van een nieuwe medewerker)

[seq_uence]

Het is belangrijk dat je bepaald wat je gaat documenteren, en hoe gedetailleerd je gaat documenteren.
Maak onderscheid in procedures en documentatie van een inrichting, bepaal de structuur. In het bepalen van een structuur kunnen procesbeschrijvingen ook leidend zijn, sterker nog dat zou de ideale situatie zijn.

Want je wilt uiteindelijk dat iemand die nieuw binnenkomt zijn informatie snel kan vinden, aan de hand van een proces kom je altijd op de goede plek uit.

De grootste uitdaging bij documenteren is het actueel houden, anders is het bij voorbaat al een verloren strijd. Versiebeheer en consequenct bijhouden is dan ook belangrijk.

Succes!

[Ran-D]

jongens nogmaals bedankt met jullie input. best grappig om te zien dat een ieder op een iets andere manier hier mee omgaat. en dat het toch goed werkt in jullie omgevingen. ik ga al jullie tips combineren en dan komt het wel goed hier.

[wiked]

Ik onderhoud een klein netwerk met een 15-tal pc's & 3 servers.
Deze documenteer ik met DIA. Vermits ik het niet kan veroorloven om hier veel geld aan uit te geven vind ik DIA eigenlijk best wel goed.

[Lunacy]

Ik onderhoud ook een aantal kleinere netwerken en maak telkens een dokuwiki aan per bedrijf.
Kan je makkelijk tabellen maken, zaken linken aan elkaar, afbeeldingen toevoegen etc ...
http://www.splitbrain.org/projects/dokuwiki