前记： 1. 我向来是不惮以最坏的恶意，来推测中国人的，然而我还不料，也不信竟会下劣凶残到这地步。——出自《记念刘和珍君》。 2. 本文只为吐槽记。 今天一早就看到不断涌现的新闻： 春运火车售票首日 12306爆串号漏洞“踉跄”应考 http://news.xinhuanet.com/fortune/2013-12/28/c_118749593.htm 春运抢票首日12306再崩溃 手机客户端未受影响 http://news.cnblogs.com/n/196846/ 春运首日抢票：12306网站串号泄露身份证 http://tech.sina.com.cn/i/2013-12-28/21449050218.shtml 12306网站上午瘫痪1小时 图定春运车票今起开售 http://news.xinhuanet.com/yzyd/energy/20131228/c_118749250.htm 12306：分布式内存数据技术为查询提速75倍 http://www.ctocio.com.cn/cloud/120/12820120.shtml 正文： 12306做为如此受人瞩目的项目，屡屡出现问题暴露在公众视线之内，真是不想知道都不太可能。从2011年6月正式上线以来，每到关键时刻必掉链子的事实不得不让大家从各个角度来吐槽。不管是细节的技术分析，还是舆论传言的权利斗争揣测，都不得不面对当前点击率一高就出各种问题的事实。做为性能测试行业里从业多年的人来说，不得不有另一个想法就是：12306为性能领域贡献了足够有讨论价值的案例。记得在去年出问题的时候，我就曾经写过一篇文章感慨，今年看到了这些新闻之后，我还是想唠叨两句。 这次出现的问题主要是：1. 2013年12月28日早 9 时许 12306 网站出现了故障，无法使用购票、查询等各项功能；2. 串号漏洞。 这不得不让我想起来在前一天看到的另一个新闻：《12306：分布式内存数据技术为查询提速75倍》，有如为证：  其中提到了：“一期先改造12306的主要瓶颈——余票查询系统。9月份完成代码改造，系统上线。2012年国庆，又是网上订票高峰期间，大家可以显著发现，可以登录12306，虽然还是很难订票，但是查询余票很快。2012年10月份，二期改造订单查询系统(客户查询自己的订单记录)。2013年春节，又是网上订票高峰期间，大家可以显著发现，可以登录12306，虽然还是很难订票，但是查询余票很快，而且查询自己的订票和下订单也很快。” 这显著的发现到了今天就立即得到了验证，那就是显著出了性能问题和安全问题，有图为证：  两则新闻只差一天，对使用12306的人来说，我想这第二天的新闻肯定是更显著地切身体会到了。一边是夸奖系统性能提升得显著，一边是订不了票和串号的事实。这、这、这让人怎么能接受性能提升的事实？ 在网上又有了各种的吐槽，还有某号称搞安全的公司的安全专家对串号事件的“分析”：1， 可能是服务器身份识别发生错误，导致session取值不对；2， 可能CDN缓存配置不当；3，可能网站本身存在漏洞。哥不得不说第三句是废话。不过安全专家也像各电视里出现的各领域砖家一样会打太极了，哥表示很肯定技术专家的进步，但是在这件事情里，这样的专家分析也太模糊了。对不是这个系统内部的技术人员来说，最多就是揣测，根据已有的公开信息做稍微向前一步推进性的猜测，也最多就做到这里了，谈什么分析，如果真是分析，还用得到三个“可能”吗？！ 看到有些企业专门为抢票开发浏览器插件，也真是哭笑不得。12306不断地想屏蔽这些，而企业不断地想提升自己的产品在用户中的知名度，并且给12306带来更大的压力，抢吧，不断地发请求，一次不行，两次、三次….不断地发呀发。当然像12306这样针对互联网的应用，肯定也做了各种防护手段，IP请求数限制、session请求数限制等等。做为有公德心的公司，做这样的浏览器有什么意义。其实很多做技术的人要想做抢票的工具都简单地跟玩一样，但是大家都这么干，对整个12306来说除了更慢之外还能怎么样呢？用得人能抢到，那不用的人呢？如果大家都用，那服务器要承受的压力得多出很多去。 在经济学中有一个概念：公共资源悲剧，说到这个具体的事件里就是：每个抢票的人都在努力地想尽快抢到票而不得不把抢票产生的后果转嫁到所有想得到票的人身上，最后大家都得忍受12306出现的问题。 分布式内存数据技术出现的时间倒是不短了，但是要说疯狂地使用，也就是这几年的事情，并且从个人观点来看，这个技术的成熟程度还是不如传统的数据库的。12306敢如此选择，也表现了一定的勇气，但是成败是验证英雄的唯一标准，所以那个说12306选择分布式内存数据的新闻，只是那个厂商为了打广告所用，而那个时间点的选择是一种冒险，如果12306今天很顺利地通过了考验，那厂商就可以大吹一下了。可怜见的是，今天12306还是没撑住。从揣测的角度来说，串号的问题更像是分布式内存数据技术的使用导致了（这里只是揣测，不是“分析”）。 我在性能测试优化方向上做了这么久，每次看到大系统崩溃都很自然地激动，因为这些问题是很好的案例（仅从专业方向的角度说，从其他方面说当然不是好事情）。12306，这是一个神奇的网站，给我们不断地贡献着新的谈资。多年利益之争的产物，技术和管理都不是那么好搞的。 今天跟几个人在一块聊天的时候，说12306选择春运前上线新版本到底是好还是坏，如果说新系统上线之前经过了严格地性能评估认为是可能顶得住压力的话（当然是在流控之下的压力），那现在串号的问题就应该是可以预见的，针对这个问题只能说没有很好的模拟线上的压力场景，对这样的技术问题，在技术的角度里，是可以很确切地分析出问题根源的，只要有足够的支持数据。模拟线上的场景需要一系列地分析和建模，这也是我认为当前性能测试领域时处理地很差的环节，也是直接导致很多性能测试工作形同虚设的环节。 我还是要强调的是，整个系统的性能评估，是在任何一个环节都有可能出现直接导致线上问题的，所有环节做到的细致程度直接影响着性能评估结果，而要想做得更细致那就需要有很好的计划和控制，我所提到的计划并不是领导拍脑袋拍出的时间点，而是从技术完整性的角度推导出来的真正可行的计划。 我想起跟客户谈性能测试优化项目的情形，很多客户认为这是一个短时间内就可以做完的事情，并且拍出来一个不知道从哪里出来的时间长度，而通过沟通发现，他们想要的结果和他们可以给出的支持，在他们要求的周期里就不可能实现真正的性能评估。而在我把要做的工作前前后后都描述一遍后，他们说要是这样做，那肯定这个时间完成不了的，要不就做简单点吧。而简单是不可能达到他们想要的结果的。于是，需求和过程就慢慢地变形了。前阵子谈的一个客户就是典型的例子，系统第一次上线的时候，因为性能问题不断地在用户高峰期重启，分析过程中发现很多基本的性能参数都调得非常不合理，当他们把调了之后的参数和业务量跟我说的时候，我只能苦笑了。 做为12306这样的项目，细节做到的程度就更重要了，要不然就是一高峰就各种错。 后记：我并不想单纯地说12306做得烂，也不想说12306的技术和管理有问题，只是从胡思乱想的角度把今天看到新闻时的感慨写下来。 |
|Archiver|手机版|小黑屋|7点测试网
( 京ICP备09084002号 ) 
GMT+8, 2019-2-23 23:52 , Processed in 0.130516 second(s), 26 queries .
Powered by Discuz! X3.1
© 2001-2013 Comsenz Inc.
