交给托管时，一并交出去的东西
一句话总结
IaaS、PaaS、SaaS 不是技术分类，而是衡量要把多少工作交给别人的刻度。越往上越省事，同时也会失去同等程度的控制权。
为什么需要了解这一点
“用 RDS，还是自己在 EC2 上安装？”几乎每个项目都会至少问一次。答案不取决于“哪个更好”，而取决于我们可以放弃什么。
| IaaS（自行部署在 EC2） | PaaS（RDS） | |
|---|---|---|
| 版本选择 | 任意版本 | 仅限提供商支持的版本 |
| 扩展 | 可安装任何扩展 | 仅限允许列表中的扩展 |
| OS 访问 | 以 root 执行任何操作 | 没有——不存在 Shell |
| 补丁 | 由我们规划 | 提供商在维护窗口执行 |
| 故障调查 | 可自由查看日志与性能分析 | 仅能使用公开的指标和日志 |
| 运维人员 | 需要 | 几乎不需要 |
| 成本 | 通常较低 | 通常较高 |
无法访问 OS 是实务中最令人痛苦的一项限制。确实有团队因为无法使用某个 PostgreSQL 扩展，或不能修改内核参数，而放弃托管服务。因此在决策前，最好先列出“我们现在在服务器上实际做了哪些事”。
工作原理
容器位于哪里
IaaS ─ VM ─ 컨테이너(직접 운영) ─ 관리형 K8s ─ 컨테이너 서버리스 ─ PaaS ─ SaaS
(EKS/AKS/GKE) (Fargate/Cloud Run)
托管 Kubernetes 只托管控制平面。工作节点的 OS、kubelet 和 CNI 往往仍由我们负责。不了解这一点，就会问出“明明是托管服务，为什么节点补丁还要我们来做？”
Serverless 交换了什么
以函数为单位运行的服务（如 Lambda）几乎消除了运维负担，但也附带限制。
- 冷启动——一段时间没有调用后，第一个请求会更慢。
- 执行时间上限——无法运行耗时很长的任务。
- 无状态——不能在本地磁盘或内存中持续积累内容。
- 厂商锁定——不同提供商的事件模型和运行时各不相同。
当流量波动很大且任务很短时，它具有压倒性优势；若负载稳定、任务耗时长，反而可能更昂贵。
用数值衡量锁定(lock-in)
采用托管服务会绑定到相应提供商。若试图完全避免绑定，就什么也无法使用；但若不知道绑定的代价，日后迁移成本会爆炸。判断标准如下。
- 是否建立在标准之上——兼容 PostgreSQL 的托管服务容易迁移，专有 API 则很难。
- 数据会积累多少——数据越大，迁移成本越高。
- 是否有替代方案——其他提供商是否有性质相同的服务。
比起“绝不被绑定”，“知道以绑定为代价换来了什么” 是更实用的态度。
实际工作中的表现
- 迁移到托管数据库后，发现缺少所需扩展而回退 → 前期确认遗漏。
- 用 Serverless 跑批处理，却触及执行时间上限 → 任务性质不匹配。
- 明明是托管 K8s，节点 CVE 仍由我们处理 → 误解了责任边界。
用文字明确责任边界
比选择哪种模型更容易引发事故的，是对边界的误解。“既然是托管服务，应该会自动处理吧”这种模糊认识中，很多项目其实仍是我们的责任。因此，每次引入服务时，最好逐项写清以下内容由谁负责。
| 项目 | 谁负责 |
|---|---|
| 物理设备与虚拟机监控器 | 始终由提供商负责 |
| 客户机 OS 补丁 | IaaS 由我们负责，PaaS 由提供商负责；托管 K8s 节点通常仍由我们负责 |
| 应用漏洞 | 始终由我们负责 |
| 访问权限配置 | 始终由我们负责 |
| 是否启用数据加密 | 通常由我们开启 |
| 备份保留期与恢复测试 | 即使提供商生成备份，恢复测试仍由我们负责 |
| 可用区部署 | 由我们决定 |
表中最常令人失望的是备份这一行。 人们因为托管数据库每天生成备份就感到安心，但这些备份能否真正恢复、保留期是否满足需求，以及账号本身出现问题时备份是否仍然存在，都必须由我们确认。有备份和能够恢复，是两个不同的事实。
权限也是如此。云事故中相当一部分源于“配置错误”，无论选择哪种模型，这一领域都仍由我们负责。越往上减少的是运维负担，而不是责任。 托管程度越高，我们能控制的手段往往只剩配置，因此每项配置的分量反而更重。迁移到托管服务后，应把节省下来的操作时间投入配置评审和恢复测试；若不预留这段时间，省下的运维时间就会原样转化为风险。
接下来将了解什么
理解托管服务的价值来自哪里——不是从价目表，而是从运维时间的角度来看。