CSDI summit 中国软件研发管理行业技术峰会（Software development management industry technology summit）由国内专业咨询机构百林哲匠心打造的软件行业技术领域顶级盛会。

于 2022 年 9 月 16-18 日举办。协同国内外知名软件、互联网等企业研发一线技术专家，从 AI 和大数据、产业变革、技术创新、生态发展、业务创新、商业模式等方面重点研讨软件研发趋势，秉承干货案例、深度分享、情景教学、沙盘演练、以本土化选题适应城市化需求。

我司同学王月凡于 9 月 18 日进行内容分享“智能化变更防控方法、架构与组织实践”，以下为演讲实录；

以下内容来自微信公众号：蚂蚁技术风险 TRaaS

“

我是蚂蚁集团智能变更和 AIOps 的负责人-王月凡，也曾负责蚂蚁的金融网络 SRE 的一些工作。同时在高可用领域也沉淀了 5 年左右，主导建设了智能变更、巡检平台、无痛技术升级等多款高可用技术平台，也拥有大规模分布式集群下的稳定性和高可用实战经验和技术。

今天给大家带来的是在 AIOps 这个场景下，一些实际的应用场景，就关于智能变更，应急、智能容量等后面有机会再给大家介绍。今天主要是讲在 AIOps 的场景下，智能的变更防控的内容。

接下来我会从三个方面去讲：一是变更防控的价值和问题，第二部分是变更防控的方法和架构，以及在智能化变更防控里面的一些实践。

一.变更防控的价值

首先看第一部分，我们做技术风险或者 SRE 稳定性，最终的目的是要降低由变更而带来的线上稳定性风险。蚂蚁集团内部，包括外部各家公司，对于稳定性风险的原因的分析，变更执行和编码的问题占了一半以上，变更其实是导致线上稳定性问题的主要引发因素。如何进行变更风险防控，从而降低整个企业的稳定性风险，这是一个比较重要的命题。

同时，整个系统的分布式复杂度是越来越高的，任何系统设计都依赖于组织间的关系，这是符合康威定律的，就是组织架构决定生产关系。所以像亚马逊、NETFLIX，包括蚂蚁集团，整个系统的复杂度也是会逐渐升高的，随着业务的发展和组织逐渐的扩大，对于变更的问题也会尤其严重。

所以基本上业界有一个共识，就是没有变更，就没有伤害，防控住变更的风险，基本上稳定性的问题就解决了一半以上，这也是稳定性领域的一个共识。

虽然说故障的根因有很多，可能因为代码有问题，或者系统某些容量、资源、流量的突增带来的问题，但往往这些问题触发的源头，都是由变更而带来的。所以怎么样降低变更带来的风险，是变更防控的价值和意义。对于一个公司，特别是大的企业，其实对于稳定性的容忍程度也是比较低的，所以变更这个大头的引发故障的因素，我们需要去考虑怎么样解决掉。

大的趋势是线上的故障引发，变更会占很大的比例，故障原因虽然说有各种各样，但是往往故障的源头都是由变更导致的。其次就是日益复杂的微服务分布式系统，也会导致团队之间的协作关系日益复杂，这也符合康威定律，因为组织架构决定生产关系。

同时对于企业来说，为了提升整个企业的市场竞争力，提升企业的协同效率，整个企业的发展模式会让变更操作越发高频，且团队是处于离散状态的。在整个趋势里面，之前可能是技术研发团队会追求敏捷开发、DevOps、持续集成/持续交付，能够快速地把业务上的一些价值都面向用户的想法，业务上的演进，快速在技术研发团队落地。然后通过敏捷开发、DevOps、持续集成/持续交付的方式，快速地把一个理念或者想法或者业务上的新的场景，快速地交付给用户去使用。技术团队本身也会追求一个高效和敏捷，所以整个软件开发流程，从最开始的瀑布式的开发模式，到现在追求敏捷开发、DevOps、持续集成/持续交付这样的模式。

这种模式天然会带来问题，就是整个技术产品从研发到上线整个过程中，它的周期会非常短。像再往前的 PC 时代，一个 Windows 软件的开发周期或者发布周期，一般是以年为单位、以季度为单位去更新小的迭代或版本。但在互联网时代，整个软件开发的频率，包括 APP、小程序，开发频率是非常高的，可能 7 天或一周就能开发一个。像最近比较火的“羊了个羊”这样的小游戏给大家去体验和使用，这也是整个技术团队会追求敏捷和效率的快速交付。

