Über unsMediaKontaktImpressum
Peter Resch-Edermayr 16. August 2017

In sechs Schritten zur perfekten IT-Dokumentation

Irgendwann muss jeder IT-Administrator mit einer IT-Dokumentation starten. Je nach Dokumentationsplattform, die entweder dateibasierend ist oder auf einer Datenbank aufsetzt, ergeben sich schnell sowohl unterschiedliche Möglichkeiten der Anwendung, als auch Notwendigkeiten beim Setup: Denn früher oder später wird auch Ihre Dokumentation von mehreren Personen genutzt. Damit das Vorhaben gelingt, benötigen alle Beteiligten das gleiche Wissen, ähnliche Fähigkeiten – und ein paar organisatorische Regeln.

Bevor man beginnt, türmen sich schnell Berge an Komplexität auf, nachdem man diese Aufgabe schon einige Zeit mit sich herumschleppt. Nun soll es schnell gehen und, bitte, nur einmaliger Aufwand sein. Unternehmen und IT-Abteilungen sind  individuell und somit auch jede Anforderung an Umfang und Detailgrad der Dokumentation anders. Ihre Situation muss konkret analysiert werden, dann kann in Workshops ein Configuration Management Plan (CMP) erarbeitet werden. In diesem steht die Reihenfolge und der notwendige Detaillierungsgrad, zugeschnitten für Ihren Bedarf. Ein Rechenzentrumsbetreiber hat andere Vorschriften als der öffentliche Bereich, der Admin eines kleinen oder Mittelständischen Unternehmens hat andere Sorgen als der eines Cloud Providers.

Trotz allem gibt es eine logische Reihenfolge, die wiederkehrende Arbeitsschritte möglichst vermeidet. Diese werden Sie hier kennenlernen. Selbst wenn Sie einen der hier gebrachten Punkte nicht auf ihrer Agenda haben: Probieren sie es im Rahmen eines Pilotprojektes aus. Sie werden sehen: Der Bedarf ist früher oder später da.

Die sechs Schritte zur IT Dokumentation

  1. Die Infrastruktur
  2. Das Netzwerk
  3. Die Server
  4. Die Clients
  5. Spezialfall: Software und Lizenzen
  6. Anwendungen und IT-Services

1. Dokumentation der physischen Infrastruktur

Wenn Sie mehrere Standorte oder auch nur Räume zu betreuen haben, kennen Sie die Misere: Wo ist denn bloß…
? Da Sie für alle später folgenden Dokumentationsaufgaben öfters den Standort verwenden werden, ist es klug, diesen von Beginn an festzulegen. Die Information ist statisch, Änderungen finden selten statt. Daher ist die Zeit hier auch gut investiert. 
Nehmen Sie also Ihre nächste Inventur gleich zum Anlass, die Dokumentation aufzubauen und Sie bekommen als Ergebnis einen aktuellen Standortüberblick – und vieles dokumentieren Sie damit auch zum letzten Mal, versprochen!

Standortdokumentation leicht gemacht

Gehen Sie davon aus, dass Sie jedes Objekt, das einem Standort entspricht, nur noch genau einmal dokumentieren müssen. Alle anderen Objekte werden damit im Idealfall relational verbunden.

Das alles kann ein physischer Standort sein:

  • Ein Chassis (um Einschübe korrekt zu verorten)
  • Ein Rack (in dem Chassis oder Server eingebaut sind)
  • Ein Arbeitsplatz (mit dem Geräte verbunden sind)
  • Ein Raum (in dem z. B. Racks oder Arbeitsplätze sind)
  • Ein Stockwerk (in dem Räume sind)
  • Ein Gebäude (in dem mehrere Stockwerke sind)
  • Ein Campus (in dem Gebäude stehen)
  • Eine Stadt (in der Gebäude oder Campus sind)
  • Ein Bundesland
  • Ein Staat/Land

Die rudimentäre Variante, zum Beispiel für eine reine Rechnerraumkonfiguration, sehen Sie in Abb.2. Racks stehen in einem Raum und Räume befinden sich in einem Gebäude. Alles andere wird zunächst weggelassen.

