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

作者丨RajivPrabhakar
译者丨盖磊
策划丨田晓旭、Tina
系统出故障了 。 当年负责写这个程序的开发者早在十五年前就去世了 , 现在已经没有人能读得懂他的代码了......
现在一些关键系统的运行仍依赖于过时的软件 , 但编写他们的人要么离职要么已经去世 。 中间也缺少维护或更新 , 导致现在几乎没人能理解它们 , 而且一旦出现Bug就会给企业造成不可挽回的损失 。
而现实中的这种例子 , 远比你想象中的要多 。
一个令人深思的故事
我的一位客户负责数项世界排名前一百的养老基金 , 该公司在前几个月成功的将程序搬到了云端 。 作为项目的主任架构师 , 前两天我很意外地直接收到了CIO的短信:“抱歉打扰 , 我们出S1X级的大问题了 。 你能下午飞过来吗?” 。
「InfoQ」代码没人懂,一个bug导致千万损失,程序开发者去世
文章图片
“S1X”是他们对“比最严重级别还要糟 , 级联影响到业务其它非直接相关部分”问题的定义 。
事情看起来十万火急 , 当天晚上我就飞到现场进行了诊断 , 发现是该客户的系统中一个批处理任务发生了崩溃 。
该任务每天晚上执行一次 , 通过写一个CSV文件为某些养老金计算缴费率 , 再将计算的结果输出到另一个收益(benefit)分配程序 。 原先收益分配程序设定为在缴费(contribution)低于预测(projection)时会向客户发出报警 。 由于上一个处理任务已发生崩溃 , 不再产生输出 , 因此程序认为“所有缴费为零” 。
所以系统立即向该养老基金的经理们发出大量警报邮件 , 基金经理们被吓得赶紧从该项目里撤离了 。
起初没有人找得出问题发生在哪里 , 在大家的记忆和工作记录中 , 这个批处理任务也从未崩溃过 。 编写该批处理程序的人已经在15年前离世了 , 并且数十年前就不再是该企业的员工了 。 尽管该批处理的程序代码规模不大 , 但非常难读 。 因为在编程时主要考虑的是提高计算效率 , 并未考虑如何适合他人阅读 。 当然 , 程序也没有留下任何测试 。
事故发生的前一天 , 脚本在运行环境中的编排发生了一次更改 。 这被认为是导致事故的罪魁祸首 。 幸运的是 , 这个更改做了版本push , 工程部门据此回溯到先前的版本 。 但不幸的是 , 这只使事情变得更糟 。
最后我们通过提供热修补脚本的方式解决了这个问题 。 但实质上这次崩溃已经给该基金造成了170万美元(约1203万人民币)的直接损失 。
“数据溃烂”(BitRot)问题
事实上类似的故事并非孤例 。 我在2012年离开英特尔加入Sun公司 , 切身体会到他们的SPARC产品线做得是多么的糟糕 。 Sun在互联网泡沫时代的杀鸡取卵行为 , 导致此后SPARC远远落后于英特尔的至强产品线 。
我的经理都和我说 , 要在英特尔至强服务器上运行模拟程序 , 因为SPARC服务器“非常慢” 。 更严重的问题在于 , 英特尔不仅CPU性能更好 , 而且具有制造优势 , 这意味着CPU的制造成本也大大降低 。
随之而来的问题很明显:既然远远落后于竞争对手 , 那么为什么客户还是会购买我们的SPARC芯片?一位高级架构师向我给出了令人震惊的答案 。 那是因为我们的客户的软件系统过于僵化 , 只能在SPARC/Solaris系统上运行 。 而迁移到x86/Linux对客户而言是一项艰巨的任务 。 许多客户甚至丢失了源代码 , 无法重新编译应用 。
他们能做的最好选择 , 就是升级到最新一代的SPARC处理器 , 无论这样的处理器性能多慢 , 价格多么昂贵 。
这就是问题所在 。 我们整个部门的业务模式 , 完全围绕着这个国家中那些溃烂的软件系统 。
维持运转的代价
我加入Amazon后 , 发现自己面对正是这样一个为遗留系统而构建适用的原型 。 该系统是另一个团队基于大量技术债务开发的 , 并且团队早已解散 。 之后该项目的所有权就移交给我们的团队……事实操明 , 这并非揽下一件好事 。 所以开发人员陆陆续续跳槽到其他的团队 。 我加入时的十多名团队成员中 , 一年后一位都没有留下 。


推荐阅读