2006年商业科技黑镜头之8大失误+5大教训
作者: 译/朱筱丹, 出处:《信息周刊》, 责任编辑: 许琳,
2006-12-23 08:00
除了麦当劳公司1.7亿美元的企业资源计划(ERP)项目的惨败;电力公司的软件缺陷导致加拿大和美国东北地区的大规模断电以外，还有更多失败案例。阅读了解这些黯淡的细节，能够帮助企业找到避免类似惨剧的出路。
商业科技的复杂性可以构筑从业人员的职业地位，当然也可以在一夜之间毁掉它。高调的商业应用光鲜外表下包含着无数需要重视的细节，其中IT细节尤为关键。没有对于技术能力的充分估计，缺乏足够的预先风险测试，没有完善的灾备方案，不考虑如何对待正常用户和恶意用户等都可能导致重大的商业灾难。
在我们这座商业科技耻辱柱上，除了麦当劳公司1.7亿美元的企业资源计划(ERP)项目的惨败;电力公司的软件缺陷导致加拿大和美国东北地区的大规模断电以外，还有更多案例。阅读了解这些黯淡的细节，能够帮助企业找到避免类似惨剧的出路。
贪多嚼不烂
麦当劳公司(McDonald，下称麦当劳)的这个项目规模和覆盖范围极广，以致最终变成了不可能完成的任务。2001年的时候，快餐连锁业巨头打算开展一个项目，建立一个连接总部和遍布各地餐厅的企业内部网(Intranet)，以提供实时的运营信息。在这个代号为“创新”(Innovate)的项目里，公司在伊利诺伊州奥克布鲁克(Oak Brook)总部的经理能实时了解在佛罗里达州奥兰多(Orlando)特许经营店里的销售情况正在变缓，或者伦敦餐厅里的烤架温度不够热。麦当劳一直对“创新”项目守口如瓶——该公司对本文的采访不予回应——但它的覆盖范围之广勿庸置疑。根据受麦当劳聘用负责早期策划和技术选型的顾问公司Mpower公司的白皮书资料，这个计划的目标是创立“一个逐渐深入到每一家麦当劳店铺的全球ERP应用。”换而言之，这包括超过120个国家里的3万多家餐厅。这样的工程真的易如反掌吗?
根据麦当劳提交给美国证交会的季度报告，他们在顾问和初始实施阶段花费了1.7亿美元之后才意识到这个项目实在过于庞大。麦当劳终于在2003年给美国证交会的财物报告中宣判了“创新”项目的死刑，项目被注销，管理层决定终止这个长期技术项目。
财务报表中的补充揭示了一条绝大多数有经验的IT项目经理从一开始就能给麦当劳提出的忠告：企图在上千家门店之间创建传递实时信息的全球网络，它们中有的还缺乏基础网络建设，注定会失败。财务报告显示，“尽管这个终止项目原本的目标是长期效益，但在当前环境下，并不是最好的资金使用方式，因为预期在几年内整个系统的开销将超过10亿美元。”
这场需要耗费上10亿美元、过于超前的IT项目重蹈了McDLT汉堡(20世纪80年代一种双层包装、把热食与冷食两部分分开置放汉堡)的覆辙：因为大多数人一次吃不掉那么大的汉堡。
谨慎对待错误
有时候技术灾难的影响远远不止于出问题的公司本身。美国俄亥俄州的第一能源公司(First Energy，下称第一能源)为450万客户提供电力，3年前就因为一个与电源失效有关的软件缺陷，使美国东北部和部分加拿大地区大面积陷于停电。
这次停电的原因是俄亥俄州砍伐树木切断了平衡东北电网出入电流的电线引起的连锁反应。但真正的问题在第一能源的计算机部门，它的IT经理们好像忘了一个基本操作原则：无论引入多少自动化处理或员工经验多么的丰富，应用程序都必须遵从必要的IT管理协议，如IT基础设施库(Information Technology Infrastructure Library，ITIL)的规定。
如果第一能源的软件报警系统能正确地对不稳定情况向工程人员提出报警的话，停电原本可以局限在很小范围内。报警系统的关键在于：当你发现系统不工作的时候，一切已经太晚了。“不稳定的状况原本不会直接导致停电，但是第一能源没能及时做出响应是事故的主要原因。”北美电力可靠性协会(North America Electric Reliability Council)负责基础架构安全的经理史丹·约翰逊(Stan Johnson)总结道。
2003年8月13日下午2点左右，该公司的IT人员发现运行General Electric XA/21管理系统的服务器上的报警模块停止了工作。工作人员重启机器试图修复该问题，但服务器重启后，报警模块仍然无法正常工作。通用电气公司(GE，下称通用电气)在其后的一篇声明里表示，这是因为一个软件代码错误引起报警程序进入死循环而无法重新在线工作。而第一能源在俄亥俄工厂控制室里的操作人员没意识到这条防御线已失效，因为他们的IT架构在重启之后不会校验相关的系统是否都已恢复工作。同时，不稳定的电力状态在迅速恶化。
因为忽略了IT管理里最重要的原则，员工也不愿意与终端用户确认检查，确保他们的关键系统已能完全正常使用。IT基础设施库尤其建议IT部门建立一个受影响用户的确认列表，在重启关键性系统后，管理员必须与他们一一联系。在北美电力可靠协会关于这次停电的最后一份报告里，它指责第一能源的IT部门缺乏沟通意识。
第一能源谢绝关于此事件的采访，但约翰逊表示协会的最后一份报告里该公司已遵从了必要的建议。尤其是，协会敦促第一能源建立必要的规章，书面的管理测试、部署和备份关键硬件或软件系统准则，包括执行系统升级、补丁包管理、备份恢复和维护的方法。它还建议该公司必须建立一套系统发生故障时必须明确的交流规程。事实上，这些良好的建议适用于所有的公司。
注重细节
想象一下，在一家没有财会系统的公司里担任会计职务的滋味。这正是德尔·欣斯基(Dale Shinskey)的遭遇。他是一名财务专业人员，欣斯基的前任雇主是全球燃料服务公司(World Fuel Services)的子机构国际石油公司(International Petroleum)，在2000年被废油循环再生公司Earthcare公司用3,500万美元购并，欣斯基也因此加入了Earthcare公司。不幸的是，欣斯基表示：“Earthcare公司完成了购并，却忽略了细节。”
这项交易显示，仍由全球燃料服务公司维护欣斯基团队用来记账的Oracle财会系统。但是出现了一个问题：欣斯基宣称Earthcare公司忘了向全球燃料服务公司支付该系统的维护费，在短暂的使用之后，系统被终止。欣斯基抱怨道：“那3个月我们手头什么也没有。”在这期间，Earthcare公司只是简单地评估该机构的财务状况，估计财务数据，这些数字后来证明都是错的。“他们想把财务系统自己运作起来，但根本没法做到。”欣斯基指出。
糟糕的财务管理让Earthcare公司遇到了更大的麻烦。2001年公司被迫向全球燃料服务公司支付175万美元用于解决与收购国际石油公司相关的争端。当年6月，Earthcare公司又把国际石油公司卖给了美国过滤恢复服务公司(U.S. Filter Recovery Services)，这样欣斯基也随之离开了Earthcare公司。
但故事并没有完结，在过滤恢复服务公司工作一年之后，欣斯基和他的财务部门被要求从赛捷软件(Sage Software)的MAS 200应用程序向一套名为 Uptime from Uptime的软件迁移。“情况糟糕透了，我们管那段时间叫停工期。”欣斯基回忆道。原因是美国过滤恢复服务公司使用一套20世纪80年代初开发的落伍系统，并且不愿意出钱把欣斯基部门的财会系统整合到公司的Oracle应用环境中去。“这套系统没有下拉菜单。如果不在计算机里加上一大堆附注说明，你简直没法使用这套系统。”欣斯基抱怨道。
情形令人如此头痛，以致部门的财务和会计断断续续地离职以逃避困境。而现在已并入西门子公司(Siemens)的美国过滤恢复服务公司拒绝了《InformationWeek》的访问要求。
欣斯基表示，他们获得的教训是：实施购并的公司应该对购并后的各种运作方式有周详的考虑，其中需要确保有合适的工具支持公司的管理。
拒绝“金钱婚姻”
有的公司企图通过把IT外包以摆脱困境。一家非常着迷于外包概念的保险和金融机构甚至为此专门购并了一家外包公司。但这个决定，最后却令购并者懊悔无比。
仅仅从2001年到2002年的15个月期间，美国印第安那波利斯的康赛可公司(Conseco，下称康赛可)先是购并了印度外包商ExlService公司，继而又反悔转手卖掉了该外包公司。ExlService公司当时处于起步阶段，在印度提供低成本呼叫中心客户服务。当时康赛可总裁兼首席执行官(CEO)加里·韦特(Gary Wendt)还在通用电气工作时，就以提倡外包客户服务而著名。对他来说，这家企业无疑很诱人。在韦特的决策下，康赛可用5,200多万美元购并了ExlService公司。
韦特认为ExlService公司能在一夜之间为康赛可提供低成本高质量的客户服务。他对美国印第安那州本土的人力资源不是很有信心。在《波利斯明星报》(Indianapolis Star)问他为什么把公司的客户服务搬到海外去时，他表示“我很确信印度能提供更好的客户服务。而美国本土的(公司)不行。”
这只是其中一个理由，韦特在这桩交易里也获得了利益;他成了ExlService 公司的联合创始人，并在交易中获得ExlService公司20%的股票期权。根据美国证交所的文件显示，韦特和他的妻子在这桩交易里纯获利692,567 股康赛可股票，共价值970万美元。但兑现这些股票是有条件的，必须等康赛可确认能从这笔购并交易中获得良好收益才能生效。康赛可没有回应《InformationWeek》采访的请求。
在购并之后，康赛可就把2,000个客户服务职位转移到在印度的ExlService公司。在一份管理法规补充报告里，康赛可宣布在2002年11月放弃ExlService公司，损失达2,000万美元。自然韦特的股票期权也随即化为乌有。
根据波利斯明星报的报道，康赛可的一些高层把投资失败归咎于时机错误。因为康赛可的印度呼叫中心上线的日子是2001年9月10日。第二天就发生了“9·11“恐怖袭击，带外国口音的呼叫中心自然立刻蒙受负面影响。
这件事的教育意义是什么?警惕外包陷阱?足够充分理由，谨慎选择合作伙伴?不要低估本土人力资源?也许上面这些都包括。
各取所需导致消化不良
英国全国医疗保健系统(National Health Service，下称NHS)的IT 现代化项目也许是现存的最大规模的IT灾难。该项目比预期时间滞后2年，超支100亿美元，在花钱规模上它和美国波士顿的大隧道计划(Big Dig，美国迄今为止耗资最大也是最复杂的高速公路)项目不分伯仲。它的其中一个主要厂商——以医疗健康程序开发为主业的iSoft公司已在破产的边缘，因为该公司一直无法在这个网络上部署自己的软件。如果应用程序不能部署，iSoft就无法获得收益，所以延时无疑会拖垮他们。各种技术问题包括要整合不兼容的系统，而抵触的医生们则认为该项目没有事前充分咨询他们的意见，厂商之间就程序的功能互相指责，彼此推卸责任。
负责这个项目的IT高层和政府官员们已经挣扎了好几年，企图把项目拉上正轨。但问题依然严重并仍然持续。一台应该今年报废的大型计算机就使英格兰西北部和中英格兰北部地区的80家医疗结构停业4天。错误的起因是NHS管理下的一台存放有上百万病人记录和医疗数据的服务器出现问题。那几天里受影响区域的医生们没法获得病人的预约信息，导致对病人的服务严重延误。在一份报告中，NHS声称病人的安危并没有受损害。
深入研究过NHS项目的剑桥大学(Cambridge University)计算机科学系罗斯·安德森(Ross Anderson)教授表示，更严重的问题是政府官员把这个现代化项目分割给许多厂商，而他们之间的协调却非常糟糕。“完全不同的软件、不同的标准，一切都是各自为政。” 安德森教授指出，他主管的信息与政策研究基金会(Foundation for Information Policy Research)一直对这个现代化项目提出批评。NHS的官员隐瞒了项目的问题，而坚称项目的最终成果能提高对病人的服务。
安德森评论到，很多情况下安装的系统之间彼此根本不兼容。“这不单单是浪费数十亿英镑的问题，而且它很可能危及病人的生命。”他警告说。当然也许就这样放任下去，随着厂商的减少，这个系统反而会变得比较兼容。因为其中一家厂商埃森哲咨询公司(Accenture，下称埃森哲)9月已经退出，并把自己的合同份额转给了美国计算机科学公司(Computer Sciences Corp.)。而埃森哲不得不拨出4.5亿美元抵消在这个项目中的损失。
大型外包项目的潮流是把任务分包给不同的厂商。本意是为了减低风险，在厂商间引入竞争机制。NHS现代化项目中包括转包商共有10多个厂商参与。这简直是在重建巴比伦塔(Tower of Babel)。分担风险固然重要，但多个厂商的介入也会引起严重的问题。
墨菲定律仍然适用
[编者注：墨菲定律(Murphy’s Law)缘于美国一位名叫墨菲的上尉。墨菲认为他的某位同事是个倒霉蛋，不经意地说了句笑话：“如果一件事情有可能被弄糟，让他去做就一定会弄糟。”]
不是每个人都讨厌IT失误。比如在税务问题上弄虚作假的美国人就肯定会对美国内务财政收入局(Internal Revenue Service)失败的IT策略暗自窃喜。这个失败的策略就是年初美国内务财政收入局对欺诈行为检测软件进行的拙劣升级。“如果哪里会出问题，那么必然会是这个项目。”财政部审计处的检查员玛格丽特·贝格(Margaret Begg)明确指出。
内务财政收入局原本计划在一月让系统上线，这样正好能赶上2006年税季开始。而且这也正是项目实施整一年的日子。万众期待之下，税务署的IT人员终止了旧系统。新版本由计算机科学公司开发完成，除了内务财政收入局的主数据库，新系统的数据库资料比任何其他内务财政收入局的系统都更庞大，结果却完全无法正常运作。对于一个从2001年就开始设计的软件而言实在是说不过去。根据财政部审计处的估算，因为缺少了防欺诈系统，每年要多花3.18亿美元填补由于漏税导致的税收漏洞。
一场为期4个月、由美国众议院筹款委员会(House Ways and Means Committee)组织的调查发现这个系统“在方方面面都不合格。” 委员会主席参议员比尔·托马斯(Bill Thomas)在八月致美国财政部长(Treasury Secretary)亨利·保尔森(Henry Paulson)的信里这样写到。特别引人注目的是内务财政收入局的IT负责人错误地把这个项目归为维护而不是一次重大升级，这直接导致没有足够的监管和资助。托马斯指出，“这套系统涉及到国家的税收，非常重要。”这套系统是内务财政收入局19项被美国联邦政府列明为国家重要基础设施，防恐怖袭击重点保护对象。
到一月系统该上线的时候，还有由测试人员提交的534项问题列表。其中一个问题是欺诈检测系统项目组和这套系统最主要的使用者内务财政收入局的犯罪调查科之间完全没有沟通。事实上，沟通问题处处存在。其中一个研发小组修改了内容，却没有周知，这会影响相关的研发小组。因此内务财政收入局的系统适用性测试(System Acceptability Testing)小组每换一个地方就会碰到新的问题。贝格的报告表明，系统适用性测试小组不得不再提交一项错误报告，返回到开发商那里，又需要修改一次软件。在采访中，贝格指出内务财政收入局缺乏完成这样重要应用所必需的项目管理守则。“他们的测试不够严格，也没有引入足够的项目管理活动，所以没有确定的计划可依据执行。”她分析说。
这当然这不是内务财政收入局第一次把IT系统弄得一团糟。在过去8年里，这个机构花费80亿美元试图升级它的整体网络运算基础架构。美国国家审计总署(Government Accountability Office)复查了这个项目，发现多处出现资金超支、铺张浪费和效率低下等问题。部分原因是内务财政收入局的IT员工正在陆续退休，而合格的接替人员却很难找到。“如果需要推行某个计划，他们没有所需要的稳定性和连续性。”贝格评论道，并补充表示他们的IT管理层更替特别频繁。内务财政收入局正计划在2007年税季来临之前把旧系统恢复上线，同时还计划开发基于Web的系统。人们少不了要替他们捏把汗啊!
注重技术生命周期
2005年，美国联邦调查局(Federal Bureau of Investigation)扔掉了它那千疮百孔的虚拟案例系统(Virtual Case File System)，这套定制软件能在追查罪犯的时候为调查人员提供检索多个犯罪数据库的功能。这套软件的功能对联邦调查局来说是个难解的情结了，因为软件公司Inslam公司曾指责司法部剽窃了该公司的Promis 案例管理(Promis Case Management)软件，修改后给联邦调查局使用。Inslaw公司最后输了官司。但是在“9·11”恐怖袭击之后，对这种系统的需求又再度急迫起来。
这个价值1.7亿美元的失败的虚拟案例系统项目，是联邦调查局现代化三部曲中的一部分，虽然没有像上次那样遭遇剽窃指控，但这个项目实施过程中联邦调查局却犯了一个IT界的大忌：如果一个长期项目完成之时，所用技术也将过时，那么就要避免实施这样的项目。项目设计者应该考虑到当他的想法付诸实现之日，将来的技术环境是怎样的，哪些技术会被广泛使用。
在2001年计划虚拟案例系统项目的时候，联邦调查局选择了定制软件的方式，尽管当时许多大公司都能够提供更便宜、更通用的现成应用程序。“技术的革新一下子就超过了我们最初版本的虚拟案例系统，现在已经涌现了许多项目初始阶段没有的新产品。”联邦调查局无奈地在去年一份终止项目的报告上承认这点。
而虚拟案例系统在这非常不顺利的4年中共任命过9位项目经理和5位首席信息官(CIO)。
该项目的贡献是为联邦调查局带来了教训，让它抛弃了虚拟案例系统项目而转向信息管理系统Sentinel。Sentinel系统采用先进的技术，有比较长的生命周期：它是基于网络(Web-Based)和服务导向架构(SOA)的，因此可以和其他外部执法数据库以及其他支持Web服务标准的数据库相连。
Sentinel系统在第一阶段会向联邦调查局特工和分析员提供门户站点，让他们访问快要被替换的自动案例支持系统，日后数据会转到新的案例管理系统上。该系统还会包括一个案例管理“工具箱”，其中汇聚了使用者的所有工作(特工或者分析员正在处理的案例文件)，并可根据案例文件的人物、地点、时间进行检索。
今年3月，联邦调查局与洛克希德·马丁公司(Lockheed Martin)签订了高达 3.05亿美元的Sentinel系统合同。合同分包商包括埃森哲和计算机科学公司。计算机科学公司的Dyncorp 部门曾是美国司法部Promis项目的合作厂商。期望这次合作会比前次更顺利。
提防仓促上马的项目
在上世纪90年代，提供电视收视统计的尼尔森媒介研究公司(Nielsen Media Research，下称尼尔森)的技术高层因为贸然开展一项重要的项目而吃尽了苦头。该公司想重写自己的核心评估系统。这可不是随便更替一个办公室外围设备的问题，它是尼尔森数以10亿美元计的业务核心引擎。不幸的是，IT高管们盲目加快进度，导致编码一塌糊涂，浪费了数百万美元，还把其中的主要开发商告上了法庭，到现在已经过去10年了，尼尔森还在试图完成这个项目。项目的参与者之一评价说：“他们希望尽快完成，其结果就是他们到今日还在为此付出代价。”
这个项目的目标是把原来用于大型主机上的基于编译器代码的评估系统转换成客户-服务器架构，期望以此提高用户友好度和灵活性，尼尔森也能更准确地分离数据，卖给它那些传媒业客户们。因为这是个复杂的项目，尼尔森的技术人员原本预计需要3年完成，正好就在千禧年来临之际。
但高管对这个时间表不满意，据消息人士称他们希望系统能在一年之内上线。工程开始匆忙上马启动。
即便你希望找个机器人来管理你的 IT部门，市场上也立刻会有人表示他们能够供货。所以尼尔森找到一个外包商担保能在一年内完成这个项目也不足为奇。1997年，尼尔森和TenFold公司签订了一份软件开发合同。“他们拍了板，我们只能跟进。”相关人士表示。TenFold公司和尼尔森都谢绝了对此进行评论的要求。
尼尔森的底层技术人员从一开始就对这个项目报怀疑态度，很快就有迹象显示他们是有道理的。其后几个月对项目的检查发现，TenFold公司的评估系统使用的是文本格式文件而不是合同里要求的基于对象的开发方式。
这背后的理由是TenFold公司没有足够的时间正常地完成工作。据说在一次代码检查中，尼尔森的一位IT经理发现在一名TenFold公司开发人员的笔记本上写着：“我们只能写这些垃圾，因为我们没有时间正确地完成它。”
尽管情形令人担心，但尼尔森的IT高管要求内部员工全力支持TenFold公司。内部人员表示，“我们被要求不要干扰他们，以免引起不愉快。”
但是到最后，尼尔森的IT决策者们也受够了TenFold公司的迟缓进展。他们在2000年6月终止了该项目，控告TenFold公司并要求赔偿450万美元。双方最后达成保密的和解，但尼尔森的问题并没有得到解决。在项目开始10年之后，尼尔森还在试图把评估系统的升级拉上正轨。
++++++++++++++++++++++
信息周刊：2006年商业科技黑镜头之5大教训
编者按：商业科技的复杂性可以构筑从业人员的职业地位，当然也可以在一夜之间毁掉它。高调的商业应用光鲜外表下包含着无数需要重视的细节，其中IT细节尤为关键。没有对于技术能力的充分估计，缺乏足够的预先风险测试，没有完善的灾备方案，不考虑如何对待正常用户和恶意用户等都可能导致重大的商业灾难。
没有可以轻视的IT细节
仅因一颗马钉的脱落，导致了一名骑士的摔倒，一名骑士的摔倒导致一位国王的死亡，一位国王的死亡导致一场战役的失败，一场战役的失败最后导致一个帝国的灭亡。这则有关细节决定成败的西方谚语有了中国版本。
2006年3月2日14点10分，当天运行平稳的沪深大盘忽然发生了罕见的大跳水，在7分钟内，上证指数跌去了近20点。此后几天，市场参与者再也没有了暴跌前的乐观。沪深大盘也以连续大跌迎来了一次大级别的调整。股市中数百亿元的财富灰飞烟灭，无论是个人还是机构投资者都在这次莫名的大跳水中损失惨重。
虽然股市的调整有其内在的一些必然因素，但这些因素是否起作用，许多时候取决于是否有“马钉”的存在。业内分析人士认为，在消息面平静的情况下，扮演此次上证指数风云突变的“脱落的马钉”就是当日下午上海证券交易所(下称上证所)IT系统的故障。
据悉，在当日下午，刚上市的招商银行(下称招行)认股权证由于成交量巨大，导致其行情显示时总成交量字段溢出，致使其总成交量显示异常，并使招行权证价格在股票分析软件上成为一条不再波动的直线。这种现象让市场产生了恐慌，以为发生了突发性的灾难新闻事件，导致市场抛盘汹涌而出，带动股指发生了两波快速下跌。当日收盘，上证指数下挫1.6%，成为今年以来最大的跌幅日之一。
小小的一个显示字段出错，导致了整个IT系统的故障，引发了一场严重的恐慌，使数百亿元的财富缩水。不过，这种由于IT产生的细节失误而导致严重后果的现象，并不是偶然现象。以金融业为例，据统计，近年全球已经有多起因为IT系统故障导致金融市场大动荡的现象发生。
去年末，在短短的40天内，东京证券交易所(TSE)由于交易系统软件升级出现问题导致两起重大事故，致使投资者蒙受了重大损失。事后，除有关方面责成东京证券交易所对交易系统做全面检查以外，其系统提供商富士通公司(Fujisu)还对自己的相关高级工作人员进行了处罚。
还有一个典型的例子来自纽约证券交易所(New York Stock Exchange，下称纽交所)。2005年6月的一天，IT通信故障造成纽交所停止运行四分钟，引发了交易厅的一阵混乱，纽交所被迫取消了所有交易。场内人士后来透露，问题是由负责交易所市场数据信息发布以及维护计算机交易系统的证券行业自动化公司(SIAC)造成的。
确实，由以上事件可以看出，IT在成为证券业及其他金融业基石与支柱的同时，其细节上的得失也正同时成为企业和社会危机的根源之一。今日之事，他日之鉴。3月2日上证所“招行权证”事件所敲响的警钟，不仅仅是为上证所的IT主管所鸣，同时也是为所有企业的首席信息官(CIO)而鸣。
不打无准备之仗
对于IT项目负责人来说，一个全新项目的上线挑战性极大，如果不做好全方位的准备，没有考虑周全各种潜在的风险，以及没有将系统调试到最佳状态的话，新项目初次上线往往会面临非常多的麻烦。
2006年7月，第一期电子式储蓄国债在全国范围联网销售，就遇到个让系统管理人员措手不及的大麻烦。
由于是首次发行新型的电子式国债，而且数量有限，吸引了全国众多的购买者，在全国各地，购买者从开售当日一大早就排起了长队，场面十分火热。但是开售没多久，多家银行系统出现故障，购买者无法登录购买电子国债，有些银行销售系统由于长时间中断从而错过这短短几个小时的销售，更是让苦苦等候多时的购买者空手而归。
此次国债全国代办网点一起通过财政部的系统抓数，代理银行不受数量的限制，各地投资者先购先得，售完即止。正因为这样，对各地银行的系统提出了很高的要求，一旦系统出现问题，就无法满足当地购买者的需求。中国银行、中国农业银行(下称农行)以及交通银行(下称交行)都出现了不同程度的系统故障，农行系统中断长达5小时，而交行一些支行不但无法办理购买国债业务，甚至连储蓄等其他业务也无
法办理了。
中央国债登记结算有限责任公司则表示，国债公司发行系统端一直保持正常，而且此次发售国债数量远未达到系统负载峰值。问题出在哪里？业内人士认为，目前许多银行都在自行开发系统，各银行间开发水平有差距，加上电子国债属首次发布，又是随机抓取机制，这其中系统连接的带宽限制与短时间内海量数据的处理对销售系统来说都是极大的考验。如果之前不做好充足的风险压力测试以及连接准备，的确很容易出现问题。
这次事件之后，到10月发行第二期电子国债时，中国工商银行下属一支行表示，第一期国债发行时系统不稳定，导致很多客户买不到国债，到第二期时，该支行所有窗口都可以办理电子国债业务，分散了客户的流量，系统运行也非常顺利。
看来，在接受了一次教训之后，各大银行也都有了经验，想出各种应对措施，努力打好有准备的仗。
“有备”不一定无患
IT的集中管理往往被看作是解决信息孤岛、提高运行效率的有效手段。然而集中之后的IT系统“牵一发而动全身”。因此在集中之时，还需要多留一手，不仅仅是建设备份系统，也要真正用好备份系统。典型的案例发生在2005年10月，中国民航信息网络股份有限公司(下称中航信)的主机故障导致全国数个机场航班延误。
从10月10日13点32分起，由于中航信离港系统的主机出现技术故障，导致广州白云机场、深圳机场、北京首都机场等机场的离港航班受到影响，出现不同程度的延误。事故发生后，部分机场启动了自主开发的离港备份系统，并且采用人工方式为旅客办理登机手续及行李托运手续。当天14点16分，中航信离港系统恢复正常，但是影响直到晚上才逐渐消除。
在中国，绝大部分机场的离港系统都由中航信提供，实行数据集中管理。这种集中管理保证了全国所有机场的离港业务在标准以及操作规范上的统一，但同时如果中航信的系统发生了故障，则很容易波及到多个机场。事实上，中航信的离港系统发生故障并不是第一次。今年1月11日，由于中航信位于北京总部的服务器出现故障，就曾经造成成都双流机场离港系统“瘫痪”近40分钟。这种故障是不可避免同时也是不可预料的，因此建设一个完善的备份系统和备份制度就显得必不可少。
在航空这个高度依靠信息技术的行业，灾难备份系统的建设并不落后，在这次中航信的系统故障中，各地机场也同时启用了备份的离港系统，但航班延误的情况仍然较为严重。据某航空公司人士透露，此次虽然受影响的机场都切换了备份系统，但由于许多数据仍然需要与北京进行传送，这中间可能出现了很多信息错误的情况，使得备份系统的作用没有充分发挥。由此可见，备份系统不应该是“备而不用”，不是建设了备份系统就能高枕无忧，围绕备份系统切换的一整套流程同样需要保证万无一失，否则“有备”也并不一定能够无患。
没有外围的技术缺陷，只有核心的管理缺失
中国银联股份有限公司(下称银联)网络瘫痪的后果远比想象中严重。2006年4月20日10点56分，银联网络系统因主机原因出现了“大面积”的瘫痪，导致北京、上海、广州、江苏、浙江、福建等18地的银行卡不能跨行交易，据不完全数据统计显示，34万家商户以及六万台ATM机因此受到影响。
近年来，由于系统故障而引致的银行卡跨行交易中断并非首次，不过仅限于小范围地区，这次受影响的持卡人、商户以及交易中断时间达到银联成立以来之最，也是金融系统之最。就此，银联在事隔6天之后发布了极其含糊的官方说法，表示“故障原因是由于银联新近准备上线的某外围设备的隐性缺陷诱发了跨行交易系统主机的缺陷，使主机
发生故障。”
但同时银联又强调，这个结论还有待相关厂商的专家进一步确认。11月底，《信息周刊》记者电话采访银联询问最终结果。银联声称，虽已查明故障原因，但考虑到这属于银联内部的筹划，而且涉及的技术细节过于专业，用户可能难以理解，因此拒绝透露“主机致命”的真正原因。
不过，知情人士透露说，原来银联计划在4月25日上线一台新设备，20日上午工作繁忙时段，正当银联技术人员进行测试的时候，系统主机突然出现宕机，导致整个系统瘫痪，全国跨行交易无法正常进行。这一次宕机事件，反映出银联事前对产品测试中可能出现的问题估计不足，并没有估计到系统瘫痪的面积会如此之大、情况如此严重，事先所准备的应急预案只不过是针对小范围的故障的。
一次小疏忽引发了一场意想不到的大事故。受影响企业之一的杭州银泰百货公司信息部负责人金龙发指出：“如果考虑更周全一点，也许问题就不会发生。”关键系统的切换几乎都会选择在交易量最小的时间，如夜间进行，此时万一出现事故，也可将风险降至最低。
由于银联系统瘫痪了近9个小时，时间如此之长备受质疑。一般来说，当主机宕机之后，另一个备份机可以接管系统，保证系统的正常运行，从主机切换到备份机的时间不会很长。业内人士猜测，很可能是银联主机宕机以后，主机冗余不足或者备份机根本没有起作用，或者当初应急系统设计和建设不够理想，又或者是银联新上的系统和原系统有冲突，导致整个系统瘫痪。
不能坐等互联网强盗来“发现”你的致命弱点
2006年9月21日17点左右，作为中国三大域名服务提供商和网站服务提供商之一，北京新网数码信息技术有限公司(下称新网)的域名解析(DNS)服务器出现故障，其名下注册的约有10万左右域名不能访问，部分DNS还被解析到不正确的主机上。
来自新网的数据显示，该公司为超过60万家企业客户提供服务，占据了中国互联网基础服务业务20%以上的市场份额。此次灾难据不完全统计，造成了中国近3成网站从互联网上消失。直到第二天中午，新网才恢复其80%客户网站的正常访问。
尽管新网进行了积极的补救，而且事后新网也证实，DNS服务器出现问题是由于遭到大规模黑客攻击，但是，新网显然没有考虑到用户的感受，并没有就是否赔偿用户损失做出说明及承诺。新网处理此事略显粗硬的态度激怒了部分用户，在新网注册大量域名并在这次事件中被波及的中国网库发表声明，要求新网公开向中国网库道歉，同时赔偿直接和间接经济损失150万元。
互联网基础服务商遭遇网络攻击不是什么新鲜事，因此造成的服务中断事故也有多起。万网、百度等均曾因黑客攻击而导致服务中断。此类事件中，责任认定是最大的难题。在新网断网事件中，新网自身IT系统是否存在漏洞或操作上的失误，均无法为外人所知，但如果单纯将责任归咎于黑客攻击，显然对遭受损失的用户有失公允。
美国科学家的一项研究表明，似乎无所不能的互联网，却有着“阿喀琉斯之踵”(编者注：阿喀琉斯是希腊神话里的无敌英雄，可一旦被射中右脚后跟，就会轰然倒地。英语中意指致命的弱点。)，只要几个关键环节被破坏，整个互联网将在瞬间瘫痪。互联网基础服务提供商时刻都会面临着与新网类似的危机，如何避免造成难以挽回的损失呢？加强自身的系统安全？减少漏洞？保证操作规范？这些也许还不够，公开透明的事后处理方式也同样重要。
2006-12-23 08:00
除了麦当劳公司1.7亿美元的企业资源计划(ERP)项目的惨败;电力公司的软件缺陷导致加拿大和美国东北地区的大规模断电以外，还有更多失败案例。阅读了解这些黯淡的细节，能够帮助企业找到避免类似惨剧的出路。
商业科技的复杂性可以构筑从业人员的职业地位，当然也可以在一夜之间毁掉它。高调的商业应用光鲜外表下包含着无数需要重视的细节，其中IT细节尤为关键。没有对于技术能力的充分估计，缺乏足够的预先风险测试，没有完善的灾备方案，不考虑如何对待正常用户和恶意用户等都可能导致重大的商业灾难。
在我们这座商业科技耻辱柱上，除了麦当劳公司1.7亿美元的企业资源计划(ERP)项目的惨败;电力公司的软件缺陷导致加拿大和美国东北地区的大规模断电以外，还有更多案例。阅读了解这些黯淡的细节，能够帮助企业找到避免类似惨剧的出路。
贪多嚼不烂
麦当劳公司(McDonald，下称麦当劳)的这个项目规模和覆盖范围极广，以致最终变成了不可能完成的任务。2001年的时候，快餐连锁业巨头打算开展一个项目，建立一个连接总部和遍布各地餐厅的企业内部网(Intranet)，以提供实时的运营信息。在这个代号为“创新”(Innovate)的项目里，公司在伊利诺伊州奥克布鲁克(Oak Brook)总部的经理能实时了解在佛罗里达州奥兰多(Orlando)特许经营店里的销售情况正在变缓，或者伦敦餐厅里的烤架温度不够热。麦当劳一直对“创新”项目守口如瓶——该公司对本文的采访不予回应——但它的覆盖范围之广勿庸置疑。根据受麦当劳聘用负责早期策划和技术选型的顾问公司Mpower公司的白皮书资料，这个计划的目标是创立“一个逐渐深入到每一家麦当劳店铺的全球ERP应用。”换而言之，这包括超过120个国家里的3万多家餐厅。这样的工程真的易如反掌吗?
根据麦当劳提交给美国证交会的季度报告，他们在顾问和初始实施阶段花费了1.7亿美元之后才意识到这个项目实在过于庞大。麦当劳终于在2003年给美国证交会的财物报告中宣判了“创新”项目的死刑，项目被注销，管理层决定终止这个长期技术项目。
财务报表中的补充揭示了一条绝大多数有经验的IT项目经理从一开始就能给麦当劳提出的忠告：企图在上千家门店之间创建传递实时信息的全球网络，它们中有的还缺乏基础网络建设，注定会失败。财务报告显示，“尽管这个终止项目原本的目标是长期效益，但在当前环境下，并不是最好的资金使用方式，因为预期在几年内整个系统的开销将超过10亿美元。”
这场需要耗费上10亿美元、过于超前的IT项目重蹈了McDLT汉堡(20世纪80年代一种双层包装、把热食与冷食两部分分开置放汉堡)的覆辙：因为大多数人一次吃不掉那么大的汉堡。
谨慎对待错误
有时候技术灾难的影响远远不止于出问题的公司本身。美国俄亥俄州的第一能源公司(First Energy，下称第一能源)为450万客户提供电力，3年前就因为一个与电源失效有关的软件缺陷，使美国东北部和部分加拿大地区大面积陷于停电。
这次停电的原因是俄亥俄州砍伐树木切断了平衡东北电网出入电流的电线引起的连锁反应。但真正的问题在第一能源的计算机部门，它的IT经理们好像忘了一个基本操作原则：无论引入多少自动化处理或员工经验多么的丰富，应用程序都必须遵从必要的IT管理协议，如IT基础设施库(Information Technology Infrastructure Library，ITIL)的规定。
如果第一能源的软件报警系统能正确地对不稳定情况向工程人员提出报警的话，停电原本可以局限在很小范围内。报警系统的关键在于：当你发现系统不工作的时候，一切已经太晚了。“不稳定的状况原本不会直接导致停电，但是第一能源没能及时做出响应是事故的主要原因。”北美电力可靠性协会(North America Electric Reliability Council)负责基础架构安全的经理史丹·约翰逊(Stan Johnson)总结道。
2003年8月13日下午2点左右，该公司的IT人员发现运行General Electric XA/21管理系统的服务器上的报警模块停止了工作。工作人员重启机器试图修复该问题，但服务器重启后，报警模块仍然无法正常工作。通用电气公司(GE，下称通用电气)在其后的一篇声明里表示，这是因为一个软件代码错误引起报警程序进入死循环而无法重新在线工作。而第一能源在俄亥俄工厂控制室里的操作人员没意识到这条防御线已失效，因为他们的IT架构在重启之后不会校验相关的系统是否都已恢复工作。同时，不稳定的电力状态在迅速恶化。
因为忽略了IT管理里最重要的原则，员工也不愿意与终端用户确认检查，确保他们的关键系统已能完全正常使用。IT基础设施库尤其建议IT部门建立一个受影响用户的确认列表，在重启关键性系统后，管理员必须与他们一一联系。在北美电力可靠协会关于这次停电的最后一份报告里，它指责第一能源的IT部门缺乏沟通意识。
第一能源谢绝关于此事件的采访，但约翰逊表示协会的最后一份报告里该公司已遵从了必要的建议。尤其是，协会敦促第一能源建立必要的规章，书面的管理测试、部署和备份关键硬件或软件系统准则，包括执行系统升级、补丁包管理、备份恢复和维护的方法。它还建议该公司必须建立一套系统发生故障时必须明确的交流规程。事实上，这些良好的建议适用于所有的公司。
注重细节
想象一下，在一家没有财会系统的公司里担任会计职务的滋味。这正是德尔·欣斯基(Dale Shinskey)的遭遇。他是一名财务专业人员，欣斯基的前任雇主是全球燃料服务公司(World Fuel Services)的子机构国际石油公司(International Petroleum)，在2000年被废油循环再生公司Earthcare公司用3,500万美元购并，欣斯基也因此加入了Earthcare公司。不幸的是，欣斯基表示：“Earthcare公司完成了购并，却忽略了细节。”
这项交易显示，仍由全球燃料服务公司维护欣斯基团队用来记账的Oracle财会系统。但是出现了一个问题：欣斯基宣称Earthcare公司忘了向全球燃料服务公司支付该系统的维护费，在短暂的使用之后，系统被终止。欣斯基抱怨道：“那3个月我们手头什么也没有。”在这期间，Earthcare公司只是简单地评估该机构的财务状况，估计财务数据，这些数字后来证明都是错的。“他们想把财务系统自己运作起来，但根本没法做到。”欣斯基指出。
糟糕的财务管理让Earthcare公司遇到了更大的麻烦。2001年公司被迫向全球燃料服务公司支付175万美元用于解决与收购国际石油公司相关的争端。当年6月，Earthcare公司又把国际石油公司卖给了美国过滤恢复服务公司(U.S. Filter Recovery Services)，这样欣斯基也随之离开了Earthcare公司。
但故事并没有完结，在过滤恢复服务公司工作一年之后，欣斯基和他的财务部门被要求从赛捷软件(Sage Software)的MAS 200应用程序向一套名为 Uptime from Uptime的软件迁移。“情况糟糕透了，我们管那段时间叫停工期。”欣斯基回忆道。原因是美国过滤恢复服务公司使用一套20世纪80年代初开发的落伍系统，并且不愿意出钱把欣斯基部门的财会系统整合到公司的Oracle应用环境中去。“这套系统没有下拉菜单。如果不在计算机里加上一大堆附注说明，你简直没法使用这套系统。”欣斯基抱怨道。
情形令人如此头痛，以致部门的财务和会计断断续续地离职以逃避困境。而现在已并入西门子公司(Siemens)的美国过滤恢复服务公司拒绝了《InformationWeek》的访问要求。
欣斯基表示，他们获得的教训是：实施购并的公司应该对购并后的各种运作方式有周详的考虑，其中需要确保有合适的工具支持公司的管理。
拒绝“金钱婚姻”
有的公司企图通过把IT外包以摆脱困境。一家非常着迷于外包概念的保险和金融机构甚至为此专门购并了一家外包公司。但这个决定，最后却令购并者懊悔无比。
仅仅从2001年到2002年的15个月期间，美国印第安那波利斯的康赛可公司(Conseco，下称康赛可)先是购并了印度外包商ExlService公司，继而又反悔转手卖掉了该外包公司。ExlService公司当时处于起步阶段，在印度提供低成本呼叫中心客户服务。当时康赛可总裁兼首席执行官(CEO)加里·韦特(Gary Wendt)还在通用电气工作时，就以提倡外包客户服务而著名。对他来说，这家企业无疑很诱人。在韦特的决策下，康赛可用5,200多万美元购并了ExlService公司。
韦特认为ExlService公司能在一夜之间为康赛可提供低成本高质量的客户服务。他对美国印第安那州本土的人力资源不是很有信心。在《波利斯明星报》(Indianapolis Star)问他为什么把公司的客户服务搬到海外去时，他表示“我很确信印度能提供更好的客户服务。而美国本土的(公司)不行。”
这只是其中一个理由，韦特在这桩交易里也获得了利益;他成了ExlService 公司的联合创始人，并在交易中获得ExlService公司20%的股票期权。根据美国证交所的文件显示，韦特和他的妻子在这桩交易里纯获利692,567 股康赛可股票，共价值970万美元。但兑现这些股票是有条件的，必须等康赛可确认能从这笔购并交易中获得良好收益才能生效。康赛可没有回应《InformationWeek》采访的请求。
在购并之后，康赛可就把2,000个客户服务职位转移到在印度的ExlService公司。在一份管理法规补充报告里，康赛可宣布在2002年11月放弃ExlService公司，损失达2,000万美元。自然韦特的股票期权也随即化为乌有。
根据波利斯明星报的报道，康赛可的一些高层把投资失败归咎于时机错误。因为康赛可的印度呼叫中心上线的日子是2001年9月10日。第二天就发生了“9·11“恐怖袭击，带外国口音的呼叫中心自然立刻蒙受负面影响。
这件事的教育意义是什么?警惕外包陷阱?足够充分理由，谨慎选择合作伙伴?不要低估本土人力资源?也许上面这些都包括。
各取所需导致消化不良
英国全国医疗保健系统(National Health Service，下称NHS)的IT 现代化项目也许是现存的最大规模的IT灾难。该项目比预期时间滞后2年，超支100亿美元，在花钱规模上它和美国波士顿的大隧道计划(Big Dig，美国迄今为止耗资最大也是最复杂的高速公路)项目不分伯仲。它的其中一个主要厂商——以医疗健康程序开发为主业的iSoft公司已在破产的边缘，因为该公司一直无法在这个网络上部署自己的软件。如果应用程序不能部署，iSoft就无法获得收益，所以延时无疑会拖垮他们。各种技术问题包括要整合不兼容的系统，而抵触的医生们则认为该项目没有事前充分咨询他们的意见，厂商之间就程序的功能互相指责，彼此推卸责任。
负责这个项目的IT高层和政府官员们已经挣扎了好几年，企图把项目拉上正轨。但问题依然严重并仍然持续。一台应该今年报废的大型计算机就使英格兰西北部和中英格兰北部地区的80家医疗结构停业4天。错误的起因是NHS管理下的一台存放有上百万病人记录和医疗数据的服务器出现问题。那几天里受影响区域的医生们没法获得病人的预约信息，导致对病人的服务严重延误。在一份报告中，NHS声称病人的安危并没有受损害。
深入研究过NHS项目的剑桥大学(Cambridge University)计算机科学系罗斯·安德森(Ross Anderson)教授表示，更严重的问题是政府官员把这个现代化项目分割给许多厂商，而他们之间的协调却非常糟糕。“完全不同的软件、不同的标准，一切都是各自为政。” 安德森教授指出，他主管的信息与政策研究基金会(Foundation for Information Policy Research)一直对这个现代化项目提出批评。NHS的官员隐瞒了项目的问题，而坚称项目的最终成果能提高对病人的服务。
安德森评论到，很多情况下安装的系统之间彼此根本不兼容。“这不单单是浪费数十亿英镑的问题，而且它很可能危及病人的生命。”他警告说。当然也许就这样放任下去，随着厂商的减少，这个系统反而会变得比较兼容。因为其中一家厂商埃森哲咨询公司(Accenture，下称埃森哲)9月已经退出，并把自己的合同份额转给了美国计算机科学公司(Computer Sciences Corp.)。而埃森哲不得不拨出4.5亿美元抵消在这个项目中的损失。
大型外包项目的潮流是把任务分包给不同的厂商。本意是为了减低风险，在厂商间引入竞争机制。NHS现代化项目中包括转包商共有10多个厂商参与。这简直是在重建巴比伦塔(Tower of Babel)。分担风险固然重要，但多个厂商的介入也会引起严重的问题。
墨菲定律仍然适用
[编者注：墨菲定律(Murphy’s Law)缘于美国一位名叫墨菲的上尉。墨菲认为他的某位同事是个倒霉蛋，不经意地说了句笑话：“如果一件事情有可能被弄糟，让他去做就一定会弄糟。”]
不是每个人都讨厌IT失误。比如在税务问题上弄虚作假的美国人就肯定会对美国内务财政收入局(Internal Revenue Service)失败的IT策略暗自窃喜。这个失败的策略就是年初美国内务财政收入局对欺诈行为检测软件进行的拙劣升级。“如果哪里会出问题，那么必然会是这个项目。”财政部审计处的检查员玛格丽特·贝格(Margaret Begg)明确指出。
内务财政收入局原本计划在一月让系统上线，这样正好能赶上2006年税季开始。而且这也正是项目实施整一年的日子。万众期待之下，税务署的IT人员终止了旧系统。新版本由计算机科学公司开发完成，除了内务财政收入局的主数据库，新系统的数据库资料比任何其他内务财政收入局的系统都更庞大，结果却完全无法正常运作。对于一个从2001年就开始设计的软件而言实在是说不过去。根据财政部审计处的估算，因为缺少了防欺诈系统，每年要多花3.18亿美元填补由于漏税导致的税收漏洞。
一场为期4个月、由美国众议院筹款委员会(House Ways and Means Committee)组织的调查发现这个系统“在方方面面都不合格。” 委员会主席参议员比尔·托马斯(Bill Thomas)在八月致美国财政部长(Treasury Secretary)亨利·保尔森(Henry Paulson)的信里这样写到。特别引人注目的是内务财政收入局的IT负责人错误地把这个项目归为维护而不是一次重大升级，这直接导致没有足够的监管和资助。托马斯指出，“这套系统涉及到国家的税收，非常重要。”这套系统是内务财政收入局19项被美国联邦政府列明为国家重要基础设施，防恐怖袭击重点保护对象。
到一月系统该上线的时候，还有由测试人员提交的534项问题列表。其中一个问题是欺诈检测系统项目组和这套系统最主要的使用者内务财政收入局的犯罪调查科之间完全没有沟通。事实上，沟通问题处处存在。其中一个研发小组修改了内容，却没有周知，这会影响相关的研发小组。因此内务财政收入局的系统适用性测试(System Acceptability Testing)小组每换一个地方就会碰到新的问题。贝格的报告表明，系统适用性测试小组不得不再提交一项错误报告，返回到开发商那里，又需要修改一次软件。在采访中，贝格指出内务财政收入局缺乏完成这样重要应用所必需的项目管理守则。“他们的测试不够严格，也没有引入足够的项目管理活动，所以没有确定的计划可依据执行。”她分析说。
这当然这不是内务财政收入局第一次把IT系统弄得一团糟。在过去8年里，这个机构花费80亿美元试图升级它的整体网络运算基础架构。美国国家审计总署(Government Accountability Office)复查了这个项目，发现多处出现资金超支、铺张浪费和效率低下等问题。部分原因是内务财政收入局的IT员工正在陆续退休，而合格的接替人员却很难找到。“如果需要推行某个计划，他们没有所需要的稳定性和连续性。”贝格评论道，并补充表示他们的IT管理层更替特别频繁。内务财政收入局正计划在2007年税季来临之前把旧系统恢复上线，同时还计划开发基于Web的系统。人们少不了要替他们捏把汗啊!
注重技术生命周期
2005年，美国联邦调查局(Federal Bureau of Investigation)扔掉了它那千疮百孔的虚拟案例系统(Virtual Case File System)，这套定制软件能在追查罪犯的时候为调查人员提供检索多个犯罪数据库的功能。这套软件的功能对联邦调查局来说是个难解的情结了，因为软件公司Inslam公司曾指责司法部剽窃了该公司的Promis 案例管理(Promis Case Management)软件，修改后给联邦调查局使用。Inslaw公司最后输了官司。但是在“9·11”恐怖袭击之后，对这种系统的需求又再度急迫起来。
这个价值1.7亿美元的失败的虚拟案例系统项目，是联邦调查局现代化三部曲中的一部分，虽然没有像上次那样遭遇剽窃指控，但这个项目实施过程中联邦调查局却犯了一个IT界的大忌：如果一个长期项目完成之时，所用技术也将过时，那么就要避免实施这样的项目。项目设计者应该考虑到当他的想法付诸实现之日，将来的技术环境是怎样的，哪些技术会被广泛使用。
在2001年计划虚拟案例系统项目的时候，联邦调查局选择了定制软件的方式，尽管当时许多大公司都能够提供更便宜、更通用的现成应用程序。“技术的革新一下子就超过了我们最初版本的虚拟案例系统，现在已经涌现了许多项目初始阶段没有的新产品。”联邦调查局无奈地在去年一份终止项目的报告上承认这点。
而虚拟案例系统在这非常不顺利的4年中共任命过9位项目经理和5位首席信息官(CIO)。
该项目的贡献是为联邦调查局带来了教训，让它抛弃了虚拟案例系统项目而转向信息管理系统Sentinel。Sentinel系统采用先进的技术，有比较长的生命周期：它是基于网络(Web-Based)和服务导向架构(SOA)的，因此可以和其他外部执法数据库以及其他支持Web服务标准的数据库相连。
Sentinel系统在第一阶段会向联邦调查局特工和分析员提供门户站点，让他们访问快要被替换的自动案例支持系统，日后数据会转到新的案例管理系统上。该系统还会包括一个案例管理“工具箱”，其中汇聚了使用者的所有工作(特工或者分析员正在处理的案例文件)，并可根据案例文件的人物、地点、时间进行检索。
今年3月，联邦调查局与洛克希德·马丁公司(Lockheed Martin)签订了高达 3.05亿美元的Sentinel系统合同。合同分包商包括埃森哲和计算机科学公司。计算机科学公司的Dyncorp 部门曾是美国司法部Promis项目的合作厂商。期望这次合作会比前次更顺利。
提防仓促上马的项目
在上世纪90年代，提供电视收视统计的尼尔森媒介研究公司(Nielsen Media Research，下称尼尔森)的技术高层因为贸然开展一项重要的项目而吃尽了苦头。该公司想重写自己的核心评估系统。这可不是随便更替一个办公室外围设备的问题，它是尼尔森数以10亿美元计的业务核心引擎。不幸的是，IT高管们盲目加快进度，导致编码一塌糊涂，浪费了数百万美元，还把其中的主要开发商告上了法庭，到现在已经过去10年了，尼尔森还在试图完成这个项目。项目的参与者之一评价说：“他们希望尽快完成，其结果就是他们到今日还在为此付出代价。”
这个项目的目标是把原来用于大型主机上的基于编译器代码的评估系统转换成客户-服务器架构，期望以此提高用户友好度和灵活性，尼尔森也能更准确地分离数据，卖给它那些传媒业客户们。因为这是个复杂的项目，尼尔森的技术人员原本预计需要3年完成，正好就在千禧年来临之际。
但高管对这个时间表不满意，据消息人士称他们希望系统能在一年之内上线。工程开始匆忙上马启动。
即便你希望找个机器人来管理你的 IT部门，市场上也立刻会有人表示他们能够供货。所以尼尔森找到一个外包商担保能在一年内完成这个项目也不足为奇。1997年，尼尔森和TenFold公司签订了一份软件开发合同。“他们拍了板，我们只能跟进。”相关人士表示。TenFold公司和尼尔森都谢绝了对此进行评论的要求。
尼尔森的底层技术人员从一开始就对这个项目报怀疑态度，很快就有迹象显示他们是有道理的。其后几个月对项目的检查发现，TenFold公司的评估系统使用的是文本格式文件而不是合同里要求的基于对象的开发方式。
这背后的理由是TenFold公司没有足够的时间正常地完成工作。据说在一次代码检查中，尼尔森的一位IT经理发现在一名TenFold公司开发人员的笔记本上写着：“我们只能写这些垃圾，因为我们没有时间正确地完成它。”
尽管情形令人担心，但尼尔森的IT高管要求内部员工全力支持TenFold公司。内部人员表示，“我们被要求不要干扰他们，以免引起不愉快。”
但是到最后，尼尔森的IT决策者们也受够了TenFold公司的迟缓进展。他们在2000年6月终止了该项目，控告TenFold公司并要求赔偿450万美元。双方最后达成保密的和解，但尼尔森的问题并没有得到解决。在项目开始10年之后，尼尔森还在试图把评估系统的升级拉上正轨。
++++++++++++++++++++++
信息周刊：2006年商业科技黑镜头之5大教训
编者按：商业科技的复杂性可以构筑从业人员的职业地位，当然也可以在一夜之间毁掉它。高调的商业应用光鲜外表下包含着无数需要重视的细节，其中IT细节尤为关键。没有对于技术能力的充分估计，缺乏足够的预先风险测试，没有完善的灾备方案，不考虑如何对待正常用户和恶意用户等都可能导致重大的商业灾难。
没有可以轻视的IT细节
仅因一颗马钉的脱落，导致了一名骑士的摔倒，一名骑士的摔倒导致一位国王的死亡，一位国王的死亡导致一场战役的失败，一场战役的失败最后导致一个帝国的灭亡。这则有关细节决定成败的西方谚语有了中国版本。
2006年3月2日14点10分，当天运行平稳的沪深大盘忽然发生了罕见的大跳水，在7分钟内，上证指数跌去了近20点。此后几天，市场参与者再也没有了暴跌前的乐观。沪深大盘也以连续大跌迎来了一次大级别的调整。股市中数百亿元的财富灰飞烟灭，无论是个人还是机构投资者都在这次莫名的大跳水中损失惨重。
虽然股市的调整有其内在的一些必然因素，但这些因素是否起作用，许多时候取决于是否有“马钉”的存在。业内分析人士认为，在消息面平静的情况下，扮演此次上证指数风云突变的“脱落的马钉”就是当日下午上海证券交易所(下称上证所)IT系统的故障。
据悉，在当日下午，刚上市的招商银行(下称招行)认股权证由于成交量巨大，导致其行情显示时总成交量字段溢出，致使其总成交量显示异常，并使招行权证价格在股票分析软件上成为一条不再波动的直线。这种现象让市场产生了恐慌，以为发生了突发性的灾难新闻事件，导致市场抛盘汹涌而出，带动股指发生了两波快速下跌。当日收盘，上证指数下挫1.6%，成为今年以来最大的跌幅日之一。
小小的一个显示字段出错，导致了整个IT系统的故障，引发了一场严重的恐慌，使数百亿元的财富缩水。不过，这种由于IT产生的细节失误而导致严重后果的现象，并不是偶然现象。以金融业为例，据统计，近年全球已经有多起因为IT系统故障导致金融市场大动荡的现象发生。
去年末，在短短的40天内，东京证券交易所(TSE)由于交易系统软件升级出现问题导致两起重大事故，致使投资者蒙受了重大损失。事后，除有关方面责成东京证券交易所对交易系统做全面检查以外，其系统提供商富士通公司(Fujisu)还对自己的相关高级工作人员进行了处罚。
还有一个典型的例子来自纽约证券交易所(New York Stock Exchange，下称纽交所)。2005年6月的一天，IT通信故障造成纽交所停止运行四分钟，引发了交易厅的一阵混乱，纽交所被迫取消了所有交易。场内人士后来透露，问题是由负责交易所市场数据信息发布以及维护计算机交易系统的证券行业自动化公司(SIAC)造成的。
确实，由以上事件可以看出，IT在成为证券业及其他金融业基石与支柱的同时，其细节上的得失也正同时成为企业和社会危机的根源之一。今日之事，他日之鉴。3月2日上证所“招行权证”事件所敲响的警钟，不仅仅是为上证所的IT主管所鸣，同时也是为所有企业的首席信息官(CIO)而鸣。
不打无准备之仗
对于IT项目负责人来说，一个全新项目的上线挑战性极大，如果不做好全方位的准备，没有考虑周全各种潜在的风险，以及没有将系统调试到最佳状态的话，新项目初次上线往往会面临非常多的麻烦。
2006年7月，第一期电子式储蓄国债在全国范围联网销售，就遇到个让系统管理人员措手不及的大麻烦。
由于是首次发行新型的电子式国债，而且数量有限，吸引了全国众多的购买者，在全国各地，购买者从开售当日一大早就排起了长队，场面十分火热。但是开售没多久，多家银行系统出现故障，购买者无法登录购买电子国债，有些银行销售系统由于长时间中断从而错过这短短几个小时的销售，更是让苦苦等候多时的购买者空手而归。
此次国债全国代办网点一起通过财政部的系统抓数，代理银行不受数量的限制，各地投资者先购先得，售完即止。正因为这样，对各地银行的系统提出了很高的要求，一旦系统出现问题，就无法满足当地购买者的需求。中国银行、中国农业银行(下称农行)以及交通银行(下称交行)都出现了不同程度的系统故障，农行系统中断长达5小时，而交行一些支行不但无法办理购买国债业务，甚至连储蓄等其他业务也无
法办理了。
中央国债登记结算有限责任公司则表示，国债公司发行系统端一直保持正常，而且此次发售国债数量远未达到系统负载峰值。问题出在哪里？业内人士认为，目前许多银行都在自行开发系统，各银行间开发水平有差距，加上电子国债属首次发布，又是随机抓取机制，这其中系统连接的带宽限制与短时间内海量数据的处理对销售系统来说都是极大的考验。如果之前不做好充足的风险压力测试以及连接准备，的确很容易出现问题。
这次事件之后，到10月发行第二期电子国债时，中国工商银行下属一支行表示，第一期国债发行时系统不稳定，导致很多客户买不到国债，到第二期时，该支行所有窗口都可以办理电子国债业务，分散了客户的流量，系统运行也非常顺利。
看来，在接受了一次教训之后，各大银行也都有了经验，想出各种应对措施，努力打好有准备的仗。
“有备”不一定无患
IT的集中管理往往被看作是解决信息孤岛、提高运行效率的有效手段。然而集中之后的IT系统“牵一发而动全身”。因此在集中之时，还需要多留一手，不仅仅是建设备份系统，也要真正用好备份系统。典型的案例发生在2005年10月，中国民航信息网络股份有限公司(下称中航信)的主机故障导致全国数个机场航班延误。
从10月10日13点32分起，由于中航信离港系统的主机出现技术故障，导致广州白云机场、深圳机场、北京首都机场等机场的离港航班受到影响，出现不同程度的延误。事故发生后，部分机场启动了自主开发的离港备份系统，并且采用人工方式为旅客办理登机手续及行李托运手续。当天14点16分，中航信离港系统恢复正常，但是影响直到晚上才逐渐消除。
在中国，绝大部分机场的离港系统都由中航信提供，实行数据集中管理。这种集中管理保证了全国所有机场的离港业务在标准以及操作规范上的统一，但同时如果中航信的系统发生了故障，则很容易波及到多个机场。事实上，中航信的离港系统发生故障并不是第一次。今年1月11日，由于中航信位于北京总部的服务器出现故障，就曾经造成成都双流机场离港系统“瘫痪”近40分钟。这种故障是不可避免同时也是不可预料的，因此建设一个完善的备份系统和备份制度就显得必不可少。
在航空这个高度依靠信息技术的行业，灾难备份系统的建设并不落后，在这次中航信的系统故障中，各地机场也同时启用了备份的离港系统，但航班延误的情况仍然较为严重。据某航空公司人士透露，此次虽然受影响的机场都切换了备份系统，但由于许多数据仍然需要与北京进行传送，这中间可能出现了很多信息错误的情况，使得备份系统的作用没有充分发挥。由此可见，备份系统不应该是“备而不用”，不是建设了备份系统就能高枕无忧，围绕备份系统切换的一整套流程同样需要保证万无一失，否则“有备”也并不一定能够无患。
没有外围的技术缺陷，只有核心的管理缺失
中国银联股份有限公司(下称银联)网络瘫痪的后果远比想象中严重。2006年4月20日10点56分，银联网络系统因主机原因出现了“大面积”的瘫痪，导致北京、上海、广州、江苏、浙江、福建等18地的银行卡不能跨行交易，据不完全数据统计显示，34万家商户以及六万台ATM机因此受到影响。
近年来，由于系统故障而引致的银行卡跨行交易中断并非首次，不过仅限于小范围地区，这次受影响的持卡人、商户以及交易中断时间达到银联成立以来之最，也是金融系统之最。就此，银联在事隔6天之后发布了极其含糊的官方说法，表示“故障原因是由于银联新近准备上线的某外围设备的隐性缺陷诱发了跨行交易系统主机的缺陷，使主机
发生故障。”
但同时银联又强调，这个结论还有待相关厂商的专家进一步确认。11月底，《信息周刊》记者电话采访银联询问最终结果。银联声称，虽已查明故障原因，但考虑到这属于银联内部的筹划，而且涉及的技术细节过于专业，用户可能难以理解，因此拒绝透露“主机致命”的真正原因。
不过，知情人士透露说，原来银联计划在4月25日上线一台新设备，20日上午工作繁忙时段，正当银联技术人员进行测试的时候，系统主机突然出现宕机，导致整个系统瘫痪，全国跨行交易无法正常进行。这一次宕机事件，反映出银联事前对产品测试中可能出现的问题估计不足，并没有估计到系统瘫痪的面积会如此之大、情况如此严重，事先所准备的应急预案只不过是针对小范围的故障的。
一次小疏忽引发了一场意想不到的大事故。受影响企业之一的杭州银泰百货公司信息部负责人金龙发指出：“如果考虑更周全一点，也许问题就不会发生。”关键系统的切换几乎都会选择在交易量最小的时间，如夜间进行，此时万一出现事故，也可将风险降至最低。
由于银联系统瘫痪了近9个小时，时间如此之长备受质疑。一般来说，当主机宕机之后，另一个备份机可以接管系统，保证系统的正常运行，从主机切换到备份机的时间不会很长。业内人士猜测，很可能是银联主机宕机以后，主机冗余不足或者备份机根本没有起作用，或者当初应急系统设计和建设不够理想，又或者是银联新上的系统和原系统有冲突，导致整个系统瘫痪。
不能坐等互联网强盗来“发现”你的致命弱点
2006年9月21日17点左右，作为中国三大域名服务提供商和网站服务提供商之一，北京新网数码信息技术有限公司(下称新网)的域名解析(DNS)服务器出现故障，其名下注册的约有10万左右域名不能访问，部分DNS还被解析到不正确的主机上。
来自新网的数据显示，该公司为超过60万家企业客户提供服务，占据了中国互联网基础服务业务20%以上的市场份额。此次灾难据不完全统计，造成了中国近3成网站从互联网上消失。直到第二天中午，新网才恢复其80%客户网站的正常访问。
尽管新网进行了积极的补救，而且事后新网也证实，DNS服务器出现问题是由于遭到大规模黑客攻击，但是，新网显然没有考虑到用户的感受，并没有就是否赔偿用户损失做出说明及承诺。新网处理此事略显粗硬的态度激怒了部分用户，在新网注册大量域名并在这次事件中被波及的中国网库发表声明，要求新网公开向中国网库道歉，同时赔偿直接和间接经济损失150万元。
互联网基础服务商遭遇网络攻击不是什么新鲜事，因此造成的服务中断事故也有多起。万网、百度等均曾因黑客攻击而导致服务中断。此类事件中，责任认定是最大的难题。在新网断网事件中，新网自身IT系统是否存在漏洞或操作上的失误，均无法为外人所知，但如果单纯将责任归咎于黑客攻击，显然对遭受损失的用户有失公允。
美国科学家的一项研究表明，似乎无所不能的互联网，却有着“阿喀琉斯之踵”(编者注：阿喀琉斯是希腊神话里的无敌英雄，可一旦被射中右脚后跟，就会轰然倒地。英语中意指致命的弱点。)，只要几个关键环节被破坏，整个互联网将在瞬间瘫痪。互联网基础服务提供商时刻都会面临着与新网类似的危机，如何避免造成难以挽回的损失呢？加强自身的系统安全？减少漏洞？保证操作规范？这些也许还不够，公开透明的事后处理方式也同样重要。