Server- und Systemdokumentation

Server-Doku ist die Antwort auf die Frage „Was steht eigentlich in unserem Rack/in unserer Cloud/in unserer VM-Farm?" – und es ist eine Antwort, die sich konstant ändert: neue Server kommen dazu, alte werden deprovisioniert, Konfigurationen wachsen, Verantwortlichkeiten wechseln. Wer hier ohne System arbeitet, weiß nach 2 Jahren nicht mehr, welcher der drei „srv-app-irgendwas"-Server wofür zuständig ist. Diese Lektion zeigt dir die zwei Haupt-Doku-Ebenen (Hardware/Virtualisierung und Software-Stack), das Konzept des Server-Steckbriefs als kompakte Standard-Vorlage, die Integration mit der CMDB, die Automatisierung mit Infrastructure as Code (Ansible, Terraform) sowie die Stolperfallen. Server-Doku ist die Voraussetzung für Patch-Management, Backups, Incidents, DR – ohne sie ist Betrieb Glücksspiel.

1) Doku-Schichten – was wird wo dokumentiert?

Klick die Schichten an, um Details zu sehen:

2) Server-Steckbrief – die Standard-Vorlage

Pro Server ein Steckbrief, immer mit gleichem Aufbau. Beispiel für einen produktiven App-Server:

3) Pflichtfelder eines Server-Steckbriefs

Auch wenn die Vorlage individuell ist, gibt es Felder, die auf keiner fehlen dürfen:

4) Infrastructure as Code als „lebende Doku"

Ein moderner Ansatz: Server-Konfiguration als Code. Mit Ansible, Terraform, Puppet wird die Doku zur ausführbaren Konfiguration:

# Ansible-Inventory: erp-server.yml
all:
  vars:
    os_family: Debian
    timezone: Europe/Berlin
  children:
    erp_app:
      hosts:
        srv-erp-app01:
          ansible_host: 10.0.20.21
          vcpu: 8
          ram_gb: 32
          role: erp_app_primary
          backup_schedule: daily-22
        srv-erp-app02:
          ansible_host: 10.0.20.22
          vcpu: 8
          ram_gb: 32
          role: erp_app_secondary
    erp_db:
      hosts:
        srv-erp-db01:
          ansible_host: 10.0.20.31
          vcpu: 16
          ram_gb: 64
          role: mssql_primary
          backup_schedule: hourly

Vorteile gegenüber statischer Word-Doku:

• Versioniert in Git – jede Änderung mit Datum, Autor, Begründung.
• Reviewbar – Pull Requests vor Anwendung.
• Ausführbar – die Doku ist die Konfiguration. Drift zwischen Doku und Realität ist ausgeschlossen.
• Reproduzierbar – Neu-Aufbau identischer Server in Minuten.
• Auditierbar – Git-Log zeigt Wer-Wann-Was.

5) CMDB-Integration

Pro Server ein Configuration Item (CI) in der CMDB. Wichtige Beziehungen, die dort modelliert werden:

• „runs on": srv-erp-app01 runs on cluster-prod01 (VMware)
• „uses": srv-erp-app01 uses srv-erp-db01 (Daten)
• „part of": srv-erp-app01 part of Service „ERP"
• „owned by": srv-erp-app01 owned by Person K. Wagner
• „located in": srv-erp-app01 located in Rack 12, Position 7-10 (RZ Hauptsitz)

Diese Beziehungen erlauben Impact-Analysen: „Was passiert, wenn srv-erp-db01 ausfällt?" → CMDB zeigt alle davon abhängigen CIs.

6) Discovery und Auto-Update

Die fleißigste Methode bringt nichts, wenn Mensch jeden Patch von Hand in die Doku eintragen muss. Moderne Setups arbeiten mit Discovery:

