第四章 流程编排

治兵不知九变之术，虽知五利，不能得人之用矣。是故智者之虑，必杂于利害。杂于利，而务可信也；杂于害，而患可解也。《九变篇》

2.1 实践说

项目正式启动之后，产品经理先设计了原型图，借鉴+创造+整合完成了基本的产品形态，功能要点。按理说该搂起袖子加油干代码了，还是Too Young Too Simple了。本小部门之前也有一定的研发流程规范，但是毕竟人为的东西灵活度很高，任何一个环节都可以根据反馈随时调整、修正，真正要信息化了，首先要解决①埋点收集数据，②合适的节点上必须写入规划的数据。经过基本的推导，按照之前的工作流程习惯，逻辑上就无法匹配设计好的产品功能。

总不能针对本部门的工作方式设计一套DevOps吧，这样整个部门都可以拿个绩效D了，当之无愧。但也总不能无脑的按照竞品或理想化的流程来落地呀，就这么自然而然的回到了所有信息化、数字化的老命题，流程规整必不可少。

最后的结论就是，召开大会讨论了一番研发流程的规整，先从现实世界入手，将工作流程调整到一定的状态，来为接入系统做好准备，并且也结合公司其他部门工作习惯来探索一条“比较优”的流程，来作为标杆，首先能够在不借助系统的情况下把事情做了。

大概最后的共识就是，各个工种如何衔接、该做哪些必须项、前置依赖如何保证等等。最重要的是代码分支如何管理，跟需求如何关联等等。此处只能省略太多字，不敢说的太清楚。

	当前迭代Iter			需求/提测	回归/上线	下个迭代Next
产品
UI
开发
测试

 

2.2 流程是基础

流程管理是实现业务集成化、标准化和模板化的途径。流程反映了业务流，承载了绩效、质量、风控、数据的要求。没有高质量的流程，就不会有高质量的数据。如果流程的活动缺乏明确的规则和标准，就会输出大量不规范、不准确的数据给下游，从而影响业务活动和决策活动的有效性。

即使没有系统，没有信息化，也得首先有合理、高效的流程，这才是强力竞争力的基础，数智化最多的是加持，是锦上添花。妄想通过数智化拯救羸弱流程本身不合理的业务，可能又这样力挽狂澜的高人，可遇不可求之。

企业在流程变革上比较被动，通常是因为当要上各类应用系统时，比如ERP、CRM等，才开始成立项目组，梳理业务流程，从蓝图规划、现状还原、未来流程设计，再固化到系统，十分漫长。这还算比较理想的了。有的企业上系统，只是将现有的流程固化进去。过去没有上系统，流程还比较灵活，大家可以自由发挥，可以规避流程，现在上了系统，矛盾集中爆发，大家纷纷抱怨系统不好用，效率更低了。其实是由于流程长期缺乏优化，随着组织规模变大、分工变细，流程进一步被割裂，同时非增值的活动大量衍生，使得数字化转型困难重重。有一个典型的痛点——企业没有流程架构，由于缺乏架构，流程野蛮生长，业务能力规划无法进行，IT应用架构规划更缺乏基础。此时，谈数字化转型，只是空中楼阁。

那固化一套最标杆、最理想、最合适的流程到系统里，就可以了吗？ToB的系统有这么简单就好了。

2.3 编排的艺术

K8S之所以能从Swarm、Nomad、Mesos等等对手中脱颖而出，成为事实上的标准，它在“编排”这件事情上某些理念肯定功不可没，在流程编排上是否可以借鉴一二。首先得搞清楚什么是编排？

Wiki 百科解释我们常说的编排的英文单词为 “Orchestration”，它常被解释为

本意:为管弦乐中的配器法，主要是研究各种管弦乐器的运用和配合方法，通过各种乐器的不同音色，以便充分表现乐曲的内容和风格。

计算机领域:引申为描述复杂计算机系统、中间件 (middleware) 和业务的自动化的安排、协调和管理。

K8S在容器编排领域，有以下概念和理念，觉得很值得借鉴或山寨用来自己设计调度系统。去年在做发布流水线调度时，觉得需求太定制化，调研过一些开源的类似项目，都没有可以完全照搬的，最后完全自己设计的，扩展能力很弱，直到今年项目二期时才进行了专门的优化与各种任务节点规范化、标准化，才完成了开放平台的建设，新增加一种任务类型流水线服务工作量降低到了之前的25% 以下。事后复盘才总结出其实K8S一直有很多东西摆在那里等待借鉴。

API 对象

API 对象是 K8s 集群中的管理操作单元。K8s 集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的 API 对象，支持对该功能的管理操作。例如副本集 Replica Set 对应的 API 对象是 RS。API 对象都有 3 大类属性：元数据 metadata、规范 spec 和状态 status。

声明式（Declarative）

K8s 中所有的配置都是通过 API 对象的 spec 去设置的，也就是用户通过配置系统的理想状态来改变系统，这是 k8s 重要设计理念之一，即所有的操作都是声明式（Declarative）的而不是命令式（Imperative）的。声明式操作在分布式系统中的好处是稳定，不怕丢操作或运行多次，例如设置副本数为 3 的操作运行多次也还是一个结果，而给副本数加 1 的操作就不是声明式的，运行多次结果就错了。

2.4 结语

“胜兵先胜而后求战，败兵先战而后求胜”，犹如业务的信息化、数智化一样，首先业务做好“胜任”数智化的准备，而后才能双赢。

我们不可能指望祈祷流程能够一成不变、固化的，就能满足所有业务诉求，就像一直使用一样的“阵形”妄想常胜。变幻莫测的排兵布阵、兵无常形，才具备更强的战斗力。既然如此，那么我们只能积极拥抱变化、小步快跑，敏捷开发，扯远了。虽然没有强大的技术实力来支撑任意的研发流程组合，但是借鉴容器编排、流水线编排等等根基能力，做一套一定范围内针对DevOps领域流程编排的系统理论上是可行的。

2.5 成果展览

企业文件建设倒不是说不能建设，这活得加钱。眼下能折腾的，重点就是流程了，工具这些开源+外采+自建，都是确定而且可控度比较高的，不容易出成绩；文化层面又太过不可控了，唯有流程介于两者之间，可以重点关照一下。

重点完成了两大引擎的自主研发，支持用户编排工具集和事项集。①流水线引擎，调度编排各种研发工具，以任务节点的方式可以被管控；②需求工作流引擎，与腾讯TAPD类似，重点针对需求状态流转、迭代阶段配置等。

工作流运转的同时，自动驱动相关流水线的运行，示例如下图。最终的效果是，新入职的小白用户，只需要写代码，按团队规范流转需求，就能够不知不觉中接入了DevOps全周期的相关能力。