31.1 事件分级与响应目标

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

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

31.1.1 用户影响、数据风险、范围与持续时间

用五个轴描述事件

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

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

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 的内置标准：

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

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

31.1.2 恢复数据、恢复拓扑、释放流量压力、抢救完整性

先说要恢复什么

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

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

响应目标必须可验收

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

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

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

最小化不可逆性

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

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

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

31.1.3 严重度决定节奏，不替代技术判型

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

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

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

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

因此，严重度只控制：

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

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

把第一个解释当作假设

首发告警应写成：

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 唯一性 和提交确认。

两条状态线并行更新

事故记录中应分别维护：

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

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

返回本章目录 · 下一节：第一原则：保护现场与可恢复性 · 查看全书目录 · 查看索引中心