京东云鼎探索DevOps之路-基础服务部总监 何雨

第一篇：京东云鼎探索DevOps之路-基础服务部总监 何雨

京东“云鼎”探索DevOps之路

DevOps是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。

通过上面的定义我们仍然不明白什么是DevOps？为什么要用DevOps？DevOps有什么好处？等等一系列的疑问。那么我们就来逐一分析。

在进入DevOps实践之前，先带大家先回顾一下软件工程的发展历史。因为我们在工作、学习、生活中所面临的诸多问题，其实只要回头看一看，就会发现我们的前辈早已用他们的智慧解决了类似的问题。我们要做的就是纵观历史，从中寻找到答案。

OK，我们用下面的简图来描述软件工程发展的历史：

20世纪60年代：

软件危机（Software Crisis）— 落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题。

历史背景：20世纪60年代以前，计算机软件是通过机器代码或者汇编语言编写的，其只能在特定的计算机上运行，可移植性，易用性都非常差。当时软件基本上是个人设计、使用、操作、维护、自给自足的私人化的软件生产方式的，其规模比较小，文档资料通常也不存在。

到了60年代中期，大容量、高速度计算机的出现，使计算机的应用范围迅速扩大，软件开发急剧增长。高级语言开始出现；操作系统的发展引起了计算机应用方式的变化；大量数据处理导致第一代数据库管理系统的诞生。软件系统的规模越来越大，复杂程度也越来越高，软件可靠性问题也越来越突出。原来的个人设计、个人使用的方式不再能满足要求，迫切需要改变软件生产方式，提高软件生产率，及时软件危机开始爆发。

20世纪70年代：

历史背景：1968 年北大西洋公约组织的计算机科学家在联邦德国召开国际会议，第一次讨论软件危机问题，并正式提出“软件工程”一词，从此一门新兴的工程学科—软件工程学—为研究和克服软件危机应运而生。

软件工程学主要研究软件生产的客观规律性，建立与系统化软件生产有关的概念、原则、方法、技术和工具，指导和支持软件系统的生产活动，以期达到降低软件生产成本、改进软件产品质量、提高软件生产率水平的目标。软件工程学从硬件工程和其他人类工程中吸收了许多成功的经验，明确提出了软件生命周期的模型，发展了许多软件开发与维护阶段适用的技术和方法，并应用于软件工程实践，取得良好的效果。在软件开发过程中人们开始研制和使用软件工具，用以辅助进行软件项目管理与技术生产，人们还将软件生命周期各阶段使用的软件工具有机地集合成为一个整体，形成能够连续支持软件开发与维护全过程的集成化软件支援环境，以期从管理和技术两方面解决软件危机问题。著名的瀑布模型、结构化程序设计方法也因此孕育而生。

20世纪80年代：

螺旋模型是在瀑布模型和原型模型基础上诞生的。所以我们必须先了解瀑布模型与原型模型的优缺点。才能知道为什么会诞生螺旋模型。

在瀑布模型中，软件开发的各个阶段严格按照线性方式进行，当前阶段接受上一阶段的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一阶段的输入，进入下一阶段，否则返回修改。

瀑布模型强调文档驱动的，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，其主要问题在于：

（1）各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；（2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；

（3）早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成.螺旋模型沿着螺线进行若干次迭代：

（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；（3）实施工程：实施软件开发和验证；

（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。20世纪90年代：

随着螺旋模型的快速发展，为了更好的控制整个软件开发流程和风险。诞生了一系列的管理软件开发过程管理方法。比较著名的就是RUP和CMM。

RUP是Rational统一过程（Rational Unified Process）的简称，它是Rational公司（现归属IBM公司）推出的一种软件过程管理产品。从软件过程模式角度看，RUP又是一种典型的软件过程模式，它以迭代增量式、架构为中心、用例驱动的软件开发方法、采用UML语言描述软件开发过程为主要特征，其中以用例驱动是贯穿整个软件开发过程始终的方法。

CMM(Capability Maturity Model)是卡耐基梅隆大学软件工程研究院(SEI，Software Engineering Institute)受美国国防部委托制定的软件过程改进评估模型也称为

SW-CMM(Software Capability Maturity Model)。SEI给CMM下的定义是：对于软件组织在定义、实现、度量、控制和改善其软件过程的进程中各个发展阶段的描述。这个模型便于确定软件组织的现有过程能力和查找出软件质量及过程改进方面的最关键的问题，从而为选择过程改进战略提供指南。CMM为软件企业的过程能力提供了一个阶梯式的进化框架，目的是适应不同机构使用的需要。这种阶梯式的框架把软件开发机构按照不同开发水平划分为5 个级别：Initial(初始级)、Repeatable(可重复)、Defined(已定义)、Managed(已管理)和 Op-timizing(优化中)。

