🎯 什麼情境該想到我
當你「生產環境裡有一個服務只有某一個人看得懂，他請假那天大家只能祈禱」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：確保技術選擇是在幫助達成組織目標，而不是只優化了單一團隊的生產力。
問題長什麼樣：在服務導向架構下，小型服務團隊本來可以用任何最適合自己的語言或框架——有時這確實最能達成組織目標。但反面情境是：某個關鍵服務的專業只存在於一個團隊裡，只有那個團隊能做變更或修問題，於是形成瓶頸。換句話說，我們優化了團隊生產力，卻不經意地阻礙了組織目標的達成。
做法要點
- 由 Dev 與 Ops 共同產出一份「Ops 會支援的技術清單」。要確保 Ops 能影響生產環境使用哪些元件，或者讓 Ops 有權「不為不受支援的平台負責」。
- 若還沒有這份清單，就系統性地盤點整個生產基礎設施、服務，以及所有目前受支援的相依，找出哪些正在製造不成比例的失效需求與計畫外工作。
- 找出四類該移除的技術：
- 阻礙或拖慢工作流動的（impede or slow down the flow of work）
- 不成比例地產生大量計畫外工作的（disproportionately create high levels of unplanned work）
- 不成比例地產生大量支援請求的（disproportionately create large numbers of support requests）
- 最不符合期望架構結果的——期望結果包括吞吐（throughput）、穩定（stability）、安全（security）、可靠（reliability）、業務持續性（business continuity）
- 把這些有問題的基礎設施與平台從 Ops 支援的技術中移除，讓 Ops 能專注在最能達成組織全域目標的基礎設施上。
Google 的做法：Tom Limoncelli——「我在 Google 時，我們有一個官方的編譯語言、一個官方的腳本語言、一個官方的 UI 語言。是的，其他語言也以某種方式被支援，但堅守『這三大』意味著支援函式庫、工具，以及更容易找到協作者。」這些標準也透過 code review 流程以及內部平台支援哪些語言來強化。
管理心法：buoys, not boundaries（浮標，而非邊界）
HP 的 CIO Ralph Loura：不是畫出所有人都必須待在裡面的硬邊界，而是放置浮標標示出「深水區」——在那裡你是安全且受支援的。只要遵循組織原則，你可以越過浮標。領導者的工作是導航航道、標示航道，並允許人們去探索航道之外。
Etsy 2010 案例
- 在一次近乎災難的旺季之後，Etsy 團隊決定大幅刪減生產環境使用的技術數量，只選少數幾樣是整個組織都能完整支援的，其餘全部根除。
- 早期決定之一是把整個 Etsy 平台遷往 PHP 與 MySQL。書中明說：這主要是哲學上的決定而非技術上的決定——他們希望 Dev 與 Ops 都能理解完整的技術堆疊，讓每個人都能貢獻到單一平台上，也讓每個人都能讀懂、重寫、修復彼此的程式。
- 退役清單（Michael Rembetsy，時任 Etsy 維運總監：「我們讓一些很棒的技術退役，把它們完全移出生產環境」）：lighttpd、Postgres、MongoDB、Scala、CoffeeScript、Python 等等。
- MongoDB 的教訓（Dan McKinley）：無 schema 資料庫帶來的所有好處，都被團隊必須解決的維運問題抵銷掉了——logging、graphing、monitoring、生產遙測、備份與還原，以及一堆開發者通常不需要操心的問題。結果是放棄 MongoDB，把新服務移植到已經受支援的 MySQL 基礎設施上。
原文（buoys, not boundaries）：「Internally, we described our goal as creating “buoys, not boundaries.” Instead of drawing hard boundaries that everyone has to stay within, we put buoys that indicate deep areas of the channel where you’re safe and supported.」（L10998–11001）
原文（Etsy 是哲學決定）：「This was primarily a philosophical decision rather than a technological decision—they wanted both Dev and Ops to be able to understand the full technology stack」（L11025–11027）
原文（四類技術的判準之一）：「Are most inconsistent with our desired architectural outcomes (e.g. throughput, stability, security, reliability, business continuity)」（L10981–10982）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 這條與「小團隊自由選技術」是有張力的，書中沒有站在單邊：在某些情況下讓小團隊自選語言與框架才是最能達成組織目標的做法。判準永遠是「有沒有製造出只有一個團隊能修的瓶頸」。
- 執行方式應該是浮標而不是圍牆——畫死邊界會殺掉下一個能讓你贏的創新。要允許人們越過浮標，只要他們遵循組織原則。
- 這條的成敗前提是 Ops 真的有影響生產元件的權力，或至少有「不為不受支援平台負責」的權力；否則清單只是一張沒人理的紙。
- Etsy 是在一次近乎災難的旺季之後才做這件事——這種收斂通常需要一個足夠痛的事件當觸發點。
🔗 相關工具
- 單一共用原始碼儲存庫（收斂之後，共用函式庫與標準才有地方放）
- 改善閃電戰（退役舊技術這種沒人想排的工作，很適合排成一次閃電戰）
- 價值流圖（用來找出哪個技術正在拖慢流動）
- 不可變基礎設施（減少受支援組態的種類，是收斂的具體落地）
- DevOps手冊