为什么"技术债务"总是一笔糊涂账

几乎每一家拥有十年以上历史的企业，都面临同一个困境：系统越来越臃肿，但没人能准确说出"到底欠了多少债"。

技术债务不像金融债务那样有清晰的本金和利率。它隐藏在耦合过紧的模块里、藏在没有文档的接口背后、潜伏于早已停止维护的依赖库中。架构评审会上，各方都在抱怨"系统太烂"，但当下一个季度的预算摆在桌面上时，“还债"的需求总是被"新业务"挤掉。

有句话说：你无法管理的，正是你无法度量的。

问题的根源不在于企业不重视技术债务，而在于缺乏一套可量化、可追踪、可纳入治理流程的度量体系。传统的架构评审依赖专家经验打分，主观性强、覆盖面窄、难以持续执行。而纯粹靠自动化扫描工具产出的"代码质量报告”，又往往脱离业务语境，无法回答"这笔债务到底值不值得还"这个关键问题。

本文试图提供一条中间路径：将 TOGAF（The Open Group Architecture Framework）的架构治理框架与演进式架构（Evolutionary Architecture）中的 Fitness Function 概念融合，构建一套面向遗留系统的技术债务量化评分方案。

两个世界的交汇：TOGAF 治理与 Fitness Function

TOGAF 的架构治理：结构化但缺乏自动化

TOGAF 的架构开发方法（ADM）提供了从愿景到迁移规划的完整生命周期。在 Phase H（架构变更管理）中，明确要求对已部署架构进行合规性审查和持续监控。

TOGAF 的架构治理框架通常包含以下要素：

问题在于，这些治理活动大多依赖周期性的人工评审——每季度一次架构评审会、每年一次架构成熟度评估。在系统变更日益频繁的今天，这种节奏远远不够。

Fitness Function：演进式架构的"健康指标"

Fitness Function 这个概念借自进化生物学。在演进式架构的理论体系中，Fitness Function 被定义为对架构某一特征的自动化评估机制，用于确保系统在持续演进过程中不偏离预期的质量属性。

一个典型的 Fitness Function 具备以下特征：

• 可自动化执行：不依赖人工判断，由工具链自动触发
• 有明确的阈值：通过/不通过的判定标准是预设的
• 持续运行：集成在 CI/CD 流水线中，每次变更都触发评估
• 多维度覆盖：从性能、安全、可维护性等多个视角评估

有句话说：好的架构不是一次性设计出来的，而是通过持续的约束和反馈"长"出来的。

融合的逻辑：用 Fitness Function 驱动架构治理

将两者结合的核心思路是：

1. 用 TOGAF 的治理框架定义"该度量什么"——从架构原则、目标架构、架构路线图出发，明确度量的维度和标准
2. 用 Fitness Function 定义"怎么度量"——将治理要求转化为可自动执行的评估函数
3. 用量化评分连接两者——把离散的 Fitness Function 结果聚合为一个可比较、可追踪的技术债务评分

技术债务的四个维度与度量指标

在构建 Fitness Function 之前，需要先明确技术债务的分类。借鉴业界广泛使用的分类方法，结合企业架构的实际场景，我们将技术债务划分为四个维度：

维度一：代码与依赖债务

这是最表层、也最容易自动化的债务类型。

关注点：代码复杂度、过时依赖、重复代码、测试覆盖率不足

典型 Fitness Function：

维度二：架构耦合债务

这一层债务更隐蔽，对系统演进能力的阻碍也更大。

关注点：模块边界侵蚀、接口契约违反、跨层调用、共享数据库

典型 Fitness Function：

维度三：基础设施与运维债务

很多技术债务并不在代码里，而在基础设施的配置和运维方式中。

关注点：手工部署、缺乏监控、配置漂移、容灾缺失

典型 Fitness Function：

维度四：文档与知识债务

这是最容易被忽视、却在关键时刻"要命"的债务类型。

关注点：架构决策缺失、接口文档过期、人员知识孤岛

典型 Fitness Function：

从指标到评分：构建技术债务综合评分模型

单个 Fitness Function 只能告诉我们"某个维度是否达标"。要形成对遗留系统的整体判断，需要一套评分聚合机制。

步骤一：指标标准化

不同指标的量纲不同——有的是百分比，有的是绝对数量，有的是时间间隔。首先将它们统一归一化到 0-100 的分值区间。

标准化公式的一般形式：

1

得分 = max(0, 100 - (实际值 - 目标值) / (最差可接受值 - 目标值) × 100)

当实际值优于目标值时，得分为 100。当实际值达到最差可接受阈值时，得分为 0。超出最差阈值的仍记 0 分，但触发告警。

步骤二：维度权重分配

不同企业、不同业务阶段的权重应有所差异。以下是一个典型的权重参考：

权重的设定本身就是一个架构治理决策，应在架构评审委员会中讨论确定，并随业务阶段动态调整。

步骤三：系统级聚合与分级

将各维度加权求和，得到系统的综合技术债务评分（Tech Debt Score, TDS），范围 0-100。分数越高，代表债务越轻、架构越健康。

根据评分划分等级：

步骤四：趋势追踪

单次评分的意义有限，真正的价值在于趋势。建议以双周或月度为周期绘制 TDS 趋势图，关注以下信号：

• 持续下降：说明新引入的债务超过了偿还速度，需要干预
• 平台期：改善措施停滞，需要检查执行力度
• 波动剧烈：可能存在"突击还债后放松"的周期性问题

