31.5 单人值守与团队响应

同一响应协议既要能被凌晨单人值守执行，也要能在几十人加入时保持一致。差别不在技术 正确性：单人把角色按时间串行切换，团队把只读调查并行化；两种模式都要有一个状态、 一个时间线、一个命令 owner 和明确的升级条件。

31.5.1 单人时先稳定、记录，再逐级升级

前十五分钟按顺序切换角色

一个人可以戴四顶帽子，但要按顺序。先把“准备执行什么”写进时间线，再切到 shell； 执行后贴原始 exit status 和 verifier 结果，再回到记录。多开几个终端不会让一个人获得 真正的独立复核，只会增加连错环境和忘记动作的概率。

单人第一目标是保持可操作

• 保留一个管理连接或 out-of-band 路径；
• 给诊断 SQL、SSH 和 HTTP probe 设置短 timeout；
• 先停止精确的错误来源，不做全局“重启看看”；
• 把当前 cluster、node、role、system id、timeline 放在命令前；
• 不在普通聊天粘贴连接串、原始 SQL、业务行或私钥；
• 每五分钟停一次，问“现有动作是否仍匹配响应目标”。

若手已经在高压下连续操作，最有价值的动作往往是叫醒第二个人。独立读回一个 target 可以阻止方向反了的 failover、误删 slot 或在错误 data directory 上恢复。

预先写死升级触发器

单人不能因为“还没完全搞清楚”而无限延迟呼叫。下列任一项应立即升级：

writer uniqueness unknown
checksum / WAL / page / storage media error
backup or archive recovery window unknown
R2/R3 action required
regulated or financial data involved
credentials / intrusion / malicious change suspected
impact still growing after first containment
fifteen minutes内没有形成可证伪路线

真正存在“几分钟后满盘”的倒计时，也只授权最小保护动作，例如按声明 marker 释放 emergency reserve 或在入口 shed load；它不自动授权删除 pg_wal。按组织 break-glass 政策执行后，必须立刻补齐 owner、证据和独立复核。

防范单人认知陷阱

如果最后一个问题答不清，应停止有副作用的操作并交接，而不是靠咖啡继续。

31.5.2 团队时避免多人同时改同一系统

两分钟内建立响应拓扑

IC                 one person
database operator  one active command token
scribe             one canonical timeline
business liaison   one outward status owner
read-only tracks   access / HA / database / host-storage / backup

人员不足时可以合并角色，人员过多时也不要复制角色。新加入者先读当前摘要和 stop line， 再领取一个问题；不要从头重复所有探针或提出第五次“要不要重启”。

并行问题，不并行状态改变

一个好的分工可能是：

track A  从客户端、HAProxy、PgBouncer 还原实际路径
track B  读取 Patroni、DCS、PostgreSQL role/timeline
track C  检查 host resource、storage 和最近 kernel error
track D  检查 backup/archive/recovery coverage
track E  由业务 owner 确认影响键和外部副作用

这些 track 默认 R0。任何人提出 R1～R3 动作，都先写成 decision packet；IC 指定唯一 operator 和 verifier。若已有动作执行中，新动作必须说明是等待、互斥还是可以安全并行。

“一个人重启 pool、另一个人切流、第三个人 terminate session”无法从结果中辨别哪个 动作有效，还可能在连接排空过程中制造未知事务。

使用 read-back 和 closed loop

IC：

Authorize action A on cluster pg-x only, node pg-x-2,
expected B within 30 seconds, stop on C, rollback D.

operator 复述 target 和条件，执行后报告：

started / completed UTC
exact command or API request hash
exit status
expected signal B actual value
stop condition C true/false
evidence id

verifier 从独立观察面确认。只有 IC 宣布状态转移后，时间线才从 authorized 变成 completed/verified。这样可以避免“某人说 done”被误读为业务已恢复。

交接要传递未决风险

轮班摘要不应只列已做事项：

current severity / impact / route
authoritative writer and timeline
active fences, pauses, silences and temporary config
last verified data/recovery boundary
actions completed and their results
hypotheses rejected / still open
next action, owner, approval and stop line
irreversible boundaries already crossed
next stakeholder update

接班 operator 对关键身份做一次 read-back。长事件要安排休息和轮换；疲劳是会改变系统 风险的运行条件，不是个人意志问题。

31.5.3 何时必须请求业务、存储、安全或厂商协助

技术 owner 不能替代语义 owner

数据库团队可以证明“这 77 行在恢复点之后被合法修改”，却不能决定哪一笔退款该撤销； 存储团队可以生成 crash-consistent snapshot，却不能宣称业务事务完整；厂商可以建议 修复步骤，最终生产授权仍属于本组织。

外部求助包要小而完整

发送前先写一个明确问题：

We need to determine whether PG18.4 can safely start this copied
data directory after error X, without modifying the preserved source.

随包提供：

• incident ID、版本、OS/架构、扩展与精确错误；
• system identifier、timeline/LSN 和简化拓扑；
• 已执行动作、结果和 stop line；
• 最小可复现样本或隔离工作副本；
• 相关日志的精确时间窗、散列与脱敏说明；
• 业务影响和所需答复时限。

不要默认发送整个 postgresql.conf、pg_hba.conf、Patroni YAML、完整日志、core dump 或业务表；它们可能含凭据、连接串、SQL、参数值和个人数据。先按合同、法律和最小必要 原则确认接收渠道与访问权限。

提前定义“必须停手”

以下情况应停止本地修复尝试，转为保存、隔离和专家协作：

• 无法确认目标 data directory 的 system identifier 或 timeline；
• 两个 writer 都有独占提交；
• pg_resetwal、手工 page copy、catalog hack 等成为唯一候选；
• pg_rewind 已失败，target 状态未知；
• 存储错误仍增长，工作副本来源不可靠；
• 扩展数据格式或加密密钥不受当前团队理解；
• 任何动作可能影响法定通知或证据可采性。

及时升级不是“把事故甩出去”。IC 仍要跟踪请求 ID、对方假设、建议适用版本、执行 授权和验证结果，并把外部建议纳入同一决策日志。

上一节：决策、沟通与变更纪律 · 返回本章目录 · 下一节：实战：盲抽症状的桌面演练 · 查看全书目录 · 查看索引中心