技术风险，作为质量保障领域的重要的一环，主要研究如何通过解决方案和技术手段，解决企业内业务在基础运维、日常运营和变更上线过程中的稳定性问题，保证业务风险得到收敛。在国内，蚂蚁金服在这个方向上有沉淀很多方法论和实践经验。变更管控是技术风险地一个子领域，主要的目标是在变更过程中，通过对变更流程的管控介入，提前发现变更过程存在的事故风险，或者阻止变更过程的错误进一步扩大影响面。在这个子领域，蚂蚁开源了AlterShield变更管控平台，提供了一套变更风险防御的解决方案。今天，本文就浅析下AlterShield平台整体的设计，适用的场景以及局限性。
AlterShield的源码可以参考这个GitHub-Repo。整体的技术架构，主要包含几块部分：
- OCMS-SDK：面向变更渠道和K8S运维平台的接入层，约定了统一的变更信息协议和变更技术协议的定义
- Defender-Framework：变更防御框架，提供异常检测、发布窗口封禁等变更防御能力，用于检测变更风险
- Analyzer-Framework：变更分析框架，提供影响面分析、变更分级等变更过程分析能力，用于提前分析变更内容，为变更防御能力提供上下文信息输入
最底层的核心概念，是变更信息协议和变更技术协议。首先是变更信息协议，整个协议描述了一次变更最基础的5W1H信息：
- Who：变更人
- When：变更时间
- Why：变更背景
- Where：变更渠道
- How：变更操作
- What：变更对象
任何渠道任意变更操作，其中的上下文信息都可以用这个5W1H表示法描述，简洁方便，利于定位和回溯。
其次是变更技术协议。变更技术协议提出了变更代际的概念，用于描述变更防控能力可介入变更过程的不同方式。变更代际这个概念粗看很有阿里味，比较难以理解，但我们如果分变更渠道和AlterShield视角来看的话，不难发现不同的变更代际实际代表着变更渠道可选接入AlterShield的不同方式。一些变更渠道可选只提供事件信息，另一些变更渠道也可以选择在变更不同阶段引用AlterShield的拦截卡口，从变更渠道方视角，不需要非常关注具体有什么变更防御能力启用，只需要注册自身的接入方式，给定几个可应用防控能力的切点即可；而从AlterShield角度，只需要给业务开放能力，让业务可针对不同平台发布，配置不同切面能力，从而达到变更防控的效果。
变更代际这样的模式，需要依赖AlterShield的开发方和主流的变更渠道做到深度密切的配合，也需要企业内部为所有变更渠道约定一套变更流程的规范作为代际概念的支撑。因此，如果变更管控平台不是和变更渠道深度共建，以及对于变更渠道的变更流程规范约束不强烈的话，引用变更代际的模式可能不够灵活，但需要保证至少有G0（变更事件）的接入方案。对于高发布频次，与业务核心链路强相关的发布渠道，需要有粒度更高（代际更大）的接入方案，去尽可能在更多的时间点发现更多的变更风险。
最后简单看一下变更防御能力。当前在文档中，介绍了4种变更防御能力：
- 时序指标异常检测：给定一批检测指标，对比变更期间这批指标跟变更前、历史变更的相似度，来推断本次变更是否有指标异常
- 日志异常检测：检测错误日志中，是否有错误或者异常堆栈信息
- 链路异常检测：检测一条上下链路上，变更期间是否有某个节点突然发生异常
- 配置值自适应校验：训练既往的变更内容，推断更新的KV是否可能有人工填写错误问题
变更防御能力的方案基本是通用的，而且像日志异常、配置校验等能力，在能力基础上，需要支持业务自定义。指标、日志和链路异常检测，如果能够结合企业内部对于性能打点、日志收集、链路打标等基础架构能力进行建设，是更加合适且具备远见的方式。