云音乐预案平台实践后端架构微服务

图片来源：https://unsplash.com
本文作者：帝青

一、背景随着服务化的大面积推开，服务稳定性越来越被重视起来，云音乐从2018年开始进行稳定性能力建设，到最后建设成通用能力，云音乐大概经历了以下几个主要阶段，从2018年无稳定性保障能力的裸奔阶段，到稳定性能力的搭建，再到提升易用性、效率的平台一体化建设，
到包括近期做的预案管理平台化建设，每一次的演进，都能为云音乐整体稳定性添砖加瓦，今天我们主要介绍下预案平台化建设的一些实践；

文章图片

1. 预案是什么？百度百科中给我是这样解释的：
预案，是指根据评估分析或经验，对潜在的或可能发生的突发事件的类别和影响程度而事先制定的应急处置方案。
上到国家大事，下到一件很小的事情，都会涉及到一些预案：

比如我们经常会看到电影中的一些场景，有PlanA、PlanB、PlanC...,其实这就是我们的预案，实施PlanA、PlanB还是PlanC是根据不同的场景来决定的；
就拿这次新冠病毒疫情来说，其实政府早就有自己的一系列预案来应对不同等级的突发事件（中华人民共和国应急管理部主要负责组织编制国家应急总体预案和规划，指导各地区各部门应对突发事件工作，推动应急预案体系建设和预案演练）；
云音乐经常会做大型活动，在活动前做很多的压测、演练，这期间会梳理在出现某些事件的情况下预案，比如某个服务扛不住了，需要做一些降级，如果还是扛不住需要继续做降级或限流等；

2、云音乐预案现状在云音乐大型活动保障过程中，会做常规演练、压测等进行容量评估和摸底，对于可能出现的风险会做评估，并做防范性的准备，其实这些准备就是预案，比如Plan A， Plan B。在此之前这些预案都是维护在wiki上（例如台风项目的各业务方预案）或者我们自己的记事本上，在具体发生了某个场景的时候我们会去执行Plan A或Plan B，所有这一切都是凌散且不统一，当涉及到大量人员时协作成本非常高预案的可执行性会比较差；另外一点就是缺乏演练，无法做到预案的有效性；
3、预案长啥样？ 【云音乐预案平台实践】预案到底是什么，提供了什么样的能力？预案一般有一些通用的能力，我们去搜索引擎里搜预案能得到各种各样的答案，但可以归纳为以下几个组成部分，比如此次预案的目的、适用范围，预案等级，预案负责人，触发条件，达成情况（预案执行后），后置处理（如何恢复）等的一些事项，

预案目的、适用范围：本次预案主要是用于完成什么样的事项，能够用到什么场景下，比如是压测场景、保障什么等级的活动等；
触发条件：开启该预案的条件是什么，通常情况下我们会根据我们系统的状态来看需要开启哪个预案，比如通过监控、告警等来告诉我们当前系统所处的状态，是否达到了预案的执行条件，比如当服务端超时阈值达到多少时，就开启限流或者主动降级的预案；
如何恢复：一般情况下，预案都是针对某个突发场景而设立的，所以在预案执行完成后，需要做一些善后的工作，将预案恢复到常态下；
达成情况：预案在执行后，需要及时填写一些达成情况，用于验证预案是否符合预期，如果不符合预期，需要记录不符合预期的事项，为后续预案优化和复盘提供数据支持；
预案等级：一般情况下，我们会给预案设置一些等级，看到这个等级我们就会知道当前预案的重要程度，是否有损等信息，更容易做一些上层的梳理；以下为云音乐的预案的等级描述：
- L0预案：事前预案，对业务的影响程度极小，对用户是无感知的(不会有操作体验上的感知)；
- L1预案：对业务部分有损(会影响业务数据等)，在预案准备过程中已经和业务线报备过；
- L2预案：一般影响比较大，则需要现场决策后才能执行；

