在过去十年中，通过追踪大型的IT灾难而获得的重要心得。

十年前，IEEE Spectrum发布了一篇名为 《软件为什么会出现故障》 的文章，其中分析了一些著名的项目故障潜在成因。几年后我们开了 “风险因素（Risk Factor）” 这个博客，希望能追踪或大或小的各类技术故障。

为了记录十年来的故障，从中吸取教训，我们对收集的数据进行了整理分析。我们不敢声称这份故障数据库就是明确而全面的，事实上也没人敢这么说。不过我们从记录的事件中精选了最有趣、最具说明性的大型IT系统与项目故障案例，并制作了5个交互式的专题（见下文），各个专题运用了不同的模式，着重不同的教训。下面就来仔细探究一下吧。重要心得之一：尽管无法确认现在的IT故障率比以前更高，但后果貌似比以前严重多了。

教训一：IT系统出错所导致的惊人影响

本章探究IT失败对各个方面的影响：不仅浪费金钱与时间，通常还会扰乱人们的生活。

这个世界数十年来一直非常依赖大型IT系统，不过我们还不了解该如何避免大型失败的发生。在IEEE Spectrum，十年来我们一直在记录这些失败与故障，开始是在时常被人引用的那篇 《软件为什么会出现故障》 中，后来就是在 “风险因素”博客 上。

这里我们将对这些失败做以回顾，以便更好地进行了解。我们遍寻存档，找出十年来最为著名也最有趣，同时最具代表性的失败案例集锦。由于其中涵盖了各类失败与故障，因此没有一个标准能单独衡量其相关影响。有些故障造成了直接的经济影响，比如在升级IT系统方面以及对项目进行现代化方面；还有一些在浪费的时间与影响人数上更容易衡量，比如宕机事件。

请记得这些失败只是冰山一角。它们只是我们在“风险因素”中所总结的数百起故障与失败中的一小部分，更是全球事件中的一粒微尘。全部事件的完整列表将会是这些事件几个数量级的倍数。

（以下内容是时间线表节选）

美洲

2005年6月

2008年4月

2009年6月

2009年6月

2010年2月

2010年2月

2011年3月

2012年11月

2013年2月

2014年11月

亚太

2008年3月

2010年1月

2012年5月

欧洲、中东、非洲

2006年7月

2006年10月

2007年9月

2009年1月

2012年6月

在回顾过去十年的时候，有几个问题是难以忽视的：

IT系统的现代化进程十分困难且价格高昂

美洲

2009年6月

2010年2月

2010年2月

2012年11月

2013年2月

亚太

2008年3月

2012年5月

影响：5.66亿澳元（合5.86亿美元）

澳大利亚维州终止了问题重重的智能健康电子病历系统（HealthSMART Electronic Health Record System），浪费了5.66个亿的澳元，却收效甚微。起初在2007年预估的成本为3.23亿澳元。

了解更多

欧洲、中东、非洲

2011年9月

2014年3月

全世界许多政府都开始着手IT现代化的工作，或替换旧式IT系统，或将许多系统合成一个。美国有几个州已经尝试改进社会福利与失业系统，不过以失败告终。同样，美国国防部一直尝试将支付与后勤系统现代化，而导致在项目取消与成本超支上花费了数十亿美元。英国在政府IT基础设施的现代化项目上也有大量开销，如2010年报废的全国身份注册项目（National Identity Register project），开销为2.57亿英镑（约3.94亿美元）。

病历电子化的进程也很困难且费用高昂

美洲

2013年2月

亚太

2012年5月

2012年6月

政府推动医疗信息技术的使用也促使澳洲、英国与美国等地一些主要IT项目惨败。比如英国曾尝试创建全国电子病历系统，最终在耗费了110亿英镑后（合170亿美元）于2012年撤销项目，而集成美国国防部与退伍军人管理局电子病历系统的计划在耗费了13亿美元后终告失败，价值归零。2009年的平价医保方案（Affordable Care Act）也造成了在多个州（夏威夷、俄勒冈、马里兰、马萨诸塞州）出现了IT项目失败，更不用说联邦级别的重大问题了。

银行所依赖的技术并不可靠

亚太

2010年11月

2011年4月

欧洲、中东、非洲

2010年1月

2011年11月

2012年6月

#p#分页标题#e#

由于IT基础设施投资不足，澳洲与英国的银行经常遇到IT故障。例如在2010年，澳洲国民银行的800万用户发现自己无法访问账户，该情况持续若干天；2012年同样的情况在英国与爱尔兰的苏格兰皇家银行也有出现，影响了600万用户。 一些RBS集团的用户有数周都无法访问自己的账户。

