主题：252-Martyn Thomas：回头再看千年虫 -- 万年看客

https://www.youtube.com/watch?v=-_9p-3j7VSM

What Really Happened in Y2K? - Professor Martyn Thomas CBE

……或许今天的人们很难记得当年的情况，但是二十年前我们当中很多人都曾经非常担心不久后将会发生什么。如今想要回顾那个时代十分不易，因为那是很久以前的事，也因为当年的事情确实让人感觉不太现实。但是我们这些亲历者，我们这些亲自参与过相关工作的人们，当年确实曾经试图识别以及解决所谓千年日期改变带来的各种问题——或者说千年虫问题。我们对于当年的印象依然十分鲜明，对于我们来说千年虫依然是一个非常真切的问题。

当年围绕这个问题发生了很多事，人们发布了很多警告、出版了很多书刊，刊登了很多头条新闻。千年虫是一个软件问题，而且很可能是许多系统的共同故障点。虽然当时我们早已习惯了软件问题，但是却并不习惯很可能让许多系统几乎同时失灵的软件问题。当时的人们高度关切这个问题，尤其是银行业从业者和政府官员。有很多人都担心这会导致国家基础设施失灵，电网将会阻断，银行账户将会被抹消，贷款与债务账目将会烟消云散。因为时值千年之交，还有很多人认为千年虫是大型宗教事件，意味着世界末日即将到来。我给大家略微展示一下，画面上这些耸人听闻的内容全都来自当年发表的书籍、报纸与杂志文章。求生手册在当时非常流行，当时美国兴起了火热的求生主义运动，这些手册旨在指导人们度过各种各样的灾难。甚至还曾经出现过求生主义菜谱，指导人们如何在一个买不到东西的世界生存——作者显然认为供应链将会断裂，商店将会关门。当时还出现过极其魔怔的千禧年邪教与灾难邪教，教徒们相信世界末日即将到来，于是纷纷躲进深山里或者森林深处，因为他们想在精神上做好准备。

与此同时，我们这些计算机从业者花了一段时间才有所作为。慢慢地情况开始逐渐改善。起初人们对于这个问题很缺乏认识，于是就有了公共宣传运动，政府逐渐参与进来，联合国开始采取行动，世界银行开始采取行动——在世界银行这边，各家公司采取行动的时间还要比政府更早一些。但是逐渐地，大型公司取得了一些成果。至于真正促使人们迅速采取行动的因素在于当年的六大审计公司一致同意，他们不愿意签核持续商务活动所需的账户，除非被审计公司向他们保证，公司的全部关键系统都接受过签核，符合2000年的标准要求，因此理应不至于在二十世纪结束时崩溃。崩溃的可能性确实吓坏了很多人，包括财务主管与董事会成员，而这些人都掌握着不少资源。

在世纪末前一天，一切似乎风平浪静，致使人们多少感到有些扫兴：或许这么多开销、这么多努力、这么多恐惧全都没有必要，或许一切都只是一场闹剧。人们开始暗示千年虫无非是骗人的鬼把戏，背后主使无非是打算捞钱的咨询公司或者打算兜售新款设备的硬件公司等等。在一定程度上，这的确是流传到今天的信息。如今只要你听到有人谈论千年虫，谈话者肯定满嘴嘲笑，或者干脆用千年虫来举例说明“你为什么不能相信专家”。我希望通过这场讲座让大家有能力对抗这种说法。如果你同意我的说法，那么千年虫绝不仅仅是骗局，而是一记警钟。我们堪堪躲过了一场灾难。千年虫警告我们，哪些行为今后必须避免，哪些措施今后必须继续采取。如果我们学不到这一点，那么显然我们很可能会再度见识一番当年原本会发生的灾难。

接下来我要回顾六个与日期相关的千年之交问题。归根结底，这六个问题全都是同一个问题，但是展现方式各不相同。我想请大家看看我们当初怎样意识到这个问题的存在，我们需要做什么，应该怎么做；然后再看看实际上发生了什么，我们学到了怎样的教训，没学到怎样的教训。这六个问题我依次简单讲一讲。

