香香甜甜圈接手商城项目之后，我第一次在一台刚交付的Ubuntu服务器上排查支付回调问题时，心里其实有点慌。线上没有图形界面，手里唯一的工具就是SSH窗口和一串串系统指令。也正是那一次之后，我养成了一个习惯：凡是跑商城的Ubuntu机器，不管是新的还是老的，先用指令把家底摸清楚，再谈部署和上线。
这套东西用久了，我干脆把商城项目日常运维和开发过程中真正高频用到的Ubuntu系统指令沉淀了下来。内容不绕弯子，全是实战场景：新服务器进场怎么查系统、多人共用服务器怎么管权限、日志把磁盘写满怎么找罪魁祸首、支付回调不通怎么一层层排查网络。适合刚拿到线上服务器权限的后端同学，也适合被拉去临时顶一下运维的全栈，照着一步步敲就行。
1. 新服务器进场：先把Ubuntu机器的底细盘清楚
1.1 确定版本、内核和CPU架构：判断该装什么包
商城项目踩过的第一个坑，往往不是代码，而是装错软件包。你看着是Ubuntu，但其实是20.04还是22.04，又是x86还是ARM，直接决定后面下载JDK、Nginx、MySQL二进制包时选哪一版。所以我拿到新服务器后的第一条命令永远是：
bash复制cat /etc/os-release
这个文件里能看到VERSION_ID="22.04 LTS"之类的信息。注意，很多人习惯用lsb_release -a，但在新版Ubuntu上这个命令默认是没有的，会提示找不到命令，需要先安装lsb-release包，多此一举。直接用cat /etc/os-release最稳。
接着看内核和架构：
bash复制uname -r
uname -m
uname -r显示内核版本，在排查驱动问题时有用，比如NVIDIA显卡驱动装不上去，经常要核对内核版本和驱动版本的匹配关系。uname -m输出的是硬件架构，x86_64对应amd64包，aarch64对应arm64包。商城项目如果用到了带GPU的机器做商品图识别，装驱动时更要注意这两项。
顺带一提，hostnamectl一条命令可以把发行版、内核、主机名全列出来，懒得打多条命令时用它最省事。
1.2 看CPU、内存、磁盘：决定JVM和中间件参数怎么调
商城系统一跑起来，JVM参数、MySQL缓冲池、Redis内存上限全都跟着机器配置走。不看实际资源就对着网上的模板抄，很容易出事。我见过有人在一台4G内存的服务器上给Java应用分-Xmx4096m，启动直接OOM，服务压根没起来。所以在调任何参数前，先看硬件底牌：
bash复制lscpu
free -h
df -h
lscpu看CPU核数和型号，free -h用人类可读的方式显示内存总量和已用量，df -h看磁盘空间。部署商城项目时，我一般建议根据机器核数来定Tomcat线程池：4核机器起步max-threads给200左右，8核能给到400到500，但别盲目调高，线程多了上下文切换反而拖慢响应。
这几条命令不止部署时用。每次大促前巡检，我固定会跑一遍free -h和df -h，如果swap用得多了或者磁盘超过80%，就要提前处理了。
1.3 时区、网络和主机名：商城日志时间错乱的头号原因
商城项目最怕的事情之一，是日志时间不对。排故障时发现服务宕机在下午3点，结果日志记的是早上7点，那是没设置时区。Ubuntu默认时区不一定是Asia/Shanghai，必须主动改：
bash复制timedatectl set-timezone Asia/Shanghai
date
改完用date确认一下。这算是商城日志系统能不能对齐的第一道保险。再一个是网络，Ubuntu Server版默认没有图形化配置，查看和修改IP都得靠指令：
bash复制ip addr
ip route
cat /etc/resolv.conf
ip addr看网卡IP，ip route看默认网关，cat /etc/resolv.conf看DNS配置。如果是Ubuntu 22.04，网络配置通常写在/etc/netplan/目录下的yaml文件里，改完要执行sudo netplan apply生效。这个跟CentOS的network-scripts方式差别很大，很多从CentOS切过来的人在这儿踩坑。
另外建议顺手设置主机名。商城系统如果用到了注册中心，比如Nacos或Eureka，服务实例上报到控制台时显示的是主机名，不设置的话一串随机ID，到时候连哪台机器都分不清。
bash复制hostnamectl set-hostname shop-api-node1
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 商城服务器不是单机游戏：用户、权限和目录规划
2.1 为什么不让所有人用root直接操作
商城项目的线上机器通常不止一个人碰。后端要发版、运维要调系统、前端偶尔要传静态资源。如果所有人共用root，最直接的后果是出了问题没法追责，误操作了连个日志都留不下来。
所以我的习惯是：给每个需要上线的同学建独立账号，根据职责分配sudo权限。从安全角度讲，这也防止了随意删文件、改配置导致的事故扩大。而且商城涉及交易数据，访问权限的控制本来就应该严格一点。
2.2 创建用户的两个命令，为什么我推荐adduser而不是useradd
Ubuntu下创建用户的命令有两条，新手很容易被绕晕。useradd是先天的底层工具，参数多且名称有迷惑性；adduser是脚本封装，会引导你设置密码并自动建好家目录。
很多人第一次用useradd创建用户，切过去发现连命令行提示符都不对，因为默认Shell还是nologin，而且没有家目录。正确写法是：
bash复制sudo useradd -m -s /bin/bash zhangsan
sudo passwd zhangsan
-m创建家目录，-s指定Shell。即便如此我还是推荐直接用adduser：
bash复制sudo adduser lisi
它会交互式地让你设置密码、补全用户信息，顺手把家目录和Shell都配好。创建完之后给需要管理员权限的同事加上sudo组：
bash复制sudo usermod -aG sudo lisi
注意-aG里的-a很重要，意思是追加到组，不带的话会把用户从其他组里挪出来，容易出幺蛾子。
商城项目一般还要走密钥登录。先在本地生成密钥对，然后把公钥内容追加到服务器上对应用户的~/.ssh/authorized_keys文件里。更方便的做法是使用ssh-copy-id：
bash复制ssh-copy-id lisi@192.168.1.101
它会把本机公钥自动装到远程用户下，还会处理好目录权限。一定要检查~/.ssh目录和authorized_keys文件的权限，过宽会导致SSH拒绝使用密钥：
bash复制chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
2.3 商城项目目录规划：代码、日志、备份分开放
项目上线久了，最怕的是所有东西堆在root目录或home底下，时间一长自己都找不到东西。我维护的商城项目统一按这个结构来组织：
bash复制/data/backend # 各个后端服务的jar包或部署目录
/data/nginx/html # 前端构建产物
/data/logs # 按服务名分目录存放日志
/data/backup # 数据库备份、发布前的版本备份
/data/scripts # 定时任务、启动脚本
用独立的deploy账号来拥有这些目录，然后按需授权。比如前端同事只需要/data/nginx/html的写权限，后端同事需要/data/backend的权限。授权用：
bash复制sudo chown -R deploy:deploy /data/backend
sudo chown -R zhangsan:deploy /data/nginx/html
目录权限我习惯设置为755，普通脚本设为755，配置文件设为644，私钥这类敏感文件设为600。这不算死规矩，但能有效减少“目录别人进不去”“配置文件所有人能看”这类尴尬。
切换用户时注意su和su -的区别：不带-的su只切换身份，不切换环境变量，很多命令会诡异地说找不到；带-的su会模拟完整登录，加载目标用户的环境。我更常用sudo -i，直接以管理员身份开一个登录Shell，适合临时执行运维操作。
3. 日志、磁盘、进程与服务：商城线上事故的高频排查链
3.1 一次日志把磁盘写满的事故复盘
商城项目线上最经典的故障之一，是日志文件把磁盘写满。现象是订单接口突然开始报错，数据库写入超时，登录也失败。我上去先跑：
bash复制df -h
结果显示根分区已经100%。接着用du逐层定位，先看项目日志目录，再看系统日志目录：
bash复制du -sh /data/logs/* 2>/dev/null | sort -rh | head -10
du -sh /var/log/* 2>/dev/null | sort -rh | head -10
当时发现某个订单服务的日志文件已经到了几十G，因为业务方反馈有异常，日志框架的root logger配置成了DEBUG，大量刷屏。常规处理是先删掉日志文件，但删除后磁盘空间依然没释放。原因是那个Java进程还活着，依然持有这个文件的句柄。用下面的命令能找到这些“被删除但还占着空间”的文件：
bash复制lsof | grep deleted
解决办法是重启服务让句柄释放，或者用cat /dev/null > 日志文件把文件内容清空而不是直接删除。前者在生产环境要谨慎，后者虽然简单但不会释放句柄占用的空间，正确做法是配好logrotate让日志按大小或时间滚动。
这次事故之后，我把磁盘检查做成了定时任务，每天凌晨跑一次，超过85%就告警。
顺带说一句，有时df -h看着正常但系统还是报磁盘满，那要查inode是不是耗尽了：
bash复制df -i
inode满通常是小文件太多导致的，比如商城生成的大量订单缓存分片文件或者上传文件的缩略图，删除一部分无用的历史文件即可。
3.2 用systemd和ss管理服务：从nohup到自愈
早期我部署商城后端服务常用的命令是：
bash复制nohup java -jar shop-order-service.jar > /data/logs/shop-order/order.log 2>&1 &
这个方式方便，但有个致命问题：机器一重启，服务不会跟着起来。大半夜机器重启，商城页面整个挂掉，人都找不到，这个坑踩过一次就不会忘记。后来我把所有Java服务都改成了systemd管理，在/etc/systemd/system/下写service文件，然后：
bash复制sudo systemctl daemon-reload
sudo systemctl start shop-order
sudo systemctl enable shop-order
sudo systemctl status shop-order
enable让服务开机自启，status能看当前运行状态和最近日志。商城项目在发布新版本时，如果我们用的是systemd，重启命令应当是systemctl restart shop-order，而不是直接kill进程再nohup，前者的退出和拉起顺序、日志重定向都已经被service文件管理好了。
查进程时，最常见的组合是：
bash复制ps -ef | grep java
ss -lntp
ps -ef | grep java能列出所有Java进程和它们启动参数，ss -lntp则能看到当前所有TCP监听端口以及对应的进程名和PID。后者的好处是检查“服务起来了但端口没监听”这类问题很直观。比如Nginx配置了8080，但ss -lntp里根本没有8080的记录，那说明Nginx实际没起来或配置没生效。
kill进程也讲究方式方法。默认的kill发的是SIGTERM信号，让进程自己处理收尾工作；kill -9则直接强制结束，可能会导致数据没落盘，尤其对MySQL这类进程要绝对避免。所以我一般先：
bash复制kill 12345
等两三秒用ps -p 12345看看进程还在不在，还在再考虑kill -9。
3.3 快速定位大文件和清理技巧
排查磁盘空间时，du一层层进去太慢了。我习惯直接用find找出超过一定大小的文件：
bash复制find / -xdev -type f -size +2G -exec ls -lh {} \; 2>/dev/null
-xdev限制只在当前文件系统里找，不往挂载的其他磁盘上跑，能省很多时间，也避免把备份盘扫一遍。商城项目里，这种大文件多半来自三个位置：日志文件、数据库的binlog、前端静态资源压缩包。日志按前面说的处理，binlog则应该在MySQL配置里设置expire_logs_days，老旧的包如果没有归档价值，删掉即可。
清理日志时还有一个实用技巧：线上服务日志还在写，不能直接rm，腾不出空间，这时用truncate可以将文件置空而不断掉写句柄：
bash复制truncate -s 0 /data/logs/shop-order/order.log
不过这些都是处理症状。根治还是要把日志轮转级别和logrotate配置好，别等问题发生再来救火。
4. 接口调不通、订单推送失败：网络问题排查指令实战
4.1 端口连通性检查：从ss到nc再到curl
商城系统上下游调用很多，一处接口不通就要查是网络问题、防火墙问题还是服务本身没监听。我排这种问题的固定顺序是：先看本机端口有没有在监听，再看能不能连通。
bash复制ss -tlnp
注意-t只显示TCP，-l只看处于LISTEN状态的端口，-n让端口号直接以数字显示，不反解服务名。-p查看占用进程。一个常见坑是服务启动参数里监听的地址写成了127.0.0.1，外部机器的订单中心或前端根本连不上，ss -tlnp会显示127.0.0.1:8080而不是0.0.0.0:8080，马上就能定位到问题。
如果你想从其他机器测试某一台服务器的端口通不通，轻量工具是nc：
bash复制nc -vz 192.168.1.20 3306
-v输出详细信息，-z只扫描端口不发送数据。连接成功会返回succeeded，失败则提示Connection refused或timed out。如果是测试HTTP接口状态，用curl -v看得更清楚，比如支付回调接口502和504的处理思路就差很多：
bash复制curl -v http://127.0.0.1:8080/api/payment/callback
4.2 DNS和路由：域名解析不了不一定是机房问题
有一次商城后台突然访问慢，前端页面资源加载超时。查ping网关通了，但是ping某个公网域名一直失败。这时候重点怀疑DNS解析。用dig工具查一下：
bash复制dig shop.example.com
如果没有dig命令，先安装dnsutils，或者用nslookup也能凑合。查看系统当前的DNS服务器，还是那句cat /etc/resolv.conf。
Ubuntu有个比较坑的地方是systemd-resolved服务会默认占用127.0.0.53:53作为DNS解析入口，如果你自己装Docker或者改了/etc/resolv.conf，经常被它覆盖或冲突。排查时如果发现本机53端口被systemd-resolved占着，而你的应用解析超时，可以考虑调整systemd-resolved配置，或者在网络配置里直接指定可用的DNS服务器，然后sudo systemctl restart systemd-resolved。这种问题在云服务器上遇到的频率不低，跟构建机或本地的解析方式差很多。
路由的问题一般用：
bash复制ip route
比如目标网络走错了网关，或者默认路由丢了，都能从这里看出端倪。如果是跨机房调用失败，还可以在服务器上ping对方网关，用延迟和丢包率判断链路质量。
4.3 支付回调这种关键链路，用tcpdump抓包看真相
有些网络问题用ping和curl测不出来，比如连接被对端RST，或者请求发出去了没有响应。遇到这种情况，我倾向于直接抓包看TCP握手过程。
有一次支付平台回调我们的服务器，nginx日志里什么都没有，但从支付平台那边的日志看它确实发起了请求。两边都说自己没问题，最后只能抓包：
bash复制sudo tcpdump -i eth0 host 203.0.113.10 and port 8443 -w /tmp/pay_callback.pcap
-i eth0指定网卡，host过滤对端IP，port过滤端口，-w把报文保存成文件，之后用Wireshark打开分析，可以看到TCP三次握手是否完成、谁发了RST、是否有重传。当时抓包发现对方请求到了服务器，但服务器的nginx监听端口对应的服务处理超时后主动断了连接，才导致回调始终没进来。这个结论不抓包的话很难定位。
tcpdump对于排查所有“应用程序说没收到”但故障发生在更底层的情况都很好用，关键词是抓本地回环时别忘了指定-i lo，因为商城服务之间互相调用可能走的是127.0.0.1，不抓lo接口什么都看不到。
5. 包管理与软件安装：apt、软件源和容器内的指令差异
5.1 apt 命令详解和几个常见报错的解法
商城服务器上的中间件，像Nginx、Redis，不少同学习惯用编译安装，但Ubuntu下我更推荐优先用apt装发行版自带包，省事且卸载干净。基本流程是：
bash复制sudo apt update
sudo apt install -y nginx redis-server mysql-server
update是刷新软件源索引，相当于告诉系统当前有哪些新版本可用。每次装新东西前先跑一下，否则可能提示找不到软件包或者装到很老的版本。
apt常见报错里，最让人头疼的是“Could not get lock /var/lib/dpkg/lock-frontend”。意思是有另一个apt进程在运行，或者上次异常退出后锁没释放。先等一下，或者用ps aux | grep apt看看是不是有自动更新在跑，确认没有残留进程后再删锁文件。乱删锁文件可能导致dpkg状态不一致，所以这个操作要谨慎。
依赖关系损坏时，比如apt install提示有未完成的配置或broken packages，可以用：
bash复制sudo apt --fix-broken install
还有个小经验：在Ubuntu上安装一些三方仓库的软件时，经常要先执行add-apt-repository，这个命令在干净系统上默认也没有，得先安装software-properties-common。有次我装某个源报错，查了半天才发现不是网络问题，而是这个基础工具没装。
5.2 apt装的软件和源码包安装的软件，管理方式大不同
用apt安装的软件，比如apt install nginx，它的可执行文件通常放在/usr/sbin，配置文件在/etc/nginx，日志在/var/log/nginx，并且自动创建了systemd服务。启动管理直接用：
bash复制sudo systemctl restart nginx
如果用源码包自己编译安装，默认会装到/usr/local/nginx，没有systemd服务文件，启动要么手动执行/usr/local/nginx/sbin/nginx，要么自己写service文件，日志位置也要自己指定。对于需要快速复现测试环境的场景，apt版本够用；如果是深度定制模块，比如Nginx需要加第三方模块，那就得手动编译。这个选择逻辑想清楚，能省不少事。
另外一个细节是apt安装的软件版本通常偏稳定但不会太新。商城项目里如果Redis需要用到较新版本的一些数据结构特性，apt源里的版本可能不满足，那就要用源码安装或者添加官方仓库。不要盲目追求最新，线上环境的稳定性优先，新特性要用之前先在小环境验证。
5.3 Docker容器里跑Ubuntu，指令思维要变一下
现在商城项目基本都有容器化部署。进入一个Ubuntu容器：
bash复制docker exec -it shop-api-container bash
进去之后你会发现它是最小化的Ubuntu，很多常见指令都没有，比如ps、ss、vim都没有。这不是系统坏了，是基础镜像刻意精简了。需要排查时临时装一下：
bash复制apt update && apt install -y procps iproute2 vim netcat-openbsd
但注意，在生产容器里频繁安装软件会导致镜像膨胀，而且容器重启后就没了。规范做法是尽量依赖宿主机的和编排平台的日志能力排查，比如查看容器日志用：
bash复制docker logs -f shop-api-container
或者直接指定只看最近200行：
bash复制docker logs --tail 200 shop-api-container
很多人进入容器后习惯找systemctl去管理服务，比如systemctl restart nginx，在容器里会报错说System has not been booted with systemd。因为容器里的进程1是业务进程，不是init系统。容器里的“重启服务”实际上应该是修改镜像配置后重新创建容器，而不是在容器内部像宿主机一样管理服务。这个思维转变挺重要，也省得在容器里瞎折腾半天。
6. 巡检与习惯：用几条指令让商城项目少出幺蛾子
6.1 一条命令看清楚当前机器健康状态
大促前或者日常巡检，我不喜欢开一堆窗口分别敲命令。可以组合起来一次性看关键信息：
bash复制uptime && free -h && df -h && ss -tlnp | head -20
uptime看系统运行时间和负载，负载值一般不要超过CPU核数的70%，如果8核机器负载长期超过5，说明可能要扩容了。free -h看内存是否存在不足，尤其是swap用量如果持续上涨，说明某些服务内存分配不合理。df -h看磁盘，确认没有资源即将耗尽的风险。ss -tlnp确认核心服务端口都正常监听，比如商城关键的8080、3306、6379、80这些端口。
为了看得更舒服，我习惯把这些命令写成一个巡检脚本放/data/scripts/check.sh，执行一次输出一份报告。脚本内容并不复杂，核心就是把这些命令包起来，设置好颜色标记，超过阈值就输出WARN。日常巡检就变成了登录服务器后执行一行脚本的事情，效率高很多。
6.2 日志查看和内核日志，很多线上故障的苗头提前藏在里面
商城服务异常最常见的是接口偶发超时。这时候除了看应用日志，也要看系统日志：
bash复制journalctl -u shop-order -f
-u指定unit，-f像tail -f一样持续跟踪输出。如果用systemd管理服务，服务自己的标准输出和错误输出会被journald接走，看这个比翻文件更快。
如果怀疑是因为内存不足导致进程被杀，查看内核日志里有没有OOM的记录：
bash复制dmesg -T | grep -i -E 'oom|killed process'
-T把时间显示成人类可读格式。有次商城搜索服务在高峰期突然挂掉，应用日志里什么都没留下，后来查看内核日志发现是OOM killer把进程杀了。触发原因是JVM堆外内存占用过高加上机器本身内存偏小，后来给服务加了堆外内存限制并扩大机器规格才解决。
dmesg能看到的不只是OOM，像是网卡断开重连、磁盘I/O错误、GPU驱动崩溃都会记录在里面。所以排查诡异问题的时候，跑一下dmesg -T | tail -50是个好习惯。
6.3 记录命令历史、使用别名和tmux的长期收益
操作规模上来以后，靠脑子记命令不现实。我给history命令加了时间戳，在/etc/profile.d/里放下这行配置：
bash复制export HISTTIMEFORMAT="%F %T "
这样执行history时每一条记录都有日期时间，回头看某天到底执行过什么命令时，非常有帮助。线上事故复盘时，这些都是最原始的证据。
给高频命令设置别名也可以减少误操作。在~/.bashrc里加上：
bash复制alias restart-order='sudo systemctl restart shop-order'
alias disk='df -h && df -i'
然后source ~/.bashrc生效。但提醒一句，生产环境下别把危险的rm -rf之类命令设成别名，容易手滑。
最后强烈推荐在SSH会话里用tmux或者screen。线上跑数据库备份、日志归档这类长任务时，一旦你本地网络断开，前台执行的任务可能就中断了。tmux里执行命令不受SSH断开影响，等恢复后重新attach回去还能继续操作：
bash复制tmux new -s deploy
tmux attach -t deploy
用tmux跑长任务，是商城项目服务器维护里最划算的习惯之一，几乎是零学习成本把“断线丢任务”的痛点解决掉。
如果非要给后来者一条最简短的经验，那就是：在Ubuntu服务器上操作的每一条指令，最好都要知道它为什么这么输、输出应该怎么解读。很多线上问题不是平台逻辑复杂，而是最基础的“查一下当前机器是什么环境、服务到底在不在监听、资源还有多少”这些动作没做扎实。把这些指令练熟了，商城项目日常的部署和故障处理，心里基本能有底。