美國FDA新藥審批流程被公認爲世界上最完備，最科學的程序，本文將從這個審批流程出發，類比互聯網公司的分級發佈策略，希望能夠更好的幫助大家理解。
新藥臨牀試驗的”黃金標準“
美國FDA新藥審批流程被公認爲世界上最完備，最科學的程序。目前的標準是從1962年開始實施，被稱爲是新藥臨牀試驗的”黃金標準“。其新藥審批流程整體如下圖所示，在此，我們重點介紹臨牀試驗階段的試驗規模和試驗方法
-
臨牀一期實驗目標是安全性，允許小範圍的人羣試驗，通常招募20-100個健康的志願者，付錢給他們，讓他們服用該藥物，嚴密監測可能的毒副作用，耗時1年左右。如果毒副作用在可以接受的範圍內，就可以申請二期實驗。
-
臨牀二期實驗目標是有效性，通常招募100-500個該藥物針對的病人，通過隨機分組雙盲對照試驗（病人被隨機編入實驗組和參照組，前者吃藥，後者吃安慰劑），耗時1-2年。如果藥物對小範圍人羣有效，且毒副作用在可以接受的範圍內，就可以申請三期實驗了。
-
臨牀三期實驗目標是在全國範圍內證明有效，通常招募1000-5000個該藥物針對的病人，耗時1-4年，通過大樣本，隨機雙盲，多國多地區多中心進行試驗，如果試驗結果比較滿意，公司要向FDA遞交新藥申請NDA。
-
非嚴格意義的臨牀四期實驗，藥物投放市場之後，讓成千上萬的人使用後，還需要嚴密監測可能的副作用，隨時向FDA報告。
即使如此，仍然有不少人指責FDA審批藥品的速度太快！比如，止疼藥Vioxx和治療糖尿病的新藥Rezulin就曾在上市後不久發現了新問題，被召回。另一方面，那些身患絕症的病人又在抱怨FDA速度太慢，貽誤時機。不少人實在等不及了，便四處打聽，要求加入三期臨牀試驗，充當志願者。
互聯網公司的分級發佈策略
藍綠部署
發佈新版本的時候，創建一套新的集羣部署新版本，然後逐漸將流量從舊版本切到新版本的集羣上，如果新版本有異常，則迅速切回到舊版本。待新版本穩定後，銷燬舊版本的集羣即可。
金絲雀部署
金絲雀部署和藍綠部署有點像，但升級的策略改爲階段性的進行，而非一次性從藍色版本切換到綠色版本，從而降低風險。
對照組
基於金絲雀部署的前提下，還可以增加對照組，如下圖示，當進行V2.0版本升級時，創建Canary分組，並且創建了一個同等機器規模的Baseline分組（使用V1.0），此時，兩者集羣規模一致，僅版本不同，可以更好的對比新舊版本的效果。如果沒有對照組的話，Canary分組的一些業務指標直接和Production分區的業務指標進行比對，可能會引入較多的噪音，導致比對困難。
Fackbook的發佈策略
Fackbook發佈策略的亮點在於對小流量用戶的選擇，從下圖可以看到，新版本發佈後，部署的集羣僅對Facebook員工可見，只有在通過了內部員工驗證後，纔會開始對外部用戶進行小流量
應用商店的灰度分佈策略
APP Store 分階段發佈策略
APP Store的分階段發佈策略主要內容是，新版本更新在 7 天內按百分比發佈給已打開自動更新的 macOS 或 iOS 用戶（根據用戶的 Apple ID 隨機挑選）。同時，所有下載了 App 的用戶可隨時在 App Store 中手動更新新版App。如果發現新版本存在問題，可以隨時暫停分階段發佈，分階段發佈累計最多可暫停30天，暫停次數不限。
筆者猜測該策略下存在的問題（因條件有限，未能一一證實）：
-
灰度僅僅針對老用戶而言，新用戶下載默認都是新版
-
根據用戶的Apple ID隨機挑選，而不能針對硬件類型（IPAD還是Iphone），設備類型（Iphone11還是Iphone8），系統版本，軟件版本，自定義用戶標籤（付費用戶）等
-
灰度發佈的版本一旦出現問題是無法回滾的，在修復版開發完成重新發布審覈上架之前，已經更新的用戶只能繼續使用bug版本，或者是將舊版本的程序以新版本號進行發佈
Google Play Store 分階段發佈策略
Google Play Store 的分階段發佈策略（staged rollout）給用戶的靈活性較大，默認策略如下圖所示，但用戶可以對分階段發佈策略進行修改，從而滿足自己的需求。
效果檢查
只有灰度而沒有效果檢查，這樣就無法發現灰度下的異常，那麼只能是不斷增加各個階段的時間間隔來被動等用戶反饋問題，長時間下去，必然會導致研發人員對發佈效率的不滿。因此，需要建立並逐步完善效果檢查機制，下圖是服務端和客戶端兩類場景下的效果檢查的截圖，供大家參考。
效果檢查需要和灰度發佈聯動起來，在一次灰度發佈完畢後，如果效果檢查通過，且停滯時間也達到要求，那麼就可以自動化的進行下一階段的發佈工作。反之，如果效果檢查不通過，則應該立即終止發佈過程並回滾版本，從而避免較大的業務影響。
全網客戶端分級發佈實戰
樣本選取
-
硬件：選取所有規模超過1000臺的機型
-
操作系統：選取所有規模超過1000臺的操作系統版本
-
內核：選取所有規模超過1000臺的內核版本
-
備機池：選取備機池所有的機器
-
IDC：覆蓋所有IDC機房
-
業務：覆蓋所有核心業務線
-
基礎設施：覆蓋所有基礎設施
發佈階段
第一階段：備機池，備機池的機器常態下處於空閒狀態，僅部署離線計算任務。樣本豐富度上雖然不盡如人意，但因爲規模較大，且對線上完全無損，因此非常適合作爲敢死隊角色。從實際效果上看，在該階段，我們攔截了大量的異常，從而避免線上遭受損失
第二階段：測試機，之所以選取測試機集羣，是因爲整個公司的測試機規模很大，更爲重要的是測試機部署了線上絕大部分應用場景，在樣本的豐富度上幾乎等同於線上環境了。且測試機的故障，相較於線上故障來說，嚴重程度會低一些
第三階段：樣本補齊，對於備機池和測試機無法覆蓋的樣本，則需要從線上隨機抽樣進行覆蓋，確保樣本的覆蓋度達到要求，在實際抽樣的時候，會盡量選取非核心業務的機器。樣本選取的數量應該佔總體數量的0.5%到1%爲宜
第四階段：自運維集羣升級，在確保程序能穩定運行在各類樣本後，就開始正式的升級流程了，首先需要將自身的集羣進行升級，從而能夠在第一時間發現可能存在的問題
第五階段：分地域升級，需要遵循以下原則：
-
按照地域進行升級，華南----華中----華北
-
同一地域內，按照故障域逐個升級，假設AZ1+AZ2是一個故障域，AZ3+AZ4是一個故障域，則必須是升級完畢一個故障域的所有AZ後，才能升級另外一個故障域
-
同一地域內，按機房建設順序，新機房先升級，老機房後升級
發佈速度
發佈的過程中有如下要求：
-
非工作日不進行升級
-
每階段均從工作日的上午開始發佈
-
所有階段執行統一的發佈速度，不進行特殊處理，避免併發度錯誤而導致故障
-
併發度爲串行升級，整體耗時控制在兩週內完成
-
第一次發佈，整體耗時不低於一個月時間
異常聯動
一旦發現升級效果不符合預期，則系統會自動終止升級操作，並視情況決定是否自動回滾。如果硬性指標如機器存活數量出現波動，則會暫停升級，等待人工介入處理。
參考文章