3问详解灰度发布,让运维拥抱变更 | IDCF
DevOps
共 4893字,需浏览 10分钟
·
2021-10-13 22:10
来源:运维之路
作者:彭华盛
导读
what:什么是灰度发布?——灰度发布概念、主要组成部份。 why:为什么要有灰度发布?——灰度发布的背景、多角度分析作用。 how:如何实现灰度发布?—— 灰度发布主要步骤、架构方案选择、常见的部署方案、案例介绍。
谁说应用变更只能晚上发布,白天发布可以有。 谁说运维不知道应用上线后性能怎么样,性能怎么样可以知道。 谁说新应用上线后会所有客户都是小白鼠,可以让少数的人先尝鲜。 谁说测试的重点在功能测试,用户体验测试与交互评估也可以有。 谁说应用变更回切方案太复杂,无缝切换部署可以有。
缩小可能风险的波及范围,比如新推产品或功能,容易出现用户体验不爽或者性能低下等不足; 尽早吸收用户的反馈,产品不必100%完美才推出,可以先让部分用户试用,分析用户行为或汲取用户反馈后,再采取快速步骤改进产品; 提高产品的最终质量,分流的灰度发布等于除了行内测试外再扩大测试人群的范围,我们让更多的忠实用户直接参与测试,让更多双眼睛来发现隐藏的缺陷; 程序升级更加有序和自动化,以往如果升级涉及复杂的数据变动,很有可能需要停机处理,但如果是以分流发布的方式,逐批更新升级,或由用户触发,就可以实现不停机处理; 通过无缝部署、分流等技术方案,运维人员可以在白天发布应用,大大解放了运维人员的生产力。
一、什么是灰度发布?
灰度发布是应用发布部署的一种方式,因其可尽早的发现问题的同时降低整体发布的风险的特点,己成为互联网产品发布常用的一种方式,那么什么是灰度发布呢?百度百科的概念是在黑和白之间平滑过渡的一种产品发布方式。
用户标识:用户标识用于区分用户,辅助数据统计,保证灰度发布过程中用户体验的连贯性(避免用户在新旧版本中跳变,匿名Web应用比较容易有这个问题)。匿名Web应用可采用IP、Cookie等,需登录的应用可直接采用应用的帐号体系。 目标用户选取策略:选取哪些用户先行体验新版本,是强制升级还是让用户自主选择等。可考虑的因素很多,包括但不限于地理位置、用户终端特性(如分辨率、性能)、用户自身特点(性别、年龄、忠诚度等)。对于细微修改(如文案、少量控件位置调整)可直接强制升级,对于类似新浪微博改版这样的大型升级,应让用户自主选择,最好能够提供让用户自主回滚至旧版本的渠道。 数据反馈:灰度发布的本质实际上是让用户帮你测试,但是用户不是专职的测试,所以他一般不会主动报bug(除非遇到大问题,但是当用户主动报bug的时候,也就是你收到投诉了,这个应该不是你想看到的),但是有用户投诉不是最坏的,最坏的是用户不投诉,或者新产品为用户提供了有力的漏洞,这时候如果监控不到位。那迎接你的将是毁灭性的回滚和修复!所以灰度发布要有安全隔离,完善的监控,并且有友好的目标客户群 用户数据反馈在得到用户允许的前提下,收集用户的使用新版本应用的情况。如客户端性能、客户端稳定性、使用次数、使用频率等。用于与旧版本进行对比,决策后续是继续扩大新版本投放范围还是回滚。服务端数据反馈:新版本服务端性能、服务端稳定性等,作用与用户数据反馈类似。 新版本回滚策略:当新版本灰度发布表现不佳时,应回滚至旧版本。对于纯粹的Web应用而言,回滚相对简单。主要难点在于用户数据的无缝切换。对于客户端应用,如果期待用户自行卸载新版本另行安装旧版本,成本和流失率都太高。可以考虑通过快速另行发布新版本,利用升级来“回滚”,覆盖上次灰度发布的修改。
二、为什么要灰度发布?
每年都会有大大小小的许多应用变更、架构改造等,这些变更有这样一些特点:
新产品或大项目初次发布时; 应用开发存在大量bug,但业务赶着上线; 业务策略不明确拿不准时; 面向特定用户群体时; 大范围升级时 ……
三、如何实现灰度发布?
3.1 灰度发布前需考虑的两个问题
用户策略:用户量规模(水平)、用户群属性(垂直); 产品策略:功能覆盖、运营规划实验; 数据策略:数据模型、行为分析 ; 部署策略:回滚、新旧系统并行 。
分流规则设定 数据分析系统 软件配置 软件部署
定义策略:确定分流的目的、放量的规模、递增的频率、回滚的策略等; 筛选用户:确定分流访问的用户特征,定义规则或导入名单; 访问分流:技术支撑,通过DRE(分流发布引擎)重定向用户请求; 部署应用:打包部署单独的分流环境; 体验反馈:收集分流用户试用后的建议反馈,修正产品设计。
分流策略方案(性能、规则、策略) 版本管理(含多版本运行,部署回切方案) 数据分析(发现问题)
优点:对现有系统改造小,灰度环境成本要求低,容易实现。对发布应用的部署方式改变小,在灰度体验后,还是可以用原来的部署方式进行发布 灰度环境出现性能问题不会影响到生产服务器 同一台服务器上只有一个版本(生产或灰度),不容易误操作。 缺点:在灰度体验结束后,未能平滑的将灰度推广到全网用户,需要对公众环境进行一次传统的中断业务的发布。同于单独部署一套灰度环境,新增服务器的资源决定可以支持灰度体验用户数的规模,通常资源分配有限,无法进行大面积的灰度体验。
优点:可能充分利用硬件环境,灵活分配资源 可以实现版本间不会相互影响 只是服务级别的故障出现,正式服务不受影响。 缺点:在系统繁忙时,可能出现灰度应用抢正式应用的资源,一旦硬件故障则所有版本都会有问题。
评论