DevOps时代联合发起人张乐-某大型互联网金融项目百人团队持续交付转型实践

聂致远

2017/11/14 发布于 技术 分类

张乐,DevOps时代联合创始人,高效运维社区合伙人,国内首批DevOps Master,前百度资深敏捷教练、架构师。超过十四年敏捷转型、工程效能提升和大型项目管理实践经验,在一线互联网、全球最大IT公司和咨询公司积累了丰厚的知识体系和优秀案例,曾主导数百人团队实施DevOps转型,在保证质量的前提下发布频率提高数倍。在百度任职期间作为持续交付方向负责人,成功主导了多个战略级产品的敏捷转型和DevOps体系建设。在业界积极推动DevOps理念和技术,被评为 DevOpsDays大会、GOPS全球运维大会金牌讲师。

文字内容
2. 某大型互联网金融项目 百人团队持续交付转型实践 DevOpsDays 2017·上海站 张乐 高效运维社区 合伙人 前百度资深敏捷/DevOps专家
3. 自我介绍 张乐 • 高效运维社区合伙人、DevOps时代联合创始人 • 前百度资深敏捷教练、DevOps专家 • 国内首批 Certified DevOps Master • 全球TOP外企,国内一线互联网 • 百度云、百度金融等新技术产品敏捷转型主导者 • DevOpsDays 大会、GOPS全球运维大会金牌讲师
4. VUCA 新常态 “we didn’t do anything wrong, but somehow, we lost”
5. VUCA 新常态 • 不是简单因果关系 • 风险和问题复杂度 • 管理维度 技术维度 • 无法从局部看全貌 • 认知的模糊和局限 • 问题发现远离来源 • 软件需求的易变性 • 认知是不断深化的 • 产品知识不断积累 • 技术方案 产品路线 • 市场和用户的反馈 • 市场环境 竞争对手
6. IT 的技术革新
7. 某金融项目的背景信息 某互联网+业态下的典型产品 • 业务链条较长,交易涉及多系统间协作,整体复杂度较高 • 初步尝试了敏捷转型,按迭代方式运作,但改进效果有限 涉及团队:6+ 人员规模:300+ 相关子系统:50+ 在线 离线
8. 敏捷研发的转型 各个子系统团队按 Scrum 模型进行运作 严格阶段划分,每个阶段控制准入和准出 迭代开发,拥抱变化,快速反馈,聚焦价值
9. Business Capabilities Business Capabilities 敏捷研发的转型 组织结构调整为跨职能团队 职职职职 职 能能能能 能 团团团团 团 队队队队 队 ︵ ︵ ︵ ︵ …︵ 产设开测 运 品计发试 维 人人人人 人 员员员员 员 ︶︶︶︶ ︶ Dev IT value chain Ops 分工细化,专业化运作,各领域深耕 缺少整体目标感,工作交接和确认,出问题必须界定清楚 跨职能产品团队 跨职能产品团队 跨职能产品团队 … 跨职能产品团队 Dev IT value chain Ops 通过目标驱动,不同角色共享责任,团队自组织 端到端负责,减少交接损耗,降低问题解决成本
10. 实际的转型效果并不理想 在具备一定复杂度的环境中,局部优化很难产生显著成效 • 敏捷转型主要局限在开发测试,但未端到端的打通 • 受架构限制,缺失并行交付能力,集成点变为是全局阻塞点 N 图片来源:《Lean Enterprise》
11. 问题的根因分析 问题现象: • 整个版本周期较长,有时一个月才能发布大版本 • 线上常有质量问题,需消耗较多精力排查和修复 问题分析: • 各阶段周期时间分解 • 关注等待/阻塞/浪费 问题定位: 系统紧耦合,相互影响和阻塞 • 多个子系统无法做到并行交付 • 故障传播不可控,相互影响 • 一端出问题,整个版本阻塞 46% 21% 33% 开发(多团队并行) 联调 (集成) 测试(端到端) 上 线 12D 5D 8D 8H 各端未控制质量,集成时问题爆发 • 开发自测不足,缺陷蔓延到集成阶段 • 自动化能力缺失,大量依赖人工处理 • 团队间存在资源争抢,相互冲突严重 环境交付未归一化,发布效率低 • 环境多依赖复杂,线下线上不一致 • 环境准备时间长,维护成本高 • 串行发布上线,需要长时间停服
12. 项目整体改进思路 俜净㌈㋾凕  ⹿惖㢚㾶 㪗㩥 冥冨 ⓧ㠐丷䡆 ↅ↹䀢㼕冠 䀬庶ⓧ冈 ⫛䬡废㢞 揉剓 㡑㙏ㆇ撰  㗢凎㠚押
13. 系统性思维 图片来源:《DevOps Master Whitepaper: Success with Enterprise DevOps 》
14. 体系化实施框架 • • • • • • • • • • • • • • •
15. 最佳实践导入 发布频率 每100天发布一次 每10天发布一次 每天发布 每天发布10次 每天发布100次 分支模型 测试 架构 发布 基础设施 数据库 在分支上开发 合并到发布分支,然后发布 后再次创建分支 由单独的质量保证部门 负责功能测试自动化 主干开发 为发布创建分支 在主干开发 从主干发布 拉动提交 请求到发布分支 在部署流水线中组织快速、完备 的自动化单元测试和功能测试 由开发人员和测试人员共同维护自动化功能测试 所有东西 一起部署 每个产品/每种Web资源单独一个包 严格的SOA架构,向前和向后兼容 功能版本,版本火车 灰度发布、蓝绿部署、金丝雀发布 开发自己将变更部署到生产 异构,运维部门 统一管理 手动迁移 可以通过收版本控制管理的脚本 来准备类生产环境 标准化的PaaS或者IaaS、Caas 平台来交付 采用增量脚本变更数据库 并对回滚进行演练 设计中考虑应用对数据库的前向、后向兼 容性(采用扩展或契约) 图片参考:《Lean Enterprise》
16. DevOps 结构化方程 KEY WORDS 变革领导力 自动化测试/部署 松耦合架构/团队 持续交付 精益产品管理
17. 1. 架构的演进 Application Module A Module C Module B Module D 整体式服务架构 Application A Application C Component 1 Component 2 Component 3 Application B Application D 单体应用式服务架构 Service Service API Gateway Service Service Service 微服务架构
18. 1. 架构的演进 Service A Service B Service C Service D Service E Service F 注册中心 Service A Dubbo Client 2 获取服务地址 1 注册服务 Service D Dubbo Monitor Monitor 4 调用统计 Service B Dubbo Client Service C Dubbo Client 自有协议 Service E Dubbo 3 服务直连 Service F Dubbo Dubbo框架解决方案 • 网状结构,服务耦合度高 • 点对点服务调用模式,难于服务治理 • 自有协议,不利于服务标准化 • 不支持动态优化服务链路、负载均衡 Service Provider Service Provider Service Provider 调度器 Docker 1 服务注册 标准化服务 3 服务请求路由 服务网关 路由链路 建议 流控策略 路由&负 载策略 Service Consumer 2 发起服务调用 Service Consumer Service Consumer 5网关策略 动态优化 4 服务运行数据收集 6 容量预警 弹性扩容 服务治理平台 服务网关解决方案 • 集中式服务平台,易于服务治理 • 统一服务入口,支持服务标准化 • 支持容量预警,服务弹性扩容 • 支持动态路由、动态流控策略优化
19. 2. 组织的演进 变革推进小组 变革Sponsor 变革推进小组 变革实施团队 Business Capabilities Dev 研发工具链 研发工具链团队 跨职能产品团队 跨职能产品团队 跨职能产品团队 … 跨职能产品团队 IT value chain Ops 测试服务平台 测试平台团队 发布部署平台 运维平台团队 • Overall Goal • T-shaped • Co-located
20. 3. 分支策略,代码协作工作流 代码库从SVN迁移到Git,提升本地操作和分支管理效率 应用Git代码托管平台,简化操作并集成代码协作工作流 Release Branches Q 8.Release Test R 10.Release Master Branch Local Branches Q 6.Integration Test R 7.Branch Out A 5.Check-in Build R 9.Cherry-pick R 4.Merge To Master R 3.Code Review A 2.CR Build R 1.Change Request R 0.Local Build A Daily Build R By RD A Automated Job Q By QA
21. 4. 建设可靠可重复的交付流水线 通过交付流水线,将全局过程标准化、自动化、可视化 关键流程和节点管控,并行开发过程中的协同和管理
22. 4. 建设可靠可重复的交付流水线 - 多服务聚合 建设原则: • 自动执行 + 自助操作 • 遵从单一制品的原则 • 测试分级,质量内建 • 快速失败,及时修复 • 端到端,延伸到生产
23. 4. 建设可靠可重复的交付流水线 – 工具实现 单服务交付流水线 多服务聚合交付流水线
24. 5. 测试分级质量保障 建立分级测试体系,从多个层次和多个验证角度实现质量防护网 分级 测试模型 图片参考: ThoughtWorks 《精益敏捷软件开发精髓 》
25. 5. 测试服务平台建设 场景数据构造 通过接口自动构造中间态测试数据, 减少测试依赖,提升稳定性和效率 Mock平台 模拟同步、异步、多协议接口返回, 减少测试依赖,提升独立性和效率 问题定位平台 根据交易ID及各类信息,自助跨服务 追踪和定位问题,降低被动配合成本
26. 6. 应用交付归一化及基础设施建设 应用交付方式和过程归一化,并通过PaaS平台实现自助化和自动化 交付 流水线 提交 编译 单元测试 模块测试 镜像制作 制品库 线下环境部署 镜像转推 系统测试 (镜像) 镜像 管理平台 镜像配置 镜像制作 镜像标准化封装 镜像自动化构建 应用 镜像层 Service Service Service 基础 镜像层 Tomcat Jetty … Java … Nginx Agent Agent Remote API Docker Host Cluster Host Host OS 镜像层 Base OS Docker Registry 基于组件方式,用户可自助进行基础层镜像组合 多台HOST作为资源池动态构建镜像 线下环境部署 镜像仓库 镜像转推 PaaS 平台 环境配置 应用配置 服务编排与 调度 容器运行时 管理 服务与BNS 及BFE协同 应用管理 发布管理 监控管理 发布 上线过单 环境部署 配置下发
27. 6. 应用交付归一化及基础设施建设 - 镜像管理
28. 6. 应用交付归一化及基础设施建设 – 环境管理 环境相互隔离 环境按模块组合
29. 7. 部署解耦及灰度发布 服务升级做到向下兼容,采用灰度发布降低风险 后退,回滚 app_1-0-0-0.paas.baidu.com app.baidu.com 正式对外服务 前进,发布 app_3-0-0-0.paas.baidu.com 预发布,线下内网观察 Router (HTTP Proxy) app_1-0-0-0 app_1-0-0-0 instance01 instance02 app_2-0-0-0 app_2-0-0-0 instance01 instance02 • 多个版本,以多个app的形式并存,通过泛 域名区分 • 泛域名随时可以观察,实现了预发布 • 修改某个泛域名为正式域名时,实现了发布 • 同理,实现了回滚 app_3-0-0-0 app_3-0-0-0 app_3-0-0-0 instance01 instance02 instance03 实例个数,控制容量 app_1-0-0-0.paas.baidu.com app.baidu.com app.baidu.com app_1-0-0-0 app_1-0-0-0 instance01 instance02 • 将一个正式域名,同时指向多个app • 调整多个app的实例数比例,即是调整了流 量的比例 app_2-0-0-0 app_2-0-0-0 app_2-0-0-0 instance01 instance02 instance03 app_3-0-0-0 app_3-0-0-0 instance01 instance02 通过调整app实例的数量, 灰度流量的分配比例
30. 8. 数据度量及持续改进 • 重点是对原则的坚持 – 频繁集成 – 红灯修复 • 建立度量指标模型 – 结果指标 – 过程指标 • 数据驱动持续改进 1 实施情况总览、分团队总览 2 数据筛选和下钻,各团队数据 3 核心数据汇总,环比变化趋势 4 自动分析和异常报表推送邮件
31. DevOps 改进实施效果 发布方式 打包格式 迭代周期 发布频率 前置周期 改进之前 多系统整体串行 程序包 一个月 双周 数小时 改进之后 各系统独立并行 镜像 双周 按需(可每天多次) 数分钟
32. 项目整体改进思路 俜净㌈㋾凕  ⹿惖㢚㾶 㪗㩥 冥冨 ⓧ㠐丷䡆 ↅ↹䀢㼕冠 䀬庶ⓧ冈 ⫛䬡废㢞 揉剓 㡑㙏ㆇ撰  㗢凎㠚押
33. DevOps 道法术器 价值观,对目标 价值的定位 道 实现价值观的 战略、方法 法 战术、技术、 具体的手段 术 用工具提高效率 复杂问题简单化 器 VALUE 快速交付价值,灵活响应变化 WHY 全局打通敏捷开发 & 高效运维 HOW 系统应用指导原则、最佳实践 系 统 思 考 的 层 次 WHAT 端到端工具链相互联通和整合 解 决 问 题 的 层 次
34. Q&A
37. DevOps时代 DevOpsDays 2017·上海站 Thanks 高效运维社区