Da jedes Element nur einmal angelegt wird, sollte man bei der einmaligen Dokumentation präzise sein: Die genaue Adresse, die Ansprechpartner (für Zutritt oder Alarmierung), eine Telefonnummer der Nebenstelle im Rechnerraum, usw. Denken Sie bitte an den Worst Case: Im schlimmsten Fall müssen nicht Sie sich zurechtfinden, sondern Personen, die unter Umständen noch nie in den Räumlichkeiten waren!

Wie mit fehlenden Angaben umgehen?

Viele Dokumentationsprojekte haben Startprobleme: Es gibt keine eindeutige Bezeichnung von Räumen, keine Raumnummern. Daher kann mit der Dokumentation der Standorte nicht fortgefahren werden. Das Projekt scheint von Anfang an festzustecken. 

Unser Tipp: Warten Sie nicht darauf, im Zweifel erfinden Sie eine Nomenklatur. Verwenden Sie Alias-Namen und schreiben Sie notfalls eine sprechende Erklärung in ein Bemerkungsfeld ("zweiter Raum rechts neben Lift im ersten Stock, Raumnummer unklar"). In Serverräumen können Sie, sollte es untersagt sein, außen Kleber anzubringen, auf die Türinnenseite ein Plakat kleben (s. Abb.3).

Bleiben Sie eindeutig!

Haben Sie sich für eine Datenbank als Plattform ihrer zukünftigen IT-Dokumentation entschieden, müssen Sie sich zumeist keine Gedanken um die primäre ID ihrer dokumentierten Objekte machen. Sind jedoch Excel, Wiki, Word und Visio die Werkzeuge der Wahl, obliegt die Aufgabe Ihnen und Ihrem Team: Eine unternehmensweit eindeutige Laufnummer ist nicht nur sinnvoll, sondern notwendig. Wir sprechen hier nicht von der Seriennummer eines Gerätes oder von Hostnamen – jede Form der Redundanz kommt in der Praxis, gewollt oder ungewollt, vor. Selbst doppelte Mac-Adressen sind "dank" Virtualisierung möglich, wir müssen uns also ein eigenes System der ID-Vergabe ausdenken. Klug gewählt, wird damit auch ein späterer Import in ein Datenbanksystem extrem vereinfacht!

Wie kann es von hier aus weitergehen?

Mit den dokumentierten Standorten kann man schon eine Menge anfangen:


  • Raumpläne
: Zeichnen Sie die geschaffene Raumstruktur in Pläne ein, um sich zurechtzufinden. Software kann das entweder mit hinterlegten Bildern oder Plänen aus CAD-Programmen. Später werden Sie in die Pläne wahrscheinlich die genauen Standorte von Anlagen, Racks, aber auch die WLAN-Abdeckung einzeichnen wollen.

  • Rack-Management
: Ein Plan eines Racks ist oft Gold wert. Hier stößt man mit manuellen Methoden schnell an die Grenzen der Wartbarkeit, doch sicherlich gibt es Situationen, in denen man sich gerade diese Darstellung wünscht.

  • Facility Management
: Verwalten Sie nicht nur Räume, sondern auch Arbeitsplätze, Benutzer, Telefonnebenstellen, bis hin zur Inventur von Tisch, Stuhl und Feuerlöscher. Wobei anfangs das Hauptaugenmerk sicher auf wichtigen IT-Komponenten liegen sollte! 

  • Dokumentieren der betrieblichen Anlagen: 
Feuerlöscher, USV-Anlagen, Netzersatzanlagen, Klimaanlagen, etc. haben eines gemeinsam: Eine Prüfplakette, oft vom TÜV ausgestellt, die Auskunft darüber gibt, wann die nächste Überprüfung stattfinden muss. Teils sind versicherungstechnische, teils gesetzliche, oder einfach betriebliche Notwendigkeiten der Hintergrund, diese Termine nicht zu übersehen. Die Dokumentation sollte im Idealfall an diese Termine automatisch erinnern können, ein Report, was im Folgemonat an Überprüfungen einzuplanen ist, erleichtert die Arbeitsplanung.
  • Verkabelungsmanagement