21世纪初：

为了更进一步的降低软件开发过程中需求变化的成本，所以敏捷的开发思想就诞生了。并且很好的解决了由于需求变更对于软件开发带来的影响。

敏捷开发的原则和方法：（1）迭代式开发（2）增量交付

（3）开发团队和用户反馈推动产品开发（4）持续集成

（5）开发团队自我管理 21世纪10年代：

DevOps是基于Agile和Lean（精益化管理，20世纪50年代由丰田提出）发展而来的一种理念，目的是更好的优化开发和运维的流程，从而更快、更高效的实现产品更新。DevOps是由Development + Operation缩写而来，但绝不是二者的简单相加。引入DevOps需要在企业文化和技术上都要落实一些措施。

我们看一下如下图示：

Business（业务团队）、Development（研发团队）、Test（测试团队）、Operations（运维团队）。各个团队之间都存在厚厚的“墙”。其阻碍了软件产品的按时、按需、高质量的交付。

敏捷的出现解决了业务、产品团队与开发团队之间的鸿沟。通过敏捷保持软件开发工作与客户/公司的目标同步，尽管需求不断变化，也可以产生高品质软件。彻底的打破了业务部门与研发部门之间的“墙”。

有人说，测试者来自火星，开发者来自金星。这是因为软件测试员和软件开发者就好比一对冤家，里面的缘由说不清也道不明。开发代表着创造，而测试则代表着摧毁，因为测试的目的就是以各种方式不断地从开发出的产品中发现大大小小的Bug，长此以往，开发者认为测试者是在故意找茬，两者的矛盾慢慢就会产生。我们如何推到介于开发者和测试者之间的这堵“墙”呢？答案是：敏捷开发 + 测试驱动 + 测试、开发结对。

接下来我们思考一个场景，开发人员把一个软件版本“扔”给墙对面的运维人员。后者拿到该版本产品后开始准备将其部署。运维人员手动修改由开发者提供的部署脚本或创建自己的脚本。他们还需要修改配置文件来适应与开发环境大不相同的真实生产环境。最完美的情况是，他们重复在此前环境中已完成的工作；而糟糕的情况是，他们将引入或发现新的漏洞。

运维人员然后开始进行他们自认为正确的部署过程。由于开发和运维之间的脚本、配置、过程和环境存在差别，这一部署过程实际上也是首次被执行。当然，期间如果发生问题，开发人员会被要求来帮助进行排障。运维人员会说开发团队给的产品存在问题。而开发人员则会回应称该产品在他们的环境下运行良好，因此一定是运维人员在部署的过程中做错了什么。由于配置、文件存储位置和过程的不同，由于是黑盒，开发人员诊断问题也并非一件易事。

没有一个可靠的方式来把环境回滚到此前已知的正常状态。本来应该一帆风顺的部署过程最后变成一场救火行动，经过反复测试之后才让生产环境恢复到正常状态。大家是否觉得很熟悉？如何解决开发与运维之间的鸿沟呢？答案是DevOps。

那现在我们再来回答何为DevOps呢？ 以下这幅图就很好的诠释了DevOps。

对外行来说，容易认为采用DevOps只是一个简单的变化，更像打开了灯泡的开关一样。传统运维的一种极端情况可以被描述为“黑盒运维”。在这种文化中，运维与开发是分开的，相互间一般不合作，就算合作，也是极为不情愿的。其特点就是开发和运维有着相反的目标。开发团队的任务是为产品增加新功能、不断升级产品，并以此制定绩效。运维团队的目标，则是稳定第一。如果没有进行足够的沟通交流，两个团队就会产生矛盾，当开发人员兴致勃勃的快速开发新功能的时候，运维人员可没什么心情去部署新功能。对稳定系统实施任何类型的变更，都会导致系统产生隐患，因此运维人员会尽可能避免变更。

因此需要运维改变是极其困难的，变革是几乎不可能的。只有通过交替的改变，每一个变化将更容易被接受。所以不用进行变革，而是通过一系列文化和技术上交替的变化来进行，最终实现DevOps。

那么京东云计算是如何实践DevOps的呢？我们将运维垂直的分配到各个项目。这样让研发与运维同事都一起工作。这样研发同事就能体谅运维同事的艰难，研发同事也可以理解运维同事的不容易。一年365天，每天7*24小时，随时都Stand By。只有相互的沟通，理解才能打造坚不可摧的团队。

以上仅仅是我个人的观点，希望对大家有所帮助，如果大家在工作中有遇到熟悉的问题，欢迎大家拍砖。

京东基础服务部 技术总监

何 雨

2014年1月22日星期三写于南京