# 1.8 Lösung umsetzen, Rückfallplan anwenden und Funktion verifizieren

Nachdem die Ursache ausreichend bestätigt wurde, kann eine geeignete Lösung geplant und umgesetzt werden.

Dabei gilt:

> Eine Störung gilt nicht als behoben, nur weil eine Fehlermeldung verschwunden ist. Die ursprüngliche Funktion, ihre Abhängigkeiten und mögliche Nebenwirkungen müssen anschließend geprüft werden.

Jede technische Korrektur ist selbst eine Änderung und kann neue Fehler verursachen. Deshalb benötigt auch eine scheinbar einfache Maßnahme einen definierten Ausgangszustand, Erfolgskriterien und einen Rückfallplan.

---

**Ziel dieser Seite**

Nach diesem Arbeitsschritt sollten:

- Sofortmaßnahme und dauerhafte Lösung getrennt sein,
- Ziel und Umfang der Änderung definiert sein,
- Risiken und Abhängigkeiten bekannt sein,
- Konfiguration oder Ausgangszustand gesichert sein,
- ein überprüfbarer Rückfallplan vorliegen,
- Erfolgskriterien und Abbruchkriterien definiert sein,
- die Änderung möglichst schrittweise erfolgen,
- technische Funktion und Benutzerfunktion geprüft sein,
- Monitoring und Protokolle nach der Änderung kontrolliert sein,
- bei Fehlschlag kontrolliert zurückgefallen werden können.

---

**1. Kennzeichnung der Befehle**

| Kennzeichnung | Bedeutung |
|---|---|
| `[RO]` | Read-only: liest Informationen aus |
| `[TEST]` | Führt eine aktive Prüfung aus |
| `[FILE]` | Erstellt oder überschreibt eine Datei |
| `[PRIV]` | Benötigt möglicherweise Administrator- oder Root-Rechte |
| `[CHANGE]` | Verändert Konfiguration oder Betriebszustand |
| `[DISRUPTIV]` | Kann Benutzer oder produktive Dienste beeinträchtigen |
| `[SENSITIV]` | Ausgabe kann vertrauliche Daten enthalten |

---

**2. Maßnahmenarten unterscheiden**

| Maßnahmenart | Zweck | Beispiel |
|---|---|---|
| Sofortmaßnahme | Auswirkungen schnell begrenzen | fehlerhaftes Backend aus dem Load Balancer nehmen |
| Workaround | Fehler umgehen, ohne Ursache zu entfernen | Benutzer verwendet vorübergehend anderen Server |
| Mitigation | Auswirkung oder Wahrscheinlichkeit reduzieren | Traffic auf funktionierende Instanzen begrenzen |
| Reparatur | unmittelbaren technischen Fehler beseitigen | fehlerhafte Konfiguration korrigieren |
| Dauerhafte Lösung | bestätigte Grundursache beseitigen | automatische Konfigurationsvalidierung einführen |
| Präventionsmaßnahme | Wiederholung oder Auswirkung verhindern | Canary-Rollout und Monitoring ergänzen |
| Rollback | vorherigen bekannten Zustand wiederherstellen | vorherige Anwendungsversion aktivieren |
| Roll-forward | Fehler durch eine neue Korrektur beheben | korrigierte Folgeversion bereitstellen |

Ein Workaround kann den Betrieb wiederherstellen, ohne die eigentliche Ursache zu beseitigen. Er muss deshalb als temporär gekennzeichnet und nachverfolgt werden.

---

**3. Wiederherstellung und Ursachenbehebung unterscheiden**

**Wiederherstellung**

Ziel ist, die betroffene Funktion möglichst schnell wieder bereitzustellen.

Beispiele:

- Dienst neu starten,
- fehlerhaftes Backend deaktivieren,
- Failover auslösen,
- vorherige Konfiguration wiederherstellen,
- Ersatzgerät verwenden,
- Benutzer auf ein anderes System umleiten.

**Ursachenbehebung**

Ziel ist, das erneute Auftreten zu verhindern.

Beispiele:

- Konfigurationsvalidierung ergänzen,
- Speicherleck durch Softwarekorrektur beseitigen,
- Monitoring erweitern,
- fehlerhafte Automatisierung korrigieren,
- Redundanz verbessern,
- unklare Berechtigungsstruktur bereinigen.

Eine Störung kann bereits wiederhergestellt sein, während die dauerhafte Ursachenbehebung noch offen ist.

---

**4. Vor jeder Änderung zu klärende Fragen**

- Was genau soll verändert werden?
- Welche bestätigte Ursache wird damit behandelt?
- Welches System und welche Komponente sind betroffen?
- Welche Benutzer oder Dienste können beeinträchtigt werden?
- Welche Abhängigkeiten bestehen?
- Ist die Änderung dokumentiert und freigegeben?
- Ist der aktuelle Zustand gesichert?
- Existiert ein getesteter Rückfallweg?
- Welche Erfolgskriterien gelten?
- Welche Abbruchkriterien gelten?
- Wie lange darf die Änderung dauern?
- Wer führt die Änderung durch?
- Wer beobachtet Monitoring und Protokolle?
- Wer entscheidet über einen Rollback?
- Wie werden betroffene Personen informiert?

---

**5. Änderungsumfang möglichst klein halten**

Eine Korrektur sollte nur die Komponente verändern, die für die bestätigte Ursache relevant ist.

**Ungeeignet**

- mehrere Firewall-Regeln gleichzeitig ändern,
- Anwendung und Betriebssystem gleichzeitig aktualisieren,
- Dienstkonto und Berechtigungen gleichzeitig verändern,
- mehrere Backends gleichzeitig neu konfigurieren,
- gleichzeitig DNS, Proxy und Routing anpassen.

