DevOps的五大实践及转型具体实施过程，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。
那么DevOps转型的正确姿势应该是怎样的呢？
持久的变革需要以小批量、持续的方式进行，通过反复实验、根据反馈循环快速学习，找到最正确的实施路径。这样需要把大的问题拆成一系列小的问题逐个、渐进式解决，也许这样没有Big Bang式的变革令人激动，但这才是让我们成功的正确姿势。
1. 找到最重要的工作
最经典的例子就是项目管理，传统上按半年或一年规划并申请预算，这驱使我们工作在大型复杂项目上，大量时间花在特性在待办清单（Backlog）中等待被分析、估算、批准和排优先级等事务性工作上。一份称为"黑天鹅农场"的白皮书显示，他们分析了3000个待办清单中等待开发的不同需求，使用延迟成本（如果不做这个需求，每周损失的成本）的优先级决策方式。
他们发现，在待办清单中有三个特性，如果不交付这些特性，每个特性每周给组织带来200万美金的损失。这几个特性隐藏在庞大的待办清单中，但确实极为关键的。他们意识到应当停掉手头所有工作，以最快的速度交付这三个特性。从统计数据上看，这种情况符合幂律分布，如下图所示。
所以我们的工作就是要在多个项目中间，找到那些真正重要的，这需要更加透明、更加清晰的优先级，以及组织中每个人的协作。
2. 架构的持续演进
很普遍的情况是，很多组织拥有大量的遗留系统，一些软件或硬件过于老旧，可能厂商已经不再支持了，有些组织的个别系统甚至没有源代码（可能在乙方手中或已丢失）。这类组织通常选择通过长达一两年的架构再造解决问题，而当进行到一年的时候，他们可能会说，系统复杂度实在太高，我们还需要额外的两年！我本人就亲历过这样的超大型项目，最后负责的CTO都换人了，项目还没做完。
以上描述的场景，关键的问题是，大家的关注点常常在架构的技术层面而不是需要达到的结果上。调查数据显示，如果以下问题的回答都是Yes，那么你更有可能做好持续交付和DevOps，成为高效能IT组织：
是否无需团队外的某人或其他团队授权就可以进行自身系统大范围的设计变更？
是否无需与团队外的其他人员进行细粒度的沟通就可以完成自身的工作？
是否可以独立于其他依赖的服务或产品，按需部署和发布自身的产品或服务？
是否无需依赖复杂的集成测试环境，就可以按需进行大多数自身系统的测试？
是否可以在日常业务时段，执行无停机的部署？
你可以在老旧的遗留系统上实现以上全部这些效果，但也可能在充满高科技、新技术的情况下，无法达到以上效果的任意一条。所以我们要关注的是架构演进的结果，而不仅仅是使用炫酷的技术。
关于演进式架构的更多内容，以及绞杀者模式的思路，我之前的文章也有介绍，其主要原则如下：
从交付业务所需的新功能开始（至少在初期是这样），新功能使用面向服务的设计
不要重写已有的功能，除非能够使它持续简化
通过不断拆分，更快的进行交付
为可测试性和可部署性进行设计
新的架构运行在PaaS平台上
在小批量工作的基础上，我们要建立起反馈循环。反馈循环让我们能够持续学习，基于学习进行持续改进，这也是敏捷和学习型组织的关键原则。
持续交付流水线就是反馈循环的具体实现，可以提供多个层次、多个链路的反馈信息，并且可以在反馈效率和反馈完整性之间取得平衡。
以下是去年我与朋友合作的全开源持续交付流水线的设计图和效果图，充分体现了流水线的递次晋级和反馈循环的原则。
全开源流水线只能满足中小企业的需求，在大型企业中的流水线设计和实现更为复杂，我后面找时间再跟大家单独介绍。
需求、开发、测试、信息安全、运维等角色需要在软件交付价值流中协同工作。价值流图是促进跨职能协作的关键工具。我们可以通过开展价值流梳理的Workshop，识别支撑价值流的各种角色以及角色之间的协作关系。我们不需要文档化价值流中每一步的细枝末节，而是理解价值是如何传递的，各角色是如何协同工作的。
以上模型不仅停留在理论层面，更可以应用在实践领域。
案例一. Google的灾难恢复测试
Google在几年之前进行过一项研究，如何打造一个优秀的团队。他们调研了来自180个Google团队的200位受访者，观察了超过250项不同的因素，比如团队中有人取得博士学位、有性格外向的人，有人着迷于AngularJS等等。但他们最终发现打造高效能IT组织，排在第一位的因素是：心理上的安全感，即可以在团队中承担风险而不会感到不安全或者受到伤害。
我们需要构建一个安全的环境，让失败是可以接受的，并且作为组织学习的基础。Google和Amazon都会在线上进行灾难恢复测试，确保在发生严重故障时，故障恢复策略真正有效，系统仍然可以正常运转。
Google有一整个团队专注于计划和实施灾难恢复测试，甚至有一年模拟外星人侵入硅谷的场景，他们断开山景城与外界的光缆连接、关闭数据中心并对基础设施施加真实的影响，但要求团队必须要维护服务级别目标。他们设计的灾难恢复测试，需要由来自很多不同组、平时不在一起工作的工程师相互协作，那么在大规模灾难真正来临的时候，他们已经建立起了很强的工作关系。
案例二. Etsy的"三只袖毛衣"奖励
Etsy每年举办开发者大会，会发给过去一年中生产环境最大中断的制造者一件"三只袖毛衣"作为奖励。那么为什么奖励是三只袖毛衣呢？因为Etsy的404页面中有一张三只袖毛衣的图片。
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的五大实践及转型具体实施过程的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注亿速云行业资讯频道，感谢各位的阅读！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
