假如我來架構12306網站---文章來自csdn（Jackxin Xu IT技術專欄）

（一）概論

序言：  此文的撰寫始於國慶期間，當中因爲工做過於繁忙而不斷終止撰寫，最近在設計另外一個電商平臺時再次萌發了完善此文而且發佈此文的想法，指望本身的綿薄之力可以給予各位同行一些火花，共同推動國內的大型在線交易系統的研發工做，本文更多地站在軟件工程角度來看待整個問題，有關後續的技術問題研究，將在另外的博文中予以探討。

 

   一年一度的國慶大假剛落下帷幕，因爲此次長假是歷史上最長的一次，所以出行問題備受關注，而鐵路出行做爲最主要的出行方式更是你們討論的熱點，老生常談的購票難問題又被提起。這幾天我在網站上也看到不少關於12306.cn的討論，不少網友都發表了本身對於鐵道部購票網站的不滿，更有不少同行討論了關於12306網站的設計問題，期待可以貢獻本身的綿薄之力，我仔細拜讀了其中至少10篇文章，不少同行可能是站在技術的角度來考慮，其中不乏不少有創意的想法，純粹的技術設計能解決一些問題，不過彷佛不可以全面地解決這個龐大的、堪稱瞬間流量「世界第一」的實時交易網站，目前12306的問題與其說是一個技術問題，還不如說它是個軟件工程問題，道理很是簡單，請看以下的新聞報導：

        [[[回望12306網站在2011年12月底以來的表現，鐵道部高層也直呼想不到。       鐵道部副部長鬍亞東介紹，今年第一次在全國鐵路實行網絡電話訂票，截至1月8日已經達到天天200萬張，12306網站的註冊用戶已超過1000萬人。1月1日至7日，「12306」網站日均點擊次數已經超過了10億次，專家認爲瞬間點擊可能達到了「世界第一」。         高度的關注、巨大的訪問量，致使12306網站頻繁出現系統崩潰、沒法登錄、沒法支付等狀況。         「像春運這樣龐大的需求量，難道鐵道部沒有預想到並有所準備？」隆梅資本管理有限公司副總經理馬宏興對此困惑不解。       在探究12306網站問題的深層緣由以及解決之道時，各家見解不一樣，「12306網站的問題最終仍是系統架構的問題。由於用戶有大量的動態、交互式訪問，全部的請求都會發送到12306網站的服務器端，同時在線併發用戶數量太多，致使網站無力承載，形成擁堵。」華南師範大學計算機學院副院長單志龍認爲。           又有說法認爲，若是給12306網站增長服務器和帶寬，也可以緩解擁堵的症狀。這一觀點鐵道部內部頗爲認同。       「得認可，咱們對訪問量估計得不足。」鐵道部信息技術中心一位中層向記者透露，12306網站曾在2011年春運期間試運行，高峯時段訪問量約在1億點擊量，所以，信息中心估計2012年春運期間的訪問量約在3億至4億。       可是，結果卻大大出乎人們的預料。「12306」網站在1月9日的日點擊量達到14億次，是原來料想峯值的5倍之多。「崩潰」在所不免！]]]
