变更处理方法、系统、设备及计算机可读存储介质

技术领域

本申请涉及数据处理技术领域，尤其涉及一种变更处理方法、系统、设备及计算机可读存储介质。

背景技术

随着云原生时代的到来，互联网形成了微服务为主的分布式应用架构和基础设施分层解耦架构特点的云上网络结构，管理对象、组件规模不断增长，也带来更大数量的网络结构中节点的变更，如应用发布变更和基础设施维护变更。从历史生产事件的原因分析可以发现，一半以上的问题都是由发布与变更引发。变更频繁增加了可用性事件发生的概率，所以评估变更风险，及时阻断变更风险较大的变更，是保障应用与基础设施安全变更的关键。

随着业务增多，组织规模增大，应用发布与配置管理、基础设施资源池管理与系统版本管理，精细化的分工下衍生出了多个变更平台，上云后整体架构相较以往更复杂，目前通过专家经验、流程管控进行风险评估和控制的方式很难及时有效地发现和防范变更风险，而导致应用与基础设施的变更安全度低的问题。

综上，如何提高应用变更与基础设施变更的变更安全度是本技术领了亟待解决的技术问题。

发明内容

本申请的主要目的在于提供一种变更处理方法、系统、设备及计算机可读存储介质，旨在解决如何提高应用变更与基础设施变更的变更安全度的技术问题。

为实现上述目的，本申请提供一种变更处理方法，包括以下步骤：

获取网络结构中当前节点的变更事件对应的变更要素，其中，所述当前节点包括发起变更请求的网络节点，所述网络节点包括应用节点与基础设施节点；

基于所述变更要素对所述变更事件进行风险分析，得到风险分析结果，其中，所述风险分析结果包括阻断变更、变更风险级别、存在变更冲突、不存在变更冲突、操作风险中的一种或多种；

检测所述风险分析结果是否满足预设阻断条件，若是，则阻断所述当前节点的变更请求。

可选地，所述检测所述风险分析结果是否满足预设阻断条件的步骤，包括：

若所述风险分析结果包括阻断变更，则确定所述风险分析结果满足预设阻断条件；

若所述风险分析结果包括存在变更冲突，则确定所述风险分析结果满足预设阻断条件；

若所述风险分析结果包括变更风险级别，且所述变更风险级别大于预设级别阈值，则确定所述风险分析结果满足预设阻断条件。

可选地，所述变更要素包括变更对象，所述基于所述变更要素对所述变更事件进行风险分析的步骤，包括：

确定所述变更事件的变更时间，确定所述变更时间对应的时间窗口，获取所述时间窗口内针对所述变更对象的变更次数，其中，所述时间窗口为包括所述变更时间的时间范围；

若所述变更次数大于或等于预设阈值，则确定存在变更冲突；

若所述变更次数小于预设阈值，则确定不存在变更冲突。

可选地，所述网络结构包括多个可用性集，所述基于所述变更要素对所述变更事件进行风险分析的步骤，还包括：

对所述变更对象进行灰度检测，得到所述变更对象对应的变更约束条件，其中，所述变更约束条件包括约束变量与约束值，所述约束变量包括同时进行的变更对象数量；

基于所述多个可用性集确定所述变更对象所在的目标可用性集；

获取所述目标可用性集内的所有变更事件，基于所述所有变更事件确定所述约束变量的变量值；

若所述变量值与所述约束值匹配失败，则确定阻断变更。

可选地，所述变更要素还包括变更场景，所述基于所述变更要素对所述变更事件进行风险分析的步骤，还包括：

若所述变更场景包括应用发布，则确定与所述变更事件关联的影响业务，确定所述影响业务的业务重要度级别，确定所述业务重要度级别中的最高业务重要度级别，将所述最高业务重要度级别对应的风险级别作为变更风险级别；

若所述变更场景包括基础设施维护，则确定与所述变更事件关联的影响应用，所述影应用的应用重要度级别，确定所述应用重要度级别中的最高应用重要度级别，将所述最高应用重要度级别对应的风险级别作为变更风险级别。

可选地，所述变更要素还包括变更操作，所述基于所述变更要素对所述变更事件进行风险分析的步骤，还包括：

确定预设缺陷库中与所述变更操作匹配的目标变更操作，确定所述预设缺陷库中所述目标变更操作对应的目标操作风险，将所述目标操作风险作为所述变更事件存在的操作风险。

