云主机挂了怎么办？别慌，一个老司机的抢救全流程
凌晨两点半，手机突然像诈尸一样疯狂震动，我迷迷糊糊地摸到床头柜上的手机，眯着眼睛一看，屏幕上赫然跳动着来自监控平台的几十条告警推送，脑子“嗡”的一声，最后一排字看得最清楚：“服务不可达”、“HTTP 502”、“连接超时”，那一刻，所有睡意瞬间蒸发，我叹了口气，摁亮台灯，知道今晚注定又是一个不眠夜——云主机挂了。
相信做运维、开发，或者自己是站长、个体老板的朋友，对这种场景都不会陌生，云主机就像我们互联网业务的“心脏”，它一旦停跳，整个业务就瘫了，而“云主机挂了怎么办”，这个问题几乎成了每个互联网从业者的必修课，在无数个与主机故障搏斗的夜晚之后，我想把我的经验梳理成一份相对完整的“求生指南”，希望能帮你在下一次遭遇“瘫痪”时，少走一些弯路，心里能更有底。
很多人，包括我早期犯过最严重的错误，就是一看见网站打不开，立刻冲进控制台点了“重启”或者“强制关机再开机”。这个操作，在大多数情况下，是绝对错误且致命的。
试想一下，你的机器突然遭了“车祸”，最要紧的是先搞清事发现场是什么样，而不是先把车拖走，直接重启，会抹掉非常关键的第一手故障信息，进程是哪个模块先崩溃的？内存是瞬间冲上去的？磁盘读写是永久卡死的？这些痕迹，随着进程重启、临时文件被清空，都会消失得无影无踪，没有这些信息，你后面的排查会变成大海捞针。
无论手有多痒，先告诉自己：“让我先看看现场”。
你心想，好吧，先排查，于是你熟练地点开SSH客户端，输入IP地址，准备上线操作，你很可能遇到第二个噩梦——连不上。
这比主机死透更让人抓狂，主机到底是在响应，只是网络不通了？还是物理机都宕了，虚拟机本身就不存在了？这时候，你需要立即启用你的“B计划”：
1、VNC / 管理终端： 几乎所有的云厂商（阿里云、腾讯云、AWS、Azure等）都提供了网页端的远程管理终端，或者叫VNC，这就相当于绕过了操作系统网络层，直接从虚拟化底层给了你一个“手摇把手”，立即打开它，如果能连上，说明主机内核、网络服务本身没问题，只是你应用的网络或SSH服务挂了，可能是你改错了防火墙规则，或者SSH服务被踢死了，在管理终端里，你可以用iptables -L -nv看防火墙，用systemctl status sshd看服务的状态，直接排障。
2、控制台的“云监控”： 紧接着，别只在命令行里闷头找，立刻打开云厂商控制台的监控面板，CPU使用率是100%空转？还是0%说明CPU彻底没活儿干？内存是爆了？磁盘I/O是不是阻塞在接近100%？网络带宽是不是被打满了？这些指标像医院的“心电图”，能给你最直观的诊断方向。
第三步：开始“验伤”——除了重启，还有什么招？
通过管理终端一旦连上，你的排查工具箱就应该全面上线了，下面是我常用的几个“望闻问切”手段：
1. 看看是不是“饿死”了（CPU/内存）
top命令，这是老兵永远的神器，输入top，按P（大写）按CPU占用排序，按M（大写）按内存占用排序，如果你看到一个或者几个Python、Java、Node.js进程直接占满了CPU，很可能是代码死循环或者被攻击了，直接找到PID，用kill -9先干掉肇事进程，业务能快速恢复一部分，内存同理，如果Swap被用满，说明物理内存不够了，系统被强制换页拖慢到“假死”。
2. 看看是不是“堵死”了（磁盘IO）
这是现代云主机最容易忽视的问题，用iostat -x 1 3或者dstat -d，如果你看到await（平均IO等待时间）几千毫秒，或者%util常年100%，说明磁盘在“堵车”，这通常是两个原因：一是某个进程在疯狂写日志（比如没关的debug日志）；二是数据库（MySQL、MongoDB等）突然有大量查询和写入，把磁盘IO塞满，如果是日志，赶紧docker logs或tail -f看看哪个日志文件在疯涨；如果是数据库，可能需要临时限制并发或优化慢查询。
3. 看看是不是“不通顺”（网络）
ping一下百度，或者ping你业务依赖的其他服务地址，如果能通，说明外网没问题，再看看ss -tlnp，看看你的Web服务（Nginx/Apache，端口80/443）是不是在监听，如果服务在，但是外部连不上，十有八九是云厂商的安全组或者系统内防火墙（iptables/firewalld）把你给拦住了，去控制台看一眼安全组规则，是不是手滑把入方向全关了。
第四步：如果真的是“死透”了——SSH不通，VNC也连不上
你耗尽所有办法，甚至尝试了重启（在万不得已，且数据不重要的场景下），发现还是连不上，或者VNC直接给你显示一个黑屏或死机画面，这时候，认命，承认这是云主机级别的彻底崩溃，这通常是宿主机出问题（硬件故障、内核Panic等单独跑不起来的严重状况）。
这是另一个分水岭：你要权衡“恢复速度”和“数据完整性”。
1、极致追求数据完整性： 你的业务数据（数据库、用户上传文件）在之前的快照或者备份里，你需要去控制台，创建快照或镜像，然后基于这个快照新开一台同配置的主机，这是最稳妥的，花15分钟起一台新机器，把你的应用部署进去，然后切流量。
2、极致追求恢复速度： 如果你的业务侧做了很好的无状态化（比如会话数据存Redis，文件存OSS），那么恭喜你，你甚至不用管这台坏机器，你只需要做一件事：启动备用主机，或者用自动化编排工具（如Terraform、Ansible）自动扩容，从新镜像快速拉起一台新机器，把DNS解析或者SLB（负载均衡）的后端服务器，从坏机器上解绑，绑定到新机器上，整个过程，熟练工可以在5分钟内完成。这就是为什么云架构花里胡哨，最后都是回归到“高可用”和“可替换性”上。
等业务恢复，咖啡续命完毕，千万别觉得完事儿了，如果你不想下次凌晨两点半再被叫起来，你必须做一次彻底的复盘。
看日志：去CloudWatch、阿里云日志服务或者你自建的ELK（Elasticsearch, Logstash, Kibana）里，把故障时间点前后半小时的日志全拉出来，系统日志（/var/log/messages）、应用日志（你的业务打印的）、Nginx访问日志，一行一行看，你会发现，90%的故障，罪魁祸首都是“人”。
找原因：是代码bug导致内存泄漏？是运维改错了配置？是被脱裤了？还是没买够扩容包？
建防线：有了原因之后，立刻改。
代码层：加熔断、限流，设置内存最大限制。
运维层：把手动的操作全部用CI/CD自动化脚本代替，杜绝“手滑”。
监控层：不只是报CPU、内存，还要监控磁盘IO、连接数、慢查询数。
架构层：推快照策略（至少每天一次）、推远程备份、推异地容灾，不要嫌麻烦，今天的麻烦，就是为了明天不麻烦。
云主机挂了，那一刻的慌乱和焦虑，是刻在每个互联网从业者心里的，但人的成长往往就来自于这些事故，解决问题的那股子韧劲，和事后复盘时的憨笑，比任何正经的培训都管用。
技术永远依赖工具，但最终依赖的是你、我这些使用工具的人，与其临时抱佛脚，不如平时多修行，定期做故障演练，模拟机房断电、网络攻击、高流量冲击，把这些模拟演练当作日常游戏的一部分，当你对这个“云主机挂了怎么办”的问题，能像面对小学算术题一样从容地分析、分步骤、拿结果的时候，你就已经从一个新手，蜕变成了一个能扛事、值得信赖的老司机了。
好了，天快亮了，把这篇文章收好，再去补个回笼觉，愿你今晚的梦里，只有平稳运行的绿码，没有惊心动魄的红警。
文章摘自：https://idc.huochengrm.cn/zj/25817.html
评论