Seminar Cloud&Heat Titan / SecuStack – Intensivseminar Betrieb, Hochverfügbarkeit und Automatisierung

Inhaltsübersicht

• Seminarprofil
• Lernziele
• Zielgruppe und Voraussetzungen
• Seminarinhalte
• Praxislabor
• Methoden und Arbeitsweise

Seminarprofil

Das Intensivseminar verdichtet Servicebetrieb, Monitoring, Fehleranalyse, Hochverfügbarkeit, Backup, Lifecycle, Migration und Infrastructure as Code. Die behandelten Verfahren bilden einen durchgängigen Day-2-Betriebspfad und fassen die operativen Fachseminare zusammen.

Lernziele

• Betriebszustände über Metriken, Logs und Alerts belastbar beurteilen
• Störungen schichtweise analysieren und koordinieren
• Hochverfügbarkeit, Kapazität und Wartungsfähigkeit praktisch bewerten
• Backup-, Restore- und Notfallverfahren testen
• Patches, Upgrades, Migrationen und IaC-Änderungen kontrolliert umsetzen

Zielgruppe und Voraussetzungen

Zielgruppe: Plattformbetrieb, Site Reliability Engineering, Cloud Operations, DevOps, Backup- und Notfallbetrieb, technische Serviceverantwortung.

Voraussetzungen: Praktische Linux- und OpenStack-Erfahrung. Grundlagen in Kubernetes, Skripting und Versionsverwaltung werden vorausgesetzt.

Seminarinhalte

Tag 1: Monitoring, Dashboards, Logging und Alarmierung

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Monitoring-Architektur und Signalquellen

Monitoring verbindet Infrastruktur-, Kubernetes-, OpenStack- und Workload-Signale zu einer belastbaren Betriebsübersicht.

1. Schritt 1 – Signalquellen erfassen: Hardware-Sensoren, Betriebssysteme, Kubernetes, Operatoren, OpenStack-Dienste und externe Prüfungen werden inventarisiert.
2. Schritt 2 – Verantwortung zuordnen: Metriken werden einem Dienst, einer Fehlerdomäne und einem betrieblichen Eigentümer zugeordnet.
3. Schritt 3 – Erfassungswege prüfen: Exporter, ServiceMonitors, Scraping, Aufbewahrung und Zugriff werden auf Vollständigkeit und Ausfallsicherheit bewertet.
4. Schritt 4 – Lücken erkennen: Nicht überwachte Abhängigkeiten, unklare Grenzwerte und fehlende End-to-End-Prüfungen werden dokumentiert.

Praxisbezug: Erstellung einer Monitoring-Matrix für Hardware, Kubernetes, OpenStack und Beispielworkload.

Metriken, Dashboards und SLOs

Dashboards werden aus Betriebszielen abgeleitet und trennen Verfügbarkeit, Sättigung, Fehler und Latenz.

1. Schritt 1 – Betriebsziel definieren: Service Level Indicators und messbare Ziele werden für zentrale Plattformfunktionen festgelegt.
2. Schritt 2 – Metriken auswählen: Auslastung, Fehlerquote, Latenz, Queue-Zustand, Replikate und Kapazitätsreserve werden nach Aussagekraft priorisiert.
3. Schritt 3 – Dashboard strukturieren: Gesamtzustand, Dienstsicht, Fehlerdomänen und Detaildiagnose werden in getrennten Ebenen dargestellt.
4. Schritt 4 – Grenzwerte validieren: Warn- und Kritisch-Schwellen werden anhand Normalbetrieb, Lasttest und bekannten Störungen überprüft.

Praxisbezug: Entwurf eines Dashboards für API-Verfügbarkeit, Compute-Kapazität, Netzwerkfehler und Storage-Latenz.

Zentrale Protokollierung und Korrelation

Zentrale Logs ermöglichen die zeitliche und technische Korrelation von Nutzeraktion, API-Aufruf, Operatorreaktion und Infrastrukturereignis.

