在线上服务变更过程中，我们希望可以通过一套实时观测机制去监测线上服务的风险，从而能够确保线上稳定性，在出问题时可以及时回滚变更。今天这篇文章，就简单讲一下变更风险观测的流程逻辑需要怎么设计。
首先我们需要建模变更观测的过程。变更观测的生命周期，一般来讲，当服务某阶段变更开始后，观测会开始，然后当服务某阶段变更完，一般还需要停留观察一段时间，确定线上没有遗留风险之后，观测才会结束。可以简单的认为，一次变更观测，关联一次发布的某一个过程。所以一个观测任务，结构数据上需要包含发布工单的元信息、观测参数的元信息，以及任务自己的运转状态，同时每个任务实例需要被有序的调度起来，因此所以要有一个调度系统去处理每个任务实例的状态推进。
然后，再细一个粒度，对于一个特定的变更风险点，我们也需要用一个特定的观测能力去cover，所以对于每个观测能力，也要和上层的观测任务一样，有自己的元信息和状态转换定义。任务对能力是一对多的关系，一个观测任务当中，可以通过某种编排，把不同能力在不同的时间点启动起来，切入到发布过程的不同时机，这样就能够形成灵活的变更观测。
从这些角度出发，以一个简单的串行思维，整个变更观测任务需要做以下的动作：
- 任务创建
- 预处理任务启动参数，确定需要观测的服务对象
- 获取观测策略，确定需要启动的监测能力
- 落库一条任务记录，调整为init状态，缓存观测能力和服务对象等上下文信息
- 返回任务记录，任务创建完成
- 任务推进
- 确认任务是否在终止态，如果没有终止就继续推进
- 确认任务是否需要提前终止（比如变更取消的情况）
- 确认当下需要新启动哪些检测项，如果有需要做异步启动，关联这个任务
- 确认已启动的检测项最新的状态和结果是什么，做状态推进动作
- 对当下的结果做动态降噪，如果有必要则实时旁路告警，缓存最终决策的结果
- 确认是否所有检测项达到终止态，达到则终止任务，做执行结果和告警的最终落库
当然，其中每个点还可以详细挖掘，首先是观测策略怎么去匹配。策略的匹配，涉及到每个变更渠道会通过什么样的方式去管理资源，有些渠道可能具备业务性质，通过树结构去管理每个业务下面的资源，有些则可能是简单的uuid的形式。
这里，如果渠道是通过树结构管理资源的话，那么需要考虑一条root到leaf的路径上，对应的观测策略要取哪些，是取leaf就近的一个，还是说所有都取，或者是其它怎么样的逻辑。从笔者的经验来讲，一个比较合适的方式是，所有都取，但每个策略需要排优先级，按照优先级去去除同质的检测项。这样通过组合代替继承的方式，可以兼容渠道各种管理资源的方式，也可以满足更多的业务需求。
然后是不同的观测能力怎么去做联动。好比说，对于某一个风险点，我们需要把变更上下文分析、数据告警监测、结果降噪、风险周知以及根因分析这些能力给串联起来，对于其它风险点又可能有不同的能力联动和切入条件，那么整个任务的逻辑编排将会是非常复杂的，简单的一个实现思路是通过一条主线链路加上多条支线链路去兼容的方式，但这也并非最完美的描述。
从一个产品化的角度讲，变更观测从行为上看，其实可以用一个行为树来描述，也就是说观测的每一刻，我都需要动态地判断哪个检测能力要启动，哪个能力要停止，哪个能力的上游依赖完成了可以运行，然后启动的话传入什么参数，不同时间点传的参数也会不一样，以及线上如果有其它的变更事件，需要对任务怎样动态调整。对于用户而言，可以通过可视化的方式去编排整个行为树，这样就可以让用户非常方便地去定制化编排整个观测任务。
最后就是决策结果怎么和发布工单联动。从变更质量管理的角度来讲，我们通常希望变更观测出现风险时，对变更渠道的发布过程进行卡点或者其他流程干预操作。要实现这个事情，更多的考虑还是变更观测方和变更渠道方在合作模式上怎么达成共识。一般来讲合适的方式是，渠道本身发现任务结果fail然后去卡流程，但风险确认跳过的操作统一注册给变更观测方，在跳过时变更观测报告调整为skip状态并且skip掉渠道的卡点。这样一来不会有过多侵入的操作，二来也能够达到变更管控的效果。