007：监控报警专项（SRE 稳定性 · 监控三板斧 / MTTx / 告警分级 / 事故响应）

监控报警专项（监控三板斧与可观测三支柱 · MTTx 指标族 · 告警分级 SEV · 黄金 15 分钟 · 事故响应全链路）

体系定位：监控报警专项（监控三板斧与可观测三支柱 · MTTx 指标族 · 告警分级 SEV · 黄金 15 分钟 · 事故响应全链路） 来源文件数：4（从 005_容灾止损专项.md 拆出：监控三板斧与 MTTx 段 + 009 章 + SRE 事故响应手册 1-7、9-12 节 + 附） 说明：内容原封不动拆出，仅调整标题层级与图片相对路径

📑 目录

• 1 SRE 稳定性工程：监控三板斧与 MTTx 指标族【2026-09-09 拆分】
• 2 SRE 与容灾监控
• 3 SRE 事故响应与容灾止损 —— 面试知识手册
• 3.1 事故响应体系总览（原理层）
  • 3.1.1 为什么需要「体系」而不是「救火」
  • 3.1.2 核心时间指标（面试高频）
  • 3.1.3 止损优先于根因（最重要的心法）
• 3.2 SEV 分级：原理、矩阵与踩线判定
  • 3.2.1 为什么要分级
  • 3.2.2 SEV 评级矩阵（可直接复用）
  • 3.2.3 踩线判定规则（面试爱问的模糊地带）
• 3.3 黄金 15 分钟：分诊（Triage）流程
  • 3.3.1 逐步清单（接告警后前 15 分钟）
  • 3.3.2 三条红线
  • 3.3.3 T0 定义的坑（细节但高频踩雷）
• 3.4 ICS 角色体系：职责边界与授权
  • 3.4.1 四角色卡（Google/PagerDuty 通用模型）
  • 3.4.2 兼任规则
  • 3.4.3 中国互联网语境下的三角色映射
• 3.5 事故沟通：三类模板与法律风险
  • 3.5.1 模板总览
  • 3.5.2 模板 1：内部 War-room 同步
  • 3.5.3 模板 2：Exec 简报
  • 3.5.4 模板 3：用户公告（Status Page / 客服口径）
  • 3.5.5 对外沟通的四条法律与口径红线（重点）
• 3.6 无责复盘（Blameless Postmortem）方法论
  • 3.6.1 为什么必须无责
  • 3.6.2 复盘文档标准章节
  • 3.6.3 5 Why 的正确用法与常见误区
  • 3.6.4 行动项质量标准
• 3.7 真实案例拆解：TikTok 美区大规模中断（2026-01）
  • 3.7.1 事件概要
  • 3.7.2 影响范围（量化）
  • 3.7.3 SEV1 定级依据
  • 3.7.4 5 Why 根因链（追到系统 / 流程层）
  • 3.7.5 行动项（7 条）
  • 3.7.6 四维预防措施
  • 3.7.7 这个案例在面试中怎么讲（核心洞察）
• 3.8 进阶：事故应急 Agent 协作系统设计
  • 3.8.1 问题定义：人工应急的三个耗时瓶颈
  • 3.8.2 核心架构决策：共享状态枢纽 > Agent 自由对话
  • 3.8.3 生命周期状态机
  • 3.8.4 三个 Agent 规格
  • 3.8.4.1 事故指挥官 Agent（IC）
  • 3.8.4.2 信息联络员 Agent（Liaison）—— 最低风险最高价值
  • 3.8.4.3 技术处理官 Agent（Handler）⚠️ 最高风险
  • 3.8.5 安全闸门（这是整个设计的生死线）
  • 3.8.5.1 自动 hotfix PR
  • 3.8.5.2 自动回滚 / SOP 执行（按爆炸半径分级）
  • 3.8.5.3 IC Agent 的自主边界
  • 3.8.5.4 影子模式（Shadow Mode）—— 上线前提
  • 3.8.5.5 可观测性、审计与 Kill Switch
  • 3.8.6 Agent 特有的失效模式（面试深水区）
  • 3.8.7 MVP 分期落地（按「价值 / 风险」比排序）
  • 3.8.8 技术栈
  • 3.8.9 实战化设计草案：字节容灾止损专项视角（一线落地版）
  • 3.8.9.1 一线痛点：为什么必须 Agent 化（你的真实场景）
  • 3.8.9.2 三 Agent 角色：你的设想 → 设计映射
  • 3.8.9.3 如何设计「协作机制」（面试官最爱追问）
  • 3.8.9.4 如何设计开发「Agent」（落地工程视角）
  • 3.8.9.5 面试话术模板（把一线经验讲成系统设计）
  • 3.8.10 P1 联络员 Agent：群摘要 Prompt + 影响矩阵 Schema（可跑骨架）
  • 3.8.10.1 影响矩阵 Schema（ImpactMatrix）
  • 3.8.10.2 群摘要 System Prompt（直接可用）
  • 3.8.10.3 增量摘要 Prompt（每轮调用）
  • 3.8.10.4 增量摘要 Agent 循环（断点续摘 + 广播）
• 3.9 最佳实践清单与反模式
  • 3.9.1 ✅ 最佳实践（可直接说的 20 条）
  • 3.9.2 ❌ 反模式（面试中说出来会显得很懂）
• 3.10 面试题库与参考答法
  • 3.10.1 基础层
  • 3.10.2 进阶层
  • 3.10.3 架构层
  • 3.10.4 AI / Agent 层（差异化亮点）
• 3.11 术语速查表
• 3.12 附：三份原始工程产出索引

1 SRE 稳定性工程：监控三板斧与 MTTx 指标族【2026-09-09 拆分】

| 容灾 | 可冗余、可切换、可恢复 | 没有冗余 = 没有底牌；没有切换 = 故障持续；没有恢复 = 数据业务丢了 | 可灰度≈可冗余；可监控≈可切换；可回滚≈可恢复 |

监控三板斧的另一说法（数据源版）：指标 Metrics（系统健康吗）+ 日志 Logs（发生了什么）+ 链路追踪 Traces（请求走到哪、哪慢了）—— 即 "可观测性三大支柱 / 三件套"。

MTTx 指标族（故障处理全生命周期时间线）：

故障发生 → MTTD 发现 → MTTA 响应 → MTTI 定位 → MTTP 止损 → MTTR 恢复

            (Detect)   (Acknowledge) (Identify)   (Patch/Mitigate) (Recovery)