1. Schritt 1 – Quellen priorisieren: Audit-, API-, Operator-, Kubernetes-, System- und Hardwarelogs werden nach Diagnose- und Nachweiswert bewertet.
2. Schritt 2 – Felder standardisieren: Zeit, Host, Dienst, Namespace, Projekt, Request-ID, Schweregrad und Ereignistyp werden einheitlich erfasst.
3. Schritt 3 – Aufbewahrung festlegen: Hot-, Such- und Archivzeiträume werden aus Betriebs- und Nachweisanforderungen abgeleitet.
4. Schritt 4 – Suchmuster entwickeln: Request-ID, Instanz-ID, Port-ID und Zeitfenster werden für wiederkehrende Diagnosepfade kombiniert.

Praxisbezug: Korrelation eines fehlgeschlagenen API-Aufrufs über mehrere Dienst- und Operatorlogs.

Alerting und Eskalationslogik

Alarmierung soll handlungsrelevante Zustände melden, Rauschen begrenzen und eine eindeutige Reaktion auslösen.

1. Schritt 1 – Alarmziel bestimmen: Jeder Alarm erhält Ursache, Auswirkung, Zuständigkeit und erwartete Erstreaktion.
2. Schritt 2 – Bedingung formulieren: Schwelle, Dauer, Mehrfachbedingung und Abhängigkeit von Wartungsfenstern werden präzise festgelegt.
3. Schritt 3 – Routing einrichten: Priorität, Bereitschaft, Fachgruppe, Eskalationsstufe und Kommunikationsweg werden zugeordnet.
4. Schritt 4 – Wirksamkeit testen: Auslösung, Zustellung, Quittierung, Runbook-Aufruf und Entwarnung werden regelmäßig geprüft.

Praxisbezug: Entwicklung und Test eines Alarmsets für Kapazitätsmangel, API-Ausfall und gestörte Reconciliation.

Tag 2: Troubleshooting, Incident und Runbooks

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Schichtweise Troubleshooting-Methode

Eine feste Methode verhindert Aktionismus und hält Hypothesen, Belege, Änderungen und Ergebnisse nachvollziehbar.

1. Schritt 1 – Symptom operationalisieren: Betroffene Funktion, Umfang, Beginn, Reproduzierbarkeit und letzte Änderung werden präzise erfasst.
2. Schritt 2 – Schicht lokalisieren: Physik, Betriebssystem, Kubernetes, Operator, OpenStack-Dienst, Mandantenressource und Workload werden getrennt geprüft.
3. Schritt 3 – Hypothese testen: Pro Test wird nur eine Annahme mit definiertem erwarteten Ergebnis untersucht.
4. Schritt 4 – Lösung verifizieren: Ursache, Korrektur, Gegenprobe, Nebenwirkungen und Präventionsmaßnahme werden dokumentiert.

Praxisbezug: Analyse eines mehrschichtigen Fehlers mit Hypothesenprotokoll und minimalen Eingriffen.

Operator- und Reconciliation-Fehleranalyse

Störungen werden vom Custom Resource Status über Operator-Logs bis zu abhängigen Kubernetes-Objekten eingegrenzt.

1. Schritt 1 – Fehlerbedingung sichern: Generation, Conditions, Events, Zeitstempel und letzte Konfigurationsänderung werden dokumentiert.
2. Schritt 2 – Operator-Log korrelieren: Objektname, Namespace und Reconciliation-Zeitfenster werden zur gezielten Logauswertung verwendet.
3. Schritt 3 – Teilressourcen prüfen: Jobs, Deployments, StatefulSets, Services, Secrets und Zertifikate werden auf blockierende Zustände untersucht.
4. Schritt 4 – Korrektur minimal halten: Die Ursache wird möglichst an der deklarativen Quelle behoben; direkte Änderungen an verwalteten Objekten bleiben Ausnahme.

Praxisbezug: Bearbeitung eines simulierten Operatorfehlers mit abgelaufenem Zertifikat oder fehlender Abhängigkeit.

