大家好，我是来自CA Technologies的王志明，今天很开心能跟大家分享一个最近大家都十分关注的一个议题，我们称之为DevOps，DevOps本身是由两个词组成的，Development和Operations，在接下来的时间我会跟他们分享DevOps的一些点点滴滴，包括它的历史，包含什么是真正的DevOps，以及CA对DevOps的诠释。

现在让我们来看看DevOps的相关一些细节，DevOps中文我们称之为开发运维，首先我们来看这张图，这张图上有很多角色，我相信各位在各位的工作当中常常遇到相关不同角色的一些同事，甚至您可能也是这张图上某一个角色的在职人员，我们看这张图上有什么角色，比如说我们的开发人员，我们的环境准备人员，我们的测试同事，我们的运维同事，以及负责应用资源的一些同事。

我们来看看这些评语是否在日常的工作中常常听到，比如说我们的开发同事常会告诉我们说，我用了70%时间来等待，开发同事常在等待的一些东西包含了比如说业务的相关需求，比如说相关的一些测试的资源，相关的一些数据，这些都是开发同事常常在等待的一些资源。

接下来我们看看环境准备的同事，环境准备人员常常遇到的问题就是我们没有多余的环境了，这个项目组跟我要这个环境，那个项目组也跟我要环境，但是我的资源是有限的，我没有办法在同一时间满足大家的需求，这是常常我们环境准备同事所遇到的一些挑战。而我们的测试人员常常告诉我们说，我们的测试环境不够真实，我所需要依赖测试的一些第三方的资源，内外部的也好，常常都是不够真实的，因为这些资源没办法在我们需要进行测试的时候提供出来，这是我们的测试同事遇到的挑战。

Level 1运维的同事常会告诉我们说应用发布就是噩梦，当他们进行应用发布的时候常常需要熬夜加班，需要把所有的不只是运维的同事，甚至我们的开发同事，我们的一些测试人员也抓在一起，今天晚上大家坐下来就来进行这个应用的发布，这常常是一个噩梦，因为他们必须要在系统的控制时间，比如说3个小时内把所有的发布工作进行完成，而且要经过相对的验证，如果遇到问题需要进行回滚，这些都是他们所常常遇到的一些噩梦，一些挑战。

应用资源的同事更惨，常会告诉我们说现在有问题了，我的使用者有问题了，但是我应该去哪里找到问题，我应该怎么样把这些问题找出来，里面缺少了一个很重要的角色，我们来看看，对了，就是我们的业务主管，业务主管常常会对IT部门说你们IT在做什么，我们正在错过外面所带来的业务的机会，我需要新的应用，我需要新的功能，你们都在干嘛。

我相信这是大家常常听到的评语，或许跟各位的工作息息相关，或许你昨天才遇到相对的问题。好了，接下来我们来看看我们应该怎么做，我们应该怎么解决。

我们先看一个数据，绿色的线条是代表现在业务所带来的一些需求，我们都知道IT都在变革当中，特别是现在大家在谈论的就是应用经济，所有的公司都是IT公司，应用经济所带来的机会是巨大的，但是很多时候我们发现我们本身的创新，我们本身没有很好的能抓住这些机会，其实这是由于IT创新能力的低下，试想一想在二十年前大家开发应用的时候是用同样的一套方式，在二十年后的今天当我们在开发应用的时候，我们来进行我们的应用运维的时候，其实我们所作所为还是一模一样的，这个部分是IT需要补足的差距。

针对这一点Forrester进行了相关的调研，我们来看看这个调研的结果，我们先看一看它访问了一些不同角色的人员，在这些人员当中39%的管理人员和企业战略的人员认为IT能按时按预算提供新的服务，这也代表着61%的管理人员其实不认为IT是有办法能按时按预算地提供相关新的服务，这是一个很悲哀的数据。

我们再看一看制造和供应链的同事只有25%的同事们认为说其实IT有办法按时按预算提供新的服务，我们可以从这张表上明确看出来，其实在一个企业里面除了IT自己本身的同事，IT的从业人员就如你和我，觉得我们是有能力提供这些服务的，我们是能按时按预算把这些服务交付出来的，除此之外其他的同事们基本上不看好我们，也不认为说我们其实有这个能力的。
我们再往下看，这张图告诉我们大多数的决策者，75%的决策者可以认为我们是有必要提高整体IT的效率，他们认为IT的效率是有问题的，IT的效率包含创新的能力，包含了简化的流程，包含了我们工作的效率，他们认为是有必要提升的。

