驱散谬见 | 7个常见的 DevOps 误区解读

前言：

本文将介绍《DevOps Handbook》全书中的一部分：对 DevOps 常见误区进行解读。有些朋友对DevOps不熟悉或有一些不准确的理解，比如是不是只有互联网公司可以仅仅，是不是与ITIL不兼容，是不是做DevOps就不能同时保证质量和效率等，我们会对这些常见误区进行分析。

驱散谬见-常见DevOps误区解读

在DevOps推广过程中有非常多的声音，有人说 DevOps 只适合特定的公司、特定的企业、特定的文化，他们的公司很难去推广 DevOps 活动。所以在《DevOps Handbook》中专门有一个章节来谈一谈常见的 DevOps 误区，结合我的理解，我为大家做一下解读。

1、误区一

第一个常见的误区：DevOps只适合于初创型的互联网公司，这也是很多人经常会表达的一个观点。

DevOps实践确实是被那些互联网独角兽公司所倡导，包括优秀的公司比如谷歌、亚马逊、Netflix、Etsy，这些公司都在倡导DevOps相关的方法实践，虽然也许他们不把它称为DevOps。

实际上，这些公司并不是生来如此的，每个公司成长过程都是一样的，都会经历很多问题、坎坷，也经历过IT跟不上业务的发展导致业务停滞的风险。

我们把他们叫做独角兽公司，因为在神话里独角兽是一种长着犄角和翅膀的白马，这些公司都是从普通的”马驹”公司进化成了独角兽公司，他们也会遇到传统公司所碰到的问题，包括高危代码导致的灾难性的失败、不能快速发布功能、不能应对市场上竞争的变化、不能扩大规模，以及开发和运维相互对立而不能相互信任等。

但是这些公司采用了一些比较好的方法和实践，促进他们成功完成了转变。这里我收集了一些资料，这些公司都或多或少都进行了很多架构上的、技术实践上的，以及文化的转型。

- 亚马逊在2001年时，他们那时的系统叫做奥比杜斯，奥比杜斯是亚马逊流域下游一个很有名的城市，他们这个的系统就以此命名。这个系统是一个很大的单体应用，面临很多系统的问题。2002年的转型大家都非常熟悉了，他们CTO说我们必须要转成SOA的架构，所有不按这个原则工作的人都要被fire掉，他们通过强力的转型，开启了SOA架构的路线。现在亚马逊被认为是在技术领域非常成功的公司，因为他在很久之前就开始做这些技术转型的工作。 - 2009年推特也遇到了很复杂的情况，他们把前端巨石架构的Ruby on Rails系统花了一年多时间做重构。 - Etsy是手工艺制品销售网站，为了提升工程能力，公司在2009年花很大的代价，用两年时间去解耦原来一个叫做Sprouter的系统。这个案例我们在第二期会进行详细分析。 - Facebook经历了快速成长后，在2009年运维已经接近崩溃，无法跟上用户的增长，到处救火，于是开始进行技术和文化上的变革。 - 2011年领英在IPO之后同样面临了很大的困境，技术已经无法完全跟上业务和用户的发展，他们做了一个决策，整整两个月时间，不做任何新功能的开发，而是去解决环境部署和技术架构的技术债。

类似的案例其实非常多，可以说这些成功的公司背后都经历了很多也许不为人知的努力，他们因为改变了技术架构、技术实践，改变了文化的氛围，才有可能不断走向成功。DevOps不仅是初创公司可以使用，它其实是一种普适技术，所有类型的公司都可以采用DevOps的方法和实践帮助取得比较好的成果，后面会逐步看到这些方法和技术实践是什么。以上是第一个误区。

2、误区二

第二个误区，DevOps Replaces Agile，有些人认为是不是DevOps就会替换掉Agile。

正确的说法应该是DevOps的方法和实践是与敏捷相适应的，我们认为DevOps是敏捷之旅的一种逻辑延伸。

敏捷是DevOps的使能者，因为做了敏捷，具备小团队快速发布和持续交付的能力，才能进一步做好DevOps。

但是DevOps实际上是在超越敏捷的，大家读过《敏捷宣言》，有一句是”可工作的软件大于面面俱到的文档”，每个迭代结束之后它会得到一个潜在可交付的版本，但是我们认为DevOps已经在超越这个目标，把目标扩展为”让代码一直处于可部署的状态”。

通过每日频繁的签入代码到主干上，经过一系列的构建、自动化测试，能够很快在类生产环境甚至生产环境看到这次变更所带来的影响。DevOps不是替换敏捷，而是敏捷之旅的延伸，把目标做进一步的扩展。

