判断 CPU、内存和磁盘是否造成故障

本机测试与外部测试需要分开进行。服务器本机能够访问而外部无法访问，重点排查监听地址、防火墙、安全组、负载均衡和访问控制；本机访问也失败，则应优先查看应用配置、依赖服务、资源👍压力和错误日志。

把检查结果整理成明确结论

服务器连通性检查首先要区分“主机不可达”和“应用不可用”。从客户端执行连通性测试时，先确认服务器地址、▶️网络线路和访问端口是否正确。能够收到🌅 ping 响应，只能说明网络层可能可达，不能证明远程登录或业务端口一定正常；部分服务器会禁用 ping，此时应直接测试实际使用的端口。

日志内容出现敏感信息时，应在共享排查结果前清理账号、令🌺牌、密钥和用户数据。完整保留时间、错误级别、组件名称和上下文，通常比复制整份日志更适合协作分析。

检查服务器状态的标准顺序

磁盘检查需要同时查看空间和 inode。磁盘空间满会阻止日志、🌺临时文件、数据库文件或上传文件继续写入，inode 用尽则可能在仍有剩余容量时无法创建新文件🍀。定位大文件时，应先确认业务目录和日志目录，再进行清理或扩容，避免直接删除正在使用的文件。

先确认服务器是否能够连通

检查服务器状态时，应按照“网络是否可达、端口是否监听、服务是📌否运行、资源是👍否充足、日志是否报错、业务是否可用”的顺序进行。单独查看某一个服务进程并不能证明服务器正常，因为服务可能仍在运行，但端口未开放、磁盘已满、依赖组件异常，或者请求根本没有到达应用。

错误日志中的时间、进程编号、错误类型和关联组件是定位依据。权限不足通常会出⚡现拒绝访问或无法打开文件，配置错误常见于参数解析❤️失败或配置文件格式错误，端口冲突会表现为地址已被占用，证书、数据库和缓存异常则通常会在应用启动或请求处理阶段留下连续报错。

确认端口监听不等于业务正常

CPU 负载持续升高时，应进一步确认是单个进程占用过高，还是大量请求、定时任务或磁盘等待造成。负载数值不能脱离 CPU 核心数量单独判断，短时❤️间的峰😎值未必代表故障，持续升高并伴随请求变慢才具有更强的排查价值。

应用可用性检查必须从真实请求结果判断。端口处于监听状态，只能说明网✅络连接已经交给某个进程；应用仍可能因为线程池耗尽、数据库连接池耗尽、后端超时、权限异常或业务数据错误而无法正常返回。

依赖服务检查应覆盖数据库、缓存、⚡消息队列、文件存储和身份认证组件。主应用显示运行状态，但关键依赖不可用时，用户仍会遇到超时💯、空白响应、登录失败或部分功能异常。依赖关系应按调用顺序记录，便于确定第一个失败节点。