扫码阅读
手机扫码阅读

DevOps需要哪些关键能力?新书预览《加速:精益软件和DevOps的科学》

355 2024-03-29

重磅新书《加速:精益软件和DevOps的科学:如何构建和扩展高效能的技术组织》(ACCELERATE - The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations)是Nicole Forsgren、Jez Humble以及Gene Kim合著的新作。


本文是该书读后感系列文章之一。

01

书与作者介绍

到底我们该怎样运用技术驱动商业价值呢?多年以来,我们一直听到有声音说,软件交付团队无关紧要,因为对公司来说,它无法提供有优势的竞争力。

《加速》(ACCELERATE)一书通过四年的研究,洞察了哪些能力和实践对加速软件交付息息相关,及其对公司价值的贡献,最终实现为你的团队和组织加速,并赢得市场!

作者介绍:

Dr. Nicole ForsgrenDevOps研究和评估有限公司的首席科学家和CEO。她是迄今为止,在DevOps大规模研究中最为知名的首席调查员。她也是一名专家和机械工程师,她的作品在同行评议的期刊中有过多次地发表。

Jez Humble曾合著过《DevOps操作指南》(The DevOps Handbook)、《精益企业》(Lean Enterprise)和 Jolt Award(软件产业的一个奖项)获奖作品《持续交付》(Continuous Delivery)。他最近正着手研究在 DevOps研究和评估有限公司怎样建立高效的团队。他也在伯克利加州大学执教。

Gene Kim是摘得多项奖项的首席技术员、研究员,也是《凤凰项目》(The Phoenix Project)、《DevOps操作指南》(The DevOps Handbook)以及《可视化运维指南》(The Visible Ops Handbook)的作者之一。他也是 IT Revolution的创始人和 DevOps 企业峰会的主持人。

02

能力度胜于成熟度?

日常运营已经不足以维持一家公司的竞争力。我们必须在以下方面进行加速:

  1. 产品和服务的交付

  2. 感知市场和理解客户的真实需要

  3. 应对对系统产生影响的合规和监管的变化

  4. 对潜在风险(如安全威胁)或经济变化的响应

这些加速的核心在于软件。技术与盈利的关联在不断加强。


根据波士顿大学的研究,对技术的策略性应用所带来的回报与生产力提升大于并购与创业:银行已经很难再通过躺在金库的金条获得收益,今天的制胜之道是更快、更安全地交易,并通过开发新的渠道和产品来赢取客户。

DevOps的能力与执行存在断层。我们必须学习如何准确地度量DevOps能力来向领导层沟通改善的结果。这将帮助领导层利用这些度量结果来决策并建立技术策略。

成功转型的关键之道是标准化这些度量,而且应该聚焦在能力度,而不是成熟度。

那么,为什么能力度是比成熟度更优的度量模型呢?

下面是能力度与成熟度的比较:

能力模型聚焦在帮助组织持续进步。认可技术和商业图景都在持续变化。最高效能的组织总是追求更优异,而不会止步。这是一个动态的过程。

成熟度模型聚焦在帮助组织“到达”某个成熟度状态,并声称达标。相对比较静态。


能力度模型强调灵活,允许组织中的不同部门采纳适合自己的方式进行改进,并聚焦在基于他们现有的场景和目标,能赋予他们最高回报的能力。
成熟度模型通常会遵循较统一的技术、实践和能力。


能力模型聚焦在关键成果和哪些能力能够驱动这些成果的达成。这将给技术领导层清晰的方向和为目标制定策略。

成熟度模型倾向于度量组织内对某些知识、技能的掌握程度,或者是某些工具的安装、使用情况,并不关注其带来的结果。这将无视这些变化对业务的实际影响。


能力模型更适合动态变化的环境,并允许团队聚焦在维持竞争力而拓展的技术与能力。

成熟度模型定义技术、流程和组织层面的静态水平。它们并不考虑技术与商业在持续变化的事实。

03

关键能力与度量

所有组织都可以通过聚焦在能力度上进行持续改进。有24个关键能力可以驱动软件交付效能的改进。本书作者发现这些能力适用于任何类型的组织,包括初创企业、政府,甚至是拥有大量遗留系统的巨兽企业。

为了改进和拓展这些能力,我们也需要度量效能。它要求我们要做到两点:

  1. 聚焦在成果(outcomes),而不是输出(outputs),人们不会仅仅因为忙碌而被嘉奖;

  2. 全局(global)度量,而不是局部(local)度量,确保团队间不会互相挖坑。

四大全局度量:

  1. 交付周期(Delivery Lead Time) - 从客户提起一个请求到该请求被满足所需要的时间;

  2. 部署频率(Deployment Frequency) - 1) 减小批量大小,从而缩短实施所需要的周期时间(Cycle Time),并更快地获得反馈;2)软件的批量是很难度量的,部署频率意味着软件部署到生产环境所需要的时间和频次;

  3. 服务恢复时间(Time to restore service) - 当有故障发生的时候,恢复服务所需要的时间;

  4. 变更失败率(Change Fail Rate) - 变更导致故障的比率。

各效能水平组织在这些度量的表现:

高效能组织:

  1. 交付周期 - 按需交付,每天部署多次;

  2. 部署频率 - 小于1小时;

  3. 服务恢复时间 - 小于1小时;

  4. 变更失败率 - 低于15%。

中等效能组织:

  1. 交付周期 - 每周一次或每月一次部署;

  2. 部署频率 - 一周至一个月;

  3. 服务恢复时间 - 小于1天;

  4. 变更失败率 - 低于15%。

低效能组织:

  1. 交付周期 - 每周一次或每月一次部署;

  2. 部署频率 - 一周至一个月;

  3. 服务恢复时间) - 一天到一周;

  4. 变更失败率 - 31%至45%。

书中提到的24种能力可以归纳成以下5大类:

  1. 持续交付能力

  2. 架构能力

  3. 产品和流程能力

  4. 精益管理和监控能力

  5. 文化能力

我将在后续的系列文章中逐一展开介绍,敬请留意。


部分内容翻译自Ariana Brighenti@HSBC的撰文。


原文链接: http://mp.weixin.qq.com/s?__biz=MzI1MjQ3NzE2Mw==&mid=2247484323&idx=1&sn=3cb164d804e59017a578d19cb3616608&chksm=e9e26826de95e130047f8922dfee3bcb020b92967e14c640f606b2eb#rd