搜索“云计算服务4个层次”，往往是想弄清楚：租一台云服务器、使用云开发平台、订阅在线软件，究竟差在哪里？这些差异会直接影响上线后的维护工作，也决定应用发生故障时，该找供应商处理什么。

四层划分里，为什么会多出一个底层

按从物理资源到应用交付的划分方式，云计算可分为硬件资源层、基础设施服务层、平台服务层和软件服务层。后三层分别对应IaaS、PaaS和SaaS。

但“四层”并非统一的云服务分类标准。广泛采用的服务模型是IaaS、PaaS、SaaS三类；把支撑它们的物理资源单独列出，才形成上述四层结构。有些资料另列函数服务等类别，阅读时要核对其分类口径。

硬件资源层包含数据中心里的服务器、存储设备和网络设施。企业购买公有云服务时，一般不会直接操作这些设备，而是获得经过虚拟化或其他资源管理机制交付的计算能力。因此，四层有助于理解技术结构，采购时仍要落实到具体产品和服务范围。

买了云服务，哪些工作还留在自己手里

IaaS交付的是云服务器等基础资源。供应商维护底层设施，用户仍要处理虚拟机里的操作系统补丁，以及自己安装的软件。把应用搬到云服务器上，原来的维护任务不会自动消失。

PaaS把运行环境也纳入平台管理。开发团队提交代码，平台负责约定范围内的运行环境维护，团队减少了搭建环境的工作，却仍要修改业务代码、管理应用配置。某段查询拖慢页面，平台未必能代替开发者改写它。

SaaS交付可直接使用的软件，用户主要处理账号权限和业务配置。它适合功能匹配现有工作方式的场景；遇到特殊流程，则要核对产品支持的配置范围，不能按“拥有一套可任意修改的软件”来安排开发。

选型时，把现有工作写进采购沟通中，比只问“属于哪一层”更具体。比如，系统补丁由谁处理，数据恢复由谁发起？产品名称相同，托管范围和合同约定也可能不同。“托管数据库”与“在云服务器上自行安装数据库”，留下的运维工作就有明显差别。

应用上线后变慢，该把问题交给谁

假设一家小型业务团队将订单系统部署到PaaS平台。上线后，订单查询页面逐渐变慢，团队向供应商提出扩容请求，希望平台直接解决响应问题。

在这个假设情境中，平台资源记录没有显示明显的计算资源不足，应用日志却显示，延迟集中在查询历史订单的请求。开发人员检查代码后，发现页面每次打开都会读取大量历史记录，再在应用端筛选。

处理方向转向查询逻辑：限制单次读取范围，把筛选交给数据库执行。供应商协助确认平台侧的运行状态，开发团队负责修改代码并测试。直接增加资源可能暂时缓解负载，但会增加费用，也可能留下同一条低效查询。

修改版本进入测试后，团队仍未确认它在业务高峰时的表现，暂时保留原有资源配置，没有立即缩容。下一次沟通带上慢请求记录和对应时间，让供应商核对平台状态；发布安排则留下回退版本，等待高峰时段验证。

准备购买云服务时，将“谁维护运行环境”和“应用故障由谁修改”写清楚。已经上线的系统，则先整理当前产品的托管范围，再确认备份恢复的操作责任与测试安排，避免等到故障发生后才发现双方理解不同。