什么是技术债管理
技术债是过去为了赶进度而做的妥协在未来产生的额外维护成本，包括结构耦合、测试缺失、依赖落后、文档脱节与手工运维。管理的核心不是「还清所有债」，而是把债务显性化、量化利息、按影响排序偿还，并用护栏防止边还边欠。
基本信息
| 债务分类 | 结构债、测试债、依赖债、文档债、运维债 |
|---|---|
| 登记方式 | 独立台账或问题单，任何人可提交 |
| 排序依据 | 利息高低（每次相关变更的额外耗时与风险） |
| 护栏机制 | 适应度函数、评审清单与迭代容量预留 |
常见债务与处置
| 类型 | 表现 | 处置方向 |
|---|---|---|
| 结构债 | 模块耦合、循环依赖、上帝类 | 边界重构与依赖规则检查 |
| 测试债 | 回归依赖人工点检 | 补齐关键路径自动化 |
| 依赖债 | 版本落后或上游停更 | 升级排期与替代评估 |
| 文档债 | 文档与实现脱节 | 随版本更新并精简结构 |
| 运维债 | 发布与扩容靠手工脚本 | 脚本化、流水线与 IaC 化 |
落地要点
- 登记入口轻量：提交时写清现象、影响面与复现方式即可，不要求完整方案
- 分类打标：结构、测试、依赖、文档与运维分开统计，便于对应不同处置路径
- 影响面评估：记录受影响模块、变更频率与是否与历史事故相关联
- 利息估算：估算每次相关变更的额外耗时，作为排序依据
- 偿还排期：按利息与处理成本排序，进入迭代而非无限期排队
- 验收口径：写清偿还完成的判定标准，避免「改了一半」长期挂着
债务台账字段示例
债务台账字段示例
# 每行一条债务（示意，可放看板或问题单模板）
id：TD-014
类型：测试债 影响模块：订单结算
现象：结算回归依赖人工执行 40 项用例，每次发版耗时约半天
利息：每次结算相关变更额外 4 人时，且曾漏测导致线上对账差异
处置方向：先补 12 条关键路径自动化，覆盖八成回归场景
验收：流水线可自动跑通关键路径，人工用例降到 10 项以内
预算：本迭代预留 15% 容量偿还动作要小步化：与业务迭代同行的持续小额偿还，比集中几个月的大重构更可持续，也更容易验证效果。
把债务与事故关联起来最有说服力：有事故数据的债务条目更容易拿到排期容量。