4.1 Störung und betroffenen Dienst eingrenzen

Bei einer Störung entsteht schnell der Wunsch, sofort einen Dienst neu zu starten oder eine bekannte Lösung auszuprobieren. Dadurch können jedoch wichtige Diagnoseinformationen verloren gehen.

Eine sinnvolle Haltung lautet:

1. Störungsmeldung nicht ungeprüft als Ursache übernehmen.
2. Beobachtungen von Vermutungen trennen.
3. Noch keine technische Ursache festlegen.
4. Zuerst den Umfang der Störung bestimmen.
5. Mit einfachen und möglichst lesenden Prüfungen beginnen.
6. Pro Arbeitsschritt nur eine wesentliche Veränderung durchführen.
7. Vor und nach jeder Maßnahme vergleichen.
8. Ergebnisse und Zeitpunkte dokumentieren.

Wichtig: Eine Fehlermeldung beschreibt häufig nur die Stelle, an der ein Fehler sichtbar wird – nicht die eigentliche Ursache.

Eine gute Fehlerbeschreibung beantwortet mindestens folgende Fragen:

Unzureichende Beschreibung:

„Der Server geht nicht.“

Verwertbare Beschreibung:

„Seit 09:15 Uhr erhalten alle geprüften Benutzer beim Anmelden an https://intranet.example.local den HTTP-Statuscode 503. Die Namensauflösung funktioniert und die Startseite ist erreichbar. Der Fehler tritt von mehreren Clients und Benutzerkonten aus auf.“

Beispiele für Schlussfolgerungen:

Diese Zuordnungen sind Arbeitshypothesen und noch kein endgültiger Ursachenbeweis.

Vor der technischen Prüfung müssen folgende Angaben geklärt werden:

Der sichtbare Name einer Anwendung, der Betriebssystem-Dienstname und der Prozessname können unterschiedlich sein.

Beispiel einer Dienstkette:

Client
  → DNS
  → Firewall oder Loadbalancer
  → Webserver
  → Anwendungsdienst
  → Datenbank
  → Verzeichnisdienst oder externe API

Die Störung kann an jeder Übergabestelle dieser Kette entstehen.

Die folgenden Befehle verändern den Systemzustand normalerweise nicht.

Hinweise:

• hostname --fqdn liefert nur dann ein sinnvolles Ergebnis, wenn Hostname und Namensauflösung korrekt konfiguriert sind.
• hostname -f kann unter macOS abhängig von der lokalen Namenskonfiguration fehlschlagen oder einen unerwarteten Namen liefern.
• systeminfo erzeugt eine umfangreiche Ausgabe. Für eine Dokumentation können relevante Zeilen gezielt ausgewählt werden.
• Zeitstempel müssen zusammen mit der Zeitzone dokumentiert werden, damit Client-, Server- und Netzwerkprotokolle richtig verglichen werden können.

Die Platzhalter <SUCHBEGRIFF>, <DIENST> und <PROZESS> müssen ersetzt werden.

Besonderheiten:

• Windows unterscheidet zwischen internem Dienstnamen und sichtbarem Anzeigenamen.
• Bei systemd gehört die Endung .service zum vollständigen Unit-Namen, kann bei eindeutigen Namen aber häufig weggelassen werden.
• launchctl list zeigt nicht automatisch alle Konfigurationsdetails eines Dienstes.
• launchctl print system/<DIENST> erwartet das tatsächliche launchd-Label.
• Ein laufender Prozess beweist noch nicht, dass der Dienst auf dem erwarteten Port lauscht oder fachlich korrekt arbeitet.

Auf dieser frühen Diagnosestufe sollte ein Dienst noch nicht neu gestartet werden. Zuerst müssen Status, Prozess, Port und relevante Protokolle erfasst werden.

Ein Vergleichstest verändert jeweils nur eine Prüfdimension. Dadurch lässt sich erkennen, welche Eigenschaft mit dem Fehler zusammenhängt.

Regel für einen aussagekräftigen Vergleich:

Gleicher Benutzer + anderer Client
oder
anderer Benutzer + gleicher Client
oder
gleicher Client + anderer Netzwerkweg

Werden mehrere Eigenschaften gleichzeitig verändert, ist das Ergebnis häufig nicht eindeutig.

