---
title: "SRE Consulting: Zuverlässigkeit und Observability | SKAFFON"
description: "SRE Consulting von SKAFFON: SLOs und Fehlerbudgets, Observability mit Prometheus, Grafana, Loki, Tempo und OpenTelemetry, Alerting und Incident-Retros."
url: https://skaffon.de/leistungen/sre-observability/
---
![Abstrakte blau leuchtende Punktewellen auf dunklem Hintergrund, als Sinnbild für Telemetriedaten und Messsignale](/_astro/telemetrie-signalwellen-hero.DgMe5VE9_uEwt7.jpg) 

1. [Startseite](/)
2. [Leistungen](/leistungen/)
3. SRE Consulting: Zuverlässigkeit, Automatisierung und stabile Plattformen

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.

[Projekt anfragen](/projekt-anfragen/) [Zum SLO-Rechenbeispiel](/leistungen/sre-observability/#slo-rechenbeispiel) 

- SLIs, SLOs und Fehlerbudget-Regel
- Prometheus, Grafana, Loki, Tempo
- OpenTelemetry als Erfassungsschicht
- Dashboards und Runbooks als Code

Autor: [Ibrahim Yesilay](/unternehmen/ibrahim-yesilay/), Gründer und Geschäftsführer Stand: 13.11.2026 

Ausgangslage

## 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](/managed-services/observability-monitoring/)).

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.

![Silhouette einer Person im Profil vor einem Bildschirm in einem dunklen Raum, als Sinnbild für nächtliche Bereitschaft und Störungsanalyse](/_astro/entwickler-silhouette-nachts-am-bildschirm.DQsShF_e_Z2wbfIj.jpg) 

Methode

## Vom Indikator zur Regel: so entsteht ein SLO

Das Grundmodell folgt dem [SRE Workbook von Google](https://sre.google/workbook/implementing-slos/): 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.

 Illustratives Rechenbeispiel, keine Empfehlung. 

 Illustratives Rechenbeispiel, keine Empfehlung. 

Rechenbeispiel

## 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.

1. 01  
### Dienst und „gute“ Anfrage festlegen  
Dienst  
Bestell-API: Eine Anfrage ist „gut“, wenn sie mit einem Erfolgsstatus beantwortet wird und innerhalb einer vereinbarten Zeitschwelle antwortet.
2. 02  
### SLI definieren  
SLI  
Gute Anfragen geteilt durch alle gültigen Anfragen, gemessen am Lastverteiler.
3. 03  
### Ziel setzen  
SLO (angenommen)  
99,9 Prozent gute Anfragen über 30 Tage.
4. 04  
### Fehlerbudget ausrechnen  
Budget  
0,1 Prozent. Bei angenommenen 3 Millionen Anfragen im Zeitraum entspricht das 3.000 schlechten Anfragen.
5. 05  
### Messen und sichtbar machen  
Messung  
Prometheus erfasst Anfragezähler und Latenz-Histogramme; Grafana zeigt das verbleibende Budget.
6. 06  
### Regel vereinbaren  
Fehlerbudget-Regel  
Ist 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.
7. 07  
### Offene Fragen klären  
Vor Inbetriebnahme  
Was zählt als „gültige“ Anfrage? Wie werden geplante Wartungen behandelt? Welche Abhängigkeiten, etwa ein Zahlungsdienst, sind im SLO enthalten?

Alarmierung

## 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](https://prometheus.io/docs/alerting/latest/alertmanager/) um, der Alarme gruppiert, hemmt (Inhibition) und stumm schaltet (Silencing).

__Entwurfsraster für Alarme: Symptom vor Ursache (illustrativ)__
| 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.

Observability-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](https://opentelemetry.io/docs/what-is-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

[Wenn der Betrieb dazukommen soll](/managed-services/observability-monitoring/)

![Laptop-Bildschirm mit dunklem Dashboard: Histogramme, Verlaufskurven und Kennzahlen zu Ladezeit und Sitzungen](/_astro/metriken-dashboard-laptop.DDN4EHVu_3CRRg.jpg) 

Lieferumfang

## 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](/leistungen/devops-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.

Technischer 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](/leistungen/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 Security](/cybersecurity/cloud-security/) 

Vorbereitung

## 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

Abgrenzung

## 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](/managed-services/observability-monitoring/) oder [Cloud-Betrieb](/managed-services/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](/nearshore/devops-kubernetes-teams/) oder ein Managed Service passender.

Angebot

## 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.

Aufwandstreiber

Zahl der Dienste im Scope, vorhandene Werkzeuge und deren Zustand, Plattformvielfalt, Zahl der beteiligten Teams und der Anteil, den Ihr Team selbst baut.

## 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](/leistungen/).

[Projekt anfragen](/projekt-anfragen/) [Alle Leistungen](/leistungen/)