在服务或者其它线上资源发布新版本的时候，我们都有必要为发布信息本身和上线的资源做风险检查，以确认发布内容不会对线上造成影响。通常来说，在检查能力铺垫时，一个主旨的思路是保证问题的召回率，即检查能力本身必须理论上可以拦截更多的风险，这样才能够基本限度保证发布过程的安全。但随着检查能力集合变得成熟，业务也肯定会有对检查能力优化的需求，需要提升检查的准确率，不至于出现太多无用的噪音，这也成为了风险检查提升可靠性的一项挑战。
因此，本文就浅谈一下，提升发布风险检查准确率的一些思路。
首先，我们需要寻找提升准确率的抓手，也就是说从哪些点入手，可以比较有效提升数据。对于一次发布过程，我们可能会应用多种检查能力，而每种检查能力每次运行可能会检查多个检查项。因此，我们需要了解到每个检查能力判定为失败时，发布人回滚发布或是跳过检查的情况，以及这些情况下，每个检查项具体的判定结果为多少。这样就能够了解哪些检查项的逻辑比较靠谱，哪些检查项的逻辑需要做优化。如果可以找到一些典型的案例，那么就能够成为突破口。
举个例子，一个Web-Service发布过程中，我们可能会检查服务的性能和业务监控指标。针对单个业务指标，可能存在不同的告警等级，比如超过某个阈值是Warning，然后再超过一个更高的阈值则是Fatal。在开发检查能力的时候，为了方便交付，我们可能判定如果某个指标为Fatal，则整个检查都失败。但事实上，如果这个指标实际表征的风险程度不高，即便在告警上是Fatal，但发布过程可能还是会被人为强制跳过。这样的监控指标，就是需要优化的典型案例。
然后，才是看如何实施优化手段。比如，上面提到的监控指标严重程度不能很好反映风险度的问题，就有两种优化方向：一种是调整指标本身的设定阈值，一种是在检查过程做风险评分，并为这种指标给一个相对较低的风险权重值。或者，从大的角度，在监测到一个Fatal告警之后，先和变更前线上环境的监控告警情况做对比，如果情况和变更前类似，那么也无需给一个非常严重的检查失败告警。如果是持续性地做检测，那么也需要考虑异常告警的持续性，防止因为部分毛刺导致最终判定结果不置信。
假设我们检查的结果，也分为Fatal和Warning两个级别，在数据上也有一个很基础的优化点，就是将Fatal结果和Warning结果的准确率做区分。如果一个检查项存在不置信的情况，但检查项是基础的必须的，就需要做风险降级。一般而言，Fatal结果的可靠性是需要非常高的，而Warning可是相对可容忍噪音的。因此，需要对各检查能力也做结果优先级划分，对于相对更有置信度的检查能力或检查项，应当考虑做更加严格的风险判定，对于整体的风险评定优先级更高，而置信度较小的，则在风险评定中，优先级放低。
最后，需要注意的是，虽然我们的最终目的是为了提升检查准确率，但召回率是不能丢的，不能因为提升了准确性，导致可拦截的风险面变小。检查准确率提升主要是基于用户体验的优化，而召回率才是真正面向检查能力的SLA。