1张乐-持续交付：高效率和高质量可以兼得

GOPS2016全球运维大会·上海站持续交付-高效率和高质量可以兼得张乐百度自我介绍张乐•百度工程效率部–资深敏捷教练、架构师•百度内先进软件工程方法和生产力的践行者、布道者•十三年软件行业工作经验•敏捷、精益•项目管理•持续交付、DevOps•『百度方法+』持续交付专题负责人互联网时代对软件交付的诉求效率质量•专注、极致、口碑、快•快速迭代•唯快不破•只有第一，没有第二•用户体验至上•细节决定成败•缺陷-差评-卸载•服务故障-百倍赔付我们处在一个VUCA的时代软件交付面临易变性、不确定性、复杂性、模糊性业界互联网公司软件交付能力概况公司周期时间部署频率可靠性客户响应Amazon分钟23000次/天高高Google分钟5500次/天高高Netflix分钟500次/天高高数据来源：《ThePhoenixProject：ANovelAboutIT,DevOps,andHelpingYourBusinessWin》仅涉及一行代码的改动需要花多长时间才能部署上线？你是以一种可重复且可靠的方式来做这件事的吗？引用：《ImplementingLeanSoftwareDevelopment》,Page.59除此之外，还有Facebook、Twitter等国际互联网巨头，都有非常高的部署频率百度某产品部署频率统计0102030405060020040060080010001200一月二月三月四月五月六月某产品生产环境部署次数每工作日部署次数每月部署次数进度不可控package里版本号脚本修改错误传统软件交付的困境流程不可靠环境不稳定协作不顺畅分支过多合并困难缺陷爆发测试阻塞版本混乱无法回溯环境公用未知错误部署复杂经常失败等待上线周期太长发现故障无法定位线上报警紧急回滚传统软件交付过程的问题分析业务开发运维测试墙墙墙•运维排期紧张，上线需要等待•手工运维繁琐、复杂、易出错•测试反馈周期长，测试占研发比重大•自动化测试程度低，质量把控不完备•需求以文档传递，缺乏沟通•需求描述不清，且经常变更传统软件研发和交付过程无法满足业务快速、稳定交付的要求效率低，存在浪费反馈慢，质量保证不全故障多，操作耗时长人员、流程、技术被「墙」阻断，Throwitoverthewall…持续交付的解决思路SSSOD如何实现持续交付？持续交付方法体系•••••••••••••••业务–从源头改变交付模式最简可行产品（MVP）研发的最大的浪费是构建没有人使用的东西精益创业：更小、更快的迭代流程验证想法验证式学习循环看板：可视化方法管理流动用户故事地图：需求全景和发布计划业务–看板功能的生命周期可视化，管理流动并且要建立需求到代码的追踪机制建立需求卡片到代码的关联流程-可靠可重复的流水线通过流水线阶段划分，平衡测试反馈速度与覆盖度通过流水线分析瓶颈、识别自动化改造点和协作点交付流水线演进：模块级申请版本编译单元测试撰写单测报告提测系统测试撰写测试报告发上线单上线审批上线原始的、低效的流水线代码合入编译单元测试模块测试系统测试提测系统测试发布预上线现代化、高效的流水线主干合并自动触发一键式操作自动触发定时触发邮件通知自动触发一键式操作一键式操作一键式操作填写表单单机编译环境手工执行编译执行测试脚本编写测试报告文档发邮件或消息告知版本号、地址手工准备环境手工执行部署手工执行测试编写测试报告文档填写表单编写上线步骤文档工单流转QA、RD、OP审批手工准备环境手工执行部署手工冒烟测试编译集群分布式编译加速自动上传产品库自动执行测试脚本自动统计测试覆盖率自动部署测试环境自动执行测试脚本自动部署测试环境自动执行测试脚本自动部署测试环境部署后自动冒烟测试手工执行测试非功能和异常测试设置测试结果状态设定四位版本自动上传正式产品库自动部署环境部署后自动冒烟测试执行端到端场景测试自动部署环境部署后自动冒烟测试提交到代码库CodeReview代码规范检查OfflineOnline小流量Online全流量N套交付流水线演进：产品级编码和自测代码合入，触发编译和测试Daily测试集成测试阶段发布阶段Pre-submit单元测试模块测试系统测试代码合入拉出分支编译-临时产品库发布四位版本-生产镜像发布四位版本-生产镜像发布四位版本-正式产品库检出代码开发,提交生产监控Pre-submit单元测试模块测试系统测试代码合入编译-临时产品库检出代码开发,提交Pre-submit单元测试模块测试系统测试代码合入编译-临时产品库检出代码开发,提交模块一模块二模块三端到端的集成测试性能压力稳定性测试准入测试提测提测提测制作镜像-镜像库编译-制作镜像-镜像库拉出分支准入测试编译-制作镜像-镜像库拉出分支准入测试编译-临时产品库完整的端到端测试性能压力稳定性测试小流量-全流量小流量-全流量小流量-全流量制作镜像-镜像库17交付流水线的工具落地开源方案：GoCD、Spinnaker自研方案：百度Agile平台配置管理–FeatureBranch•RD在自己的分支工作，隔离其他工作变更•场景A：分支开发，分支发布，发布后合并主干•场景B：分支开发，分支测试，主干回归，主干发布存在的问题：•昀终还是要集成，如果不同分支代码有交互，合并时大量冲突需要解决（文本冲突、语意冲突）•合并冲突时易出错，发布后容易忘记合并回主干•每个分支建立单独的测试流水线，浪费资源，并且其实未实施集成测试带来的好处：•多个Feature完全并行开发，互不影响•可以选择Feature进行发布，不会被其他功能阻塞配置管理–TrunkBasedDevelopment•RD经过充分的本地验证后，频繁提交代码到主干•场景A：主干开发、主干发布•场景B：主干开发、分支发布存在的问题：•主干上功能开发有先后，有未完成的功能但又需要发布时，需要能隐藏未完成部分•为了避免以上情况，有三种递进的方式：（1）功能拆分，小批量频繁发布；（2）后端先行，UI或功能入口后发布；（3）功能开关，配置决定功能带来的好处：•主干持续集成，在冲突形成的早期发现•主干一直健康，每次合入后都可安全发布主干开发&Localbuild主干测试发布分支RB测试上线拉分支开发&Localbuild开发&Localbuild•全量部署包•提供稳定的控制接口•差异化部署使用配置派生•自定义上线步骤配置管理–部署包规范GIT/SVN构建回溯标准化部署包规范，提升大规模部署时的自动化程度配置管理–配置注入的方式MacPro编译集群Ubuntu编译集群CentOS编译集群Windows编译集群其他定制编译集群调度策略l集群加速，提高并发场景吞吐量l模块间依赖采用二进制构建产物l使用增量编译l机器针对编译任务硬件优化lC++模块间使用distcc和ccache分布式编译l标准化编译配置文件，代码提交自动编译构建管理l编译结果推送至『制品仓库』管理提供云编译服务，标准化编译环境，提升编译效率测试管理分级测试模型建立分级测试体系，从多个层次和多个验证角度实现质量防护网持续集成重点在原则的坚持：•小改动，逐步构建•每人每天提交代码•在主干上持续集成•至少每天进行集成•使用持续集成工具•自动化构建和测试•分级测试快速反馈•红灯需要立即修复StorageServersNetworkingO/SMiddlewareVirtualizationDataApplicationsRuntimeStorageServersNetworkingO/SMiddlewareVirtualizationDataApplicationsRuntimePaaSSYS（硬运维）OP（软运维）环境管理转为平台运维•上线时间降低（小时级别-分钟级别）•扩容效率提升（天级别-分钟级别）•运维效率提升，人均运维机器数（百台-千台）•流程繁杂，需运维介入手工操作多•跨团队协作，沟通和协调成本高•运维效率低，派单周期长、问题多环境管理-PaaS平台开源方案：K8S+Docker自研方案：百度Matrix系统Matrix作为百度数据中心的容器集群管理系统，为所有的产品线提供规范的底层架构•资源管理：提供虚拟化的容器资源•隔离与混部：资源高效、充分利用环境管理–容器集群管理部署管理部署管理遵循的原则•部署包全部来自制品仓库•各环境使用相同部署方式•各环境使用相同部署脚本•部署流程编排，阶梯式晋级•运维人员参与部署过程创建•只有流水线才可变更生产环境，防止配置漂移•不可变（Immutable）服务器•热部署：蓝绿部署、金丝雀发布自动化测试自动化测试自动化监控自动化监控自动化测试自动化测试自动化测试自动/手工测试自动化测试产品A测试环境产品B测试环境产品C测试环境编译集群单元测试模块测试提交代码主干持续集成沙盒测试环境预上线环境内网生产环境外网生产环境自动部署自动部署自动部署自动部署拉分支源码库代码、配置、脚本系统测试分支发布自动化编译自动部署候选发布版本『每台服务器都是不同的』自动化、配置化的环境管理不可变服务器（ImmutableServer)部署管理-不可变服务器基础架构–持续交付技术栈bH--TRxrineh-&-&--oBE-aMcSltnltNUvm--&-&---IDSDNApsuetueKi----i-hi-DPtPtgCue•SourceCode•TestCode•AppConf•PackConf&-&-•QMC•P•G•ORpsA--QMS-应用架构–微服务架构微服务架构优点•技术异构性、弹性、扩展性、简化部署、与组织结构匹配、可组合性、优化可替代性微服务架构实践•每个服务独立部署•每个服务独立构建流水线•在隔离的容器中运行服务•消费者驱动的测试（CDC）微服务架构是一种分布式系统解决方案，推动细粒度服务的使用，这些服务协同工作，且每个服务都有自己的生命周期。应用架构–配置化架构配置化架构解决的问题•静态代码构成的大型系统在编译、重型的测试上都耗费很多时间•系统升级需要重启，影响对外提供服务，甚至会影响收入配置化架构的优点•通过配置，在较低的变更成本下，实现快速的调整软件系统配置化架构是指可配置的方式构建软件的方法。它是在领域建模的基础上，以配置表述业务，以配置组织架构元素（服务、组件、数据），并对配置进行规范化、自动化的管理。组织–团队和协作沟通协作集成DEV•遵从配置管理策略•坚持持续集成习惯•非功能、运维需求•构建监控反馈通道•培养端到端责任文化•构造更贴近生产的环境OPS•标准化部署过程•自动化部署脚本•服务能力转换为平台能力•减少对人员和经验的依赖•上线执行者转变为审核者•面向事务转变为面向价值透明化工作流程、系统架构、监控模型基于完整流水线的可视化工作集成在保持本职工作专注的前提下，鼓励T型人才和跨界的文化1234流水线构建总览、分团队总览数据筛选和下钻，各团队数据核心数据汇总，环比变化趋势自动分析和异常报表推送邮件组织–数据度量和改进100.0%100.0%100.0%96.5%93.6%90.9%89.3%86.4%85.7%81.3%80.4%77.4%72.6%69.8%69.6%58.5%50.5%50.0%48.1%47.4%47.0%40.7%4.2%0%10%20%30%40%50%60%70%80%90%100%构建成功率从度量中找到问题，从度量中看到进步组织–数据度量和改进配置管理构建管理持续集成测试管理部署管理环境管理持续交付成熟度模型组织–持续交付成熟度模型配置管理构建管理持续集成测试管理部署管理环境管理持续交付效果案例编译单元测试模块测试产品测试发布发单上线上线检查持续交付改进之前•编译、开发、测试、部署上线全面加速，整体交付周期明显缩短•各角色可以基于统一的交付流水线紧密协作，产品交付过程可视化、可控制•每日多次发布能力、故障快速回滚的能力持续交付的价值快速交付从需求到交付端到端交付周期缩短保证质量效率提升的同时，保证质量稳定降低风险稳定节奏的交付，增强可预测性Q&AGOPS2016全球运维大会·上海站Thanks高效运维社区开发运维联盟