参考复盘
这 8 篇是在搭建本项目过程中产生的技术记录， 涵盖 nginx 配置、systemd 服务管理、cron 陷阱、安全加固等主题。 每篇包含完整的现象描述、排查路径与验证方法。
关于这部分的定位
这些复盘记录的是环境搭建与调试过程中出现的技术问题， 作为复盘写作的参考样例保留在这里。
个人实操记录在 我的手记 中—— 那里记录的是个人的部署、排障与脚本开发过程。
为什么保留这些样例
一份完整的复盘应该包含：现象、排查过程、根因、修复、验证、预防。 这 8 篇按这个结构写成，可以作为写作模板参考。
其中有两篇记录了"先判断错误、后纠正"的过程—— 这类内容比只写成功结果的记录更有参考价值，因为 排查过程中走弯路是常态。
故障复盘 #001：nginx 崩溃后服务无法自动恢复
| 日期 | 2026-09-13 |
|---|---|
| 环境 | Alibaba Cloud Linux 3.2104 / ECS 2 vCPU 2 GB / 华北1（青岛） |
| 影响 | 进程被杀后站点持续不可用，需人工介入才能恢复 |
| 严重级别 | 中（无自动恢复能力，2 GB 内存机器 OOM 风险高，实际会发生） |
| 处理耗时 | 约 15 分钟 |
故障复盘 #002：nginx 配置注释导致服务无法 reload（以及被安全网拦住的过程）
| 日期 | 2026-09-13 |
|---|---|
| 环境 | Alibaba Cloud Linux 3 / nginx 1.24.0 |
| 影响 | **无服务中断**（配置校验阶段被拦截，nginx 继续用旧配置运行） |
| 严重级别 | 低（被安全网拦住）／但**教训级别高** |
| 处理耗时 | 约 5 分钟 |
故障复盘 #003：cron 任务里未转义的 `%` 导致命令被静默截断
| 日期 | 2026-09-13 |
|---|---|
| 环境 | Alibaba Cloud Linux 3 / cronie / bash 4.4 |
| 影响 | **任务静默失败** —— 无报错、无输出、无告警，看起来像"没执行" |
| 严重级别 | **高**（静默失败是运维中最危险的失败模式） |
| 处理耗时 | 约 20 分钟（含两次被推翻的错误结论） |
故障复盘 #004：nginx reload 静默失败——两个"成功"信号都是假的
| 日期 | 2026-09-13 |
|---|---|
| 环境 | Alibaba Cloud Linux 3 / nginx 1.24.0 |
| 影响 | **配置静默不生效**，磁盘与内存配置分叉；诊断过程中站点一度对访问者返回 429 |
| 严重级别 | **高**（两次错误判断 + 两个虚假成功信号 + 配置分叉） |
| 处理耗时 | 约 40 分钟 |
故障复盘 #005：安全加固被发行版预设静默覆盖——两次无效修复
| 日期 | 2026-09-13 |
|---|---|
| 环境 | Alibaba Cloud Linux 3.2104 / kernel 5.10 |
| 影响 | 1 项加固未生效（静默）；2 次修复尝试无效；无服务中断 |
| 严重级别 | 中（加固静默失效，但无实际损失） |
| 处理耗时 | 约 25 分钟 |
变更记录 #006：部署 fail2ban（含两次自我纠错）
| 日期 | 2026-09-13 |
|---|---|
| 环境 | Alibaba Cloud Linux 3.2104 / fail2ban 1.0.2 |
| 处理耗时 | 约 30 分钟 |
故障复盘 #007：`pipefail` + `grep -q` 制造的间歇性假失败
| 日期 | 2026-09-13 |
|---|---|
| 环境 | bash 4.4 / GNU coreutils / tar 1.30 |
| 影响 | **间歇性假警报**：备份检查随机报告"文件缺失"，实际文件都在 |
| 严重级别 | **高**（静默、间歇、侵蚀监控可信度） |
| 处理耗时 | 约 35 分钟 |
故障复盘 #008：`set -e` + `systemctl is-active` 导致脚本静默中断
| 日期 | 2026-09-13 |
|---|---|
| 环境 | Alibaba Cloud Linux 3 / bash 4.4 / systemd 239 |
| 影响 | **测试脚本中途退出，把 nginx 停在了 inactive 状态**（站点短暂不可用） |
| 严重级别 | 中（服务可恢复，但暴露了危险的脚本模式） |
| 处理耗时 | 约 20 分钟 |