9月28日晚间消息，在多位信息化专家和技术专家问诊12306之后，大家最后都指向了同一个问题，12306产品不给力，与产品设计和运营管理团队的经验不足有一定关系。以下的2个实例或在一定程度上印证了专家们的判断。

　　搜狐IT独家解剖12306网站结构图

　　根据铁道部在2012年初对外公布的信息看，12306客票系统于1996年6月被列为“九五”国家科技攻关计划，1998年又列为“九五”国家科技攻关计划重中之重项目。是在铁道部的领导下，由中国铁道科学研究院牵头组织，由全国数十家高校和科研机构的上百名科研工作者联合攻关，采用核心技术自主研发、通用软硬平台开放的技术路线，历时两年研发成功。

　　在10余年的成功运营过程中，先后完成6次版本升级。其中，1.0版本实现了计算机售票取代人工硬板票，2.0版本实现了区域级联网，3.0版本实现了全国联网售票，4.0版本实现了与清分清算系统的对接，5.0版本实现了席位复用和共用，5.2版本了实现实名制售票、电子客票和电子支付。目前正在使用的，增加了“强制排队”功能的版本应该是5.2版之后的最新一版。

　　在实际操作过程中，开发和生产环境即软硬件平台采用外包方式，目前公开招标的也是这一部分，而产品设计和软件开发则是由中国铁道科学研究院电子所(以下简称铁科研)团队负责。

　　某国内知名互联网公司的技术负责人李先生向搜狐IT透露，2012年3月，他面试了来求职的铁科研12306产品开发团队的一位成员，该成员长期负责12306的架构设计。他向李先生详细介绍了12306的架构设计思路和过程，李先生认为这位架构师基本没有互联网产品设计经验。

　　据李先生介绍，12306架构设计中连基本的分布式和高性能都没考虑过，诸如读写分离、高并发下的分布式处理也没考虑过，系统也没有考虑设置不同数据库分布到不同的服务器上，甚至都没有考虑为读写做相应的缓存，整个流程中也没有考虑过队列，所以卡住后排队等基本情况都没想过。

　　而这些都是互联网架构师需要具备的最基本的思维，这位12306的架构师完全没有这样的思维。

　　其实12306这个系统的业务项比较复杂，跟机票系统一样，出票等业务规则复杂，由于规则负杂，会有特殊的颗粒、特殊的流，比如分段出票，退票、新增票等，所以必须要有相应的架构设计与之相对应。比如从技术角度看，订票是一个写操作，查询是读的操作，不能因为查询很多影响订票操作，需要通过使用读写分离就可以实现。

　　李先生认为，对于大的互联网的公司，12306是一个很简单的项目，好的架构设计再加上10~20人的团队，产品和技术一体，可以很轻松地做好。而李先生从12306的架构师处了解到，其产品设计团队基本属于学院派的团队，与外部接触比较少，没有任何互联网产品经验，他们把12306当做了一个内部系统来开发，开发完成后又作为一个外部系统开放使用。所以出现现在的问题是难免的。

　　另外这个团队解决问题的思维很业余，出了问题，比如出现拥堵就加服务器，再出问题还加服务器，服务器中使用了大量的小型机，价格都很贵。无限制地通过增加服务器来解决原始架构缺陷，人为地增加了系统成本。

　　有意思的是，一位曾经参与过该项目的搜狐网友也在搜狐网上披露：这个系统，当年有些生产环境是我搭建的，去过开发现场。整个项目也就十几个人吧，说实话，算下来一年人力成本三四百万撑死了。现场人员基本没有大型集成系统开发经验，否则不至于连环境都不会搭建。唯一让我印象深刻的是，现场吃的真多——红牛，可乐，方便面，火腿肠。。。至于系统本身呢，也很糙。铁科研没有买Oracle的现场服务，导致所有环境都没有厂家的支持及现场服务。这么大的系统，没有分布式，甚至连个集群都没用，两台机子共享存储，居然做的是单活，不是集群。通俗点说，本来可以用两台机子处理的事儿，生生放着一台不用。去搭建前对于软件服务器版本没有任何要求，很不严肃。。。根据我的经验，单单人力成本，最多五百万，加上服务器和网络成本，不到一千万。

　　另外“人称T客”也在微博中爆料：网友检验一下12306，爆露出这个这个神奇的网站，是怎么做出来的。 数据库： Oracle 应用服务器：WebLogic 开发框架：Spring\Hibernate\Struts 连接池：C3P0 没有做基本判断，输入特殊字符，直接SQL语法错误，完全没有经验测试，太极这3个亿赚得好轻松呀。连SQL注入防范都做。