题目重点：从用户影响和止损开始，保留升级、值班交接与恢复确认，避免只说看dashboard。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 回答须来自本人真实经历；本文示例为虚构训练情境，不声称是原候选人案例。
- 规模、时间线、批准人和影响以实际可核对内容填写，未知数字明确说未知，不为了结果好看补造。
解题路线
- 先说明值班范围、权限、告警含义与当班动作。分清亲自处置、辅助定位与旁听事故，不能把团队经历当自己主导。
- 收到告警先核真实用户影响、持续性、范围与严重度，同时建立incident owner和通信渠道；噪声告警可核验但不能因指标正常就关闭。
- 止损优先选可逆且已授权动作，如回滚、限流或隔离异常shard，并记录证据。恢复服务和找根因可并行，不能为完美根因耗尽用户容忍。
- 升级和交接按影响与缺失能力触发，说明谁做技术决策、谁通知相关方。明确下一次更新时点，而不是等修完才沟通。
- 恢复确认用用户侧错误率/任务成功、依赖与backlog消退，持续观察再结案。随后复盘根因、检测缺口和预防owner/期限，不仅降低告警阈值。
手动走一遍
虚构训练例：部署后部分用户认证失败，候选人核版本与用户切片，按runbook回滚并检查登录成功率；恢复后调查兼容问题，保留回滚前日志和时间线。不要虚构审批或宣称任何on-call都能直接改生产。
规模与取舍
准备一条可追问的证据链：目标→约束→备选解释→个人行动→验证→残留问题。回答主线可练约2分钟，但题目没有限时要求；需要保留真实日志、设计结论或指标口径以展开细节。
易错点与追问
容易失分的边界
- 先查根因却不止损。
- 只报dashboard恢复没有用户确认。
- 把所有权限和批准默认授予自己。
继续深挖
- 告警与用户反馈不一致怎么办？
- 什么时候升级而不是继续自己查？
- 交接后你仍需追踪什么？
