蚂蚁集团变更管控平台 AlterShield 正式开源-六虎

原文首发自【蚂蚁技能危险TRaaS】大众号

蚂蚁集团改变管控渠道 AlterShield 正式开源

01：AlterShield 简介

AlterShield 主要期望经过体系化的办法处理改变引发的安稳性危险问题，协助SRE有用削减因为改变引发的线上毛病。

什么是改变管控

▌改变问题的价值和含义

关于出产环境的安稳性，是各个互联网行业相关公司都关注的。尤其是关于大型互联网公司来说，安稳性就显得更为重要。另外，从诱发安稳性问题的原因剖析来说，改变及编码问题所占有的比例，终年超越一半以上。前史上因而产生的重大毛病不乏其人。

一同，因为散布式所带来的体系杂乱度、事务越来越杂乱所带来组织间联系的杂乱度。导致了像亚马逊、NetFlix、蚂蚁集团这类事务体系巨大的公司，改变的问题就更为严重。

所以，关于安稳性来说，业界的一个一致是：防控住改变危险，安稳性问题就处理了一半以上。

▌改变管控的思路

尽管说业界有了上述的一个一致，但诱发线上问题的根因是多种多样的，比方编码引进的Bug、改变人员的忽略、人员之间沟通不到位等等。一同，跟着事务体量的不断增大，组织区别与团队协作联系也会日益杂乱。这种联系是契合康威定律的，也便是说组织联系的杂乱会引发沟通本钱的加重，也间接导致了改变问题难以管控。

所以，关于改变管控的思路，业界最基础也最简单完成的计划是做事情的感知 + 计划报备批阅。但这种办法的弊端在于强依靠批阅者的专家经历，且无法扩大改变管控的规划。

咱们在蚂蚁集团实践的改变管控思路是：在整个改变的生命周期中（包含改变事前的计划报备、提前的改变危险及影响剖析、改变中的反常观测、改变呈现反常的熔断及自愈、改变完成后的改变度量及审计），以体系化的手法去防控和办理约束改变流程，使改变流程完成“三板斧”：可灰度、可观测、可应急。

那么，AlterShield 是什么？

AlterShield 是作为改变管控范畴中一款集改变感知、改变防护、改变剖析于一身的一站式管控渠道。旨在经过界说改变标准协议，标准改变管控流程，使得用户能够快速发现改变中的问题，并及时下降毛病影响面。

AlterShield 是蚂蚁集团内部研制了近 5 年的改变管控渠道 OpsCloud 的开源版别。经过多年大型互联网公司内部杂乱事务场景的驱动，OpsCloud 在改变管控范畴沉积了丰厚经历，是蚂蚁集团内部悉数类型改变的一致管控渠道，也是事务研制、质量测验、SRE同学日常进行改变感知、改变剖析、改变反常辨认的重要进口，在蚂蚁集团的改变危险防控上取得了显著的效果。

咱们十分期望能将这些经历和业界进行一同评论与一同演进，为此咱们开源了 AlterShield，因为整套改变防控体系较杂乱，咱们会逐步将一切的功用共享到社区，也十分欢迎咱们来和咱们沟通关于你当时遇到的关于这个范畴遇到的问题。

02：AlterShield 全体技能架构

在技能架构上，AlterShield 分为以下几部分内容：

产品功用层：面向研制、质量、SRE同学，供给改变信息感知及订阅、改变信息查找、改变剖析成果检查、改变计划履行流程、改变防护装备、改变防护反常检测成果感知的产品才能。
OCMS（Open Change Management Specification） SDK，咱们想逐步构建一套标准的改变信息协议，未来在这个范畴，咱们都能够依据一套标准的协议，去进行各自的体系设计；现在的协议是依据蚂蚁集团的上千种改变场景总结概括而来，十分初期的一个版别，这部分也欢迎咱们来一同演进，协议包含两部分内容：

改变信息协议：这个信息协议是上层改变渠道与后续一切功用模块间进行改变信息交互的标准信息结构。
改变技能协议：一种按代际区别不同改变收效流程的SDK，一切上游改变渠道经过该办法对接 AlterShield 进行前后置切面的管控。

