我们来谈一谈一个显而易见却没人愿意讨论的问题（不是 Apache Hadoop）——技术债务。
在开发产品过程中,实际上从第一行代码开始，团队就已经开始累积技术债务，只不过有些团队会比其他团队积累得更快。技术债务的问题十分普遍，以至于人们开设了一个专门讨论该话题的国际会议——techdebtconf.org
什么是技术债务？
在深入探讨技术债务的管理策略前，我们应该明确它究竟是什么。
你也可以通过排除法来对它下定义。这篇写得很棒的Plutora 文章就总结了人们对技术债务存在的一些误解。似乎有人将技术债务与 bug 和糟糕的代码编写（完全是为了之后再做调整）混为一谈。这两者都不是技术债务。
那么它究竟是什么？我们首先从维基百科给出的简单定义开始：“技术债务是软件开发中的概念，它反映了开发人员选择简单（有限）的解决方案而非更好但更耗时的方案导致额外返工的隐含成本。”
马丁·福勒 (Martin Fowler) 在他的文章中给出的另一个定义是：“软件系统很容易积累残留工作，与理想情况不同，这种内部质量缺陷使得进一步修改和扩展系统更为困难。技术债务是沃德·库宁汉姆 (Ward Cunningham) 给出的比喻，它定义了如何看待处理这些残留工作的方式，即将其视作财务负债。增加新功能时所需的额外投入则是为债务支付的利息。”
无论是维基百科的定义，还是沃德·库宁汉姆所作的比喻，关键信息都十分清晰。
你可以这样想：债务就是贷款并产生了利息。当我们讨论技术相关的债务时，通常是指里程碑的实现（比如软件版本发布），也就是贷款，以及推迟的返工，（为增加之前略过的功能编写代码），也就是利息。技术债务不仅仅是与编写正确的代码相关（尽管代码复杂性是技术债务的一种主要类型）。债务也可能是由配置差距、定义或需求差距、低测试覆盖率、缺少文档、旧的遗留技术（可能是库、框架、甚至编程语言）等等因素导致的。这篇 DZone 文章详细解释了其中一些类型。
无论其原因或类型，与货币债务无异，技术债务会随着时间的推移产生利息，偿还成本也因此越来越高。
一些相关数据
技术债务是否比较罕见？绝非如此。事实上，技术债务问题十分普遍。麦肯锡的调查数据显示，“新产品的技术预算中有 10% 到 20% 都用来解决与技术债务相关的问题”。
从时间维度来看，技术债务依然是普遍问题。根据 Stripe 的数据，“工程师们需要花费 33% 的时间来处理技术债务”，相当于每周约 13.4 小时的时间。
IT 领导人对该问题的看法也不太乐观。OutSystems 的一份报告指出，“多数 (69%) IT 领导人表示技术债务从根本上限制了他们的创新能力，61% 的领导人称技术债务拖累了公司业绩，并有 64% 的领导人认为技术债务问题将在未来继续产生重大影响”。
所以没错，这是个非常普遍的问题。现在我们评估一下技术债务的不良影响或潜在威胁（取决于如何看待这一问题）。
Stripe 估计技术债务对全球 GDP 造成的影响高达 3 万亿美元。
更具体一点，据 2021 年 CodeScene 的一份报告显示，因技术债务问题，普通公司平均损失 23-42% 的开发时间。这意味着，如果一家普通公司雇佣了 100 名开发人员，那么它只能实现 75 名开发人员的产出。相反，在为结清技术债务进行投资后，减少公司中的技术债务可有效增加 25% 或更多的产出。
Gartner 的研究也强调了这一潜在的可能性。“到 2023 年，积极管理和减少技术债务的基础设施和运营 (I&O) 领导人将能缩短至少 50% 的服务交付时间”。
ROI（投资回报率）的问题十分棘手，因为每个项目和结清技术债务所需的投资额以及实际回报都很难计算。
而且，如果能像其他债务一样记得还款，技术债务也不一定是坏事，因为它可以帮助你实现短期目标，比如更快地发布某个功能。这样，你就能更早收到客户反馈，这是非常有价值的。只需记住，技术债务是会增长的，因此必须尽早偿还债务，而不是拖延还款。
衡量技术债务
我可以继续解释为什么首先需要衡量技术债务。但我们还是有必要先总结一下：与其他问题一样，衡量是根本要求，因此非常重要。它可以帮助你了解哪些问题需要解决，哪些问题需要关注。彼得·德鲁克 (Peter Drucker) 的名言：“无法衡量也就无法改进”，在这次讨论中，我们也不难发现这一道理。
然而，衡量技术债务并不容易。虽然有技术债务比率（很快也会讨论），但可能有人会反驳并不存在唯一适用的衡量标准或公式。在某种程度上，由于每个公司管理风险的方式和优先级不同，各公司衡量技术债务的方式也截然不同。例如，有些公司会把 bug 数量、需要重构的代码、代码复杂性、违反编码规则当做可能的衡量标准，而有些公司则不会。
不过，衡量债务的一个常见基准线被称为技术债务比率 (TDR)：
技术债务比率 =（补救成本/开发成本）* 100%
补救成本是与构建软件产品相关的成本。一般来说，在计算技术债务比率时，由于软件产品已经进行开发并积累了技术债务，所以补救成本已是固定的成本。然而，在计算活跃项目期间的技术债务比率时，补救成本可能为一系列固定费用的组合，包括花费的时间、估计的成本、为项目分配的剩余时间等。对许多项目而言，这可以看作是沉没成本。
开发成本则更容易理解，它是指为解决债务问题开发代码所需的时间。开发成本的数值视债务的具体情况而异，一般是对代码量的衡量，此外也会因分配给工作的资源而有所不同，一般指开发人员数量。开发成本可以表述为开发 1 行代码的成本 * 代码行数
DevOps 能提供怎样的帮助？
尽管许多人称 DevOps 并不是解决技术债务问题的灵丹妙药，但 DevOps 在应对技术债务方面确实有一定作用。诚然，DevOps 的应用并不能帮助一家公司从根本上避免技术债务或累积债务利息。然而，DevOps 本身具备的一些优势确实能够提供相应的帮助。
DevOps（以及 CI/CD）就是自动化。在将一些耗时的任务或比其他任务更易出错的任务自动化后，你就能利用节省的时间偿还技术债务。CI/CD 过程中所体现的自动化，如自动化测试和自动化构建，有助于更早识别技术债务。相应的，这样又有助于持续偿还债务。那代码质量呢？自动化会严格执行质量标准，同样能够帮助减少技术债务。
沟通是 DevOps 能够提供帮助的另一个优势。许多 DevOps 公司会在运营日程中添加一个回顾性任务，例如在敏捷冲刺的最后阶段。这样便提供了一个有效的平台，对已经发生的技术债务进行编目和跟踪，并在债务影响露出苗头时，从一开始就与其他利益相关者团队沟通或对继承的债务进行优先级排序（例如阻断能力交付后）。开放沟通——健康 DevOps 公司的标志——是长期管理技术债务的重要工具。
沟通的话题——从沟通的技术层面出发——应用程序堆栈的组件之间相互沟通的方式也可以成为用 DevOps 解决技术债务的关键。追求围绕一系列 API （应用编程接口）进行通信的服务模式，能够帮助 DevOps 团队在提高应用预期可见性的同时，增强通信的可持续性。因此，通过实现 API，任何后来与相应服务交互的团队在与服务沟通时都会有一系列明确定义的期望。为了在不对 API 的现有客户端产生负面影响的前提下引入巨大或颠覆性变化，一些公司还追求多个版本的 API。可能有人会说，使用明确的 API 是一种基于服务或微服务的方法，严格意义上与 DevOps 没有关系。然而，完善的 DevOps 流程所带来的频繁循环周期是使各 API 流畅协同工作的关键。
许多采用“API 优先”模式的公司发现，通过使用容器，确保服务 API 每个组件都完成封装和移植，他们就能更好地管理技术债务。这种可移植性有助于提高团队信心，因为单个工件可以可靠部署在所有环境中，所以在非生产环境中进行的工作（例如在预生产空间进行负载测试或用户验收测试）将能反映代码生效时观察到的结果。容器编排平台——如 Kubernetes——也能帮助减少技术债务，因为此类平台可以本地处理多方面的扩展要求——如 Kubernetes Horizontal Pod Autoscaler (HPA)。增加对代码和测试的信心，以及自动化扩展支持所节省的时间，可以是减少直接技术债务的重要因素，而节省下来的时间将返还给能够将精力投入减少其他技术债务的团队（例如通过重构代码）。
DevOps 公司可以用来管理技术债务的另一个更好的策略就是为常见的任务（如编译代码、构建容器、执行测试或部署到同一环境中——总体而言就是内部软件即服务 (SaaS) 产品）实现共享、自助服务管道。在团队间共享这些活动，公司也就能使用共同的技术语言来探讨活动和问题。设计、实现和支持这样一种框架的过程也需要团队充分讨论和记录利用现有能力的众多应用程序的要求。为开发和支持团队额外节省出的时间将进一步帮助相关团队管理和减少技术债务。
一些没有应用 DevOps 的公司以大规模的项目工作为导向，项目级别以外的任务或是以前的项目遗留下来的任务因此成为需优先应对的挑战。DevOps 公司在识别、优先处理和执行低于项目工作量的一次性工作方面所展现的敏捷性同样为支付技术债务提供了有效途径。
相关文章：
2021 年最佳 DevOps 工具
DevOps 未来展望 – 顶级 DevOps 趋势
总结
技术债务并不一定是坏事。它与财务债务一样，只是一种工具，可以合理利用来实现快速开发和缩短上市时间。然而，如果公司忽略了累积的技术债务，债务利息可能会堆积得非常多。DevOps 文化和工具可以用来更好地管理和处理技术债务。另一个重要的观点是，如今缺乏适当的 DevOps 本身就属于技术债务范畴，所以如果你的公司有相应的 DevOps 流程和自动化能力，至少你也就避免了在这方面累积技术债务的问题。