: Oft ist es nötig, die Kabelverbindungen zu dokumentieren. Vor allem beim Patchen eine große Hilfe zur immer wiederkehrenden Frage: Welche Strippe kann abgesteckt werden? Unabhängig davon, ob Sie Strom- oder Netzwerkverbindungen abbilden wollen, stellt sich die Frage: ist das nun der richtige Zeitpunkt? Wir meinen: Nein. Später dazu mehr.

2. Das Netzwerk

Was brauchen wir mindestens, um eine pragmatische Netzwerkdokumentation zu schaffen, die einerseits nicht bis ins letzte Detail geht, die jedoch genügt, um zu einem späteren Zeitpunkt auf die Informationen zurückgreifen zu können?

Die IP-Netzwerke (OSI Layer 2 + Layer 3)

IP-Ranges werden als eigene Netze dokumentiert. Diese Netze wurden auch ausführlich geplant, mit großer Mühe umgesetzt und sind zumeist auf veralteten Visio-Grafiken zu finden. Eine dateibasierte Dokumentation wird gerne bei Neuprojekten durchgeführt, bei Änderungen wird hingegen gerne auf die Aktualisierung verzichtet. Zukünftige Anwendungsfälle profitieren jedoch von aktueller Information. Später werden weitere Netzwerkgeräte – egal ob physisch oder virtuell – mit diesen Netzen verbunden. Als Ergebnis erhalten Sie eine Gesamtübersicht über verwendete bzw. freie IP-Adressen, eine Übersicht über verwendete Ports, und mit ein paar Scripts die Möglichkeit, verschiedene Abfragen und Automatismen direkt aus der Dokumentation auf den Geräten durchzuführen (PING, NSLOOKUP, weitere Scripts, ...).

Die VLANs

VLANs findet man in immer mehr Organisationen und diese bedürfen einiger Organisation und Dokumentation, will man den Überblick über die korrekte Konfiguration der Router und Endgeräte behalten. VLANs werden mit den entsprechenden IP-Netzen verbunden. 

Die Router

Die Router bzw. Layer und Router/Switches schließlich werden in die bereits dokumentierten Racks "eingebaut" und so in der Dokumentation verortet. Auf den richtigen Höheneinheiten eingetragen, wächst nach und nach die Rack-Dokumentation. Ebenso verbinden Sie nun über die richtigen Ports die Netzwerke miteinander.

Welche Abzweigungen gibt es von hier aus?

Mit den nun dokumentierten Netzwerken kann es wie folgt weitergehen:


  • WAN-Verbindungen
: Vor allem bei Störungen ist es nötig, schnell die richtigen Ansprechpartner und Hotline-Nummern bei der Hand zu haben.
  • Verträge
: mit Providern, inkl. Service Level-Vereinbarungen und der vereinbarten Entstörungsprozesse. Diese können als Anhang bzw. Beilage verwaltet werden.  

  • Monitoring-Anbindung
: Verbinden Sie Ihr bestehendes Netzwerkmonitoring oder bauen Sie ein neues auf. Ihre Dokumentation unterstützt Sie dabei:
    • Zugriff auf den Livestatus aus der Dokumentation "auf Knopfdruck".
    • Unterstützung bei der Konfiguration des Monitoring-Systems durch vorgehende Dokumentation

3. Dokumentation der Server

Jeder hat sie, doch selten sind sie ausreichend dokumentiert. Der Detailgrad ist anfangs nicht wichtig. Lieber weniger und aktuell, als viel und veraltet! Aber um das Dokumentieren der Server kommen Sie nicht herum, denn früher oder später kommen folgende Situationen auf Sie zu:

  • Ausfall bzw. Notfall
: So selten dieser Fall vorkommt, die Serverkonfiguration muss auf jeden Fall dokumentiert werden. Denn nicht immer ist es mit einer Rücksicherung getan. Eine aktuelle Notfalldokumentation vorzuhalten, wird mittlerweile in vielen Branchen und Organisationen vorgeschrieben.

  • Migrationen, Updates, Virtualisierung
: Sind größere Veränderungen in der Server- und Applikationslandschaft geplant, benötigt man sogar zwei Dokumentationen: jene des IST-Standes (bisherige Server) und auch eine des zukünftigen SOLL-Zustands (neue Server).

  • Dokumentation von Applikationen und Services
: Diese laufen auf den Servern. Daher ist es ratsam, die Server bereits im Datenbestand zu haben.