Incident Management und Eskalation

Störungen werden nach Auswirkung priorisiert, technisch stabilisiert und mit klarer Kommunikation bis zur Ursachenanalyse geführt.

1. Schritt 1 – Incident eröffnen: Zeitpunkt, Auswirkung, betroffene Services, aktuelle Symptome und verantwortliche Leitung werden festgehalten.
2. Schritt 2 – Stabilisierung priorisieren: Schadensbegrenzung, Wiederherstellung und Beweissicherung werden vor nicht notwendigen Detailanalysen behandelt.
3. Schritt 3 – Arbeitsstränge koordinieren: Infrastruktur, Kubernetes, OpenStack, Netzwerk, Storage und Kommunikation erhalten klar abgegrenzte Aufgaben.
4. Schritt 4 – Nachbereitung durchführen: Ursache, beitragende Faktoren, Wirksamkeit der Reaktion und dauerhafte Maßnahmen werden dokumentiert.

Praxisbezug: Bearbeitung eines simulierten Major Incidents mit Rollen, Lageprotokoll, Stabilisierung und Nachbereitung.

Runbooks und Standardverfahren

Runbooks übersetzen bekannte Betriebsfälle in reproduzierbare Schritte mit Vorbedingungen, Prüfungen und Rückfall.

1. Schritt 1 – Auslöser beschreiben: Symptom, Alarm, Grenzwert oder Änderungsanlass wird eindeutig definiert.
2. Schritt 2 – Vorprüfung festlegen: Berechtigung, Ausgangszustand, betroffene Systeme, Backup und Wartungsfenster werden vor dem Eingriff geprüft.
3. Schritt 3 – Handlungsschritte ordnen: Befehle und Kontrollen werden in kleinste prüfbare Einheiten mit erwarteten Ergebnissen zerlegt.
4. Schritt 4 – Abschluss sichern: Funktionstest, Monitoring, Dokumentation, Ticketabschluss und gegebenenfalls Problem-Record werden festgelegt.

Praxisbezug: Erstellung eines Runbooks für den kontrollierten Neustart eines nicht reagierenden Plattformdienstes.

Tag 3: Hochverfügbarkeit, Kapazität und Hardwarewartung

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Hochverfügbarkeit und Fehlerdomänen

Hochverfügbarkeit entsteht aus Redundanz, Quorum, verteilter Platzierung, getesteten Failover-Verfahren und ausreichender Reserve.

1. Schritt 1 – Kritische Komponenten erfassen: APIs, Datenbanken, Message Queues, Kubernetes-Steuerung, Netzwerk, Storage und physische Infrastruktur werden bewertet.
2. Schritt 2 – Fehlerdomänen zuordnen: Knoten, Rack, Strompfad, Netzpfad und Standort werden als mögliche gemeinsame Ausfallursachen betrachtet.
3. Schritt 3 – Quorum und Replikate prüfen: Mindestanzahl, Platzierung, PodDisruptionBudgets und Wartungsfähigkeit werden gegen Ausfallszenarien getestet.
4. Schritt 4 – Failover nachweisen: Geplante Abschaltung und unerwarteter Ausfall werden mit Messung von Unterbrechung und Wiederherstellung durchgeführt.

Praxisbezug: Entwicklung einer Ausfallmatrix und Durchführung eines kontrollierten Knoten-Failovers.

Kapazitätsmanagement und Skalierung

Kapazitätsmanagement verbindet technische Messwerte mit Wachstum, Wartungsreserve und Beschaffungs- beziehungsweise Erweiterungszeiten.

1. Schritt 1 – Ist-Kapazität messen: Nutzbare und belegte CPU-, RAM-, Storage-, Netzwerk- und Lizenzressourcen werden je Fehlerdomäne erfasst.
2. Schritt 2 – Trend ableiten: Wachstum, saisonale Spitzen, Rebuild-Belastung und neue Projekte werden in realistische Prognosen überführt.
3. Schritt 3 – Schwellen definieren: Zeitpunkte für Optimierung, Beschaffung, Erweiterung und Aufnahmebeschränkung werden festgelegt.
4. Schritt 4 – Skalierung planen: Zusätzliche Knoten oder Micro-DC-Einheiten werden mit Netzwerk, Storage, Kühlung und Betriebsprozessen abgestimmt.

