《2019年转型的灯塔！DevOps 持续交付能力成熟度模型及最新实践.pdf》由会员分享，可在线阅读，更多相关《2019年转型的灯塔！DevOps 持续交付能力成熟度模型及最新实践.pdf（22页珍藏版）》请在三个皮匠报告上搜索。

1、G O P S 全 球 运 维 大 会 2 0 1 9 上 海 站G O P S 全 球 运 维 大 会 2 0 1 9 上 海 站转型的灯塔！DevOps 持续交付能力成熟度模型及最新实践G O P S 全 球 运 维 大 会 2 0 1 9 上 海 站目录DevOps的重要性1DevOps实施的五个关键阶段2DevOps实施的四个要素和七个问题3持续交付能力成熟度模型介绍4二级应该怎么做5G O P S 全 球 运 维 大 会 2 0 1 9 上 海 站为什么DevOps很重要提质增效，行业总体趋势减少停机时间，更快上线减少人为错误，更安全，少故障降低人员流失带来的伤害您的竞争对手已经在这

2、样做G O P S 全 球 运 维 大 会 2 0 1 9 上 海 站DevOps实施的五个关键阶段定目标 理解DevOps，培训赋能，上下对齐，设定共同目标看现状 评估现有研发流程，技术栈，工具链，文化，管理，组织结构找差距 对标DevOps能力成熟度模型，找到差距，分析原因，设计方案画蓝图 绘制DevOps实施路线图搞事情 小规模试验，探索+调整，复制流程，大规模应用G O P S 全 球 运 维 大 会 2 0 1 9 上 海 站流程 基于现有产品研发流程进行梳理 打通流程的各个环节 保证流程的流畅和闭环 不断优化 可复制的流程管理规范 需求规范 开发规范 测试规范 部署规范 运维规范技

3、术/平台 技术架构 跨平台，多终端 云服务，自服务 业务管理平台 开发/测试/部署/监控平台DevOps实施的四个要素可视化（DevOps流水线+度量体系）G O P S 全 球 运 维 大 会 2 0 1 9 上 海 站1.DevOps 长什么样？2.DevOps 真的有用？3.DevOps 真的对我有用？4.DevOps 常见路线图5.我在哪儿，我做的如何？6.我要做什么才能变得更好？7.我要用什么工具？DevOps标准看见全貌参考路线定位度量改进方向工具平台DevOps 转型与落地，我们需要弄清楚七个问题G O P S 全 球 运 维 大 会 2 0 1 9 上 海 站主管单位：工信部

4、中国信息通信研究院（国家级智库，可信云等出品单位）联合发起：OSCAR 联盟、DevOps时代社区、高效运维社区起草单位：中国信息通信研究院、DevOps时代社区、高效运维社区、BATJ、中国移动、中国电信、中国银行、中国太平洋保险集团等目前进展：工信部和联合国ITU-T正式立项，2018年6月29发布全量送审稿DevOps 标准：研发运营一体化能力成熟度模型级别英文中文1级Initial Level初始级2级Foundation Level基础级3级Comprehensive Level全面级4级Excellent Level优秀级5级Fabulous Level卓越级G O P S 全 球

5、 运 维 大 会 2 0 1 9 上 海 站G O P S 全 球 运 维 大 会 2 0 1 9 上 海 站 1.具备中等企业IT交付水平 2.集中式管理，在局部建立自动化能力（包括构建、测试、部署与环境配置等）3.可按月进行发布，交付时长与质量具备一定水平，部署成功率和业务连续性相对稳定二级 1.具备成熟企业IT交付水平（IT能力是业务支撑）2.专业化管理，在全流程建立自动化能力，端到端打通各个交付环节 3.可按天或周进行发布，内建质量管控，部署失败率低，业务可用性高 4.具备一定的度量可视化能力，客观体现团队现状和问题三级 1.具备顶级互联网/科技企业IT交付水平（IT能力是核心竞争力）

6、2.团队自治，实现持续交付平台化，CD as Service，并对研发团队进行赋能 3.每天具备多次发布的能力，团队可按需自行交付，实现业务无中断和高质量 4.具备较强的度量反馈机制，业务实现良性增长和团队持续改进四级国内先进水平DevOps标准的级别说明G O P S 全 球 运 维 大 会 2 0 1 9 上 海 站为了实现二级，我们还有很多问题版本混乱无法回溯，修复了的Bug又出现了每次集成伴随大量的问题和冲突，集成期间主干长期不可用迭代6次才能上线投产一次，版本如何管理进度不可控，等待上线时间太长部署步骤太多太复杂，上线经常失败为了实现二级，我们还有很多 问题 机会G O P S 全

