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是各种技术实践的⼤融合
持续交付的驱动⼒力力 — 持续交付的影响地图
架构很关键 ⽽不是技术
架构的产出很关键 ➤ 团队能否: ★ 变更系统的设计 ★ 测试系统 ★ 部署系统 ★ ⽽不依赖与外部⼈进⾏沟通和协作
每个开发者,每天的部署次数 部署频率 ⾼高等效能 随着开发者⼈数急剧提⾼ 中等效能 维持在⼀个基本恒定的频率 低等效能 随着开发者⼈数急剧下降 开发⼈员数量
“ 任何组织在设计⼀套系统时,所交付的设计⽅案在 结构上都与该组织的沟通结构保持⼀致。 -梅尔.康威
软件管理理实践和 产品开发很关键 两⼿抓,两⼿都要硬
精益管理理实践的影响地图 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教练 微信公众号
The following resources were mentioned during the presentation or are useful additional information.
在不确定、迅速变化的DevOps时代里,一刀切的模型和标准都将死去!