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:
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.
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.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 348225
Url: https://administrator.de/forum/server-dokumentation-was-sollte-rein-348225.html
Ausgedruckt am: 23.12.2024 um 00:12 Uhr
18 Kommentare
Neuester Kommentar
Hallo,
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
Gruß,
Jörg
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
Gruß,
Jörg
Zitat von @117471:
Hallo,
HalloHallo,
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?!?
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
Gruß,
Jörg
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
Das ist die Systemdokumentation. Dann gibt es je nach Unternehmen noch die Anwendungsdokumentation, Betriebshandbuch, Standard Operating Procedure)
Gruss Penny
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
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.
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
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
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.
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!
Hallo TrialAndError,
Richtig, weil du bei einem Ausfall möglichst schnell die Neuinstallation exakt nach der damaligen Ablauf nachvollziehen willst.
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
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.
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
Zitat von @runasservice:
Top, kurz und knackig!
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.
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!
Yupp, volle Zustimmung.
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:
Ist noch nicht ganz fertig, aber so kann sich auch ein Kollege der im Helpdesk sitzt ein Bild davon machen wenn es irgendwo hackt.
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:
Ist noch nicht ganz fertig, aber so kann sich auch ein Kollege der im Helpdesk sitzt ein Bild davon machen wenn es irgendwo hackt.
@TrialAndError,
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.
Wir bleiben auch hinter unseren Ansprüchen zurück.
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
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.
Wir bleiben auch hinter unseren Ansprüchen zurück.
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
Zitat von @TrialAndError:
Hallo Fa-jka
Ich habe noch nie nen Apache, OTRS/KIX, Bareos, Windows Print Server, ... out of the Box verwendet.
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"
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
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.
P.S.
Gruss Penny
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 sindWir bleiben auch hinter unseren Ansprüchen zurück.
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
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
Grade wenn man einen Überblick über die Sicherungs- und Laufzeiten haben will, bietet sich eine Timeline (Zeitstrahl) an.
Gruss Penny
Hallo,
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
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.
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