# 1. 你的 leader 长期不作为（不 review、不排期、不挡需求），你想向 skip-level 反馈，怎么把握边界不变成告状？ A 先内部解决，升级时用"事实+影响+寻求帮助"而非"告状"，聚焦问题而非人身 ✓ 正确答案 B 越级反馈应该直接历数 leader 的缺点 C 越级反馈是唯一有效手段，越快越好 D 反馈 leader 不作为就是告状，不该做
# 2. skip-level 1:1 中如何既反映团队真实问题又保护直属 leader 的关系？ A skip-level 1:1 就是向大老板告直属 leader 的状 B 用"团队层面问题"而非"归咎 leader"的方式，建设性、事实化地反映并保护关系 ✓ 正确答案 C 反映真实问题就必然伤害 leader 关系 D skip-level 1:1 只报喜不报忧
# 3. leader 的 leader 直接给你派活与 leader 安排冲突，你怎么处理？ A 大老板派活就该直接执行，无视 leader B 先对齐直属 leader 让其决策优先级，必要时由 leader 间沟通，不越级接活也不传话 ✓ 正确答案 C 应拒绝大老板的派活 D 越级派活是常态，直接两头做
# 4. 你发现 leader 向上虚报进度或隐瞒风险，要不要越级反映、怎么反映？ A 先私下给纠错机会，不纠正时用"事实+证据+风险"走合规通道反映，聚焦风险而非人身 ✓ 正确答案 B 发现 leader 虚报进度就该装作没看见 C 虚报进度是 leader 的自由，与己无关 D 越级反映诚信问题必然自毁前程
# 5. 越级沟通被 leader 知道后关系恶化，你怎么修复？ A 越级被 leader 知道后关系已无法修复 B 主动坦诚沟通、重申尊重权威、用更透明的行动重建信任，关系可持续修复 ✓ 正确答案 C 越级后应该继续越级，不会加重矛盾 D 关系恶化是 leader 心胸狭隘，无需修复
# 6. skip-level 主动约你吃饭想了解团队情况，你该说多少真话？ A 说团队层面的客观事实，对 leader 相关负面用事实化建设性方式，既真实又保护关系 ✓ 正确答案 B skip-level 约谈就该全盘托出所有内幕 C skip-level 约谈只能打太极说客套话 D 该把同事的隐私和猜疑都告诉 skip-level
# 7. 跨级汇报后被 leader 问是不是去找他老板了，如何诚实回答又不激化矛盾？ A 诚实承认并说明初衷与内容，重申尊重权威，把话说开而非辩解对抗 ✓ 正确答案 B 被问越级就该死不承认 C 越级后应该回避 leader 的所有追问 D 被问越级就承认是去告状
# 8. 什么情况下越级沟通是必要的？什么情况下是自毁前程？ A 越级沟通在任何情况下都不应该做 B 越级沟通只考虑自己利益即可 C 只要想越级就随时可以，无需理由 D 正当越级（重大风险/内部无效/为团队）必要，不当越级（未先沟通/为个人/无事实）自毁前程 ✓ 正确答案
# 9. 你的 oncall 告警没分 owner（所有人收到），你怎么看怎么推动 A 用"owner 明确+精准路由+告警归属表"让告警找到责任人，降低噪音提升响应 ✓ 正确答案 B 告警全员广播能让更多人看到，更安全 C 告警不需要 owner，谁看到谁处理 D 告警路由会拖慢响应
# 10. 你的 oncall 人手不够（每次都是你），你怎么看怎么推动轮值 A oncall 能者多劳，一个人扛就行 B oncall 轮值会让团队更累 C 用轮值+交接+shadow+补偿建立团队 oncall 机制，消除单点故障并保证可持续 ✓ 正确答案 D oncall 是个人能力展示，不该分给别人
# 11. 你的 oncall 告警 dashboard 不准，你看怎么推动 A 监控 dashboard 不准无所谓，能看个大概就行 B 梳理修正指标口径/数据源/阈值并定期校准，不准确的监控比没有监控更危险 ✓ 正确答案 C dashboard 不准是偶发，不必处理 D 监控数据准确性靠运气
# 12. 你的 oncall 告警 triggered by 第三方你看怎么推动 A 第三方告警不可控，只能忍 B 分类处理第三方告警（噪音去抖/真实故障对接追踪）并治理第三方依赖，化不可控为可控 ✓ 正确答案 C 第三方告警都该忽略 D 第三方告警只能由第三方自己解决
# 13. 你的 oncall 告警分级不清（P0 和 P3 混在一起），你怎么看怎么推动 A 用分级标准+分级响应策略+定期 review 校准，让 oncall 按轻重缓急响应 ✓ 正确答案 B 告警分级不重要，能不区分就别区分 C 所有告警都该按 P0 响应 D 分级越细越混乱
# 14. 你的 oncall 告警太多（每晚 20 个），你怎么看怎么推动降噪 A 告警越多越安全，oncall 就该多收 B oncall 疲劳是常态，无需处理 C 用去抖/聚合/自动恢复降级/校准阈值系统性降噪，聚焦真正重要的告警 ✓ 正确答案 D 告警数量永远不该减少
# 15. 公司空降一位新 leader，不了解你们系统的历史背景，上任第一周就要推翻两项既有架构决策，你如何用「现状/迁移成本/风险」简报对齐事实，再通过最小试点验证其方案，什么信号表明应该升级为正式反对？ A 新 leader 推翻架构决策就该直接服从，因为是新官 B 用现状/迁移成本/风险简报对齐事实，用最小试点验证，数据或风险不可控时升级正式反对 ✓ 正确答案 C 新 leader 的决策一定有道理，无需质疑 D 出现分歧就立刻升级反对，不用试点
# 16. 你的 oncall 告警没人 ack（其他人装睡），你怎么看怎么推动文化 A 用 ack 时限+未 ack 自动升级+ack 率考核+文化引导，让 ack 成为有约束的责任 ✓ 正确答案 B 没人 ack 说明团队不需要 ack C ack 是形式主义，可做可不做 D 告警 ack 应该靠自觉，无需机制
# 17. 你的 oncall 告警级别不合理（P3 叫醒你），你怎么看怎么推动分级 A 重新校准级别，只有 P0/P1 才非工作时间叫醒，让分级匹配响应方式 ✓ 正确答案 B P3 叫醒 oncall 是正常的，说明告警及时 C 所有级别都该半夜叫醒，确保不漏 D 告警级别无法调整，只能忍受
# 18. 你的 oncall 响应 SLA 严（5 分钟响应），你怎么看怎么 argue A oncall 就该 5 分钟内解决所有问题 B oncall 响应时间完全没法讨论 C SLA 越严越专业 D 区分响应与解决，用分级 SLA+实际数据+非工作时段例外，让 SLA 兼顾质量与可行性 ✓ 正确答案
# 19. 你的团队出 P1 事故但没人担任 Incident Commander，你怎么看怎么推动 A 事故处理无需统一指挥，大家各自处理即可 B 预先定义 IC 角色/职责/权限并设事故预案，让 IC 成为事故处理的指挥中枢 ✓ 正确答案 C P1 事故靠临场发挥就行 D IC 角色是多余的，多个人一起指挥更好
# 20. 你的团队出事故但 bridge 会议没秩序，你看怎么推动 A bridge 会议不用秩序，大家自由讨论更快 B 事故会议多吵吵才能尽快解决 C bridge 会议秩序由运气决定 D 用 IC 主持+固定议程+角色分工+会前异步同步，让 bridge 会议有序高效 ✓ 正确答案
# 21. 你的团队出事故但没人通知 stakeholders，你看怎么推动 A 事故是自己的事，不用通知 stakeholders B 建立清单+触发条件+通知方式+预案，主动通知是风险管理且避免信任受损 ✓ 正确答案 C 事故可以等恢复后再通知 stakeholders D 通知 stakeholders 会扩大影响，应隐瞒
# 22. 你的团队出事故时 Information Radiator（信息屏）不更新，你看怎么推动 A 信息屏不更新无妨，靠口头沟通就行 B 信息屏更新是锦上添花，非必需 C 事故处理无需可视化信息 D 明确更新负责人+内容+频率，让信息屏成为事故处理的单一信息源 ✓ 正确答案
# 23. 你的团队出事故时 bridge 会议有 30 人太多，你看怎么推动精简 A 事故 bridge 人越多越好，集思广益 B 区分核心与外围参与者，外围用静默/异步，精简 bridge 让核心团队专注 ✓ 正确答案 C 30 人 bridge 是正常的，无需处理 D 事故处理该让所有感兴趣的人都参与讨论
# 24. 你的团队出事故时 oncall 以为恢复了实际没恢复，你看怎么推动验证 A 感觉恢复了就宣布恢复，越快越好 B 用恢复标准+自动化验证+观察期确认恢复，避免误判导致事故反复 ✓ 正确答案 C 恢复验证浪费时间 D 恢复判断凭 oncall 直觉即可
# 25. 你的团队出事故时 oncall 手忙脚乱（缺 runbook），你看怎么推动 A 为常见故障编写 runbook 并沉淀知识库、复盘补充、定期演练，让 oncall 有章可循 ✓ 正确答案 B oncall 靠临场发挥就行，runbook 是多余的 C runbook 写出来就没人看，没意义 D 事故处理靠经验，不需要文档
# 26. 你的团队出事故时 role 不清（多人做同一件事），你怎么看怎么推动 A 事故时大家一拥而上处理，人多力量大 B 多人做同一件事更保险 C 事故角色分工是形式主义 D 预先定义角色与职责边界并按角色分配任务，让事故处理并行高效不重复 ✓ 正确答案
# 27. 你的团队出事故时 senior 工程师不在你看怎么推动 A senior 不在就只能等，事故处理暂停 B 事故处理必须等 senior 回来才能开始 C senior 不在时应该什么都不做 D 用 runbook 沉淀经验+升级路径+oncall 敢于担当，让事故处理不依赖单一个人 ✓ 正确答案
# 28. 你的团队出事故时你在 oncall 但 leader 抢着指挥，你看怎么 argue A leader 抢指挥就该直接对抗，坚持自己 B leader 指挥一定对，oncall 完全服从 C 先倾听再用事实依据 argue，明确 oncall 与 leader 分工，避免双重指挥 ✓ 正确答案 D 事故处理时任何人都该抢着指挥
# 29. 你的团队出事故时有人急着改代码不 review，你看怎么推动 A 紧急修复用最小改动+快速 review+灰度回滚兜底，快速且安全地恢复 ✓ 正确答案 B 事故紧急就该跳过 review 快速改 C 事故时 review 会拖慢恢复 D 紧急修复随便改，反正先恢复
# 30. 你的团队出事故时沟通频道多（bridge+IM+邮件）混乱，你看怎么推动收敛 A 事故沟通频道越多，信息越全 B 事故信息该分散在各处，各看各的 C 多频道同步是事故处理的正常态 D 明确主沟通频道+约定单一事实源+其他频道只做归档，收敛事故信息避免混乱 ✓ 正确答案
# 31. 你的团队出事故时 bridge 没人 lead（乱），你怎么看怎么推动 A bridge 没人 lead 就各自处理，无需头领 B 事故会议不需要主持人 C bridge lead 是多余的 D 明确 bridge lead 角色与职责，没人 lead 时主动担当，有 lead 才有序 ✓ 正确答案
# 32. 你的团队出事故时 oncall 经验不足（junior），你看怎么推动支持 A junior oncall 就该硬扛，才能成长 B 用 shadow+升级路径+培训+pair oncall 支持 junior，让其在安全中成长 ✓ 正确答案 C junior 不该参与 oncall D oncall 经验不足只能靠运气
