Zurück zum Playbook
Define & DesignDD-10
Service Level Objectives definieren und prüfen
Wählt Zuverlässigkeitsziele für nutzerzentrierte Trade-offs und prüft dann, ob die Indikatoren das Erlebnis wirklich abbilden.
ProduktstatusVerfügbar
Input3 benötigte InputsKritische User Journeys und Kundenerwartungen · Verfügbare Messungen und Zuverlässigkeitsbelege · Fokus der Initiative und freigegebene Product-Brain-Leitlinien
SkillsDefine or review reliability objectives · Prepare task context · Review an artifact against agreed criteriaReliability Engineer + Reliability Engineer Agent
ErgebnisSLO-Definition: Nutzererwartungen, SLI-Definitionen, Ziele mit Zeitfenster und Owner sowie die Error-Budget-Entscheidungsregel.Artefakt: SLO-Definition
Owner
Reliability Engineer
Mensch + Agent
Beteiligte · Agents
EngineerProduct ManagerReliability Engineer Agent
Auslöser
Ein Service und seine kritischen User Journeys brauchen vereinbarte Zuverlässigkeitsziele, oder ein Review steht an.
Benötigter Kontext
Product BrainKritische User Journeys und KundenerwartungenAnalyticsVerfügbare Messungen und ZuverlässigkeitsbelegeProduct BrainFokus der Initiative und freigegebene Product-Brain-Leitlinien
Optionaler Kontext
ConfluenceAktuelle Ziele und Error-Budget-RegelnArchitekturService-Architektur
Skills
Define or review reliability objectivesPrepare task contextReview an artifact against agreed criteria
Vorgeschlagener Gesprächsbogen
- 1Zuverlässigkeits-Outcomes wählenDie kritischen Nutzeroperationen und die akzeptable Verschlechterung identifizieren, dann wenige bedeutsame Zuverlässigkeitsdimensionen wählen.Skills: Prepare task context
- 2Indikatoren und Ziele definierenGute und gesamte Ereignisse, Datenquelle, Zeitfenster, Ziel, Messgrenzen und eine erste Error-Budget-Regel festlegen. Kein perfektes Ziel annehmen.Skills: Define or review reliability objectives
- 3Zuverlässigkeits-Trade-offs vereinbarenMachbarkeit mit Engineering und Product prüfen, Ownership bestätigen und festlegen, wie der Budgetverbrauch Priorisierung oder Release-Entscheide verändert.
- 4Service-Evidenz prüfenBeobachtete Leistung mit der Vereinbarung und dem Nutzererlebnis vergleichen. Blinde Flecken erkennen und versionierte Updates vorschlagen, statt Ziele nach einer Verletzung stillschweigend zu verschieben.Skills: Define or review reliability objectives · Review an artifact against agreed criteria
Ergebnis
SLO-Definition: Nutzererwartungen, SLI-Definitionen, Ziele mit Zeitfenster und Owner sowie die Error-Budget-Entscheidungsregel.
Artefakte
Erstellt: SLO-Definition
So sieht gut aus
- Indikatoren haben eindeutige Messdefinitionen.
- Ziele und die Freigabe der Regel sind von Vorschlägen unterscheidbar.
- Keine behauptete Zielerreichung ohne Telemetrie; keine Alerts konfiguriert und keine Produktion geändert.
Freigabe
Der Service-Owner bestätigt Ziele, Ownership und die Error-Budget-Regel mit Engineering und Product.
Ziel
ConfluenceProduct Brain
Meist als Nächstes
Menschen und Agents arbeiten mit demselben Product Brain. Der Owner bleibt verantwortlich. Zugewiesene Agents bereiten vor und prüfen. Ein benannter Mensch gibt an der Freigabe frei.
Wähl den Einstieg, der zu deiner Rolle passt.
Leg mit uns die Product-AI-Richtung fest oder teste das gemeinsame Product Brain mit Jira und Code an echter Arbeit.