新 ECS 到手先做这 7 项基线检查：时区、NTP、主机名、磁盘挂载与安全组

背景：新实例最容易出问题的，不是买错规格

新买一台华为云弹性云服务器（ECS），多数人第一件事是装软件、部署业务。等到日志时间对不上、服务起不来、磁盘重启后“消失”、远程连不上，才回头排障，成本反而更高。

本文的办法很简单：业务上线前，先花约 15 分钟，把时区、时间同步、主机名、磁盘挂载、端口与安全组这 7 项基线检查按顺序走一遍。每一项都有明确的命令、预期输出和判断标准，不需要额外付费资源，任何一台 Linux 实例都适用。

前提条件

• 已有一台可登录的 ECS，能以 root 或 sudo 用户执行命令。
• 系统为常见 Linux 发行版（本文命令以 openEuler / EulerOS / CentOS / Ubuntu 的通用命令为主，个别差异会在文中说明）。
• 不改动业务数据。凡是写操作，本文都会先说明影响，确认后再执行。

第 1 项：确认时区是 Asia/Shanghai

时区错了，最直接的后果是日志时间与业务时间相差 8 小时，排障时对不上号，定时任务也会在错误的时间执行。

date
timedatectl

预期结果：date 输出的时间与北京时间一致；timedatectl 里 Time zone 显示 Asia/Shanghai (CST, +0800)。如果显示 UTC，立即修正：

sudo timedatectl set-timezone Asia/Shanghai
date

改完后重新登录一次终端，确认提示符和日志里的时间都已变化。不要只改应用的时区配置而忽略系统时区，系统时间是所有服务的基准。

第 2 项：确认 NTP 时间同步正常

时区对了，时间本身还可能漂移。时间偏差过大会导致证书校验失败、接口签名过期、数据库主从复制异常。

timedatectl
sudo chronyc tracking
sudo chronyc sources -v

预期结果：timedatectl 里 System clock synchronized 为 yes；chronyc tracking 的 Leap status 为 Normal，Stratum 一般在 2 到 4 之间。如果系统里没有 chronyc，说明没有安装 chrony，先用发行版的包管理器安装，例如 Ubuntu 用 sudo apt-get update && sudo apt-get install -y chrony，EulerOS / CentOS 用 sudo dnf install -y chrony，安装后执行 sudo systemctl enable --now chronyd 再复查。

注意：不要在同一台机器上同时跑 chronyd 和 ntpd，两个时间同步服务会互相干扰。

第 3 项：确认主机名唯一且可解析

多台实例共用默认主机名时，日志、监控和 CMDB 里很难区分谁是谁，出了问题先要花时间确认是哪台机器。

hostname
hostnamectl
cat /etc/hosts

预期结果：hostname 显示的是你为这台实例起的名字，例如 ecs-web-01，而不是镜像的默认名字；/etc/hosts 里有 127.0.0.1 对应本机主机名的记录。如果需要改名：

sudo hostnamectl set-hostname ecs-web-01

改名后重新登录，提示符会随之变化。主机名只改本机的，控制台上的实例名称也要顺手改成一致，避免控制台和系统里各叫各的。

第 4 项：确认磁盘已挂载，容量符合购买规格

这是最容易在重启后翻车的一环：磁盘当时挂上了，但没有写进开机自动挂载配置，重启后就“消失”了。

lsblk -f
df -hT
mount | grep -E 'vdb|nvme'

预期结果：df -hT 里数据盘的容量与购买规格一致，文件系统类型（如 xfs 或 ext4）明确；lsblk 能看到磁盘和分区。如果数据盘还没挂载，按官方的分区、格式化、挂载流程处理，挂载后务必写进 /etc/fstab，并且用 UUID 而不是设备名。

sudo blkid
cat /etc/fstab
sudo mount -a

mount -a 没有报错，才算通过。常见错误是把设备写成 /dev/vdb1：设备名在重启后可能变化，UUID 不会，所以永远优先用 UUID。

