我的服务器运维日记

引言

大家好，今天想聊聊我这段时间捣鼓服务器的一些经历。说起来，我接触服务器运维也有一年多了，从最开始的小白到现在的略懂皮毛，中间踩了不少坑，也学到了很多东西。今天就把最近的一些心得体会整理一下，分享给大家，希望能对同样在运维路上摸索的朋友有点帮助。

第一次部署服务的惨痛经历

记得上个月，我信心满满地把第一个 Django 项目部署到服务器上。那时候我天真的以为，不就是 SCP 传个文件，然后 runserver 启动一下嘛。结果现实给了我沉重的一击。

首先，服务器环境一团糟。Python 版本是 3.8，但我的项目需要 3.10。依赖包也是缺这少那，我一个一个手动安装，整整搞了一上午。最要命的是，我直接用 python manage.py runserver 启动服务，结果 SSH 一断开，服务也跟着停了。当时我都懵了，完全不知道发生了什么。

后来才了解到，应该用 Supervisor 或者 systemd 来管理进程。于是我恶补了一波 Linux 进程管理知识，总算把服务跑起来了。不过现在回想起来，那次的部署过程简直是灾难级别的。

监控报警的那些事儿

服务是跑起来了，但我心里还是不踏实。万一服务器挂了怎么办？万一内存爆了怎么办？我不可能 24 小时盯着服务器吧。

于是我开始研究监控方案。最初用的是 Prometheus + Grafana 这套组合拳，说实在的，确实很强大，但配置起来也够复杂的。对于我这种小型服务器来说，有点杀鸡用牛刀的感觉。

后来我换成了更轻量的方案：Node Exporter + Prometheus + Grafana，只监控最核心的几个指标：

- CPU 使用率

- 内存使用情况

- 磁盘空间

- 网络流量

- 进程状态

配置好告警规则后，一旦指标超过阈值，就会收到钉钉或者邮件通知。记得有一次，凌晨三点收到磁盘告警，说根分区使用率超过 90%。我赶紧爬起来登录服务器查看，发现是日志文件没做轮转，几天时间就堆了几十个 G。还好发现得早，不然服务器就要挂掉了。

自动化部署的真香警告

手动部署是真的累。每次更新代码，都要 SSH 登录服务器，git pull，pip install，restart 服务。一套流程下来，至少要十几分钟，而且还容易出错。

痛定思痛，我决定搞自动化部署。调研了一圈，最后选择了 GitHub Actions + Docker 的方案。流程是这样的：

1. 本地 push 代码到 GitHub

2. GitHub Actions 自动构建 Docker 镜像

3. 镜像推送到 Docker Hub

4. 服务器上自动拉取最新镜像并重启服务

配置过程还是有点复杂的，这里就不展开说了，直接上我用的 workflow 文件：

name: Deploy to Server

on:
push:
branches: [main]

jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
      
- name: Build Docker image
run: docker build -t myapp:latest .
      
- name: Push to Docker Hub
run: |
echo ${{ secrets.DOCKER_PASSWORD }} | docker login -u ${{ secrets.DOCKER_USERNAME }} --password-stdin
docker push myapp:latest
      
- name: Deploy to server
run: |
ssh ${{ secrets.SERVER_USER }}@${{ secrets.SERVER_HOST }} "
docker pull myapp:latest &&
docker stop myapp || true &&
docker rm myapp || true &&
docker run -d --name myapp myapp:latest
"

自从用了这套方案，更代码变成了件极其优雅的事情。git push 之后，CI/CD 自动跑完，服务自动更新，我只需要喝杯咖啡等着就行。而且因为用了 Docker，环境问题也彻底解决了，再也不会出现"在我电脑上能跑"的情况。

安全加固那些不能省的功夫

服务器暴露在公网上，安全性不得不重视。我曾经被人用弱密码爆破过，当时日志里全是失败的 SSH 登录记录，密密麻麻看得我头皮发麻。

后来我做了以下几项安全加固：

# 生成密钥对
ssh-keygen -t ed25519

把公钥复制到服务器
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

修改 SSH 配置
sudo vim /etc/ssh/sshd_config

关键配置项
PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

只开放必要的端口，比如 80、443 和 SSH 端口。其他端口一律拒绝。

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

这个很重要，很多安全漏洞都是通过已知的 CVE 爆出来的。养成每周执行一次 sudo apt update && sudo apt upgrade 的习惯。

这个工具可以自动封禁多次登录失败的 IP，配置简单，效果显著。

经过这些加固之后，服务器安全多了，至少日志里那些密密麻麻的爆破记录消失不见了。

故障排查的一点心得

运维这么久，遇到的故障也算不少了。总结下来，排查问题的套路其实都差不多：

1. 先看日志：百分之八十的问题都能在日志里找到线索。应用日志、系统日志，都要仔细看看。

2. 检查资源：用 top、htop 看看 CPU 和内存，用 df -h 看看磁盘，用 netstat 看看网络连接。

3. 看进程状态：ps aux 或者 systemctl status 能帮你了解进程的运行状态。

4. 逐步排除：把问题可能的原因列出来，一个一个验证。

记得有一次，网站响应特别慢，首页要加载好几秒。我按上面的套路排查：日志没异常，CPU 和内存都很低，磁盘 IO 也不高。最后发现是数据库查询的问题，有一条 SQL 没有建索引，导致全表扫描。加上索引之后，响应时间瞬间从几秒变成了几十毫秒。

总结

这段时间的服务器运维经历，让我学到了很多东西。从最初的的手忙脚乱，到现在的游刃有余，中间付出了不少时间和精力。但看到自己的服务稳定运行，所有的付出都是值得的。

如果你也在学习服务器运维，我的建议是：

- 多动手：光看教程是没用的，一定要自己实际操作

- 做好记录：遇到的问题和解决方法都记下来，下次遇到就不慌了

- 重视监控：宁可过度监控，也不要事后救火

- 保持学习：技术更新很快，要持续学习新知识

好了，今天的分享就到这里。如果大家有什么问题或者更好的经验，欢迎在评论区交流。我们下期再见！