做后端、搞独立开发、帮朋友公司搭服务器的朋友，应该都有过这种经历：拿到一台新服务器，第一反应不是直接开干，而是先发一会儿呆。配置怎么选？系统装哪个版本？端口开哪些？服务怎么托管？日志放哪儿？监控怎么做？这一串问题要是没想清楚，后面业务一上来，光排查故障就能耗掉你大把时间。

这文章我就围绕“servers”这个主题，把从选型、初始化、安全加固、部署核心服务到监控告警、故障排查的完整链路捋一遍。内容不是教科书式的科普，而是我这些年实际运维服务器时实打实的操作习惯和踩坑记录。适合刚接触服务器的新手，也适合那些已经跑着业务、但想系统梳理一遍运维细节的全栈工程师。

1. 服务器选型的核心逻辑：先搞清楚它要干什么

1.1 不同业务场景下的配置侧重完全不一样

很多人买服务器有个惯性：预算够就上高配，核数越多越好，内存越大越好。但实际跑起来你会发现，配置和业务场景不匹配才是最尴尬的事。

拿最常见的三种场景举例。

静态资源托管，比如一个个人博客、公司官网、前端打包后的静态文件分发，这类业务对计算能力几乎没有要求，2核4G跑Nginx或者Caddy绰绰有余，瓶颈通常在带宽而不是CPU。动态API服务，比如Java、Go、Python写的后端接口，这类业务主要看并发模型和IO模型，4核8G起步算是比较稳妥的基线，但如果接口里有大量数据库查询或者外部HTTP调用，内存和连接数反而更容易成为瓶颈。数据库专用节点，这个最特殊，随机读写性能决定一切，CPU可以不用那么顶，但磁盘必须是NVMe SSD，内存越大越好，因为像MySQL的InnoDB缓冲池、PostgreSQL的shared_buffer，本质都是拿内存换磁盘随机IO。

所以选配置之前，先想清楚一件事：这台服务器是拿来跑什么业务的？它的瓶颈会在哪里？然后反向推导配置，而不是对着云厂商的套餐表纠结。

1.2 配置计算不是玄学，是可以估算的

选配置时最实用的方法是做简单容量估算，不必精确，但能排除明显不合适的选项。

内存是最容易估算的。如果你跑一个Java应用，JVM堆设4G，那么实际进程占用的内存大概是堆的1.5到2倍，因为要算上元空间、线程栈、GC相关结构、JIT编译缓存。再加上操作系统本身就要占用几百M到1G，Putting it together，一台8G内存的服务器跑一个4G堆Java进程已经比较紧张了，留点余量的话建议至少16G。别对着任务管理器里的数字算账，Linux下看的是实际可用内存，不是表面数字。

带宽估算也经常被忽视。注意带宽单位是bit，流量和请求体积单位是Byte，换算时要乘以8。假设你的接口平均响应体是100KB，高峰期QPS是100，那需要的峰值带宽大约是100KB乘以100QPS乘以8等于80Mbps。这个算法很粗糙，但能让你对“5M带宽够不够”这种问题有一个基本判断。很多新手服务器卡，不是配置不够，而是带宽被打满了，日志里全是连接超时，你还在傻傻地排查CPU。

CPU的选择上，要看业务是CPU密集还是IO密集。计算密集型，比如图片处理、视频转码、加解密签名，优先考虑高主频，核数反而没那么关键。IO密集型，比如Web服务、API网关，对CPU核心数更敏感，因为要处理大量并发连接和上下文切换。如果是数据库，CPU主频重要，但更重要的是内存和磁盘先跟上，否则CPU大部分时间都在等待IO。

1.3 物理机、云服务器、容器到底怎么选

这个话题经常被混淆，其实它们根本不是一个维度的事。

物理机适合GPU训练、高性能计算、或者有硬性合规要求必须物理隔离的场景。优势是性能完全独享，没有邻居，劣势是成本高、扩容慢、硬件故障要自己处理。云服务器适合绝大多数中小业务和创业团队，核心价值是弹性：按量付费、快照备份、安全组、负载均衡这些能力都是开箱即用。容器是部署层面的技术，不直接替代服务器，但它会影响你怎么规划服务器——比如用Docker部署业务，操作系统上就不用装太多运行时，服务器更像一个“干净的底座”。