应当记得，千年虫往往被视为一个技术问题，但其实并不是。这是一个商务问题，因为人们无法足够确定千禧年效应究竟有多大可能导致连锁反应，以至于无法进行保险。如今说到网络安全问题依然能听到这一点的回响。如今人们依然很难为网络安全失灵购买保险。有些保险公司确实出售网络安全保险，但是我不建议你去索赔，因为很可能是白费功夫。千年虫之所以是商务问题，因为问题规模实在太大：太多的基于微处理器的嵌入式系统位于其他设备零件内部，探明的故障率表明千年虫大规模潜伏在基础设施系统当中，至于相应的商务系统则更不必说。因为千年虫是许多不同系统的单一故障点，因此也就成为了许多不同组织的单一故障点。就算你的公司挺过了千年虫的进击，你的客户或者供应商还有可能出问题；在供应链上向你传递数据的上游公司或许会送来损坏数据，这样一来哪怕你的系统能够正确地处理正确数据也依然会出问题。因此千年虫涉及很多商务问题，比你想象的更加难以解决。

第一个问题在于接受处理的数据当中不包含世纪。这一点当然很正常，直到今天我们讨论六十年代或者二十年代的时候依然很清楚我们指得是哪个世纪。只要存储空间有限，即便到了今天，即便在2000年之后，我们依然不会标注世纪。可以看到，我们并不会在信用卡或者借记卡上标注发行时间是哪个世纪，因为卡面空间有限。所以并不意外的是，在计算机时代初期，许多数据还存储在80栏打孔卡上，计算机的磁性存储空间非常昂贵，主机的随机存储器空间不仅极其昂贵而且极其有限，人们自然会将世纪当成可以省略的信息。当时的程序员并不觉得这样做会导致什么问题，因为程序员并不认为自己的程序会被一直沿用到世纪之交，其次还因为当时的人们并不会思考此等尺度的未来问题，或者说世纪之交从一开始就不在他们的思考范围之内。艾伦.格林斯潘曾经告诉美国国会，自己也是导致千年虫问题的人们之一，因为他年轻时也是个程序员，他的代码记录也不很完备，而且他当年也需要节省存贮空间。他表示他和同事们专门苦心积虑地设计了怎样才能够挤出更多数据空间，从而让程序更加高效。他也是酿成问题的人们之一。

几乎所有利用日期的系统都会被千年虫影响，因为问题的核心在于一旦你开始对比或者排列跨世纪的日期序列，就一定会出现错误。待会我们举两个例子。常见的错误结果要么是0要么是负值，而不是你期待的日期，或者与你期待的日期正好相差100年。此类对比结果非常常见。画面下半部分列举了一部分需要处理日期的系统——安保设备、条形码读码器、电话总机、电梯、自动售货机、车辆等等——几乎覆盖了全部商务系统，即便今天大多数商务系统都要处理日期数据，大多数日期处理过程都包含日期比较或者排列。有些系统需要担心信用卡的到期时间或者电梯与自动扶梯的维修间期，一旦长时间未曾得到维修保养就要按照法律要求加以关停。此类系统同样很容易受到攻击。还有些系统为监控处理设备提供趋势数据，例如工厂里存在大量此类系统。例如在千年虫发作的早期，某大型污水处理厂的排放口闸门就出了问题，差点导致严重的环境污染事故。

以上是千年虫问题的根源、其次的问题在于大量个人电脑将会出毛病。早期个人电脑的计时系统非常简陋。早期的IBM个人电脑根本不会保存日期，每次关机再开机之后必须重新输入一遍日期。人们普遍认为这一设计非常麻烦。因此下一代IBM个人计算机XT开始保存日期以及世纪，但是具体做法却埋下了其他隐患，尤其因为在很多情况下这套做法往往不能正确保存数据，会将错误的日期或者世纪输如当时的操作系统DOS以及后来基于DOS的Windows系统，两者都遭受了许多相同的问题。DOS认定，一切有效日期都位于1980年到2099年之间。假如你输入一个它不喜欢的日期，DOS就会将日期重置为1980年4月1日。这一点导致很多计算机都出了问题。假如你在开机时将日期设定在二十一世纪，IBM个人电脑就会强行将日期改成1980年4月1日。大量问题由此而生，因为很多文件都被标注上了同一个错误日期——1980年4月1日——以至于打乱了备份周期，导致各种管理问题。

