31.4 决策、沟通与变更纪律

故障不会因为开了 incident channel 就停止变化。没有统一决策格式时，聊天记录很快会 混合事实、猜测、建议、已经执行的命令和转述结果；十分钟后，团队甚至无法回答“谁在 哪台机器上改了什么”。响应纪律的作用不是增加仪式，而是让并行思考最后汇聚成一个 可审计的系统状态转移。

31.4.1 事实、假设、动作、预期与停止条件

五类记录不能混写

“Patroni 有问题，已处理”不属于任何合格类型。它没有时间、来源、动作和结果，也让接班 人无法判断现在是否安全。

把每个动作写成有界实验

一次可执行动作至少包含：

minute / UTC
actor and exact target
facts and hypothesis that justify it
risk class and approver
rendered action
expected observable result
time budget
stop condition
rollback or compensation
actual result and evidence id

例如：

fact       HAProxy has zero healthy backends; all Patroni members agree
            pg-test-1 is primary on timeline 11
hypothesis health-check secret v42 is invalid
action     access owner rolls back only secret v42 -> v41
expected   pg-test-1 becomes healthy within 10 s; no role change
stop       any replica becomes write backend, or primary identity changes
rollback   restore v42 and keep write endpoint fenced
result     pending

预期结果必须是可以再观察的状态，不是“应该修好”。停止条件写在命令之前，因为执行后 人容易被 sunk cost 推着继续。没有可行 rollback 时，要明确写 irreversible after <boundary>，而不是填一个虚假的“恢复备份”。

时间线记录的是认识变化

02:03 fact       endpoint 503
02:05 hypothesis primary may be down
02:07 fact       SQL primary running; Patroni/DCS agree
02:08 hypothesis access health check failed
02:10 decision   hold failover; access rollback authorized
02:11 action     health credential v42 -> v41
02:12 result     backend healthy; canary commit succeeds
02:14 decision   impact downgraded; data validation remains open

早期假设错误并不可耻，偷偷改写历史才危险。保留被推翻的假设和证据，可以解释为什么 没有执行另一条路径，也能在复盘中发现告警或 runbook 的诱导性。

所有时间以 UTC 为主，并记录 collector clock。若应用、主机和数据库时钟有偏差，先 保存各自时间再估算 offset，不要直接修改原始日志时间。

31.4.2 单一指挥、记录员、执行者与业务接口

单一指挥不等于单一思考

团队模式至少有四个逻辑角色：

还可以增加 HA、storage、security、application 等 subject-matter expert。NIST SP 800-61r3 强调现代响应依赖领导、事件处理者、技术人员、法律、公共沟通和资产 owner 等多方参与；这些角色要由一个协调实体汇合，而不是各自行动。

IC 不必是职位最高或 PostgreSQL 最熟的人，而应能维护共享状态、拒绝未经验证的高风险 动作、召集正确 owner。技术负责人可以给出候选方案，最终由 IC 根据业务目标和授权 选择状态转移。

一次只允许一个命令 owner

可以并行：

• 一组读取 Patroni/DCS；
• 一组确认应用影响和最近变更；
• 一组检查 backup/archive；
• scribe 持续整理时间线。

不能并行：

• 两个人同时修改同一 cluster；
• 一边 failover，一边重启旧 primary；
• 一边 drop slot，一边尝试恢复 consumer；
• 一边回切路由，一边解除写围栏。

每个有副作用的系统在一个时刻只有一个 operator token。执行前读回：

incident / environment / cluster / node
current role / system id / timeline
exact command or API request
expected / timeout / stop / rollback
approver

执行者贴回 exit status、时间与证据引用，不只说“done”。讨论频道、命令频道和业务状态 频道最好分开，避免建议被误当命令、原始日志被转发给无权限人员。

对外更新只说已知边界

一条合格更新包含：

known       checkout writes degraded since 02:03Z
unknown     final cause and whether 318 requests have external side effects
impact      74% write failure; reads unaffected
doing       bad deploy fenced; recovery and topology evidence being checked
next update 02:20Z, or earlier on material change

不要为了显得确定而宣布未经验证的 root cause 或恢复时间；也不要把技术日志直接扔给 业务方。固定下一次更新时间可以减少无序追问，让 operator 保持注意力。

31.4.3 高风险动作的复核、审批与回退

风险分级针对动作，不针对职位

熟练 DBA 执行 R3 仍然是 R3。SEV1 可以缩短等待，但不能让 system identifier、 timeline、目标路径和 writer fencing 变得不重要。

批准之前解析最终目标

审批材料不能只有模板变量：

bad:  drop slot ${SLOT}
good: cluster=pg-prod, system_id=..., primary=pg-prod-2,
      slot=cdc_legacy, active=false, retained=1.31TiB,
      consumer owner=..., rebuild approved=..., command hash=...

最终执行包应包含：

1. 当前证据与目标状态；
2. exact host/service/database/object/PID/path；
3. 命令渲染结果，而不是未解析变量、glob 或 command substitution；
4. 前置条件和权限；
5. 预计持续时间、负载与观察查询；
6. stop condition；
7. rollback、compensation 或不可逆边界；
8. operator、reviewer 与 IC 的时间戳。

审批证明组织授权，不证明命令技术上正确。reviewer 必须独立检查目标、方向和恢复前提， 不能只回一个“LGTM”。

回退、补偿和重建不是同义词

DROP replication slot 无法 rollback；只能让 consumer 从新快照重建。目标数据库已接受 独占写后，切回旧库需要反向对账，不再是路由 rollback。pg_rewind 失败后不能假设重跑 会恢复 target；官方建议此时取新备份。

高风险动作完成后必须运行独立的 verifier。执行命令的人报告成功还不够：服务 owner 验证端点，数据 owner 验证业务 manifest，HA owner 验证 writer/timeline，backup owner 验证归档与恢复链。最后再决定扩大流量或进入观察窗口。

上一节：从症状路由而不是猜根因 · 返回本章目录 · 下一节：单人值守与团队响应 · 查看全书目录 · 查看索引中心