Änderungsverwaltung

Eine Änderung ist jede Modifikation an der IT-Infrastruktur, die Services beeinflussen könnte.

Ziel der Änderungsverwaltung

Laut ITIL:

• Sicherstellen, dass Änderungen bewertet, autorisiert und dokumentiert werden
• Risiken von Serviceunterbrechungen minimieren
• Kontinuierliche Verbesserung ermöglichen

Beispiele für Änderungen

• Anwendungs-Versions-Upgrade
• Server-Konfigurationsänderung
• Neue Service-Bereitstellung
• Netzwerkarchitektur-Änderung
• Sicherheitspatch-Installation

Warum Änderungen verwalten?

• Risikokontrolle: Impact vor Implementierung bewerten
• Nachverfolgbarkeit: Wissen, was wann und warum geändert wurde
• Koordination: Konflikte zwischen Änderungen vermeiden
• Lernen: Erfolge und Misserfolge analysieren

Drei Änderungstypen

Standardänderungen

Eigenschaften:

• Niedriges Risiko, gut verstanden
• Vom CAB vorabgenehmigt
• Dokumentiertes Verfahren existiert
• Beispiele: Passwort-Reset, Arbeitsplatz-Bereitstellung

Normale Änderungen

Eigenschaften:

• Erfordern Risikobewertung
• Vollständige CAB-Evaluierung
• Geplantes Wartungsfenster
• Beispiele: Anwendungs-Upgrade, Infrastrukturänderung

Notfalländerungen

Eigenschaften:

• Adressieren kritische Vorfälle
• Fast-Track-Genehmigung (reduziertes CAB)
• Vollständige Dokumentation nach Implementierung
• Beispiele: Sicherheitspatches, kritische Fixes

Verfügbare Status

Standard-Workflow

DRAFT → SUBMITTED → PENDING_APPROVAL → APPROVED → SCHEDULED → 
  IMPLEMENTING → COMPLETED → CLOSED
                       ↓
                    FAILED → ROLLED_BACK → CLOSED

Das Change Advisory Board (CAB) bewertet und genehmigt Änderungen.

CAB-Rolle

• Risikobewertungen prüfen
• Implementierungspläne evaluieren
• Genehmigen, ablehnen oder weitere Informationen anfordern
• Wartungsfenster planen

CAB-Evaluierung

Für jede Änderung berücksichtigt das CAB:

• Risiko: Was könnte schiefgehen?
• Impact: Wer/was ist betroffen?
• Timing: Ist das Fenster angemessen?
• Ressourcen: Haben wir die richtigen Personen?
• Rollback: Können wir bei Bedarf zurücksetzen?

CAB-Entscheidung

In KaliaOps:

1. CAB-Mitglied öffnet die Änderung
2. Prüft alle Dokumentation
3. Klickt auf «Genehmigen» oder «Ablehnen»
4. Fügt Entscheidungsnotizen hinzu

Die Entscheidung wird in der Änderungshistorie nachverfolgt.

Notfall-CAB

Für Notfalländerungen:

• Reduzierte CAB-Besetzung
• Schnellere Bearbeitungszeit
• Post-Implementierungs-Dokumentation erforderlich

Wartungsfenster

Ein Wartungsfenster ist die geplante Zeit für die Implementierung der Änderung.

Terminplanung

Definieren:

• Start Datum/Zeit: Wann die Implementierung beginnt
• End Datum/Zeit: Wann sie abgeschlossen sein sollte
• Dauer: Geschätzte Implementierungszeit

Fenster-Überlegungen

• Geschäftlicher Impact: Zeiten mit geringer Aktivität wählen
• Benutzerbenachrichtigung: Zeit für Kommunikation einplanen
• Ressourcenverfügbarkeit: Sicherstellen, dass Implementierer verfügbar sind
• Konfliktprüfung: Überlappende Änderungen vermeiden

Kalenderansicht