在运营团队，也会追求高效的配置变更和生效，比如阿里、腾讯、字节这样的公司，每天都会进行一些不同类型的运营营销活动，这些活动会面向用户去透出一些活动的规则，包括运营的一些策略，发红包、发奖券等，这些都是运营的手段。而这些运营的配置，都是由运营团队的同学去面向用户配置、发布。对于整个企业而言，从最传统的可能只有一个系统运维的团队，主要负责系统的发布部署，系统的运维变更，逐渐会演进到一方面是多个研发团队会在 DevOps、敏捷开发这种模式下，快速地研发和迭代系统的发布部署，同时也会有 SRE 团队做系统的运维。还会存在很多业务运维团队，他们会去做运营活动的变更，营销配置的变更等等。

从最开始单一的运维团队，可以执行生产和操作，逐渐演化为从研发、SRE、业务运营等团队，都可以具备线上变更操作。这其实会从最开始只需要管控住运维团队不要对线上进行变更，就能防控住某些时期对于线上稳定性的要求。到现在整个变更的复杂度以及操作越来越高频，越来越分散，对于变更这个事情的管控难度也会日益增加。从最开始管控运维团队，就演变成管控研发、SRE、业务运营等团队，要对他们变更进行管控，这也是当前企业在市场竞争上，为了提升企业效率而引发的一些变更操作的趋势和演进的方向。所以变更的防控是非常重要的，并且是需要持续演进的一个技术方向。

简单总结一下面临变更的风险和挑战，当前互联网公司、科技公司面临的挑战主要有：

第一个，互相交错的组织协同模式。因为康威定律，组织架构决定生产关系，当前云原生、分布式、微服务这样的模式下，大家会把系统服务拆分成各个微服务组件，每个微服务组件会相互提供一些调用关系，这样会决定整个组织架构的分布，谁负责这个微服务系统的开发和运维，DevOps 模式下，也会让研发团队和业务团队做一个区分。

第二个是错综复杂的分布式微服务链路。比如一个对外的用户付款系统，整个链路会涉及到几十个上百个微服务系统，每个微服务系统都有很多可以进行变更的操作入口，除了传统的运维发布变更之外，还会有一些营销活动配置的变更对它进行操作。

第三个是对于稳定性问题的容忍度。现在大部分的互联网公司、科技公司，一旦出现稳定性问题，就会面临社会比较大的舆论。对于整个社会的使用，因为互联网已经逐渐变成了社会运行的一个基础设施，当这个基础设施出现一些稳定性问题的时候，大家的生活可能会受到一些影响。拿支付宝举例，当它出现一些问题的时候，会导致大家去买票或者食堂付钱的时候出现问题。前段时间成都健康码其实也有稳定性问题，会影响大家核酸检测，这是整个社会对于稳定性问题的容忍度。

再比如 Facebook、微软、亚马逊，其实也会经常出现宕机和稳定性的问题，可能是各种原因导致的，比如网络、硬件设备，以及变更导致。

对于企业来说，如何进行变更防控是一个比较大的命题蚂蚁非常重视。很多企业把变更风险问题，主要是通过对于人和流程进行管理，常见的比如聚焦于做变更流程的设计，变更计划的制定，由谁来审批，过程中的应急 On call 如何协作，其实这里是有一定成本的，你要对做变更的人员进行良好的培训。但就算你对他进行良好的培训，其实也没办法避免因为人的疏忽操作而导致的一些故障。纵观历史上很多变更引发的故障，几乎都是人的疏忽和误操作而导致。

所以今天我们讨论的更多是怎样通过系统化的技术手段，系统化地管控住变更的风险，流程手段我们就不讨论。流程手段方面，比如在变更流程上增加一些审批的环节、风险评估的环节，同时把整个变更的流程合理地设计好，由谁去变更，谁去做审批，对人进行管控可以解决问题。但今天我们主要讨论的还是在技术层面上，怎样通过技术的方法和手段，去解决变更带来的风险问题。