落地实施：将 Fitness Function 嵌入治理流程

与 TOGAF ADM 的对齐

将 Fitness Function 集成到 TOGAF 的架构开发方法中，可以在以下阶段发挥作用：

Phase E（机会与解决方案）：利用 TDS 评分识别最需要改造的遗留系统，作为迁移规划的输入依据。不再依赖"谁嗓门大谁优先"的资源争夺模式，而是用数据说话。

Phase G（实施治理）：在开发实施阶段，Fitness Function 作为持续集成流水线的一部分自动运行。每次代码提交、每次部署，都触发相关评估。这弥补了传统架构合规性审查"事后追溯"的不足。

Phase H（架构变更管理）：TDS 趋势作为架构变更管理的核心输入指标。当某个系统的评分持续走低，自动触发架构评审流程。

工具链选型建议

构建 Fitness Function 工具链不需要从零开始，很多开源工具可以组合使用：

• 代码与依赖分析：SonarQube、Dependabot、ArchUnit
• 架构耦合检测：ArchUnit、Structure101、自研依赖图分析工具
• 基础设施合规：InSpec、OPA（Open Policy Agent）、Terrascan
• 文档与知识：ADR 管理工具（adr-tools）、文档过期告警脚本、代码贡献者分析

关键不在于工具本身，而在于将工具的输出聚合到统一的评分平台。可以是一个简单的仪表盘，也可以是集成到企业架构管理平台（如 Mega、LeanIX 或自研系统）的模块。

实施路径：从小处开始

不要试图一次性覆盖所有维度。建议的推进节奏：

1. 第 1-2 个月：选择 1-2 个最痛的系统，仅实现"代码与依赖债务"维度的 Fitness Function，跑通自动化采集和评分流程
2. 第 3-4 个月：扩展到"架构耦合债务"维度，引入 ArchUnit 等工具定义架构规则
3. 第 5-6 个月：覆盖基础设施和文档维度，完善评分模型，开始在全组织范围内推广
4. 持续迭代：根据实践反馈调整指标、阈值和权重

治理中的常见陷阱与应对

陷阱一：指标博弈

当评分与绩效考核挂钩时，团队可能会"优化指标"而非"改善架构"——比如为了提升测试覆盖率而编写大量无意义的测试。

应对：设置"对抗性指标"。例如，在追踪测试覆盖率的同时，追踪变异测试（Mutation Testing）得分，确保测试真正在检测行为而非仅仅覆盖代码行。

陷阱二：阈值僵化

随着技术栈演进，半年前设定的阈值可能已经不合时宜。一个曾经合理的"依赖版本老化度 ≤ 3"在新框架发布后可能过于宽松。

应对：建立阈值的定期回顾机制，将其纳入架构评审委员会的固定议程。Fitness Function 的参数本身也需要"治理"。

陷阱三：忽视业务语境

一个面向内部员工的报表系统，和一个日活千万的面向消费者系统，对架构健康度的要求不应相同。用同一套标准评估所有系统，会导致资源错配。

应对：根据系统的业务重要性分级（Business Criticality Tier），为不同级别设定差异化的 Fitness Function 阈值和权重。核心系统的架构耦合债务权重可以提高到 45%，而辅助系统可以降低到 25%。

陷阱四：评分沦为报告

如果 TDS 评分只出现在季度报告中，从未影响过实际的技术决策，那么整套体系就只是一个"昂贵的摆设"。

应对：建立硬性关联规则。例如：

• TDS 低于 C 级的系统，新功能开发必须包含 20% 的还债工作量
• TDS 持续两个季度下降的系统，自动触发架构重构评审
• TDS 低于 D 级的系统，限制新增功能范围，仅允许修复类需求

一个实际的评分示例

为了更直观地展示这套方案的效果，以下是一个假设的遗留系统评分案例。

系统背景：某企业的订单管理系统，运行 8 年，经历了多次业务变更，当前由三个团队共同维护。

各维度评分：

综合评分：42.05（D 级）

治理建议：该系统已进入"重度债务"区间。建议立项架构重构，优先拆分订单与库存的共享数据库，同时将基础设施 IaC 覆盖率提升到 90% 以上。在重构完成前，限制新功能的范围，每个迭代至少投入 30% 的工程量用于还债。

技术债务量化与架构演进的长期关系

技术债务的量化不是一个孤立活动，它应该成为企业架构演进能力的底层基础设施。

当 Fitness Function 的评分数据积累到一定量级，就可以支撑更高层次的决策。比如：哪些技术栈的债务增长速度最快？哪些架构模式在长期运营中表现出更好的可维护性？团队的工程实践成熟度是否与系统健康度正相关？

这些洞察反过来又能指导架构原则的修订、技术选型的决策、以及组织能力建设的优先级。形成从度量到治理、从治理到演进的闭环。

架构治理的本质不是"控制"，而是建立一套让系统持续保持健康状态的反馈机制。Fitness Function 是这套机制的执行层，TOGAF 框架是决策层，而技术债务评分则是连接两者的共同语言。

当技术债务不再是一个模糊的形容词，而是一个可以追踪、可以比较、可以设定改进目标的数字时，架构治理才真正从"开会讨论"走向了"数据驱动"。遗留系统的改造优先级不再取决于谁的声音更大，而是取决于数据告诉我们的事实。这才是企业架构治理应有的样子。