程序开发者逝世代码没人懂一个bug导致千万丢失

作者丨Rajiv Prabhakar

译者丨盖磊

策划丨田晓旭、Tina

体系出毛病了。当年担任写这个程序的开发者早在十五年前就逝世了，现在现已没有人能读得懂他的代码了......

现在一些要害体系的作业仍依靠于过期的软件，但编写他们的人要么离任要么现已逝世。中心也短少保护或更新，导致现在简直没人能了解它们，而且假如呈现 Bug 就会给企业形成不行拯救的丢掉。

而实际中的这种比如，远比你幻想中的要多。

一个令人深思的故事

我的一位客户担任数项国际排名前一百的养老基金，该公司在前几个月成功的将程序搬到了云端。作为项意图主任架构师，前两天我很意外地直接纳到了 CIO 的短信：“抱愧打扰，咱们出 S1X 级的大问题了。你能下午飞过来吗？”。

“S1X”是他们对“比最严峻等级还要糟，级联影响到事务其它非直接相关部分”问题的界说。

作业看起来十万火急，当天晚上我就飞到现场进行了确诊，发现是该客户的体系中一个批处理使命发作了溃散。

该使命每天晚上履行一次，经过写一个 CSV 文件为某些养老金核算缴费率，再将核算的效果输出到另一个收益（benefit）分配程序。原先收益分配程序设定为在缴费（contribution）低于猜测（projection）时会向客户宣布报警。由于上一个处理使命已发作溃散，不再发作输出，因而程序以为“一切缴费为零”。

所以体系当即向该养老基金的司理们宣布许多警报邮件，基金司理们被吓得赶忙从该项目里撤离了。

起先没有人找得出问题发作在哪里，在咱们的回忆和作业记载中，这个批处理使命也从未溃散过。编写该批处理程序的人现已在 15 年前离世了，而且数十年前就不再是该企业的职工了。尽管该批处理的程序代码规划不大，但十分难读。由于在编程时首要考虑的是前进核算功率，并未考虑怎么合适别人阅览。当然，程序也没有留下任何测验。

事端发作的前一天，脚本在作业环境中的编列发作了一次更改。这被以为是导致事端的元凶巨恶。走运的是，这个更改做了版别 push，工程部分据此回溯到从前的版别。但不幸的是，这只使作业变得更糟。

终究咱们经过提供热修补脚本的办法处理了这样的一个问题。但实质上这次溃散现已给该基金形成了 170 万美元（约 1203 万人民币）的直接丢掉。

“数据溃烂”（Bit Rot）问题

实际上相似的故事并非孤例。我在 2012 年脱离英特尔参加 Sun 公司，切身体会到他们的 SPARC 产品线做得是多么的糟糕。Sun 在互联网泡沫年代的饮鸠止渴行为，导致尔后 SPARC 远远落后于英特尔的至强产品线。

我的司理都和我说，要在英特尔至强服务器上作业模拟程序，由于 SPARC 服务器“十分慢”。更严峻的问题在于，英特尔不只 CPU 功用更好，而且具有制作优势，这在某种程度上预示着 CPU 的制形本钱也大幅度的下降。

随之而来的问题很明显：已然远远落后于竞争对手，那么为什么客户仍是会购买咱们的 SPARC 芯片？一位高档架构师向我给出了令人震惊的答案。那是由于咱们的客户的软件体系过于死板，只能在 SPARC/Solaris 体系上作业。而迁移到 x86/Linux 对客户而言是一项艰巨的使命。许多客户乃至丢掉了源代码，无法从头编译运用。

他们能做的最好挑选，便是升级到最新一代的 SPARC 处理器，不管这样的处理器功用多慢，价格多么贵重。

这便是问题所在。咱们整个部分的事务形式，彻底围绕着这个国家中那些溃烂的软件体系。

坚持作业的价值

我参加 Amazon 后，发现了自己面临正是这样一个为留传体系而构建适用的原型。该体系是另一个团队根据许多技能债款开发的，而且团队早已闭幕。之后该项意图一切权就移送给咱们的团队……实际操明，这并非揽下一件功德。所以开发人员陆陆续续换岗到其他的团队。我参加时的十多名团队成员中，一年后一位都没有留下。

该体系从表面上看并非一无可取。它运用了现代编程语言和技能栈（Java 8）编写，由拿着六位数收入的开发人员所组成的团队进行着日常保护，并不断更新以修正过错和增加新功用。尽管如此，测验修正（turnover）依然是连累整个体系的明显担负。一切权改动和团队替换导致全体代码规划、端到端功用、最佳实践和调试技能等许多实操常识的丢掉。尽管咱们一向尽力坚持项意图推动，但感觉就像进入了一片沼泽地，四处亡羊补牢，深陷战役迷雾（Fog of War）中。

