Aus Linux-Magazin 08/2017

Best Practices – Folge 9: Der sichere Weg zur Dokumentation

© Jean-Marie Guyon, 123RF

Irgendwann muss jeder Admin eine IT-Dokumentation anfertigen. Das Linux-Magazin demonstriert, wie er dabei mit sechs einfachen Schritten erfolgreich ist.

Wie soll man eine Dokumentation beginnen? Schon drohen sich Berge an Komplexität aufzutürmen. Schnell soll es auch noch gehen, denn der Admin schleppt die Aufgabe schon einige Zeit mit sich herum. Und, bitte, es soll nur ein einmaliger Aufwand sein.

Kann es dafür ein Patentrezept geben? Ist nicht jedes Unternehmen, jede IT-Abteilung verschieden und braucht individuelle Leitlinien für Umfang und Detailierungsgrad? Ein Rechenzentrumsbetreiber unterliegt schließlich anderen Vorschriften als ein Anwender im öffentlichen Bereich. Der Admin eines Mittelständlers hat mit Sicherheit andere Sorgen als der eines Cloudproviders.

Trotz allem gibt es eine logische Reihenfolge beim Dokumentieren, bei der die Schritte aufeinander aufbauen und sich nicht wiederholen. Diese Schrittfolge wollen dieser und die nächsten Beiträge der Best-Practices-Serie vorstellen. Selbst wer einen der dabei aufgeführten Punkte nicht auf seiner Agenda hat, sollte die hier vorgestellte Methode im Rahmen eines Pilotprojektes zumindest einmal ausprobieren.

Schritt 1: Infrastruktur dokumentieren

Wer mehrere Standorte oder auch nur Räume zu betreuen hat, kennt die Misere: Wo ist denn bloß …? Wo etwas steht, ist für die meisten Nutzer einer Dokumentation eine Kernfrage. Der Standort spielt zudem für alle späteren Dokumentationsaufgaben eine wichtige Rolle. Deshalb ist es klug, ihn von Beginn an festzulegen. Diese Information ist relativ statisch, Änderungen gibt es selten. Die Zeit für diesen Schritt ist daher gut investiert.

Wer sich eine Dokumentation vornimmt, sollte also gleich die nächste Inventur zum Anlass nehmen, einen aktuellen Standortüberblick zu erarbeiten. Vieles dokumentiert der Admin dabei zum ersten und letzten Mal, versprochen! Als Prinzip dabei gilt: Jeder Standort wird nur einmal dokumentiert. Standorte in diesem Sinn können sein:

  • Ein Chassis (für Einschübe),
  • ein Rack (in dem Chassis oder Server eingebaut sind),
  • ein Arbeitsplatz (mit dem Geräte verbunden sind),
  • ein Raum (mit Racks oder Arbeitsplätzen),
  • ein Stockwerk (in dem Räume sind),
  • ein Gebäude (in es mehrere Stockwerke gibt),
  • ein Campus (in dem Gebäude stehen),
  • eine Stadt (in der sich Gebäude oder Campus befinden),
  • ein Bundesland,
  • ein Staat.

Nicht immer werden alle Ebenen gebraucht. Eine rudimentäre Variante, zum Beispiel für eine reine Rechnerraum-Konfiguration, könnte aussehen wie in Abbildung 1.

Abbildung 1: Racks stehen in einem Raum und Räume befinden sich in einem Gebäude. Alles andere wird anfangs weggelassen.

Abbildung 1: Racks stehen in einem Raum und Räume befinden sich in einem Gebäude. Alles andere wird anfangs weggelassen.

Da kein Element doppelt angelegt wird, darf die einmalige Dokumentation etwas mehr Mühe kosten: Neben dem Namen empfiehlt es sich, weitere Eigenschaften zu erfassen: die genaue Adresse, die Ansprechpartner (für Zutritt oder Alarmierung), eine Telefonnummer der Nebenstelle im Rechnerraum und so weiter. Wer dokumentiert, denke daran, dass sich im schlimmsten Fall Personen zurechtfinden müssen, die noch nie in den Räumlichkeiten waren!