**Besser**

1. eine klar definierte Änderung,
2. definierter Funktionstest,
3. Beobachtung,
4. nächste Änderung nur bei Bedarf.

Kleine Änderungen lassen sich leichter:

- überprüfen,
- zuordnen,
- zurücknehmen,
- dokumentieren,
- auf Nebenwirkungen untersuchen.

---

**6. Risiko der Änderung bewerten**

| Risikofaktor | Niedriges Risiko | Hohes Risiko |
|---|---|---|
| Umfang | einzelner Testclient | gesamte Produktion |
| Reversibilität | einfache Konfigurationsrücknahme | irreversible Datenmigration |
| Verfügbarkeit | redundantes System | einzelner kritischer Server |
| Erfahrung | dokumentierte Standardänderung | erstmalige unbekannte Änderung |
| Abhängigkeiten | wenige bekannte Abhängigkeiten | viele unbekannte Abhängigkeiten |
| Daten | keine Datenänderung | Schema- oder Datenänderung |
| Zugang | lokaler Konsolenzugang | nur entfernte Verbindung |
| Testbarkeit | funktionierende Testumgebung | nur Produktion verfügbar |
| Beobachtung | vollständiges Monitoring | kaum Messwerte vorhanden |
| Zeitdruck | geplantes Wartungsfenster | ungeplanter kritischer Ausfall |

---

**7. Änderungsplan erstellen**

| Feld | Eintrag |
|---|---|
| Ticket- oder Change-Nummer |  |
| bestätigte Ursache |  |
| geplante Änderung |  |
| technisches Ziel |  |
| betroffene Systeme |  |
| betroffene Benutzer |  |
| Abhängigkeiten |  |
| erwartete Unterbrechung |  |
| Risiko | Niedrig / Mittel / Hoch |
| ausführende Person |  |
| beobachtende Person |  |
| Wartungsfenster |  |
| Sicherung des Ausgangszustands |  |
| Erfolgskriterien |  |
| Abbruchkriterien |  |
| Rückfallplan |  |
| Rückfallentscheidung durch |  |
| Kommunikationsweg |  |
| Beobachtungsdauer |  |

---

**8. Backup und Rollback unterscheiden**

| Begriff | Bedeutung |
|---|---|
| Backup | Sicherung von Daten oder Konfiguration |
| Restore | Wiederherstellung aus einem Backup |
| Rollback | Rückkehr zum vorherigen bekannten Betriebszustand |
| Snapshot | Momentaufnahme eines bestimmten Systems oder Datenträgers |
| Export | Sicherung einer Konfiguration in einem unterstützten Format |
| Roll-forward | Korrektur durch eine nachfolgende Version oder Änderung |

Ein vorhandenes Backup ist noch kein vollständiger Rückfallplan.

Ein Rückfallplan beantwortet zusätzlich:

- Welche Sicherung wird verwendet?
- Wie wird sie zurückgespielt?
- Welche Dienste müssen vorher beendet werden?
- Welche Abhängigkeiten sind betroffen?
- Wie lange dauert die Wiederherstellung?
- Wie wird der Erfolg des Rollbacks geprüft?
- Was geschieht mit Daten, die nach der Änderung entstanden sind?
- Wer darf den Rollback freigeben?
- Was geschieht, wenn auch der Rollback fehlschlägt?

---

**9. Grenzen von Snapshots beachten**

Ein Snapshot ersetzt kein reguläres Backup und ist nicht für jede Anwendung als Rückfallmethode geeignet.

Besondere Vorsicht gilt unter anderem bei:

- Datenbanken,
- Active Directory,
- verteilten Dateisystemen,
- Clustern,
- Replikationssystemen,
- Transaktionssystemen,
- verschlüsselten Volumes,
- Anwendungen mit externen Abhängigkeiten.

Vor der Nutzung eines Snapshots muss geprüft werden:

- Unterstützt der Hersteller diese Wiederherstellung?
- Ist der Snapshot anwendungskonsistent?
- Welche externen Systeme wurden seitdem verändert?
- Entstehen Replikations- oder Transaktionsprobleme?
- Gehen nach dem Snapshot erzeugte Daten verloren?
- Existiert zusätzlich ein unabhängiges Backup?

---

**10. Ausgangskonfiguration sichern**

Für produktive Systeme sollte möglichst die vom Hersteller vorgesehene Export-, Backup- oder Versionsverwaltungsfunktion verwendet werden.

Einfache Dateikopien sind nur für einzelne Konfigurationsdateien geeignet, wenn Berechtigungen, Besitzer, ACLs, erweiterte Attribute und Anwendungsanforderungen berücksichtigt werden.

---

**Windows-Beispiel für eine einzelne Konfigurationsdatei**

    $backupFile = Join-Path "<Zielpfad>" "config-$(Get-Date -Format 'yyyyMMdd-HHmmss').bak"

    Copy-Item "<Konfigurationsdatei>" $backupFile

    Get-FileHash -Path "<Konfigurationsdatei>", $backupFile -Algorithm SHA256

Kennzeichnung:

- `Copy-Item`: `[FILE]`
- `Get-FileHash`: `[RO]`

Die Prüfsummen sollten bei einer unveränderten Kopie identisch sein.

---

**Linux-Beispiel für eine einzelne Konfigurationsdatei**

    backup_file="<Zielpfad>/config-$(date +%Y%m%d-%H%M%S).bak"

    cp --preserve=all -- "<Konfigurationsdatei>" "$backup_file"

    sha256sum "<Konfigurationsdatei>" "$backup_file"

`cp --preserve=all` ist eine GNU-Option und steht nicht auf jedem Unix-System zur Verfügung.

---