关键点（面试加分）：

1. MTTR 是多义词：Repair（修复）/ Recovery（恢复）/ Resolve（解决）/ Respond（响应）都缩写成 MTTR；容灾语境下明确说 Mean Time To Recovery，避免歧义。趋势是拆成 MTTD/MTTA/MTTI 分别看，因为 "只看 MTTR" 看不出时间耗在哪个环节。

2. 可用性公式：A = MTBF / (MTBF + MTTR)——MTBF 决定 "多久坏一次"，MTTR 决定 "坏一次停多久"，共同决定可用性。

3. 容灾规划目标：RPO（Recovery Point Objective，恢复点目标）= 最多容忍丢多少数据；RTO（Recovery Time Objective，恢复时间目标）= 最多容忍停多久。MTTR 是 "实际恢复花了多久"，RTO 是 "约定最多停多久"，MTTR ≤ RTO 才算达标。

4. 定位时长 = MTTI（Mean Time To Identify / Investigate）；MTTP 全称 Mean Time To Patch / Mitigate（止损期指标，非 SRE 四大主流指标但业界有定义）。

面试速答：变更三板斧 = 可灰度 / 可监控 / 可回滚；监控三板斧 = 可发现 / 可告警 / 可定位（或指标 / 日志 / 链路三支柱）；容灾三板斧 = 可冗余 / 可切换 / 可恢复。故障处理链 MTTD（发现）→MTTA（响应）→MTTI（定位）→MTTP（止损）→MTTR（恢复），定位时长 = MTTI，容灾恢复核心 = MTTR（Mean Time To Recovery），配合 RPO/RTO 衡量容灾能力。

2 SRE 与容灾监控

体系定位：SRE 与容灾监控（事故响应 / 容灾止损 / 监控） 来源文件数：1（内容原封不动按来源保留）

📄

来源：008_sre-incident-response-interview-guide.md

3 SRE 事故响应与容灾止损 —— 面试知识手册

定位

：把「事故响应 Playbook + TikTok 美区大中断真实复盘 + 事故应急 Agent 协作系统设计」三份工程产出，重组为一份可直接用于面试准备的系统性知识文档。 覆盖

：原理 → 示例 → 最佳实践 → 解决方案 → 防御措施 → 面试答法。 适用岗位

：SRE / 稳定性工程 / 基础架构 / 平台工程 / AI Infra（Agent 方向）。 生成日期

：2026-07-15

3.1 事故响应体系总览（原理层）

3.1.1 为什么需要「体系」而不是「救火」

事故响应的本质矛盾：信息在爆炸性增长，而决策带宽是常数。

一次大事故里同时发生的事：告警刷屏、多团队涌入群聊、业务方追问影响、管理层要结论、工程师在并行排查。若没有体系，会出现三种典型失败：

体系的作用就是把这三件事分别托管给指挥、联络、处置三条独立轨道 —— 这就是 ICS（Incident Command System，源自美国消防应急指挥体系，被 Google SRE、PagerDuty、字节等广泛引入）。

3.1.2 核心时间指标（面试高频）

故障发生 ──▶ 被发现 ──▶ 被确认 ──▶ 开始止损 ──▶ 恢复 ──▶ 复盘闭环

     │  MTTD   │  MTTA    │   MTTM    │        │

     └─────────┴──────────┴───────────┴────────┘

                        MTTR

面试要点

：面试官问「你怎么衡量稳定性工作的成果」，标准答法不是「故障少了」，而是

「MTTD/MTTM 各降低多少 %，以及故障影响面（受影响用户 × 时长）下降多少」

。因为故障不可能归零，可控的是

发现速度

和

止损速度

。

3.1.3 止损优先于根因（最重要的心法）

原则：Mitigate first, root-cause later.

事故中最常见的认知错误是「先搞清楚为什么，再动手」。正确顺序是：

1\. 止血（回滚/切流/降级/限流）——恢复用户体验

2\. 稳定观察——确认指标回归

3\. 事后定位根因——在复盘阶段慢慢查

例外：数据一致性类故障（如脏数据在持续写入），此时盲目回滚可能扩大损失，需要先「止写」再决策。

面试话术：

" 我在容灾止损专项里定的第一条铁律是：

恢复服务优先于查明真相

。变更引发的故障 70%+ 可以靠回滚在 5 分钟内止血，而定位根因平均要 30 分钟以上。所以我们把『最近 30 分钟内有变更』做成分诊第一个必检项 —— 有变更先回滚，没变更再进排查链路。"

3.2 SEV 分级：原理、矩阵与踩线判定

3.2.1 为什么要分级

分级不是为了「贴标签」，而是为了自动化决策三件事：

1. 响应时效（多久必须有人上）

2. 升级范围（拉谁、要不要惊动高管）

3. 沟通节奏（多久同步一次、要不要对外公告）

没有分级，就会出现「小事惊动 CTO / 大事无人知晓」的双向错配。

3.2.2 SEV 评级矩阵（可直接复用）

注

：SEV0/SEV1 行中的「合规 / PR」是法务与公关职能，由管理层 / 外部协调接入，

非 war-room 常驻技术角色

；Comms Lead 仍是用户与内部的唯一信息出口，合规 / PR 只负责监管与法律口径。

3.2.3 踩线判定规则（面试爱问的模糊地带）

四条辅助判据：

1. 影响营收 / 核心转化 → 至少 SEV2

2. 用户可见且大面积 → 至少 SEV2，并同步准备对外公告

3. 数据丢失 / 安全暴露 → 直接 SEV1

4. 不确定时取高不取低（Over-escalate is cheap, under-escalate is fatal）

边界量化示例（把主观判断变成可执行规则）：

• 核心接口 p99 超标但失败率 < 5% 且可重试 → SEV3

• 失败率 ≥ 5% 或主流程无法完成 → SEV2

• 核心链路成功率 < 50% 或完全不可用 → SEV1

动态调整：影响扩大必须升级，收敛可降级，但降级需 IC 明确宣布并记录。

面试陷阱题

："一个功能只影响 0.1% 用户，但这 0.1% 是你最大的 KOL / 大客户，你定几级？" 答

：按「业务影响」而非「用户比例」定级。定级矩阵要有一条「大客户 / 合规相关 → 至少 SEV2」的旁路规则，并且这类事故即使技术影响小也必须走对外沟通流程。

