Vor der Auswahl stehend, einen neuen Server zu installieren oder ein Dokument �ber die Erstellung von Systembackups zu schreiben, w�hlen die meisten Systemadministratoren mit Sicherheit das Installieren des Servers. W�hrend dies nicht unbedingt ungew�hnlich ist, m�ssen Sie jedoch alles das dokumentiern, was von Ihnen getan wird. Viele Systemadministratoren z�gern die n�tige Dokumentation aus einer Reihe von Gr�nden hinaus:
"Ich mach das sp�ter."
Leider ist dies meistens nicht der Fall. Selbst wenn ein Systemadministrator dies ernst meint, ist jedoch die Natur des Jobs meistens zu chaotisch, um irgendetwas "sp�ter" zu erledigen. Noch schlimmer, je l�nger man die Aufgabe herausz�gert, desto mehr wird vergessen, was zu einem weniger detaillierten (und daher auch weniger hilfreichen) Dokument f�hrt.
"Warum aufschreiben? Ich werd es schon nicht vergessen."
Wenn Sie nicht zuf�llig ein photografisches Ged�chtnis haben, ist die Chance, dass Sie sich genau an alles erinnern, relativ gering. Oder noch schlimmer; Sie erinnern sich nur an die H�lfte und merken nicht, dass Sie einen wesentlichen Teil vergessen haben. Meist f�hrt dies zu enormer Zeitverschwendung, wenn Sie n�mlich entweder versuchen, das Vergessene neu zu lernen oder Reparaturen durchf�hren m�ssen, weil Sie durch Ihr Halbwissen etwas kaputt gemacht haben.
"Wenn ich es nur in meinem Kopf habe, k�nnen sie mich nicht so einfach entlassen — mein Arbeitsplatz ist somit sicher!"
W�hrend dies vielleicht eine Zeit lang funktioniert, f�hrt dies zwangsl�ufig zu weniger — nicht mehr — Job-Sicherheit. �berlegen Sie sich einmal, was bei einem Notfall passiert. Sie sind vielleicht nicht da; Ihre Dokumentation jedoch rettet die Situation, weil jemand anderes das Problem in Ihrer Abwesenheit dadurch l�sen kann. Und vergessen Sie niemals, dass Notf�lle immer dann auftreten, wenn das Management gerade genau hinsieht. In diesen F�llen ist es besser, dass Ihre Dokumentation Teil der L�sung ist und nicht Ihre Abwesenheit Teil des Problems.
Zus�tzlich dazu, wenn Sie Teil eines kleinen, jedoch wachsenden Unternehmens sind, besteht irgendwann vielleicht der Bedarf an einem zweiten Systemadministrator. Wie kann dieser jedoch lernen, wenn sich alles in Ihrem Kopf befindet? Das Vers�umen der Dokumentation kann Sie auch so unersetzlich machen, dass Sie sich damit jegliche Aufstiegschancen im Unternehmen verbauen. Sie k�nnten dann z.B. f�r die Person arbeiten, die eingestellt wurde, um Ihnen zu helfen.
Hoffentlich sind Sie jetzt von den Vorteilen der Systemdokumentation �berzeugt. Dies bringt uns zur n�chsten Frage: Was sollten Sie dokumentieren? Hier eine kleine Liste:
Richtlinien
Richtlinien sind dazu geschrieben, die Beziehung zwischen Ihnen und den Benutzern klar darzulegen und in Form zu fassen. Dies gibt dem Benutzer klar vor, wie deren Anfragen nach Ressourcen und/oder Unterst�tzung behandelt werden. Die Art, wie diese Richtlinien an die Community weitergeben werden, ist von Unternehmen zu Unternehmen unterschiedlich.
Prozesse
Prozesse sind Schritt-f�r-Schritt Abfolgen von Aktionen, die durchgef�hrt werden m�ssen, um eine bestimmte Aufgabe zu erledigen. Zu dokumentierende Prozesse sind z.B. Backup-Prozesse, Benutzeraccount-Prozesse, Problem-Reporterstellungs-Prozesse usw.. Wie bei der Automatisierung gilt auch f�r Prozesse: wird ein Prozess mehr als einmal ausgef�hrt, so ist es sinnvoll, diesen zu dokumentieren.
�nderungen
Ein gro�er Teil der Arbeit eines Systemadministrators bezieht sich auf das Durchf�hren von �nderungen — das Konfigurieren von Systemen f�r die bestm�gliche Leistung, das �ndern von Skripten, das Modifizieren von Konfigurationsdateien, usw.. Alle diese �nderungen sollten dokumentiert werden. Ansonsten werden Sie in Zukunft vielleicht von den �nderungen verwirrt, die Sie ein paar Monate zuvor durchgef�hrt haben.
Einige Unternehmen verwenden komplexere Methoden f�r das Verzeichnen von �nderungen, aber in den meisten F�llen ist eine einfache �nderungs�bersicht am Anfang einer modifizierten Datei alles, was n�tig ist. Jeder Eintrag in dem �nderungs�berblick sollte zumindest folgendes enthalten:
Den Namen oder die Initialen derjenigen Person, die die �nderungen durchf�hrt
Das Datum der �nderung
Der Grund f�r die �nderung
Dies resultiert in kurzen, jedoch sinnvollen Angaben:
ECB, 12-Juni-2002 — Aktualisierter Eintrag f�r neuen Drucker f�r die Buchhaltungsabteilung (um die F�higkeit des Ersatzdruckers, Duplex zu drucken, zu unterst�tzen)