**macOS-Beispiel für eine einzelne Konfigurationsdatei**

    backup_file="<Zielpfad>/config-$(date +%Y%m%d-%H%M%S).bak"

    cp -p "<Konfigurationsdatei>" "$backup_file"

    shasum -a 256 "<Konfigurationsdatei>" "$backup_file"

`cp -p` erhält wichtige Dateiattribute, garantiert aber nicht für jede Anwendung die vollständige Sicherung aller Metadaten. Für komplexe Anwendungen muss die vorgesehene Backupfunktion verwendet werden.

---

**11. Konfiguration vor der Aktivierung validieren**

Eine Konfigurationsdatei sollte möglichst vor einem Reload oder Neustart geprüft werden.

**JSON unter Windows PowerShell prüfen**

`[TEST] Get-Content "<Datei.json>" -Raw | ConvertFrom-Json | Out-Null`

Bei ungültigem JSON erzeugt PowerShell eine Fehlermeldung.

**JSON unter Linux oder macOS mit Python prüfen**

`[TEST] python3 -m json.tool "<Datei.json>" > /dev/null`

**JSON mit jq prüfen, sofern installiert**

`[TEST] jq empty "<Datei.json>"`

**macOS-Property-List prüfen**

`[TEST] plutil -lint "<Datei.plist>"`

**systemd-Unit-Datei prüfen**

`[TEST] systemd-analyze verify "<Datei.service>"`

**NGINX-Konfiguration prüfen**

`[TEST][PRIV] nginx -t`

**Apache-Konfiguration prüfen**

`[TEST][PRIV] apachectl configtest`

**OpenSSH-Serverkonfiguration prüfen**

`[TEST][PRIV] sshd -t`

> Die Werkzeuge prüfen unterschiedliche Aspekte. Ein erfolgreicher Syntax-Test bestätigt nicht automatisch, dass Netzwerkziele, Zugangsdaten, Zertifikate und abhängige Dienste funktionieren.

---

**12. PowerShell-Änderung mit WhatIf vorprüfen**

Einige PowerShell-Cmdlets unterstützen den allgemeinen Parameter `-WhatIf`.

**Beispiel**

`[TEST] Restart-Service -Name <Dienstname> -WhatIf`

PowerShell zeigt, welche Aktion vorgesehen ist, führt den Neustart aber nicht aus.

**Wichtige Einschränkung**

`-WhatIf`:

- simuliert nicht die Anwendung selbst,
- prüft nicht die spätere Funktionsfähigkeit,
- erkennt nicht jede Abhängigkeit,
- prüft nicht automatisch den Rückfallplan,
- funktioniert nur bei Befehlen, die `-WhatIf` unterstützen.

---

**13. Dienständerungen unter Windows**

**Aktuellen Zustand prüfen**

`[RO] Get-Service -Name <Dienstname>`

**Abhängige Dienste prüfen**

`[RO] Get-Service -Name <Dienstname> -DependentServices`

**Benötigte Dienste prüfen**

`[RO] Get-Service -Name <Dienstname> -RequiredServices`

**Dienstkonfiguration prüfen**

`[RO][SENSITIV] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" | Select-Object Name, State, StartMode, StartName, PathName, ProcessId`

**Neustart zunächst anzeigen**

`[TEST] Restart-Service -Name <Dienstname> -WhatIf`

**Dienst mit Bestätigungsabfrage neu starten**

`[CHANGE][DISRUPTIV][PRIV] Restart-Service -Name <Dienstname> -Confirm`

**Gestoppten Dienst starten**

`[CHANGE][PRIV] Start-Service -Name <Dienstname> -Confirm`

**Zustand danach prüfen**

`[RO] Get-Service -Name <Dienstname>`

> `Restart-Service` sendet eine Stopp- und anschließend eine Startanforderung. War der Dienst bereits gestoppt, versucht das Cmdlet ihn zu starten. Vorher müssen abhängige Dienste und Auswirkungen geprüft werden.

---

**14. Dienständerungen unter Linux**

**Aktuellen Zustand prüfen**

`[RO] systemctl status <Dienstname>.service --no-pager`

**Zustand kompakt prüfen**

`[RO] systemctl is-active <Dienstname>.service`

**Reload-Fähigkeit prüfen**

`[RO] systemctl show <Dienstname>.service -p CanReload -p ActiveState -p SubState -p MainPID`

**Konfiguration neu laden**

`[CHANGE][PRIV] sudo systemctl reload <Dienstname>.service`

Ein Reload funktioniert nur, wenn der Dienst diese Funktion unterstützt.

**Dienst neu starten**

`[CHANGE][DISRUPTIV][PRIV] sudo systemctl restart <Dienstname>.service`

**Nur dann neu starten, wenn der Dienst bereits läuft**

`[CHANGE][DISRUPTIV][PRIV] sudo systemctl try-restart <Dienstname>.service`

**Zustand danach prüfen**

`[RO] systemctl status <Dienstname>.service --no-pager`

**Neue Protokolle anzeigen**

`[RO] journalctl -u <Dienstname>.service --since "5 minutes ago" --no-pager`

---

**15. Dienständerungen unter macOS**

macOS verwendet `launchd`. Für die Befehle muss der richtige Dienstkontext bekannt sein.

**Systemdienst prüfen**

`[RO][PRIV] launchctl print system/<Dienstlabel>`

**Benutzerdienst prüfen**

`[RO] launchctl print gui/$(id -u)/<Dienstlabel>`

**Systemdienst beenden und neu starten**

`[CHANGE][DISRUPTIV][PRIV] sudo launchctl kickstart -k system/<Dienstlabel>`

**Benutzerdienst beenden und neu starten**

`[CHANGE][DISRUPTIV] launchctl kickstart -k gui/$(id -u)/<Dienstlabel>`