3.3 黄金 15 分钟：分诊（Triage）流程

3.3.1 逐步清单（接告警后前 15 分钟）

SEV0/SEV1 加速

：上述各步须在

≤5 分钟

内压缩完成，15 分钟是通用上限而非目标。

3.3.2 三条红线

1. ❌ 分诊阶段不得独自回滚生产而不告知 IC —— IC 是唯一指挥权来源。

2. ❌ 不得在未确认影响面前对外发声 —— 错误公告的伤害大于晚 10 分钟发。

3. ❌ 不得让排查者兼任沟通者 —— 一心二用等于两件事都做不好（SEV1/2 强制角色分离）。

3.3.3 T0 定义的坑（细节但高频踩雷）

T0 必须全篇统一定义为「首次确认（非误报）的时间」，而非「告警时间」。

• 若二者都要记录，则显式区分 T_alert（告警触发）与 T0（确认）。

• 原因：事故持续时长、SLA 赔付、MTTR 统计全部以 T0 为基准，定义漂移会让所有数字不可比。

3.4 ICS 角色体系：职责边界与授权

3.4.1 四角色卡（Google/PagerDuty 通用模型）

3.4.2 兼任规则

• SEV1 / SEV2：IC、Comms、Ops、Scribe 必须角色分离。

• SEV3：允许一人兼多角，但仍须有 Scribe 角色（可自兼）负责时间线留痕。

• IC 空缺兜底：正式 IC 未指派前，由接警 On-call 值班负责人临时代行，覆盖 T+2\~T+15 全部分诊动作，并即时补派正式 IC。

面试要点

：能说出「IC 不做排查」这一条，基本就证明你真跑过事故。这是最反直觉、也最容易被违反的规则 —— 因为 IC 往往是现场技术最好的人，本能就想下场。

3.4.3 中国互联网语境下的三角色映射

继伟在字节容灾止损专项的三角色划分，与 ICS 的对应关系：

3.5 事故沟通：三类模板与法律风险

3.5.1 模板总览

3.5.2 模板 1：内部 War-room 同步

【事故同步 #<编号> | SEV<级> | T+<分钟>】

更新时间：<绝对时间>

当前状态：🔴 处置中 / 🟡 缓解中 / 🟢 已恢复观察

已知事实：<只写已确认的，不写推测>

未知事项：<明确列出还不知道什么>

已采取措施：<动作 + 效果>

下一步：<谁 + 做什么 + 预计何时>

需要帮助：<需要哪个团队支援>

下次更新：<时间>

T+<分钟>

\= 自

T0

（首次确认时间）起经过的分钟数，如

T+45

。

3.5.3 模板 2：Exec 简报

【Exec 简报 #<编号> | SEV<级>】

⚠ 币种说明：本简报金额单位为 <人民币 / USD>，混合时逐项标注

发生时间：\<T0>

当前状态：<一句话>

影响摘要：<用户量 / 请求量 / 地域>

业务影响：<营收、转化、客户投诉，标注「实测」或「报道/估算」>

已采取措施：<要点>

预计恢复：<给区间或"待评估"，禁止给精确承诺>

需决策支持：<需要管理层拍板的事项>

下次简报：<时间>

3.5.4 模板 3：用户公告（Status Page / 客服口径）

⚠ 发布门槛：本模板对外发布前须经 【法务 + Comms Lead 双签】；

⚠ 发布前须剥离所有内部 \[来源] 标注与内部系统名。

标题：<服务名> 部分功能异常

状态：⚠ 调查中 / 🔄 部分恢复 / ✅ 已恢复

影响：<用户可感知的现象，不用内部术语>

我们正在：<正在做什么>

建议用户：<可操作建议，如稍后重试>

预计下次更新：<时间>

3.5.5 对外沟通的四条法律与口径红线（重点）

1. 禁止承诺精确恢复时间 —— 一旦超时就是二次信任危机，用「预计下次更新时间」替代。

2. 禁止对用户说教 —— 例如「请勿传播未经证实的猜测」会被解读为封口，反而放大谣言。正确写法：「请以官方渠道信息为准」。

3. 否认性断言必须有背书 —— 例如「与内容审查无直接关联」这类表述，必须有第三方（如云厂商）公开否认作为依据，且用「无直接关联」留出余地，并标注需法务审批。

4. 数字口径必须标注来源与性质 —— 区分「实测数据」「官方口径」「媒体报道估算」；货币必须标币种。混用「10 万元」和「5 万美元」是典型的管理层误导。

3.6 无责复盘（Blameless Postmortem）方法论

3.6.1 为什么必须无责

原理：如果复盘会追责到人，工程师就会隐瞒细节 → 时间线失真 → 根因找不到 → 同类故障必然复发。

Google SRE 的表述："You can't fix what you're afraid to talk about."

无责 ≠ 无责任，而是：追究系统与流程的责任，不追究个人的责任。

• ❌ "小王忘了加索引"

• ✅ "变更评审流程未覆盖非核心路径的 DB 索引影响评估，导致缺索引 SQL 可以无阻碍上线"

3.6.2 复盘文档标准章节

颗粒度规则：SEV1–SEV3 须产出复盘（SEV1 须含对外公告与 Exec 简报存档链接）；SEV4 不强制。

时效：恢复后 5 个工作日内完成初稿评审。

3.6.3 5 Why 的正确用法与常见误区

原理：5 Why 不是机械问五次，而是沿着「现象 → 机制 → 缺陷 → 防线缺失」的链条下探，直到触及可被工程手段修复的层面。

标准示例（支付延迟飙升）：

三大误区：

1. 停在 Why 3（人为操作层）就收工 —— "因为工程师改错了配置"，这是现象不是根因。

2. 单线程追问 —— 真实事故常有多条因果链（触发因素 + 放大因素 + 防线失效），应做「因果树」而非单链。

3. 根因数量为 1 —— 大事故几乎必然是多个防线同时失效（瑞士奶酪模型）。

瑞士奶酪模型（Swiss Cheese Model）

：每层防线都有洞，事故是所有洞恰好对齐的结果。复盘的目标不是补一个洞，而是问「为什么这么多层都没拦住」。

3.6.4 行动项质量标准

一条合格的行动项必须能通过这五问：

1. 可验证吗？（"加强监控" ❌ → "账务 DB 慢查询 >500ms 触发告警并自动 kill" ✅）

