opsmith / monitoring-incident-operations / Modul

Änderungsrisiko und Observability

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

Änderungen brauchen beobachtbare Exit-Kriterien

Einführung · 4 Abschnitte · ~11 Min Lesezeit · Stand

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.

Änderungsschleife

  1. Nutzer-SLI und Ausgangswert festhalten
  2. Kleinen Scope und Beobachtungsfenster wählen
  3. Änderung mit Zeitstempel ausrollen
  4. Wirkung und Nebenwirkungen vergleichen
  5. 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.

Gelesen ist nicht geprüft: Im Modul entscheidest du die Fälle selbst und siehst danach, wo dein Urteil trägt.

3 Checks starten →

Modul-Aufbau

EINFÜHRUNGÄnderungen brauchen beobachtbare Exit-Kriterien~11 Min
ADR-001CHANGE-CRITERIAsolide
TRACE-002MISSION · CHANGE-CORRELATIONsenior
FLOW-003MISSION · CANARY-LOOPsolide

Quellen

  1. 01sre.google/workbook/canarying-releases
  2. 02sre.google/sre-book/release-engineering