Wie soll der Verantwortliche mit fehlenden Angaben umgehen? Viele Dokumentationsprojekte haben Startprobleme: Es gibt keine eindeutige Bezeichnung von Räumen, keine Raumnummern. Daher kann vermeintlich mit der Dokumentation der Standorte nicht fortgefahren werden. Das Projekt scheint von Anfang an festzustecken, aber auf eine Nummernvergabe irgendwann später darf man nicht warten!

Im Zweifel ist es besser, eine Nomenklatur zu erfinden, denn der Ernstfall wartet auch nicht auf das Raumnummern-Projekt. Der Admin kann stattdessen Aliasnamen verwenden und eine sprechende Erklärung in ein Bemerkungsfeld schreiben (“Zweiter Raum rechts neben Lift im ersten Stock, Raumnummer unklar”). In Serverräumen lässt sich an der Tür-Innenseite ein Etikett anbringen, sollte das außen untersagt sein: “Sie befinden sich im Raum mit der IT-internen Bezeichnung # r1105.”

Kommunikation ist alles

Die Auszeichnung von dokumentierten Objekten sollte immer unzweideutig sein. Wer sich für eine Datenbank als Plattform seiner zukünftigen IT-Dokumentation entschieden hat, muss sich darum meist keine Gedanken machen – in diesem Fall erzwingt bereits die Datenbank Eindeutigkeit. Sind jedoch Excel, Wiki, Word und Visio die Werkzeuge der Wahl, obliegt es dem Dokumentator, eine eindeutige ID zu vergeben: Eine unternehmensweit eindeutige Laufnummer ist nicht nur sinnvoll, sondern notwendig.

Die Rede ist hier nicht von der Seriennummer eines Geräts oder von Hostnamen, diese Merkmale kommen in der Praxis, gewollt oder nicht, doppelt vor. Selbst doppelte MAC-Adressen sind dank Virtualisierung möglich. Der Admin muss sich also ein eigenes System der ID-Vergabe ausdenken. Klug gewählt wird damit auch der spätere Import in ein Datenbanksystem deutlich einfacher.

Mit den dokumentierten Standorten kann man schon eine Menge anfangen:

  • Raumpläne. Sie helfen sich zurechtzufinden. Mit Softwarehilfe lassen sich Bilder hinterlegen oder Pläne aus CAD-Programmen nutzen. Später möchte der Admin in die Pläne wahrscheinlich die genauen Standorte von Anlagen, Racks, aber auch die WLAN-Abdeckung einzeichnen.
  • Rack Management. Der Plan eines Racks ist oft Gold wert. Hier stößt man mit manuellen Methoden jedoch schnell an die Grenzen der Wartbarkeit, doch sicherlich gibt es Situationen, in denen sich gerade diese Darstellung anbietet.
  • Facility Management. Mit den Plänen lassen sich nicht nur Räume verwalten, 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.
  • Betriebliche Anlagen. Feuerlöscher, USV-Anlagen, Netzersatz- oder Klimaanlagen haben eins 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. Die Dokumentation sollte im Idealfall an diese Termine automatisch erinnern, ein Report, was im Folgemonat an Überprüfungen ansteht, erleichtert die Arbeitsplanung.
  • Verkabelungsmanagement. Oft ist es nötig, die Kabelverbindungen zu dokumentieren. Das ist vor allem beim Patchen eine große Hilfe bei der Beantwortung der immer wiederkehrenden Frage: Welche Strippe kann abgesteckt werden?

In der nächsten Folge geht es um die Dokumentation des Netzwerks.

DIESEN ARTIKEL ALS PDF KAUFEN
EXPRESS-KAUF ALS PDFUmfang: 2 HeftseitenPreis €0,99
(inkl. 19% MwSt.)
LINUX-MAGAZIN KAUFEN
EINZELNE AUSGABE Print-Ausgaben Digitale Ausgaben
ABONNEMENTS Print-Abos Digitales Abo
TABLET & SMARTPHONE APPS Readly Logo
E-Mail Benachrichtigung
Benachrichtige mich zu:
0 Kommentare
Älteste
Neuste Beste Bewertung
Nach oben