关于后端:云音乐预案平台实践

图片起源：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. 预案配置须要关注的问题

在设计一个预案时是依据一些场景或演练后果等进行假如的，这个场景可能临时是咱们本身的产品、技术方案设计上或代码上的一些问题，假如咱们做了一些优化，然而预案没有及时调整，那么这个预案的有效性就会大打折扣，这时候可能咱们会思考如何及时的将咱们的预案有效性晋升，避免预案腐化；

• 预案腐化

  • 预案的建设和代码、产品实现非亲非故，而代码、产品始终处于疾速迭代当中，预案和零碎架构一样，在经验一次又一次的需要迭代后一直被“腐化”。如何预案放弃活性？目前一个好的计划是将预案演练进行到底，能够配合故障演练一起来做。当然，预案在咱们一次次演练和线上实操时一直被欠缺和补充，这是一个双赢的过程。
  • 为了防止预案腐化，放弃预案的可执行性，尽量将预案的内容缩减，不要扩充；

• 预案常态化演练：

  • 预案建设是稳定性建设中十分重要的一环，预案设计实现后，不是摆在那里，等对应的触发条件达成后，间接关上，试想一个场景，一个预案在设计了半年后发现呈现某个问题合乎触发条件，咱们这时候要关上，然而预案此时是否曾经不合乎之前的条件，相干同学可能都没有太大的信念，这是不足日常演练导致的后果，所以针对预案要做常态化的演练，这样在惯例状况下，才可能更好的进行预案的治理和优化，更好的防止预案腐化；

六、将来布局

将来次要会做一些场景买通方面的事项，也会依据业务的试用状况做一些及时的调整，做更多的可扩大的能力，同时在平台化方向也会继续建设；

1. 场景化买通：对于现有的故障演练平台、NPT 压测平台、流动保障平台，都须要预案能力；
2. 故障演练平台的买通，须要为故障演练平台设计一个预案，当某个故障被 mock 后，须要开启某个预案，使得可能在无损或局部有损的去疾速拉起服务或保障服务不死；
3. NPT 压测平台，有很多同学在压测的时候须要做一些摸高，但又要保障服务的稳定性，不至于被继续的流量打垮，所以兴许要做一个限流的阈值调整能力，这个调整能力是能够失去积淀的，并且能够将 NPT 压测和预案常态化进行关联，保障预案的继续无效，不至于被疾速腐化；
4. 流动保障平台：搞一次流动尤其是大型流动须要做很多的压测、稳定性保障的事项，所以在这个过程中会波及到很多的开关、配置、限流等的能力，须要设计 N 套预案应答；

5. 预案的平台化建设能力加强

   • 预案资源层监控能力；
   • 预案成果可视化验证；
   • 危险巡检能力；
   • 更丰盛的治理能力；
   • 预案自动化执行能力铺垫；
   • 执行打算依赖关系能力；
6. 预案日常化推动，尽量避免预案腐化；

七、总结

• 预案平台是在对配置批量解决需要上建设起来的，而这些批量能力是其中最简略的一种需要场景，预案建设是业务稳定性保障中十分重要的一环，同时预案的平台化建设可能给业务的稳定性保障带来事倍功半的成果；
• 更多维度进行预案的尝试（场景化买通），将有助于对风险意识、稳定性的晋升；
• 如何将预案演练做到日常化，避免预案腐化依然是咱们须要后续须要持续摸索的方向。

本文公布自网易云音乐技术团队，文章未经受权禁止任何模式的转载。咱们长年招收各类技术岗位，如果你筹备换工作，又恰好喜爱云音乐，那就退出咱们 grp.music-fe(at)corp.netease.com！