接下来我们看一看这个问题应该怎么解决，我们都知道IT部门的骨干是有两个最主要的工作部门组成的，一个是研发，也就是开发，另外一个是我们的运维部门，也就是operations，我们来看看研发，其实研发的同事常会有这个思维模式，如果您碰巧在研发的岗位上您或许也有相同的思维，比如说研发同事常会说我们需要快速地创新，我们需要写简易的代码，我们需要用最新的技术来增加更多的功能在我们的应用上面，这是研发同事的思维。但是运维的同事他们有另外一套思维模式，如果您是负责运维的或许您会觉得我需要我的系统稳定最好是十年都不做任何的改变，那是最好的，我系统能稳定地运行。我要完善的安全机制，我要更简易的管理步骤，这是运维同事的思维模式，我们可以明确看出开发与运维的同事在思维模式上是有明显差异的。

我们再来看一看运维人员与研发人员当在看双方的时候会怎么样，左手边的图告诉我们这是运维人员所做的事情，右手边是我们的。

接下来我们来看看运维人员与研发人员之间的差别，左边这张图是当我们的运维人员看我们的开发人员的时候，在运维人员眼中开发人员就是每天不同的逻辑，每天的图打交道，而右边这一张是我们的研发人员看运维人员的时候，你们就是每天跟机器打交道，我们可以发现说在各自的观点当中对对方的工作以及对方关注的事情其实是有完全的差异点的。

而如何把这双方的差异点整合起来，就是DevOps本身的精髓，DevOps是由研发、Development与operation这两个词所组成的，它所要达到的目的是能确保稳定的创新，我有简易发布，我有简单的安全管理，我有简易的功能，我有Agile的规划，我能很好地使用敏捷开发来交付我的应用，敏捷运维来运维我的应用，这是DevOps整体的观念。

我们来看一看DevOps本身的演进史，一开始的时候DevOps有两个运动组成的，第一个运动我们称之为敏捷系统管理的运动，这个运动的触发点是这个Velocity Conference的一个会议所触发的，这个Conference会议在2008年举办，而且这个会议最主要的内容是讨论相关于Web的运维，以提高整个web运维的效率。经过这个会议之后，在2009年的时候由Gordon Banner这个人正式地推展敏捷系统管理的运动。另外一个对DevOps的历史有影响的运动叫企业系统管理的运动，这个运动在2000年中旬的时候就开展了，它是由这两个人John Willis和Mark Hinkle开始的，这两个运动的结合体也就是称之为DevOps的运动，这个DevOps的运动也就衍生了第一届DevOps大会，第一届DevOps大会是在比利时的根特举办的，在这个会议上Andrew和Shafer这两个DevOps的始祖就跟大家分享了整个DevOps的概念，以及DevOps所需要达成的一个目的。

这个会议是2009年举办的，我们可以发现说其实DevOps大会现在为止已经连续举办了很多届，而且DevOps其实在2009年的时候已经开始在世界的整个IT舞台上得到相对的一些专家学者们的关注，而国内在这几年也渐渐开始了对于DevOps有相对的讨论，更有相对的关注了，这是整个DevOps的历史。

我们来看一下其实DevOps没有一定的定义，这上面是我们去找了一些相对的数据，一些资料之后，我们发现有一些人说DevOps是一组流程，有一些人说DevOps是一个概念，有一些人说DevOps是应用开发和系统运维团队执行任务的混合体，有一些人说DevOps是一个新兴的软件集成以及IT业务的沟通协作方式，一个原则。

其实这些都是正确的，这些的出发点是为了确保我们提高整体IT的运维，IT的研发，以及IT的交付能力效率所产生的一些说法，或是所定义的关于DevOps的一些解释。

我们分析了以上种种之后，我们发现到底DevOps是什么东西，DevOps是一个方法，DevOps强调沟通，DevOps确保集成能顺利进行，而且是一个协同的方式，它当然包含了我们的开发与我们的运维。在整合了这些说法之后，我个人觉得DevOps其实是一套增强开发集运维之间的集成协作，以及沟通的方式，它其实不是一套工具，它其实也不是透过单一的方式能实现的，基本上DevOps需要透过一连串的流程以及当然一些辅助性的工具来达到整个开发以及运维很好的协作，这是我们对DevOps的理解。

