Training Module

DevOps Monitoring: Von Status-Checks zu Observability & SRE

Baustein im DevOps-Kurscluster, klar abgegrenzt von den Nachbarmodulen: den eigenen Prometheus/Grafana-Monitoring-Stack baut ihr Schritt für Schritt in Docker Betrieb auf, Bereitschaftsdienst, Blameless Post Mortem, ChatOps und Chaos Engineering behandelt DevOps Betrieb im Detail – hier geht es um das, was zwischen einem binären Status-Check und einer ausgereiften Observability-Praxis liegt: die konzeptionelle Landschaft und das Steuerungsframework selbst, ganz ohne Tool-Bedienung. In diesem 160-Minuten-Modul (2 Stunden 40 Minuten) seht ihr an der Fallstudie BadCompany GmbH, wie ein Silo zwischen Dev und Ops zu undurchsichtigen Fehlermeldungen, Symptombekämpfung statt Ursachenanalyse und Alarm-Rauschen führt, lernt die Grenzen des klassischen Status-Monitorings (OK/Warning/Critical/Unknown) kennen, versteht Zeitreihen-Metriken, strukturierte Log-Level und die drei Säulen der Observability (Metrics, Logs, Traces), ordnet spezialisierte Infrastruktur wie Log-Server, Service Mesh, Error Tracking und Incident-Alerting als Tool-Kategorien ein und arbeitet das SRE-Framework aus SLA, SLO, SLI und Error Budget heraus. In der Hands-on-Übung rechnet ihr ein Error Budget aus einem fiktiven SLO/SLA-Beispiel durch und ordnet einen fiktiven, von der Academy zur Veranschaulichung erstellten BadCompany-Log-/Metrik-Ausschnitt den Log-Leveln und Observability-Säulen zu.

Academy Briefing vereinbaren

Oder sofort per Mail an kontakt@codecraft.academy

Format

160 Minuten (2 Stunden 40 Minuten), live (remote oder vor Ort), Input & geführtes Hands-on zu Error-Budget-Rechnung und Log-Level-Zuordnung

Teilnehmende

DevOps-Engineers, SRE-/Betriebsverantwortliche und Entwickler:innen, die von reaktiven Status-Checks zu proaktiver Observability und einem SRE-Framework wechseln wollen

Voraussetzungen

Keine Pflicht; DevOps Betrieb (On-Call, Blameless Post Mortem) und Docker Betrieb (Prometheus/Grafana-Hands-on) helfen beim Einstieg, sind aber keine Pflicht

Warum dieses Training für deine Organisation wirkt

Klare Abgrenzung statt Doppelung

Der eigene Prometheus/Grafana-Monitoring-Stack kommt aus Docker Betrieb, Bereitschaftsdienst und Blameless Post Mortem aus DevOps Betrieb – hier bleibt der Fokus auf dem Übergang von Status-Monitoring zu Observability und dem SRE-Framework selbst, rein konzeptionell.

Eine Fallstudie von Silo bis SRE

BadCompany GmbH zieht sich als roter Faden durch die Session: vom Dev-Ops-Silo-Problem in Modul 3 bis zur Error-Budget-Rechnung und Log-Interpretation in der Hands-on-Übung.

Hands-on statt Theorie allein

In der geführten Übung rechnet ihr ein Error Budget aus einem fiktiven SLO/SLA-Beispiel durch und ordnet einen fiktiven, von der Academy zur Veranschaulichung erstellten Log-/Metrik-Ausschnitt den Log-Leveln und Observability-Säulen zu – und gleicht beides mit der Musterlösung ab.