2. 有具名 owner 吗？（只写角色 = 无人负责）

3. 有明确 due 吗？（日期或版本号）

4. 优先级是否对应风险？（P0 = 不做就会复发）

5. 进了跟踪看板吗？（Jira/TAPD 链接，否则复盘文档就是墓志铭）

3.7 真实案例拆解：TikTok 美区大规模中断（2026-01）

数据来源

：Sohu（2026-01-29）、BBC（2026-01-26）、Wired、网经社 /ec100（2026-01-28）、tkfff（2026-01-28）、Oracle 发言人 Michael Egbert 公开表态、TikTok USDS 发言人 Jamie Favazza 声明。 性质说明

：本节为

基于公开报道的历史重建

，非当事团队内部实时记录。

3.7.1 事件概要

3.7.2 影响范围（量化）

3.7.3 SEV1 定级依据

1. 核心功能（上传 / 观看 / FYP 推荐流）大面积不可用

2. 持续 \~72 小时（远超任何 SEV2 的时长预期）

3. 66.3 万 + 用户报告（Downdetector 口径）

4. 重大营收损失：电商销量 >50% 跌幅、CPM \~10x

5. 多区域（美 + 马来）、多产品（TikTok + CapCut）连带

6. 叠加信任危机（用户猜测与内容审查 / 新所有权相关）

3.7.4 5 Why 根因链（追到系统 / 流程层）

3.7.5 行动项（7 条）

3.7.6 四维预防措施

3.7.7 这个案例在面试中怎么讲（核心洞察）

别只讲「机房停电了」—— 那是天气，不是工程。真正的工程教训有四条：

1. 停电不是根因，「恢复失败」才是。任何 DC 都会停电，问题是为什么恢复要 72 小时。这暴露的是恢复编排能力和多活缺失。

2. 迁移后的 72 小时是最危险的窗口。1/23 完成迁移，1/25 出事 —— 新架构的容灾能力尚未经过验证就直面真实故障。任何重大迁移必须配套「迁移后加固期」：加密监控、值班加倍、预案预演、回退通道保留。

3. 沟通真空会制造第二场事故。官方澄清滞后到 1/27，中间两天的信息真空被「内容审查」猜测填满，技术故障演变成信任危机。SEV1 的对外首次说明应有硬性时限。

4. B 端影响常被 C 端指标掩盖。用户报告数 66 万看起来是「体验问题」，但卖家侧是 CPM 涨 10 倍、销量腰斩的真金白银损失，且后台数据错乱的修复远晚于主链路。影响面评估必须包含 B 端 / 生态侧。

3.8 进阶：事故应急 Agent 协作系统设计

这部分是把上述人工体系「Agent 化」的系统设计，适用于 AI Infra / 平台工程 / Agent 方向面试，也是稳定性岗位的差异化亮点。

3.8.1 问题定义：人工应急的三个耗时瓶颈

3.8.2 核心架构决策：共享状态枢纽 > Agent 自由对话

推荐拓扑：「共享事故状态枢纽（Incident State Hub，单一事实源）+ IC 编排中枢」

                   ┌──────────────────────────────┐

                   │   事故状态枢纽（单一事实源）    │

                   │ incident\_id / sev / status    │

                   │ timeline\[] / decisions\[]      │

                   │ action\_log\[] / impact\_matrix  │

                   │ comms\_log\[] / handlers\_state  │

                   └───────▲──────────▲───────────┘

                     读写  │          │  读写

        ┌─────────────────┼──────────┼─────────────────┐

        │                 │          │                 │

   ┌────┴─────┐     ┌─────┴────┐  ┌──┴───────┐   ┌────┴──────┐

   │ IC Agent │────▶│ Liaison  │  │ Handler  │   │ 人类值班    │

   │（编排中枢）│ 派活 │  Agent   │  │  Agent   │   │ (可接管)   │

   └──────────┘     └──────────┘  └────┬─────┘   └───────────┘

                                        │

                              ┌─────────┴─────────┐

                              │   人审闸门（必经）  │

                              └───────────────────┘

为什么不用 Agent 间自由对话（点对点消息）：

运行时选型：Redis（热数据 + 分布式锁）+ Postgres/Kafka（追加式事件日志）；通知走事件总线（Redis Streams / Kafka）。Agent 间不直接 API 互调，统一经枢纽读写 + 订阅事件。

3.8.3 生命周期状态机

Detecting ──(确认影响)──▶ Triage ──(定级+派活)──▶ Mitigating

   ▲                        │                        │

   └──── 误报/重复 ─────────┘                        ▼

                                            Resolved ──▶ Postmortem

• Detecting：告警接入，Liaison 建群，IC 拉起

• Triage：IC 聚合大盘定 SEV、分派角色（状态迁移需 IC 或代行拍板）

• Mitigating：Handler 定位 + 止血，Liaison 持续同步，IC 监控决策

• Resolved：指标回稳 + IC 宣布

• Postmortem：自动从 timeline / action_log / impact_matrix 生成复盘初稿

3.8.4 三个 Agent 规格

3.8.4.1 事故指挥官 Agent（IC）

• 职责边界：定级、升降级、分派、决策节奏、保对外口径统一。不做排查。

• 工具集成：看板聚合 MCP（business_kpi / sli_slo / capacity / change_board）、决策日志写入、角色分派、升级触发。

• 推理循环：订阅 alert → 拉看板快照 → 套评级矩阵评 SEV → 写决策 → 派活 → 轮询枢纽监控态势 → 判断升级/缓解/恢复

• 输出 schema：

{ "incident\_id":"inc-20260125-001", "sev":"SEV1", "scope":"美区推荐链路",

  "assignments":\[{"role":"Liaison","task":"建群+每15分摘要"},

                 {"role":"Handler","task":"定位推荐服务不可用"}],

  "comms\_plan":"SEV1→对用户公告+管理层简报" }

• 子代理拆分：可拆 DashboardAggregator 专职多源看板拉取与归一化，IC 只做决策。

3.8.4.2 信息联络员 Agent（Liaison）—— 最低风险最高价值

• 职责边界：建群、抽象群聊、构建跨团队影响矩阵、定时通报。不臆测根因、不承诺恢复时间。

• 工具集成：IM API（飞书 / Slack：建群 / 订阅消息 / 发消息）、LLM 摘要、影响矩阵构建器、广播（写 comms_log）。

