引言
本期分享主题是B站SRE流程中心实践，本期分享内容为谈谈Google SRE工作手册、SRE业务流程化的挑战、流程中心设计与核心技术要素、B站流程中心实践，以及总结与展望。
一、谈谈Google SRE工作手册
（1）专注于长期项目而不是琐事
“当SRE团队平稳运行时，团队成员应该可以感觉到自己能轻松地处理所有工作。他们应当不仅能从容地处理工单，而且仍有时间花在长期项目上，这些长期项目一旦完成，管理服务将会变得更加容易。”
（2）On-call中无法预测的工作量
“你永远无法预测在on-call时会出现什么问题，或者工作量会是多少。一方面，一个关于磁盘空间用尽看似简单的工单，可能会引起对重复发生的垃圾收集作业的深入研究。另一方面，20+个告警风暴可能只是监控系统的小问题。”
（3）频繁的中断导致超负荷
“特别是在进行运维工作时，过多的中断很容易导致团队从正常的工作负荷升级到超负荷。频繁的中断会导致超负荷，而超负荷更会对运行状况和生产效率产生负面影响，超负荷会给团队成员带来心理压力，这会进一步影响工作，导致恶性循环。”
二、SRE业务流程化的挑战
（1）SRE效能提升挑战重重
企业的经营多样化和业务多向探索，致使业务线的种类繁多。各业务特性差异大、场景众多，数量庞大，靠人力难以收敛常态化的琐事需求。
在单一业务下，随着云原生、微服务的推行，业务应用的扇入扇出带来了服务数量规模和接口调用范围的大爆炸，进一步提升了SRE的运营复杂度和成本。
在国内SRE实践中，80%的SRE团队均由企业现存的运维团队转型而来。SRE成员在研发侧的能力积淀有限，难以完成大型自动化和稳定性项目的设计和研发工作。相比业务团队的多职能、明细化分工，运维、SRE团队本质也是独立业务领域，缺少专业的产品、运维、测试等职能成员。从手工 => 平台 => 产品，跨度太大，兼顾不下，单纯运维/SRE团队难以支撑专业业务领域的平台化建设要求。
（2）SRE流程化四大难题
三、流程中心设计与核心技术要素
（1）什么是流程中心？
流程中心提供了一个功能完善的业务流程平台，业务可以在流程中心完成一站式的流程配置和管理。
（2）流程中心覆盖的企业场景
流程中心作为低代码平台的重要组成部分，实现了信息化技术与企业的深度融合，推动了企业的数字化转型 。它支撑了企业众多场景的自动化：
（3）流程组成
（4）回调机制
（5）动态表单配置
提供业务建模、表单设计等功能，通过方便快捷的在线表单设计快速生成表单，用于流程审批和业务逻辑处理。
（6）规则引擎设计
（7）规则引擎实践
基于MongoDB表达式实现的规则引擎六大特征：
• 原生JSON结构，易于解析
• 并行计算优化
• 短路优化，减少无用计算
• 多种数据类型支持
• 热点规则缓存
• 结构可视化
（8）节点编排
如果说动态表单构成了流程中心展示层的灵活性，那么节点编排就构成了流程中心在流程构成中的自由度。流程上下文是贯穿流程的全局变量，每个节点如同一个函数，运行并计算出相应的结果值传递到下游节点做分支判断。如下图所示：
功能特性：
（1）展示形式灵活
（2）支持在线Mock数据
（3）支持调试
（4）接入成本低
（9）版本控制
组成流程的相关元素不支持动态变更。
★ 每一个流程都由流程模版的某一版本生成
★ 动态表单版本由流程模版版本绑定的表单模版版本决定
★ 编辑流程模版并保存将产生一个版本，发布并打上Tag后即可根据此版本发起流程
★ 支持版本回退以及流程模版Debug
（10）流程合法性检测算法
• 流程引擎中可以使用邻接矩阵来辅助判断流程是否是一个合法的有向无环图（DAG）。邻接矩阵(adjacency matrix) 是指一种方阵，用来表示有限图。它的每个元素代 表各点之间是否有边相连。
• 判断一个图是否为有向无环图的算法有卡恩算法和深度优先搜索（DFS）。深度优先搜索以任意顺序循环遍历图中的每个节点。若搜索进行中碰到之前已经遇到的节点，或碰到叶节点，则中止算法。
（11）效率工具
11.1 效率大盘
(1) 节点审批耗时统计
(2) 流程发起总数排行
(3) 个人、部门和总数多维度统计
11.2 多种通知机制
(1) 基于RabbitMQ的死信队列实延时通知
(2) 基于Redis ZSet实现定时通知
(3) 基于用户标签系统实现每日通知
四、B站流程中心实践
（1）Comet流程中心
Comet流程中心是B站以业务为核心、流程为导向构建的新一代流程中心。
1.1 强调流程、人员和技术三大要素的有机结合
1.2 根据企业的具体情况制定人员的岗位职责、设计日常流程
1.3 以建立完备、关联的业务资源配置管理数据库（CMDB）为基础和切入点
（2）技术架构
2.1 平台层：提供平台接口和开放接口给用户及平台调用
2.2 程序层：由管控层、引擎层和异步执行层三大块组成
★ 管控层：负责模版、插件、请求的鉴权和图的合法性检测。
★ 引擎层：负责流程的核心功能如发起、流转、拒绝、关闭、加签和转签等。
★ 异步执行层：负责流程引擎产生的事件动作的处理。
2.3 存储层：提供基础的数据存储、事件通知等基础支持
（3）全场景覆盖
（4）SRE案例-缓存资源变更申请
4.1 服务和应用需要使用缓存的情况下通常需要借助流程引擎实现相关资源大小合理性的评估以及资源的自动化创建。
4.2 该流程往往需要申请人填写对应的缓存资源的信息，如：内存大小、归属集群、申请应用。
4.3 根据变更的行为来控制流程的流转，保证了变更幅度比较大时的安全性。该流程使用了流程插件来回调缓存平台，执行审批后的Hook操作。
（5）SRE案例-变更封版
基于SRE对网站稳定性的要求，事件平台基于Comet开发了一套封控规则。当用户在非工作时间段使用发布平台做发布时，如果命中封禁规则，则需要根据变更服务的SLA做不同级别的审批逻辑。
（6）数据体量
五、总结与展望
（1）总结
流程中心驱动业务按照公司设定的固定流程去流转，在复杂多变的业务情况下，使用既定的流程能够提高工作效率，降低设计业务成本，保证业务执行的准确性。
自Comet 2019年立项以来，累计多版本迭代并稳定运行至今，业务涵盖基数据平台、运维平台、中间件平台和推送平台等多个平台业务。
Comet在B站的SRE实践中发挥着重要的作用，帮助实现了自动化测试、部署、发布等工作流程的自动化处理，优化开发流程，提高效率和质量，并且实现自动化管理和监控，提高系统稳定性和可靠性。相信这些实际的案例和收益，对于大家在日后的SRE实践中也会有所启发和帮助。
（2）未来规划
2.1 子流程/内嵌流程实现
2.2 多语言脚本/插件支持，流程配置从低代码到零代码
2.3 丰富前端组件，提供开箱即用的可视化能力
2.4 优化版本控制能力，支持压缩模版改动
六、互动答疑（Q& A）
潘俊杰
哔哩哔哩-资深开发工程师
2021年加入B站，负责流程引擎、数据库运维平台的研发，有着多年SRE相关经验.主要关注于提高流程引擎的性能和稳定性，通过对现有流程的优化以及引入新的技术手段，使得公司的业务得到了更高效的处理。同时，致力于数据库运维平台的开发，以便为公司提供更加可靠、高效的数据存储和管理服务。目前在SRE平台工程团队负责负责CMDB（配置管理数据库）系统的开发工作。
Q1:一般认为 SRE 是强调自动化的，为什么还要再建设一个流程平台？
A1: 流程是主要为了自动化更好的实施，因为虽然说 SRE 强调自动化，但是在我们的实际的工作中，其实我们还是需要建设流程平台，因为其实自动化不是万能的，有些情况其实需要我们的人工的干预与决策，因为流程平台可以将这些流程和工作标准化，并且规范化。然后我们还可以去跟踪我们的工作流程，确保我们的工作的这个高效性和质量。此外其实流程平台还可以更好地帮助我们的团队去协同和沟通，比如说像我们在完全自动化场景，可能我们没办法覆盖到像中间环节的debug，或者说是我们在流转的过程中去做一些审批操作。然后这些的话其实都是需要我们流程中心的一些功能或者一些特性才能完全达到的。其实它本质上是提高我们的工作效率和准确性。因此其实我们SRE 团队中建设流程平台其实是非常必要的。
Q2: Comet流程中心是一个开源的平台吗？还是说是从头到尾闭源做出来的？
A2:流程中心，它本身是并没有使用开源的软件设计。因为我们第一版是用 Python 写的，然后后续我们再又通过我们的 Golang重构了一版，整个过程中其实是没有使用开源软件。目前为止还是一个闭源的商用软件，暂时没有对外提供服务。
Q3:Comet流程引擎目前有开源的计划吗？
A3:这个也是在规划中的，因为我们开源不仅我们本身的一个技术原因，同样需要我们公司的审批，满足我们的整个开源的一个策略。
Q4:这个存储层里面用到了MySQL，但现在好像 Postgre SQL 开始比较流行了，它是国外比较主流的一个数据库。咱们现在有用 PG 嘛？
A4:暂时没有。Postgre SQL 的话，我之前了解的是我们的离线计算一个Airflow，好像是用了Postgre，但是首先因为我们的公司的自主引擎的支持的主流其实就是MySQL，所以说我们通常会选用我们公司支持的这种，以统一技术栈，防止提高我们整个公司的一个维护成本。
Q5:数据体量中，2022年的 100w+流程具体是什么意思？是 100 万个工单吗，还是 100 万个审批流 ？都是人在审批吗，还是有自动授权？
A5:就是一百万个审批流程，比如上面我说的变更封版。有自动授权，因为我们作业系统之前也是接入我们流程来做一些自动化的编排，所以它会有那种纯自动化的这种节点。因为我们节点的格式它是支持自动流转的，所以说在我们做一些纯自动化的一些流程的话，我们在后面的流程中心也是可以支持的。当然，绝大部分流程它还是会有一定的审批的场景存在的，用以防止我们一些不可预知的错误对我们的这个系统造成一些危害。
Q6: 流程平台和自动化的关系是什么？有没有先后实时顺序？
A6:流程平台和自动化是密切相关的，因为流程平台是我们企业内部标准自动化流程的一个承载者。我们刚刚提到了一个自动化节点，它其实就是服务于我们的这个自动化的。然后自动化其实是基于我们这些标准化的流程来实现的。其实在企业内部我们实施自动化之前，我们通常需要先建立我们的标准化流程，只有建立了我们标准化流程之后，我们才能把它固化在我们的平台中，然后使得所有人能按照我们这个相同的规则来开展我们的工作，这个就是我们实现自动化的一个前提。所以说，流程平台应该先于自动化来实施，然后来更好的去服务于我们的这个自动化过程。
Q7: 流程平台有 ITSM 平台吗？是什么关系？有没有先后实时顺序？
A7: 流程平台和 ITSM是相关，但不完全相同的一个概念。因为流程平台的话，它是可以用于我们实现各种业务流程以及工作流程的一个自动化。包括像 ITSM 中涉及到了一些像变更管理、故障管理，还有包括像服务请求管理之类的。ITSM 其实是一种管理方法论，它本质的意义在就是通过标准化和规划的方式来提供高质量的 IT 服务，然后 ITSM 其实包括许多流程和实践，但不仅限于我们流程自动化，它也包括其他的，比如说像服务策略，包括像服务策划以及服务设计等。然后在实践过程中，其实我们可以先实施ITSM，以确保我们基本的这个服务管理流程以及实践先落地。然后我们再通过我们引入流程平台来去更好的支持和优化这些流程和实践。当然也可以说先实施ITSM，同时引入流程平台，然后来更好支持我们流程的一个自动化以及优化。因此其实没有什么固定的这个先后顺序，需要根据我们的这个具体的情况来进行考虑，我们具体的ITSM是先于流程平台实施，还是说是先做流程平台。
Q8:接口编排用的什么框架？
A8:接口编排的话，你可以用流程引擎做一系列的一个接口编排，因为如果接口平台是指接口调用的话，那其实我们无论说是通过流程平台也好，或者说流程中心也好，还是说通过像我们离线的开源的一些组件，比如说像 Airflow 这种，它其实也可以实现到我们就是接口的这个调用级别的编排的。
Q9:建设流程平台有什么经验教训？如果相关的其他公司要实现这个流程平台，你有哪一些落地建议？
A9: 建议主要就是在于我们的流程平台的设计通常需要，其实主要是要做出来一个点，就是它的通用性。无论说是展示层还是集成层面，我们提供的这个插件也好，表单也好，需要足够的通用化。因为一旦我们只提供一些比如说固化的一些组件的话，那其实对于我们业务方面的需求来说的话，它是无法满足的。并且同时我们还要注意的就是我们不能过度的去依赖三方平台，因为一旦就是依赖的三方平台出现问题的话可能会导致整个系统瘫痪。所以说我们做了一些插件，包括还有像回调机制，这个就是为了和我们的这个业务平台解耦。然后同时也要考虑我们建设平台是需要考虑一些扩展性，尽可能采用我们可扩展的一些技术和架构，以便在未来，比如说像流程中心，它可能采用微服务的架构，如果我们用一些可扩展架构的话，那我们的整个的这个流程、这个系统稳定性包括一些扩展性它会得到一个质的提升。然后同时的话我们也要去考虑一些安全性，因为我们流程平台它涉及的一些数据，包括我们三方平台给我们的一些数据，我们可能需要一定的加密机制来保证我们数据的安全性、灵活性，方便地适应市场需求、公司内的需求，以及我们的平台用户的一些需求。
Q10:跟 SRE 相关有没有一些国际的一些培训认证？
A10: 有的，目前国际上认证机构DOI （DevOps Institute），有一些跟 SRE相关的系列认证，课程是比较多的。包括SRE Foundation认证、SRE Practitioner认证、可观测性认证等。
往期精彩视频回看：
