在线上服务变更过程中,我们希望可以通过一套实时观测机制去监测线上服务的风险,从而能够确保线上稳定性,在出问题时可以及时回滚变更。今天这篇文章,就简单讲一下变更风险观测的流程逻辑需要怎么设计。
首先我们需要建模变更观测的过程。变更观测的生命周期,一般来讲,当服务某阶段变更开始后,观测会开始,然后当服务某阶段变更完,一般还需要停留观察一段时间,确定线上没有遗留风险之后,观测才会结束。可以简单的认为,一次变更观测,关联一次发布的某一个过程。所以一个观测任务,结构数据上需要包含发布工单的元信息、观测参数的元信息,以及任务自己的运转状态,同时每个任务实例需要被有序的调度起来,因此所以要有一个调度系统去处理每个任务实例的状态推进。
然后,再细一个粒度,对于一个特定的变更风险点,我们也需要用一个特定的观测能力去cover,所以对于每个观测能力,也要和上层的观测任务一样,有自己的元信息和状态转换定义。任务对能力是一对多的关系,一个观测任务当中,可以通过某种编排,把不同能力在不同的时间点启动起来,切入到发布过程的不同时机,这样就能够形成灵活的变更观测。
从这些角度出发,以一个简单的串行思维,整个变更观测任务需要做以下的动作: