从奥运门票系统瘫痪到家乐福踩踏事件看软件设计中业务模型的处理,该怎么处理
从奥运门票系统瘫痪到家乐福踩踏事件看软件设计中业务模型的处理
作者：郭方明
完成日期：2007-11-17 version 1.0
联系信箱：gfm.job@Gmail.com
注：转载文章，请注明作者信息。
关键字：业务模型 并发控制 系统分析
最近一个多月，我国发生了两起比较严重的“拥挤”事件。一是奥运门票第二阶段预定开始第一天，订票系统就陷入瘫痪。二是，刚刚发生的重庆家乐福促销导致的踩踏事件。这两件看起来毫不相关的事件，如果从软件设计的角度看却有着惊人的相似。他们让我想起一个专业词语“并发”。网络软件系统，设计时我们必需要考虑并发的问题，对并发控制我们也有很多成熟的解决方案，但是并不是所有的“并发”问题，都能通过完美的设计，或高性能的服务器来解决的。本文并不讨论解决“并发问题”的技术，而是通过分析软件层面之上的业务模型来避免发生“并发问题”。
我们先来分析一下奥运门票第二阶段预定的规则，“先到先得”。奥运门票是“稀缺资源”，购票人当然会抢在“第一时间”排队购票。“先到先得”的业务模式是造成系统瘫痪根本原因。无论奥运订票系统设计的多么完善，使用的服务器性能多高，也不能足以处理这样的访问量。我相信奥运订票系统的软件开发的项目经理一定想到过这个问题，第一阶段采用抽签的方式一定就是他们提出的解决方案，因为他们知道，目前的软件和硬件能力，无法解决这个问题。
在看一下重庆家乐福的促销方案，“限时”、“限量”、早上开门开始。这样一个方案直接导致了三人死亡，三十多人受伤的惨剧。不说方案实施时的细节问题，这个方案本身就有很严重的缺陷没有考虑“并发”问题。和奥运订票系统一样，他有一个统一开始的时间点。而重庆家乐福的时间点选择上犯了一个很严重的错误，“早上开门”时顾客都在“聚集”在门外，一到开门时间，大家都会一拥而进，这和软件的“并发”是一个道理。这时如果入口有任何小问题，都会被放大。
如果说重庆家乐福踩踏事件和软件没有直接关系的话，哪奥运门票系统的瘫痪值得我们每个程序员思考以下问题。
一、 软件设计人员应该介入业务模型的设计吗？
我认为系统分析员应该介入业务模型的设计。当一个业务需要软件支持的时候，业务本身必然会有一定的变化，这种变化可能是细微的，比如原来用笔纸记录数据，现在用电脑录入数据；也可能是巨大的，比如一些原来不可能实现的计算，现在可以通过系统很容易的实现。这些变化会发上的业务的每个细节，所以，系统设计人员，应该和业务的管理者一起来设计新的业务模型。
二、 业务建模只是了解业务需求就可以了吗？
业务建模是需求分析的一部分，通常开发人员从心理上会认为，业务模型是客户的事，我们只是将原有的模型稍作改造，使之能适应软件系统就可以了。实际情况并非如此，业务模型本身的设计人员对软件系统的了解是有限的，我们的需求分析人员在了解业务以后，要从软件专业的角度，给客户提出业务改造的方案。
比如奥运门票系统，第一阶段的抽签方式就是一个很好的方案，第二阶段“先到先得”的方案就是必须要改造的方案。当然怎么让客户接受这样的方案也是技巧。因为通常提出一个不同于客户的业务模型改造方案后，客户都可能怀疑你的技术能力，他们会想是不是你的技术不过关啊？是不是你们提供的硬件不能满足我们的业务需求啊？当我们面对这样的怀疑的时候，我们必须拿出确实的数据来。这就需要解决下面这个问题。
三、 业务模型的正确性怎么验证？
业务模型的验证有很多的方法，这里并不讨论具体的方法，只是讲一些原则性的东西。
首先，业务模型验证这个流程必须要经过，我们给业务建模以后，模型是否能实际可行，不能只凭感觉，应该使用科学的方法来验证。
第二，使用极值法来验证业务模型。极值能帮助我们更好的考虑业务模型的承受能力。
第三，“关键时间点”的选择是否合适。所谓关键时间点就是业务开始等时间点，比如奥运门票开始预定的时间，如果选在凌晨开始，系统或许就不会瘫痪。有的超市把促销活动安排的下午，顾客少的时间来进行，也能很好的避免不可控制的事件发生。
第四，有没有“应急通道”，无论我们计划的多么周密，不可抗力也可能使我们的业务无法正常进行，这时如果提前有一套应急方案，就能缓解我们的燃眉之急。
写在最后
其实，很多问题都不是因为某个人的失误造成的，而是在人与人之间一连串的错误造成的，所以在强调技术与方法的同时，我们必须要重视协同工作，团队合作的重要性。
------解决方案--------------------
这个问题不单单是业务模型的问题，还有很多潜藏在背后的事件和问题，还有些可未必是技术水平和能力的问题，或者还有人际关系，甚至一些上不了台面的问题存在。呵呵
简单的归结于业务模型和验证的问题，太简化了。
------解决方案--------------------
上不了台面的问题存在
--------------------------
呵呵....
------解决方案--------------------
qingrun
有见地
------解决方案--------------------
呵呵。说实话，没有看懂。但愿是没有很好排版吧
观点不够鲜明、没有从具体的实例中，总结出经验与方法。
------解决方案--------------------
并发的确是个问题
作者：郭方明
完成日期：2007-11-17 version 1.0
联系信箱：gfm.job@Gmail.com
注：转载文章，请注明作者信息。
关键字：业务模型 并发控制 系统分析
最近一个多月，我国发生了两起比较严重的“拥挤”事件。一是奥运门票第二阶段预定开始第一天，订票系统就陷入瘫痪。二是，刚刚发生的重庆家乐福促销导致的踩踏事件。这两件看起来毫不相关的事件，如果从软件设计的角度看却有着惊人的相似。他们让我想起一个专业词语“并发”。网络软件系统，设计时我们必需要考虑并发的问题，对并发控制我们也有很多成熟的解决方案，但是并不是所有的“并发”问题，都能通过完美的设计，或高性能的服务器来解决的。本文并不讨论解决“并发问题”的技术，而是通过分析软件层面之上的业务模型来避免发生“并发问题”。
我们先来分析一下奥运门票第二阶段预定的规则，“先到先得”。奥运门票是“稀缺资源”，购票人当然会抢在“第一时间”排队购票。“先到先得”的业务模式是造成系统瘫痪根本原因。无论奥运订票系统设计的多么完善，使用的服务器性能多高，也不能足以处理这样的访问量。我相信奥运订票系统的软件开发的项目经理一定想到过这个问题，第一阶段采用抽签的方式一定就是他们提出的解决方案，因为他们知道，目前的软件和硬件能力，无法解决这个问题。
在看一下重庆家乐福的促销方案，“限时”、“限量”、早上开门开始。这样一个方案直接导致了三人死亡，三十多人受伤的惨剧。不说方案实施时的细节问题，这个方案本身就有很严重的缺陷没有考虑“并发”问题。和奥运订票系统一样，他有一个统一开始的时间点。而重庆家乐福的时间点选择上犯了一个很严重的错误，“早上开门”时顾客都在“聚集”在门外，一到开门时间，大家都会一拥而进，这和软件的“并发”是一个道理。这时如果入口有任何小问题，都会被放大。
如果说重庆家乐福踩踏事件和软件没有直接关系的话，哪奥运门票系统的瘫痪值得我们每个程序员思考以下问题。
一、 软件设计人员应该介入业务模型的设计吗？
我认为系统分析员应该介入业务模型的设计。当一个业务需要软件支持的时候，业务本身必然会有一定的变化，这种变化可能是细微的，比如原来用笔纸记录数据，现在用电脑录入数据；也可能是巨大的，比如一些原来不可能实现的计算，现在可以通过系统很容易的实现。这些变化会发上的业务的每个细节，所以，系统设计人员，应该和业务的管理者一起来设计新的业务模型。
二、 业务建模只是了解业务需求就可以了吗？
业务建模是需求分析的一部分，通常开发人员从心理上会认为，业务模型是客户的事，我们只是将原有的模型稍作改造，使之能适应软件系统就可以了。实际情况并非如此，业务模型本身的设计人员对软件系统的了解是有限的，我们的需求分析人员在了解业务以后，要从软件专业的角度，给客户提出业务改造的方案。
比如奥运门票系统，第一阶段的抽签方式就是一个很好的方案，第二阶段“先到先得”的方案就是必须要改造的方案。当然怎么让客户接受这样的方案也是技巧。因为通常提出一个不同于客户的业务模型改造方案后，客户都可能怀疑你的技术能力，他们会想是不是你的技术不过关啊？是不是你们提供的硬件不能满足我们的业务需求啊？当我们面对这样的怀疑的时候，我们必须拿出确实的数据来。这就需要解决下面这个问题。
三、 业务模型的正确性怎么验证？
业务模型的验证有很多的方法，这里并不讨论具体的方法，只是讲一些原则性的东西。
首先，业务模型验证这个流程必须要经过，我们给业务建模以后，模型是否能实际可行，不能只凭感觉，应该使用科学的方法来验证。
第二，使用极值法来验证业务模型。极值能帮助我们更好的考虑业务模型的承受能力。
第三，“关键时间点”的选择是否合适。所谓关键时间点就是业务开始等时间点，比如奥运门票开始预定的时间，如果选在凌晨开始，系统或许就不会瘫痪。有的超市把促销活动安排的下午，顾客少的时间来进行，也能很好的避免不可控制的事件发生。
第四，有没有“应急通道”，无论我们计划的多么周密，不可抗力也可能使我们的业务无法正常进行，这时如果提前有一套应急方案，就能缓解我们的燃眉之急。
写在最后
其实，很多问题都不是因为某个人的失误造成的，而是在人与人之间一连串的错误造成的，所以在强调技术与方法的同时，我们必须要重视协同工作，团队合作的重要性。
------解决方案--------------------
这个问题不单单是业务模型的问题，还有很多潜藏在背后的事件和问题，还有些可未必是技术水平和能力的问题，或者还有人际关系，甚至一些上不了台面的问题存在。呵呵
简单的归结于业务模型和验证的问题，太简化了。
------解决方案--------------------
上不了台面的问题存在
--------------------------
呵呵....
------解决方案--------------------
qingrun
有见地
------解决方案--------------------
呵呵。说实话，没有看懂。但愿是没有很好排版吧
观点不够鲜明、没有从具体的实例中，总结出经验与方法。
------解决方案--------------------
并发的确是个问题