程序开发者去世，代码没人懂，一个bug导致千万损失

系统出故障了。当年负责写这个程序的开发者早在十五年前就去世了，现在已经没有人能读得懂他的代码了…
现在一些关键系统的运行仍依赖于过时的软件，但编写他们的人要么离职要么已经去世。中间也缺少维护或更新，导致现在几乎没人能理解它们，而且一旦出现 Bug 就会给企业造成不可挽回的损失。
而现实中的这种例子，远比你想象中的要多。
一个令人深思的故事
我的一位客户负责数项世界排名前一百的养老基金，该公司在前几个月成功的将程序搬到了云端。作为项目的主任架构师，前两天我很意外地直接收到了 CIO 的短信：“抱歉打扰，我们出 S1X 级的大问题了。你能下午飞过来吗？”。

“S1X”是他们对“比最严重级别还要糟，级联影响到业务其它非直接相关部分”问题的定义。
事情看起来十万火急，当天晚上我就飞到现场进行了诊断，发现是该客户的系统中一个批处理任务发生了崩溃。
该任务每天晚上执行一次，通过写一个 CSV 文件为某些养老金计算缴费率，再将计算的结果输出到另一个收益（benefit）分配程序。原先收益分配程序设定为在缴费（contribution）低于预测（projection）时会向客户发出报警。由于上一个处理任务已发生崩溃，不再产生输出，因此程序认为“所有缴费为零”。
所以系统立即向该养老基金的经理们发出大量警报邮件，基金经理们被吓得赶紧从该项目里撤离了。
起初没有人找得出问题发生在哪里，在大家的记忆和工作记录中，这个批处理任务也从未崩溃过。编写该批处理程序的人已经在 15 年前离世了，并且数十年前就不再是该企业的员工了。尽管该批处理的程序代码规模不大，但非常难读。因为在编程时主要考虑的是提高计算效率，并未考虑如何适合他人阅读。当然，程序也没有留下任何测试。
事故发生的前一天，脚本在运行环境中的编排发生了一次更改。这被认为是导致事故的罪魁祸首。幸运的是，这个更改做了版本 push，工程部门据此回溯到先前的版本。但不幸的是，这只使事情变得更糟。
最后我们通过提供热修补脚本的方式解决了这个问题。但实质上这次崩溃已经给该基金造成了 170 万美元（约 1203 万人民币）的直接损失。