二.变更防控方法与架构

这部分主要讨论一下如何在一个复杂的组织关系下，变更的风险防控切面，能够做到剥离变更的执行与防控。

首先“变更”这个词，就如何定义变更，在 AIOps 领域，这个 Ops 更多是指运维，或者叫智能运维。在变更领域，变更这个理念或者概念，比运维的概念要大一些。

变更的定义：由企业内部人员触发的任何导致 IT 服务状态发生变化的行为。它包含了运维这个领域。对于 Linux 来说它的时钟滴答其实不是一个变更，只是一个常态的系统行为。用户的转账也不是，这是用户自己的界面操作。但是运营同学的一个运营配置操作和运维同学下线了一台服务器，这两个就属于变更。

变更在这里的定义，跟 ITIL V4 标准里面的变更定义差不多一个意思，ITIL 里面的定义是“添加、修改或删除任何可能对 IT 服务产生影响的内容”。这里增加了一个定义，“是由企业内部人员”，因为往往变更的操作，不会开放给企业外部人员，所以我们的定义是“企业内部人员触发的任何导致 IT 服务状态发生变化的一些行为”，这个含义和 ITIL 的标准是一致的。这是怎么去定义变更。

而智能运维或者运维变更，其实是变更里面很小的一个领域，主要包含像系统发布部署，运维操作，重启，扩缩容这样一些变更。而这里定义的变更就是更广义上的一个企业的变更，对于 IT 服务状态可能发生变化行为的这些操作，统称为变更。这是对于“变更”这个词的定义。

变更防控的方法与组织关系。在整个微服务的分布式架构下，平台开发跟业务团队的业务平台是强挂钩的，所以这些所谓的做变更操作的平台，会分散到各个团队，研发团队会有，业务运营团队会有，运维团队也会有，这些团队都有一些对应的平台和能力，能够做到对于线上的 IT 服务状态发生变化的一些行为和操作。

举个常见的例子，在业务运营的变更平台，通常可能会有以下这几类：

第一个是做运营活动配置相关的；可能近期要做 6.18 活动，要上架一个活动配置，或者要投放一个广告，或者要做一些营销活动下放一些奖券，或者对于风控要进行管控策略的下发，这些属于业务类的一些变更平台或者变更配置。

第二个是应用系统内的运维变更平台；这部分跟传统的系统运维或者智能运维相关，包括系统的代码发布、重启、扩缩容、系统压测，传统的 SQL 变更。再往下就是偏中间件，网络、DNS 的变更、DB 硬件的变更，这里我不赘述。

整体这些其实都是属于可以对线上 IT 的服务状态发生改变的行为和操作的入口，这些入口暴露出来就相当于有很多口子，有很多人能够通过这些入口去对线上的稳定性造成影响，可能不是主观意识上主动要去造成的，就是因为日常工作中的误操作，或者没有注意，就疏忽了一些点，导致一些问题。所以我们今天更多讨论的是怎么样从系统的角度去彻底规避掉这些问题，管控住这些问题。

在蚂蚁这边，我们有一套 OpsCloud 系统，这个系统提供了变更风险的防控切面，如图所示，会把各个变更平台的变更操作，通过 OpsCloud 的变更风险防控切面接入进来，再把这些变更平台的变更信息进行标准化。所有的变更场景，可能在原本的变更平台有各种各样的定义、各种各样的配置、各种各样的描述方式，但是它通过这个变更风险防控的切面接入进来之后，就会提供一个标准的信息化结构，通过主谓宾的方式去描述这个变更是谁在做什么变更，做的东西是什么。

同时接入到这个风险管控切面之后，到后面就由风险变更的防控团队，通常是由 SRE 或者质量团队，有时候是线上稳定性或者质量负责的团队，他们针对这些变更进行一个实时的风险防控的动作；

这些动作包含：第一个是变更计划，刚才提到对变更信息的标准化；第二个是变更灰度和封闭策略，就你这个变更怎么样逐步验证，怎么样逐步发现线上的风险；

第二就是变更感知，我怎样能够实时地感知到谁正在对线上的某一个环节、某一个环境、某一个机器或某一个业务做变更操作，这个感知也分为变更事件订阅和搜索，订阅就是主动订阅到这个变更事件的发生，搜索就是在出现了线上故障或问题的时候，能够快速检索到，到底当前是哪个人在做什么样的操作，可能会对线上的故障产生影响。这是变更的整个防控的两大事情。

