正如任何变革性和颠覆性运动一样，DevOps 也可能被误解或错误描述。以下是一些关于 DevOps 的主要误解。
DevOps 取代了 Agile
DevOps 与 Agile 完全兼容。事实上，DevOps 是 2001 年开始的 Agile 之旅的逻辑延续，因为我们现在知道，“完成”的真正定义不是开发完成编码时。相反，只有当代码经过全面测试并在生产环境中按设计运行时，代码才算“完成”。（请注意，Agile 不是采用 DevOps 的先决条件。）
DevOps 取代了 ITIL
尽管有些人可能将 DevOps 视为对 ITIL（IT 基础设施库）或 ITSM（IT 服务管理）的抵制，但 DevOps 和 ITIL 也是兼容的。ITIL 和 ITSM 仍然是 IT 运维流程的最佳编纂，实际上描述了 IT 运维为了支持 DevOps 风格的工作流程所需的许多能力。
为了适应与 DevOps 相关的更快的前置时间和更高的部署频率，ITIL 流程的许多领域需要自动化，特别是围绕变更、配置和发布流程。因为当服务事件发生时，我们也需要快速检测和恢复，所以服务设计以及事件和问题管理的 ITIL 规范仍然像以往一样重要。
DevOps 意味着 NoOps
DevOps 有时被错误地解释为 NoOps（即，完全消除 IT 运维）。然而，更准确地说，DevOps 通常会给开发部门施加更多责任，以进行代码部署和维护服务级别。这仅仅意味着开发部门正在接管许多 IT 运维和运维工程职能。
为了支持快速的前置时间并提高开发人员的生产力，DevOps 确实需要许多 IT 运维任务实现自助服务。换句话说，开发人员无需提交工单并等待 IT 运维完成工作，许多这些活动将实现自动化，以便开发人员可以自己完成（例如，获得类似生产环境的开发环境或为生产遥测添加功能指标）。
DevOps 仅适用于开源软件
尽管许多 DevOps 成功案例发生在使用 LAMP 堆栈（Linux、Apache Web 服务器、MySQL 数据库、PHP 或 Python 或 Perl）等软件的组织中，但组织正在使用 Microsoft .NET、SAP，甚至在大型机和 HP LaserJet 固件上运行的 COBOL 应用程序实施 DevOps 模式。
DevOps 原则是通用的，并且在很大程度上独立于所使用的底层技术。一些 DevOps 模式具有特定的技术要求（例如，能够支持自动化测试，能够公开可以检入版本控制的配置），这些要求在开源软件中通常更为普遍。
DevOps 仅仅是“基础设施即代码”或自动化
虽然许多 DevOps 模式需要自动化，但 DevOps 也需要在整个 IT 价值流中共享目标和共同承担痛苦。这远远超出了自动化的范畴。
DevOps 仅适用于初创公司和独角兽企业
DevOps 适用于任何必须在提高开发计划工作流程的同时，为客户保持质量、可靠性和安全性的组织，并且与之相关。
事实上，DevOps 对于老牌企业来说甚至比对于独角兽企业更重要。毕竟，正如 Richard Foster 所说，“1955 年的财富 500 强公司中，有 87% 已经消失。1958 年，财富 500 强企业的平均寿命为 61 年；现在仅为 18 年。” (1)
我们知道，每家 IT 组织都会经历下滑的螺旋式下降。然而，大多数企业 IT 组织都会想出无数理由来解释为什么他们不能采用 DevOps，或者为什么 DevOps 与他们无关。
老牌企业的主要反对意见之一是，所有独角兽企业（例如 Google、Amazon、Twitter、Etsy）都是天生如此。换句话说，独角兽企业天生就在做 DevOps。
实际上，几乎每个 DevOps 独角兽企业都曾经是老牌企业，并且具有与老牌企业相关的所有问题
- Amazon 在 2001 年之前一直运行在 OBIDOS 内容交付系统上，该系统变得非常麻烦且难以维护，以至于 CTO Werner Vogels 对其整个组织和代码进行了改造，使其成为面向服务的架构。(2)
- Twitter 在 2009 年努力扩展其前端单体 Ruby on Rails 系统的容量，并启动了一个多年的项目，逐步对其进行重新架构和替换。(3)
- LinkedIn 在 2011 年成功 IPO 六个月后，因部署问题而苦苦挣扎，这些问题非常痛苦，以至于他们启动了“Operation InVersion”行动，冻结功能开发两个月，以便全面检修其计算环境、部署和架构。(4)
- Etsy 在 2009 年，根据 Michael Rembetsy 的说法，“不得不正视他们生活在自己工程污秽的海洋中”，处理有问题的软件部署和技术债务。他们致力于文化转型。(5)
- Facebook 在 2009 年，基础设施运维正处于崩溃的边缘。几乎无法跟上用户增长，代码部署变得越来越危险，员工不断救火。Jay Parikh 和 Pedro Canahuati 开始了他们的转型，使代码再次可以安全部署。(6)
简而言之，所有独角兽企业都曾经是老牌企业。DevOps 是任何老牌企业如何成为独角兽企业的方式，如果他们想成为独角兽企业的话。事实上，采用 DevOps 的企业名单还在不断增长。Christopher Little 表示，“如果说所有老牌企业 [企业 IT 组织] 都讨厌什么，那就是听到关于独角兽企业 [DevOps 商店] 的故事。这很奇怪，因为老牌企业和独角兽企业可能是同一个物种。独角兽企业只是长角的马。”
- Richard Foster 和 Sarah Kaplan，《创造性破坏：为什么旨在持久的公司表现不如市场——以及如何成功转型它们》，（纽约：百老汇图书，2001 年）。
- Jim Gray，“与 Werner Vogels 的对话：从 Amazon 技术平台学习”，计算机协会网站，2006 年 6 月 4 日，https://queue.org.cn/detail.cfm?id=1142065。
- Raffi Krikorian，“Twitter 的实时系统”，（Velocity Conference 演讲），Slideshare 网站，2012 年 6 月 26 日，http://www.slideshare.net/raffikrikorian/realtime-systems-at-twitter。
- Ashlee Vance，“Operation InVersion 内幕，拯救 LinkedIn 的代码冻结”，企业技术（博客），彭博商业周刊，2013 年 4 月 10 日，http://www.businessweek.com/articles/2013-04-10/inside-operation-invers…。
- Michael Rembetsy 和 Patrick McDonnell，“持续部署文化：在 Etsy 扩展文化”，（Velocity Europe Conference 演讲），Slideshare 网站，2012 年 10 月 4 日，http://www.slideshare.net/mcdonnps/continuously-deploying-culture-scali…。
- Pedro Canahuati，“从少数到多数：Facebook 的规模化运维”，（OmniTI Surge Conference 演讲），2013 年 9 月 12 日，http://surge.omniti.com/2013/speakerslides/surge13_Scaling-Operations-O…。
评论已关闭。