可选地，所述基于所述变更要素对所述当前节点的变更进行风险分析，得到风险分析结果的步骤之后，所述方法还包括：

输出所述变更风险结果，并确定预设变更控制列表中与所述变更要素匹配的目标变更要素，确定所述预设变更控制列表中所述目标变更要素对应的目标变更控制规则；

基于所述目标变更控制规则对所述变更事件进行变更风险控制，其中，所述目标控制规则包括窗消息提示、变更风险级别调级、变更阻断、强制通知、特殊关联审批中的一种或多种。

此外，为实现上述目的，本申请还提供一种变更处理系统，所述变更处理系统包括：

获取模块，用于获取网络结构中当前节点的变更要素，其中，所述当前节点包括发起变更请求的网络节点，所述变更要素包括变更对象；

风险分析模块，用于基于所述变更要素对所述当前节点的变更进行风险分析，得到风险分析结果，其中，所述风险分析结果包括阻断变更、变更风险级别、存在变更冲突、不存在变更冲突中的一种或多种；

检测模块，用于检测所述风险分析结果是否满足预设阻断条件，若是，则阻断所述当前节点的变更请求。

此外，为实现上述目的，本申请还提供一种变更处理设备，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的应用与基础设施的变更处理程序，所述应用与基础设施的变更处理程序被所述处理器执行时实现如上述的变更处理方法的步骤。

此外，为实现上述目的，本申请还提供一种计算机可读存储介质，计算机可读存储介质上存储有应用与基础设施的变更处理程序，应用与基础设施的变更处理程序被处理器执行时实现如上述的变更处理方法的步骤。

本申请获取网络结构中当前节点的变更事件对应的变更要素，其中，所述当前节点包括发起变更请求的网络节点，所述网络节点包括应用节点与基础设施节点；基于所述变更要素对所述变更事件进行风险分析，得到风险分析结果，其中，所述风险分析结果包括阻断变更、变更风险级别、存在变更冲突、不存在变更冲突、操作风险中的一种或多种；检测所述风险分析结果是否满足预设阻断条件，若是，则阻断所述当前节点的变更请求。如此，与现有技术中，人工评估变更风险进行变更风险管控的方式相比，本申请实施例基于变更要素智能地对当前节点变更进行风险分析，以量化变更的变更风险，得到变更风险分析结果，从而在确定应用与基础设置的变更存在完全隐患时，也即风险分析结果满足预设阻断条件时，可以及时阻断应用与基础设施的变更请求，不允许应用与基础设施的当次变更，从而提高了应用变更与基础设施变更的变更安全度。

附图说明

本申请目的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

图1是本申请实施例方案涉及的硬件运行环境的终端系统结构示意图；

图2为本申请变更处理方法第一实施例的流程示意图；

图3为风控系统系统架构示意图；

图4为本申请变更处理方法关联链路示意图；

图5为本申请变更处理方法操作风险分析流程示意图；

图6是本申请变更处理系统的系统模块示意图。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

参照图1，图1为本申请实施例方案涉及的硬件运行环境的变更处理设备结构示意图。

如图1所示，该变更处理设备可以包括：处理器1001，例如中央处理器(CentralProcessing Unit，CPU)，通信总线1002、用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如无线保真(WIreless-FIdelity，WI-FI)接口)。存储器1005可以是高速的随机存取存储器(RandomAccess Memory，RAM)存储器，也可以是稳定的非易失性存储器(Non-Volatile Memory，NVM)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储系统。

本领域技术人员可以理解，图1中示出的结构并不构成对变更处理设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种存储介质的存储器1005中可以包括操作系统、数据存储模块、网络通信模块、用户接口模块以及应用与基础设施的变更处理程序。

在图1所示的变更处理设备中，网络接口1004主要用于与其他设备进行数据通信；用户接口1003主要用于与用户进行数据交互；本申请变更处理设备中的处理器1001、存储器1005可以设置在变更处理设备中，所述变更处理设备通过处理器1001调用存储器1005中存储的应用与基础设施的变更处理程序，并执行本申请实施例提供的变更处理方法。

金融行业的根本任务是防范化解金融风险，业务的稳定运行至关重要。随着云原生时代的到来，金融IT(Information Technology，信息技术)形成了微服务为主的分布式应用架构和基础设施分层解耦架构特点的云上模式，管理对象、组件规模不断增长，也带来更大数量的应用发布变更和基础设施维护变更。从历史生产事件的原因分析可以发现，一半以上的问题都是由发布与变更引发。变更频繁增加了可用性事件发生的概率，所以防控变更风险，是提升业务稳定运行关键。