KaliaOps bietet eine Kalenderansicht mit:

• Allen geplanten Änderungen
• Potenziellen Konflikten
• Ressourcenzuweisung

Implementierungsplan

Schritt-für-Schritt dokumentieren:

1. Vorab-Implementierungsprüfungen
2. Backup-Verfahren
3. Implementierungsschritte
4. Verifizierungsschritte
5. Post-Implementierungsprüfungen

Testplan

Definieren, wie validiert wird:

• Service-Funktionalität
• Performance-Kriterien
• Benutzerakzeptanz

Rollback-Plan

Für riskante Änderungen dokumentieren, wie zurückgesetzt wird:

• Auslöser: Wann Rollback initiieren
• Schritte: Wie zurücksetzen
• Dauer: Wie lange der Rollback dauert
• Validierung: Wie Rollback-Erfolg bestätigen

Rollback-Anforderung

Für Hochrisiko-Änderungen:

• Rollback-Plan ist obligatorisch
• Änderung kann ohne ihn nicht genehmigt werden
• Plan sollte wenn möglich getestet werden

Implementierung starten

1. Genehmigte Änderung öffnen
2. Auf «Implementierung starten» klicken
3. Status wechselt zu «Implementing»
4. Dem Implementierungsplan folgen

Während der Implementierung

Dokumentieren:

• Durchgeführte Aktionen
• Aufgetretene Probleme
• Abweichungen vom Plan

Änderung abschließen

Bei Erfolg:

1. Auf «Abschließen» klicken
2. Ergebnisse dokumentieren
3. Status wechselt zu «Completed»

Bei Misserfolg:

1. Rollback-Plan ausführen
2. Auf «Fehlgeschlagen» oder «Zurückgesetzt» klicken
3. Dokumentieren, was passiert ist

Abschluss

Nach Fertigstellung:

1. Ergebnisse überprüfen
2. Dokumentation aktualisieren
3. Änderung schließen

Wenn Änderungen fehlschlagen

Eine Änderung schlägt fehl, wenn:

• Implementierung nicht abgeschlossen werden kann
• Service nicht wie erwartet wiederhergestellt wird
• Inakzeptable Nebenwirkungen auftreten

Fehlerbehandlung

1. Rollback-Plan ausführen
2. Service wiederherstellen
3. Änderung als «Failed» oder «Rolled Back» markieren
4. Dokumentieren, was schiefgelaufen ist

Post-Fehler-Analyse

Eine Überprüfung durchführen:

• Was hat den Fehler verursacht?
• War die Risikobewertung genau?
• War der Rollback-Plan angemessen?
• Was können wir verbessern?

Lernen

Fehler zur Verbesserung nutzen:

• Verfahren aktualisieren
• Tests verbessern
• Risikobewertung verbessern
• Lessons Learned teilen

KaliaOps korreliert automatisch Vorfälle mit kürzlichen Änderungen.

Funktionsweise

Wenn ein Vorfall erstellt wird:

• KaliaOps identifiziert Änderungen der letzten 24-48 Stunden
• Gemeinsame Assets/Anwendungen werden erkannt
• Potenzielle Korrelationen werden vorgeschlagen

Korrelationsindikatoren

• Zeitliche Nähe: Vorfall kurz nach Änderung
• Gemeinsame Assets: Gleiche Ausrüstung beteiligt
• Gemeinsame Anwendungen: Gleiche Services betroffen

Korrelationen nutzen

Wenn ein Vorfall änderungsbezogen sein könnte:

1. Die korrelierte Änderung überprüfen
2. Prüfen, ob sie die Symptome verursachen könnte
3. Bei Bestätigung Rollback in Betracht ziehen
4. Vorfall mit Änderung zur Verfolgung verknüpfen

Change Success Rate

KaliaOps berechnet:

CSR = (Erfolgreiche Änderungen / Gesamtänderungen) × 100%

Branchenziel: > 95%