Über unsMediaKontaktImpressum
Peter Resch-Edermayr 16. August 2017

In sechs Schritten zur perfekten IT-Dokumentation - Teil 2

Dies ist der zweite Teil des Artikels zur perfekten IT-Dokumentation. Im ersten Teil beschreibt Peter Resch-Edermayr die Bereiche "Infrastruktur", "Netzwerk" und "Server".

4. Clients

Bevor wir mit der Dokumentation der Client-Hardware bzw. Peripherie beginnen, überlegen Sie sich bitte das Konzept des dokumentierten Arbeitsplatzes.

Ein Arbeitsplatz ist sozusagen eine "virtuelle Ortsbezeichnung", mit der man wiederum Objekte verknüpfen kann. Gerade im Zeitalter hoher Mobilität können so mobile Geräte von fest verbauten Einheiten unterschieden werden. Ein Beispiel:

Ein Arbeitsplatz ist ...

  • einem Standort (Raum) fix zugeordnet.
  • einer oder mehreren Personen zugewiesen
  • einer oder mehreren Abteilungen zugewiesen
  • eine Art "Container" für fest installierte Geräte: Drucker, Telefone, Scanner, Monitore, Dockingstations, Ladegeräte oder fest installierte PC.

Ein weiterer Vorteil für die Verwendung der Arbeitsplätze ist die Zuordnung zu Netzwerk-Anschlüssen (Patchdosen), Feuermeldern und anderen betrieblichen Einrichtungen.

Ebenso können Arbeitsplätze in den Raumplänen fest eingezeichnet werden. Ein weiterer Anwendungsfall ist die Dokumentation von Heimarbeitsplätzen. Wir raten dazu, vor der eigentlichen Clientdokumentation die Arbeitsplätze zu definieren.

Die Zusammenhänge ergeben sich wieder aus unserem Ablaufdiagramm (s. Abb.9).

Asset-Management

Bei der Dokumentation bzw. dem Durchführen einer Client-Inventur ist es sinnvoll, sich über Methoden des Asset-Managements klar zu werden:

  • Vergeben unternehmensweit eindeutiger Laufnummern für Geräte,
  • Ausdruck und Anbringung von Aufklebern für die einfache Identifikation,
  • Verwendung von Barcodes für die einfache Handhabung mit Barcode Lesern und
  • Verwendung von QR-Codes für zusätzliche Daten, Verwendung von Tablets und mobilen Geräten als Scanner und Hyperlinks zu den dokumentierten Objekten.

Auch hier gilt wie zuvor: Diese Techniken werden von entsprechender Dokumentationssoftware zumeist unterstützt, während man sich bei der Quick-and-dirty-Version im Excel-Spreadsheet selbst ein System aufbauen muss! Jedenfalls macht sich ein wenig Investment für das Finden Ihres Systems positiv durch Zeiteinsparung in der Zukunft bemerkbar.

5. Spezialfall Software und Lizenzen

Sofern Sie nicht komplett auf proprietäre Software verzichten, kommt das Thema Lizenzen und Installationen auf Sie zu. Wenn Sie ihren Chef fragen, welche Auswertung er aus der neuen IT-Dokumentation haben will, wird sehr schnell das Wort Lizenzen fallen. Denn hierbei geht es um einen nicht unerheblichen Kostenfaktor. Sowohl bei der Anschaffung, als auch bei einer eventuellen Abmahnung entstehen Kosten, übrigens auch bei Lizenzen, die gar nicht mehr nötig sind. Um hier den Überblick zu bewahren, muss man gut dokumentieren. Zweifelsohne werden Sie hierbei mit manuellen Methoden an den Rand der Leistungsfähigkeit kommen – spätestens dann ist es an der Zeit, sich mit automatisierten Helferlein zu beschäftigen. Doch keine Angst: Die Lizenzen dafür sind recht kostengünstig und es gibt sogar Freeware für einige Aufgabenstellungen.

Unserer Erfahrung nach ist eine Dokumentation der installierten Software – und oftmals auch der physischen Clients, Drucker und Server – ohne Discovery nicht zu bewerkstelligen. Die Investition und der Aufwand für die Einarbeitung in die Software ist überschaubar, gerade wenn man die Kosten für Lizenzen und die benötigte Arbeitszeit gegenüberstellt. Ohne Discovery ist die Liste der installierten Software und Versionen nicht aktuell zu halten. Eine Softwareinventarisierung mit Lizenzmanagement bleibt unvollständig.

