trialanderror
Goto Top

Server Dokumentation (Was sollte rein?)

Hallo,
nach dem ich im vergangenen Jahr zwei größere Ausfälle hatte, ist bei mir das Thema Dokumentation wieder weiter nach oben auf die ToDo gerückt.

Ich habe hier eine undokumentierte bestehende Infrastruktur übernommen. Beim aufarbeiten der Doku habe ich bisher erhoben:
  • Kurzbeschreibung des Servers
  • DNS (hostname, cnames)
  • Netzwerk (Interfacekonfiguration)
  • Hardware (HW oder VM, Board, HBA, Platten mit SN, UUIDs bei RAID, …)

Für die Dokumentation setze ich gegenwärtig auf i-Doit (Standort, Alter, Seriennummern, Rechnungen, ...) und Dokuwiki (oben genannte Punkte).

Als ich gerade (Software RAID auf größere Platten umziehen) Probleme mit einem RAID hatte, wurde auch noch mal auf das Thema Serverdokumentation hingewiesen.

Welche Bereiche landen bei euch in der Doku?
Ist es Sinnvoll jeden manuell installierten/konfigurierten Dienst aufzuführen und dessen Konfiguration zu dokumentieren?

Ich freue mich auf eure Rückmeldungen.

Content-Key: 348225

Url: https://administrator.de/contentid/348225

Ausgedruckt am: 19.03.2024 um 05:03 Uhr

Mitglied: 117471
117471 05.09.2017 um 11:06:13 Uhr
Goto Top
Hallo,

Ist es Sinnvoll jeden manuell installierten/konfigurierten Dienst aufzuführen und dessen Konfiguration zu dokumentieren?

Ich habe bis dato noch nie Dienste konfigurieren müssen?!?

Grundsätzlich die beste Lösung ist meiner Meinung nach, vor der Inbetriebnahme die "Best practice" des Herstellers zu recherchieren und diese gnadenlos umzusetzen. In dem Fall ist die Dokumentation des Herstellers die Dokumentation des eigenen Systems face-smile

Gruß,
Jörg
Mitglied: Penny.Cilin
Penny.Cilin 05.09.2017 um 11:26:31 Uhr
Goto Top
Zitat von @117471:

Hallo,
Hallo

Ist es Sinnvoll jeden manuell installierten/konfigurierten Dienst aufzuführen und dessen Konfiguration zu dokumentieren?
Zumindest diejenigen, welche nachträglich aufgrund Softwareinstallation eingerichtet wurden.

Ich habe bis dato noch nie Dienste konfigurieren müssen?!?
Kommt darauf an. bei manchen Diensten macht es Sinn, etwa wenn ein Dienst sofort wieder neu gestartet werden soll, wenn er abgestürzt ist.

Grundsätzlich die beste Lösung ist meiner Meinung nach, vor der Inbetriebnahme die "Best practice" des Herstellers zu recherchieren und diese gnadenlos umzusetzen. In dem Fall ist die Dokumentation des Herstellers die Dokumentation des eigenen Systems face-smile

Gruß,
Jörg

Eine pauschale Antwort kann man auf die Frage des Beitragserstellers nicht geben.
Was ich in der Systemdokumentation immer mit aufnehme, ist
  • Releasestand Betriebssystem (Patchlevelstand)
  • Releasestand installierter Software
  • Konfiguration der Software
  • Betriebssystemvariablen, welche zusätzlich zum Standard hinzugefügt wurden
dann wie schon vom Beitragsersteller aufgeführt, die Hardware / Netzwerkkonfiguration, Standort, Ansprechpartner (Inhouse, Systemhaus, Händler, usw.)
Das ist die Systemdokumentation. Dann gibt es je nach Unternehmen noch die Anwendungsdokumentation, Betriebshandbuch, Standard Operating Procedure)


Gruss Penny
Mitglied: emeriks
emeriks 05.09.2017 aktualisiert um 11:29:48 Uhr
Goto Top
Hi,
die Antwort ist eigentlich ganz einfach:
In diese Doku muss alles rein, was Du selbst vorzufinden wünscht, wenn Du Dich über einen "fremden", "unbekannten" Server informieren willst. Alles, was Du für eine Übernahme (der Verantwortung) benötigt würdest. Alles, was Dir für eine Fehleranalyse hilfreich wäre. Alles, was Dir für eine Restauration nach Totalausfall (Brand, Diebstahl) hilfreich wäre.

E.

