（转载自2023年《数字化运维》“聚焦-跨越双态”栏目）

文/王英伟 

由于工作关系，我接触到一些金融机构的运维部门。在交流的过程中，发现无论是高层领 导、还是具体的执行层， 大家都在谈论“双态运维”。 下面我们谈谈“双态运维”的含 义，及如何构建“横跨全流程的双态模型”。 

“双态运维”， 包括“稳态”、“敏态”两部分。 稳态方面， 究其原因， 由于金融机构 ToB产品及技术架构的特性，往往牵一发而动全身。例如，一个政策的变更，往往会导致 从app、支付系统、审计系统到最后核心交易系统整个链条发生变更，会牵涉到跨部门、 多团队的协作；另一方面，由于涉及到经济交易，合规、风控等往往要严格得多，就必然 需要保障系统与产品的高可靠及稳定性。 

敏态方面，由于互联网产品的冲击，要求运维部门必须快速支撑业务发展，更快地响应市 场变化，积极促进新产品布局及商业模式验证。 

一、    “双态模型”概念历史由来

图1 技术发展三大阶段 

首先从技术发展历史的角度，来看看“双态运维”模式产生的基础。纵观近几十年的技术发展，大致可以分成三个阶段。 

l  信息化时代：上世纪九十年代前后，软件开发模式以瀑布模式为主，技术架构则是单体架构模式，至于部署模式则以裸机为主，PC放在数据中心，如需扩容则以纵向扩容为主。此时的应用大多是ToB模式，直接部署在操作系统层，所以此时的运维发布流程则以稳态为主，此时的应用强调安全、稳定，基础设施多采用集中式部署和高端服务器。

l  互联网+时代：到了本世纪初，尤其是“敏捷宣言”发布以后，软件开发模式转变为敏捷开发，各种敏捷开发框架比如Scrum、Kanban等逐一发布。此时的技术架构也发展到了多层架构，其中以SOA和ESB等技术框架为代表。与此同时，虚拟化技术也有了进一步的发展，其中以虚拟机的出现为代表，更加适应了多层架构的部署模式，而集群扩容则以横向扩容为主。

l  数字化时代：到了2015年前后，随着DevOps概念的产生与发展，软件开发模式也发展到了“开发运维一体化”的阶段，主要强调打破开发、运维之间的界限，让两种角色在同一个团队中更好的交流协作。此时的技术架构，则以微服务模式为主，一个应用会有几十个、甚至几百个服务在后台进行支撑。而虚拟化技术则发展到了容器时代，一个虚拟机中可以部署十几个、甚至几十个服务。后台资源则以公有云、私有云的形式，通过自助服务进行扩充。 

由此可见，“双态运维”也是随着软件开发模式、技术架构、虚拟化等技术的发展，逐步发展而来的。归根结底，技术是为业务服务的，必须保证业务价值的最大化。下面以金融行业为例，阐述如何把“双态运维”扩展成“横跨全流程的双态交付模型”。

二、    三线融合，构建“横跨全流程的双态交付模型”

针对软件企业而言，为了完成产品的设计、开发、上市，内部存在着三条线。

l  第一条是管理价值流（如图2所示），主要以业务需求为流动单元，以流程审批、需求管理为主，承载的系统多是OA、工作流程审批、需求管理系统等，从项目管理的角度来规范软件开发相关活动。

图2 管理价值流

l  第二条是构建价值流（如图3所示），主要以实现业务需求的功能代码为流动单元，其中包括代码仓库、编译构建、制品仓库、自动化测试、安全扫描、持续部署等系统，从工程的维度，管理代码从提交到上线部署的相关活动。

图3 构建价值流

l  第三条是发布价值流（如图4所示），主要以发布包为流动单元，管理不同的资源、环境、事件、服务、问题及变更等内容，以ITIL、ITSM等系统为主，从发布运营的维度，来管理部署之后的相关活动。

图4 发布价值流

在金融、能源、生产制造类的企业中，这三条线分别由不同的部门管理使用，比如管理价值流一般由业务、需求、项目管理部门或者人员在使用，构建价值流一般由开发、测试人员在维护使用，发布价值流一般由运维、基础设施团队在维护使用。但企业是一个整体，如何让这三条线更加流畅的协作，以适应业务发展形式的方式，提供有力的支撑，一直是困扰企业多年的问题。

就整个企业架构而言，上层的管理价值流融合了企业内部各个角色，而底层的构建价值流、发布价值流，则承载着各个阶段的管控措施。流程与工具相互结合，才能最终支撑业务价值的交付。

三、    如何构建支持“横跨全流程的双态交付模型“的管理、发布价值流

在项目管理领域，“双态模型”包括稳态、敏态两种模式的开发流程。对于两种模式的产品，其特点对比如表1所示。

表1 项目管理两种模式特点对比

而在运维侧，也存在着稳态与敏态业务，他们的特点如表2所示。

表2 运维两种业务特点对比 

