事故复盘与可靠性工程

• 掌握 Incident Commander（IC）角色的职责与单一决策权
• 理解状态更新模板与信息同步的设计
• 掌握升级路径与接管的时机

Incident Commander 是事故响应中的唯一决策权威，负责指挥协调而非亲自处理技术细节，其核心职责是：判定事故等级、分配任务给各专业角色、掌控全局进展、对外发布统一信息。IC 的设立避免了"多人同时指挥"的混乱，让技术专家专注于调查处置。状态更新模板应统一信息结构，通常包含：当前状态、影响范围、已采取措施、下一步计划、升级状态与时间点，通过统一状态页或频道定期同步，保证所有相关方信息一致。升级路径设计为多级：当事故超出当前 IC 能力范围、时间超过预期或影响扩大时，自动/手动升级到更高级别（如资深 IC、管理层），并完成正式的指挥权交接。设计中要明确"何时升级、通知谁、谁接管"，避免延误与信息断层。

面试官关注候选人对"指挥权威单一化"的理解。回答应体现 IC 的决策权与分工、统一状态模板、以及多级升级与交接的机制，避免指挥混乱。

• 掌握事故定级（SEV/P0-P3）的判定标准
• 理解定级与响应流程的联动
• 掌握不同级别对应的响应时间、升级与角色

事故定级依据"影响范围与严重程度"划分，通常分 SEV1（P0，全站性/核心业务不可用）、SEV2（P1，核心功能受损但可用）、SEV3（P2，局部/非关键影响）、SEV4（P3，无实际影响）。定级标准需明确可判定的指标（如用户可见性、营收影响、受影响用户数、合规风险），避免主观判断。定级与响应流程联动：级别越高，响应时间越短（SEV1 分钟级响应、SEV2 及时响应）、升级路径越短（SEV1 直达管理层）、参与角色越多（SEV1 需 IC、各专业团队、管理层、沟通）。定级不是静态的，事故过程中可能升级或降级，需按更新的影响重新定级并调整响应。定级标准制定后要宣贯、演练，确保一线能快速正确判定。

面试官关注候选人对"定级驱动响应"的理解。回答应体现定级标准、与响应时间/升级/角色的联动、以及动态调整机制。

• 掌握多源数据（监控/日志/聊天）的时间对齐
• 理解关键事件标注与时间线构建
• 掌握因果链梳理避免主观臆断

复盘时间线是还原事故"发生了什么、何时发生"的客观依据。多源时间对齐是前提：监控、应用日志、系统日志、聊天记录使用不同时钟，需统一到 UTC 并处理时钟偏差，确保事件时间可比。关键事件标注：按时间顺序标注告警、错误日志、变更、重启、人工操作等节点，标注来源与证据。因果链梳理：把看似孤立的事件按"先后+因果"连接，识别"触发点→放大→业务影响"的链路，避免把相关性当因果。构建时间线要区分"事实"与"推断"：基于日志/监控的事实明确标注，基于经验的推断单独说明，避免事后诸葛亮。最终时间线应可回溯、有证据支撑，成为根因分析与改进的基础。

面试官关注候选人对"客观还原"的严谨性。回答应体现多源时间对齐、事实与推断区分、因果链梳理，且结论有证据支撑。

• 掌握改进项（action item）的要素
• 理解跟踪闭环与验证标准
• 掌握逾期治理机制

复盘结论要转化为可执行的改进项（action item），每个改进项需包含：明确的 Owner（谁负责）、期限（何时完成）、验证标准（如何判定完成）、优先级（区分紧急与长期）。改进项要"可执行、可衡量"，避免笼统（如"加强监控"应细化为"对 X 增加 Y 告警并验证 Z"）。跟踪闭环需要统一管理：纳入工单/看板系统，定期评审进度，超过期限自动升级提醒。验证标准是闭环的关键——改进项完成不代表真正解决，需验证其有效性（如新告警能否命中本次事故特征）。逾期治理机制包括：逾期提醒、升级到负责人上级、复盘时评审未完成项。核心是"改进项不是清单，而是必须闭环的承诺"，避免复而不改。