Edit:
Oder anders ausgedrückt:
Alles was in einer von einem Dritten erstellten Doku drin sein müsste, damit Du nicht von
eine undokumentierte bestehende Infrastruktur
sprechen würdest.
Mitglied: clSchak
clSchak 05.09.2017 um 11:39:27 Uhr
Goto Top
Hi

wir sind auch erst "einfach" angefangen, Name, technische Daten usw. zu dokumentieren. Mittlerweile haben wir alle Seriennummern der Festplatten erfasst, die gesamten Buchhaltungsdaten sind hinterlegt, alle Wartungs- und Serviceverträge, die technische Dokumentation, Standort im Rack, Verlinkung zum Monitoring, Ansprechpartner, Anschlusspunkte (Netz, SAS, FC, LAN ....). Das ist ein haufen Arbeit ja, aber wenn man "größere" Umgebungen hat macht das durchaus Sinn wenn man auch die Firmwarestände der einzelnen Komponenten dokumentiert ....

Automatisiert schön und gut, damit sind wir angefangen alles möglich über XML, CSV, SQL .... zu importieren, machen wir mittlerweile nicht mehr, da wir recht homogene Hardware haben konnten wir uns entsprechende Vorlagen erstellen und diese dann jeweils anpassen.

Wir setzen auch I-DOIT ein, fangen gerade an die Dienste zu implementieren um so eine Abhängigkeitsstruktur zu haben, daraus resultiert dann der "Wert" eines Ausfalls (praktisch für die Risikobewertung).

Bisher sind wie (sogar) ohne Anpassungen ausgekommen, dass was wir zusätzlich an Infos benötigen kann man sich mit dem Tools schnell selbst einstellen und die Ansichten um die Punkte reduzieren die nicht relevant sind.

Gruß
@clSchak
Mitglied: runasservice
runasservice 05.09.2017 um 13:07:52 Uhr
Goto Top
Zitat von @emeriks:
In diese Doku muss alles rein, was Du selbst vorzufinden wünscht, wenn Du Dich über einen "fremden", "unbekannten" Server informieren willst. Alles, was Du für eine Übernahme (der Verantwortung) benötigt würdest. Alles, was Dir für eine Fehleranalyse hilfreich wäre. Alles, was Dir für eine Restauration nach Totalausfall (Brand, Diebstahl) hilfreich wäre.

Top, kurz und knackig! face-smile
Mitglied: it-frosch
it-frosch 05.09.2017 aktualisiert um 13:18:12 Uhr
Goto Top
Hallo TrialAndError,

Welche Bereiche landen bei euch in der Doku?
Warum erstellst du eine Doku?
Richtig, weil du bei einem Ausfall möglichst schnell die Neuinstallation exakt nach der damaligen Ablauf nachvollziehen willst. face-wink

Damit ist doch eigentlich alles klar.

Auf die Infrastruktur bezogen, gehört dann alles rein, was ein neuer Kollege benötigt, um sich sofort zurechtfinden zu können.

grüße vom it-frosch
Mitglied: Penny.Cilin
Penny.Cilin 05.09.2017 um 13:27:20 Uhr
Goto Top
Zitat von @runasservice:

Zitat von @emeriks:
In diese Doku muss alles rein, was Du selbst vorzufinden wünscht, wenn Du Dich über einen "fremden", "unbekannten" Server informieren willst. Alles, was Du für eine Übernahme (der Verantwortung) benötigt würdest. Alles, was Dir für eine Fehleranalyse hilfreich wäre. Alles, was Dir für eine Restauration nach Totalausfall (Brand, Diebstahl) hilfreich wäre.

Top, kurz und knackig! face-smile

Yupp, volle Zustimmung. face-smile
Mitglied: TrialAndError
TrialAndError 07.09.2017 um 07:26:32 Uhr
Goto Top
Hallo Fa-jka
Ich habe bis dato noch nie Dienste konfigurieren müssen?!?

Ich habe noch nie nen Apache, OTRS/KIX, Bareos, Windows Print Server, ... out of the Box verwendet. In der Regel sind bei diesen Diensten doch immer irgend welche Anpassungen relevant, die das System einzigartig machen oder?
Mitglied: TrialAndError
TrialAndError 07.09.2017 um 07:35:27 Uhr
Goto Top
@emeriks

Alles was in einer von einem Dritten erstellten Doku drin sein müsste, damit Du nicht von
eine undokumentierte bestehende Infrastruktur
sprechen würdest.

Und genau an dieser Stelle hab ich ein Problem. Ich weiß nicht was ich brauchen würde.

