本文是敏捷開發產品管理系列的第八篇。(專欄目錄)
在產品開發中,常常遇到產品效能問題,這些效能問題會很大程度上影響到產品的架構。
但解決這些效能問題,切莫認為只是技術人員的事情,產品經理和產品總監也要參與其中,甚至是業務人員(銷售、售前)。
下面以12306的售票問題為例,來做一個完整的說明。
本文的目的,不是說技術性最佳化不必要,而是說作為開發人員不要悶頭只想技術,而作為產品經理不要把所有“技術”問題推給開發人員,這一點很重要。
技術方案的局限性12306為什麼崩潰了?
原因眾說紛紜,解決方案也眾說紛紜。
到網上一搜“12306 效能”http://www.baidu.com/s?wd=12306+%D0%D4%C4%DC&rsv_bp=0&rsv_spt=3&inputT=8540支招者不計其數,但多數集中在技術方面。
本人對資料庫一項所知甚少,也不懂如何最佳化,但下面我們從業務的角度看看有沒有什麼解決方案。
先看看這個方案:為何不上10倍的伺服器?
很多人提出,如果上10倍的伺服器(或10倍的記憶體/硬碟/……),可能就解決了擁堵問題。
實際上我也想過是否可以上10倍的火車,解決中國的春運問題。答案是不能。
因為任何能夠滿足春運數量的火車,在非春運的時候都會變成很大的負擔,只能停在什麼地方風吹雨淋等待下一個春運到來。
所以,突發性是核心矛盾,無論用技術方法,解決突發性是主要矛盾。
突發性的放大
除了很多人在這段時間買票之外,有一個正反饋過程加重了突發性,那就是買不到票。
可以說,訪問人數無論上升還是下降,只要還有票,多數人都只會登入此網站一次,效能問題至少還是線性。
但如果買不到票,或買不到某個車次的票,人們就會突然多次訪問網站,效能問題就變成非線性了。比如有一個人就重新整理200多次,終於購票成功。
把200變回1,這不是一個簡單地利用技術能解決的問題。
在某個攻略中也提到,由於人數太多,登入都需要20~30次才能完成。這些非線性因素,乘上本來就增加的人數,難免崩潰。
從業務角度思考問題
先胡寫幾個方案看看,先假設我不會編程。
1. 把提前售票時間從10天改為20天
“什嗎?”是的,這個傻方法差不多可以降低伺服器負載50%。
2. 設計一個排隊系統,完成登入
以前玩遊戲的時候,經常因為部分伺服器崩潰而無法登陸,不過,這時候都會出現一個排隊系統:“您正在排隊登入,前面還有1000人……900人……800人……(別亂動鍵盤啊,快到你了)”
這個是用來解決雪上加霜的突發性放大問題的。
我相信12306肯定為30億人次的春運做過準備,只是沒為6000人次的春運做準備,排隊系統可以把人數重新變回30億。
3. 設計一個排隊系統,完成預訂票
進去了,還是沒有票,怎麼辦?每天抽空就上來看看,然後重新登入……重新整理……又是一個突發性放大因素。
如果有一個排隊系統,你按優先順序排列上自己想買的幾種票,甚至直接說“某月日,哪到哪,無論車次,有票就給我”,在家等著退票,或者偶然發出臨時車次吧。
如果是我,我還會做個簡訊服務,如果買到了就簡訊通知;如果還在排隊……如果你願意接收,每排名向前10%,可以再發個簡訊;你耐不住性子想查詢一下,也可以反向發個簡訊來,即時查詢。
不過,簡訊要付費的,1毛一條,平價的。我聽說簡訊分賬是2:8開,電信才拿2分錢,剩下8分歸鐵道部,不知道現在是否還是這個規矩。
一個春運下來簡訊還能賺幾億(應該完勝CCTV的春晚),而且客戶還挺高興,畢竟這幾毛錢解決了大問題了,免去半夜爬起來/請假/寒風中排隊。撇開這些不說,一台台式機開機3小時就是一度電,6毛錢,管保3小時內你買不到票的;而現在能了(如果還有票)。
當然,如果鐵道部願意讓利於民,免費發簡訊就更好了,不過如果能解決這個問題,相信實際上大家都會覺得讓不讓的都無所謂了;畢竟火車票10年沒漲價,這些錢給人家發加班費吧。
另外這個排隊系統還能把黃牛的刷票軟體幹掉,黃牛再多,也跟著十億人民一起排隊吧。
……
等等諸種業務方法,雖然不能解決有沒有票的問題,但能解決購票的效能問題。
實際客戶體驗也要好得多,畢竟無論你怎麼上伺服器和最佳化技術,如果我還是上去200次,依舊耽誤工作和生活,弄不好還的從黃牛黨買票(他們有專業刷票軟體,從效能最佳化的收益遠超過我們)。
從業務角度思考技術架構
正題反而很簡單了,如果要做技術架構,先要瞭解業務架構。
這一點要說服產品人員和業務人員參加進來,在http://blog.csdn.net/cheny_com/article/details/7220270裡邊的案例中提及了如何讓商務人員進行架構設計的問題。