DevOps最佳实践之海量资源技术运营

白凡

分享：熊普江-腾讯布道师
编辑：白凡

今天我给大家带来的分享就是海量资源的技术运营，这里有几个关键字，一个是“海量资源”，这个海量资源，当然腾讯有这么多海量资源，但实际上我们的海量资源在大家的脑海里的概念是不是有一些不一样，等下我会介绍。“技术运营”这个词我们感受到它越来越重要，今天我还有一个定义叫精细化的技术运营，今天用一系列案例带给代替。

今天我从三方面给大家做分享，第一我刚才讲在我们现在做技术运营会面临哪些趋势和挑战，就是说在这种海量资源的背景下面腾讯有哪些实践案例，最后我们归纳一下在海量资源下我们现在这个时候怎么样做好这个技术运营，有一个方法论。

1. 趋势与挑战

我们先来看一下趋势与挑战，我们看几个趋势，第一个趋势非常明显，就是大家都在上云，我相信在场的没有哪一位没听过云或者说对上云的趋势不理解的，在座的如果我们做技术运营的多多少少用了一些云，CMDB也是云的一种形态。最近的话，随着云的能力的提升和大家对数字化转型的要求以来，这个趋势是非常明显的，基本上现在在我们的政府，在我们的传统的工业制造其实都在探索数字化转型，探索我们的业务在云上实现，也就是说我们的云计算现在是成为一种真正的生产力，而大家在广东也非常感受到我们有一个数字广东，各个城市都享受业务上云给我们带来非常多的便利。我们做业务的时候，我们也要思考一下，我们有没有感受到要去用云。

第二就是微服务架构，实际上这个是时代演进的必然结果，我们最早的时候是集中式的架构，有了互联网之后，我们就是分布式的架构，随着移动互联网的到来以及我们这种敏捷开发快速迭代的要求，还有上云的这些要求使得我们的服务都是要微服务的，那么它就是方便我们能够很快速的迭代，也能够让我们的业务在升级的时候，都不会受太多的影响，其实这也是我们DevOps的理念最关键的一点，通过微服务的话，让我们的研发和运维有一个很好的结合，但是它会带来一个问题，这种微服务会造成我们的服务的数量会以几何的速度增长，利用我们的部署、容量变化是非常大的，这个趋势也是有挑战的。

AI也很火热，包括现在做一些业务的都跟AI关联上，实际上在不管阿里也好还是腾讯也好百度也好，其实都在大投入AI，腾讯的话，这里也有一个战略就是让AI无处不在，实际上这个也跟移动互联网，跟IOT移动互联网的连接数据到把这个数据应用兴起是一样的，这个也是我们要注意到的，我们大量的数据怎么应用起来，怎么样能够，包括上午主会场，我们腾讯的赵总也提到怎么样跟DevOps结合起来，这是我们要思考的地方。

云有很多AI的能力，我们可以直接拿过来使用。在这个背景下我们再来理解下什么是海量资源，我们以往理解的海量资源是我们有海量用户、海量请求，在后端有承载海量用户和海量服务的资源包括服务器、带宽等，刚才我们看了那几个之后，我们对海量资源的理解应该有点变化，第一个变化，微服务，个性化的需求也越来多，微服务也是海量的资源，其次这种服务也是容器化的，这种容器也是成千上万的，这种容器管理也是海量资源管理，我们对海量资源，除了传统服务器数量多少、带宽多少、专线多少，实际上还包括云的资源，云组机、容器、服务，PaaS服务、SaaS服务都是，包括我们知道我们现在积累的那些海量的数据也是一种海量资源。

因此在这种新的时代或者说数字化比重越来越重的时代，我们海量资源的运营和挑战会有这几个方面，首先始终要坚持用户价值，在座的可能很少思考用户价值表现在哪些方面，我们真正每做一个服务、做一个产品，一定能解决用户的痛点或者用户的问题，这个是价值的体现之一，其次的话，我们还能够帮助用户提升效率或者是节省成本，这个是第二部分就是效率的提升，这个也是用户价值的一个体现，还有就是我们给用户带来的服务是非常稳定、非常安全的，这个就刚才赵班长讲到的这个服务如果受DevOps攻击，实际上是已经受到一些威胁了，对用户的体验，对用户的价值也造成一定的伤害，我们要做防DevOps攻击的技术要应用上。