第三个就是变更的分析，包括变更影响面分析和变更风险分析，变更影响面分析是整个变更对于线上的哪些业务、哪些用户、哪些系统产生影响；变更风险分析就是这个变更这样去做会有哪些风险，包括稳定性风险、会不会产生资金安全的风险，会不会产生一些舆论风险等等。

变更防御是在整个变更执行期间，有一个变更防控的三板斧 pipeline，这个 pipeline 会在变更执行分批阶段做前后规则的实时校验，这个实时校验会及时发现这个变更对于线上生产环境、系统、业务上的一些影响，如果发现有任何异常，会实时地做异常的阻断，让这个变更能做自动的停止。

变更的止损，就是当发现异常之后，能进行变更的快速回滚和恢复。通过两种方式，第一种方式是变更本身的回滚操作，把这个变更给回退掉，密箱做掉；第二种方式是通过快速的切流和降级，来快速恢复业务，先降低变更对于这个业务的影响，确保业务的可用。

这里的方法和架构主要有两个点可以提炼出来：第一个是对于这么多变更平台，如果每一个变更平台都针对性地去做一些防控的动作、技术上的演进，其实是非常复杂的。这里列的可能就只有这十几个、几十个，但实际情况下可能有上百个、上千个这样的变更平台以及变更场景，每个变更平台、变更场景的描述语义都是不一样的。

所以我们第一步要做的事情就是对这些变更平台和变更场景的信息进行标准化，对各类信息进行统一的标准化之后，才能够将变更的执行与管控这两个事情给分开。执行还是放在原有的变更平台的团队去做执行，防控就会放到变更防控的团队，像 SRE、质量这样的团队，基于标准化的信息结构做变更风险的防控工作。这是在组织架构上执行的一些关系。

第二个是执行和防控的分离，通过 OpsCloud 这个变更风险防控的切面，其实没有违背康威定律，即组织架构决定生产关系，变更平台本身的开发和执行，还是归于原有的变更平台团队，只是整个变更平台要受到变更防控团队的控制。通过 OpsCloud 这个切面，通过 SRE 质量防控规则，对于变更的防线进行把控，让专门的防线团队能够去做变更的防控工作。

这就是变更防控在蚂蚁这边实践下来的方法和组织关系，没有违背康威定律的原则，还是通过这样一个切面，让更专业的人去做专业的事情。这是变更防控的方法。

变更防控的架构思路，这个思路偏技术一点。变更的业务团队和风险防控团队，OpsCloud 里面的设定，会把整个变更的信息做一个标准化的定义，包括变更的情景、动作，变更对象、变更内容和变更的影响面，这也是变更的基础信息。

同时对变更执行的 pipeline 进行定义，就是变更在执行过程中第一步、第二步要做什么，有标准的三板斧 pipeline，要求必须逐渐对线上的用户生效，而不是一把就完全对全量用户生效。在每一个 pipeline 的前后都有前后置的防御校验，风险防控团队可以基于这个防御校验的扩展 SPI，去增加防控变更场景下的防控规则和防控手段。

举个例子，当上面这些全部的变更平台都涌入进来之后，假设我们在某个时间点要做一个对外的营销活动，站在业务的视角，肯定是希望在这个活动准备充分之后，不要有任何的系统上、业务上的变更，引发一些额外的问题。这个时候就可以通过这样一个变更防控的 pipeline 以及 SPI 去定义，在这一段时间之内不允许某些变更场景下的变更去发生。当然某些特殊的变更是可以执行的。这个规则就会通过变更接入的 SDK，反馈到上面的变更平台，通过这些变更平台的拦截，阻断这个变更的执行。

这是整个变更的架构思路，第一方面是通过一个接入的 SDK，把变更平台的变更事件通过这个 SDK 接入进来，然后把信息标准化，把执行的 pipeline 标准化定义出来。第二方面就通过开放的 SPI 扩展能力，把后面风险防控团队做的一些防控的事情，比如业务高峰期的管控、变更后的可观测性的监控指标、日志异常、链路调度异常等等，做一个技术化的防控手段。这是整体的技术架构的思路。

