「上線」不只是把新 binary 推上去——只要引入使用者可見的變更就算。這類事件常伴隨硬截止與大幅未知的流量，是風險最高的時刻。與其讓每個團隊各自摸索，不如把上線當成一件需要被協調、被檢查清單化的高風險工程，並交給一支懂跨產品經驗的專責團隊。
🧠 Intuition
IMPORTANT
「Launch」= 引入任何使用者可見變更的新程式碼。高速變更的反面，就是需要一套經過深思的上線流程——這正是 Launch Coordination Engineer（LCE） 存在的理由：在不犧牲穩定性的前提下加速變更。
- LCE 在服務生命週期的多個時點介入：新產品／服務上線前查核、新接 SRE 支援的服務做 service audit、教育開發者最佳實踐與內部服務的整合方式。
- 為什麼要專責團隊而非各團隊自理：專責角色帶來跨產品經驗的廣度、涵蓋 SRE／研發／PM／行銷的跨職能視角，以及作為非派系顧問的客觀性。
- LCE 本身是 SRE 角色，因此優先順序仍是可靠性；換一種誘因結構的公司，可能需要不同設計。
- 良好上線流程要同時輕量、強韌、徹底、可規模化、可調整——把基本盤做對、常見路徑走極簡流程、複雜案例才由資深工程師高接觸客製。
- 上線常用的技術（漸進式 rollout、feature flag、過載壓測等）只是上線工具箱的一部分；LCE 的獨特價值在於把這些工具編排進一套可重複的協調流程。
⚖️ Tradeoffs
每團隊各自摸索上線 vs 專責 LCE + 檢查清單
- 各團隊自理：貼近自身脈絡，但缺乏跨產品的災難經驗、也缺客觀第三方，重要細節容易在 crunch mode 中漏掉。
- 專責 LCE + 檢查清單：清單像航空起飛清單或手術清單，降低疏漏、確保重要細節一致且可重複；LCE 補上廣度、跨職能視角與客觀性。
- 代價與風險：工程師會繞過他們覺得過重的流程——尤其在趕工時。LCE 必須持續優化「成本／效益」平衡，否則流程形同虛設。
徹底的大清單 vs 維持小巧的清單
- 清單越徹底越抓得到明顯錯誤，但清單會不斷膨脹；Google 曾要求新增題目必須經 VP 批准來煞車。
- 維持小巧的兩條原則：每個問題的重要性都要有依據（最好對應過去的災難）；每個指示要具體、實際、可達成。
- 涵蓋主題橫跨架構與依賴、整合（DNS／LB／監控）、容量規劃（launch 尖峰可能比預估高 15 倍）、失敗模式、客戶端行為、流程與自動化、開發流程、外部依賴、rollout 計畫——但每一項都得為自己的存在辯護。
🔑 Takeaways
- 「上線」是引入使用者可見變更的高風險事件；把它當成需要被協調的工程，而非各團隊各自為政，才能在速度與可靠間建立紀律。
- 上線檢查清單是可重複的核心機制——用它抓明顯錯誤、確保細節一致；但要靠「重要性有依據、指示可達成」來對抗清單膨脹，並持續平衡成本效益以免被繞過。
- LCE 解決不了的問題需要全公司長期投入：規模轉變（用量超預期兩個量級要重新架構）、運維負擔成長、以及基建擾動（解法是要求基建團隊釋出破壞性變更時同時提供自動遷移工具）。
No notes yet — jot your takeaways or Q&A here.