[原创]从奥运售票系统的崩溃说起

这几天关于奥运的消息中有一条特别扎眼，奥运售票系统崩溃了。据媒体报道，系统设计的每小时处理能力为3万张，而实际每秒的提交量为20万，官方的理由是超出预期，一个非常可笑和尴尬的理由！

何以见得尴尬和可笑呢？撇开背后可能的主办方和软件提供方的猫腻不说，我想从软件需求分析、需求设计、系统设计、开发过程管理以及系统运行监测几个角度来谈谈这个问题：

1、首先说需求分析。北京奥运是中国有史以来最大的一次国际盛会，不说人家外国人，单13、14亿中国人的热情就必须充分考虑和预见到，更何况喜欢凑热闹是我们国人的一大具有悠久传统的爱好。每小时3万，每分钟也就只有500张票的处理能力，这与可能几千万、上亿的希望购票的需求相比，很显然从结果来看，主办方和软件提供方是在用屁股思考问题。

2、有了需求，就需要系统设计来支撑这个需求了，从架构的规划、数据结构甚至到如何进行数据处理优化的细节进行充分考虑，雇用顶级的架构、数据库专家来负责系统的整体和缜密规划。在设计系统的处理能力时，考量系统可能出现的任何问题、故障是软件设计的基本常识，可惜这么大一空前盛会，刚开始售票就出现了系统崩溃的尴尬，无不说明了设计能力的低下。其实举个简单的例子这个问题就不会发生，比如，把目前系统在线人数作为一个动态指标管理起来，一旦达到某个上限值，就拒绝其他人登陆，然后逐步释放登陆许可，这样也不至于系统会垮掉。

3、再说开发过程管理，严密、科学的开发规范是首先的，这个早就有章可循，这么大压力的系统肯定要选择有CMM资质的顶级软件提供商了。而且，主办方自己也必须有CMM和实施方面的顶级专家来监控开发、测试、数据初始化、系统模拟运行等等。不然，就国内已经过CMM（N）级的多家公司的产品来看，他们包括金X公司在内显然是在偷奸耍滑，那么质量自然就无法保证。而且各种量级压力的监测报告必须好好记录和保留下来供后期运维参考，因为只有通过严格、严密的压力测试我们才知道系统的极限能力在哪里：什么情况下系统可能运行速度会较正常值慢，什么时候会特别慢，什么时候会出现假死机，什么时候真的会死机。。。在系统运行监测中才能够动态监控系统性能，及时采取应急措施以免出现系统崩溃的尴尬境况。

4、经过再严谨严密分析、设计、开发、测试的信息系统也需要一套好的运行监测机制，而且关系这么重大的系统一定是24*7的专家级动态监控。只有这样，在一旦出现了威胁系统极限能力的情况出现时就有事先经过多方论证的预案付诸实施以保障系统的正常运转。ITIL中有非常完善的参考，而且ITIL在中国也是运行了很多很多年了。

主办方辨称，事先其实经过了大量的压力测试，但似乎这是一个无力的狡辩。这个尴尬背后是什么在尴尬发生了以后已经不那么重要，重要的是这种尴尬从技术层面反应了一些IT领域先进思想在国内的尴尬现状，就像ISO9000一样，善于搞形式主义、崇尚差不多文化的国人，在特别需要严谨、科学的态度和行为风格的大型IT系统面前依然是做做样子、我行我素、弄虚作假。这，也许是阻碍中国软件业、IT应用实施领域真正上档次的一个非常重要的原因吧。

但愿一向优越感冠全国的八旗子弟们不要再在世人面前象这般露脸了。