即便是短暂的股票交易所故障也花费不菲

美洲

2008年12月

2013年8月

亚太

2005年11月

2008年2月

2008年7月

2011年10月

2012年2月

欧洲、中东、非洲

2008年9月

2009年11月

2011年2月

全世界的证券交易所，包括东京、新加坡、伦敦、孟买、多伦多、芝加哥还有纽约都遇到过运转问题。在2010年，纽约证券交易所遇到了“闪电崩盘”，整个市场在几分钟内暴跌1000点，然后反弹；在2012年，差不多45分钟之内，由于遇到流氓算法（rogue algorithm）而导致骑士资本集团（Knight Capital Group）在错误交易上损失了4.4亿美元。

即便短暂的航空故障也花费不菲

美洲

2007年3月

2007年8月

2012年3月

亚太

2010年9月

欧洲、中东、非洲

2008年3月

2008年4月

2013年12月

2014年6月

航空公司在将订票系统现代化时经常遇到问题，特别是在合并系统时。在2007年，US Airways与America West航空公司在合并订票系统时出现了重大故障。在2012年与Continental合并时，United Airlines遇到了订票系统的重大故障。澳洲Virgin Blue的新型订票系统在2010年出台时也颇为曲折。2008年，British Airways在Heathrow Airport的自动化行李处理系统也遇到了宕机问题。

教训二：过于复杂而无法交付

尝试用单个系统替换多个系统的做法可能会导致毫无收获。

从头构建IT系统很难，但事实证明维护系统更难。很多政府机构数十年来对此极为忽视，导致它们参差不齐地都对系统理解贫乏、执行欠佳，从而限制了系统的运转效率与效果。在过去十年中，很多人尝试将多个老式系统的功能结合到单一的现代化替代系统上。

谈何容易。几乎在每个案例中这样的尝试都比预想的更难。这毫不出奇，因为每个需要被替换掉的老式系统都有着特定的挑战和隐藏的陷阱。我们对实际中能够合并的系统数量是否有所限制这一点非常好奇。

下面，我们将过去几年中的一些现代化进程的初始预期与最终结果进行了对比。几乎所有项目都超出预算，其中很多只交付了预想功能的很小一部分（或者干脆没能提供相关功能）。较长的线条一般代表着失败地更为彻底。

美国空军的ERP项目

美国国防部的DIMHRS项目

交付功能：0%

成本为初始预算的199%

国防军事一体化机构人力资源系统（DIMHRS）原计划通过整合DoD所使用的90种不同的IT系统来管理工资和人事记录。据DoD估计，DIMHRS将于2007年财年完全部署，开发成本约为4.27亿美元。最终在浪费了12年，花费了超过8.5亿美元之后终告失败。

了解更多

加州公务员退休基金（CalPERS）福利管理系统

加州的法院管理系统

加拿大British Columbia省的综合案例管理系统（Integrated Case Management System）

英国的消防项目

美国社会保障管理局的残疾案例处理系统（DCPS）

加州的MyCalPays工资现代化项目

虽然很难就数个项目得出明确的结论，不过几乎可以确定：IT现代化进程都会超出预算。图表还展示了项目中存在的挑战：普遍成本超支、延迟与功能缺失，甚至还有自我鼓吹成功故事的。

一个解决方案就是在评估时更切合实际。虽然需要更多数据（如果了解我们漏掉的项目，请留言），不过想要只花费4亿到5亿美元就将50多个重要的老式政府IT系统进行合并，这几乎是不可能的。因此我们在看到过度乐观的评估时应秉持怀疑态度，这可能完全是欺诈行为。事实上，我们应当预料到：未来的现代化工作进程会更为困难，因为老式系统与数据的技术欠缺程度，会比我们的修复能力发展地更为迅速。

不过想要进行准确的预测并负起相关责任，必须对需要完成的工作有清晰的理解。

我们要替换的系统有多少呢？

#p#分页标题#e#

