中国IDC圈12月26日报道，12月20-22日，第十一届中国IDC产业年度大典（IDCC2016）在北京国家会议中心隆重召开。本次大会由中国信息通信研究院、云计算发展与政策论坛、数据中心联盟指导，中国IDC产业年度大典组委会主办，中国IDC圈承办，并受到诸多媒体的大力支持。

中国IDC产业年度大典作为国内云计算和数据中心领域规模大、具影响力的标志性盛会，之前已成功举办过十届，在本届大会无论是规格还是规模都"更上一层楼"，引来现场人员爆满，影响力全面覆盖数据中心、互联网、云计算、大数据等多个领域。

会上，网龙云计算架构师 阮少钧出席本次大会并为当天的IDC上市企业大会做 《企业在云计算架构下的运维治理》主题演讲。

网龙云计算架构师 阮少钧

以下是演讲实录：

阮少钧：今天会分成三个部分，先讲一下在云计算整个场景下运维有上来特点，包括怎么去做一些应对，第二个部分会讲云计算的运维用什么样的架构去适配，第三是分享最佳实践。

我们先看一下传统运维会遇到的挑战，在过去可能基础设施的运维是比较花钱的部门，现在我们每天都在讲云计算，对于老板而言，他被这些云计算的东西洗脑过以后，老板是想是否投资可以倒过来，云计算就是要花得更少，做得要好，还不能倒。所以大概会是这样的场景。在云计算时代，交付速度越来越快，成本越来越低，质量越来越高，这是一个趋势。从传统的运维到开发的整个链条来说，最容易碰到什么样的情况？业务发生故障的时候，损失可用性，开发和运维是这样的场景。开发说东西在运维手上，出了问题找运维，运维说代码写的有问题。这里面有一个运维墙，运维墙的存在不仅在质量上难以改善，速度上，开发说我要开发更多的功能，我要交付更多的功能，我要更快的发布，运维说我要稳定，所以慢一点，开发少一点。为了协调开发和运维之间的矛盾，我们在管理上要做很多的努力，包括我们要做管理上的一些流程规范。这一方面的成本开销很大。

最近几年比较多的叫DEVOPS，开发媒体化。并不是说我们提了DEVOPS，明天有DEVOPS.我们看看DEVOPS的整个过程怎么发生。首先我们先把开发和运维都放到一个大包里面，它们俩同时负责一个可用性的指标，这个在职责上先统一。当然在DEVOPS初期，运维的贡献肯定大一点，运维说我做双活，我做储备，我做一些预案去防止这个系统宕了以后有一些处置的方案。这个时候应用还是很苦的，因为应用连不到数据库了，我们找运维说，运维一看数据库是好的，网络也没问题，什么意思？代码写的有问题？所以代码只好打日志，下次再出这个情况，开发说没办法，还看不出来，我们只好预打。开发受不了再往前走，说干脆我们在应用层做预案算了，我们在代码里能不能定义一些故障场景，分配一些错误码，我们再招三千服务人员，碰到错误场景一二三四怎么去做。

讲到这里，大家应该都有一个体会，我们家宽待拨不上去跳出一个码。运营商很早就在这么干了。因为有了应用级的预案我们的可用性会得到提升。再往后，预案跑的比较稳定了，我们能不能把它沉淀到工具，比如说一键扩容，比如说一键重启，在出现问题的时候点这些按纽让机器去跑，我们处理故障的时间又会提升，可用性又会提升，人肉沉淀到工具。再往后工具也比较稳定了，我们能不能写到代码里去？把这个服务人员给干掉。遇到问题的时候代码自己上解决问题。所以最终我们会发现，DEVOPS过程就是人肉不断到工具，工具不断到沉淀到架构的一个过程，所以未来我们就不断地迭代。

这告诉我们，其实在云计算的时代，开发和运维是一体的，它们之间是不断地转换。同时这里有个感悟，我们在互联网上看到很多牛的个架构、中间件，其实都是逐步叠加的，其实一开始大家都很人肉。

