托管看着贵的原因

一句话总结

如果只直接比较价目表，托管服务**总会显得更贵。**因为有一些项目没有列入其中—— 我们的时间，以及我们因此无法完成的工作。

为什么需要它

会议上经常会出现“RDS 比直接安装在 EC2 上贵一倍”的比较。 这个数字没有错，但比较表中通常缺少以下项目。

遗漏的项目	自行运维时需要做什么
补丁规划与应用	每季度投入数天，并在夜间操作
备份配置与验证	初始建设 + 恢复演练
高可用配置	复制设置与故障转移测试
监控	采集指标、编写告警规则
故障响应	凌晨被叫醒；频率虽低但不会为零
版本升级	每几年一次，但每次都是大型工作

把这些项目换算成人员时间后，通常会超过费用差额。团队越小，这一点越明显—— 在一个 3 人团队中，如果有一人把 20% 的时间用于数据库运维，相当于总人工成本的 6～7%，往往已经高于托管服务的费用差额。

选择托管服务的例外情况

但托管服务并非永远是答案

也必须进行反方向的计算。

• 规模非常大时，自行运维的单位成本会低得多。达到数百台规模后，配备专职人员反而更便宜。
• 负载很特殊时，托管服务的默认设置可能不适用。由于缺少调优空间，只能通过增加费用解决，成本反而更高。
• 如果团队已经做得很好，就没有必要强行迁移。改变一个运行良好的系统同样需要成本。

把判断转化为数字的方法

只要写下三行，通常就能得出结论。

1. 월 요금 차액                      = ( 관리형 − 직접 ) 원
2. 직접 운영에 드는 월 인시(person-hours)
3. 인시 × 시간당 비용                 = 숨은 비용 원

2+3 이 1 보다 크면 관리형이 싸다.

再增加一行，结果会更准确——这段时间里无法完成的工作的价值。 如果因为维护数据库而没能开发某项功能，那才是真正的成本。

迁移到托管服务时的检查清单

1. 是否支持所需的版本和扩展
2. 连接数与性能上限能否承受我们的负载
3. 备份保留策略和**恢复时间（RTO）**是否满足要求
4. 能否查看足够详细的日志和指标
5. 能否自行指定维护窗口
6. 退出服务时如何导出数据

很少有团队会在一开始检查第 6 项，但以后往往会为它付出最高代价。

自行运维的实际成本

只比较托管服务与自行运维的价目表，自行运维看起来总是更便宜。 只有把价目表之外的项目一并计算，比较才有意义。

项目	自行运维	托管服务
实例与存储	按价目表	按价目表（通常为 1.5～3 倍）
高可用配置	备用节点费用 + 配置时间	已包含（或只需打开一个开关）
备份与恢复演练	由人员设计并验证	已包含，可点击执行时间点恢复
版本升级	每季度规划、演练并安排窗口	选择窗口即可
值班	人员在凌晨被叫醒	通常无需被叫醒
监控与告警	自行建设和维护	提供基础监控面板

成本最大的往往是最后三项。如果一次数据库版本升级需要两名工程师工作两天， 每年 4 次就是 8 天。按每天 60 万韩元人工成本计算，总计 480 万韩元——足以支付数台实例。

用一行数字作出判断

자체 운영 총비용 = 인프라 + (연간 운영 시간 × 시간당 인건비) + 사고 비용 기댓값
관리형 총비용   = 인프라(비싼 값) + (남는 시간 × 그 시간에 만들 가치)

最后一项才是关键。购买托管服务就是购买时间；如果能用这段时间开发产品， 这笔交易就是划算的。反过来，如果人员充足并且需要特殊调优，自行运维更合适。

把锁定（lock-in）换算为成本

托管服务真正的代价不是费用，而是离开困难。不过，锁定程度也有差别。

类型	锁定程度	示例
完全使用标准协议	低	托管 PostgreSQL、Redis、Kafka
标准协议 + 专有扩展	中	Aurora、ElastiCache 的扩展功能
完全专有 API	高	DynamoDB、Firestore、无服务器函数

第一类实际上几乎没有锁定。把数据转储后迁移到使用相同协议的其他平台即可。 **担心锁定时，应优先采用标准协议的托管服务。**使用专有 API 前，则要先计算 它带来的收益是否超过未来迁移成本。

生产现场中的表现

• 只比较费用后选择自行运维 → 6 个月后负责人离职，系统变得无人了解。
• 迁移到托管服务后触及连接数上限 → 事前检查遗漏。
• 托管服务费用上升，想迁回时却不知道如何导出数据 → 没有检查第 6 项。

下一步内容

最后，我们将讨论哪些内容不应该迁移到云端。