随着业务增多，组织规模增大，应用发布与配置管理、基础设施资源池管理与系统版本管理，精细化的分工下衍生出了多个变更平台，上云后整体架构相较以往更复杂，通过专家经验、流程管控进行风险评估和控制的方式很难发现和防范整体系统性风险，而且不同平台的变更风险管控也存在差异，当前亟需一个有效识别和管控变更风险的方式，以此保障业务稳定运行。

对于每次生产环境的操作，如应用发布、配置修改与基础设施维护操作如果缺乏风险管理，应急方案准备不充分，严重时可能导致业务不可用，甚至导致用户利益受损，可能存在的风险场景如下：

1、变更前业务影响风险分析不充分，对影响的应用范围不清晰不明确，无法合理制定变更方案；

2、变更前对象风险分析不充分，存在变更冲突缺乏沟通协调；

3、变更前影响分析不充分，底层变更有异常时，难以定位影响范围，上层应用告警时也难以快速定位问题；

4、变更前操作风险识别不充分，改动大或影响全局性的变更未分批及充分验证，出现问题时影响严重；

5、变更前未进行一致风险管控，业务出现异常的可能性更大。

基于上述问题，参照图2，图2为本申请变更处理方法第一实施例的流程示意图。需要说明的是，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

如图2所示，本申请提供一种变更处理方法，在变更处理方法的第一实施例中，变更处理方法包括以下步骤：

步骤S10，获取网络结构中当前节点的变更事件对应的变更要素，其中，所述当前节点包括发起变更请求的网络节点，所述网络节点包括应用节点与基础设施节点；

参照图3所示，本实施例变更处理方法可应用于风控系统，该风控系统包括风险分析模块与风险控制模块，将应用管理平台与基础设施变更平台接入该风控系统，建议以应用与基础设施的变更处理与控制能力为主建设统一风控系统。具体可以用于对云上应用与基础设施的变更进行风险分析。其中，应用为实现某个特定工作(通常为业务需求)而运行的计算机程序。基础设施为在云的底座部分，支撑应用和云服务运行的基础IT组件，包括但不限于容器、虚拟机、物理机、存储设备、网络设备、机房设施等等。变更(或称变更时间)可为生产环境参数发生变化的行为，包括但不限于设备增减、架构变化、配置改变、基础软件升级、参数调整、灾备演练等，生产环境为接入生产环境(包含业务网和办公网)的所有生产用途的设备及其承载的应用，包括但不限于机房基础设施、网络设备、存储、服务器、云平台、云服务、数据库、中间件、业务应用和运维支持应用等，无论其是否正式对外提供服务，均视同生产环境。

该网络结构具体可为接入风控系统的应用、基础设施、存储等设备基于彼此之前的关联关系而形成的网络。如参照图4所示，图4为示例性的网络结构，图4中该网络结构包括应用层与基础设施层，应用层为具体应用，每一应用设定其重要度级别，如普通应该、重要应用等，基础设施层包括云服务、IaaS(Infrastructure as a Service，基础服务设施)、基础设施，云服务包括PaaS(Platform as a Service，平台即服务)、其他云服务、数据库等，IaaS包括虚拟机，如ACS(Access Control Server，访问控制服务器)虚拟机、RS6K虚拟机、大数据虚拟机等，基础设备包括交换机、路由器、存储、ACS物理机、RS6K物理机等等。

该变更要素包括但不限于变更场景、变更操作与变更对象，如还可以包括变更人、变更时间、变更平台、变更类型(极简、标准、普通、重要、重大)等等。变更类型的一种可能分类方式可如下表一所示。

表一

步骤S20，基于所述变更要素对所述变更事件进行风险分析，得到风险分析结果，其中，所述风险分析结果包括阻断变更、变更风险级别、存在变更冲突、不存在变更冲突、操作风险中的一种或多种；

基于变更要素对变更进行风险分析，具体地，可从每一变更要素的维度评估该变更的变更风险，评估该变更在每一变更要素维度可能存在的变更风险，从而基于预设规则聚合每一变更要素维度的变更风险得到该变更的风险分析结果。该预设规则可以任意规则，如直接聚合、取每一变更要素维度中变更风险级别最高的变更风险级别作为该变更最终的变更风险级别等等，并实施例并不做具体限制。

