综合练习

这一课你将能做到

1. 按固定顺序独立排查四类生产故障：502、端口占用、Permission denied、磁盘打满，全程说出「命令依据」
2. 完成「从裸机到上线」的 15 分钟全流程演练：装环境 → 配服务 → 开门 → 验收，一次通过
3. 产出一份自己的《上线/排障检查单》（≤10 条），并完成一次限时故障演习（15 分钟内定位根因）

为什么要学

单课会命令不等于会运维。生产故障从不单挑：磁盘满引发 MySQL 写失败，MySQL 超时引发 API 5xx，5xx 期间你重启了应用导致配置错乱——故障是链式的，慌乱会毁掉证据。若每次都靠「重装面板/重启整机」，日志没了、根因永远查不到，下次同样慌。

本课把 intro 到 deploy 十二课串成肌肉记忆：四个故障场景（每个都来自真实运维），一次全流程上线演练，最后固化成检查单。练的是冷静的顺序，不是运气。

先建立图像

排障总图：先分层，再下钻

访客报障
  │
  ├─ 1. 应用层   curl 本机端口(3000/8080)      上游活吗？接口健康吗？
  ├─ 2. 进程层   ss / pm2 list / systemctl     进程在吗？谁在监听？
  ├─ 3. 反代层   nginx -t + error.log          转发写对了吗？
  ├─ 4. 资源层   df -h / free -h / top         磁盘/内存/CPU 有没有爆？
  ├─ 5. 权限层   ls -l + 进程用户对照          读得到文件吗？写得了日志吗？
  └─ 6. 门禁层   ufw status + 云安全组          门开对了吗？监听地址对吗？

顺序的意义：从应用层往下查，因为报障最常见的原因就是上游死了；每层都有「快刀」，30 秒内能定性。记住一句行话：先止血，再查因；证据在日志里，别用重启毁掉它。

跟着做

场景一：502 全流程（主推场景，务必走完整遍）

制造故障（实验环境）：

pm2 stop platform 2>/dev/null            # 或 sudo systemctl stop coderoadmap-backend
# 浏览器访问首页 → 502

标准排查链（每步解释现象）：

# A. 上游还活着吗？（应用层）
curl -s -o /dev/null -w "front:%{http_code}\n" http://127.0.0.1:3000/    # 000=死
curl -s http://127.0.0.1:8080/actuator/health; echo

# B. 进程与监听（进程层）
pm2 list
sudo ss -tlnp | grep -E ':(3000|8080)\s'      # 没有监听=没人服务

# C. Nginx 怎么说？（反代层）
sudo tail -20 /var/log/nginx/error.log | grep -i upstream
# connect() failed (111: Connection refused) while connecting to upstream → 印证 A 的结论

# D. 修复 + 验活
pm2 start platform
curl -s -o /dev/null -w "front:%{http_code}\n" http://127.0.0.1:3000/    # 200

解释题（写进笔记）：若 A 中 3000 失败而 8080 正常，502 的是首页还是 /api/？为什么？

场景二：Address already in use（端口占用）

# 制造：用 python 占住 8080
python3 -m http.server 8080 &          # 记下回显的 PID
# 此时重启后端 → journalctl 会看到 Web server failed to start. Port 8080 was already in use.

sudo ss -tlnp | grep 8080              # 定位：谁占的（进程名+PID）
ps -p <PID> -o user,pid,etime,cmd      # 是谁、跑了多久、什么命令

# 处置分流：
# 旧实例没杀干净 → 停它：
sudo systemctl restart coderoadmap-backend
# 是别的服务占的 → 改自己端口（--server.port=8081）而不是杀别人
# 杀掉本场景的实验占用者：
kill %1 2>/dev/null || kill <PID>