5 年经验面试：技术债和业务需求怎么平衡？怎么说服上级给时间还债？
面试怎么回答
我会先把技术债分类：正在导致故障和延迟的优先还，其次是拖慢交付的和浪费资源的，稳定运行、很少改动的旧代码可以先放着。说服上级时用业务语言讲代价，比如过去三个月有几次报表延迟是这些老任务导致的、改一次口径要动多少脚本花几天、重复计算每月多花多少钱，同时给出投入、步骤和每一步可见的收益。平衡上，我会固定每个迭代留 15% 到 20% 时间做技术债和稳定性；业务有新需求时顺手重构这个域的模型；引擎迁移、分层重建这类大改单独立项，有里程碑和收益目标；再通过代码 Review 和模型评审防止新增债务。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
几乎每个数仓都有技术债：几千个没人敢动的老任务、复制粘贴的 SQL、没有分层的烟囱表、跑了三年的 Hive on MR。团队想重构，上级说「先把需求做完」。面试官想看你能不能把技术债讲成业务能听懂的代价，并且找到边做业务边还债的办法。
先把技术债看清楚
不是所有技术债都要还。按影响排序：
- 已经在出事的：频繁导致任务失败、数据错误、产出延迟的，优先级最高；
- 在拖慢交付的：每次改口径要改十几个地方、新需求要从原始层重新写，影响开发效率；
- 在浪费钱的：重复计算、低效任务占了大量资源；
- 只是不优雅的：代码风格旧，但稳定运行、很少改动，可以放着。
用业务语言讲代价
上级不关心「架构不合理」，关心的是：
- 「过去三个月，有 6 次报表延迟是这几个老任务导致的，影响了每天早上的经营会」；
- 「改一个 GMV 口径要动 14 个脚本，平均要 5 天，重构公共层后可以缩短到 1 天」；
- 「这批重复计算每月多花 8 万资源费」。
再给出方案：投入多少人、多长时间、分几步、每一步带来什么可见的改善。
怎么平衡
- 固定比例：每个迭代留出 15%–20% 的时间给技术债和稳定性，作为团队的常规工作，而不是每次单独申请；
- 跟着需求还：某个业务域有新需求时，顺手把这个域的模型重构了，业务方得到需求，团队还了债；
- 大的重构单独立项：比如引擎迁移、数仓分层重建，要有明确的目标、里程碑和收益，作为季度重点；
- 防止新增债务：代码 Review、模型评审、开发规范，不让问题越积越多。