标签： 服务器运维
-
阿里云 ECS 20GB 系统盘使用率升至 81% 并持续触发告警后，对服务器磁盘占用进行逐项排查。确认 PHP 8.5、Nginx 1.30.4、Redis 8.10.0 当前生产运行路径后，清理升级遗留的构建目录、源码、回滚备份和旧 OneinStack 归档，同时处理 824MB PHP-FPM 异常日志、约 2GB systemd journal，以及已经完成使命的 WordPress 历史文章处理目录。最终系统盘使用率从 81% 降至 42%，可用空间增加至约 11GB，并完成 Nginx、PHP-FPM、Redis 运行状态验证。
-
在多次 OneinStack 生产环境升级和兼容性处理之后，我将已经实际验证并固化到代码中的修改整理为 oneinstack-custom 定制分支，并正式公开到 GitHub。该分支继续保留 OneinStack 原有目录结构和运维方式，重点补充 PHP 8.5.9 构建兼容、GNU libiconv 冲突处理、Imagick 3.8.1、PHP-FPM 状态验证以及 Nginx/OpenSSL 3.5.7 构建等内容。本文同时梳理 OneinStack 原生能力与定制分支的边界，并说明哪些历史运维实践尚未自动化进入仓库。
-
一次 WordPress 生产站点根目录清理实战。从 SSH 终端误粘贴产生的 0 字节命令碎片入手，逐步排查 WordPress 核心空文件、历史临时文件、旧主题与插件、PHP 维护脚本、Nginx/W3 Total Cache 配置、搜索引擎验证文件以及多年遗留的安装包。通过源码校验、旧博客溯源、当前配置核对和隔离机制，最终清理无用文件，同时避免误删仍在使用的标签处理脚本、AdSense、IndexNow 和搜索引擎验证文件，并总结生产环境下“先确认用途、优先隔离、最后删除”的安全清理思路。
-
本文记录在阿里云 ECS 的 OneinStack 环境中，将源码安装的 Redis 7.0.11 升级到 Redis 8.10.0 的完整过程。内容包括升级前环境审计、vm.overcommit_memory 与 Transparent Huge Pages 优化、手动生成 RDB、双重备份与自动回滚、RedisBloom 等附加模块编译失败分析、Redis 核心二进制单独构建、旧版 RDB 兼容检查、临时端口与 PHP Redis 读写测试，以及生产切换后的 WordPress、W3 Total Cache、内存和缓存状态验证。
-
本文记录在 Alibaba Cloud Linux 3 与 OneinStack 环境中，将 Nginx 从 1.24.0 升级到 1.30.4，并将其静态编译使用的 OpenSSL 从 1.1.1t 升级到 3.5.7 的完整过程。操作采用旁路编译、生产配置预检、完整备份、短暂停机切换和自动回滚方案，期间解决了 GitHub 下载失败、Perl 模块缺失、Python 3.6 语法不兼容以及旧版 HTTP/2 配置警告等问题。升级后，中文站、英文站、管理子域、WordPress REST API、PHP-FPM 和源站 HTTP/2 均通过验证。
-
在一次 WordPress 502 故障排查结束后，我继续完善阿里云 ECS 的主机监控与报警体系。排查发现原有云监控 Agent 2.1.56 已停止运行，导致 CPU、内存、磁盘等操作系统级指标长期没有数据。随后通过传统云监控「主机监控」将 Agent 升级至 4.0.0，恢复 CPU、内存、Load、磁盘、网络和公网带宽等监控，并分别为 CPU、内存、磁盘及公网流出带宽设置 Info、Warn、Critical 三级报警。结合恢复后的实际监控数据，现阶段 1 核 2G ECS 与 2 Mbps 公网带宽仍有明显余量，因此暂不升级服务器，而是先通过持续监控积累长期运行基线，让服务器运维从“故障后排查”转向“异常前预警”。