基于DevOps理念的私有PaaS运维平台实践

刘亚丹：刚才有党总又有王总给我们介绍了Devops的理念，我这边就具体讲一下YY在这一块的具体实践，希望我们的一些实践的经验能够对正在实施Devops步骤的公司和同仁们有一些参考的意义。

我先简单介绍一下自己，自己工作了8年，2009年加入YY，与公司一起成长，经常熬夜，我估计这个也是大部分运维同学的感触。第二个公司是做基于IaaS的私有云平台，2012年开始做私有云，这些年也是在私有云这块有比较多的工作经验。我参与了YY互娱游戏私有云平台建设，也是负责YY互娱PaaS层平台建设管理。
今天我会从5个方面跟大家分享一下我们的实践经验。第一个是运维的价值体系，第二个是运维平台化的方式，第三个是YY互娱PaaS运维平台理念，第四个是实践，最后是想跟大家分享一下我们正在做的未来的简单规划。

第一个运维的价值体系。运维的价值体系包括现在腾讯系非常推崇的体系，我个人也是认可这个体系，主要是包括这几个方面，质量、效率、成本、安全，有可能是将安全放在质量这块，我觉得很多时候运维的工作都是围绕四大块做。这四大块就不是纯技术问题，我觉得它就是经济问题。很多时候最终的问题都会转化成经济问题。这样的问题不管是跟懂技术和不懂技术的聊都会有点，跟最高老板汇报工作也从这个维度汇报，老板也看得懂你做了什么。我们也想做从服务单纯管理做服务运营。也就是腾讯这边一直推崇的技术运营。在这做这些的时候我们很多时候是平衡，有一把称，这个称是质量偏重或者是领导的想法，或者是公司战略要求。然后是跟效率、成本这样的平衡。可能我们为了某一段短期的战略目标投很多的钱，但是不是经济的，它看的是长远方式，所以平衡的过程也很重要。

第二个分享一下我认为的平台化的方式，那么平台化的方式第一个是面向流程的，或者是以ITIL为建设思想的，提供独立的子系统，然后对外提供服务，会随着现在Devops的理念，将工具组件API化，也就是党总所说的有一个原则性的操作就算成是有一个API，然后往上提供SaaS和PaaS的集成能力。从一个场景来说有一个独立的CMDB，有一个数据库管理系统，然后有一个权限管理系统。假如我有一个很简单的产品，我要上线一个业务，我要上CMDB查一下有没有空闲的机器，然后有我要提一个单然后审批，然后我数据库管理系统提一个单，然后那边给我批一下，然后权限。做得好就是CMDB的权限和你机器权限绑定，然后DNS解析要提一个单，然后发布，有可能有些地方发布也要提一个单。然后对监控，在这样的一套面向流程的系统里面，每一个子系统都是要面向一个流程的，所以这里面的核心就是流程、流程、流程。这种方式我觉得最大的问题是面向互联网的方式，特别是传统企业，特别是银行，在做互联网改造的时候，他们现在面临的是比较大的效率问题。所以说这里面我通过Devops怎样改进，通过工具的自建和流程化打通构建效率。

第二个是业务的，我要上线一个业务，我只要一个数据源只要一个MySql，我要一个存储，存储用户文件，我要计算资源，不管是Vmware还是物理机，我只要一个计算资源给我。然后CDN资源，我要持续集成，我要发布，然后我要持续部署还有其他的一系列。我只要这些资源，能不能做到资源的快速交付，我要一个资源你说没有或者是等领导批，能不能自动分配，我发现一个资源，我要的这个资源能不能自动分配给我。能不能弹性伸缩，就是我现在的访问量会是一百，如果明天来一个活动要一千万，能不能随访问量的变化自动弹性伸缩呢？最后一个就是质量反馈，我们不能等到业务出问题才说我们查一下哪里有问题，而是我们建立一套度量的质量监控的标准，主动 分析实时监控质量。在这样的平台里面，是以这样的事情，我们是有很多的内容可以去做的。上面这个方式也是YY互娱建设PaaS云平台的方式。