可以理解地是，若从在某一个变更要素维度风险分析得到不允许变更，则可以不在继续进行其他维度的风险分析，以减少风险分析时长，提高风险分析效率。

进一步地，可将风险分析结果发送给相关人员，以供相关人员查看风险分析结果后，决定是否进行变更、是否需要走变更审批流程、以及具体需要走哪些变更审批流程、是否更改变更时间等等，以管控该变更变更风险。此外，可以预先设置不同的风险分析结果关联的变更审批流程，得到风险分析结果后，若存在与该风险分析结果关联的变更审批流程，则进入至该变更审批流程，通知相关的审批人员进行流程审批，以智能化发起审批流程，提高审批效率，进而提高变更风险管控的及时性。

该风险分析结果包括但不限于是否允许变更、变更风险级别、是否存在变更冲突，如还可以包括风险点、该变更影响的应用或业务等等。

在一种可能的实施方式中，所述变更要素包括变更场景、变更对象与变更操作，所述基于所述变更要素对所述变更事件进行风险分析的步骤，包括：

步骤S201，基于所述变更对象对所述变更事件进行变更对象风险分析，得到对象风险分析结果；

针对变更对象进行风险分析具体可包括变更冲突检测和/或灰度检测。Y优选地，本实施例中针对变更对象进行变更冲突检测和灰度检测，可以理解地是，还可以设置针对变更对象的其他方面的检测。

变更冲突检测同一时间是否存在相同对象的变更，防止操作人互不知道的情况下出现变更冲突；灰度检测判断变更是否遵守了灰度原则，对于能灰度的对象，拒绝非灰度变更。

针对变更对象冲突检测方案可基于各平台的变更申请记录包含的对象要素及时间要素判别是否存在其他变更，若存在同一对象在相同时间窗口的变更，则将冲突信息通知给后申请人，确认是否冲突以调整变更时间窗口；变更冲突可通过前置工作规避，针对重要重大类型的变更需要提前预约变更窗口，提前进行Preview(预约)会议；

针对变更对象的灰度检测通过三个模块实现：

1、灰度策略管理。提供灰度策略库供用户创建及维护，支持基于CMDB(Configuration Management Database，配置管理数据库)CI(Configuration Item，配置项)的属性组合、标签，对Region(区域)、MU、集群、FD、服务器、虚拟机等层面的高可用约束进行定义。

2、计算引擎。依据变更灰度策略库，在指定的领域内，计算用户提交的变更是否符合灰度策略的要求。

3、自动分批。针对用户选择的变更对象及操作，依据灰度策略库，自动给出分批次方案。

基于此，针对变更对象进行变更冲突检测及灰度检测，将变更冲突检测的检测结果与灰度检测的检测结果作为对象风险分析结果。需要说明地是，变更冲突检测的检测结果可为是否存在变更冲突，进一步地，存在变更冲突时，还可以包括具体与该变更存在冲突的变更的变更要素信息，如可以包括变更平台、变更时间、变更人等等。灰度检测的检测结果可为是否阻断变更，具体地不满足灰度策略时，阻断变更，反之，则不阻断变更，也即允许变更，进一地地，阻断变更时，该灰度检测的检测结果还可以具体包括该变更(或称变更事件)具体不满足的灰度策略。

步骤S202，基于所述变更场景对所述变更事件进行业务影响风险分析，得到影响风险分析结果；

在云上，应用架构为多实例部署，且随时可漂移，所以应用底层的基础设施并非固定不变的。为了管理应用与基础设施间的关系，可通过定期数据采集来完成，形成物理服务器、虚拟机、容器平台、应用系统、数据库等的配置数据模型并建立相互间关联关系。

变更的业务影响分析旨在识别某个变更对象是否关联重要应用和/或重要业务(或称服务单元)，其中，服务单元为应用具体实现业务功能的功能模块，如对于一个手机银行应用，余额查询、电子工资单查询、转账记录查询等等为其具体地服务单元，以此来判定变更的风险级别。根据应用间及应用与基础设施的连接或互访关系有三个分析维度：1、底层资源与承载应用的影响分析，2、业务链路上关联应用的影响分析，3、使用数据服务的应用的影响分析(例如跑批类应用)，无论是应用发布或是基础设施维护变更场景，都可以通过这三种关联关系进行影响分析。

