腾讯 自研游戏运维中心总监
腾讯游戏服务“云梯”的服务体系设计和建设第一负责人，专注海量运维、高可用以及自动化运维等相关技术，致力于提升业务运维的自动化，建设运维岗位价值体系。
通过运维服务整体提升团队核心价值和技术能力，拥有十三年的运维技术实践和团队管理经验，跟随腾讯大平台运维成长，深知运维之痛，同时更了解如何从日常运维中，挖掘业务运维核心价值。
前言
笔者在腾讯游戏运维里面除了做好业务运维之外，还承担一个云梯的建设。这个云梯的团队核心价值就在于提升游戏运维岗位的价值，助力游戏业务做得更好，并专注于海量运维，高可用以及自动化运维等相关技术，建设运维岗位的成长体系，最终通过运维服务输出，不断提升运维团队的岗位价值和核心竞争力。
1、运维服务再定义
讲到运维服务，我们首先要定义下什么叫运维服务。从百度里面查到运维服务，一共分为六大项服务内容，实际上这个应该叫IT服务，从一定程度上来说，这个有点太过于复杂了，而且很难理解。
我这边浓缩一下，变成一个运维基础服务：发布、变更、故障处理，+SLA（安全、成本）。为什么 +SLA，因为运维一定要关注安全和成本这两个要点。
今天给大家介绍我们的定义：“被你的产品或你服务的团队关注并且可以产生增值价值点，而且是可计价的才叫运维服务+”。
相当于它必须具备三个关键点：
第一个是用户关注；
第二个是能够增值效益；
第三个是可计价。
可能有人有疑问说为什么是三点，我解释一下：
运维一直都是在后端默默无闻，典型背锅侠，既然你要做服务，从幕后走到台前，那必须做你的用户—老板、产品负责团队、玩家（用户）关注的事情。
做好现在用户关注的事情并不足够，只有关注未来，就如股票一样都是在买未来的增长。
先做好本分的事情，然后再不断思考和建设可以产生增值效益的事情，因为增值才体现你和团队的核心竞争力。
做任何事情都是有价值的，如果没有价值对比，就没有办法衡量是否做得好。
可计价也就是有有价值的事情做，才能够使得团队更有动力。
2、腾讯游戏运维服务体系
讲完这个大家可能会觉得说好像有点道理，但也挺虚的，那我们来看看实战。
正式开始实战介绍之前我们来介绍腾讯游戏运维服务的整体构成。一共包括六大块服务体系：用户体验、运营活动、运维成本控制、运营咨询、版本服务和整个业务安全的保障服务构成。
六大服务模块下面还分了19个子服务，今天我不会将19个子服务一一向大家介绍。我一共介绍三个案例，也是不断进阶演进的服务案例。
3、服务实战检验—游戏行业开合服
首先看一个在游戏行业大家最熟悉的开服和合服。开合服是干什么的？
其实开合服最先是在页游时代出来的，是里面最简单最直接的手段。最先在我们行业叫滚服，是一个产品运营接的，可以减少玩家之间平衡度的问题。同时可以减少一些内容创作的工作量，同时也可以通过导流的方式拉到更多的收入。
3.1 游戏行业开合服的特点
对于运维层面来看，一共有四个阶段，分别有各自的特点：
上线初期
第一个是上线初期，业务刚上线，开服，这个时候导量速度非常猛，需要人力盯着导量情况，新区的开放也一般是人工判断，手动执行。
导量稳定期
第二个是导量稳定期，这个业务进入平稳期了，每周会有基本固定的放量，可以不需要人工操作，通过业务设定注册量，到量后自动开新区，有的业务则会固定每周的开放时间。
精细运营期
第三个是精细运营期，通过之前积累的数据，产品运营跟踪开服后的效果，调整开服时间，开服策略，运营策略等。达到既能让老区玩家对游戏的某些玩法还能够顺利进行，同时后来新进的玩家追赶起来也不至过于困难。
合服期
最后是合服期,单服人数低于某个量后，玩家流失速度会非常快，游戏中的一些核心团队 PVP 玩法也会受到影响，业务一般通过合服降低流失。
3.2 开合服要完成的重要事项
这背后运维要做什么，最直接简单的就是做开服的动作。腾讯游戏运维做了什么事情？
我们首先做到了手动开服，在智慧雪球项目组通过人工点击开服按钮，调后台任务自动完成大区对外开放操作，然后是自动开服，最后做到定时开服。
自动开服会有一个问题，达到这个阈值的时候你有可能是半夜三更，也可能时间并不是项目组想要的市场导量的时间点，你把这个服对外了，但这个量上不来，自然这个服就变成鬼服了。
三个节点里面，目前整个腾讯游戏运维做到的自动化程度还有技术实现程度，在2016年最新的统计数据中，整个效率做到了5分钟之内我们能够将一个服对外。
3.3 开服向更高进阶
如何服务进阶？做技术的天天看曲线，这条曲线有没有什么特点？
这个曲线上，在线 PCU 和注册人数两个曲线基本上很吻合，这个就是一个开服期间最容易出现的情况，就是在线跟注册人数同样速度在增长的，因为这个游戏很火爆。
大家做运维都很清楚一点，你的在线的承载和你的注册数肯定不是一一对应的，比如注册可以注册到5万人，但是在线撑死只有1万人。这会带来什么问题？
最大的问题是这个新服很容易在过两天之后就变成鬼服了，比如前期你的注册达到1万的时候你的 PCU 也达到了1万，按照我们之前定的三个场景，必然会触动你的自动开服或者定时开服，因为玩家进不来，你不开这个量就流失了，市场就没了。
这个好像挺无解的，我们运维干了一件事情，我们从原来的开一个服，我们把它变成了一个池子，这个池子就是当注册和 PCU 达到一定量级的时候，我们将这个服关闭推荐，而自动推荐其他服。
推荐服是什么意思：大家玩游戏可能都会注意到一点，新手登进之后，会有个默认推荐服在那里，你自然会点进默认推荐服。
所以下次当你看到上面这条曲线是上面这个情况的时候，你可以把几个服做成一个池子去推荐，避免瞬间撑满，而是均衡灌满。右边这个流程是我们的整个自动推荐服的流程图，5分钟自动轮循一次，达到这样一个效果。
这时候你的项目组会非常买你做的事情，因为你干的活好像不是很复杂，但是解决了他们一个很大的痛点，他不需要一开服就合服。
3.4 合服向更高进阶
讲完开服的服务进阶我们再讲合服的，合服这个就相当于前面的一些鬼服把它合在一起。
最正常的一个工作流程是这样的。项目组运营团队会提交需求，开发团队会提交数据合并工具，因为合服最大的工作量就是把数据库里的数据做合并，你有很多社区、社团或者玩家的角色名称，你要把它合并在一起，开发必须提供数据合并工具。
运营团队会提供一个N合M的过程，有可能是2合1，有可能是3合1。大部分的运维同学会收到这样一个表格，xxx服务，活跃多少，合并到什么样子。这是普通的运营团队会给我们的数据报告。
做得好一点，他会给我们一个这样的报告，因为什么原因，从几个维度上看，分别选取，像日活跃、开服小于多少天的区服列表等，拿到之后，运维团队会挑选合适的服务器，这个是我们该做的。
接下来运维执行工具，做数据合并，然后正式对外开服。
整个运维的工作里面，最大的工作量就在数据合并的过程，有很多会出错，特别是做 DBA 的兄弟，肯定天天吐槽合服的事情。数据合并特别是在腾讯这样数据量特别巨大的情况下，我们目前能够做到的2016年的场景是2到3小时能够完成一个服的合并动作。
当然包括完成所有数据的清洗包括重新导入的，包括处理数据异常的过程。周而复始这样去操作。这样一个服务其实只能说你做好了本份的事情，整个增值的效益完全没有体现在这里。
既然做服务，看一下在腾讯游戏运维里面是怎么去做的，这个是目前我们真正的合服的流程图。
首先可以看到，我会根据项目组给我们的条件，会帮他们做一些筛选大区，比如说 PCU 小于多少，DNU 小于多少，活跃付费率小于多少的大区，筛选这些大区属于需要去合并的大区。
筛选完之后根据一些组合，我们不希望项目组只是通过很简单的 excel 表格去做，我们会去帮他做开服天数相近等来进行合服的组合，给项目组推荐哪几个合服组合是合适的。
最后会给到一个合服后的数据分析对比。这些数据我们做更好一点，我们会把这个数据放到合服预估里面去。
为什么叫合服预估？因为合服是一个周而复始的过程，你做得更好一步，你需要把这个定期推给项目组。
这个是我们内部的截图，会根据他的规则选择条件，当他有数据异常的时候会提醒他出来，会标示出哪些是符合规则、哪些不符合规则的。这些是项目组现在关注的，因为你帮他解决工作效率的问题，但那是不是就足够了？做完这个还不够，我们需要关注整个项目组未来能够做得更好的一点是什么。
做游戏有一个非常大的关键，如果你理解这个游戏业务的话，你会发现，如果想让这个服合并之后会效果更好的话，其实你需要去考虑，合服里面的用户，不只是说你只把 DAU、客户、付费能力相加一起就可以了，因为你还需要让玩家保持经济平衡或者社区平衡，引入这些因子之后，你对运维的技术挑战提升就会要求高很多。
你需要在组合里面考虑这些因子，我们怎么做，在这里面我们引入了大数据的算法，目前用聚类的算法，帮项目组聚类出哪几个服的战力平衡、经济水平平衡，通过这个推给项目组，这个是我们整个合服的进阶。
接下来整个合服之后的效果对比，我们会跟踪他的 PCU、DAU 的数据对比变化，给项目组更好的决策数据。包括 DAU 的分布、ARPU 值的收益分布等。
这是我们上线半年来我们做到的收益，我们已经累计给项目组节约了260个小时，我们的推荐区服已经被使用了7368次，详细效果如下：
3.5 服务建设过程中的几个问题
在整个服务建设过程，我们都会很怕产品团队提很多需求，因为做IT的实际上是不断在挖产品需求，你一旦开始挖产品需求了，就会带来一个问题，产品团队他的需求会不断的变化，他也会有自己很好的想法给到你。
我们从服务开发者的角度或者服务建设者的角度上讲，他会从集成平台这里，开发者中心，开发者框架，给我们快捷的支撑。
同时刚才大家也看到前面的服务建设里面，我们会用到很多的原子和功能，在下面这个作业平台里，有丰富的原子层，能够让我们组合起来灵活快速。
4、向外部产品的用户延伸—版本服务
讲完这个服务以后大家还是会有疑问，刚才讲到的都是服务于内部用户的，既然你想从幕后到台前，只是让你的产品团队、你的老板都知道这样还是不够的，最好的方法是你能够服务于你产品使用的用户，那才是最能够从幕后走到台前。延伸到产品的用户，怎么做？这里不讲太多废话和道理，直接来看案例。
从内部到外部，我们通过一个版本服务案例讲一下，这个案例大家可能会更容易理解一点。
4.1 版本服务在日常发布中的应用
因为做版本，只要做运维的都接触过，不像前面的开合服，只有做游戏的才会有这种业务场景，离开了游戏其实很难有这种业务场景。在做版本服务，做发布这个事情上，我们可以做什么？
还是看一条曲线，这个曲线有个非常简单的特点，红色的线是发布日的曲线，黑色的线是平时的业务曲线，这两个点是我们运维最关心的点，就是发布时长。从2012年的3到4个小时到2016年的0.88个小时我们可以完成一个版本的发布对外。
实际上来说这是不够的，我不是说发布时长我们优化得还不够，而是我们做运维来说，我们关注得还不够。因为关注的只是产品中你目前知道的事情，本份的事情。哪些是产品关心的事情？产品关注收入、DAU，一个在线恢复时长才是产品最关注的事情，在线恢复得快，DAU和日常的DAU是一样的。
4.2 版本服务在线恢复中的应用
在线恢复快，玩家的在线时长也会同样加长，比如说你等到晚上8、9点钟玩家才能进到游戏，你的在线恢复到正常水平到晚上8点钟，还是说你上午一发布完，中午玩家就进来了，其实这是有本质上的区别的。
看一下腾讯游戏运维是怎么做在线恢复时长提升的，因为你一个版本发布了，玩家进不进来是用户决定，纯粹由用户的行为决定。
分析一下，玩家什么时间喜欢上来玩游戏，更新版本包时长，这个还跟成本关联，同时自动化程度也密切相关。
首先，我们再深入分析一下这个怎么去做，会有个版本发布时间，选在凌晨几点钟发还是在高峰期发，这个也看你运维的技术能力，你敢不敢在高峰期发和在高峰期来临之前发，这是不一样的。还有更新包投放时间，这个包你是提前发出去还是在版本发布同时发出去。
第二步是投放自动化，还有更新的成本。用户更新包所需要的时长，分发量和用户增量的问题。在四大因素里面，我们游戏运维是怎么去影响他们的。大家可以看到，在在线恢复时长优化里、在包投放时间还有投放自动化、分发量做一些优化，会有几大方面，分发量和成本会由阉割的完整包和更新包分解拆包。
一个游戏版本如果对外的话，会分两类玩家，一类是新玩家，一类是原来的玩家做更新的。阉割版的你在发布之前几天就可以对外发布了。
另一个问题，更新包的拆包解包，那么更新包是什么？
做过游戏行业可能会了解到一点，它除了那些程序脚本之外，其实有很多资源，很多时候美工团队或者音频团队已经做出来了，如果运维团队愿意把这个事情做一些拆分的话，你可以提前把这个更新包拆分出去，让玩家预埋到已经在他电脑里的版本里去，这样直接减少分发量和成本的问题。
在时间点上，预下载的自动推送和错峰时间点的预判，这两点会直接决定你的成本还有你预下载的效果。预下载就是说你的玩家在玩游戏的时候，他可以预先把你的资源下载到本地来，这是一个很成熟很简单的技术，你是自动推送的还是人工盯着的，这个差别还是蛮大的。
另外一块是根据玩家的平均在线时长去计算预下载投放的时间。
当你的玩家的在线时长是2小时、3小时或者6小时，实际上会决定你的投放时长，因为你的资源包的下载是需要时间的，你不可能以全速的速度下载，因为玩家玩游戏，你全速下载会占他的带宽，你可以根据你平均下载的速度，根据你的游戏体验去决定。
这时候你会算出100M的更新包，如果玩家每天平均在线2小时，你要提前多少时间放，这是很精细的计算的过程，时间点的掌控对运维来说，不再是以前你放一个包过来就往上丢。
还有用户增量的问题，用户的增长速度，这个游戏版本非常好玩，用户增量会非常大，你怎么控制这个增量，通过预下载多渠道推送，通过大区灰度、用户灰度，P2P 增量。
整个体现了在版本服务里面，在运维团队里面怎么去做精细化的运营，不只是说你把自动化做好就足够了。
4.3 我们的收益
看一下我们做完前面的事情之后有什么收益，在用户增长和包量增长上，在2013年和2016年增长2倍的情况下我们的在线恢复时长压缩到了原来的90%，同时这个带宽成本下降了50%。
这个事情做的不仅漂亮，而且老板觉得你给整个业务团队省钱了，是非常合适的事情，拿这个业绩汇报给老板看，老板会很嗨。
怎么做到，可以看一下，这里传统的就不讲了，业务ABC会把版本需求推送给我们，正常来说(黑色字体)我们会做一些部署的动作，成本监测，完整包管理等。
我们会做用户数据、推送时间、自动推送、灰度控制、拆包的自动建设的能力，不一一介绍了，依托蓝鲸会做自动化调度的能力，会达成整个游戏版本服务技术架构的特点，更多是一些功能模块。整个服务是由这些框框组成的。
4.4 我们不曾止步
看到上面的版本服务和开合服的案例，大家可能想蛮不错了，因为它有三个特点都满足了。
用户关注，包括刚才说的版本服务，玩家可以很快的进到游戏里面来玩耍，一进来更新时间又短，花在版本更新的带宽也少。
老板也关注，玩家也关注，增值效益也有了，助力提升 DAU、在线时长，收益还不错，在两年多的时间里我们压缩到了只有10%在线恢复时长。
可计价当然是 ok 的，每一个用户进来之后产生收益是 ok 的，因为你影响了在线时长，每个用户的在线时长在商业里的数据是可以依托的。
我们觉得还不够，我们碰到一个核心的问题，刚才看到特别是前面那一页版本服务建设的框架里面，会有一个问题，这个问题有四个特点
特点一：环节紧扣
每个服务环节紧密相扣，不管是前面的像表格一样的方式还是后面的框架图，都会发现它整个环节非常紧扣，密不可分。
特点二：依赖业务运维
它非常依赖业务运维某个人或者某个团队的某几个兄弟对这个业务的理解。
特点三：更加复杂变化的需求
因为你做好了现在这一步，你除了能做发布变更、自动化部署之外，你还能帮助我们去影响 DAU 和在线恢复时长。这样项目组就嗨了，他们觉得他可以给你提更多的需求，更加复杂变化的需求，他会想能不能给我加点不同的用户等级，怎么去给用户更好的更新版本的体验。
特点四：成本控制
然后是成本控制，还是有很多人为的因素在里面。
5、实战进阶引入微服务新应用—下载服务
5.1 微服务初探
这里面我们引入了一个东西，叫微服务框架。
左边这张图是微服务框架很简单的示意图，微服务有三个特点。
去中心化
解耦合
可以独立演进。
为什么引入微服务框架？
因为这三个特点可以去解决我们前面的这四个核心的问题。同时，架构、框架这些东西让运维团队的可以比较好理解。
当你跟他讲一些代码级的东西，他很难真正去理解，做运维和做后台开发的兄弟还是有思维理解上的区别的。
这时候我们看一下在微服务引入之后，我们怎么让服务进阶。微服务引入之后我们解决了三个问题。
一个是服务的分解，这里跟蓝鲸的支撑框架不一样的一点是，我们这个不是原子的，我们是单单的一个微服务，完全是一个独立可运作的服务内容。
第二个是消除依赖
第三个是可以成本细分
我们可以演进成下面这些点，而且可以随意组合。比如有些项目组说，我不想要那么复杂高大上的功能，就要包制作和版本管理就可以了，把这个服务给到项目组就 ok 了。
项目组觉得我不需要版本管理，我只要包制作实时数据，或者更多，通过预下载渠道投放，希望能给玩家更好的体验，可以这样去组合，或者需要更多的东西，包括防盗链跟踪、异常用户跟踪。
一个是服务分解，每个都是独立的微服务，第二，依赖关系完全没有了，第三个每一个都可以独立控制成本。
5.2 下载服务微服务优化
下载服务引入微服务之后，会从左边的只有原来的四大块管理，包制作、版本管理、成功率跟踪、成本限速，右边是除了做到原来的，拓展了包制作的功能之外，包括智能限速，用户等级、单用户、地域这些。
我们还做到一点，可以在异常用户里做到单用户级包括用户分级的能力，整个服务可以不断往前去拓展。
像用户分级里面有专属的礼包、专属的 VIP、用户关怀，对单独的用户做白名单限制，实时数据里可以根据用户的等级、地域去做，整个服务的拓展会更加灵活更方便。
5.3 我们引入微服务后的收益
引入之后可以达到几个效果，一个是灵活，可见收益。因为每个服务都是独立可以看到效果的。
还有独立计价，独立演进，还有拓展能力，上面那个图是非常方便的，可以随意往下或者往左右两边去扩展你的服务。
做完这个之后我们的收益是怎么样呢？
首先，玩家下载完成率我们提升20%，下载完成率是产品运营团队关注的玩家的下载时长，这个是玩家关注的，玩家下载时长下降60%，一个玩家下载一个版本包花的时间只需原来的40%就 ok 了。
另外老板比较关心的成本，我们在整个事情中成本消耗增加是0。显然好像还不够，还算了一个收益，因为我们不可能去导流用户过来，不可能吸引用户过来，但是我们可以在这个阶段让玩家不要流失，用户成功下载完以后就能让玩家进入游戏，这样就提升了游戏的转化率。
5.4 更进一步—礼包分发服务
如果说我们还想进一步提升转化率和下载成功率，我们能怎么去做，达成一个服务进阶？
服务你既然做出来了，你的项目组、你的团队，会给你更高的要求，你自己也希望更进一步。这里会有一个影响，你要关注下载取消和不转化的用户。这个时候我们想到一个东西，你要让下载取消和不转化用户，再增加一点东西吸引他，看行不行。
这时候我们想到一个游戏道具礼包，这个也不太复杂，这也是项目组给我们提的要求，希望说这个时候你能不能再增加一点东西，我们多投一点市场成本是 ok 的。
5.5 礼包问题的三座大山
礼包不是一个小事，这是一个市场资源进去要投放的东西，我们解决哪些问题，你必须有精准定位，给谁发，什么时候发，发什么东西。
接下来大家可能会想，这不是营销该干的事情吗，营销团队他可能来说可以帮我们制作礼包，但是在运维环节给谁，什么时候投和投什么，投什么可能他们比我们的专业度更好一点。但给谁，什么时候投放完全是由我们运维团队决定的。
怎么去做呢，首先做这个事情你需要去关注理解你的业务，简单一点，你怎样给玩家投，会有两个特性，一个是老玩家，一个是新玩家。
WHO？
解决 WHO 这个问题，我们会有用户分级，可以看到玩家的等级与付费的关系，玩家的等级越高，付费率就越高。因为我们需要决定给谁发的问题，是给高等级的玩家发还是给低等级的玩家发。
再看左边那张图，玩家等级成长分布图，中间有掉下来一个点，在130级，这是某款游戏的数据，130级的玩家很难升级，这时候如果来了一个老玩家，是个老用户，他刚好在120级左右的时候，那你给他发是最合理的。
这个很简单，其实就是数据分析的过程，所有做运维做技术的其实就是做数据分析。
WHEN？
要解决什么时候发的问题，因为玩家下载过程是个动态的过程，我们引入“智能+”，就是运维大数据的建设。
首先通过取消玩家下载完成比例的数据分析图，看到一个玩家基本上会在10%以内或者15%之间取消掉下载。这个区间其实还很大，我们提炼几个关键的因素，玩家目前下载过程中的当前完成率和当前耗时，都是当前而不是历史。
左边这张图是历史数据分析出来的取消的规则，右边这张图是实时数据取消的规则，还有当前下载的速度。
通过这个会形成一个拉格朗日函数，再用一个 SVN 向量机的方式找到一个分类的超平面，因为你三个因子可以去定义一个分类的超平面。通过这个你可以去划分一个玩家有可能取消的平面。
在实时下载过程中，这三个因子数据我们实时运算出来，越靠近这个超平面的时候，越不需要给他发礼包，当他离得更远的时候，更需要给他发礼包，因为他有可能就真正的流失了。靠这个平面他有可能会从取消变成完成。通过实时运算获取玩家下载过程中的取消概率，这个是我们解决的 WHEN 的问题。
WHAT？
解决发什么的问题，刚才前面提到不同等级的玩家，需要给谁发的问题。这个实际上在大数据里面也没有别的算法。基于隐因子模型的协同过滤推荐算法，确定正在单个下载玩家的礼包内容。
结论举例，在下载为 1879KB/S、当前进度为 5%、已下载10分钟的玩家，在进度 8%、15% 和 30% 会分别发送XX礼包。在运维领域看起来有点害怕，但实际上就看你敢不敢跨界用了。
5.6 “礼包+智能”效果展示
我们整个腾讯游戏运维也在慢慢跨向现在的智能化的时代。做完这个之后，有什么效益，我们在原来基础上将下载完成率提升了 8%，转化率在原来基础上再加9%。还不错的，也让运维的兄弟会觉得自己不只是说我就天天做个包往外分发，看看 CDN 的成本数据。
我会关注用户怎么从我所负责的环节流失走，我怎么能拉他回来，用一些营销手段，也会看到我们下载的实时数据里面怎么去给项目组更好的技术上的优化和解决方案。
6、“智能+”&“微”服务
目前我们整个服务的走向是“智能+”，以“智能+”的技术和解决方案去推进我们微服务不断往前拓展。这个微服务除了微服务框架之外，有个特点，就是无微不至，我们希望通过我们运维团队提供给用户无微不至的服务。
举例一下我们无微不至怎么去拓展，比如像下载服务可以不断往下拓展。
像安装登录服务也可以不断往前拓展。包括开服服务，手动开服和自动开服，在上线初期和运营期，哪些是可以做的，哪些是关注的。
包括最下面的，战力的差距，你开了一个新服的时候，当战力的差距不够的时候，我们会跟销售说这时候你应该给玩家推送一个礼包。
腾讯游戏运维服务进阶，刚才提到像智能化还有贴近业务之类的，我们整个运维团队需要具备六大能力项，需要有感知、分析、决策、执行、呈现，非常关键的一点是保护。
另外还有两个关键点，一个是整个团队的文化，还有一个是人才结构的培养。
同时我们浓缩了六个字母，为了让运维更好的记忆和理解，“CEBTOS”，贴近业务、理解业务，关注用户的体验，在质量效率成本方面找一个均衡，以技术导向为优先。
上面所有案例都有核心技术在里面，这里面也会体现你的团队的技术竞争力，拥有运营能力，同时你最终的产出，给用户看到的都是服务，并且需要非常关注安全。