选云服务器还有一个容易忽略的点：地域。如果你面向国内用户，地域选在离用户近的城市，延迟会低不少；如果你面向海外用户，就选对应的区域节点。另外注意区分“公网带宽”和“内网带宽”，如果业务是云服务器之间的服务调用，尽量走内网，又快又省流量费。

2. 系统初始化与安全加固：新服务器到手后的第一件事

2.1 操作系统选择与分区规划

操作系统我一般推荐两条路线：Debian系的Ubuntu LTS或者Debian stable，适合大多数业务，包管理是apt，生态好、更新稳、文档多；RHEL系的AlmaLinux或者Rocky Linux，适合公司内部本来就统一用CentOS风格的环境，包管理是dnf/yum，生产环境里也很常见。至于CentOS 7已经停止维护这件事，还在用的尽早迁移吧。

系统装完后，第一件事就是分区规划。这一步在装机时就要想好，后面再改分区就痛苦了。我自己的习惯是至少分四个区：/boot单独一个分区，放内核和引导文件，不跟系统盘混在一起；/分区，系统本身；/var/log单独分，防止日志写满把根分区撑爆，这个坑我踩过，日志一涨整个系统就进入只读或者服务全部异常；/data或者/opt单独分，放业务数据和软件。数据盘最好用独立的云盘或者物理盘，跟系统盘分离，这样系统崩溃不影响数据，快照备份也能分开做。

swap分区要看内存大小来决定。内存小于2G的机器，swap可以设为内存的两倍；内存8G以上，个人建议要么关掉swap，要么只设一个很小的兜底（比如2G）。因为现在的物理内存已经足够大，过度依赖swap会导致性能剧烈抖动，尤其是内存密集型应用，卡起来你会以为死机了，其实是swap在拼命换页。

2.2 SSH安全加固是防御工作的第一线

新服务器到手，除了改root密码（严格来说应该直接禁用root远程登录），第一件事就是处理SSH。

首选方案是创建普通用户，加入sudo组，日常操作都用这个用户登录，需要管理员权限时再sudo。然后修改/etc/ssh/sshd_config，至少要包含这几项：

PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes Port 2222

把SSH端口从22改成别的端口，比如2222，不是为了安全，而是为了减少那些全网扫描的爆破尝试，日志会干净很多，对心理压力也有好处。改完端口记得要同步防火墙和安全组规则，不然改完你自己就连不上了，这个我干过不止一次。

生成密钥对时，建议用ed25519算法，比RSA短且快：

ssh-keygen -t ed25519 -C "your-name@your-server" ssh-copy-id -p 2222 user@your-server

别忘了在sshd_config里把AllowUsers或者AllowGroups加上，只允许指定的用户登录。这一步能挡住绝大多数“扫到弱密码就爆破”的脚本。

另外强烈建议装fail2ban，专门对付SSH爆破。配置起来很简单，Debian系执行apt install fail2ban，然后写一个jail.local覆盖默认配置：

[sshd] enabled = true port = 2222 maxretry = 3 bantime = 3600

这个配置的意思是同一个IP在10分钟内尝试3次失败就封1小时。实测下来，服务器在公网裸露一段时间后，fail2ban里会积累一堆封禁记录，它能帮你挡掉大量低水平攻击。

2.3 自动更新与基础工具配置

安全补丁必须及时打，但也不能无脑自动重启。Ubuntu上可以用unattended-upgrades配置自动安装安全更新，但是把自动重启关掉，改成手动维护窗口重启。内核升级尤其要谨慎，因为可能存在驱动兼容性问题，比如某些云厂商的定制内核模块。

基础工具我通常都会装一套：curl、wget、htop、iotop、iftop、lsof、netstat（其实现在更多用ss）、git、tmux、vim、jq。这些工具平时不起眼，排查问题时一个都不能少。tmux一定要装上，SSH一断会话就丢的问题只有被坑过才知道痛。

