从奥运门票系统瘫痪到家乐福踩踏事件看软件设计中业务模型的处理

从奥运门票系统瘫痪到家乐福踩踏事件看软件设计中业务模型的处理

作者：郭方明

完成日期：2007-11-17 version 1.0

联系信箱：gfm.job@Gmail.com

注：转载文章，请注明作者信息。

关键字：业务模型并发控制系统分析

最近一个多月，我国发生了两起比较严重的“拥挤”事件。一是奥运门票第二阶段预定开始第一天，订票系统就陷入瘫痪。二是，刚刚发生的重庆家乐福促销导致的踩踏事件。这两件看起来毫不相关的事件，如果从软件设计的角度看却有着惊人的相似。他们让我想起一个专业词语“并发”。网络软件系统，设计时我们必需要考虑并发的问题，对并发控制我们也有很多成熟的解决方案，但是并不是所有的“并发”问题，都能通过完美的设计，或高性能的服务器来解决的。本文并不讨论解决“并发问题”的技术，而是通过分析软件层面之上的业务模型来避免发生“并发问题”。

我们先来分析一下奥运门票第二阶段预定的规则，“先到先得”。奥运门票是“稀缺资源”，购票人当然会抢在“第一时间”排队购票。“先到先得”的业务模式是造成系统瘫痪根本原因。无论奥运订票系统设计的多么完善，使用的服务器性能多高，也不能足以处理这样的访问量。我相信奥运订票系统的软件开发的项目经理一定想到过这个问题，第一阶段采用抽签的方式一定就是他们提出的解决方案，因为他们知道，目前的软件和硬件能力，无法解决这个问题。

在看一下重庆家乐福的促销方案，“限时”、“限量”、早上开门开始。这样一个方案直接导致了三人死亡，三十多人受伤的惨剧。不说方案实施时的细节问题，这个方案本身就有很严重的缺陷没有考虑“并发”问题。和奥运订票系统一样，他有一个统一开始的时间点。而重庆家乐福的时间点选择上犯了一个很严重的错误，“早上开门”时顾客都在“聚集”在门外，一到开门时间，大家都会一拥而进，这和软件的“并发”是一个道理。这时如果入口有任何小问题，都会被放大。

如果说重庆家乐福踩踏事件和软件没有直接关系的话，哪奥运门票系统的瘫痪值得我们每个程序员思考以下问题。

一、软件设计人员应该介入业务模型的设计吗？

我认为系统分析员应该介入业务模型的设计。当一个业务需要软件支持的时候，业务本身必然会有一定的变化，这种变化可能是细微的，比如原来用笔纸记录数据，现在用电脑录入数据；也可能是巨大的，比如一些原来不可能实现的计算，现在可以通过系统很容易的实现。这些变化会发上的业务的每个细节，所以，系统设计人员，应该和业务的管理者一起来设计新的业务模型。

二、业务建模只是了解业务需求就可以了吗？

业务建模是需求分析的一部分，通常开发人员从心理上会认为，业务模型是客户的事，我们只是将原有的模型稍作改造，使之能适应软件系统就可以了。实际情况并非如此，业务模型本身的设计人员对软件系统的了解是有限的，我们的需求分析人员在了解业务以后，要从软件专业的角度，给客户提出业务改造的方案。

比如奥运门票系统，第一阶段的抽签方式就是一个很好的方案，第二阶段“先到先得”的方案就是必须要改造的方案。当然怎么让客户接受这样的方案也是技巧。因为通常提出一个不同于客户的业务模型改造方案后，客户都可能怀疑你的技术能力，他们会想是不是你的技术不过关啊？是不是你们提供的硬件不能满足我们的业务需求啊？当我们面对这样的怀疑的时候，我们必须拿出确实的数据来。这就需要解决下面这个问题。

三、业务模型的正确性怎么验证？

业务模型的验证有很多的方法，这里并不讨论具体的方法，只是讲一些原则性的东西。

首先，业务模型验证这个流程必须要经过，我们给业务建模以后，模型是否能实际可行，不能只凭感觉，应该使用科学的方法来验证。

第二，使用极值法来验证业务模型。极值能帮助我们更好的考虑业务模型的承受能力。

