大规模DevOps云原生转型血泪史

大规模DevOps云原生转型血泪史 曾海剑 广东移动云原生总架构师 目01转型血泪史 contents 录02踩坑分析 03减负与规模化实践 PART01 转型血泪史 第三方开发模式背景 团队众多 水平参差 上百个不同的合作商的 开发团队 各团队开发人员水平参差不齐 分散在不同合作商办公环境 远程开发 开发团队 由于每年投资缩减，人员变动大，普遍技能水平低 人员分散变动频繁 阶段1：开源+放养（技术方案） 一套云原生环境：K8S+CephFS 全套DevOps工具：代码仓库：Gitlab 流水线：Jenkins 镜像仓库：Harbor制品仓库：Nexus 代码扫描：Sonarqube …… 阶段1：开源+放养（实施方式） 搭戏台 建平台选试点做培训 过程问题 投入大整合难没人用 没人用 阶段2：开源+保姆（技术方案） 三套云原生环境：测试环境（SIT） 预发环境（UAT） 生产环境（PROD）x2 三条流水线： develop：发布到SIT环境master：发布到UAT环境release：发布到PROD环境 阶段2：开源+保姆（实施方式） 当保姆 帮编写帮配置帮调试 过程问题 累瓶颈复制难 小规模 阶段3：商用+外援（技术方案） 愿景 自建自维 手工编写 商用的云原生技术底座 商用的全套DevOps工具 外部支持 自助配置 阶段3：商用+外援（实施方式） 找外援 买产品买培训买支持 过程问题 配置工作量大培训成本高严重依赖供应商 小规模 PART02 踩坑分析 问题分析：团队角度 常态 •团队没有DevOps和云原生技能 •开发/运维人员本来的工作量就很大 •理解好需求，编写好程序才是开发人员的本职工作 •6-7k薪酬的现实，做不出20-30k薪酬的效果 外援 •团队不会只能靠专家把团队教会 •团队不想只能靠专家下手干 •但不是每个企业都有能力承担引入或者培养专家的成本 源头 •开发人员是价值创造的源头 •开发人员最了解自己开发的应用应该如何编译、打包和部署 •DevOps平台首先应该为开发人员服务 GOPS全球运维大会2024·深圳站 问题分析：团队角度 转型难 负担 认知负担 工作负担 现有开源方案 优势 劣势 •灵活：很多功能都可以通过编程实现 •灵活：很多功能都需要通过编程实现 问题分析：技术角度 面向专家 问题分析：技术角度 现有商用方案 优势 劣势 开源封装 •配置：用界面配置代替编程 •封装：对开源工具做了整合与封装 面向专家 •支持：有供应商提供的专家团队支持 •配置工作量大 •培训成本高 •支持和定制严重依赖供应商 开源方案 商用方案 问题分析：总结 租户想要的 拎包入住自己动手带着施工队租房 PART03 减负与规模化实践 工具平台设计思路 学习k8s学习DevOps 编写/配置/调试工作量 认知减负工作减负 不用学 不用写 不用配 阶段4：自研+自助 Dory-Engine：开源的面向开发人员的远程开发环境 远程开发模式 •研发过程迁移 •无运维参与 •基于DORY部署 •基于容器调测 （serverless） •配额隔离 架构 演示 规模化应用成果 跨省市/跨部门外包开发/自主开发合作开发商26开发人员1400+ 业务系统120+代码仓库130+微服务种类800+ 环境种类包括：开发调试/预发/生产/异地容灾接管k8s集群16节点数800+ CPU架构跨X86/ARM64跨开源/国产k8s产品跨v1.18.x-v1.31.xk8s版本接管GPU算力集群3部署Pod3000+ 平台运营团队（自有人员）2平台教练团队（外包人员）3 降低云原生应用部署难度 以资源为单位定义部署（K8S）以应用为单位定义部署（自研） 云原生资源隔离难题 平台管理者 收权？ 放权？ GOPS全球运维大会2024·深圳站 解决云原生资源隔离难题 GOPS全球运维大会2024·深圳站 解决流水线构建隔离难题 脚本越权访问容器隔离 云原生普及的未来–简单 价值=产出–投入 SimplicityisthefutureofDevOps CloudNative 欢迎交流 欢迎来撩 https://gitee.com/dory-engine/dory-engine