Building Service Ownership Using Documentation, Telemetry, and a Chance to Make
summary
Company uses services.yaml as the single source of truth to generate dashboards, escalation policies and CI/CD entries, and it augments human-written wikis with automated dependency diagrams from distributed tracing. Alerts collect traces and an automation traverses causal dependencies to page downstream teams most likely to fix the fault, cutting the number of responders and shortening mitigation time. Required tiny postmortems capture incident metadata, and SLOs are derived from traces (example: p99 < 5s for a caller forces tighter targets for dependent services).
AI-written summary · about
chapters (21)
- 0:00Intro
- 2:42Service ownership, defined
- 3:40Obstacles to successful service ownership
- 6:12Distributed tracing, defined
- 7:40Relationships matter
- 8:08Traces = raw material, not finished product
- 10:18Centralized documentation
- 14:33Why is documentation important?
- 17:24Iterating toward ownership
- 19:38More context -- mitigating facter
- 20:36Dynamic alert delivery
- 22:37Handling alerts
- 23:34Improving postmortems
- 23:52Postmortems are documentation
- 25:16Why is improving oncall important?
- 29:22Determining SLOS
- 30:16Derive internal SLOs using tracing
- 33:04Why are SLOs important?
- 34:023-piece puzzle review
- 35:13Making changes
- 36:49Ownership = Accountability + Agency
related talks
44mFull Service Ownership & The Lifecycle of a Service
24mThe Lifecycle of A Service
25mThe More You Know: A Guide to Understanding your Systems
38mDemocratizing Observability
11mFitness functions: Scaling service consistency
29mObservability; a gentle introduction
44mYou build it, you run it
29mYou build it, you run it.