🎯 什麼情境該想到我
當你「新功能有明顯的發布風險，想在對使用者可見之前先用真實生產流量把它壓過一遍」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：把全部功能都部署到生產環境，但對客戶完全不可見，然後在「還看不到」的狀態下用真實生產流量測試它。
做法要點：
- 對大型或高風險的變更，書中說常常在正式上線前就這樣做上數週，好在預期的類生產負載下安全地測試。
- 適用對象舉例：新的搜尋功能、帳號建立流程、新的資料庫查詢。
- 具體手法：所有程式碼都已在生產、新功能維持停用，然後修改使用者 session 的程式碼去呼叫新函式——但不把結果顯示給使用者，只是記錄（log）或直接丟棄（discard）。
- 逐步加壓的節奏：先讓 1% 的線上使用者對新功能做隱形呼叫，觀察它在負載下的行為；找到並修好問題後，再逐步提高呼叫頻率與參與的使用者數，藉此安全地模擬類生產負載。
- 真的要上線時，逐步把功能推給小群客戶，一發現問題就中止發布，把「給了又收回」的客戶數降到最低。
- 2009 年 John Allspaw 任 Flickr 維運副總時寫給 Yahoo! 高層說，這個流程「讓大家的信心高到近乎冷漠」的程度——就負載問題的恐懼而言。
Facebook Chat 案例（2008）：
- 當時 Facebook 每日活躍使用者超過 7,000 萬，Chat 是史上最大的技術工程之一，耗時將近一年完成（用到 C++、JavaScript、PHP，以及後端首次採用 Erlang）。
- 這一整年間，Chat 團隊把程式碼簽入版本控制，每天至少部署到生產一次。功能一開始只有 Chat 團隊看得到，後來開放給全體內部員工，但透過 Gatekeeper 對外部使用者完全隱藏。
- 黑啟動的做法：每一個 Facebook 使用者 session（瀏覽器裡跑的 JavaScript）都載入了一個測試載具（test harness）——Chat 的 UI 元素是隱藏的，但瀏覽器會持續送出隱形的測試聊天訊息，打到早已在生產環境上的後端 chat 服務，於是能在整個專案期間模擬類生產負載，遠早於對客戶發布之前就找出並修好效能問題。
- 結果是每一個 Facebook 使用者都成了大規模負載測試計畫的一部分。
- 最終發布只需要兩個步驟：(1) 修改 Gatekeeper 組態設定，讓 Chat 對一部分外部使用者可見；(2) 讓使用者載入新的 JavaScript，渲染 Chat UI 並停用隱形測試載具。出錯的話就把這兩步反向執行。
- 上線當天出奇順利平淡，像是一夜之間從零擴展到 7,000 萬使用者。發布時是漸進開放：先全體內部 Facebook 員工 → 再 1% 的客戶 → 再 5% → 以此類推。
原文：「For example, we may have 1% of our online users make invisible calls to a new」（L6770，接 L6771「feature scheduled to be launched to see how our new feature behaves under load.」）
原文：「seventy million users overnight is to avoid doing it all in one fell」（L6858，Letuchy 語，全句為「The secret for going from zero to seventy million users overnight is to avoid doing it all in one fell swoop.」L6857–6859）
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 黑啟動建立在功能開關之上——沒有 功能開關 就沒有「部署了但不可見」這件事。
- 隱形呼叫會真的消耗生產資源，所以才要從 1% 起跳逐步加壓；一開始就開太大等於自己 DDoS 自己。
- 只 log 或丟棄結果的設計要小心副作用（寫入、計費、寄信這類不可逆操作不能盲目黑啟動）。
- 書中把數週的黑啟動定位在「大型或高風險變更」，小改動不需要付這個成本。
🔗 相關工具
- 解耦部署與發布（黑啟動是把「部署」與「發布」拉開到極致的做法）
- 功能開關（黑啟動的前提機制，Facebook 用的是 Gatekeeper）
- 金絲雀發布（同樣逐步放大受眾，但是在功能已對使用者可見之後）
- A-B測試與假設驅動開發（黑啟動之後接上遙測，就能在發布前驗證業務假設）
- 工具-部署管線與持續交付（每天至少部署一次生產，是 Chat 團隊撐住一年黑啟動的基礎）
- DevOps手冊