Analyser Framework（改变剖析结构）：在OCMS SDK流程中，供给了改变前的影响面剖析、危险剖析、可观测性剖析才能，会对改变内容、改变影响面、改变履行战略进行剖析，一同依据这些剖析成果，给出本次改变的危险分级，能够描绘这个改变或许存在的危险程度。
Defender Framework（改变防护结构）：在OCMS SDK流程中，供给了改变中反常辨认手法的路由、调度、并发履行、异步化操控才能，终究给出改变是否准入或可继续的断定。
Defender Service（改变防护服务）：AlterShield 在防护结构中集成的大局通用的防护才能。如：可观测性范畴的反常检测、装备改变中装备值的自适应校验、改变窗口及封网的管控、定制模板的改变参数校验。
敞开扩展：以Plugin、SPI的办法，集成不同范畴关于改变剖析、改变防护的不同诉求，并以装备化的办法进行路由、履行，能够愈加灵敏的满足不同改变场景、不同事务场景下的危险防控诉求。
事情调度：AlterShield 中各个模块间的交互办法都是经过内部事情来进行的，一同也担任各防护才能、剖析才能的并发调度履行。

上面介绍到的模块，咱们都会陆续在Github库房开源，也欢迎咱们一同来参加，接下来，咱们将结合 AlterShield 中几个关键模块，来具体介绍下咱们的改变管控思路。

什么是改变

▌改变的概念

在做改变之前，咱们必须先弄清楚，什么是“改变”，或许说什么是咱们安稳性范畴所关怀的“改变”？业界一般把“Ops”当做改变，但“Ops”更多指的是研制、运维人员做的偏运维动作。在改变管控范畴，“改变”这个概念要比“Ops”在规模上大很多。

所以，咱们最开始对改变的界说是：任何导致线上服务状况产生改变的行为叫做改变。

可是这样的界说过于含糊。比方“状况”这个概念，假如说服务依靠和包含的持久化数据是一种清楚明了的状况，那么服务当时所在的、时时流逝着的时钟是否算作“状况”？再比方数据清楚明了是“状况”，那么假如用户打开支付宝建议一笔转账，这个行为是否归于“对账务体系的记账表数据状况做了改变”然后应该视作改变？

带着这个问题，咱们剖析了前史上由改变引发的线上环境毛病事例。发现一个共性：它们都是企业内部人员经过某个渠道或黑屏命令进行的线上操作。这些内部人员从运维、研制、产品到活动运营等，涵盖了多种角色。所以，改变，或许说做改变管控所需求关怀的改变，指的便是“内部人员触发的任何导致线上服务状况产生改变的行为”。因而Linux时钟滴答不是改变，用户转账也不是。

▌改变标准化协议（OCMS-Open Change Management Specification）

在圈定了咱们的方针规模之后，另一个要处理的问题是：单一体系建议的改变，其影响规模并不局限于这个体系自身，这关于研制、运维人员的经历性带来了极高的要求与剖析本钱。一同，每个企业所在的事务布景不同，甚至同一家企业不同的事务部分之间也存在着较大的差异与壁障。这个问题导致各个企业或部分所做的改变在语义、描绘办法和收效办法等方面有着巨大的差异。

举个简略的比方：关于传统运维改变、事务运营装备这两类改变来说，在公司内部承载的渠道或许是两个，且由不同的事务线团队来担任。那么这种差异就会导致这两类改变关于信息的界说（比方改变的内容、目标）、改变的收效办法（运维改变或许是依照服务器维度收效，事务运营装备更多是DB/内存/缓存中的数据修正）、改变的影响规模等都有所不同。那么想要对这两类改变一同在一个渠道进步行管控，不一致这种信息及技能差异，本钱是极高的。

针关于上述杂乱场景，AlterShield 界说了OCMS（Open Change Management Specification）SDK，其间包含两部分内容：改变信息协议、改变技能协议。

改变信息协议

因而，AlterShield 在进行改变管控的第一步条件便是要做到不同布景下的改变信息及技能一致，其信息协议的界说能够参阅下图：

这样信息协议标准化的好处是：

