精彩演讲推荐｜智能化变更防控方法、架构与组织实践

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、业务运营等团队，都可以具备线上变更操作。这其实会从最开始只需要管控住运维团队不要对线上进行变更，就能防控住某些时期对于线上稳定性的要求。到现在整个变更的复杂度以及操作越来越高频，越来越分散，对于变更这个事情的管控难度也会日益增加。从最开始管控运维