阿里仿真灰度变更测试简介

Posted 2021-08-29 阿里云云栖号

简介： 基础网络产品的生命周期大致包含研发、架构、交付、优化和运营等几个环节，每一个环节的质量保证都涉及重要的一环，即预期验证测试。本文将重点讲解一下如何在仿真测试平台进行灰度变更测试，从而保证变更的稳定性。

作者 | 聪敬、苏玮、玖玄、林涛
来源 | 阿里技术公众号

一 前言

基础网络产品的生命周期大致包含研发、架构、交付、优化和运营等几个环节，每一个环节的质量保证都涉及重要的一环，即预期验证测试。比如研发的功能测试，架构的POC测试/AVL测试，交付的配置验收，优化的灰度变更和方案测试，运营的GNOC模版测试/演练/LANDING测试等等。如何安全、高效和低成本地保证这些环节能够稳定持续运行呢？自动化测试平台Full-Automation-Simple-Touch（FAST）应运而生，为网络全生命周期测试提供了平台，提升网络的稳定性。

本文将重点讲解一下如何在仿真测试平台进行灰度变更测试，从而保证变更的稳定性。

二 技术引领稳定变更的必要性

众所周知，网络变更的数量在逐年递增，从2016到2020年，变更数量增加了5倍，同时网络规模复杂度也在提升，如何在人力资源没有增加的前提下保证变更的稳定性，是一件非常具有挑战而且非常重要的事情。设想如果能在真正变更前把变更方案在测试环境中提前灰度验证，保证提前发现并解决潜在的问题，将大幅度提高变更稳定性。

三 变更稳定性流程剖析

灰度变更测试是为变更流程中的各个环节提供提前验证的能力。比如说验证方案中的CLI是否能正确下发到设备，验证配置下发到设备后的行为是否符合预期，验证设备之间的状态交互是否正常。还可以模拟异常条件，提供紧急应对措施的验证。提前发现问题并且验证解决方案，是灰度变更测试的核心价值之一（保证稳定性）。

另外一个核心价值就是成本效率的提升，使用了厂商提供的镜像，通过仿真技术可以快速搭建一个灰度测试环境， 一般是在分钟/小时级别，具体要看规模。而搭建一个相同的物理环境需要几个星期，甚至是几个月，因为涉及到采购，交付上架，连线等等，另外仿真设备本身的成本也远低于物理设备的成本。

四 阿里巴巴AIS网络仿真系统

阿里巴巴AIS网络仿真系统是什么样的呢？

在2018年前是没有网络仿真环境的，2018后我们开始着手搭建了核心网的仿真灰度环境，根据现网设备配置/现网拓扑/现网路由，加上厂商提供的设备镜像，通过仿真技术，搭建了一个协议1：1低成本高保真的仿真环境，并且完成了和线上自动化运维系统的对接，实现了灰度变更测试从0到1的飞跃。

上图的左半边是一个典型的阿里生产网络，2个IDC数据中心通过骨干网链接起来，操作人员通过跳板机链接到物理目标设备，然后进行一系列操作。上图的右半边是我们仿真出来的一个仿真网络。从操作人员的角度来看，也是通过跳板机，经过仿真和真实之间的TCP/IP代理服务，就可以轻松地进入虚拟世界，对仿真设备进行相应的操作。除了基本的操作能力外，在仿真系统中也加入仿真特有的功能，比如预期判断/故障演练/健康检查/安全防护等等。

同时由于是仿真环境，我们可以轻松地制造出多个仿真环境，用于不同的场景。

五 仿真系统构建的挑战示例

构建仿真系统挑战很多，这里列举了几个比较重要的挑战：

大规模光纤仿真

我们模拟了整个近千台设备的互联，怎么保证这些链接的稳定可靠至关重要，因为链接不可靠，容易导致丢包/延迟等，严重影响环境质量。

镜像和物理设备端口不一致

仿真镜像自身有一些无法改动的设置，包括端口名字和数目，无法直接和现实网络做到严格1:1。

自身可信度保障

建立仿真环境后，面临的很大的挑战就是，怎么验证和线上的一致性。

路由注入

仿真环境镜像/连线/配置完成后，还需要引入实际业务数据，比较关注的就是自动化的路由注入。

厂商镜像不足

IDC内部分厂商的镜像还没有镜像，我们采用了混部多协议逻辑验证 （HPLV hybrid protocols logic verification）来扩展IDC设备。

六 业界产品比较

相对于其他公司，其实阿里的网络更复杂，主要体现架构更多，设备的厂商更多，这些都给网络带来了更大的复杂度，所以可以想象，要在阿里的网络里面完成灰度测试环境的搭建难度要远比想象中的大。

七 流程规范化的挑战

有了仿真环境后，还需要有可靠的流程来保障灰度变更，为此我们在变更流程中引入了方案测试和灰度测试两个环节。

方案测试是在方案设计之后，评审上线之前，用于判断测试方案的各个环节是否都有被测试覆盖、不同维度测试是否完整。理论上只有经过方案测试达标后的方案才能评审上线，为方案的稳定性设立的第一道关卡。

方案测试的特点如下：

• 根据维度自动生成用例（这里的维度指的是一类属性的概念，比如厂商，角色等等）
• 批量并发执行，提高执行效率。
• 执行完后有统计数据支持维度级别的精确上线控制。

变更测试的第二个关卡是在变更工单审核之前做了流程卡点，对于核心网变更，如果没有经过灰度测试是无法提交工单审核的，从流程中保证了“无灰度不变更”。

八 落地场景与结果

• 自动化系统能力的保障
• 月平均拦截40次变更风险

九 未来展望

• 扩大支持覆盖率
• 平台自助化/智能化
• 商业化

原文链接

本文为阿里云原创内容，未经允许不得转载。