Define the outcome and interface
In a fictional fund service, every server is available, yet reconciled files arrive after business close. Review should start with the useful outcome and deadline, supported by technical diagnostic indicators. A team completing its task does not establish complete delivery. Define who receives incidents, who coordinates, who can restore service, and who corrects defects. These functions may be distributed with confirmed conditions and contacts. If the team reorganizes, update the interface and test routing; an old unanswered mailbox does not become functional because a document has a recent date. The manager helps resolve gaps and commitments while respecting applicable technical and change authorities in each context.
Demonstrate support transition
Case Handover has an acceptance signature, but alerts still reach the former group and the runbook uses another version. Transition remains conditional on resolving those gaps. Rehearse detection, routing, acknowledgment, escalation, and recovery within authorized scope. Confirm that procedures match the environment and relevant dependencies. Temporary support from the former team may help if capacity, responsibility, and duration are accepted. After handover, new out-of-scope requests require demand and capacity review instead of invisible acceptance or automatic rejection. If L3 restores service through a workaround while another team must change code, separate restoration ownership from corrective ownership. Restored availability does not prove that the cause disappeared.
Examine dependencies and intermediate states
The recovery objective is two hours, but a critical dependency guarantees only an initial response within four. Do not announce readiness merely because a contract exists: response and restoration are different commitments. Seek a rehearsed alternative or renegotiate the objective with decision authority. During an API change, the provider shortens timeout while the consumer retains retries for unknown outcomes. Agree failure and retry semantics and rehearse the combination. In case Schema, producer N+1 and consumer N are incompatible for thirty minutes even though final N+1/N+1 tests pass. Risk lies in transition. Define a sequence or compatibility mechanism and progression or reversal conditions. Final diagrams and isolated unit tests do not establish that window.
Keep indicators and decisions traceable
With 100,000 eligible events and a 99.9% objective, the arithmetic budget is one hundred failures. If twenty occurred, eighty remain for the same fixed population and window; this does not authorize causing failures. Count transactions in the agreed unit without converting three alerts for one transaction into three failures. If the definition excludes synthetic traffic by label, apply the rule to numerator and denominator. Use the actual agreed service policy: a feature pause may permit urgent fixes with analysis and approval. The exception is not automatic. During retirement, seven traffic-free days do not cover a known monthly process. Confirm that cycle and the consumer before closing dependencies. These examples are fictional; the laboratory checks only arithmetic and synthetic rules without validating real policies or operations.
Outcome: valid reconciliation before business close
Dependency: response time is not restoration time
Acceptance: routing + acknowledgment + recovery evidence
Transition: producer/consumer versions during coexistence
Retirement: cover known cycles and confirm consumersAn initial response within four hours does not itself support an objective to recover the complete service within two hours.
Common pitfalls
Signature as readiness proof; green component as complete outcome; response as restoration; final state as proof of transition.
Related topics: Reliability and learning · Technical decisions and quality
Service ownership requires working interfaces, observed conditions, and tracked decisions throughout the lifecycle.
Reference: SRE Engagement Model · GitLab Handbook 2026; DORA current five-metric model; SRE and engineering guidance reviewed 2026-09-30