Reliability & Graceful Degradation: 解释事故复盘的要点与产出。

Core Concept: 无指责文化、聚焦系统性根因（多因素 + 触发条件）、量化影响、产出可验证且有时限的行动项，并回填监控、测试与演练。

数学机理：<strong>事故复盘（postmortem / incident review）</strong>——(1) <strong>无指责文化（blameless）</strong>——(a) <strong>原则</strong>——人是会犯错的，系统应设计得容错；聚焦'为什么系统允许这个错误造成事故'而非'谁犯了错'；(b) <strong>效果</strong>——鼓励如实、及时地披露信息（否则会隐瞒导致更大损失）；(c) <strong>注意</strong>——无指责不等于无责任（行动项仍需负责人）。(2) <strong>时间线（timeline）</strong>——(a) <strong>关键节点</strong>——首次异常发生（T0）、首次被检测（MTTD 起点）、首次响应、缓解（止血）、恢复、复盘；(b) <strong>度量</strong>——MTTD（检测时间）、MTTA（响应时间）、MTTR（恢复时间）；(c) <strong>目的</strong>——暴露检测与响应的薄弱环节（很多事故是'检测慢'而非'发生'）。(3) <strong>根因与触发</strong>——(a) <strong>潜在条件（latent conditions）</strong>——长期存在的系统缺陷（如缺少超时、无熔断、单点、测试不足）；(b) <strong>触发事件（trigger）</strong>——直接引发事故的变更/流量/故障；(c) <strong>多因素</strong>——真实事故通常是'多个潜在条件 + 一个触发'叠加（瑞士奶酪模型）；(d) <strong>故</strong>'单一根因'往往是简化，应识别系统性因素。(4) <strong>影响量化</strong>——(a) 受影响用户数/请求数；(b) 持续时长；(c) 业务损失（收入/转化）；(d) SLO 消耗（error budget 用掉多少）；(e) 数据影响（是否有数据损坏/丢失）。(5) <strong>行动项（action items）</strong>——(a) <strong>可验证</strong>——具体、可度量（'为 X 接口加超时 500ms' 而非 '提升可靠性'）；(b) <strong>有负责人与时限</strong>；(c) <strong>分类</strong>——(i) <strong>检测</strong>——补监控/告警；(ii) <strong>预防</strong>——加熔断/超时/冗余/测试；(iii) <strong>缓解</strong>——加降级/限流；(iv) <strong>流程</strong>——变更评审/演练；(d) <strong>跟踪</strong>——行动项需被跟踪至完成（否则复盘白做）。(6) <strong>回填</strong>——(a) <strong>监控</strong>——补上'本应检测到'的指标与告警；(b) <strong>测试</strong>——加回归测试与故障注入；(c) <strong>演练</strong>——把该场景纳入混沌演练；(d) <strong>文档</strong>——更新 runbook。(7) <strong>共享</strong>——(a) 复盘文档公开（组织内）；(b) 提炼通用教训；(c) 避免重复事故。(8) <strong>常见反模式</strong>——(a) <strong>指责个人</strong>（掩盖系统问题）；(b) <strong>停在表面根因</strong>（'某人操作失误' 而非 '为何系统允许该操作'）；(c) <strong>行动项模糊无时限</strong>；(d) <strong>复盘后不跟踪</strong>；(e) <strong>只复盘大事故</strong>（小事故是预警信号）。<strong>与其他问题的关系</strong>——(a) 与监控告警（MTTD）；(b) 与降级熔断（预防）；(c) 与容量规划（过载事故）；(d) 与混沌演练（验证）。<strong>度量</strong>——(a) MTTD/MTTA/MTTR；(b) 重复事故率；(c) 行动项完成率与及时率；(d) 检测覆盖率。

深度剖析与工程权衡：① <strong>无指责文化是复盘有效的前提</strong>——否则信息被隐瞒；面试中能解释这点是深度理解的标志。② <strong>区分潜在条件与触发事件</strong>——事故多为多因素叠加（瑞士奶酪模型）。③ <strong>很多事故是检测慢而非发生</strong>——MTTD 常比根因更值得改进。④ <strong>行动项必须可验证且被跟踪</strong>——否则复盘白做。⑤ <strong>回填监控与演练是闭环</strong>——把教训固化到系统。⑥ <strong>小事故是预警</strong>——只复盘大事故会错失信号。⑦ <strong>面试要点</strong>——被问怎么做事故复盘，应给出'<strong>无指责 + 时间线（MTTD/MTTR）+ 潜在条件与触发 + 影响量化 + 可验证行动项 + 回填监控/测试/演练 + 跟踪闭环</strong>'；能区分潜在条件与触发、指出检测慢是深度理解的标志。