柳州网站建设之如何设计可靠的灰度方案

一   灰度的基本概念

1   一个典型的灰度方案

一个较大的业务或系统改动，往往会影响整个产品的用户体验或操作流程。为了控制影响面，可以选取一批特定用户、流程、单据等，只允许这一部分用户或数据按照变更后的新逻辑在系统中流转，而另一部分用户仍然执行变更前的老逻辑。这一步是线上系统灰度方案的起点。

将用户按照特定规则分隔为两类之后，我们主要需要关注命中灰度的这部分用户，是否按照预期执行了新逻辑、产生了符合预期的数据，以及系统整体的变化等。此阶段即灰度观察阶段，线上验证工作也是其中的关键步骤。

随着系统中使用新逻辑的用户、订单等数据的逐步累计，即可证明新系统的正确性、有效性，那么更多的用户就应当被迁移进新逻辑中，这一阶段一般称作灰度推进。灰度推进有时是小流量验证后立即切全量的，也有需要逐步放量的，这需要结合实际业务&系统能力做出决定。

最终，全部用户被纳入到新逻辑的范围内，此时需要决定是否将灰度逻辑本身和系统中的老业务逻辑同步下线，全部用户仅可以使用新逻辑，此时即灰度完成。也有由于历史数据原因，长期无法完成全量灰度切换的，此时业务系统中将会长期驻留两套逻辑。

2   灰度在解决什么问题

一个变更如果在发布后立即全量上线，那么如果出现系统、逻辑、数据等问题，将会是灾难性的，比如全部用户无法创建新订单、全部新订单出现脏数据等，甚至有可能会影响到变更前的数据。

灰度过程就是在规避变更过程中这个**的风险：全局影响。通过减小影响范围，再配合灰度线上验证、监控报警等手段，将出现问题时影响面，控制在有限的范围内，如减少订正的数据量或降低资损金额等。

安全生产规则中所谓的“无灰度，不发布”就是这个思想，通过灰度尽可能的减少问题的影响面。如果通过灰度过程发现一个线上问题，那么去掉灰度的保护，可能就会产生一个严重的故障。

3   灰度会带来什么风险

灰度方案可以规避全局性的影响，但是会不会带来其他的风险呢？答案是肯定的，工程中没有一劳永逸的银弹。

首先是如何发现灰度过程中的问题

这与上线过程中的监控报警有一定的相似性，二者主要都是依赖日志&监控&报警规则的建设和配置；但二者又存在一定的差异，如报警阈值如何配置才能有效发现小流量异常？灰度名单外的老逻辑会不会触发新逻辑的监控报警？灰度系统影响的上下游是否也有对应的灰度监控？这些问题都可能影响灰度问题能否被发现与发现问题的时效性。

此外，对灰度系统要重点关注资损风险。资损字段在上线前一定要做好核对的保障，或者至少应当在灰度开始阶段之前完成，尤其是对新变更引入或影响的资损字段，要做到全覆盖，“无核对不上线”。

灰度过程中还可以协同客户、运营、产品等多条线的同学做好布防，及时感知处理相关舆情，使用非技术手段作为问题发现的兜底与补充。

其次，如何控制灰度中问题的影响面

灰度过程中产生的灰度数据，不能侵入非灰度数据，反之亦然，要确保二者的充分隔离。

但是灰度系统需要与上下游联动，灰度本身也需要推进，一旦遇到问题，还需要进行灰度停止、灰度回退等更复杂的操作，因此灰度整体是一个动态的过程，而在整个动态过程中，需要严格保持灰度数据&非灰度数据的隔离，否则将会导致问题影响面扩大化，危及整个系统，甚至发生严重故障。

这里尤其需要注意的是灰度停止与灰度回退的复杂性：如果灰度停止手段不能生效，那么问题影响就无法得到有效控制；灰度回退则需要涉及阻断灰度流程、修改已有灰度数据、修复错误数据等，一般来说是整套灰度方案中最复杂的部分。

最后，发生问题时的处理也会比较复杂

生产系统往往没有太多的资源或条件进行AB-test，灰度与非灰度数据都是真实的业务数据，一旦出现问题，并不能通过删除灰度数据或脏数据的方式解决问题，一般需要进行数据订正，或发布新的变更进行修复。数据订正的数量、订正数据的正确性、如何甄别灰度用户、如何保证新变更的正确性、如何保证新变更可以有效修复问题数据等，都是恢复过程中的难点工作与潜在风险。

来源：阿里技术