問診12306之四：產品設計團隊缺乏經驗

        【搜狐 IT 消息】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 注入防范都做。