Die Option `-k` beendet eine bereits laufende Instanz, bevor sie neu gestartet wird.

**Protokolle danach prüfen**

`[RO] log show --last 5m --predicate 'process == "<Prozessname>"' --style compact`

> Vor dem Einsatz muss die lokale Dokumentation mit `man launchctl` geprüft werden. System-, Benutzer- und GUI-Dienste verwenden unterschiedliche Domains. Ein falscher Dienstkontext kann dazu führen, dass nicht der erwartete Dienst angesprochen wird.

---

**16. Reload, Restart und Reboot unterscheiden**

| Maßnahme | Wirkung | Typisches Risiko |
|---|---|---|
| Reload | Konfiguration wird im laufenden Prozess neu geladen | Niedrig bis mittel |
| Restart | Prozess wird beendet und neu gestartet | Mittel bis hoch |
| Reboot | gesamtes Betriebssystem wird neu gestartet | Hoch |
| Failover | Betrieb wechselt auf anderes System | Mittel bis hoch |
| Rollback | vorheriger Zustand wird wiederhergestellt | Abhängig von Daten und Anwendung |

**Sinnvolle Reihenfolge**

1. anwendungseigene Konfigurationsprüfung,
2. Reload, wenn unterstützt,
3. gezielter Dienstneustart,
4. Failover oder Rollback,
5. vollständiger Systemneustart nur mit technischer Begründung.

Ein vollständiger Neustart sollte nicht als Standardlösung verwendet werden, wenn ein einzelner Dienst gezielt behandelt werden kann.

---

**17. Änderungen schrittweise ausrollen**

| Verfahren | Beschreibung |
|---|---|
| Einzelner Testclient | Änderung zunächst auf einem ausgewählten Client |
| Einzelne Instanz | Änderung auf einem Server innerhalb einer redundanten Gruppe |
| Canary | kleiner Anteil produktiver Systeme oder Anfragen |
| Rolling Deployment | Instanzen werden nacheinander geändert |
| Blue-Green | neue und alte Umgebung existieren parallel |
| Staged Rollout | Änderung wird in definierten Stufen erweitert |
| Wartungsgruppe | ausgewählte Benutzer oder Systeme werden zuerst umgestellt |

**Beispiel für einen stufenweisen Rollout**

1. Testumgebung,
2. einzelne produktionsnahe Instanz,
3. ausgewählte Benutzer,
4. kleiner Produktionsanteil,
5. Monitoring auswerten,
6. weitere Instanzen,
7. vollständiger Rollout.

Nach jeder Stufe muss ein Entscheidungspunkt bestehen:

- fortsetzen,
- beobachten,
- stoppen,
- zurückfallen.

---

**18. Canary und Kontrollgruppe vergleichen**

| Messwert | Kontrollgruppe | Canary | Bewertung |
|---|---:|---:|---|
| Fehlerrate | 0,5 % | 0,6 % | ähnlich |
| Antwortzeit | 220 ms | 225 ms | ähnlich |
| CPU-Auslastung | 42 % | 44 % | ähnlich |
| HTTP 500 | 2 | 3 | beobachten |
| erfolgreiche Anmeldungen | 99,5 % | 99,4 % | ähnlich |
| neue Protokollfehler | 0 | 0 | unauffällig |

Die Bewertung darf nicht nur auf dem Gesamtsystem erfolgen. Ein kleiner Canary kann in aggregierten Messwerten unsichtbar bleiben. Canary und Kontrollgruppe müssen getrennt ausgewertet werden.

---

**19. Abbruchkriterien vor dem Rollout festlegen**

Mögliche Abbruchkriterien:

- Dienst startet nicht,
- Health Check schlägt fehl,
- Benutzerfunktion funktioniert nicht,
- Fehlerquote steigt über den freigegebenen Grenzwert,
- Antwortzeit verschlechtert sich erheblich,
- Datenintegritätsfehler tritt auf,
- unerwartete Systeme sind betroffen,
- Administrationszugang geht verloren,
- Monitoring meldet kritische Fehler,
- Rückfallmöglichkeit ist nicht mehr gewährleistet,
- Wartungsfenster wird überschritten.

Schwellenwerte müssen aus SLA, SLO, Monitoring-Baseline oder dokumentierten Anforderungen stammen und dürfen nicht frei erfunden werden.

---

**20. Technische Verifikation in mehreren Ebenen**

| Ebene | Zu prüfende Frage |
|---|---|
| Prozess | Läuft der erwartete Prozess? |
| Dienst | Meldet der Dienst einen gesunden Zustand? |
| Listener | Lauscht der erwartete Port? |
| Netzwerk | Ist das Ziel vom vorgesehenen Client erreichbar? |
| TLS | Funktionieren Zertifikat und Handshake? |
| Protokoll | Liefert der Dienst eine gültige Antwort? |
| Authentifizierung | Kann sich der Benutzer anmelden? |
| Autorisierung | Darf der Benutzer die vorgesehene Funktion verwenden? |
| Anwendung | Funktioniert die konkrete Aktion? |
| Daten | Werden Daten korrekt gelesen und geschrieben? |
| Abhängigkeiten | Funktionieren Datenbank, Storage, DNS und APIs? |
| Monitoring | Wird das System korrekt als gesund erkannt? |
| Protokolle | Entstehen keine neuen relevanten Fehler? |
| Redundanz | Sind verbleibende Instanzen und Failover weiterhin verfügbar? |

---

**21. Windows-Verifikation**

**Dienststatus**

`[RO] Get-Service -Name <Dienstname>`

**Prozess-ID des Dienstes**

`[RO] Get-CimInstance Win32_Service -Filter "Name='<Dienstname>'" | Select-Object Name, State, ProcessId`