• 推理循环：建群 → 订阅消息流 → 每 N 分钟或触发式摘要 → 更新 impact_matrix → 生成 digest → 广播 → 标注"agent 生成·待确认"

• 状态管理：维护「已读消息游标 + 上版摘要指纹」实现断点续摘，避免重复 / 遗漏。

• 输出 schema：

{ "impact\_matrix":\[{"team":"电商","service":"支付","sev":"高","status":"止血中","evidence":"msg#N"},

                   {"team":"直播","service":"推流","sev":"中","status":"观察","evidence":"msg#N"}],

  "digest":"T+45：根因定位订单DB慢查询，已加索引，失败率 9.3%→3%，预计 T+90 恢复" }

• 关键护栏：摘要必须标注「agent 生成、待人工确认」；同一事实以枢纽为准去重；群内出现矛盾信息时上报 IC 而非自行裁决。

3.8.4.3 技术处理官 Agent（Handler）⚠️ 最高风险

• 职责边界：根因定位、止损、变更、数据善后。任何写生产动作前必须过审批闸门。

• 工具集成：监控查询（PromQL）、日志检索（ELK/Loki）、变更记录（发布系统 / CMDB）、Git/PR（仅草稿）、SOP 引擎。

• 推理循环：收 task → 关联「指标异常 + 日志错误 + 近期变更」→ 定位服务/代码 → 生成方案 → 走审批 → 执行 → 校验终止条件

• 输出 schema：

{ "localization":{"service":"order-svc","file":"order\_dao.go:88",

                  "hypothesis":"20:40 配置变更致统计SQL全表扫","confidence":0.7},

  "proposed\_fix":{"type":"hotfix\_pr","pr\_url":null,"draft":true,"status":"pending\_approval"},

  "sop\_exec":{"sop\_id":"rollback-order-db","step":2,"blast\_radius":"中","approved":false} }

• 子代理拆分（强烈建议）：

• code-locator：关联 metrics + logs + change 锁定服务与代码（只读，安全）

• hotfix-generator：基于定位开草稿 PR（绝不自动合并）

• sop-executor：评估 SOP trigger → 逐步执行，按爆炸半径分级审批

3.8.5 安全闸门（这是整个设计的生死线）

3.8.5.1 自动 hotfix PR

• 铁律：只产出草稿 PR，禁止自动合并。

• 闸门链：草稿 PR → 人类 Owner 审阅 → CI 全绿 → 灰度 /canary 验证 → IC 或人类拍板合并。

• 护栏：PR 描述自动附「定位依据（指标 / 日志 / 变更链接）+ 影响面 + 回滚方案」；支付 / 登录等高风险服务即使草稿也需资深人批。

3.8.5.2 自动回滚 / SOP 执行（按爆炸半径分级）

• dry-run：中 / 高级步骤先演练，确认无误再真做。

• 终止条件：每个 SOP 必须有明确 success/fail/abort 判定；指标不改善或恶化则自动中止并告警。

3.8.5.3 IC Agent 的自主边界

• 可自主：定级（取高不取低）、派活、内部同步节奏。

• 须人类批准：SEV 升级到 SEV1、对外公告口径、重大回滚 / 切流。

3.8.5.4 影子模式（Shadow Mode）—— 上线前提

• Handler 先跑 suggest-only：定位 + 出方案 + 草稿 PR，不执行任何写动作，只推送给人类参考。

• 在 golden incident 评测集（历史真实事故回放）上统计「定位准确率 / 方案可用率 / 误动作率」，达标后再升为受限自动。

3.8.5.5 可观测性、审计与 Kill Switch

• 每个 agent 动作写 action_log（agent_id、时间、输入、输出、审批状态）。

• 支持「暂停某 agent」「驳回某动作」；人类可随时接管 IC，接管后所有 agent 退化为建议模式。

• Agent 自身异常（超时 / 死循环 / 幻觉）由编排服务 watchdog 检测并自动挂起 + 告警。

3.8.6 Agent 特有的失效模式（面试深水区）

3.8.7 MVP 分期落地（按「价值 / 风险」比排序）

落地建议

：先只做 P1。它独立、低风险、价值立竿见影，且产出的

impact_matrix

/

timeline

正好成为 P2/P4 的枢纽数据基础。

3.8.8 技术栈

3.8.9 实战化设计草案：字节容灾止损专项视角（一线落地版）

这一节是把第 9 章通用框架「从一线经验反推」的范例。下面 9.9.1–9.9.2 基本是你原话的结构化展开，9.9.3–9.9.5 是配套的设计方法论与面试话术。面试官吃这一套：不当空谈 Agent 概念，而是用真实痛点推出三 Agent 分工，再对回 9.2–9.8 的安全框架。

3.8.9.1 一线痛点：为什么必须 Agent 化（你的真实场景）

你在字节负责容灾止损专项，事中应急止损环节拆出三个角色，每个都卡在「信息分散 + 人工串行」：

3.8.9.2 三 Agent 角色：你的设想 → 设计映射

① 事故指挥官 Agent（IC）

• 你的设想：全盘调度、人员分工、决策；把业务看板 + SLI 大盘 + 容量大盘 + 变更大盘汇总起来做决策。

• 设计映射（对回 9.4①）：把「多源看板聚合」抽成独立子代理 DashboardAggregator（经 dashboard-mcp 拉取 + 归一化），IC 只做定级 / 派活 / 升级决策。

• 关键细节：每个大盘指标必须带 freshness 时间戳 —— 这正是 9.6「看板数据陈旧」失效模式的防御点，过期数据要标红并降权，否则 IC 会基于 5 分钟前的快照误判。

② 信息联络官 Agent（Liaison）

• 你的设想：自动拉起事故群，把群聊对话及时抽象整理，对关键处理动作 + 各部门业务团队影响面汇总通报；以前人去爬楼一点点看，现在 agent 效率大幅提高。

• 设计映射（对回 9.4② + P1 联络员 9.7）：落地链是 IM MCP 建群 → 订阅消息流 → 增量摘要（带读游标做断点续摘，避免重复/遗漏）→ 构建 impact_matrix → 定时/触发式 digest 广播 → 标注「agent 生成·待确认」。

• 价值量化：全员「同一信息面」达成时间↓、爬楼耗时↓、摘要准确率 ≥90%。这是第 9 章里风险最低、价值立竿见影的切入点。