筆者連日來也萌發了一個想法，假如讓我來設計12306網站，我做爲總架構師，該當如何考慮呢？本身雖然經歷過衆多的大項目的全生命週期跟蹤管理，對於軟件工程應該是有必定的研究，但像如此巨型項目，應該如何來設計、管控與實施？ 確實也頗傷腦筋，下面就筆者根據本身多年根植於IT研發的經驗，特別是近年來對於巨型網站譬如國內的淘寶、京東等，國外的Facebook、Google等的跟蹤研究經驗談談本身的見解。
1. 需求分析階段 需求分析是相當重要的，對於12306而言，需求分析的重點應該須要得出以下方面的關鍵數據纔算需求分析基本結束： 終端用戶方面的： 訪問用戶數量、整體註冊用戶數量、平時訪問用戶的峯值、平時訪問用戶的谷值、大假期訪問用戶的峯值、大假期訪問用戶的谷值、小假期訪問用戶的峯值、小假期訪問用戶的谷值； 用戶的地域分佈性、用戶可能介入的設備、用戶接入的網絡情況統計分析； 後臺服務方面的： 關鍵購票流程業務分析： 購票的基本流程分析、一次購票的TPS數量分析、一次購票的用戶流量分析、一次購票的用戶靜態流量分析、一次購票的用戶動態流量分析； 這其中又分爲初次購票與再次購票兩種狀況，流程稍微有些不一樣； 系統提供的其餘服務統計分析； 前面所說的的大假在國內目前只有2個即春節與國慶，小假較多譬如清明、端午、中秋等。 對於用戶訪問用戶數、流量、網絡、後臺的TPS數量可以創建一個數學預測模型那就很是的清晰了，對於後續的設計指導意義相當重要；
對於如此大的網站在安全性方面的需求須要作重點調研，另外因爲是實時交易網站，還須要考慮金融安全問題，安全方面還得從以下兩個方面來全面考慮：    內部安全，主要關注資金以及交易的安全，特別是防止內部人員尤爲是系統管理員；    外部安全，主要關注如何確保拒絕外部惡意入侵與攻擊成爲一個核心，特別是相似DDOS之類的攻擊； 對照筆者的論述以及前面的新聞內容，不難發現，12306的設計組很是明顯沒有充分深刻地進行需求調研與數據模型分析，特別是預案設計，所以筆者纔敢說這更是個工程問題，而不徹底是個純粹的技術問題。
2. 系統原型設計階段 國內不少的軟件公司不過重視原型設計，這點對於小軟件開發可有可無，但是一旦到了大型軟件的開發之時，不重視原型設計會失敗得很慘，筆者曾經在後期救過一個ITSM管理系統的開發，究其緣由，其中很重要的一條是對於原型設計不過重視，特別是在應用了大量的新技術而未進行原型設計是一件風險極大的事情，在筆者親身帶的幾十個項目中有一部分就是這種狀況，其中幾個項目的痛苦經歷（通宵達晝的加班長達1-2個月）更是令我終生難忘；
根據前面的需求方面的分析討論，不難發現12306的原型設計中須要解決的問題以下： 前端Web服務器基於巨量訪問的（秒均訪問千萬級別）可伸縮性模式驗證：    這塊可供選擇的技術包括以下一些：基於CDN的Internet緩存加速技術、基於Apache Server+JBoss(Weblogic)的組合服務不一樣的、基於不一樣接口的調用原型研究、請求排隊技術等的原型研究；
後端數據庫讀寫基於火車票應用的可擴展模式；    你們都知道，借鑑Facebook的巨量數據處理經驗，必須基於現代數據庫的分區技術、分佈式處理技術而且經過後續的查詢結果集成技術來實現巨量交易數據的可擴展性，基於巨量數據應用的可擴展模式一般有以下模式：   水平擴展技術，一般是基於分區技術來實施，維度是分區技術進行選擇時的關鍵，針對於火車票的交易數據而言，時間維度是最好的選擇，具體執行而言，能夠將天天的車票交易信息放到某一分區上來執行，這樣對於後續的數據維護（存儲備份等）都將帶來極大的方便；       垂直擴展技術，一般是基於地域等實現的分佈式擴展，針對於火車票的交易數據而言，如何將不一樣地域的車票、車次信息劃歸爲不一樣的數據庫服務器來執行，確保在數據交易上的廣域可並行性；
對於12306系統，筆者建議最好可以按照列車始發與到達站的地域性進行垂直切割，而交易數據按照時間來進行橫向水平擴展造成不一樣的子數據庫，同時經過中間的緩存服務器、索引服務器、集成服務器將不一樣的數據進行地整合過來，提供給前端的應用服務器，所以從系統架構上來看這個結構圖形以下：