我们再看下一个问题云计算基本上会带来一个产品的分层。我们原先可能是一个铁板，现在可以看到很多的层次。从端到云，会造成每个运维分散到每一层，中央运维团队被打散了。每一层都有刚刚提到的架构跟运维两个部分，并且共同地要向上一层承诺SLA，承诺质量。这面里面每一层都要根据底下的这层提供的SLA的承诺，再根据自己的质量需求去决定架构和运维到底要怎么做。什么意思呢？比如说我们中间这层服务API，它想做可用，他一定要看这层可以提供给它什么样的可用性，然后再说距离承诺有多远，再决定在架构上做改善，还是在运维上做加强。这里面要小心SLA是有陷阱的，其实在企业内部开发的很多应用是提不出所谓的SLA，对于一些公有云，像一些比较知名的公有云，他们的案例很多，我们认为说它提的SLA的可信度很高，我们在这一层需要两个动作，第一是需要制定一些规范做准入，第二还要做质量控制。

我们看质量控制怎么做。一开始连监控都没有，这时候就是人冲进去，API看了没问题，我们就看容器，容器没问题就看数据库，数据库没问题就看网络，这种定位故障成本是比较高的。我们再往前走，这是大部分的企业都会做到的，会提供一个第三方的工具，对每一层的服务做监控，这种监控基本上会形成一些量化的指标，我们可以得到刚才说的整个云计算每一层每一个服务的量化质量指标。还要再往前走。我们说好我能有一个SDK，捕获到用户发出的所有请求，搜集他的结果，算出他的质量。所以由工具沉淀到架构，还是刚才说的那个过程。我们认为说真实的服务品质实际上是我们的用户从每一次的请求结果中去感受到的。就跟大家去店里面销售，这个店说他怎么好是承诺，真的好不好我们到那里消费就知道了。

再往前走，我们要实现控制对不对？前面说到了监控，控制怎么做呢？举个例子，我们公司内部有一个专门处理文件上传下载的服务，他会处理SDK给到客户端，这个服务还把CDN引入进来做下载的加速，把高速的通道引进来做上传的加速，这个对业务是不感知的。我们就发现我们用了国内好的一家CDN厂商，结果从第三步的过程中发现监控上发现它的可用性只有99.4%，这个数值是很低的，所以我们的应用在全国范围内有很多的人会反馈有问题。我们就引入了第二家CDN厂商，这家下载不到，我们就自动地换到另外一家，通过这种弥补，我们就发现了，从样本上我们证明了可以百分之百都请求到。实际运行数字上看可以提升到99.95%的可用性。这是在可用性上我们的SDK再往前做就可以实现控制。我们在SDK上做算法，如果从这条路上上传比较慢再切换到另外一条路，这都可以做。

整套的质量控制的演化的做法可以应用在云计算的每一个层次，不只是在互联网的请求这一层，在云端的每个层都可以用。

我们再来看两个案例。云计算多层的依赖对于质量会有什么样的影响。这是一个企业里面最常见的服务，就是用户认证，几乎企业里所有的应用都要依赖这些API，所以我们举一个登录的API.假设这个负责人承诺三个九。这个API会顺序请求四个DB，这些DB的背后一定有服务器，服务器背后一定有网络。我们假定这些DB都有三个九的可用性。我抛开登录的API，它是内部的代码，它的实际可用性只有99.6%，看起来只差0.3%，但是一年的情况就差了1500多分钟，每个月多损失两个小时的可用性。假定网络不稳定怎么办？导致所有的DB可用性低于99.5%，实际上这个API的可用性会降到98%，这个很可怕，一个月就要当掉14个小时，没到三个月，这个负责人就要下岗了。所以在整个云计算的多个层次的切开破以后，它的底层服务的质量对于最上层的业务的质量影响是非常大的。DI服务质量这么低怎么办？要不要换服务商？这个远水也解不了近渴。第二个找它PK，没做到承诺要赔款，这个看起来可以，但是好歹也买了一年的服务，合约也签了，看不惯我也干不掉了，就自己做强一点。自己加强架构运营上怎么做？

假定Mysql的可用性只有99%，遇到这么低的mysqi怎么办？用两个九的mysqi发请求，这个时候有什么改善，在1%故障的概率下发生另外一个1%的故障只有0.01%，可用性瞬间提升了两个量级，看起来是特效药，但是这个方法很贵，因为改善可用性有很多的方式，这边只是提需要根据我们所依赖的服务去决定上层到底要怎么做。

