DevOps 的实践和转型一样，我们很难照搬其他组织的成功，而是应该深入理解其背后的原理、原则和实践，从正确的方向入手。
DevOps 转型应该怎么做
DevOps is everywhere，所有人都在说在做。DevOps转型的案例和故事很多，有些转型成功了，但也许失败的例子更多（虽然你没有机会听到他们出来分享了）。不同组织面临的情况和环境各不相同，其实很难简单的复制别人的成功。
我经常喜欢举的一个例子，学习DevOps有不同的方式，就像人类学习飞行时有鸟飞派和空气动力学派。人类的飞行梦想始于古老而又遥远的年代，但真正的飞行实践起源于仿鸟飞行，即给自己装上一对翅膀，学习鸟的扑翼动作而飞行，但大量长期的实践证明这样的尝试都是失败的。
但还有另外一派，英国的科学家提出人造飞行器应该解决推进动力和升力等方面的问题，需要增强对空气动力学理论体系的基本认知，这使很多人放弃了单纯模仿鸟类飞行而逐渐接受和实践固定翼飞行器的设计思路，并最终由莱特兄弟发明了完全受控、可持续飞行的载人飞行器。
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）。
在我的上一篇文章 DevOps听起来不错，但适合你的企业么 ，我讲到了在大型嵌入式软件、保险公司的大型机系统上进行持续交付的案例。除此之外，在《DevOps Handbook》中也提到在传统的POS机上，采用蓝绿部署进行快速和低风险发布的例子。
所以，你不用等待漫长的应用重建并迁移到云上，而是可以在现有系统和组织环境中使用DevOps的思路进行逐步改进，最好的转型启动时间点就是现在！
误区四：购买一揽子DevOps工具
DevOps发展到今天，已经出现了非常多的支撑工具。我们认可好的工具可以对DevOps的实施提供出非常强有力的支持，但我们的观点是：如果仅仅是购买工具，无法真正帮助你解决问题。
Jez Humble与Dave Farley在2005~2006年进行持续交付的工作时，并没有上图中展示的如此众多的工具，很多自动化的工作都是由Bash脚本完成的，但也同样获得了非常显著的效果。问题的关键在于你如何解决问题，而不是具体应用哪一款的工具。如果组织仅仅是购买工具而不改变工作流程，这样不会改变任何事情。
我就曾经见过有人把Jira用成了管控型的传统项目管理工具，把Jenkins用成了批处理任务的手动触发器，只有工具而没有方法和实践的改变，是无法走上DevOps成功之路的。
误区五：给开发生产环境的完全访问权限
有人说DevOps就是让开发自己进行发布，所以需要给开发所有生产环境的权限。我们认为这是一种可怕的想法。理想情况下，任何人都不应该有生产环境的权限，所有生产环境的部署应该由人工触发后，只通过自动化的方式进行。
只有在特殊的场景下，比如需要在生产环境进行诊断时，才可以允许有人登陆到生产环境。但这种情况下仍然需要特别小心，比如使用一次性的登陆口令，并将任何操作日志都记录下来并发送给系统管理员。
总结
今天我们从鸟飞派和空气动力学派的类比说起，DevOps的转型不能照搬其他组织的实施过程，而是应该深入理解其背后的原理、原则和实践。
由于篇幅所限，本文重点介绍了DevOps转型的五个误区，分别是：放弃现有人员而招聘新的DevOps专家、进行大规模组织结构重组、重新编写应用并上云、购买一揽子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！
2018年 5 月 5 日，与大神 Jez Humble 面对面畅聊 DevOps！
本文来源：开源中国
