DevOps集开发、测试、部署和运营为一体，并迅速成为了加速应用交付的典型技术。如今，业务成功更加依赖于高质量软件服务，因此DevOps的影响也日益显著。

　　同其他新技术一样，DevOps的出现也激起了许多讨论。有人认为，DevOps是针对IT潮人的新技术，所以传统公司无需为此而费心，然而事实果真如此么？在深入理解DevOps之前，应该首先来澄清一些关于DevOps的常见迷思和误解。

　　1.DevOps专为IT潮人们而生

　　对于DevOps的转换问题，即开发员将不确定的代码交给运营部门（由运营部门来进行解码），人们往往认为只能通过拥有多重专业能力的新人来解决：一个对从自动化配置到生产代码模拟的知识都有了解的全能型人才。

　　CA Technologies的建议：企业在试图找出DevOps人才之前，应该回顾一下现有人力资源中所未被开发的潜能。事实上，许多资深开发人员正是DevOps创新的缩影——他既是一个能像程序员一样思考的专业运营人员，又是一个能了解他所开发的所有产品变化需求的程序员。但是刻板的文化和“一个萝卜一个坑”的组织架构却使他们全面的才能和技术无法得到充分利用。

　　2.一个创新技术统领全局

　　让人惊讶的是，那些对DevOps大加鼓吹的人对现有的优秀运营方法往往展现出不屑和轻蔑。于是忽然间，已有的工作体系如ITIL、COBIT和平衡计分卡不再受到重视，那些所谓的DevOps拥护者们宣称这些旧体系已失去地位，应该被淘汰。

　　CA Technologies的建议：别被炒作所迷惑。真正值得投资的方向是那些可以加快或提升服务的最佳实践。当DevOps的支持者们大肆宣扬其作为敏捷思维、创新改变、持续交付的代表的同时，IT服务管理流程实际需要的是对恢复力和稳定性的重视和强调。新技术的浪潮不断袭来，我们不能只聚焦于诸多技术间的竞争，更要关注它们能够互相补充的能力。

　　3.这是一项技术创新

　　如今，围绕DevOps的话题涌现不少优秀的技术性文章，同时，很多像基础设施式代码和抗脆弱性这样发人深思的新术语也随着一系列新产品和新技术的诞生被创造出来。然而，虽然这些新工具是进行创新的基础，但人们经常忽略一点，即不恰当的自动化数据处理只会让原有的缺陷雪上加霜。因此，单纯通过利用一些看似强大的新型工具使自身成为最快速的应用开发平台不过是徒劳之举，因为这些纯粹追求速度的工作既不能创造商业效益，也无法满足消费者的预期。

　　CA Technologies的建议：回顾我们当前工具的使用方式，应用性能管理这类的工作通常是由运营团队来操控。试想如果开发者能有效使用工具来检测代码、模拟性能表现、在产品被生产出来之前做出更精确的容量判断，将会有怎么样的情况出现？它不仅是一个监测工具，它应该成为一种减少缺陷、提升产品质量的协作生产方式。

　　谨记，密切关注速度和“灵敏性”——对那些有助于快速安装可行应用程序的性能进行测试，并利用用户的反馈来检验你的假设。尤其值得注意的是，安装完成的应用可能与你的预期完全不同，因此要经常对项目策划、产品管理、资金和项目实施进行检查并随时做好改变策略的准备。

　　4.业务不会受到影响

　　很多机构认为DevOps的运行原理是无法真正实现的，因为他们不是将业务外包，就是不具有开发应用产品的能力。另一些机构猜测，由于DevOps属于产品制造商业或政府服务交付，需要不断维修更换的行为都无法在他们信奉“不坏不修”的世界中占有一席之地。

　　CA Technologies的建议：看一看商业和IT行业中的这两个例子。耐克并非生意场中的一员，因为他们只生产运动鞋，而事实上他们出售的是一种健身体验，即可穿戴设备。威辛斯（Withings）也不仅仅是出售浴室秤的厂商，他们提供的是拥有外部开发应用生态系统的智能身体分析仪。

　　不论选择何种基础设施平台和开发方法，这些公司都意识到了一点，他们正在转型成为软件领域的一员。这些公司利用软件来创造新的商业模式，增强品牌影响力，并交付创新服务。

　　当提及DevOps时，常常会联想到精细、灵敏、持续生产等等，但真正应该关注的是，如何做好专业工作，如何充分利用实验、迭代和增量式设计等技术，还有最重要的是，如何从失败中吸取教训。

　5.DevOps将改变世界

　　围绕DevOps的信息如此之多，人们总是轻易服下定心丸，对DevOps表现出信心。但仔细想想——尽管采用了最佳的实践、方法或举措，软件开发项目的成功率在近二十年却没有得到多少提高。虽然2012年软件开发项目的成功率又创新高，然而根据斯坦迪什集团2013年的CHAOS宣言，仍有61%的项目正面临挑战，有的甚至已经彻底失败。

　　CA Technologies的建议： DevOps的关键点在于人。所以在涉足DevOps之前，应该先审视一下支撑你们团队的组织文化、工作流程和指标。举例来说，如果你的运营团队曾因停止发布应用而获得奖励，那其中肯定存在某些问题，即使采用再多的敏捷式开发也无济于事。同样的，如果你的开发人员不愿离开办公室去了解用户需求，那么DevOps也无能为力。