③ 技术处理官 Agent（Handler）

• 你的设想：根据事故期间监控、日志、变更记录锁定具体服务的具体代码，自动提交 hotfix PR；或自动根据预案 SOP 的「触发条件 / 操作步骤 / 终止条件」执行预案操作和回滚，大幅提高止损时效。

• 设计映射（对回 9.4③）：拆三个子代理 ——

• code-locator：关联 metrics + logs + change 锁定服务与代码行（只读，安全）；

• hotfix-generator：基于定位开草稿 PR，绝不自动合并；

• sop-executor：解析 SOP 的触发 / 步骤 / 终止三要素，按爆炸半径分级审批执行。

• 铁律：hotfix 只出草稿；SOP 必须三要素齐备 + 分级审批闸门（对回 9.5）。

3.8.9.3 如何设计「协作机制」（面试官最爱追问）

你的设想是「出现事故，三个角色自动通过 agent 形成团队」。这件事的机制设计必须回答五个问题，否则就是画饼：

1. 它们怎么连？ → 不能让三个 agent 自由对话（点对点消息会衰减、不可审计、崩溃不可恢复）。正确做法：在 Detecting 阶段由 IC Agent 拉起三人，统一挂到 Incident State Hub（单一事实源，9.2），所有读写经枢纽 + 事件总线，agent 间不直接 API 互调。

2. 它们怎么协同不打架？ → 用生命周期状态机（9.3）：Detecting → Triage → Mitigating → Resolved → Postmortem。状态迁移由 IC 或人类拍板，避免并行 agent 自作主张。

3. 写生产谁批准？ → 分级审批闸门（9.5）：低爆炸（特性开关 / 扩容 / 限流）可自动 + dry-run；中爆炸（单服回滚 / 配置回退）需 IC 一键确认；高爆炸（DB 回滚 / 跨机房切流）强制人类值班负责人批。

4. 出错了怎么停？ → action_log 记录每个动作的 actor + 审批人；配 kill switch，人类一键接管 IC，所有 agent 退化为建议模式；watchdog 检测 agent 超时 / 死循环 / 幻觉并自动挂起。

5. 凭什么敢放开自动？ → 影子模式 + golden incident 评测集（9.5/9.7）：Handler 先跑 suggest-only，在历史真实事故回放上统计定位准确率 / 方案可用率 / 误动作率，达标再升受限自动。

加分点

：你的设想里「自动形成团队 / 自动拉群 / 自动提交 hotfix」都很对，但

面试里主动补上「审批闸门、摘要标注待确认、看板新鲜度、kill switch、影子模式评测」这五条没明说却必须有的安全设计

，才是从「会画饼」到「懂工程」的分水岭。

3.8.9.4 如何设计开发「Agent」（落地工程视角）

按「工具层 → 状态层 → 编排层 → 闸门层 → 评测层 → 分期」顺序落地：

1. 工具层先做成 MCP server（对回 9.8）：dashboard-mcp / im-mcp / observability-mcp / git-mcp / sop-mcp。Agent 只调 MCP，权限与审计集中在 server 侧，杜绝 agent 直连生产系统。

2. 状态枢纽是骨架不是对话（9.2）：Redis 存热数据 + 分布式锁，Postgres/Kafka 存追加式 action_log / timeline / impact_matrix。这是 dashboard 也是审计源。

3. 编排用状态机 / LangGraph（9.8）：核心是「枢纽 + 事件总线 + 审批节点」，不是复杂多轮对话。

4. 闸门层建模：每个 agent 动作写 action_log(agent_id, time, input, output, approval)；按爆炸半径定义 低 / 中 / 高 三级策略与审批人。

5. 评测闭环：golden incident 回放 + 影子模式对比，把「定位准确率 / 方案可用率 / 误动作率」作为升自动的硬门槛。

6. 迭代顺序（价值 / 风险比）：P1 联络员（只读摘要，低风险高价值）→ P2 指挥官（人在环）→ P3 处理官只读（定位 + 草稿 PR，误动作 = 0）→ P4 受限自动（经评测后放开）。

3.8.9.5 面试话术模板（把一线经验讲成系统设计）

「我在字节做容灾止损专项时，发现事中应急最大的瓶颈是

信息分散 + 人工串行

：指挥官要在 4 类大盘间切屏找线索，联络官要爬几百条群消息提炼影响面，处理官要手动定位、提 PR、跑 SOP，止损时效被这些人工步骤拖慢。 所以我设想把三个 ICS 角色 Agent 化，挂到一个

共享事故状态枢纽

上：IC 聚合多源大盘辅助定级派活，Liaison 自动拉群做增量摘要和影响矩阵，Handler 只读定位 + 出草稿 PR + 按 SOP 三要素（触发 / 步骤 / 终止）执行预案。 但关键安全设计是 ——

任何写生产动作过审批闸门、摘要标注待确认、先跑影子模式评测集再放开自动

。这样既把止损时效压下来，又不会让 agent 放大事故。」

3.8.10 P1 联络员 Agent：群摘要 Prompt + 影响矩阵 Schema（可跑骨架）

对应 9.9.2 联络官 + 9.7 P1 联络员。下面给出

可独立运行的 Python 骨架

（仅依赖标准库，

python3 liaison_agent.py

即可跑 demo），以及直接可用的 Prompt 与影响矩阵 Schema。完整代码见

liaison_agent.py

（与本文件同目录，已实测

exit 0

）。

3.8.10.1 影响矩阵 Schema（ImpactMatrix）

跨团队影响面用结构化对象表示，便于去重、广播与审计：

@dataclass

class ImpactItem:

    team: str            # 受影响业务团队，如「电商」「直播」

    service: str         # 受影响服务，如「支付」「推流」

    sev: str             # 高 / 中 / 低（影响严重度）

    status: str          # 止血中 / 观察 / 已恢复 / 未确认

    evidence: str = ""   # 原始消息/指标链接，用于溯源（防幻觉）

    updated\_at: float = field(default\_factory=time.time)

@dataclass

class ImpactMatrix:

    incident\_id: str

    items: list\[ImpactItem] = field(default\_factory=list)

    def upsert(self, item):  # 同 team+service 去重更新，保证全员同一信息面

        for i, e in enumerate(self.items):

            if e.team == item.team and e.service == item.service:

                self.items\[i] = item; return

        self.items.append(item)

