1. 引言

随着数字化进程的不断推进，新兴数字技术如云计算、大数据、区块链、AI、物联网、边缘计算和算力网络等不断涌现，IT基础设施也在不断演进，以适应技术与业务的发展。数字化转型的推动下，基础设施的重要性越来越受到关注，应用和数据量仍在不断增长，云和工作负载也变得越来越复杂和多样化，安全问题也变得越来越紧迫。随着这些爆炸性技术的涌现和基础设施的不断演进，软件研发平台也面临着前所未有的挑战，软件研发人员的认知成本也在急剧上升。

从2009年Dev Ops[1]运动的兴起，不断推动软件研发大规模的左移，开发人员负责越来越多的应用程序生命周期和交付工作流程。与此同时，更复杂的微服务架构和技术，如Kubernetes[2]、Git Ops[3]和基础架构即代码也成为了行业标准。这些趋势导致现代云原生设置比几年前复杂得多。即使是一项简单的任务，例如在重新部署应用程序之前更改环境变量，也需要开发人员对其企业工具链有端到端的了解。这增加了研发人员认知负荷，造成低效率和太多的影子行动。

2. 文献综述

平台工程是Dev Ops和基础架构中最热门的趋势之一，Gartner最近将其添加到软件工程的技术成熟度曲线。目前这一趋势发展可分为三种类型：一类亚马逊、Google、Netflix、蚂蚁金服等云平台型公司依靠自身云基础设施与业务量身定制的内部研发平台(IDP)；一类Git Hub、Gitee、Jira专注于软件研发流程，擅长软件管理与工具开发，围绕自身工具发展集成公有云与标准云管工具等基础设施打造流程工具链；再一类为云原生开源社区如Kubevela，通过定义标准的基础设施代码、流程工具代码及集成开源工具完成平台打造；以上类型发展均处于平台工程理念发展的早期阶段。国内大多数软件供应商还介于Iaa S、Paa S、Saa S、Dev Ops平台发展期间并逐步在向平台工程理念演进。

平台工程能更大程度地发挥软件工程的优势，研发人员应对软件开发、交付、运行有更高要求和期待，绝不仅仅局限于Dev Ops、工具链、流水线等方面。相反地，我们应该从基础架构到中间件、微服务、IDE等各个层次，提供更大弹性和更好的用户体验。从平台工程的角度，我们应该重点关注自助式服务API、内部开发者平台和开发者体验。

现有研运服务相关研究主要针对Dev Ops安全展开，Mac Donald等人提出了Dev Ops相关的安全问题和缺失措施，病情提出了一种与Dev Ops开发模式相匹配的安全保障技术Dev Sec Ops[4]，保障产品研发过程的质量。围绕数字化升级大趋势，电信运营商也在积极通过各种新技术，提升IT研发和运维效率，针对传统瀑布型研发模型存在的协调难度大和研发效率低的问题，何健[5]等人提出了基于Dev Ops的研发运维体系变革方案。

针对现有研究存在的不足，本文重点围绕电信运营商在软件研发全流程中的管理问题，通过引入组装式PBC技术和混沌工程技术，提高了基础研发能力的复用度，提升了研发效率，同时也提升了系统稳定性。

3. 研运服务平台体系结构

3.1. 功能架构

研运服务平台主要以应用开发支撑为导向、研发质效提升为目标、网管价值经营为抓手，规划“统一入口 + 十大中心”。提供应用研发运营访问一体化入口；适配多云异构云原生底座、支撑Dev Ops研运一体化、服务网管能力管控运营，提升应用开发效益、赋能业务快速创新。如图1所示，平台包括资源中心、服务中心、能力中心、应用中心、配置中心、研发中心、运维中心、质效中心、人才中心和流程中心十大模块。

Figure 1.Functional architecture diagram of the Biz Dev Ops platform

图1.研运服务平台功能架构图

3.2. 角色定义

平台定义四类11个角色，驱动多云异构云资源管理、网管服务登记注册、网管能力管控运营、统一权限管控、研运一体化管理等各项目工作开展。面向产品营销和经营决策，设置了产品销售者，主要是一线政企客户经理，负责销售OSS产品、有后端专家支撑诉求；此外，还设置了管理决策者，便于全面掌控网管资源、能力、应用的整体情况，结合网管研发质量、效益、过程等因素，对研发工作做决策指导。

面向平台配置，设置管理员、资源管理员和研发管理员三大角色。管理员负责平台涉及的部门、员工、厂家、角色等基础信息初始化维护，租户创建配置、账号创建配置、安全策略配置。资源管理员负责平台容器资源的统筹规划，计算、存储、网络资源面向不同场景的初始化配置与维护。研发管理员负责平台研发流水线的统筹规划，代码仓库、代码检测、制品库、流水线、镜像仓库面向不同应用场景的初始化配置与维护。