**TCP-Listener**

`[RO][PRIV] Get-NetTCPConnection -State Listen -LocalPort <Port>`

**Remote-Porttest**

`[TEST] Test-NetConnection <Servername> -Port <Port> -InformationLevel Detailed`

**HTTP- oder HTTPS-Test**

`[TEST] curl.exe -sS -o NUL -w "HTTP=%{http_code} Ziel=%{remote_ip} Gesamt=%{time_total}\n" --connect-timeout 5 --max-time 15 https://<Servername>/`

**Neue Systemereignisse**

`[RO] Get-WinEvent -FilterHashtable @{LogName="System"; StartTime=(Get-Date).AddMinutes(-10)} | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message`

**Neue Anwendungsereignisse**

`[RO] Get-WinEvent -FilterHashtable @{LogName="Application"; StartTime=(Get-Date).AddMinutes(-10)} | Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message`

---

**22. Linux-Verifikation**

**Dienststatus**

`[RO] systemctl status <Dienstname>.service --no-pager`

**Nur aktiven Zustand abfragen**

`[RO] systemctl is-active <Dienstname>.service`

**Hauptprozess-ID**

`[RO] systemctl show <Dienstname>.service -p MainPID`

**TCP-Listener**

`[RO][PRIV] ss -lntp | grep ":<Port>"`

**Remote-Porttest**

`[TEST] nc -vz -w 3 <Servername> <Port>`

**HTTP- oder HTTPS-Test**

`[TEST] curl -sS -o /dev/null -w "HTTP=%{http_code} Ziel=%{remote_ip} Gesamt=%{time_total}\n" --connect-timeout 5 --max-time 15 https://<Servername>/`

**Neue Dienstprotokolle**

`[RO] journalctl -u <Dienstname>.service --since "10 minutes ago" --no-pager`

**Neue Fehler des Systems**

`[RO] journalctl --since "10 minutes ago" -p err --no-pager`

---

**23. macOS-Verifikation**

**Systemdienststatus**

`[RO][PRIV] launchctl print system/<Dienstlabel>`

**Benutzerdienststatus**

`[RO] launchctl print gui/$(id -u)/<Dienstlabel>`

**TCP-Listener**

`[RO][PRIV] lsof -nP -iTCP:<Port> -sTCP:LISTEN`

**Remote-Porttest**

`[TEST] nc -vz -w 3 <Servername> <Port>`

**HTTP- oder HTTPS-Test**

`[TEST] curl -sS -o /dev/null -w "HTTP=%{http_code} Ziel=%{remote_ip} Gesamt=%{time_total}\n" --connect-timeout 5 --max-time 15 https://<Servername>/`

**Neue Prozessprotokolle**

`[RO] log show --last 10m --predicate 'process == "<Prozessname>"' --style compact`

**Neue Fehler und Faults**

`[RO] log show --last 10m --predicate 'messageType == error OR messageType == fault' --style compact`

---

**24. Ursprüngliche Benutzerfunktion prüfen**

Eine technische Verifikation reicht nicht aus. Abschließend muss die ursprünglich gestörte Funktion getestet werden.

**Beispiele**

- Benutzer kann sich anmelden,
- Datei kann geöffnet werden,
- Datei kann gespeichert werden,
- E-Mail kann gesendet und empfangen werden,
- Druckauftrag wird vollständig ausgegeben,
- VPN-Verbindung wird aufgebaut,
- Anwendung kann Datenbankdaten lesen,
- Anwendung kann Daten speichern,
- Backupjob endet erfolgreich,
- Client erhält korrekte DHCP-Optionen,
- Gruppenrichtlinie wird angewendet,
- API liefert erwartete Daten.

Der Test sollte möglichst:

- vom ursprünglichen Quellsystem,
- mit dem ursprünglichen Benutzerkontext,
- über denselben Netzwerkpfad,
- mit derselben Zieladresse,
- mit derselben Aktion

durchgeführt werden.

---

**25. Positive und negative Tests durchführen**

**Positiver Test**

Prüft, ob eine erlaubte Funktion erfolgreich ist.

Beispiel:

`Ein berechtigter Benutzer kann eine Datei lesen.`

**Negativer Test**

Prüft, ob eine nicht erlaubte Funktion weiterhin verhindert wird.

Beispiel:

`Ein unberechtigter Benutzer kann die Datei weiterhin nicht lesen.`

**Weitere negative Tests**

- geschlossener Port bleibt geschlossen,
- nicht autorisierter Benutzer bleibt abgewiesen,
- deaktiviertes Konto kann sich nicht anmelden,
- abgelaufenes Token wird nicht akzeptiert,
- unerlaubtes VLAN erhält keinen Zugriff,
- alte verwundbare Schnittstelle bleibt deaktiviert.

Eine Lösung ist fehlerhaft, wenn sie die Funktion wiederherstellt, dabei aber Sicherheitskontrollen unbeabsichtigt entfernt.

---

**26. Regressionstests durchführen**

Ein Regressionstest prüft, ob bisher funktionierende Bereiche nach der Änderung weiterhin funktionieren.

| Geänderte Komponente | Mögliche Regressionstests |
|---|---|
| Firewall | andere erlaubte und gesperrte Verbindungen |
| DNS | interne und externe Namensauflösung |
| DHCP | neue und bestehende Clients |
| Webserver | Anmeldung, Upload, Download, API |
| Datenbank | Lesen, Schreiben, Replikation, Backup |
| Dateiserver | Lesen, Schreiben, ACL, Freigaben |
| Active Directory | Anmeldung, Gruppenrichtlinie, Replikation |
| Proxy | erlaubte Seiten, Ausnahmen, Authentifizierung |
| Zertifikat | Browser, API, mobile Clients, alte Clients |
| Load Balancer | alle Backends, Health Checks, Sitzungen |
| Backup | Sicherung und testweise Wiederherstellung |