面试官关注"复盘→改进→闭环"的完整性。回答应体现改进项四要素、验证标准、跟踪系统与逾期治理机制。

• 掌握 blameless postmortem 的议程结构
• 理解根因分析与改进项产出
• 掌握 postmortem 文档与 action items 的规范

blameless postmortem 的核心是"聚焦系统而非追责"。典型议程：时间线还原（基于监控/日志客观呈现事件）、根因分析（用 5 whys/鱼骨图深入系统与流程层面）、改进项讨论（识别可执行的 action items）。会议组织上，需提前准备时间线与资料、限制时长、聚焦根因引导、避免跑题与相互指责。产出物包括：postmortem 文档（记录事件概要、时间线、根因、影响、改进项）与 action items（带 Owner、期限、验证标准）。文档要清晰、可检索、可复用。关键是把"人为失误"转化为系统/流程改进（如"为什么没有告警""为什么回滚失败"），并确保每个结论都有证据。blameless 是态度也是方法，让参与者敢于如实呈现。

面试官关注候选人对"复盘议程与产出物"的完整掌握。回答应体现时间线、根因、改进项三大议程、blameless 引导、以及文档与 action items 的规范。

• 掌握 5 whys 与鱼骨图的方法
• 理解分析深度的把握
• 掌握避免人为失误作为终点的技巧

5 whys 通过连续追问"为什么"回溯根本原因，鱼骨图（因果图）从人、机、料、法、环等维度发散排查可能原因，两者常结合使用。运用时要警惕"人为失误"作为终点——人的失误几乎总是系统/流程缺陷的显现。深入系统层面的技巧：追问"为什么人容易出错"（如缺乏检查、告警缺失、文档过时、疲劳）、"为什么系统允许这个错误发生"（如缺少防呆、缺少回滚）、"为什么流程没有拦截"。要把"人"作为起点而非终点，从"谁做错了"转向"什么环境促使出错"。例如操作失误背后可能是权限过大、缺少双人复核、变更流程不完善。关键是持续追问到系统、流程、工具层面，才能找到真正可改进因。

面试官关注候选人对"根因分析深度"的把握。回答应体现 5 whys/鱼骨图用法、把人为失误转化为系统缺陷追问的技巧。

• 掌握紧急缓解与长期根治的区分
• 理解两阶段的优先级与衔接
• 掌握避免只做临时修复的机制

事故后改进分为两阶段：紧急缓解（short-term mitigation）是快速恢复业务、控制风险的临时措施（如重启、回滚、临时扩容、禁用功能），目标是尽快止损；长期根治（long-term fix）是彻底解决根因的永久性改进（如代码修复、架构改造、监控补齐、流程优化），目标是防止复发。拆分管理的关键：紧急缓解虽快但往往"治标"，若长期根治未跟进，同类事故会复发。管理上需为两阶段分别建立 action item，明确长期根治的 Owner、期限与验证标准，避免紧急缓解项目被"默认为已解决"。衔接机制：紧急缓解完成时主动触发长期根治立项，定期复盘检查长期项进度。关键认知是"恢复业务≠修复根因"，紧急缓解只是争取时间，长期根治才是终点。

面试官关注候选人对"临时与根治"的清醒区分。回答应体现两阶段的目的差异、拆分与衔接机制、以及避免临时修复被当作最终方案。

• 掌握变更管理流程与评审要点
• 理解灰度发布降低变更风险
• 掌握回滚预案与可靠性联动