Mit dokumentierten Servern können Sie also sowohl in die Tiefe der Details gehen, als auch weiter in die Welt der Services und Applikationen.

Wir schlagen als Reihenfolge wieder vor, jene Objekte zuerst zu dokumentieren, die eventuell wieder verwendet werden, also virtuelle Geräte erst nach der Hardware. Und Cluster, die aus mehreren Servern bestehen, erst danach.

Was soll man auf jeden Fall bei Servern dokumentieren?

Gehen wir vom Worst Case aus: Ein Server muss neu aufgebaut werden, um eine spezielle Funktion im Netzwerk zu erfüllen. Das Backup kann nicht verwendet werden und jene Person, die den Server aufgebaut hat und laufend wartet, ist ebenfalls nicht verfügbar. Nun muss mit Personal improvisiert werden, doch die handelnden Personen müssen in kürzest möglicher Zeit die Dokumentation lesen, verstehen und danach handeln können.

Neben der Hardwarekonfiguration, physisch oder virtuell, muss daher einmal der Standard, ab dem verändert wurde, bekannt sein. Danach sind die individuellen Eigenschaften des Gerätes hervorzuheben. Alles, was nicht dem Standard entspricht um eine spezielle Funktion zu erreichen, ist es wert, dokumentiert zu werden.

  • Hardwaredetails
  • Standort: durch unsere Vorarbeit mit 2 Mausklicks getan
  • Netzwerkanbindung: ebenso einfach
  • Ansprechpartner
  • Speicherkonfiguration
  • Betriebssystem, Software, Versionen: 
Spätestens ab diesem Punkt ist es sinnvoll, über ein automatisches Discovery nachzudenken. Software in der jeweils aktuellen Version manuell zu dokumentieren ist aufwändig, die Zeit benötigen wir an anderer Stelle!
  • Storage-Anbindung: Ebenso keine einfache manuelle Tätigkeit, wenn die Daten nicht automatisiert geliefert werden können.

Die detaillierte Serverdokumentation

Im Folgenden ein paar Ideen, was man noch dokumentieren könnte:

  • verwendete Administrative Accounts (lokal oder im Directory)
  • Verwendete Passwörter (mit Link zum Passwortsafe-Eintrag bzw. Suchkriterium, oder verschlüsselt abgelegt)
  • Anpassungen von Dateien - am besten sind die Dateien oder eben die Abweichungen des Standards in den Dateien in Griffweite der Dokumentation abgelegt
  • Anpassungen der Konfiguration (betriebssystem-eigene Firewall?)
  • Installierte Software (am besten mit Screenshots der Installation für alle Einzelschritte)
  • Installierte Lizenzen (am besten gleich mitdokumentiert, auch hier ist die Erinnerung an das nahende Ablaufdatum ein wesentlicher Mehrwert!)
  • Veränderungen an der Konfiguration der installierten Software – entweder mit Screenshots oder mit Konfigurationsdateien. Chronologisch abgelegt hilft es nachzuvollziehen, welche Schritte zur aktuellen Konfiguration geführt haben.

Das waren die ersten 3 Schritte der perfekten IT-Dokumentation. Die Bereiche "Clients", "Software und Lizenzen" und "Anwendungen und IT-Services" beschreibt Peter Resch-Edermayr im zweiten Teil >>.

Autor

Peter Resch-Edermayr

Peter Resch-Edermayr arbeitet seit über 20 Jahren in unterschiedlichen Rollen an der Ausgestaltung von IT-Prozessen. Die wiederkehrenden Situationen in seinen ITSM-Projekten verarbeitet er zu online-Artikeln.
>> Weiterlesen
Das könnte Sie auch interessieren
Kommentare (2)
  • Konrad Voigt
    am 15.08.2022
    Sehr guter Beitrag! Mit welchem Programm wurden die Grafiken modelliert ?
    • Peter Resch-Edermayr
      am 25.08.2022
      Danke!
      Das Programm heißt yEd vom deutschen Hersteller yworks.com. Es ist frei erhältlich.
      Damit geht das Modellieren von Graphen und Prozessen leicht von der Hand.
      Beste Grüße und gutes Gelingen!

Neuen Kommentar schreiben