经常看到devops，可是却一直没去了解它是什么，今天从百度了下解释，如下：
DevOps是什么？
DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。
作用
DevOps是Develop与Operations的缩写，它是企业内开发、技术运营和质量保障这三方面工作的融合，用于促进开发、技术运营和质保部门之间的沟通、协作与整合。有研究显示，在那些引入了DevOps概念的企业中，开发与运营人员在设计、构建、测试工作中共同在内部应用上进行协作之后，可以将产品开发的效率提升20%。
然而最为重要的如何成为一名真正的消费者用户并像消费者用户那样来考虑这整件事情的意义所在，无论是成为企业内部用户的还是外部用户。事实上，如何提升最终用户体验一直是DevOps战略发展的第一驱动力，有68%的企业是这样认为的，第二个需求是为了提升开发与运营团队之间的协作水平与效率，有61%的受访者选择了这一项。企业的移动与云计算转型趋势的兴起，同样也是企业引入DevOps的重要原因，有52%与43%的人分别选择了这两项。 [11]
工具
即便是具有最高度功能化的DevOps团队也是需要第三方工具来管理诸如云计算这类的分布式环境。对于这样的环境来说，某些工具是特别有用的。
诸如FlowDock或HipChat这样的DevOps实用工具能够帮助开发团队的成员互相以及与DevOps人员保持联系。诸如Asana或Basecamp这类服务能够有助于跟踪开发任务以及在应用发布中的注意事项。
诸如以客户为中心的支持门户网站可让用户直接与管理层或开发团队进行需求沟通。这将有助于触发新的或改进的功能，并确保客户的需求能够得到满足。一个DevOps团队能够帮助建立这些服务，并让团队成员了解相关技术。 [12]
无论是纵向集成还是横向集成，DevOps都需要通过工具链与持续集成、交付、反馈与优化进行端到端整合。华为基于二十几年的研发实践，并融合DevOps等理念方法，打造了软件开发云服务，希望为企业提供一站式的云上开发工具平台。据了解，华为软件开发云提供了项目管理、配置管理、代码检查、编译构建、测试、部署、发布等端到端地覆盖软件生命周期的相关服务。 [13]
发展介绍
DevOps: Development和Operations的组合
可以把DevOps看作开发（软件工程）、技术运营和质量保障（QA）三者的交集。
传统的软件组织将开发、IT运营和质量保障设为各自分离的部门。在这种环境下如何采用新的开发方法（例如敏捷软件开发），这是一个重要的课题：按照从前的工作方式，开发和部署不需要IT支持或者QA深入的、跨部门的支持，而却需要极其紧密的多部门协作。然而DevOps考虑的还不止是软件部署。它是一套针对这几个部门间沟通与协作问题的流程和方法。
需要频繁交付的企业可能更需要对DevOps有一个大致的了解。Flickr发展了自己的DevOps能力，使之能够支撑业务部门“每天部署10次”的要求──如果一个组织要生产面向多种用户、具备多样功能的应用程序，其部署周期必然会很短。这种能力也被称为持续部署，并且经常与精益创业方法联系起来。 从2009年起，相关的工作组、专业组织和博客快速涌现。
DevOps的引入能对产品交付、测试、功能开发和维护（包括──曾经罕见但如今已屡见不鲜的──“热补丁”）起到意义深远的影响。在缺乏DevOps能力的组织中，开发与运营之间存在着信息“鸿沟”──例如运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。
以下几方面因素可能促使一个组织引入DevOps：
1、使用敏捷或其他软件开发过程与方法
2、业务负责人要求加快产品交付的速率
3、虚拟化和云计算基础设施（可能来自内部或外部供应商）日益普遍
5、有一种观点认为，占主导地位的“传统”美国式管理风格（“斯隆模型 vs 丰田模型”）会导致“烟囱式自动化”，从而造成开发与运营之间的鸿沟，因此需要DevOps能力来克服由此引发的问题。
DevOps经常被描述为“开发团队与运营团队之间更具协作性、更高效的关系”。由于团队间协作关系的改善，整个组织的效率因此得到提升，伴随频繁变化而来的生产环境的风险也能得到降低。
DevOps对应用程序发布的影响
在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备DevOps能力的组织中，应用程序发布的风险很低，原因如下 [2] ：
（1）减少变更范围
与传统的瀑布式开发模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。由于部署经常进行，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长。
（2）加强发布协调
靠强有力的发布协调人来弥合开发与运营之间的技能鸿沟和沟通鸿沟；采用电子数据表、电话会议、即时消息、企业门户（wiki、sharepoint）等协作工具来确保所有相关人员理解变更的内容并全力合作。
（3）自动化
强大的部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。
与传统开发方法那种大规模的、不频繁的发布（通常以“季度”或“年”为单位）相比，敏捷方法大大提升了发布频率（通常以“天”或“周”为单位）
现状
很多组织将开发和系统管理划分成不同的部门。开发部门的驱动力通常是“频繁交付新特性”，而运营部门则更关注IT服务的可靠性和IT成本投入的效率。两者目标的不匹配，就在开发与运营部门之间造成了鸿沟，从而减慢了IT交付业务价值的速度 [3] 。
开发人员经常不考虑自己写的代码会对运营造成什么影响。他们在交付代码之前，并不邀请运营人员参与架构决策或代码评审。
开发人员对配置或环境进行修改之后，经常没有及时与运营人员沟通，导致新的代码不能运行。
开发人员在自己的机器上手工修改配置，而没有记录所有需要的步骤。想找到必要的配置参数，通常需要尝试很多不同的参数；在得到一个可工作的状态后，往往很难识别出通过哪些最小步骤就能到达该状态。
开发人员倾向于使用有利于快速开发的工具：对代码修改更快的反馈，更低的内存消耗，等等。这样的工具集与运营人员面对的目标运行时环境非常不同：后者对稳定性和性能的要求远胜于灵活性。
由于开发人员平时使用桌面电脑，他们倾向于使用为桌面用户优化的操作系统。生产环境的运行时系统通常都运行服务器操作系统上。
在开发过程中，系统在开发者的本地机器上运行。在运营过程中，系统经常分布在多台服务器上，例如web服务器、应用服务器、数据库服务器等等。
开发是由功能性需求（通常与业务需求直接相关）驱动的。
运营是由非功能性需求（例如可获得性、可靠性、性能等）驱动的。
运营人员希望尽量避免修改功能，从而降低满足非功能性需求的风险
如果拒绝了小的修改，但给定时间段内需要修改的总量不变，那么每次变更的规模就会变大
变更规模越大，风险也越大，因为其中涉及的区域越多
由于运营人员尝试避免变更，新功能流入生产环境的速度因此被延缓，从而延缓了开发人员将特性交付给用户使用的速度。
运营人员可能对应用程序内部缺乏了解，从而难以正确地选择运行时环境和发布流程。
开发人员可能对运行时环境缺乏了解，从而难以正确地对代码进行调整。
可参考文献：
- 1. DevOps ．维基百科
- 2. 霍娜. 2017年DevOps三大趋势预测[N]. 中国信息化周报,2017-03-06(024).
- 3. 牛晓玲,吴蕾.DevOps发展现状研究[J].电信网技术,2017(10):48-51.
- 4. 重塑IT组织 实现DevOps战略
- 5. DevOps成功的两个关键
- 6. 五大DevOps最佳实践实现安全、可伸缩和性能
- 7. DevOps实施的三种IT障碍
- 8. 跟踪DevOps指标 增加业务敏捷度
- 9. DevOps的三板斧
- 10. 云计算如何牵手DevOps提升生产率？
- 11. DevOps战略究竟能为企业带来什么？
- 12. 莫慌！DevOps团队能缓解云迁移问题
- 13. 华为软件开发云如何让DevOps真正落地？
- 14. 赢在DevOps 企业必须知道的四件事
- 15. DevOps和敏捷相结合 改进软件质量
- 16. 在大型机上使用agile DevOps的四点好处
- 17. 如何用DevOps加强云应用安全
700
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
