从美国 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 后，才能升级另外一个故障域
-
同一地域内，按机房建设顺序，新机房先升级，老机房后升级
发布速度
发布的过程中有如下要求：
-
非工作日不进行升级
-
每阶段均从工作日的上午开始发布
-
所有阶段执行统一的发布速度，不进行特殊处理，避免并发度错误而导致故障
-
并发度为串行升级，整体耗时控制在两周内完成
-
第一次发布，整体耗时不低于一个月时间
异常联动
一旦发现升级效果不符合预期，则系统会自动终止升级操作，并视情况决定是否自动回滚。如果硬性指标如机器存活数量出现波动，则会暂停升级，等待人工介入处理。
参考文章