题干与适用场景
你发现团队经常使用的一份事故运行手册包含已移除的服务步骤，继续照做可能扩大故障。请说明你如何在不打断当前值班的情况下保护团队、验证替代流程、推动废弃或改写，并回答如何证明改进真的被采用。
面试官考察点
- 是否会先降低错误操作风险，再讨论文档责任归属。
- 是否能把“文档过时”转化为可复现、可验收的迁移计划。
- 是否能用 STAR 讲清影响、协作、取舍和后续指标。
回答前需要澄清的问题
- 哪些步骤已经失效，是否会删除数据、扩大流量或阻塞恢复？
- 当前值班人员从哪里打开这份手册，是否存在缓存链接或自动引用？
- 新流程的 owner、演练环境和紧急回滚路径是什么？
30 秒回答框架
我会先在手册顶部标注风险并提供临时安全路径，通知值班和事件负责人，避免有人继续执行失效步骤。然后用一次演练或沙盒验证替代流程，和服务 owner 一起更新入口、权限和回滚说明。废弃或发布新版本后，我会通过链接访问、演练成功率、误操作数和行动项完成率确认迁移，而不是只看合并请求是否通过。
分步骤深入解答
1. 先隔离危险步骤
确认手册中哪些命令或决策会造成不可逆影响。若存在风险，在顶部加醒目警告、停用自动链接或把旧版本移到明确的存档位置；保留一条经过值班负责人确认的临时路径。
2. 还原真实使用路径
检查值班目录、搜索结果、机器人消息、权限和缓存书签，找出团队实际打开的版本。只改主仓库文件却忽略复制链接，会让旧内容继续流通。
3. 验证替代流程
在沙盒或低风险窗口执行新步骤，记录前置条件、观察信号、停止条件和回滚。GitLab 将 runbook 用于常见故障的初步识别与处理，复杂情形则由 playbook 或升级流程承接；文档边界应与真实职责一致。
4. 与相关团队共同改写
邀请服务 owner、值班代表和安全或合规联系人复核。把争议拆成事实、假设和待验证项，避免由单人凭记忆重写关键命令。每一段步骤都说明适用范围和失败时的升级入口。
5. 设计发布与废弃策略
新版本先发布为候选，旧版本标记废弃日期和替代链接。若旧流程可能造成严重损害，先移除执行权限或改成只读说明，再按变更流程发布。回滚策略要与部署权限和最近可用版本一致。
6. 用演练验证采用
让不参与编写的人按新手册完成一次演练，观察是否能找到入口、识别前置条件并在停止条件触发时升级。记录完成时间、错误步骤和提问，不用作者自测代替真实使用。
7. 把改进纳入维护节奏
设定 owner、复查日期和触发条件，例如服务拓扑、告警名称或权限变化时自动开更新任务。过时手册的根因可能是变更流程没有文档检查，应把它纳入发布清单和事故复盘行动。
高质量示范回答
我会先确认失效步骤的风险，在手册顶部加警告并通知值班和事件负责人，提供一条经过确认的临时安全路径。随后检查团队实际使用的链接和机器人入口，在沙盒中验证替代流程，记录前置条件、停止条件和回滚。邀请服务 owner 与值班代表共同复核，发布新版本并标记旧版本废弃。最后让未参与编写的人做演练，用找到入口的时间、误操作和升级是否及时来验收，并把复查触发条件加入变更流程。
常见错误
- 只删除旧手册，没有给值班人员安全替代路径。
- 只改仓库中的文件，不检查缓存链接、机器人和书签。
- 让作者自己演练后就宣布文档可用。
- 把所有故障步骤塞进 runbook，不区分 playbook 和升级边界。
- 只统计文档合并次数，不衡量误操作和演练结果。
追问及应对
如果当前正发生事故怎么办？
先由 incident lead 确认临时路径和风险，暂停失效步骤的传播，再把文档修复纳入事故行动项。不要在救火中进行未经验证的大规模重写。
如果服务 owner 不愿承认手册过时怎么办？
带上具体步骤、最近变更和可复现的失败证据，提出小范围演练。把讨论聚焦在用户风险和维护责任，不评价个人。
旧手册被很多外部团队引用怎么办？
保留稳定重定向或兼容说明，通知消费者并设置迁移截止日期。对高风险命令先限制权限，再逐个确认迁移完成。
什么时候应该彻底删除旧版本？
替代路径经过演练、有明确 owner，所有关键入口已迁移且有回滚方案后再删。安全或合规要求更严格时遵循保留政策。
如何应对新流程在演练中失败？
停止发布，记录失败前置条件和观察信号，修正流程后重新演练。失败本身是发布门槛没有通过的证据，不应靠口头解释绕过。
你会怎样用 STAR 回答？
说明过时手册带来的具体风险和任务，再讲你如何通知、验证、协作和发布，最后给出误操作减少、演练通过率或迁移完成率等结果与后续维护机制。