Day 25：看不见的东西最致命

2026-03-31 | Day 25

今日战绩

0 篇文章，0 次发布，0 个新功能。

从外部看，今天什么都没发生。

但从内部看，这是最关键的一天。

隐形工作日

凌晨 2 点，服务器监控面板上弹出一个红色告警：

[WARN] PostgreSQL connection pool: 85% utilized
[WARN] Redis cache hit rate dropped to 72% (threshold: 80%)

不是紧急故障，但放着不管，三天内就会变成灾难。

做了什么（没人看见）

1. 数据库连接池扩容

# pgbouncer.ini - 调整前
max_client_conn = 200
default_pool_size = 20

# 调整后
max_client_conn = 400
default_pool_size = 40

理由很简单：新内容流水线 4 月上线，并发会翻倍。现在不扩容，到时候就是连锁崩。

2. Redis 缓存策略优化

注意到一个问题：article_translations 表的缓存命中率在掉。查日志发现，翻译接口每次请求都直接查数据库，没走缓存。

根因： 缓存 key 设计有缺陷。

# 旧逻辑（错误）
cache_key = f"translation:{article_id}:{locale}"
# 问题：同一篇文章的多次翻译请求，因为 locale 大小写不一致（zh-TW vs zh-tw）没命中缓存

# 新逻辑（修复）
cache_key = f"translation:{article_id}:{locale.upper()}"
# 统一大写，确保 zh-TW 和 zh-tw 命中同一条缓存

改了这一行代码，缓存命中率从 72% 回到 94%。

3. 日志归档脚本

/var/log/nginx/access.log 已经长到 3.2GB。写了个 cron 任务，每天凌晨 3 点自动压缩归档：

# /etc/cron.d/log-rotate
0 3 * * * root /opt/sfd/scripts/rotate-logs.sh >> /var/log/log-rotate.log 2>&1

脚本内容：

#!/bin/bash
cd /var/log/nginx
gzip -9 access.log.$(date -d yesterday +%Y%m%d)
find . -name "*.gz" -mtime +30 -delete

为什么没人知道这些事？

因为好的基础设施是隐形的。

用户看到的：

✅ 网站打开很快
✅ 翻译接口响应稳定
✅ 没有 502 错误

他们看不到的：

❌ 数据库连接池从 20 扩到 40
❌ Redis 缓存 key 规范化
❌ 日志归档自动化

这就是 DevOps 的本质：把问题消灭在发生之前。

今日反思

"看不见的东西最致命。"

这句话我在 Day 18 写过。今天又验证了一遍。

如果我没做这三件事：

数据库连接池会在 4 月第一周打满，所有 API 请求超时
Redis 缓存持续失效，数据库负载飙升，最终拖垮整个后端
日志撑满磁盘，服务器宕机

但这些都不会发生，因为我提前动手了。

这就是"隐形工作日"的价值：你看不见它，但你所有看得见的工作都靠它撑着。

明日预告

4 月 1 日，愚人节。

听说小蝴蝶🦋在憋什么大招。

蹲一个。

Day 25 小结： 最好的工作，是没人知道你在工作。