Training Module
DevOps Betrieb: Cloud-Architektur, On-Call & Fehlerkultur
Baustein im DevOps-Kurscluster, klar abgegrenzt von den Nachbarmodulen: Umgebungsstufen und Releasestrategie vermittelt CD: Continuous Delivery im Detail, den konkreten IaC-Tool-Einstieg mit eigenem Code Pulumi Grundlagen – hier geht es um das, was nach dem Deployment beginnt und nie mehr aufhört: den laufenden Betrieb selbst. In diesem 175-Minuten-Modul (2 Stunden 55 Minuten) seht ihr an der Fallstudie BadCompany GmbH, wie eine starre Jahres-Hardwareplanung gegen Betriebssystem-Supportzyklen einen Infrastruktur-Deadlock erzeugt, lernt ganzheitliches Systemdenken (Three Ways) und das Lift-and-Shift-Antipattern kennen, ordnet Infrastruktur-Abstraktionsstufen (Bare Metal, VM, Container), On-Premise vs. Cloud, die Pizza-as-a-Service-Dienstmodelle und die fünf NIST-Cloud-Charakteristiken ein, versteht Cattle-not-Pets als Infrastruktur-Paradigma, lernt Bereitschaftsdienst/On-Call und das Blameless Post Mortem als Werkzeug einer offenen Fehlerkultur kennen und ordnet ChatOps, Infrastructure as Code und Chaos Engineering als Automatisierungs- und Resilienzwerkzeuge ein. In der Hands-on-Übung füllt ihr für einen fiktiven BadCompany-GmbH-Incident (eine vollgelaufene Log-Platte) ein Blameless-Post-Mortem-Template aus und gleicht es mit der Musterlösung ab.
Format
175 Minuten (2 Stunden 55 Minuten), live (remote oder vor Ort), Input & geführtes Hands-on zum Blameless-Post-Mortem-Template
Teilnehmende
DevOps-Engineers, Platform-/Infrastruktur-Verantwortliche und Entwickler:innen, die im Bereitschaftsdienst rotieren oder eine Cloud-Betriebsstrategie mitgestalten wollen
Voraussetzungen
Keine Pflicht; CD: Continuous Delivery (Umgebungsstufen, Immutable Infrastructure) und DevOps Grundlagen (CALMS, Three Ways) helfen beim Einstieg, sind aber keine Pflicht
Warum dieses Training für deine Organisation wirkt
Klare Abgrenzung statt Doppelung
Umgebungsstufen und Releasestrategie kommen aus CD: Continuous Delivery, der konkrete IaC-Tool-Einstieg mit eigenem Code aus Pulumi Grundlagen – hier bleibt der Fokus auf Betrieb als Organisation, Cloud-Architektur-Entscheidung und Fehlerkultur selbst.
Eine Fallstudie von Silo bis Incident
BadCompany GmbH zieht sich als roter Faden durch die Session: vom Infrastruktur-Deadlock in Modul 1 bis zum konkreten Incident, den ihr in der Hands-on-Übung analysiert.
Hands-on statt Theorie allein
In der geführten Übung füllt ihr für einen realistischen Incident (vollgelaufene Log-Platte) ein echtes Blameless-Post-Mortem-Template anhand vorgegebener Rohdaten aus – und gleicht es mit der Musterlösung ab.
Was Teilnehmende mitnehmen
- Die Operate-Phase in Day 0 (Planung), Day 1 (Deployment) und Day 2 (laufender Betrieb) einordnen und die Fallstudie BadCompany GmbH als Infrastruktur-Deadlock verstehen: starre Jahres-Hardwareplanung gegen Betriebssystem-Supportzyklen, fehlende gemeinsame Datenbasis zwischen Business, Entwicklung und Finanzen, Henne-Ei-Blockade zwischen Infrastruktur- und Betriebsteam.
- Ganzheitliches Systemdenken (der erste der Three Ways) von Silo-Optimierung unterscheiden und Lift-and-Shift als Anti-Pattern erkennen: eine Anwendung ohne Architekturänderung in die Cloud zu kopieren erzeugt höhere Kosten ohne betrieblichen Mehrwert.
- Infrastruktur-Abstraktionsstufen unterscheiden (Bare Metal, virtuelle Maschinen, Container), On-Premise gegen Cloud fundiert abwägen, die vier Pizza-as-a-Service-Dienstmodelle (On-Premise, IaaS, PaaS, SaaS) und die fünf NIST-Cloud-Charakteristiken benennen.
- Cattle-not-Pets als Infrastruktur-Paradigma anwenden: Server als austauschbare, ephemere Einheiten mit generischen IDs statt individuell gepflegter Unikate mit eigenem Namen.
- Bereitschaftsdienst/On-Call organisatorisch einordnen: Escalation Policy mit Primary On-Call, arbeitsrechtliche Grundlagen (Ruhezeiten, Vergütung von Rufbereitschaft und Störungsarbeit), crossfunktionale Rotation zwischen Betrieb und Entwicklung.
- Das Blameless Post Mortem als Werkzeug einer offenen Fehlerkultur anwenden: die vier Pflichtfelder Impact, Timeline, Root Cause und Follow-up Actions korrekt befüllen, ohne Schuldzuweisung und ohne Symptom-statt-Ursache-Verwechslung.
- ChatOps, Infrastructure as Code (deklarativ vs. imperativ, Terraform/Ansible/Puppet im Konzept) und Chaos Engineering als Automatisierungs- und Resilienzwerkzeuge einordnen.
- In der Hands-on-Übung für einen fiktiven BadCompany-GmbH-Incident ein Blameless-Post-Mortem-Template anhand vorgegebener Rohdaten (Zeitstempel, Monitoring-Ausschnitt, Symptom-Text) ausfüllen und mit der Musterlösung abgleichen.
Für wen dieses Modul ideal ist
- • DevOps-Engineers und Platform-/Infrastruktur-Verantwortliche, die Cloud-Architektur-Entscheidungen fundiert begründen wollen
- • Entwickler:innen, die neu in eine On-Call-Rotation eingebunden werden und die organisatorischen und arbeitsrechtlichen Grundlagen verstehen wollen
- • Team-/Betriebsverantwortliche, die eine offene Fehlerkultur mit Blameless Post Mortems statt Schuldzuweisung aufbauen wollen
- • Voraussetzung: keine Pflicht; CD: Continuous Delivery und DevOps Grundlagen hilfreich, keine Pflicht
Rahmendaten
- • Dauer: 175 Minuten (2 Stunden 55 Minuten) live (remote oder vor Ort)
- • Format: Input und geführtes Hands-on zum Blameless-Post-Mortem-Template, kein Live-IaC-Coding und kein Chaos-Engineering-Tool-Drill
- • Voraussetzungen: keine Pflicht, CD: Continuous Delivery und DevOps Grundlagen hilfreich
Modulaufbau & Agenda
Kick-off & Abgrenzung (10 min): Format, Ablauf und Abgrenzung zu CD: Continuous Delivery (Umgebungsstufen und Releasestrategie dort, hier nur als Vorstufe des Betriebs vorausgesetzt), zu Pulumi Grundlagen (konkreter IaC-Tool-Einstieg mit eigenem Code dort, hier nur das Prinzip) und zu DevSecOps Grundlagen (Security-Prinzipien dort) – hier kein Security-Deep-Dive, kein Live-IaC-Coding, kein Chaos-Engineering-Tool-Drill.
Fallstudie BadCompany GmbH: Operate-Phase & Infrastruktur-Deadlock (30 min): Day 0/Day 1/Day 2 als Zeitachse der Infrastruktur, starre Jahres-Hardwareplanung gegen OS-Supportzyklen, zersplittertes Monitoring, Henne-Ei-Blockade zwischen Infrastruktur- und Betriebsteam.
Kollaboration & Systemdenken: Three Ways, Lift-and-Shift-Antipattern (25 min): fehlender Informationsfluss zwischen Entwicklung und Betrieb, ganzheitliches Systemdenken als erster der Three Ways, Lift-and-Shift als Anti-Pattern, Microservices/Kubernetes als Ausweg der BadCompany GmbH.
Infrastruktur-Abstraktion & Cloud-Dienstmodelle: Pizza-as-a-Service, NIST, Cattle not Pets (35 min): Bare Metal/VM/Container, On-Premise vs. Cloud, die vier Pizza-as-a-Service-Modelle, die fünf NIST-Charakteristiken, Cattle-not-Pets, Vendor-Lock-in-Abwägung.
On-Call & Fehlerkultur: Bereitschaftsdienst, Escalation Policy, Blameless Post Mortem (25 min): arbeitsrechtliche Grundlagen, Primary On-Call und Eskalationskette, offene Fehlerkultur, die vier Pflichtfelder eines Blameless Post Mortem. Wie viel Ausfall dabei überhaupt tolerierbar ist, bevor ein Post Mortem fällig wird, quantifiziert das SRE-Framework SLA/SLO/SLI mit Error Budget aus DevOps Monitoring: Von Status-Checks zu Observability & SRE – hier nur als Verweis, nicht neu erklärt.
Hands-on: Blameless-Post-Mortem-Template für den BadCompany-GmbH-Incident (20 min): Rohdaten (Zeitstempel, Monitoring-Ausschnitt, Symptom-Text) zu einer vollgelaufenen Log-Platte auswerten, die vier Pflichtfelder ausfüllen, Abgleich mit der Musterlösung.
ChatOps, Infrastructure as Code & Chaos Engineering (25 min): Chat-Kanäle als Echtzeit-Signal statt Dokumentationsort, deklarativ vs. imperativ, Terraform/Ansible/Puppet im Konzept, Backup-Restore-Pflicht, Chaos Engineering in vier Schritten.
Fazit & Ausblick (5 min): Betrieb als integraler, nie endender Teil des Produktlebenszyklus, Verweis auf DevSecOps Grundlagen für die Security-Perspektive auf denselben Lifecycle und auf Docker Betrieb für die containerspezifische Vertiefung von Restart-Policies, Ressourcenlimits und Monitoring-Stack.
Hands-on Inhalte (Auszug)
Fallstudie BadCompany GmbH
- Starre Jahres-Hardwareplanung ohne gemeinsame Datenbasis zwischen Business, Entwicklung und Finanzen
- Henne-Ei-Deadlock: Betriebssystem-Updates warten auf neue Hardware, neue Hardware wartet auf ausgemusterte Systeme
- Fehlende Telemetrie-Rückspiegelung an die Entwicklung, dargestellt am Beispiel der vollgelaufenen Log-Platte
Cloud-Architektur & Infrastruktur-Paradigma
- Pizza-as-a-Service: On-Premise (selbst backen) bis SaaS (Restaurantbesuch) mit Kontrolle und Aufwand im Vergleich
- Fünf NIST-Charakteristiken: On-Demand Self-Service, Broad Network Access, Resource Pooling, Rapid Elasticity, Measured Service
- Cattle-not-Pets: ephemere, austauschbare Server statt individuell gepflegter Unikate
On-Call & Blameless Post Mortem
- Escalation Policy mit Primary On-Call, arbeitsrechtliche Ruhezeiten und Vergütungsregeln
- Blameless Post Mortem: Impact, Timeline, Root Cause, Follow-up Actions als vier Pflichtfelder
- Systemische Ursache statt Schuldzuweisung, Ziel ist Wiederholungsschutz statt fehlerfreie Historie
Hands-on: Blameless-Post-Mortem-Template
- Vorgegebene Rohdaten (Zeitstempel, Monitoring-Ausschnitt, Symptom-Text) zu einer vollgelaufenen Log-Platte auswerten
- Die vier Pflichtfelder eigenständig ausfüllen, bevor die Musterlösung aufgelöst wird
- Abgleich mit der Musterlösung: korrekt abgegrenzte systemische Root Cause statt Schuldzuweisung oder Symptomverwechslung
Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Qualität der erkannten Root Cause im Blameless-Post-Mortem-Template, Trefferquote bei der Zuordnung der Cloud-Dienstmodelle) und werten sie im Anschluss transparent aus. Ergebnisse veröffentlichen wir, sobald sie belastbar sind.
Bereit, das Modul zu buchen?
Wir passen die Fallstudie und den Incident auf eure tatsächliche Infrastruktur- und Betriebslandschaft an.
Academy Briefing anfragen