能够兼容不同布景下的各类改变，完成了多类型改变的“一致管控”
屏蔽了上层事务场景带来的信息差异，使得改变管控后续的改变防护、改变查找、改变审计能够依据一套标准的信息模型来进行
为其他技能危险范畴相关的才能（如应急定位等）的结合供给了一套一致的信息模型，能够协助事务在产生问题时快速定位到相关事务链路所产生过的改变

改变技能协议

在信息协议标准化处理之后，另一个问题便是上文比方中说到的“传统运维改变和事务运营装备改变，其改变收效办法不同”。这种流程上的不同，会导致改变在做管控时交互的机制不同。

再举个简略的比方：关于传统运维改变，一般是依照服务器分批收效的。那么关于这个改变单来说，改变管控渠道能够在每个批次的前后做管控校验和信息收集；但关于DB装备类运营改变，因为DB数据仅有一份收效，所以在出产环境中的改变一般只要一个过程，或许在上层经过UID操控分批收效。

因而，针对上述的改变流程和收效办法的不同。AlterShield 在技能协议上，经过前后置切面的办法，界说了“改变代际”的概念，从G0~G4共分为5个代际（G取自英文单词中Generation）：

代际名称	支撑的改变流程和收效办法
G0	以事情告诉的协议接入 AlterShield，不供给管控才能，仅可做改变事情的告诉、查找
G1	关于无法依照批次拆分一步一步收效的改变，做单节点的改变流程管控
G2	能够依照批次拆分收效的改变（如集群服务器重启），做完好工单的改变流程管控
G3	在有完好的改变工单管控的基础上，增加了改变提单阶段的管控
G4	在改变提单管控的基础上，增加了改变无人值守的决策才能

这种技能协议标准带来的好处是：渠道事务团队与危险防控团队有了清晰的责任区别边界，以及一个一致交互的标准办法，改变渠道研制的团队，更聚集于渠道研制自身，而SRE团队能够关注于改变的危险防控与治理，让更专业的人做更专业的事情。

云原生下的 OCMS 集成

云原生的发展趋势下，应用体系自身的布置、运维改变，都是依据Kubernetes或其它开源CI/CD东西进行的。关于这类下沉场景，AlterShield 供给了 AlterShield Operator，衔接各类CI/CD东西到OCMS SDK。一同，Operator 自身也供给了改变流速操控、反常回滚战略操控等才能。

防控改变引发的危险

▌让改变渐进式灰度收效

金丝雀发布的思路来历是，矿井工人发现，金丝雀对瓦斯气体很敏感，矿工会在下井之前，先放一只金丝雀到井中，假如金丝雀不叫了，就代表瓦斯浓度高。在灰度发布开始后，先发动一个新版别应用，可是并不直接将流量切过来，而是测验人员对新版别进行线上测验，发动的这个新版别应用，便是金丝雀发布办法，下图简略描绘了下一个金丝雀的大致逻辑：

矿井的做法，不再企图剖析瓦斯的化学成分，然后找到这种成分的显影试剂然后判别瓦斯是否存在。而是直接经过金丝雀的表象反应(是否健康)来勘探一切危险，然后处理了瓦斯以及其他或许的有毒气体的检测问题。而较之悉数根因，表象的规模更小、勘探手法更清晰。

这样一种办法，能够在改变无法充分事前剖析出危险的状况下，在真实履行期间，经过操控爆破半径的办法，让改变能够逐步收效，能够削减不知道改变危险引发的安稳性问题影响面，一同再配合上危险防护才能，能够有用的及时发现改变引发的问题，快速做阻拦处置康复动作。

▌可干涉改变的危险防护才能

灰度的中心，是将改变动作拆分为可逐步收效的办法，比方代码发布能够依照机器的环境进行拆解。而一般性的改变，拆解维度不止有环境。咱们企图处理改变引发的黑天鹅隐患的主要逻辑是：

▪ 选择在一个危险可控的改变规模（这个规模关于安稳性的影响程度是能够承受的），将危险逐步露出出来。

▪ 再经过改变危险辨认防护才能（金丝雀们）去检测改变后是否有反常状况产生。所以能够说，以什么维度做拆解，取决于什么因素决议“危险可控”。“可控”意味着规模和危险线性联系。蚂蚁的毛病终究体现在对外用户的事务流量上，流量和线性地散布在承载应用进程的机器上，一同，事务线性的散布在包含Pod、PID、UID、事务场景、机房、流量类型等在内的多种维度上。

