# SRE Foundations

> Serviceziele, Telemetrie, Alarmierung und Incident-Lernen für allgemeine Softwaresysteme.

Track: [Observability & SRE](https://physar.tech/learn/observability-sre)  
Kanonische Fassung: https://physar.tech/learn/observability-sre/sre-foundations  
Stand: 2026-07-25  
Interaktiver Teil: 2 Checks (nur im Browser)

## Reliabilität beginnt bei Nutzerwirkung

### Messen, was Nutzer merken

Ein Dienst kann Infrastrukturmetriken im grünen Bereich haben und trotzdem sein Nutzerziel verfehlen. Ein SLI misst beobachtbares Serviceverhalten; ein SLO setzt dafür ein bewusstes Ziel. Erst dann ist klar, was ein Alarm schützen soll.

_[Abbildung: Ein SLI wird erst wirksam, wenn sein Signal eine verantwortete Entscheidung und eine messbare Nutzerwirkung verbindet.]_

> **Merksatz:** Verfügbarkeit ist kein Selbstzweck: das relevante Signal beschreibt eine Nutzeraufgabe.

### Signale beantworten verschiedene Fragen

|  |  |
| --- | --- |
| Signal | Frage |
| Metrik | Wie entwickelt sich eine aggregierte Größe? |
| Trace | Welchen Weg nahm diese Anfrage? |
| Log | Welches diskrete Ereignis trat ein? |
| Profil | Welcher Code verbraucht Ressourcen? |

Korrelation macht die Signale wertvoll: eine Fehlerrate ohne Trace erklärt selten, warum sie steigt.

### Alarm ist ein Handlungsauftrag

Ein Alarm sollte eine dringliche, entscheidbare Nutzerwirkung anzeigen und einen Besitzer haben. Rauschen, das niemand sinnvoll bearbeitet, nimmt Aufmerksamkeit von echten Incidents.

> **Trade-off:** Niedrige Schwellen finden mehr Symptome, erzeugen aber mehr Unterbrechung. Ein Error Budget hilft, diesen Konflikt bewusst zu verhandeln.

### Nächste Checks

- Einen SLI aus einer Nutzeraufgabe ableiten
- Trace, Log und Metrik passend kombinieren
- Ein Alert- und Incident-Signal von Diagnosematerial trennen

## Quellen

- OpenTelemetry: Observability Primer — https://opentelemetry.io/docs/concepts/observability-primer/
- Google SRE Workbook — https://sre.google/workbook/