系统时间同步也不能漏，安装并启用chrony或者systemd-timesyncd，保证NTP同步正常。服务器时间偏移带来的问题非常隐蔽——HTTPS证书验证失败、日志时间顺序错乱、分布式系统里的注册中心心跳异常，都是时间惹的祸。

3. 部署架构与核心服务配置：让服务稳定跑起来

3.1 Nginx反向代理配置实例

现在的业务极少裸跑应用进程对外提供服务，几乎都是前面挂一个Nginx，充当反向代理、静态资源服务、SSL终结、负载均衡、限流缓冲。

一套Nginx配置我通常会分成几个文件：nginx.conf管全局，conf.d下面分站点配置。一个比较完整的server块长这样：

server { listen 443 ssl http2; server_name api.example.com; ssl_certificate /etc/nginx/certs/api.example.com.pem; ssl_certificate_key /etc/nginx/certs/api.example.com.key; client_max_body_size 20m; gzip on; gzip_types text/plain text/css application/json application/javascript; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_connect_timeout 10s; proxy_send_timeout 30s; proxy_read_timeout 30s; } access_log /var/log/nginx/api.access.log; error_log /var/log/nginx/api.error.log; }

这里有几个容易被忽略的点。client_max_body_size如果没设，默认是1M，用户上传大文件直接给你报413，排查半天原来是Nginx默认值。proxy_read_timeout的意思是后端在多久内必须返回数据，如果你的接口本身就有长耗时任务，要根据实际业务调大，不然后端还在处理，Nginx这边已经超时断连了。

改完配置务必先执行nginx -t检查语法，没问题再nginx -s reload。reload是平滑重载，不会断开现有连接，这是生产环境改配置的标准操作，千万不要用restart。

3.2 用systemd把应用托管起来

应用进程怎么启动、崩溃了怎么办、开机怎么自启，这是每个服务器都会遇到的问题。systemd是现在Linux系统的事实标准，一个unit文件就能解决。

我在/etc/systemd/system/下面建一个服务单元，比如myapp.service：

[Unit] Description=My Application Service After=network.target [Service] User=deploy WorkingDirectory=/data/myapp ExecStart=/usr/bin/java -Xms4g -Xmx4g -jar myapp.jar Restart=always RestartSec=10 Environment=SPRING_PROFILES_ACTIVE=prod LimitNOFILE=65535 [Install] WantedBy=multi-user.target

这里重点说两个参数。Restart=always的意思是不论什么原因退出都自动拉起，生产环境服务必须这么配，否则进程一挂整条业务链就断了，如果业务还没接监控，你能发现的时候已经过去好几个小时。LimitNOFILE这个尤其关键，Linux默认的文件描述符上限是1024，一个稍微有点流量的应用瞬间就能把文件描述符耗尽，报OutOfMemoryError或者Too many open files，你以为加内存能解决，其实是文件句柄不够。

写完后执行daemon-reload重载配置，再enable加开机自启，然后start。以后查看状态就systemctl status myapp，看日志journalctl -u myapp -f，日志按天轮转也可以交给logrotate。

3.3 数据库与缓存的常用参数调整

数据库是服务器上最娇气的组件，很多人装了MySQL就默认配置跑，结果数据量一上去就卡成幻灯片。

MySQL最核心的参数是innodb_buffer_pool_size，这个值决定了InnoDB把多少数据缓存在内存里。经验值是物理内存的50%到70%，但不能无脑设高，要考虑机器上还跑不跑其他服务。我见过有人在一台8G的机器上给MySQL配了6G缓冲池，结果Java应用直接内存溢出，两边打架。

另外几个值得改的参数：

max_connections = 500 innodb_io_capacity = 2000 slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 2

慢查询日志一定要开，这是性能优化的第一手资料。哪个接口把数据库拖慢了，打开慢查询日志看执行时间和扫描行数，基本就能锁定。

