【架构艺术】构建变更风险防控能力市场的一些经验

变更风险防控的能力是多样的，除了最传统的告警检测、Metrics曲线对比以及自动化测试能力之外，像变更影响分析、风险降噪以及线上风险RCA等周边能力也是不可少的。有了更多的上下文信息，才能对变更风险做更好的判断。从中台技术视角来看，不论是传统能力还是一些AI加成的能力，如果没有一套稳固的技术基建让这些能力尽情发挥，那么这些能力将难以快速落地，充分兑现其业务价值。

基于此，笔者在今年工作中，交付了一套「能力市场」产品与技术架构，旨在面向不同业务团队的自研能力，提供一套开放式标准化的接入方案，让业务自研的变更防控能力可以快速应用到变更风险质检过程中。虽然这套架构目前还有很多继续扩展和完善的空间，并且也没有蹭到LLM的噱头，但在架构迭代过程中笔者权衡了很多利害关系，主导了很多技术演进判断，最终也成功落实了这个技术结果。

具体一些技术上的设计，其实前面的文章已经聊了很多，包括任务调度、事件状态机以及内置降噪模块嵌入之类的点都有阐述。所以今天这篇文章，不倾向于聊这些具体的技术实现，更倾向于聊下整个产品交付过程中的一些权衡和判断。

首先是如何决断「能力市场」产品技术架构的整体设计，这部分如果从最终效果出发，是比较好推理的。产品的潜在用户主要是变更防控能力RD以及业务SRE，能力RD关注怎么把能力接入到系统，业务SRE关注怎么把能力应用到服务变更发布过程。面向能力RD，需要有一套能力元信息管理机制和接入协议；面向业务SRE，需要有一套能力执行策略机制；面向能力实际落地，又需要有一套调度机制把能力元信息和执行策略串起来。所以一套元信息管理->执行策略配置->执行调度Workflow的架构设计就很清晰了。

然后在实际研发前，需要考虑的是这套产品交付后，如何不影响原有产品体验。在笔者这里，有一个背景是笔者所在团队已经有了一套技术实现偏业务定制化的变更防控产品，基本覆盖了全公司的业务，很多历史逻辑都不是很好挪。研发人力方面，「能力市场」投入也不算多。所以最终决策上，「能力市场」整套技术架构会作为原有产品的扩充，双方内部会共享状态数据，做一些数据兼容逻辑。虽然这样实现上比较复杂，但也是唯一能保障产品体验的可行方案。

之后就是对于每类变更防控能力，如何在变更风险观测过程中做灵活自由的调度，对于这件事情，上面「事件状态机」的方案是可以解决的，并且也可以应付未来更多的接入需求。简单来说，变更风险观测过程里，涉及到观测和变更两条时间线，两条时间线上各类状态完成的事件都是不可逆的。因此可以固化出一套事件状态机，通过不断的状态演进，来判断什么时候启停哪些能力，什么时候结束观测。

最后就是对于「能力市场」后续迭代的一些展望。个人以为「能力市场」的职责上，除了提升业务风险拦截水平以外，还需要有能力执行数据的运营功能，比如稳定性、风险召回率以及检测准确率等方面，通过数据分析去辅助各能力专项做定向优化。如果面向LLM增强的风险决策能力，也可以构建一些评测手段，评价这些决策能力的最终效果。至少从技术上来讲，可扩展的点还是非常丰富的。