Was braucht man an Dokumentation auf jeden Fall, um zum letzten Schritt weiter zu kommen?

  • Installierte Server-Software wird im nächsten Schritt verwendet, um die geschäftskritischen Applikationen zu modellieren. Diese kann notfalls auch händisch aufgebaut werden, da sich die Informationen (ausgenommen Versionen und Patchlevel) eher selten ändern.

  • Serverdienste 
werden verwendet, um Infrastrukturservices zu bilden und die Abhängigkeiten festzustellen. Auch diese Information ist eher statisch, denn nicht jeden Tag werden neue Dienste geschaffen oder geändert. Selbst hier kann theoretisch manuell dokumentiert werden. Wenngleich die Liste der automatisch ermittelten laufenden Dienste sehr aufschlussreich sein kann, auch in Hinblick auf jene Dienste, die aus unterschiedlichen Gründen gar nicht laufen sollten.

6. Die wichtigsten Anwendungen und IT-Services

Wir haben es bereits mehrfach angemerkt: im IT-Notfallmanagement ist das Wiederherstellen der wichtigsten Anwendungen am wichtigsten, um die Geschäftsprozesse so schnell wie möglich wieder anlaufen zu lassen. Das ist nicht neu, aber vor allem eins: Eine Teamaufgabe. Hier benötigen Sie nicht nur den Administrator, sondern auch den Netzwerker und die Kollegen aus der Fachabteilung, oft sogar externe Dienstleister. Sie werden bei diesem Punkt schnell feststellen, dass die Unsicherheiten groß sind: warum etwas wirklich läuft, was es dazu alles braucht – ist eigentlich nicht klar.

Never touch a running system? But document it, please!

Falls Sie hier bei Null beginnen, nutzen Sie eine Standardmethode für die Applikationsanalyse oder beauftragen einen Dienstleister, der auf die Analyse von bestehenden Systemen spezialisiert ist. Doch zuallererst benötigen wir einmal eine Liste jener IT-Services bzw. -Applikationen, bei denen wir beginnen müssen zu dokumentieren.

Was ist wichtig?

Viele IT-Organisationen haben hundert und mehr Applikationen auf ihren Servern laufen. Teilweise Altlasten (die aus verschiedenen Gründen noch nicht endgültig abgeschaltet wurden), teilweise schon wieder Neues (im Testbetrieb, der schon halb produktiv ist). Das verstellt den Blick auf das, was "sowieso läuft", aber in Wahrheit der Motor des Unternehmen ist. Wie soll man nun den Überblick behalten und herausfinden, was "wichtig" ist, um mit der Dokumentation zu beginnen?

Die rote Linie

In jedem IT-Betrieb gibt es einen Bereich, ein oder mehrere Systeme, zu denen nur einige Spezialisten Zugriff haben. Eine "magische rote Linie" umgibt sowohl die Server, als auch das zugehörige Storage- und Backup-System. Jede Änderung kommt einem Staatsakt gleich. Nun können Sie ziemlich sicher sein: Hier wird das Geld ihres Arbeitgebers verdient oder verwaltet. Das ist schließlich auch einer der Hauptgründe für's Dokumentieren: Die Geschäftsprozesse, mit denen Geld verdient wird, so schnell wie möglich wieder zu ermöglichen.

Vorsicht Bequemlichkeitsfalle: "Alle Komponenten sind bei diesen Systemen doppelt abgesichert, alles redundant aufgebaut, da muss man nicht so genau sein." Nun, das ist laut Murphys Law auch doppelt zu hinterfragen. Gehen Sie bitte davon aus, dass das viele Geld, das für redundante Absicherung dieser Systeme vorhanden war, auch in ähnlichem Verhältnis für eine zeitgemäße Dokumentation investiert werden muss. Und wehe dem, der im Worst Case aus Bequemlichkeit keine IT-Dokumentation vorlegen kann!

Die Cloud muss nicht dokumentiert werden

Auch das ist eine gängige Fehlannahme. Immer mehr Systeme kommen aus der Wolke, sind in wenigen Minuten verfügbar, aber im schlimmsten Fall kann sich niemand erinnern, wie das damals genau war… Wenn Sie schon bei Cloud-Applikationen nicht Einblick in die "Blackbox" bekommen, gibt es doch eine Menge Details, die wichtig zu dokumentieren sind:

  • Vertrag (und Ablaufdatum!)
  • Ansprechpartner für Vertrieb und Support
  • Supportvereinbarung
  • Vereinbarungen jeder Art für Datensicherung, Rücksicherung, etc.
  • Vereinbarte Wartungsfenster
  • Zugangsdaten für Administrationskonten
  • Konfiguration der Dienste (allgemein, bzw. individuelle Einstellungen)

