基于变更事件的巡检回归配置能力
一、前言
变更管控平台对接了公司绝大部分的公共变更系统以及业务系统，收拢了研发侧的变更数据，做到了变更事件的数据可查询、可追溯；并且约定了公司级别的违规变更事件，通过数据推送至各个变更平台，实现卡点与违规变更识别；在变更下游，通过线上巡检与线下回归的手段，识别变更存在风险。
二、巡检与回归能力现状
目前酷家乐支持的巡检能力有：日志巡检、慢sql巡检以及接口巡检；回归能力有UI自动化、接口自动化以及各业务方自建的一些回归平台。在巡检回归配置支持之前，巡检的配置触发逻辑比较粗糙，主要体现在：
- 单一A服务变更后，巡检也是围绕A进行，不支持依赖链路上的巡检触发逻辑
- 巡检内容相对简单，仅围绕巡检平台上的能力进行，不支持回归能力
- 巡检的触发配置只支持一大类变更类型的配置，且都是系统级别的配置，用户不能自定义配置
- 对于UI巡检，无法与目标前端应用绑定，只能通过定时或者手动触发来回归
三、变更管控平台的巡检回归配置能力
巡检回归配置能力把具体的一个变更事件作为触发源，当事件发生后，去触发对应的巡检或者回归，而变更事件与巡检回归的关系，用户可通过配置自由搭配，即一个服务（应用）在一种环境下发生一种变更类型的维度配置。
巡检配置功能解决了上述的问题，变更管控平台也相当于作为了巡检和回归能力的调度平台：
- 一改以往A服务只能触发A服务自身的巡检，现在还支持强依赖的A、B服务（或pub应用、仓库、分组），在A服务发生变更后，去触发B服务的巡检或回归
- 通过各个回归平台的对接与巡检平台的合作，支持的回归手段和巡检能力种类也大大增加
- 除了变更管控平台系统配置的一些必要巡检规则，用户还可以根据自身需求去配置不同的规则，且配置力度也更加精细，触发源不仅支持前后端发布，更支持配置变更、数据变更等全部变更种类
下面主要列举下巡检配置的使用场景：
1、我关注后端服务A，当后端服务A在某个环境发生某种变更时，我需要触发相应的巡检策略；如：当prod环境发生biz-drawing服务的后端代码发布时，就会触发biz-drawing的日志巡检
2、我关注前端应用B（仓库/分组），当应用B发生某种变更时，我需要触发相应的巡检策略；如，当prod环境发生了前端应用A的发布时，就会触发对应的UI自动化场景
3、我有个自建的回归平台，需要在某种变更后触发对应的回归集如，当prod环境发生了C服务的发布，就会触发“渲染集群回归”平台的“渲染后台线上巡检”场景
4、我的服务A，强依赖服务B，服务B的变更对我影响巨大，当服务B发生变更后，我需要触发服务A的巡检策略；如，当search-algo服务在prod环境发布时，就会触发search-qp服务的日志巡检；在依赖链路上，也是可以跨越前后端的，这里举一个真实使用场景，前端的一个页面依赖后端返回的数据，有个同学就配置了在后端进行发布时，去触发对应的UI自动化回归该页面
四、巡检回归风险识别
在变更下游，若巡检回归的结果存在问题，则对应的变更事件存在一定风险，我们将这风险与变更事件绑定，并创建在变更人的名下创建一个风险事项，围绕该事项去监控风险问题解决状态，督促变更人员解决存在风险
风险提示：
五、结果展示
通过对风险事项的统计，在最近一个月的时间内，创建风险事项总数：138个
有效问题发现：用户填写问题原因和措施，且措施进度100%的事项：
- 数量：29个
- 有效问题发现率：29 / 138 = 21%
无效事项：用户点击拒绝的事项：
- 数量：46个
- 拒绝率 = 46 / 138 = 33.3%
逾期事项：用户未处理的事项：
- 数量：63个
- 未处理率 = 63 / 138 = 45.7%