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

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

书与作者介绍

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

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

作者介绍：

Dr. Nicole Forsgren是 DevOps研究和评估有限公司的首席科学家和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 企业峰会的主持人。

能力度胜于成熟度？

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

1. 产品和服务的交付；

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

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

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

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

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

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

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

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

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

关键能力与度量

所有组织都可以通过聚焦在能力度上进行持续改进。有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%。