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