Der direkte Zugriff auf ein Backend kann Sicherheitsregeln, Authentifizierung, TLS-Prüfungen oder den Loadbalancer umgehen. Er darf nur über einen freigegebenen administrativen Testweg erfolgen.

Bevor auf dem Server weitergesucht wird, sollte der Fehler möglichst reproduziert und genau protokolliert werden.

Beispiel:

Zeitpunkt:       2026-07-31T09:15:42+02:00
Client:          client-017
Betriebssystem:  Windows 11
Benutzerrolle:   Standardbenutzer
Ziel:            https://intranet.example.local/login
Aktion:          Anmeldeformular abgesendet
Ergebnis:        HTTP 503
Dauer:           Antwort nach ungefähr 2 Sekunden
Wiederholbar:    Ja
Vergleich:       Gleicher Fehler auf einem zweiten Client

Sensible Inhalte wie Kennwörter, Sitzungscookies, Zugriffstoken, private Schlüssel oder vollständige personenbezogene Daten dürfen nicht in die Dokumentation übernommen werden.

Viele Dienstfehler entstehen nach einer technischen oder organisatorischen Änderung. Ein zeitlicher Zusammenhang ist jedoch noch kein Beweis für die Ursache.

Zu prüfen sind insbesondere:

• Betriebssystem- und Anwendungsupdates,
• Änderungen an Konfigurationsdateien,
• Zertifikatswechsel,
• Kennwortänderungen von Dienstkonten,
• Änderungen an Gruppen oder Berechtigungen,
• Firewall- und Proxyänderungen,
• DNS- oder Loadbalanceränderungen,
• Datenbankmigrationen,
• Speicher- und Volumeänderungen,
• Container- oder Image-Updates,
• Neustarts und Stromausfälle,
• Sicherungs- und Wartungsaufgaben,
• Änderungen an externen APIs,
• abgelaufene Lizenzen oder Zertifikate,
• neu eingerichtete Überwachungs- oder Sicherheitssoftware.

Die Aussage „Seit dem Update besteht der Fehler“ ist eine wichtige Spur. Erst ein reproduzierbarer Zusammenhang oder ein passender Protokolleintrag macht daraus einen belastbaren Ursachenhinweis.

Die erste Eingrenzung ist ausreichend, wenn folgende Punkte beantwortet sind:

• Welche konkrete Funktion ist gestört?
• Welcher Server oder Dienst stellt diese Funktion bereit?
• Welche Benutzer, Geräte und Standorte sind betroffen?
• Welche Bereiche sind ausdrücklich nicht betroffen?
• Seit wann besteht die Störung?
• Ist der Fehler reproduzierbar?
• Welche Fehlermeldung oder welcher Statuscode erscheint?
• Welche Vergleichstests wurden durchgeführt?
• Welche Änderungen gingen der Störung voraus?
• Welche technische Ebene wird als Nächstes geprüft?
• Wurde der Ausgangszustand dokumentiert?

Beispiel einer abgeschlossenen Eingrenzung:

Alle geprüften Benutzer können die Startseite des Intranets über HTTPS aufrufen. Beim Absenden des Anmeldeformulars antwortet die Anwendung jedoch mit HTTP 503. Der Fehler tritt von Windows-, Linux- und macOS-Clients sowie an zwei Standorten auf. DNS-Auflösung und Netzwerkzugriff funktionieren. Als Nächstes werden deshalb Dienststatus, Prozess und Backend-Abhängigkeiten auf dem Anwendungsserver geprüft.

[ ] Konkrete gestörte Funktion erfasst
[ ] Vollständige Fehlermeldung erfasst
[ ] Datum, Uhrzeit und Zeitzone notiert
[ ] Betroffene Benutzer bestimmt
[ ] Betroffene Clients und Betriebssysteme bestimmt
[ ] Betroffene Standorte und Netzwerkwege bestimmt
[ ] Funktionierende Bereiche dokumentiert
[ ] Fehler reproduziert
[ ] Vergleichstest durchgeführt
[ ] Servername und Umgebung verifiziert
[ ] Dienstname, Prozess, Protokoll und Port zugeordnet
[ ] Abhängige Systeme aufgenommen
[ ] Letzte Änderungen erfragt
[ ] Ausgangszustand vor Änderungen dokumentiert
[ ] Keine Kennwörter, Token oder vertraulichen Daten gespeichert
[ ] Nächster technischer Prüfschritt festgelegt