没有度量就没有管理—洞察DevOps能力成长模型

A presentation at DevOpsDays Taipei 2018 in September 2018 in Taipei, Taiwan by Martin Liu 刘征

Slide 1

Slide 1

没有度量量就没有管理理 洞察DevOps能⼒成长模型 1

Slide 2

Slide 2

中国DevOps社区组织者 刘征 Martin Liu Ops背景 云计算 ⼯具链

Slide 3

Slide 3

Slide 4

Slide 4

Fortune 500 company 数字化颠覆将在10年年内抹掉40%的公司 ➤ 在下⼀个10年⾥，S&P500的公司⼀半会被新 的公司替换 ➤ 奥地利经济学家约瑟夫·熊彼特：创新性破坏

Slide 5

Slide 5

加速度 业务⼀如既往等于⽇落西⼭

Slide 6

Slide 6

⾯面向度量量指标的管理理⽅方式？ ➤ Dev的考核指标是什么？ ➤ QA的考核指标是什么？ ➤ Ops的考核指标是什么？ ➤ 追求确定的、绝对的数值的管理⽅法对么？ ➤ 考核什么指标，就会得到什么指标？ ➤ 企业绩效的考核指标是什么？

Slide 7

Slide 7

⾼高效能组织都能够达成⽬目标 2x+ 三年⾥市场总值 增长超过50% 商业⽬标 ⾮商业⽬标 ➤ ⽣产率 ➤ 产品或服务的质量 ➤ 利润率 ➤ 运营效率 ➤ 市场份额 ➤ 客户满意度 ➤ ⽤户数 ➤ 产品或服务的数量 ➤ 达成组织的使命和⽬标

Slide 8

Slide 8

度量量管理理的常⻅见错误 ➤ 低层级的⼯作输出 > 全局的成果 ➤ ➤ Outputs > Outcomes 局部/个体 > 全局/团队 ➤ Global / team > locale / individual

Slide 9

Slide 9

常⻅见错误1：代码⾏行行数 Line of code ➤ ➤ 越多越好？ ★ 更臃肿的软件 ★ 更⾼的维护成本 ★ 更⾼的变更成本 越少越好？ ★ ➤ ⽞妙莫测且⽆法理解的代码 理想的：⽤最有效的代码解决业务问题

Slide 10

Slide 10

常⻅见错误2： 速率 Velocity ➤ Agile：问题被拆分成故事，评估完成这些⼯作的点数 ➤ 在冲刺结束的时候，由客户签收的点数被记录下来 = 速率 ➤ Velocity 速率是 产能计划 ⼯具。⽽不是 ⽣产效率⼯具 ➤ 为什么速率不能作为⽣产效率使⽤？ ★ 速率只是⼀个相对的度量，⽽⾮绝对的。因此，很不 适合⽤于团队间的⽐较 ★ 点数评估被夸⼤，被博弈 ★ 聚焦在团队的完成度，通常牺牲了团队间的协作（这 是⼀个全局⽬标）

Slide 11

Slide 11

常⻅见错误3：利利⽤用率 Utilization ➤ 利⽤率仅仅在某个点上/程度上是好的 ➤ 利⽤率越⾼越好么？ ★ 在⾼利⽤率下，我们失去了⽤于⾮计划⼯ 作的可⽀配的时段 ★ 排队理论：在利⽤率达到100%的时候， 前置时间接近于⽆穷⼤ ★ 当你们的利⽤率越来越⾼的时候，所有团 队将花费越来越长的时间完成任何的⼯作

Slide 12

Slide 12

DevOps能⼒力力成⻓长模型-2017年年版 DORA - Dr Nicole Forsgren, CEO and Chief Scientist &

Slide 13

Slide 13

Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations Link: http://a.co/eo5FyQj

Slide 14

Slide 14

四年年的DevOps⾏行行业状态调查研究

Slide 15

Slide 15

2018年年DevOps状态报告是怎样的？

Slide 16

Slide 16

2018报告的核⼼心发现？ ➤ SDO效能解锁竞争优势 ➤ 如何实施云基础设施很关键 ➤ 应⽤开业软件可以提⾼效能 ➤ 精英团队⼏乎不使⽤有损于效能的职能外 包模式 ➤ 关键技术实践驱动⾼效能 ➤ 实现⾼效能的软件交付和⾏业⽆关

Slide 17

Slide 17

Slide 18

Slide 18

效能指标模型有所扩展 吞吐量 稳定性

Slide 19

Slide 19

⾼高效能是怎么 炼成的？ 成熟度是已经过时的模型

Slide 20

Slide 20

Slide 21

Slide 21

DevOps能⼒力力成⻓长模型有什什么优势？ ➤ 适⽤于本来能⼒和起点就参差不齐的不同团队 ➤ 符合每个团队的优劣势和业务上下⽂的不同 ➤ 每个团队聚焦在不同的、各⾃的约束点/弱点上 ➤ 根据⾏业基线设置下⼀步的⽬标 能⼒ 模型