变更管理是可靠性的重要防线，目标是"降低变更引入故障的概率"，与 SLO 联动。变更评审关注：变更内容与影响范围、风险等级、回滚方案、灰度计划、监控告警是否就绪。灰度发布把变更分批次推给部分用户/实例，观察指标稳定后再扩大，若异常可快速回滚，控制了爆炸半径。回滚预案是评审的必备项：回滚方式、回滚触发条件、回滚后验证，确保变更失败可快速恢复。与可靠性目标联动：变更期间监控 SLO 类指标（成功率、延迟、错误率），符合预期才继续灰度；变更失败率本身是 DORA 核心指标，用于衡量变更质量。高影响变更需更严格评审、更小灰度步长、更前置的回滚演练。核心是"变更可审计、可灰度、可回滚"。

面试官关注变更管理对可靠性的保障。回答应体现评审、灰度、回滚三要素，以及用 SLO 指标与 DORA 变更失败率联动可靠性。

• 掌握复盘文化的要素
• 理解领导层支持与无惩罚氛围的作用
• 掌握跨团队分享与改进项完成率回顾

复盘文化的核心是"从事故中学习而非惩罚"。领导层支持是前提：领导以身作则参与复盘、不责罚主动上报者、为改进项提供资源，才能让团队敢于如实呈现。无惩罚氛围（blameless）是关键：复盘聚焦系统与流程，区分"无意失误"与"重大过失"，让失败成为学习机会。跨团队分享扩大学习价值：把复盘结论与经验分享给其他团队，避免"同一事故在不同团队重演"，形成组织级知识复用。定期回顾改进项完成率衡量复盘有效性：完成率低说明复盘流于形式或资源不足，需治理。复盘文化是"制度+示范+习惯"的长期建设，靠领导力与机制共同推动，而非口号。

面试官关注复盘文化的系统性建设。回答应体现领导支持、无惩罚氛围、跨团队分享、以及用改进项完成率回顾驱动闭环。

• 掌握脚手架工具（copier）的作用
• 理解统一项目结构与规范的价值
• 掌握模板化提升可维护性的做法

运维自动化项目若结构随意、命名不规范，会大幅降低可维护性。脚手架工具（如 copier）通过模板生成项目骨架，统一目录结构、配置、脚本入口、文档与测试框架，让新项目"开箱即用且有规范"。copier 支持模板化、参数化与更新：定义项目模板（含目录布局、变量、钩子），创建项目时根据参数生成对应用例；模板更新后可通过 copier update 同步到已有项目。统一规范的收益：降低新人上手成本、减少重复配置、保证代码风格一致、便于后续扩展与维护。实施上需设计一个高质量的模板，沉淀团队最佳实践（目录、命名、日志、错误处理、CI）。工具只是载体，核心是把"约定"固化为"模板"，让规范自动生效。

面试官关注候选人对"规范化落地"的工具化理解。回答应体现脚手架工具的作用、统一结构规范的价值、以及模板更新与最佳实践沉淀。

• 掌握复盘有效性的度量指标
• 理解指标间的关联
• 掌握用指标驱动复盘改进

复盘机制的有效性需用指标度量，否则容易"为复盘而复盘"。关键指标：改进项完成率（复盘产生的 action items 按期完成的比例，低则说明复盘流于形式或资源不足）；同类故障复发率（相同根因/模式的事故是否复发，复发说明长期根治未落实）；MTTR 改善趋势（平均恢复时间是否随复盘改进而下降，反映处置能力提升）。三个指标相互关联：完成率高→复发率下降→MTTR 改善。度量时需建立基线、定期回顾（如月度/季度）、并把结果反馈给复盘机制（如改进项逾期治理）。同时要避免"指标失真"（如只报完成率不报效果）。核心是"复盘好不好，用复发率与 MTTR 说话"，而非形式上的会议产出。

面试官关注候选人对"复盘效果可度量"的理解。回答应体现完成率、复发率、MTTR 三类指标及其关联，并说明如何驱动闭环。

• 掌握故障知识库与 runbook 的组织
• 理解文档模板与标签体系
• 掌握定期评审与更新机制

