云原生时代携程 DevOps 体系建设

1. 云原生时代携程 DevOps 体系建设携程：肖小龙施燕

2. 肖小龙施燕携程云原生研发专家携程资深云原生研发工程师主要关注领域：产研管理主要关注领域：软件配置管理云原生交付持续集成、持续交付资源利用率提升研发效能 K8S 组件研发和优化

3. 目录 Contents 01 产研管理 02 持续集成 03 持续交付 04 度量体系建设 05 总结与展望

4. 产研管理 PART 01

5. 背景 50+ BU 150+ 产品线 1000+ 研发团队 6000+ 研发人员

6. 存在的问题竖井效率问题需求分配不合理不同组织和职能之间相互没有统一视角查看资源分配情等待，需求无法顺畅流动况，无法合理安排需求产出和预期差需求优先级难以确定很多需求口头描述，不停的变需求来自不同的 BU、不同的团队化，导致产出和预期相差甚远和人，数量多，无法很好的确定优先级

7. 研发效率中台 iDev • 需求管理标准化 • 需求层次管理 • 需求流转闭环 • 研发过程管理标准化 • 多种敏捷模式 • 研发流转规则定制 • 研发资源分配 • 产研一体

8. 需求管理标准化 v 需求层次管理 • 需求类型 • 普通需求 • 技改 • BugFix • 其他 • 需求优先级 • P0 • P1 • P2 • 其他

9. 需求管理标准化 v 需求流转闭环

10. 研发过程管理标准化 v 多种敏捷模式 • 标准敏捷模式 • Lite 敏捷模式 • Less 大规模敏捷模式

11. 研发过程管理标准化 v 研发资源分配

12. 研发过程管理标准化 v 产研一体 • 产研过程 • 需求梳理 • 代码关联 • 交付关联 • 测试验收 • 安全评审 • 产研人员 • 产品经理 • UED • 开发 • QA

13. 小结竖井效率问题 √ 需求分配不合理 √ 需求流转闭环，打通部门、职能统一视角查看资源分配情况，之间壁垒，确保需求流通顺畅合理分配需求产出和预期差 √ 需求优先级难以确定 √ 产品、UED、开发、测试同需求管理标准化、层次化，一视角的需求看板界定好优先级逐步完成赋能产研过程，落地最佳实践，提高产研效率

14. 持续集成 PART 02

15. 背景 6000+ 研发人员 12000+ 应用 10+ 应用类型

16. 持续集成的价值 • 更早更快的发现软件潜在问题 • 持续交付可部署软件 • 减少重复劳动

17. 持续集成架构 1.0 v 基于 Jenkins 的持续集成架构 • 构建数据 • 支持 30+ 构建类型 • 日构建数 20000+ • 携程 5 年业务增长需求 • 存在的问题 • Jenkins Master 运维成本高 • 微服务多，运维困难 • 持续集成反馈链路过长 • 代码质量数据集成困难

18. 新架构选型 - GitlabCI • 开源 • Gitlab 无缝集成 • 扩展性强 • 隔离性好 • 具备二次研发能力 https://docs.gitlab.com/ee/ci/

19. 原生 GitlabCI 存在的问题学习成本高组件难以复用需要学习基本语法，手动组件复用需要 copy yml 片段编写 yml 文件极易出错到 .gitlab-ci.yml 文件质量门禁数据集成困难流水线控制力度粗项目对应的质量门禁数据缺用户无法灵活编排流水线，少集成入口定制自己的构建任务

20. 如何破局流水线组件质量门禁标准化抽象化数据捆绑打造一个流水线编排系统

21. 流水线编排系统 Sailor v 主体功能概览

22. 流水线编排系统 Sailor v 项目流水线编排 • 标准流水线 • 基于流水线模版生成 • 编排流水线 • 选择任务模板灵活编排

23. 持续集成架构 2.0 v 基于 GitlabCI 的持续集成架构 • 构建数据 • 日构建 80000+ • 最高并发 300 • 自定义 Runner 160+ • 构建特性 • Runner 无状态，扩展性强 • 构建资源池隔离 • 混部 • 高可用 • 更便捷、更快的持续集成反馈 • 高效集成代码质量数据

24. 流水线最佳实践 v Java 流水线最佳实践 • Maven 生命周期拆解 • 镜像交付速度 4 倍提升 • 测试左移 • 安全左移

25. 研发流程标准化