DevOps可以更快地交付业务的价值，在服务交付的过程当中打破孤岛，也就打破开发及运维之间沟通的成本，我们必须要整合我们的开发和运维的团队成为一个协作团队，他们不再是开发，他们不再是运维，而他们是IT的团队。

DevOps最主要专注的是端到端的服务交付，流程的变革，如何由开发快速地开发完我们的应用之后，交付到我们测试同事，在测试过程中如何快速进行一些测试，而把一些我们的限制移除或者是把一些我们的限制解决掉。当我们测试完毕之后如何地快速把应用交付到我们运维同事，部署到我们不同的环境上面，而当我们的运维同事在进行运维的过程当中如果应用发生了问题，如何快速地把这些问题找出来，而且把这个问题点快速地回馈到我们的开发同事手上，让开发同事能针对问题点把这个问题解决，重新快速地交付到我们运维同事，上到生产环节上面去。以及一些新的应用，特别是现在大家在关注我们互联网的一些应用，甚至互联网的思维大家在关注这些运动的时候，或者这个趋势的时候，如何快速地把应用推出市场，如何快速地交付新的服务成为一个IT现在不可避免所需要面对的一个问题，而DevOps恰巧就能协助各个企业解决这个问题，快速地把应用交付出来，特别是一点我们大家要关注的，当我们在实现整个DevOps的交付过程当中，我们必须要确保这个流程的变革，或者是新式工具的推广，或者新的工作流程的推广的时候，我们要确保这些推广是不影响我们的安全性的，不影响我应用的兼容性，以及不能影响我应用的性能，这是DevOps所需要带来也是所希望带来的一个价值。

接下来我想跟大家分享一下，对于DevOps的终极目标，我们称之为持续交付，我们都知道刚才我跟大家分享过的DevOps是如何打破信息的孤岛，让我们开发与运维同事更好协作起来，更好协作起来的目的是确保说应用能很快速地由开发流转到我们的测试，由测试流转到运维，运维遇到问题的时候能建制一个完整的闭环回到我们开发的手上。

让我们来看看持续交付是什么，我相信一个应用的开始都是由开发人员开始把我们的应用开发完成了，当然我们前端还有我们的相关业务部门，业务部门把这个需求提给开发，开发的同事分析完需求之后进行他们的开发，开发完之后相关的代码我们会放到我们的代码库上，这是大家现在常做的做法。

在一个持续交付的观念里面，放代码库之后我们应该有一个持续集成，也就是Continuous integration构建自动化的一个平台，这个平台你可能可以使用一些开源的工具或者是使用一些现在市面上一些持续集成的工具，甚至使用一些build的工具来进行建制持续的集成。

持续集成的结果也就是我们的工件，工件我们可以存到我们的代码库上，存到代码库之后我们应该让我们的持续集成工具开始来呼叫CA的一个解决方案，我们叫做CA Release Automation，CA发布自动化，我们应用发布的解决方案，我们的这个解决方案将会由工件库把最新的工件取下来，这工件可能是我们的ear file, 可能是我们的war file, 可能是一个jar, 可能是我们的一个exe ，我们就在这个工件库把这个应用最新相关的工件取下来，取下来之后我们会自动结合到比如说我们发布到我们的SID的测试环境，我们会结合这个环境的发布清单把相关的应用透过一个已经定制好，已经定义好的发布流程，发布到我们SID环境上去。

下一个问题来了，在正常的状况底下我们是有手工进行这个SID上面的测试，一个验证的，但是为了实现持续交付的目的自动化的测试变成必不可缺的一个环节，在这个环节上我们的自动化发布解决方案能呼叫我们下一个解决方案叫做CA Service Virtualization，CA服务虚拟化包含了两个部分，第一个部分是测试的发起端，它包含了录制网页的一些测试脚本，也包含了一些比如说我透过传输协议直接发起的一些测试，甚至它包含了一些我们移动终端的一些应用的测试，比如说我手机应用的测试，我的手机应用当然包含了安卓，甚至苹果平台的一些测试。