2. 海量资源技术运营实战案例

我们在这种挑战下我们如何考虑用户的价值，其次我们知道随着你用户规模的增长，我资源的承载服务的资源的上升，我们的运营成本一直在增加，大家如果做过预算的同学知道，实际上我们的成本基本上是一个梯形往上走的，今年最高成本往往是下一年最低成本的消耗，这里头我们要思考怎么样能够面对成本快速增长的压力，还有我们做技术运营的同学或者运维的同学我们经常会受到一些挑战或者来自于我们的领导或者我们其他的团队，就是你这个技术架构到底是不是好的，外界是不是这么做的，实际上这里头我们也要经常思考，我跟外界是不是能够进入领先性，这些我觉得是我们特别要思考在新时代下面的一些技术挑战。

讲完这个趋势和挑战之后我们就来看一些我们在腾讯里面海量资源下面我们做的一些精细化的技术运营的案例，在看这个案例之前，我们先看一个我们一直注意到的一个方法，怎么样能够做好技术运营，这里我们最重要的一个观点就是我通过技术架构的一些评审来帮助我们把技术运营做最好，因为我们的技术架构是决定我们的运营效率和用户价值的，运营价值包括三方面：第一技术框架是用什么样的框架和技术，其次我们的业务逻辑是不是合理，以往我们做运维可能很少考虑这块，今天我们的观念就是希望大家重视和理解我们的业务逻辑，整个业务逻辑是不是合理的，包括他实现的算法，我们以往OPS那块是不对的，我们也要看到DEV的算法，我们其实以前做运营的话，后面的运营效率的数据我们是有的，我们知道的瓶颈在哪里，我们的单机性能，实际上这块我们现在要往前走一些，通过技术架构我们看看它是怎么影响我这个运营效率的。我们提到用户价值，我们怎么帮助用户的价值体现，帮到用户效率的提高以及用户用的更放心，对我们的服务用的更放心，这是一个我的观点，就是技术架构的评审会决定我们的运营效率。

第一个案例，我们来讲微信的业务，它是做微服务化的，实际上在微服务，实际上在2014年兴起，微信是2012年出来的产品，很早微信主张微服务化，微信有5000个微模块，这些模块要对使用用户进行访问，肯定编排和调度是非常有效的，这里面容器的编排和调度是YARD系统，两层架构，还有一层是应用调度，这两层使得我根据资源的状况将不同的业务进行一些调度。它会判断我每个节点上判断自己节点的状态包括健康的状态和资源利用率的情况。在应用调度上，有哪些任务，怎么编排，怎么调度以及执行结果的反馈。目前来说，这个系统容器编排和业务调度YARD系统已经覆盖微信超过80%的微服务。

这个容器的编排和调度非常重要，这里还讲了一个效果就是我们讲它能够将我们大量的资源可以节省，因为我们每一个业务是不一样的，因为每个业务的特征有的峰值有可能不一样，如果我们调度的效率非常高的话，我们就可以将这些进行错峰的调度，左边是三张图，模块A有一个峰值点在这个地方，就是凌晨00：00，在这个时候我们会发礼品，发游戏每一天的礼品，这个礼品大家都要领，所以就造成了峰值，我们可以看到这些集群里面游戏CPU都超过80%，实际上已经到了瓶颈，我们也可以从这个效果可以看出来这里是快速聚集，快速聚集的量很大，这个时候会影响用户的体验，因为一些服务被请求拒绝掉了。

