即使 Google 一律要求 SRE「50% 專案 / 50% 運維」的平衡，現實中可能因 ticket 量激增而連續數月失衡——團隊或 burnout，或專案陷入停滯。
對策：暫時嵌入一位 SRE 到過載團隊——任務不是幫他們清 queue，而是改善他們的實踐。
嵌入只派一人——兩人會讓被嵌團隊產生防衛反應。
第一階段：學服務、取得脈絡#
嵌入者的職責是闡明「為什麼某些流程與習慣影響可擴展性」——不是幫團隊擋告警，是讓服務真的能 work。
Ops 模式 vs. 非線性擴展#
- Ops 模式：服務變大就加管理員管 VM
- SRE 模式：寫軟體或消除擴展性問題，讓人數不隨負載線性成長
許多滑入 ops 模式的團隊會說「我的服務很小，規模沒關係」——shadow 他們的 On-Call 評估是否屬實。
- 服務真的小但對業務重要 → 把焦點放在「目前做法如何阻礙可靠性改善」
- 服務剛起步 → 為「爆炸性成長」做準備（100 QPS 可能一年變 10k QPS）
找出最大的壓力源#
團隊往往因「不堪壓力」滑入 ops 模式——但壓力可能是真的也可能是想像的。先按「對團隊壓力的影響」排序故障，注意有些小問題可能因團隊歷史而帶來巨大壓力。
找出將要燃燒的火種#
可能的隱患：
- 知識斷層：大團隊裡過度專業化讓人沒整體理解
- 被 SRE 維護但慢慢變大的服務：因為「自家人罩」反而沒得到該有的審查
- 過度仰賴「下個大版本」：把問題延宕數月相信未來能解決
- 無人診斷的常見告警：被視為短暫但實際分心
- 被客戶抱怨但無正式 SLI/SLO/SLA 的服務
- 容量規劃只說「加機器」：未來性不足
- 事後檢討 action items 只是「rollback」：沒挖根因（如「為什麼某些情境會花 60 秒抓首 MB？」而非「把 timeout 改回 60 秒」）
- 「dev 才知道」的關鍵元件：SRE 至少要知道「壞了會怎樣、多急要修」
第二階段：分享脈絡#
為團隊寫一份好事後檢討#
別翻舊事後檢討留言改進——會引發防衛。
改採：嵌入期間必有 outage，親自主導下一份事後檢討，示範無究責、深挖根因、有持久修復的版本。
對「為什麼是我？」的反應：
「複雜系統的多重微妙互動下，錯誤無可避免。你當班，我相信你以當時的資訊做出了對的決定。請寫下你每個時刻的想法，讓我們找出系統哪裡誤導你、認知負擔太重的地方。」
破除「壞蘋果理論」——拿掉壞人系統就會好的迷思已被多領域（航空安全等）駁倒。
把火源分類#
兩類：
- 本來不該存在的火：toil
- 本來就是工作一部分的火：但需要工具把燃燒控制好
整理清單後攤給團隊看，清楚說明每個火源屬於哪一類、為什麼。
第三階段：推動改變#
團隊健康是「過程」而非「英雄式一次性投入」。
人類擅長 homeostasis——把初始條件設對、教會少數核心原則，他們就會自我調節。
從基礎開始#
第一個目標：寫出 SLO（若尚未存在）。
SLO 是「把團隊從 reactive ops 拉回健康 SRE focus 的最強槓桿」。沒有 SLO，本章其他建議都用不上。
找隊員一起清火種#
別自己動手修——這會加深「改變是別人的事」的錯覺。
改採：
- 找一件單人可完成的有用工作
- 清楚解釋此工作如何永久解決事後檢討的問題
- 你當該變更的 reviewer
- 對 2–3 個議題重複此程序
其餘識別到的問題，寫成 bug 或 doc 留給團隊——既散播資訊，也鼓勵團隊重視文件。
解釋你的推理#
不論有沒有人問，主動解釋你每個決定的推理——讓團隊建立心智模型，你離開後他們才能預測「你會怎麼評」。
好範例#
- 「我不是因為測試不夠擋這次發佈，而是因為這個 quarter 的錯誤預算用光了。」
- 「Release 需 rollback-safe 因為我們 SLO 很嚴——MTTR 必須很小，不能容許先做深度根因分析再 rollback。」
壞範例#
- 「不應該讓每個 server 自己產 routing config，因為我們看不到。」
- → 改：「…不安全因為該段程式的 bug 會跨服務同時失效，而且額外程式碼是 bug 源頭，可能拖慢 rollback。」
- 「自動化遇到衝突部署時應該放棄。」
- → 改：「…因為我們做了『所有變更走自動化』的簡化假設，現在顯然被破壞了。若常發生，要找出並消除未受管的變更源頭。」
問引導式問題#
別問載彈式問題（loaded），問引導式問題（leading）讓人回到第一原理。
✅ 「TaskFailures 告警頻繁但 On-Call 多半沒動作。這會對 SLO 有什麼影響？」
❌ 「這些舊的卡死 release 是怎麼回事？」
✅ 「這個 turnup 流程很複雜——你知道為什麼新增實例要改這麼多設定檔嗎？」
❌ 「Frobnitzer 為什麼做這麼多事？」
結語#
嵌入結束後，給團隊：
- 為何要改變的技術（可能量化）視角
- 改變看起來的具體例子
- 對「SRE 民間智慧」的邏輯解釋
- 處理新情況的核心原則
最後寫一份「postvitam」報告（事生報告，與事後檢討相對）——解釋通往成功的每個關鍵決策。
嵌入結束後續仍持續：design / code review、觀察容量規劃、緊急應變、rollout 流程是否慢慢進步。