【架构艺术】变更风险防控架构嵌入决策降噪模块的方法

在先前的文章中，我们聊到了一个变更观测任务可以通过什么样的方式对不同的变更防控能力做统一调度，达到优越的变更风险拦截效果。但是在实战当中，变更观测任务集成了很多能力，即便风险拦截率很高，但不同能力效果也有差距，因此会有可能出现误报，导致变更观测结论不准确，影响研发发布效率。为此，一套成熟的变更观测系统，是需要嵌入一个决策降噪模块，通过干预变更防控拦截结果，达到在风险召回不劣化的同时，提升准确率，让结果更加置信。

因此，今天笔者决定结合自己的工作经验，简单聊一下变更风险防控架构的宏观体系当中，决策降噪模块应当怎样接入比较合适。需要说明的是，本文不涉及具体降噪的实现，包括算法的许多部分，主要是从后端工程架构角度，聊一下怎样的架构设计，能够让变更观测任务和降噪任务完美配合起来。

首先，咱们需要从产品角度看下降噪最终要呈现什么效果。简单而言，降噪的对象，一块是对于线上告警的降噪，比如critical的告警，假使被降噪模块认为和当次变更无关，那么就可以忽略，所以检测报告里面透出的，可能就是报警的最终结果以及降噪理由。另一块就是对于单个检测能力的结论做干预，这是由于单个能力的告警被降噪，连带做了最终结果的决策。

因此，从最终效果反推，决策降噪模块的切入方面，结果决策作为统一的、低延迟的后处理模块，而告警降噪则作为单独的、容忍高延迟的计算模块比较合适。一个变更观测任务会产出多个观测能力的多个风险告警，这些风险告警在产出后需要经由结果决策模块做后处理，结果决策在后处理的时候，根据所有观测能力产出的告警，查询对应降噪模块是否有对应的降噪结果。有的话，就对风险告警和观测能力结论做干预，以提升观测整体的准确率。

之后，结果决策模块，做的简单的话，可以通过线性或者决策树的方式对不同业务/能力/告警的降噪优先级做配置，这样就能够实现对不同业务场景的定制化降噪，复杂的话可以支持平台化低代码的降噪策略配置，这样业务可以自主做一些策略接入。告警降噪实现模块的话，从不影响正常变更观测任务的调度考虑，可以做成异步降噪。也就是说，降噪模块能够实时感知变更观测任务的上下文，且当某变更观测能力产出新的告警时候，立即对新的告警数据做分析，发起一个分钟级的任务，判断对单条告警以及变更观测结论是否都做降级。同时，降噪模块需要给决策模块提供一个接口，以供获取当前观测任务具备时效性的降噪结果集，这样从决策模块角度，获取的数据也是置信的，而降噪数据的时效性则统一由外挂的降噪模块做保障。

最后，如果要评估某个降噪能力的效果，降噪能力的灰度放量、实时打点，以及产品方面告警有效性打标、降噪结论度量看板等能力也是不可少的。拥有这些技术基建，才可以让变更防控降噪模块发挥更多价值。