这还只是DOS一家的问题。在DOS之下还有BIOS系统，这套系统一方面负责驱动硬件，另一方面又要承载操作系统。BIOS同样会以各种愚蠢的方式出问题，有些问题的后果还非常严重。举个例子，有一套BIOS系统拒绝接受二十世纪九十年代之外的日期。如果你为系统设定范围以外的日期，那么系统就会发生无法通过重新设置来解决的故障，必须更换BIOS芯片才能解决问题，而BIOS芯片在设计上就不允许替换，因此大多数用户碰上这种事就只能更换电脑。就连Windows95碰上这一范围之外的日期也会出问题。二十世纪九十年代中期很多人都用上了Win95，或早或晚他们必须升级到Win98，这是第一版可以成功处理新世纪日期的Windows系统。问题并不仅仅在于日期处理，因为个人电脑应用非常广泛，控制着各种设备。

另一种控制手段是可编程逻辑控制器或者说PLC。典型来说这一部分网络与SCADA系统相连，即数据采集与监视控制系统，从各种控制器收集数据，从而监管整个工厂。PLC惯于处理趋势数据，这些数据来自一家复杂工厂里各种各样的测量指标，因此他们也会遇到大量问题，因为他们处理数据时同样会基于日期进行排列，尤其容易遭到千年虫的祸害。而且PLC软件往往高度定制化，专门为了特定的工厂设备配置而编写出来，编程用得是阶梯逻辑，只有少数人理解编程语言，而且他们的记录情况一般都很差劲。对于很多工业公司来说这一切导致了大量困难。

接下来说说四五六号问题。首先，2000年是1600年以来的第一个世纪之交的闰年。很多人都认为2000年既然是世纪之交就不能是闰年，但是没有人意识到2000可以被400整除，因此这一年确实是闰年，必须要解决这个问题。程序员是一个很有创造力的群体，尤其非常擅长构建看上去十分简单的解决方案，其实只是将问题推卸给了未来的程序员。在这里他们采取的方法之一就是将99作为文件尾标志。既然尾数为99的年份位于非常遥远的未来，因此不妨采用99来告诉阅读阅读序列文件或者磁带的程序：“你已经达到了文件的结尾。”随着我们开始将系统日期的年份设定为1999年，在一直这一年得到大量真正的数据，这种做法也成为了亟待解决的严重问题。

同理，0年也被用于特殊目的，比如标志某一份记录正在被处理，应当被排在文件最前方，以免之后遭到重复处理。这种做法一度得到广泛使用，每一处都要得到处理。至于固定世纪的用法更是随处可见，例如大量机构专用信纸早就在年份的位置印上了19XX，将二十世纪当成了常量，支票簿也往往会印上19XX，此外合同格式也是一样。所有预先设定了日期格式的世纪部分的物品都需要加以替换升级。这些都是在截止日期之前不断累加的额外工作量。事实上在美国足足有五万人——世界其他地区加起来大概也有这么多人——提前为自己预定了墓碑并且刻上了19XX，他们显然没想到自己能活到新世纪。因此就连墓碑上的铭文都要修改。

还有哪些事情让人们产生警惕？比如玛莎百货买了一批牛肉罐头，但是库存系统拒绝将其入库。这批罐头的保质期到期时间是2000年，库存系统却读取成了1900年，因此认定这批罐头已经过期了100年。玛莎百货退掉这批罐头之后，原本发货的仓库又另外发了一批，结果因为同样的原因又被拒之门外。就这样兜了几圈之后人们才意识到问题出在哪里。再举一个例子：在1992年，104岁的玛丽.班达（Mary Bandar）得知自己被幼儿园录取了。此外还有大量备份磁带的保留时间是999天，这个时长跨越新千年之后也会导致备份系统出现运算错误。