Kleines Beispiel: Ich hatte in meiner Doku die Festplatten, Seriennummern, Slots der Disks und interne "Namen" (sdx) aufgenommen. Nach meinen Problemen mit dem RAID habe ich jetzt noch die Konfiguration der mdx hinzugenommen und die UUIDs der einzelnen Partitionen ergänzt.

Ich habe ja nichts dagegen aus Fehlern zu lernen. Aber es hatte doch sicherlich auch schon der ein oder andere Admin Probleme bei denen er sich gewünscht hat, dass er Detail xy vorher dokumentiert hätte.
Mitglied: TrialAndError
TrialAndError 07.09.2017 um 07:41:26 Uhr
Goto Top
Hallo @clSchak,

Wir setzen auch I-DOIT ein

ich kratze noch an der Oberfläche von diesem Wunderwerk. Allerdings macht mir die Finanzierungspolitik Probleme. Auch wenn i-doit das anders sieht sind deren Lizenzen nicht wirklich günstig. Nutzt ihr die open oder die supportete Version?

Führt ihr eure gesamte Doku nur in i-doit oder zusätzlich auch noch in einer externen Anwendung, einem Wiki oder Excel, Word, ...?

, fangen gerade an die Dienste zu implementieren um so eine Abhängigkeitsstruktur zu haben, daraus resultiert dann der "Wert" eines Ausfalls (praktisch für die Risikobewertung).

Man kann ich i-doit Dienste abbilden? Gut zu wissen.
Mitglied: TrialAndError
TrialAndError 07.09.2017 um 07:48:21 Uhr
Goto Top
@it-frosch
weil du bei einem Ausfall möglichst schnell die Neuinstallation exakt nach der damaligen Ablauf nachvollziehen willst.

Das ist nur bedingt richtig.

Ich brauche eine Doku, die mir im Fehlerfall (z.B. nach einem Update) hilft den Mist wieder zum laufen zu bringen.
Ein Desaster Recovery ist nur sehr sehr selten notwendig. In dem Fall würde mir ein clean Setup warscheinlich auch nur wenig helfen, da allein der Import unserer LDAP (um mal ein großes Beispiel zu nennen) mindestens 48 Stunden benötigt. (Diese Info steht jetzt z.B. nach meinem letzten Versuch in der Doku)

Mein Problem ist, dass ich nicht weiß was relevant ist und es eventuell werden könnte. Ich weiß aber, dass es super unübersichtlich wird, wenn ich z.B. den Setup jedes einzelnen Dienstes auf jedem Host (unterscheidet sich ja meist zumindest durch abweichende IP oder DNS Einstellungen) dokumentiere.


Damit ist doch eigentlich alles klar.

Auf die Infrastruktur bezogen, gehört dann alles rein, was ein neuer Kollege benötigt, um sich sofort zurechtfinden zu können.

Angenommen du würdest bei uns anfangen. Was würdest du erwarten, dass es in der Doku steht?

(Ich selbst habe noch nie eine gute Doku gesehen. Hatte aber bisher Kollegen, die besser waren als jede Doku)
Mitglied: clSchak
clSchak 07.09.2017 um 08:56:07 Uhr
Goto Top
Hi

wir "migrieren" unsere Word / Excel / usw. Daten alle Richtung I-DOIT, die Anbindung an OTRS soll auch noch in diesem Jahr erfolgen. Leider hat das Tool keine Schnittstelle zu PRTG (zu Nagios allerdings schon).

Mit den einzelnen Diensten, Services, Hardware usw. bekommt man gute Ansichten über beteiligte Dienste, die dann in etwa so aussehen:

service_nav

Ist noch nicht ganz fertig, aber so kann sich auch ein Kollege der im Helpdesk sitzt ein Bild davon machen wenn es irgendwo hackt.
Mitglied: it-frosch
it-frosch 07.09.2017 um 12:48:30 Uhr
Goto Top
@TrialAndError,

Angenommen du würdest bei uns anfangen. Was würdest du erwarten, dass es in der Doku steht?
Systemübersicht (wie spielt was zusammen?)
Installationsdoku + Änderungsdoku + Knowhow Übersicht für jedes System

So versuchen wir seit einiger Zeit die Doku zu pflegen.

Das das alles andere als trivial ist weiß ich. face-wink
Wir bleiben auch hinter unseren Ansprüchen zurück. face-wink

Ich dokumentiere sehr viel in ZIM. Dann kann ich die Doku auch schnell einem Kollegen schicken,
der sie in seinen ZIM einhängt oder über den WEBServer zu Lesen freigeben.