第三个方式是运维建设平台是拿来主义，比如说AWS、阿里云，很多创业公司一上来就到云平台。这些云平台就是比较好的运维平台，提供的资源海量，要多少有多少，然后又是按需使用按量付费，然后基础组件功能都是非常丰富的，然后它还有非常好的生态。还有一个拿来主义是ITSM商业软件，像王总所做的Devops管理专家，就是这种商业软件，他们业提供一站式的运维解决方案，然后会很核心地就是我持续交付的一个集成，就一定会有这个功能，然后他们比较看重安全审计的能力，然后可能会存在做混合云的管理，我这个平台我可能要对接阿里云，我也要对接AWS，我也要对接青云各种公有云，我在平台上各种API对接好，你只要把帐号、密码提供上来，你在那边创造的资源我全部展示，或者是动态创建资源，这个就是我这边简单理解的三个方式。

第三个讲一下我们做PaaS运维平台的理念。刚才讲了很多，都没有讲Devops是什么东西，今天讲了很多，我提炼一下。我也是拿来的，第一个它是一个沟通合作的过程，这个过程就必然会产生很多的动作，这个动作就是很多我们需要去做的事情。然后这个本质上它是文化运动或实践。最终的目的是什么？就是要达到敏捷、频繁和可靠地达到一个业务和程序的上线。这里面其实Devops没有提Test的，开发人员跟运维人员对接，然后需求，测试就上线了，测试人员都不知道。很多业务在互联网场景下，老板说想出来一个Idea都给我上线了，如果两周上线了，测试说我要一周测试，那根本没半壁满足需求。有些产品可能测试很好，有可能上线一个月就死了很多时候都是在试错。所以很多时候会把Test给忽视掉。所以我觉得Devops名词里面，甚至有些场景下面确实就是没有TEST，但是不能说没有Test的能力，开发自己就在Test，也许开发自己救灾运维。

我们平台是怎样的理念建设，我们觉得将运维技术服务化转化生产力，这就想到运维有哪些技术，我还是从刚才所说的四个维度描述，一个是质量，质量的管理，质量的管理有哪些，比如说高可用是质量的能力，容灾备份也是质量的能力，质量监控、优化都是质量能力，还有效率管理，比如说持续交付、配置管理、知识管理，配置管理很容易理解，就是有时候如果说一个项目交接了几次，再找原来的配置，那个配置就不是原来的配置了，谁都不敢动，但是有一个集中的平台把配置管理起来，不管人走不走，配置在我上面任何人走了都没关系，还有对于项目的交接，对于公司来说很好的。还有资源管理，这涉及到成本优化、容量优化。最后一个就是安全，这其实对于公司，一些抢眼的业务经常被攻击，那安全这块的能力其实也很重要，入侵检测、漏洞扫描、应用安全、网络安全。我们希望将这样一个能力把我们的PaaS平台进行封装，让我们的开发人员借助我们的平台就能用，就能具备运维的能力，也就是说我们这边的理念是我们尽量让开发用我们的平台，我们的运维是不直接介入日常的运维，包括发布。我们让它自助式运维，比如说回到这里面，我们要申请一个数据库，我们直接让它一键创建，就类似于在公有云上申请一个，交互给它。然后我们希望达到NoOps的理念，没有运维，但是实际达到运维的能力。然后是弹性，我们分配一个实例、数据源出去，很多时候数据是有状态的，我们怎样做弹性呢？对有状态的东西做弹性很难，也是要建这样的东西云化我们的产品，以云为依托。什么是云？就是按需付费，按量计费，类似于公有云这样的场景。这样就构成我们整个PaaS平台的理念。

这个就是我们真实的场景，左边有颜色的是基础于硬件层、Iaas、PaaS、业务层，业务层就是多租户，一个项目就是一个租户，一个项目下面的角色可能是开发人员也有项目管理人员也有项目运维人员，在这样一个前提下，有多租户、自服务然后高可用，你的项目接入平台，你的 负载均衡能力，还有应用逻辑层的弹性等都是具备的，在灰色那边运维视图报表图形，实际上就是一个运维视图，所谓运维视图就是面向运维的场景，比如说资源管理，有时候资源管理我们要看一个全局的视图，我们上面一百个项目，可能我们要对这一百个项目进行视图，如果对项目级别进行分析，安全管理、硬件管理、硬件管理、集中信息管理，这个都是集中的，这区别于租户形态的方式。

