中国IDC圈2016年9月6日报道，9月1日由工业和信息化部指导，中国信息通信研究院、中国通信标准化协会主办，数据中心联盟承办的“2016可信云大会”在京隆重召开。在可信云服务性能和运维论坛上，开放运维联盟联合主席、高效运维社区发起人 萧田国发表了题为“DevOps运维理论与实践”的演讲。以下是演讲全文：

开放运维联盟联合主席、高效运维社区发起人 萧田国 

我分享的题目是“DevOps”，大家知道DevOps特别火，前段时间有一篇文章，说DevOps已经八年了，为什么还没有落地？但实际上我们发现一个趋势，从去年开始，去年的四五月份开始至今，我们发现在整个互联网上，我们运维方面有很多产品，现在DevOps在传统行业的落地，实际上已经是可以预见的。今天我的内容是关于我们认为DevOps理论在运维面对的一些理论和实践。

我是萧田国，我是5月18日从之前的公司出来的，到现在已经三个多月了。我做运维完全出来是几个月，但是我之前做运维有一年时间，做社区也有两年时间，我也做了中国第一个运维社区，做了中国第一个运维行业协会，包括做了第一个运维行业大会。今天我们的同学在这里坚守的不容易，如果有人愿意参加我们9月23日上海站的话，我个人会送张门票。然后跟一些朋友做了运维第一个解决方案和运维的节日。

今天我主要分享三个方面，第一，DevOps在运维侧是怎么理解的。第二，DevOps运维平台的架构。第三，云服务持续交付的实现。为什么会出现DevOps这个概念？为什么之前有很多这样的问题，我们说在以前的时候，根据传统的物流形式，一个产品的出台，一个版本的出台分为三步，首先是开发，开发以后是测试，测试以后是生产，但是模式问题就是首先产生一个部门墙，开发、运维、测试就偏离了，他们之间相互指责，运维、开发不管最终版本的上线，所以它有足够的接去推托，就是因为你的运维部署开发，导致我没有机会把问题发现出来，这就是一些坑在里面。后来程序的更新方式也改变了，就变得更加敏捷了，在敏捷时代的时候，我们看到开发和测试，它们之间会交互。但是问题在于他们两个玩得很开心，最后的结果还是一股脑提供给运维这边，运维者跟运维部门还是割裂的，意味着并没有改变根本问题。如果版本更新很频繁的话，很多锅还是由运维来背。所以基于此，在大概七八年间开始，谷歌就开始做很多事情了。后来这个模式就叫做DevOps，就是说把运维、开发、测试放在一起了，他们是一个团队。这个时候他们实现的是一个快速的迭代，我们说DevOps价值在哪里？价值就是敏捷的实现业务的快速交付。我们说句人话，什么意思？原来你的公司可能需要半年发一次新版本，你基于DevOps做了一些事情之后，你发现你可以一周发一个版本，甚至一天发多个版本，而不是像以前小批量的发布了。所以DevOps就变成一种敏捷式快速迭代的发布，但是具体怎么实现的，实际上也跟最近这些年来新出的很多概念，很多产品以及技术机制是有关系的。

那我们怎么在运维这一侧理解DevOps，我们认为作为DevOps而言，首先是开发能力，它延伸到运维，其次反过来运维也把它的某种能力传递到DevOps，我们这里人很多，我问大家你觉得如果要做一个DevOps，到底是运维出身的人合适，还是开发出身的人合适呢？我认为可能运维做DevOps更加合适。但是最近我们在做培训的认证，我们发现一个问题，就是说运维实际上也会有问题，我们对所谓的敏捷方法还是知之甚少，所以说这也是以后还有一些我们的机会怎么做更加高效的DevOps的关键所在。我们运维理解DevOps的时候，应该是以自动化过程为核心理念，因为只有自动化才有机会实现快速的交互和迭代，这里面有很多工具，还有很多流程，还有作为DevOps它是一种文化。但是不管怎么样，它首先是自动化的过程，那么怎么实现DevOps呢？我们认为应该是分为一体两翼，首先是一体，一体里面首先是需要对运维很多工作做标准和规划，然后做优化和架构化，然后再实现一个无障碍化，这是一体，后面我们再去做一个平台自动化和数据化。一体两翼我们可以把它简称为鸟人，所以接下来我们看一下DevOps的运维平台，应该是怎样合理的整体架构。