面向服务供给，设置服务提供者和服务管理员两大角色。服务提供者通过标准化信息导入模板和标准化服务注册规范，实现服务开发和服务注册接入。服务管理员对服务的来源(来源系统、提供者)和去向(订阅情况、调用量)进行管控审批，负责服务日常的健康度监控和质效评估分析。

面向产品开发使用，设置能力开发者、能力管理员、应用开发者、应用管理员和应用使用者五大角色。能力开发者从业务的角度对客户需求进行初步分析，并与服务进行匹配，负责能力的开发、测试、交付和调优。能力管理员统筹规划能力全景，明确能力建设里程碑，制定能力上下架规范与考核要求，对能力上架审核，负责能力质效评估运营分析。应用开发者依托平台提供的能力、资源、开发环境集流水线，遵循相关研发管理规范，围绕创新业务场景，快速创建应用。应用管理员负责需求管理审批、研发流水线调用审批、应用上架审批等研发过程管控，负责研运一体化运营管理。应用使用者对已发布的应用进行订阅和使用，可以根据个人诉求提需求。

3.3. 平台业务流程

如图2所示，研运服务平台统一对接运营商内部业务系统，整合账号、安全、需求、工单等基础系统能力，面向需求方提供产品商城全面展示底层资源、能力和应用信息，面向内部研发专家提供研发工作台，个性化分配和全流程管理产品研发任务，面向平台运维团队提供统一运维驾驶舱，面向企业管理层提供管理决策中心，实时分析研发质效，企业内部人员能力等信息。

Figure 2.Functional architecture diagram of the Biz Dev Ops platform

图2.研运服务平台业务流程图

4. 研运服务平台关键技术

4.1. 组装式应用PBC

现代化应用是组装式的，各模块可自治、可编排和可发现。可以灵活的构建差异化能力，快速响应客户需求，通过集成化应用数据平台，联接企业应用、数据，整合跨APP数据、开放API封装好业务能力(PBC)，通过低代码提供的组装体验，灵活编排以实现新的业务能力。

组装式应用PBC具备可自治，可编排和可发现三大优势。可自治：应用具有完整的服务能力，能够单独为用户服务。可编排：应用具有非常清晰、易用的接口，能够与其他PBC组合，从而创造新的能力可发现：应用具有能够让开发者发现、使用的服务能力，将服务能力上传到公开目录或服务市场，帮助开发者快速封装。基于组装式应用PBC可以实现服务器无感知，部署方式便捷和自动弹性扩展。服务器无感知：通过打包的服务能力进行快速组装，上线新功能，相对于微服务架构更加灵活。部署方式便捷：Server Less化资源层，用户无需关注底层资源部署。自动弹性扩展：做到一切皆服务，无需运维，做到毫秒级极致弹性，小时级的业务构建[6]。

4.2. 混沌工程技术

围绕电信运营商网络管理相关软件平台研发和运维，如何保障系统稳健性存在较大。微服务架构造成的运维复杂度高，为保证高可用，势必要做故障演练，而混沌工程平台是必要的支撑手段。混沌工程是提升复杂系统稳定性的赋能活动，通过故障注入实验增加各个角度加强协作、提升系统稳定性的紧迫感，根据实验观测数据，分析系统运行和失效模式，以了解复杂系统，改进系统稳定性设计和可观测机制，提升系统韧性及故障响应速度。

本系统基于Chaos Mesh[7]技术，通过Kubernetes在测试环境中搭建混沌实验，通过模拟网络故障(延迟、丢包等)、文件系统故障和Pod故障等问题来测试系统的恢复能力，每次混沌实验后，通过查看日志来查看测试结果。同时，结合了CI\CD工具的特性，完成了混沌实验的自动化执行，提升了测试效率。

5. 总结

本文主要针对企业研发和企业内部应用云化改造工作中的痛点问题。本文提出了基于Biz Dev Ops的研运服务平台，通过组装式应用PBC的方式，实现了服务自发现和自编排，进一步利用混沌工程技术自动引入故障因素，测试并提升系统鲁棒性。本文所设计的研运服务平台将有效帮助企业用户深化产品研发转型工作，通过IT支撑手段升级与工作管理抓手强化，面向合作伙伴与自研团队引导意识转变、帮扶行动落实，加速网络运维数智化实现，致力于打造运营商研发转型的最佳实践。

基金项目

泰山产业领军人才项目(tscx202312006)；山东省博士后创新项目(SDCX-ZG-202400307)。

参考文献