Was Teilnehmende mitnehmen

  • Die Monitoring-Phase als Rückkopplung in die Planung einordnen statt als reine Kontrollinstanz für den Betrieb, und die Grenzen des klassischen Status-Monitorings (OK/Warning/Critical/Unknown) benennen: es zeigt, ob ein Dienst antwortet, nicht, wie sich Performance schleichend verschlechtert.
  • Die Fallstudie BadCompany GmbH als Silo-Problem zwischen Dev und Ops einordnen: undurchsichtige Fehlermeldungen als Symptom fehlenden Austauschs, Symptombekämpfung statt Ursachenanalyse, Alarm-Rauschen durch fehlende gemeinsame Priorisierung.
  • Metriken als Zeitreihen (Time Series), strukturierte Log-Level (Debug/Info/Warn/Error/Fatal) und die drei Säulen der Observability (Metrics, Logs, Traces) unterscheiden und den Übergang von reaktivem Monitoring zu proaktiver Observability erklären.
  • Spezialisierte Infrastruktur als Tool-Kategorien einordnen: Log-Server (ELK, FluentD/Fluent Bit, Grafana Loki, OpenTelemetry), Service Mesh (Linkerd, Istio, Cilium), Error Tracking (Sentry), Incident-Alerting (PagerDuty, Opsgenie) – als Landschaft verstehen, nicht bedienen.
  • Business Monitoring und A/B-Tests als Feedbackschleife zwischen CI/CD, Feature Flags und Umsatzwirkung einordnen.
  • Das SRE-Framework SLA (Vertrag), SLO (internes Ziel) und SLI (Ist-Messung) sauber trennen und ein Error Budget berechnen (Beispiel: SLO 99,9 % Verfügbarkeit/Monat = ca. 43 Minuten 50 Sekunden erlaubte Downtime/Monat).
  • In der Hands-on-Übung ein Error Budget aus einem fiktiven SLO/SLA-Beispiel durchrechnen und einen fiktiven, von der Academy zur Veranschaulichung erstellten BadCompany-Log-/Metrik-Ausschnitt interpretieren: was klassisches Monitoring gezeigt/übersehen hätte, welche Observability-Säule früher geholfen hätte, und welche Log-Level zu welchen Zeilen gehören.

Für wen dieses Modul ideal ist

  • • DevOps-Engineers und SRE-/Betriebsverantwortliche, die von reaktivem Status-Monitoring zu proaktiver Observability wechseln wollen
  • • Entwickler:innen, die verstehen wollen, wie Metriken, Logs und Traces zusammenspielen und wie ein Error Budget die eigene Release-Freiheit beeinflusst
  • • Team-/Serviceverantwortliche, die SLA, SLO und SLI sauber trennen und ein Error Budget als Steuerungsinstrument einführen wollen
  • • Voraussetzung: keine Pflicht; DevOps Betrieb und Docker Betrieb hilfreich, keine Pflicht

Rahmendaten

  • • Dauer: 160 Minuten (2 Stunden 40 Minuten) live (remote oder vor Ort)
  • • Format: Input und geführtes Hands-on zu Error-Budget-Rechnung und Log-Level-Zuordnung, kein Prometheus/Grafana-Aufbau, kein Blameless-Post-Mortem-Template
  • • Voraussetzungen: keine Pflicht, DevOps Betrieb und Docker Betrieb hilfreich