第 5 项：确认关键端口只在需要时监听

用 ss 先看本机到底在监听什么，再对照安全组，两边都要收紧。

sudo ss -tlnp
sudo systemctl status sshd --no-pager

预期结果：能说出每一个监听端口是哪个服务、为什么要开。22 端口只应对事先约定的管理地址开放；业务端口只开给需要访问它的来源。ss 输出里如果看到不认识的端口，先查是哪个进程在用：

sudo ss -tlnp | grep :8080
ps -ef | grep 进程名

确认不是业务需要的进程再处理，不要直接 kill 掉不认识的进程，生产环境先停掉再观察。

第 6 项：核对安全组，只放行业务必需的入口

操作系统层面没开端口，安全组放行了也进不来；反过来，操作系统开了端口，安全组却放行了全网，等于门没锁。两者要一起核对。

控制台路径：进入 ECS 实例详情页，看到安全组后逐条检查入方向规则，重点看三处：协议与端口、来源地址、优先级。

检查标准：生产实例的 22、3389、3306、6379 等管理与数据库端口，不应对 0.0.0.0/0 开放；业务端口只放行负载均衡、客户端网段或指定的固定 IP。出方向一般保持默认即可。改完规则后不要只看控制台，立刻从外部实际访问一次，确认“该通的通、该拦的拦”。

第 7 项：确认系统更新源与基础工具可用

基线检查本身不做大版本升级，但要确认包管理器能正常工作，避免以后装软件时才发现源不可达。

cat /etc/os-release
sudo dnf check-update 2>&1 | head -20
# Ubuntu 系统用：sudo apt-get update 2>&1 | tail -20

预期结果：os-release 显示的发行版与镜像一致；更新源能正常返回，不报 404 或连接超时。如果源不可达，先检查实例能否访问外网、DNS 是否正常、是否走了代理，再在控制台核对安全组出方向规则。

验证：把 7 项结果一次性对一遍

以上 7 项做完后，重新跑一次只读命令收尾，确认没有哪一步是当时看着对、现在又变了：

date && timedatectl | grep -E 'Time zone|synchronized'
hostname && hostnamectl --static
lsblk -f && df -hT
sudo ss -tlnp

建议把 7 项结果写成一张小表记下来，包括每项的命令输出关键行和判断结论。这样以后排查问题时，第一句就能说清“这台机器的基线是什么时候、由谁、以什么状态通过的”，而不是凭记忆猜。

如果这台实例以后要做升配、换盘、改安全组，验证步骤和上一篇文章是一样的思路：改完先在控制台确认，再到系统里确认，最后到业务上确认，三层都对得上才算完成。

常见坑

• 只改了应用时区，没改系统时区，日志和计划任务仍按 UTC 走。
• NTP 没同步就启动需要签名的接口调用，报签名过期，查半天以为是密钥问题。
• 多台实例主机名相同，日志聚合后分不清来源，最后只能按 IP 反推。
• 磁盘用设备名写进 /etc/fstab，重启后设备名变化，实例进不了系统。
• 只在系统里关了防火墙，却忘了安全组还放行着全网管理端口，等于只锁了一道门。
• 安全组改完不实测，到了真正需要访问时才发现规则写错了端口或来源。

小结清单

• [ ] 时区为 Asia/Shanghai，date 与北京时间一致。
• [ ] NTP 已同步，System clock synchronized 为 yes。
• [ ] 主机名唯一且与控制台实例名称一致。
• [ ] 数据盘已挂载，容量与规格一致，/etc/fstab 用 UUID 且 mount -a 无报错。
• [ ] ss -tlnp 的每个监听端口都能说明用途。
• [ ] 安全组入方向只放行业务必需端口，管理端口不对全网开放。
• [ ] 包管理器更新源可用，系统版本与镜像一致。

7 项都通过后，再部署业务。以后每次新开实例，都按这张清单走一遍，排障时至少能排除一半的“环境问题”。