7、球 运 维 大 会 2 0 1 9 上 海 站配置管理过程域二级 过程域评估维度一级（初始级）二级（基础级：自动化/脚本化、小范围）配置管理版本控制版本控制系统源代码分散在研发本地自行管理1)使用统一的版本控制系统2)将全部源代码纳入版本控制系统管理分支管理无分支策略，或没有统一策略多条分支长期并行存在且分支合并到主干的周期长制品管理构建产物分散在研发本地自行管理1)使用统一的制品库管理构建产物2)有清晰的存储结构3)有唯一的版本号4)通过统一的制品库地址进行构建产物分发单一可信数据源无开发测试部署环节所用到的源代码来源于统一版本控制系统变更管理说明：该变更是指需求、代码等内容变更过程1)无变

8、更过程2）变更信息分散在每个系统内部，缺乏信息的有效共享机制1)建立代码基线2)记录代码变更管理信息3)针对重点变更内容进行评审变更追溯无1)有清晰定义的版本号规则2)实现制品和代码基线的关联，可追溯指定版本的完整源代码信息变更回滚无手工实现回滚G O P S 全 球 运 维 大 会 2 0 1 9 上 海 站构建方式 采用手工方式进行构建，或者严重依赖于IDE 使用研发人员本地设备构建构建计划 构建任务不定期执行 没有统一的持续集成服务持续集成 长期本地开发代码，集成频率几周或者几月一次 代码集成作为软件交付流程中的一个独立阶段 每次集成伴随大量的问题和冲突，集成期间主干长期不可用G O P

9、 S 全 球 运 维 大 会 2 0 1 9 上 海 站过程域二级 过程域评估维度一级（初始级）二级（基础级：自动化/脚本化、小范围）构建与持续集成构建实践说明：关注软件代码到可运行程序之间的过程构建方式采用手工方式进行构建采用脚本实现构建过程自动化构建环境使用研发本地设备构建有独立的构建服务器，多种任务共用构建环境构建计划构建任务不定期执行1）实现每日自动构建2）根据发布策略细分构建类型，比如发布构建、测试构建构建职责无专人专岗负责构建构建工具、环境与计划由专人负责维护并有权限管理持续集成集成服务无持续集成服务搭建统一的持续集成服务集成频率长期本地开发代码，集成频率几周或者几月一次采用团队定

10、期统一集成的策略，代码集成频率几天或者几周一次集成方式代码集成作为软件交付流程中的一个独立阶段在部分分支上进行每天多次的定时构建反馈周期每次集成伴随大量的问题和冲突，集成期间主干长期不可用集成问题反馈和解决需要半天或者更长时间构建与持续集成G O P S 全 球 运 维 大 会 2 0 1 9 上 海 站测试分层策略 只进行用户/业务级的UI测试 无测试分层方法或分层策略测试介入时机 测试在软件交付过程中在开发完成后才介入 手工测试为主，自动化程度低自动化测试 自动化测试脚本与工具分散管理 测试执行以周为单位 手工对测试结果进行分析判断G O P S 全 球 运 维 大 会 2 0 1 9 上

11、 海 站过程域二级 过程域评估维度一级（初始级）二级（基础级：自动化/脚本化、小范围）测试管理测试分层策略分层方法说明：分层方法是测试体系按照不同的测试对象，类型进行分类聚合的方法，每一层对应了特有的测试需求。只进行用户/业务级的UI测试1)采用接口/服务级测试对模块/服务进行覆盖全面的接口测试；2)采用代码级测试对核心模块的函数或类方法进行单元测试；3)对系统进行基本的性能测试分层策略说明：分层策略是指基于测试分层策略对每部分的测试比重和投入，以及覆盖度等的划分策略。无测试分层策略1)已建立测试分层策略2)测试设计以对用户/业务级UI测试为主，辅以少量的接口/服务级测试测试时机测试在软件交付

12、过程中在开发完成后才介入1)测试在持续交付过程中的介入时间提前到开发的集成阶段2)接口/服务级测试在模块的接口开发完成后进行自动化测试自动化设计说明：自动化设计是指测试分层中各种测试类型的自动化设计方法，用于指导自动化测试工作的有效执 行。无对用户/业务级的UI测试进行自动化设计自动化开发自动化测试脚本与工具分散管理1)设置专人专岗统一管理自动化测试脚本与工具2)使用版本控制系统对自动化测试脚本进行有效管理自动化执行1)手工测试为主，自动化程度低2)测试执行以周为单位1)对用户/业务级UI测试采用自动化测试2)自动化测试的执行效率较低，以天为单位自动化分析手工对测试结果进行分析判断对自动化测试

13、结果具备一定的自动判断能力，存在一定的误报测试管理G O P S 全 球 运 维 大 会 2 0 1 9 上 海 站灰度测试每周每日测试每日服务测试定时（12小时）可用性测试提交即测试（510分钟）稳定性测试验收测试/人工测试灰度测试压力测试/异常测试系统测试验收测试/人工测试功能测试/新功能测试回归测试集成测试单元测试冒烟测试功能测试建立测试分级体系，从不同级别和频率进行全面的质量保障。UI测试服务测试单元测试建立测试分级体系G O P S 全 球 运 维 大 会 2 0 1 9 上 海 站质量规约&环境管理过程域二级过程域评估维度一级（初始级）二级（基础级：自动化/脚本化、小范围）代码质量