那么我们需要做什么？我们需要采取什么措施？首先要增强问题意识，因为你没法动员人们投资金钱解决问题，除非首先让他们知道问题的存在以及严重性。实际上直到很晚的时候，依然有一批数量惊人的人们不理解千年虫问题。1996年在政府支持下，我们建立了一支“2000别动队”，领头人是罗宾.古尼埃（Robin Guenier），他今天就坐在观众席前排，之前还帮助我筹备了这场讲座。其他领导人包括来自国防部以及计算机服务与软件协会的代表——后者可以说是当时的计算机行业行会。我们积极地成立并且运营了这个网络组织，做了很多好事。一开始我们得到了保守党政府的支持，他们意识到需要采取措施；后来工党于1997年上台之后决定英国真正需要的不是与政府合作的民间组织，而是得到政府彻底支持的官方项目。然后他们设立了“行动2000”项目，投入了远远更多的预算，花费了远比以往更多的钱。我刚才提到，最早意识到问题严重性的是审计公司，他们反过来又向客户提供了很多信息，起到了很大帮助。当年的G7在1998年的会议上还专门提到了千年虫问题并且警告各家公司。联合国与世界银行最终设立了全球千年虫协调中心来管理各国的国家级千年虫应对项目，当时几乎全部发达国家以及一大部分发展中国家都开展了类似项目。有趣的是，大多数全球千年虫协调中心的文件依然保存在互联网档案馆网站，你可以通过当年的报告看看各个国家采取的措施。

英国标准协会/BSI推出了应对千年虫的国家标准，后来这套标准被推广到了全球，标明了需要采取的合规措施。这套标准提供了基准线，可以被写入合同，这正是标准的重要作用。千年虫项目本身也有一套标准结构：首先要明确定义全部计算机系统，然后进行可靠的盘点来确定当前对于这些系统的了解程度；然后你还需要评估这些系统，找出其中哪些会发生千年虫问题。这是个大规模任务，包括扫描代码，解读代码，利用特殊工具处理源代码，进行测试来确定系统是否会在各种条件下失灵；然后还要指定补救措施来处理问题，这些补救措施本身又需要测试与落实；最后你还需要管理所有这些资产，因为原本的各项系统现在都有了升级版本，这些系统之间的关系必须得到协调。这是绝大多数公司所面临过的规模最大的IT项目，而且当年的绝大多数公司就像现在一样并不擅长在规定时间内实施IT项目。更有甚者，千年虫项目有着不止一个截止日期。尽管2000年的大限已经确定，但是在彻底检查程序之前你并不能确定你的系统会在什么时候开始失灵，会在什么时候开始应对位于新世纪另一侧的日期。

许多公司甚至都找不到自己程序的源代码。我记得当初为一家富时100强公司做报告，我把所有子公司的财务总监都叫来，总共60多个人，每个人都要负责各自公司的IT系统。我问他们：“如果你们相信自己有能力在下个月按照源代码重构公司里最关键系统，而且不会引入任何错误，请举手。不用你们干别的，只需根据源代码重建你们目前正在运行的系统就行。”结果一个举手的都没有。他们接下来讲的故事我都听腻了：“我们有过一位非常了不起的程序员，他对于客户的要求有求必应，经常加班到半夜，加入各种新功能。不过他的工作全都是在他自己的文件存储器上完成的。现在他离职了，他的文件我们全都找不着了。”我们需要的资源非常紧缺，因此推高了工资，许多退休员工被重金返聘了回来，以至于员工流动率提升了，因为各家公司都在寻找有正确技能的人，到处都在挖人。员工流动率与工资膨胀成了很显著的问题。

我们需要做什么？有各种方式可以解决这个问题。你可以将两位数日期扩展成四位数。这是个好方法，但是很昂贵而且很容易出错。另一种方法是窗口法，也就是修改日期程序，让程序通过日期本身来推断这个日期位于哪个世纪的具体年份。比方说，00到19年可以被默认为2000到2019年，20到99年则被默认为1920到1999年。不过这种做法要求我们必须在一切处理相同数据的系统上应用同一个窗口，否则还是会出问题。而且你还需要在你设定的窗口关闭之前采取更好的解决方案来取代这些系统。我不介意打个赌：现在肯定有些公司当初为了应对千年虫而设定了窗口，然后一直没有升级系统，眼看着窗口逐渐关闭。过去几年这个问题确实发生过好几次。当然你还可以直接改用新系统。顾问们经常推荐这种做法，因为顾问帮助公司安装新系统的报酬十分可观。供应商也很喜欢这种做法，因为他们能销售升级系统。但是大多数公司都忍不住在兴建新系统时加入新功能，他们并不想让新系统只有原本的功能，致使系统升级的过程变得更加复杂。过去就像现在一样，很多升级过程的截止日期都非常紧。应当得到替换的系统已经开始失灵，新系统却迟迟无法就位。针对千年虫进行基础测试很容易，可以将系统日期设定为2001年，也可以将其设定为1999年12月31日，并使其滚动到2000年1月1日——如果你胆量足够大，敢用自家的关键系统这样尝试的话。