IT现代化项目中最吸引人也最令人沮丧的案例之一就是美国空军远征作战支持系统（ECSS）。美国空军从审计团队调查中得知，耗费10亿美元却终告失败的根源在于这样的事实：“需要替换的远征作战支持系统的具体数量未知”。这样的结果毫不出奇，尽管从项目规划、管理和资金角度来看确实骇人听闻。我们之前 在博文中就2014年参议院ECSS审计报告解释过 ：“在不同场合中，空军对现有遗留项目的数量广泛使用各类不同的预估数据，从175个旧式系统到几百个旧式系统，再到超过900个旧式系统不等。”有一点非常奇怪，在2014年终止ECSS计划时，负责的USAF将军使用了一个数字——大约“214个旧式系统”，这个数字以前从未见过。在下面的图表中关于需要替换的ECSS旧式系统数量有不同的估计数据。

到底哪一个估值是准确的，还是都不对？实际上在这么多审计报告中，没有一个能提供系统的列表，因此也许我们永远也无法知晓。在这种情况下，测量的复杂程度不断变化，几乎注定了这个问题无人能够了解，因而绝不可能获得成功。

教训三：失败项目的生命周期

再多的金钱与时间也无法避免项目失败这一灾难。

IT项目很少立刻全然崩盘。相反，失败就像是滚雪球，随着时间推移越滚越大，越没有解决的希望。在这个过程中，成功的定义很容易随着截止日期的接近及预算的增长而变化。这就是为什么甚至在推迟了三年之后，项目还能被称为“提前”发布。

为了说明这个过程，我们将过去十年中的最糟糕的那些失败的IT项目拿出来，重新列出其预算与截止日期。

美国空军的远征作战保障系统（ECSS）系统

2004年1月：ECSS项目正式启动

在预想中， ECSS 是一个使用现成商业软件，将全军资源计划系统整合为单一系统的项目，旨在向全球各处需要服务的供给方提供现代化的服务。

ECSS 最初预估的生命周期成本 为30亿美元，开发约为18亿美元，操作和维护约为12亿美元，原本计划到2012年完全部署。

在早期进行了一些规避风险的重新规划之后，项目在2005年5月“重新启动”。

（注意：没人拥有ECSS的财政大权，这一点在美国参议院的调查报告中非常清楚，他们对空军无法说明投资的具体用项，甚至是ECSS对资金的具体使用安排表达了愤怒与失望。各个报告中所记录的预估及实际使用资金都是自相矛盾的。）

2006年9月：主要合同敲定

Computer Sciences公司获得了最大的合同之一——美国6.38亿美元的项目，提供技术与商业转型服务。在2006年初期，美国空军还向甲骨文支付了9千万美元，用以购买该系统的支持软件。

ECSS原本想要实现的功能仍然是个谜。彼时美国空军在两个自相矛盾的声明中表示：ECSS将会取代“400多个旧式系统”以及“700多个旧式系统”。

截止此时的花费：6500美元

2007年9月：财政模糊化

据2008年政府问责局报告，ECSS的整个生命周期总花费仍为30亿美元。同时报告中还强调，美国空军承认这个项目将会超支，因为在功能上本属于DEAMS的项目现在也将合并到ECSS中。需要替换的旧式系统数量将会减少到250个（尽管在空军文献中仍有“超过400个旧式系统”这样的描述）。

DEAMS的项目从2003年启动，计划将9个传统的空军会计系统替换掉，预估在整个生命周期中需要花费的成本为4.2亿美元，截止时间为2009年10月。按计划该项目将于2017年4月完工，预计生命周期花费为22亿美元。

截至此时的花费：1.95亿美元

2009年12月：核查现状

ECSS的花销飙升 到34亿美元的开发费用与18亿美元的维护运转费用，并且按计划最早将于2016年完全部署。

ECSS的第一个试行版出现了数据质量、数据转换、互操作性和集成、可用性、信息安全及需求可测试性各方面的问题。结果管理者决定，不仅要重构ECSS运行的方式，还要重构整个系统。他们计划要提高数据质量、升级所使用的Oracle软件并将发行的数量从3个增加到4个。

截至此时的花费：5.19亿美元

开发预算增加了16亿美元（+89%）。

2011年9月：项目重新评估

在2011年末，美国空军与国防部长办公室一同参与了项目审查，并同意“ECSS的开发与执行进度滞后”。

目前在这个项目上的花费达到了8.76亿美元，另有1.1亿美元的合同未付款项。美国空军表示，ECSS将会替代240个旧式系统。

截至此时的花费：8.76亿美元

2012年9月：项目被撤销

ECSS由于脱离控制而被正式撤销，共花费11亿美元。美国空军承认，想要实现系统计划功能的四分之一，都得再花费10亿美元。

截至2015年所损失的机会成本 已达50亿美元，到2017年如果无法替换的话，很可能还将再损失额外70亿美元。

