韩洪雷DevOps工具平台的“诗和远方”

韩洪雷高效运维社区 曾主导并参与过多个效能平台的建设，如项目管理平台、度量平台、流水线平台等，对持续集成，持续交付，研发效能度量，BizDevOps等研发效能提升方面有一定的落地实战经验，现从事DevOps咨询工作，曾服务过多家大型金融机构。 D e v O p s工 具 平 台 的 发 展 目录 工 具 平 台 的 场 景 化 服 务 能 力 平 台 工 程 的 定 义 DevOps工具平台的发展 DevOps工具平台的发展 ①解决个人问题 ④解决组织问题 ③解决团队问题 ②解决项目问题 满足管理诉求 满足个性诉求 满足既有诉求 满足新的诉求 专职团队，多技术栈，工程特性，流程规范，主动（次），被动（主） 规模的专职团队，强调流程规范，封装，易用性，管理要求，主动 管理诉求（少量），开源工具链，被动 单点工具，开源工具，脚本，被动 管理诉求 管理要求 G O P S全 球 运 维 大 会 暨X O p s技 术 创 新 峰 会2 0 2 4·北 京 站 DevOps工具平台发展到一定阶段出现的绩效导向 过度关注管理诉求，从而忽略了用户体验 绩效导向：推广率&功能数 DevOps工具平台团队经常会出现的一些绩效导向： •推广率提升X%•上线X个功能 解决X个Bug 可能会出现的一些问题 流程规范建设层面 平台推广层面 平台易用性层面 平台运营推广成本较高•依靠专人贴身服务指导，耗时耗力，本末倒置 缺少流程规范对工具的约束和指引 缺少产品视角的调优和规划 •兼容了各种各样的场景•功能多而杂，违背了奥卡姆剃刀原则 •用户的操作入口多•操作事件的前后逻辑性差 服务场景提炼 规范工具融合 用户自服务 流程规范制定 通过将流程规范的约束嵌入到工具平台内，减少个性化服务场景的支持，实现规模统一化，步骤一致化，使用简单化。 基于研发过程的主要活动，识别交付过程中的核心服务场景，通过场景对单点能力进行识别聚合，将原有的单点自动化能力聚合为场景化的自动化服务能力，使其具备理想的平台工程化能力。 基于高度自动化的场景化服务能力，释放团队运营资源，降低运营成本，同时能够提升用户的体验，真正通过场景化的服务能力实现用户自服务，以及未来可能的工具平台“零服务”。 制定组织级的流程规范，规范应尽量覆盖交付生命周期的各个环节，如依赖包，环境，数据库变更等，至少应覆盖和工程领域能力相关的流程规范，从而为工具的高度自动化奠定基础能力。 一个值得思考的指标 用户停留时长（User Session Duration） 用户停留时长是指用户在一次会话中从进入平台到离开平台所花费的总时间。 这一指标可以反映用户在平台上的参与度和体验质量。 可能的结论 停留时长较长可能意味着用户对平台内容或功能的兴趣较高。 但也不排除用户是在你的平台里迷了路。。。。 可能的解决方向：通过平台工程实践落地工具平台的场景化服务能力 到2026年，80%的大型软件工程组织将建立平台工程团队，将提供可重用的服务，组件和工具来支持应用的交付，平台工程将更进一步有效解决Dev和Ops之间的协作问题。建立平台工程标准，指导国内企业平台团队工作与平台功能建设意义重大，帮助企业审视DevOps平台工程能力建设现状，优化平台工程能力框架，提供平台工程能力体系建设指导及参考，进而实现企业高质量发展，中国信通院牵头发起《研发运营一体化（DevOps）能力成熟度模型第13部分：平台工程能力要求》标准编制工作，这是首个针对DevOps平台工程能力成熟度的标准。 场景化 平台工程 平台域 工具平台 •面向一体化平台的场景化服务能力与平台团队管理能力，如：价值流场景、需求工程场景、研发工程场景、测试工程场景、运维工程场景、安全工程场景等•验证企业一体化平台场景符合度 单领域 •面向工具平台，如：项目管理平台、持续交付平台、测试管理平台、技术运营平台等•验证企业工具平台功能符合度•平台包括多个工具模块 工具模块 •面向工具模块，如：工作项管理、流水线、自动化接口测试等•验证企业工具单点功能符合度 DevOps系统和工具标准规定了研发运营一体化（DevOps）过程中所涉及的系统和工具的能力技术要求，适用于在IT软件研发交付运营的使用方实施相关系统、工具和服务建设时进行评价和指导，将端到端软件交付生命周期全流程用工具链进行连接，包括：项目与开发管理、应用设计与开发、持续交付、测试管理、自动化测试、移动应用测试、技术运营、安全及风险管理。 DevOps工具平台发展经历的几个主要阶段 特点：半自研+封装工具（开源/商业）-平台化•统一界面（入口）+固化实践（Portal化）•统一度量 A工具化建设阶段：在各个阶段搭建相对独立的技术工具平台，聚焦于工具化以及通过工具提升自动化水平。 特点：独立工具（开源/商业）-工具化 工具平台的场景化服务能力 基础能力：打造工具平台的基础服务能力 •流水线的编排和嵌套，可以应对众多复杂的业务场景，实现流水线的灵活编排和调度 进阶能力：迈向工具平台的场景化服务能力 单点能力的不断提升并外延，与其他单点能力结合，形成场景，场景来源于企业既定的业务流程，实现工具的连锁反应 解决场景化服务能力的关键：构建以应用为中心的交付模式 以应用为中心串联各服务 分支模型 驱动代码分支和流水线的自动创建及关联 环境模型 驱动运行环境的自动生成驱动镜像的基础环境 技术栈类型 驱动流水线内部的结构编排，参数等 应用名称仓库名称分支名称流水线名称制品名称制品路径 开发人员在接收需求后，一系列的开发活动，在基于应用画像后全部实现自动化 现在 未来 •提交代码到开发分支•开发自测•创建MR•等待结果•提测 •创建代码仓库•创建开发分支•创建开发分支流水线•提交代码到开发分支•开发自测•创建集成分支•创建集成分支流水线•创建MR•创建MR预合并分支•创建MR预合并分支流水线•提测•配置应用参数•应用环境申请 一个典型的ChatOps 工具平台模式的转变：自服务能力的提升 平台工程社区给出的概念 可能的平台工程 •平台工程无所谓狭义，广义•纠结概念不重要，关注思想很重要•平台工程的内涵不是反映我们的工具平台能力有多强大 Ø平台工程是希望我们能够建立一套高度标准化的流程规范，并把这套流程和规范嵌入到工具平台内，规范和功能的融合能够让用户的学习和使用成本最小化。 Ø模型能力会在平台工程领域内得到广泛的应用 平台工程标准能力要求示例 •当应用创建时，平台应支持应用定义描述、检索查看，满足开发、测试、运维等各个场景的需要，包括但不限于：应用唯一标识（各场景均使用此唯一标识）、应用的状态、应用的负责人、应用的归属、应用的重要等级等•当应用创建时，平台应支持生成代码框架的功能。可以选择应用类型，然后自动生成相应代码框架，提供基本的项目结构和文件，包括源代码、配置文件等•当应用创建时，平台应支持自动创建配套的各种流水线，如：根据分支策略及应用级别•当应用创建时，平台应支持创建配套环境资源等•当管理应用时，平台应支持组织级的应用管理流程与规范，如：应用创建、应用下线等的审批与通知等流程•当管理应用时，平台应支持以应用为中心的权限模型，如：根据应用的各个角色批量赋权相关系统的权限•当应用下线时，平台应支持应用下线前自动化校验，如：应用调用关系已清理•当应用下线时，平台应支持对应用相关资产保留，如：数据备份归档•当应用下线时，平台应支持应用相关资源或权限自动化回收与通知，如：代码库、测试资源、生产环境、域名等•当启动特性开发时，平台应支持自动基于工作项创建分支并建立关联，并修改工作项状态•当开发特性时，平台应支持持续的质量反馈，包括提交代码自动触发构建、静态代码分析等•当提交特性时，平台应支持代码质量门禁管理，包括代码构建、单元测试、代码静态分析、代码评审等，确保特性达到一定的质量要求•当提交特性时，平台应支持自动化测试且提供可配置的质量门禁，包括接口测试、UI测试等，确保特性达到一定的质量要求•当提交特性时，平台应支持当特性达到质量要求时，将分支代码合并到集成发布分支•当代码评审时，平台应支持对比两个版本之间的差异和评论•当代码评审时，平台应支持查看两个版本的上下文、代码调用情况等•当代码评审时，平台应支持代码评审辅助能力，如：评审时可查看自动化扫描结果等•当回滚特性时，平台应支持针对一个特性的完整的、便捷的回滚•在特性开发、测试、发布过程中，平台应支持看板墙，识别特性进度和阻碍•在特性开发、测试、发布过程中，平台应自动改变特性状态•当集成、提交测试或发布时，自动计算该版本的变更范围（包括特性和修复的bug）•在集成、测试与发布过程中，平台应自动记录应用的制品版本及其相关属性，如：制品级别，代码版本，流水线id，各种测试结果，并支持方便的查询和获取•当代码集成时，平台应自动执行集成流水线，流水线应包括单元测试、代码静态分析、自动化测试等•当代码集成时，平台应支持设置质量门禁，如单元测试覆盖率/成功率、静态代码问题数、自动化测试通过率等，确保集成达到一定的质量测试准入要求•当代码集成时，平台应支持安全合规测试，以达到安全合规要求，如开源合规检查、软件成分分析、自动化安全测试等•当测试时，平台应保证测试环境中各应用版本的正确性，各应用包括本次变更涉及的应用及其依赖应用•当准备发布时，平台应支持根据需求自动创建发布审批流程并自动收集发布审批相关信息，提供可视化的方式展示审批流程的状态和进度•当执行测试和发布时，平台应支持选择工作项形成版本进行测试和发布 价值流场景 高效运维社区DevOps时代 感谢大家观看