二十世纪九十年代，千年虫问题开始冒头。澳大利亚西部的一家炼铝厂在1996年这个闰年的年底因为我刚才解释过的原因出了问题，致使这家炼铝厂发生了严重事故。工厂的计算机系统强行关闭，致使设备受到了无法修复的损坏。在新西兰有一家配置完全一致的炼铝厂，万幸的是他们在遇到这一天的同一时刻之前得到了消息，并且小心且有序地关闭了系统，躲过了同样的问题。克莱斯勒公司的斯特灵高地工厂进行了日期滚动测试。用克莱斯勒公司董事长的话来说：“我们经历了很多意外。”工厂的安保系统隔绝了内外，工资发不下去，最后工厂不得不暂时关门。尽管大多数公司投入了大量努力来改善自己的系统，但还是有人中招。1999年底，瑞卡尔电子公司制造的信用卡读卡器普遍失灵，很多使用这款读卡器的商店都因为无法处理收付款而蒙受损失。零售业声称总共损失达到了500万美元。这起事故还导致了进一步的诉讼。我没能发现诉讼和解金额是多少，大概没有公开。

那么我们提前发现并且防住了哪些事故？英国的防空导弹系统得到了及时修复，否则也会失灵。瑞典的一座核电站在夏天进行测试并且关闭。如果发生在1月关闭的话问题会更大，因为那时候天气更冷，需要更多电力。伦敦千年穹顶也要接受千年虫合规监测，千禧年之交的时候千年穹顶下面计划举行一场大型跨千年庆祝活动，很多贵宾都会到场。这场活动在政治上非常敏感。当他们第一次进行测试时，系统故障的警报信息弹出速度如此之快，以至于在屏幕上只能看到无数提示框闪过然后消失。面对如此之多的问题，他们只得召集了一支大规模团队。有些为我工作的顾问曾经帮助过英国石油公司应对千年虫。英国石油公司后来宣称，在我的团队找到的所有问题当中有一个问题如此严重，以至于找出这一个问题所挽回的损失就值得整个千年虫合规项目的开销，因为这一个错误如果得不到纠正将会影响世界各地所有安装了这套系统的钻井平台。130万张visa卡原本会出问题，升级之后就不会了。商务系统当中的大量漏洞被揭露出来得到了解决。这种项目的规模历来十分浩大。在欧洲，仅仅为了让通用汽车这一家公司实现千年虫合规，德勤就租用了一座飞机棚充当办公场地，购买了好几百台个人计算机，包圆了好几家当地酒店来容纳工作团队，项目规模堪比动员一只小规模军队，仅仅为了应对这一位客户的问题。

那么在千禧年过后情况又怎样？好几年以来我一直在主持世界范围内的千年虫项目。我大约在1997年离开德勤，然后成为了国家空中交通服务/NATS的最高级审核员。我审核了NATS开展的所有旨在查缺补漏的千年虫项目。当然这是一份非常有趣的工作，让我有机会造访了各种有趣的地方。但不幸的是，2000年1月1日凌晨4点，英国所有机场的跑道视程系统——其作用是计算机场空域的可见距离——还是闹起了千年虫。问题本身并不大：跑道视程系统原本会定期呼叫主计算机进行健康检查，那天早上4点系统发现两边的时间没有对齐，于是就自行关闭了。当初是为了安全才这样设计的。这次事故好在没有导致任何严重后果，因为当时天上没有人。实际上NATS有一支别动队专门监控英国空域的各种活动，他们在1999年12月31日晚上就接到了苏格兰空管局的电话，对方表示他们的雷达失灵了，因为他们收不到来自任何飞机的通话。事实表明，这是因为当天晚上英国上空一架飞机都没有，显然人们不约而同地决定他们不打算在千禧夜飞行，所以雷达自然什么信号都接收不到。

