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

曾海剑 广东移动云原生总架构师 01转 型 血 泪 史 02踩 坑 分 析 03减 负 与 规 模 化 实 践 第三方开发模式背景 阶段1：开源+放养（技术方案） l一套云原生环境： K8S+CephFS l全套DevOps工具： 代码仓库：Gitlab流水线：Jenkins镜像仓库：Harbor制品仓库：Nexus代码扫描：Sonarqube…… 阶段1：开源+放养（实施方式） 阶段2：开源+保姆（技术方案） l三套云原生环境： 测试环境（SIT）预发环境（UAT）生产环境（PROD）x2 l三条流水线： develop：发布到SIT环境master：发布到UAT环境release：发布到PROD环境 阶段2：开源+保姆（实施方式） 阶段3：商用+外援（技术方案） 愿景 l商用的云原生技术底座 l商用的全套DevOps工具 阶段3：商用+外援（实施方式） PART 02 踩坑分析 问题分析：团队角度 常态 外援 源头 •开发人员是价值创造的源头•开发人员最了解自己开发的应用应该如何编译、打包和部署•DevOps平台首先应该为开发人员服务 •团队没有DevOps和云原生技能•开发/运维人员本来的工作量就很大•理解好需求，编写好程序才是开发人员的本职工作•6-7k薪酬的现实，做不出20-30k薪酬的效果 •团队不会只能靠专家把团队教会•团队不想只能靠专家下手干•但不是每个企业都有能力承担引入或者培养专家的成本 问题分析：团队角度 问题分析：技术角度 现有开源方案 •灵活：很多功能都可以通过编程实现 •灵活：很多功能都需要通过编程实现 面向专家 问题分析：技术角度 现有商用方案 优势 劣势 •配置：用界面配置代替编程•封装：对开源工具做了整合与封装•支持：有供应商提供的专家团队支持 •配置工作量大•培训成本高•支持和定制严重依赖供应商 面向专家 问题分析：总结 PART 03 减负与规模化实践 工具平台设计思路 阶段4：自研+自助 远程开发模式 •研发过程迁移•无运维参与•基于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 降低云原生应用部署难度 云原生资源隔离难题 解决云原生资源隔离难题 解决流水线构建隔离难题 云原生普及的未来–简单 价值=产出–投入 Simplicityis the futureofDevOpsCloudNative 欢迎交流