行为面试：讲一次你在不丢失用户的情况下退役旧系统
题干与适用场景
面试官想知道你是否真正推动过一项有历史包袱的改变。旧系统可能还能运行，却消耗大量值班时间、无法满足安全要求，或阻碍新产品。请讲清你如何决定退役、迁移用户并处理反对意见。
这道题不是让你描述一次技术重写，也不是把迁移成功归功于“团队配合”。回答要让面试官听见你的判断、动作、证据和结果。
面试官考察什么
重点包括：能否从用户工作流而非系统年龄出发；能否用数据识别真正受影响的人；能否把风险、责任人和时间点公开；能否在有争议时坚持用户目标并在决定后共同执行。Amazon 的面试指引强调 STAR、具体个人贡献和可量化结果；Google SRE 的退役案例也强调用户工作流、沟通与迁移工具。
回答前要澄清的问题
先确认“退役”是停止新用户、只读保留、完全下线，还是替换一条内部流程。再确认你担任的角色、影响范围、迁移期限、可用替代品和不可逆风险。若无法公开具体公司数据，可说明数字是经脱敏的真实口径或面试假设。
30 秒回答框架
我会用五句讲：背景和代价；我负责的目标；我如何用访问数据和用户访谈划分迁移批次；我如何设计双轨、回滚和沟通；结果、教训和下一次会改什么。每句都用“我”说明动作，用数字说明结果。
分步骤深入分析
第一步：把“旧”翻译成可验证的问题
不要因为技术栈老就宣布下线。先量化维护工时、故障、成本、合规缺口和仍在使用的关键流程。按用户、工作流、数据规模和访问频率分组，找出替代方案尚未覆盖的例外。Google SRE 通过访问模式理解用户工作流，避免只凭系统统计决定迁移。
第二步：建立迁移证据与最小可行路径
为每一类用户定义目标状态：直接迁移、转换工具、只读归档或暂缓。给出兼容性清单、数据校验、演练环境和明确的停止条件。先选择低风险批次做试点，让替代系统的能力和迁移成本用真实结果说话。
第三步：处理反对意见与利益相关者
把反对者的顾虑拆成数据丢失、工作中断、责任不清或替代方案不足。与支持、客服、安全和替代系统负责人一起建立问题清单和每周决策记录。遇到不同意见时先用证据争论；决定后明确谁负责执行、谁有权暂停，而不是让争论一直拖延。
第四步：设计双轨、回滚和沟通
迁移期间保留旧系统的只读或回退能力，给每批用户一个可验证的完成信号。提前发出影响范围、原因、截止日期、迁移步骤和求助入口；发生失败时说明事实、补救动作和下一次更新。错误地通知了不受影响用户，或漏掉了真正受影响用户，都会损害信任并增加客服工作。
第五步：定义结果与复盘
结果指标可以包括迁移完成率、关键工作流成功率、回滚次数、故障工时、用户求助量和维护工时。不要只报“旧系统已关闭”；同时说明受影响用户是否完成任务、运营负担是否下降，以及哪些例外被保留。复盘应写下错误假设、早期信号和下一次迁移会提前做的验证。
高质量示范回答
我曾负责一套仍被少数客户使用的旧报表流程。它每周占用约 20 小时人工维护，替代方案已覆盖大多数查询，但高峰客户担心历史数据不一致。我先按访问日志和客户工作流划分用户，发现 82% 的访问可以直接迁移，另外 18% 需要历史数据转换。
我把目标设为先完成低风险批次，而不是立即关闭旧流程。工程为两套结果生成校验报告，支持团队准备按客户分组的通知，我负责每周公开迁移表和暂停条件。试点两周后，关键报表一致率达到 99.9%，没有发生回滚；对剩余用户，我们提供转换工具和只读归档，并把最终截止日期延后一次。
最终旧流程维护工时从每周约 20 小时降到 4 小时，所有仍有访问的客户都有替代路径。复盘发现我们低估了一个地区的导出格式，所以后来把地区和导出方式加入最初的分群，而不是在截止日期前才补救。
常见错误与改进
- 只说“系统太旧”：补充用户影响、维护代价和替代证据。
- 只讲技术重写：说明你如何调查工作流、分批和沟通。
- 把反对者描述成阻力：呈现其风险证据和你如何回应。
- 只报迁移百分比：补充关键任务成功率、回滚和求助量。
- 声称零风险：说明保留的只读、回滚或延期期限。
追问及应对
What if the replacement is not ready for every user?
Keep a documented exception path: read-only archive, conversion tooling, or a time-boxed extension. Define the owner and exit condition for each exception instead of forcing a risky cutover.
How did you convince a stakeholder who opposed retirement?
I asked which failure they were protecting against, measured that workflow, and ran a small migration to test the replacement. If the decision still went against their preference, I recorded the risk and committed to the agreed plan with a pause condition.
What would you do if migration caused data loss?
Stop the batch, preserve the old source, identify the affected records, and communicate a concrete recovery timeline. After restoring service, add an automated reconciliation check and revise the next batch gate.
How do you know the project succeeded?
Use user-outcome and operating metrics together: critical workflow success, migration completion, rollback and support volume, plus maintenance hours. A closed system without a safe user path is not a successful retirement.