既然有这个特征，我们看模块B，在00：00的时候看调用量不是很高，CPU更低，不到15%，如果我们的容器编排和调度足够强大的话，我就可以将我的业务在峰值到来之前我就可以把它部署到这个模块上面来，也就是说这里是我节点的管理，这个节点管理之后的话，如果调度过来之后，如果没有调度能力，这个模块要加服务器，如果有调度能力可以在之前把业务部署起来，部署起来之后我们可以看到原来CPU利用率超过80%，现在60%。从业务的体验上来看，这是原来拒绝的量，现在的拒绝量几乎没有了，很显然如果编排能力能够快速调度部署，就能大大节省运营成本，业务体验也得到了提升。这种业务编排能力当然在微信方面展示还用不到，但是我们把这个能力在云上进行了开放，在腾讯云上有两个大家可以尝试，这都是免费的，大家可以尝试，如果自己微服务相当多，如果想加强这种调度能力的话，可以尝试这两个服务。

我们看第二个案例，我们叫微信的收发消息，我们天天用微信，这个收发消息非常大，每天收发消息可能会超过5千亿条，肯定需要我们很多服务器资源支撑，本身调用也是海量的，这里头我们看看怎么微服务化的，我们怎么将它精细的化的技术运营，我们看一个单聊消息，用户A发到用户B的发消息的过程，实际上我们通过这张图可以看到实际上很复杂，感觉一条消息从A用户发到B用户，实际上要经过一个接入层，发消息的逻辑层、帐号、帐号的存储、帐号属性、反垃圾、通讯录、序列号、消息体、推送等等这么多过程。显然每发一条消息，后面还会放大十多倍，有消息的层面。比如说我们操作系统的能力如果不优化足够好的话，单机的性能根本上不去，所以我们后面做了很多优化，左边可以看出来，第一个对操作系统层面做了很多系统层面的优化，使得单机处理这种并发可以达到每秒达到200万次。

第二我们有一些调用层次可以减少，如果不减少的话，这个调用是放大的非常厉害的，减少调用层次，你的请求处理就少了，你的性能上去了，你的资源也会减少。我们的服务器性能是有差别的，可能服务器是一样，但是分配到的请求数也是不一样的，这会造成什么后果呢，同样的机器，有的机器负载高，有的低，这种情况下，我们没处理好的话，我们要根据峰值进行扩容，如果不均匀就会导致我们有很多机器的利用率上不来，会造成很多成本浪费。我们有一个优化，针对怎么样把每一台机器负载处理的请求都是一样的，怎么样达到都一样的能力，非常关键。后面还有很多，怎么样合并一些请求调用，因为合并调用了，有些可以同时下发下去做成一个请求下发下去。

还有新服务器，我们经常有新的微模块和新的微服务上线，一般来讲我们要为新服务准备一些机器和资源给大家承载，但是这些新的服务很难知道到底需要多少资源量，这个时候我们就有一个设想设立一个新的服务资源池，到了一定体量再单独部署，这样就能够避免一些业务后面跑不起来的占用我多余的资源。

我们看微信朋友圈的案例，也是DevOps技术精细化运营怎么来体现的，朋友圈的话，大家经常知道我们是永久保存的，朋友圈的话有两种形态存在，第一种就是我们平常看的朋友圈“发现”里面的朋友圈，那里面只有2000条，是一个时间线，是你跟你朋友发的东西在那个地方，那个地方实际上是一个索引，真正保存你个人朋友圈是在“我的相册”里面才是你真正的朋友圈，那里的数据是永远保存的，朋友圈的量非常大，特别是图片、视频，每天图片的量都是数十亿次。这会产生一个问题，它是永久保存，都是增量的，这个量是非常巨大，每天都是几十亿张、上百亿次的请求，如果保证用户体验的话，我必然要用很好性能的存储，这个存储如果全部用这个存储访问的话，那会造成我成本巨大的增长，每天都在增长，实际上这里头通过技术运营我们会发现一些数据，这些数据实际上一天之内的请求，访问一天之内发的朋友圈有70%，大部分访问都是访问当天的，70%的请求都是看这个朋友当天发的朋友圈，在一天内发的量占总存储0.3%。我们再看一个月内的请求占了90%，也就是说我看朋友圈基本上90%都落在一个月内，这说明了朋友圈数据的冷热是非常分明的，我就有一个可能了，就是我要保证我的用户的体验，要非常快，我在一个月内的数据我就给它保存在很高性能的机器上面，这就是热数据集群。超过一个月就放在冷数据集群里面，这样的话，我们看到一个月数据也只占整个存储量的6.5%。
我通过这种冷热分离，使得我的架构一个能保证用户读取的性能，一其次我的成本快速的下降，基本上我将来的话，大家仔细思考一下，基本上我的热数据集群不会增长，增长就是冷数据集群，冷数据集群相比热数据集群，量大成本低，成本还不到前面的1/3，这样的话，通过我们的架构优化使得用户体验得到提升和成本大幅下降。

