腾讯T4技术专家吴悦：Web云服务是未来趋势

腾讯云9月9日在北京·郎园Vintage召开以“亿万云端，信心共享”为主题的腾讯云开放战略发布会。腾讯云终于揭开面纱，正式宣布全面开放。腾讯T4技术专家吴悦先生在大会现场致辞演讲，他表示，互联网的云服务其实背后是有太多太多的陷阱和挑战的，云代表的是一个生态体系，需要管理和维护来保证它正常的运营。

他提到，在生活中，数据的丢失和服务的中断不仅能造成经济上的损失，甚至还可能发生人生安全的事故灾难。

他表示，云服务所面临的挑战主要来源硬件、IDC以及运营流程规范三个方面。他认为，腾讯云代表的是一种技术上的追求，而长期在运营维护过程中积累下来的经验和形成的处理机制就是云服务本身一笔宝贵的财富。

腾讯T4技术专家吴悦：Web云服务服务是未来趋势(腾讯科技配图)

以下是吴悦演讲实录：

各位来宾、各位领导，大家下午好，我是腾讯的吴悦。

我今天想和大家分享的是关于腾讯云在运营方面的一些情况。其实说到运营，在我们生活中是无处不在的。我今天上午来参加这个腾讯云发布会的彩排，看到其实这样一个专业、高端、大气、上流，并且活泼的发布会背后是有若干个系统支持的，比如说音响系统、影像系统，还有很多专业人士的背后的管理和维护，这个就是一种运营。大家知道我们生活在城市里面，享受着一个城市便利的生活，在这个城市便利生活的背后，其实是有比如像电力、交通、供水、排水等等这样一个专业系统的支持，以及各个行业人员的管理和维护。在前一段时间，大约在8月30号左右，深圳市大暴雨，在凌晨的四点到五点左右有一辆汽车涉水遇险，非常不幸的是这个汽车司机去世了，一个年轻的妈妈，才三十多岁就离开了她的丈夫和她的儿子，这个是一个悲剧了，它其实反映的是在生活的云服务中因为故障而导致的一个事故。

其实在虚拟的互联网的云服务中，类似于这样的悲剧或者事故也是经常有的。我们接下来具体来看一看，大概在2011年3月份，当时谷歌(微博)Gmail发生了一个数据丢失，后来经过工程师的修复，最终数据是得到了修复。我们再看2012年6月份，雅虎的日本系统发生了一个故障，导致了5700家的企业数据发生了丢失，但是最后这个处理结果情况没有具体的公布，不得而知。我们再看同年的6月14号，著名的云服务提供商Amazon发生了故障，同年12月Amazon再次发生故障，导致了服务发生了中断。我们再看国内的一些情况，差不多2012年8月，盛大云由于故障导致了数据丢失，12月份阿里云因为电力故障导致服务中断。最近我们的微信也是因为光纤被市政挖断导致了故障。说了这么多故障是想说明一个问题，互联网的云服务背后是有太多太多的陷阱和挑战。我今天主要是就三个方面来跟大家做一下分享。

第一个方面是关于硬件方面的一个挑战，第二个方面主要是关于IDC方面的挑战，第三个是运营流程规范方面的一些事情。

