SLO und Error Budget im Alltag
Ein SLO ist wie ein Qualitätsversprechen mit messbarer Toleranz. Das Error Budget ist der Teil, den ein System innerhalb eines Zeitraums noch „verbrauchen“ darf, bevor Stabilität Vorrang vor neuen Features bekommt.
Alltagstaugliche Ablaufbeschreibung
Dieser Abschnitt beschreibt den Ablauf ohne unnötige Fachsprache. Er dient als Brücke zwischen dem sichtbaren Ergebnis und der technischen Umsetzung.
- SLI definieren
- Zielwert festlegen
- Messfenster wählen
- Error Budget berechnen
- Burn Rate beobachten
- Alarm- und Release-Entscheidungen ableiten.
Fachlicher Ablauf
Eine geprüfte Änderung soll kontrolliert in Produktion gelangen. Fachlich zählt, dass der gewünschte Nutzen ausgeliefert wird, ohne Sicherheit, Stabilität oder Rückrollfähigkeit zu verlieren.
- Fachliches Ziel: Der Ablauf liefert ein fachlich eindeutiges und für Benutzer beziehungsweise Betrieb nachvollziehbares Ergebnis.
- Verantwortung: Jeder beteiligte Bereich entscheidet nur innerhalb seiner eigenen fachlichen Zuständigkeit.
- Sichtbares Ergebnis: Benutzer erhalten die neue Funktion schrittweise; bei Problemen kann die alte Version reproduzierbar wiederhergestellt werden.
Technischer Ablauf
Ein Commit startet Build, Tests, Security Scans und Artifact-Erzeugung. Das Image wird unveränderlich in der Registry gespeichert. GitOps übernimmt den gewünschten Deployment-Zustand; Kubernetes führt den Rollout mit Probes und kontrollierter Strategie aus.
- Daten und Schnittstellen: Daten werden an jeder Grenze validiert und nur über definierte APIs, Ports oder Events weitergegeben.
- Fehlerbehandlung: Fehler werden dort behandelt, wo ausreichender Kontext und Verantwortung vorhanden sind; Wiederholungen müssen sicher und nachvollziehbar bleiben.
- Technischer Nachweis: Geprüft werden Quality Gates, Image Digest, GitOps Sync, Pod Readiness, Error Rate und Rollback-Fähigkeit.
Zusammenspiel: Der fachliche Ablauf erklärt, warum etwas geschieht und welches Ergebnis zählt. Der technische Ablauf erklärt, wie dieses Ergebnis zuverlässig, sicher und beobachtbar umgesetzt wird.
Release Gates
Vor einer neuen Version werden technische, fachliche, didaktische und betriebliche Kriterien gemeinsam geprüft.
IDs eindeutig, Pflichtfelder vorhanden, Beziehungen gültig.
Keine defekten Links, Anker oder verwaisten Seiten.
Keine reine Stichwortseite; Problem, Zusammenhang und Beispiel sind verständlich erklärt.
Lernziele, Aufgaben und Selbsttest passen zum Kapitel.
Alternativen, Trade-offs und betroffene Beziehungen sind dokumentiert.
SLO, Telemetrie, Runbook oder Recovery-Bezug ist vorhanden, sofern der Knoten produktionsrelevant ist.
Daten, Identitäten, Berechtigungen und Supply-Chain-Auswirkungen sind geprüft.
ZIP, SHA-256, Check-Dateien und Öffnungsreihenfolge sind konsistent.