这次事件后我反思，如果我若没能把这个突发状况搞定会怎么办？海南现场维护的同事还能向我求助，我当时还能向谁求助么？当时已没有比我更熟悉这个系统的人，原来求助我的人，已将我当成最后能降妖除魔的「大圣」。
在崩与不崩之间之后，电信全集团发力推 3G 后，我们的产品卖了很多省，第一次试点在人最少的海南省出了一次大问题。后来又在人最多的浙江省出了另一次问题。本来浙江的单子是竞争对手用免费占坑策略拿下的，但用免费策略占了很多坑人却不够，所以浙江这边对手公司一直只有一个现场售前的人。浙江电信已经提前放了电视广告出去确定要在指定日期准时放号推广营业，但他们系统其实还没开始实施。临近 deadline 对方还没派人，局方毛了就拉了我们公司进场一起做，谁先做出来用谁了，而且不免费承诺了几千万的后续合同。
就这样我们的产品因为已经顺利实施了其他多个省份，所以进展很快，一个月左右现场对接实施基本全部完毕。到了电视广告的放号日，早上 8 点公司领导和局方领导全员到场，局方还请了埃森哲做咨询协调各厂方工作，埃森哲弄了个大屏幕监控各厂方系统上线业务情况和系统运行指标。然后就在 9 点一开门营业后不久，从最前端 CRM 和 BSS 系统来的大量工单就蜂涌而至（看来那次电视广告营销效果很不错）然后我们的系统就看着 CPU 不停的攀升，很快就变成了两条直线，两台 IBM 顶配的 128 U 小型机 CPU 全部跑满 100%，然后进入压单阶段。
压单是个什么体验呢，就是你跑去营业厅开了个新手机号，交了钱两小时还不能打电话，这比双十一买个东西晚一周送到要难受点吧。当时公司所有领域最好的技术人员全到齐了，有专门优化 Weblogic 的，有搞 Oracle 的，有厂商磁阵的专业支持，我和另外个同事负责应用性能，同样在现场看代码还能怎么优化。其实那个年代的瓶颈大部分都出在数据库上，应用都是围绕数据库为中心构建的，如今互联网公司这套分布式架构还闻所未闻。
只是奇怪瓶颈一般在数据库，怎么 CPU 那么高。后来通过分析发现是因为浙江电信有些特殊逻辑很大一部分是通过动态脚本由现场实施人员编写的（产品框架支持），这部分特别消耗 CPU，工单量一冲过来 CPU 立刻就飙升。我和另一个同事就在现场不停的把脚本的逻辑改成原生代码的实现，并立刻上线观察效果，改了几个比较重的脚本后，CPU 立刻就下来了。期间我们一直担心硬件先烧坏了，还好 IBM 的小型机质量还是过硬的，100% 跑了大半天。
其实这次系统再次走在崩溃边缘，但我并没有比以前更大的压力。我知道不管这次问题出在哪，会有相应领域的「大圣」能处理好。
走在程序员的路上，久了总会碰到一些系统崩溃的事件，很多时候并没有「大圣」踩着七色云彩来救你。系统崩溃就像老君的炼丹炉，「大圣」于其中练就火眼金睛，玄铁肉身，丹炉不崩溃，「大圣」何归来？
在程序猿们成长的路上，每一次系统崩溃事件都是一个不幸的开始，但未必会有一个不幸的结局。
posted @
相关文章
精彩导读
热门资讯
关注我们
