2016年7月26日，『腾讯智营』与『腾讯云』联合举办的第四届游戏运营技术论坛在上海瑞金洲际酒店圆满举行，腾讯网络平台部总监吴坚坚以“腾讯游戏海量业务下的网络运营”为主题做了精彩的分享，以下是他的演讲实录。
一、稳定与盈利
在腾讯的运营里，有两句话：让业务在线稳定地多运营一分钟；让业务每一分钟多盈利一点。
这是我们做运营、数据挖掘、营销中最关键和最核心的体会和理解。
很多时候 ，我们工作的任务目标都是围绕这两句话去开展。要做好整体的游戏运营，涉及数据中心、网络、服务器、应用、运营商、终端、用户这些层面，我们不仅要了解这些层面上的结构及运作机制，而且要深入了解对数据中心的容灾、光纤、路由的调整和独立化、出口的调度、平台级的保护等方面的细节，才能更好地建设和运营。
二、游戏运营的持续思考
我们现在遇到什么样的痛点，矛盾是什么？在未来，这块还会发生什么，怎样去做，这两个事情要持续思考。宏观方面遇到哪些压力和瓶颈或者是哪些策略需要调整；微观方面怎样做精细化地操作。下面是我们持续在想的一个思考模型。
三、DDOS攻击的洗礼
做游戏大家都知道，人在江湖飘，哪有不挨刀，DDOS攻击这个顽疾一直都存在，这不是技术问题，而是生态链的问题，越大的利益，就有越大的竞争。
目前DDOS有以下三方面值得关注：
- DDOS攻击本身难以追根溯源，导致其攻击数和攻击规模在不断的增长；
- DDOS攻击的防护能力要求较高，小公司投入成本和速度跟不上外部的变化；
- 运营商在流量治理上有起色，但是发展比较慢。
我们的防御分为三个层面:
- 洪峰流量（超高攻击流量），超出自身带宽容量承受范围，为了保护平台，就要壮士断臂，与运营商联动封堵。
我们一直与运营商合作，希望运营商层面给我们的更快，更准，更有效的封堵，同时思考怎样联动起来做更好，能不能在技术上做数据联动。 - 特大流量，即攻击流量在腾讯清洗中心的防护范围内，启用很多网关式安全防护来保护IDC。
- 在流量清洗的基础上，建立了集群式清洗。
今天着重讲讲洪峰流量，讲讲腾讯和运营商合作的案例。下图是两个腾讯的数据中心，同时，运营商的骨干网可以看到整个攻击流量，很多时候运营商层面过来的攻击流量已经对骨干网造成压力了，这个压力很难在某个单体上面消化，那怎么办？
我们的做法是与运营商做合作。
- 腾讯会做一个DDOS的triger（触发器），然后做一些联动，对接好协议和Community上传。
- 每次一有攻击，发生特大流量报警，我们会triger（触发）一些设备，对运营商发布路由。
- 然后运营商会在自己省网路由进行反射，反射到大的核心节点里面。
- 通过路由反射器，把流量反射到省网的骨干设备商，这样特大洪峰流量就不会到腾讯的IDC中，而是导流到省网的黑洞路由中。
这个过程不需要太多清洗，只是在特大洪峰攻击时，把IP在运营层面上清洗掉，就不过来了，根本访问不到腾讯IDC内部的。这样在整个平台的保护上起到非常大的效果。
在跟运营商的合作商要注意一点，首先要尊敬一些习惯。例如跟运营商对接需要采用网络设备对接，而不是应用API对接，运营商会担心自行开发的应用有潜在的Bug，可能把整个大网搞瘫，可能会撑爆清洗网络。
或者是无故发送腾讯的IP地址过去，运营商会怀疑你是否会倒卖流量和带宽。所以一定要跟运营商有很好地协调，而且要控制发送的频率和总量，这样双方都会有保护。
在建立好联动机制后，怎样保证这样的triger是一直在跑的，怎么知道这个机制是跑得通的呢，我们建立影子IP，把平常几台不用的服务器当作靶子进行攻击，触发保护机制，验证整个流程的效果，以期望保持新熟练度，持续运营。
四、全球利剑
在全球所有的25个运营商出口我们都覆盖了利剑（清洗中心）。所有互联网出口实现了封堵能力，我们堵过248G的攻击，腾讯有很多的数据中心，哪一个出现DDOS攻击，都下发到出口的黑洞路由，就防护了一个最高峰。
但是，每年都要去买一些黑洞的或者是清洗设备成本非常高，我们希望简单的方式，在路由层面，在运营商骨干层面就消失掉。
这里还有一个问题，我把IP封掉了，我看不到IP还有没有流量进来，我怎样知道当我封了以后当前还有没有流量攻击IP呢？可能解封以后再来还有攻击，这个过程现在也是比较头疼的，的确没有很好地解决方法，只通过定时放开检测攻击流量。
后续希望通过运营商的大数据来确认攻击的开始和结束。因为它有全网的分布，然后结合安全策略，确认什么时候封，封多久。
进而结合腾讯云的伸缩调度，攻击时扩张腾讯云保证前端的带宽供应。还有蓝鲸的自动化能力。这些联动在一起，即使在攻击发生，也能有准确的判断和弹性的扩缩容支持。
这就是未来腾讯的防御能力上需要持续做强和做精的，通过与运营商的合作和自研防御系统，持续高速增长。
五、自由切换出口流量
由于各种自然灾害，运行商扩容割接等，会对业务持续运行造成影响。怎样降低这些情况对业务造成的影响呢？
在腾讯有一个TIX的平台（公网交换平台），主要起到IDC资源扁平化供给的作用，中小运营接入在TIX上。
TIX的优势如下：
- 可以产生价格的博弈；
- 摆脱对单一运营商强依赖；
- 流量灵活调度；
- DDOS集中防范；
- 跨园区出口共享。
简单来说，全国有很多的数据中心，每个数据中心都会有这样的TIX汇聚平台，接了很多的运营商，所有的出口都接到高速互联，这样内部就有一个可伸缩、可调度的网络。怎样做呢？
举一个实际例子，比如说今天我们检测监控系统发现默认广州到A运营商的流量全部都从深圳出去，同时，发现上海的网络质量比较好，覆盖地区比较好，那怎么办？我就可以做一些调整，把出方向的路由调整到上海方向， Community 配值配好，广州的路由删掉，这就出到上海去了。
然后入方向，将广州的CAP地址进行向上海A运营商进行明细广播。这样就会通过路由层面把基于业务的IP在不同的业务出口进行调度。很多时候运营商的调整也好，阶段性的质量变化也好，内部都是通过这样的路由调整进行规避和优化的。
调整出口方面很难做到精细化。腾讯的做法是把全局的路由收集起来，通过大的数据集群进行路由计算，确认哪个路由更好。然后路由集中计算后，会重新发给本地路由控制器，通过I2RS的设备给到出口设备，然后通过反射器反射到全局出口，进行调整，这个就是内部通过I2RS实现的。
可以看到，在这样的平台上，我们在2015年主动规避了137次大网的调整，规避了8000多分钟由于割接变更导致的影响。
还有一些大带宽切换，比如说天津大爆炸，把天津的流量都割到上海、深圳这样的地方，全部做路由器上的割接，全网时间是1分钟，全网实施分钟级的调度流程。其中检测、工单什么的加起来时间会较长，但是技术实现就是1分钟。
你发布出去，运营商本身还有收敛的时间，整个策略在全网，包括腾讯游戏所在的数据中心能实现百G出口调度，为整个腾讯游戏保驾护航。
六、细节+实现=未来
未来，还有很多可以想像的空间。比如说通过质量监控触发，通过路由收集、集中运算、接口下发、全局反射等。但是我认为这些实现不精细。例如我调整了A业务，B业务会被顺带调整，B业务有可能因此受到影响。
所以，在这个地方未来会有改进的空间，有更多的参数输入，集中运算，集成很多业务属性和时间上的参数输入。
比如说，一些业务相对成本敏感型；或者是运营商出口比较廉价的，在低峰期和高峰期进行一些参数输入和控制，以控制好成本。这样更加精确和贴近业务诉求。计算出最佳策略后，通过路由器下发，从而使用路由层面的控制面进行协同。
第二个是细分到业务本身，比如说今天我要调度A业务，那么调到哪个省份，哪个AP段哪个逻辑，这是TIX平台调度精细化运作的动作，已经在腾讯云上面部署了很久。
第三个是我们在腾讯里面也接触过很多的一些代理的游戏，代理游戏都是黑盒，很难配合你做各种优化，怎么办？在代理游戏的通讯协议和调用方法不太完美的情况下，很容易出现局部的突发。有些游戏是多对一的通讯模式，有些微突发的不可预测性，这些情况都造成排查很困难。
七、突发！突发！
不知道大家有没有这样的感觉，我们所用的网络架构是为了以前的游戏所打造的，随着时间流逝，你的单机的网络成为瓶颈，但是这个瓶颈表现并不是网络中断或大量丢包，可能是微乎其微的小突发意外，而且出现很不规律，很难发现问题。
例如游戏中，大家都会有选英雄雄的这个场景，用户选择英雄一次，后台服务器进行重新匹配，游戏架构它没有做集群处理，一个大区多个房间开启，就是多对一的场景。
其中一台服务器是做匹配运算，许多用户一起大量点击，会带来多对一的请求流量，这一台匹配运算服务器就会抽风。
网络抓包下来是140Mb/s左右。继续抓包，发现它已经达到了千兆网卡的极限，在0.01秒的内，达到服务器的瓶颈。这种现象很难抓取和看到。很难说这个微突发什么时候发生，我们怎样发现呢？
所以腾讯和厂家合作，通过与芯片厂家的合作，设定Buffer利用率阈值监控。当Buffer利用率超过80%的情况下我会进行加权，加权到一定程度下，我们认为端口服务器的流量模型超过了可控的情况，就触发告警规则和策略。
进行主动上报。发现微突发的问题，特别是在老旧架构上怎样发现，突破点就在Buffer上，解决微突发上的难点。
八、预测
第四个我想讲讲未来的事情。磁盘故障率比较大，处理也比较耗时，特别是数据迁移，人工更换坏盘等，磁盘故障总是出现在不经意的时候，特别是晚上。我们在硬盘和服务器本身层面能否做工作，通过算法和数据进行推演，能否发现硬盘上的问题。
当你发现一些症状，通过观察外部指标，可以预测设备的故障和影响，顺着这个思路。通过大数据把一些有问题的指标汇集起来，找到将要故障的磁盘，这就是所说的前期预测判断。
腾讯的服务器数量摆在那儿，海量的磁盘。把整个运营的磁盘状况监控起来，把现网所有硬盘数据推进去进行学习，然后进行模型预测，预测以后有一个结果，把预测为坏的硬盘更换掉。
这里有一个问题，磁盘更换了以后无法确定预测到底准不准，有没有坏。把这些硬盘拿下来给到厂家。通过厂家更苛刻的底层数据分析，厂家会有验证结果。通过厂家的判决与预测结果对比，然后反过来推算模型的成熟度。
我们从指标大数据分析出来预测值，给到厂家，发现有90%以上的准确率。根据已经发生的Case推断即将发生的，进行Case和Cracking的判断。健康指标的监控，我们也在做，，通过日志采集关键字来预测未来是否发生Failure的东西，这些模型都有。
我们也有用到偏数学的东西。比如说用磁盘的SMART信息，已运作的硬盘和无运作的，都拿来进行SMART 进行对比。这样的情况下有一个分值，这个分值可能是通过SMART值的对比，说明可能这个指标不健康，这样就有一个预测故障，这是系统模型。
第二种大概是这样，这一片出现过ABC三个事件，这三个事件出现过后，可能一段时间硬盘坏了，这就是一个不健康的指纹。这是通过事件的发生，顺序来预测，磁盘坏之前会有这些表征，这些我们称之为磁盘的特征串，然后我们扫描线网运作中的硬盘，大家可以看到这个硬盘有这个特征串，可能未来会坏，这些磁盘定位为高危硬盘。
当然还有一些指标，我们内部有几个指标，一个FP（预测故障错误）、TP（预测故障正确），磁盘上面是这两个指标，你预测越大率越低。腾讯的磁盘比较多，这样我们有比较好的大的规模，我们有很多的数据，持续地对这两个数据调整。
FN（漏报），这是预测值，7天后损坏准确率为58%，单一模型最高综合准确率20天内损坏有81%的准确率，但是，不可能提前20天让你换磁盘，要把时间窗缩小到一个合理的时间窗，所以时间和准确率要取一个平衡。
这个服务上线三个月，主动预测并处理2000单的Case（换硬盘），主要是保证业务换硬盘怕影响大家的工作。我们每个月产出一个病例库，病例库一般是准确率80%。
下面讲讲怎样减少更换硬盘，因为你换硬盘拔插，换一个硬盘就要消耗一个人一天的时间了。所以，在线修复是个更优的选项，每个厂家是有隐藏扇区。
假如其中一个扇区坏了，就从可替代扇区上面划一块补过来就可以了。就在File Syetem Rewrite一下即可。很多时候业务写东西写不进去，在线上通过蓝鲸调度，通过File syetem Rewrite调整扇区。
提醒一下，Rewrite是有限的，不要拼命Rewrite，这个是有限度的，最高补了9次。如果换成人来更换磁盘，就需要更多的时间，也需要更多的人力。在线替换坏扇区就显得小巧灵活了。这时我给大家输送的一个技巧。可以通过SMART监控这方面的消耗情况。
-END-
欢迎关注“互联网架构师”，我们分享最有价值的互联网技术干货文章，助力您成为有思想的全栈架构师，我们只聊互联网、只聊架构，不聊其他！打造最有价值的架构师圈子和社区。
本公众号覆盖中国主要首席架构师、高级架构师、CTO、技术总监、技术负责人等人 群。分享最有价值的架构思想和内容。打造中国互联网圈最有价值的架构师圈子。
长按下方的二维码可以快速关注我们
