抢购时网站宕机，没必要苛责百度、小米、聚美优品、京东、苏宁们

昨天早上10点28分，百度 金融 平台的理财产品“百发”上线，可不幸的是，当我打开其官方页面，准备一探究竟时，之前预想到的情况发生了——登录页面没有响应。遇到这种情况的当然不止我一个，这种状况持续了大半天，所以当不少人终于成功进入这款产品时，却发现在下午2点50分时，百度的10亿限额已经全部被购买光了。

于是，对“百发”的热情和期待，一瞬间转变成了对百度的口诛笔伐，我看到最多的声音就是认为这次“宕机”事件完全是出自百度的策划，将其和最近在风口浪尖的小米公司一道，扣上“饥饿 营销 ”的帽子；还有些人将不忘将京东、小米、聚美优品、苏宁易购等出现过类似问题的公司一道拉出来鞭尸，“提醒”他们在营销之前，应当做足准备，以免伤害用户。

可实际上，如果你稍微了解一下“百发”等产品所面对的状况，就应该明白他们的这些失误情有可原。

首先，从 技术 上而言，百度只是个“新手”。 百度虽然是一家后端技术强劲的互联网公司，但长久以来，百度对并发的技术积累都是“大并发读+小并发写”的模式，换句话说，百度以往处理的主要是大量用户同时调用服务器内容的请求，在并发写入上，所遭遇过最严峻的，可能也就是百度贴吧被“爆吧”的状况，对于购买支付这类“大并发读+大并发写”的项目，百度确实没有什么应对经验。

其次，有些技术方案是“无法准备”的。 对于在线服务而言，当一个平台从小到大的发展中，随着用户量的增加，往往伴随各种“状况”，工程师们要面对的不仅是底层架构的变迁，还有代码审查、应用服务器参数的调整、服务器容灾、限流等各种问题，在去年的双11 活动 中，阿里巴巴就准备了400多个系统降级预案，这显然是需要长期积累的。

可一旦这项在线服务发展的过于迅速，或像百度、小米、聚美优品、苏宁易购这样一开始就要面对如此大的读写并发数，那么除非企业能够从外部引进对此有丰富经验的人才，否则“犯错”是在所难免的事情。要知道，eBay在初创的几年中，经常宕机、断电且毫无 安全 性可言，直到Gateway信息部门主管Maynard Webb加入才得到改善；Twitter在2008年上半年，还经常处于停机状态，这和他们无法招募到优秀的扩展性工程师有关。所以京东才痛定思痛，在2012年初招揽了来自盛大云、甲骨文的几位顶级人才。

此外，有时可能并非这些公司想犯错，而是银行们拖了后腿。 还是在这方面具有最深厚功底的阿里巴巴举例，2012年双11时，阿里巴巴除了在技术保障方面已做了充足准备，同时不断的在号召消费者提前将现金转移到支付宝，原因在于——每当在这个时机，整个支付通路的压力会非常大，他们担心当天中国各家银行网银网关受不了。对于涉及金融交易的服务，不仅包含大量随机互动工作，还要求整个系统在零失误的环境下运转，所以对于这些互联网企业而言，一旦网银网关难以应付大规模的流量或是自己的服务器遭受过大的压力，他们能做的，只能是通过限制带宽等方式，来确保整个系统的安全，最严重的情况就是要切开关断网了，否则后果不堪设想。 更何况，百度这次还要照顾到华夏基金的服务器和网络。

最后，在“百发”的交易中，百度也没有理由使用“饥饿营销”的手段： 一方面，如我之前所说， 百发总共只有10亿人民币的限额 ，相对于阿里巴巴余额宝超过1300亿的申购总额和华夏基金自己的400亿额度而言，盘口太小，根本没有必要玩“饥饿营销”；另一方面，百度否认“8%年收益率”承诺也是为了回避政策风险，毕竟他们已经被监管部门盯上了，和单纯的营销噱头在本质上有所不同。

所以，无论是阿里巴巴、百度、小米、聚美优品、京东还是苏宁易购，他们在应对和支付金融服务时遇到的实际挑战，要比大部分人想象中要困难的多，一旦出现错误，带来的将是难以估量的损失。对于这些不断在业务模式和规模上挑战行业和自己的互联网企业们，我们不应当有太多苛责。