DevOps的七大认知误区，你踩了几个？

误区1：DevOps只适用于创业公司

澄清：虽然谷歌、亚马逊、Netflix和Etsy 等互联网“独角兽”公司是DevOps的先行者，但这些公司在过去都面临过巨大的风险，而且他们所遇到的问题和传统企业相比并无二致：软件的高风险代码容易导致灾难性故障，无法快速发布新功能来击败竞争对手，存在安全合规性问题，服务无法扩容，开发和运维彼此高度不信任等。然而，这些公司都能够适时地改变它们的架构、技术实践和文化，如今他们都创造出了惊人的DevOps成果。正如信息安全高管Branden Williams博士所说：“不要管DevOps是适合独角兽还是马，只要跑得快就能抵达目的地。”

误区2：DevOps将取代敏捷

澄清：DevOps的原则和实践与敏捷方法一致，许多人认为DevOps是自2001年开始的敏捷之旅的合理延续。敏捷通常是DevOps效率的保障，因为它专注于让小团队向客户持续交付高品质的代码。如果我们每次迭代的目标不限于“潜在可交付的代码”，而是扩展到让代码始终处于可发布状态，让开发人员每天都把代码提交到主干，并在类生产环境中做功能演示，那么许多DevOps相关的实践就会浮现。

误区3：DevOps与ITIL不兼容

澄清：许多人认为，DevOps与1989年发布的 ITIL（Information Technology Infrastructure Library，IT基础架构库）或ITSM（IT Service Management，IT服务管理）是背道而驰的。ITIL广泛影响了好几代运维实践者，并且它依然在演进，是一个不断发展的实践体系，旨在稳定地支撑世界级的IT运维，而且横跨服务战略、设计和支持等流程和实践。

DevOps实践可以与ITIL流程兼容。然而，为了支持DevOps所追求的更短的发布周期和更频繁的部署，ITIL流程的许多方面需要完全自动化，以解决配置和发布管理流程相关的许多问题，例如保持配置管理数据库和最终软件库是最新的。由于DevOps需要在服务事件发生时进行快速的定位和恢复，因此这些其实还是和ITIL的服务设计、事件和问题管理方面的原则相一致。

误区4：DevOps与信息安全及合规活动不兼容

澄清：传统控制手段（例如职责分离、变更审批流程、项目结束时的手动安全审查）的缺位，可能会令信息安全和合规审计人员感到失望。然而，这并不意味着采用DevOps的公司里没有有效的控制，只是它并不一定体现在项目结束时的安全和合规性活动中，而是集成到了软件开发生命周期的每一项日常工作中，因此会得到更好的质量、安全性和合规性。

误区5：DevOps意味着消除IT运维，即“NoOps”

澄清：许多人错误地DevOps解释为完全消除IT运维的职能，然而，这种情况是很少见的。

虽然IT运维工作的性质可能会发生改变，但它仍然像以前一样重要。IT运维团队要在软件生命周期的早期就与开发团队开展合作。在代码部署到生产环境中后，开发团队也要继续与运维团队合作。

IT运维不只是工单驱动的手动操作，而是能够通过自助服务平台和API 来提升开发人员的生产效率，让他们能自助地创建开发环境、测试和部署代码、监控和显示业务运行的状态等。通过这种方式，IT运维人员变得更像是开发人员（或者QA和信息安全人员），融入到了产品开发过程中，而该产品则是开发人员在生产中用来安全快速地测试、部署和运行IT服务的平台。

误区6：DevOps只是“基础设施即代码”或自动化

澄清：尽管许多DevOps模式都需要自动化，但是DevOps还需要文化规范和架构，以便在IT价值流中实现共同的目标。而这远远超越了自动化的范畴。DevOps最早的拥护者之一Christopher Little也是一名技术主管，他写道：“DevOps不仅是自动化，就像天文学不只是望远镜一样。”

误区7：DevOps仅适用于开源软件

澄清：尽管许多DevOps成功案例发生在使用LAMP栈（Linux、Apache、MySQL、PHP）等构建软件的公司， 但实现DevOps与所使用的技术无关。在使用Microsoft .NET、COBOL和大型机汇编语言以及SAP甚至嵌入式系统（如惠普LaserJet打印机固件程 序）等编写应用程序的公司，DevOps也能取得成功。

以上来源：《DevOps实践指南》

翰德恩洞见