在平台实践中我会涉及到 这些方面的标准化，XaaS乃至于service，然后持续交付怎样做，平台高可用架构怎样做。这边会重点讲一下我们在弹性调度怎样去做。自服务，自助式运维怎样管理，我们将权限交给开发，他可以自动操作数据源，作为公司层面怎样安全管理，然后分享收益与风险，这是有风险的，虽然它有收益，但是更愿意跟大家分享风险，如果篮球去做云化实施。

然后XaaS、MySql都是缓存处理，我们有一个统一的调度器管下面一个资源池，怎样创建、怎样销毁这些资源，怎样配置这些资源我们都有原子层Api，然后VM，我们是用Openstack，然后KVM、本地存储。第三个CDN非常常见的，以前创建一个CDN很麻烦，需要CDN提单，然后内部审批，我们是一键打通的，跟这些云厂商要求提供API，然后在PaaS层面上键创建频道，然后业务就可以利用这个频道。然后我们的DNS是基于Bind9实现，通过API操作直接解析域名。对象存储是公司其他团队自己做的对象存储。然后MQ也是自己拉一个RabbitMQ来做的。

在持续交付这块，集中这些资源是为了解决业务交付。我们设计了一个交付模型，我们认为有项目管理员，有人，人跟人下面有模块，这些模块下面直接对应的是CMDB，这些CMDB也不是底层硬件的CMDB，完全是业务层的CMDB。如果大家关注老王的文章，可以看到老王有几次描述了怎样把CMDB做分层，实际上我们这边是有这样一个实践的经验。比如说人、项目、模块就直接映射到CMDB里面去了，这个关系就很清楚，不用人去维护这个机器是谁的，只要一串进项目，哪些人串入项目在CMDB就会看到，然后做告警，自动化告警哪些人，然后自动维护起来。然后就到持续交付，吃副交付涉及到多环境管理，测试环境、开发环境、生产环境怎样管理，我们借助环境变量的方式，就是说我们会交付这个容器或者是这个环境的时候我们会往这个环境里面注入一个环境变量，交涉它是测试环境、开发环境还是生产环境。然后平台直接与Jenkins打通，可以一键打包。持续集成里面有一点看不清，叫做选择性。在互联网公司里面，如果每个项目都跑一个持续集成，有可能时间不短，但是不是很长，但是收益不一定很高。而且这种收益如果团队里面的文化不支持的话，这种收益会变得很弱，然后我们是有选择的，比如说对核心业务，我们会每个项目，就是这个项目一路打标签，比如说这个项目是充值项目与钱相关，那这个标签具备的话必须要跑通持续集成，就是提交以后要去持续集成那边反馈一个通过的接口，才走第二步发布。第二步是持续测试，持续测试还有一些自动化测试，有一些人工的测试，这里面针对核心的业务，如果不是核心的业务，我们集成、测试这边都没有要求一定要跑，可以不跑，然求直接进入到部署。在前端测试这块，还有一个经验跟大家分享，比如说充值与钱相关的。大家充了钱很想做到无Bug，这很难，但是我们引入与钱相关的风控，我们预测这样一个活动在多久时间把我们的奖品发放出去，或者是相关的业务。如果我们预测是三个小时发放完，结果20分钟发放完，这个时候可以发预警可能有Bug导致，就会有一些风控机制。在部署我们做了配制管理。涉及到哪些配置？DNS配置，Agent的配置，我们的逻辑是用Java的，我们连数据库的配置，连缓存的配置，然后是回滚。最后就是怎样自动化监测，以及自动化反馈给开发。我们的开发是没有业务开的，也就是开发要兼顾一部分运维的职责，如果是平台层面的故障，肯定是平台运维介入，这就形成我们这边平台的一个持续交付的闭环。