需要说明地是，可以预先设定每一应用的重要级别，以及同一应用中不同服务单元的重要级别，重要级别越高，则应用与服务单元越重要。

基于此，对于应用发布或是基础设施维护变更场景，基于上述的关联关系进行业务影响风险分析，确定该变更关联的应用和/或业务。进一步获取关联的应用和/或关联的业务的重要级别，基于其关联的应用和/或业务的重要级别，从而可以评估该变更的变更风险级别，具体地，可以以应用和/或业务的重要级别中最高的重要级别评估该变更的变更风险级别，可以预设不同的重要级别与变更风险级别之间的对应关系，基于此对应关系确定变更风险级别。需要说明地是，变更风险级别越高，则该变更的变更风险越大，变更风险级别可与重要级别呈正相关。

进一步地，还可以综合关联的应用和/或关联的业务的重要级别以及该变更的变更时间对应的交易量评估变更变更风险级别，该交易量可基于关联应用的历史访问量、历史查询量进行评估确定。可以基于交易量对进行变更风险调级，如假设一变更关联的应用中重要级别最高的应用为应用m，对应的变更风险级别为B，该变更的变更时间为零点，在两点时间段应用m的交易量为5，则可以对降低变更风险级别，如可以变更风险级别可以调整为C，其中，C变更风险级别低于B变更风险级别，从而，综合交易量与关联的应用和/或关联的业务的重要级别因素评估变更风险级别，可以提高变更风险级别评估的准确度。

该影响风险分析结果可以包括变更风险级别，还可以包括与该变更关联的应用和/或业务，以供相关人员查看该变更具体会影响哪些应用与业务，从而对影响的应用与业务可以进行相应的变更管控，扩大了变更管控的范围，进一步提高了变更管控的有效性。

步骤S203，基于所述变更操作对所述变更事件进行变更操作风险分析，得到操作风险分析结果；

变更操作风险为针对不同对象执行不同操作可能会触发的风险，通过测试或历史生产事件总结经验建立设备与操作对应的缺陷库(风险库)，基于该缺陷库可以确定该变更操作可能存在的操作风险，可将该操作风险作为操作风险分析结果。

步骤S204，依据所述对象风险分析结果、所述影响风险分析结果与所述操作风险分析结果，生成所述变更的风险分析结果。

具体地，基于预设规则分析对象风险分析结果、影响风险分析结果与操作风险分析结果，得到风险分析结果。如可以直接聚合对象风险分析结果、影响风险分析结果与操作风险分析结果得到风险分析结果。

需要说明地是，需要说明的是，虽然在上述步骤中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，如对于步骤S201～步骤S203本实例并不具体地限制其执行顺序，且任意步骤中分析得到阻断变更这一风险分析结果时，可不在执行后续步骤，直接执行步骤S204，此时风险分析结果包括阻断变更，具体地还可以包括阻断变更的原因，以提高风险分析效率。

步骤S30，检测所述风险分析结果是否满足预设阻断条件，若是，则阻断所述当前节点的变更请求。

该预设阻断条件可为基于实际情况设置的任意条件，如风险分析结果包括阻断变更等等，风险分析结果满足预设阻断条件，则阻断当前节点的变更请求，进一步地可将输出该风险分析结果，以便相关人员基于此风险分析结果管控变更风险，风险分析结果不满足预设阻断条件，可以进行当前节点的变更操作，也可以可将输出该风险分析结果，以便相关人员查看该风险分析结果后确定是否进行变更。此外，还可以预设不同风险分析结果关联的审批流程，确定与该风险分析关联的审批流程，进入该审批流程进行审批，并通知相关人员进行审批，审批通过后进行变更，从而实现变更的智能化审批。

本实施例获取网络结构中当前节点的变更事件对应的变更要素，其中，所述当前节点包括发起变更请求的网络节点，所述网络节点包括应用节点与基础设施节点；基于所述变更要素对所述变更事件进行风险分析，得到风险分析结果，其中，所述风险分析结果包括阻断变更、变更风险级别、存在变更冲突、不存在变更冲突、操作风险中的一种或多种；检测所述风险分析结果是否满足预设阻断条件，若是，则阻断所述当前节点的变更请求。如此，与现有技术中，人工评估变更风险进行变更风险管控的方式相比，本实施例基于变更要素智能地对当前节点变更进行风险分析，以量化变更的变更风险，得到变更风险分析结果，从而在确定应用与基础设置的变更存在完全隐患时，也即风险分析结果满足预设阻断条件时，可以及时阻断应用与基础设施的变更请求，不允许应用与基础设施的当次变更，从而提高了应用变更与基础设施变更的变更安全度。