---

**27. Persistenz der Lösung prüfen**

Manche Korrekturen funktionieren nur bis zum nächsten:

- Neustart,
- Dienstneustart,
- DHCP-Lease-Wechsel,
- Gruppenrichtlinien-Refresh,
- Konfigurationsdeployment,
- Container-Neustart,
- Failover,
- Update,
- Passwort- oder Zertifikatswechsel.

Zu prüfen ist:

- Wurde die richtige permanente Konfiguration geändert?
- Wird die Datei durch Automatisierung überschrieben?
- Stammt die Konfiguration aus einer zentralen Quelle?
- Ist die Änderung in Versionsverwaltung übernommen?
- Muss ein Deploymenttemplate angepasst werden?
- Existieren mehrere Konfigurationskopien?
- Wird beim Neustart eine alte Konfiguration geladen?

Ein Neustart zur Persistenzprüfung darf nur geplant durchgeführt werden, wenn er technisch erforderlich und freigegeben ist.

---

**28. Monitoring nach der Änderung**

Nach einer erfolgreichen Funktionsprüfung muss das System weiter beobachtet werden.

**Zu beobachtende Werte**

- Verfügbarkeit,
- Fehlerquote,
- Antwortzeit,
- CPU-Auslastung,
- Speichernutzung,
- Datenträgerbelegung,
- I/O-Wartezeit,
- Netzwerkfehler,
- Verbindungsanzahl,
- Warteschlangen,
- Datenbankverbindungen,
- Replikationszustand,
- Zertifikatsfehler,
- Anmeldefehler,
- Benutzerbeschwerden.

Die Beobachtungsdauer richtet sich nach dem Fehlerbild.

| Fehlerart | Geeignete Beobachtung |
|---|---|
| dauerhafter Startfehler | unmittelbare Tests nach Start |
| sporadischer Fehler | mehrere typische Nutzungszyklen |
| nächtlicher Job | mindestens nächster geplanter Lauf |
| DHCP-Problem | mindestens ein Lease-Erneuerungszyklus |
| Backupfehler | vollständiger Sicherungs- und Prüfzyklus |
| Lastproblem | typischer Lastzeitraum |
| Zertifikatserneuerung | vollständige Kette und betroffene Clients |
| Replikationsproblem | vorgesehener Replikationszyklus |

---

**29. Rollback-Auslöser**

Ein Rollback sollte ausgelöst werden, wenn:

- definiertes Erfolgskriterium nicht erreicht wird,
- ursprünglicher Fehler bestehen bleibt,
- neue kritische Fehler entstehen,
- unerwartete Systeme betroffen sind,
- Sicherheitskontrolle nicht mehr funktioniert,
- Datenintegrität gefährdet ist,
- Administrationszugang verloren zu gehen droht,
- Abbruchkriterium erreicht wird,
- Wartungsfenster überschritten wird,
- weitere sichere Diagnose nicht möglich ist.

Die Entscheidung darf nicht erst improvisiert werden, nachdem ein Problem entstanden ist.

---

**30. Kontrollierter Rollback-Ablauf**

1. weiteren Rollout stoppen,
2. zuständige Personen informieren,
3. aktuellen Fehlerzustand sichern,
4. Rückfallentscheidung dokumentieren,
5. freigegebenen Rückfallplan ausführen,
6. Dienst- und Systemstatus prüfen,
7. ursprüngliche Funktion testen,
8. negative Tests durchführen,
9. Protokolle und Monitoring kontrollieren,
10. Ergebnis dokumentieren,
11. weitere Untersuchung planen.

> Auch ein Rollback ist eine Änderung und kann fehlschlagen.

---

**31. Rollback oder Roll-forward wählen**

| Situation | Rollback eher geeignet | Roll-forward eher geeignet |
|---|---|---|
| vorherige Version bekannt funktionsfähig | Ja | Möglich |
| Konfiguration einfach reversibel | Ja | Möglich |
| Datenbankschema bereits verändert | Riskant | Häufig besser |
| neue Daten nicht rückwärtskompatibel | Riskant | Häufig besser |
| kritische Sicherheitslücke würde wieder geöffnet | Eher ungeeignet | Besser |
| Fehlerkorrektur ist klein und geprüft | Möglich | Häufig besser |
| vorheriger Zustand nicht eindeutig | Riskant | Möglicherweise besser |
| Rollback bereits getestet | Ja | Nicht zwingend |
| Zeit bis zur Folgekorrektur sehr lang | Häufig besser | Eher ungeeignet |
| Produktionsauswirkung steigt schnell | schneller sicherer Weg entscheidend | schneller sicherer Weg entscheidend |

Ein Rollback darf keine bekannte Sicherheitslücke oder Dateninkonsistenz unbewertet wieder einführen.

---

**32. Rollback einfacher Konfigurationsdateien**

Eine Konfigurationsdatei darf nur dann direkt zurückkopiert werden, wenn:

- die Sicherung eindeutig zugeordnet ist,
- die Prüfsumme geprüft wurde,
- keine neuen relevanten Änderungen verloren gehen,
- Dateibesitzer und Berechtigungen bekannt sind,
- keine Datenmigration betroffen ist,
- die Anwendung dieses Verfahren unterstützt,
- der Dienst anschließend korrekt validiert werden kann.

**Windows-Beispiel**

`[CHANGE][PRIV] Copy-Item "<Sicherungsdatei>" "<Konfigurationsdatei>" -Force`

**Linux-Beispiel**

`[CHANGE][PRIV] sudo cp --preserve=all -- "<Sicherungsdatei>" "<Konfigurationsdatei>"`