接下来是完整的变更三板斧，“三板斧”是在蚂蚁这边提得比较多的词，叫变更三板斧，主要是指在做一个变更的时候，希望这个变更是可灰度、可观测、可回滚，这个是在约束人的行为，在做变更的时候，要知道这个变更在执行的过程中应该观测什么，比如观测什么样的系统指标、业务指标。可灰度主要是指渐进式的对于线上环境、用户、业务场景能够逐步生效，而不是对于几千甚至上亿的所有用户全量生效。可回滚就是当这个变更出现问题的时候，怎样快速地把这个变更回滚到原始的状态。

这里有一个前提是变更前置的审批、风险评估，对于人的流程的管控大部分会漏掉一些，因为它非常依赖于人的经验判断和人的经验积累，所以很容易漏掉一些风险的评估。变更到生产环境或者线上之后，如果不进行一个灰度逐步生效的控制，以及可观测性的观测，极容易出现一些之外的问题，从而引发比较严重的故障和问题。这就是整个变更管控三板斧的思路。

落到变更防控这样一个场景下，我们是这样去定义的，整个变更我们划分了两个阶段，第一个阶段叫变更计划阶段，也叫工单计划阶段。第二个阶段叫执行 pipeline 阶段。前面那个阶段主要是指在变更提交的时候要做哪些事情，变更提交的时候会让变更系统通过 SDK 去构建变更的标准信息，同时做到灰度和密测，怎样逐步灰度生效，对应到执行的预发、灰度、正式生产这样一个环境的执行顺序，在过程中也会进行一些风险和检测。

到后面执行的划分，比如一个偏系统的变更的方式，按照系统的部署环境，通常会有预发、灰度、正式这样几个环境。我们会要求每个环境里面的变更执行动作拆成好几部分，比如灰度环境被拆成了两个批次，这两个批次代表着在灰度环境有 100 台机器，先执行 50 台，再执行 50 台机器，逐步分批去做，正式环境也是一样的。

好处是假设变更出现了一些人没有评估到的预料之外的问题，能够快速地通过线上的可观测性手段去发现问题，这是业界提得比较多的金丝雀发布（灰度发布）的常见思路，就是通过逐步放量，去发现这次变更的内容、代码发布的内容、配置的内容，有没有对线上业务或者用户的使用稳定性造成一些影响。一旦发现有一些影响之后，就对这个变更快速地执行回滚的操作。

所以对于一笔变更，如果要符合变更三板斧，必须遵循以下能力：

1、必须要有一个能区分环境和批次的能力，就是能够分批执行，而不是一把就对全量用户生效。

2、在分批执行前后，分别埋一个前置的阻断和后置的阻断，也就是 pre 和 post 这两个节点，这两个节点会带到整个变更核心 OpsCloud 的系统上，再路游到对应的变更防御规则，进行防御的校验。这两个节点其实需要变更平台去做接入和改造。

3、当这个节点发现问题的时候，能够对这个变更进行快速的回滚操作，把被变更的实体，比如系统的应用，快速地恢复到变更前的状态。

这三个能力是我们满足变更三板斧这样一个变更管控平台需要具备的能力要求。这是具体的例子，一个变更满足什么样的条件，能够做到风险可控。这里会涉及到后面 pre 和 post 里面建立哪些内容，建立哪些规则，接下来详细介绍变更防御。

变更防御是在整个变更执行的前后这个阶段，去进行实时的变更风险的校验，整个风险校验会对于变更过程进行实时的干预，当校验结果不通过的时候，会对某个阶段进行阻断。当 OK 的时候，这个变更会按顺序自动执行下去。

整个阶段有几个能力，第一个是在这个校验阶段会建立什么内容，主要从三个角度出发：

一是当前能不能做变更，比如是不是在业务高峰期是执行黑屏命令或者一些操作，是不是在黑名单里面，是不是要做删库跑路的操作，删库可能是一个高危的变更操作，通常只有某些人的权限才能做。同时在前置做缩容的时候，容量是不是足够，要在前置做容量的检测。

