给网络变更加个“护身符”—— 腾讯网络变更红绿灯

前言

       变更是网络运营中最常见的工作之一。过去，想要在变更过程中监控网络质量变化，变更人员需要自行准备样本进行质量探测，同时逐个打开变更设备的流量视图以及关联区域的业务探测曲线，并在实施过程中实时关注这些页面。实施完成后，根据经验确认无异常，即结束变更。看起来行云流水又风平浪静的一次操作，往往在变更结束后却收到业务报障，此时才忽然发现变更存在异常，然后紧急回退来恢复业务，但从业务受到影响开始，到变更回退后业务恢复，影响时间已非常长，已经造成了严重网络故障，影响用户体验。如果能给变更加个“护身符”，让变更能够逢凶化吉，出现异常快速恢复，那么业务影响就能大幅降低，用户体验也能得到保障。

       “变更护身符”该如何获得呢？回顾变更人员未能及时发现变更异常的原因，主要是凭借个人经验选择的质量探测样例及监控内容不全，或者关注有遗漏。就像在车水马龙的十字路口，个人主观判断往往很难获取全面的交通信息，容易造成交通拥堵甚至交通事故，需要有交通信号灯来统筹指挥车辆的行进。网络变更也一样，如果能有交通信号灯一样的工具，站在上帝视角，告诉变更人员什么时候可以实施、什么时候需要暂停，什么时候必须回退，那么变更也将像交通一样稳定畅通。腾讯网络变更红绿灯就是网络变更的“护身符”。

变更红绿灯

       腾讯网络变更红绿灯是专为网络变更设计的质量监控平台，旨在为每个变更提供独立且全面的质量监控。“红灯停，绿灯行，黄灯就请等一等”，让这个简单的规则，同样适用于网络变更领域，通过点灯来指示变更的下一步操作。确保在变更出现异常时，变更人员能够准确掌握变更情况，规避未及时发现异常而导致的长时间业务影响。这样对于做网络变更的同学来说，变更红绿灯就为他们打开了“上帝视角”，让变更人员只需安心专注于网络变更操作以及看灯，不必再考虑该怎样选择探测样例度量网络质量，也不必担心自己选择的监控内容是否准确完备。就好像在开火车的老司机，只要关心火车驾驶技术以及红绿灯即可，不必关心任何其他事情；

       从技术角度看，变更红绿灯主要解决如下几个问题：

• 如何监控每个变更范围内的网络质量
• 如何将监控告警准确关联到异常的变更
• 在异常发生时，如何帮助变更人员及自动化变更系统快速决策回退

       为解决上述三个问题，红绿灯平台通过输入、关联、点灯及执行四个模块来实现从前端监控到后端操作端对端快速闭环联动，详细框架设计如下：

      下面将对四个模块进行详细介绍和说明。

1. 输入模块：多维度监控

       输入模块主要解决监控覆盖的问题。为了快速提升监控覆盖率，红绿灯对内联动各类网络监控系统，对外联动业务监控系统，全方位整合监控资源，并结合具体变更场景进行有序编排，达到为每个变更创建个性化监控任务的目的。

1.1 内部网络监控

       经过多年的沉淀，网络运营与研发团队针对基础网络与云网络打造了一套全方位的网络质量监控平台，通过抽样探测流来模拟业务流，准确感知业务故障范围，涵盖了内网和外网不同维度及底层、中层和上层等不同层次的网络范围，这些在网络精细化监控和运营工作中发挥着至关重要的作用。红绿灯充分复用团队能力，将变更系统与质量监控平台打通，采用“大盘监控+个性化监控“的模式，为每一个变更量身定做质量监控。

• 大盘监控

       对于常态化监控覆盖的变更场景，红绿灯直接接入大盘监控告警，并依据变更影响范围配置监控范围。变更影响范围基于变更设备的架构角色、所属业务、网络拓扑、机房信息等综合计算得到，并依据不同监控告警的格式自动转换成标准的监控配置。

