万用户的规模。

短短1个小时，就赶上之前一个月的总和还要多，这就是热点事件带来宛如银河倒灌般的流量，恐怖如斯。

陈默虽然心里有所预期，但没料到会这么夸张。

可不待他倒吸一口凉气，这口气就被运维主管先一步吸走了。

运维主管洗完凉气才把内心的燥热压了下去，不禁产生阵阵后怕。

因为前段时间陈总要他进行服务器扩容他还有些质疑，当时微信运营的确实不错，一个月百万在线，可让他准备承载千万量级的服务器，要知道服务器加上去闲置，对于他来说就像是如狼似虎的娘们嫁给伟哥，总感觉可惜了了。

当时他还是觉得陈总小题大做，可看领导坚定不移的态度还是照办。

还好照办了，看着目前服务器性能监视面板稳如老狗的曲线，他的心也安定下来，否则现在估计不光值班的他俩，整个公司的运维都得鸡飞狗跳，赶回公司亡羊补牢。

毕竟用户和流量来了服务器没撑住，首要责任就是自己，一个没处理好，造成了线上事故和公司利益的损失，那自己就可以卷铺盖滚蛋了。

幸好幸好，运维主管实时观察着各服务器的各项指标虽然猛蹿了一大截，但还在安全线以内。

随后他老神在在地喝着雀巢咖啡.

心里暗自感谢伟大的陈总，否则现在最忙的应该就是他了

即便微信这段时间经过了技术人员反复的测试和验证，尽可能考虑到所有可能发生的意外和结果。

随着时间的推移，当数据量达到一定的层级，还是有各种大大小小突发情况的发生。

一般的问题，经过反馈基本到李建超这里就消灭殆尽了。

可有极特殊的情况还是在前面三个小时内爆发出来，比如360那边数据传输格式在极端情况下会偶现脏（错误）数据等等

一开始所有人都认为是自身代码出现问题，在10分钟内李建超没发现任何端倪和报错后，立马上报给了陈默。

这时就轮到陈默出马了，仅仅想了不到10秒，陈默立马联系360技术协调解决，这边修复数据，先解决用户问题及时止损，再来查找原因。

但还是有新的脏数据产生，虽然几率比较低，经过孙子维扫描统计，只占整体千分之几，可放大到百万级的数据面前，那就是几百上千个用户出现问题。

陈默淡定下令，让许良手动持续修复错误数据，然后他带领技术排查根本原因。

随后在他牵头排查下，3分钟排除代码层面问题，5分钟排除中间件问

本章未完，请点击下一页继续阅读！ 第2页 / 共5页