故障知识库与 runbook 的价值在于"经验可复用、可检索"。建设要点：文档模板统一（故障记录含现象、根因、处置、规避、相关日志/告警），runbook 含触发条件、步骤、预期结果、回滚。标签体系支撑检索：按系统、故障类型、根因类别、影响级别、处置动作打标签，便于按场景检索与统计。检索复用强调"可查找"：统一命名、标签完整、全文可检索，让复盘经验在下次故障时被快速找到。更新机制：故障复盘后把新经验沉淀入库，定期评审（如按季度）清理过期内容、更新 runbook 与系统变更，避免知识库"积灰"。关键是把"这次的经验"变成"下次的预案"，让知识库成为活文档。

面试官关注知识的"可检索复用"。回答应体现模板、标签、检索与定期更新，让复盘经验转化为可复用的 runbook 与预案。

• 掌握 DORA 四指标的定义
• 理解指标衡量工程成效
• 掌握与复盘改进的联动

DORA 四指标用于衡量软件交付与可靠性：部署频率（Deployment Frequency，多久发布一次）、变更前置时间（Lead Time for Changes，从代码到上线的时间）、变更失败率（Change Failure Rate，变更导致故障的比例）、MTTR（恢复时间）。理想状态是"高部署频率、短前置时间、低失败率、快恢复"，说明交付快且稳定。用 DORA 衡量可靠性工程成效：跟踪指标变化验证改进措施（如自动化、灰度、复盘）是否有效。与复盘改进联动：变更失败率上升→复盘变更流程问题；MTTR 长→复盘处置能力与 runbook；部署频率低→复盘交付瓶颈。DORA 指标可作为复盘改进的"效果检验"，让可靠性改进有量化依据，而非凭感觉。

面试官关注用数据衡量可靠性工程。回答应体现 DORA 四指标定义、用其验证改进成效、以及与复盘改进的联动机制。

• 掌握不同规模下自动化/平台化的差异
• 理解随规模演进的技术选型
• 掌握避免过度设计与不足设计的平衡

自动化与平台化需匹配规模，避免"小马拉大车"或"大马拉小车"。10 实例级：脚本为主，用 shell/Ansible 等简单脚本+配置管理，重点记录与可复现，无需复杂平台。100 实例级：引入配置管理与 CI/CD，用 Ansible/Terraform/容器编排，建立统一基础镜像与发布流程，监控告警体系化。1k 实例级：需要平台化，引入 Kubernetes、IaC、统一监控日志（Prometheus/Grafana/ELK）、SRE 实践，把常用能力抽象为自助平台。10k 实例级：需要大规模平台与多租户、弹性伸缩、混沌工程、高级容量规划，强调自动化可靠性、自助服务与治理。演进原则：按需渐进，避免过早引入重平台；每阶段先解决当前瓶颈，保持自动化与手动操作的平衡。

面试官关注候选人对"规模演化"的认知。回答应体现各规模的技术选型差异、渐进演进原则与避免过度设计。

• 掌握幂等性的定义与价值
• 理解幂等设计的原则
• 掌握幂等验证方法

幂等性指"同一操作执行多次结果一致"，是自动化可靠性的基础——重复执行不会产生副作用或错误。幂等设计原则：先检查后执行（先判断状态，已满足则跳过，如"不存在才创建"）；用确定性操作（以最终状态为目标，而非"新增"）；处理部分失败（支持重试，中断后可继续）；避免不可控的追加（如日志重复、端口重复绑定）。实现手法：用条件判断（if 存在性检查）、用 state 化（Ansible 的 idempotent 模块）、使用唯一键/幂等标识。验证方法：对同一输入重复执行多次，检查结果一致；用 --check 试运行；比较执行前后状态；在 CI 中做幂等测试。幂等让脚本可安全重跑、可并行、可恢复，是高质量自动化的标志。

面试官关注自动化脚本的健壮性。回答应体现幂等定义、设计原则（先检查后执行、确定性）、与验证方法。