前置转后置配合线性分批，形成了新的改变范型：

这样一个可灰度/分批的改变防控架构，把本来只能靠体验应急康复速度来处理的问题，经过一个可控规模露出危险，再运用充分的危险辨认手法，不断将不知道的改变危险问题逐步收敛。假如说之前咱们等待依据前史概括的前置规则能够回答一切或许的问题触发根因，然后在问题产生前防止之。那么此时，思路转换成了在每一个小批次之后，回答是否有问题。

事实上，一切的问题根因无法穷举，使得前置校验的危险覆盖率低；一同相同根因的改变毛病不常复犯，使得前置规则编写的ROI低。但改变目标及其影响面有没有问题，总是更简单回答的，且因为分批的引进，即使前面几个小批次呈现了问题，因为规模可控，问题的严重性也可控。

至此，改变危险防控从面向已知问题的防控，演进到了面向不知道的防控。从押宝前置校验演进到了前后置一同防控。

这套可灰度/分批的改变防控架构，有以下几个必要条件：▪ 固定流程的履行pipeline(强制危险发现/过程可控)：履行依照预发/灰度/出产批次进行环境间/批次间串联▪ 改变分批履行才能(操控危险规模)：改变的收效需求能够区别环境线上环境按批次收效▪ 前后置防护校验(危险发现)：前置阻断改变、后置发现问题/阻断下一批次改变每批次的前后置需求布防

▌改变防护结构（Defender Framework）

依据前文的思路，在对渠道事务与危险防控团队做了清晰的责任区别之后，咱们要做的便是为危险防控团队供给一套结构，以便为其供给更灵敏、体系化的手法去检测改变过程中的反常，及时地熔断改变。

为什么需求灵敏性？

让咱们思考一个场景：关于公司内部的办理体系来说，其做体系发布改变时一般只关注体系监控目标和中心日志就够了；但关于对客的事务体系，或许事务上的战略改变，除了关怀上述目标外，还需求关注事务自身功用的健康状况（如：对客的展现页面是否白屏、事务活动预算是否充足等）。并且不同的事务改变，其关怀的目标还会存在差异。

上述场景引发的问题是，即使一致了改变的信息差，关于后续的改变防护流程来说，也是不够的。因为改变防护的观测手法，是跟着事务布景不同，而产生灵敏变动的。这便是在之前，改变防护依靠人的经历性的原因所在。

关于改变危险防控这部分内容，AlterShield将其统称为“改变防护”。共分为：改变防护结构（Defender Framework）、改变防护才能（Defender Service）、敞开扩展服务三大部分内容。

结构层所供给的中心才能是：

防护才能路由：针关于不同改变，经过表达式装备的办法，路由到不同防护才能调集等待履行检测逻辑。以满足不同改变的防护校验多样性诉求。
防护才能的调度与并行履行：各防护才能间彼此独立，各自担任自己的校验逻辑，并依照一个“一致的结构”进行成果回来。这个结构在后文中会进行论述。
防护才能异步化：防护校验自身需求必定的时刻（尤其关于可观测性相关的检测来说），这部分时刻会带来改变功率的下降（因为操作改变的人员需求等待校验定论）。因而，针对分批次改变的场景下，防护结构供给了异步化校验的才能，运用改变自身履行的时刻替换防护校验的时刻，做危险与功率的平衡。

▌改变防护才能（Defender Service）

如前文所述，关于大部分改变来说，尽管部分运用的防护才能会存在差异（事务语义较强的部分），但大体上所需的防护才能仍是大同小异的（如：可观测性检测、装备改变的值校验、改变操作标准校验等）。这部分咱们统称为“通用防护才能”，AlterShield 已在自身结构内部默认集成。

时序目标反常检测 — 分批改变监控

关于可观测性范畴，OpenTelemetry 给出了清晰的三个子范畴界说（Metric、Logging、Tracing），其间“Metric”指的便是监控中时序目标（如：CPU运用率、体系RPC服务调用成功率等）。AlterShield 针对时序反常检测，贴合改变分批次履行的布景，建造了“分批改变监控”。

