全球运维技术大会

姚冬 2018加速度,洞悉DevOps高效能组织的秘

1. 2018加速度:洞悉DevOps高效能组织的秘密 全球DevOps状态报告解读 姚冬 中国DevOpsDays核心组织者 华为云 软件开发服务 首席技术布道师
2. 姚冬 华为云 软件开发服务(DevCloud) • 首席技术布道师 • 资深DevOps与精益/敏捷专家 • 金融解决方案技术Leader • 中国DevOpsDays社区核心组织者
3. 没有度量,就无法管理 没有度量,就无法改进
4. 如何度量? • DEV的考核指标是什么? • QA的考核指标是什么? • OPS的考核指标是什么? • 追求确定的、绝对的数值的管理方法? • 考核什么指标,就会得到什么指标 • 企业绩效的考核指标是什么?
5. 度量的常见误区 • Outputs > Outcomes • Local > Global • Individual > Team
6. 常见错误1:代码行数 Line of code • 越多越好? ★ 更臃肿的软件 ★ 更高的维护成本 ★ 更高的变更成本 • 越少越好? ★ 玄妙莫测且无法理解的代码 • 理想的:用最有效的代码解决业务问 题
7. 常见错误2: 速率 Velocity • Agile:问题被拆分成故事,评估完成这些工作的点 数 • 在冲刺结束的时候,由客户签收的点数被记录下来 = 速率 • Velocity 速率是 产能计划 工具。而不是 生产效率 工具 • 为什么速率不能作为生产效率使用? ★ 速率只是一个相对的度量,而非绝对的。因此,很不适合 用于团队间的比较 ★ 点数评估被夸大,被博弈 ★ 聚焦在团队的完成度,通常牺牲了团队间的协作(这是一 个全局目标)
8. 常见错误3:利用率 Utilization • 利用率仅仅在某个点上/程度上是好 的 • 利用率越高越好么? ★ 在高利用率下,我们失去了用于非计划工 作的可支配的时段 ★ 排队理论:在利用率达到100%的时候, 前置时间接近于无穷大 ★ 当你们的利用率越来越高的时候,所有团 队将花费越来越长的时间完成任何的工作
9. 度量指标的延迟反馈 引自乔梁 “Leading DevOps in the right way”
10. 组织效能 高效能组织的考量标准 商业目标 非商业目标 • 盈利能力 三年里市场总值 • • 生产力 利润率 增长超过50% • 市场份额 • 客户数量 • 产品或服务的数量 • 运营效率 • 客户满意度 • 产品或服务的质量 • 达成组织的使命和目标
11. 全球 DevOps 现状调查报告 DevOps领域 被充分验证过的实践集合 《Accelerate: State of DevOps Report》
12. 2018报告的关键发现 • SDO 软件开发与运维效能解锁竞争优势 • 如何实施云基础设施很关键 • 云原生、平台即服务PaaS • 应用开源软件可以提高效能 • 精英团队几乎不使用有损于效能的职能 外包模式 • 关键技术实践驱动高效能 • 实现高效能的软件交付和行业无关
13. 价值点:软件交付效能的量化定义 • 软件研发效能度量的难点 • 研发过程可视性差 • 工作切分的随意性 • 敏捷开发中工作都是并行的 聚焦在全局产出(Outcome),而不是局部工作输出(Output) • 软件研发效能度量的误区 • 代码行 • 资源使用率 • 缺陷数 • 敏捷速率(如故事点数)
14. 价值点:保守还是追求卓越?速度与稳定可以兼得 最优秀的高绩效组织总是能在吞吐量和稳定性上同时达到卓越的水平,而不是在两者中取舍,或者牺牲掉某一个 • 在吞吐量(throughput)和稳定性(stability)之间 进行取舍(权衡)是一种常见的行业实践,尤其是 在政府或高度监管的领域里 • 有的组织更愿意采取保守型的软件开发和交付策略。 他们保证,低频次地发布代码是一个有效的策略。 因为这样就可以有更多的时间用于部署、测试和质 量检验,从而失败/故障发生的可能性将会降到最低 • 在日益复杂的系统中实施软件开发是困难的,失败/故障也是在所难免 • 大批量、低频的变更会给部署环节带来风险 • 一旦有失败/故障出现,找到问题的根因和恢复服务是非常困难的。更 糟糕的是,部署还会在整个系统里引发一连串其它的故障,全面恢复这 些次生故障需要的时间更是惊人的。
15. 价值点:人工操作占比 • 将重复性任务或可并行处理 的任务自动化 • 团队和组织可以提升工作的 质量、可重复性和一致性 • 将员工从低价值任务中解放 出来 • 高效能组织可以释放出更多 的技术人员来从事那些可增 加真正价值的创新性工作。 • 精英组织和高效能组织的人工工作量水平在所有维度都低 于低效能同业且差距显著 • 中等效能组织的人工工作量在所有维度都是最高的
16. 价值点:时间都去哪儿了?还没好好干活项目就延期了 四类工作 • 业务项目 • 内部项目 • 变更 • 计划外工作
17. 价值点:软件交付效能是组织效能的重要因素 新增『可用性』度量指标 可用性代表团队确保服务可用的能力。增加可用性指标后,我 们的指标集就形成了涵盖软件开发、交付、运维的更为全面的 视⻆,从软件交付效能升级为:软件交付和运维效能 SDO。 软件交付效能是理解组织效能的重要因素。今年我们在模型中新增了可用性, 创建了用于预测组织效能的二阶构造。新的软件交付和运维效能二阶构造,与 以前单独的度量软件交付效能或可用性相比,能更好地预测组织效能。
18. 价值点:DevOps实践与软件交付效能的关系 结构化方程模型(SEM) 具体实践的指引
19. SEM结构化方程模型的演进 2015 2016 2017
20. DevOps能力成长模型-2017年版
21. Accelerate 精益软件和DevOps的科学 构建并拓展高效能技术组织
22. 个人介绍 2018DevOpsDays●深圳站
23. 持续交付的影响地图 (没有最佳实践) • 自动化部署 • 持续集成 • 主干开发 • 松耦合架构 • 版本控制 • 持续测试 • 监控与可观测性 • 管理数据库变更 • 安全性和安全效能 DevOps是各种好的技术实践的融合
24. Architecture matters...Technology doesn't • 架构的产出很关键 • 团队能否: ★ 变更系统的设计 ★ 测试系统 ★ 部署系统 ★ 而不依赖与外部人进行沟通和协作
25. 康威定律 康威指出:系统设计受限于组织自身的沟通结构 • 第一定律:组织沟通方式会通过系统设计表达出来 • 第二定律:时间再多一件事情也不可能做得完美,但 总有时间做完一件事情 • 第三定律:线型系统和线型组织架构间有潜在的异质 同态特性 • 第四定律:大的系统组织总是比小系统更倾向于分解 “系统设计受限于组织自身的沟通结构,组织规 模越大,灵活性就越差,这种现象也就越明显” – Melvin Conway, 1968 http://www.melconway.com/Home/Committ ees_Paper.html
26. 精益管理 精益管理 (未在2018状态报告中包含)
27. 精益产品开发 精益产品开发 可视化
28. 领导力转型的7个维度 聪明的投资在技术和实践上,营造良好的工作氛围(文化) 工作在:减少部署痛点方面 工作在:降低精疲力尽/加班加点上 工作在:提高NPS员工净推荐值上
29. • 把学习看做为是一种投资 • 在复杂环境中学习新知识 • 把失败看作是学习的机会 • 建立起公正和学习的文化 “我们可以找有经验的人来,避免 犯错,但这种人很少;我们也可以 找没有经验的人,通过鼓励他们在 工作中不断尝试,不断犯错,缩短 反馈周期,降低犯错的成本,来增 长经验,避免更大的错误。” ——Kent Beck 学习氛围 Good decision comes from experience, experience comes from bad decisions. —Kent Beck
30. 个人介绍 2018DevOpsDays●深圳站 在高效能组织中工作的雇员更愿 意向周围的朋友推荐自己的组织
31. DevOps能力成长模型的价值 • 是演进的模型,而不是标准 • 适用于能力和起点,水平不齐的不同团队 能力 • 符合每个团队的优劣势,和业务上下文的不同 模型 • 每个团队聚焦在不同的、各自的约束点/弱点上 • 根据行业基线设置下一步的目标
32. 建议的套路 • 从度量少量的几个指标开始 • 聚焦在成果产出型的、全局的指标上 • 考量有哪些在你控制之内的事情,可以 推动的指标 • 不仅仅在技术方面,而且还包括非技术 方面 • 分享你的成功案例!利用本地社群!
34. 转型的J型曲线
35. 惯性 against 加速度 固守既往 等于 坐以待毙 个人能力成长 组织创新求变
36. Jesse's Rule: Don't Fight Stupid, Make More Awesome 微信号 公众号 AgileRunner

相关幻灯片