3. 原型驗證階段 針對系統的原型設計，須要針對相應的子系統來驗證原型的技術穩定性與成熟度，具體而言分別分爲以下幾段： 針對前端訪問的巨量級別的HTTP負載均衡子系統驗證，特別是驗證針對單個數據農場的服務響應能力，須要驗證單個服務器的HTTP極限響應數量、動態擴展機制、網絡帶寬佔用狀況等； 針對中間訪問的緩存子系統、索引子系統、集成子系統，須要驗證依照前端的用戶請求如何將鏈接到後端不一樣的數據庫上進行相應的數據分佈化集成服務； 針對後端訪問的數據庫垂直、水平切割技術，基於地域的垂直切割與基於時間的水平切割技術而且結合存儲方面的分佈式來擴充數據庫系統的事務能力；
4. 系統正式設計階段 正式設計整個系統時要考慮的設計方面仍是挺多的，分別列出以下。 功能性設計： 前端Web服務器設計，能夠按照Apache來負責靜態頁面響應處理、JBOSS/WEBLOGIC負責動態頁面響應處理來進行設計，同時能夠考慮將整個資源放到內存裏面而使得Apache服務器對於靜態資源的調用完全離開磁盤I/O的制限，從而最大程度上提高前端Web服務器響應能力，這點筆者在一個遊戲網站的後端服務器上曾經使用過，總體的web server響應能力提高了好幾倍； 具體的業務設計須要依照個業務的流程來拆解實施，此設計的關鍵是在於將前段的業務如何可以跟後端的高度擴展的分佈數據庫可以集成對應起來；
後端數據庫處理系統能夠考慮按照以下的模式來予以完善設計：   將前段系統的運算分解與將各服務器進行（結果集成子系統）、使用成熟的反向搜索引擎系統做爲前端的車站查詢系統（搜索引擎子系統）、中間基於車次的具體查詢可使用緩存系統來實現（緩存子系統）、交易數據將寫入到RDBMS之中（可水平、垂直擴展的事務處理子系統）； 這樣設計的好處主要是將各類交易以及訪問可以最大程度上的並行化，實現分佈式集成化處理，從而最大程度上提高系統的總體處理能力；
存儲子系統的設計： 主要是如何在RDMMS之間可以最大化各數據庫的I/O處理能力同時提供不一樣地域（數據農場）的數據同步服務支持，同時對於從網絡條件來看，建議將不一樣數據中心互聯的光纖與用戶請求的光纖分開了確保後端的數據同步響應不受前端的密集巨量請求服務之影響。
安全性設計： 前端的安全性設計主要包括防止諸如拒絕訪問攻擊(DDOS)、腳本注入攻擊、用戶信息安全、系統入侵等，後端的安全性設計主要是要考慮帳戶信息、交易的安全等； 一般來講，前端能夠考慮基於防火牆以及各類訪問監測技術來作統計分析監控各類異常狀況，然後端主要是基於數據加密、交易通道安全、數據庫防篡改設計等來實施。
冗餘設計： 包括依照地域、用戶羣創建不一樣的數據中心的設計、基於DNS區域解析規劃設計、基於各服務器角色進行的冗餘設計（WEB服務器、搜索服務器、緩存服務器、集成服務器、數據庫服務器、存儲服務器等）所進行的數據的冗餘設計，譬如常見的集羣技術、熱備以及熱切技術等都可考慮在此應用； 其實筆者使用了中國國內的服務器以及美國的服務器分別解析了12306.cn域名地址，顯示了兩個不一樣的地址，這已說明12306設計組已經考慮了這些內容： 從美國PING將會發現： ping www.12306.cn PING 08911.xdwscache.glb0.lxdns.com (183.60.136.64) 56(84) bytes of data. 64 bytes from 183.60.136.64: icmp_seq=1 ttl=49 time=171 ms 64 bytes from 183.60.136.64: icmp_seq=2 ttl=49 time=171 ms
從上海PING將會發現： ping www.12306.cn Pinging 08911.xdwscache.glb0.lxdns.com [211.144.81.22] with 32 bytes of data: Reply from 211.144.81.22: bytes=32 time=11ms TTL=59 Reply from 211.144.81.22: bytes=32 time=10ms TTL=59
部署與維護設計： 部署設計的關鍵是確保各類角色的服務器如何可以實現快速複製擴展，在緊急須要時可以快速部署實施，同時對於服務器集羣在進行升級時如何快速批量地更新整個執行包； 維護設計的關鍵考慮因素是系統運行的監控與報警系統設計，監控的指標就前端包括整個系統的訪問數量、單個客戶端的訪問頻率、訪問的URL分佈等，後端須要監控的是各服務器的使用量、負載量同時以此進行上報到監控服務器來決定相應的服務器是否須要進行動態擴展；
5. 開發實施階段 針對於此巨型交易系統的開發，在開發階段的關鍵因素是代碼品質控制，建議採用軟件工程成熟的Coding->Review->UT控制技術（基於TDD的開發模式）來完成個模塊以及集成子系統的品質管控，在此特別提醒的是對於Review、UT段的密度須要作硬性的規定，流程裁剪時建議採用高密開發模式確保此階段的品質管控目標，在此不得很少說一句的是不少時候不少的公司、開發人員老是錯誤地認爲這些流程過於複雜，浪費時間，其實從各類實際的項目實施經從來看，此處多花了2-3倍的開發時間能夠避免後續5-10甚至數十倍調試時間(Bug fix)的投入，總體上來算仍是很是值得的，對於大型項目尤爲如此，筆者在不少大型項目的集成階段碰到集成不順暢、沒法按時完成集成任務時，開發、測試人員都是通宵達晝地加班，這其中不少的工做都是無用功，何不在開發實施階段將系統的測試密度進行加大呢？構建質量上更好的組件（部件、模塊），這樣到集成的時候就不手忙腳亂了。
因爲此係統的規模很是大，所以在詳細設計、開發時，應該考慮到各子系統必須設計得很是易於測試，特別是易於進行單體測試與自動化測試，這點能夠大幅下降項目的執行成本;
6. 測試階段 對此巨型系統的構建完畢後須要經歷子系統集成測試、系統總集成測試兩個階段，而且須要按照以下不一樣的測試種類來進行逐個測試確認：  功能測試、性能測試、安全測試、破壞性測試、持久運行能力測試等 功能測試須要針對多服務器角色集成後按照設計所提供的功能清單依據測試密度以及測試的分佈性來肯定不一樣方面的測試case，依據此來分步執行此功能測試，而且依照測試執行的結果來分析各個模塊的缺陷密度以及缺陷的消化曲線，以此指導後期的開發設計工做，並藉此可儘快完成功能方面的驗收確認；
性能測試針對這個案列相對比較複雜，因爲服務器角色不少，其基本的思路仍是分析肯定前端各業務的使用比例，編寫開發自動化測試腳原本模擬用戶的操做行爲，而且在測試環境下針對特定的服務器數量的集羣發起服務請求，同時完整地檢測每一個角色服務器的CPU/Memory/Disk I|O/Network方面的性能參數值，經過不斷增減客戶端請求數（伴隨客戶端機器的增長、譬如初期使用100臺，逐步增長到200臺測試機）來觀察服務器的性能反應，分析出拐點，同時須要測試出系統的極限吞吐量(RPS,TPS等值)，而且測試出增長不一樣的服務器角色對於這些吞吐量的影響，同時在此階段須要開發人員的協助來針對不一樣的角色根據測試結果進行性能調優工做；
安全測試，須要針對如下不一樣的場景進行模擬攻擊測試： 外部安全而言： 包括腳本注入攻擊、端口掃描、拒絕服務攻擊、主機入侵等安全測試都須要逐個進行驗證，確保系統的外部安全； 內部安全而言： 包括各服務器的數據的安全、密碼安全等進行測試；
破壞性測試，須要就各個角色服務器所對應的物理服務器進行不一樣部位失效、移除等試驗，看看整個服務器集羣的監控、維護服務以及服務輸出吞吐的影響，而且完善後續的各類系統對應的維護流程；
持久運行能力測試須要，待系統達到Beta測試版本要求以後，須要針對待部署的系統進行必定負載量持續運行至少2周以上，而且觀測系統的穩定性方面的反應，同時就數據庫的增加、日誌的增加等各類狀況進行綜合評估而且須要結合後續的部署維護作適當完善性調整；
7. 部署階段