Slide 22

Slide 22

技术实践很关键 DevOps是各种技术实践的⼤融合

Slide 23

Slide 23

持续交付的驱动⼒力力 — 持续交付的影响地图

  1. 版本控制 2. ⾃自动化部署 3. 持续集成 4. 主⼲干开发 5. ⾃自动化测试 6. 测试数据管理理 7. 模式化安全管理理 8. 松耦合架构 9. 赋能团队 10. 监控 11. 前瞻性预警通知 Westrum企业⽂文化 持续交付 更更少的返⼯工 软件交付效能 个⼈人的认同 组织的效能

Slide 24

Slide 24

架构很关键 ⽽不是技术

Slide 25

Slide 25

架构的产出很关键 ➤ 团队能否： ★ 变更系统的设计 ★ 测试系统 ★ 部署系统 ★ ⽽不依赖与外部⼈进⾏沟通和协作

Slide 26

Slide 26

每个开发者，每天的部署次数 部署频率 ⾼高等效能 随着开发者⼈数急剧提⾼ 中等效能 维持在⼀个基本恒定的频率 低等效能 随着开发者⼈数急剧下降 开发⼈员数量

Slide 27

Slide 27

“ 任何组织在设计⼀套系统时，所交付的设计⽅案在 结构上都与该组织的沟通结构保持⼀致。 -梅尔.康威

Slide 28

Slide 28

软件管理理实践和 产品开发很关键 两⼿抓，两⼿都要硬

Slide 29

Slide 29

精益管理理实践的影响地图 Westrum企业⽂文化 精益管理理 限制在制品（WIP） 可视化管理理 ⽣生产环境的反馈 轻量量的变更更管理理 软件交付效能 更更少的加班加点

Slide 30

Slide 30

精益产品管理理的影响地图 Westrum企业⽂文化 精益产品管理理 ⼩小批量量⼯工作 使⼯工作流可视化 收集和实施客户反馈 进⾏行行团队实验 软件交付效能 更更少的加班加点 组织的效能

Slide 31

Slide 31

领导⼒力力很关键 组织转型领导⼒

Slide 32

Slide 32

领导⼒力力转型的5个维度

Slide 33

Slide 33

转型领导⼒力力和效能之间的关系 转型领导⼒力力 个体认同 ⽀支持型领导 智⼒力力激发 ⿎鼓舞型沟通 愿景 组织的效能 精益产品管理理 团队进⾏行行试验 ⼩小批量量⼯工作 收集和实施客户反馈 测和部署⾃自动化 持续集成 主⼲干开发 前置安全管理理 松耦合架构 赋能团队 IT效能 2016 持续交付 ⾮非商业性效能 更更少的部署痛点

Slide 34

Slide 34

领导总是有更更好的⽅方法 ➤ 聪明的投资在技术和实践上，使我们的⼯作变的更好： ➤ ⼯作在：减少部署痛点⽅⾯ ➤ ⼯作在：降低精疲⼒尽/加班加点上 ➤ ⼯作在：提⾼NPS员⼯净推荐值上

Slide 35

Slide 35

在⾼高效能组织中⼯工作的雇员更更愿意 向周围的朋友推荐⾃自⼰己的组织

Slide 36

Slide 36

怎样开始？ 应⽤能⼒成长模型的套路

Slide 37

Slide 37

建议的套路路 ➤ 从度量少量的⼏个指标开始 ➤ 聚焦在成果产出型的、全局的指标上 ➤ 考量有哪些在你控制之内的事情，可以 推动的指标—不仅仅在技术⽅⾯，⽽且 还包括⾮技术⽅⾯ ➤ 分享你的成功案例！利⽤本地社群！

Slide 38

Slide 38

Slide 39

Slide 39

Slide 40

Slide 40

成熟度模型告诉我们 已经到达某个⽬目的地 可是整个世界从你身旁正呼啸⽽而过

Slide 41

Slide 41

成熟度模型告诉我们等 ⼀一旦到达了了某个等级 之前的专项资源投⼊入会即刻停⽌止

Slide 42

Slide 42

成熟度模型告诉我们 所有的⼈人都是遵循着 ⼀一模⼀一样的成功之旅

Slide 43

Slide 43

成熟度模型告诉我们 技术只是有待完成的检查清单 ⽽而不不是持续探索和改进的激动旅程

Slide 44

Slide 44

Jesse’s Rule: Don’t Fight Stupid, Make More Awesome

Slide 45

Slide 45

感谢聆听！ ➤ E-mail：[email protected] ➤ 微信：martinliu_cn ➤ Twitter: @martinliu ➤ Blog: https://martinliu.cn ➤ Facebook： https://www.facebook.com/groups/devops.handbook/ ⼤家来找茬，求勘误。 DevOps教练 微信公众号