Linux 应急预案是可快速触发、明确动作、有人执行的“操作地图”，聚焦高频故障场景，每类单独成章并标注典型现象与判定阈值，步骤须可执行、可验证、有退路，固化角色、工具与信息源，并通过季度真实演练检验信息、操作、协同断点，持续更新保持实效性。
Linux 应急预案不是写完就束之高阁的文档，而是要能快速触发、明确动作、有人能执行的“操作地图”。核心是聚焦常见故障场景，把“谁在什么条件下做什么、怎么做、做到什么程度”写清楚，而不是堆砌理论。
聚焦真实高频故障，不罗列所有可能性
预案不是故障百科全书。优先覆盖生产环境中真正影响业务的几类问题：系统负载飙升至不可响应、关键服务（如 SSH、Nginx、数据库）进程异常退出、磁盘空间 100% 导致写入失败、网络连通性中断（本机出向 / 入向 / 跨网段）、时间同步严重偏移引发认证失败等。每个场景单独成章，避免混写。
- 每类故障标注典型现象：比如“df -h 显示 /var/log 使用率 ≥95%”比“磁盘空间不足”更可识别
- 明确判定阈值：如“CPU load > 核心数×3 持续 5 分钟”才启动预案，避免误触发
- 剔除低概率或无法现场处置的问题（如 主板 硬件损坏），这类应归入灾备流程
每步操作必须可执行、可验证、有退路
避免出现“检查系统状态”“分析日志”这类模糊指令。每一步都要带命令、预期输出、失败应对。
- 例如磁盘满预案第一步：执行 ls -lt /var/log/*.log | head -5 查看最大日志文件；若发现 access.log.20240515 超过 2GB，立即执行 logrotate -f /etc/logrotate.d/nginx
- 每条命令后注明验证方式：“执行后运行 df -h /var/log，确认使用率回落至 85% 以下”
- 关键操作前加“⚠️ 执行前确认：当前无备份任务在运行（ps aux | grep pg_dump）”
角色、工具、信息源提前固化，不依赖临时查找
故障时没人会翻手册。预案里直接写死联系人、命令别名、配置路径、监控地址。
- “第一响应人：运维 A（手机 XXX）、运维 B（手机 XXX）——非工作时间呼叫值班群 @运维组”
- “必备工具：已预装 iftop（实时流量）、iotop（IO 瓶颈）、journalctl -u nginx –since “2 hours ago“（服务日志）”
- “关键配置位置：/etc/nginx/nginx.conf、/var/lib/postgresql/data/pg_hba.conf、Zabbix 告警链接：http://zbx.example.com/latest?filter=host:web01”
演练不是走形式，要测“断点”和“人反应”
每季度至少一次真实演练，禁用“模拟”“假设”。重点检验三个断点：
- 信息断点：告警是否真能触达？值班人是否在 5 分钟内确认并打开预案文档？
- 操作断点：预案中写的命令，在目标机器上是否语法正确、权限足够、路径存在？（常因版本差异失效）
- 协同断点：当需要 DBA 介入时，联络话术是否清晰？提供哪几个关键指标（如 pg_stat_activity 连接数、慢查询日志片段）？
每次演练后更新预案：补全缺失命令、修正过期路径、增加新发现的误判条件。让预案始终是“活”的操作指南。