我们先看一下硬件故障，这个数据是我们统计的在我们腾讯的磁盘的故障率的情况，差不多是月故障率是0.2几，但是这个硬盘如果服务时间超过五年之后，它的故障率更高一些，差不多是0.7几，这个数据说明了其实磁盘故障是非常常态的事情，所以我们设计的系统必须要能够应对这样的一个问题，我们设计了有三套的解决方案，有两份的冗余的存储方案，分别对应的是不同的业务场景，比如说两份的存储，特点是性能比较好，但是可用率的情况比三份稍微差一点，它主要是系统日志的数据，或者是这种数据计算中的中间临时数据，对于三份数据的方案，比如说微云数据，我们是把它存储在三份的数据拷贝里面，还有一种场景，是说一些对这种数据可行性要求比较高，但是访问性能要求并不是特别高的场景，比如说我们的一些历史归档数据，可能很长时间不会访问，但是它的数据可行性要求非常高，我要访问的时候必须要访问得到，这个就可以采取存储编码的方式，我上面讲的三种方案，以及它对应的可用率的推导，其实只是第一步。后面的挑战其实会更多，我们具体来看一看实际的情况，在我们腾讯的管理的硬盘，差不多管理了三十万块硬盘，如果我们按照刚刚讲的月度故障率是0.21%的故障率来看，我们平均每天差不多是要换20块硬盘。但是还有一个问题，是因为硬盘的提供商它有的时候也会有问题，会给我们提供一批有批次质量的问题，会导致峰值的时候故障率更高，我们一天要换一百块硬盘，我们简单地把这个数据折算一下，这个数据这个故障导致每天我们需要复制的数据将近上百T，上百T是一个什么概念?就是中国人每个人每天上传一张手机图片的数据也不过是一百T，这么大的一个数据，复制对我们内网的要求是非常高的，因为它是一个额外的复制数据的流量，这是第一个。

第二个是说你复制的数据量这么大，并且要去换的硬盘的个数又这么多，这里面如果是完全的人工处理的话，这里面会带来很多的风险，所以说我们会有一套自动化的处理坏盘的机制。我们看一下，一个硬盘故障从发生到完全结束，大概有几个过程，首先你要能够识别出来一个硬盘的故障，你识别出来这个硬盘故障之后，你可能就要去复制数据，复制数据完之后你需要把这个状态，就是把这个坏盘的情况以一个流程单的时候知会到驻厂，工程师经过换盘，恢复整个服务，这个差不多有五个流程，每一个环节都有可能出错，举一个例子来说，如何发现硬盘故障?硬盘故障本身就有很多种，有的是坏道，有的是坏块，有的是历史只读的故障，有的是软件终端导致的，你怎么去区分各种情况?这是第一个你发现硬盘故障就有很多场景，第二个是怎么去复制数据?复制数据这个过程中又有很多的挑战，比如说你在复制数据的过程中，有可能你的源盘出现了问题，也有可能你的目标盘出现了问题，每一个流程都涉及到很多异常分支，如果把每个环节的每个异常分支乘积下来看，这里会涉及到几十种场景，我们针对这么多的场景进行了上千次的演练，差不多用了五年的时间才完成了这样一套自动化换盘的系统。具体看一看，我们有一个磁盘健康度的管理系统，它可以预测磁盘的一个损坏，可以监测到磁盘的健康情况，这是我们的一个换盘的系统。

接下来我们再看一下硬件故障中的机器故障，机器在腾讯我们把它分成三大类的服务器，分别是接入类的服务器跟内存类的服务器，以及存储类的服务器，分别也对应了不同的场景，我们接入服务器主要是进行一些Web服务，内存服务器主要做一些计算逻辑，做一些存储缓存，存储服务器，主要是做一些DB的存储。可以看到机器的故障率其实也是蛮高的，月度故障率差不多0.1%几到0.4%左右，所以我们也设计了两套方案，分别是去应对这样的一个机器故障。具体来说是有两种，一种方法是我们通过N:M的冗余方式，当一台机器发生故障的时候，它可以通过负载均衡的方式把它的流量切换到其它机器，具体来说首先识别出故障的机器，识别出故障之后可以快速地把它的流量分担到其它机器上。第二种方法是1:1备份，主要解决的是DB类存储的一个问题，具体对应到刚才讲到的那个NoSQL和CDB存储解决方案。

当我们拿到这样两个冗余方案之后，我们怎么去实现我们业务的架构?我们通常建议是这样，第一个是说尽量地去使用这种NosQL和CDB的存储，我们接入逻辑和计算逻辑，把数据实时写入NosQL和CDB中去，如果自己本地没有持有这样的数据，你后面做这样一个切换的时候就非常简单，如果你持有数据，这个数据切换和转换就非常复杂，大家可以把复制数据比较困难或者比较有挑战的事情交给专业的服务器去解决。第二个是使用负载均衡去解决接入逻辑和计算逻辑的容错，我们的负载均衡刚刚也说到了，本身的可用性非常高，它还支持TCP状态的迁移，可以做到负载均衡内部机器异常切换对业务来说透明。