通过对比我们可以看出，只有从产品、项目立项开始，就确定好它的管理、发布模式，在研发侧打通整个平台模块之间的功能，形成联动效果，把发布价值流中的反馈、告警信息转化为新的需求，进行流转，才能从根本上真正支持“横跨全流程的双态交付模型”。 

四、    如何构建支持“横跨全流程的双态交付模型”的流水线

以金融行业为例，其核心系统大多属于稳态模式（此处包括管理价值流、构建价值流、发布价值流三个领域），无论是开发模式，还是上线部署模式，大多以季度或者半年为发版周期。而金融行业的移动端应用或者ToC的业务，属于敏态模式（此处也包括管理价值流、构建价值流、发布价值流三个领域），其开发、上线大多以4~6周为发版周期。

表3 稳态产品流水线类型

为了支撑不同的项目形态，持续集成流水线也需要分成不同的种类，进行交付。比如对于稳态类型的项目，我们一般会分阶段用不同的流水线进行支持，比如预构建、集成构建、版本验证与发布流水线等。而对于敏态项目，一般会使用一条流水线贯穿整个阶段。 

以某金融机构为例，对于稳态项目类型（如图5所示），分为自主开发、定制化、预研流程和平台开发四种流程，那么对应不同类型的项目，就需要几种流水线进行不同组合，来配合发布上线。基础设施侧，也需要通过稳态流程进行支撑。

图5 某金融机构稳态产品管理流程 

而对于敏态项目类型（如图6所示），由于发布周期较短，客户对交互设计、更新频率等内容容错率较低，所以大多数产品，都是使用一条流水线，发布到预生产环境。其中如果出现Bug，则整条流水线停止运行，等待问题解决或者回滚。SIT、UAT、生产环境出现的问题，也转换成新的需求，通过需求流程进行解决。基础设施侧，则需要通过容器化的技术手段，进行发布支撑。

图6 某金融机构敏态产品管理流程

对于持续集成平台，尤其是要支持变化频发的敏态项目，必须具备流程的编排能力。即用户可以自行定义软件交付过程的每个步骤，以及各个步骤之间的先后执行顺序。在流水线设计阶段，按照stages、stage、step这样的三层模式（此处以jenkins file脚本为例）进行流程的设计组装。

综上所述，从持续集成角度而言，也需要区分不同的产品、项目类型，使用不同的流水线类型（一条还是多条）、流水线模式（固定模式还是自主服务模式）进行支撑。 

五、   如何构建支持“横跨全流程的双态交付模型”的管理、发布价值流

图7 流水线产品自助服务示意图

如图7所示，针对传统行业，相对缺乏全栈工程师，所以只能要求各岗位角色各司其职，比较顺畅地共同交付业务功能。对于产品经理、项目管理人员，采用Scrum、Kanban等敏捷框架，加快产品和开发团队的交流协作。对于运维团队而言，只要负责维护基础设施，设计、搭建好流水线模板。对于开发团队而言，只是流水线的使用者，在不同的阶段，对流水线模板进行简单的配置即可使用，一旦流水线出现不能解决的问题，立即通知运维团队进行修复。只有这样做到管用分离，才能以双态的方式，构建“横跨全流程的双态交付模型”。

六、    如何构建支持“横跨全流程的双态交付模型”的效能洞察

从研发数据度量的维度而言，在传统企业，很多度量数据和度量指标，分散在不同的工具或者系统里面。比如需求过程管理数据存储在项目管理系统中，代码提交评审信息存储在代码仓库中，流水线执行的过程信息存储在持续集成平台中，测试报告存储在测试服务系统中，系统监控、日志信息存储在运维平台中等等。

而对于开发过程中每种角色，管理者、产品经理、开发人员、测试人员、运维人员，每个角色的关注点不同，展现的指标数据也不同。但这些指标元数据之间，又存在前后的关联关系。所以对于构建“横跨全流程的双态交付模型”的效能洞察而言，将割裂的软件开发流程收敛到一个平台上，通过收集软件开发全流程的数据，并进行智能分析，从而让整个软件交付过程的全部信息对所有人都可视化。

比如项目管理、开发侧的元数据，则需要分阶段采集，进行统一存储展示，以研发数据链、驾驶舱的形式进行展现，而运维侧CMDB存储的运维的元数据，即可成为连接运维场景的数据桥梁，可供监控、告警等场景使用（如图8所示）。

图8 效能洞察示例

七、    结束语

“双态运维”只是不同类型产品，在运维阶段不同部署模式的一种体现。在云原生技术飞速发展的时代，我们需要尽可能的打破工作领域的限制，以全局的视角，分析从需求提出到上线运营的整个链路，来构建基于“横跨全流程的双态交付模型”。以管理价值流、构建价值流、发布价值流为主线，分别从管理、工程、度量、团队成员工作职责等多维度相互配合，根据企业内部不同的产品类型，选择适合的交付模式，快速、稳定地为最终用户提供业务价值。