對於如此巨型系統的部署調試工做，也是個不大不小的工程，那麼如何確保部署調試工做進展的順利，根據筆者多年維護廣域網系統的經驗，有以下幾點須要注意：

 -> 如何管理好不一樣的服務器之間的發行版本問題，確保發佈不會亂，特別是小版本的升級上部署不會亂是個關鍵，不然對於數以千計的服務器那絕對是個災難；

 ->如何可以快速解決單次發佈的升級與回退問題一樣是很重要，這當中筆者的經驗是使用一個通過驗證的發佈部署流程以及校驗流程，整個過程最後放在一個發佈腳本中，對於具體的升級與回退，維護人員只須要執行一次命令便可完成，而且對於每一個版本發佈完畢後的校驗工做尤爲重要，必須在腳本中予以體現；

 ->最後一點對於部署而言，任何部署都必需要有回滾方案配套，確保任什麼時候間點上系統皆可用；

 

8. 運行維護階段 在運行維護階段有不少細節須要配套考慮：   ->系統總體的實時狀態監控，包括各類角色的應用主機的監控、網絡設備的監控、用戶訪問流量的監控、服務可用性監控、安全監控等；   ->系統巨量的交易數據轉儲、交易日誌的轉儲問題， 這個問題的解決須要結合前面在設計時的 數據庫垂直（按時間維度）擴展以及日誌按照天的維度來進行維護的方式進行有計劃地轉儲到不一樣時間段的歷史庫中，而且經過數據的清洗、整理將部分重要數據轉入到OLAP/OLTP系統中，爲後續系統基於實時交易數據的聯機分析改進業務提供幫助；
9. 優化階段

  ->業務流程優化：這塊最主要的問題是將購票這個核心業務按照計算機易於執行計算的模型來進行不斷地優化，同時體驗，譬如異步事務提交優化、排隊技術等皆可使用在用戶的模型上，同時能夠向用戶提供預訂業務等來下降某個時段的網站流量壓力，使得流量的總體峯值、谷值差距縮小不少；

  ->架構設計優化：在數據庫的分區（垂直、水平分區）方面不斷地進行優化，同時對於單數據庫，就事務處理能力方面進行優化存儲方面的操做，譬如使用固態硬盤替代傳統的SCSI盤等，並行虛擬寫技術等大幅提高磁盤I/O操做能力、或者採用內存數據庫技術來管理好讀寫分離（讀自內存、寫到內存與磁盤同時），這樣能夠在數據庫層面上得到性能的大幅提高；若是可以配合系統壓力測試模型來獲取其性能衰減曲線圖針對性地優化，其效果將更加明顯；

 在中間層服務器上，如何將不一樣的車次分佈在大小几百個數據庫上，而且使用反向搜索引擎技術來鏈接前端的訪問請求到後端的數據庫服務器之間的映射與集成（這點能夠參考MapReduce並行算法）；

在應用層服務器上，如何將靜態內容與動態內容予以剝離，而且無需保存的內容（只讀）內容全放在內存中，如何平衡CDN加速與後端Web server的服務架構也是不斷提高單個農場集羣服務能力的關鍵與核心；

  ->性能優化： 這些優化是很是之多的，譬如針對Web server的socket鏈接池優化、日誌優化，針對中間集成服務器的並行任務分解與結果集成優化，基於後端數據庫服務器的數據計算模型、訪問方式、冗餘與數據同步、傳遞優化、數據分區優化等；

  ->其餘調優：其餘方面的調優譬如基於監控的優化、基於大併發量的快速響應與擴展優化等等；