我们这边是将VM做了一个容器，刚才赵老师是用Docker。一个VM我们只部署一个应用，不管这个应用是断掉效果也还只是一个应用，我们不会部署多个复杂应用。这上面基于我们的IaaS层考虑我们做了这样一个容器，我们是VM容器化，要求业务方在开发时对我们逻辑层没有放开，你后台文件存储不要存本地，这个用户对本地VM的状态没有依赖了。像国外有一个平台，连日志都不能打本地，改变开发人员的习惯日志不能打本地这对开发影响很大。所以日志我们集中收集出去，这样一个无状态化的设计，就便与后面做弹性收缩，因为容器层面无状态的，随着业务不断增加我不断升，业务访问量下来我又可以缩。

刚才说到我们具备提供这样一个平台，我们要具备建设整个平台的能力。那平台第一个就是云防DDOS，现在很多的业务包括游戏，可能一天被攻击几十次，所以我们引入这个系统，然后这个是基础据DPDK来做的，是公司其他团队来做，将他的产品引入我们的机房，本身它也做了服务化的设计，就是我们可以看到某个业务的IP被攻击，什么类型的攻击这种。然后第二局是全局负载均衡，这个就是多机房部署，我一个业务一上线，默人进入5个机房，让它就近接入。然后第三层就是四层负载均衡，OSPF—LVS四层负载均衡，这是隧道模式，然后七层是Approuter。再下一层是容器层，这一层我们也引入Nginx，因为之前 是七层的，你这个改了所有的都要改。很多只是我本应用内部的逻辑控制，不想用容器来，比如说我是其他的容器层面控制，你给我配一下Nginx，我们有两层Nginx。然后就是Cache数据缓存层，这方面怎样做到高可用，就是DNS切换。如果Must挂了，会通过切DNS的方式，然后DB 我们就提供MySql，有些业务说我要求MongoDB，我们会推动或者是一般建议，一般这种情况我们还是比较强势一点。很多时候MySql能够解决，然后他就说MongoDB怎样好，对于运维来说你的维护复杂度就增加了，所以我们目前统一是MySql，这些从上往下架构都是高可、水平扩容、故障隔离、弹性伸缩又具备安全防护的能力。

这是多机房接入的架构。我们有些业务部署在IDC1，假如这个就在无锡。用户一访问就是直接访问无锡。如果一个广东的用户访问无锡比较远，就直接进入到IDC2是广东的，然后通过IDC2第二层反射到这个机房来，这里面解决的问题是用户端的链路质量，你让用户直接访问这一带，没有用去访问到这里然后放射到这里质量好一些。然后第三组，一个用户说我做了多机房部署，而且是多活的状态，北方的用户直接访问到IDC3，不知道腾讯上面看到了他们多Set的这种，这是一致性。这种业务稍微好一点，然后我们也支持，底下要做数据的一致性同步，可能会有一定延时。这种方式接入只要勾一下可以了，数据这曾还要人工一下，但是前面的只要勾一下就搞定了。单机房我们是基础据OSPF—LVS的架构，这个模式有一个坑就是OSPF的调度节点，优势是可以横向扩展，模式是不受VIP网断限制，但是假设你一个机房有两个出口，一个是A出口，你带到B出口，然后B那边直接从出口2出去了，这个时候你一个IP入的IP和出去的IP不是同一个交换机会被检测，这个包不让你出去。换成配置，我出的包一定是我自己网段里面的，我控制的，但是这种在国内比较少，但是也有可能这样子。所以这个大家要注意，这个就是弹性伸缩的简单架构，我可能简单跟大家分享，就是PaaS平台会做配置下发，然后下发到Cloud—Router它就会运行，就相当于是一个大脑。相当于我们项目在运行的，然后持续上报它的状态，然后Cloud那边会在Cloudmoritor查状态，达到我们弹性伸缩的条件，就会下发控制指令，我们每个运行是下发一个Agent去扩容和缩容，在这边的话就有一个资源池，大家知道创建一个VM的效率比较慢，你就算比较快都要1分钟，Docker是秒起。我然后先做成池化，提前预创建一大批的VM在那里，用于做弹性伸缩。如果不够了会写一个机关任务，会不断地从OpenStack里面创建资源不断地写进来。

