從奧運門票系統癱瘓到家樂福踩踏事件看軟件設計中業務模型的處理
作者：郭方明
完成日期：2007-11-17 version 1.0
聯繫信箱：[email protected]
注：轉載文章，請註明作者信息。
關鍵字：業務模型 併發控制 系統分析
最近一個多月，我國發生了兩起比較嚴重的“擁擠”事件。一是奧運門票第二階段預定開始第一天，訂票系統就陷入癱瘓。二是，剛剛發生的重慶家樂福促銷導致的踩踏事件。這兩件看起來毫不相關的事件，如果從軟件設計的角度看卻有着驚人的相似。他們讓我想起一個專業詞語“併發”。網絡軟件系統，設計時我們必需要考慮併發的問題，對併發控制我們也有很多成熟的解決方案，但是並不是所有的“併發”問題，都能通過完美的設計，或高性能的服務器來解決的。本文並不討論解決“併發問題”的技術，而是通過分析軟件層面之上的業務模型來避免發生“併發問題”。
我們先來分析一下奧運門票第二階段預定的規則，“先到先得”。奧運門票是“稀缺資源”，購票人當然會搶在“第一時間”排隊購票。“先到先得”的業務模式是造成系統癱瘓根本原因。無論奧運訂票系統設計的多麼完善，使用的服務器性能多高，也不能足以處理這樣的訪問量。我相信奧運訂票系統的軟件開發的項目經理一定想到過這個問題，第一階段採用抽籤的方式一定就是他們提出的解決方案，因爲他們知道，目前的軟件和硬件能力，無法解決這個問題。
在看一下重慶家樂福的促銷方案，“限時”、“限量”、早上開門開始。這樣一個方案直接導致了三人死亡，三十多人受傷的慘劇。不說方案實施時的細節問題，這個方案本身就有很嚴重的缺陷沒有考慮“併發”問題。和奧運訂票系統一樣，他有一個統一開始的時間點。而重慶家樂福的時間點選擇上犯了一個很嚴重的錯誤，“早上開門”時顧客都在“聚集”在門外，一到開門時間，大家都會一擁而進，這和軟件的“併發”是一個道理。這時如果入口有任何小問題，都會被放大。
如果說重慶家樂福踩踏事件和軟件沒有直接關係的話，哪奧運門票系統的癱瘓值得我們每個程序員思考以下問題。
一、 軟件設計人員應該介入業務模型的設計嗎？
我認爲系統分析員應該介入業務模型的設計。當一個業務需要軟件支持的時候，業務本身必然會有一定的變化，這種變化可能是細微的，比如原來用筆紙記錄數據，現在用電腦錄入數據；也可能是巨大的，比如一些原來不可能實現的計算，現在可以通過系統很容易的實現。這些變化會發上的業務的每個細節，所以，系統設計人員，應該和業務的管理者一起來設計新的業務模型。
二、 業務建模只是瞭解業務需求就可以了嗎？
業務建模是需求分析的一部分，通常開發人員從心理上會認爲，業務模型是客戶的事，我們只是將原有的模型稍作改造，使之能適應軟件系統就可以了。實際情況並非如此，業務模型本身的設計人員對軟件系統的瞭解是有限的，我們的需求分析人員在瞭解業務以後，要從軟件專業的角度，給客戶提出業務改造的方案。
比如奧運門票系統，第一階段的抽籤方式就是一個很好的方案，第二階段“先到先得”的方案就是必須要改造的方案。當然怎麼讓客戶接受這樣的方案也是技巧。因爲通常提出一個不同於客戶的業務模型改造方案後，客戶都可能懷疑你的技術能力，他們會想是不是你的技術不過關啊？是不是你們提供的硬件不能滿足我們的業務需求啊？當我們面對這樣的懷疑的時候，我們必須拿出確實的數據來。這就需要解決下面這個問題。
三、 業務模型的正確性怎麼驗證？
業務模型的驗證有很多的方法，這裏並不討論具體的方法，只是講一些原則性的東西。
首先，業務模型驗證這個流程必須要經過，我們給業務建模以後，模型是否能實際可行，不能只憑感覺，應該使用科學的方法來驗證。
第二，使用極值法來驗證業務模型。極值能幫助我們更好的考慮業務模型的承受能力。
第三，“關鍵時間點”的選擇是否合適。所謂關鍵時間點就是業務開始等時間點，比如奧運門票開始預定的時間，如果選在凌晨開始，系統或許就不會癱瘓。有的超市把促銷活動安排的下午，顧客少的時間來進行，也能很好的避免不可控制的事件發生。
第四，有沒有“應急通道”，無論我們計劃的多麼周密，不可抗力也可能使我們的業務無法正常進行，這時如果提前有一套應急方案，就能緩解我們的燃眉之急。
寫在最後
其實，很多問題都不是因爲某個人的失誤造成的，而是在人與人之間一連串的錯誤造成的，所以在強調技術與方法的同時，我們必須要重視協同工作，團隊合作的重要性。