![]()
本文作者：聪敬、苏玮、玖玄、林涛
基础网络产品的生命周期大致包含研发、架构、交付、优化和运营等几个环节，每一个环节的质量保证都涉及重要的一环，即预期验证测试。比如研发的功能测试，架构的POC测试/AVL测试，交付的配置验收，优化的灰度变更和方案测试，运营的GNOC模版测试/演练/LANDING测试等等。如何安全、高效和低成本地保证这些环节能够稳定持续运行呢？自动化测试平台Full-Automation-Simple-Touch（FAST）应运而生，为网络全生命周期测试提供了平台，提升网络的稳定性。![]()
本文将重点讲解一下如何在仿真测试平台进行灰度变更测试，从而保证变更的稳定性。![]()
众所周知，网络变更的数量在逐年递增，从2016到2020年，变更数量增加了5倍，同时网络规模复杂度也在提升，如何在人力资源没有增加的前提下保证变更的稳定性，是一件非常具有挑战而且非常重要的事情。设想如果能在真正变更前把变更方案在测试环境中提前灰度验证，保证提前发现并解决潜在的问题，将大幅度提高变更稳定性。灰度变更测试是为变更流程中的各个环节提供提前验证的能力。比如说验证方案中的CLI是否能正确下发到设备，验证配置下发到设备后的行为是否符合预期，验证设备之间的状态交互是否正常。还可以模拟异常条件，提供紧急应对措施的验证。提前发现问题并且验证解决方案，是灰度变更测试的核心价值之一（保证稳定性）。另外一个核心价值就是成本效率的提升，使用了厂商提供的镜像，通过仿真技术可以快速搭建一个灰度测试环境， 一般是在分钟/小时级别，具体要看规模。而搭建一个相同的物理环境需要几个星期，甚至是几个月，因为涉及到采购，交付上架，连线等等，另外仿真设备本身的成本也远低于物理设备的成本。![]()
在2018年前是没有网络仿真环境的，2018后我们开始着手搭建了核心网的仿真灰度环境，根据现网设备配置/现网拓扑/现网路由，加上厂商提供的设备镜像，通过仿真技术，搭建了一个协议1：1低成本高保真的仿真环境，并且完成了和线上自动化运维系统的对接，实现了灰度变更测试从0到1的飞跃。上图的左半边是一个典型的阿里生产网络，2个IDC数据中心通过骨干网链接起来，操作人员通过跳板机链接到物理目标设备，然后进行一系列操作。上图的右半边是我们仿真出来的一个仿真网络。从操作人员的角度来看，也是通过跳板机，经过仿真和真实之间的TCP/IP代理服务，就可以轻松地进入虚拟世界，对仿真设备进行相应的操作。除了基本的操作能力外，在仿真系统中也加入仿真特有的功能，比如预期判断/故障演练/健康检查/安全防护等等。同时由于是仿真环境，我们可以轻松地制造出多个仿真环境，用于不同的场景。构建仿真系统挑战很多，这里列举了几个比较重要的挑战：我们模拟了整个近千台设备的互联，怎么保证这些链接的稳定可靠至关重要，因为链接不可靠，容易导致丢包/延迟等，严重影响环境质量。仿真镜像自身有一些无法改动的设置，包括端口名字和数目，无法直接和现实网络做到严格1:1。建立仿真环境后，面临的很大的挑战就是，怎么验证和线上的一致性。仿真环境镜像/连线/配置完成后，还需要引入实际业务数据，比较关注的就是自动化的路由注入。IDC内部分厂商的镜像还没有镜像，我们采用了混部多协议逻辑验证 （HPLV hybrid protocols logic verification）来扩展IDC设备。相对于其他公司，其实阿里的网络更复杂，主要体现架构更多，设备的厂商更多，这些都给网络带来了更大的复杂度，所以可以想象，要在阿里的网络里面完成灰度测试环境的搭建难度要远比想象中的大。![]()
有了仿真环境后，还需要有可靠的流程来保障灰度变更，为此我们在变更流程中引入了方案测试和灰度测试两个环节。方案测试是在方案设计之后，评审上线之前，用于判断测试方案的各个环节是否都有被测试覆盖、不同维度测试是否完整。理论上只有经过方案测试达标后的方案才能评审上线，为方案的稳定性设立的第一道关卡。变更测试的第二个关卡是在变更工单审核之前做了流程卡点，对于核心网变更，如果没有经过灰度测试是无法提交工单审核的，从流程中保证了“无灰度不变更”。
免费领取电子书
《Dubbo分布式服务治理实战》
Dubbo是阿里巴巴开源的高性能分布式RPC服务治理框架，提供了六大核心能力：面向接口代理的高性能RPC调用、智能容错和负载均衡、服务自动注册和发现、高度可扩展能力、运行期流量调度、可视化的服务治理与运维。本书将带同学们了解并掌握Dubbo3.0新特性及相关实践实战。
点击“阅读原文”，立即下载吧~