没有度量就没有管理—洞察DevOps能力成长模型
A presentation at DevOpsDays Taipei 2018 in in Taipei, Taiwan by Martin Liu 刘征
没有度量量就没有管理理 洞察DevOps能⼒成长模型 1
中国DevOps社区组织者 刘征 Martin Liu Ops背景 云计算 ⼯具链
Fortune 500 company 数字化颠覆将在10年年内抹掉40%的公司 ➤ 在下⼀个10年⾥，S&P500的公司⼀半会被新 的公司替换 ➤ 奥地利经济学家约瑟夫·熊彼特：创新性破坏
加速度 业务⼀如既往等于⽇落西⼭
⾯面向度量量指标的管理理⽅方式？ ➤ Dev的考核指标是什么？ ➤ QA的考核指标是什么？ ➤ Ops的考核指标是什么？ ➤ 追求确定的、绝对的数值的管理⽅法对么？ ➤ 考核什么指标，就会得到什么指标？ ➤ 企业绩效的考核指标是什么？
⾼高效能组织都能够达成⽬目标 2x+ 三年⾥市场总值 增长超过50% 商业⽬标 ⾮商业⽬标 ➤ ⽣产率 ➤ 产品或服务的质量 ➤ 利润率 ➤ 运营效率 ➤ 市场份额 ➤ 客户满意度 ➤ ⽤户数 ➤ 产品或服务的数量 ➤ 达成组织的使命和⽬标
度量量管理理的常⻅见错误 ➤ 低层级的⼯作输出 > 全局的成果 ➤ ➤ Outputs > Outcomes 局部/个体 > 全局/团队 ➤ Global / team > locale / individual
常⻅见错误1：代码⾏行行数 Line of code ➤ ➤ 越多越好？ ★ 更臃肿的软件 ★ 更⾼的维护成本 ★ 更⾼的变更成本 越少越好？ ★ ➤ ⽞妙莫测且⽆法理解的代码 理想的：⽤最有效的代码解决业务问题
常⻅见错误2： 速率 Velocity ➤ Agile：问题被拆分成故事，评估完成这些⼯作的点数 ➤ 在冲刺结束的时候，由客户签收的点数被记录下来 = 速率 ➤ Velocity 速率是 产能计划 ⼯具。⽽不是 ⽣产效率⼯具 ➤ 为什么速率不能作为⽣产效率使⽤？ ★ 速率只是⼀个相对的度量，⽽⾮绝对的。因此，很不 适合⽤于团队间的⽐较 ★ 点数评估被夸⼤，被博弈 ★ 聚焦在团队的完成度，通常牺牲了团队间的协作（这 是⼀个全局⽬标）
常⻅见错误3：利利⽤用率 Utilization ➤ 利⽤率仅仅在某个点上/程度上是好的 ➤ 利⽤率越⾼越好么？ ★ 在⾼利⽤率下，我们失去了⽤于⾮计划⼯ 作的可⽀配的时段 ★ 排队理论：在利⽤率达到100%的时候， 前置时间接近于⽆穷⼤ ★ 当你们的利⽤率越来越⾼的时候，所有团 队将花费越来越长的时间完成任何的⼯作
DevOps能⼒力力成⻓长模型-2017年年版 DORA - Dr Nicole Forsgren, CEO and Chief Scientist &
Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations Link: http://a.co/eo5FyQj
四年年的DevOps⾏行行业状态调查研究
2018年年DevOps状态报告是怎样的？
2018报告的核⼼心发现？ ➤ SDO效能解锁竞争优势 ➤ 如何实施云基础设施很关键 ➤ 应⽤开业软件可以提⾼效能 ➤ 精英团队⼏乎不使⽤有损于效能的职能外 包模式 ➤ 关键技术实践驱动⾼效能 ➤ 实现⾼效能的软件交付和⾏业⽆关
效能指标模型有所扩展 吞吐量 稳定性
⾼高效能是怎么 炼成的？ 成熟度是已经过时的模型
DevOps能⼒力力成⻓长模型有什什么优势？ ➤ 适⽤于本来能⼒和起点就参差不齐的不同团队 ➤ 符合每个团队的优劣势和业务上下⽂的不同 ➤ 每个团队聚焦在不同的、各⾃的约束点/弱点上 ➤ 根据⾏业基线设置下⼀步的⽬标 能⼒ 模型
技术实践很关键 DevOps是各种技术实践的⼤融合
持续交付的驱动⼒力力 — 持续交付的影响地图
- 版本控制 2. ⾃自动化部署 3. 持续集成 4. 主⼲干开发 5. ⾃自动化测试 6. 测试数据管理理 7. 模式化安全管理理 8. 松耦合架构 9. 赋能团队 10. 监控 11. 前瞻性预警通知 Westrum企业⽂文化 持续交付 更更少的返⼯工 软件交付效能 个⼈人的认同 组织的效能
架构很关键 ⽽不是技术
架构的产出很关键 ➤ 团队能否： ★ 变更系统的设计 ★ 测试系统 ★ 部署系统 ★ ⽽不依赖与外部⼈进⾏沟通和协作
每个开发者，每天的部署次数 部署频率 ⾼高等效能 随着开发者⼈数急剧提⾼ 中等效能 维持在⼀个基本恒定的频率 低等效能 随着开发者⼈数急剧下降 开发⼈员数量
“ 任何组织在设计⼀套系统时，所交付的设计⽅案在 结构上都与该组织的沟通结构保持⼀致。 -梅尔.康威
软件管理理实践和 产品开发很关键 两⼿抓，两⼿都要硬
精益管理理实践的影响地图 Westrum企业⽂文化 精益管理理 限制在制品（WIP） 可视化管理理 ⽣生产环境的反馈 轻量量的变更更管理理 软件交付效能 更更少的加班加点
精益产品管理理的影响地图 Westrum企业⽂文化 精益产品管理理 ⼩小批量量⼯工作 使⼯工作流可视化 收集和实施客户反馈 进⾏行行团队实验 软件交付效能 更更少的加班加点 组织的效能
领导⼒力力很关键 组织转型领导⼒
领导⼒力力转型的5个维度
转型领导⼒力力和效能之间的关系 转型领导⼒力力 个体认同 ⽀支持型领导 智⼒力力激发 ⿎鼓舞型沟通 愿景 组织的效能 精益产品管理理 团队进⾏行行试验 ⼩小批量量⼯工作 收集和实施客户反馈 测和部署⾃自动化 持续集成 主⼲干开发 前置安全管理理 松耦合架构 赋能团队 IT效能 2016 持续交付 ⾮非商业性效能 更更少的部署痛点
领导总是有更更好的⽅方法 ➤ 聪明的投资在技术和实践上，使我们的⼯作变的更好： ➤ ⼯作在：减少部署痛点⽅⾯ ➤ ⼯作在：降低精疲⼒尽/加班加点上 ➤ ⼯作在：提⾼NPS员⼯净推荐值上
在⾼高效能组织中⼯工作的雇员更更愿意 向周围的朋友推荐⾃自⼰己的组织
怎样开始？ 应⽤能⼒成长模型的套路
建议的套路路 ➤ 从度量少量的⼏个指标开始 ➤ 聚焦在成果产出型的、全局的指标上 ➤ 考量有哪些在你控制之内的事情，可以 推动的指标—不仅仅在技术⽅⾯，⽽且 还包括⾮技术⽅⾯ ➤ 分享你的成功案例！利⽤本地社群！
成熟度模型告诉我们 已经到达某个⽬目的地 可是整个世界从你身旁正呼啸⽽而过
成熟度模型告诉我们等 ⼀一旦到达了了某个等级 之前的专项资源投⼊入会即刻停⽌止
成熟度模型告诉我们 所有的⼈人都是遵循着 ⼀一模⼀一样的成功之旅
成熟度模型告诉我们 技术只是有待完成的检查清单 ⽽而不不是持续探索和改进的激动旅程
Jesse’s Rule: Don’t Fight Stupid, Make More Awesome
感谢聆听！ ➤ E-mail：[email protected] ➤ 微信：martinliu_cn ➤ Twitter: @martinliu ➤ Blog: https://martinliu.cn ➤ Facebook： https://www.facebook.com/groups/devops.handbook/ ⼤家来找茬，求勘误。 DevOps教练 微信公众号
- 在Nicole Forsgren 博士、Jez Humble 和 Gene Kim 联合创作的《Accelerate 》一书中，Nicole博士用科学的方法令人信服地揭示了高绩效IT组织的秘密。
- 本演讲将系统地解说 DevOps 能力构成模型的 24 个核心能力点和实践
- 分析各种DevOps核心能力之间的相互作用关系。
- 探讨传统上基于成熟度模型的弊病和危害性。
for free. You
can too.
Resources
The following resources were mentioned during the presentation or are useful additional information.
-
成熟度模型已死
在不确定、迅速变化的DevOps时代里，一刀切的模型和标准都将死去！
