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转型的关键能力要素，对可度量的业务目标达成一致、给团队资源进行实验并对学习进行激励、与其他团队沟通并鼓励协作、取得速赢、分享成功经验、持续改进。

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