运维案例 vps日本 cn2 故障响应与自动恢复实践

1. 故障发现 — 被动与主动监控

1) 被动告警：接入监控（Zabbix/Prometheus + Alertmanager），设置关键指标：ICMP 丢包率、RTT、HTTP 200、TCP 端口可达。触发条件示例：连续 3 次 ping 丢包 > 50% 或 HTTP 200 超时 10s。

2) 主动巡检：编写简单 healthcheck 脚本，定期（cron 或 systemd timer）从国内节点（如阿里云/腾讯云国内）对目标 VPS 做 ping + curl。示例命令：ping -c 5 -W 2 1.2.3.4；curl -sS -m 8 -I http://1.2.3.4/health。

2. 快速定位网络层问题

1) 基本连通性：从本地或监控节点执行：ping -c 5 ；mtr -r -c 100 （观察哪一跳开始丢包或延迟剧增）。

2) 路由追踪：traceroute -I 或使用 tcptraceroute 指定端口，留意经过的 CN2 节点和是否在日本入口处丢包；若在境内 CN2 节点丢包，问题可能是运营商链路。

3. 在 VPS 内部的检查步骤（顺序很重要）

1) 登录并检查网络接口与路由：ip addr; ip route show; ip neigh。确认网口 UP 且没有错误（ip -s link show eth0）。

2) 检查服务端口：ss -tulpn | grep :80；curl -I 127.0.0.1:80。若本机可达，说明是外部网络或防火墙问题。

3) 系统日志与内核：journalctl -u network -n 200；dmesg | tail -n 50，排查网卡驱动或链路掉线事件。

4. 手动恢复流程（从最轻到最重）

1) 重启服务：systemctl restart nginx 或 systemctl restart your-app。先重启应用层，若应用异常可快速恢复。

2) 刷新网络配置：systemctl restart networking 或 /etc/init.d/networking restart。对于 cloud-init 管理的实例，使用 cloud-init modules --mode=config。

3) 重启网卡：ip link set dev eth0 down; sleep 2; ip link set dev eth0 up。若怀疑驱动问题，尝试重载驱动 modprobe -r <驱动>; modprobe <驱动>。

4) 最后手段：通过 provider 控制台或 API 发起重启（soft reboot -> hard reboot）。示例：使用 curl 调用 provider reboot API（参见下文自动化段）。

5. 自动化检测与自愈脚本范例

1) healthcheck.sh（放 /usr/local/bin/healthcheck.sh）：

#!/bin/bash
IP=1.2.3.4
ping -c 4 -W 2 $IP >/dev/null 2>&1 || (echo "ping fail"; systemctl restart networking; sleep 10; ping -c 2 $IP >/dev/null 2>&1 || /usr/local/bin/provider-reboot.sh) 

2) provider-reboot.sh：用 provider API 重启实例（示例采用 curl + token，按厂商文档替换 URL/头/参数）。注意保存 API Key 到 /root/.provider_token 并限制权限 chmod 600。

6. 用 systemd 定时器与告警集成提高可靠性

1) 创建 systemd service：/etc/systemd/system/healthcheck.service，ExecStart=/usr/local/bin/healthcheck.sh；创建 healthcheck.timer 每 5 分钟运行。

2) 告警与通知：脚本在执行关键动作前后调用告警 API（Webhook、企业微信/钉钉/Telegram），并将日志写入 /var/log/healthcheck.log，便于审计。

7. 进一步的高可用策略与流量切换（可选）

1) 双机/多地域：准备备用 VPS（不同运营商或不同出口），使用 DNS（带 TTL）或 Anycast/负载均衡做故障转移。修改 DNS TTL 到 60s，发生故障时自动切换到备用 IP。

2) Keepalived + VRRP：若能分配浮动 IP，可用 keepalived 在两台实例间漂移 VIP；配置 health check 脚本决定优先级降级并漂移 IP。

8. 问：如何判断是 CN2 线路问题还是 VPS 本身问题？

答：先从外部和内部两端做对比：若 VPS 本机能访问内网服务（127.0.0.1/localhost），但外部连续丢包或 traceroute 在 CN2 节点出现丢包，则很可能是 CN2/运营商链路问题；若本机也无法访问或网卡日志有错误，优先排查 VPS 本身（服务、网卡、驱动）。

9. 问：自动重启失败时如何保证不会反复重启导致更大问题？

答：在脚本里加入“熔断”逻辑：记录重启计数和时间窗口（如 /var/run/healthcheck.count），超过阈值（例如 3 次/小时）后停止自动重启并升级为人工告警；同时发出详细诊断日志供人工分析。

10. 问：使用 provider API 重启有哪些安全与权限注意事项？

答：仅将 API Key 存放在权限严格的文件（chmod 600），调用脚本限制为 root 执行；日志中不要记录明文 token；使用 provider 提供的最小权限 API Key（仅允许重启/查询实例，不要授予删除或账单权限）。

来源：运维案例 vps日本 cn2 故障响应与自动恢复实践