像 Google 這類網路公司能以遠快於傳統公司的節奏推出新產品與功能。SRE 的角色是在不犧牲穩定性的前提下加速變更。Google 為此設置了專門的 Launch Coordination Engineer（LCE） 團隊。

開場案例：Keyhole（為 Google Maps / Earth 提供衛星圖）平日數千 QPS，2011 年聖誕夜（與 NORAD 合作的 Track Santa 活動）達到 25 倍尖峰、超過 100 萬 QPS——這類「硬截止 + 大幅流量未知」就是 LCE 的舞台。

上線是什麼#

「Launch」= 引入使用者可見變更的任何新程式碼。

Google 高速變更的反面就是需要一套經過深思的上線流程——LCE 就是答案。

LCE 的職責#

LCE 在服務生命週期的多個時點審查。職責包含：

• 在新產品 / 服務上線前查核
• 對新接 SRE 支援的服務做 service audit
• 教育開發者最佳實踐、整合內部服務的方式

為什麼需要專責團隊#

專責 LCE 帶來的優勢：

• 跨產品經驗的廣度
• 跨職能視角（SRE、研發、PM、行銷）
• 客觀性：作為非派系顧問，介於各方之間

LCE 是 SRE 角色，因此優先順序仍是可靠性——其他誘因結構的公司可能需要不同設計。

良好上線流程的標準#

Google 十年磨出的標準：

• 輕量：對開發者友善
• 強韌：抓得到明顯錯誤
• 徹底：重要細節一致、可重複
• 可規模化：能處理大量簡單上線與少量複雜上線
• 可調整：對新類型上線也有效

對策：

• 簡單：把基本盤做對，不為每個邊角設計
• 高接觸：經驗豐富的工程師按需客製
• 快速常見路徑：常見上線（如新增語言）有極簡流程

工程師會繞過他們覺得過重的流程——尤其在 crunch mode。LCE 必須持續優化「成本 / 效益」平衡。

上線檢查清單#

檢查清單像航空起飛清單或手術清單——降低疏漏、確保一致。

但清單會不斷膨脹。Google 曾要求新增題目必須經 VP 批准。

維持小巧的原則：

• 每個問題的重要性都要有依據（最好是過去災難）
• 每個指示要具體、實際、可達成

涵蓋的主題#

• 架構與依賴：請求流、是否誤用共享基建
• 整合：DNS、LB、監控、機器配置
• 容量規劃：launch 尖峰可能比預估高 15 倍；分區域漸進上線
• 失敗模式：單點故障、依賴不可用、DoS、降級模式
• 客戶端行為：自動同步、心跳——必須指數退避 + jitter
• 流程與自動化：手動流程必須文件化，任何成員能執行
• 開發流程：版控、release branch、設定也納入版控
• 外部依賴：第三方程式碼 / 服務 / 資料；事前規劃緩解措施
• Rollout 計畫：複雜上線需要編舞，含應急方案

上線常用技術#

漸進式 rollout#

Google 幾乎沒有「按鈕全球上線」這種事。

• 先一兩台「canary」觀察
• OK 後一整個 DC
• 再全球
• 自動化工具觀察 canary 一段時間，異常即自動回滾

Android app 升級也以「漸進式安裝百分比」執行——既可觀察伺服器影響也能早期偵測問題。

「邀請制」「按日限制註冊數」也是漸進式 rollout 的一種。

Feature Flag 框架#

不必為所有變更走重磅 launch 流程——尤其 UI 微調或早期實驗。需求：

• 多個變更平行 rollout，每個只到少數使用者 / DC
• 從 1% 漸進到 10%
• 依使用者 / session / 物件 / 位置路由
• 失敗時自動「不影響使用者」回退
• 每個變更可獨立立即關閉
• 量測每個變更對使用者體驗的影響

兩大類：

• 純 UI 改進（HTTP payload rewriter 於前端）
• 任意 server-side / 業務邏輯（依使用者 ID / 物件 ID 路由到不同伺服器）

處理失序的 client 行為#

Client 把 60s 同步改成 600s 同步 → 流量 ×10。Retry 不當會把過載服務雪上加霜。

必要設計：

• 指數退避 + jitter（隨機化延遲）：避免「重試浪潮」與「夜晚 2 點同步爆量」
• 區分可 retry 與不可 retry 錯誤（4xx 不該 retry）
• server-side 可遙控 client：透過設定檔開關功能、調整 sync / retry 頻率
• 預先把功能放進 app（dormant），由 server 啟用 → 出錯時直接關掉、不必重發版本

過載行為與壓力測試#

真實服務的負載不是線性——快取效應、JIT 暖機讓低負載時反而比較慢；接近過載時常突然失控。

範例：某服務在 backend 錯誤時記 debug log，過載時 log 本身比正常處理還貴 → 進入 GC thrashing → 整服務 freeze。

因此壓力測試是上線的必備——既為可靠性，也為容量規劃。

LCE 的演進#

Google 早期由「Launch Engineers」這個志願小隊撰寫起飛清單；隨服務複雜化於 2004 年成立 LCE 全職團隊。3.5 年內一名 LCE 跑了 350 場 launch，5 人團隊全期超過 1,500 場。

新進 LCE 約需半年訓練；後期把「低風險 launch」（無新 binary、流量增量 < 10%）分流走極簡流程——到 2008 年 30% 的審查屬此類。

LCE 解決不了的問題#

一些問題超出 LCE 範圍，需要全公司的長期投入：

• 規模轉變：用量超出預期兩個量級時，需要重新架構並遷移使用者
• 運維負擔成長：告警噪音、部署複雜度逐年增加，需主動清理（呼應第 5 章 50% 上限）
• 基建擾動（churn）：底層 cluster / 儲存 / LB 變動 → 服務團隊「跑很快才能留在原地」；解法是「churn reduction policy」——基建團隊釋出向後不相容變更時必須同時提供自動遷移工具

這些需要更好的平台 API、framework、CI / CD 自動化與標準化。

結語#

對於每 1–2 年產品開發者翻倍、服務規模億級的公司，LCE 這類角色能在「速度」與「可靠」間建立紀律性的橋樑。

Google 十年來累積的清單、流程、心法——希望能啟發其他面對相似挑戰的組織。