3.8.10.2 群摘要 System Prompt（直接可用）

你是事故应急的「信息联络官 Agent」。

职责：自动拉起事故群、对群聊对话做增量摘要、构建跨团队影响矩阵、定时通报。

铁律：

1\. 不臆测根因、不承诺恢复时间。

2\. 所有输出必须标注「agent 生成·待确认」。

3\. 关键结论必须引用原始消息链接/指标链接（evidence 字段），事实以状态枢纽为准。

4\. 群内出现矛盾信息时，上报指挥官(IC)而非自行裁决。

输出：严格 JSON，字段为 items: \[{team, service, sev, status, evidence}]。

3.8.10.3 增量摘要 Prompt（每轮调用）

以下是事故群近 N 条新消息（已按时间排序）：

{new\_messages}

当前影响矩阵快照：

{current\_matrix}

请：

1\. 提炼关键处理动作（谁、做了什么、结果）。

2\. 更新各业务团队影响面（team/service/sev/status），新信息不足时沿用旧值并标 status=未确认。

3\. 对每条更新附 evidence（原始消息序号或链接）。

仅输出 JSON，不要解释。

3.8.10.4 增量摘要 Agent 循环（断点续摘 + 广播）

class LiaisonAgent:

    def \_\_init\_\_(self, incident\_id, llm\_call=None):

        self.matrix = ImpactMatrix(incident\_id)

        self.last\_cursor = 0          # 读游标，断点续摘避免重复/遗漏

        self.llm\_call = llm\_call or self.\_stub\_llm

    def ingest(self, messages):       # 订阅 IM 消息流，只处理游标之后的增量

        new = messages\[self.last\_cursor:]; self.last\_cursor = len(messages)

        if not new: return

        prompt = SUMMARY\_PROMPT.format(new\_messages=..., current\_matrix=...)

        for it in self.\_parse\_items(self.llm\_call(prompt)):

            self.matrix.upsert(it)

    def digest(self):                 # 定时/触发式通报，强制标注待确认

        return f"\[agent 生成·待确认]\n{json.dumps(self.matrix.to\_dict(), ensure\_ascii=False, indent=2)}"

运行

：

python3 liaison_agent.py

会跑一段 demo（注入 2 条消息 → 输出带「agent 生成・待确认」的影响矩阵 JSON）。真实接入时把

_stub_llm

换成 IM MCP + LLM 调用，

ingest

接到 IM 事件总线即可。 安全护栏回顾（面试常问）

：① 摘要强制「待确认」标注；②

evidence

字段强制引用原始消息，可一键溯源；③

upsert

去重保证同一信息面；④ 矛盾信息上报 IC 而非自裁决；⑤ 事实以状态枢纽为准，不基于模型上下文发声。

3.9 最佳实践清单与反模式

3.9.1 ✅ 最佳实践（可直接说的 20 条）

响应期

1. 止损优先于根因，恢复服务是唯一目标

2. IC 不下场排查，保持全局视野

3. 定级不确定时取高不取低

4. 30 分钟内有变更 → 先怀疑变更、先回滚

5. SEV1/2 强制角色分离，SEV3 也要有 Scribe 留痕

6. T0 全组织统一定义为「首次确认时间」

7. 首条状态更新在 T+12 分钟内发出，哪怕内容是「正在确认」

8. 群聊即单一事实源，早期事实立即留痕

9. 战情室只留决策者与处置者，围观者进旁听频道

沟通期

10. 对外只承诺「下次更新时间」，不承诺恢复时间

11. 所有数字标注口径（实测 / 官方 / 媒体估算）与币种

12. 否认性表述必须有第三方背书 + 法务双签

13. 不对用户说教，用「请以官方渠道为准」

复盘期

14. 无责复盘，追系统与流程不追个人

15. 5 Why 追到可被行动项解决的层面

16. 行动项必须有具名 owner + due + 可验证标准 + 看板链接

17. 复盘 5 个工作日内出初稿

预防期

18. 变更三板斧：可灰度、可监控、可回滚

19. 预案必须有终止条件和自身回滚方案

20. 演练过的预案才是预案（混沌工程常态化）

3.9.2 ❌ 反模式（面试中说出来会显得很懂）

3.10 面试题库与参考答法

3.10.1 基础层

Q1：介绍一下你们的事故分级标准，SEV1 和 SEV2 怎么区分？

按「核心功能是否完全不可用」「是否数据丢失 / 安全暴露」两条硬线区分。SEV1 是核心链路 100% 不可用或数据 / 安全类；SEV2 是主要功能严重降级但仍有可用路径。踩线时我们有量化旁路：失败率 ≥5% 或主流程无法完成 → SEV2；<5% 且可重试 → SEV3。原则是取高不取低，因为过度升级的成本是打扰几个人，升级不足的成本是丢用户和营收。

Q2：MTTR 由哪几段组成？你最优先优化哪一段？为什么？

MTTD + MTTA + MTTM。我优先优化

MTTM（止损耗时）

，因为它占比最大且最可控 —— MTTD 受监控覆盖率上限约束，MTTA 靠 On-call 制度基本能压到几分钟，而 MTTM 取决于「有没有可一键执行的预案」，这是纯工程投入能显著改善的部分。具体做法是把预案 SOP 化（trigger/steps/termination）并做成一键执行 + 常态化演练。

Q3：IC 的核心职责是什么？为什么 IC 不能自己排查？

IC 是唯一指挥权来源，负责定级、分派、决策节奏、对外口径。不能排查的原因是：排查会占满认知带宽，一旦下场，全局态势就无人跟踪，会出现「所有人都在低头干活，没人抬头看方向」的状态。这也是为什么我们要求 SEV1/2 强制角色分离。

3.10.2 进阶层

Q4：讲一个你处理过的印象最深的事故。（STAR 结构 + 以 TikTok 案例为例演示讲法）

S（背景）

：2026 年 1 月 TikTok 美区完成向 Oracle 数据中心的迁移，1/23 刚上线，1/25 遇到极端冬季风暴导致 DC 停电。 T（挑战）

：故障持续 72 小时，66 万 + 用户报告，电商卖家销量腰斩、CPM 涨 10 倍，同时因官方澄清滞后到 1/27，用户开始猜测是内容审查，技术故障演变成信任危机。 A（动作）