#p#分页标题#e#

目前有执行ECSS替换系统的计划 ，但军方并未提及需要耗费的金额，旧式系统如何替换，以及何时能够运行。尽管有承诺其花费肯定 低于ECSS 。

ECSS失败的原因是什么？三份公开报告（来自 IDA 、 美国空军 还有 参议院 ）给出了很多原因，但95%的原因在于管理层的无能、过度狂妄自大以及无法听取负面信息的态度。尽管承诺过要吸取之前类似大规模IT失败的教训，但美国空军管理者不仅刻意忽略这些问题，还似乎故意发出挑衅。

那么谁需要为ECSS的失败负责呢？事实证明：没人对此负责。空军高级领导者已经说得很明白了， 没有必要 为了这个花了10亿美元却完全没用的IT系统解雇或贬谪任何人。

截至此时花费：10.3亿美元

开发预算增加了46亿美元（+135%）。

North Carolina的NCTracks

2008年12月：NCTracks合同启动

北卡罗来纳州（North Carolina）将第一个合同给了Computer Sciences公司（CSC），令其负责完成一个名为NCTracks的新型医疗索赔处理和管理系统。这是NC州在浪费了3千万美元之后的第二次尝试。

2011年7月：审查项目，重订计划

根据州审计，在2010年7月CSC公司“通知政府部门无法在预订日期正常发布，请求延期。在经过漫长的磋商之后，在2011年7月政府签署了一份合同补充条款，同意宽限18到22个月来完成该系统的构建，并将合同的总金额从2.65亿美元增加到4.84亿美元，并将运转时间延长了额外两年，到2020年。”

开发预算增加了1.373亿美元（+148%）。

2012年12月：继续延迟

系统为了适应法律法规的要求而继续延迟。

2013年7月：不成熟的发布

系统于2013年7月发布，并遇到了重大的问题。在系统开发的过程中，North Carolina由于新系统延迟上线而需要继续维护旧式福利系统，在上面至少花费了3600万美元（净值）。

系统原本预计在2014年夏季获得医疗补助制度认证（Medicaid certification），但由于bug太多，直到2015年3月也未能实现。直到2015年3月，NCTracks才算真正“修复”，获得联邦认证。

截至此时的花费：2.3亿美元

加州残疾保险自动化升级项目

2006年1月：项目正式启动

残疾保险自动化项目旨在将大量的手动工作自动化，让残疾保险索赔的申请工作更加简便。

2007年11月：项目重审

采购问题导致进度拖延，不过项目成本也有所下降。

2009年11月：重新评估并调整项目

加州就业发展部承认低估了该系统的复杂性与工作量，因此该项目被重新评估。为了完成该项目，政府向Deloitte Consulting支付了5200万美元。现在开发才算正式开始。

开发预算增加了1900万美元（+58%）

2011年11月：项目范围变更

由于项目范围变更而增加了生命周期成本，并延迟了进度。开发成本又增加了800万美元。

2012年5月根据报告，由于“成本通常在项目生命周期中有所增长，包括人员配备需求的增加、系统功能或范围的增加，数据中心成本增加等等”，而导致预算价格上涨。

开发预算增加了800万美元（+15%）

2012年11月：系统提前发布

系统“提前”发布，不过处理过渡问题还需要几个月。

很明显就算不统计州政府开销，总开发成本也超过6千万美元了，但由于没有审计报告，项目花费的具体项目与成本我们不得而知。

截至此时的花费：6千万美元

加州的失业保险现代化进程

2003年10月：加州的失业保险现代化项目正式启动

#p#分页标题#e#

加州的就业发展部（EDD）原本计划开发两个系统：呼叫中心网络平台与应用升级（CCNPAU）是为了给EDD的呼叫中心创建单一的网络基础设施，能够与智能呼叫分配系统进行交互。失业保险连续索赔重计划（CCR）旨在开发网站与电话应用，允许客户通过互联网或电话申请失业保险索赔，并在两周一次的基础上重新认证。

呼叫中心项目计划于2006年完工，CCR的重设计工作预算更多，计划时间更长。

2006年5月：项目合并

由于相互依赖关系两个项目被合并了，比CCNPAU的最初完工日期仅提前了几个月。根据IEEE Spectrum得到的只言片语，在这三年中并没有太多工作完成。文档中记录道：这个项目的计划阶段从2005年7月开始，一直延伸到2006年。2004年到底发生了什么还是个谜。