我们还有一个案例就是公众号，就是图文消息，图文消息的话，实际上也是我们作为技术运营人员来说，是有很多精细化的地方的，我们可以看到带宽耗用也非常大，因为每天的我们的公众号文章的阅读量是超过30-40亿次的，这样的带宽我们是怎么看的呢，我们就把它分解，通过每一种，尺寸大小图片分文多少，每种类型访问多少，它从哪里来，我通过这些分解我们会读到用户看什么图片，是什么格式的图片，我们怎么优化它。当然我们有很多的数据，我这里本来就没有展示，如果用户上传的图片是低压缩的我就可以进行转化，转化成WEBP或者PNG，压缩之后会降低30-40%的存储量。GIF是动图，在整个公众平台只占7%的请求量，但是GIF的带宽占了60%的带宽，我们可以抓住GIF进行优化，这种图片有很多地方进行优化，我们可以减少真、颜色、我们可以将它变成JEPG的图片，只要找到矛盾点我们就一定能够进行优化。

再看一个案例就是我们在发消息里面，现在负媒体消息越来多，就是视频越来越多，视频也一样，我们要保证体验的话，我们做了很多加速点，让用户就近上传、就近下载，中间要保存很多存储，用户下载的时候要有很多带宽，这里头将它分解，包括它占用中间的专线也非常多，我们怎么能够减少中间端线的传输，减少用户拉取的带宽，都有很多做技术运营的地方，我们做过这些，将它存储的格式，进行优化，视频有MP4格式，我们实际上也可以做H5的格式，还有质量系数，有些不需要那么高清的视频，比如说教学视频，压缩比科技下降一些，用户体验又不受损。高峰期的限数、下载去重、有害视频去掉等等，我这里讲两个，边下边播，我们一直用微信都知道，以前发一个视频给你你要看这个视频要下载完，我们经常发现这个视频是我以前看过的，你会马上关掉，如果这种形态的话，实际上浪费了我一次下载的带宽，而且这里面时间等待花了不少时间，我们就通过数据分析，我们就建议产品做一些优化，优化成什么呢？就是边下边播，点开就可以播放，只要我下载的速率快过你播放的速率就可以了，如果你看过的视频你马上关掉，然后终止下载。这个优化实际上已经给我们带宽减少40%，这是一个巨大的优化量。还有视频外调，CDN带宽很便宜，你会发现热点过去了之后，CDN节点没有了，要回到中心节点上去，这就没必要让它再缓存一次，用户从这里访问，发现这里没有，又从这里拉取一遍，如果访问次数不多，实际上我们可以改变，当它只有一两次访问的时候，就直接用户跳转到原来的节点就可以了，当然这个当海量用户访问的时候效果比较明显。

最后一个案例，大数据也是一种资源，相信大家在自己的业务里面也在慢慢积累，也越来重视，这个大数据实际上也有很多坑，这个坑会发现就是说我们这个大数据会增长很快，实际上它会有一些问题，包括比如说有一些数据我们搜集下来从来不被使用，这是一个我们讲沉默数据，就是你这个数据搜集了，但是从来不被访问到，还有一个就是你处理完了之后，这个数据也不被访问，实际上这也是沉默数据。沉默数据如果不清理的话，会占据你大量的存储，像腾讯的体量的话，存储增长很可怕，我们还看到一个生命周期，在后来的话，我们进行大数据管理就要求搜集数据的时候，要有一个生命周期的管九，必须存储数据你必须指定数据保存多久，这是生命周期，还有很多，大数据处理经常有任务分析，这些任务分析会有很多任务很慢，处理占用很多资源，我们要把比较慢的任务找出来看看它是不是能够有优化，提升我的效率。