**macOS-Beispiel**

`[CHANGE][PRIV] sudo cp -p "<Sicherungsdatei>" "<Konfigurationsdatei>"`

> Diese Befehle sind keine universelle Rollbacklösung. Datenbanken, Verzeichnisdienste, Cluster, Containerplattformen und komplexe Anwendungen benötigen die vom Hersteller vorgesehene Wiederherstellungsmethode.

Nach dem Zurückkopieren müssen mindestens geprüft werden:

- Inhalt,
- Prüfsumme,
- Besitzer,
- Gruppe,
- Berechtigungen,
- ACL,
- Syntax,
- Dienststart,
- Funktion.

---

**33. Kommunikation während der Umsetzung**

| Zeitpunkt | Information |
|---|---|
| Vor Beginn | Umfang, erwartete Auswirkung und Zeitraum |
| Zu Beginn | Änderung wurde gestartet |
| Währenddessen | relevante Abweichungen oder Verzögerungen |
| Bei Abbruch | Grund und eingeleitete Rückfallmaßnahme |
| Nach Erfolg | Funktion wiederhergestellt und Beobachtung läuft |
| Nach Rollback | vorheriger Zustand wiederhergestellt |
| Nach Abschluss | Ergebnis, offene Punkte und Präventionsmaßnahmen |

Technische Kommunikation sollte sachlich sein und zwischen folgenden Zuständen unterscheiden:

- Störung erkannt,
- Ursache vermutet,
- Ursache bestätigt,
- Workaround aktiv,
- Dienst wiederhergestellt,
- dauerhafte Lösung umgesetzt,
- Beobachtung läuft,
- Störung abgeschlossen.

---

**34. Vollständiges Praxisbeispiel**

**Störung**

Ein Backend liefert HTTP `503`, weil die Anwendung einen falschen Datenbank-Hostnamen verwendet.

**Bestätigte Ursache**

Die neue Konfigurationsdatei enthält `db-prdo.example` statt `db-prod.example`.

**Geplante Lösung**

- Konfiguration korrigieren,
- Syntax validieren,
- Änderung zunächst auf einem Backend anwenden,
- Dienst neu laden oder neu starten,
- technische und fachliche Funktion prüfen,
- danach weitere Instanzen ändern.

**Rückfallplan**

- gesicherte vorherige Konfiguration zurückspielen,
- Dienst erneut starten,
- Backend aus Load-Balancer-Rotation entfernen, falls es weiterhin fehlerhaft ist.

**Erfolgskriterien**

- Dienststatus aktiv,
- TCP-Listener vorhanden,
- Datenbankverbindung erfolgreich,
- HTTP-Health-Check erfolgreich,
- Anmeldung funktioniert,
- keine neuen Fehler im Protokoll,
- Fehlerrate entspricht der Kontrollgruppe.

**Abbruchkriterien**

- Dienst startet nicht,
- Datenbankverbindung bleibt gestört,
- neue Fehler treten auf,
- Antwortzeit verschlechtert sich deutlich,
- Benutzerfunktion schlägt fehl.

**Ablauf**

| Schritt | Maßnahme |
|---:|---|
| 1 | Ausgangszustand und Protokolle sichern |
| 2 | aktuelle Konfiguration sichern und Prüfsumme bilden |
| 3 | korrigierte Datei in Testumgebung validieren |
| 4 | ein Backend aus der Rotation nehmen |
| 5 | Konfiguration auf diesem Backend ändern |
| 6 | Konfigurationsprüfung ausführen |
| 7 | Dienst kontrolliert neu laden oder starten |
| 8 | Listener und Protokolle prüfen |
| 9 | Datenbankfunktion prüfen |
| 10 | HTTP- und Anmeldetest durchführen |
| 11 | Backend mit Kontrollgruppe vergleichen |
| 12 | Backend wieder in Rotation nehmen |
| 13 | Monitoring beobachten |
| 14 | Änderung schrittweise auf weitere Instanzen ausrollen |

---

**35. Verifikationsprotokoll**

| Feld | Vor Änderung | Nach Änderung | Nach Beobachtung |
|---|---|---|---|
| Zeitpunkt |  |  |  |
| Dienststatus |  |  |  |
| Prozess-ID |  |  |  |
| Listener |  |  |  |
| Ziel-IP |  |  |  |
| HTTP-Status |  |  |  |
| Antwortzeit |  |  |  |
| Authentifizierung |  |  |  |
| Benutzerfunktion |  |  |  |
| Datenbankverbindung |  |  |  |
| Fehler im Protokoll |  |  |  |
| Monitoringstatus |  |  |  |
| Fehlerrate |  |  |  |
| Nebenwirkungen |  |  |  |

---

**36. Änderungs- und Rollbackprotokoll**

| Feld | Eintrag |
|---|---|
| Ticket- oder Change-Nummer |  |
| bestätigte Ursache |  |
| umgesetzte Änderung |  |
| Beginn |  |
| Ende |  |
| ausführende Person |  |
| betroffene Systeme |  |
| Sicherungsdatei oder Backup |  |
| Prüfsumme |  |
| Konfigurationsprüfung | Bestanden / Nicht bestanden |
| Dienstneustart erforderlich | Ja / Nein |
| Erfolgskriterien erreicht | Ja / Nein / Teilweise |
| Abbruchkriterium erreicht | Ja / Nein |
| Rollback durchgeführt | Ja / Nein |
| Rollback-Ergebnis |  |
| Benutzerfunktion geprüft | Ja / Nein |
| Regressionstests durchgeführt |  |
| Beobachtungsdauer |  |
| neue Fehler |  |
| verbleibende Risiken |  |
| offene Maßnahmen |  |

---

