技术债、优先级与业务价值
技术债是当前技术选择持续增加未来交付成本或运行风险的部分，偿还优先级需要与业务影响、发生概率和投入一起评估。
1. 把技术债写成具体问题
“代码很乱”不能直接进入排期。一项可管理的技术债要说明：
- 具体位于哪个系统、模块或流程；
- 由什么历史选择或当前约束形成；
- 正在影响哪些用户、团队或业务指标；
- 如果继续保留，成本会怎样增长；
- 哪些变化会触发风险；
- 谁负责跟踪和重新评估。
例如：“订单发布仍需人工修改三处配置，过去六个月造成两次回滚，平均增加四小时发布等待”，比“发布系统需要重构”更容易比较和验收。
缺陷、功能缺口、过时依赖和技术债可以有交集，但处理方式不同。安全漏洞可能需要立即修复，不必等待技术债排序；纯审美偏好也不应自动占用业务资源。
2. 区分本金与持续利息
本金是消除问题所需的一次性投入，例如重构、迁移和测试。利息是继续保留问题带来的重复成本，例如：
- 每次需求需要额外修改和回归；
- 发布频率下降、等待时间增加；
- 故障、告警和人工值班增多；
- 云资源或许可证持续浪费；
- 新成员理解系统需要更长时间；
- 关键依赖失去安全更新。
利息可以从 issue、变更记录、事故、工时和账单中估算。即使不能得到精确金额，也可以记录频率、持续时间和影响范围，形成可比较的数量级。
一项债务本金很高、利息很低时，可以继续观察；本金较小并且每周都在付利息时，通常应尽快处理。
3. 风险债务单独评估
有些问题尚未造成日常效率损失，却可能引发严重事件，例如证书无法轮换、备份从未恢复、单点组件停止维护。
这类债务使用风险评估：
预期风险 = 发生概率 × 影响 × 暴露时间
还要考虑风险是否不可逆、能否检测和是否有替代路径。低概率的数据永久丢失通常比高频的小额资源浪费优先级更高。
合规、安全和已承诺 SLO 可以形成硬约束。这些问题由对应责任人确定最低处理要求，不能只放进普通价值矩阵等待。
4. 与业务工作使用共同尺度
技术债和功能需求争夺同一批人力时，需要把两者都转换为结果：
- 减少多少故障和用户损失；
- 缩短多少需求交付或恢复时间；
- 降低多少运行成本；
- 解锁哪些已经排期的业务能力；
- 降低哪些安全或合规风险；
- 需要多少工程时间和迁移风险。
可以使用影响、紧迫度、信心和投入形成简单评分，但评分只是排序输入。重大依赖关系、硬截止日期和不可逆风险仍需要单独判断。
“技术质量”本身可以有价值，但要说明它如何影响持续交付、可靠性和维护责任，避免技术团队与业务团队使用两套无法对话的语言。
5. 选择合适的偿还方式
技术债不都需要一次性重写。常见路径包括：
- 在相关功能开发时顺带重构局部；
- 建立适配层，逐步替换旧实现；
- 用自动化测试和监控先降低风险；
- 停止扩展旧模块，把新需求放到新边界；
- 删除低价值功能或合并重复系统；
- 在明确窗口完成集中迁移。
选择路径时比较价值出现时间和中间状态。大规模重写在完成前很少产生收益，还会追赶旧系统持续变化；增量方式更容易验证，但兼容期会增加临时复杂度。
如果问题来自缺少所有权、发布流程或架构约束，只改代码会再次积累。偿还方案要处理产生债务的机制。
6. 为主动借债设置到期条件
为了固定发布日期采用临时方案可以是合理选择，但要在决策当时记录：
- 得到的短期业务价值；
- 放弃了哪些质量属性；
- 允许保留到何时或什么规模；
- 需要补充的测试、监控和保护；
- 偿还负责人和触发条件。
“以后再优化”没有约束，通常会永久保留。可以把到期条件设为流量、租户数、错误预算、依赖版本或下一阶段产品目标。
主动承担的债务也要控制总量。团队同时维护大量临时路径时，新的业务价值会被兼容和排障成本抵消。
7. 在日常工作中持续处理
只靠每季度一次“技术债冲刺”，容易让债务在其余时间继续增长。更稳定的做法包括：
- 每项债务有所有者、证据和复审日期；
- 产品与工程共同查看高风险和高利息项；
- 功能规划时计算受影响模块的偿还成本；
- 错误预算耗尽时优先可靠性工作；
- 为小规模持续改进保留固定容量；
- 大型迁移按业务里程碑单独立项。
固定比例不是普遍答案。债务很少时不必为了用满比例创造工作；严重影响交付时，固定比例又可能不足。以可见风险和价值动态调整。
8. 完成标准需要量化验证
技术债任务的完成标准不是“完成重构”。它应回到原始问题，例如：
- 发布人工步骤从三项降为零；
- 相关变更前置时间降低 50%；
- 旧 API 流量归零并删除兼容层；
- 恢复演练满足 RTO/RPO；
- 单位请求成本下降且 SLO 不退化。
指标没有改善时，说明原因判断、方案或实施范围可能有误。及时停止低收益投入，比继续扩大重写范围更有价值。
9. 面试题
9.1 业务需求很紧时，怎样决定是否优先偿还技术债
出现公司：蚂蚁金服
考察重点
- 具体债务、持续利息与风险暴露。
- 与业务需求使用共同结果和成本比较。
- 增量偿还、到期条件和量化验收。
相关内容：第 1 节“把技术债写成具体问题”至第 8 节“完成标准需要量化验证”。
参考回答
我会先把债务写成具体系统问题，用事故、交付等待、人工工时、成本或安全暴露说明持续利息。再估算消除它的本金，以及继续保留的发生概率和业务影响。合规、安全、数据丢失和已承诺 SLO 属于硬约束，优先满足最低要求；其他债务与功能一起比较用户价值、解锁能力、风险降低、投入和信心。
偿还方式优先选择能分阶段产生收益的局部重构、适配替换、自动化保护或删除低价值能力。确实需要短期借债时，记录到期条件、保护措施和负责人。完成后用发布时间、故障、成本或旧路径流量验证原问题已经改善；没有改善就重新评估，不把“重构完成”当成果。