大量系统失灵都被直接上报给了千年虫协调中心。我在讲座的文字稿当中列举了25到30个例子，这里我简要介绍其中几个。全球共有15家核电站关停；许多信用卡被拒收；尤穆尔塔勒克的油泵全部关停，切断了伊斯坦布尔的油料供应；夏威夷停了电；克林姆林宫新闻办公室没法发送任何电子邮件；不少人的贷款被征收了足足一百年的利息，少数人的存款则接收了一百年的利息——可以想见后者的问题比前者更快得到了银行方面的解决；新西兰的某家自动化广播电台循环播出11点新闻，将其当成了距离眼下时间最近的节目，因为0显然比11更小；英国的出生证明将年份印成了1900。各种各样类似这样的问题纷纷出现，有些问题相当严重，有些问题无非是细枝末节。这些例子一方面表明了我们究竟修复了多少问题，同时也表明了我们究竟错过了多少问题，以及如果我们的补救措施没有生效的话情况究竟会多么严重。

那么为什么情况不像我们恐怕的那么严重？首先，我们发现并且修正了大量的错误，数量非常巨大。我认为首先要非常感谢从业者的辛勤付出，他们完成了一项了不起的任务，而且的确发现了大量原本会发生的错误。我们曾经非常担心串联式的多米诺式故障瘫痪整条供应链，这种故障同样没有发生。一方面因为重要的供应链往往由大公司来经营，而他们应对千年虫问题的方式往往最为专业，因为他们有足够的资源并且面临巨大的风险，所以并不意外的是，他们对这个问题的处理最为认真。另一方面也因为供应链并不像我们所害怕的那么严密耦合，其中存在很多结构性冗余，一家公司出问题未必就一定会造成连带效应，我接下来还要进一步讨论这一点意味着什么。

当时有些人觉得，某些在千年虫项目方面落在后面的国家似乎并没有出现大问题，这意味着领头的问题一定在浪费钱，既然投入没这么多的国家也糊弄过去了，那说不定我们原本也能糊弄过去。这种推理站不住脚。实际上许多走在前列的公司首先驱使供应商下大力气升级了许多广泛使用的系统，使得许多落后公司可以搭便车。第二，许多咨询公司与工具公司构建了许多自动化工具。在二十世纪九十年代初期到中期我们估算过，要想让一个使用 COBOL语言的商务程序实现千年虫合规，所需要的每一行代码的成本是一到二美元。这笔开销相当可观，因为大一点的软件动不动就需要几十万行代码，小型软件的代码规模也在几万行。我们原本预测，因为员工短缺，代码价格会上升到每行四美元。但实际上代码价格却极大地下降，达到了每行40美分左右，因为自动化工具可以完成大量分析与修复工作，起到了很大的帮助，也使得后来者能够追上。

话又说回来，千年虫的威胁确实在一定程度上遭到了夸张。一方面是为了提升人们的危机意识，因为除非你大鸣大放，否则人们根本就不会动弹一下。另一方面，当时确实有很多公司打算做系统升级的生意，他们经常拒绝为客户签署千年虫合规审核书，哪怕客户的系统根本没有内置日历，根本不关心当前是哪个世纪，从来都没有人向系统输入日期，所以从一开始就闹不出日期错误，比方说暖风机以及空管中心的备用大型柴油发电机。咨询公司与设备供应商一度曾经试图说服NATS相信这些设备也会失灵，这纯属胡说八道。整体来说这种情况的发生概率很小，但是发生的次数确实足够多，因此确实为“千年虫是个大骗局”的说法提供了一点事实基础。无论赶上什么风口，总难免有人想要趁机赚钱。再然后还有些人为了另外的盘算而炒作千年虫。我们一开始就提到有人为了政治或者宗教原因而炒作千年虫恐慌。因为他们想要为自己的组织获得头条关注。因此千年虫的严重程度确实遭到了一定程度上的夸张，但是实际上千年虫也确实构成了全球范围的威胁，而我们也动员了相应的努力加以应对并且花费了很多钱。

应对千年虫的代价多么大？很大。不过并不是所有扔进去的钱都被浪费了。有些投入确实带来了长期收益。印度的软件行业基本上就是乘着千年虫的东风创建起来的。二十世纪九十年代初的时候，印度并没有多少著名软件公司。到了九十年代末期，印度已经创建了好几家价值几十亿美元的跨国公司，这些公司起家创业靠的都是千年虫。对于印度的软件外包公司来说，千年虫可谓是最完美的业务：他们有很多非常聪明的员工，而且这些人很乐意一遍又一遍地完成常规的无聊工作。因此印度软件业经历了一轮爆发式增长。换句话说，西方软件行业因为千年虫而丧失了一大块竞争优势。话说回来，我们进行了很多升级，运行了很多服役周期更长的新系统，因此并非所有的努力都是白费。各家公司肯定也更加深入地了解了自家软件，到哪里寻找源代码，以及进一步控制与监督IT系统的重要性。他们意识到了IT系统对于公司运营多么重要。所以千年虫项目确实产生了一些确实的好处，并非全都是浪费钱。