Hier kommt ein wichtiger Prozess zum Tragen: Fluktuation bei internen Betreuern ist mit Dokumentation und guten Prozessen zu kompensieren. Im Ernstfall kann es, obwohl technisch verfügbar, mehrere Tage dauern, bis man wieder an die Daten herankommt. Weil vergessen wurde, dem Provider neue Ansprechpartner zu melden – und dieser sich strikt an seine Policies hält.

Die unterschätzten internen IT-Services

Nennen wir sie "Infrastruktur-Services" oder "Rechenzentrums-Services" – gemeint sind jene Dienste, die ein Zusammenspiel des IT-Verbundes erst ermöglichen. Beispielhaft seien erwähnt: Directory-Service, Namensauflösung, Firewalls, Antivirus, Datenbankdienste, usw. Auch hier wird eine Liste an Services schnell an die 100 Dienste ergeben, die als gegeben angenommen werden. Aber sind sie auch so dokumentiert, dass sie im Ernstfall in wenigen Minuten wiederhergestellt werden können? Kann das Directory, dem gestern ein neuer Administrativer Account für einen Dienst hinzugefügt wurde, heute identisch wiederhergestellt werden? Kann es aufgrund von Betriebssystemeinschränkungen überhaupt rückgesichert werden? Braucht man eventuell ein funktionierendes Unternehmensdirectory für die Backup-Software?

Die Abhängigkeiten

Nun sind wir beim eigentlichen Kern und Unterschied zwischen "flacher" IT-Dokumentation und CMDB – der Configuration Management Database: Den Relationen. Diese verbinden Objekte zu Abhängigkeiten und damit zu einer Hierarchie. Der oft so genannte "Servicebaum" gibt Auskunft über jene Elemente, die zwingend (oder optional) vorhanden sein müssen, damit ein Service eben funktional ist. Spätestens hier ist eine rein dateibasierte Umsetzung schwer handhabbar. Und schlicht nicht wirtschaftlich.

Die Königsklasse: IT-Service-Management

Bisher arbeiten wir an der Dokumentation von zumeist direkt greifbaren Dingen, doch nun geht es um jene Services, die von der IT-Abteilung erbracht werden. Dies sind nicht nur technische Services, die auf Rechnern laufen. Das kann auch durchaus eine Dienstleistung sein, die in Ihrer IT-Abteilung erbracht wird. Sei es die Beratung, die stattfindet, oder der Kundenservice, der hier durchgeführt wird. Ja selbst das Dokumentieren, das hier beschrieben wird und das Durchführen eines Änderungsmanagements sind Prozesse, die alle anderen IT-Services zwingend benötigen und daher auch früher oder später der Dokumentation bedürfen.

Im Katalog Ihrer Services findet man eben viel mehr als nur Technik. In diesem Schritt bauen Sie einen Servicekatalog auf und verbinden ihn mit den entsprechenden Objekten, die für die Erbringung verantwortlich sind. Ebenso haben Services einen Lebenszyklus, über die Dokumentation desselben wird gerne hinweggesehen.

Fazit

Haben Sie diese sechs Schritte – inklusive Abzweigung in die Softwaredokumentation – durchlaufen, kann man Ihnen gratulieren: Sie haben nun alle Ebenen der Dokumentation kennen gelernt und können nun dort ins Detail gehen, wo Ihr Unternehmen es weiter benötigt. Wie kann es von hier aus weitergehen?

  • Automatisch erstellte Dokumentation
: Scripten Sie, automatisieren Sie oder wenden Sie die Funktionen Ihrer CMDB an: automatisch und tagesaktuell erstellte Dokumente aus Ihrer Dokumentation sind ein willkommenes Ergebnis Ihres Projektes. Sei es das Notfallhandbuch, seien es Systemscheine oder einfach nur ein täglicher Export der wichtigsten Informationen auf einen USB-Stick: Machen Sie sich das Leben leichter, machen Sie Ihre Informationen für Sie und Ihr Unternehmen nutzbar.

  • Automatisieren, was zu automatisieren ist
: Nicht nur Daten zu sammeln, wie das im Fall des Discovery geschieht, ist das Ziel: Viele Anwendungsfälle beschäftigen sich mit der Steuerung weiterer Systeme: Das automatische Provisionieren von Servern, das automatische Konfigurieren des System- und Netzwerkmonitorings, uvm. All dies ist erst durch ihre Dokumentation möglich.

  • Dokumentieren, was bisher liegen geblieben ist: 
Zum Beispiel ist nun, nach erfolgreichem Durchlauf des Projekts, Zeit, sich um die Dokumentation der Verkabelung zu kümmern.
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
botMessage_toctoc_comments_9210