刚刚讲的是怎么去应对这样的一个硬件的故障，实际上我们在IDC方面也会遇到很多的挑战和问题，具体来说是分为两个部分，一个部分是我们可控的，比如说内网交换器的故障，或者是电力的故障，另外一种是我们目前来讲比较难去管控的部分。比如说运营商的一个网络故障，这里面我们也分别提供了不同的解决方案，像内网交换机，我们都采用了冗余的网络架构，可以保证说交换机故障对业务来说是没有影响的，同时我们也有这种备用发电机，电力出现故障的时候，我们会随时上线，保持电力不会被中断。对于运营商故障这一块，我们可以提供多个IDC的出口，同时大家知道我们的QQ、我们的微信，或者是我们的Qzone等等对运营商的故障都有很多非常好的解决方案，这个在后面我们可以继续来探讨。

我们在运营中出现很多问题，天灾只是一部分，人祸也是很大的一个部分，这是什么样一个原因呢?在互联网里面，它的很多的服务是非常动态的一个过程。每天都有可能有新业务接入，每天都有可能因为用户的增多需要扩容，可能也会有很多机器的故障，这里面的事件都需要人去处理。在09年6月份的时候，谷歌出现过一个问题，是它的一个反垃圾的服务，需要通过人工名单配置的方式进行加载，有一天运维人员在配置的时候不小心在反垃圾配置名单后面加上了一个根目录号，结果导致当天谷歌的每个页面都出现了一个反垃圾的提示。

具体来说运营流程分成四个部分，第一是要建立比较完善的运营规范流程，第二个是保障的运营规范流程要得到执行，第三个对各种故障必须有各种预案机制，第四个是保障预案机制在关键的时候要能生效。

我给大家介绍一下我们曾经遇到过的一个问题，这是2011年出现的一次事故，当时的背景是，我们的设备供应商提供给了我们一个批有问题的机器，机器的故障率特别高，正常情况下月度0.1%几的故障率，它的故障率达到了3%、4%。一天有一台主机发生了故障，主机的故障没有发出来，不幸的是随后导致备机又发生了故障，因为主机和备机同时故障导致了业务数据的中断。经历了这个事情之后，我们有一个NosQL的架构师进行了非常深刻的反省和总结，正好当时的时候中国发生了动车事故，他与之做了一个对比，动车事故是因为信号灯被雷劈告警和预警机制未生效，而我们的事故是机器告警和预警机制未生效。核心的点就是流程机制关键的时候掉了链子。所以这个事故出现以后我们就做了很多的工作，比如去审查了监控机制或者报警机制本身是不是有效的，这是第一个;第二个，我们做了类似于火警定期演习的方式，保证各个流程都能够定期被测试和应用到。

总的来看运营有两方面的事情，第一方面你本身的运营的流程要规范，你要有一些比较完善的运营工具的系统，并且你对各种的异常，或者故障有一套处理机制，同时刚刚讲的要有一些定期的故障演习。当然除了工具机制上的保障之外，人员的运营意识也是非常重要的。特别是在你的运营工具不是那么完善的时候，人的意识往往会起到非常关键的一个作用。所以说关于运营人员这一块我们也是做到了定期的培训，新员工过来之后，一定会把历史上所有曾经发生过的问题去跟大家做一次这样的培训，让大家认识到如果说运营上不严谨、不谨慎会有可能导致多么大的一个灾难。

我记得Tony曾经讲过一句话，“不精一技，莫谈一艺”。他讲的是腾讯的技术员工在技术上的一种追求，其实腾讯云也是代表了这样一个追求，腾讯云是我们腾讯的技术人员15年摸爬滚打这样一套经验的总结。我觉得这个经验总结对腾讯公司来说是一笔非常宝贵的财富了，同时我觉得这个也是中国互联网中一笔非常宝贵的财富，我们今天把这样一笔财富分享给大家，希望我们的每一位开发者可以基于腾讯云的平台获取非常大的成功。

我今天的分享到此为之，谢谢大家!