二是有没有做完变更，就是这个变更执行了，但是执行的最终效果是不是达到了预期的效果，比如推完这个变更的时候，配置值是不是一致，代码版本是不是一致，更新的软件版本是不是更新集群。假设发布更新集群的软件有一千台机器，更新完所有的机器之后，软件版本是不是一致，需要做最终的校验和确认。这是变更有没有做完。

三是有没有做对变更，做对就是线上变更执行完之后，有没有对真实的生产环境造成一些预期外的影响，以及这个变更想达到的预期效果有没有达到。比如系统做完之后，有没有出现预期外的异常，日志类的或者监控类的异常有没有出现。业务上是不是出现了一些异常，比如说客数增加了，业务量增加了，出现了一些新的舆情等等。

另外是业务上是否满足变更的预期，就功能验证，举个例子，想上一个业务的新功能，这个功能上上去之后，在 APP 或者在小程序上，是否能看到这个功能的入口，以及这个功能的操作、流程是不是一致。这个除了靠人去验证之外，还有一些自动化测试工具可以去做功能的验证。另外就是对于涉及到的系统和业务，这次变更肯定会影响其他的一些系统，因为在分布式的微服务下面，一个微服务系统的变更，可能会影响其他微服务的系统和链路。这个时候对于其他系统和业务是不是造成了一些预期外的影响，需要进行功能的回归。

这是在变更防控三板斧的基础上，对于变更的执行阶段，每个前后置，每个阶段进行每个批次的风险校验，如果发现有风险，就会阻断这个变更往下执行。严重的情况下，会直接让这个变更回滚、自愈，规避变更对于线上已经产生的风险。如果没有异常，就会继续进行下一批的变更，直到这个变更逐步在生产环境执行完成。这是变更防御对于变更风险的实时校验。

整个灰度执行的过程中，风险逐步呈收敛的状态，因为执行的范围，相当于整个 pipeine 进行过程中，对于机器、用户流量、业务场景，随着这个 pipeline 的执行，变更生效范围是逐步放大的。在这个放大的基础上，如果校验都没有发现问题，大概率情况下本次变更的风险是逐渐收敛的。这就是整个灰度执行的好处，一个大致的模型。

为什么要这么做？因为这里做变更防控，其实有个假设条件是不相信每个代码变更，或者线上的配置操作，都是没有风险的，我们都会假设它都有可能会引入一个新的风险。在这个前提假设的情况下，会要求所有的变更都要去灰度，分批地执行，然后逐步地去释放风险或验证风险，当验证的风险范围越来越大，整个风险可能造成的线上问题或故障的风险应该是呈逐步收敛的状态的。这就是变更风险防御的大致思路。

三.变更防控智能化实践

最后一部分是变更防控智能化的实践，就是在变更防控场景下有哪些智能化的应用，怎么去防控住变更的风险。

第一个是在变更防御场景下，我们做了一个实时指标时序异常检测的能力，这个能力会在整个变更期间，对于变更执行，比如发布的多少台服务器，针对这个批次的执行服务器去动态创建实时监控的指标项。可能这些指标项既包含了系统化的指标，像常见的 CPU、Load、memory，也会包含一些微服务化的指标，像 Ops 调用、消息事件、订阅关系等等，也会对系统打 data 日志进行实时的监控。

对监控指标进行实时监控检测之后，把这些指标作一个变更前后的对比，比如识别变更前与变更后有没有引入一些不一样的风险或者指标异常。识别到变更指标异常后，对于线上的变更进行实时的阻断操作。比如在整个变更后出现了一个线上的异常，error 数突然猛增了很多。相比其他的智能告警或者对于监控指标的实时异常检测，好处是它完全是由变更触发的，我们会告诉实时异常检测平台整个变更防御在什么时候开始执行了变更。

这里会有一个变更开始的时间和变更结束的时间，开始一个变更之后，这个变更的范围也是有限的，就是这次变更的批次，本就涉及到这五台机器，会把这五台机器扔给整个监控平台以及异常检测平台，去做实时的监控指标的采集。采集完了指标，会再进行变更前后的异常指标的检测或者对比。相比于变更前和变更后，理论上如果没有产生异常，指标变化就不大。