如上如暗示，改变场景和一般场景在时序反常检测的区别是，改变场景是有明显的两个时刻点的：改变开始、改变结束。因而，咱们在获取到监控时序数据后，主要是做改变前后两段时序的对比反常检测。

短时序反常检测

在时序反常检测部分，咱们运用了KDE模型进行（Kernel Density Estimation，核密度函数估量）。KDE是核算概率模型之一，核算概率模型是也是比较常见的反常检测思路。数据往往具有其散布规则，假如落在散布边界则触发了小概率事情，即为或许产生了反常。在正态中，99.73% 的数据散布在距平均值三个标准差以内（3-sigma）。那么，假如咱们的数据遵守必定散布，就能够从散布曲线推断呈现当时值的概率。

反映到改变场景中，改变前和改变后的时序数据遵守必定散布（例如正态散布），那么改变后的当时时刻点数据假如超越 N-sigma，则能够判别为反常，一个简要的检测能够描绘为：

三个标准差 3-sigma 是常用的标准，但它的问题是，真实的改变时序数据大部分无法假设其真实散布，即使是一个小时刻窗口里的数据散布也很杂乱，它不是一个简略的正态散布。相比而言，KDE 是一种非参数估量办法，对数据散布不附加任何假定，仅仅从数据样本自身动身研讨数据散布特征。依据 KDE 的改变时序反常发现，主要流程同 N-sigma，主要是 step2 不同，它需求从头构建改变前样本的数据散布: X1、X2、… Xn 为独立同散布的 n 个样本点，设其概率密度函数为 f，则核密度估量公式为：

其间 h 为一个非负的滑润参数，称作带宽， K(.)为核函数(非负、积分为 1，契合概率密度性质，并且均值为 0 )。

核函数有很多种，例如：uniform、triangular 、biweight、triweight、Epanechnikov、normal 等。依据改变前数据求得概率密度函数 f 后，即可求改变后恣意点的概率，进行反常判别。

另外，仅做改变前后的时序反常比对，极端简单呈现因为各类突发、预期内事情导致的目标异动误判。咱们回滚并剖析了各类误报事例，总结并建造了依据对照组、布景组、前史组的准召率提升计划：▪ 对照组：同逻辑单元下未改变的服务器收集的目标数据▪ 布景组：该批次服务器前史n天内的时序目标数据▪ 前史组：该应用上次同类型改变前后的时序目标数据

日志反常检测 — 新增、突增反常检测

一个体系运转的状况，除了在监控时序目标上能够反映外，另外需求关注的便是其过错日志中，是否有反常堆栈信息，如下图：

AlterShield 针对此类日志反常辨认场景建造了“新增、突增反常检测”防护才能，检测改变后过错日志中的反常改变状况，共分为两个阶段：

训练阶段：将通用过错日志中的反常信息进行正则化处理，并将处理后的日志正则模板依照类似度进行分类，结构该体系的日志模板库。
预测阶段：将体系实时收集反常日志信息相同进行正则化处理，并与模板库中全量模板进行类似度拟合，得出该反常是否为新增反常的定论；针对突增反常，需求核算反常模板计数，预测思路和上文时序反常检测思路类似。

反常类似度核算

在类似度核算上，AlterShield 运用了 Drain 算法，其中心思维是依据各个模板结构固定深度的解析树。当新的反常模板进来时，会与每个已有分支进行类似度核算，不类似则新增分支。

链路反常检测 — 链路过错码检测

关于单一体系的改变，其影响很或许并不局限于这个体系自身，更或许波及到其上/下游，或整个事务链路的进口/结尾。那么就需求改变后能够具有对整条事务链路进行反常检测的才能。

简略办法下，经过trace日志聚合即可反映出体系间每笔流量的调用反常状况以及事务过错码的改变状况，但这种办法的问题在于核算量过于巨大，极度损耗资源。

那么较为杂乱的办法是结合中间件才能，将每笔流量的调用带着特别符号进行透传染色，这样既能清晰感知一笔流量所经过的体系链路，又能在透传的一同带着体系交互的关键信息，然后完成整条链路的反常检测。