寫到此，感受上彷佛已經設計完畢了，不過忽然回頭一望，還真發現內容很是之多，可能有實戰經驗的朋友確定會提到此係統屬於「過分設計」了，不過筆者在此要說的是，確實這個最後的提醒是很是有必要的，任何系統的設計特別是如此複雜的系統的設計只能是須要經過時間來按部就班，先原型後實際系統而且遵循幾輪研發調優（含架構設計調優），最後逐漸演變到一個真實成熟的系統，任何超前的設計最終都被證實是無用功而遭廢棄；
不少的網友對於12306的網站的技術議論紛紜，而且提出了衆多的創造性想法，筆者在提出本身的想法後還有幾點補充想法供你們參考： 1. 其實此網站的需求不是一個純粹的技術問題，試想一下，真的按照國慶、春節的高峯訪問需求來設計、部署整個系統的時候，在平時的時候大部分機器都是浪費的，如何平衡峯值與谷值時矛盾是個技術問題，可背後掩蓋着的是全中國13億多人口在短短的10-15天內完成衆多的人口遷徙，如此巨大的工程放在任何一個國家都是難於解決的問題，如何從需求層面來化解這個短時間內的巨量人口流動問題纔是此問題的命根； 正所謂 「 解決火車票購買過程容易，而解決人人能買到火車票難！！！」 2. 此問題的求解永遠是個迭代過程，須要看到的是很難有人可以在短時間內設計而且實現這麼一個巨量系統，這個工程問題的求解是拆解爲不一樣的子模塊來分步實現，而且逐步迭代優化求解的過程；

3. 此問題的解決必須是個系統工程，牽涉到資金、技術、人才、時間 這4個基本要素，不少的同行過於看重人才與技術，而忽略了資金等前提性因素，試想若是隻有3000萬預算讓你來設計實現這個巨型交易系統，你能解決麼？ 不說別的，光性能模擬測試就須要調動數以萬計的前端機器來在全國範圍內不一樣的典型區域發起海量請求，這些是個小資金可以解決得了的問題麼？

 

後記： 筆者深知，任何技術的討論必然會引發一些爭議，整個技術的發展必需要經歷這樣的紛爭才能進步與提升，在此博文發佈的幾天內，備受各位同行的關注，筆者很是感謝，也發現了諸多不友好的言辭， 對於有相似架構經驗、大項目經歷的同行一看就明白，而無此經歷的同行看起來相對比較而言沒有感受，筆者在此指望技術紛爭的同行不要爆粗，你們共同的目的是爲了推進技術交流，推進你個人技術進步，推進國家與民族的技術發展。

 

（二）淺談需求調研

