產品完成開發之後，當然就要推出去。推出去之前，有些產品需要進行風險控製。比如，支付類的產品經常會做發布前評估（Pre-launch Review）。
所謂發布前評估，就是在發布之前，根據具體的產品或者該次發布的特點，做一些諸如發布策略、需監測的核心數據、產品演示、核心算法改變等方麵的討論。我在做產品討論的時候，要求參會的人員都思考這個問題——“如果這次發布出現大問題的話，可能會是什麼？”主要目的是在發布之前思考可能會出現失誤的節點，如果是大風險，做一些必要的防護措施；如果是小風險，心裏要清楚自己在冒這個險，準備好一旦出問題該如何補救。另外，由於Facebook發布的產品比較多，經常出現互相影響的情況，做發布前評估可以讓大家知道什麼產品即將在什麼時候推出去。
對於發布前評估，我有這樣一些經驗。
1.要短。不應超過半小時。做產品預覽是需要成本的，不能因為這件事而產生麵麵俱到、追求完美的副作用。
2.形式可以多樣。成本比較高的會議形式，比較適合大的或者新產品的發布。也可以是成本比較低的郵件方式，比較適合改錯（Bug Fix）或者產品改進（Product Improvement）。甚至可以是幾個技術人員口頭聊聊，適合於小的改錯（Minor Bug Fix）。
3.人員選擇可以多樣。如果是產品發布，一般找與該產品關聯的相關產品的人員來參與。如果是郵件，會發相關列表。由於涉及人員的時間成本，選擇時盡可能隻找有可能會提出建議的人。
4.內容可以多樣。前麵提到，根據產品的特性或者代碼改變的特點，討論的內容可以不同。如果是發布策略，一開始先針對哪些類型的用戶之中百分之幾的人發布產品，然後觀察哪些核心數據能夠得知產品成敗與否。如果是產品演示，在有限時間內展示哪些核心功能，這些功能的上遊和下遊產品分別是什麼，和他們的集成以及團隊的溝通做得如何。如果是核心算法的一些改變，要把核心的改變解釋清楚。
不過，不管你在產品發布之前做了什麼樣的準備，都不可能100%確保發布是安全的。大家要坦然麵對這一點，也不需要在發布之前做出極端的準備措施。
但不能藐視發布過程中的風險，一種發布工程的做法是閥門控製式的灰度發布（Gated Launch），就是有所控製地選擇發布的人群及其比例。在Facebook有一個比較完善的工具，可以允許在產品源代碼中嵌入一行灰度控製代碼，這樣就可以很容易地控製該產品的發布對象。比如第一次發布時隻讓1%的美國用戶使用這個新功能，如果沒有什麼大問題，接下去再擴大到5%、10%、50%、90%、100%之類的，或者擴展到其他國家。具體的擴展策略根據產品來決定，並沒有嚴格的規定。不管如何，目的就是在盡可能短的時間內將產品安全地發布到所有Facebook用戶麵前。灰度發布工具允許控製的屬性很多，比如年齡、國家、城市、性別、語言、學曆、工作單位等，還有這些屬性之間的條件並列，發布者都可以控製。比如你可以把產品發布到“當前居住在舊金山的會講中文的女大學生”。
灰度發布是控製發布的範圍和速度，但如何才能得知某一階段產品發布的質量，何種狀況下才提高灰度發布的範圍呢？隻有通過數據監測來判斷發布狀態。
需要監測的有兩類數據。
一類數據反映當前的係統狀態，比如訪問總量、訪問成功量及其占總量的比例、致命範圍錯誤的量和比例、訪問速度、出現最多的錯誤類型統計，等等。這些數據的統計和展示都應該是實時的，這樣才能確保一旦發生問題，能夠在最短的時間內發現並采取措施。如果問題僅局限於新功能之中，由於是有控製的灰度發布，可以馬上關掉或者降低發布範圍，使損失得到控製。但如果新功能對已有的係統帶來了致命的問題（Critical Bug），導致其他核心功能無法使用，那危害性就大了。我就曾經在發布禮物商店（Gift Shop）的一個功能時導致Facebook無法訪問達半個小時。當時還沒有灰度發布工具，否則隻需要在這個工具上點一下鼠標，就能關掉新的功能，盡可能減少損失。