服务器出故障时，人最容易在慌乱中先重启、再乱改配置，结果把小问题拖成大问题。华为云服务器（ECS）上跑着的业务，一旦宕机或访问变慢，用户很快就会感觉到。下面按实际排查的顺序，说说重启之前该先看哪几项。
一、先判断问题在哪一层
动手之前，先把故障归到大致的层面上。常见情况大致分为四类。
- 实例状态异常，表现为实例停止、无法启动，或控制台显示异常状态。
- 网络连通性问题，表现为公网访问不了、SSH连接超时，或内网机器之间互通失败。
- 操作系统层问题，比如系统卡死、服务进程崩溃、磁盘写满、内存耗尽。
- 业务应用问题，机器本身没问题，但应用报错、接口超时。
分层之后，很多无用功就能省掉。比如业务打不开，很可能只是安全组没放行端口。这时候重启机器解决不了问题，还会打断正在跑的进程。
二、按顺序排查
第一步：看控制台和云监控
进入华为云控制台，先确认实例状态是不是“运行中”。然后打开云监控（CES），看CPU、内存、磁盘和网络流量的历史曲线。很多故障会在曲线上留下痕迹，比如CPU长时间顶到100%，磁盘使用率在某个时间点突然往上跳，或者网络流量忽然归零。曲线能告诉你问题大概从什么时候开始，排查范围也就小了。
第二步：检查网络和安全组
实例正常、外部却访问不了，就按下面几项逐个核对。
- 弹性公网IP是否已经绑定，状态是否正常。
- 安全组入方向规则是否放行了对应端口，比如22（SSH）、80（HTTP）、443（HTTPS）。
- 操作系统自带的防火墙（firewalld 或 iptables）有没有拦住流量。
- 业务进程是否真的监听在预期的IP和端口上，用 ss -tlnp 可以直接确认。
第三步：用VNC登录
SSH连不上的时候，可以在控制台用远程登录（VNC）直接进入系统。它绕过了网络层，能看到系统真实的开机日志和报错信息，这一步很有用。如果VNC也没有反应，一般说明问题出在内核或引导层，光改网络配置解决不了，需要进一步处理。
第四步：看磁盘、内存和日志
登录之后，先看这几样。
- 用 df -h 查磁盘空间，用 df -i 看inode是否耗尽。inode满了的时候，磁盘即使还有空间，也一样没法写文件。
- 用 free -m 和 top 看内存和CPU占用，找出是哪个进程在吃资源。
- 查看 /var/log/messages 或 journalctl 日志，定位报错发生的时间点，再往前回溯。
三、三个处理案例
案例一：SSH突然连不上，原因是安全组被误改
某电商团队的运维同事在调整一批服务器的安全组时，误把SSH端口的入方向规则删掉了。之后团队发现所有机器都连不上，业务本身却还在正常运行。
处理时，先通过VNC登录其中一台，确认系统和服务都正常，端口也在监听。再检查安全组，才发现22端口的规则确实不见了。补回规则后，SSH马上恢复。这件事之后，团队定下两条规矩：安全组变更先在测试环境验证，生产变更保留回滚记录；运维入口只允许固定的管理网段访问。
案例二：磁盘写满，服务跟着宕机
一台部署了日志采集服务的华为云ECS，某天凌晨业务突然全部报错。云监控显示，磁盘使用率两个小时内从60%涨到了100%。
用 du -sh /var/log/* 很快找到了原因：某个应用的调试日志没有配置轮转，单个文件已经涨到几十GB。处理办法是先清掉没用的历史日志，再重启相关服务，业务随之恢复。事后，团队给这个目录配了logrotate策略，又在云监控里把磁盘告警阈值设为80%。
磁盘一满，数据库、Web服务，甚至SSH都可能受影响。告警阈值定得太高，留给处理的时间就不够了。
案例三：系统补丁升级后无法启动，用备份恢复
某企业做完一次系统补丁升级后，服务器重启一直启动失败，控制台也持续显示异常。通过VNC能看到内核引导阶段的报错，初步判断是系统文件损坏了。
这台实例平时开着云备份（CBR）策略，团队找到了升级前一天的备份副本，恢复到一台新的云服务器上，再把数据盘挂载回去。整个过程大约40分钟，业务影响在可以接受的范围内。复盘时，团队把“升级前手动创建快照”写进了变更流程，之后每次升级都要执行。
四、恢复之后要做的事
业务恢复只是第一步。能降低下次故障概率的，主要靠复盘和预防。
- 把故障的时间线、现象、根因和处理步骤记下来，放进内部知识库，方便下次直接查。
- 定期做备份恢复演练。备份能不能用，只有真正恢复一次才知道，不要等出了事才发现。
- 为CPU、内存、磁盘、网络和关键进程配置云监控告警，并明确每条告警由谁负责处理。
- 安全组、防火墙和系统配置的改动，走审批并留记录。
- 问题超出团队能力时，及时通过华为云官方工单或技术支持寻求协助，提前备好日志和截图，能省下不少来回沟通的时间。
五、小结
华为云服务器故障处理没有什么神秘的地方，关键是按层次排查，别急着动手。先看状态和监控，再查网络和安全组，然后通过VNC进入系统看日志和资源，最后根据实际情况决定修复、回滚还是重建。每次故障处理完，把复盘做扎实，下次遇到类似问题就会从容很多。
