半夜报警响了，服务器全挂了怎么办
凌晨两点，手机突然疯狂震动，监控平台连发十几条告警：核心业务服务器集群全部失联。这不是演习，是真实发生在我司的一次事故。当时第一反应不是查日志，而是先让服务恢复——毕竟用户可不管你是硬件问题还是代码bug，他们只关心能不能打开网页。
第一步：确认范围，别急着重启
很多人一看到“集群宕机”就想着赶紧重启机器。但这样可能掩盖现场，导致事后排查困难。正确的做法是先通过内网穿透工具（比如 frp 或 nps）连接到跳板机，查看各节点状态。如果所有节点同时离线，大概率是网络或电源问题；如果是部分节点异常，更可能是应用层面的问题。
可以用下面这个简单的脚本批量探测主机存活：
for ip in 192.168.1.{10..20}; do
ping -c 1 $ip > /dev/null && echo "$ip 可达" || echo "$ip 不可达"
done第二步：优先恢复对外服务
如果你用了负载均衡器（如 Nginx 或 HAProxy），第一时间把故障节点从上游摘掉，避免请求打过去造成超时堆积。然后检查是否有备用机房或云上镜像可以快速拉起。我们曾遇到过一次交换机故障导致整个机柜断网，就是靠提前部署在阿里云的备用节点顶住了流量。
临时切换时，记得更新 DNS TTL 提前降下来，不然生效太慢。一般建议平时就把 TTL 设成 300 秒以内，为应急留出空间。
第三步：利用内网穿透做远程诊断
物理服务器没屏幕、不在机房，怎么查问题？这时候内网穿透就派上大用场了。我们在每台服务器上都运行了一个反向代理客户端，把 SSH 端口映射到公网的一个安全入口。
例如使用 frpc 配置：
[ssh]
type = tcp
local_ip = 127.0.0.1
local_port = 22
remote_port = 6000即使主网络中断，只要管理网口还通，就能通过跳板机进入系统，查看 dmesg、journalctl 或磁盘IO情况。有一次发现是某个日志文件暴涨占满根分区，清理后立即恢复正常。
第四步：记录时间线，别光救火
应急过程中随手记下每个操作的时间点：几点几分收到告警、几点几分开始重启、几点几分服务恢复。这些信息对后续复盘至关重要。我们后来整理出一份《5分钟响应 checklist》，包括联系人清单、常用命令、账号密码位置，打印贴在值班墙上。
顺便提醒一句，定期演练比写一百页预案都有用。去年我们搞了一次“拔网线”演练，结果发现备份数据库居然连不上——这种问题不练真不知道。