victormends/incident-response-runbook

    # incident-response-runbook 一个用于 PostgreSQL 环境的生产级事件响应框架，将沟通故障视为一等技术难题来处理。 ## 解决的问题 大多数 P1 事件解决缓慢，源于以下三个原因之一。 第一：技术诊断循环被情绪升级破坏。客户惊慌来电，工程师感到压力而在未准备好答案时猜测，猜错后 20 分钟被浪费在错误假设上，而客户愈发愤怒。 第二：响应者依赖记忆而非结构。经历过五次连接耗尽事件的工程师有脑内清单。面对凌晨两点的第二次 P1 的工程师则没有。解决时间的差异不在于天赋，而在于是否存在可遵循的书面路径。 第三：事后恢复措施被写入后从未回顾。事件关闭后，纠正措施记录在工单中，三个月后同类事件再次发生，因为系统性原因已被识别但预防性修复从未实施。 本运行手册同时解决以上三点。 ## 本仓库包含内容 | 文档 | 类别 | 描述 | |---|---|---| | [`severity-classification/matrix.md`](severity-classification/matrix.md) | 分类 | P1–P4 定义、SLA、升级路径与沟通节奏 | | [`triage/flowchart.md`](triage/flowchart.md) | 诊断 | 从“事件上报”到正确检查清单的 Mermaid 决策树 | | [`diagnosis/connection-exhaustion.md`](diagnosis/connection-exhaustion.md) | 诊断 | 针对 max_connections 耗尽的逐步诊断 | | [`diagnosis/replication-lag.md`](diagnosis/replication-lag.md) | 诊断 | 复制延迟、孤立槽位检测与 WAL 保留监控 | | [`diagnosis/lock-contention.md`](diagnosis/lock-contention.md) | 诊断 | 锁等待链可视化、死锁诊断与紧急解锁 | | [`diagnosis/auth-failure.md`](diagnosis/auth-failure.md) | 诊断 | 认证故障：SCRAM/MD5 不匹配、pg_hba.conf 规则、peer 认证与 TLS | | [`diagnosis/corruption.md`](diagnosis/corruption.md) | 诊断 | 初始腐败分类——症状、验证查询与升级 | | ★ [`runbooks/pg-wal-zero-bytes-free.md`](runbooks/pg-wal-zero-bytes-free.md) | 运行手册 | 针对 pg_wal 磁盘耗尽的完整逐步恢复（Linux、macOS、Windows） | | ★ [`communication/nvc-incident-communication.md`](communication/nvc-incident-communication.md) | 沟通 | NVC 四步框架在事件沟通中的应用 | | [`post-mortem/template.md`](post-mortem/template.md) | 事后恢复 | 包含 5 个为什么、沟通回顾与纠正/预防行动的复用模板 | | [`post-mortem/example-pg-wal-incident.md`](post-mortem/example-pg-wal-incident.md) | 事后恢复 | 实践示例：由孤立复制槽导致的 WAL 磁盘耗尽 | | [`post-mortem/example-connection-exhaustion.md`](post-mortem/example-connection-exhaustion.md) | 事后恢复 | 实践示例：由 ORM 事务泄漏导致连接池耗尽 | | [`escalation/protocol.md`](escalation/protocol.md) | 升级 | 何时升级、准备内容、升级矩阵与客户管理 | | [`war-room/etiquette.md`](war-room/etiquette.md) | 应急响应室 | 角色、三条规则、决策时间盒与事后记录 | ★ 旗舰文档 — 首次阅读请从此处开始。 ## 快速开始 **步骤 1：** 将 [`severity-classification/matrix.md`](severity-classification/matrix.md) 加入书签。收到工单时，先进行分类，再执行其他操作。分类决定你的 SLA、升级路径与沟通节奏。 **步骤 2：** 深入研究 [`triage/flowchart.md`](triage/flowchart.md)，直到可以不看顶部说明直接遵循它。在活跃的 P1 事件中，你需要在 5 分钟内形成初步假设，而流程图正是这条路径。 **步骤 3：** 在下次 P1 之前阅读 [`communication/nvc-incident-communication.md`](communication/nvc-incident-communication.md)。特别要记住降级脚本。你接起客户 P1 电话后的 90 秒决定了接下来一小时是顺利还是糟糕。该脚本是本仓库中最立即可用的资产。 ## 平台支持 所有运行手册与检查清单均包含 **Linux**、**macOS** 和 **Windows** 的命令。SQL 查询与平台无关——可在任意 PostgreSQL 实例上运行。 认证故障诊断涵盖影响 PostgreSQL 14+ 升级的 SCRAM-SHA-256 / MD5 不匹配。WAL 运行手册涵盖 `pg_ctl`、`systemctl` 与 Windows 服务。诊断流程图包含 `journalctl`、`tail`、`Get-Content` 与 `sc query` 等对应命令。 ## NVC 视角 非暴力沟通（NVC）由马歇尔·罗森伯格提出，见于《非暴力沟通：一种生活语言》（1999）。它最初为冲突解决设计，其四步结构——观察、感受、需要、请求——几乎完全映射到事件沟通所需。 NVC 并非附加在技术流程之上的软技能，而是一种精确工具，用于消除事件响应中最昂贵的失败模式：压力下的沟通误解。 其结构上的对应关系直接。在冲突解决中，两人对同一事件有不同感知；在事件响应中，工程师与客户对同一系统故障信息不同。失败模式相同——以评价伪装成观察，导致防御性沟通，形成不产生信息的耗时循环。 NVC 四步结构在第一步就打破这一循环。压力下坚持使用观察语言——例如“数据库自 14:30 部署后已不可达 12 分钟”而非“数据库挂了”——已使后续 30 分钟的效率高于原本水平。 ## 仓库结构 ``` incident-response-runbook/ severity-classification/ matrix.md triage/ flowchart.md diagnosis/ connection-exhaustion.md replication-lag.md lock-contention.md auth-failure.md corruption.md runbooks/ pg-wal-zero-bytes-free.md communication/ nvc-incident-communication.md post-mortem/ template.md example-pg-wal-incident.md example-connection-exhaustion.md escalation/ protocol.md war-room/ etiquette.md LICENSE README.md ``` ## 许可证 MIT —— 参见 [LICENSE](LICENSE)。

标签：ITIL, NVC, P1, PostgreSQL, runbook, SLA, 书面检查单, 事后分析, 多线程, 库, 应急响应, 技术诊断, 故障处理, 数据库, 沟通失败, 生产环境, 结构化流程, 运维, 连接耗尽, 防御加固