本文是敏捷开发产品管理系列的第八篇。(专栏目录)

在产品开发中,常常遇到产品性能问题,这些性能问题会很大程度上影响到产品的架构。

但解决这些性能问题,切莫认为只是技术人员的事情,产品经理和产品总监也要参与其中,甚至是业务人员(销售、售前)。

下面以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次,依旧耽误工作和生活,弄不好还的从黄牛党买票(他们有专业刷票软件,从性能优化的收益远超过我们)。

从业务角度思考技术架构

正题反而很简单了,如果要做技术架构,先要了解业务架构。

这一点要说服产品人员和业务人员参加进来,在里边的案例中提及了如何让商务人员进行架构设计的问题。