前言： 此文的是續接假如我來架構12306網站(一) - 概論一文，目的是繼續探討整個項目的開發鏈條，將項目開發中的每一個環節都進行必定程度的剖析研究，跟各位同行切磋技藝，共同提升，但畢竟此項目帶有虛擬性，若有言之不妥之處，還請各位同行予以諒解。
需求分析是相當重要的，對於每一個系統而言，需求是生命線，是一切後續工做的源頭，筆者在大量的項目實踐中發現成功的項目每每在需求定義上相對比較清晰，雙方的溝通很順暢，而死攪難纏的項目每每在需求階段就能發現苗頭，溝通上也困難重重，從某種意義上來說，一個系統的開發其實就是系統開發商與客戶的一次「戀愛」行爲，系統從某種程度上就是雙方「戀愛」的結果，可否有好的結果，取決於雙方是否投入了充足的精力，是否有高度統一的認識以及一致的協調配合，在這裏筆者我的很是反對以下兩種片面的認識，     ->系統開發是開發供應商（俗稱「乙方」）的事情。這種思路在客戶（「甲方」）中很廣泛存在，甲方不少時候都認爲簽好合同付好錢後就等待系統上線了，這個對於跨行業過來對IT幾無瞭解的客戶存在得極爲廣泛，其實客戶在整個過程當中起着極爲關鍵的做用，能夠絕不誇張地講，一個系統的成功是甲方的成熟度+乙方的成熟度的和值可以達到成熟的結果。     ->需求是調研出來的，這種思路在開發商（「乙方」）中廣泛存在，開發人員老是認爲需求應該是客戶的事情，這些認識都是片面與有害的，需求來源於調研，但又要基於現實的模型進行適度的優化而且設計後的出來的結果，這個也是不少系統失敗的一個極爲重要的緣由，畢竟電腦系統的操做跟紙張操做模型存在着巨大的差距。
不少的項目經理，作了不少年的項目，然而對於需求的重要做用，依然認識不清，當項目成功的時候，歸於客戶「好說話」，當項目碰到困難或者失敗的時候，歸於客戶「不講道理」，固然鑑於國內目前的信息業現狀，咱們只能說應用科學合理的管理方式來提升項目的成功機率，但確實沒法保證項目百分之百成功。
筆者認爲，爲了確保一個項目的需求階段可以取得成功，以下方面是必不可少的：     a. 合同中有關工做任務的定義，即俗稱的SOW定義必須很清晰，不少的開發公司的合同在這塊定義極度不清晰，筆者見過的最極端的例子就是隻有寥寥數語來簡單介紹此合同對應的工做範圍，若是各位有幸碰到這樣的合同，惟一能作的就是牢牢拉住客戶關係，燒香拜佛了，乞求客戶控制需求慾望了，不要將一個幾十萬的MIS系統演變爲一個數百萬的ERP系統了。 那什麼樣的定義才能稱爲清晰的範圍定義呢？ 筆者認爲必須知足以下標準：         -> 流程定義清晰，板塊劃分明確； 若是沒法劃分的部分建議不要放到合同中，不然害人也害己；         -> 角色分明，功能點定義明確；若是都不知道有幾個用戶須要使用此係統，那角色定義以及功能點定義確定就是一塌糊塗；         -> 必須量化每一個功能點，建議你們使用業務信息字段數量以及頁面數量、流程數量、報表數量的定義放到此SOW，量化是最好的去模糊手段；     b. 定義好項目的管理組織結構，梳理好雙方的項目管理組織結構，創建通暢的項目溝通渠道，而且將決策人員在關鍵點確認上必須予以加入，此處理論上很好解釋，實踐中的難處在於如何真實地肯定這些實際的內容，筆者的建議是直接諮詢付款決定人由他/她來直接告訴你這個結構是最爲合適的；     c. 控制好需求確認流程以及需求變動流程，而且嚴格造成文檔， 此處的流程與文檔是需求的關鍵環節，不少的年輕項目經理，因爲閱歷比較淺，老是依賴於口頭上的確認，以致於往後發生爭執時，只能頓足捶胸地說，悔當初沒能記下來這個那個；其實嚴格的流程是保證效率的關鍵，而文檔是證據管理的根子，同時證據管理又是項目管理的關鍵環節，忽視證據管理的項目管理失敗是在所不免的；     d. 跟客戶的干係人必須講清楚項目的最終目標是什麼，不少時候這些關鍵控制人老是熱衷於盡力提需求，老是盡力將系統變爲一個盡善盡美的系統，這個時候必須得統一你們的思路，雙方的目標不是構建盡善盡美的系統，而是構建一個可用、適用系統，可以知足大多數目前可以看到的清晰需求（在合同當中嚴格定義過的系統），另外特別須要強調的是，盡善盡美的系統原本就不存在，人類對事物的認識老是按照哲學規律在逐步深刻的，此處筆者經常使用的例子就是喬布斯作iPhone與iPad，在此以前他失敗過多少回，況且iPhone/iPad也經歷了這麼多代，若是他老人家能構造一個近乎完美的iPhone，哪兒還來iPhone3, iPhone4, iPhone5這麼多代的發展呢？
結合本文的主題，假如我來架構12306網站，如何來實施需求調研工程呢？筆者根據本身的經驗，大致能夠分爲以下幾方面： 功能需求： 從12306設計的功能角度來看，主要需實現以下2大塊業務： 主營業務需求： 此處包含了以下幾個大塊的基本需求。     客運服務需求，此處系統需求的核心是構建一個以用戶爲中心，圍繞用戶在鐵路旅行方面的服務需求來進行展開的各項服務，其基礎服務包含以下幾塊：        出行服務： 用戶註冊、車票預訂、退票服務、餘票查詢、列車時刻表查詢、車次查詢、發到站查詢、票價查詢、中轉查詢、車站通過、車次查詢、起售時間查詢、正晚點查詢、客票代售點、鐵路旅程規劃等；        接行服務： 車次查詢、列車時刻表查詢、發到站查詢、正晚點查詢、旅客信息查詢、列車信息、乘務服務信息查詢、接行信息服務等；        託運服務： 提供貨物交運、狀態監控、到站提取、安全保證服務等；        用戶支付服務： 便捷支付（主流銀行以及網銀支付）、支付帳單、對帳查詢、退款、支付投訴等各類支付服務；     貨運服務需求，此處系統需求的核心是構建一個以服務於貨運主的貨運需求爲核心的各項服務，其基礎服務包含以下幾塊：        貨運服務：其中包含整車、散貨、小件物品運輸業務辦理、跟貨運相關的理賠業務的辦理等；        貨運信息服務：其中包含貨運路線、車輛運輸參數、運輸能力、運價、保價、運輸時刻信息、貨物安全保障信息、運輸方案等各類運輸信息服務，其目的是幫助貨主尋求合適的運輸方案，提供便捷的貨運服務；        支付服務： 企業支付服務（含線上與線下支付服務），我的支付服務、支付安全等；     信息發佈需求，此處提供是鐵路運輸相關的各種法律、法規、發文、消息、新聞等各種信息；     後臺管理需求，包含以下幾部分：            客運管理後臺，提供各種客運相關的基礎數據譬如列車班次信息、時刻表信息、票價信息、車票分配策略調控、列車運行時刻信息、各類起售時刻信息等；        貨運管理後臺，提供各種貨運相關的基礎數據譬如列車的車輛運輸參數、線路信息、運力、運能、時刻、運價等各種跟貨運相關的信息；            信息發佈管理後臺，提供跟鐵路運輸相關的各類法規、規程、信息集裝、新聞、公告信息等的錄入、維護等；        各種角色的管理，提供各類級別的角色管理，而且這些角色還須要跟各列車車次以及路局等直接相關聯；        其餘系統級別的後臺管理服務，譬如用戶管理、用戶投訴、角色管理、系統維護服務、系統監控服務等； 增值業務需求：     目前的12306網站暫時不提供此類業務，但筆者認爲憑藉着鐵路在全國齊全的路網以及運價、運能的優點，在中長途的貨物運輸上面，公路以及民航幾乎無力與其進行全面競爭，所以此處的增值業務仍是大有做爲的。     物流增值服務： 考慮到鐵路的佈局全面性，所以建設現代化的大型物流基地，培養造成一批網絡化、鏈條化、規模化、具備知名品牌的大型現代物流企業，爲目前的貨運服務提供延伸的現代物流服務而不只僅侷限於鐵路運輸服務是很是有切入價值的，此塊增值業務爲其最大的增值服務；     電子商務服務： 因爲鐵路幾乎掌握全國70%以上的大宗貨物運輸服務，所以對於供需雙方的信息以及貨物信息以及季節性具備很是強的全局掌握性，由此引起的信息匹配增值服務也能夠極大地服務於各大型製造、物流、貿易類型的企業，由此而引起的各種電子商務增值服務也是獨具自然優點的；     其餘類型的增值服務： 針對服務的我的、企業等提供各種增值服務，譬如各種出行方案挖掘、VIP服務、運輸類數據挖掘帶來的運輸方案優化等各種增值服務將極大地帶動鐵路的運營活力的發揮，同時爲鐵路帶來大量的增值收益。
性能需求：      精度方面的需求： 其中包括了用戶的數據精度，特別是時間、金額、密碼等重要敏感數據的精度要求以及各種計量規則方面的需求（含四捨五入規則等），依照鐵道部的要求制定出相應的精度方面的要求；      響應時間與時間特性方面的需求： 因爲此係統服務的用戶數量很是巨大，初步估算都是在數千萬併發用戶級別，而且考慮到後面的交易系統依然沿用了諸多舊的交易系統，所以在響應時間方面過去的基於TPS的計算模型比較難於精確地預估到在響應速度方面的需求，此處筆者建議經過原型系統的演繹方式來作，具體地來講先投入一部分資金依照目前的核心業務需求開發出一個原型交易系統，依照鐵道路內部的系統架構來部署一個小型測試系統（譬如20臺服務器規模）實施測試，而後作適量的服務器增減來測算CPU/Memory/Disk IOPS/Network bandwidth與用戶數量的變化關係曲線圖來測試用戶的響應時間等方面的需求，逐步求精，但在實際的用戶需求規劃時依然須要堅持平時用戶的單個頁面響應速度<2秒，高峯時<5s這樣的計算與設計標準，達到優良的用戶體驗；
安全性需求：   外部安全需求     防黑客入侵，須要防止黑客從外部入侵的以下幾種手段：     利用操做系統以及防火牆的漏洞等進行入侵獲取高級別的權限；     利用特洛伊木馬程序來感染而且獲取系統的高級別權限或者竊取敏感的交易數據；     口令猜想，經過暴力破解以及字典攻擊等方式來實施管理員口令猜想，以期實現對系統的入侵；     緩衝區溢出攻擊技術；     掃描探測技術；     防拒絕服務攻擊(DDOS)，多人同時向主機提出Web請求，在流量到達必定的程度以後致使系統沒法爲真實正常的用戶提供訪問服務；     防頁面注入攻擊，經過HTML、Javascript、SQL等人爲地構造計算邏輯來攻入系統致使系統的崩潰或者數據異常；     防IP假裝技術，經過截獲、分析數據傳送包來分析同時構造新的數據包發送到服務器來實施攻擊；   內部安全需求     防止數據丟失與被盜的安全機制，須要杜絕生產環境下的數據丟失以及被盜，創建起一整套數據的儲運、銷燬等的數據安全保障機制；     防止管理員密碼遺失與被盜的安全機制，對於管理員密碼，必須以必定強度的加密格式予以安全存放，同時創建嚴格的管理制度，禁止管理員私自將本身的密碼在未經流程許可的前提下告知他人等行爲發生，避免密碼的傳播與遺失、被盜等情形；     防止交易數據篡改，特別是要防止超級管理員（含應用管理員與數據庫管理員）在未經許可的流程下私自篡改系統數據，另外更改數據的行爲系統都要有能夠審覈的記錄，特別是帳戶與交易信息必須具有修正歷史可供查閱；
高可用性方面需求（HA)： 能夠肯定的是在高可用的規劃方面，應該將此係統的定位肯定在7*12小時的可用度在99.9%這個級別，用戶的系統可訪問度定義在95%以上，這樣總體的高可用可以達到大多數用戶的心理預期。
系統接口方面的需求：12306系統因爲關聯了衆多的鐵路局的內部管理系統以及調度系統，另外也關聯了衆多的支付接口，所以系統的接口部份內容極爲衆多，大致上按照性質能夠劃分爲兩個大類 即內部系統接口以及外部系統結構，另外按照提供與調用的關係 分爲12306提供給其餘系統的接口與調用其餘系統的接口， 對於提供接口，須要明確接口標準，建議採用Restful格式來提供給其餘系統而且對於普通訊息能夠走HTTP通道，而交易信息必須走HTTPS通道來實施，對於調用其餘系統的接口將依照既有系統的接口形式來逐個細化實施；
軟件的其餘部分需求： 其餘方面的需求主要包括以下幾塊：    運行環境方面的需求： 這當中包括了服務器端的硬件環境（服務器）、軟件環境（操做系統、數據庫、應用服務器、中間件）、網絡環境（包括數據中心的佈局以及分佈式設計、網絡鏈接以及容量設計）等方面的需求；另外對於客戶端，須要明確指出支持的瀏覽器的種類以及版本、須要安裝的安全組件（插件）等。 筆者特別須要提到的是不少需求調研都忘記確認運行環境， 結果到上線前用戶使用Firefox甚至IE6等來檢驗發現根本沒法進行驗證運行的狀況，其中的苦只有本身可以知曉了。    系統可維護方面的需求： 其中包括Bug修復流程、系統發佈流程、系統升級部署流程、系統擴容流程方面的需求，考慮到此係統的服務器數量衆多、地域分佈有必定的廣度，所以在設計此部分維護性需求時必須考慮到凡此種種狀況。    系統可監控性方面的需求： 其中包含服務器端的常規監控（CPU/Memory/Disk I/O)以及網絡流量監控，另外須要特別增長對於交易事務隊列以及請求隊列的隊列長度、去化速度等方面的監控，從HTTP方面須要監控每一個request的去化速度以及隊列長度，從而從各個方面全面地瞭解系統的當前性能指標。    其餘需求包含了可移植性、可擴張性等各個方面的需求。
需求文檔的寫法： 此處列出需求文檔的所有目錄結構供你們參考，具體的文檔內容就不貼出來了。 1. 引言     1.1 編寫的目的     1.2 背景說明     1.3 術語定義    
2. 任務概述     2.1 目標描述     2.2 功能性需求     2.3 業務信息定義     2.4 約束條件    
3. 數據流圖     3.1 全局數據流圖 3.2 各子塊數據流圖
4. 系統接口     4.1 用戶接口     4.2 硬件接口     4.3 軟件接口    
5. 性能需求     5.1 精度要求     5.2 時間特徵     5.3 靈活性    
6. 軟件屬性     6.1 可以使用性     6.2 系統安全性     6.3 可維護性     6.4 可移植性    
7. 系統配置需求     7.1系統硬件和軟件配置 7.2網絡配置     7.3網絡拓撲圖    
8. 其餘需求     8.1 數據庫需求     8.2 故障及其處理需求
能夠絕不誇張地說，需求肯定的清晰程度以及雙方的承認度，直接決定最終項目的成敗與否，不少的同事老是抱怨客戶在最後不講道理，不留情面，其實仔細分析發現項目開始的時候項目組就已經溝通很不充分了，存在了巨大的隱患，留給整個項目的執行是無窮盡的遺憾。
項目需求的溝通能夠簡單、形象地總結爲一句話： 需求調研就是了解在什麼環境下（服務器、客戶端環境、網絡環境）實現怎麼樣的一個系統（功能列表），其可用度如何（性能、安全、可靠度）？       理論雖是如此，可實際執行的時候你們仍是發現存在以下的諸多問題： 1. 跟客戶的一個領導將需求討論清楚了，但是後面換了新領導，整個思路全變了，系統也必須大改， 如何控制需求？ 2. 跟客戶下面的項目管理人員定義得很清楚了，但是等到最後給高層領導一看，才發現需求根本偏向了，怎麼辦？ 3. 在設計、開發過程當中，客戶老是千方百計變着法子來添加需求，還會有種種這樣那樣子的理由，需求想控也控不住； 4. 碰到極端客戶，就算你一開始跟他談得很好，也簽字承認了，到了後面一翻臉就說，這事兒我還得改，不然我就不打算讓你上線？
如此種種，令不少理論派PMP的管理人員手足無措，也不知何從處理，根據筆者的我的經驗來看，若是真的出現上述狀況了，那咱們還得必須考慮一下，任何項目管理都是寄生於企業的管理生態與社會的交往生態當中，此處從PMP的經典理論已經沒法來解決上述問題了，必須昇華爲管理生態以及客戶關係生態來解決了，此時項目經理必須藉助銷售以及公司的其餘各類途徑來突破解決此問題了。

 

後記： 當項目經理真的可以站在管理生態與客戶關係生態來解決項目管理的各類棘手問題之時，也恭喜各位已經突破性升級了，筆者在多年的工做實踐中，不多看到這樣的優秀的項目經理，正如筆者在參加PMP大會時常常聽到的一句話，經濟的發展不可或缺的是項目經理，此話既是套話，同時也是實話，可以深入理解項目管理的業務實踐而且站在全局的角度來主動出擊解決項目當中碰到的各類問題真可謂優秀項目經理，確實爲經濟發展大潮乃至人類發展大潮中的弄潮兒，必將得到我的職業乃至人生理想的成功