老技术栈的系统，维护成本怎么算

一套五六年前做的系统，现在每年维护费两万，看起来挺划算。真算总账，可能花的比新建一套还多，只是成本分散在各个地方，不集中，不容易看见。

把隐性成本摊到明面上，才能判断是继续维护还是该换。

一、人员获取的难度

技术栈越老，会的人越少。原来做这套系统的开发人员如果都转行了，要找人维护就困难。能找到的人往往报价更高，因为他们可选的项目多。

更麻烦的是，有些技术栈已经停止更新，出一份新系统装不上，依赖的组件下载不到。这种情况下的维护，有时不是钱的问题，是根本找不到人来接。

评估方法很简单，问开发方这套技术栈现在招人好不好招、公司里还有几个人在写。如果答案是不太好招、只有一个，那就该警惕了。

二、改动成本是不是在变高

老系统通常有这样几个特征，没有文档、代码结构乱、改动要连带改很多地方。结果就是同样一个需求，在老系统上做需要的工时比新系统多好几倍。

可以做个对照。拿最近半年做的几个需求，看看实际耗掉的工时，再评估如果在新的技术栈上做同样的功能需要多少。比值超过三倍，说明改动成本已经很高。

还有一个信号是改动引发的新问题。改了一个地方，别的地方坏了，测试要覆盖的范围越来越大。这说明系统内部的耦合太重，已经不适合继续小修小补。

三、安全风险的成本

老系统用的组件版本旧，已知漏洞大概率没有修复。如果系统不联网，风险相对可控。如果对外提供服务或者能访问互联网，风险就很实际。

这类成本平时不显，出事的时候很大。数据泄露、系统被入侵、被用来发起攻击，处理起来的经济和声誉成本远超维护费用。

评估的时候看两点。系统能不能从外部访问，系统里有没有敏感数据。两点都符合，安全升级就不该再往后拖。

四、什么时候该重构，什么时候还能扛

可以按下面几条判断。如果只是版本旧、功能稳定、改动很少、不对外网开放，继续维护是合理的，成本可控。

如果出现了这几种情况，就要认真考虑重构。改动成本持续上升且没有改善的可能。找不到人维护或者维护方明确提出不再支持。有安全风险且无法通过打补丁解决。业务要发展，老系统的结构支撑不了新需求。

重构不等于推倒重来。常见做法是逐步迁移，把老系统里的模块一个个挪到新架构上，两个系统并行运行一段时间，迁移完一个切换一个。这样做的优点是风险分散，业务不会因为重构停下来。缺点是过渡期需要维护两套系统，成本会一段时间内上升。

无论走哪条路，第一步都是先把老系统的真实成本算清楚。算不清楚，讨论该不该重构是没法得出结果的。