背景

DevOps is everywhere，所有人都在说在做。DevOps转型的案例和故事很多，有些转型成功了，但也许失败的例子更多（虽然你没有机会听到他们出来分享了）。不同组织面临的情况和环境各不相同，其实很难简单的复制别人的成功。

我经常喜欢举的一个例子，学习DevOps有不同的方式，就像人类学习飞行时有鸟飞派和空气动力学派。人类的飞行梦想始于古老而又遥远的年代，但真正的飞行实践起源于仿鸟飞行，即给自己装上一对翅膀，学习鸟的扑翼动作而飞行，但大量长期的实践证明这样的尝试都是失败的。但还有另外一派，英国的科学家提出人造飞行器应该解决推进动力和升力等方面的问题，需要增强对空气动力学理论体系的基本认知，这使很多人放弃了单纯模仿鸟类飞行而逐渐接受和实践固定翼飞行器的设计思路，并最终由莱特兄弟发明了完全受控、可持续飞行的载人飞行器。

DevOps的实践和转型也是一样，我们很难照搬其他组织的成功，而是应该深入理解其背后的原理、原则和实践，从正确的方向入手。本文主要内容来自Jez Humble在Devon Summit上的演讲《Leading a DevOps Transformation》，重点介绍了DevOps转型的五个误区、五个实践，以及转型实施的具体建议。与之前的文章一样，我会结合我的经验和理解进行适当的内容扩展，而不仅限于演讲内容，核心还是希望帮助大家少走弯路、避免踩坑，能够更顺利的走向DevOps成功之路。

另外再介绍一下Jez Humble，作为DevOps领域里公认的世界级领军人物，他既是一位非常有影响力的软件研究人员，也是一位屡获殊荣的作家。他与其他作者合著的《持续交付》(Continuous Delivery) 一书曾获Jot大奖，是学习DevOps的必读书籍。Jez的其他畅销书包括《精益企业》(LeanEnterprise)，以及DevOps Handbook，其中文译本《DevOps实践指南》将于5月5日在DevOpsDays北京站首发，大神Jez Humble也会来华与大家面对面畅谈DevOps！

DevOps能够帮助我们什么

传统软件交付方式的问题大家都清楚，比如很长的交付周期、很差的应变能力和低效的价值交付。所有很多组织进行了敏捷转型，但敏捷转型的历程可能也并不是一帆风顺。以开发为代表的工程师部门使用敏捷的方式运作，从瀑布转向了Scrum快速迭代，并引入了TDD，做好了架构解耦，工作非常开心。

但组织里的其他部门也许就不是这样想的了。比如运维团队，原来一年做好几次发布就可以了，现在随时有上线包扔过来，随时都需要准备发布，这个实在太可怕了。遇到这样的问题，很自然的反应是建立起一个屏障，比如”变更管理流程”，而这个流程的职责就是限制变更。

DevOps的出现就是为了解决这样的问题，可能很多人对DevOps的理解都不同，也可能并没有一个统一的定义。但这并没有关系，我们可以从DevOps的起源来思考。DevOps运动始于社区，一些人试图解决某些从未被解决的问题：如何构建大规模、分布式、可靠、安全的系统，并且可以在持续、快速变更的情况下，让系统一直保持安全和可靠。

在过去的五年时间中，通过对很多高效能企业的调研，可以发现投资于DevOps实践所取得的众多好处，首当其冲的就是软件交付会对业务发展产生重大的影响，高效能企业有两倍于其他企业的概率达到其利润率、市场占有率、生产效率等业务目标。

接下来，我们从统计学的角度来分析IT效能，这里设计了两大类四个指标。分别是度量吞吐量的指标（部署频率、变更前置时间），以及度量稳定性的指标（MTTR、变更失败率）。这些数据来自每年的DevOps现状调查报告，我在去年也进行过多次线上、线下解读和分享，这里暂不展开说明。但值得再次强调的是，从统计结果上来看，高效能的企业可以在吞吐量和稳定性方面兼得，而不是传统意义上的为了提升效率而牺牲质量，或者为了质量而牺牲效率。

之前Facebook有句格言是”Move fast and break things”，意思是公司应该快速行动、打破陈规。但我觉得可以改成”Move fast and don’t break things“，即快速交付的同时必须要确保质量和安全性，这正是DevOps可以赋予给我们的能力。

DevOps转型的五个误区

Jez Humble提出了DevOps转型的五个误区：

下面我们来详细分析一下：

误区一：放弃现有的系统管理员、测试人员，招聘新的DevOps专家

不得不说，这绝对是一个糟糕的想法，建议不要这样做。从经验来看，招聘新的DevOps专家是一件很困难的事情，我身边的一些朋友都在寻找这样的人才，但其实很难找到完美的人选。因为DevOps工程师或专家不是直接能够培训出来的，也没有一所大学教授DevOps的课程，这些有经验的人都是在工作中不断遇到和解决问题的过程中逐渐成长起来的。

所以问题的关键在于，如何建立一个组织环境，让员工可以在工作中学习，他们不会被刻意地限制在各自的角色中，而是被鼓励在解决问题的过程中不断学习新技能，并为整个组织服务。

误区二：进行大规模组织结构重组（Re-Org）

有的组织转型很干脆，一上来就进行大规模的组织结构重组。但经验告诉我们，组织结构重组是非常容易引起混乱的活动，组织通常会消耗数月时间和巨大的能量，员工需要重新熟悉新的组织结构和工作方式，这对组织生产力的打击是非常大的。