• 个性化监控

       对于常态化监控无法覆盖的变更场景，红绿灯则直接复用质量监控平台的底层探测能力，依据变更设备的架构角色抽样选择所覆盖的业务地址，自定义创建探测任务，设置告警规则，在变更期间精准监控变更范围内的网络质量。

 1.2 外部业务监控

       为了监控业务的运行状态，业务部门打造了各自业务层的监控体系。在内部网络监控未能及时发现质量异常时，变更人员往往通过业务报障才能发现变更问题，但从业务运维人员发现异常，到报障网络NOC值班人员，再到定位出变更问题，通知变更人员回退，通常需要很长一段时间。在此期间，业务持续受损，由此产生的直接和间接损失不可估量。红绿灯打破了这一链条，将业务监控直接接入变更系统。变更单在提交时即可自动计算变更涉及的业务类型，并自动开启对应业务监控告警推送路径，确保变更平台在变更实施过程中可以直接收到业务异常告警，并经过变更红绿灯模块判断告警是否与变更有关。一旦确认有关联，系统将自动触发变更回退，从而大幅缩短异常变更影响时长。

 2. 关联模块：智能关联

       基于输入模块为每个变更单创建的质量监控任务，变更范围内的质量异常就可以快速通知变更人员了。接下来，红绿灯需要判断当前异常是否与本次变更有关联。如果确认有关联，系统亮红灯，提醒变更人员立即回退恢复业务；否则，系统亮黄灯，提醒变更人员暂停操作至异常恢复，规避继续实施可能带来的叠加风险。关联模块从变更时间、空间及内容三个维度展开判断。

 2.1 时间关联

       与其他异常原因不同，变更触发的网络故障一定伴随着变更操作。并且，由于网络收敛的速度很快，变更操作和故障产生的时间间隔非常短。因此，在故障产生时，立即搜索故障前一定时间间隔内发生的变更操作，即可快速锁定异常变更范围。

• 告警时间与变更窗口关联

       依赖于精细化授权的控制，变更操作只能在变更窗口内进行。因此，当变更范围出现监控告警时，红绿灯首先将告警时间与变更窗口进行关联。若监控告警不在变更窗口内，则关联失败，说明当前告警与本次变更无关；否则，关联成功，当前告警与本次变更可能有关，需要进一步判断变更是否存在操作。

• 告警时间与操作时间关联

       对于配置层面的变更操作，权限系统有详细的登录操作日志，红绿灯打通了权限系统。当告警时间与变更窗口匹配成功时，红绿灯进一步以告警产生时间点为基准，向前取δ时间间隔，查询变更关联设备在权限系统里是否存在操作记录。若没有记录，则关联失败，当前告警与本次变更无关；否则，关联成功，当前告警与本次变更可能有关。

      理论上，δ越小，关联到的变更操作就会越少，最后锁定的异常变更范围也就会越精准。当δ足够小时，红绿灯就能准确判断出当前异常是否与本次变更有关。然而实际情况是，δ受设备性能、监控精度以及告警规则影响，不可能无限小。因此，红绿灯还需进一步关联才能准确定位出产生异常的变更。

 2.2 空间关联

       基于历史异常变更的数据分析发现，98%的变更异常都会导致变更操作设备所在区域的网络质量异常。因此，将告警区域与变更操作设备所在区域进行关联，可以进一步缩小异常变更范围，提升关联结果的准确率。

• 物理层面

       物理层面的区域也就是地域。腾讯在全球范围内布局有多个数据中心。作为腾讯互联网业务服务的基础设施，腾讯数据中心网络按照大区、城市、园区和机房四层结构分区域分层次管理，网络设备的属性定义和告警内容的格式定义也均按照这四层结构展开。因此，当变更范围出现监控告警并且匹配到变更操作时，红绿灯可以从告警内容和操作设备的属性当中提取出地域信息进行关联。当告警区域与正在操作的变更设备所属地域匹配失败时，关联失败，当前告警与本次变更无关；否则，关联成功，当前告警与本次变更可能有关。

• 逻辑层面

       逻辑层面的区域也就是设备配置的逻辑分区。腾讯数据中心网将承载的业务划分成了多个类型，不同业务类型之间路由相互隔离，避免某一业务相关的变更操作影响全局网络。业务类型在数据中心建设前完成规划，并在网络配置管理数据库中与设备信息进行绑定。另外，业务类型也是监控告警的关键字段。由于相同地域下可能存在多个逻辑分区，红绿灯在匹配区域时，还需进一步匹配告警的业务类型和变更操作设备所绑定的业务类型。当业务类型匹配失败时，关联失败，当前告警与本次变更无关；否则，关联成功，当前告警与本次变更可能有关。

 2.3 内容关联

       在变更操作的时间、空间和告警信息都吻合时，如果操作的内容仅仅是检查设备端口、协议状态，或者进入某个进程，通常都不会改变网络的运行状态，也不会引起网络质量的异常。因此，红绿灯在操作时间和空间都匹配成功后，会进一步识别操作命令，将不会改变网络运行状态的命令标记为安全命令，将会改变网络运行状态的命令标记为危险命令。

       由于不同厂商、型号的设备命令不一致，且同一型号设备的不同OS版本也存在命令变化的可能，红绿灯按照“厂商+型号+OS版本”的配套组方式维护命令集。同时，为了准确识别出危险命令和安全命令，红绿灯针对命令行配置生效模式的不同，采取了差异化的命令维护方式，两阶段生效的设备采用危险命令集黑名单的方式，立即生效的设备采用安全命令集白名单的方式来判断。若操作命令被识别为安全命令，红绿灯判断当前告警与本次变更无关；否则，判断当前告警与本次变更有关。

