选云服务时，容易出现一种落差：以为买了服务，系统维护就交出去了；真正上线后，却发现补丁、备份和故障处理仍有不少工作留在自己手里。

云计算三种服务模式的区别，可以从交付内容理解：IaaS提供基础计算资源，PaaS提供运行应用的平台，SaaS提供直接使用的软件。选型时，要把这层区别落实到“谁负责维护什么”。

系统出故障，哪些事情还归自己处理？

使用IaaS，企业拿到的是云服务器等基础资源。云厂商负责底层基础设施，用户仍要管理服务器里的操作系统和应用。网站因应用进程异常而无法访问，处理工作一般仍在自己的技术团队；底层宿主机故障则属于厂商负责的范围。

这类服务保留了较大的环境控制空间。应用依赖特定系统组件，或者要自行调整运行环境时，IaaS能容纳这些操作，但系统补丁、配置维护也随之留给用户。

PaaS把操作系统和运行环境的管理进一步交给平台，开发者主要提交代码、配置应用。代价是部署要遵守平台规则：支持哪些语言版本、允许安装哪些依赖，会直接影响现有程序能否运行。

SaaS交付的是成品软件，用户通过网页或客户端开展业务，不必部署应用。不过，账号权限和业务数据仍要自己管理。员工离职后账号未停用，不能指望软件厂商自动识别并处理。

应用能运行，为什么迁移仍会卡住？

IaaS与PaaS的选择，常卡在“减少维护”和“保留环境控制”之间。已有应用在云服务器上能运行，并不代表搬到托管平台后仍能原样运行。

假设一支小型团队在IaaS上维护自研订单系统，业务功能可以正常交付，但操作系统更新和运行环境维护持续占用开发时间。团队准备转向PaaS，希望把这些工作交给平台。

试部署时，应用依赖的一个本地组件无法在平台支持的环境中安装。这个阻碍与服务器算力无关，加大套餐也解决不了。团队查阅平台文档，确认该组件要求自行安装系统级依赖，而所选服务没有开放相应权限。

处理方向收敛为两条：替换这项依赖，或者继续保留能自行管理系统的部署环境。团队尝试用平台支持的实现替代旧组件，再验证相关业务功能。改动后的应用能够进入后续测试，但依赖该组件的历史处理逻辑还未验证完成，正式迁移暂时没有推进。

后续测试集中在这部分逻辑，原有IaaS环境继续运行，避免迁移试验影响订单处理。减少维护的目标仍在，但代码修改和验证工作已经进入迁移预算。

比较报价时，把哪些工作算进去？

IaaS账单主要体现资源使用，团队承担的维护时间往往不在报价里。PaaS可能按应用实例或调用量计费，部分平台管理工作包含在服务中，但应用代码出错仍由开发团队处理。比较两者时，把运行费用和内部维护投入放在同一份记录里，单看套餐价格容易漏项。

如果需求只是使用现成的办公或客户管理软件，SaaS能省去自建应用的工作。若业务流程超出产品支持范围，就要核对配置能力和接口限制，不能默认购买后便能任意修改。

退出成本也要在购买前确认。SaaS核对数据导出的内容和格式；PaaS检查应用对专有接口的依赖。拿现有应用的关键依赖做一次试部署，或导出一份样例业务数据，确认能运行、能迁出，再确定采购范围。