但是，它也包含了另外一部分，也就是它能把比如说我们测试过程当中我们应用所依赖的第三方的一些内外部的资源，比如说银行我需要接到人行，我需要接到银联，我需要接到一些第三方的比如说对手行的环境上面，甚至我一个网银可能我需要接到我核心的时候，我们能透过服务虚拟化这个解决方案把我们一些所依赖的资源透过一定的手段把它虚拟出来，这样子我就能达到真正的自动化测试，我们启动了，当然在这个部分我们启动了我们的服务虚拟化之后，我们的服务虚拟化解决方案能自动针对这个SIT的环境上面所部署的应用进行一个自动化完整的测试。

在测试过程当中如果一切顺利的话，下一步它会回馈给我们发布自动化的解决方案这个平台，我们发布自动化的解决方案将会针对下一个环境，比如说我们UAT的环境，针对这个环境的一些参数，一些环境的配置，跟我们当初所测试的工件做一个集合，集合之后我们发布到UAT环境上面去，发布到UAT环境上面去同样使用我们的服务虚拟化解决方案，直接的自动化进行完整的测试，这一连串的工作我们甚至可以在不同环境当中，无论你是有三个环境在到生产之前，或者是你有四个环境，或者是你只有一个环境，我们都能自动化地进行。

当然如果在过程当中，比如说我在这张图上所示的这个预生产环境，如果遇到任何问题，比如说我测试过程当中发现某一个问题，某一个错误发生了，我们能自动地回滚，我这个CA的自动化发布的解决方案，我们能自动把这个应用回滚成旧的版本，而且是在各个环境当中，自动地都回滚成旧的版本上面去。

如果一切无误的话，我相信在很多企业，在很多单位，当我们上到生产环境之前是需要经过相对的一些审批流程的，当然在我们的生产环境上可能你会有一个变更管理的平台，可能你有一些配置管理，一些基础架构管理平台是需要做相对的一些配置的，我们的这个解决方案是能跟这些平台做相对的集成的，当我们得到相对的审批或者得到相对的许可说全部已经配置好了，变更管理领导也审批了，我们其实能把这个应用发布到生产环境上面去的。

好，那在接下来我们这个平台会拿同样的工件结合同样环境发布清单，把这个应用完整地发布到我们生产环境上面去。在生产环境上面我相信很多企业现在遇到的一个挑战是，当我们把应用发布到生产环境上面的时候，我们是没有办法进行任何流程或者是交易测试的，原因很简单，因为在生产环境上我们做任何测试都会影响到生产的数据，我们在生产环境上如果我们测任何跟比如说第三方连接的一些交易，都会把这个交易真的发到第三方上面去。

所以变成往往我们发布之后是没办法进行完整的测试，只能等到隔天真的使用者上线的时候，真的在使用的时候我们才可能发现一些问题。但是在现在高竞争的环境底下当你发生，或者是这个问题已经发生了，你已经发现问题的时候，已经太迟了，所以透过我们的服务虚拟化解决方案，当我们发布到生产环境上面去的时候，其实我们就能开始进行一些相对的验证了，在这个使用的场景底下除了我们的应用是真实的，我们的发起端，我们的接收端其实都是虚拟的。在这样子的状况底下我们是有办法也有能力进行完整的应用的交易测试以及确认的，当一切无误之后，我们当然能通知相对的一些同事，相对的一些领导们告诉他们说这个应用在昨天晚上或者在什么时候已经发布完成了，这次的发布包含了哪些功能，一切正常。

而且另外一点，我们这个发布解决方案的一个特性，我们在发布过程当中把所有所做过的一些动作，所进行的一些工作，所有都完整地记录下来，供后续的这个发布报告分析，这个发布报告可能就能协助领导们或者是一些相对同事们来确保说来分析我们这次发布到底进行了哪一些工作，发布到底成功与否，或者是某一个应用一年发布了几次，在某一次发布的时候包含了哪一些东西，成功与否，其实这些都是我们所能够记录下来的数据。

以上其实就是DevOps的终极目标，也就是持续的交付。谢谢大家今天的时间，我相信经过过程的一番解释之后大家对于整体DevOps到底是什么，以及CA对DevOps本身的解决方案到底有哪一些已经有了一些深入的认识，其实CA在这几年来一直在DevOps进行了一连串的布局，我相信各位也能看到说我们的解决方案相对成熟的，我诚挚地希望各位能选择CA帮助大家在DevOps这条路上走得更顺利，谢谢。