专访金明：如何运用DevOps保证项目可靠、高效实施
我们都知道现在中国互联网的发展速度是非常迅猛的，可以说在世界上也达到了相当的规模和比例。那么在软件行业进入互联网时代后，在整个市场用户对软件产品以及服务的要求也跟着提高，这不仅需要开发和运维人员快速实现，而且要快速部署发布上线，并且必须保证业务可靠、高效运行。那么如何去满足这些要求，加强IT组织需要强有力的流程呢？
金明，ThoughtWorks首席咨询师，拥有多年企业应用与互联网应用开发经验， 热衷折腾新技术，是敏捷和精益的坚定追随者。目前主要关注于持续交付、DevOps、敏捷实施、组织转型以及虚拟化和云计算，同时积极参与开源软件以及国内外软件开发者的大会与社区活动。
以下为采访实录：
记者：敏捷的出现打破了用户、开发和测试之间的隔阂，实现了团队的协作。DevOps的出现和敏捷之间有着什么样的关系？
金明：我觉得这个是一脉相承的，我们传统意义上来讲，传统模型带来的是开发及测试的部门壁垒。随着我们通过像敏捷，像Scrum这样的敏捷方法，在加强开发团队和测试团队之间的沟通协作之后，其实我们不可避免地会面临到开发部门和我们的运维，以及发布运营这样的一个瓶颈。它会取代我们之前开发团队里面所遇到的障碍和瓶颈，我们新的要解决这样的问题。所以DevOps我认为，它从时间上来看，大概是零七年左右在国外开始流行。从它的思想和实践上来看，也是随着敏捷的实践项目继续集成、自动化部署这样的一些实践成熟。它慢慢地流行起来。
记者：他们之间人员的部署情况，开发人员跟运维人员之间，人员角色和职责这块相关事情如何去部署？
金明：传统的意义上讲，我们开发团队，开发完了之后往往是打包扔给发布部门，或者说是运维部门，随着我们对于发布的要求越来越高。我们其实是要求，就是说生产环境的运维部门和发布团队，跟开发部门坐到一起，双方角色互补，开发人员去学习运维的知识和工具。运维去提供我生产环境部署的约束和要求，双方融合形成一个比较一体化的DevOps这样的团队。
记者：目前在云计算上也提供了一些相关的部署，这样是不是能够很方便地推进DevOps？
金明：是，因为传统的，我们之前是说，在虚拟化和云计算出来之前，往往我们的部署和生产运维，而且都是在实体机上面，实体机上面的成本基数很高的。在虚拟化技术出来之后，我一个普通的运维人员，输入命令就可以得到几台这样的虚拟机。当这样的工具出来之后，我可以再输入命令就会拿到一个完全一样的环境出来。所以我们来讲，随着虚拟化和云计算技术，以及周边的管理，像自动化创建工具这样的成熟后，DevOps就传统的运维技能会变得越来越大众化，可以被我们开发人员所接受、所拥抱，再用到环境里面去。
记者：很多开发者都认为，迭代项目管理方法Scrum是敏捷开发的代名词，DevOps您认为用什么来做它的代名词比较合适？
金明：我觉得目前不足以说，就是还不足以说出现像Scrum的这样的一个方法论里面比较典型的方法，我就说方法。因为DevOps还是以工程实践为主，管理实践这块，像Scrum成体系的还比较少。目前各大工具是正在慢慢演化的过程里面，我们看到的刚才讲虚拟机配置和我们来讲部署，各自有各自的工具来做。目前还没有看到说，从底向下，整个打通的DevOps的方法论。
记者：开发人员和运维人员认识的方法，以及各自所处的角色，都存在根本性的差别。如何通过DevOps来解决他们之间的一些开发部署的问题。
金明：那我就举个例子，像我们之前在国外的项目上面，之前他们开发和运维是分开的两个部门，项目之间通过一个发布包，做出一个FTP这样的去沟通。其他团队把包放在FTP上面，然后运维从FTP上取下包去部署。这个导致的问题就是，很多生产环境下面的环境配置，这样的一些软件要求，跟开发的时候不一样。我们现在做事的方式是，就是说从发布团队和运维团队里面，它会变成一个池子，里面每个成员会变成具有DevOps能力的成员。DevOps成员是作为团队的一分子参与到开发团队的日常工作里面去，它的几个主要工作职责会包括，第一，它会帮助团队把他们团队对环境的配置、对环境的要求，用一些工具把它变成代码，变成自动化的。
另外一个就是说，在生产环境下面会考虑到可用性、考虑到安全、考虑到运维的要求。它会把这样的约束条件灌输给团队，团队在设计系统的时候就考量这一块的约束情况，这样的时候实施就会更好一些。
记者：很多人都认为DevOps是一个非常强大的方法论，它可以在众多不同层面上产生共鸣。您认为开发人员和运维人员应该如何去落实DevOps？需要具备哪些条件？
金明：在我们公司的话，DevOps也会变成是一种角色，就像我们开发测试一样变成一个角色。很早的话跟团队一起来工作，然后考虑我们像环境自动化、配置自动化，以及我们部署自动化这样的事情，很早会作为团队的一份子参与到这里面去。
就相当说，假如说一个传统的团队，我希望往DevOps这块去转型的时候，可能要一些这样的先决条件。在整个过程可能要有些这样的挑战和问题要克服。的确是说，开发和运维其实是两种不同的技能，开发的头脑里面就是我赶紧把代码写完，扔给运维就好了。运维的头脑就想着，我这块要是出了问题，那我就可能睡不着觉，每天晚上接到电话起来维护。
其实来讲，两边对对方存在一些这样的误解，很大的原因就是，大家对于各自工作是不了解的，他不知道运维需要做什么事情，我只看到运维可能有这样的一些报表，有这样的投影，投在那里说系统实际是怎么样，有没有出现问题。运维看到开发团队在那边写代码，也不知道在做什么事情。要想在团队里面实施这样的运维，DevOps的话，其实我们觉得它从文化和技术，或者是技能两方面都要提供相应的辅导。从文化层面上面来讲，就要鼓励我们的运维和开发人员坐在一起，互相地分享。因为团队的目标还是一致的，我把系统更快的部署到环境上去，让它能够稳定安全地运行。从文化上面来讲，首先要让大家理解这样的一个，大家是共同的目标，不是说势如水火。
其次的话，要营造出双方相互协作的一个情况、一个场景。就是文化上面，然后从场景和技巧上面来讲，除了双方对于各自技能的掌握和培训之外，我们发现还是有一些前提条件是比较满足的，比如说我们来讲企业集成。我们需要自动化测试，只要我们能够在团队内部把企业集成和自动化测试先做到一定程度的话，比如说我们可以有信心地拍胸脯说，我们这个软件没有太大的问题。在这样的情况下面，我们再引入DevOps做这个，从软件交付的角度来讲，会是比较好的一种方式。否则的话团队整天在修复缺陷，这时候我们的运维和开发坐在一起可能没有太多的意义，这是第一。
第二就是说，如果我们不是这么全局来看，我们是从局部优化来看，我们可以看到运维团队在系统配置、系统创建这一块的技能。它也是非常必要的，因为我们发现开发团队，不管是开发还是测试，它其实有一个很严重的问题，他们要想做调试、做测试的时候，环境是不够的。可能这个环境做完一套测试之后，环境就被污染了、数据被污染、我的应用包被污染。在追求环境的准备和提供方面，其实我们的运维是可以进来，或者是我们的DevOps团队是可以形成的，然后去做一些相对来讲没有那么广的事情，还是跟在这一块上面。而这个前提条件就可能是我们这样的一个架构也好、技术也好，能够比较好的支持我们DevOps去做基础设施代码的工作。
跳出这两种方式，两种场景下来看，如果在一个组织里面想去推DevOps的话，其实上层的支持是必不可少的。上层要有这样的决心和魄力，我们来挑个项目，我们从点击项目开始，我们试着哪一个运维团队的成员跟开发团队坐在一起。然后看看如何在双方的磨合过程里面，能够取得一个比较平衡、比较优秀的结果。其实也看到这样的情况，有一些组织，尤其是互联网组织，他们的CIO就会喜欢拉一个团队。从运维里面拉一两个人出来，那就专门做环境自动化，就设计代码这个工作，去帮助他的开发团队里面，去准备测试环境的，一键式搭建，一键式配置的事情。
记者：在前些时间，IBM的一个技术峰会上面，我看到了很多人都在在讨论着一个DevOps的主题，他们认为DevOps已经成为帮助企业实现移动和云计算转型的关键。你是怎么认为的？
金明：这是一个非常大的概念和论断，从大层面来讲，我是基本赞同这样的一个论断的，为什么呢？随着移动应用和云计算的兴起，其实给我们开发带来两个大的变化。一个是开发这边的复杂信息降低了，我们传统意义上的互联网，比如做个网站，你前后端代码可能是几十万行、几百万行代码，出现移动互联网的应用可能就是很少的一些代码，轻量的这样一个应用。
从这样的角度来看，在传统意义上，如果说去对我的应用做测试，去做集成，它所暴露出来的问题就不是整个移动应用去运维业务上面的大问题。相反我如何能够快速的开发出来，然后发布出去，然后积极反馈、修改，再快速发布出去。这个变成我们移动应用能否在互联网业务上面取得门传票的这样一个很关键的点。从另外方面来看，从云计算来看，它虚拟化技术又给我们带来背后的，基础设施这一块的轻量化。技术和应用轻量化，加虚拟化和背后基础设施的轻量化。这就迫使我们在如何融合双方的节点上面，来提出更好、更先进的工具和技术，DevOps就来帮助我们解决这个问题。
记者：其实我知道目前大部分的互联网行业企业都能够适用DevOps这个方法论，或者说有开发部门、运维部门这样的一些企业。那么DevOps在传统的企业它能用上吗？
金明：这个问题，我想这样来看，DevOps类似于我们敏捷方法，它其实也是跟思想原则和具体的实现，DevOps它的本身的这样一个思想和价值观就是说，让我们的开发和我们的运维也好，或者说我们的实施也好，让他们能够更好地，双方能够消除各自领域的浪费。从原则上来讲，就会有一些像基础设施代码、配置自动化等等这样的一些原则。
我想对DevOps来讲，不管是传统行业，还是互联网行业，或者是移动应用行业。其实它的原则和思想都是适用的，是通的。但是在具体上可能会有些差别。举个例子，应该是爱立信，爱立信之间有这样的网络设备，网络设备整个的需要开发，上到板子上面，部署到机房里面去测试。之前的话会出现一个问题，它在实验室的板子上面烧的程序是可以工作，大概到生产上的板子，实际上的板子，它也是不能工作的。于是他们针对这个问题，也是做了DevOps相关的这样一些活动，把生产环节和实施上面的，这样的一些问题和要求，提早地告诉给开发团队。让开发团队在他们的实验室里面，就按照生产环境准备相应的板子和规格。在开发的时候，就按照跟生产环境几乎一致的板子来验证他们实际是否是一样的，这也是DevOps良好的一个使用场景。
如果存在多套不同的环境也好，或者是碰到不同阶段，比如说我们开发调试构建，跟我们今后的运维，或者说实施，这样的阶段其实他们都会这样的优化和改进的空间，双方的一个融合，就是DevOps这样的一个空间和土壤。
记者：之前我也了解过，在ThoughtWorks公司里面的一些项目也用到了DevOps持续交付。在这个过程当中，你们公司在实施的过程当中，你们遇到一些什么样的问题？
金明：这其实是一个现在很多人会关心的问题。就是说DevOps虽然给我们承诺，或者是许诺这么良好的一个愿景，在具体过程会有些什么问题？在我们做的时候也是遇到一些相对的问题？现在我讲讲最主要的几个大的问题。
在我们传统的像软件架构的设计和它对于这样的配置，环境配置、像数据这样的一些管理的工作，并没有达到一个比较成熟和稳定的地步。导致的问题是什么？比如说我们曾经遇到这样的一个项目，这样的一个系统。这个系统包括十几个这样的不同系统组成，不同的系统使用的技术又不一样。有些系统，甚至是没有人能知道他上面的配置信息什么样子，因为这个已经太早了，用了比较早的语言来写的。所以这块信息的丢失，其实对于我们DevOps来讲，就会导致走很多的弯路，很多这样的一个尝试。但是其实正是因为DevOps，反而才能解决我们之前像这样配置信息丢失，架构不合理，分成和我们的模块不合理，这样的情况。所以这也算是DevOps给我们带来反向的一个优势，让我们很好地审视我们之前的交流设计、我们的发布、我们的环境配置是否是经过仔细考量和设计过的。
记者：你能阐述一下你对DevOps前景的发展是怎么样的？