SRE · SLOs · Observability
SRE Consulting: Zuverlässigkeit, Automatisierung und stabile Plattformen
Ihre Systeme laufen, aber Ausfälle fallen zu spät, zu laut oder gar nicht auf. SKAFFON macht Zuverlässigkeit messbar: mit SLOs und Fehlerbudgets, einer Telemetrie-Grundlage, Alarmen, die zählen, und Nachbetrachtungen, die zu Änderungen führen.
- SLIs, SLOs und Fehlerbudget-Regel
- Prometheus, Grafana, Loki, Tempo
- OpenTelemetry als Erfassungsschicht
- Dashboards und Runbooks als Code
01Ausgangslage
Wenn Kunden die Störung melden, bevor das Monitoring sie sieht
SKAFFON unterstützt Teams dabei, Zuverlässigkeit messbar und steuerbar zu machen. Das ist eine Planungs- und Engineering-Leistung: Wir entwerfen, bauen und übergeben. Den laufenden Betrieb von Monitoring übernimmt ein eigenes Angebot (Managed Monitoring und Observability).
Die Arbeit lohnt sich vor allem für IT-Leitung und Plattformverantwortliche, die sich in einem dieser Punkte wiedererkennen:
- Viele Alarme, aber niemand weiß, welche zählen; nächtliche Alarme führen selten zu einer Maßnahme.
- Kunden melden Störungen, bevor das Monitoring sie sieht.
- „Zuverlässig genug“ ist nicht definiert; Entwicklung und Betrieb streiten über Stabilität gegen neue Funktionen.
- Nach einer Störung wird repariert, die Ursache bleibt, und dieselbe Störung kehrt wieder.
- Logs, Metriken und Traces liegen in getrennten Werkzeugen und lassen sich nicht verbinden.
02Methode
Vom Indikator zur Regel: so entsteht ein SLO
Das Grundmodell folgt dem SRE Workbook von Google: Ein SLI ist typischerweise das Verhältnis guter Ereignisse zu allen Ereignissen, das Fehlerbudget ist das Komplement zum SLO. Das Beispiel darunter ist ein Rechenbeispiel zur Veranschaulichung; die Zahlen sind keine Empfehlung und kein Ziel für Ihre Systeme, sie ergeben sich in der Praxis aus Messung und Geschäftsbedarf.
03Rechenbeispiel
Ein SLO für eine Bestell-API, Schritt für Schritt
Die Reihenfolge ist die, in der wir ein SLO mit Ihnen entwickeln. Die Zahlen sind angenommen.
- 01
Dienst und „gute“ Anfrage festlegen
DienstBestell-API: Eine Anfrage ist „gut“, wenn sie mit einem Erfolgsstatus beantwortet wird und innerhalb einer vereinbarten Zeitschwelle antwortet.
- 02
SLI definieren
SLIGute Anfragen geteilt durch alle gültigen Anfragen, gemessen am Lastverteiler.
- 03
Ziel setzen
SLO (angenommen)99,9 Prozent gute Anfragen über 30 Tage.
- 04
Fehlerbudget ausrechnen
Budget0,1 Prozent. Bei angenommenen 3 Millionen Anfragen im Zeitraum entspricht das 3.000 schlechten Anfragen.
- 05
Messen und sichtbar machen
MessungPrometheus erfasst Anfragezähler und Latenz-Histogramme; Grafana zeigt das verbleibende Budget.
- 06
Regel vereinbaren
Fehlerbudget-RegelIst mehr als die Hälfte des Budgets vor Ablauf des halben Zeitraums verbraucht, wird die Priorität der Stabilitätsarbeit im nächsten Planungstermin besprochen. Ist es aufgebraucht, gilt, was Produkt, Entwicklung und Betrieb vorab vereinbart haben, etwa Stopp riskanter Änderungen bis zur Erholung.
- 07
Offene Fragen klären
Vor InbetriebnahmeWas zählt als „gültige“ Anfrage? Wie werden geplante Wartungen behandelt? Welche Abhängigkeiten, etwa ein Zahlungsdienst, sind im SLO enthalten?
04Alarmierung
Alarme nach Wirkung sortiert: wer wird wann geweckt
Wir entwerfen Alarme so, dass sie auf Auswirkungen für Nutzer zielen und Ursachen als Hilfsinformation dienen. Die Alarmregeln werten wir in Prometheus aus; Routing und Gruppierung setzen wir mit dem Alertmanager um, der Alarme gruppiert, hemmt (Inhibition) und stumm schaltet (Silencing).
| Alarmart | Beispiel | Wohin | Erwartete Reaktion |
|---|---|---|---|
| Nutzerwirkung (SLO-basiert, hohe Verbrauchsrate des Budgets) | Fehlerquote der Bestell-API steigt über Schwelle | Bereitschaft, sofort | Untersuchen und eingreifen |
| Drohende Nutzerwirkung | Speicher läuft in absehbarer Zeit voll | Ticket oder Kanal, werktags | Planbare Maßnahme |
| Ursache / Diagnose | Hohe CPU-Last eines Knotens | Dashboard, kein Alarm | Zur Analyse bei einer Störung |
| Wartung / Bekannt | Geplante Migration | Stumm geschaltet mit Ablaufzeit | Keine |
Jeder Alarm erhält Besitzer, Runbook-Verweis und eine Entscheidung, ob er weiterhin gebraucht wird. Alarme ohne Reaktion werden gestrichen oder herabgestuft.
05Observability-Design
Welche Signale braucht welcher Dienst, und wie lange?
Im Design legen wir je Dienst fest, welche Metriken, Logs und Traces erfasst werden, wie sie erfasst werden und wie lange sie aufbewahrt bleiben.
OpenTelemetry ist dabei die herstellerneutrale Schicht zum Erzeugen und Sammeln der Signale. Es ist selbst kein Speicher und keine Auswertung; diese Rollen übernehmen die Backends.
- Metriken: Prometheus
- Dashboards: Grafana
- Logs: Loki
- Traces: Tempo
06Lieferumfang
Sieben Ergebnisse, die in Ihrem Repository und Ihren Runbooks landen
Je nach Scope liefern wir diese Bausteine einzeln oder gemeinsam.
-
SLIs und SLOs
Für ausgewählte Dienste legen wir mit Ihnen fest, was „gut“ bedeutet und welches Ziel gilt.
-
Fehlerbudget-Regel
Eine schriftliche Vereinbarung zwischen Produkt, Entwicklung und Betrieb, was geschieht, wenn das Budget aufgebraucht ist, etwa Priorität für Stabilitätsarbeit oder Pause bei Funktionsfreigaben.
-
Observability-Design
Signale je Dienst, Erfassung und Aufbewahrung, abgestimmt auf Ihre Umgebung.
-
Alarmierung
Alarmregeln auf Basis der SLOs mit Routing und Gruppierung.
-
Störungsnachbereitung
Vorlage für Nachbetrachtungen ohne Schuldzuweisung mit Zeitlinie, Ursachen, Erkennungslücke und Maßnahmen mit Eigentümer und Termin; Begleitung der ersten Nachbetrachtungen.
-
Automatisierung
Wiederkehrende manuelle Betriebsaufgaben wie Wiederherstellung, Skalierung und Rotation werden nach Aufwand und Nutzen automatisiert.
-
Übergabe
Dashboards, Alarmregeln und Runbooks als Code im Repository, dazu die Einweisung Ihres Teams.
07Technischer Kern
Die Werkzeuge hinter den Signalen
Je nach Umgebung kommt dieser Kern zum Einsatz. Werkzeuge liefern Signale; Zuverlässigkeit entsteht durch Entscheidungen und Änderungen.
Erfassung
- OpenTelemetry
Metriken und Alarme
- Prometheus
- Alertmanager
Auswertung
- Grafana
- Loki (Logs)
- Tempo (Traces)
Plattformen, auf denen wir das aufsetzen: Kubernetes, virtuelle Maschinen und Cloud-Dienste, siehe Kubernetes-Beratung.
Telemetrie-Schutz
Telemetrie enthält schnell sensible Inhalte, deshalb entscheiden wir das im Design
Nutzerkennungen in Logs, Parameter in Traces: Wir legen fest, was erfasst, was maskiert und wie lange es aufbewahrt wird. Zugriff auf Dashboards und Logs ist rollenbasiert, Zugangsdaten für die Erfassung liegen in einem Geheimnisspeicher. Zur Anknüpfung an die Sicherheitsüberwachung siehe Cloud Security.
Cloud Security08Vorbereitung
Diese Eingaben brauchen wir für den SRE-Start
- Liste der Dienste mit Eigentümer und geschäftlicher Bedeutung
- Zugang zu vorhandener Überwachung, Alarmhistorie und Störungsprotokollen
- Bereitschaftsmodell, soweit vorhanden (wer wird wann alarmiert)
- Plattform: Kubernetes, virtuelle Maschinen, Cloud-Dienste
- Bereitschaft von Produkt und Entwicklung, ein SLO mitzutragen; ohne diese Zustimmung bleibt ein SLO ein Dokument
09Abgrenzung
Für wen sich SRE Consulting von SKAFFON lohnt, und für wen nicht
Das passt
- Sie wollen SLOs, Alarme und Nachbetrachtungen aufbauen und danach selbst betreiben.
- Produkt und Entwicklung sind bereit, aus Kennzahlen Konsequenzen zu ziehen.
- Ihr Bereitschaftsmodell bleibt in Ihrer Hand; wir entwerfen die Technik und die Regeln dafür.
Das passt nicht
- Sie suchen einen laufenden Überwachungs- und Bereitschaftsdienst: dafür gibt es Managed Monitoring und Observability oder Cloud-Betrieb.
- Sie wollen Kennzahlen ohne Konsequenzen; ein SLO ohne Fehlerbudget-Regel ändert nichts.
- Sie erwarten, dass ein Werkzeug Zuverlässigkeit „einkauft“.
- Es gibt bereits funktionierende Observability mit Praxis in der Nachbereitung und Sie suchen nur Betriebspersonal: dann ist Nearshore-DevOps oder ein Managed Service passender.
10Angebot
Wovon der Umfang eines SRE-Projekts abhängt
Was den Aufwand bestimmt, steht unten; das Angebot fasst Umfang und Preismodell zusammen. Es entsteht nach einem Scoping-Gespräch, mit Phasen, Ergebnissen und Annahmen.
Welche Störung hat Sie zuletzt am meisten getroffen?
Nennen Sie uns Dienste, heutige Überwachung und die letzten Störungen, die Sie schmerzhaft getroffen haben. Zurück zur Übersicht: Leistungen.