合并后的项目在维护时间表上仍是分开的。CCNPAU完工时间被推迟了4年，比一开始计划的开发时间长得多。CCR也获得预算追加，并延后了发布日期。

2007年8月：项目花费增加

由于采购方式的变更，CCNPAU的成本再次上升，不过好在计划的时间缩短了。同时CCR的成本继续上升，而且项目继续延迟。

2009年9月：花费更高，延迟更厉害

在该项目上又投入2年之后，CCNPAU的成本与延迟情况再次增加。不过现在CCR的进度再次提前（但仅提前一个月）。

2011年5月：呼叫中心更新发布

CCNPAU在2011年5月初次发布，比之前计划的截止时间：2009年延迟了4个月（比原本的截止日期推迟了4年多）。发布并不顺利；关于等待时间过长的投诉非常多。

2012年4月：继续延迟

CCR的发布又延迟了一年。

2013年9月：开始重新设计系统

CCR在劳动节周末发布，比最终期限迟了4个月（但按照原本计划，则已经推迟了5年多）。此外这次发布 完全就是一场灾难 。从发布开始，该州花费了大约400万美元来升级与修复CCR。

昆州健康部门的工资更换系统项目

2007年12月：IBM竞得了昆州卫生部的工资替换系统开发权。

IBM从共享服务项目（SSI）中获得了9800万澳元的资金，用于为澳洲昆州提供全州性的人力资源与财务解决方案。

其中的一小部分（6190万澳元）将用于为昆州卫生部打造一个新型工资系统。考虑到该州已经在打造这类系统上有过尝试（并且失败了），需要明确这笔资金预算低到难以置信。

2008年6月：交付结果为零

六个月过去了，审计师后来指出，交付结果为零。项目花费有略微增加，项目进度轻微拖延。

开发预算增加了200万澳元（+2%）

2008年10月：工作集中在工资支付系统上

工资支付系统离完工还差得很远。由于IBM表示要为昆州健康部门提供全州人力资源与财务解决方案的预算费用为1.81亿澳元，费用太过高昂，因此较大的提案都被取消了。

取而代之，让昆州健康部门的工资支付系统能够运作成了新的主要目标。IBM已经花费了总计3200万澳元的费用，包括花在工资支付系统上的那些，而合同的总金额为9800万澳元。

在对项目进行了总的评估之后，新的项目成本与进度只包括工资支付系统，不过没能完成。原本计划让IBM提供快速低成本的解决方案，结果工资支付系统的开发完全失控，。

原本预期在2008年11月末上线的项目，很快调整到了2009年3月/4月。事实证明这种预期也过于乐观。

截至此时的花费：3200万澳元

开发预算增加了8100万澳元（+81%）

2010年3月：系统过早发布

第二年要做的工作很多，但进展甚微，开发进度多次延迟。主要问题在于所涉及劳动合同与劳动分类的复杂性。据报道，根据13种不同的奖励结构，还有13种不同的劳动合同，支付员工工资的不同方式有2.4万种。经常由于系统稳定性不能通过测试，而造成项目进度的拖延。

根据后来的调查报告：“在2010年3月14日，经过10次失败的交付后，新的工资支付系统终于上线了。完全是一个灾难性的失败……”

当系统（仍未完全测试过）上线后，影响是灾难性的：超过1.8万名员工受到影响，其中1800名员工没发或少发了工资。员工总人数为7.8万人，很多雇员有一次拿到的是正确的工资金额，另一次是错的。在统计至少受到一次影响的员工人数时，没有得到结果。最终产生的工资问题涉及了1450万澳元。

IBM的工资支付系统花费此时为2500万澳元（它拿到了2200万澳元）；政府表示该系统的总成本（包括政府支出）总计为1.02亿澳元。

截至此时的花费：1.02亿澳元

2010年11月：该完全解决了

政府决定再支出2.09亿澳元来修复系统。

截至此时的花费：1.02亿澳元

2011年7月：系统改版

政府声称工资支付系统已经稳定。

截至此时的花费：3.11亿澳元

2012年6月：还未结束

#p#分页标题#e#

在系统开发上的花费至少达到4.4亿澳元。完全修复该系统还需要再追加1亿澳元的投入，而在未来5年运行这个系统需要8.37亿澳元；超额支付的工资花费还需要支付9100澳元。整个生命周期的总花费至少达到12.5亿澳元。截至2012年5月31日，仍有20万的手动工作，每两周昆州健康部门的1000多名雇员需手动提交9.2万份表格来执行工资的发放。为了正常运作，系统还需要数千次的修改与定制，因此政府雇佣了130多名人员来手动操作。为了搞清楚到底怎么回事，调查又花费了500万澳元。

