🎯 什麼情境該想到我
當你「同一個生產問題重複折磨維運好幾個月，而寫出它的人完全沒感覺」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：讓價值流上的每個人都共同承擔下游的營運事故責任，使上游的架構與程式決策能拿到**切身的（visceral）**回饋。
做法要點：
- 把 developers、development managers、architects 都放進 pager rotation（呼叫器輪值），就像 Facebook 生產工程總監 Pedro Canahuati 在 2009 年做的那樣。
- 這樣做確保價值流上每個人都會對自己所做的上游架構與程式決策拿到切身回饋。
- 效果：Ops 不再被孤立地獨自面對「跟程式碼有關的生產問題」；所有人一起在「修生產缺陷」與「開發新功能」之間找平衡，不管你站在價值流的哪一段。
- 副作用（書中特別點出的價值）：讓開發管理層看見「功能被標成 done 不代表業務目標達成」——功能要到在生產環境按設計運作、且沒有為 Dev 或 Ops 造成過多升級與計畫外工作時，才算真的完成。
- 這個做法對 market-oriented 團隊（同時負責開發與運行）與 functionally-oriented 團隊一樣適用。PagerDuty 的 Arup Chakrabarti（2014）觀察：專職 on-call 團隊越來越少見，任何碰到生產程式與環境的人，都被期待在服務中斷時聯絡得上。
配套：服務退回機制（Service Handback）
- 對於已經在生產環境的服務，需要另一個機制確保 Ops 不會被卡在一個無法支援的服務上。
- 機制內容：當一個生產服務變得夠脆弱時，Ops 有權把生產支援責任退回給 Development。
- 服務回到 developer-managed 狀態後，Ops 的角色從「生產支援」轉為「顧問」，協助團隊把服務變得 production-ready。
- 書中稱這是壓力洩壓閥（pressure escape valve）：確保 Ops 不會被困在管理脆弱服務、被越積越多的技術債埋掉，把局部問題放大成全域問題；同時也保住 Ops 做改善與預防性專案的產能。
- Handback 在 Google 是長期實踐，書中說它「或許是 Dev 與 Ops 工程師之間互相尊重最好的展示之一」。
Google 的門檻（SRE 案例，2010）：
- SRE 極為稀缺，只分配給對公司最重要、或必須符合法規要求的產品團隊，而且那些服務營運負擔必須夠低；不符標準的產品維持 developer-managed 狀態。
- 即使新產品重要到值得配 SRE，開發者仍必須先自行管理該服務在生產環境運行至少六個月，團隊才有資格被分配 SRE。
原文：「this by putting developers, development managers, and architects on pager」（L8710，接 L8711「rotation, just as Pedro Canahuati, Facebook Director of Production Engineering,」）
原文：「developers at 2 a.m., defects were fixed faster than ever.」（L8720，Patrick Lightbody, 2011）
原文：「when a production service becomes sufficiently fragile, Operations has the」（L8906，接 L8907「ability to return production support responsibility back to Development.」）
原文：「have self-managed their service in production for at least six」（L8957，接 L8958「months before it becomes eligible to have an SRE assigned to the」）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 這是把痛苦往上游傳的機制，前提是團隊有心理安全感、不會演變成互相究責——否則只是換一批人被燒掉。
- 沒有足夠遙測的話，被叫醒的開發者也只能瞎猜；先補 五層遙測覆蓋 與 從事故回推告警。
- Handback 是權力設計（Ops「有能力」退回），不是情緒發洩；退回後 Ops 要轉成顧問角色協助團隊補強，否則服務只是換個人被困住。
- Google 的「至少六個月自管」是取得 SRE 支援的資格門檻，不是「六個月後就可以丟給別人」。