在当前预案平台，预案目的、适用范围，执行条件，如何恢复，达成情况做的比较简单，都是在预案的描述信息中进行填写，并未进行展开；
预案会在事前做一些充分的准备，对预案做充分的讨论、梳理，然后再事中的时候，当触发了某个条件，就回去执行对应的预案，然后会记录预案是否符合预期，在事后也会做一个预案的优化/复盘，如下图所示：

文章图片

二、预案平台化建设 1. 预案平台产生的背景：

最初的预案来自于批量操作的需求，比如多应用限流阈值的批量操作，批量调整降级开关的能力；
各业务方预案大部分情况下主要是针对配置中心配置值、限流阈值、降级规则进行调整；
预案不规范：主要来源于预案的形式是多种多样的，有些是通知我们去做什么事情，比如检查某个配置，检查监控是否符合预期，有些是调整配置中心的阈值、调整限流阈值、调整降级能力，另外从认知上，比如预案等级，存在L0，L1，L2，大家对等级的认知也是不一致的；
没有相应平台提供预案的制定、执行、管控能力：长期以来，这些文档化的预案在wiki上维护，所有这一切都是凌散且不统一，当涉及到大量人员时协作成本非常高预案的可执行性会比较差。

2. 预案平台的概念对齐：在云音乐预案平台中，有三个基本概念：

资源：可以是配置中心的key/value，可以是一个限流规则，也可以是一个熔断降级规则；
预案：归属于一个预案组，是在某些情况下才会触发的，比如在压测前时，可以关闭限流，进行摸高压测；
预案组：是对同一组资源的管理，在预案组下可以有多个预案；比如有一个演练场景，需要对几个限流资源进行调整，对于预案组下不同的预案对应的限流阈值可能是不一样的；

文章图片

整体可以通过上图进行理解，一个预案组包含了多个预案，同时包含了一个资源管理的功能，预案组中每个预案的的资源是继承自资源管理中导入的预案的，每个预案中的资源可以独立调整；
平台化后，预案格式也就能够固定下来了，比如预案模块、负责人、预案级别、类型等信息；
3. 平台化能力

文章图片

平台化（产品化）的预案平台不仅仅是上面的一些预案自身能力，更多的还会从平台化建设角度进行设计，比如审批能力、权限管理、配置的安全性（发布预览、配置比对等）、基本的治理能力；
目前支持限流、降级、配置中心的预案管理能力；
执行计划，为什么会有这个概念，接下来我们会在预案编排中进行介绍；

4. 平台视图以下为预案平台的预案维度管理的视图；

文章图片

三、预案编排很多同学会问到一个问题，预案是否需要编排？这里的编排是指在一次活动中，有多个预案，我是有顺序或者有计划的去执行一系列的预案；
其实对于预案来说这种场景是有的，具体是看业务需求；如果预案执行的可预测性、可评估性比较差，只有在某种情况下才会被启用（仅仅是预防使用），这种情况下不需要预案编排；
如果有些预案执行非常明确，且有些大概率会被用到的，这种编排能力就可能会用到；
所以我们支撑了另外一套能力：执行计划，这里需要明确下执行计划的目标，及其相关概念&能力；

执行计划的目标：
- 提供时间线维度的流程管理、通知能力；
- 提供一个统一的执行视图进行展示。
概念对齐：
- 执行计划：执行流程的管理单位，包含一个或多个执行流程；
- 引用执行计划：通过引用其他执行计划，可以对被引用的执行计划的所属执行流程做一个软链展示；
- 执行流程：执行计划的最小单元，用于存放一个需要执行的内容；
- 描述性预案：作为非执行预案外的执行内容记录；
- 执行预案：当前直接对接了预案模块的预案。
执行计划的能力：
- 丰富的通知机制：目前支持popo、stone、邮件、短信四种通知策略；可以灵活的配置通知时机；
- 简单易用的权限管控机制：目前执行计划维度和流程维度的权限管理能力；
- 执行计划关联能力：便于执行计划之间进行关联，比如多个人针对自己的场景设计了各自的执行计划，从整体上来看，需要合并为一个执行计划，便于从整体上进行统一把控；
- 友好的执行计划可视化能力；如下图：
  
  文章图片
