阿里微服务质量保障系列：阿里变更三板斧

变更是指对线上系统的任何操作（如：发布、增加、修改或移除等），或其他对生产业务可能有影响的任何操作。基于阿里巴巴的历史经验，有一半以上的重大故障皆为变更触发，因此，变更过程的风险防御显得尤为重要，会直接关乎业务的稳定性。

变更系统是指承载任何对线上生产环境变更操作的系统或工具。例如拥有控制台的白屏化系统/工具、压测/演练平台、黑屏脚本、开放出来的可触发变更操作的API、不以变更为主要功能和目标的平台/系统，如具备了对生产环境实施变更的功能，则相应的变更功能部分也视同变更系统对待等。

变更风控首先是一个业务理念，是稳定性领域内指导变更操作的一套标准，同时规范经济体变更系统的能力建设。其次变更风控是一套技术体系，通过技术手段干预变更的整个生命周期，在变更前进行准入检测，变更中约束渐进式的执行过程，并通过宏观的观测手段验证变更的阶段结果，及时发现问题进行回滚止血，同时在变更后，通过影响面的拓补提供变更数据的应用，辅助故障定位和问题排查。

变更风控主要有三个目的：

• 收敛因变更触发的重大故障；

• 规范业务团队的变更操作，沉淀通用变更能力和执行标准；

• 帮助变更系统建设风控能力，护航业务变更执行。

标准的变更过程一般可分为：计划、执行、结束三个部分，其中：

1. 计划阶段：该阶段主要包含变更申请，以及申请的准入审批。变更申请需要明确变更计划、窗口期、潜在影响以及回滚方案。

2. 执行阶段：首先对变更行为进行二次校验，如确定变更环境是否满足要求，业务流量已按预期停止等。变更过程建议先在测试环境验证后，再进入生产环境变更阶段，同时灰度、分批进行。每批次间设定一定间隔时间，并进行观察记录至少一项可反映核心业务健康状态的指标（业务监控项、日志文件名等），同时须具备回滚能力。

3. 结束阶段：通过监控、日志等数据验证业务是否正常，并记录上报相关数据。

4. 对线上系统的任何操作（如：发布、增加、修改或移除等），或其他对生产业务可能有影响的任何操作时，都需要满足变更风险防控的三原则“可观测、可灰度、可回滚”。

可观测

变更观测是指在变更执行过程中，任何因变更触发的且预期外的线上业务异常（含监控、报警、日志等）均能实时被变更执行人感知的能力。是变更人主动并及时发现问题，降低重大故障影响半径的有效方式之一。变更观测是变更执行人的基础工具之一，变更可观测能力是对变更系统最基础的要求。

变更观测三大原则

• 变更执行期间需有效观测：变更系统逐步实现强管控，所有变更从第1批执行开始时即要启动变更观测。

• 变更执行每批次灰度均需观测：变更执行时需全程进行变更观测，确保验证该批次变更观测无异常后再进行下一批次变更。

• 每批次变更需保证充分的观测间隔时长：各业务可结合自身经验和特性，推行适合各业务的不同观测间隔时长，尽量避免观测不到位问题。

可观测层次

可观测覆盖可以综合参考监控的对象和方式，将可观测划分为4层：

• 基础设施监控：主要关注机房、网络等基础设施的运行情况。在云上的Kubernetes环境也指宿主机节点、网络基础组件的性能监控等。这部分可观测可通过阿里云云监控实现。如查看节点负载、CPU、内存、网络等指标的使用率等。

• 系统应用监控：主要关注实例、中间件等基础服务的运行情况。这部分可观测也可通过云监控实现。同时阿里云托管版Prometheus（ARMS Prometheus）也可满足云原生指标可观测需求。

• 业务监控：通过采集应用程序中的业务状态数据，如接口的请求次数、成功率和响应时长等，产出业务级别的监控指标，以数据反映业务健康状况，从而完成对业务的监控。阿里云ARMS以代码无侵入的方式，可视化定义业务请求，提供贴合业务的丰富性能指标与诊断能力。也可使用阿里云日志服务SLS （Log Service）作为自定义指标的观测方案。用户可通过自定义应用系统的内容、格式，并通过日志服务收集，并在日志服务中配置业务大盘，观测自己的业务情况，或做系统审计。

• 用户反馈监控：主要从舆情、客诉等反向收集用户对功能可用性的反馈，作为兜底监控。

可灰度

灰度为变更提供一种快速低成本的试错机制，其具有多种不同层面的实现形式。一种典型的灰度机制，是提供一套完整而独立的灰度环境，用于正式生产变更前的提前验证。另一种较为典型的灰度机制，为在生产环境分批次变更，通过细化控制变更的节奏和影响范围，实现小规模生产试错能力。

灰度环境

灰度测试环境的目的是隔离生产流量，减少风险影响，在环境内形成调用闭环，方便测试，具体灰度环境建设如上图所示。灰度环境灰度的时间点位一定要在上线生产之前。可引流内网全部流量和线上1%流量作为测试覆盖的基础。

灰度分批

这里列举三个常见的分批方式：簇内分批、簇间串行、簇间打散，每个层面中对应的灰度方式如下图所示：

图中的簇指的是可以继续拆分的逻辑组，包含但不限于单元、地域、机房、可用区、VPC、集群、分组、自定义逻辑区域等。

线上生产环境灰度变更建议包含以下要求：可分批、可控制分批间隔、可观测/可验证、可暂停/可回滚。

• 可分批：指灰度方式必须至少满足灰度分批方式中的一项：簇内分批、簇间串行、簇间打散。确定好灰度方式后，至少需要2批进行发布。如果确实不具备灰度能力，建议提升审批申报层级。

• 可控制间隔：指变更可对每批次的发布时间间隔进行控制。一般建议重大风险的变更灰度时长至少一个小时。核心系统的生产环境灰度发布总观测时长不少于30-60分钟。第一批变更完后至少观测20分钟，后续发布批次间隔可自定。

• 可观测：指变更系统每批次发完后，需要观测并验证本批次发布无问题后才能进行下一批次的发布。观测和验证的手段包括但不限于以下方式：在变更系统里至少记录一项核心反应健康状态的指标（业务监控项、日志文件名等）或记录二次确认人员或采用自动化观测等，并能通过对线上文件验证等方式确定已发布成功。

• 可回滚：指灰度时需具备分批回滚、全量回滚的能力，回滚单要有变更记录并可追溯。

可回滚

变更回滚是指当服务、配置或数据出错时，能顺利恢复到最近一个正确版本的可逆操作，且回滚范围应同变更前的范围一致。任何线上变更需具备回滚方案，如果发生概率性风险事件或者未知风险导致的系统或业务异常，必须有相关的措施可以第一时间恢复到变更前的状态。

对回滚进行模型提炼和属性解构，根据变更对象恢复到变更前状态的方式，可以分为两种典型的回滚模式：

1. backward模式：又称回退模式回滚，主要指将变更对象从当前状态回退到变更前状态的回滚方式。执行变更前，线上服务处于A状态，变更执行使得线上服务处于B状态，此时进行变更回滚，则线上服务会恢复到变更前的A状态，用状态机表达式可以描述为：roll-back: A->B->A。

2. forward模式：又称前进模式回滚，主要指将变更对象从当前状态再一次变更到新状态，而新状态即为变更前状态值的回滚方式。执行变更前，线上服务处于A状态，变更执行使得线上服务处于B状态，此时进行变更前滚，则线上服务会前进至A'状态，但A'状态同A状态满足内容一致性，用状态机表达式可以描述为：roll-forward: A->B-A'。

回滚五要素

为实现变更的一次成功回滚，需具备如下五个基本要素：变更对象、回滚模式、变更已生效范围、变更对象在变更前的状态值、变更对象在变更后的状态值。

• 变更对象，是指变更执行所操作的原子资源，例如：应用包、配置项等。

• 回滚模式，是指采用rollback模式或者forward模式来将变更对象恢复到变更前状态的回滚模式。

• 变更已生效范围，是指在变更灰度过程中已生效的变更范围。

• 变更对象在变更前的状态值，是指变更对象在变更前的稳定状态原子描述。

• 变更对象在变更后的状态值，是指变更对象在变更后的稳定状态原子描述。

变更发布策略

通过合理的流量分配及部署策略，可将生产流量逐步切至已发布新版本的应用上实现灰度及快速回滚，以最大限度避免非预期的变更部署问题导致的影响。业界广泛采用的的发布策略包括：

• 蓝绿发布：通过对服务新版本进行冗余部署实现。一般会将新版本的实例规格和数量与旧版本保持一致。当新版本服务验证通过后，将业务流量全部切至新版本。旧版本作为热备。如新版本上线后出现问题，可将流量全部切回至旧版本完成回滚，缩短故障恢复时间。

• A/B测试：通过用户请求的元信息将流量路由到新版本，是一种基于请求内容匹配的灰度发布策略。常见的做法包括基于HTTP Header和Cookie，将特定请求或用户灰度至新版本，降低故障影响范围。

• 金丝雀发布：通过调整流量权重比例，逐步将流量从老版本切换至新版本。同时对老版本服务进行缩容，对新版本进行扩容，相比蓝绿发布资源利用率较高。

阿里云MSE云原生网关以托管的方式来做流量入口，提供丰富的流量治理能力，支持多种服务发现方式，如容器服务、MSE Nacos、MSE Zookeeper、EDAS注册中心、SAE注册中心、固定地址和DNS域名，并以统一的模型支持服务版本以及灰度发布能力。支持以上三种发布策略及应用无损上下线等功能。

行动吧，在路上总比一直观望的要好，未来的你肯定会感谢现在拼搏的自己！如果想学习提升找不到资料，没人答疑解惑时，请及时加入群： 786229024，里面有各种测试开发资料和技术可以一起交流哦。

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

软件测试面试文档

我们学习必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有字节大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。