：定级 SEV1；分诊阶段确认非误报后拉战情室并指定 IC（正式 IC 未到位时由 On-call 代行）；Comms 走法务双签发对外公告，明确「极端天气停电 + 恢复过程技术故障」并引用云厂商公开表态澄清与审查无直接关联；Ops 侧与依赖方联合恢复。 R（结果与教训）

：复盘 5 Why 追到三层系统根因 —— 单 DC 依赖缺多活、迁移磨合期缺演练与降级预案、可观测性与对外沟通 SOP 不健全。产出 7 条行动项，P0 三条：美区多活 / 故障转移、迁移期演练与降级、依赖方 SLA 重订与应急联动。 我的洞察

：

停电不是根因，恢复失败才是

；任何 DC 都会停电，问题是为什么恢复要 72 小时。以及沟通真空会制造第二场事故。

Q5：如果一个故障你怀疑是变更引起的，但回滚需要 20 分钟，重启只需 2 分钟且可能有效，你选哪个？

先看爆炸半径和数据风险。若重启无数据风险，我会

并行

：一边让人执行重启（快速验证假设），一边同步启动回滚流程（不等待重启结果）。这样重启若有效就省了 18 分钟，无效也不损失回滚时间。事故中的关键决策原则是

并行推进而非串行等待

，前提是两条路径互不冲突且 IC 明确授权。

Q6：怎么防止「重试风暴」把恢复中的服务二次打死？

四层防御：① 重试必须带指数退避 + 随机抖动；② 客户端设重试预算（retry budget，如全局重试量不超过正常量的 10%）；③ 服务端熔断 + 自适应限流（过载时快速失败而非排队）；④ 恢复时

渐进放量

而不是一次性开闸。TikTok 案例里「恢复过程中出现技术故障」很可能就有这一类放大效应。

Q7：无责复盘怎么落地？如果确实是某人操作失误呢？

无责不是不追责，而是

把「人为什么会犯这个错」当作系统问题来问

。如果某人执行了危险命令，正确的追问是：为什么这个命令没有二次确认？为什么权限没有分级？为什么没有 dry-run？为什么演练时没暴露？把每个「人失误」翻译成「防线缺失」，才能产出有效行动项。反之，一旦复盘会变成追责会，下次就没人愿意说真话，时间线会失真，根因永远找不到。

3.10.3 架构层

Q8：同城双活和异地多活的核心区别？

关键不是距离，是

故障域是否真正独立

和

数据一致性方案

。同城双活的两个 IDC 常共享电力、网络运营商甚至同一自然灾害半径，RPO 可以做到～0 但故障域不完全独立；异地多活故障域独立，但跨地域延迟（几十毫秒）使强一致同步不可行，必须做单元化 + 最终一致 + 冲突解决。所以异地多活的难点从来不是「部署两份」，而是

数据分片路由

和

跨单元一致性

。

Q9：怎么设计一个「爆炸半径可控」的系统？

四个层次：①

单元化

（用户按分片路由到独立单元，单元内自闭环）；②

舱壁隔离

（核心 / 非核心不共享连接池、线程池）；③

依赖分级

（强依赖冗余，弱依赖可降级，定期审计防止弱依赖被写成强依赖）；④

变更灰度

（1%→10%→50%→100%，每档自动熔断回滚）。验证手段是混沌工程 —— 主动注入 AZ 断网、依赖慢化，看爆炸半径是否符合设计预期。

3.10.4 AI / Agent 层（差异化亮点）

Q10：如果让 AI Agent 参与事故响应，你怎么设计才敢让它上生产？

三条设计原则： ①

共享状态枢纽而非 agent 自由对话

—— 所有 agent 围绕一个结构化的单一事实源读写，保证信息不丢失、可审计、崩溃可恢复、人类随时能接管。自由对话是黑盒，出了事无法追溯。 ②

按风险分期上线

—— 联络员（摘要 / 影响矩阵，纯只读，低风险高价值）最先；指挥官（看板聚合 + 辅助定级，人在环）其次；技术处理官（写生产）最后，且必须先跑影子模式，在 golden incident 评测集上达标才升级为受限自动。 ③

人审闸门按爆炸半径分级

—— hotfix 只出草稿 PR 绝不自动合并；SOP 按低 / 中 / 高爆炸半径决定自动、IC 确认、还是强制人批；每个动作写审计日志，配 kill switch 让人类一键接管，agent 退化为建议模式。 核心判断是：

Agent 在事故里最大的价值不是 "替人做决定"，而是 "把人从信息搬运里解放出来"

。所以第一期我只做摘要和影响矩阵 —— 这块占人工耗时最多，且做错了顶多是信息不准（可通过 "agent 生成待确认" 标注兜底），不会直接搞坏生产。

Q11：Agent 摘要出现幻觉导致全员误判怎么办？

三重防御：① 所有 agent 生成内容强制标注「agent 生成、待人工确认」；② 关键结论必须附原始消息 / 指标链接，可一键溯源；③ 事实以状态枢纽为准，agent 不得基于自己的记忆发声 —— 广播内容必须来自枢纽的

impact_matrix

，而不是模型上下文。另外群内出现矛盾信息时，Liaison 的正确动作是上报 IC 而非自行裁决。

Q12：你在一线做过容灾止损，如果要 Agent 化，三个角色怎么分工、怎么避免放大事故？

我按 ICS 拆成三 Agent 挂到共享状态枢纽：① 指挥官 Agent 聚合业务 / SLI / 容量 / 变更四类大盘辅助定级派活；② 联络官 Agent 自动拉群做增量摘要 + 影响矩阵，把人从爬楼里解放出来；③ 处理官 Agent 只读定位到服务 / 代码、出草稿 PR、按 SOP 三要素跑预案。 防放大事故的关键不是「不让它动」，而是

分级闸门 + 影子模式

：hotfix 只出草稿不自动合并，SOP 按爆炸半径决定自动 / IC 确认 / 人批，所有动作写审计日志配 kill switch；且处理官先跑影子模式在 golden incident 评测集上达标，才升受限自动。一句话 ——

Agent 的价值是把人从信息搬运里解放出来，而不是替人做写生产的决定

。

3.11 术语速查表

3.12 附：三份原始工程产出索引

本手册由工程保障团队 AI 协作生成，基于公开报道与通用工程实践。TikTok 案例部分为

基于公开新闻的历史重建

，非当事团队内部记录；财务数字多为媒体估算。面试引用时建议注明信息来源与性质。