**37. Häufige Fehler bei der Lösungsumsetzung**

| Fehler | Folge | Besseres Vorgehen |
|---|---|---|
| Keine Sicherung | Ausgangszustand kann nicht wiederhergestellt werden | Konfiguration oder Backup vorher sichern |
| Backup mit Rollback verwechselt | Wiederherstellung ist nicht geplant | vollständigen Rückfallablauf dokumentieren |
| Mehrere Änderungen gleichzeitig | Wirkung nicht zuordenbar | kleine einzelne Änderungen |
| Sofortiger vollständiger Rollout | großer möglicher Ausfall | Canary oder stufenweiser Rollout |
| Nur Dienststatus geprüft | Benutzerfunktion kann weiterhin gestört sein | Ende-zu-Ende-Test durchführen |
| Nur positiver Test | Sicherheitskontrolle kann unbemerkt fehlen | negativen Test ergänzen |
| Keine Abbruchkriterien | zu lange an fehlerhafter Änderung festgehalten | Grenzwerte vorher definieren |
| Rollback erst im Fehlerfall geplant | zusätzliche Ausfallzeit | Rollback vor Beginn vorbereiten |
| Snapshot als einziges Backup | Wiederherstellung möglicherweise ungeeignet | anwendungsgerechtes Backup verwenden |
| Neustart als Standardlösung | unnötige Unterbrechung und Informationsverlust | kleinste geeignete Maßnahme wählen |
| Monitoring sofort beendet | sporadischer Fehler bleibt unentdeckt | angemessene Beobachtungsdauer |
| Workaround als dauerhafte Lösung behandelt | Grundursache bleibt bestehen | Folgeaufgabe mit Verantwortlichkeit |
| Sicherheitsupdate zurückgenommen | bekannte Schwachstelle erneut aktiv | Sicherheitsrisiko bewerten und Roll-forward prüfen |
| Dokumentation erst später erstellt | genaue Schritte und Zeiten gehen verloren | während der Änderung dokumentieren |

---

**Kurzcheckliste**

- [ ] Ursache ausreichend bestätigt
- [ ] Sofortmaßnahme und dauerhafte Lösung getrennt
- [ ] Änderungsumfang eindeutig definiert
- [ ] Auswirkungen und Abhängigkeiten geprüft
- [ ] Risiko bewertet
- [ ] Freigabe eingeholt
- [ ] Wartungsfenster geklärt
- [ ] Ausgangszustand dokumentiert
- [ ] Konfiguration oder Daten gesichert
- [ ] Prüfsummen dokumentiert
- [ ] Rückfallplan vorhanden
- [ ] Rückfallplan technisch durchführbar
- [ ] Erfolgskriterien festgelegt
- [ ] Abbruchkriterien festgelegt
- [ ] Monitoring vorbereitet
- [ ] Kommunikation vorbereitet
- [ ] Konfiguration vor Aktivierung validiert
- [ ] Änderung möglichst klein gehalten
- [ ] Änderung zunächst begrenzt ausgerollt
- [ ] Dienststatus geprüft
- [ ] Prozess und Listener geprüft
- [ ] Netzwerk- und Protokolltest durchgeführt
- [ ] ursprüngliche Benutzerfunktion geprüft
- [ ] negative Sicherheitstests durchgeführt
- [ ] Regressionstests durchgeführt
- [ ] Protokolle nach der Änderung geprüft
- [ ] Monitoring nach der Änderung beobachtet
- [ ] Persistenz der Lösung berücksichtigt
- [ ] Rollback bei Erreichen eines Abbruchkriteriums durchgeführt
- [ ] Ergebnis und offene Maßnahmen dokumentiert

---

**Ergebnis dieses Arbeitsschrittes**

Am Ende dieses Schrittes ist die bestätigte Ursache durch eine kontrollierte und dokumentierte Änderung behandelt.

Die Lösung gilt erst als erfolgreich, wenn:

- technische Prüfungen bestanden sind,
- die ursprüngliche Benutzerfunktion funktioniert,
- abhängige Funktionen weiterhin funktionieren,
- Sicherheitskontrollen weiterhin wirksam sind,
- keine neuen relevanten Fehler auftreten,
- Monitoring einen stabilen Zustand zeigt,
- die Änderung dauerhaft bestehen bleibt,
- Rückfall- oder Folgemaßnahmen dokumentiert sind.

**Nächste Seite:**  
**1.9 Störung dokumentieren, abschließen und Wiederholung verhindern**

---

**Offizielle Hersteller-, Standard- und Projektdokumentation**

- [Microsoft Learn – Restart-Service](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/restart-service)
- [Microsoft Learn – Start-Service](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/start-service)
- [Microsoft Learn – Stop-Service](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/stop-service)
- [Microsoft Learn – Get-Service](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-service)
- [Microsoft Learn – Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection)
- [Microsoft Learn – Get-WinEvent](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.diagnostics/get-winevent)
- [Microsoft Learn – Get-FileHash](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/get-filehash)
- [freedesktop.org – systemctl](https://www.freedesktop.org/software/systemd/man/latest/systemctl.html)
- [freedesktop.org – systemd-analyze](https://www.freedesktop.org/software/systemd/man/latest/systemd-analyze.html)
- [freedesktop.org – journalctl](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html)
- [Google SRE Workbook – Canarying Releases](https://sre.google/workbook/canarying-releases/)
- [Google SRE Workbook – Configuration Design and Best Practices](https://sre.google/workbook/configuration-design/)
- [Apple Support – Scriptverwaltung mit launchd](https://support.apple.com/guide/terminal/script-management-with-launchd-apdc6c1077b/mac)
- [curl – Offizielle Befehlsreferenz](https://curl.se/docs/manpage.html)