我们再看一下性能的问题。假定我们有一个最外层的运维API，他会以来N个底层的API，每个底层的API又依赖N个更底层的API，假定如果到最终每个基础设施的请求，平均响应时间是10毫秒，当然因为响应一定要遵循分布，它一定会有99%的区间，大概会落在1秒内，这很合理。如果会落到一百次拴串行的基础设施请求，这个假设不扩张。理想情况下这个业务API平均响应时间应该是100次的基础设施请求10毫秒，1秒完成。但是一百次请求都小于1秒的概率只有37%.到底大于2秒是大多少，2秒、3秒、4秒我们还要继续分析。63%的概率怎么分布，用整个计算可以看出来。假定100次请求，99次小于1秒，，一次大于一秒，这个概率是37%，差不多三次请求会出一次。100次请求，98次小于一秒，两次大于一秒的概率还有18.5%，五次请求出一次，我们再往下分析就会说整个是非常长尾的，有的需要十几二十秒才能完成一次请求，用户肯定不能接受，我们在请求一个API的时候，发现它转老出不来，受不了。所以说在整个云计算的多层次依赖的情况下，底层基础设施做的好，但是你还是会对上层的应用造成质量上的一个影响。这种问题要怎么解呢？

在行业里面，基本上还是会按照一个负载均衡的做法去做。像腾讯的L5，或者是阿里的微服务框架，他们都会用一些负载均衡的办法把某一些热点消除掉。比如某一个业务请求两秒、三秒造成后面的请求排队了，他就会把处理这个请求的实例做一些负载保护，让它的负载能恢复。这就是行业上的一些做法，但具体的技术就不再引用了。

这是另外一个特点，就是模块化清单购买。我们在公有云可以买到不同配置的服务器，不同配置的硬盘容量，IOPS也可以买，数据库实例也可以卖，甚至可以按次数、用量计费买一些API的东西。特点是内部是专业化、模块化，需求入口是标准化的，什么意思呢？我就这么多服务器的规格，你们就自己买吧。你也不要告诉我说你要什么特别的规格，我就这么多规格，让用户的选择比较少。它带来的一个好处是做容量规划决策的责任上移到了使用方，不再是运维人。是不是只有基础资源才可以做模块化的清单式购买？不是的。我举个例子，这是我在公司自己做的真实经历。我当时有力的一个小组在开发一个APP，肯定要做安全检查，我把安全检查小组叫来，说给我做一些检查，叫了两次他们也烦了，他们干脆做了一个规范，IOS怎么做，Android怎么做，Java后端做什么东西，这样就轻松了。这就是一个专业化的过程，够不够呢？还不够。因为我那个APP做的是明星跟粉丝之间的互动，我说我做这种APP，为什么每次都要检查密码软件盘？他说安全。我说不合理。要不就这样吧，你把金融类的APP做一个规范，社交类的做一个规范，媒体类的再做一个规范。然后这就把需求的入口给统一出来了。我们在网龙大概有七八百个应用，每个应用都对号入座，找到它所在的模块。安全检查的团队以后在每个块里面一起做更细致的，不管是技术还是规范、更多的差异化，他可以做成服务，所以我之前在写这个PPT的时候，大概上网查了一下，现在国内是有做APP检查的服务，但是好像还没有做成这样这说明还是一门生意。

这里面有一个结论，好的运维一地是服务化的，好的服务一定是产品化的，好的产品一定是标准化的。

我们讲完整个云计算运维的一些特点，我们看看怎么用一些架构去应对。

首先我们先看运维的业务架构，我这边引入了一个三维模型。先看需求入口，我们大概需要做运维的可能会有中间件、容器，甚至持续集成和持续发布的系统。第二个维度云计算的层次，会分成机房的环境、服务器/网络、容器/实例，再往上就是API/集群。再引入一个维度，就是运维的动词，这是专业领域，可以分为监控/响应/预案等等、扩展性、安全、数据管理等等。这个业务架构怎么用呢？我们选取安全，用安全作为一个例子，这是我们的云计算平台，从安全层面在AWS，在亚马逊数据中心做的运维安全的规划。

最左边的这一列就是要运维的需求入口，最上面就是云计算的层次，我们把安全跟云计算的层次一交叉出来了这么多安全的点，这些点都是标准化的做法，点进去有很多的内容。这些点可以实施在不同的服务上，然后我们会发现说，像Mangodb的服务，这个实例安全我们得自己做，集群得自己做，为什么MYSQL要这么做，是因为我们用了MYSQL的实例，所以背后的服务器我们是看不见的，所以要自己做。实例之上的集群还是我们负责，为什么底下的S3长成这样，因为S3本身是API了，集群背后的实例，实例背后的服务器，服务器背后的机房我们都不用管，剩下的是我们做。所以你会发现说，用刚才那个矩阵交叉网络以后，它会出来这样的一个不同的职责分担。