我们将这些空的任务或者无价值的任务要进行管理起来，这些任务在处理这些数据，处理完了结果没有人看，就是空跑空转的任务，还有就是跑出带的实际上都不成功这些任务都要清理，可以节省我们大量数据存储的服务器和计算的服务器，所以这块的话这种大数据资源我们怎么样能够有效的利用也是非常重要的。

最后我们再讲一个案例就是微信运动，相信很多也有很多小伙伴在用，每天都有一个排行榜，你一个人加入微信运动就多了一个排行榜的需求，我们业务部门按照这个算法每多一个用户进入微信运动就要加一些机器进行处理，会推导出我需要这么多资源，如果用户继续使用微信运动的话会使用大量的资源，这个算法是值得探讨的，后来我们推荐它使用全局的排行榜，以往有4亿人参加微信运动，可能要排序4亿次，如果使用前期排行榜的话，运算资源量会增多，后来把前期参与的人进行排序，这样需要的资源多一点，前期排序之后，所有的序都不用排了，其他的排序都是一个子集，只要把我的朋友抽出来就可以了。我们通过算法的优化，基本上所有的业务量增长跟我的设备的增长没有关系这样节省超过80%的资源。

包括原创保护，我们在公众平台我们的一些文章做原创保护，你要对比指纹，是不是原创的，有点类似于我们的病毒库，这里有一些算法是可以优化的。

3. 技术运营方法论

我们刚才带领大家看了一下我们在这个DevOps背景下面我们做海量资源技术运营实际上有精细化的措施，最后我们通过这个总结一个案例，第一就是我觉得我们DevOps未来很多业务都在上云，上云的话，云的资源也变成我们的一个海量资源之一，我们怎么样很好的管理这些容器和无服务器计算，这个是大家要关注和怎么样调度管理的。

下面有两个例子，未来这种云的开发模式可以大大提升我们的效率，比方说我们通过云上的AI能力和技术我们直接拿过来用，可以大大提升我们的开发的效率，比如说我们一个上传下载，左边是上传下载，用户通过云存储和调用我们可以提升571倍效率，右边是数据库调用接口，这个效率来实现数据库查询和读写效率能提升上千倍。第二点的话就是说我们这种容器也是一种资源，我们的函数也是一种资源，怎么样能够有效的管理和调度，这是我们要思考的地方。

通过一个架构评审，有效的找到技术运营的细节点，能够有效的提升我们的运营的效率，一个总体方法论我们要将不管是服务器资源还是带宽资源，我们要做很好的分解，就像我讲的公共平台的带宽一样，分解清楚，每个构成，技术架构图的每个点都把它列出来，有了这些之后，我们就很清楚我们在哪几个环节做优化。优化也不是说面面俱到，每一个都抓，而要抓某一个矛盾，就是跟我刚才说的GIF，70%的请求调用量占了60%的量，我肯定要先解决主要矛盾。通过技术架构，平时就能够给我们的开发，我们整个产品提出一些优化的方案，包括技术架构做一些调整，比如说冷热分离，比如说算法，比如说我使用全局排序方法，都能大大优化我们产品的体验，降低成本，这个实现之后我们再要看这两个都要做，还有一个叫产品策略，就是边下边播，以往你下载过来看，你下载完了肯定能看，但是我如果改成边下边播就可以提升用户体验，可能会有卡顿现象。

通过我们的技术手段和我们推进让产品经理去做产品策略的调整，都能够帮助我们提升用户价值。所有这些不只是做一次就完了，我们要不断的回头看这些优化是不是还可以进一步提升，这是持之以恒做，这样做下来我们的技术运营一定能够体现出在公司里面的地位和巨大的价值。

通过技术架构评审带来精细化的技术运营的手段，能够让我们更好的去触达业务，以往我们可能很少关注业务，但是通过技术架构评审精细化的技术运营使得我们触达业务，优化产品，提升用户价值，而且我们能够把控成本，知道我们的成本是通过技术运营带来的提升，使得我们的产品做到极致。