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可以赋予给我们的能力。

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

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