Praxisbezug: Erstellung einer Zwölfmonatsprognose mit Erweiterungsschwellen und N+1-Reserve.

Hardwarewartung und Ersatzteilstrategie

Wartung muss Redundanz, Datenintegrität, Plattformzustand und sichere Rückkehr in den Regelbetrieb berücksichtigen.

1. Schritt 1 – Wartungsfähigkeit prüfen: N+1-Reserve, Replikation, Quorum, Workload-Verteilung und Ersatzteilverfügbarkeit werden vorab bestätigt.
2. Schritt 2 – Komponente entlasten: Workloads werden migriert, Dienste kontrolliert drainiert und betroffene Pfade aus dem Betrieb genommen.
3. Schritt 3 – Arbeit durchführen: Identität der Komponente, ESD-Schutz, Austausch, Firmwarestand und Verkabelung werden nach Prüfliste kontrolliert.
4. Schritt 4 – Wiedereingliederung testen: Hardwarezustand, Clusterbeitritt, Rebalancing, Monitoring und Redundanz werden vor Freigabe geprüft.

Praxisbezug: Planung eines Compute-Knoten-Austauschs ohne unnötige Workload-Unterbrechung.

Change Management und Wartungsfenster

Technische Änderungen werden mit Risiko, Abhängigkeit, Kommunikationsplan, Freigabe und Rückfall steuerbar gemacht.

1. Schritt 1 – Änderung beschreiben: Zweck, Umfang, betroffene Dienste, erwarteter Nutzen und Nicht-Ziele werden präzise festgehalten.
2. Schritt 2 – Risiko analysieren: Fehlerdomäne, Kundenauswirkung, Datenrisiko, Paralleländerungen und fehlende Tests werden bewertet.
3. Schritt 3 – Durchführung vorbereiten: Schritte, Rollen, Zeitplan, Monitoring, Abbruchkriterien und Rückfall werden verbindlich dokumentiert.
4. Schritt 4 – Abschluss bewerten: Funktion, Nebenwirkungen, Monitoring, Dokumentation und gegebenenfalls Nacharbeit werden bestätigt.

Praxisbezug: Erstellung eines Standard-Changes und eines risikoreichen Normal-Changes für eine Plattformkomponente.

Tag 4: Backup, Restore, Notfall und Lifecycle

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Backup-Konzept und Schutzobjekte

Das Backup-Konzept unterscheidet Plattformzustand, Konfiguration, Datenbanken, Images, Volumes, Objekte und externe Abhängigkeiten.

1. Schritt 1 – Schutzobjekte erfassen: Pro Komponente werden Dateninhalt, Konsistenzanforderung, Eigentümer und Wiederherstellungsabhängigkeiten dokumentiert.
2. Schritt 2 – RPO und RTO festlegen: Zulässiger Datenverlust und Wiederanlaufzeit werden je Service- und Datenklasse definiert.
3. Schritt 3 – Sicherungsmethode wählen: Snapshot, anwendungskoordinierte Sicherung, Datenbankbackup, Konfigurationsexport und Replikation werden passend kombiniert.
4. Schritt 4 – Aufbewahrung absichern: Rotation, getrennte Fehlerdomäne, Unveränderbarkeit, Verschlüsselung und Löschfristen werden festgelegt.

Praxisbezug: Erstellung einer Backup-Matrix mit Schutzobjekt, Methode, Intervall, RPO, RTO und Aufbewahrung.

Sicherung von Plattform- und Mandantendaten

OpenStack-Steuerungsdaten und Mandantenressourcen benötigen unterschiedliche Sicherungsverfahren und Verantwortlichkeiten.

