Seminar Cloud&Heat Titan / SecuStack – Servicebetrieb, Troubleshooting und Hochverfügbarkeit

Inhaltsübersicht

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

Seminarprofil

Das Seminar vermittelt den operativen Betrieb einer hochverfügbaren Plattform. Beobachtbarkeit, Runbooks, Incident-Steuerung, Fehlerdomänen, Kapazität sowie Operator-, Compute- und Netzwerkdiagnose werden in realistischen Störungsketten trainiert.

Lernziele

• Betriebszustände aus Metriken, Logs und Alarmen korrekt ableiten
• Störungen mit einer schichtweisen Methode ohne Aktionismus eingrenzen
• Runbooks und Eskalationswege für wiederkehrende Fälle entwickeln
• Fehlerdomänen, Quorum und Kapazitätsreserven bewerten
• Operator-, Compute- und Netzwerkfehler gezielt korrelieren

Zielgruppe und Voraussetzungen

Zielgruppe: Cloud Operations, Plattformadministration, Site Reliability Engineering, Bereitschaftsdienst, technische Serviceleitung und Second-/Third-Level-Support.

Voraussetzungen: Praktische Erfahrung mit Linux und mindestens einem der Bereiche OpenStack, Kubernetes oder Netzwerkbetrieb.

Seminarinhalte

Tag 1: Monitoring, Dashboards und Logkorrelation

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.

Tag 2: Alerting, Runbooks und Troubleshooting-Methode

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

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.

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.

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.

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

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.

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.

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.

Tag 4: Operator-, Compute- und Netzwerkdiagnose

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

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.

Fehleranalyse im Compute-Bereich

Compute-Störungen werden entlang der Kette API, Scheduler, Conductor, Compute-Dienst, Hypervisor, Netzwerk und Storage eingegrenzt.

1. Schritt 1 – Fehlerbild sichern: Instanzstatus, Task State, Fault-Information, Request-ID und Zeitfenster werden vor Änderungen dokumentiert.
2. Schritt 2 – Steuerungspfad verfolgen: API-, Scheduler- und Conductor-Protokolle werden anhand der Request-ID korreliert.
3. Schritt 3 – Hostzustand prüfen: Compute-Service, Hypervisor, Ressourcenbelegung, Libvirt-Ereignisse und lokale Abhängigkeiten werden kontrolliert.
4. Schritt 4 – Behebung validieren: Korrektur, erneuter Test, Nebenwirkungsprüfung und dokumentierte Ursache schließen die Analyse ab.

Praxisbezug: Analyse eines simulierten Boot-Fehlers mit Request-ID und Zuordnung zur verursachenden Schicht.

Systematische Netzwerkdiagnose

Netzwerkfehler werden vom virtuellen Port bis zur physischen Anbindung ohne vorschnelle Eingriffe eingegrenzt.

1. Schritt 1 – Symptom präzisieren: Quelle, Ziel, Richtung, Protokoll, Zeitpunkt, Paketgröße und betroffene Mandanten werden erfasst.
2. Schritt 2 – Kontrollebene prüfen: Neutron-Objekte, Portstatus, Router, Sicherheitsgruppen und OVN-Zustände werden auf Konsistenz geprüft.
3. Schritt 3 – Datenebene verfolgen: Namespace beziehungsweise Chassis, Open-vSwitch-Flows, Tunnel und physische Interfaces werden untersucht.
4. Schritt 4 – Behebung absichern: Änderung, Gegenprobe, Seiteneffekte und dauerhafte Ursache werden dokumentiert.

Praxisbezug: Bearbeitung eines gestörten Ost-West- und eines gestörten Nord-Süd-Kommunikationspfads.

Praxislabor

• Erstellung einer Monitoring-Matrix für Hardware, Kubernetes, OpenStack und Beispielworkload.
• Korrelation eines fehlgeschlagenen API-Aufrufs über mehrere Dienst- und Operatorlogs.
• Erstellung eines Runbooks für den kontrollierten Neustart eines nicht reagierenden Plattformdienstes.
• Bearbeitung eines simulierten Major Incidents mit Rollen, Lageprotokoll, Stabilisierung und Nachbereitung.
• Bearbeitung eines simulierten Operatorfehlers mit abgelaufenem Zertifikat oder fehlender Abhängigkeit.
• Bearbeitung eines gestörten Ost-West- und eines gestörten Nord-Süd-Kommunikationspfads.

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.