云服务用了三年，我留下这份实用清单

三年前我把博客从虚拟主机搬到云上，当时觉得是件大事。现在回头看，真正折腾的不是迁移本身，而是后来不断冒出来的小需求：图片想加个水印、日志想按天归档、某个接口偶尔要跑个定时任务。每次都觉得“这功能应该很简单”，然后打开控制台发现又是一套新概念。这篇文章不聊架构，就说说我这些年实际在用的几项云服务，以及哪些钱花得值、哪些纯属冲动。

先说对象存储，这是我最常用的服务。博客的图片、播客的音频、还有一堆零碎的备份文件，全扔在里面。目前存了大概 40GB，每月费用不到五块钱。关键操作是设置生命周期规则：我设了“30 天未访问自动转低频存储，180 天直接删除”。这个规则帮我省了不少，因为早期传上去的测试图片根本没人看。有个细节值得注意——不同厂商对“低频存储”的取回费用差别很大，有一次我为了找回一张两年前的截图，取回费用比存一年还贵。所以现在我会在本地留一份最近半年的常用文件，云端只放冷数据。

云函数是我第二个高频使用的服务。最开始只是用来做图床的自动压缩：用户上传图片后触发函数，压成 WebP 再存回去。后来慢慢扩展，现在跑着七八个小任务，比如每天早上抓取几个 RSS 源、把新文章链接推到社交平台、监控某个页面的价格走势。每个月的调用次数大概两万次，费用几乎可以忽略。但云函数有个坑：冷启动。我有个函数是给文章生成摘要的，偶尔用户点开要等三四秒，体验很差。后来改成定时预热，每十分钟 ping 一次，才算解决。如果你也用云函数，建议把对延迟敏感的任务单独拎出来，别和批处理混在一起。

数据库这块我走过弯路。一开始用云厂商的关系型数据库，选了最低配，想着博客那点访问量绰绰有余。结果有次被爬虫扫了一遍，连接数直接打满，页面报错半小时。后来换成轻量级的托管数据库，按月付费，连接数放宽了些，还加了自动备份。现在每周会导出一次全量数据到对象存储，保留最近八周。这个习惯来自一次误操作——手滑删了一张表，虽然最后从备份恢复了，但那两个小时的心跳不想再来一次。备份策略不用复杂，关键是定期验证能不能恢复，我每个月会挑一个备份文件实际还原一次，确认流程走得通。

费用管理是我最近半年才开始认真对待的事。云服务账单有个特点：单项看起来都不贵，加起来就有点肉疼。我现在的做法是给每个资源打标签，比如“博客”“工具”“实验”，然后每月看一次分标签的账单走势。有个月发现“实验”标签下有个测试用的负载均衡器一直开着，每小时几分钱，开了四个月，白白多花了几十块。后来设了预算告警，超过设定金额就发邮件。另外，很多厂商对新用户有免费额度，但到期后不会自动停，会按量计费。我的建议是：试用期结束前三天设个提醒，要么升级要么关掉，别让它默默跑着。

再聊一个容易被忽略的服务：日志和监控。我一开始觉得小博客不需要这些，直到有次网站变慢，查了半天不知道问题出在哪。现在开了基础的日志服务，把访问日志和错误日志分开存，保留 14 天。监控只设了三条告警：网站返回 5xx、响应时间超过三秒、证书还有 15 天到期。这三条基本覆盖了 90% 的突发情况。有个小技巧：日志里记录请求 ID，这样从前端报错到后端日志能串起来，排查快很多。这套组合每月成本大概一杯奶茶钱，但省下的时间远不止。

最后列一下我目前觉得值得开的清单：对象存储加生命周期规则、云函数做轻量自动化、托管数据库带自动备份、分标签的费用告警、基础日志和三条核心告警。不值得折腾的也有：自建 Kubernetes 跑小博客（运维成本太高）、为了省几块钱频繁迁移厂商（迁移一次半天没了）、买那些用不上的高级支持套餐。云服务的核心逻辑是按需付费，但“需”有时候是厂商帮你定义的。每隔几个月回头看看账单和实际用量，把那些为了“万一”而开的服务关掉，比研究新功能更实在。

说到底，云服务是工具，不是收藏品。我现在的原则很简单：能自动化就不手动，能设规则就不靠记忆，能打标签就不混着算。数据在云上，但控制权得留在自己手里。下次再聊具体某个服务的配置细节，这篇就当是个总览。