• Agent-basiert: Tools wie Tanium, SCCM/MECM, Lansweeper, Intune haben Agents auf allen Geräten, melden Hardware, OS, Software automatisch.
• Agent-less: SSH/WMI-Discovery scannt Netzwerk, sammelt Informationen. NetBox, Auvik, OpenAudIT.
• Cloud-API: AWS/Azure/GCP haben eigene APIs zum Asset-Listing. Tools wie CloudKnox, Wiz nutzen das.
• Ansible Facts: nach jedem Playbook-Lauf wird die aktuelle Konfig erfasst und kann in CMDB gespeist werden.

Ergebnis: die CMDB spiegelt die Realität, ohne dass jemand pflegt. Manuelle Felder gibt es nur dort, wo Discovery keine Informationen liefern kann (z. B. Service-Owner-Zuordnung).

7) Standard-Templates und Goldenes Image

Wer alle Server identisch aufsetzt, spart Doku-Aufwand:

• Goldenes Image / Template: einmal pro OS-Familie sauber konfigurieren (NTP, DNS, SSH, Monitoring-Agent, Logging) – alle neuen Server aus diesem Template klonen.
• Naming-Konvention: <rolle>-<zweck>-<nummer>, z. B. srv-erp-app01, srv-erp-db01, srv-fileserver01. Selbsterklärend.
• Standard-Sizing: Klassen wie „Small/Medium/Large" mit definiertem CPU/RAM/Disk. Vereinfacht Doku und Kapazitätsplanung.
• Tagging in Cloud: Owner, Environment (prod/test/dev), Cost-Center, Application als Tags.

8) Antipatterns

• „Excel-Liste reicht." Bei 10 Servern ja, bei 100 nicht. Lösung: CMDB oder NetBox.
• Hostnames willkürlich. WICKIE, RUFUS, BUTTERLOSER – nach 3 Jahren weiß niemand mehr, was wo läuft. Lösung: Naming-Konvention.
• Nur ein „Server X läuft." in der Doku. Ohne Versionen, Service, Owner. Lösung: Pflicht-Steckbrief-Felder.
• Patch-Stand nicht dokumentiert. Audit fragt: „auf welchem Patch-Level ist srv-erp-app01?" – niemand kann antworten ohne SSH. Lösung: automatisches Erfassen in CMDB.
• Service-Owner = „IT". Allgemeiner Eintrag, niemand spezifisch. Bei Incident keine schnelle Ansprache. Lösung: konkrete Personen.
• Doku-Drift. Konfiguration in Realität weicht von Doku ab, weil manuelle Änderungen nicht eingetragen wurden. Lösung: IaC und Drift-Detection.
• Server „aus Versehen" deprovisioniert. War als „Test" markiert, war aber Prod. Lösung: Lifecycle-Status in CMDB, Schutz vor Löschung.
• Doku ohne Lifecycle-Status. srv-old05 läuft noch, aber niemand weiß ob es noch gebraucht wird. Lösung: Status-Feld (planned / staging / prod / deprecated / decommissioned).
• Lizenz-Doku fehlt. Bei Lizenz-Audit teure Strafzahlung. Lösung: pro Software-Komponente Lizenz-Info im Steckbrief.

Zusammenfassung

Server-Doku dokumentiert pro System fünf Schichten von Hardware/Virtualisierung über OS, Middleware und Anwendung bis zu Daten/Schnittstellen – standardisiert als Server-Steckbrief mit klaren Pflichtfeldern (ID, Hardware, OS+Patch-Stand, Netz, App, Owner, Backup, Monitoring). Moderne Variante: Infrastructure as Code mit Ansible/Terraform – die Konfiguration ist die Doku. Anbindung an die CMDB mit Discovery-Tools (Tanium, NetBox, MECM) automatisiert die Pflege. Naming-Konventionen, Goldenes Image und Tagging reduzieren den Doku-Aufwand drastisch.

Verwandte Lektionen: Betriebshandbuch · Netzwerk-Doku · CMDB · und mehrWeitere relevante LektionenAnsible-PlaybooksPatch-ManagementRTO/RPOFailoverMonitoringWindows-ServerLinux systemd