【测试人生】变更风险观测的流程逻辑设计

在线上服务变更过程中，我们希望可以通过一套实时观测机制去监测线上服务的风险，从而能够确保线上稳定性，在出问题是可以及时回滚变更。今天这篇文章，就简单讲一下变更风险观测的流程逻辑需要怎么设计。

首先需要明确变更观测的相关概念。变更观测是一个有生命周期的过程，当服务变更开始后观测开始，当服务变更完一段时间后观测结束，所以要有一个任务的概念，需要做任务的元信息和状态转换定义，以及怎么去一个个把任务调度起来。

然后，再细一个粒度，对于一个特定的变更风险点，我们需要用一个特定的观测能力去cover，所以需要有一个能力的概念。一个能力也和任务一样，有自己的元信息和状态转换定义，但是每个能力实例的调度需要关联一个特定的任务，也就是任务对能力是一对多的关系。这样子，就暂时满足了概念定义上的基础。

之后讨论下一个变更观测任务需要怎么去跑流程。首先观测任务的输入，包含以下几些内容：

• 变更工单：哪个服务，哪个批次或阶段，具体的明细信息
• 观测策略：启用哪些监测能力，观察多久，每个检测能力具体的配置
• 服务状态：服务的集群实例、指标状态，上下游信息，关联的库表

从这些信息出发，我们需要做的就是以下动作：

• 任务创建
  • 预处理任务启动参数，确定需要观测的服务对象
  • 获取观测策略，确定需要启动的监测能力
  • 落库一条任务记录，调整为init状态，缓存观测能力和服务对象等上下文信息
  • 返回任务记录，任务创建完成
• 任务推进
  • 确认任务是否在终止态，如果没有终止就继续推进
  • 确认任务是否需要提前终止（比如变更取消的情况）
  • 确认当下需要新启动哪些检测项，如果有需要做异步启动，关联这个任务
  • 确认已启动的检测项最新的状态和结果是什么，做状态推进动作
  • 对当下的结果做动态降噪，如果有必要则实时旁路告警，缓存最终决策的结果
  • 确认是否所有检测项达到终止态，达到则终止任务，做执行结果和告警的最终落库

最简单的动作是这些，当然其中每个点还有很复杂的部分，比如获取观测策略怎么匹配、去重，观测策略怎么应用到每个能力里，需要做什么转换和替换逻辑，监测能力创建和运行的时候，需要获取哪些外部的服务上下文信息，以及推进任务流程的时候，具体怎么状态转换，怎么降噪，都是需要细节下来写的。更别说如果这套模式用到实际的业务场景，可能需要补充很多定制化的逻辑节点，解决的话，就是需要把定制化的逻辑节点以支线的方式放到主线里面，扩充主线的流程长度和节点就可以。

当然，如果要更进一步描述变更观测过程的话，通过一条主线链路加上多条支线链路的方式，并非最完美的描述。变更观测从行为上看，其实可以用一个行为树来描述，也就是说观测的每一刻，我都需要动态地判断哪个检测能力要启动，哪个能力要停止，启动的话传入什么参数，不同时间点传的参数也会不一样，以及线上如果有其它的变更事件，需要对任务怎样动态调整。

在行为树的基础上，变更观测也可以去做到对线上状态具备“五感”的能力，线上状态是可以被服务指标、告警事件等数据做描述的，观测者就是在不断地收集线上数据，根据自己的算法经验，做一些降噪或者告警的决策，一直在做这一些动作。如果能够实现变更观测的行为树和“五感”能力，那才能认为变更观测做到了智能化。