一个人的全栈运维：16 项优化把网站从"能用"变成"抗造"
单兵作战，没有 QA、没有 SRE、没有 on-call。这一轮 16 项优化，每一项都是在减少未来半夜被叫起来的概率。
这篇是什么：同一轮 16 项优化的叙事复盘，讲的是决策顺序和一个人扛运维的心态。想要纯表格速查版看 全站优化报告；单项深挖看 Nginx 210→62 行、Tailwind CDN 瘦身、SQLite + Flask g。
一、起点：一个"能用"的网站
venxine.vip 是一个个人金融工具平台：基金跟踪、新闻聚合、Token 用量监控、Cron 调度。Flask + Jinja2 + SQLite + Nginx，一台 2C/4G 的云服务器。
2026 年 7 月 2 日那天，我问了自己一个问题："如果我现在睡着，这个网站能在不碰它的前提下活多久？"
答案不太乐观。于是开始了系统性的逐层体检。
二、决策框架：安全 > 可靠性 > 性能 > 可维护性
这四个维度的优先级不是拍脑袋定的，是按照出问题的代价排的：
| 优先级 | 维度 | 最坏后果 | 恢复难度 |
|---|---|---|---|
| 1 | 安全 | 被脱库、被挂马、被中间人嗅探 | 需要重建信任，不可逆 |
| 2 | 可靠性 | 进程崩溃没人重启，早上起来网站挂了整夜 | 手动重启，但已损失时间 |
| 3 | 性能 | 用户打开慢、带宽浪费 | 体验差，但网站还能用 |
| 4 | 可维护性 | 改一个路由翻几千行、加功能要复制粘贴 | 慢但不致命 |
这个优先级决定了执行顺序也是安全先做。
三、安全的 4 步闭环
3.1 TLS：不是"开 HTTPS 就行了"
HTTPS 只是传输加密，协议版本同样重要。TLSv1.0（1999）和 TLSv1.1（2006）已经被各大浏览器标记为不安全，PCI DSS 也要求禁用。
# 优化前
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
# 优化后
ssl_protocols TLSv1.2 TLSv1.3;
验证方法很简单，用 curl 逐个协议测试：
curl -sI --tls-max 1.1 https://venxine.vip/ # 应拒绝
curl -sI --tls-max 1.2 https://venxine.vip/ # 应 200
3.2 安全头：四件套的含义
很多人加安全头只是复制粘贴，不理解含义。这四个头的选择逻辑：
| 头 | 作用 | 为什么选这个值 |
|---|---|---|
Strict-Transport-Security: max-age=63072000 |
强制浏览器 2 年内只能用 HTTPS | 2 年足够覆盖所有回访 |
X-Frame-Options: SAMEORIGIN |
禁止其他网站用 iframe 嵌入 | 防点击劫持，但允许本站内嵌 |
X-Content-Type-Options: nosniff |
禁止浏览器猜 MIME 类型 | 防 MIME 混淆攻击 |
Referrer-Policy: strict-origin-when-cross-origin |
跨域只传域名不传路径 | 平衡隐私和兼容性 |
3.3 硬编码密码：一个 grep password 就能发现的漏洞
# 优化前：任何有源码权限的人都能看到
DEMO_PASSWORD = "liu1990423!"
app.secret_key = os.environ.get('FLASK_SECRET_KEY', 'demo-venxine-2026-secret')
# 优化后：零敏感信息在源码
DEMO_PASSWORD = os.environ['DEMO_PASSWORD']
app.secret_key = os.environ['FLASK_SECRET_KEY'] # openssl rand -hex 24
核心教训：不要给默认值，不要 fallback，直接 fail-fast。 环境变量缺失就应该启动失败，而不是静默使用弱密码。
四、可靠性：一个人运维的核心命题
4.1 从 python3 app.py 到 systemd
开发时 python3 app.py 很方便，崩溃了终端会显示。但生产环境没有终端盯着。
# 优化前：进程挂了就挂了
python3 app.py &
# 优化后：systemd 托管
# /etc/systemd/system/venxine-gunicorn.service
[Service]
User=agentuser
ExecStart=/usr/local/bin/gunicorn -c gunicorn_config.py app:app
Restart=always # 关键：崩溃自动重启
RestartSec=5
[Install]
WantedBy=multi-user.target # 开机自启
4.2 gthread 踩坑：不是所有 worker 类型都适合你的机器
我一开始配置了 worker_class = "gthread" + 4 threads，觉得并发能力强。但 3.6GB 内存在 4 个 worker × 4 threads 的组合下直接 OOM，子进程反复 exit。
# 最终方案：sync workers，简单可靠
bind = "127.0.0.1:5000"
workers = 2 # 2C 机器用 2 个 worker 刚好
worker_class = "sync" # 不花哨，但从不崩溃
低内存机器（<4GB）优先 sync，别追 gthread/gevent。
五、性能：让用户感觉"快"
5.1 缓存粒度决策
| 资源类型 | 缓存时间 | 策略 | 理由 |
|---|---|---|---|
| favicon/PNG/CSS | 30 天 | immutable | 内容 hash 化了，永不变 |
| 首页 index.html | 1 小时 | public | 首页偶尔改，1 小时可以接受 |
| 动态页面 (/system/ 等) | 不缓存 | no-store | 数据实时变化 |
5.2 Gzip：被大多数人忽略的"免费加速"
很多人只开了 gzip on，却不知道 vary、proxied、types 才是关键：
gzip on;
gzip_vary on; # 告诉 CDN/代理：不同 Accept-Encoding 返回不同内容
gzip_proxied any; # 经由代理也要压缩
gzip_comp_level 6; # 5-6 是压缩率和 CPU 的最佳平衡
gzip_types text/plain text/css application/json
application/javascript image/svg+xml;
效果：index.html 从 28,625B → 5,491B（-80.8%）。不开的话，每个月浪费的带宽足够买几杯咖啡。
5.3 /system/ 页面的坑：每次请求 fork 10+ 子进程
这是最容易忽视的性能杀手。/system/ 页面展示主机信息，每次请求执行：
subprocess.run(['hermes', '--version']) # 500ms
subprocess.run(['git', 'log']) # 200ms
subprocess.run(['uv', '--version']) # 100ms
subprocess.run(['lsb_release', '-ds']) # 50ms
subprocess.run(['lscpu']) # 50ms
subprocess.run(['free', '-h']) # 20ms
subprocess.run(['df', '-h']) # 20ms
subprocess.run(['uptime', '-p']) # 10ms
subprocess.run(['nginx', '-v']) # 50ms
subprocess.run(['node', '--version']) # 80ms
10 条 × 每个 50-500ms = 每次请求可能等 1-3 秒。 如果有 5 个并发请求同时进来，就是 5 组进程风暴。
解决方案：启动时计算一次，存内存 Hash，5 分钟过期。
_system_cache = {"ts": 0, "data": None}
def _refresh_system_cache():
if _system_cache["data"] and (time.time() - _system_cache["ts"]) < 300:
return _system_cache["data"] # 命中缓存，零 fork
# 冷启动才跑 subprocess...
六、可维护性：让你少加班
6.1 Nginx 210 行 → 62 行
这不是美学问题，是维护成本问题。之前 26 个 location ^~ /xxx/ 块每个都要复制粘贴 6 行 proxy 配置，新增路由必须改 Nginx。有两次忘了，页面 404 了半天才发现。
# 26 个独立块 → 1 个正则
location ~ ^/(api|fundanalysis|archive[1-5]|demo(?:[1-8])?|
chinastock|funddata|fundreturns|fundtracker|
cryptonews|cron|skills|ainews|wallstreet|
token|system|dcacalc)/ {
proxy_pass http://127.0.0.1:5000;
# ... 一组通用的 proxy_set_header
}
6.2 4000 行单文件 → 模块化
app.py 从 3,983 行减到 3,367 行，提取了 595 行纯工具函数到 utils.py。
拆分原则：先抽无路由依赖的纯函数，再抽有路由依赖的模块。每步抽完立即验证 from app import app 能通过。
七、如果你也要做类似的优化
检查清单（按执行顺序）：
□ curl -sI https://yoursite.com | grep -i "strict\|frame\|content\|referrer"
→ 如果为空，加四件套安全头
□ curl -sI --tls-max 1.1 https://yoursite.com/
→ 如果返回 200，赶紧关 TLSv1.0/1.1
□ grep -r "password\|secret\|key" app.py | grep -v "os.environ"
→ 如果输出包含明文，移到 .env
□ ps aux | grep "python.*app.py"
→ 如果直接裸跑，改为 gunicorn + systemd
□ curl -sI https://yoursite.com/ | grep "Cache-Control"
→ 如果为空，加缓存头
□ curl -sH "Accept-Encoding: gzip" https://yoursite.com/ | wc -c
→ 和未压缩对比，差 <50% 说明 gzip 没开全
□ grep -c "sqlite3.connect" app.py
→ 如果 >10，加 Flask g 复用
□ grep -c "subprocess.run" app.py
→ 如果在请求函数内，加缓存
□ grep "src=\"https://cdn" index.html
→ 如果有，本地构建
八、数字总结
| 指标 | 前 | 后 | 变化 |
|---|---|---|---|
| Nginx 行数 | 210 | 62 | -70% |
| app.py 行数 | 3,983 | 3,367 | -15.5% |
| 安全头覆盖 | 0 | 4 | 全覆盖 |
| 首屏加载 | ~328KB | ~46KB | -86% |
| Gzip 首页 | 28,625B | 5,491B | -80.8% |
| favicon | 136KB | 5.9KB | -95.7% |
| DB 连接/请求 | 5-12 | 1 | Flask g 复用 |
| 进程守护 | 无 | systemd | 崩溃自动重启 |
一个人做运维，拼的不是技术有多深，是能不能让自己少半夜爬起来。这 16 项没有一项是炫技，全是为了让网站在我睡着的时候也能自己扛住。