• 掌握复盘识别监控盲区的方法
• 理解监控补齐的跟进与验证
• 掌握闭环机制

复盘常发现"这次事故本可被监控/告警提前发现"，驱动监控补齐。识别盲区：复盘时检查时间线，找出"最初出现异常信号的时间点"与"首次告警时间点"的差距，定位缺监控或告警配置缺失的环节。跟进：把监控补齐作为 action item（明确指标、阈值、告警方式、Owner、期限）。验证：补齐后需验证有效性——用历史数据回放确认新告警能命中本次事故特征、模拟故障确认告警触发、评估误报率避免告警噪音。闭环：验证通过后纳入监控体系，定期在新事故中检验。关键是"监控盲区找到后要补到能真正拦截同类事故"，而非简单加一条告警。复盘与监控形成"发现盲区→补齐→验证→再发现"的循环。

面试官关注复盘对监控的驱动。回答应体现识别盲区、补齐跟进、有效性验证与闭环机制。

• 掌握可靠性测试的类型
• 理解纳入迭代节奏的方法
• 掌握与复盘结论对齐

可靠性测试常态化指把故障注入、容量测试等纳入常规迭代节奏，而非出事才做。故障注入（混沌工程）验证系统在异常下的韧性，容量测试验证系统在负载下的表现。纳入迭代节奏：在 CI/CD 流水线或定期发版中编排可靠性测试（如每次发版跑关键故障注入、定期跑容量压测），与功能测试并行，确保可靠性不随迭代退化。与复盘结论对齐：回到"这次事故暴露的薄弱点"，把复盘产生的改进项（如某组件需加固、容量需扩容）转化为对应的可靠性测试用例，纳入常态化测试，验证改进是否真正生效并防止复发。核心是"测试不是一次性，而是持续验证可靠性假设"，让可靠性成为迭代的一部分。

面试官关注可靠性测试的持续化。回答应体现故障注入与容量测试纳入迭代节奏、以及与复盘结论对齐形成验证闭环。

• 掌握复盘会前准备
• 理解时间盒控制
• 掌握聚焦根因的引导技巧

高效复盘的关键在"会前准备充分、会中节奏可控、聚焦根因"。会前准备：提前收集事件时间线、监控日志、聊天记录，让参与者先读资料，避免会议现场从头还原；明确会议目标与主持人。时间盒控制：为复盘设定时长上限（如 60-90 分钟），分阶段分配时间（时间线、根因、改进项），超时项以 action item 跟进，避免无限讨论。聚焦根因的引导技巧：主持人用提问引导（"为什么没有告警""为什么回滚失败"），避免陷入细节与指责；对跑题及时拉回；区分"事实"与"推断"；把讨论收敛到可执行的改进项。参会人员精简（关键角色+相关方），避免无关人员浪费。核心是"复盘产出 action items 而非情绪"。

面试官关注复盘的组织效率。回答应体现会前资料准备、时间盒控制、聚焦根因的引导与收敛到改进项。

• 掌握从多次复盘识别模式
• 理解系统性风险的识别方法
• 掌握跨团队专项治理与长期改进

单次事故反映局部问题，多次复盘可识别系统性风险（跨系统的共性薄弱点）。识别方法：汇总多次事故的根因与模式，分析共性（如"变更缺乏评审""依赖脆弱""监控盲区""容量不足"），用 Pareto/聚类找出高频、高影响的共因。识别后推动跨团队专项治理：把系统性风险作为一个专项项目（而非散落在各团队），明确牵头团队、治理目标、资源与期限，成立专项小组推进。长期改进：对系统性风险做根因治理（如统一变更流程、加固公共依赖、补齐公共监控），跟踪效果（相关事故复发率是否下降）。核心是"从点状事故到面状治理"，避免"每个团队各自修自己的"而系统性根因无人负责。

面试官关注组织级风险治理能力。回答应体现从多次复盘识别共性模式、跨团队专项治理与用复发率验证长期改进。