李彦宏该怒了,百度怎么可能宕机半个小时
中国互联网发生了一件大事,百度,以技术见长的百度,居然移动搜索宕机了30分钟!李彦宏确实该怒了。本文分析和猜测了一些可能宕机的原因,最后,还是期待百度的官方分析,聊以借鉴。...
中国互联网发生了一件大事,百度,以技术见长的百度,居然移动搜索宕机了30分钟!李彦宏确实该怒了。
对不起,得知百度移动搜索宕机了,并不是由于去搜索,而是从微信朋友圈看到了一则消息。后来确认,是收到的第一条关于百度宕机的消息。这条消息的时间大概是晚上8点54分。当时,也没有太在意,还以为是恶搞,或是愚人节笑话。但之后,又连续看到了好几条,于是,就上去试了一下,发现首页还是好的,但是输入搜索词之后,确实发生大事了。后来听说PC搜索并没有宕。
从跟踪朋友圈看,大概晚上9点24左右,百度的移动搜索终于恢复正常了。这时,30分钟,堂堂的1800秒,已经过去。在互联网这个分秒必争的时代,在各大公司比拼三个9或是四个9的无故障服务,能宕机这么长的时间,确实百度内部是个大事故,吃瓜群众见识了一个大笑话。
后来,不严肃的百度PR部门,不是以科学的精神解释这个事件发生的原委,而是娱乐至上的在公众号发了一篇文章《“大家一直用的搜索引擎”不正经了一小会儿,很抱歉!》,不知道李彦宏看完是不是该气晕过去,刚上任的一向严谨踏实的新总裁先生是不是该无语了。还好,对吃瓜群众来说,文章还是透露了一点有用的信息,说是“错过了大家上亿次的搜索请求”。那么,估算一下,30分钟一个亿,一天24小时,那么百度一天的移动搜索量大概就是48亿,也就是50亿上下,还是挺多的。
好了,言归正传,虽然知道百度的整个系统很复杂,我们还是来大胆分析和猜测一下这次宕机的原因。
由于百度的首页和PC搜索还是正常的,基本上,应该可以排除域名服务,运营商,数据中心,网络,硬件的问题。正常情况下,像Google,百度,这样大型的搜索服务,一般会部署到几个数据中心,比如,在Google,要求的是N+2个不同的数据中心,一个中心在服务,一个中心可能在维护中,那么还有一个中心可以提供线上灾备,这就是为什么需要N+2。这样就算一个数据中心和它的相关硬设发生了问题,全球流量控制系统能迅速的调整DNS,让其它的数据中心很好的接管服务。
这么看来,应该推断是软件系统的问题。也许,百度当时正在升级移动搜索服务。按正常的流程,应该是先升级一个数据中心的服务,观测一段事件没有问题之后,才会升级所有的数据中心的移动服务。就算是没有管理,没有流程控制,一下升级了所有的数据中心,由于搜索是一个无状态的服务,不象电商交易网站,应该有回滚的机制,一旦发现问题,不是在线上调试,希望能很短时间内修复问题,而是立即回滚,让系统回到升级前的正常工作状态,保障用户的服务是第一优先。这么大的公司,这么长的历史,不至于这些都没有吧。
如果不是正在升级线上系统时发生问题,那么又可能是什么呢?现在的搜索系统的架构,一般是一个Root服务节点,下面有多个Parent服务节点,之下有多个Leaf服务节点,每个Leaf节点负责一部分网页的搜索,然后将搜索结果返回给Parent,最后由Root节点综合所有的结果,给出最后的排序结果,也就是一种分而治之的思想。如果一个数据中心的移动搜索服务宕了,最大的可能是Root服务节点出问题了,否则的话,至少会有部分结果。那Root最有可能的宕机原因是硬件出问题了,内存不够了,或是磁盘满了。但一般Root这种SPOF节点,一定应该由Backup,也就是Backup也出问题了,这就不大可能是硬件问题。
还有一种大面积出问题的可能,query of death,就是一个有问题的搜索词,触发了所有系统节点的bug,引起所有的系统节点都crash,不能正常服务。这个问题在搜索发展的初级阶段是很有可能的,然后,人们在设计系统时,专门有机制来处理这种问题,比如,在前端服务器中有黑名单机制,在着急的时候,先把这个搜索放到黑名单,这个搜索词就不会往后面的树状服务传播,然后再慢慢修复。
再说了,百度运营了这么长的时间,又是以技术见长,系统,架构,灾备,防攻击,监控,报警,流程,规范,紧急处理,等等,都应该很完备。那么问题,究竟会出在哪里呢?
网上有阴谋论,说是百度最近在员工评级,可能是有不满意的员工在报复性的破坏。觉得这个不大可能,所有的线上服务的操作应该有一套完善的流程,应该有抹不去的记录。比如,在Google,要做线上的修改,首先必须有代码准备,然后代码审查,然后有领导审批,最后才会有运帷人员负责执行操作。对于重要的服务的上线,一般会是两个人配合,一个人操作,一个人监察,防止误操作。除非百度没有完善的管理机制,否则不大可能破坏。再说,就算破坏了,那些日志也足以把坏蛋揪出来,绳之以法,谁会愿意去冒这个牢狱之灾的险呢。
能想像的一种可能场景,监控系统报警移动服务出问题了,运帷人员接到报警后,认为是个小问题,不遵守流程规范,直接在线上修复。在修复的过程中,可能是误操作,可能是对整体系统不够了解,结果引起了连锁反应。这时,发现事大了,准备回滚,但是,由于是线上直接修复,系统状态发生了改变,某些重要数据被系统修改了,回滚也失效了,这样,麻烦就大了。所以,才会花了30分钟,去线上诊断问题修复,或者是直接从早期备份导数据。否则,30分钟实在没法解释。就算这种情况,也不是特别好解释,难道百度移动搜索只在一个数据中心部署,没有备份吗?搜索,毕竟不象一个交易系统,需要保存状态,需要强一致性,数据库是SPOF,就像上次github出问题,需要从备份数据库导数据,花了很长时间才恢复。
总之,感觉还是百度的管理和流程出现了问题,否则,30分钟,1800秒,太难解释了。不管如何,但最后,作为一个外人,还是期待听到百度自我调查的结果,聊以借鉴。
关注 待字闺中
![](https://www.a-site.cn/static/down/wx_205x205.png)