DevOps转型成功之路 - 五大实践及转型具体实施建议

在上一篇文章《DevOps转型成功之路 - 转型的意义及五大误区》中，咱们从鸟飞派和空气动力学派的类比提及，DevOps的转型不能照搬其余组织的实施过程，而是应该深刻理解其背后的原理、原则和实践。上篇文章重点介绍了DevOps转型的五个误区，分别是：放弃现有人员而招聘新的DevOps专家、进行大规模组织结构重组、从新编写应用并上云、购买一揽子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成功之路！

DevOpsDays大会北京站报名通道

2018年5月5日，与大神Jez Humble面对面畅聊DevOps！ 

与大神见面并交流的机会可贵，赶快扫码报名！