进一步地，基于上述本申请的第一实施例，提出本申请变更处理方法的第二实施例，与上述第一实施例相同或相似的内容，可以参考上文介绍，后续不再赘述。在本实施例中，所述检测所述风险分析结果是否满足预设阻断条件的步骤，包括：

步骤A10，若所述风险分析结果包括阻断变更，则确定所述风险分析结果满足预设阻断条件；

步骤A20，若所述风险分析结果包括存在变更冲突，则确定所述风险分析结果满足预设阻断条件；

步骤A30，若所述风险分析结果包括变更风险级别，且所述变更风险级别大于预设级别阈值，则确定所述风险分析结果满足预设阻断条件。

该预设级别阈值可为提前设置的级别阈值，如假设有五级变更风险级别分别为【A、B、C、D、E】，且从A到E变更风险级别依次增高，假设级别阈值为D，则变更风险级别为E时，确定风险分析结果满足预设阻断条件。

本实施例中，风险分析结果包括阻断变更或存在变更冲突或更风险级别大于预设级别阈值时，也就该变更事件存在较大的变更风险，此时阻断该变更事件，从而提高了变更安全性。

在一种可能的实施方式中，所述变更要素包括变更对象，所述基于所述变更要素对所述变更事件进行风险分析的步骤，包括：

步骤B10，确定所述变更事件的变更时间，确定所述变更时间对应的时间窗口，获取所述时间窗口内针对所述变更对象的变更次数，其中，所述时间窗口为包括所述变更时间的时间范围；

步骤B20，若所述变更次数大于或等于预设阈值，则确定存在变更冲突；

步骤B30，若所述变更次数小于预设阈值，则确定不存在变更冲突。

该时间窗口可基于变更时间确定，如假设变更时间为12点，变更所需的平均变更时长为一小时，则该时间窗口可为11点到13点，或者该变更具有排斥性，从该变更开始的六小时内不允许其他变更，则该时间窗口可为6点到18，在或者变更时间为10点到12点，变更所需的平均变更时长为一小时，则时间窗口可为9点到13点。由此，可基于预设规则确定变更时间对应的时间窗口。

可基于各平台的变更申请记录包含的对象要素及时间要素判别针对该变更对象在此时间窗口内的变更次数，该变更次数可为除当前变更之外与当前变更存在变更冲突的其他变更的变更次数，此时预设阈值可为1，为便于后续阐述与说明，与当前变更存在变更冲突的其他变更可记为冲突变更，变更次数也可为包括当前变更与冲突变更，此时预设阈值可为2。

需要说明地是，变更次数小于预设阈值时，可对象风险分析结果可包括不存在变更冲突。

进一步地，还可以将冲突信息通知给后变更的变更申请人，确认是否冲突以调整变更时间窗口。

本实施例中，基于变更的对象因素与时间因素判别该变更是否存在变更冲突，保证了变更冲突判别的准确性与有效性，同时进行变更冲突检测，可以避免变更冲突而导致变更失败的风险。

在一种可能的实施方式中，所述网络结构包括多个可用性集，所述基于所述变更要素对所述变更事件进行风险分析的步骤，还包括：

步骤C10，对所述变更对象进行灰度检测，得到所述变更对象对应的变更约束条件，其中，所述变更约束条件包括约束变量与约束值，所述约束变量包括同时进行的变更对象数量；

步骤C20，基于所述多个可用性集确定所述变更对象所在的目标可用性集；

步骤C30，获取所述目标可用性集内的所有变更事件，基于所述所有变更事件确定所述约束变量的变量值；

步骤C40，若所述变量值与所述约束值匹配失败，则确定阻断变更。

可以基于灰度策略预设灰度规则，灰度策略配置信息包括：ID、策略名称、策略描述、策略优先级、策略创建时间、策略更新时间、操作对象类型、可用性集、灰度规则、策略作者、策略是否激活。

每一灰度规则的字段包括：操作对象类型(CI_TYPE)、可用性集(AVAIL_DOM)、筛选条件(FILTER_BY)、约束范围(RESTRAIN_SCOPE)、约束变量(RESTRAIN_VAR)、约束值(RESTRAIN_VALUE)。一示例性灰度规则的每一字段的字段表达式可参照表二所示，该灰度规则的变更约束条件为：同一MU下，同时变更物理机数量，不超过MU总物理机数量的50％。

