# Änderungsrisiko und Observability

> Deployments und Konfigurationsänderungen mit Wirkungssignalen, Rollback-Kriterien und Zeitlinien koppeln.

Track: [Monitoring, Troubleshooting & Incident Operations](https://opsmith.app/learn/monitoring-incident-operations)  
Kanonische Fassung: https://opsmith.app/learn/monitoring-incident-operations/change-risk-observability  
Stand: 2026-07-30  
Interaktiver Teil: 3 Checks (nur im Browser)

## Änderungen brauchen beobachtbare Exit-Kriterien

### Die Betriebsfrage

Eine zeitliche Korrelation beweist keine Ursache, ist aber ein starker Triage-Hinweis. Eine Änderung darf erst fortgesetzt werden, wenn vorher feststeht, welche Nutzerwirkung sie beobachten und wann sie zurückgerollt wird.

> **Lernziel:** Du kannst eine Änderung mit Baseline, Scope, Abbruchkriterium und geeigneter Verifikation planen.

### Änderungsschleife

Nutzer-SLI und Ausgangswert festhalten → Kleinen Scope und Beobachtungsfenster wählen → Änderung mit Zeitstempel ausrollen → Wirkung und Nebenwirkungen vergleichen → Bei Kriterium Rollback oder kontrolliert ausweiten

### Korrelation begrenzen

Weitere Änderungen während der Analyse verwischen den Befund. Ein Rollback ist nur dann sinnvoll, wenn er sicher, möglich und mit einem erwarteten Signal verbunden ist; andernfalls muss die Incident-Führung die Abwägung übernehmen.

### Im Check

Die Checks verlangen eine vorab definierte Messung. Reine Infrastrukturmetriken reichen nicht, wenn der Dienst weiterhin Nutzeranfragen korrekt verarbeitet.

## Quellen

- sre.google/workbook/canarying-releases — https://sre.google/workbook/canarying-releases/
- sre.google/sre-book/release-engineering — https://sre.google/sre-book/release-engineering/