Redis配置相对简单，但要关注几点。maxmemory必须设置，比如设置为物理内存的70%，否则Redis会吞掉全部内存，导致OOM Killer把它杀掉。持久化策略RDB和AOF要有取舍，个人建议日常业务开AOF但设置everysec刷盘，数据丢失窗口最多一秒，性能损失可控。另外保护模式默认开着，没改配置的话Redis不应该暴露到公网。如果必须走网络访问，至少设置requirepass并限制bind地址。

4. 监控告警与日志体系：没监控的服务器就是裸奔

4.1 基础三板斧：load、内存、磁盘快速查看

监控系统没搭起来之前，先用系统自带的基础工具快速判断问题。这个阶段你只需要几个命令。

uptime看负载均衡值，比如load average: 2.50, 1.80, 1.20，三个数分别代表1分钟、5分钟、15分钟的平均负载。重点不是看数字大小，而是看趋势：如果1分钟负载比15分钟高，说明系统正在经历一个短时高峰；如果15分钟一直很高，说明可能一直处于打满状态。注意load高不代表CPU满，io wait高的时候load也会高。

free -h看内存，要理解buff/cache是可以回收的缓存，别看到used很高就慌。真正要关注的是available，这才是系统实际可用的内存。如果available持续走低，才需要考虑加内存或者排查内存泄漏。

df -h看磁盘使用率，建议磁盘使用率超过80%就开始处理，别等到95%再动手。还有一个容易忽略的是inode耗尽，df -i看一眼，文件数超限也会导致磁盘明明有空间但写不进文件。

4.2 Prometheus加Node Exporter加Grafana的组合

基础命令适合临时排查，但真正常态化的监控还是需要一个监控系统。我用的组合是Prometheus加Node Exporter加Grafana，这套方案免费、稳定、生态大，个人项目和中小团队都够用。

最轻量的部署方式是用Docker Compose拉起一套：

services: node-exporter: image: prom/node-exporter:latest restart: always network_mode: host pid: host prometheus: image: prom/prometheus:latest restart: always ports: - "9090:9090" volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml - prom-data:/prometheus grafana: image: grafana/grafana:latest restart: always ports: - "3000:3000" volumes: - grafana-data:/var/lib/grafana volumes: prom-data: grafana-data:

Prometheus的抓取配置在prometheus.yml里：

scrape_configs: - job_name: 'node' static_configs: - targets: ['localhost:9100']

然后用Grafana导入一个现成的Node Exporter Dashboard（比如ID 1860），CPU、内存、磁盘、网络、文件描述符就都有图表了。这里要说一句：监控系统本身只负责采集和展示，真正起作用的是告警。别搭了Grafana看板就以为万事大吉，没人24小时盯着大屏的，还是得把告警接出去。

4.3 告警规则与通知策略

告警建议用Alertmanager来处理，通过邮件、钉钉或者飞书Webhook推送。告警配置的核心是“减少噪音”，不要什么异常都报，否则报多了就没人看了。

我常用的几条告警规则，按优先级排序：