运维实际上没有我们所想象的那么容易，运维不仅仅是搬砖，搬服务器，也不是说到目前为止就没得搬了。我们说首先我们来看一下运维整体价值何在，运维应该是提供四大机制，那就是质量、成本、效率、安全，它应该有各种各样的服务体系，性能优化、安全优化、还有成本，以及相关的程序，标准化、规范化、方法论，最后落地是平台体系，数据平台、安全平台、运维平台，运维平台是承载着我们价值最后的实现。那么我们从面向场景看一些运维，包括为了实现场景以后我们把一些服务和能力做抽象提炼出来，所以这是我们这样的环节，就是说由角色到场景到我们能力的抽象。如果说要把我们运维自动化做得更加好一些，其实它会注意到一个事实点，公司很少会给我们足够的时间，如果我们在公司跟他说，我们运维平台需要两年时间，那可能在半年以后你就得走人了，公司会等不及的，那么怎么更好的做一个运维自动化呢？

我们建议是这样的，首先要识别痛点和瓶颈，哪儿有问题，我们从哪儿下手。实际上一般情况下，我们说痛点和瓶颈更多就是一个版本的更新，所以我们应该首先做自助化，基于此做自动化，自助化流程，可视化PI。这是一个运维的模型，一个能力的分层结构，首先它有一个基础这时层，运维包括IaaS、PaaS、OIS层，这是运维对外提供的服务。在我们考虑到高效服务自动化的时候，为什么在最近这些年特别火，就因为很多底层的事情，已经不是由我们运维自己做了。因为当我们聊到自动化的时候，如果你自己看服务器上架的话，是不现实的。正因为有各种各样公有云、私有云服务的，所以它使得我们快速交互成为一种可能。然后在上面我们把通用能力层和平台能力层都作为PaaS交互，通用能力层就是把DNS名字、配置数据、附载均衡和资源都抽象成服务，抽象成服务的好处就是减少对后台人员的要求，如果你要重启服务器上面的进程，如果还需要对服务器使用权限的话，是很不应该的实行，那怎么办？我们可以去对API，或者对操作器调用，这就是我们服务化的能力。基于此它们才有拼接，他们才有IT运营和安全。

但是，这些还不是运维对外最直接的产出，我们的产出实际上是在这儿，是运营能力，包括我们的成本优化，还有业务体系优化，还有用户体验的优化，我们说用户体验优化是用户产品体验的优化，比如我们可以举个例子，假设我们公司是做游戏的，这个时候我们应该能够提供服务，就是我们能够从底层看得多哪些玩家它下载游戏包的时候很慢或者很快，很慢的我们看是不是中断了，如果很慢的话，我们可以向它的邮箱发一个流程。当然用户对体验优化里包括什么呢，如果他下载的时候，你可以给他限速，或者你可以根据运营商配合，可以提速，这个单个用户级的是可以做到的。

如果说我们把平台扩展的话，这个时候我们说的运维平台就更加复杂一些了，当然这还是基于我们刚刚的蓝图。这个时候在底层还是IaaS层，IaaS层还是没有变，当然我们的运维价值以后一定不是IaaS层，因为IaaS没有了，已经被他们彻底干掉了。IaaS以上是配置管理层，但是我们所说的DevOps并不仅仅是基础的管理，还包括业务信息的管理，包的配置包等等，还有组织管理，人员信息管理，因为他们有时候都会用到。基于这些东西，往上以后，我们说到了这个时候才会有具体的交付，以及往上大家看到的就是小小的出具了，最后向老板出具的可能就是数据，老板看到数据的变化就是可视化了。但是在简单的数据背后，运维要做很多的事情。

