自助服務平台

🎯 什麼情境該想到我

當你「開發團隊為了拿到環境或工具，得開單等別人手動處理」的時候。

⚙️ 怎麼用（步驟 / 公式）

意圖：由 Operations 打造集中化的平台與工具服務，讓任何 Dev 團隊都能自助取得所需能力，把時間花在替客戶做功能上，而不是張羅基礎設施。

做法要點：

• 平台內容：類生產環境、部署管線、自動化測試工具、生產遙測儀表板等。（L4189–4193）
• 自動化且隨選，不用開單：所有平台與服務理想上都要自動化、可 on demand 取得，不需要開發者開一張單、等人手動作業。否則 Operations 就會變成客戶的瓶頸——書中舉的反例是「我們收到你的需求了，手動設定那些測試環境需要六週」。（L4197–4201）
• 關鍵治理原則：幾乎不強制。書中寫得很直接——在幾乎所有情況下，我們不會強制內部團隊使用這些平台與服務；這些平台團隊必須去贏得並滿足內部客戶，有時甚至得和外部廠商競爭。透過建立這個有效的內部能力市場，才能確保做出來的平台是最容易、最吸引人的選擇，也就是 the path of least resistance（阻力最小的路徑）。（L4208–4213）
• 把它當真正的產品開發做：平台的客戶不是外部客戶，而是內部 Dev 團隊。像做任何好產品一樣，「大家都愛的平台」不會意外發生；客戶意識差的內部平台團隊做出來的工具，大家都會討厭並很快拋棄，改用別的內部平台或外部廠商。（L4230–4236）
• 平台承載組織的集體經驗：把 QA、Operations、Infosec 全體的累積經驗建進平台裡，例如共享版控倉庫附預先核可的安全函式庫、自動跑程式碼品質與安全掃描的部署管線、部署到已裝好生產監控工具的已知良好環境。（L4215–4228）
• 從已經在運作的東西擴散：持續尋找組織內已被廣泛採用的內部工具鏈，決定哪些適合集中支援、開放給所有人。書中判斷：拿已經在某處運作的東西擴大使用，比從零打造這些能力成功率高得多。（L4259–4263）
• 人力補位：指定 Ops（designated Ops）。當成本或人力稀缺讓我們無法在每個產品團隊都嵌入 Ops 工程師時，可以改為每個產品團隊指派一位聯絡人。Etsy 稱之為 designated Ops，中央 Operations 仍管理所有環境（不只生產，也包含 pre-production，以確保一致）。指定的 Ops 工程師必須理解六件事（L4324–4340）：
  1. 新的產品功能是什麼、為什麼要做。
  2. 就 operability、scalability、observability 而言它怎麼運作（強烈鼓勵畫圖）。
  3. 如何監控與蒐集指標，以確認該功能的進展、成功或失敗。
  4. 與過去架構和模式的任何偏離，以及這麼做的理由。
  5. 任何額外的基礎設施需求，以及使用量會如何影響基礎設施容量。
  6. 功能上線計畫（feature launch plans）。
• 聯絡人一樣要參加團隊 standup，把需求整合進 Operations 的 road map，並負責把資源競爭或優先序衝突往上升。（L4341–4346）

原文：「In almost all cases, we will not mandate that internal teams use these platforms and services—these platform teams will have to win over and satisfy their internal customers, sometimes even competing with external vendors.」（L4208–4210）

原文：「Without these self-service Operations platforms, the cloud is just Expensive Hosting 2.0.」（L4205–4206）

原文：「It’s okay for people to be dependent on our tools, but it’s important that they don’t become dependent on us.」（Netflix 工程工具總監 Dianne Marsh，L4241–4243）

🧪 我實際套用的紀錄

• （待填）

⚠️ 注意 / 什麼時候不適用

• 若組織規定只能用核准工具，可以先對少數團隊（例如轉型團隊）解除這個限制，用來實驗與發掘哪些能力真的能提升生產力。（L4254–4257）
• 反過來說，每個產品團隊各選各的工具鏈也有代價：工程師換團隊就得重學一整套技術，等於把團隊目標放在全域目標之上。共享服務的價值有一部分就是標準化。（L4248–4252）
• 指定 Ops 能支援比嵌入式 Ops 更多的產品團隊，但如果聯絡人被攤得太薄、拖累產品團隊達標，就得減少每人支援的團隊數，或臨時把 Ops 工程師嵌進特定團隊。目標是「Ops 不成為產品團隊的約束點」。（L4348–4353）

🔗 相關工具

• 工具-部署管線與持續交付（部署管線通常就是平台上最重要的那個自助服務）
• 專責轉型團隊（轉型團隊常是第一個被解除工具限制、用來試驗新平台能力的對象）
• 康威定律作為設計工具（平台團隊與產品團隊的邊界，本身就是康威定律的設計題）
• 工具-找出並管理約束點（自助服務的目的就是讓 Ops 不再是約束點）
• DevOps手冊