1. Schritt 1 – Plattformdaten sichern: Datenbanken, Schlüsselkonfigurationen, Zertifikate, Custom Resources und betriebliche Konfiguration werden konsistent erfasst.
2. Schritt 2 – Mandantendaten sichern: Volumes, Objekte, Images und anwendungseigene Daten werden nach Serviceklasse und Verantwortungsmodell behandelt.
3. Schritt 3 – Sicherungsjobs überwachen: Laufzeit, Datenmenge, Erfolgsstatus, Fehler, Aufbewahrung und Replikationsstand werden zentral kontrolliert.
4. Schritt 4 – Wiederlesbarkeit prüfen: Stichproben und automatisierte Integritätsprüfungen bestätigen, dass Sicherungen vollständig und entschlüsselbar sind.

Praxisbezug: Planung eines Sicherungslaufs für Steuerungsdaten und ein mandantenseitiges Anwendungsvolume.

Restore-Verfahren und Wiederanlaufreihenfolge

Wiederherstellung wird als abhängige Reihenfolge von Basisinfrastruktur, Plattformdiensten, Konfiguration und Nutzdaten geplant.

1. Schritt 1 – Wiederherstellungsziel bestimmen: Einzelobjekt, Dienst, Cluster, Standort oder vollständige Plattform werden klar voneinander abgegrenzt.
2. Schritt 2 – Abhängigkeiten ordnen: Identität, Datenbanken, Message Queue, Kubernetes, Operatoren, OpenStack-Dienste und Mandantendaten werden in eine Reihenfolge gebracht.
3. Schritt 3 – Restore isoliert ausführen: Zieldomäne, Netzwerkzugriff, Schlüsselmaterial und Konflikte mit produktiven Ressourcen werden vorab kontrolliert.
4. Schritt 4 – Funktion nachweisen: Integrität, API-Funktion, Zugriffsrechte, Netzwerk, Storage und Beispielworkload werden nach der Wiederherstellung getestet.

Praxisbezug: Durchführung eines dokumentierten Restore-Tests für Konfiguration und ein Testvolume.

Disaster-Recovery-Tests

Notfallverfahren gelten erst nach einem realistischen, wiederholbaren und ausgewerteten Test als belastbar.

1. Schritt 1 – Szenario wählen: Ausfall von Management, Storage, mehreren Knoten, Rack oder Standort wird mit klaren Annahmen beschrieben.
2. Schritt 2 – Erfolgskriterien definieren: RTO, RPO, Datenintegrität, Mindestservice und Kommunikationsziele werden messbar festgelegt.
3. Schritt 3 – Übung steuern: Startzustand, Freigabe, Beobachter, Sicherheitsgrenzen und Abbruchkriterien werden vor Beginn festgehalten.
4. Schritt 4 – Erkenntnisse umsetzen: Zeitabweichungen, fehlende Zugänge, unklare Rollen und technische Lücken werden in konkrete Maßnahmen überführt.

Praxisbezug: Planung einer Tabletop- und einer technischen Wiederanlaufübung mit messbaren Kriterien.

Patch- und Schwachstellenprozess

Patches werden anhand Risiko, Exponierung, Verfügbarkeit, Abhängigkeiten und Testbarkeit priorisiert.

1. Schritt 1 – Informationsquellen bündeln: Herstellerhinweise, Projektmeldungen, Scannergebnisse und interne Befunde werden einem Komponentenbestand zugeordnet.
2. Schritt 2 – Risiko bewerten: Schweregrad, Ausnutzbarkeit, Erreichbarkeit, vorhandene Kontrollen und betroffene Daten bestimmen die Priorität.
3. Schritt 3 – Umsetzung planen: Test, Wartungsfenster, Reihenfolge, Backup, Abbruchkriterium und Rückfall werden pro Patchpaket festgelegt.
4. Schritt 4 – Wirksamkeit bestätigen: Versionsstand, Funktionstest, erneuter Scan und Abschlussdokumentation belegen die Behebung.