截止此时的花费：4.16亿澳元

英国消防系统

2004年3月：消防项目启动。

旨在用九个专用的区域控制中心网络替换掉原本的46个局部控制的房间，将会动用国家计算机系统来处理呼叫、设备运送以及事故管理。原计划的推出时间是2007年10月，最终推迟到2009年10月。

项目成本包括IT与设施建设花费，因为两者缺一不可。

2007年6月：

截止2006年2月，负责人员意识到一开始在规模上和复杂程度上，特别是对信息技术的要求上都严重低估了该项目。在重新评估后，新的预算公布了，需要3.4亿美元。在2007年3月，欧洲航空防务和航天公司（EADS）被聘为总承包公司，开发需要的IT系统；合同价值可能达到2亿美元，完工时间为8年。设定最初上线为2009年10月，最终完工时间为2011年底。

开发预算增加了2.2亿美元（+183%）

2008年7月：现实很伤人

项目管理不善，几乎没有政府监管。在2008年4月，EADS承认开发该系统所需的一个重要组件无法运作。系统完整运行的时间被定为2012年初。

开发预算增加了4千万欧元（+12%）

2009年5月：项目问题重重

项目成本保持不变，而进度却推迟了。审查后发现了很多问题：项目管理无效、缺乏项目计划、供应商与政府之间关系糟糕。

2010年12月：项目终止

在耗费了2.5亿欧元后，项目宣告终止。另有2.19亿欧元的不可撤销支出，总开销达到4.69亿欧元。消防系统终止时最终“估计”的完工成本增长到6.35亿欧元，而初次发布是在2012年的某个时间，具体时间没人知道。

截止此时的花费：2.5亿欧元

开发预算增加了2.55亿欧元（+67%）

教训四：IT故障中的责任推卸

尝试匹配故障与成因。

在IT系统出现故障时，总有其成因。如果进行足够的深挖，其实任何问题都源于人类的决策：代码草率、测试不足、对依赖理解贫乏与假设错误。但在阅读（与报告）失败时，人们往往将责任归咎于无法自辩或者无法被解雇的科技这一无生命体。

我们从存储的失败报告中进行逐字提取，尝试确定过失方或失败产生的原因。你可能会注意到过失与责任有这样一些趋势。

请尝试匹配下面的故障与成因。

问题1/10

故障：计费问题影响了澳洲能源的使用者，新的IBM计费系统出现问题，影响了14.5万名用户。

原因：税款软件的问题已经被修复，但退税可能会由于一些因素而推迟8周时间。澳洲引用了这样的说法：“工作积压是由于IBM的中间软件无法处理由分销商等第三方所发送的销售文档。而故障产生是由于对正确性检查不足，IBM在印度的团队人手不足而造成的工作积压。

问题2/10

故障：电脑问题导致西雅图的主要公交隧道封闭数日，隧道停止使用近一周。

原因：西雅图市区公交隧道由于更新将封闭到本周五（更新：将会持续到12月24日星期一；更新2：改到12月26日；更新3：请等待另行通知；更新：将于12月27日开启）。据《西雅图时报》报道是由于电脑故障。

“海湾运输署在近期所指导的一项隧道更新项目中发现了两三个电路板疑似有缺陷，将会用5到6个类似的电路板进行替换。”

问题3/10

故障：Gmail宕机

服务停机时间约为2小时，波及1.5亿用户。

原因：根据事件记录，昨天所发生的问题是由于Gmail性能“升级”导致的。

问题4/10

故障：IT问题搞垮了英国HSBC的网上银行与ATM系统，有1500万用户受到影响。

原因：根据BBC的报道，问题可追溯到一台出错的服务器。

问题5/10

故障：伦敦证券交易所由于软件问题而关闭了7个小时。

#p#分页标题#e#

原因：据路透社报道，由于软件问题，而非最初所猜测的交易量过多问题，伦敦证券交易所（LSE）在周一关闭了7个小时。路透社引用了LSE发言人的表述：

“这是软件的问题，纯属巧合，由于两个我们无法实现预估的进程出现了问题。”

问题6/10

故障：澳洲维珍蓝航空公司（Virgin Blue）斥资1千万澳元的全新订票系统崩溃，澳洲航班因此推迟。

原因：究竟New Skies公司系统为何崩溃并没有给出原因。

问题7/10

