# 1. 你的团队出事故状态页没 owner，你看怎么推动 A 明确状态页 owner 与职责、兜底并纳入预案，保证对外沟通准确及时 ✓ 正确答案 B 状态页没 owner 也没关系，事后补就行 C 状态页更新是临时有人做就行 D 状态页只对内部，对外不重要
# 2. 你的团队出事故后复盘改进项不写入团队 OKR（无法考核），你怎么看怎么推动 A 复盘改进项靠团队自觉就行，不用考核 B 改进项写入 OKR 是形式主义 C 复盘结论止于文档即可 D 把高价值改进项纳入 OKR 并在复盘闭环中跟进，保证改进落地不落空 ✓ 正确答案
# 3. 你的团队出事故后复盘改进项没人 owner（没人负责），你看怎么推动 A 改进项由团队集体负责，人人有责 B 复盘改进项不需要 owner，自觉完成 C 改进项无人负责就搁置，等有空再说 D 每个改进项指定 owner+deadline+验收标准并跟进，责任到人才落地 ✓ 正确答案
# 4. 你想争取 20%人力做稳定性建设但 PM 要求全速做需求，怎么 argue？ A 稳定性建设是浪费业务时间 B 应该 100% 人做需求，稳定性靠运气 C 稳定性建设与业务无关 D 用事故/返工/技术债数据证明稳定性是业务速度保障，用小步持续投入论证 20% 合理性 ✓ 正确答案
# 5. 稳定性改进无直接业务收益，如何在规划会上用数据证明价值？ A 稳定性无业务收益，无法证明价值 B 用事故损失/人时浪费/机会成本/ROI 数据证明稳定性是"避免亏损"的投资 ✓ 正确答案 C 稳定性价值只能靠领导拍板 D 稳定性改进完全无法量化
# 6. 上线节奏过快隐患累积，你如何说服 leader 降速？ A 上线越快越好，降速是退缩 B 隐患累积是正常的，不用担心 C 用失败率/事故率/返工数据证明快而不稳更慢，用质量门禁等优化节奏而非降野心 ✓ 正确答案 D 降速只会让业务落后
# 7. 你提议 blameless 文化但 leader 习惯追责，怎么推动文化转变？ A blameless 针对系统性问题，用系统根因思维替代追责，鼓励暴露真相减少重复事故 ✓ 正确答案 B blameless 文化就是犯错不追责、包庇 C 追责文化更好，能震慑犯错 D blameless 会让团队不负责
# 8. 稳定性指标（MTTR/MTBF）如何量化成业务语言让 PM 理解？ A MTTR/MTBF 是纯技术指标，PM 无需理解 B 稳定性指标只能技术团队自己看 C 把 MTTR/MTBF 翻译成业务中断/用户留存/收入成本等业务语言，让 PM 理解稳定性价值 ✓ 正确答案 D PM 永远无法理解稳定性
# 9. 你的团队出事故状态页没和 IM 机器人集成（手动更新），你怎么看怎么推动 A 状态页手动更新就够了，不用自动化 B 状态页更新只能靠人 C 自动化集成复杂且无用 D 用状态页与 IM 机器人集成+告警自动联动，让状态页更快更准、释放 oncall 精力 ✓ 正确答案
# 10. 你的团队出事故状态页 RSS/Atom feed，你看怎么推动 A 状态页不需要订阅功能，stakeholders 自己查就行 B 提供 RSS/Atom 订阅让 stakeholders 主动获取更新，信息触达更即时省心 ✓ 正确答案 C RSS/Atom 是过时技术，无用 D 状态页订阅只能靠邮件
# 11. 你的团队出事故状态页合规审查（GDPR 等），你怎么看怎么推动 A 事故状态页不需要合规，直接发布即可 B 合规审查会拖慢沟通，应跳过 C 明确可发布边界+合规审查流程+预写模板+遵守披露时限，保证事故沟通合规 ✓ 正确答案 D 事故信息可以随意包含隐私数据
# 12. 你出事故了想回滚但 leader 坚持修复不回滚，你怎么看怎么 argue A 回滚一定比修复好，必须回滚 B 出事就该立刻回滚，不用讨论 C leader 坚持修复就修复，别再争 D 用风险与时间对比回滚 vs 修复，选风险更低恢复更快的方式，尊重 leader 决策 ✓ 正确答案
# 13. 你出事故了想回滚但 oncall 没权限，你看怎么推动授权 A oncall 不该有回滚权限，容易滥用 B 用分级授权+预授权+事后审计让 oncall 事故时能快速回滚，兼顾效率与安全 ✓ 正确答案 C oncall 回滚必须逐级审批 D 事故处理等待审批是正常的
# 14. 你出事故了想回滚但回滚可能丢数据，你看怎么 argue 取舍 A 为了止损必须回滚，丢数据在所难免 B 综合评估回滚丢数据与不回滚事故的损失，选损失最小的方案 ✓ 正确答案 C 回滚丢数据就不能回滚，只能硬扛 D 数据丢失无所谓，服务恢复就行
# 15. 你出事故了想回滚但数据库 schema 变了无法回滚，你看怎么推动兼容 A schema 变了就无法回滚，只能硬扛 B schema 变更后回滚永远不可能 C 回滚方案不重要，上线再说 D 用向前兼容/双写/分阶段迁移让 schema 变更后回滚仍可行，事故能安全恢复 ✓ 正确答案
# 16. 你出事故了想降级但降级方案没人 review，你看怎么推动 A 降级是紧急操作，不用 review 直接降 B 降级方案写出来就不会严格执行 C 提前定义并 review 降级方案放 runbook，事故时按预案安全执行 ✓ 正确答案 D 降级全靠临时临场发挥
# 17. 你出事故了想降级（关闭某些功能）但 PM 说"不能关"，你怎么看怎么 argue A PM 说不能关就绝不降级，硬扛事故 B 事故时降级会让 PM 不满，不该做 C 降级就应该全关所有功能 D 用部分降级（保核心）+风险对比+恢复承诺 argue 降级是保护整体而非牺牲业务 ✓ 正确答案
# 18. 你的团队出了 P1 事故但 leader 说"没必要复盘"，你怎么看怎么推动 A leader 说没必要复盘就不复盘，听从他 B 用根因/重复风险论证+轻量复盘+blameless，推动 P1 复盘防止重复事故 ✓ 正确答案 C P1 事故复盘是浪费时间 D 复盘已经发生的事没有意义
# 19. 你的团队出事故后复盘但被批评"反思不够深"，你怎么看怎么 argue A 复盘反思到表面操作失误就够了 B 复盘深度是玄学，无法提升 C 用 5 Whys 和系统根因视角深挖，区分直接原因与根本原因 ✓ 正确答案 D 反思够不够深无所谓
# 20. 你的团队出事故后复盘改进项分配给 junior（无法落地），你怎么看怎么 argue A 改进项分配匹配能力并提供 senior 支持，用 owner+deadline+验收保证落地 ✓ 正确答案 B 改进项给 junior 是锻炼，让 ta 自己想办法 C 改进项谁能做就给谁，无需匹配 D 改进项落地不了就换一个做
# 21. 你的团队出事故后复盘改进项没人跟进（JIRA 不更新），你看怎么推动 A 改进项 JIRA 不更新是小事，无需管 B 用看板跟踪+定期例会+复盘验证+未完成升级，形成改进项闭环跟进 ✓ 正确答案 C 改进项跟进靠团队记忆 D 改进项追踪是形式主义
# 22. 你想推动故障演练（GameDay）但 leader 说"占时间"，你怎么看怎么推动 A 故障演练占时间，等真出事再说 B 演练会发现不了问题，没意义 C 用低成本演练暴露问题，证明演练是比真实事故代价小的保险 ✓ 正确答案 D 演练只在真实事故后做
# 23. 你想推动混沌工程但 PM 说"可能影响客户"，你怎么看怎么 argue A 混沌工程会破坏生产，不该做 B 混沌工程必须在生产全量乱搞 C 用低风险设计（小范围/自动回滚/灰度）让混沌工程受控，主动发现系统脆弱点 ✓ 正确答案 D 混沌工程只对测试环境有意义
# 24. 你想推动混沌工程但 leader 说"风险太大"，你怎么看怎么 argue A 混沌工程风险太大，永远不该做 B 从低风险开始+安全机制+逐步扩大，主动管理风险比被动等事故更安全 ✓ 正确答案 C 混沌工程只做一次高风险的 D 混沌工程风险无法管理
# 25. 你想推动混沌工程但没人写过 Chaos 实验，你看怎么推动 A 没人写过混沌实验就放弃，等有经验的人来 B 混沌实验必须一次写完美 C 用学习工具+简单低风险起步+带头示范+模板沉淀，从零建立混沌工程能力 ✓ 正确答案 D 混沌工程只能由专家做
# 26. 系统没有 SLO/错误预算，业务只盯功能上线，你怎么推动建立可靠性基线？ A 用 SLO 定义可靠性目标+错误预算平衡功能与稳定性，让可靠性可衡量可管理 ✓ 正确答案 B 系统没有 SLO 也没关系，盯功能上线就行 C SLO 是纯技术概念，业务用不上 D 可靠性靠感觉，无法量化
# 27. leader 说稳定性重要但不给资源，如何用一次小事故教育组织？ A 量化小事故损失+类比放大+ROI 对比，用数据证明稳定性投入是必要保险 ✓ 正确答案 B 一次小事故无所谓，不值得提 C 小事故不用教育组织，等大事故再说 D 稳定性投入完全靠 leader 自觉
# 28. 如何在需求排期中自然嵌入稳定性工作而不被当成阻碍业务？ A 稳定性工作就该单独排期，与业务无关 B 用业务化+小步嵌入+与功能绑定，把稳定性工作融入排期而非对立 ✓ 正确答案 C 稳定性会拖慢业务，不该做 D 稳定性工作只能等业务做完再做
# 29. 状态页（status page）应发布哪些信息（影响范围、时间线、修复进展）与更新节奏如何把握？ A 状态页发布状态/影响范围/时间线/进展/总结，并按初步/过程/恢复/总结节奏更新 ✓ 正确答案 B 状态页只写"正在修复"四个字就够了 C 状态页更新越少越好，避免打扰 D 状态页只给内部看，无需完整
# 30. 事故沟通中状态页、IM 群公告与邮件通知的适用边界有何差异？ A 状态页、IM、邮件都可以随意用，区别不大 B 状态页对外公开、IM 即时内部、邮件正式异步，按受众场景选渠道并让状态页为对外单一源 ✓ 正确答案 C 事故沟通只用 IM 就够了 D 邮件是最快的沟通方式
# 31. 事故沟通与状态页的常见误区（隐瞒细节/过度承诺/无负责人/不更新）有哪些，正确的事故沟通节奏与状态页模板如何设计？ A 事故沟通要隐瞒细节、多承诺，以免影响信任 B 状态页可以随便承诺恢复时间 C 事故沟通只发一次就完事 D 避免隐瞒/过度承诺/无负责人/不更新，用"初步→过程→恢复→总结"节奏和规范模板坦诚沟通 ✓ 正确答案
# 32. 生产事故中如何用状态页对外沟通，模板、事件时间线与复盘如何联动？ A 状态页只用于对外发布，与复盘无关 B 状态页沟通完就结束，无需复盘 C 状态页时间线不需要记录 D 用规范模板+完整时间线，并让状态页与复盘联动形成对外沟通闭环 ✓ 正确答案