同样的案例放在第三方的物理数据中心就变成这样。这里有个结论，每个企业都可以根据自己不同的需求，在刚才的长方形上自己裁剪，裁剪出合适的适合这个企业本身的业务架构，再根据这个业务架构去做整个的规划，规划完了之后出来规划表，就可以做团队，包括人员和技能方面的配备。

讲完业务架构以后再看，要用什么样的应用架构去实现它。每个企业裁剪出来的业务架构模型不一样，应用架构必然也不一样。只提两点，第一点是网龙做的云，是为了能够飘在不同的IAAS云上。为了能做到这一点，所以我们有抽象云的代理，网龙把Docker引入进来做标准化的封装，解决互操作性的问题。第二个是这个平台本身对应用和开发者提供方便，所以我们还要做业务方面的运维。

最后一部分我们看最佳实践，供应商准入，之前有个人告诉我有个生意要做，对公司很重要，但是要我们部署到他的数据中心，我们去看之后发现，对方是一个云计算平台，只有四个机柜，我说我们的最小部署规模是二十个，给不出来。我们再看整个的存储是用没隔离的，网络没隔离，最外段用的F5，F5能不能做隔离还不知道，我当时对项目经理说八千万有点困难，八十万都未必能做的了。他说不行，这个合同都签了，必须做。出了这事以后我们就做了一个准入。根据刚才的业务模型把两个维度排进去。第一个还是云计算维度，第二个是我们做出来运维的维度。定了一些执行项，我们做了一个准入标准和良好标准，然后我们还列了没有达到准入标准会有什么危险，最后有一个打分。 这个有什么好处呢？首先对于很多做不出服务承诺的，没有服务承诺的服务提供商，我们需要按照我们的要求对他提一个准入，这样我们就可以量化供应商的能力，找出潜在的风险，下次我可以把它写到合同里面，如果你一定要做，责任先说清楚。第二个就是我们建立了这个标准库以后，可以方便我们自己筛选供应商。第三个也是为了刚才提到的质量控制，因为有了SLA，至少是我们定出来的，打完分以后，哪些地方满足我们应用的地方，哪些不满足，应用就知道了，它能根据这些标准去做自己架构运维上的调整。

左边的图在网上很容易找到，我基本上是把它加了七个指标，把它变成了云软件的，对于云计算所有的软件都适用。这里面有提到了像第三级的成熟度实现逻辑物理隔离，做这个成熟度怎么用呢？主要用来识别我们在云的软件体系里面，每个软件到底在哪个成熟度，在哪个成熟度就要看七个指标哪些地方做的有问题。最终对于我们的业务软件，它是依赖这些底层，比如以来nginx在哪儿，mysqi主从集群在哪里。它在做出所谓的成熟度的时候就要看原来我们还要做这些事情。这个也很重要。

最后再讲一下关于整个运维这块的职业发展。我基本上提了云计算工程师的能力模型，我觉得会分成三个层面，一个是IT项目管理能力，这是传统的IT工程师具备的一个能力，架构开发能力、运维能力。基本上每一个不同类型的企业对于工程师技能要求都不太一样，比如说传统IT企业上云，大部分还是用来做集成和采购，项目管理能力还是很重要的，但是他要具备一定的架构开发能力，因为要做集成。如果是对于互联网创业公司来说，它直接买就好了，也不需要做什么集成，也没有那么多旧系统要治理，它更该关注的是自身这个软件云化的架构、运维、开发上面的一些事情。对于像BAT这样的企业，也许也不存在集成的问题，它所有的软件站都是自己开发，服务器都要定制，芯片都要定制，所以它的架构开发能力要求非常高。

基本上这个模型大家可以用来思考，企业可以根据自身的业务需求裁剪，业务模型的裁剪过以后，考虑团体人员配备的时候可以考虑，我们要招聘什么样的工程师，他整个的技能要怎么样分布。我们最后再谈到一个工程师的职业发展，好的当然去做顶级的技术架构师，但是在国内一线的互联网公司也就那么几个，大部分的从事运维行业的，从事云计算下的运维行业的人还是有很多，可以往第二个方向发展，IT规划、管理、实施咨询的方向去走。今天的PPT分享没有太多技术层面的东西，更多的也还是在怎么样用一个新思维模式，包括一些新的方法去规划整个云计算下面的运维，怎么去做它的治理，其实也是在这个方向上做的一个分享。我认为在这个领域还有大片的空间，大家可以去成长。今天的分享完了，谢谢大家！