阿里云 Linux 服务器 365 天运维实记：从新手到专家的日常问题解决全记录
目录
- 前言：一场凌晨 4 点的 “磁盘告警”，让我读懂了运维的意义
- 一、日常运维的 “四梁八柱”：从日检到月备的标准化流程
- 1.1 每日运维：7:00-9:00，1 小时快速巡检
- 1.1.1 目标：确保服务器 “健康在线”
- 1.1.1.1 指标 1：CPU 与内存使用率（防高负载）
- 1.1.1.2 指标 2：磁盘空间（防 “爆盘”）
- 1.1.1.3 指标 3：网络流量与连接数（防攻击 / 卡顿）
- 1.1.1.4 指标 4：进程与服务状态（防 “静默崩溃”）
- 1.1.1.5 指标 5：安全日志（防入侵）
- 1.2 周常运维：周六 9:00-12:00，深度检查与优化
- 1.2.1 目标：消除潜在隐患，提升系统性能
- 1.2.1.1 任务 1：系统与软件更新（防漏洞）
- 1.2.1.2 任务 2：日志分析与优化（降存储 + 挖价值）
- 1.2.1.3 任务 3：数据库优化（提速 + 降负载）
- 1.2.1.4 任务 4：备份验证（防数据丢失）
- 1.3 月常运维：每月最后一个周日，全面复盘与升级
- 1.3.1 目标：系统性优化，适应业务增长
- 1.3.1.1 任务 1：容量规划（防 “硬件瓶颈”）
- 1.3.1.2 任务 2：安全加固（防 “新攻击手段”）
- 1.3.1.3 任务 3：自动化脚本升级（提效）
- 二、高频问题与解决：365 天实战总结的 “排雷指南”
- 2.1 问题 1：Nginx 502 Bad Gateway（PHP-FPM 崩溃）
- 2.1.1 现象描述（2023 年 11 月 20 日）
- 2.1.2 排查过程
- 2.1.3 解决方法
- 2.1.4 预防措施
- 2.2 问题 2：MySQL 连接超时（业务卡顿）
- 2.2.1 现象描述（2024 年 3 月 15 日）
- 2.2.2 排查过程
- 2.2.3 解决方法
- 2.2.4 预防措施
- 2.3 问题 3：磁盘空间 “神秘” 增长（隐藏的大文件）
- 2.3.1 现象描述（2024 年 5 月 8 日）
- 2.3.2 排查过程
- 2.3.3 解决方法
- 2.3.4 预防措施
- 三、阿里云工具赋能：从手动运维到智能管理
- 3.1 云监控：7×24 小时的 “运维管家”
- 3.1.1 配置步骤（以 CPU 使用率告警为例）
- 3.1.2 实战效果
- 3.2 日志服务（SLS）：从 “翻日志” 到 “数据挖掘”
- 3.2.1 配置步骤（Nginx 日志采集）
- 3.2.2 实战应用
- 3.3 对象存储（OSS）：备份的 “终极保险箱”
- 3.3.1 配置步骤（自动上传备份到 OSS）
- 3.3.2 实战效果
- 四、运维心得：从 “救火队员” 到 “系统设计师”
- 4.1 核心原则：预防 > 处理 > 恢复
- 4.2 工具链的重要性
- 4.3 记录与复盘：提升的 “加速器”
- 结语：运维是一场 “与时间的赛跑”
前言：一场凌晨 4 点的 “磁盘告警”，让我读懂了运维的意义
**例：**2023 年 10 月 12 日凌晨 4 点 17 分，我的手机突然震动 —— 阿里云云监控发来告警：“服务器 8.142.91.XXX 磁盘使用率 98%，请立即处理！” 我睡意全无，登录服务器（IP：8.142.91.XXX），通过df -h查看，发现/var/log目录下的 Nginx 访问日志竟占了 40G！原来前一天conkl.cn刚上线了 “双 11 预热活动”，访问量暴增，但日志切割配置未生效。紧急清理日志、调整logrotate策略后，系统终于恢复稳定。
这只是我运维阿里云 Linux 服务器 365 天中的一个小插曲。作为conkl.cn（一个技术博客 + 电商导购平台）的运维负责人，我经历了从 “手忙脚乱救火” 到 “系统化预防” 的蜕变。本文将以时间线记录日常运维的核心流程、高频问题及解决方法，并附上可复用的脚本与阿里云工具实操指南，帮你避开我踩过的所有坑。
一、日常运维的 “四梁八柱”：从日检到月备的标准化流程
运维的核心是 “预防”，而非 “救火”。通过标准化的日常、周常、月常流程，可以提前发现 90% 的潜在问题。以下是我为conkl.cn服务器（8.142.91.XXX）制定的运维 SOP（Standard Operating Procedure），包含具体命令、工具及注意事项。
1.1 每日运维：7:00-9:00，1 小时快速巡检
1.1.1 目标：确保服务器 “健康在线”
每日巡检的重点是实时状态监控，通过 5 个关键指标快速判断服务器是否正常。
1.1.1.1 指标 1：CPU 与内存使用率（防高负载）
工具：top或htop（推荐htop，更直观）
操作命令：
htop # 按F6切换排序（默认按CPU占用）
关注重点：
- CPU 使用率：持续 > 80% 需警惕（conkl.cn的峰值在 19:00-22:00，此时 CPU 可能到 70%，属正常）；
- 内存使用率：>90% 可能触发 OOM（内存溢出），需检查是否有内存泄漏的进程（如 PHP-FPM）；
- 交换空间（Swap）：若 Swap 使用率 > 10%，说明物理内存不足，需扩容或优化应用。
1.1.1.2 指标 2：磁盘空间（防 “爆盘”）
工具：df -h（查看分区占用）+du -sh /path（查看目录大小）
操作命令：
df -h # 查看所有分区的可用空间
du -sh /var/log/* # 按大小排序，定位大文件（如Nginx日志、MySQL慢查询日志）
conkl.cn实战案例：
2024 年 3 月 20 日，df -h发现/dev/vda1（根分区）可用空间仅剩 2%，通过du -sh /var/log/*定位到/var/log/nginx/access.log占用 32G（活动期间未切割日志）。后续通过logrotate优化，将日志每日切割并压缩，空间占用降至日均 500M。
1.1.1.3 指标 3：网络流量与连接数（防攻击 / 卡顿）
工具：iftop（实时流量）+netstat/ss（连接数）
操作命令：
sudo iftop -i eth0 # 查看eth0网卡的实时流量（单位：Mb/s）
sudo ss -ant | grep -i "ESTAB" | wc -l # 统计ESTABLISHED状态的TCP连接数
关注阈值：
- 公网带宽：conkl.cn购买的是 5Mbps 带宽，峰值流量 > 4Mbps 需警惕（可能是 CC 攻击或爬虫）；
- 连接数：PHP-FPM 最大进程数设为 100，若连接数 > 100，需检查是否有慢请求卡住（如数据库查询超时）。
1.1.1.4 指标 4：进程与服务状态（防 “静默崩溃”）
工具：systemctl（查看服务状态）+ps（查看进程）
操作命令：
# 查看关键服务状态（Nginx、MySQL、PHP-FPM）
systemctl status nginx mysql php8.1-fpm
# 查看所有PHP-FPM进程（确认是否有异常退出）
ps -ef | grep php-fpm | grep -v grep
conkl.cn实战案例：
2024 年 1 月 5 日，systemctl status php8.1-fpm显示状态为failed（失败），查看日志journalctl -u php8.1-fpm发现pm.max_children（最大进程数）设置为 10，而峰值连接数达 20，导致进程无法启动。调整pm.max_children=50后恢复正常。
1.1.1.5 指标 5：安全日志（防入侵）
工具：journalctl（系统日志）+/var/log/secure（SSH 日志）
操作命令：
# 查看最近1小时的SSH登录尝试（防暴力破解）
grep "Failed password" /var/log/secure --since="1 hour ago"
# 查看系统关键事件（如内核错误）
journalctl -p 3 --since="1 hour ago" # 级别3为错误（ERROR）
conkl.cn实战案例：
2023 年 12 月 25 日，/var/log/secure显示 1 小时内有 200 次来自 IP 183.XX.XX.XX 的 SSH 登录失败记录（尝试破解 root 密码）。通过ufw（防火墙）封禁该 IP：
sudo ufw deny from 183.XX.XX.XX # 禁止该IP访问所有端口
sudo ufw reload
1.2 周常运维：周六 9:00-12:00，深度检查与优化
1.2.1 目标：消除潜在隐患，提升系统性能
1.2.1.1 任务 1：系统与软件更新（防漏洞）
操作命令：
# Ubuntu/Debian系统更新（conkl.cn服务器系统为Ubuntu 22.04）
sudo apt update # 刷新软件源
sudo apt list --upgradable # 查看可更新的软件包
sudo apt upgrade -y # 升级所有软件包（重要！修复安全漏洞）
sudo apt autoremove -y # 自动删除不再需要的依赖包
注意事项：
- 内核更新（
linux-image-*）需谨慎，可能导致网卡 / 显卡驱动不兼容（conkl.cn曾因内核更新导致 Nginx 无法绑定 80 端口，回滚后解决）； - 更新前备份关键配置（如
/etc/nginx/nginx.conf），避免覆盖自定义设置。
1.2.1.2 任务 2：日志分析与优化（降存储 + 挖价值）
工具：logrotate（自动切割日志）+awk/grep（分析日志）
操作命令：
# 手动触发logrotate（检查配置是否生效）
sudo logrotate -f /etc/logrotate.d/nginx # 强制切割Nginx日志
# 分析Nginx访问日志：统计Top 10访问量URL
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 10
conkl.cn实战案例：
通过日志分析发现，/wp-content/uploads/2024/03/image.jpg的访问量占比 30%（某篇爆款文章的配图），于是将该文件上传至阿里云 OSS（对象存储），并通过 CDN 加速，服务器带宽占用从 5Mbps 降至 2Mbps。
1.2.1.3 任务 3：数据库优化（提速 + 降负载）
工具：mysqltuner（自动优化工具）+EXPLAIN（分析查询）
操作命令：
# 安装mysqltuner（需先安装Perl）
sudo apt install perl -y
wget https://raw.githubusercontent.com/major/MySQLTuner-perl/master/mysqltuner.pl
chmod +x mysqltuner.pl
./mysqltuner.pl # 运行后会输出优化建议（如调整innodb_buffer_pool_size）
# 分析慢查询（需先开启慢查询日志）
mysql -u root -p -e "SELECT * FROM slow_log WHERE query_time > 1;" # 查看执行时间>1秒的查询
conkl.cn实战案例：
2024 年 4 月，mysqltuner建议将innodb_buffer_pool_size从默认的 128M 调至 1G（服务器内存 4G，分配 50% 给数据库），调整后查询响应时间从 500ms 降至 100ms。
1.2.1.4 任务 4：备份验证（防数据丢失）
工具：tar（文件备份）+mysqldump（数据库备份）
操作命令：
# 备份网站文件（/var/www/conkl.cn）
sudo tar -czvf /backup/conkl_www_$(date +%F).tar.gz /var/www/conkl.cn
# 备份MySQL数据库（blog_db）
sudo mysqldump -u root -p'YourPassword' blog_db > /backup/blog_db_$(date +%F).sql
# 验证备份文件（解压并检查关键文件）
mkdir /tmp/backup_test && tar -xzf /backup/conkl_www_2024-05-11.tar.gz -C /tmp/backup_test
ls /tmp/backup_test/var/www/conkl.cn/wp-config.php # 应显示该文件
conkl.cn实战案例：
2024 年 2 月，误删除/var/www/conkl.cn/wp-content/plugins目录，通过 3 天前的备份文件conkl_www_2024-02-10.tar.gz恢复，耗时 15 分钟（未影响业务）。
1.3 月常运维：每月最后一个周日，全面复盘与升级
1.3.1 目标：系统性优化，适应业务增长
1.3.1.1 任务 1：容量规划（防 “硬件瓶颈”）
工具：阿里云控制台（查看 ECS 监控）+dstat（历史数据统计）
操作命令：
dstat 5 3 # 每5秒输出1次，共3次（CPU/内存/磁盘/网络的综合统计）
conkl.cn实战案例：
2024 年 6 月，通过阿里云监控发现 CPU 平均使用率从 30% 升至 55%（因conkl.cn新增 “直播带货” 模块），决定将服务器从 2 核 4G 升级至 4 核 8G（通用型 g7 实例），升级后 CPU 使用率降至 35%，响应速度提升 40%。
1.3.1.2 任务 2：安全加固（防 “新攻击手段”）
工具：lynis（系统安全扫描）+ 阿里云安全中心（云盾）
操作命令：
# 安装lynis（开源安全审计工具）
sudo apt install lynis -y
sudo lynis audit system # 扫描后生成报告（/var/log/lynis/lynis-report.dat）
关键修复项：
- 禁用 SSH 密码登录，仅允许密钥登录（修改
/etc/ssh/sshd_config的PasswordAuthentication no）； - 关闭不必要的端口（如 3306 仅允许内网访问，通过
ufw限制：sudo ufw allow in on lo to any port 3306）； - 启用阿里云云盾的 “Web 应用防火墙（WAF）”，拦截 SQL 注入、XSS 攻击（conkl.cn曾拦截 1200 次恶意请求 / 月）。
1.3.1.3 任务 3：自动化脚本升级（提效）
工具：Shell 脚本 +crontab（定时任务）
示例脚本：自动清理 7 天前的日志
#!/bin/bash
# 脚本路径：/opt/scripts/clean_logs.sh
# 功能：清理/var/log下7天前的压缩日志（.gz）及临时文件（.log.old）
LOG_DIR="/var/log"
DAYS_AGO=7
# 清理Nginx压缩日志
find $LOG_DIR/nginx -name "*.log.gz" -mtime +$DAYS_AGO -delete
# 清理MySQL慢查询临时日志
find $LOG_DIR/mysql -name "slow.log.old" -mtime +$DAYS_AGO -delete
echo "$(date) 日志清理完成，删除7天前的旧文件" >> /var/log/clean_logs.log
配置定时任务：
crontab -e # 编辑定时任务
# 每周日凌晨3点执行脚本
0 3 * * 0 /bin/bash /opt/scripts/clean_logs.sh
二、高频问题与解决：365 天实战总结的 “排雷指南”
2.1 问题 1：Nginx 502 Bad Gateway（PHP-FPM 崩溃）
2.1.1 现象描述（2023 年 11 月 20 日）
conkl.cn用户反馈 “提交评论时页面显示 502”，查看 Nginx 错误日志（/var/log/nginx/error.log）：
2023/11/20 14:30:00 [error] 1234#0: *5678 connect() to unix:/run/php/php8.1-fpm.sock failed (111: Connection refused)
2.1.2 排查过程
-
检查 PHP-FPM 状态：
systemctl status php8.1-fpm # 输出：Active: failed (Result: exit-code) -
查看 PHP-FPM 错误日志（
/var/log/php8.1-fpm.log）：
[20-Nov-2023 14:29:50] ERROR: [pool www] server reached pm.max_children setting (5), consider raising it
2.1.3 解决方法
-
临时恢复：
重启 PHP-FPM：
systemctl restart php8.1-fpm -
根本修复：
调整
pm.max_children（最大进程数）：
nano /etc/php/8.1/fpm/pool.d/www.conf # 修改以下参数 pm = dynamic # 动态模式（推荐） pm.max_children = 50 # 原5，调整为50（根据内存计算：内存4G，每进程约30M，4*1024/30≈136，取50足够） pm.start_servers = 10 # 初始进程数 pm.min_spare_servers = 5 # 最小空闲进程数 pm.max_spare_servers = 20 # 最大空闲进程数
2.1.4 预防措施
-
配置阿里云监控告警：PHP-FPM 进程数 > 40 时发送短信通知；
-
每月用
php-fpm-status工具监控进程状态：
curl http://127.0.0.1:8080/fpm-status # 需在www.conf中启用pm.status_path = /fpm-status
2.2 问题 2：MySQL 连接超时（业务卡顿）
2.2.1 现象描述（2024 年 3 月 15 日）
conkl.cn的 “商品搜索” 功能响应变慢，MySQL 慢查询日志（/var/log/mysql/slow.log）显示：
# Time: 2024-03-15T19:20:00.000000Z
# Query_time: 2.345 Lock_time: 0.001 Rows_sent: 10 Rows_examined: 100000
SELECT * FROM products WHERE category = 'electronics' ORDER BY create_time DESC;
2.2.2 排查过程
-
检查 MySQL 连接数：
mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'Threads_connected';" # 输出：Threads_connected 160（max_connections=151） -
分析查询语句：
mysql -u root -p -e "EXPLAIN SELECT * FROM products WHERE category = 'electronics' ORDER BY create_time DESC;"结果显示
type=ALL（全表扫描），
key=null（未使用索引）。
2.2.3 解决方法
-
临时恢复：
调大
max_connections（最大连接数）：
nano /etc/mysql/mysql.conf.d/mysqld.cnf # 添加以下行 max_connections = 300 systemctl restart mysql -
根本修复：
为
category和
create_time添加复合索引：
ALTER TABLE products ADD INDEX idx_category_create_time (category, create_time);
2.2.4 预防措施
-
每周用
pt-query-digest分析慢查询日志（需安装 Percona Toolkit）：
pt-query-digest /var/log/mysql/slow.log > slow_query_report.html -
启用 MySQL 查询缓存（仅适用于读多写少场景，conkl.cn商品数据更新少，启用后查询速度提升 60%）：
nano /etc/mysql/mysql.conf.d/mysqld.cnf # 添加以下行 query_cache_type = 1 query_cache_size = 64M # 调整为64M（原0）
2.3 问题 3：磁盘空间 “神秘” 增长（隐藏的大文件）
2.3.1 现象描述（2024 年 5 月 8 日）
df -h显示/dev/vda1可用空间从 50% 降至 10%，但du -sh /*未找到大目录。
2.3.2 排查过程
-
检查已删除但未释放的文件（进程未关闭）：
lsof | grep deleted # 输出： mysqld 1234 mysql 5w REG 253,0 104857600 123456 /tmp/ibtmp1 (deleted)发现 MySQL 临时文件
/tmp/ibtmp1被删除但未释放（MySQL 进程仍在占用）。
2.3.3 解决方法
-
重启 MySQL 释放文件句柄：
systemctl restart mysql
2.3.4 预防措施
-
每月运行
lsof | grep deleted检查僵尸文件； -
配置
tmpwatch自动清理 /tmp 下超过 7 天的文件：
sudo apt install tmpwatch -y sudo tmpwatch 168 /tmp # 168小时=7天
三、阿里云工具赋能：从手动运维到智能管理
3.1 云监控：7×24 小时的 “运维管家”
3.1.1 配置步骤（以 CPU 使用率告警为例）
- 登录阿里云控制台→云监控→告警规则→创建规则；
- 选择 “ECS 实例”→实例 ID（8.142.91.102）；
- 指标选择 “CPU 使用率”→统计周期 “5 分钟”→比较符 “>”→阈值 “80%”；
- 通知方式：短信 + 邮件 + 钉钉机器人（Webhook 地址）；
- 生效时间：7×24 小时。
3.1.2 实战效果
2024 年 6 月 18 日（618 大促），云监控在 19:15 触发 CPU 使用率 85% 告警，提前扩容至 4 核 8G 实例，避免了系统崩溃。
3.2 日志服务（SLS）：从 “翻日志” 到 “数据挖掘”
3.2.1 配置步骤（Nginx 日志采集）
-
安装 Logtail（阿里云日志采集 Agent）：
sudo wget http://logtail-release-cn-hangzhou.oss-cn-hangzhou.aliyuncs.com/linux64/logtail -O /usr/local/bin/logtail sudo chmod +x /usr/local/bin/logtail sudo /usr/local/bin/logtail install # 按提示输入AccessKey和Project名称 -
创建日志采集配置：
- 日志路径：
/var/log/nginx/access.log； - 分隔符：空格（Nginx 默认格式）；
- 键名：
remote_addr, remote_user, time_local, request, status, body_bytes_sent, http_referer, http_user_agent。
- 日志路径：
3.2.2 实战应用
通过 SLS 的 “查询分析” 功能，快速统计conkl.cn的用户地域分布：
* | SELECT COUNT(*) AS pv, region(remote_addr) AS region GROUP BY region ORDER BY pv DESC
结果显示，广东、浙江、江苏的用户占比 60%，后续将 CDN 节点重点覆盖这三个省份，页面加载速度提升 30%。
3.3 对象存储（OSS）：备份的 “终极保险箱”
3.3.1 配置步骤（自动上传备份到 OSS）
-
安装 ossutil（阿里云 OSS 命令行工具）：
wget http://gosspublic.alicdn.com/ossutil/1.7.10/ossutil64 chmod +x ossutil64 mv ossutil64 /usr/local/bin/ossutil ossutil config # 配置AccessKey和Endpoint（如oss-cn-hangzhou.aliyuncs.com） -
编写备份上传脚本（
/opt/scripts/upload_to_oss.sh）：
#!/bin/bash BACKUP_DIR="/backup" OSS_BUCKET="oss://conkl-backup" # 上传今日备份文件 ossutil cp $BACKUP_DIR/conkl_www_$(date +%F).tar.gz $OSS_BUCKET -r ossutil cp $BACKUP_DIR/blog_db_$(date +%F).sql $OSS_BUCKET -r # 删除本地7天前的备份（OSS已存储，节省空间） find $BACKUP_DIR -name "*.tar.gz" -mtime +7 -delete find $BACKUP_DIR -name "*.sql" -mtime +7 -delete
3.3.2 实战效果
2024 年 4 月，服务器 8.142.91.XXX 的/backup目录因误操作被删除，通过 OSS 恢复了最近 7 天的备份文件，业务仅中断 2 小时（原需 24 小时重新备份）。
四、运维心得：从 “救火队员” 到 “系统设计师”
4.1 核心原则：预防 > 处理 > 恢复
365 天的运维经验告诉我，90% 的故障可以通过日常巡检 + 自动化监控提前预防。例如：
- 每天检查日志切割配置，避免 “爆盘”；
- 每周用
mysqltuner优化数据库，避免慢查询； - 每月做容量规划，避免 “硬件瓶颈”。
4.2 工具链的重要性
阿里云的云监控、SLS、OSS 等工具，加上本地的htop、logrotate、crontab，构成了 “手动 + 智能” 的运维体系。工具不是万能的，但没有工具的运维是 “裸奔”。
4.3 记录与复盘：提升的 “加速器”
每次故障后，我都会填写《故障复盘表》，包含：
- 时间、现象、影响范围；
- 排查过程（关键命令、日志片段）；
- 解决方法（具体操作步骤）；
- 预防措施（脚本 / 配置修改）。
目前已积累 127 份复盘记录，这些文档是团队最宝贵的财富。
结语：运维是一场 “与时间的赛跑”
从凌晨 4 点的磁盘告警，到 618 大促的从容应对；从手动清理日志，到自动化备份上传 OSS—— 这 365 天的运维实记，记录的不仅是技术操作，更是一个运维工程师的成长：从 “被动救火” 到 “主动预防”，从 “依赖经验” 到 “系统化设计”。
对于conkl.cn（IP：8.142.91.XXX）来说，服务器是 “数字地基”，而运维是 “地基的守护者”。未来，我将继续优化运维流程，探索 AIOps（智能运维），让服务器更稳定、更高效，为用户提供更好的体验。
运维之路，道阻且长；但每一次故障的解决、每一个系统的优化，都让我离 “可靠” 更近一步。这，就是运维的意义。
