拥抱DevOps文化，第一部分

    当下DevOps流行，各行业（组织）渴望拥抱“DevOps文化“。但与ITIL不同的是：组织不会在一夜之间，决定想实现DevOps（译注：我又理解错了，原来人家的意思是，组织不会一夜之间决定拥抱DevOps，而ITIL不一样，一出来就受到热捧）。

    与Nextflix，亚马逊等公司相比，大部分的公司并没有每天数千次的应用部署。实际上，新创公司更能完全拥抱DevOps，因为他们所有商业运维都已经依赖IT。

DevOps 理念（观念）大于过程

    有非常多的文章试图定义DevOps，但是DevOps更像一个（哲学）理念，而不是一个过程。如果你拉出100个组织，在他们已有的业务流程上基于自己的经验实施DevOps，你将会看到100个不同的答案。

    每个组织迈向DevOps的路都是独特的，因为有很多不同因素会影响DevOps整合。包括公司规模大小、公司发展历史、所在的行业（银行/金融，零售，卫生保健，电子商务，教育，公共服务）、公司技术的复杂度、IT类型（数据中心还是SaaS）、组织结构（竖井式 还是 综合式。译注：综合式一般有矩阵结构）、开发方法（敏捷 还是 瀑布）、关键应用的类型（Web 2.0？虚拟化？CS结构？…）等等等等。创业生态之外的大多数公司依赖Web 2.0与敏捷应用开发，开发与运维相处并不融洽。

开发 vs 运维

    在部门目标不一致的情况下试图协调开发与运维就像将油与醋混在一起。其结果是，IT的业务价值交付能力将被大打折扣。为了有效的推动业务，开发与运维必须融洽相处。

    通常，开发与运维之间的冲突是由于各自的关注点不同，这也导致两者协同时紧张原因。开发关注的是持续交付新产品或特性去满足商业需要，而IT运维则努力保障IT服务的可用性与稳定性，以及IT成本效率。

因素	Dev（开发）	Ops（运维）
驱动力	商业需要	非功能需求
倾向变更	是	否
快速变更意味…	新特性	额外风险
变更频率	越快越好	最好不变

DevOps不能为工具所限

    首先，为了保证开发与运维无缝协作，两个部门必须使用兼容工具。不匹配的工具集会产生瓶颈、误解和误导，进而导致大量的时间浪费，最终损害商业。

    其次，流程必须一致（匹配）。工具兼容但流程冲突也没有意义。例如，通常会发现服务台使用的工单系统与用于管理产品缺陷与提升的应用开发工具是分离的。（译注：作者的意思是工单处理流产应该和产品管理流程打通）

    开发者倾向于依赖工具来达到最快捷的开发：代码变更快速反馈、自动化编译与应用发布。另外，开发团队一般对运行环境不敏感，因此难于对代码做出相应调整。相反，运维人员直接使用目标环境，对稳定性与性能追求胜于灵活性。

    集成流程对每个组织来说都是独特的，关键需要找到适合你的新流程（DevOps新流程）与员工的合适工具。一个团队仅仅是使用了最新的自动化发布工具，达到应用持续可重复的部署投产，并不意味着他们就采纳了DevOps。

    事实上，版本控制、应用发布自动化与业务事务自动发现（译注：这个事务不是保持一致性的那个事务，其实就是应用对外的提供一个交易请求）等等工具是有助于开发者达成自己的目标，但它并不着力于另外一方：运维的目标。

译注：Auto-discovery of business transactions或者business transactions detection是APM范畴的概念，就是在做应用性能监控管理时候，需要对每一笔业务交易进行监控管理，所谓的自动发现，是指定义好一些规则（一般是根据URI来定的一些规则），然后按照这些规则监控这些交易。例如：Movie_admin/Account，Movie_admin/Customer，这两个URI都可以默认成为监控的Transaction对象。

    最后，最重要的是选择合适的领导团队——从你的C级可执行团队到开发与运维团队的负责人。DevOps的集成流程并不容易，需要整合两个独立团队与流程来驱动协作，需要开发、运维双方负责人对大的目标有清晰的愿景，并清楚大家的需要，这样才能驱动公司向前迈进。

关于作者/Vincent Geffray

Vincent Geffray 是Everbridge的资深产品市场总监，公司致力于IT服务告警与通信自动化及物联网。

Vincent在技术商业拥有超过14年的经验，涉及IT运维管理解决方案设计、促销与销售，包括关键通信、应用性能管理、IT流程与工作自动化。职业生涯起步于欧洲，具备国际经验。Vincent拥有理科硕士学位（机械工程与计算机科学），并且获得麻省理工学院斯隆商学院的管理（执行）认证。

原文链接