第三，“关键时间点”的选择是否合适。所谓关键时间点就是业务开始等时间点，比如奥运门票开始预定的时间，如果选在凌晨开始，系统或许就不会瘫痪。有的超市把促销活动安排的下午，顾客少的时间来进行，也能很好的避免不可控制的事件发生。

第四，有没有“应急通道”，无论我们计划的多么周密，不可抗力也可能使我们的业务无法正常进行，这时如果提前有一套应急方案，就能缓解我们的燃眉之急。

写在最后

其实，很多问题都不是因为某个人的失误造成的，而是在人与人之间一连串的错误造成的，所以在强调技术与方法的同时，我们必须要重视协同工作，团队合作的重要性。

从奥运门票系统瘫痪到家乐福踩踏事件看软件设计中业务模型的处理相关推荐

说说北京奥运购票系统瘫痪这事儿
说说北京奥运购票系统瘫痪这事儿作者: Fenng | 可以转载, 转载时务必以超链接形式标明文章原始出处和作者信息及版权声明网址: http://www.dbanotes.net/review/b ...
软考高级系统架构设计师系列之：面向构件的软件设计，构件平台与典型架构
软考高级系统架构设计师系列之:面向构件的软件设计,构件平台与典型架构一.构件的概念二.构件的标准布线三.构件框架 1.体系结构核心构成 2.语境相关组合构件框架 3.构件开发 4.开发构件通常采 ...
从万达百货到家乐福中国，苏宁如何快速消化“大块头”？
零售变革当道.过去两年间,阿里.腾讯的连番大手笔线下并购曾引发广泛关注.与之相比,晚出手的苏宁下手稳.狠,成为今年线下并购的主力. 6月23日,苏宁易购公告称,全资子公司苏宁国际拟出资48亿元等值 ...
性能测试：从奥运门票系统崩溃想到的
先说性能指标的来源.对于正规的项目,用户对各项指标有明确的需求:对于没有明确性能需求的项目,则可以根据用户功能需求,测试人员的经验来设计性能指标.简单地说,就是需求加上经验.很多情况下,经验要派上用场 ...
家乐福618保卫战二-零售O2O场景中的万级并发交易情况下的极限性能调优
本系列简介这个系列可以帮助普通程序员们深刻的意识到平时工作中到底还有什么不足以及如何进一步进化成真正意义上的架构师.CTO以及后面的道路是如何走的: 这个系列可以帮助企业IT管理者深刻意识到,性能安 ...
迄今为止最深刻分析家乐福的文章—从商业模式、公司制度、公司文化三方面
在写家乐福的商业模式前,我一直在思考以什么样的切入点来进入.作为一个世界500强的零售企业来说它的商业模式其实并不复杂,14年里基本上经过了4个重要的发展阶段,让我从这四个阶段开始谈谈我对家乐福商业模 ...
金行健:仓储会员店打响渠道之战，家乐福和沃尔玛谁抄袭、谁垄断？
近日,家乐福和沃尔玛旗下山姆会员店之间,关于供应商"二选一"事件甚嚣尘上,也让仓储会员店这一业态再度引发讨论. 10月22日,上海浦东新区,家乐福国内首家会员仓储店没有开业当晚的喜 ...
零售EDI：家乐福Carrefour EDI需求分析
家乐福(Carrefour)于1959年创立于法国,是大卖场业态的首创者,欧洲第一大零售商,世界第二大国际化零售连锁集团,主营大型超市.超市以及折扣店.大型连锁商超的供应链遍布全球,需要传输的业务数据 ...
家乐福中国：曾经的零售之王走上资本运作之路
近日,彭博新闻社援引不愿具名的知情人士称,苏宁易购正考虑出售其所持有的家乐福中国控股股权,已经联系潜在买家,通过此次减持,苏宁易购寻求筹资约7亿至8亿美元. 前段时间,家乐福刚刚与盒马一同指控山姆会员 ...

从奥运门票系统瘫痪到家乐福踩踏事件看软件设计中业务模型的处理

从奥运门票系统瘫痪到家乐福踩踏事件看软件设计中业务模型的处理相关推荐

最新文章

热门文章