在先前的文章中，我們聊到了一個變更觀測任務可以通過什么樣的方式對不同的變更防控能力做統一調度，達到優越的變更風險攔截效果。但是在實戰當中，變更觀測任務集成了很多能力，即便風險攔截率很高，但不同能力效果也有差距，因此會有可能出現誤報，導致變更觀測結論不準確，影響研發發布效率。為此，一套成熟的變更觀測系統，是需要嵌入一個決策降噪模塊，通過干預變更防控攔截結果，達到在風險召回不劣化的同時，提升準確率，讓結果更加置信。

因此，今天筆者決定結合自己的工作經驗，簡單聊一下變更風險防控架構的宏觀體系當中，決策降噪模塊應當怎樣接入比較合適。需要說明的是，本文不涉及具體降噪的實現，包括算法的許多部分，主要是從后端工程架構角度，聊一下怎樣的架構設計，能夠讓變更觀測任務和降噪任務完美配合起來。

首先，咱們需要從產品角度看下降噪最終要呈現什么效果。簡單而言，降噪的對象，一塊是對于線上告警的降噪，比如critical的告警，假使被降噪模塊認為和當次變更無關，那么就可以忽略，所以檢測報告里面透出的，可能就是報警的最終結果以及降噪理由。另一塊就是對于單個檢測能力的結論做干預，這是由于單個能力的告警被降噪，連帶做了最終結果的決策。

因此，從最終效果反推，決策降噪模塊的切入方面，結果決策作為統一的、低延遲的后處理模塊，而告警降噪則作為單獨的、容忍高延遲的計算模塊比較合適。一個變更觀測任務會產出多個觀測能力的多個風險告警，這些風險告警在產出后需要經由結果決策模塊做后處理，結果決策在后處理的時候，根據所有觀測能力產出的告警，查詢對應降噪模塊是否有對應的降噪結果。有的話，就對風險告警和觀測能力結論做干預，以提升觀測整體的準確率。

之后，結果決策模塊，做的簡單的話，可以通過線性或者決策樹的方式對不同業務/能力/告警的降噪優先級做配置，這樣就能夠實現對不同業務場景的定制化降噪，復雜的話可以支持平臺化低代碼的降噪策略配置，這樣業務可以自主做一些策略接入。告警降噪實現模塊的話，從不影響正常變更觀測任務的調度考慮，可以做成異步降噪。也就是說，降噪模塊能夠實時感知變更觀測任務的上下文，且當某變更觀測能力產出新的告警時候，立即對新的告警數據做分析，發起一個分鐘級的任務，判斷對單條告警以及變更觀測結論是否都做降級。同時，降噪模塊需要給決策模塊提供一個接口，以供獲取當前觀測任務具備時效性的降噪結果集，這樣從決策模塊角度，獲取的數據也是置信的，而降噪數據的時效性則統一由外掛的降噪模塊做保障。

最后，如果要評估某個降噪能力的效果，降噪能力的灰度放量、實時打點，以及產品方面告警有效性打標、降噪結論度量看板等能力也是不可少的。擁有這些技術基建，才可以讓變更防控降噪模塊發揮更多價值。