值得注意的是，我们并不是说不需要对组织进行改进。我们都知道，跨职能团队（比如面向服务或特性）会比按职能切分的团队具有更高的生产力，所以建立跨职能团队本身是非常有效的。但这里观点是Re-Org并不是唯一的选择。我们也可以用其他方式达到这个目标，比如让这些不同角色的人员物理地聚在一起；或者下游职能团队通过自动化的自服务平台，把他们的能力赋予给上游的团队使用（见下图）。很多让人敬佩的DevOps组织也没有完全形成跨职能团队（如Etsy，Google和GitHub），但他们的生产率同样非常高。

误区三：重新编写你的应用并迁移到云上

DevOps现状调查报告中也显示，DevOps适用于各种场景，包括Mainframe主机系统和商业套装软件（COTS）。

在我的上一篇文章 [ ttps://mp.weixin.qq.com/s?__biz=MzU1MjAzNjE4NA==&mid=2247483851&idx=1&sn=68243e2b0a49f1755c4cd077911721d3&chksm=fb8973fcccfefaea3fe5355d15613b9bec82cfb0b775ded48594b325de2e4168ed58f912cdd7&scene=21#wechat_redirect]DevOps听起来不错，但适合你的企业么[/url] ，我讲到了在大型嵌入式软件、保险公司的大型机系统上进行持续交付的案例。除此之外，在《DevOps Handbook》中也提到在传统的POS机上，采用蓝绿部署进行快速和低风险发布的例子。

所以，你不用等待漫长的应用重建并迁移到云上，而是可以在现有系统和组织环境中使用DevOps的思路进行逐步改进，最好的转型启动时间点就是现在！

误区四：购买一揽子DevOps工具

DevOps发展到今天，已经出现了非常多的支撑工具。我们认可好的工具可以对DevOps的实施提供出非常强有力的支持，但我们的观点是：如果仅仅是购买工具，无法真正帮助你解决问题。

Jez Humble与Dave Farley在2005~2006年进行持续交付的工作时，并没有上图中展示的如此众多的工具，很多自动化的工作都是由Bash脚本完成的，但也同样获得了非常显著的效果。问题的关键在于你如何解决问题，而不是具体应用哪一款的工具。如果组织仅仅是购买工具而不改变工作流程，这样不会改变任何事情。

我就曾经见过有人把Jira用成了管控型的传统项目管理工具，把Jenkins用成了批处理任务的手动触发器，只有工具而没有方法和实践的改变，是无法走上DevOps成功之路的。

误区五：给开发生产环境的完全访问权限

有人说DevOps就是让开发自己进行发布，所以需要给开发所有生产环境的权限。我们认为这是一种可怕的想法。理想情况下，任何人都不应该有生产环境的权限，所有生产环境的部署应该由人工触发后，只通过自动化的方式进行。

只有在特殊的场景下，比如需要在生产环境进行诊断时，才可以允许有人登陆到生产环境。但这种情况下仍然需要特别小心，比如使用一次性的登陆口令，并将任何操作日志都记录下来并发送给系统管理员。

DevOps转型的五个实践

以上介绍了DevOps转型的五个误区，那么正确的转型打开方式是怎样的呢？我们总结为以下五个实践。

实践一：习惯小批量的方式工作（开发、架构、组织文化的演进）

持久的变革需要以小批量、持续的方式进行，通过反复实验、根据反馈循环快速学习，找到最正确的实施路径。这样需要把大的问题拆成一系列小的问题逐个、渐进式解决，也许这样没有Big Bang式的变革令人激动，但这才是让我们成功的正确姿势。

1. 找到最重要的工作

最经典的例子就是项目管理，传统上按半年或一年规划并申请预算，这驱使我们工作在大型复杂项目上，大量时间花在特性在待办清单（Backlog）中等待被分析、估算、批准和排优先级等事务性工作上。一份称为”黑天鹅农场”的白皮书显示，他们分析了3000个待办清单中等待开发的不同需求，使用延迟成本（如果不做这个需求，每周损失的成本）的优先级决策方式。

他们发现，在待办清单中有三个特性，如果不交付这些特性，每个特性每周给组织带来200万美金的损失。这几个特性隐藏在庞大的待办清单中，但确实极为关键的。他们意识到应当停掉手头所有工作，以最快的速度交付这三个特性。从统计数据上看，这种情况符合幂律分布，如下图所示。

所以我们的工作就是要在多个项目中间，找到那些真正重要的，这需要更加透明、更加清晰的优先级，以及组织中每个人的协作。

2. 架构的持续演进

很普遍的情况是，很多组织拥有大量的遗留系统，一些软件或硬件过于老旧，可能厂商已经不再支持了，有些组织的个别系统甚至没有源代码（可能在乙方手中或已丢失）。这类组织通常选择通过长达一两年的架构再造解决问题，而当进行到一年的时候，他们可能会说，系统复杂度实在太高，我们还需要额外的两年！我本人就亲历过这样的超大型项目，最后负责的CTO都换人了，项目还没做完。

以上描述的场景，关键的问题是，大家的关注点常常在架构的技术层面而不是需要达到的结果上。调查数据显示，如果以下问题的回答都是Yes，那么你更有可能做好持续交付和DevOps，成为高效能IT组织：

• 是否无需团队外的某人或其他团队授权就可以进行自身系统大范围的设计变更？
  
  

• 是否无需与团队外的其他人员进行细粒度的沟通就可以完成自身的工作？
  
  

• 是否可以独立于其他依赖的服务或产品，按需部署和发布自身的产品或服务？
  
  

• 是否无需依赖复杂的集成测试环境，就可以按需进行大多数自身系统的测试？
  
  

• 是否可以在日常业务时段，执行无停机的部署？
  
  

你可以在老旧的遗留系统上实现以上全部这些效果，但也可能在充满高科技、新技术的情况下，无法达到以上效果的任意一条。所以我们要关注的是架构演进的结果，而不仅仅是使用炫酷的技术。

关于演进式架构的更多内容，以及绞杀者模式的思路，我之前的文章也有介绍，其主要原则如下：

• 从交付业务所需的新功能开始（至少在初期是这样），新功能使用面向服务的设计
  
  

• 不要重写已有的功能，除非能够使它持续简化
  
  

• 通过不断拆分，更快的进行交付
  
  

• 为可测试性和可部署性进行设计
  
  

• 新的架构运行在PaaS平台上
  
  
  

3. 组织文化的持续演进

组织和文化的变革同样应用使用持续演进的方式。在组织中有各种各样的员工，有些人对新方法和新技术非常感兴趣，有些人则偏于保守，不愿意尝试进行改变。

你不能一刀切地进行整个组织的变革，应该从最赞同DevOps的理念、方法和技术的人群开始。接受一个新想法，需要跨越鸿沟。我们先找到认同DevOps原则和实践的团队，聚焦在有一定风险承受能力的小组上，快速做出转型的标杆效果，打好基础、给人信心。我们不需要在早期花费大量时间用于转化保守的人群，而最重要的是先要把第一枪打响。

实践二：创建反馈循环

在小批量工作的基础上，我们要建立起反馈循环。反馈循环让我们能够持续学习，基于学习进行持续改进，这也是敏捷和学习型组织的关键原则。

持续交付流水线就是反馈循环的具体实现，可以提供多个层次、多个链路的反馈信息，并且可以在反馈效率和反馈完整性之间取得平衡。

以下是去年我与朋友合作的全开源持续交付流水线的设计图和效果图，充分体现了流水线的递次晋级和反馈循环的原则。

全开源流水线只能满足中小企业的需求，在大型企业中的流水线设计和实现更为复杂，我后面找时间再跟大家单独介绍。

实践三：通过价值流进行跨职能协作

需求、开发、测试、信息安全、运维等角色需要在软件交付价值流中协同工作。价值流图是促进跨职能协作的关键工具。我们可以通过开展价值流梳理的Workshop，识别支撑价值流的各种角色以及角色之间的协作关系。我们不需要文档化价值流中每一步的细枝末节，而是理解价值是如何传递的，各角色是如何协同工作的。

另外，这里还要强调跨职能协作时的质量管控部分。不仅仅是自动化测试，还要关注持续测试、持续安全检查，让这些活动在日常工作中反复进行，做到内建质量。

实践四：建立实验的组织文化

调查表明，组织文化是可以被度量的，而且组织文化对IT效能和组织绩效都有可度量的影响。我们使用Westrum模型来度量组织文化。该模型中有三种类型：

• 病态型组织（Pathological）的特征是存在大量恐惧和威胁。人们通常处于政治因素而隐藏或者压制信息，甚至为了让自己表面上看起来更好而扭曲事实。
  
  

• 官僚型组织（Bureaucratic）的特征是各部门自保。每个部门都想维护自己的一亩三分地儿，坚持自己的规则，通常会依照自己的章程按部就班地行事。
  
  

• 生机型组织（Generative）专注于自身的使命以及如何达到目标。任何因素都要让位于高绩效，团队间高度合作、风险共担、鼓励联结。面对失败时需要尝试发现系统中的问题根因，而不是寻找替罪羊或相互推诿。
  
  
  

根据统计结果发现，一个高度信任的生机型文化不仅对创造一个安全的工作环境非常重要，更是打造高绩效组织的基础。

以上模型不仅停留在理论层面，更可以应用在实践领域。

案例一. Google的灾难恢复测试

Google在几年之前进行过一项研究，如何打造一个优秀的团队。他们调研了来自180个Google团队的200位受访者，观察了超过250项不同的因素，比如团队中有人取得博士学位、有性格外向的人，有人着迷于AngularJS等等。但他们最终发现打造高效能IT组织，排在第一位的因素是：心理上的安全感，即可以在团队中承担风险而不会感到不安全或者受到伤害。

我们需要构建一个安全的环境，让失败是可以接受的，并且作为组织学习的基础。Google和Amazon都会在线上进行灾难恢复测试，确保在发生严重故障时，故障恢复策略真正有效，系统仍然可以正常运转。

Google有一整个团队专注于计划和实施灾难恢复测试，甚至有一年模拟外星人侵入硅谷的场景，他们断开山景城与外界的光缆连接、关闭数据中心并对基础设施施加真实的影响，但要求团队必须要维护服务级别目标。他们设计的灾难恢复测试，需要由来自很多不同组、平时不在一起工作的工程师相互协作，那么在大规模灾难真正来临的时候，他们已经建立起了很强的工作关系。

案例二. Etsy的”三只袖毛衣”奖励

Etsy每年举办开发者大会，会发给过去一年中生产环境最大中断的制造者一件”三只袖毛衣”作为奖励。那么为什么奖励是三只袖毛衣呢？因为Etsy的404页面中有一张三只袖毛衣的图片。

图中这位身穿毛衣的同学就是Etsy去年最大故障的制造者Ryn，她把故障的过程记录在了博客中，包括何时、什么原因造成了生产环境中断。发生故障时，她马上在Slack上寻求帮助，然后立即得到了身边很多人的回复，然后他们一起蜂拥而上快速解决了问题。之后，他们开展了免责的事后故障分析会议，并给出了防止再次失败、优化系统的具体措施。Ryn也因此获得去年的奖励，因为她促进了组织学习，让系统的恢复能力变得更强。

案例三. Netflix的Chaos Monkey和Simian Army

Netflix的这个工具不断在生产环境上制造破坏，验证系统是否具备良好的恢复能力，并帮助工程师构建更加健壮的系统。

实践五：持续消除浪费，优化价值流

DevOps需要持续改进，移除浪费，让价值流动变得更加顺畅。我近期辅导了一些团队使用价值流图的方式进行流程和问题梳理，发现这的确对组织认知和优化现有软件交付过程非常有帮助。

我们可以邀请来自产品、开发、测试、运维、安全等不同部门的Leader参加价值流梳理活动，其实最难的部分是让这些人在同一时间聚在一间会议室中。我们逐个梳理从需求提出到编码、测试验证再到部署、发布的过程，过程中会发现大家的认知并不一致，尤其是对前置时间、等待时间和C/A%（完整且准确比例）的估算。

让所有人达成对整个价值流的理解和认知非常重要，但更重要的是确定未来如何改进的具体措施和预期目标。在不同的角色对目标达成一致意见的基础上，定期（如一个月）进行回顾和持续的改进。在改进的过程中，并不是事无巨细的告诉团队具体如何开展工作，而是明确目标并让团队深度参与、自主思考，通过不断实验和学习想办法达到目标。（这映射了我们之前提到的误区一）

DevOps转型实施的具体建议

在过去五年对高效能企业的研究中，总结出了DevOps转型的关键能力要素，如下图所示。图中共有四大领域，分别是软件开发实践、精益产品开发、精益管理、变革领导力，这些领域又细化出了20多个能力项。这些能力项的建设可以作为DevOps转型实施的主要参照系，强烈推荐大家持续关注。

DevOps的转型并不简单，想要走上成功之路，这里还有几个Tips：

• 对可度量的业务目标达成一致。制定”跳一跳可以达到”的目标，比如减少10%严重缺陷数、提升20%服务可用时长、达到2倍的发布频率，或者其他混合的结果指标。
  
  
  
  

• 给团队资源进行实验并对学习进行激励。团队无法在日常工作照旧的前提下，”加班”进行改进的探索。改进是要有真实工作量投入的，这应当与开发新功能、修复缺陷以同样的方式进行优先级排序。具体来讲，可以使用看板管理WIP，指派专职的团队全职做改进工作，或者每周给团队一个特定时间用于做改进工作。
  
  
  
  

• 与其他团队沟通，鼓励协作。很多人经常提及合规、安全、治理等团队，认为他们是改进的阻碍。但其实如果与这些团队进行友好的沟通，你可能会发现他们非常期望讨论获得双赢的具体措施。
  
  
  
  

• 取得速赢。你需要在一到两个月做出改进的效果。具体来讲有三个关键点：首先，通过价值流图或约束理论，找到一个影响最大的、并且可以快速解决和可被度量效果的问题；其次，限制首次进行改进的范围，最小化改进工作；然后，与对改进有兴趣并有充足容量和能力的团队合作，取得速赢。
  
  
  
  

• 分享成功经验。为了获得其他人的支持，你需要做好成功经验的宣传工作，吸引更多的人加入到改进工作中来。比如有的企业组织内部的DevOpsDays大会，跨部门进行经验的推广，这非常有效。另外午餐学习会、内部博客、邮件列表、Slack或HipChat频道都是获得参与者最好的渠道。还要对其他尝试的人提供帮助，就像DevOps教练应该做的工作那样。
  
  
  
  

• 持续改进。高效能的组织永远追求改进的机会。就像丰田管理系统的缔造者大野耐一所说的：”Kaizen [improvement] opportunities are infinite”，改进的机会是无穷无尽的。百度集团总裁兼COO陆奇在去年的一次演讲中也讲过：”Engineering Excellence 是一个永无止境的、个人的、团队的，能力的追求和工具平台的创新，综合在一起可以带给我们带来的长期的、核心的竞争力”。Relentless pursuit of excellence，这是我们应该坚持的态度。
  
  
  
  
  

总结

今天我们从鸟飞派和空气动力学派的类比说起，DevOps的转型不能照搬其他组织的实施过程，而是应该深入理解其背后的原理、原则和实践。

我们分别介绍了DevOps转型的五个误区、五个实践，以及转型实施的具体建议。

• 五个误区。放弃现有人员而招聘新的DevOps专家、进行大规模组织结构重组、重新编写应用并上云、购买一揽子DevOps工具、给开发生产环境完全访问权限；
  
  

• 五个实践。习惯小批量的工作方式（开发、架构、组织文化的演进）、创建反馈循环（流水线建设）、通过价值流进行跨职能协作、建立实验的组织文化、持续消除浪费并优化价值流；
  
  

• 转型实施具体建议。关注DevOps转型的关键能力要素，对可度量的业务目标达成一致、给团队资源进行实验并对学习进行激励、与其他团队沟通并鼓励协作、取得速赢、分享成功经验、持续改进。
  
  
  

以上这些内容都是在很多企业中总结出来，是被证明过的、对提升组织效能最有效的方式。我们的目标是快速的发布、更高的可靠性、更好的恢复能力和更安全的系统，以及更人性化、持续改进和自我增强的组织。

希望本文能对你的DevOps转型提供一点点光亮，也祝你早日走上DevOps成功之路！

原创：张乐

背景

DevOps is everywhere，所有人都在说在做。DevOps转型的案例和故事很多，有些转型成功了，但也许失败的例子更多（虽然你没有机会听到他们出来分享了）。不同组织面临的情况和环境各不相同，其实很难简单的复制别人的成功。

我经常喜欢举的一个例子，学习DevOps有不同的方式，就像人类学习飞行时有鸟飞派和空气动力学派。人类的飞行梦想始于古老而又遥远的年代，但真正的飞行实践起源于仿鸟飞行，即给自己装上一对翅膀，学习鸟的扑翼动作而飞行，但大量长期的实践证明这样的尝试都是失败的。但还有另外一派，英国的科学家提出人造飞行器应该解决推进动力和升力等方面的问题，需要增强对空气动力学理论体系的基本认知，这使很多人放弃了单纯模仿鸟类飞行而逐渐接受和实践固定翼飞行器的设计思路，并最终由莱特兄弟发明了完全受控、可持续飞行的载人飞行器。

DevOps的实践和转型也是一样，我们很难照搬其他组织的成功，而是应该深入理解其背后的原理、原则和实践，从正确的方向入手。本文主要内容来自Jez Humble在Devon Summit上的演讲《Leading a DevOps Transformation》，重点介绍了DevOps转型的五个误区、五个实践，以及转型实施的具体建议。与之前的文章一样，我会结合我的经验和理解进行适当的内容扩展，而不仅限于演讲内容，核心还是希望帮助大家少走弯路、避免踩坑，能够更顺利的走向DevOps成功之路。

另外再介绍一下Jez Humble，作为DevOps领域里公认的世界级领军人物，他既是一位非常有影响力的软件研究人员，也是一位屡获殊荣的作家。他与其他作者合著的《持续交付》(Continuous Delivery) 一书曾获Jot大奖，是学习DevOps的必读书籍。Jez的其他畅销书包括《精益企业》(LeanEnterprise)，以及DevOps Handbook，其中文译本《DevOps实践指南》将于5月5日在DevOpsDays北京站首发，大神Jez Humble也会来华与大家面对面畅谈DevOps！

DevOps能够帮助我们什么

传统软件交付方式的问题大家都清楚，比如很长的交付周期、很差的应变能力和低效的价值交付。所有很多组织进行了敏捷转型，但敏捷转型的历程可能也并不是一帆风顺。以开发为代表的工程师部门使用敏捷的方式运作，从瀑布转向了Scrum快速迭代，并引入了TDD，做好了架构解耦，工作非常开心。

但组织里的其他部门也许就不是这样想的了。比如运维团队，原来一年做好几次发布就可以了，现在随时有上线包扔过来，随时都需要准备发布，这个实在太可怕了。遇到这样的问题，很自然的反应是建立起一个屏障，比如”变更管理流程”，而这个流程的职责就是限制变更。

DevOps的出现就是为了解决这样的问题，可能很多人对DevOps的理解都不同，也可能并没有一个统一的定义。但这并没有关系，我们可以从DevOps的起源来思考。DevOps运动始于社区，一些人试图解决某些从未被解决的问题：如何构建大规模、分布式、可靠、安全的系统，并且可以在持续、快速变更的情况下，让系统一直保持安全和可靠。

在过去的五年时间中，通过对很多高效能企业的调研，可以发现投资于DevOps实践所取得的众多好处，首当其冲的就是软件交付会对业务发展产生重大的影响，高效能企业有两倍于其他企业的概率达到其利润率、市场占有率、生产效率等业务目标。

接下来，我们从统计学的角度来分析IT效能，这里设计了两大类四个指标。分别是度量吞吐量的指标（部署频率、变更前置时间），以及度量稳定性的指标（MTTR、变更失败率）。这些数据来自每年的DevOps现状调查报告，我在去年也进行过多次线上、线下解读和分享，这里暂不展开说明。但值得再次强调的是，从统计结果上来看，高效能的企业可以在吞吐量和稳定性方面兼得，而不是传统意义上的为了提升效率而牺牲质量，或者为了质量而牺牲效率。

之前Facebook有句格言是”Move fast and break things”，意思是公司应该快速行动、打破陈规。但我觉得可以改成”Move fast and don’t break things“，即快速交付的同时必须要确保质量和安全性，这正是DevOps可以赋予给我们的能力。

DevOps转型的五个误区

Jez Humble提出了DevOps转型的五个误区：

下面我们来详细分析一下：

误区一：放弃现有的系统管理员、测试人员，招聘新的DevOps专家

不得不说，这绝对是一个糟糕的想法，建议不要这样做。从经验来看，招聘新的DevOps专家是一件很困难的事情，我身边的一些朋友都在寻找这样的人才，但其实很难找到完美的人选。因为DevOps工程师或专家不是直接能够培训出来的，也没有一所大学教授DevOps的课程，这些有经验的人都是在工作中不断遇到和解决问题的过程中逐渐成长起来的。

所以问题的关键在于，如何建立一个组织环境，让员工可以在工作中学习，他们不会被刻意地限制在各自的角色中，而是被鼓励在解决问题的过程中不断学习新技能，并为整个组织服务。

误区二：进行大规模组织结构重组（Re-Org）

有的组织转型很干脆，一上来就进行大规模的组织结构重组。但经验告诉我们，组织结构重组是非常容易引起混乱的活动，组织通常会消耗数月时间和巨大的能量，员工需要重新熟悉新的组织结构和工作方式，这对组织生产力的打击是非常大的。

值得注意的是，我们并不是说不需要对组织进行改进。我们都知道，跨职能团队（比如面向服务或特性）会比按职能切分的团队具有更高的生产力，所以建立跨职能团队本身是非常有效的。但这里观点是Re-Org并不是唯一的选择。我们也可以用其他方式达到这个目标，比如让这些不同角色的人员物理地聚在一起；或者下游职能团队通过自动化的自服务平台，把他们的能力赋予给上游的团队使用（见下图）。很多让人敬佩的DevOps组织也没有完全形成跨职能团队（如Etsy，Google和GitHub），但他们的生产率同样非常高。

误区三：重新编写你的应用并迁移到云上

DevOps现状调查报告中也显示，DevOps适用于各种场景，包括Mainframe主机系统和商业套装软件（COTS）。

在我的上一篇文章 [ ttps://mp.weixin.qq.com/s?__biz=MzU1MjAzNjE4NA==&mid=2247483851&idx=1&sn=68243e2b0a49f1755c4cd077911721d3&chksm=fb8973fcccfefaea3fe5355d15613b9bec82cfb0b775ded48594b325de2e4168ed58f912cdd7&scene=21#wechat_redirect]DevOps听起来不错，但适合你的企业么[/url] ，我讲到了在大型嵌入式软件、保险公司的大型机系统上进行持续交付的案例。除此之外，在《DevOps Handbook》中也提到在传统的POS机上，采用蓝绿部署进行快速和低风险发布的例子。

所以，你不用等待漫长的应用重建并迁移到云上，而是可以在现有系统和组织环境中使用DevOps的思路进行逐步改进，最好的转型启动时间点就是现在！

误区四：购买一揽子DevOps工具

DevOps发展到今天，已经出现了非常多的支撑工具。我们认可好的工具可以对DevOps的实施提供出非常强有力的支持，但我们的观点是：如果仅仅是购买工具，无法真正帮助你解决问题。

Jez Humble与Dave Farley在2005~2006年进行持续交付的工作时，并没有上图中展示的如此众多的工具，很多自动化的工作都是由Bash脚本完成的，但也同样获得了非常显著的效果。问题的关键在于你如何解决问题，而不是具体应用哪一款的工具。如果组织仅仅是购买工具而不改变工作流程，这样不会改变任何事情。

我就曾经见过有人把Jira用成了管控型的传统项目管理工具，把Jenkins用成了批处理任务的手动触发器，只有工具而没有方法和实践的改变，是无法走上DevOps成功之路的。

误区五：给开发生产环境的完全访问权限

有人说DevOps就是让开发自己进行发布，所以需要给开发所有生产环境的权限。我们认为这是一种可怕的想法。理想情况下，任何人都不应该有生产环境的权限，所有生产环境的部署应该由人工触发后，只通过自动化的方式进行。

只有在特殊的场景下，比如需要在生产环境进行诊断时，才可以允许有人登陆到生产环境。但这种情况下仍然需要特别小心，比如使用一次性的登陆口令，并将任何操作日志都记录下来并发送给系统管理员。

DevOps转型的五个实践

以上介绍了DevOps转型的五个误区，那么正确的转型打开方式是怎样的呢？我们总结为以下五个实践。

实践一：习惯小批量的方式工作（开发、架构、组织文化的演进）

持久的变革需要以小批量、持续的方式进行，通过反复实验、根据反馈循环快速学习，找到最正确的实施路径。这样需要把大的问题拆成一系列小的问题逐个、渐进式解决，也许这样没有Big Bang式的变革令人激动，但这才是让我们成功的正确姿势。

1. 找到最重要的工作

最经典的例子就是项目管理，传统上按半年或一年规划并申请预算，这驱使我们工作在大型复杂项目上，大量时间花在特性在待办清单（Backlog）中等待被分析、估算、批准和排优先级等事务性工作上。一份称为”黑天鹅农场”的白皮书显示，他们分析了3000个待办清单中等待开发的不同需求，使用延迟成本（如果不做这个需求，每周损失的成本）的优先级决策方式。

他们发现，在待办清单中有三个特性，如果不交付这些特性，每个特性每周给组织带来200万美金的损失。这几个特性隐藏在庞大的待办清单中，但确实极为关键的。他们意识到应当停掉手头所有工作，以最快的速度交付这三个特性。从统计数据上看，这种情况符合幂律分布，如下图所示。

所以我们的工作就是要在多个项目中间，找到那些真正重要的，这需要更加透明、更加清晰的优先级，以及组织中每个人的协作。

2. 架构的持续演进

很普遍的情况是，很多组织拥有大量的遗留系统，一些软件或硬件过于老旧，可能厂商已经不再支持了，有些组织的个别系统甚至没有源代码（可能在乙方手中或已丢失）。这类组织通常选择通过长达一两年的架构再造解决问题，而当进行到一年的时候，他们可能会说，系统复杂度实在太高，我们还需要额外的两年！我本人就亲历过这样的超大型项目，最后负责的CTO都换人了，项目还没做完。

以上描述的场景，关键的问题是，大家的关注点常常在架构的技术层面而不是需要达到的结果上。调查数据显示，如果以下问题的回答都是Yes，那么你更有可能做好持续交付和DevOps，成为高效能IT组织：

• 是否无需团队外的某人或其他团队授权就可以进行自身系统大范围的设计变更？
  
  

• 是否无需与团队外的其他人员进行细粒度的沟通就可以完成自身的工作？
  
  

• 是否可以独立于其他依赖的服务或产品，按需部署和发布自身的产品或服务？
  
  

• 是否无需依赖复杂的集成测试环境，就可以按需进行大多数自身系统的测试？
  
  

• 是否可以在日常业务时段，执行无停机的部署？
  
  

你可以在老旧的遗留系统上实现以上全部这些效果，但也可能在充满高科技、新技术的情况下，无法达到以上效果的任意一条。所以我们要关注的是架构演进的结果，而不仅仅是使用炫酷的技术。

关于演进式架构的更多内容，以及绞杀者模式的思路，我之前的文章也有介绍，其主要原则如下：

• 从交付业务所需的新功能开始（至少在初期是这样），新功能使用面向服务的设计
  
  

• 不要重写已有的功能，除非能够使它持续简化
  
  

• 通过不断拆分，更快的进行交付
  
  

• 为可测试性和可部署性进行设计
  
  

• 新的架构运行在PaaS平台上
  
  
  

3. 组织文化的持续演进

组织和文化的变革同样应用使用持续演进的方式。在组织中有各种各样的员工，有些人对新方法和新技术非常感兴趣，有些人则偏于保守，不愿意尝试进行改变。

你不能一刀切地进行整个组织的变革，应该从最赞同DevOps的理念、方法和技术的人群开始。接受一个新想法，需要跨越鸿沟。我们先找到认同DevOps原则和实践的团队，聚焦在有一定风险承受能力的小组上，快速做出转型的标杆效果，打好基础、给人信心。我们不需要在早期花费大量时间用于转化保守的人群，而最重要的是先要把第一枪打响。

实践二：创建反馈循环

在小批量工作的基础上，我们要建立起反馈循环。反馈循环让我们能够持续学习，基于学习进行持续改进，这也是敏捷和学习型组织的关键原则。

持续交付流水线就是反馈循环的具体实现，可以提供多个层次、多个链路的反馈信息，并且可以在反馈效率和反馈完整性之间取得平衡。

以下是去年我与朋友合作的全开源持续交付流水线的设计图和效果图，充分体现了流水线的递次晋级和反馈循环的原则。

全开源流水线只能满足中小企业的需求，在大型企业中的流水线设计和实现更为复杂，我后面找时间再跟大家单独介绍。

实践三：通过价值流进行跨职能协作

需求、开发、测试、信息安全、运维等角色需要在软件交付价值流中协同工作。价值流图是促进跨职能协作的关键工具。我们可以通过开展价值流梳理的Workshop，识别支撑价值流的各种角色以及角色之间的协作关系。我们不需要文档化价值流中每一步的细枝末节，而是理解价值是如何传递的，各角色是如何协同工作的。

另外，这里还要强调跨职能协作时的质量管控部分。不仅仅是自动化测试，还要关注持续测试、持续安全检查，让这些活动在日常工作中反复进行，做到内建质量。

实践四：建立实验的组织文化

调查表明，组织文化是可以被度量的，而且组织文化对IT效能和组织绩效都有可度量的影响。我们使用Westrum模型来度量组织文化。该模型中有三种类型：

• 病态型组织（Pathological）的特征是存在大量恐惧和威胁。人们通常处于政治因素而隐藏或者压制信息，甚至为了让自己表面上看起来更好而扭曲事实。
  
  

• 官僚型组织（Bureaucratic）的特征是各部门自保。每个部门都想维护自己的一亩三分地儿，坚持自己的规则，通常会依照自己的章程按部就班地行事。
  
  

• 生机型组织（Generative）专注于自身的使命以及如何达到目标。任何因素都要让位于高绩效，团队间高度合作、风险共担、鼓励联结。面对失败时需要尝试发现系统中的问题根因，而不是寻找替罪羊或相互推诿。
  
  
  

根据统计结果发现，一个高度信任的生机型文化不仅对创造一个安全的工作环境非常重要，更是打造高绩效组织的基础。

以上模型不仅停留在理论层面，更可以应用在实践领域。

案例一. Google的灾难恢复测试

Google在几年之前进行过一项研究，如何打造一个优秀的团队。他们调研了来自180个Google团队的200位受访者，观察了超过250项不同的因素，比如团队中有人取得博士学位、有性格外向的人，有人着迷于AngularJS等等。但他们最终发现打造高效能IT组织，排在第一位的因素是：心理上的安全感，即可以在团队中承担风险而不会感到不安全或者受到伤害。

我们需要构建一个安全的环境，让失败是可以接受的，并且作为组织学习的基础。Google和Amazon都会在线上进行灾难恢复测试，确保在发生严重故障时，故障恢复策略真正有效，系统仍然可以正常运转。

Google有一整个团队专注于计划和实施灾难恢复测试，甚至有一年模拟外星人侵入硅谷的场景，他们断开山景城与外界的光缆连接、关闭数据中心并对基础设施施加真实的影响，但要求团队必须要维护服务级别目标。他们设计的灾难恢复测试，需要由来自很多不同组、平时不在一起工作的工程师相互协作，那么在大规模灾难真正来临的时候，他们已经建立起了很强的工作关系。

案例二. Etsy的”三只袖毛衣”奖励

Etsy每年举办开发者大会，会发给过去一年中生产环境最大中断的制造者一件”三只袖毛衣”作为奖励。那么为什么奖励是三只袖毛衣呢？因为Etsy的404页面中有一张三只袖毛衣的图片。

图中这位身穿毛衣的同学就是Etsy去年最大故障的制造者Ryn，她把故障的过程记录在了博客中，包括何时、什么原因造成了生产环境中断。发生故障时，她马上在Slack上寻求帮助，然后立即得到了身边很多人的回复，然后他们一起蜂拥而上快速解决了问题。之后，他们开展了免责的事后故障分析会议，并给出了防止再次失败、优化系统的具体措施。Ryn也因此获得去年的奖励，因为她促进了组织学习，让系统的恢复能力变得更强。

案例三. Netflix的Chaos Monkey和Simian Army

Netflix的这个工具不断在生产环境上制造破坏，验证系统是否具备良好的恢复能力，并帮助工程师构建更加健壮的系统。

实践五：持续消除浪费，优化价值流

DevOps需要持续改进，移除浪费，让价值流动变得更加顺畅。我近期辅导了一些团队使用价值流图的方式进行流程和问题梳理，发现这的确对组织认知和优化现有软件交付过程非常有帮助。

我们可以邀请来自产品、开发、测试、运维、安全等不同部门的Leader参加价值流梳理活动，其实最难的部分是让这些人在同一时间聚在一间会议室中。我们逐个梳理从需求提出到编码、测试验证再到部署、发布的过程，过程中会发现大家的认知并不一致，尤其是对前置时间、等待时间和C/A%（完整且准确比例）的估算。

让所有人达成对整个价值流的理解和认知非常重要，但更重要的是确定未来如何改进的具体措施和预期目标。在不同的角色对目标达成一致意见的基础上，定期（如一个月）进行回顾和持续的改进。在改进的过程中，并不是事无巨细的告诉团队具体如何开展工作，而是明确目标并让团队深度参与、自主思考，通过不断实验和学习想办法达到目标。（这映射了我们之前提到的误区一）

DevOps转型实施的具体建议

在过去五年对高效能企业的研究中，总结出了DevOps转型的关键能力要素，如下图所示。图中共有四大领域，分别是软件开发实践、精益产品开发、精益管理、变革领导力，这些领域又细化出了20多个能力项。这些能力项的建设可以作为DevOps转型实施的主要参照系，强烈推荐大家持续关注。

DevOps的转型并不简单，想要走上成功之路，这里还有几个Tips：

• 对可度量的业务目标达成一致。制定”跳一跳可以达到”的目标，比如减少10%严重缺陷数、提升20%服务可用时长、达到2倍的发布频率，或者其他混合的结果指标。
  
  
  
  

• 给团队资源进行实验并对学习进行激励。团队无法在日常工作照旧的前提下，”加班”进行改进的探索。改进是要有真实工作量投入的，这应当与开发新功能、修复缺陷以同样的方式进行优先级排序。具体来讲，可以使用看板管理WIP，指派专职的团队全职做改进工作，或者每周给团队一个特定时间用于做改进工作。
  
  
  
  

• 与其他团队沟通，鼓励协作。很多人经常提及合规、安全、治理等团队，认为他们是改进的阻碍。但其实如果与这些团队进行友好的沟通，你可能会发现他们非常期望讨论获得双赢的具体措施。
  
  
  
  

• 取得速赢。你需要在一到两个月做出改进的效果。具体来讲有三个关键点：首先，通过价值流图或约束理论，找到一个影响最大的、并且可以快速解决和可被度量效果的问题；其次，限制首次进行改进的范围，最小化改进工作；然后，与对改进有兴趣并有充足容量和能力的团队合作，取得速赢。
  
  
  
  

• 分享成功经验。为了获得其他人的支持，你需要做好成功经验的宣传工作，吸引更多的人加入到改进工作中来。比如有的企业组织内部的DevOpsDays大会，跨部门进行经验的推广，这非常有效。另外午餐学习会、内部博客、邮件列表、Slack或HipChat频道都是获得参与者最好的渠道。还要对其他尝试的人提供帮助，就像DevOps教练应该做的工作那样。
  
  
  
  

• 持续改进。高效能的组织永远追求改进的机会。就像丰田管理系统的缔造者大野耐一所说的：”Kaizen [improvement] opportunities are infinite”，改进的机会是无穷无尽的。百度集团总裁兼COO陆奇在去年的一次演讲中也讲过：”Engineering Excellence 是一个永无止境的、个人的、团队的，能力的追求和工具平台的创新，综合在一起可以带给我们带来的长期的、核心的竞争力”。Relentless pursuit of excellence，这是我们应该坚持的态度。
  
  
  
  
  

总结

今天我们从鸟飞派和空气动力学派的类比说起，DevOps的转型不能照搬其他组织的实施过程，而是应该深入理解其背后的原理、原则和实践。

我们分别介绍了DevOps转型的五个误区、五个实践，以及转型实施的具体建议。

• 五个误区。放弃现有人员而招聘新的DevOps专家、进行大规模组织结构重组、重新编写应用并上云、购买一揽子DevOps工具、给开发生产环境完全访问权限；
  
  

• 五个实践。习惯小批量的工作方式（开发、架构、组织文化的演进）、创建反馈循环（流水线建设）、通过价值流进行跨职能协作、建立实验的组织文化、持续消除浪费并优化价值流；
  
  

• 转型实施具体建议。关注DevOps转型的关键能力要素，对可度量的业务目标达成一致、给团队资源进行实验并对学习进行激励、与其他团队沟通并鼓励协作、取得速赢、分享成功经验、持续改进。
  
  
  

以上这些内容都是在很多企业中总结出来，是被证明过的、对提升组织效能最有效的方式。我们的目标是快速的发布、更高的可靠性、更好的恢复能力和更安全的系统，以及更人性化、持续改进和自我增强的组织。

希望本文能对你的DevOps转型提供一点点光亮，也祝你早日走上DevOps成功之路！

原创：张乐