想象一下，一个作业在第一版 Java 上的项目，开发活动简直为零，没有开发人员担任。还有比这更糟的项目吗？

怎么防备发作灾难性毛病

软件开发人员致力于构建强健、无过错的体系，无需过多人工保护就能正常作业多年。据此规范，上面所说的养老金脚本无疑是十分成功的项目。

可是实际很严峻，再好的项目有发作溃散的一天。终究，一切内容都需求做更新。导致原因或许是：

体系作业所根据的硬件体系停产了。

体系的依靠联系不再可用。

依靠联系中呈现了严峻安全漏洞，而仅有可用的安全补丁仅适用于并不后向兼容的版别。

运用开发根据一些已不再树立的假定。

乃至是整个国际发作了改动，软件必需因势而变。

不管出于何种原因，改动都是不行防止的。仅有的问题是，当终究需求改动时，它的价值有多大。

关于一个活泼保护的体系，改动就不会那么苦楚。可是，关于一个已有几年乃至数十年没有保护的体系，那么许多要素都或许会导致灾难性的过错。例如：

构建体系的开发人员现已离任。

源码丢掉。

开发人员不了解怎么正确地编译源码，并构建可履行文件。

开发人员不了解怎么布置体系。

开发人员不了解怎么正确地装备作业可履行文件。

开发人员对代码的架构和完成一头雾水。

开发人员不了解使代码功用正常运作所依靠的常量和隐含假定。

开发人员不了解怎么作业自动化测验。

开发人员不了解怎么调试测验问题。

开发人员不了解怎么调试出产毛病。

开发人员不了解怎么获取出产日志和目标衡量。

一种处理方案是对上述问题做尽量具体的记载。但文档并非最优的处理方案，由于其间不免会有遗失。再全面的文档，也比不上自己亲自动手操作。

抱负的做法

一个好的初步，便是企业指定专门的开发人员全面担任上述一切问题。但这还不行。

假如只是重复“阅览文档”，那么就会发作厌恶。人们并不能从中取得实践经验，从而处理实际问题。

假如加上“绩效审阅”，那么人们更倾向于新的出彩项目，很有必定的概率会简略地抹去并掩盖旧的问题，乃至直接从中除掉问题。假如没有真实面临的可交给效果或应战，许多人自然会挑选一条最轻松的路途。

真实要想防止软件发作溃烂，仅有的办法是保证项意图继续推动，即便看起来毫无必要，或是存在危险。树立、保护和验证明操常识和才能的最佳办法，便是不断做出改动，并测验这些改动是否能成功地履行。一旦项目中止推动，那么相关实操常识就会过期和消解。

即便原地打转听上去很可笑，但这对疏于保护而言仍是一种前进。实际上，保护人员总是能够做一些作业完成向前推动，尽管脚步或许很小。

一种做法是运用一切依靠联系的最新版别去更新开发环境，例如：

从 JDK 8 迁移到 11。

更新 JVM，运用 G1 废物收回机制代替原先的 CMS。

将 GCC 编译器从版别 5 更新到 7。

将数据库从 Postgres 9.5 更新到 Postgres 11。

将 AWS SDK 从版别 1.10 更新到 1.11。

在出产环境中装置最新的 Linux 发行版。

在一些情况下，依靠联系会过期。这时就需求细心考虑全体迁移到新的架构。例如：

从 SPARC 迁移到 x86；

从 Solaris 迁移到 Linux。

相同，坚持开发人员的战斗力，可对运用做如下更新：

修正恶疾和一些边际用例。

加固自动测验套件。

整理技能债款。

做功用优化。

完成新特性。

增量重构代码库，改善可读性。

上述改变势必会带来暂时性危险，并发作看似“不必要的”开销。开发人员不免会犯一些过错，乃至引进新的过错。面临这些价值时，人们很简单退而求其次，以为“假如还没有决裂，就不要修正。”

关于一个事务价值不大的体系，这或许是合理的做法。但关于任何要害使命体系而言，疏忽问题将仅会掩盖较小的瞬态危险，而没有处理永久的灾难性危险。一旦有一天需求紧迫调试或更新体系，那么企业将莫衷一是。

关于任何要害使命体系，至关重要的便是坚持实操常识和才能。做到这一点的仅有办法，便是不断地展开实操。企业的大脑和肌肉相同，不运用，就会失效。

作者简介

Rajiv Prabhakar，结业于密歇根大学和斯坦福大学，之后曾在 Intel 和 Sun Microsystem 公司作业五年，参加了 Jaketown、Skylake 和 SPARC 规划团队。之后转向软件相关作业，先后任职于 Amazon、Google、Engineers Gate，并数次自己组成创业公司。

参阅阅览：

https://software.rajivprab.com/2020/04/25/preventing-software-rot/

为你引荐

InfoQ Pro是 InfoQ 专为技能前期开拓者和乐于研究的技能探险者打造的专业媒体服务渠道。