# 事件分级与响应目标

LLMS 索引： [llms.txt](/llms.txt)

---

监控系统每天会产生很多 event，真正需要进入 incident response 的只是其中一部分。
本书把“事件”定义为：用户、数据、恢复能力或关键控制面出现现实风险，需要超出日常
工单节奏的协调、记录和处置。它可以由告警触发，也可以由用户投诉、审计差异、存储
报错或一次危险变更触发。

这个定义故意不要求先知道根因。先建立响应节奏，才有机会在状态继续变化之前保存证据
和恢复选择。NIST SP 800-61r3 也把检测、响应、恢复放进持续的风险管理活动，而不是把
响应理解成一次孤立的“修服务器”任务
（[NIST SP 800-61r3](https://doi.org/10.6028/NIST.SP.800-61r3)）。

## 31.1.1 用户影响、数据风险、范围与持续时间 {#item-31-1-1}

### 用五个轴描述事件

“数据库有问题”不是可以分级的事实。事件声明至少要填五个轴：

| 轴 | 要回答的问题 | 可验证的例子 |
|---|---|---|
| 用户影响 | 谁现在不能完成什么？ | checkout 写失败 74%，只读目录正常 |
| 数据风险 | 已提交状态会丢、错、重复或泄漏吗？ | 12,400 行被错误更新，外部退款 318 笔 |
| blast radius | 哪些租户、库、表、节点、地域和依赖受影响？ | `pg-test` 写服务；只涉及订单库 |
| time dynamics | 稳定、扩散、振荡还是已停止？ | WAL 每分钟增长 3 GiB；错误 job 仍运行 |
| recoverability | 现有副本、WAL、备份和证据还能支持什么？ | archive 覆盖事发前 41 小时，尚未试恢复 |

每个结论都应带三个限定：

```text
as_of       2026-07-30T02:14:00Z
source      dashboard / SQL result / ticket / business owner
confidence  observed / inferred / unknown
```

不要把 unknown 填成 zero。没有发现数据损坏，可能只是还没有做 manifest 或 checksum
验证；监控图没有错误，也可能是 exporter、规则或标签链路已经失效。第 25 章建立的
“signal missing 也是状态”在事故中尤其重要。

### 严重度是一套组织合同

下面是一种可用的起点，不是 PostgreSQL 的内置标准：

| 等级 | 典型触发 | 协调节奏 |
|---|---|---|
| SEV1 | 核心服务大面积不可用；数据完整性或唯一 writer 不确定 | 立即指挥、持续记录、5～15 分钟更新 |
| SEV2 | 重要功能显著受损；范围受限但可能扩大 | 值班负责人接管、15～30 分钟更新 |
| SEV3 | 局部降级且有可靠绕行，数据风险低 | 工作时段协调并持续观察 |
| SEV4 | 无当前用户影响的缺陷或近失事件 | 正常问题管理 |

真正的阈值必须写入组织策略：多少用户、多少收入、哪类数据、哪个合规义务。数据库
SLO 可以帮助衡量可用性，却不能单独覆盖错误数据、隐私泄露或恢复窗口丢失。

分级不是一次性动作。影响扩大、发现第二个 writer 或确认 archive 断档时要升级；入口
恢复而数据仍不可信时，不能因为 HTTP 200 回来了就降级。

## 31.1.2 恢复数据、恢复拓扑、释放流量压力、抢救完整性 {#item-31-1-2}

### 先说要恢复什么

`restart PostgreSQL`、`promote replica`、`drop slot` 都是动作，不是目标。若没有目标，
团队无法判断动作成功后是否真的改善了局面。第六篇把主要响应目标分成四类：

| 目标 | 典型问题 | 第一优先保护 | 后续章节 |
|---|---|---|---|
| 恢复数据 | 已提交数据被误删、误改或要回到历史边界 | writer、WAL/archive、恢复目标 | ch32 |
| 恢复拓扑 | primary、timeline、DCS 或服务路由不确定 | 唯一 writer、fencing、提交边界 | ch33 |
| 释放压力 | 连接、锁、CPU、内存、I/O、磁盘成为约束 | 管理通道、关键流量、剩余容量 | ch34 |
| 抢救完整性 | page、checksum、WAL、index 或业务等价存疑 | 原始介质、独立副本、证据来源 | ch35 |

一次事件可能同时有多个问题。例如 inactive slot 填满 `pg_wal`，既威胁可用性，也威胁
恢复能力。此时主要目标可以先定为“释放压力，但禁止直接删除 WAL”；当空间稳定后再
转入 consumer 重建与完整性验证。

### 响应目标必须可验收

把“尽快恢复”改写成状态断言：

```text
用户状态       关键写接口恢复，错误率低于已声明阈值
数据状态       marker 边界后的 manifest 与业务不变量成立
拓扑状态       一个可写 primary，所有服务端点与 DCS 认知一致
恢复状态       新 WAL 持续归档，备份覆盖未被破坏
证据状态       时间线、动作与结果均有来源和散列
```

这些状态可以分步达到。为了保护数据，允许先进入 degraded read-only；为了避免满盘，
可以先 shed 非关键写，而不是立即恢复所有流量。关键是把“临时稳定状态”和“最终恢复
状态”分别命名，避免临时措施永久化。

### 最小化不可逆性

在信息不足时，优先级通常是：

```text
围住继续扩散
  -> 保存恢复与取证输入
      -> 建立独立观察
          -> 执行最小范围的可逆动作
              -> 验证后再扩大
```

这不是“永远不动作”。磁盘还剩两分钟时必须行动，但动作仍应有精确目标、owner、停止线
和后续代价。例如扩容比删除 `pg_wal` 更可控；暂停一个错误 job 比停止整个集群更容易
验证；隔离恢复比在主库上直接覆盖更能保留选择。

## 31.1.3 严重度决定节奏，不替代技术判型 {#item-31-1-3}

### 相同症状，可以是四条完全不同的路

“应用连不上数据库”至少可能表示：

```text
错误 DDL/DML 后应用主动拒绝服务       -> PITR / data recovery
HAProxy health check 失效              -> HA / service topology
max_connections 或 pool queue 耗尽     -> overload
关键 catalog/page 无法读取导致启动失败  -> integrity
```

它们都可能是 SEV1，但安全动作相反。第二种情况下随机提升副本会把接入故障变成双主；
第三种情况下重启只会暂时清空连接，重试风暴会再次打满；第四种情况下在原介质上反复
启动可能覆盖证据。

因此，严重度只控制：

- 谁必须加入、谁有决策权；
- 更新频率和业务沟通范围；
- 可以接受多大的临时降级；
- 多快需要引入外部专家。

它不告诉你根因，也不降低高风险动作的证据门槛。

### 把第一个解释当作假设

首发告警应写成：

```text
fact        write endpoint returned 503 from 02:03Z
hypothesis  primary may be unavailable
alternatives
            proxy health check / pool exhaustion / DCS partition /
            primary crash / network path
next test   compare endpoint, Patroni, SQL role and DCS leader
```

一次测试的价值不只在“证实”，也在排除。若直连现任 primary 成功，不能直接宣告数据库
健康；它只降低了“postmaster 已停止”的可能性，还要检查服务 backend、writer 唯一性
和提交确认。

### 两条状态线并行更新

事故记录中应分别维护：

```text
impact line      SEV1 -> SEV2 -> resolved
technical route HA -> OVERLOAD -> recovery complete
```

入口恢复可能让影响下降，但若数据等价尚未验证，技术事件仍未关闭。相反，根因尚未知时
也可以通过限流、围栏或只读模式降低影响。把两条线分开，团队才不会为了“找到根因”
延误止血，也不会为了“服务绿了”过早结束调查。

---

[返回本章目录](../) · [下一节：第一原则：保护现场与可恢复性](../02/) ·
[查看全书目录](/toc/) · [查看索引中心](/indexes/)