云计算的主要服务模式包括基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）。三者的区别，可以从一个实际问题理解：购买服务之后，业务系统还有哪些部分由自己搭建和维护？

公有云、私有云、混合云回答的是另一类问题——云资源如何部署和使用，不能拿来替代上述服务模式分类。选型时，把这两个维度分开，才能看清买到了什么、还留下了哪些工作。

买到云服务器后，谁来维护应用

购买IaaS，相当于获得计算、存储和网络资源。服务商维护底层基础设施，使用方仍要管理云服务器中的操作系统和应用。网站无法访问时，如果原因是应用配置错误或磁盘被日志占满，处理工作通常仍落在自己的技术团队身上。

这种模式适合需要控制运行环境的业务。已有系统依赖特定组件，迁移时也有较大的调整空间；代价是补丁更新、故障处理等工作不会因为“上云”而消失。

PaaS把运行平台的管理进一步交给服务商。开发团队提交代码或部署包，不必从零搭建每一台服务器，但仍负责应用逻辑和配置。采购前，把“谁维护操作系统”和“谁处理应用报错”写进责任分工，比笼统地约定“平台负责运维”更清楚。具体分工还取决于产品能力与合同约定。

上线时间紧，现有代码能在平台上运行吗

PaaS能减少环境维护工作，但它提供的运行环境有明确范围。开发语言相同，也可能因为版本、扩展组件或系统权限不同而无法部署。选型阶段，拿现有应用做一次试部署，能提前发现这类限制。

假设一个小型开发团队准备把内部业务系统迁到云端，希望减少服务器维护。系统依赖一个需要安装到操作系统中的原生扩展，而候选PaaS只开放托管运行环境，不允许自行安装该组件。试部署停在依赖加载环节，业务页面尚未启动。

团队核对平台文档，并向服务商确认该扩展的支持方式。若平台没有兼容方案，处理方向就落到修改应用或更换承载方式上。在这个假设情境中，替换扩展会牵动已有功能，团队暂时保留代码，改用IaaS部署该系统，同时接回操作系统维护工作。

迁移安排中，应用部署已有负责人，服务器补丁由谁处理仍未确定。下一次部署测试除了验证扩展能否加载，还要测试更新后的应用能否恢复到上一版本；值守安排暂未确认，暂不把“运行成功”当成迁移完成。

订阅在线软件前，确认数据怎样取回

如果目标是直接使用办公或业务功能，SaaS往往更接近采购成品软件。使用方通过浏览器或客户端使用服务，日常工作集中在账号权限和业务配置上，不必自行部署整套应用。

这种便利也带来产品范围的限制。系统支持哪些功能、如何修改流程，取决于服务商开放的配置能力。业务要求涉及底层代码修改时，标准订阅服务未必能满足，采购前就要确认，避免把功能缺口留到正式使用之后。

数据导出也要具体核对。页面上有“导出”按钮，并不代表业务记录和附件都能完整取回。用少量测试数据验证导出格式，检查附件能否对应到原记录，再确认停止订阅后的数据保留安排。

缩小候选范围时，把尚未分配的维护工作写清，再让候选服务承载一次真实的部署测试或业务操作。签约前留下测试记录，把未支持的依赖、未确认的导出内容逐项落实。