Praxisbezug: Bearbeitung eines beispielhaften kritischen Sicherheitsupdates vom Eingang bis zum Wirksamkeitsnachweis.

Tag 5: Automatisierung, Upgrade und Migration

Die Themen werden in einer festen Reihenfolge aus Einordnung, technischer Umsetzung, Kontrolle und dokumentierter Prüfung bearbeitet.

Automatisierungsmodell und Wiederholbarkeit

Automatisierung beginnt mit stabilen Standards, eindeutigen Eingaben, idempotenten Abläufen und überprüfbaren Ergebnissen.

1. Schritt 1 – Prozess auswählen: Häufigkeit, Fehleranfälligkeit, Standardisierbarkeit und Sicherheitswirkung bestimmen geeignete Automatisierungskandidaten.
2. Schritt 2 – Sollzustand definieren: Eingaben, Ressourcenmodell, Namenskonventionen, Abhängigkeiten und erwartete Ergebnisse werden formal beschrieben.
3. Schritt 3 – Idempotenz sicherstellen: Wiederholte Ausführung führt zum gleichen Zustand und erzeugt keine unkontrollierten Duplikate.
4. Schritt 4 – Kontrollen einbauen: Validierung, Dry Run, Logging, Fehlerbehandlung, Rollback und Freigabe werden Teil des Ablaufs.

Praxisbezug: Bewertung mehrerer Betriebsaufgaben und Auswahl eines geeigneten Automatisierungskandidaten.

OpenStack-API und CLI für Automatisierung

API und CLI liefern reproduzierbare Schnittstellen für Inventarisierung, Bereitstellung und kontrollierte Massenänderungen.

1. Schritt 1 – Authentifizierung kapseln: clouds.yaml, Application Credentials und Zertifikatsprüfung werden ohne Klartextgeheimnisse eingebunden.
2. Schritt 2 – Abfragen stabilisieren: Filter, maschinenlesbare Ausgabe, Pagination und eindeutige IDs werden statt bildschirmorientierter Ausgabe verwendet.
3. Schritt 3 – Änderungen absichern: Vorprüfung, Zielmengenermittlung, Bestätigung, Fehlercode und Wiederholungslogik werden implementiert.
4. Schritt 4 – Ergebnisse protokollieren: Request-ID, Objekt-ID, Zeit, Aktion und Status werden für Audit und Fehleranalyse gespeichert.

Praxisbezug: Erstellung eines robusten CLI-Ablaufs zur Inventarisierung und Quotenprüfung mehrerer Projekte.

Infrastructure as Code mit Terraform und Ansible

Terraform modelliert Cloud-Ressourcen deklarativ; Ansible ergänzt Konfiguration und orchestrierte Betriebsschritte.

1. Schritt 1 – Verantwortung trennen: Cloud-Ressourcen, Gastkonfiguration und Plattformbetrieb werden klar auf Werkzeuge und Repositories verteilt.
2. Schritt 2 – State absichern: Terraform-State, Sperre, Verschlüsselung, Zugriff und Sicherung werden als kritische Betriebsdaten behandelt.
3. Schritt 3 – Module entwickeln: Netze, Sicherheitsgruppen, Instanzen und Volumes werden mit validierten Eingaben und sinnvollen Standardwerten gekapselt.
4. Schritt 4 – Änderung prüfen: Formatierung, Validierung, Plan, Peer Review, Freigabe und kontrolliertes Apply bilden die feste Kette.

Praxisbezug: Aufbau eines kleinen IaC-Moduls für Netzwerk, Sicherheitsgruppe und Testinstanz.

CI/CD für Infrastrukturänderungen

Pipelines automatisieren Qualitätskontrollen und halten produktive Änderungen an nachvollziehbare Freigaben gebunden.

