写点什么

从美国 FDA 新药审批制度看分级发布最佳实践

2019 年 9 月 13 日

从美国 FDA 新药审批制度看分级发布最佳实践

美国 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 后,才能升级另外一个故障域

  • 同一地域内,按机房建设顺序,新机房先升级,老机房后升级


发布速度

发布的过程中有如下要求:


  • 非工作日不进行升级

  • 每阶段均从工作日的上午开始发布

  • 所有阶段执行统一的发布速度,不进行特殊处理,避免并发度错误而导致故障

  • 并发度为串行升级,整体耗时控制在两周内完成

  • 第一次发布,整体耗时不低于一个月时间


异常联动

一旦发现升级效果不符合预期,则系统会自动终止升级操作,并视情况决定是否自动回滚。如果硬性指标如机器存活数量出现波动,则会暂停升级,等待人工介入处理。


参考文章


部署策略对比:蓝绿部署、金丝雀发布及其他


CanaryRelease


2019 年 9 月 13 日 08:0011734

评论 4 条评论

发布
用户头像
每家公司或者公司内较为独立的成规模的业务,都要跑出自己的变更节奏,什么时间该干什么事情,这应该是非常明确的。例如说,每周二和每周四上线,且每次上线的时间点固定就是xxx时间,然后进行倒推,你什么时候提测,什么时候提交代码,什么时候做code view,基本上都可以慢慢的形成一个固定的节奏和预期。这次如果我delay了,我也清楚下次什么时候可以上线,真要出现了问题,我们也可以进行快速回滚,回滚到哪个版本也比较清晰和明确。
2020 年 06 月 23 日 15:25
回复
用户头像
大家经常会讨论说,升级完毕一个机房后,对第二个机房,是直接全量升级,还是说按照单台,多台,全量的顺序升级。
从经验的角度看,升级单个机器,主要是为了检查一些基本问题,程序是否可以正常工作,有没有coredump,端口是否正常等等较为基础的问题,毕竟一台机器,也难以发现一些系统整体层面的问题,除非说太明显了,太低级了。
再加上,其实,每一个分组都是要消耗时间的,因为每一个分组都需要检查,检查都需要数据的积累和计算,这都是时间,因此,如果在第一个机房之后的所有机房还需要有单台的升级策略,那么整体的升级耗时将会增加很多,我个人并不是特别建议
建议的灰度方式:线下环境->线上小流量机房(单机,多台,全量)->线上每个机房(按照并发度进行实例升级)->达成全量升级完毕,并且在每个升级间隔,是需要做效果检查的,而不是等着,效果检查不一定要拦截变更,虽然这是理想情况。
展开
2020 年 06 月 23 日 15:19
回复
用户头像
还需要将分级发布的并发度设置标准讲清楚,就是任何时候,并发度都不能超过集群整体的冗余度。
以100个机器的集群为例,假设集群的冗余度为20%,那么如果升级的并发度设置为25%,如果本次升级出现故障,那么服务必然会受到影响。因此升级的并发度必须小于冗余度。
2020 年 03 月 23 日 11:02
回复
用户头像
FDA认证,还有一个比较好的图片参考:https://www.astrazeneca.com/our-focus-areas/pearl-therapeutics.html
2020 年 01 月 09 日 20:54
回复
没有更多了
发现更多内容

大厂Offer收割机!八大核心思维导图+1000页核心知识梳理

Java成神之路

Java 程序员 架构 面试 编程语言

总结近期腾讯+阿里+百度Java岗高频面试题,提问率高达98%,看到这篇文章基本offer稳了

Java架构之路

Java 程序员 架构 面试 编程语言

连肝26天,熬夜拜读349页阿里面试通关手册,成功闯进字节跳动

互联网架构师小马

Java 编程 面试 求职 找工作

萌新不看会后悔的C++基本类型总结(二)

花狗Fdog

互联网信贷风险与大数据 风险管理&信贷准入

张老蔫

28天写作

架构大作业2

J

【金三银四】这才是打开Java面试的正确方式,吃透这份【Java面试手册】offer稳了

云流

Java 编程 面试

Wireshark数据包分析学习笔记Day3

穿过生命散发芬芳

Wireshark 数据包分析 3月日更

惊险!阿里面试被问到高并发系统设计,还好面试前在Github偶然刷到一份高并发速成笔记,侥幸入职阿里!

Java王路飞

Java 程序员 面试 高并发 阿里

架构大作业1

J

区块链药品溯源解决方案-区块链技术监管医药溯源

13530558032

《不看后悔》38个JVM精选问答,让你变成专家

云流

Java 架构 面试 JVM虚拟机原理

正则表达式.01 - 元字符

insight

正则表达式 3月日更

阿里面经最新分享:Java面试指南/成长笔记(金三银四程序员必备)

比伯

Java 编程 程序员 架构 面试

刚刚毕业的我怀着激动和忐忑的心情,去了蚂蚁金服四面!

Java成神之路

Java 程序员 架构 面试 编程语言

智慧党建系统开发,智慧组工平台建设

13530558032

【回溯算法】借助最后一道「组合总和」问题来总结一下回溯算法 ...

宫水三叶的刷题日记

LeetCode 数据结构与算法 面试数据结构与算法

饿了么刚给我确认了p7的职位,对自己的经历,做一个面试总结。

Java架构之路

Java 程序员 架构 面试 编程语言

2021普通Java程序员如何在行业中脱颖而出?阿里进阶架构师不传之秘终于开源!

程序员小毕

Java 程序员 架构 面试 分布式

微信团队分享:微信直播聊天室单房间1500万在线的消息架构演进之路

JackJiang

微信 架构设计 即时通讯

mock 请求分发

blueju

JavaScript React Mock umi umijs

开源镜像仓库Harbor的镜像安全

运维研习社

Docker Harbor 漏洞扫描 镜像安全 私有仓库

简单工厂模式、工厂模式、抽象工厂模式比较

良知犹存

设计模式

一个程序员的自我修养不应该只是“吊打面试官”而已!

Java成神之路

Java 程序员 架构 面试 编程语言

区块链电子合同应用平台-助力企业数字化转型

13530558032

Flutter 2 来了

SamGo

flutter

两会热词“区块链”,打开传统溯源的一扇大门!

源中瑞-龙先生

区块链 两会

LeetCode题解:714. 买卖股票的最佳时机含手续费,动态规划,JavaScript,详细注释

Lee Chen

算法 LeetCode 前端进阶训练营

Elasticsearch Index Types and Mappings

escray

elastic 七日更 28天写作 死磕Elasticsearch 60天通过Elastic认证考试 3月日更

用c++创作一个简单小游戏

张鹤羽粑粑

28天写作 3月日更

恋物志(二):独居者的智能生活指南

脑极体

云原生场景下企业API 网关选型及落地实践

云原生场景下企业API 网关选型及落地实践

从美国 FDA 新药审批制度看分级发布最佳实践-InfoQ