/>

表二

基于所有灰度规则对对更对象进行灰度检测，具体地，可基于每一灰度规则的操作对象类型字段可以确定是否存在与该变更对象匹配的目标灰度规则，若存在，则获取灰度规则的AVAIL_DOM字段的字段值，以确定目标灰度规则的可用性领域，以此可用性集领域的领域类型，确定变更对象所在的目标可用性集，如假设目标灰度规则中可用性领域为MU，则确定变更对象所在的MU，又假设目标灰度规则中可用性领域为AZ，则确定变更对象所在的AZ。

该变更约束条件可为目标灰度规则的变更约束条件，具体地可基于灰度规则的所有字段确定该目标灰度规则的目标变更约束条件，即同一可用性集领域同时进行的变更对象为操作对象类型的数量在约束值的约束范围内，进而检测该变更是否满足此变更约束条件，如不满足，则对象风险分析结果包括阻断变更。

本实施例中，对变更进程灰度检测，灰度检测判断变更是否遵守了灰度原则，对于能灰度的对象，拒绝非灰度变更，避免了非灰度变更的现象。

在一种可能的实施方式中，所述变更要素还包括变更场景，所述基于所述变更要素对所述变更事件进行风险分析的步骤，还包括：

步骤D10，若所述变更场景包括应用发布，则确定与所述变更事件关联的影响业务，确定所述影响业务的业务重要度级别，确定所述业务重要度级别中的最高业务重要度级别，将所述最高业务重要度级别对应的风险级别作为变更风险级别；

与变更事件关联的影响业务具体可为与变更事件的变更对象关联的影响业务。参照图4所示，可以基于应用、基础设施的关联关系预先建立关联链路。

应用发布场景，通过关联链路追踪确定应用上下游关系，分析应用发布影响的业务码关联的应用，明确本次应用发布对其他业务的影响，也即确定变更对象关联的影响业务，进一步可综合业务重要度级别与交易量计算判断变更风险级别。每一业务的业务重要度级别可预先设定。

步骤D20，若所述变更场景包括基础设施维护，则确定与所述变更事件关联的影响应用，所述影应用的应用重要度级别，确定所述应用重要度级别中的最高应用重要度级别，将所述最高应用重要度级别对应的风险级别作为变更风险级别。

与变更事件关联的影响应用具体可为与变更事件的变更对象关联的影响应用。

基础设施维护场景，也可以基于预先建立的关联链路追踪关联的影响应用。通过物理机变更详细说明如何进行关联影响分析。通过物理机和虚机、虚机与容器集群、虚拟机与云服务集群、物理机与云服务集群部署关系建立关联，各对象与服务单元的关系通过访问日志采集并建立关联，服务单元与系统子系统根据服务单元建立时录入的配置数据建立关联，数据库与日终批量应用关联关系。最终构建模型间的关系链路如下：

(1)物理机-虚拟机-容器集群-命名空间-容器应用-服务单元-系统子系统；

(2)物理机-虚拟机-云服务集群-服务单元-系统子系统；

(3)物理机-虚拟机-服务单元-系统子系统；

(4)物理机-云服务集群-服务单元-系统子系统；

(5)物理数据库-物理数据库-逻辑数据库-日终批量作业-系统子系统。

通过以上链路对变更的物理机进行数据探索，针对命中的应用(或称系统)及其时段对应的交易量评估本次变更风险级别。

本实施例中，在变更前对分析业务影响分析，可明确变更影响的应用范围不清晰，从而合理制定变更方案。

本实施例中，基于关联链路可以确定本次变更影响的业务或应用，从而可以量化变更的影响范围，进一步量化变更风险级别。

在一种可能的实施方式中，所述变更要素还包括变更操作，所述基于所述变更要素对所述变更事件进行风险分析的步骤，还包括：

步骤E10，确定预设缺陷库中与所述变更操作匹配的目标变更操作，确定所述预设缺陷库中所述目标变更操作对应的目标操作风险，将所述目标操作风险作为所述变更事件存在的操作风险。

变更操作风险为针对不同对象执行不同操作可能会触发的风险，通过测试或历史生产事件总结经验建立设备与操作对应的缺陷库(风险库)，变更申请人在提单申请时查看风险提示确认操作风险。

