|
what：什么是灰度发布？——灰度发布概念、主要组成部份。why：为什么要有灰度发布？——灰度发布的背景、多角度分析作用。how：如何实现灰度发布？—— 灰度发布主要步骤、架构方案选择、常见的部署方案、案例介绍。谁说应用变更只能晚上发布，白天发布可以有。谁说运维不知道应用上线后性能怎么样，性能怎么样可以知道。谁说新应用上线后会所有客户都是小白鼠，可以让少数的人先尝鲜。谁说测试的重点在功能测试，用户体验测试与交互评估也可以有。谁说应用变更回切方案太复杂，无缝切换部署可以有。 应用系统通过建立灰度发布平台，可以实现： 缩小可能风险的波及范围，比如新推产品或功能，容易出现用户体验不爽或者性能低下等不足； 尽早吸收用户的反馈，产品不必100%完美才推出，可以先让部分用户试用，分析用户行为或汲取用户反馈后，再采取快速步骤改进产品； 提高产品的最终质量，分流的灰度发布等于除了行内测试外再扩大测试人群的范围，我们让更多的忠实用户直接参与测试，让更多双眼睛来发现隐藏的缺陷； 程序升级更加有序和自动化，以往如果升级涉及复杂的数据变动，很有可能需要停机处理，但如果是以分流发布的方式，逐批更新升级，或由用户触发，就可以实现不停机处理；通过无缝部署、分流等技术方案，运维人员可以在白天发布应用，大大解放了运维人员的生产力。 灰度发布是应用发布部署的一种方式，因其可尽早的发现问题的同时降低整体发布的风险的特点，己成为互联网产品发布常用的一种方式，那么什么是灰度发布呢？百度百科的概念是在黑和白之间平滑过渡的一种产品发布方式。 通俗的讲，可以这样理解：产品的发布过程不是一蹴而就，而是逐步扩大使用用户的范围，从公司内部用户->忠诚度较高的种子用户->更大范围的活跃用户->所有用户，在灰度发布过程中，产品发布者根据某种规则策略，让一部分用户继续用原来的产品功能，另一部分用户开始逐渐启用新功能，在过渡的过程中通过收集体验使用的数据，对新版本应用的功能、性能、稳定性等指标进行评判，进而决定继续放大新版本投放范围直至全量升级或回滚至老版本。 从上面的概念描述看，一个灰度发布的架构需要有以下的组成部分： 用户标识：用户标识用于区分用户，辅助数据统计，保证灰度发布过程中用户体验的连贯性（避免用户在新旧版本中跳变，匿名Web应用比较容易有这个问题）。匿名Web应用可采用IP、Cookie等，需登录的应用可直接采用应用的账号体系。目标用户选取策略：选取哪些用户先行体验新版本，是强制升级还是让用户自主选择等。可考虑的因素很多，包括但不限于地理位置、用户终端特性（如分辨率、性能）、用户自身特点（性别、年龄、忠诚度等）。对于细微修改（如文案、少量控件位置调整）可直接强制升级，对于类似新浪微博改版这样的大型升级，应让用户自主选择，最好能够提供让用户自主回滚至旧版本的渠道。数据反馈：灰度发布的本质实际上是让用户帮你测试，但是用户不是专职的测试，所以他一般不会主动报bug（除非遇到大问题，但是当用户主动报bug的时候，也就是你收到投诉了，这个应该不是你想看到的），但是有用户投诉不是最坏的，最坏的是用户不投诉，或者新产品为用户提供了有力的漏洞，这时候如果监控不到位。那迎接你的将是毁灭性的回滚和修复！所以灰度发布要有安全隔离，完善的监控，并且有友好的目标客户群 用户数据反馈在得到用户允许的前提下，收集用户的使用新版本应用的情况。如客户端性能、客户端稳定性、使用次数、使用频率等。用于与旧版本进行对比，决策后续是继续扩大新版本投放范围还是回滚。服务端数据反馈：新版本服务端性能、服务端稳定性等，作用与用户数据反馈类似。新版本回滚策略：当新版本灰度发布表现不佳时，应回滚至旧版本。对于纯粹的Web应用而言，回滚相对简单。主要难点在于用户数据的无缝切换。对于客户端应用，如果期待用户自行卸载新版本另行安装旧版本，成本和流失率都太高。可以考虑通过快速另行发布新版本，利用升级来“回滚”，覆盖上次灰度发布的修改。 每年都会有大大小小的许多应用变更、架构改造等，这些变更有这样一些特点： 新产品或大项目初次发布时；应用开发存在大量bug，但业务赶着上线；业务策略不明确拿不准时；面向特定用户群体时；大范围升级时 …… 经过大大小小的各种变更后，我们知道面对上述的特点的应用变更轻则带来一些功能性的bug，重则带来重大的客户或行里的资金损失、监管风险，甚至整个业务瘫痪。这些经验让我们一步步的完善高可用的应用架构、弹性的资源池、各种技术应急方案以应对突发事件，但经验却无法让我们把握这些应用变更后影响到底有多大，这是运维的困惑，同时也是开发、业务的困惑。灰度发布就是为了解决以上的困惑而来。 传统金融正在向互联网金融过渡，互联网金融有一个特点，就是不停的升级，升级，再升级，变更窗口从每月一次，到每月两次，到现在每周一次的发布频率都不算多，系统升级总是伴随着风险，新旧版本兼容的风险，用户使用习惯突然改变而造成用户流失的风险，系统宕机的风险..... 正因为变更带来风险，且对运维人员带来的感受是最直接的，所以运维人员则往往视变更为敌人。银行依靠运维人员维持正常业务运维和实施让银行赚钱的服务。由于变更会影响稳定性和可靠性，运维业务有理由对它说不。就算不统计，我们也知道事件中有80%情况是源于变更。 另外，正是因为变更将给应用带来运行风险，所以在银行的运维人员是苦逼的，数据中心的大楼在晚上夜深人静时往往会格外忙碌，在人们还在睡梦里时我们在做着我们最不想做的变更，做完变更还要等着即将发生的各种应急工作。 灰度发布可以提前发现问题，并通过部署策略控制发布动作对业务的影响，一方面可以减少新版本程序大规模使用后的风险；另一方面也可以让运维人员并不一定要在无业务或少量业务使用的夜晚才能进行变更。 在一个产品研发过程中，一般在发布前都有线下测试阶段，那么是不是线下测试验证通过后，就可以直接将产品的新代码发布上线，覆盖原来的版本呢？这样做其实有很大的风险，因为线下测试的运行环境和线上环境不是完全一致的，可能线下运行OK，到线上就出问题。 另外，正常一个产品开发过程中，会对其进行功能测试，用户体验测试，交互评估等。功能测试可以让产品尽量少的BUG；用户体验测试与交互评估等可以在开发过程中，使产品尽可能的满足于用户的使用习惯，以及对功能的可接受程度。但这些都是少部分人的感觉与习惯所产生的结果，只是公司内部的测试+小范围外部测试。 同时，在互联网产品的发布中，因为业务希望最快的抢占市场，大多都是做到这里就直接上线，替换了原有的版本，这种跳跃式的发布是非常危险的。 灰度发布可以增加了更大范围的外部测试，是一个不断的放量过程，通过这样的发布过程可以使产品的问题暴露出来，而不会影响到全部的用户，最终可以让产品最大程度稳定、适合用户，而这些问题可以通过业务策略进行控制。 业务人员，尤其是互联网金融的业务人员大脑接受着大量的新鲜事物，他们迫不及待的希望他们的新产品可以更高频度的发布到学历证书市场，抢占市场。他们要更多的流量、更多的用户、更多资金流入。 但他们往往又忽略了变更的高频给开发的版本管理、程序质量带来极大的风险，这种情况带来的结果经常是：在各方迫切的要求下，产品上去了，但是灾难随着而来，系统不仅不适合大部分用户，而且还有错账，客户反而流失了。 灰度发布一方面满足业务高频发布应用的需求，另一方面通过灰度分流的发布变更，让新版的系统越来越稳定。同时通过数据分析，变更优化，让应用设计更符合客户的使用习惯等要求。使业务人员可以去关注流量、用户量、资金的收益，去考虑如何推广新的业务，而不是考虑如何进行客户解释、应急工作。 对于用户体验方面，在线下测试阶段的用户是不全的，只有测试、开发和PD等人，他们的体验不能完全代表线上的大量用户。另外还有性能方面的原因等等。 所以，一般线下测试通过后，在发布阶段会采用灰度发布的方式，选用线上的部分服务器部署新代码，剩下的服务器仍然部署老代码，然后进行引流，部分请求采用部署了新代码的服务器处理，剩下的请求采用仍然部署着老代码的服务器处理。经过一段时间的线上观察，没问题后，再更新所有的服务器。 用户策略：用户量规模（水平）、用户群属性（垂直）；产品策略：功能覆盖、运营规划实验；数据策略：数据模型、行为分析 ；部署策略：回滚、新旧系统并行 。分流规则设定数据分析系统软件配置软件部署定义策略：确定分流的目的、放量的规模、递增的频率、回滚的策略等；筛选用户：确定分流访问的用户特征，定义规则或导入名单；访问分流：技术支撑，通过DRE（分流发布引擎）重定向用户请求；部署应用：打包部署单独的分流环境；体验反馈：收集分流用户试用后的建议反馈，修正产品设计。 以下是灰度发布常见部署环境，对于灰度发布有几个重要的组成部门： 分流策略方案（性能、规则、策略）版本管理（含多版本运行，部署回切方案）数据分析（发现问题） 几种可选的方案： 在原有的生产环境服务器以外，单独部署一套服务器，并在这些单独的服务器上部署灰度版本应用，提供给内部或外部的体验用户使用，灰度体验完成后，再对生产使用的服务器进行常规的部署发布。这种部署方案下灰度环境类似于试运行或演练环境，但不同的是此环境会用到正式生产环境的后台接口及数据库模块等。 优点：对现有系统改造小，灰度环境成本要求低，容易实现。对发布应用的部署方式改变小，在灰度体验后，还是可以用原来的部署方式进行发布 灰度环境出现性能问题不会影响到生产服务器 同一台服务器上只有一个版本（生产或灰度），不容易误操作。缺点：在灰度体验结束后，未能平滑的将灰度推广到全网用户，需要对公众环境进行一次传统的中断业务的发布。同于单独部署一套灰度环境，新增服务器的资源决定可以支持灰度体验用户数的规模，通常资源分配有限，无法进行大面积的灰度体验。 充分利用服务器资源，在同一个资源中部署两个服务，其中一个正式的SVR，另一个是类度的服务，因为不同的服务端口不一样，可以通过负载均衡器实现不同的版本的请求分发。 优点：可能充分利用硬件环境，灵活分配资源 可以实现版本间不会相互影响 只是服务级别的故障出现，正式服务不受影响。缺点：在系统繁忙时，可能出现灰度应用抢正式应用的资源，一旦硬件故障则所有版本都会有问题。 灰度版本管理是指需要有系统有实现升级包文件、版本号，系统应用部署、升级、备份、回切等自动化部署的方案。这个版本管理有别于以前的版本管理的一点是：灰度发布出现的版本升级或回切，不能影响用户端业务的连续性。 |
|
|
来自： 新用户0175WbuX > 《待分类》