故障：英国伦敦希思罗机场T5的新型行李架系统再次崩溃，有24个航班被取消，延迟的更多。

机场运营商BAA还发布了道歉：“今晨由于T5行李架系统的软件问题”。

问题8/10

故障：法航447航班在把西海岸坠毁，有228名乘客与机组人员在灾难中丧生，这是“自动化悖论”的沉痛案例。

法航447航班于2009年6月1日坠毁是由于导频混淆、“预警系统工程学”设计不当外加飞行员训练不足多方面因素导致的。

问题9/10

故障：德州实用性软件升级故障，Oncor Electric Delivery的计量软件故障影响了超过30万用户的账单计费。

原因：Oncor表示软件问题已经修复，并为“……对客户造成的不便”道歉。

问题10/10

故障：防病毒补丁让US-VISIT的边界扫描系统宕机，造成了端口延迟差不多一整天。

原因：据称是由于US-VISIT现场与弗吉尼亚数据中心的管理员出现了沟通障碍。

教训五：故障纪念碑

死亡的IT项目尸体被埋在成堆金钱下面。

从我们10年回顾中总结出的最后一个教训是：从IEEE Spectrum的2005年软件故障特刊到如今，改进少得可怜。可导致项目迅速死亡的项目风险因素并无改变。这片墓碑背后掩藏着不切实际与不够清晰的项目目标、定义很差的系统需求、不受控制的项目复杂性、贫乏的人机交互设计、草率的开发实践、利益相关者之间的恶性政治博弈还有激烈的商业压力，以上仅是寥寥数例。

如果你是IT高管、程序员或者项目经理的话，可能会对这片墓碑——集合了一部分过去10年中最为昂贵的IT项目故障——发出嘘声。这里集合了价值700亿的项目死亡记录，只是我们在“风险因素”博客中记录的所有死亡项目中的一小部分。我们并未计算这些项目可能花费的成本，就像科学怪人一样，它们在技术上仍然存在，但由于所产生的负面价值，死掉会更好些。

点击 这里查看全部

总结十年IT失败教训的原因

2005年秋季，IEEE Spectrum发布了 软件特刊 ，研究 软件失败如何产生 以及 怎样避免失败 的问题。此后不久，我们便开了博客记录全世界的IT项目与运行故障、心得情感还有其他技术故障。

现在发布10周年报告，似乎是时候回顾一下过去，浏览这1750篇博文，并针对软件崩溃与故障方面哪些有变化，而哪些没有变化得出整体印象了。显然，网络犯罪的频度与成本风险出现了重大转变，不过我们决定至少在目前阶段集中有限的资源来总结过去意想不到的系统开发和操作失败。

我与Spectrum的前资深互动内容编辑Josh Romero进行了详细研讨——他也负责互动调查“ 十年IT故障教训 ，关于IT项目与运行故障”的数据可视化工作。考虑到很多“风险因素”的博文只是讨论多个项目故障与运行问题的综述性文章，这将是个很有意义的任务。

为了使得工作可控，我们决定选用遇到重大麻烦的IT项目与系统。这意味着我们选用的开发项目都是被取消、遇到重大成本或计划故障、交付结果远低于预期的项目。而选取的IT系统运转故障都是遇到大规模宕机情况的。

为了进一步精简数据，我们精选了那些对事情发生经过、原因、花费与影响人群有可靠记录的项目故障或事故。如果在IT项目开发或运转故障中有特征并未改变，就代表缺乏可靠与详细的公开数据。我们会在以后的博文中详细讨论这类问题。

#p#分页标题#e#

这也突出了我们在“10年IT故障教训”中所使用数据的另一方面：数据是歪曲过的，不仅因为我们在记录时会选择要包含哪些、不包含哪些，还因为事件数据实际上是放在公共区域中的。大多数在列的故障都是政府项目，因为政府出于责任机制，更倾向于将问题曝光。私营企业更倾向于将IT故障隐藏起来，因此除非罕见的法律诉讼，很少有运转故障被曝光，除非影响到大量用户或者有政府监管机构介入。而在依靠语言报道的新闻里，很明显项目与运转故障中的数据会被歪曲。