以网络设备为变更对象的变更为例，详细说明操作风险分析流程。参照图5所示，用户选择操作对象(网络设备)和操作，选择原子，该原子为一个操作原子，认为该原子为无法在细化的操作，系统后台通过设备查询缺陷库查询操作风险，具体可基于对象mip(modelip，模型+唯一键)列表，其中每一变更对象可以模型+唯一键表示，按mip查询缺陷库，得到操作风险数据，并返回参数设备-操作-风险，进一步可展示操作风险结果，手工操作由用户选择具体变更操作后系统自动展示对应风险点，完成操作风险分析，进一步地，用户提交变更后，可进入孺牛审批流程，以审批操作风险内容。

在一种可能的实施方式中，所述基于所述变更要素对所述当前节点的变更进行风险分析，得到风险分析结果的步骤之后，所述方法还包括：

步骤F10，输出所述变更风险结果，并确定预设变更控制列表中与所述变更要素匹配的目标变更要素，确定所述预设变更控制列表中所述目标变更要素对应的目标变更控制规则；

步骤F20，基于所述目标变更控制规则对所述变更事件进行变更风险控制，其中，所述目标控制规则包括窗消息提示、变更风险级别调级、变更阻断、强制通知、特殊关联审批中的一种或多种。

通过控制变更要素，实现变更风险控制。可根据变更涉及的人员、时间、对象、操作、影响分析等变更要素，配置变更控制规则。规则可配置：弹窗消息提示、变更风险级别调级、变更阻断、强制通知、特殊关联审批等控制措施。

1、人员策略。(1)新员工。根据员工入职时间，少于1年判定为新员工。(2)组织架构。可按照组织架构进行中心、团队、室进行配置。(3)可根据员工id进行变更限制。

2、时间策略。(1)时间段。根据配置的特定时间段，进行变更控制。(2)周期时间。支持配置crontab表达式，进行周期时间段的变更控制。

3、对象策略。(1)可配置变更对象的属性，如主机名、数据库名、资产id、系统级别进行分类变更控制；(2)可根据对象标签进行配置。通过标签，批量进行配置变更管控对象；(3)根据变更对象不同操作冲突进行限制配置；(4)根据灰度策略进行配置。

4、操作策略。(1)可配置某个具体的变更原子。(2)可配置变更原子的风险级别，实现不同级别变更操作的个性化控制。(3)可根据原子执行次数高于或低于某个阈值的统计数据命中要控制的变更原子。(4)可配置控制命中的操作风险数量。

5、影响分析。(1)可配置根据变更影响分析结论的影响对象，进行关联影响变更的控制。

每一变更要素均可匹配预设变更控制列表中是否存在与其匹配的目标变更要素，进而可以确定所有变更要素中与预设变更控制列表中匹配的目标变更要素，确定每一目标变更要素对应的目标控制规则，进行风险管控，从而在变更前进行一致风险管控，避免业务出现异常。

此外，参照图6，本申请还提供一种变更处理系统，所述变更处理系统，包括：

获取模块10，用于获取网络结构中当前节点的变更要素，其中，所述当前节点包括发起变更请求的网络节点，所述变更要素包括变更对象；

风险分析模块20，用于基于所述变更要素对所述当前节点的变更进行风险分析，得到风险分析结果，其中，所述风险分析结果包括阻断变更、变更风险级别、存在变更冲突、不存在变更冲突中的一种或多种；

检测模块30，用于检测所述风险分析结果是否满足预设阻断条件，若是，则阻断所述当前节点的变更请求。

此外，本申请实施例还提出一种变更处理设备，变更处理设备括存储器、处理器及存储在所述存储器上并可在所述处理器上执行的应用与基础设施的变更处理程序，所述应用与基础设施的变更处理程序被所述处理器执行时实现如上述的变更处理方法的步骤。

本申请变更处理设备具体实施方式与上述变更处理方法各实施例基本相同，在此不再赘述。

此外，为实现上述目的，本申请还提供一种计算机可读存储介质，计算机可读存储介质上存储有应用与基础设施的变更处理程序，应用与基础设施的变更处理程序被处理器执行时实现如上述的变更处理方法的步骤。

本申请计算机可读存储介质具体实施方式与上述变更处理方法各实施例基本相同，在此不再赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本申请各个实施例所述的方法。

以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。