groups: - name: server-alerts rules: - alert: CPUHigh expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90 for: 5m labels: severity: warning annotations: summary: "CPU usage over 90%" - alert: DiskUsageHigh expr: (node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"}) * 100 < 15 for: 10m labels: severity: critical annotations: summary: "Disk available under 15%" - alert: MemoryUsageHigh expr: (1 - (node_memory_Available_bytes / node_memory_MemTotal_bytes)) * 100 > 90 for: 5m labels: severity: warning annotations: summary: "Memory usage over 90%"

配置里有个很关键的词：for。它的意思是指标持续异常多少分钟才触发告警，避免偶发波动刷屏。比如CPU瞬间飙到90%可能是某个定时任务在跑，持续5分钟才告警就合理很多。

告警推送给谁、用什么渠道，团队内部最好定一条原则：值班人能收到就行，别拉全员。如果告警变成狼来了，真正的故障来临时反而没人响应。

4.4 日志轮转与容器日志限制

日志管理最简单但也最容易被忽略。默认情况下很多服务会一直往同一个日志文件里写，一个月下来就是几十GB，把磁盘写满。

Linux上的标准做法是logrotate。一个常见的Nginx日志轮转配置：

/var/log/nginx/*.log { daily rotate 30 compress delaycompress missingok notifempty create 0640 www-data adm postrotate [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid` endscript }

这个配置的意思是天轮转、保留30份、压缩旧日志，轮转后给Nginx发USR1信号让它重开日志句柄。用Docker的话也要注意容器日志无限增长的问题，启动容器时加上：

--log-driver json-file --log-opt max-size=10m --log-opt max-file=3

这样单个容器日志最多30M，不会把宿主机磁盘撑爆。很多服务器磁盘突然满了，一查，全是Docker容器容积的json日志文件。

5. 常见故障排查与避坑手册：我把踩过的坑都写在这里

5.1 文件描述符耗尽与端口耗尽

故障现象通常是应用突然报Too many open files，或者Cannot assign requested address。排查链路是这样的：

先用ss或者lsof检查连接数：

ss -s ss -tan | wc -l

查看当前进程的fd限制和已用fd：

ls /proc/<pid>/fd | wc -l cat /proc/<pid>/limits | grep "open files"

如果看到当前fd数接近软限制，那就调大。这里要区分几个地方：systemd unit文件里配的LimitNOFILE、Nginx配置里的worker_rlimit_nofile、内核级别的fs.file-max，层层都要够。

端口耗尽的问题，多见于高并发短连接场景。大量TIME_WAIT状态连接占着端口和内存，新连接就分配不到端口了。处理方法有几个：调大ephemeral_port_range，比如：

net.ipv4.ip_local_port_range = 1024 65535

开启tcp_tw_reuse，允许复用TIME_WAIT连接：

net.ipv4.tcp_tw_reuse = 1

但这些都只是缓解手段，根源上还是要引导客户端使用连接池，避免频繁创建销毁连接。

5.2 高CPU与高IO的定位方法

CPU打满的时候，先用top找到最耗CPU的进程，然后用top -Hp 找到最耗CPU的线程。如果是Java应用，多一步操作：把线程ID转成十六进制，然后jstack去看到底是哪个线程、在哪个代码段里死循环或者频繁GC。生产环境我一般会抓三到四个线程快照，间隔几秒，看看线程状态是Runnable还是Blocked，能更快定位问题。

高IO同理。先iostat -x 1看设备的%util和await，%util长期接近100%说明磁盘IO已经饱和。iotop可以进一步定位是哪个进程在疯狂读写。确认是数据库还是应用在造成IO压力后，再从慢查询、大表扫描或者大量日志写入这些方向逐步排查。

5.3 常见问题速查表

还有一个高级的坑：服务器内存不足时，Linux会启动OOM Killer杀掉Redis或MySQL，这类进程被强杀后如果没有配置好的自动拉起和告警，业务可能要过很久才被发现异常。所以重要服务必须设置Restart=always，并配上进程级别的守护监控。

5.4 一些值得长期坚持的运维习惯

关于服务器运维，我个人的体会是：稳定比什么都重要，但稳定来自细节。每次变更之前，先把当前状态记录下来，比如配置文件备份、数据库导出一份、当前进程列表存一下，万一出问题可以有干净的回滚点。我习惯在每个系统目录下面放一个init-backup目录，里面存着刚初始化时的原始配置，改乱了随时翻出来对比。

新服务器到手后，第一时间建好文档，记下这么几样东西：机器IP、SSH端口、登录用户、部署了哪些服务、监听了哪些端口、有哪些定时任务。这些信息平时不起眼，但半年后你再回到这台服务器上排查问题，就能省下大量猜测时间。很多线上故障之所以需要几小时才恢复，就是因为接手的人根本不知道服务器上跑着哪些东西。

最后再分享一个小技巧：养成写操作日志的习惯。每次在服务器上做了什么变更，改了什么配置，重启了什么服务，哪怕只是加了一条iptables规则，都在一个固定文件里记一笔，带日期。几个月后再出问题，回头翻这些操作记录，比拿着配置文件和现在对比高效太多了。服务器这个东西，你越尊重它的细节，它越少给你惹麻烦。