AlterShield 正是借助 Sofa RPC 中间件的才能，将改变信息协议中的仅有标识位在整条流量链路进步行透传。再在链路的进口和结尾处打印悉数流量中的事务过错码核算信息。这样，就将链路反常辨认问题转换为依据日志的监控目标时序比对问题。后续反常检测的思路大致和“分批改变监控”相同。

在此你或许有些疑问：假如改变的体系，RPC服务反常导致上/下游根本接纳不到音讯，就不会在链路的进口和结尾打印核算日志了。那么这类反常怎样辨认呢？

其实，关于RPC服务的来说，各类干流结构都是支撑打印核算日志的。一旦呈现失败量突升，在核算日志中即可反映出来。所以，这个问题是归于“单体系的监控时序目标校验”范畴，也便是说运用前文说到的“分批改变监控”就可校验出来。

装备值自适应校验

关于装备类型的改变（如：散布式内存装备改变、营销活动装备改变等），一旦提单人员忽略填写过错或遗漏，也会导致线上问题。一同，这类装备或许数量极端巨大（在蚂蚁集团内部有上千万+），靠人工进行梳理是不现实的。

因而，关于前史上正常结束没有回滚的装备改变，AlterShield 依据其改变值进行特征提取，学习该装备的key、value改变规则，从核算学、正则、枚举等多个角度结构每个装备值的特征组。当新改变到来时，就转化成了特征类似匹配，然后发现人工填写过错的问题。

另外，除 AlterShield 供给的上述防护才能外，危险防控人员也可将自己在特定事务布景下的专家经历，以Plugin、SPI扩展的办法沉积到 AlterShield 中，并以装备化的办法进行路由设置，收效到指定改变中。

03：社区建造

改变管控范畴是提升出产环境安稳性的一个重要范畴。相关的技能标准也在逐步完善建造起来，并推进这一范畴的演进。在这样的布景下，咱们也期望将 AlterShield 在蚂蚁5年的实践经历敞开出来，与各行业的范畴专家一同评论学习，并逐步丰厚 AlterShield 自身才能与社区建造。

咱们的开源作业在陆续预备中，当时还仅仅咱们的0.1版别。首期咱们会开源 AlterShield 的 OCMS + Operator体系。接下来咱们的计划如下：

供给完善的开箱即用及Q&A手册
完善 Operator 才能：供给完好的改变战略操控、回滚战略操控才能。
扩展 Operator 生态：集成更多的开源CI/CD东西傍边，丰厚感知及防控场景。
原生防护才能下沉：在 Operator 中直接供给对接监控东西服务及反常校验才能。
完善可观测性反常检测生态：集成更多的开源监控东西，供给反常检测才能。
开源完好的Defender模块：包含防护结构、防护才能及敞开扩展部分。
开源完好的Analyser模块：包含剖析结构、影响面剖析、危险剖析、可观测性剖析及改变分级部分。
敞开独立的防护校验才能：使防护结构独立于OCMS SDK，无需接入改造，即可进行改变防控校验。

作为开源社区，咱们欢迎各种办法的贡献，您能够参加到社区的共建的办法包含但不限于：

▪ 错别字修正：协助咱们纠正文档中的过错。

▪ 问题及事例评论：您公司中的改变毛病事例，脱敏后可参加评论，一期评论处理计划。

▪ Bug提交：协助咱们指出 AlterShield 中逻辑过错的地方。

▪ 新功用场景评论：任何 AlterShield 还不具有的改变范畴功用，都能够一同评论。

▪ 完善 OCMS 协议：现在 OCMS 开源还处于0.1版别，假如在您的场景下有不能适配的状况，您能够直接参加评论及扩充。

▪ 完善 Operator 生态：现在 Operator 在0.1版别会对接Kubernetes Deployment，您能够在您的CI/CD东西下改造及对接 Operator，扩展其生态。

▪ 对接更多监控东西：您能够将您所运用的监控东西对接到 AlterShield 供给的可观测性防护才能中，扩展 AlterShield 的检测才能规模。

▪ 沉积您的改变防护专家经历：您能够以Plugin、SPI扩展的办法，将您的改变防护专家经历沉积到 AlterShield 中。

后续，一切的研制、评论等相关工都会在社区通明运转。您能够经过以下办法联系到咱们：

AlterShield Github社区：

github.com/traas-stack…

AlterShield-Operator Github社区：