DevOps:推倒隔阂之墙
开篇：润墨网以专业的文秘视角，为您筛选了一篇DevOps:推倒隔阂之墙范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！
导语：devops是一个融合词，即把开发（Develop）和运维（Operation）合在一起，表面上看，这个词合起来很容易，但实际操作的过程并不容易。因为在开发和运维中间始终有堵墙，DevOps要做的就是将其推到。
什么是DevOps？
人们越来越意识到传统意义上的开发行为和运维行为存在脱节现象，从而导致冲突和低效，因此DevOps应运而生。维基百科这样定义DevOps：英文Development和Operations的组合，是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
简单来说，它更像是一套技术工具的组合，将人员、流程、信息三者的价值充分发挥出来，帮助提升软件持续交付的能力。
对于一线的运维和开发人员，DevOps会给他们带来什么实际的意义呢？他们的观点是：DevOps可以让他们从众多烦恼中解脱出来，它虽然不是具有魔力的万灵药，但是如果你能够让DevOps奏效，则会节省大量时间，而且不至于打击自己的士气。显而易见，投入精力将DevOps落到实处，应该会更加高效、更加敏捷和减少挫败感。
小标题：软件交付过程中的隔阂
以开发为中心的人通常认为，变化会带来回报。企业依靠他们来应对不断变化的需求。因此他们被鼓励尽可能进行变革。而运维人员则往往视变化为敌人，企业依靠他们维持正常业务运维和实施让企业赚钱的服务。由于变化会影响稳定性和可靠性，运维业务有理由对它说不。
开发人员和运维人员认识世界的方法，以及各自所处的角色，存在根本性的差别。他们都认为自己的做法是正确的。的确，孤立的来看他们都是正确的。但当两组不同的人在不同的组织架构下，不同的文化、不同的管理流程下，共同让软件发挥竞争力的时候，他们之间就形成了隔阂之墙。
于是“隔墙扔包袱”这一幕经常在企业中上演：研发人员把不断更新的软件版本往运维人员那边甩，运维人员接到后，发现这个的版本可能有问题，就往回甩，在墙头之间甩来甩去，无数的包袱就出现了。这个包袱是怎么形成的？不是研发人员的问题，也不是运维人员的问题，是传统的软件组织将开发、IT运营和质量保障设为各自分离的部门，因此，在这种环境下如何采用新的开发方法和技术就成为一个重要的课题。
在近日召开的IBM 2013技术峰会上，以DevOps软件持续交付为核心的移动、云计算的开发创新成为亮点。IBM全球副总裁兼大中华区软件集团总经理胡世忠认为，DevOps是一种提倡将开发机构的文化、流程和工具整合到一起的集成软件交付方式，跨越从业务规划、创建、交付到反馈的整个软件开发生命周期，旨在通过持续交付软件，从而帮助企业迅速抓住市场机会，更好地满足客户的需求。
小标题：聚合力量的“金钥匙”
IBM杰出工程师、IBM软件集团Tivoli云和服务管理解决方案架构与设计负责人Bala Rajaraman介绍 ，更多企业面临着平衡IT系统优化以及新的业务价值创新方面的问题。对此，IBM公司的战略主要集中在三方面：一是优化现有的IT系统，降低IT运维成本，以及高效管理控制风险；二是在新的业务需求快速转变的环境下，产品的速度以及响应新需求能力也在变快，如何能够从软件定义的各种环境当中，响应业务变化；三是怎样能够平衡基本的业务模块，包括数据库、业务流程等，以比较和谐的方式发展。
这三方面问题的解决和改善，可以说软件交付起着不可或缺的作用，有统计表明，45分钟一个小的发版错误，就可能导致4亿美金的丢失，在日益激烈的商业竞争中，软件交付能力在行业中扮演的角色也越来越重要。据IBM近期针对400名CEO/CIO企业高管进行的一项调查表明：有86%的公司认为软件交付是十分重要的，但是不好的消息是，目前只有25%的CEO认为他们公司有有效的软件交付能力。另外，IBM 软件集团Rational软件市场部副总裁Gina Poole女士补充道：“如今大数据、云计算、移动应用、社交商务、物联网这五个大力量正在发挥重要的作用，但是如果没有把软件交付这个过程掌握好，这些大的力量就无法被掌握，在调查中，有69%左右的CEO告诉我们，如果他们能够掌握软件持续交付的能力，利用这五大技术趋势的力量，企业自身的竞争力肯定会得到提升。”
企业常常渴望达到的一个状态，能够高效的使用信息技术来达到企业目标——通常是提高公司业绩或市场竞争力，即IT融合能力，DevOps能发挥的作用就是从共同企业目标角度出发，校准开发和运维的职责和流程，有助于实现IT融合。同时，企业也希望使一个机构以高效、经济的方式迅速适应市场和环境变化的能力，这就是业务敏捷性，DevOps是通过考虑到快速、反应灵敏但稳定的业务运维，使其能够与开发过程的创新保持同步。因此，DevOps是聚合企业发挥力量的“金钥匙”。
那么如何使用这把金钥匙？IBM院士、IBM软件部Rational首席技术官Kevin Stoodley认为，DevOps绝不仅仅局限于开发和运维，它包括四个部分，一是计划，为企业的商业决定中做一些计量，设定目标；二是开发和测试，这是关于如何能够在整个生命周期进行协作性的开发，使用持续的测试和持续整合的原则；三是和部署，关于可重复性以及提高循环的质量，在开发的过程中是一天做10次还是一个月做1次，这需要引入自动化；四是监控和优化，开发者和运维者都需要理解所开发出来的新应用的市场表现，去了解客户的反馈是什么，因为这是开发和获得新的洞察力的有效办法。
整个DevOps基础是将过去这四个分开的领域串联起来，提升软件交付的能力，从而使客户加强业务竞争力。其中不仅涉及开发和运营，也包含客户的需求。例如，一个银行的客户，他在银行服务时发现了新的业务转变，他就会提供一些需求给交付方。整个流程经过内部的分析、设计，然后变成代码，再交给运营的同事来进行推广。如果有一个部分出现延误，就会影响这个银行服务的实现，自然会影响到客户的满意度。而DevOps做的就是尽可能提升软件持续交付的能力，并且平衡交付速度、客户的承受力、以及内部IT的承受力，也包括至关重要的成本和风险问题。在提升软件质量的同时，还要跟客户做沟通，在得到反馈时尽快做出优化。
TIPS：用好DevOps的12问（可加可不加）
协作
1.你的开发和运维团队相互协作吗？是经常的吗？
2.你们对应用和平台有一致的模式吗？
3.你有清晰定义的应用和平台交付流水线吗？自动化
4.你的运行时工程师理解如何开发结构良好的可重用系统配置脚本吗？
5.你能一步部署一个系统吗？
6.你能为你的开发软对提供基础设施即服务和平台即服务环境吗？
7.你的开发人员能不在运行时操作人员的帮助下按需启动、
使用和销毁典型的环境吗？验证
8.你有自动化测试来验证你的应用和平台的功能和安全性吗？
9.你能再部署你的应用之前就基于期望的KPI验证平台软件吗？
10.你能以天为周期部署你的应用并进行验证吗？管理和控制
11.你使用版本控制吗？
12.你有一个和开发阶段使用的缺陷数据库相关联的运行时问题追踪系统吗？