破解Dev Ops的五大迷思

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

　　同其他新技术一样，Dev Ops的出现也激起了许多讨论。在深入理解Dev Ops之前，应该首先澄清一些关于Dev Ops的常见迷思和误解。

　　1.Dev Ops专为IT潮人而生

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

　　事实上，许多资深开发人员正是Dev Ops创新的缩影-他既是一个能像程序员一样思考的专业运营人员，又是一个能了解他所开发的所有产品变化需求的程序员。但是刻板的文化和“一个萝卜一个坑”的组织架构却使他们全面的才能和技术无法得到充分利用。

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

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

　　当Dev Ops的支持者们大肆宣扬其作为敏捷思维、创新改变、持续交付的代表的同时，IT服务管理流程实际需要的是对恢复力和稳定性的重视和强调。新技术的浪潮不断袭来，我们不能只聚焦于诸多技术间的竞争，更要关注它们能够互相补充的能力。

　　3.一项技术创新

　　如今，围绕Dev Ops的话题涌现出不少优秀的技术性文章，同时，很多像“基础设施式代码”和“抗脆弱性”这样发人深思的新术语也随着一系列新产品和新技术的诞生被创造出来。然而，虽然这些新工具是进行创新的基础，但人们经常忽略一点，即不恰当的自动化数据处理只会让原有的缺陷雪上加霜。

　　试想如果开发者能有效使用工具来检测代码、模拟性能表现、在产品被生产出来之前做出更精确的容量判断，将会有怎样的情况出现？它不仅是一个监测工具，它应该成为一种减少缺陷、提升产品质量的协作生产方式。

　　4.业务不会受到影响

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

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

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

　　5.Dev Ops将改变世界

　　围绕Dev Ops的信息如此之多，人们总是轻易服下定心丸，对Dev Ops表现出信心。但仔细想想-尽管采用了最佳的实践、方法或举措，软件开发项目的成功率在近20年却没有得到多少提高。

　　Dev Ops的关键点在于人。所以在涉足Dev Ops之前，应该先审视一下支撑你们团队的企业文化、工作流程和指标。如果你的开发人员不愿离开办公室去了解用户需求，那么Dev Ops也无能为力。

　　Sumal Karunanayake

　　CAT echnologies亚太及日本地区应用交付部副总裁

关注读览天下微信， 100万篇深度好文， 等你来看……