我们学到了什么教训？千年虫问题的核心在于低劣的软件工程学。如果程序员在写程序的时候使用了例如抽象编程、信息隐藏以及面向对象编程之类的技术——这些技术早在二十世纪六十年代末就已经出现了——那么日后修改日期格式肯定非常容易，不至于产生大量严重问题。我们并没有学会这项教训。大多数软件依然写得非常糟糕。我希望你们都来听我下一次讲座，主题是怎样编写在构建层面就正确的软件。因为我们确实可以一次性写好正确的软件，而且有显著证据表明与我们目前的做法相比这样做更便宜——这里所谓的更便宜指的是在研发阶段就更便宜，至于长期运作的成本就更不用说了。有些公司正在这样写软件，并且愿意提供绝对免费的售后纠错维护，以防万一。这是计算机行业并没有学会的教训，或许下个月的讲座可以让人们意识到这一点。

另一个主要问题在于测试依然是人们试图确定软件是否运作正常的主要方式。可是几十年的经验告诉我们，大多数缺陷都不可能在实际的测试时间之内得到发现。我们真正应当学会的教训在于必须避免单一故障点，以免一处缺陷导致大量系统同时发生故障。但是我们并没有学会这一课。我们现在有了GPS，这也是一个单一故障点，世界上几乎所有国家的整个经济都要依靠这套体系。GPS的用途非常广泛，不仅用来定位，还用来计时与导航等等——这个问题我能讲一个小时，总之这是极大的风险。很多其他方面的情况也一样，比如开源数据运动旨在让数据集广泛可用，但是没有人监管这场运动，没有人试图确定究竟是谁正在使用这些数据，而这些数据集对于所有使用它们的人们来说正是单一故障点。如果这样的数据集足够多，而且人们与这些数据集互动方式是错误的，那么一旦这些数据集被败坏就可能会导致非常严肃的问题。软件也是同样的情况，最近的例子就是SSL的心血漏洞。太多的人们都在使用同一套开源软件模组，如果某一个模组是错的，如果有人在某个模组添加了木马代码或者犯了极大的错误，那么许多系统都会以很多意料之外的方式失灵。冗余是重要的保险措施，但是当前的供应链却奉行准时制无库存原则。研究商业流程与设备的价值工程师们正在竭力挤出系统当中的冗余从而降低成本，同时也剥夺了供应链自带的保险机制。我们需要非常小心地评估冗余带来的保险，因为千年虫升级之后我们的系统现在耦合得更加紧密了，而我认为我们并没有充分评估这一点带来的风险。

千年虫问题表明，我们确实可以非常高效地通过正式或者非正式的监管方式将很多人组织起来。我们现在并没有使用这种方式来解决网络安全或者软件质量低下问题的政治胃口，我觉得很可惜。我们本应学会，确实有可能动员协调一场国际运动来解决某个影响所有人的复杂问题。我认为千年虫并不是骗局，我一开始说过这是一次勉强躲过去的灾难，我们应当从中学到恰当的教训。今天的威胁要比当年更大，因此尽管我们并不像之前那样面临确定的截止日期，也很难指定足以导致大量系统失灵的特定威胁，但是系统的脆弱性确实正在累积，因为我们正在编写很多不够好的软件，每一年这个问题的规模都在增大。一开始我说过，当你们听说千年虫的时候都说：“我们不该相信专家。别拿着气候变化什么的太当回事，还记得千年虫那时候吗？还记得2000年吗？”是的，我们确实应该记得2000年。你们觉得我们应该从2000年学会什么教训呢？谢谢大家。

连着7个星期跑了七个城市。至今记忆犹新，年轻时还是熬得住的。

只得跟着外标公司将数据转换过去，然后单位倒闭了，那时的确够酸爽的。