1. Schritt 1 – Pipeline-Stufen definieren: Linting, Syntaxprüfung, Sicherheitsprüfung, Plan, Review, Freigabe und Ausführung werden getrennt.
2. Schritt 2 – Credentials begrenzen: Kurzlebige Zugangsdaten, getrennte Umgebungen und minimal berechtigte Servicekonten reduzieren das Pipeline-Risiko.
3. Schritt 3 – Artefakte sichern: Pläne, Prüfberichte, Logs und Freigabeinformationen werden versioniert und vor Manipulation geschützt.
4. Schritt 4 – Fehlerpfad testen: Abbruch, Teilfehler, Wiederholung und manuelle Wiederaufnahme werden vor Produktiveinsatz erprobt.

Praxisbezug: Entwurf einer Pipeline für Terraform-Änderungen mit manueller Produktionsfreigabe.

Upgrade-Pfad und Kompatibilitätsanalyse

Ein Upgrade wird als Kette abhängiger Versionen und Datenmigrationen mit klaren Zwischenständen geplant.

1. Schritt 1 – Versionen erfassen: Firmware, Betriebssystem, Kubernetes, Operatoren, OpenStack-Dienste und Clientwerkzeuge werden inventarisiert.
2. Schritt 2 – Kompatibilität prüfen: Unterstützte Sprünge, API-Änderungen, Datenbankschemata, Treiber und kundenspezifische Anpassungen werden bewertet.
3. Schritt 3 – Zwischenstufen planen: Notwendige Upgrade-Hops, Wartungsfenster und Validierungspunkte werden in eine feste Sequenz gebracht.
4. Schritt 4 – Rückfallgrenzen klären: Vorwärtsmigrationen, Datenbankänderungen und irreversible Schritte werden ausdrücklich markiert.

Praxisbezug: Erstellung eines Upgrade-Pfads mit Zwischenversionen und Go-/No-Go-Prüfpunkten.

Migrationsstrategie und Wellenplanung

Migrationen werden nach Kritikalität, Abhängigkeit, Datenvolumen, Ausfalltoleranz und Rückfallfähigkeit in Wellen organisiert.

1. Schritt 1 – Migrationsmuster wählen: Rehost, Replatform, Refactor, Retire und Retain werden je Workload begründet zugeordnet.
2. Schritt 2 – Abhängigkeiten entflechten: Netzwerk, Identität, Datenbanken, externe Systeme und Zeitkopplungen werden sichtbar gemacht.
3. Schritt 3 – Wellen bilden: Pilot, einfache Workloads, mittlere Komplexität und kritische Systeme werden in steigender Schwierigkeit geplant.
4. Schritt 4 – Cutover absichern: Datenabgleich, Freeze, Umschaltung, Funktionstest, Rückfall und Kommunikationsplan werden festgelegt.

Praxisbezug: Erstellung einer Migrationswelle für drei unterschiedlich kritische Beispielworkloads.

Praxislabor

• Erstellung einer Monitoring-Matrix für Hardware, Kubernetes, OpenStack und Beispielworkload.
• Analyse eines mehrschichtigen Fehlers mit Hypothesenprotokoll und minimalen Eingriffen.
• Erstellung einer Zwölfmonatsprognose mit Erweiterungsschwellen und N+1-Reserve.
• Planung eines Sicherungslaufs für Steuerungsdaten und ein mandantenseitiges Anwendungsvolume.
• Erstellung eines robusten CLI-Ablaufs zur Inventarisierung und Quotenprüfung mehrerer Projekte.
• Erstellung einer Migrationswelle für drei unterschiedlich kritische Beispielworkloads.

Methoden und Arbeitsweise

Fachliche Einordnung, strukturierte Demonstrationen, geführte Systemübungen, technische Prüflisten und dokumentierte Störungsszenarien wechseln sich ab. Jeder Arbeitsschritt wird mit Ausgangszustand, erwarteter Wirkung, Prüfkriterium und Rückfallmöglichkeit beschrieben. Die Übungen verwenden realistische Rollen- und Fehlerbilder; produktive Zugangsdaten oder externe Verbindungen sind nicht erforderlich.