26. 小结持续集成架构升级流水线最佳实践架构完成 1.0 -> 2.0 升级，整有效落地 5 种标准语言流水体的构建能力更强、更灵活线最佳实践流水线编排系统集成数据迁移精细化控制流水线，灵活复用 1.0 到 2.0 构建数据迁移，14000+ 构建组件，有效集成质量门禁流水线，90000+ 构建任务数据更早、更快的发现软件潜在问题，增强项目的可见性

27. 持续交付 PART 03

28. 背景持续集成 + 持续部署 = 持续交付发布系统

29. 发布模式滚动发布蓝绿发布

30. 发布过程 • Group：一组暴露同一服务的机器 • 拉入拉出：Group 中某个实例是否接受流量请求 • 堡垒：Group 中第一台被发布测试的机器 • 点火：应用初始化、预热、加载数据 • 金丝雀：Group 中第一台被发布验证的机器 • 刹车：当发布失败实例数量大于一定比例时停止发布 • 分批：同一 Group 分成多个批次进行滚动部署 • 回滚：服务回滚到某个可用的版本状态 Group 发布过程

31. 发布环境管理 FAT 为业务应用提供独立的功能测试环境 FWS 为业务应用独立的功能测试提供的公共基础服务 LPT 业务应用的性能测试环境 UAT 业务应用验收测试环境 PRO 业务应用用来承载生产流量的环境

32. 发布系统 1.0 v PaaS1.0 经典部署模式 • 存在的问题： • Tars 为控制中心的模式，发布链路长，性能差 • 数据同步链路复杂，稳定性差 • 虚机思维：先分资源（固定 IP）再发布，限制扩缩容能力 • 基于 Salt 命令式 API 而非 K8S 的声明式 API，自愈能力差

33. 新架构选型 - OpenKruise • 增强版本的 Workloads • 应用的旁路管理 • 高可用性防护 • 高级的应用运维能力 https://openkruise.io/zh/docs

34. 原生 OpenKruise 存在的问题缺少 PaaS 侧管理特定发布需求无法满足 Openkruise 只是一个标携程有自己的特定发布需求，准的扩展组件，无法暴露发布过程中涉及到堡垒、刹车、给用户直接使用批次、流量相关发布逻辑

35. 如何破局发布自定义中间件平台化发布引擎引擎打造一个契合自身的云原生发布系统

36. 发布系统 2.0 v PaaS 2.0 云原生部署模式 • 核心 • K8S 作为控制中心 • 改进 • 命令式 -> 声明式 • 发布逻辑和中间件下沉 K8S • CMS 数据中心 -> K8S 为元数据中心 • 不再提前单独分配 IP，Neutron -> Cilium

37. 发布系统 2.0 v 云原生发布系统架构 • 优势： • K8S 作为控制中心，扩缩容链路短，性能强 • 没有复杂的数据同步链路，各 Operator 自治，发布更加稳定 • Neutron -> Cilium，去除固定 IP 依赖，灵活扩缩容 • K8S 声明式 API，自愈能力强

38. 极致的交互体验 • 镜像选择 • 点火配置 • 集群配置 • 批次配置

39. 极致的交互体验

40. 小结发布系统 1.0->2.0 升级助力其他云原生技术完成传统发布模式到云原生发为 HPA/Serverless/Service 布模式升级 Mesh 等云原生技术提供底座发布体验更好、适配性更强支持打造云原生发布系统，更快、更安全的交付软件

41. 度量体系建设 PART 04

42. 背景 v 研发效能度量的价值 • 研发数据更加直观 • 发现研发痛点，改进研发流程 • 数据驱动，提升研发效率

43. 度量指标 v 研发效能度量指标

44. 效能度量平台 v 主体功能概览交付效率数据分析自定义报表

45. 效能度量平台 v 交付效率

46. 效能度量平台 v 数据分析

47. 效能度量平台 v 自定义报表

48. 小结流动效率质量保障交付周期、开发周期缺陷分布、缺陷库存发布频率、发布前置时间单位时间线上缺陷、线上问题时长资源效率其他指标单位时间内交付需求数通过度量分析发现研发痛点、解决研发痛点，提升研发效率

49. 总结与展望 PART 05

50. 总结与展望持续集成产研管理 • 组件孵化 • 进一步打通产品和研发 • 集成体验及效率提升壁垒，提高产研效率 • Idea 本地插件开发持续交付效能度量 • 交付体验、交付效率、 • 集成更全面的效能数据 • 效能数据分析交付安全 • Serverless 以产研管理、持续集成、持续交付为地基，构建效能度量平台，完善 DevOps 体系建设，持续提升研发效能

51. 总结与展望 THANKS