# 单人值守与团队响应

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

---

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

## 31.5.1 单人时先稳定、记录，再逐级升级 {#item-31-5-1}

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

| 分钟 | 逻辑角色 | 产物 |
|---:|---|---|
| 0～2 | IC | incident ID、UTC 起点、当前用户影响、下一次更新时间 |
| 2～5 | scribe | 首发事实、告警来源、最近变更、当前自动化和 writer 身份 |
| 5～9 | operator | L0 只读现场包；连接/HA/资源/完整性最小证据 |
| 9～12 | technical lead | 候选路线、被排除路线、第一安全动作与 stop line |
| 12～15 | liaison | 呼叫所需 owner、发布 known/unknown/impact/next update |

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

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

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

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

### 预先写死升级触发器

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

```text
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、证据和独立复核。

### 防范单人认知陷阱

| 陷阱 | 自检问题 |
|---|---|
| anchoring | 除首发告警外，还有哪两个解释？ |
| action bias | 不做这条命令，未来五分钟会丢掉什么？ |
| confirmation bias | 哪条最便宜的证据会推翻我的路线？ |
| sunk cost | stop condition 是否已经触发？ |
| fatigue | 我能否准确复述 target、方向和不可逆边界？ |

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

## 31.5.2 团队时避免多人同时改同一系统 {#item-31-5-2}

### 两分钟内建立响应拓扑

```text
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，
再领取一个问题；不要从头重复所有探针或提出第五次“要不要重启”。

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

一个好的分工可能是：

```text
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：

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

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

```text
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”被误读为业务已恢复。

### 交接要传递未决风险

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

```text
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 何时必须请求业务、存储、安全或厂商协助 {#item-31-5-3}

### 技术 owner 不能替代语义 owner

| 需要谁 | 强制触发条件 | 需要对方决定什么 |
|---|---|---|
| 业务/数据 owner | 错误值、target-only 写、退款/通知等副作用 | 权威状态、补偿规则、可接受降级 |
| 应用 owner | 重试、连接池、幂等键、deploy/job 相关 | 围栏范围、回放安全、客户端验收 |
| 存储/基础设施 | media error、snapshot、空间、fsync/latency 异常 | 一致快照、fencing、扩容与设备替换 |
| 网络/DCS owner | leader lock、分区、VIP/route 不一致 | 多数派、网络围栏和路径恢复 |
| 安全/法务/隐私 | 凭据泄漏、恶意变更、受监管数据、证据可能用于调查 | 保全、通知、访问范围和 chain of custody |
| 扩展/厂商 | 非核心插件、内核崩溃、未文档格式或支持合同相关 | 已知缺陷、受支持恢复路径、补丁 |

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

### 外部求助包要小而完整

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

```text
We need to determine whether PG18.6 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、对方假设、建议适用版本、执行
授权和验证结果，并把外部建议纳入同一决策日志。

---

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