很多公司关注的就是持续交付，持续交付、持续集成、持续部署，导致很多人质疑说我都不知道持续交付是什么。当我们学习一个新东西的时候，最好的方法就是从字典或者标准去找，看看它的原始定义是什么，这样可以避免被别人忽悠的神乎其神。持续交付实际上是一种全面的工程实践，它试图用最小成本，最快速度实现端到端面对用户的交付，或者它的价值就是能够实现持续的用户交互，当然持续我们有时候认为有一些问题，我们叫快速就可以了，因为持续是外传过来的。可能有人会问，持续交付和持续部署有什么区别？持续交付本身并没有涉及到自动化，并没有说我的部署过程需要做整个自动化流程，我们说持续部署是持续交互的高级阶段，意味着如果你的持续部署是基于一些自动化的实现，那么它就会成为持续部署，如果说你再把测试环节加进去，就会成为持续集成，这是三个词的区别。

当我们谈到持续交付的时候，为了实现最终的目标，就是价值的交互，我们整体架构里面做的持续交付是很多的，基于此才会产生出所谓平台管理，能力管理，过程，可视化平台，交付平台，监控平台。然后在这些基础上，才会有版本更新以及内部的改变。当我们要实现作业自动化的时候，大家知道数据库版本的自动更新是整个业务的核心，它也是会有问题的地方。我们的方案是长DevOps成为当中的一员，我们希望能够自动化整个流程，还有测试、审查。

我们看一个例子，基于DevOps持续交付是怎么实现的？在基于这些理念，我们做了这样的事情以后，开发者可以上线几个代码，他可以直接用IE浏览器直接点开访问。当他把他的代码聚焦到服务器上的时候，变成它会向后台，向我们系统发出一个指令，后台系统一般情况下会进入静态层，静态层获取代码，做自动化构建，自动化测试和打包，像这是一整块的。如果这时候你的代码是标准代码，这时候自动化构建就可以使用。这个时候它就会把代码自动部署，部署到开发环节、测试环节、生产环节。这就是我们说的持续交付流水线，大家说如果是持续部署的话意味着什么，意味着自动化完成了。这个好处是什么？这个好处是使得开发和运维没有办法再扯皮了，这其实是真正的价值所在。像以前的时候开发老说，我的版本，我早就做好了，结果运维上线前一天才给我部署上去，你看我好冤的，我太难受了。现在程序优什么bug，你一旦更新一个CCS这样的，你都会自己过一会儿看到代码，这个时候就意味着自己挖的坑，自己也要往下跳。而且开发不仅可以更新开发环境，测试环境，甚至可以更新生产环境。这时候带来的就是团队的效率提高，所以这也是为什么很多公司它对于DevOps很在意，它觉得这个东西很爽，很好的原因所在。

我们把刚刚的情况做一个PDCA的理解，这个时候用户会产生它的需求，这个需求被我们带入到持续集成和持续测试里面去，然后构建人工库，再进行持续交付运营，然后形成一个闭环。这是我们的理想的结构，但是现实和联想往往有很大差距的，对于传统企业这也是可望而不可及的事情，如果数据是orico，如果要实现对DDA操作自动化还是很危险的事情，因为有可能你的数据库是很庞大的。但是这是一个趋势，而且趋势的意义在于传统行业要向互联网转型的时候，互联网业务可以基于DevOps做一定的实现。

我们知道谷歌SRE很厉害，但是实际上SRE是DevOps的最佳实践，他们是在很多年以前，提出来这个观点，当然在国内开始有很多公司模仿，我们也知道SRE，但实际上有问题的，因为SRE的S是站点的意思，但是国内很多是系统，很多时候不是完全一致的。这本书谷歌SRE中文版应该出来了，如果大家需要这本书的话可以跟我们联系，但是现在我也没有。最后做一个广告，我们今年会有一个全球运维大会，今年有四站，分别以歌曲来命名的，第一个是三月份的，名字叫春天里，第二站是9月份的上海站怒放的生命，然后是美国战飞得更高，北京站是北京北京。到时候希望我们运维这些从草根，一步一步出来的人，能够有一些体系化、理论化的收获。最近我在跟一些小朋友学DevOps相关的书，我们也是希望能够把相关的东西做一些提炼，在国内进行扩散。希望有一个传播的过程。谢谢大家！