在弹性伸缩的条件、策略、场景也是有一些可以分享给大家的点。第一个是要无状态化，就是容器层面的弹性，刚才从应用层、接入层到四层、七层全部都是可以弹性伸缩，而在容器层面就要无状态化，那无状态华就要满足弹性，是要具备一些灵活性，比如说是不是要弹，这个是可选的，而且是让户可选的，比如说有一些后台，说我就三个人用，你没必要给我搞弹性伸缩，甚至我只要一台部署就可以了，要不要谈伸缩这个我们现在是可选的，你默认是勾上的，不要的话不勾就可以了。第二个是最小实例数，我一个业务上线，比如说我们根据业务的项目会打标签，如果它是前台对外的业务，我们默认2个VM给它，而且不在同一台宿主机，有些后台说一个就够了，那就最小数1个，发布的时候只分配一个。还有弹性阀值，什么时候弹，这个用户可以自定义，我们提供相关文档用户就可以用。弹性伸缩有哪些场景，比如说动态伸缩，我现在有两个，随着场面增大会有4个场景，再就是热部署，比如说我现在有3个，现在我要发布一次，我现在还是这3个还是继续运行，然后我们另外挑3台重新发布好，经过平台Check，没有问题了，然后再Nginx那边踢掉。然后第三种是故障隔离，我还是三个，我们会定期检测发现有一个S3挂了踢掉，再拿一个补充进来。

我们怎样支撑到没有Ops呢？因为业务已经交给开发自己去弄了，我们怎样支撑到他们自己在线上运维呢？第一个就是资源交付，然后上面还有运行维护，VM、自建源，一反馈自己拿着用就可以了，自动分配，他要的服务器不用找我申请，你自己上线自动分配给你。弹性伸缩，业务量访问大小要扩容了也不用找我，保证给你弹性。这一块就是满足自服务和自动化的场景。然后就是配额，我们给项目允许创建8个MySql，如果不限制它就有一些捣蛋分子，我就不限制一下子给你点300个，所以我们就是8个数据源，最多是面向20G的内存这样一个配额管理。所以配额管理在做云化的场景下也是比较需要的。第二个维护的话就涉及到日志、命令、监控、维护审计。监控的话这里面有基础监控、有自定义监控，还有可用性监控。最后面的是Zabbix，我列出来实际上我们用了很多的开源工具，希望大家构建自己系统的时候，也可以用这些开源的工具。第二个日志是文本日志，我们的机器交付给它默认是没有权限的，没有服务器的权限的，我们将所有的日志打出来收集，通过权限隔离，让它自己查自己的日志，所以它没有登录的权限，没有服务器登录的权限。那在命令交付上，我们的平台上直接操作命令，不用交付服务器，在服务器上就可以了，只要是常见的命令都可以执行。审计这边的数据，因为将数据源一键创建，这里面运维的职责还是要在，怎样满足，因为数据不是随便导出，与充值相关的，数据谁想导就导那就麻烦了，所以我们会有管控的对于这些业务属性。一些系统想查一条数据或者是几十条数据都没问题，那你要一下子一万条数据是不可以查。日志气用原生的Storm，然后业务访问质量怎样，我们收集日志做分析，去做反馈，这里面用Flumed+Storm做分析，然后大概延迟5分钟，就可以看到你5分钟以前你的访问多少，你的接口请求、访问量分布是怎样的，包括机房分布。

质量反馈上，刚才说我要平台的质量，我们提供一系列的从接入层到数据源层面，整个一系列的组件都是由运维提供出去，平台提供出去，那平台的质量得度量、监控，所以我们要建设质量的反馈能力，比如说对数据源进行质量评分。我们昨天和过去一段时间他打了80分，昨天打了60分，这个分数降低了条件，那我们就推动开发优化它，什么原因。在业务反馈，一个是可用性监控，每个项目列一个规范必须列入可用性监控，就是UAL监控，但是这个必须要有业务的逻辑写里面，要持续不断地Check，这些不用人工就起到监护。在Web运营就是日志分析，重复的任务工具化、自动化。