grüße vom it-frosch
Mitglied: 117471
117471 07.09.2017 aktualisiert um 13:18:05 Uhr
Goto Top
Zitat von @TrialAndError:

Hallo Fa-jka
Ich habe bis dato noch nie Dienste konfigurieren müssen?!?

Ich habe noch nie nen Apache, OTRS/KIX, Bareos, Windows Print Server, ... out of the Box verwendet.

Achso. Ich dachte, Du fummelst an Windows-Diensten herum.

In deinem Beispiel (Apache usw. usf.) ist die lokale Konfiguration die Dokumentation - zumindest, solange sie nach der "Best practice" erfolgt ist.

Eine "externe" Dokumentation würde letztendlich darauf hinauslaufen, dass man eine Kopie der Konfiguration wegspeichert. Und das heißt bei mit "Backup" face-smile

Ernsthaft: Wenn jemand einen Fehler in einem Apache2 sucht, erwarte ich schon, dass der "apache2ctl -S" eingibt. Ansonsten ist da meines Erachtens nach der falsche Mann am falschen Ort.

Gruß,
Jörg
Mitglied: Penny.Cilin
Penny.Cilin 07.09.2017 um 14:05:26 Uhr
Goto Top
Wie @it-frosch schon anmerkt, welche Informationen benötigst DU, um ein System wieder zum laufen zu bringen.
Hierbei könne wir nur Anregungen und Tipps geben.
DU musst wissen, welche Informationen DU benötigst, um ein System / Anwendung, was-auch-immer wieder zum laufen zu bekommen.

Und Du solltest berücksichtigen, die Informationen sollten Deinem (evtl.) neuen Kollegen behilflich sein.
Denn der kennt Eure Umgebung nicht.

Das das alles andere als trivial ist weiß ich.
Wir bleiben auch hinter unseren Ansprüchen zurück.
Das bleibt unter Umständen nicht aus, wenn zu wenig Ressourcen vorhanden sind

P.S.
  • Dokumentation LEBEN. D.h. Die Dokumentationen müssen von Zeit zu Zeit überarbeitet / angepasst werden.
  • Die Dokumentationen, welche ich den Kollegen überlasse, enthalten alle nötigen Informationen.
  • Die Dokumentation, speziell Installationsverfahren enthalten 2 Varianten
    • Kurzfassung für IT Pros
    • Ausführliche Fassung
      • Allgemeinverständlich
      • Revisionssicher


Gruss Penny
Mitglied: TrialAndError
TrialAndError 11.09.2017 um 09:42:17 Uhr
Goto Top
Naja, die vielen Apache Installationen sind schon eher das "kleinste" Übel. Wobei hier auch jeder Server anders aussieht. Und gibt es da wirklich EINE "Best pracitce"? Irgend wie hat doch wieder jedes System seine eigenheiten. Seien es auch nur irgend welche nervigen PHP oder Java CGI Geschichten.

Eine "externe" Dokumentation würde letztendlich darauf hinauslaufen, dass man eine Kopie der Konfiguration wegspeichert. Und das heißt bei mit "Backup"

Die Idee finde ich gut. Das Backup würde ich jetzt zwar eher nicht als Doku verwenden wollen aber die Konfigurationsdateien wegschreiben und kommentieren ist ein einfacher erster Schritt.
Mitglied: Penny.Cilin
Penny.Cilin 11.09.2017 um 10:39:38 Uhr
Goto Top
Grade im Hinblick auf Datensicherung (Backup) ist eine Dokumentation sinnvoll. Nicht nur die Installation und Konfiguration der Backupumgebung selbst, sondern in Hinblick der Datensicherungen (Schedules, Sicherungen (was, wo => Disk, Band, usw.).

Grade wenn man einen Überblick über die Sicherungs- und Laufzeiten haben will, bietet sich eine Timeline (Zeitstrahl) an.


Gruss Penny
Mitglied: 117471
117471 11.09.2017 um 11:19:01 Uhr
Goto Top
Hallo,

Zitat von @TrialAndError:

Das Backup würde ich jetzt zwar eher nicht als Doku verwenden wollen aber die Konfigurationsdateien wegschreiben und kommentieren ist ein einfacher erster Schritt.

Man sollte mal darüber nachdenken, wo ein Kollege als Erstes sucht, wenn er ein Problem hat.

Wichtig ist, dss die Suche endlich ist. D.h., es muss irgendwann ein Punkt erreicht sein an dem man sagen kann: "Ich habe diese Information nicht gefunden - also existiert sie noch nicht".

Gruß,
Jörg