31.4 决策、沟通与变更纪律

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

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

五类记录不能混写

类型	含义	示例
fact	有来源、时间和范围的直接观察	02:03Z 写端点 503；直连 primary 只读探针成功
hypothesis	对事实的可证伪解释	HAProxy health credential 可能失效
decision	在不确定性下选择目标或约束	在证明 writer 唯一前禁止 promote
action	获授权并实际执行的状态改变或测试	回退 exact health-check secret version
result	动作后重新观察到的事实	三个 backend 中仅 DCS leader healthy

“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 单一指挥、记录员、执行者与业务接口

单一指挥不等于单一思考

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

角色	负责	不负责
incident commander	目标、优先级、风险门、角色与更新节奏	亲自解释所有技术细节
operator	预检、读回目标、执行一个获批动作、报告原始结果	私自扩大范围或并行试命令
scribe	UTC 时间线、证据 ID、决定、结果和待办	把聊天摘要伪装成事实
business liaison	用户影响、业务优先级、外部副作用和状态更新	替数据库团队选择技术命令

还可以增加 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 高风险动作的复核、审批与回退

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

级别	例子	最低控制
R0 观察	短超时聚合 SQL、只读 REST、配置 hash	范围、来源、timeout
R1 可逆 containment	限制一个 job、摘掉一类非关键流量	exact target、owner、验证、恢复条件
R2 受控状态变更	terminate 精确会话、有限且可回退的路由调整、drop exact rebuildable slot、隔离 failover 演练	IC 批准、独立技术复核、回退/补偿
R3 生产敏感/潜在不可逆	生产 failover 或 authority cutover、覆盖恢复、rewind、`pg_resetwal`、手工页修复	保存原件、明确授权、双人 command review、停止线

熟练 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=...

最终执行包应包含：

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

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

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

类型	含义	例子
rollback	恢复原状态且没有新独占事实	目标写入前切回 copy-mode 旧集群
compensation	原动作无法抹去，新增反向业务动作	已发退款后执行会计冲正
rebuild	丢弃一个非权威副本，从权威来源重建	failover 后重建旧 primary 为 replica

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

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

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