理解技术债务

摘自维基百科：“技术债务（也称为设计债务或代码债务）是“编程中的一个概念，它反映了当采用短期内易于实现的代码、而非应用整体最佳方案时所产生的额外开发工作”。

技术债务可以与货币债务相类比。如果技术债务得不到偿还，它就会累积‘利息’，使得日后实现变更变得更加困难。未予处理的技术债务会增加软件熵。技术债务未必是坏事，有时（例如，作为概念验证）为了推进项目前进，技术债务是必需的。另一方面，一些专家声称，“技术债务”这一隐喻往往会淡化其影响，从而导致对纠正它所必需的工作给予的优先级不足。”

技术债务这一概念源自软件工程领域，但它同样适用于 IT 与企业基础设施领域。与软件工程一样，我们设计自己的系统和网络，而在设计中走捷径，包括采用不够理想的设计、纳入现有硬件以及其他糟糕的设计做法，都会产生技术债务。其中一种较为显著的形式来自于投资于“过去”而非“未来”，并且往往是由沉没成本谬误（即在错误的投入上继续追加投入）所引发的。

每天都能轻易在企业中看到这种情况的发生。人们为未来制定了新的计划，但在计划付诸实施之前，又投入资金让一个旧系统设计继续运转、运转得更好、扩容或诸如此类。这笔投资随后要么几乎立即变成财务损失，要么更常见地成为一种诱因，使人们不再那么迅速、那么彻底，或者根本不去投资于面向未来的设计。在最糟糕的情况下，对过去的投资可能会变得令人难以承受。

这种情况以多种方式发生，并且通常并非有意为之。往往需要投入资金来保持现有系统正常运行，在通常情况下，这笔投入本就理应进行。但在存在一项需要进行或可能已规划好的未来变更的情形下，这笔投入就可能成为问题。不过在许多情况下，更好的成本分析和分流规划可以弥补这一点。

举一个非技术性的例子，设想你拥有一辆较旧的汽车，它一直表现良好，但三个月后就到了该报废的时候。三个月后你打算投资购买一辆新车，因为由于持续的维护需求、更低的效率等等，旧车已不再划算。但在你三个月的购车计划到来之前，旧车发生了一次小故障，如今需要一大笔投入才能让它继续运转。把钱投到旧车上将是对技术债务的一笔新投资。与其花一大笔钱让旧车再多跑几个月，不如把购买新车的时间表提前，这显然在财务上要稳妥得多。对于汽车，我们能够轻易看清这一点（在大多数情况下）。通过迅速购买新车，我们省下了钱，可能还是一大笔钱。如果我们在旧车上大举投入，要么过几个月就损失了这笔投资，要么我们冒着打乱原本已经做好的购买新车的稳健财务规划的风险。这两种情况在财务上都很糟糕。

IT 的运作方式与此相同。在计划迁移到托管式电子邮件系统之前六个月，却花一大笔钱来维护一个旧的电子邮件系统，很可能是非常愚蠢的。当旧系统退役时，这笔投资要么几乎立即损失掉，要么它会破坏我们良好的规划流程，导致我们不按计划进行迁移，从而因为我们让技术债务而非恰当的规划来主导决策，而给我们的企业做了一份次优的工作。

糟糕的分流操作，或者赋予分流相关人员的权限不当，往往会成为促成应急性技术债务投入、而非迅速面向未来投入的因素。这只是重大改进可能解决问题的一个领域，但却是一个重要的领域。在某些情况下，这也可以通过“假设”式规划来加以缓解，即针对可能出现的常见或预期的紧急情况，预先制定好相应的投资预案，这或许简单到只是因增长而产生的、在系统规划介入之前就发生的扩容需求。

另一个常见技术债务的绝佳例子是服务器存储容量扩展。这是我相当频繁见到的一种情形，很好地体现了技术债务。企业购买缺乏大容量内部存储的服务器是很常见的。要么立刻、要么在日后的某个时候，就会需要更多容量。如果这种需求立刻出现，我们就能看出所购买的服务器是设计不当所导致的一种技术债务，显然代表了规划和采购过程中的一个缺陷。

但更常见的例子是在服务器购入两三年之后才需要扩展存储。常见的扩展选择包括添加一个外部存储阵列连接到服务器，或者改造服务器以容纳更多本地存储。这两种做法往往都是对一台本已陈旧的服务器进行的大笔投资，而这台服务器很容易已经走过其有效使用寿命的百分之四十甚至更多。在许多情况下，用相同或仅略高的投入购买一台全新的服务器，就能换来全新的硬件、更快的 CPU、更多的 RAM、所需的存储，而且是专门设计和构建、相互匹配并刷新的支持周期、更小的数据中心占用空间、更低的功耗、更新的技术和功能、更好的厂商关系等等，与此同时还能保留原有的服务器以供重新利用、退役或转售。一种方式是花钱支持过去，另一种方式往往能以相当的资金投资于未来。

技术债务对许多企业来说是一个令其难以承受的因素。它会增加 IT 的成本，有时增幅可观，并且可能由于缺乏规划、大多数支出都基于应急而导致高水平的风险。