3、误区三

第三个误区，DevOps与ITIL不兼容，这可能是很多做运维的朋友最大的困惑。1989年提出的ITIL是非常经典的方法论，影响了一代又一代运维实践者。

有很多世界级IT运维流程横跨整个服务的策略、设计和支持等很多方面，但是我们认为DevOps的实践实际上可以与ITIL流程做兼容。具体有三个方面：

• 第一，为了支持更短的前置周期和更高的部署效率，很多ITIL流程需要自动化，通过自动化的方式提升效率。
• 第二，为了解决配置和发布管理流程方面的一些问题，我们强调DevOps需要保持配置管理数据库以及软件库的及时更新。
• 第三，DevOps需要快速探测和恢复故障，在这个背景之下ITIL里关于服务的设计、事故、问题管理的这些流程其实是仍然适用的。

ITIL与DevOps其实是可以兼容的，之前有一个文档《企业级DevOps成功之路》，里面谈到DevOps里有很多组成部分，包括敏捷、持续交付、精益，还有轻量级的ITSM，如何把ITIL流程做效率上的优化，与DevOps频繁发布变更的模式相匹配等，所以我们认为本质上二者是可以兼容的。

4、误区四

第四个误区，DevOps和信息安全、合规性之间不兼容。

很多人觉得DevOps缺乏传统的控制方式，比如职责隔离，不同人有不同权限、做不同事情，DevOps讲究跨界，鼓励开发人员自服务的方式做环境申请、部署和发布。

又比如说传统的控制方式有很严格的变更审批的流程，以及在整个项目末尾人工进行非常完善的安全review的活动。

DevOps没有这些活动，但是不代表没有安全控制，反过来，很多做DevOps的公司的安全性、合规性甚至会超过原来传统控制方式的公司。因为DevOps其实是把原来项目末尾做的安全和合规性的检查注入到了每个阶段，变成日常工作的一部分。

我们经常说在DevOps里是没有单独的测试阶段的，但是它把测试已经融入到每个阶段，测试在DevOps场景里是每个阶段都要做的实践，而不是一个单独的阶段。没有传统的控制方式，并不意味着DevOps没有安全和合规性的要求，反而它会更强。

5、误区五

第五个误区，DevOps没有Ops或者说排斥了IT运营。

诚然在DevOps场景里IT运营或者运维的职责会发生一些变化，但是这种角色仍然是非常重要的。

我们的运维更早的会介入到软件生命周期里，可能会与开发一起工作。反过来，开发也会在代码部署到生产之后，与运维一起去持续工作。变化是我们更强调自动化，通过自动化替代原来手工处理工单的一些工作。

运维最大的变化是通过一系列自服务平台的创建和开发，能够把自己原来基于人工的环境的建设、维护、发布、部署等等这些能力赋能给开发，通过赋能给开发的方式，提升流程生产效率。

从这个角度讲，IT运营或运维其实更像是一种开发，开发的产品是一个平台，让开发人员可以快速、安全、可靠的用这个平台去完成经常操作的场景，比如部署、环境分配等。从这个角度讲，并不是说没有运营或运维，反过来运维的职能会有些变化，更强调赋能给开发，提升自服务能力。

6、误区六

第六个误区，DevOps仅仅是基础设施即代码。

因为很多人在谈DevOps强调的是自动化，强调的是Puppet、Chef、Ansible这种工具，我们认为这远远不够。

很多DevOps模式确实需要自动化，但是那些成功的公司不仅仅有技术范畴的改进，更有公司组织结构的调整、文化氛围的调整，让整个共享目标在IT的价值流里快速交付，这已经远远超出了自动化的范畴。

这里有一句很经典的话：”DevOps不仅是自动化，就像天文学不仅是望远镜那样”。我们要超越技术的范畴去看更广阔的改进空间。

7、误区七

第七个误区，DevOps只为开源软件服务。

很多成功的故事都是用LAMP技术栈，比如Linux、Apache、MySQL、PHP，但是这些其实与取得DevOps的成果是无关的，我们看到很多成功案例可以用微软.Net、大型机系统、SAP软件，或者是一些嵌入式软件等，都可以做DevOps转型，在《DevOps Handbook》这本书里也提到很多，包括ATM机这种复杂的嵌入式的系统也可以做DevOps转型。

以上谈到了七个误区，希望大家通过我的解读慢慢去理解，DevOps实际上是一个普适的概念，它不仅仅是自动化，不仅仅是一种流程，可以跟我们日常的工作场景相兼容。