云计算的3种服务模式是IaaS（基础设施即服务）、PaaS（平台即服务）和SaaS（软件即服务）。简单理解：IaaS提供计算、存储等基础资源，PaaS提供运行应用的平台，SaaS交付能够直接使用的软件。

选择时，先明确自己要完成的工作：是直接使用业务软件，还是部署自己开发的应用？后者还要回答一个问题：服务器和运行环境由谁维护？

开通服务后，哪些工作还留在自己手里

购买IaaS云服务器后，使用方仍要安装或配置操作系统、部署程序，并处理系统补丁。服务商负责底层基础设施，但应用报错、服务器配置不当等问题，仍可能落到自己的技术人员手中。

这种模式适合对运行环境有明确要求、能够承担运维工作的团队。已有系统依赖特定组件时，云服务器保留了较多调整空间；相应地，维护工作也不会随着“上云”自动消失。

SaaS的使用方式不同。打开在线办公或客户管理软件，用户接触的是业务功能，无须自行部署服务器。不过，账号权限怎样分配、离职员工的访问权限怎样收回，仍由使用方处理。采购前还要确认数据导出方式，避免停止订阅时才发现迁移受限。

SaaS解决的是使用现成软件的问题。若业务离不开自行编写的程序，就要继续比较IaaS与PaaS。

开发团队被服务器维护占用时

PaaS处在基础资源与成品软件之间：开发者提交代码或应用，平台承担约定范围内的运行环境管理。具体托管到哪一层，要看产品说明；“平台服务”这个名称并不保证所有维护任务都被接管。

例如，设想一个小型开发团队正在上线自研的订单查询系统。程序已经能运行，但部署在云服务器后，开发人员还要处理环境更新，业务迭代因此频繁被打断。团队想减少这部分工作，又不能换成现成的SaaS软件，因为查询逻辑由自己开发。

这时，PaaS是一条可测试的路径。团队把测试版本部署到候选平台，核对现有程序使用的运行环境，并检查更新应用时的操作要求。平台能够接管部分环境维护，但代码中的错误、访问权限配置仍留在团队手里。

如果某个依赖组件不受平台支持，迁移就会停在这里。团队可能调整程序，也可能暂时保留原来的云服务器。减少维护与保持兼容之间，存在实际取舍。

后续测试继续围绕这个组件展开：确认替代方案是否改变查询功能，并把尚未迁移的部分留在现有环境中。完整迁移暂时没有确定时间。

准备采购时，核对交付内容和账单口径

三种模式不是从低级到高级的排序，同一个业务也可能同时使用它们。采购时，把产品名称还原成具体交付内容：拿到的是服务器资源、应用运行平台，还是能够直接使用的软件。

费用也要按实际使用方式核对。IaaS除了资源账单，还会占用团队的维护时间；PaaS减少部分环境管理工作，但平台功能和使用量可能影响费用；SaaS则要检查账号数量与所需功能对应的订阅范围。具体收费以产品报价和合同为准，不能仅凭模式名称判断哪种更便宜。

准备下单时，整理现有应用的运行要求，让服务商写清维护责任；若采购SaaS，就用实际业务试用，并测试数据导出。尚未确认的兼容问题和收费项目，留在采购记录中继续核对。