讲那么多好像收益很多质量、效率、成本这块。跟大家聊一下风险，第一个是容量管理，我们可以云化。如果说容量管理不预测好，以前用户像传统的模式去拿一个资源，还得运维审批一下，我们直接交互，这样交互没有容量管理的方式，那就变成容量有可能没人用导致流量浪费，或者是容量超载。你的预测的能力是要建设的，第二个是隔离，我们是基础层面资源共享，这种共享模式下导致业务的交叉影响，怎样做好隔离，这里面也是有一些相关的细节要扣的。第三点是底层技术，比如说Openstack搭起来容易，但是出问题复杂查起来比较难。所以要把Openstack弄好不是一、两个人可以弄的，所以开源的复杂性是要考虑到的。这些问题都是成长的烦恼，并不是不可逾越的鸿沟。

最后想分享一下平台运营，要建立一个群组，快速响应需求，然后是用户的需求重视起来，在做细节改进，然后是质量管理，定一些指标管理好我们自己。这里想讲的是用心做好运维服务，这就是我们的一个UI，比较丑。比如说这边可以直接创建数据源，下面就可以看到有模块，然后一键配置打包，可以查数据，自定义监控、CDN、可用性管理。这里就是配置，设计域名，发布版本，允许ID访问等。这就是维护，包括数据源的管理，实例的起停全部在界面上，这个就是模块的可用性，项目可用性。

最后是我们平台的未来规划，面向业务运维的一站式平台，继续完善我们没做好的功能。第二个是支持多语言发布，目前我们支持Java、Php，后面可能会有Node、JS，然后是提高自动化、数据化、可视化、产品化能力，然后将界面进一步优化。最后是探索应用于VDC架构，这是一站式撇太具备的能力，不太清楚，就过一下。我们想做的一个概念是做业务价值交换的解决方案。这块我们提出自动化、鼓掌自愈、故障学习，然后运维能力、数据化能力、可度量，然后现在的云化的IaaS层是自己研发的方式。最后想说做云很多坑，水很深，我觉得我们是路漫漫其修远系，吾将上下而求索兮。

嘉宾：自动化故障，发现问题是平滑还是？<br />    刘亚丹：目前是机器级别的，集群级别做不到，<br />    嘉宾：如果有请求失败。<br />    刘亚丹：挂掉是弹性伸缩，把失败的节点踢掉。<br />    嘉宾：那任务是重跑吗？刘：我有三个实例，挂一个没关系，还有两个，补充一个进来，如果业务量变大，曼苏弹性条件就再增加机器。所以除非是单点部署，也有业务是单点部署的。<br />    嘉宾：刚才说服务器进除都在平台上操作，这种操作习惯的改变或者是文化变更的情况下是怎样做的，有没有写坑，或者是说服用户转到新的模式下做工作？<br />    刘亚丹：在界面发布，然后再界面执行命令，为什么通过终端登录呢？终端还要跳板机，还要IP，我们直接后面有一个命令，你直接  在里面执行哪个命令，匹配命令收一下，然后反馈一下给你，这更方便。执行数据库查询，那个界面上也有了，不用找到帐号密码登录那个实例，这个想法更方便，唯独有些说你这样子开通道，安全问题怎样解决。其实这是更方便的，包括我自己做事不登录IP，直接在上面更方便。<br />    嘉宾：我在SqL执行，有一些破坏性语句执行怎么办？<br />    刘亚丹：目前我们是这样的，Sneck的让你执行，凡是有变更类的都是有DBA审批的。我们做简单的语义解析，这块后面还是会有很多能力挖掘，我们刚才也说有一个质量分析。比如说我们会有接近一千个实例，我们轮训跑质量分析，推出来。

讲这么多，为什么要做这样一个平台，肯定是基于业务场景做这样的问题。也是基于YY来做这样的事情，YY从小公司变成现在还有一点体量的公司，怎样的场景下驱动我们做这样的事情呢？比如说快速试错，互联网公司特别是创业公司，快速试错非常常见。我记得我们当时是一年有一、两百个项目上线，到第二年就死掉七、八十个，就这样的速度上线，大概三、二十个开发维护一、两百个项目。然后快速试错就导致项目上线多，导致运维需求多。运维需求多，很多时候互联网公司，运维人员是比较缺乏的，本身人不多自己累得要死。人不多同时因为上线多，还有资源需求也多，那就会导致成本压力，本来互联网就很省钱，成本也很有压力，这三个是一个循环和关联的东西。在这样一个场景下或者是老板我们就在思考，怎样优化我们的交互模式。