DevOps 中的几大常见理解误区

这里所说的创业型公司是相对于传统公司而言的。

也就是指那些 目前势头正猛的互联网独角兽公司，比如亚马逊、Netflix、谷歌、手工艺制品销售网站 Etsy。

/DevOps 大熔炉

DevOps 适用于创业型公司，这样说是没问题的。

这些独角兽公司所倡导的方法实践尽管在名称上并不叫作 DevOps，但 本质与 DevOps 无异。

而这些独角兽公司正因为采用了这些方法实践，从而取得了较好的成果。

但是 说 DevOps 只适用于创业型公司，则是不对的。

因为 DevOps 不仅适用于创业公司，也同样适用于传统公司。

之所以这样说，是因为 创业公司面对的问题与传统公司所面对的别无二致。

这些问题往往包括：

而 DevOps 本质上是一种解决问题的方法论。

既然 DevOps 能解决创业公司的问题，那么自然也能解决传统公司的问题 。

/DevOps 解决类似的问题

独角兽公司之所以成为独角兽公司，往往正是因为当他们还只是一家普通公司的时候，在面对一些巨大的问题时， 积极改变它们的架构、技术实践和文化，一步一步迈过了种种坎坷，最终创造了惊人的 DevOps 成果，在激烈的竞争中生存了下来，成为了赢家。

比如 09 年运维接近崩溃、无法跟上用户增长的 Facebook 就积极展开了技术和文化上的变革，公司也随之取得了更大的成功。

其实争论 DevOps 是否适用于传统企业并不重要，重要的是利用 DevOps 帮助企业解决问题。

正所谓 “不要管 DevOps 是适合独角兽还是马，只要跑得快就能抵达目的地。”

事实上， DevOps 并非否定了敏捷，它反倒吸纳了许多敏捷的方法与实践。

/DevOps 吸纳了敏捷

在 DevOps 的逻辑框架中，我们依旧可以看到敏捷的身影，并且 敏捷充当了一个效率保障的角色。

它通过“小步快跑”的方式，专注于让小团队向客户持续交付高品质的代码，因此敏捷通常是 DevOps 效率的保障。

与其说 DevOps 取代了敏捷，不妨说 DevOps 是敏捷的进一步延伸，进一步拓展了敏捷的目标。

在敏捷的方法论里，开发团队每次迭代的目标就是交付潜在可交付的代码。

而 DevOps 的迭代目标则不仅限于此，而是在此之上再走了一大步，将 目标扩展到让代码始终处于可发布状态。

开发人员会频繁地将代码提交到主干，代码再接着通过一系列的构建、自动化测试、自动部署等步骤，轻松部署到生产环境。

什么是 ITIL

ITIL，全称 Information Technology

Infrastructure Library，通常被译为“信息技术基础架构库”。

它是英国中央计算机和电信局 CCTA（现在已并入英国商务部）于80年代中期开始开发的一套针对IT行业的服务管理标准库。

随着企业之间竞争的加剧和世界范围内电子商务的兴起，越来越多的企业开启企业的信息化转型，建设了大量的 IT 的基础设施。

而建 设基础设施只是第一步，如何运维好这些设施却是一个极为重要却又被长期忽略的问题。

导致IT基础设施经常出现故障的原因中，源自技术或产品（包括硬件、软件、网络、电力失常及天灾等）方面其实只占了20％，而因为管理方面的原因则占到80%。

/ 企业信息化的问题来源

正是基于这个背景，ITIL 诞生了，并且广泛影响了好几代运维实践者。

此外，它依然在演进，是一个不断发展的实践体系，旨在稳定地支撑世界级的 IT 运维，而且横跨服务战略、设计和支持等流程和实践。

经过近几十年的发展，现在已经风靡全球，并在包括政府、企业和非营利组织中得到了广泛的支持与应用。

兼容双赢

认为 DevOps 与 ITIL 不兼容其实是一种误解，事实上 DevOps 的实践是可以与 ITIL 流程做兼容的。

ITIL 里的许多流程可以被 DevOps 所用，而 DevOps 反过来又帮助更好地实现ITIL。

/DevOps、ITIL双赢

比如，将 ITIL 里的许多流程进行完全自动化，可以解决配置和发布管理流程相关的许多问题。

例如：

保持配置管理数据库和最终软件库是最新的，进而可以支持 DevOps 所追求的更短的发布周期和更频繁的部署。

由于 DevOps 需要在服务事件发生时进行快速的定位和恢复， 而 ITIL 中的一些服务设计、事件和问题管理方面的原则依旧是可以为 DevOps 所用的。

认为 DevOps 与信息安全及合规活动不兼容，这个误解大概 源自于 DevOps 取消了传统的控制方式。

传统的控制方式要求 职责分离，不同的团队负责项目流程中不同的部分，而 DevOps则赋予了各个角色自服务的能力，各个角色之间的界限变得不再那么明晰。

传统的控制方式还包括 严格的审批流程，以及 项目结束时的手动安全审查，这些控制方式的缺失让人担忧 DevOps 无法确保开发的安全性与规范性。

事实上 DevOps 做到了有效控制，只不过它的方式不同以往。

DevOps 的控制并不体现在传统的项目结束时的安全和合规性活动中，而是集成到了软件开发生命周期的每一项日常工作里。

比如 DevOps 没有传统控制方式中的开发结束后单独的测试环节，而是将这个测试环节打散分布在开发的整个流程中。

正因为如此， DevOps 不仅做到了有效控制，而且在质量、安全性、合规性方面做到了比传统控制方式更好的控制。

DevOps 旨在打破开发与运维之间的一堵“厚墙”，增强两个团队间的沟通协作，而并非消除运维。

事实上， 运维自始至终都充当着不可或缺的角色。

之所以在 DevOps 中运维看起来像是消失了，是因为运维的工作性质发生了巨大改变， 它同测试一样融入到了开发的整个流程中。

IT 运维团队要在软件生命周期的早期就要与开发团队开展合作。

在代码部署到生产环境中后，开发团队也要继续与运维团队合作。

具体而言，运维改变了以往工单驱动的手动操作方式，通过自助服务平台和 API 来提升开发人员的生产效率，让他们能自助地创建开发环境、测试和部署代码、监控和显示业务运行的状态等。

通过这种方式，IT 运维人员变得更像是开发人员（或者 QA 和信息安全人员），融入到了产品开发过程中，而该产品则是开发人员在生产中用来安全快速地测试、部署和运行 IT 服务的平台。

因此 DevOps 不仅没有消除运维，而且还让运维从枯燥繁琐的工作中解脱出来，发挥更大的价值。

说起 DevOps，人们大多专注的是各种自动化工具，以及最终如何构造一条自动化的交付流水线，却 往往忽略同样重要的团队文化。

要知道单有工具是无法实现更好的交付的，还需要公司上下的文化氛围。

DevOps 不单单只强调工具，还重视文化，正所谓 “DevOps 不仅是自动化，就像天文学不只是望远镜一样。”