Modulaufbau & Agenda

  1. Kick-off & Abgrenzung (10 min): Format, Ablauf und Abgrenzung zu Docker Betrieb (Prometheus/Grafana-Monitoring-Stack-Aufbau dort) und zu DevOps Betrieb (Blameless Post Mortem, ChatOps, Chaos Engineering dort) – hier kein Tool-Hands-on, keine Tool-Bedienung, rein konzeptionell/Tool-Landschaft.

  2. Rückkopplung in die Planung & Grenzen des klassischen Status-Monitorings (15 min): Monitoring als Katalysator für die nächste Planungsiteration statt reiner Kontrollinstanz, die vier Status OK/Warning/Critical/Unknown und ihre Grenzen bei Performance-Trends und schleichender Verschlechterung.

  3. Fallstudie BadCompany GmbH: Silo-Problem Dev vs. Ops (20 min): Monitoring ausschließlich bei Ops, undurchsichtige Fehlermeldungen als Anekdote für das Problem, Symptombekämpfung statt Ursachenanalyse, Alarm-Rauschen durch Überlastung.

  4. Metriken, Logs & Übergang zu Observability (25 min): Zeitreihen-Metriken (Name, Wert, Zeitstempel, Labels), Log-Level-Struktur Debug/Info/Warn/Error/Fatal, die drei Säulen Metrics/Logs/Traces.

  5. Spezialisierte Infrastruktur: Tool-Kategorien (30 min): Log-Server (ELK, FluentD/Fluent Bit, Grafana Loki, OpenTelemetry), Service Mesh (Linkerd, Istio, Cilium), Error Tracking (Sentry), Incident-Alerting (PagerDuty, Opsgenie) – als Landschaft vorgestellt, nicht aufgebaut.

  6. Business Monitoring, A/B-Tests & das SRE-Framework (30 min): Business Monitoring und A/B-Tests als Feedbackschleife, SLA/SLO/SLI-Framework, Error-Budget-Beispielrechnung (SLO 99,9 % = ca. 43 min 50 s erlaubte Downtime/Monat).

  7. Hands-on: Error Budget & BadCompany-Incident-Interpretation (25 min): Teil A SLO/Error-Budget-Rechenbeispiel, Teil B Interpretation eines BadCompany-Log-/Metrik-Ausschnitts, Abgleich mit der Musterlösung.

  8. Fazit & Ausblick (5 min): Monitoring als Rückkopplungsschleife statt Endpunkt, Verweis auf Docker Betrieb für den eigenen Prometheus/Grafana-Aufbau und auf DevOps Betrieb für On-Call und Blameless Post Mortem. Wie SLA/SLO/SLI und Error Budget die fünfte DORA-Metrik (Reliability) ergänzen, ordnet DevOps-Transformation ein.

Hands-on Inhalte (Auszug)

Fallstudie BadCompany GmbH

  • Undurchsichtige Fehlermeldungen als Symptom eines fehlenden Dev-Ops-Austauschs, nicht als Übungsmaterial
  • Symptombekämpfung (mehr Speicherplatz) statt Ursachenanalyse mangels Code-Einblick im Betriebsteam
  • Alarm-Rauschen: relevante Alarme gehen in überlasteten, unpriorisierten Warnungen unter

Observability-Grundlagen

  • Drei Säulen: Metrics zeigen dass, Logs zeigen warum, Traces zeigen wo ein Problem liegt
  • Log-Level-Struktur Debug/Info/Warn/Error/Fatal für aussagekräftige, priorisierbare Meldungen
  • Klassisches Monitoring bleibt reaktiv, Observability liefert auch ohne aktiven Alarm Erkenntnisse

SRE-Framework & Error Budget

  • SLA (rechtlicher Vertrag) vs. SLO (internes Ziel) vs. SLI (Ist-Messung) sauber getrennt
  • Beispielrechnung: SLO 99,9 % Verfügbarkeit/Monat = ca. 43 Minuten 50 Sekunden erlaubtes Error Budget
  • Aufgebrauchtes Error Budget friert neue Feature-Deployments ein, Fokus wandert zur Stabilisierung

Hands-on: Error Budget & Log-Interpretation

  • SLO/SLA-Rechenbeispiel mit fiktiver BadCompany-Incident-Downtime: Error Budget aufgebraucht? SLA oder nur SLO verletzt?
  • Fiktiver, von der Academy zur Veranschaulichung erstellter Log-/Metrik-Ausschnitt: fehlende Sichtbarkeit im klassischen Status-Check erkennen
  • Fünf Log-Zeilen den fünf Log-Leveln zuordnen, Abgleich mit der Musterlösung

Dieses Modul ist Teil unserer Pilotphase. Gemeinsam mit euch definieren wir passende Metriken (z. B. Trefferquote bei der Error-Budget-Rechnung, Qualität der Log-Level-Zuordnung in der Hands-on-Übung) 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 das Error-Budget-Beispiel auf eure tatsächliche SLA/SLO-Landschaft an.

Academy Briefing anfragen