IaaS、PaaS、SaaS 的区别不在功能多少，而在谁负责哪一层。截至 2025 年，主流公有云都按共享责任模型划分：云商负责「云本身的安全」，客户负责「云里的安全」。IaaS 把操作系统以上的担子留在客户手里，PaaS 收走运行时与中间件，SaaS 连应用一起接管，客户只剩数据与账号。选哪一层，本质是回答「团队愿意长期养哪块能力」。
这个判断在迁移项目里出现得很频繁。一个内部系统从自建机房上云时，团队先按「哪个便宜选哪个」的思路挑了 IaaS 云主机，把操作系统、中间件、数据库全部自己装。半年后运维人手没增加，补丁却积了三个版本，审计日志也只有登录记录。换到托管数据库加容器平台后，人还是那几个人，日常工单量降下来了。责任边界没想清楚，省下的钱会在运维窗口里分期还回去。
一张表看清三层责任边界
责任边界只有一条主线：从下往上数，第一层由云商接管的组件，决定了这套服务属于哪种模式。硬件、机房、虚拟化与物理网络在任何模式下都由云商承担，客户与云商的分工差异全部发生在操作系统以上。
| 维度 | 自建机房 | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| 机房与物理硬件 | 客户 | 云商 | 云商 | 云商 |
| 虚拟化与虚拟网络 | 客户 | 云商 | 云商 | 云商 |
| 操作系统与补丁 | 客户 | 客户 | 云商 | 云商 |
| 运行时与中间件 | 客户 | 客户 | 云商 | 云商 |
| 应用代码与发布 | 客户 | 客户 | 客户 | 云商 |
| 数据与账号权限 | 客户 | 客户 | 客户 | 客户 |
表里唯一一行在四种形态下都没有变化，是数据与账号权限。这一行解释了为什么「上了 SaaS 就不用管安全」是误解：应用层漏洞由云商修，但谁能导出数据、离职账号有没有回收，仍然是使用方自己的责任。
控制力与运维负担刚好是一对反向指标，选择时把这两列一起看会清晰很多。
| 服务模式 | 客户保留的控制力 | 客户承担的日常运维 | 典型适用状态 |
|---|---|---|---|
| IaaS | 高，可自选系统与内核参数 | 重，补丁、中间件、备份全自理 | 存量系统迁移、需特殊内核模块 |
| PaaS | 中，受限于平台支持的运行时 | 中，只管代码与配置 | 新建业务、需要快速迭代 |
| SaaS | 低，仅剩配置项 | 轻，只管账号与数据 | 办公协同、财务、客服等标准能力 |
三类服务在同一个组织里并存是常态：办公协同用 SaaS，新建业务跑在 PaaS，历史遗留系统继续放在 IaaS 上，等修完依赖再动。
判断模式归属的 8 条判据
分界点只有一个——从下往上数，云商接管的第一层组件定模式。落到具体盘点时，用下面 8 条逐项核对，比争论定义有效得多。
- 数一数操作系统补丁由哪方打。
- 看中间件与运行时版本谁升级。
- 确认应用发布流程由谁掌控。
- 核对数据库实例是否被托管。
- 检查审计日志最终落在哪一方。
- 明确账号与密钥由谁签发轮换。
- 盘一遍扩容动作由谁触发。
- 定清楚故障时谁先出面响应。
这 8 条里出现「客户」的次数，就是这套服务实际的 IaaS 成分。全中就是自建，只剩后四条里的一部分，通常落在 PaaS，一条不剩才是 SaaS。
系统层判据：补丁与版本
第 1、2 条决定的是模式归属，也是迁移成本的大头。云主机只提供镜像，镜像里的内核版本、OpenSSL 版本、Java 运行时版本，后续修复都得自己排期。托管容器平台或应用引擎会把基础镜像的修复纳入平台侧维护窗口，客户只在构建阶段选择受支持的运行时版本。判断时可以问一句：出现一个需要重启才能生效的高危补丁时，谁负责停机窗口。答案在客户这边，就是 IaaS 语义。
数据层判据：托管实例与审计落点
第 4、5 条常被忽略却直接影响合规结论。数据库用云上托管实例、日志投递到云商的日志服务，这两件事会把数据链路的责任部分转移给云商，但「谁能读这些日志」的授权配置仍归客户。审计要求里常见的「操作可追溯」，在托管服务下依然要客户自己开启审计并确认留存周期，云商只保证日志通道可用。
运维层判据：扩容与故障响应
第 7、8 条决定的是协同方式。IaaS 下扩容意味着客户自己拉起实例、改负载均衡后端、验证健康检查；PaaS 下扩容多为改副本数或阈值，平台完成调度。故障响应同理：IaaS 的排查从操作系统内部开始，PaaS 只需定位到应用日志与平台事件。把这两条的预期提前写进值班手册，能省掉大量「到底谁看」的沟通。
责任边界怎么落到文档和代码
边界写得含糊，出事时就会以「以为对方管」收场，所以把它做成一份可执行的责任矩阵，投入不大却能省掉反复确认。做法是把层与模式的对应关系放进一个映射，让上线检查脚本直接读它，而不是写在会议纪要里。
# 责任矩阵：按服务模式判断某一层由谁负责
RESPONSIBILITY = {
"硬件与虚拟化": {"IaaS": "cloud", "PaaS": "cloud", "SaaS": "cloud"},
"操作系统与补丁": {"IaaS": "customer", "PaaS": "cloud", "SaaS": "cloud"},
"运行时与中间件": {"IaaS": "customer", "PaaS": "cloud", "SaaS": "cloud"},
"应用代码与发布": {"IaaS": "customer", "PaaS": "customer", "SaaS": "cloud"},
"数据与账号权限": {"IaaS": "customer", "PaaS": "customer", "SaaS": "customer"},
}
def owner(layer, model):
try:
return RESPONSIBILITY[layer][model]
except KeyError:
return "boundary-undefined" # 边界没定义，先拦住再谈上线
if __name__ == "__main__":
for layer in RESPONSIBILITY:
print(layer, owner(layer, "PaaS"))这段脚本的价值在异常分支：出现 boundary-undefined，说明某个组件被引入时没人确认过责任归属，这类组件往往就是后续扯皮的源头。矩阵不追求一次写全，按季度补条目即可，但每条都要能对应到一个具体的人和一份具体的操作记录。
让矩阵进入评审流程
矩阵只有进入流程才会生效。新建应用走架构评审时，要求提交一张责任表，列出该应用用到的托管服务及其对应模式；采购或续费时，把责任表与合同里的服务级别条款对齐，确认「平台维护什么」与「合同承诺什么」说的是同一件事。这一步做过之后，安全基线核查的范围也会自然收敛，因为哪些层归自己管已经写清楚了。
三处边界容易被顺带挪走的地方
边界经常不是被讨论掉的，而是被默认掉的，下面三处经常在架构图上看不出来。
- 混用无服务器与容器托管，运行时的补丁已由平台接管，客户却仍在排重复的停机窗口。
- 在 SaaS 上拖拽出低代码流程，关键业务逻辑承载其中，却没人给它做版本管理。
- 托管服务提供备份能力，但备份用的加密密钥归谁保管，直接影响恢复时的自主性。
这三处都不需要推翻架构，只要在责任矩阵里补上对应条目，并指定一名归属人，就能把模糊地带消掉。
常见问题（FAQ）
Q1：云服务器和云数据库分别属于哪种模式？
云服务器属于 IaaS，托管云数据库通常按 PaaS 计，因为补丁与高可用由平台维护。
Q2：为什么用 SaaS 出了问题也要自己担责？
SaaS 只把应用与运行时的维护收走，账号权限与数据责任始终留在使用方。
Q3：怎么判断一个组件算 IaaS 还是 PaaS？
看操作系统补丁由谁打、运行时版本由谁升级，两问答「客户」即属 IaaS 语义。