3. 点灯模块：精准亮灯

       为了准确指示变更的行进情况，帮助变更人员在变更异常时快速决策回退，每个变更单的红绿灯都只能有一个状态。但是红绿灯的输入模块接入了多个系统的监控数据，单个变更的质量监控任务可能同时存在多个原始监控。另外，每个监控项可能出现多个监控告警，每个监控告警关联的结果也可能各不相同。为了实现一单一状态的目标，红绿灯将点灯平台设计为“主灯-子灯-告警灯”的三层结构，如下图所示：

• 告警灯：告警灯之间状态相互独立。每个告警灯表示一条告警关联的结果。若变更范围内没有告警，则没有告警灯；
• 子灯：子灯之间状态也相互独立，每个子灯的状态由各监控项内的告警灯取或运算而得。即监控项内有一个告警灯亮红灯，对应子灯就亮红灯；若监控项内没有告警灯，子灯亮绿灯，否则子灯亮黄灯；
• 主灯：主灯只有一个，状态由各子灯取或运算计算而得。即有一个子灯亮红灯，主灯就亮红灯，若子灯均亮绿灯，则主灯也亮绿灯，否则主灯亮黄灯；

       变更过程中，变更人员只需关注主灯状态即可。子灯和告警灯主要用于后续的数据分析和逻辑优化，变更人员无需关注。

3.1 自动点灯

      变更过程中，红绿灯自动匹配变更范围内的监控告警，并从变更操作时间、操作空间和操作内容三个方面进行智能关联，依据关联结果自动点亮红灯或者黄灯。这种自动点灯的模式可以命中95%以上的变更异常，帮助变更人员快速决策回退，并缩短异常变更影响时长。

3.2 手动点灯

       尽管如此，系统自动点灯的模式仍然存在变更异常漏告的可能，例如变更导致操作设备以外的区域质量异常。由于告警关联是基于操作设备所在区域实现的，这种异地告警很难准确关联到异常变更。此外，当全网出现大范围质量异常时，红绿灯也很难精确定位出产生异常的变更。针对这些情况，值班人员可以使用红绿灯的手动点灯功能，点亮全网、指定区域或者指定客户关联的全部变更，也可以点亮特定变更的红灯，从而触发对应变更的快速回退功能。

4. 执行模块：按灯操作

经过前序模块的分析，红绿灯给出了当前变更行进状态的指示。变更需要按灯操作，才能在异常发生时真正做到缩短影响时长的目的。在变更过程中，变更人员及自动化变更系统会实时监控红绿灯状态，并依据不同状态下发变更操作指令。

• 绿灯执行：系统亮绿灯，表示当前变更正常。变更人员及自动化变更系统可以按照变更方案依次下发配置。
• 红灯回退：系统亮红灯，表示当前变更异常。变更人员及自动化变更系统会停止实施任务，快速回退，立即恢复业务。
• 黄灯暂停：系统亮黄灯，表示当前变更范围内出现质量异常。变更人员及自动化变更系统会暂停下发配置，规避继续操作可能带来的叠加风险。

运营效果

       变更红绿灯自搭建以来已经持续运作了两年多的时间，迄今为止已累计为数万单变更提供了监控服务。通过数据化运营分析手段，持续引入新的监控项，优化异常关联逻辑，使得红绿灯的点灯准确率和异常命中率得到了稳步提升。有了红绿灯的帮助，变更人员能够更早的发现变更异常，从而快速回退恢复业务，降低变更异常持续时间。截至当前，变更平均影响时长已下降超过90%。变更红绿灯也逐步成长为腾讯网络变更中不可或缺的工具。

总结

       随着腾讯云业务的高速发展，用户对基础网络稳定性的要求越来越高，红绿灯作为最后一道防线，将牢牢守住变更质量管控的底线。

       为了进一步保障基础网络的稳定性，提升变更质量管控的上限，更多质量管控方案也在同步演进，包括变更前的方案模板化、冲突检查、技术&业务双审批，变更中的精细化授权、自动化实施、全自动EOP，以及变更后的复盘和问题闭环等。整体方案贯穿变更的生命周期，全方位为腾讯网络的稳定运营保驾护航，后续将陆续给大家一一介绍。

欢迎关注公众帐号“鹅厂网事”，我们给你提供最新的行业动态信息、腾讯网络最接地气的干货分享。

注1：凡注明来自“鹅厂网事”的文字和图片等作品，版权均属于“深圳市腾讯计算机系统有限公司”所有，未经官方授权，不得使用，如有违反，一经查实，将保留追究权利；

注2：本文图片部分来自互联网，如涉及相关版权问题，请联系sandyshuang@tencent.com；

/

关

注

我

们

/

/ 鹅厂网事/

分享鹅厂网络的那些事