14、管理代码质量管理质量规约具备初始代码质量规约，规约停留在个人级1)建立团队级代码质量规约2)规约范围覆盖部分代码质量指标，如：代码规范、错误和圈复杂度、重复度等质量指标检查方式代码质量检查采用人工方式进行评审代码质量检查采用自动化结合手工方式进行反馈处理无代码质量检查结果处理机制，存在大量技术债对代码质量检查结果给出反馈，只处理部分检查结果环境管理环境管理环境类型环境类型只有生产环境和非生产环境的划分建立功能测试环境环境构建1)人工创建环境2)环境准备时间长，需要几周完成1)环境构建通过自动化来完成2)环境准备时间以天为单位环境依赖与配置管理1)无依赖管理2)环境的管理为操作系统的交付方式通过

15、配置管理工具实现操作系统级别的依赖管理，比如说操作系统版本、组件版本、程序包版本等等G O P S 全 球 运 维 大 会 2 0 1 9 上 海 站过程域二级 过程域评估维度一级（初始级）二级（基础级：自动化/脚本化、小范围）部署与发布管理部署与发布模式部署方式运维人员手工完成所有环境的部署1)运维人员通过自动化脚本实现部署2)部署过程部分自动化部署过程部署过程存在较长的服务中止时间部署过程通过流程文档实现标准化部署策略1)采用定期部署策略，部署频率以月为单位2)单次部署包含大量需求1)采用定期部署策略，部署频率以周为单位2)应用作为部署的最小单位3)应用和数据库部署实现分离4)实现测试环境

16、的自动化部署部署质量1)部署整体失败率较高2)部署无法实现回滚，生产问题只能在线上修复，修复时间不可控1)部署失败率中等2)实现应用部署的回滚操作，问题可及时修复部署流水线协作模式1)整个软件交付过程严格遵循预先计划2)存在复杂的部门间协作和等待3)只有在开发完成后才进行测试和部署通过定义完整的软件交付过程和清晰的交付规范，保证团队之间交付的有序流水线过程 软件交付过程中的大部分工作通过手工方式完成软件交付过程中的各个环节建立自动化能力以提升处理效率过程可视化1)交付过程中的信息是封闭的2)交付状态追溯困难1)交付过程在团队内部可见，信息在团队间共享2)交付状态可追溯部署与发布管理G O P

17、S 全 球 运 维 大 会 2 0 1 9 上 海 站数据管理过程域二级过程域评估维度一级（初始级）二级（基础级：自动化/脚本化、小范围）数据管理测试数据管理数据来源测试时手工创建临时数据导出部分生产环境数据形成基准的测试数据集数据覆盖测试数据覆盖部分测试场景1)测试数据覆盖主要场景，包括：正常类型，错误类型以及边界类型2)进行初步的分类分级，满足不同测试类型需要数据独立性说明：数据独立性是指测试数据在测试执行各阶段的完整性和一致性，不会受到其他任务执行结果的影 响。无1)测试数据有明确备份恢复机制2)实现测试数据复用和保证测试一致性数据变更管理说明：数据变更管理主要是指应用程序升级和回滚过程

18、中的数据库结构和数据的变更变更过程1)数据变更由专业人员在后台手工完成2)数据变更作为软件发布的一个独立环节，单独实施和交付1)数据变更通过文档实现标准化2)使用自动化脚本完成数据变更兼容回滚没有建立数据库版本，数据库和应用存在不兼容风险建立数据库和应用的版本对应关系，并持续跟踪版本变更数据监控数据变更结果需要访问数据库进行验证收集和分析数据变更日志，实现变更问题快速定位G O P S 全 球 运 维 大 会 2 0 1 9 上 海 站度量与反馈过程域二级过程域评估维度一级（初始级）二级（基础级：自动化/脚本化、小范围）度量与反馈度量指标度量指标定义说明：度量指标是度量体系的基础在持续交付部分

19、阶段定义度量指标在持续交付各个阶段定义度量指标，度量指标仅限于部门内部度量指标类型无度量指标以结果指标为主，如变更频率，需求交付前置时间，变更失败率和平均修复时间度量数据管理度量数据是临时性的度量数据采用抽样方法收集度量指标更新无度量指标的设立后变更周期较长度量驱动改进内容和生成方式度量报告通过手工方式生成度量报告以自动化方式生成度量报告具有标准格式定义数据时效性数据和度量报告的时效性存在差异 数据报告可展现最新状态覆盖范围仅部分人员可查看报告团队内部成员均可查看报告反馈改进度量反馈问题解决周期较长度量反馈的问题录入系统跟踪，并定期实施改进G O P S 全 球 运 维 大 会 2 0 1 9 上 海 站 DevOps转型与落地要弄清楚七个问题 DevOps实施的五个关键阶段 定目标，看现状，找差距，画蓝图，搞事情 DevOps实施的四个要素 流程，规范，技术，可视化 二级应该怎么做内容回顾