即便考虑到数据的局限性，我们都能得出结论：IT项目失败与运行故障都比以前更为频繁也更严重了。如今，随着IT已经渗透了全球社会各个方面，这一点毫不奇怪。人们很容易忘记Facebook发布于2004年，YouTube发布于2005年，苹果的iPhone发布于2007年，而从2005年开始已经发布了三版新的Windows了。显然IT系统越来越复杂，越来越巨大（在数据获取、存储与操纵方面），不仅意味着困难度与花销的增加，也代表着维护困难度的增加。此外在运转的IT系统遇到停机时，受到影响的人群更广泛，有时候会波及全球数百万甚至数千万的人，这种级别的技术灾难在2005年以前十分罕见。

最重要的是过去10年中，在航空、银行、财政与医疗保健行业，特别是在政府部门都出现了重大的IT现代化进程，旨在替换20世纪八九十年代以及更早时期留存下来的IT系统。这些工作其中很多是要将多个不同的IT系统替换成单一的系统，事实证明通常这种做法在技术上和管理上比想象的难度更高，更不用说花费了。

我们从记录中提取数据制成了互动图表，正确的查看方式不止一种。我们建议读者通读一遍，从中找出感兴趣的链接，点击查看更详细的信息。你可能会感到惊讶：很多重大的IT故障都是没有听说过，或出乎意料被你忘记了的。如果你认为还有其他应该发布的开发与运转故障，或者项目成本与影响相关的更好数据，请告诉我们。在未来几周内，我们会发布更多图表，都是关于IT故障方面的观点，以及对“风险因素”档案博文的感悟的。

我们需要在IT项目失败后更好地进行总结

在总结近10年的IT开发项目失败与运行故障，完成这份特别的 互动报告 的过程中，最繁琐的工作就是在失败案例中寻找可信数据。

一开始我们在报告中使用的数据集远超过200个项目，但随着我们尝试寻找阐释情况（时间、原因、影响人群以及更为重要的——所造成的经济与社会影响）的可靠记录与可量化信息时，项目故障池迅速缩小。

事实上不仅经济方面的IT项目故障是这样——鉴于公司在记录失误方面极为谨慎，可以想到这一点——政府的IT失败项目也是这样的。有好多次我们在审查政府的审计报告时，困惑地发现同一个机构在做进度与功能方案时，对项目的初期与最终成本使用了不同的数据。项目信息的不统一性造成了在准确度、完整度与概念一致性方面出现问题。

我们最爱用的例子就是ECSS项目的案例（ 政府医疗保险项目仅仅位居其后 ）。 甚至在多重政府审计之后——其中还包括一个两党参议院武装部队委员会对这次惨败为期半年的 调查 ，结果却发现这起耗费了7年时间的项目管理失败无法获得全面的信息数据，也无法得出最终纳税人要付的费用。

考虑到这些，我们请求项目负责人与审计人员给出他们在过去10年的IT开发项目与运转失败上通过艰难辛酸而学到的教训：

在以后IT开发项目的资产或审计报告中，是否愿意以简单的图表或时间线形式来发布呢？应当直观的显示出：IT项目的开始日期（也就是项目初始投入的时间与资金）；项目希望完成的前三到五个功能性目标；还有在项目审查、交付与取消的关键时间点上的实际花费、完成时间、交付功能以及相对的预期值。

此外，如果项目扩展、重新定义或者重置的话，要将这些变更的细节描述地非常清楚。请别忘记指出这些变更是如何影响这些统计结果的。最后，如果项目取消的话，在最终成本统计中要记录机会成本。例如，由于需要维护老旧已被淘汰的系统，到目前为止失败的ECSS项目每年需要花费数十亿美元。你可以想见，总有这类项目状态的信息发布，但不幸的是，，这些信息很少以整体形式发布，即便发布也不太可能放在同一个地方。

与此类似，对于IT系统运行失败的相关记录，是否将所有结果都列入了呢——不仅是经济方面的，还有用户系统方面的，并且包括对内与对外系统？运转失败经常被认为只是“初级问题”，对于依赖系统正常工作的人来说更像是牙医用的“根管治疗术”。

#p#分页标题#e#

大约一年多以前Ontario所发布价值2.42亿加元的社保管理系统（SAMS）正是个很好的例子，目前它仍旧 无法正常运作 。省政府对于该系统的运作仍抱有乐观向上的态度，他们对系统发生故障对全省穷人所造成的影响视而不见。

大约100多年前，美国最高法院的法官Louis Brandeis认为：“称信息公开为社会和产业疾病的补救是当之无愧的。阳光是最好的防腐剂，灯光是最有效的警察。”希望我们对过去十年中的IT项目失败所做的这一点曝光能帮助减少未来故障的发生。

原文地址：Lessons From a Decade of IT Failures（译者/Vera 责编/钱曙光）