# 1. 事故响应中的指挥与沟通机制中 Incident Commander 角色、状态更新模板与升级路径如何设计 A IC 应亲自处理所有技术细节 B 升级路径会导致信息混乱，应避免 C 所有成员共享决策权以保证一致 D IC 作为唯一决策权威负责指挥协调，用统一状态模板同步信息，并设计多级升级与交接路径 ✓ 正确答案
# 2. 事故定级（SEV/P0-P3）的标准制定与响应流程联动中不同级别对应的响应时间、升级路径与参与角色 A 定级标准无需明确，靠感觉即可 B 按影响范围与严重程度定级，级别越高响应越快、升级越短、角色越多，且可动态调整 ✓ 正确答案 C 所有级别采用相同响应时间 D 定级一旦确定不可更改
# 3. 复盘时间线（timeline）基于监控/日志/聊天记录的客观还原中多源时间对齐、关键事件标注与因果链梳理 A 应统一多源时间对齐，标注关键事件并区分事实与推断，依据证据梳理因果链 ✓ 正确答案 B 时间线凭记忆还原即可 C 聊天记录不可作为时间线依据 D 相关性即可视为因果
# 4. 把复盘结论转化为改进项并跟踪闭环中 action item 的 Owner、期限、验证标准与逾期治理机制 A 改进项只要列出即可，无需跟踪 B 验证标准可有可无 C 每个改进项需明确 Owner、期限、验证标准，并纳入跟踪系统定期评审，逾期升级治理 ✓ 正确答案 D 改进项完成即视为真正解决
# 5. 如何组织一场 blameless postmortem，即关键议程（时间线还原、根因分析、改进项）与产出物（postmortem 文档、action items） A 复盘目的是找出责任人 B 议程聚焦时间线还原、根因分析与改进项，产出 postmortem 文档与带 Owner/期限/验证标准的 action items，且聚焦系统而非追责 ✓ 正确答案 C 复盘只需口头总结 D 根因分析应止步于人为失误
# 6. 5 whys 与鱼骨图在根因分析中的实际运用，即如何避免「人为操作失误」作为终点并深入系统与流程层面 A 追到"人为失误"即可停止 B 应结合 5 whys 与鱼骨图，把人为失误作为起点追问到系统/流程/工具层面，而非作为终点 ✓ 正确答案 C 人出错的根因只能是自身 D 根因分析只需列出现象
# 7. 事后改进的两阶段实践中紧急缓解与长期根治如何拆分管理以避免只做临时修复 A 紧急缓解后无需再根治 B 长期根治可以无限延期 C 两阶段完全等价 D 紧急缓解止损、长期根治除根，需分别管理并跟踪长期项，避免临时修复被当作终解 ✓ 正确答案
# 8. 变更管理如何与可靠性目标联动，即变更评审、灰度发布与回滚预案如何设计？ A 变更只要上线成功即可，无需回滚 B 回滚预案只在评审时口头确认即可 C 灰度发布会降低上线效率，应放弃 D 通过变更评审、灰度发布与回滚预案控制风险，并监控 SLO 指标与变更失败率联动可靠性 ✓ 正确答案
# 9. 复盘文化的建设中领导层支持、无惩罚氛围、跨团队分享与定期回顾改进项完成率 A 复盘文化只需靠自发自觉 B 需领导层示范与无惩罚氛围，跨团队分享经验，并定期回顾改进项完成率驱动闭环 ✓ 正确答案 C 无惩罚氛围会纵容错误 D 复盘结果无需跨团队分享
# 10. 如何使用项目模板/脚手架工具（如 copier）统一运维自动化项目的结构与规范，提升可维护性？ A 项目结构随意即可，不影响维护 B 规范会降低开发效率，应避免 C 脚手架工具只适合新项目，无法更新已有项目 D 用 copier 模板统一目录结构、配置与规范，支持参数化生成与模板更新，提升可维护性 ✓ 正确答案
# 11. 如何度量复盘机制的有效性，即改进项完成率、同类故障复发率与 MTTR 改善趋势 A 复盘开过会就算有效 B 复发率与复盘有效性无关 C 用改进项完成率、同类故障复发率与 MTTR 改善趋势度量，且三者关联，驱动长期根治闭环 ✓ 正确答案 D 完成率越高一定越好，无需看效果
# 12. 如何建设故障知识库与 runbook 使复盘经验可被检索复用，即文档模板、标签体系、定期评审与更新 A 知识库只需堆砌文档即可 B 用统一模板与标签体系组织，复盘经验沉淀入库并定期评审更新，保证可检索复用 ✓ 正确答案 C 知识库无需检索，靠人脑记忆 D runbook 更新一次即可永久有效
# 13. 用 DORA 指标（部署频率/变更前置时间/变更失败率/MTTR）衡量可靠性工程成效，与复盘改进如何联动 A DORA 只衡量部署速度，与可靠性无关 B 变更失败率升高无需关注 C 用部署频率/前置时间/失败率/MTTR 衡量成效，并联动复盘改进，以改变失败率与 MTTR 验证改进 ✓ 正确答案 D DORA 指标无法量化改进效果
# 14. 运维自动化与平台化 在不同规模（10/100/1k/10k 实例）下的扩展性策略？ A 所有规模都应一步到位用 Kubernetes B 脚本在小规模不需要 C 规模扩大只需加机器，无需平台化 D 应随规模渐进演进，小规模用脚本、大规模用平台化，按当前瓶颈选型避免过度设计 ✓ 正确答案
# 15. 运维自动化脚本与工具如何保证幂等性，幂等设计的原则与验证方法是什么？ A 幂等意味着脚本只能执行一次 B 幂等脚本无法重试 C 幂等性只影响效率，不影响正确性 D 应遵循先检查后执行、以状态为目标等原则，并通过重复执行与状态比对验证幂等 ✓ 正确答案
# 16. 事故复盘如何驱动监控与告警补齐，即发现监控盲区后如何跟进、验证与闭环？ A 复盘定位监控盲区，把补齐作为 action item 并验证新告警能命中事故特征，形成闭环 ✓ 正确答案 B 复盘与监控无关 C 加一条告警即可，无需验证 D 监控盲区无法从复盘发现
# 17. 可靠性测试的常态化中故障注入演练与容量测试如何纳入迭代节奏并与复盘结论对齐 A 可靠性测试只在出事时做一次 B 可靠性测试与迭代节奏无关 C 把故障注入与容量测试纳入迭代节奏，并与复盘结论对齐，用测试验证改进并防止复发 ✓ 正确答案 D 复盘结论无需转化为测试用例
# 18. 复盘会议如何高效组织，即会前准备、时间盒控制与聚焦根因的引导技巧？ A 会前准备资料、设定时间盒并聚焦根因引导，收敛到可执行改进项 ✓ 正确答案 B 复盘会前无需准备，现场从头还原 C 复盘时间越长越好 D 复盘应聚焦找出责任人
# 19. 如何从多次事故复盘中识别系统性风险，并推动跨团队的专项治理与长期改进？ A 每次事故单独处理即可，无需汇总 B 专项治理只需各团队自行其是 C 系统性风险无法从复盘识别 D 从多次复盘聚类识别共性薄弱点，推动跨团队专项治理，并用复发率验证长期改进 ✓ 正确答案