和预案打通，可以支撑预案的编排能力，一个执行计划包含多个执行流程，执行流程可以是预案平台中的预案。

需要着重提示的一点，预案平台和执行计划是两个不同的概念，执行计划是让我们具有编排、通知的能力，而预案是可以作为被编排，每个预案可以作为执行计划中的一个执行流程；执行计划主要是协助业务开发同学做一些流程编排，及流程通知能力，不只是做预案的编排，也能够做一些checklist的管理、通知、看板等能力。
四、一些最佳实践预案平台已有云音乐内部广泛接入，主要是针对稳定性能力的一些配置，同时在预案配置时需要关注的问题；
1. 限流、降级、配置中心预案能够实现限流、降级、配置中心的单独预案能力，同时可以实现在将多个应用、多产品的不同的限流、降级、配置中心的值管理组合到一个预案组中，以达到组合场景下的预案管理能力，并且配有权限管理的能力；

文章图片

2. 预案配置需要关注的问题在设计一个预案时是根据一些场景或演练结果等进行假设的，这个场景可能暂时是我们自身的产品、技术方案设计上或代码上的一些问题，假设我们做了一些优化，但是预案没有及时调整，那么这个预案的有效性就会大打折扣，这时候可能我们会考虑如何及时的将我们的预案有效性提升，防止预案腐化；

预案腐化
- 预案的建设和代码、产品实现息息相关，而代码、产品一直处于快速迭代当中，预案和系统架构一样，在经历一次又一次的需求迭代后不断被“腐化”。如何预案保持活性？目前一个好的方案是将预案演练进行到底，可以配合故障演练一起来做。当然，预案在我们一次次演练和线上实操时不断被完善和补充，这是一个双赢的过程。
- 为了避免预案腐化，保持预案的可执行性，尽量将预案的内容缩减，不要扩大；
预案常态化演练：
- 预案建设是稳定性建设中非常重要的一环，预案设计完成后，不是摆在那里，等对应的触发条件达成后，直接打开，试想一个场景，一个预案在设计了半年后发现出现某个问题符合触发条件，我们这时候要打开，但是预案此时是否已经不符合之前的条件，相关同学可能都没有太大的信心，这是缺乏日常演练导致的结果，所以针对预案要做常态化的演练，这样在常规情况下，才能够更好的进行预案的管理和优化，更好的避免预案腐化；

六、未来规划未来主要会做一些场景打通方面的事项，也会根据业务的试用情况做一些及时的调整，做更多的可扩展的能力，同时在平台化方向也会持续建设；

场景化打通：对于现有的故障演练平台、NPT压测平台、活动保障平台，都需要预案能力；
故障演练平台的打通，需要为故障演练平台设计一个预案，当某个故障被mock后，需要开启某个预案，使得能够在无损或部分有损的去快速拉起服务或保障服务不死；
NPT压测平台，有很多同学在压测的时候需要做一些摸高，但又要保障服务的稳定性，不至于被持续的流量打垮，所以也许要做一个限流的阈值调整能力，这个调整能力是可以得到沉淀的，并且可以将NPT压测和预案常态化进行关联，保障预案的持续有效，不至于被快速腐化；
活动保障平台：搞一次活动尤其是大型活动需要做很多的压测、稳定性保障的事项，所以在这个过程中会涉及到很多的开关、配置、限流等的能力，需要设计N套预案应对；
预案的平台化建设能力增强
- 预案资源层监控能力；
- 预案效果可视化验证；
- 风险巡检能力；
- 更丰富的治理能力；
- 预案自动化执行能力铺垫；
- 执行计划依赖关系能力；
预案日常化推进，尽量避免预案腐化；

七、总结

预案平台是在对配置批量处理需求上建设起来的，而这些批量能力是其中最简单的一种需求场景，预案建设是业务稳定性保障中非常重要的一环，同时预案的平台化建设能够给业务的稳定性保障带来事半功倍的效果；
更多维度进行预案的尝试（场景化打通），将有助于对风险意识、稳定性的提升；
如何将预案演练做到日常化，防止预案腐化仍然是我们需要后续需要继续探索的方向。