在变更前和变更后，变更前假设这是一个业务的错误量、一个调用量的指标、业务的耗时，那在这次变更的批次机器里面，整个业务的耗时应该一直呈不变的水位，除了变更期间可能机器的重启，或者机器的发布关流量，可能会导致指标的数值往下跌。在变更后，理论上这个曲线应该还是跟变更前是保持一致的，如果没有保持一致，说明这次变更期间的操作和引入的东西，可能对这个指标产生异常的影响。

其实异常指标是更准的，因为它多了变更对象、变更范围以及时间的角度，做了变更前后指标的对比，就不仅仅是一个变更的时序曲线变化的情况，去判定这个变更是不是有风险。所以这是在变更的防御情况下，它的指标时序异常检测做到更准的一种方式。

降噪维度是指通过时间和变更前后的对比，通过变更对象，变更的系统是哪一个，变更的范围是什么，变更的是哪几台机器或哪一个业务场景、哪些用户流量，对于这个范围进行圈定，然后进行小范围的监控和检测。同时还会跟历史的相似度进行比较，比如在历史场景下，这个系统做完一个发布变更，或者做完一个重启变更之后，假设它的 CPU 都会在变更后立马有个飙升，然后再回落，这样一个时序异常检测其实是满足历史相似性的，可能这个系统在启动的时候会做一些密集计算或者内存加载的操作，会导致它的 CPU 或者内存指标临时飙高，然后再回落。这样一个异常，就会满足它历史的相似度，那我们就会去学习它在历史变更的期间有没有出现过，曾经也做过一些重启或者发布一些变更的时候，它的 CPU 指标也会出现这样的飙升和回落。

通过这样的历史相似度检测，去发现这个变更可能能做一个降噪的维度，或者这个变更和系统，在重启后 CPU 会突然临时增加的这样一个表象。通过这样历史相似度的学习，也可以把变更做到指标的准确性的降噪。

相关的算法技术，用到了动态时间规划、3-Sigma 和 KDE 这样一些做实时时序异常检测的常见算法。在这个基础上，其实算法只是一个基础的技术能力，更重要的还是结合变更这个场景，在变更防御下能够利用更多的信息，对于这个时序异常检测的准确性做一个更精准的防控和降噪。这是在变更防御场景下比较特殊或者比较有特色的一个点。

第二个也是变更防御在智能化场景下的实践，就是日志堆栈内新增/突增异常检测。其实这种堆栈日志有个痛点，它不像时序指标有一根归因化之后的曲线，在整个日志堆栈异常里面，它日志模板的格式千奇百怪，可能有些是 Java 的堆栈日志，有些是业务自己打的异常日志，也有可能是系统框架打的异常日志。这些异常日志在某些程度上当人去看的时候，会把它归为一类，比如是不是 JDBC 连接超时了，还是访问哪一个底层的什么方法，抛了个 exception。

这样一个理解，对于日志内容的分类，这个分类我们在算法上其实是用到了日志的模板相似度特征的提取，将这个日志做一个格式化的哈希，哈希完之后把整个特征做一个提取，然后去识别到哪些日志是相似日志。虽然它里面有些子内容可能是不一样的，但是整个日志内容都代表可能这一类的日志是 JDBC 连接超时这一类日志。

把日志做了归类之后，就能做两个异常检测的维度：第一个是对比变更前后有没有出现过系统堆栈新的日志类型，比如之前可能系统在打，经常会出现两种日志类型，突然这次变更完之后，又出现了第三种日志类型，那这第三种日志类型或者日志的堆栈异常，大概率就是由这次变更而引入的，这也是能够实时发现这个变更风险的检测维度。

第二个维度是在突增异常上，同样变更前、变更后都是系统日常在报两个常见的日志类型或者日志模板，变更前这两类日志的报错可能是每分钟 100 个的数量级。但是在变更完之后，这个数量级突然飙升到了 1000 个或者上万个的数量级，这样就会导致整个变更检测到日志量的增长，大概率是由这个变更而引入进来的。

所以通过这两个维度，一是新增异常日志类型，二是突增的异常日志类型，这两个维度的检测，能够发现可能由变更引入的对于系统日志异常的检测。这是在变更防御下第二个智能化的实践，就是对于日志模板相似度的特征提取。

以上是我今天的内容分享，感谢大家观看，后续也将带来更多交流分享，敬请期待～

”