在 2018 第二届研发效能嘉年华上, 阿里巴巴云效技术专家崔力强带来了如何做到高效软件交付的精彩演讲, 首先介绍了阿里巴巴在近几年在交付平台上的技术经验, 以及目前云上工具平台交易的趋势, 其次分享了阿里巴巴内部交付平台如何帮助我们统一步调, 并行工作, 最后详细讲述了 Dev 无感 Ops 可以解决 DevOps 遇到的一些问题.
数十款阿里云产品限时折扣中, 赶快点击这里, 领券开始云上实践吧!
视频观看请点这
PPT 下载请点这
以下为精彩视频内容整理:
阻碍开发者前进的问题
对于一个普通的工程师而言, 第一要务是完成需求交付, 我们的最终诉求是保障编码, 测试, 部署的高效. 但实际发现我们在交付的过程中并不顺畅, 研发流程的混乱经常出现代码错合, 漏和, 丢代码的现象; 质量化下降最主要是代码有 bug, 线上环境交付不稳定, 会有严重问题出现, 测试环境不稳定指的是在做集成测试时需有一套环境, 若环境不稳定, 开发测试工作会被 block; 团队之间沟通不畅, 开发和开发之间, 开发和测试之间, 没有统一规则或流程约定; 一堆开源工具攒出来的开发工具链, 不但提高了学习成本, 还导致过程数据无法统一存储. 几年前, 几乎都使用开源工具模式做持续交付, 后续发现存在许多问题, 于是开始做自建平台过程.
上图为知名公司的一份统计数据, 统计持续交付是否能帮助我们提升研发效率, 分别是瀑布模式, 敏捷模式和持续交付模式, 可以看出在持续交付模式下, 开发在设计, 测试, 部署上的时间比重大大减少, 在真正做开发上的时间达到了 80%. 也即是说我们更专注, 更高效的在进行开发, 从 Waterfall 到 Agile 的模式在研发阶段效率高, 主要是因为有更少的时间做设计, coding, 而 coding 时产生核心价值的一个环节; 从 2-3 饼图开发时间更长, 是因为我们把交付时间压缩.
如何做到持续交付有以下五点:
1. 需求的小批量流转, 通过拆分让价值可以快速的交付, 减少集成成本, 一般单个需求我们不会超过 1 周.
2. 自动化一切, 不单是测试和部署, 运维也需要自动化.
3. 内建质量, 尽早的测试可以显著降低测试成本, 保障交付流水线通畅, 增强环境稳定性.
4. 每个人都为交付过程负责, 不单单编码完成交给测试就 ok 了, 要负责代码上线, 并且各项功能数据都正常才算完成.
5. 研发过程数据, 用户反馈数据, 对我们有非常大的价值, 可以看到目前还有哪些坑阻碍着我们前进.
团队不同阶段面临的问题
最初我们团队只有 1-7 人时, 是在最敏捷的状态, 类似 Jeff Bezos 所说的 two pizza team. 按照目前微服务化的规模, 应该有 2-3 个应用. 这样的团队首先应该具备基本的 CI 能力和质量保障, 确保自己的代码在一定质量下持续迭代. 至于发布, 运维并不一定是马上需要面对的问题, 一些纸面上的流程和脚本, 足够应付一阵子.
当团队成长到 7-20 人时, 我们应该有了一个比较大的产品, 有复杂的架构和持续成长的业务. 10 多个应用之间互相影响, 互相阻塞会导致我们线下开发和线上 SLA 面临挑战. 此时一个统一的研发流程可以帮助我们规范开发行为, 再加上统一的质量标准, 不会让我们集成环境和线上环境面临较大风险. 随着应用增多, 我们也需要一些契约测试来确保服务兼容性.
当团队成长到 20-100 人时, 已经是一个相当大的规模, 我们掌握着一个企业核心的产品, 业务压力和稳定性压力像两个小人不断 PK. 如何在质量和效率上达到最佳平衡, 是我们要考虑的核心问题. 应用规模达到了几十个, 已经不是简单研发自动化能解决的了, 此时需要一个统一的研发平台, 帮助解决从 CI 到 CD 的全链路问题, 甚至包含全自动化的运维工具. 产品, 开发, 测试, 运维等角色可以在一个平台上高效协作. 在 2017 年, 已经有 83% 的企业开始使用云计算来解决企业基础设施问题和软件交付问题. 相比 2016 年出现爆发式增长, 不难理解利用现成的经过验证的可靠方案, 可以大大缩短企业达成高效率目标的路径. 帮助企业在市场竞争中获得先发优势.
统一步调, 并行工作
阿里巴巴内部端到端的研发平台包括项目协作, 持续交付, 应用运维, 测试度量以下几方面. 用云效首先可以获得研发模式的标准化, 我们将其命名为 AoneFlow, 这是目前应用最广最适合阿里巴巴的分支管理模式, 不但具有高度自由, 快速迭代的特性, 还可以与 CD 流水线结合, 让整个公司具有统一的软件交付规范.
上图为研发模式标准化 - AoneFlow, 将分支管理模式落地到产品层面, 开发只要通过平台新建特性分支, checkout push 代码, 后续合并上线全过程全部由平台接管, 不但可以让开发者协作变的非常简单, 高效, 永不出错, 而且在研发流程中可以加入自由配置的预设规则, 比如什么时候合并代码, 需要达到什么样的标准, codereview 安全是否通过, 发布分支怎么处理, 等等像乐高积木一般定义自己的研发流程.
将繁琐的易出错的事情留给平台, 实现研发模式全自动化. 真正的做到了研发过程全上平台, 所有数据可追踪, 并且彻底杜绝了漏发, 错合, 管理混乱的情况. 让开发专心价值交付, 是云效首先要解决的问题.
持续交付核心是快速交付价值, 给与开发最大自由度, 负责开发和运维全部过程. 在监控, 故障防控工具, 功能开关的配合下, 可以在保障用户体验和快速交付价值之间找到平衡点.
Dev 无感 Ops
Ops 自身复杂由繁杂重复性的工作, Dev 可以很轻易做 Ops, 是 Dev 感觉不到 Ops 的存在, Ops 真正出现问题时, 平台会通知 Dev 处理问题, 最后帮助团队做度量. 首先介绍阿里巴巴内部是以应用为中心 DevOps 理念使用来应用串联整个 DevOps 工具链, 开发定义应用, 同时定义运维, 开发为应用全生命周期负责, 系统自动完成应用运维配置.
因此我们一直在推动标准化, 智能化, 无感的 Ops 体系建设. 目前在研发端我们的三个实践第一个是无人值守发布, 众做周知绝大部分的故障来自于变更, 变更的绝大部分又来自于发布, 如何保障每次发布都是对用户无影响的, 如何用系统代替人来关注庞杂繁琐的运维指标. 去年我们应用运维产品推出了无人值守发布功能, 它使用人工智能的方法, 计算发布过程中监控指标, 日志数据, 用户数据等等多重维度的变化, 预判可能出现的风险, 警告用户或者触发回滚, 保障发布过程无人参与. 最终避免了 90% 的发布故障. 第二个是应用健康检查, 同样我们用大数据, 人工智能的办法, 获取多重运维数据, 来帮助开发同学发现目前应用存在的风险, 进行一键修复, 有点类似大家电脑里的 360 管家. 不需要有多少经验, 人人都可以成为运维专家. 最后是应用自愈, 我们将运维工具和经验沉淀到了这个产品, 对一些场景和问题进行自动修复和调整, 达到无人参与的目的. 这就是我们无感 Ops 的目标.
截图来自阿里云云效研发的某过程
上图为全云端构建, 加速研发过程, 云效完全自研的全云化构建调度系统, 已经可以支持所有语言构建, 拥有经过阿里云安全团队认可的安全加固机制. 并且根据不同技术栈提供了自适应的构建缓存策略, 避免依赖的重复下载, 大大节约构建时间, 提高开发过程效率. 开发在使用云效只需要选择他的技术栈和构建命令, 其他都可以交给平台自动化完成.
云效目前支持阿里云容器服务, edas,ecs 三种部署方式, 对每个应用的每个环境都可单独定义它的部署方式, 并且实现任意切换. 比如我们生产环境使用 edas 保障稳定, 测试环境使用 ecs 混合部署节省资源都是可以实现的, 非常方便.
在我们做运维栈转型升级的时候, 可以通过修改部署配置进行平滑升级, 如果有问题, 我们还可以实现一键回滚. 云效保存着历史所有软件发布升级的基线数据随时可查, 随时可 rollback, 这些都是阿里巴巴内部多年经验的积累实践.
在运维方面, 我们支持了通过 ECS 模板快速扩容, 并且在云市场也上线了云效推荐镜像, 直接可以获得和阿里巴巴一致的运维标准. 最后是基于特性分支的测试环境管理功能, 支持环境隔离能力, 具有生命周期管理功能, 让每个开发都可以享受到独立的研发环境, 并行工作, 高效交付. 以上功能都可以在阿里云云效帮助中获得详细操作指南.
来源: https://yq.aliyun.com/articles/598765