云计算是什么

1 云计算回答什么问题：从买机器到按需能力

商品站准备参加促销，负责人提出的问题通常很具体：页面能否按时上线，活动时会不会卡住，图片能否稳定打开，订单数据由谁保管。传统做法往往先采购服务器，再安排机房、电力、网络、安装和维护。机器到货不等于业务可用，而活动结束后，已经买下的容量也不会随着访问量减少而退回。云计算改变的是取得这些能力的方式：通过网络远程获取可配置、可计量的 IT 能力，并按照服务约定使用它们。

这里的能力不只指计算机。它可以是运行程序的计算资源、保存文件的存储，也可以是数据库、开发运行环境或直接供人使用的软件。业务购买的是某种可交付结果及其使用权，具体控制范围取决于服务模型。云没有消除机器，只是把部分建设和运维工作交给服务提供者，让使用者通过接口申请、调整和释放资源。能远程访问的服务器并不必然具备完整的云特征，还要看申请、共享、伸缩与计量如何实现。

“云就是别人的电脑”能提醒我们数据仍有物理载体，却省略了关键边界。别人负责到哪层，自己能改什么，发生故障谁恢复，账单按什么计算，都不会由这句话自动回答。租用计算实例时，你可能仍需维护操作系统；使用在线邮件服务时，你通常无法接触底层机器，却仍要管理账号和收件人。相同的远程交付方式，可以对应不同的控制权和责任。

再区分2个常用视角：控制面负责申请、配置、授权等管理操作，数据面负责实际承载网页请求、文件读写等业务流量。创建实例成功，说明管理操作完成，并不能证明商品页面已经正常响应。反过来，管理界面短时不可用，也不必然意味着已有业务流量立即中断。入门时记住这层区别，就能避免把“资源状态正常”当作“用户体验正常”。

选型前先向业务要能力清单：谁使用，处理什么数据，平时与峰值负载多大，允许中断多久，需要保留哪些证据，团队能维护哪些层。把“买4台机器”改写为“支撑商品查询、保存图片、发送通知，并能应对短时流量增加”，才有比较服务的共同尺度。机器数量是某种实现的结果，业务能力和约束才是讨论起点。

2 5 条特征：按需自助、广域网络、资源池、快速弹性、可计量

NIST 对云计算的概括提供了5条有用的观察线索。它们描述资源如何被取得和使用，而不是厂商宣传页上的功能数量。理解每条特征所解决的痛点，也要看到它没有承诺什么。

按需自助让使用者通过控制台或接口申请资源，不必每次等待提供者人工安装。开发人员需要测试环境时，可以按既定权限发起申请。痛点从“等设备交付”变成“如何控制申请范围与回收期限”。自助不等于任何人都能无限创建，也不等于申请一定瞬间完成；容量、配额和审批规则仍可能限制交付。

广域网络访问意味着能力通过网络，以适合不同客户端的标准方式提供。电脑、手机或程序都可能成为使用者。这减少了对某台本地设备的绑定，却也把网络可达性和传输延迟纳入体验。用户能打开控制台，不代表用户所在网络访问商品图片也同样顺畅；判断业务是否可用，仍要观察真实访问路径。

资源池把提供者的计算、存储等资源组织起来，为多个客户分配能力。多租户表示多个租户共享某些底层资源，不表示客户之间可以任意读取数据。隔离是服务必须实现和说明的边界；共享则带来容量利用率与成本上的机会。用户通常选择资源规格和服务承诺，而不指定某块物理设备。共享环境也可能出现性能波动，因此不能把某次测试的最高速度当作持续保证。

快速弹性支持资源随需求增加和减少，缩短采购周期与实际负载变化之间的距离。它既包括扩容，也包括需求下降后的释放。弹性不是无限容量，也不是没有等待时间；新实例启动、程序预热和接入业务都需要过程。只有应用能利用新增资源，资源变化才会变成业务处理能力的变化。

可计量表示使用量可以按适当维度被监测、汇总和计费，例如实例运行时长、存储量、传输量和请求数。它帮助使用者把支出与活动关联起来，但可计量不等于账单天然容易理解。相同的“访问量增加”，可能同时增加计算、图片下载和接口请求费用，需要知道每条账单行对应哪项业务行为。

用1个简化数字理解采购节奏。假设自建服务器购置价为36000元，按3年直线折旧、不计残值，则每年折旧12000元，每月1000元；这些只是设备账面分摊，尚未包含机房、电力和运维。再假设可比较的云计算资源教学单价为2元/小时，运行100小时产生200元计算费用，运行720小时则为1440元，其他服务另计。两者的能力、可靠性与配套成本未必相同，不能直接由这组数字判定谁更便宜。

这个对比要说明的是时间结构：采购先承诺较长周期的容量，按量使用把一部分决策缩短到小时等计量周期。长期稳定负载与短期试验会产生不同结果。能随时释放只是条件，真的完成释放才会停止相应计费；业务停了、资源仍开着，账单仍可能继续增长。

3 IaaS / PaaS / SaaS：责任滑块不是等级

IaaS、PaaS、SaaS可以看成责任边界移动的3种典型位置。它们不代表从落后到先进的排名，也不要求整个系统只选1种。比较时，先看服务交付到哪层，再看团队还需要完成哪些工作。

IaaS，即基础设施即服务，交付计算、存储等基础资源。以计算实例为例，提供者管理底层设施，客户通常负责实例内的操作系统、运行时和应用。客户获得较多配置空间，也承担补丁、部署和恢复等工作。已经有特殊运行要求的软件可能需要这种空间，但“可自行配置”同时意味着“必须有人维护”。

PaaS，即平台即服务，进一步提供应用运行环境。客户通常提交代码或部署包，平台承担约定范围内的操作系统和运行时管理。团队可减少底层维护，把精力放在应用行为上，但必须接受平台支持的版本、部署方式和运行限制。有的平台负责运行时补丁，有的平台要求客户选择受支持版本并及时迁移；不能仅凭PaaS这个名称判断具体分工。

SaaS，即软件即服务，直接提供可用的软件功能，例如邮件协作或客服系统。客户不再自行部署整套软件，却仍需配置组织、账号、访问范围和数据保留方式。软件能正常运行，不保证误发邮件可以撤回，也不保证离职员工的权限已经关闭。业务使用和数据治理仍有明确的客户责任。

观察责任滑块时，按层问问题比背缩写更有效：谁维护操作系统，谁升级运行时，谁修复应用缺陷，谁决定数据用途，谁批准人员访问。随着托管范围增加，前面的部分工作通常移交给提供者，后面的业务判断仍留在客户侧。身份能力可能由平台提供，但谁应该拥有访问权，依然需要客户决定并持续核对。

同一商品站完全可以混用模型：旧的订单程序运行在IaaS实例上，新开发的查询接口部署在PaaS，员工使用SaaS邮件。混用让每项能力选择合适的控制范围，也会增加边界协调工作。选型记录应解释为什么需要这些控制权、谁有能力承担维护，以及服务变化时如何调整，不能只写“采用云原生平台”就结束。

4 责任共担：上云不会自动变安全

责任共担的核心是把工作分清，而不是把风险平均分配。一般而言，物理设施和底层虚拟化更多由云提供者负责，账号、数据和应用更多由客户负责；操作系统与运行时的分界随服务模型和具体产品变化。这是起点，合同、产品文档和实际配置才决定具体边界。

以IaaS为例，客户通常不能维修提供者机房里的硬盘，却需要修复自己系统中的漏洞。以SaaS为例，提供者维护软件，客户仍要避免把敏感文件分享给错误对象。故障发生在哪个技术层，也不一定等于谁承担全部业务后果：提供者恢复服务后，客户可能还要检查数据完整性、处理积压任务并告知业务负责人。

PaaS的边界尤其容易模糊。平台可能负责数据库引擎更新，却不负责客户的错误查询；可能提供自动备份，却不负责判断某个业务记录是否应被删除。“平台有备份”必须继续追问：覆盖什么数据，保留多久，谁发起恢复，恢复到什么位置，由谁确认业务可用。不能确认恢复结果的备份承诺，还不足以支撑业务恢复方案。

可以把这些任务写进RACI表。R表示执行者，A表示对结果负责的人，C表示需要协商的人，I表示需要知会的人。对“恢复商品数据”这项任务，可以约定运维执行恢复，业务负责人确认数据可用，提供者支持人员协助定位，客服获知恢复进度。每项任务应有明确的结果负责人，避免出现多个团队都认为自己只是协助方。

责任表还应附上证据和触发条件。例如发现账号异常由谁先停用、保留哪些记录、何时联系提供者；平台宣布升级时由谁检查兼容性。入门阶段无需展开具体授权策略，但必须知道权限和数据不会因为“已经上云”就自动处于正确状态。安全来自持续履责，托管服务只是改变了履责方式。

5 弹性与应用约束：能扩不等于能扛

弹性扩容改变资源数量，应用吞吐是否增加，还取决于工作能不能分给这些资源。若每个请求都依赖同1个已饱和的数据库，增加应用实例可能只是让更多请求同时等待数据库。资源图表上实例翻倍，与用户端超时减少之间，需要有可验证的因果链。

无状态是常见的扩容条件：某次请求不应只能交给某台实例才能继续处理。如果购物车只存在实例本地内存，新请求换到另一台实例时就可能找不到内容。把必要状态放到可共享、可恢复的位置，有助于实例替换，但共享状态本身也需要容量和可靠性设计。无状态不是系统没有数据，而是处理请求的实例不独占必须延续的业务状态。

启动时间决定新增能力何时真正可用。教学假设：原有2台实例合计每秒稳定处理200个请求，突发负载变成每秒300个请求，新实例从触发到就绪需要90秒，期间处理能力不变。若请求全部进入等待队列，且忽略失败、重试和用户放弃，积压将达到9000个请求。若接口目标要求绝大多数请求在2秒内完成，90秒后的扩容无法追回已经违反目标的请求。

假设扩容后总能力为每秒400个请求，而到达量仍是每秒300个，剩余每秒100个的能力才可用于清理积压，理想情况下还需要90秒。若只扩到每秒300个，新增能力仅够接住新请求，积压不会自行消失。这些数字是简化模型，却能说明为什么需要提前量、合理余量与突发期间的处理策略。

会话影响请求能否换实例，队列背压影响系统如何面对超过能力的工作。队列可以平滑短时波动，但无限排队会把过载变成长时间等待。达到边界时，应根据业务选择限制进入速度、明确拒绝、延后非关键任务或降低部分功能。重试也要有节制，否则已经处理不过来的系统会收到更多重复请求。

评估弹性时，要共同观察到达率、完成率、错误率、等待时间和下游容量，并确认实例是否真正就绪。扩容失败的常见原因不是按钮失灵，而是应用假设不成立：本地状态无法迁移、初始化过慢、连接数耗尽，或核心依赖没有扩展空间。缩容同样需要约束，实例退出前应处理好正在执行的工作，不能仅按低利用率立即终止。

6 计费直觉：计量维度与账单惊喜

读账单先建立量纲意识。计算费用可能按规格与运行时长计量，存储费用可能按容量和保存时间计量，出网费用可能按传输数据量计量，请求费用可能按调用次数计量。具体服务还可能有最低计费单位、免费额度或额外项目，因此必须以所用产品的规则为准。“服务器多少钱”只能覆盖总成本的一部分。

用1组教学假单价演算月度费用：计算1元/实例小时，存储0.1元/GB月，出网0.5元/GB，请求1元/100万次。假设2台实例各运行720小时，平均保存200GB数据，产生1000GB出网和2000万次计费请求。对应费用为1440元、20元、500元、20元，合计1980元。这里忽略阶梯价、税费、折扣和其他服务，GB的统计口径也假设已经统一，数字不代表任何厂商报价。

在这个模型中，把实例运行时间减少10%，计算项减少144元；把出网量从1000GB提高到5000GB，则出网项增加2000元。可见最显眼的计算资源不一定是增长最快的项目。页面新增大图、客户端重复下载、接口频繁轮询，都可能让账单变化快于用户数量变化。

闲置资源是另一类常见来源。测试结束后不再登录实例，并不等于实例已停止计费；实例释放后，保留的数据盘、备份或其他关联资源也可能继续产生费用。回收要按资源清单逐项核对，既避免遗留费用，也避免误删仍需保留的数据。使用量下降后，账单能否同步下降，需要看实际释放了什么。

还要留意“流量夹层”：1次用户操作可能触发页面、图片、后台接口与服务间传输，用户看到的是1个动作，计量系统看到的却是多段行为。某些跨区传输也可能单独计费，本课只要求识别这类账单项目，不展开基础设施布局。把计量项对应到业务链路，才能解释为什么页面访问量只涨了少量，传输费用却增加很多。

建立基础看板时，把预算、实际费用和关键用量放在一起，并记录资源归属与用途。费用异常时先判断是用量变化、单价变化还是资源遗留，再定位具体项目。预算告警是提醒，不自动代表已经停止支出；要事先明确收到提醒的人以及后续动作。更系统的成本治理留到后续课程，这里先掌握能解释账单的基本方法。

7 常见坑：把云当机房搬家、厂商锁定恐惧、安全外包幻觉

第1个坑是只做lift-and-shift，也就是把原有程序和运行环境搬到云上，却沿用所有旧约束。搬迁本身可以是合理起点，例如先缩短设备采购等待，但它不会自动消除单点数据库、本地文件依赖或手工发布流程。如果原系统必须依靠某台机器的本地状态运行，搬迁后的扩容仍可能失败。方案应写明此次迁移改善什么、暂时保留什么限制，以及这些限制如何影响验收。

第2个坑是被厂商锁定恐惧支配所有选择。服务接口、数据格式、运维技能和合同都可能形成迁移成本，自建系统也有自己的依赖。为了避免任何依赖而完全放弃托管能力，可能付出过高的建设和维护成本；毫无评估地采用专有功能，也可能让退出变得困难。合理做法是对关键数据和关键能力检查导出方式、恢复路径、替代服务与切换时间。

数据重力让这个问题更具体。数据量越大，围绕它形成的接口、分析流程和人员习惯越多，搬走它需要的传输时间、验证工作与费用往往越大。即使代码可以快速重新部署，也不代表历史图片、订单和审计记录能同步迁移。退出计划至少要说明数据如何取出、完整性如何核对，以及切换期间谁处理新增写入。

第3个坑是认为“全用托管就安全”。托管减少某些维护任务，却无法代替业务授权、配置检查和数据分类。把客户资料错误分享出去，通常不会因为底层平台已安装补丁就得到阻止。采用托管服务时，应把节省出的维护精力投入仍由客户承担的工作，并按责任表检查，而不是把整张安全清单划给提供者。

这3类错误都把1个局部变化当成整体保证：搬迁被当成架构改善，可迁移被当成没有依赖，托管被当成没有责任。纠正它们的方法是要求具体证据。要弹性就验证工作如何分散，要退出就验证数据如何导出，要安全就验证任务由谁完成。概念只有落到可观察的行为，才能帮助团队决策。

8 案例：同一电商的 3 种服务模型落位

某商品站需要展示商品、提供图片、处理订单并发送通知。团队有维护旧订单程序的经验，但没有维护邮件系统的能力。先列能力，再选择服务：旧程序需要特定系统环境，暂放在IaaS计算实例上；新商品查询接口可以使用PaaS运行环境；邮件采用SaaS。商品图片存入对象存储，它提供通过接口保存和读取对象的能力，具体概念将在C7展开。

对象存储提醒我们，真实产品不一定整齐落入3个缩写的格子。团队无需为了分类而争论标签，应直接确认它交付什么接口、由谁保存数据、客户如何控制访问、按什么计费。商品图片放进托管存储后，应用仍要保存正确引用，上传者仍要有适当权限，删除流程仍要避免误删在售商品图片。

这套组合的责任表需要分别落位。计算实例的操作系统和旧程序由团队维护；PaaS平台维护约定的运行环境，团队负责查询代码和发布验证；邮件服务维护软件，团队管理发信账号、收件人和通知内容。订单数据的恢复结果由业务负责人确认，不能因为用了多个服务就失去整体负责人。

计量项也要分开记录：计算实例看运行时长，PaaS按实际产品规则记录运行资源和调用量，图片服务看存储、读取请求及传输，邮件服务看订阅席位或发送量。相同的促销可能同时推动多个项目增长，预算估算必须覆盖整个用户动作，不能只估应用实例。

验收时检查3份材料。责任表要能找到每项维护与恢复任务的执行者和结果负责人；计量表要能把账单行映射到业务能力；弹性假设要说明请求如何分配、实例多久就绪、状态放在哪里、数据库能承受多少并发。再用试运行观察这些假设是否成立。成功创建资源只是交付过程中的1步，能够解释故障与费用，才说明方案已经具备基本可运营性。

9 排查案例：账单暴涨、弹性扩了仍超时、责任扯皮

促销后的早晨，团队同时收到3条反馈：昨日费用突然上升，活动期间接口仍有超时，恢复测试又因职责争议停住。不要把这些现象合并为“云不好用”。先保留同一时间范围内的账单行、资源指标、业务记录与责任表，再为每个现象建立可证伪的解释。

账单排查，路径A：出网或跨区传输。 先按服务、资源和计量项拆出增量，发现传输费用上升后，再对照传输字节数与访问来源。如果图片总下载量同步增加，就检查图片大小、重复下载和调用链；如果用户访问稳定而跨区传输增长，就核对是否增加了数据搬运任务。证据应是具体账单行和对应流量记录，不能只凭“昨天做了促销”下结论。处理后还要观察同类用量是否下降。

账单排查，路径B：未关测试机。 如果增长集中在计算时长，就查看新增实例、运行区间、用途和归属。假设测试结束后遗留10台实例，每台教学单价1元/小时，连续运行24小时会增加240元计算费用。联系归属人确认保留需求，再释放不需要的资源，并核对关联存储。证据是资源清单与计费时长；没有归属标签时，应补齐登记流程，避免下次再次靠猜测认领。

账单排查，路径C：请求次数。 如果计费调用数激增而传输量变化不大，就检查轮询频率、失败重试和后台任务。某个程序可能把每60秒调用1次误改成每1秒调用1次，使相同客户端的调用量变成原来的60倍。应核对接口日志和发布记录，区分正常使用增长与程序行为变化。3条路径可以并存，修复计算资源遗留后，仍需检查其他增量是否得到解释。

弹性扩了仍超时。 时间线显示应用实例从2台增加到4台，且新增实例已经就绪，但每秒完成请求数没有明显增加。继续对照应用等待时间、数据库连接与查询延迟，发现所有实例仍连接同1个数据库，数据库已达到处理上限。此时增加应用实例只能增加争抢。先控制进入速度、限制无效重试，并定位慢查询或其他占用，再评估数据库容量与结构调整。只有观察到瓶颈转移或消失，才能证明措施有效。

责任扯皮。 客户认为平台有备份就应该完成恢复，提供者认为客户必须先提交恢复范围，双方都没有确认恢复后的验收人。检查原责任表发现只写了“云负责备份”，没有写恢复任务。补充恢复对象、发起人、执行者、结果负责人和通知对象，并做范围可控的恢复演练。证据应包括恢复请求、操作记录和业务确认结果；“双方已沟通”不能替代可执行的分工。

这次排查的交付物不是1个笼统故障原因，而是逐项闭合的解释：哪条账单为什么增长，哪个依赖限制吞吐，哪项任务无人负责。每个修复都要有对应观察结果，并把新的认识回写到计量清单、弹性假设和责任表中。这样，事故经验才会成为下次方案评审能够使用的材料。

放进方案里

先写能力清单，把商品查询、图片保存、订单处理和邮件通知分别列出，注明使用者、数据类型、正常负载、峰值持续时间与可接受中断。对尚未确认的数字标记假设和确认人，避免把猜测写成承诺。业务负责人确认目标后，技术团队再把能力映射到具体服务，资源数量作为估算结果附后。

服务模型选择要记录控制权与维护能力。每项能力写明采用IaaS、PaaS、SaaS或其他托管接口的理由，以及客户仍需维护的层。需要特殊运行环境，就说明由谁维护系统；采用平台运行代码，就确认版本限制与升级安排；使用成品软件，就明确账号管理和数据导出方式。关键数据同时记录退出路径和迁移约束。

附上共担RACI，把补丁、授权、备份、恢复和异常处置写成可执行任务。每项任务指定执行者和结果负责人，注明何时需要提供者协助，以及用什么记录确认完成。对跨服务的恢复，另设整体负责人，确保各部分恢复后还能完成业务验收。

弹性假设应写出单实例处理能力、启动时间、状态位置、下游上限和过载时的处理方式，并约定验证场景。用突发负载检查新增资源就绪前的等待，用缩容场景检查进行中的任务，记录假设与实测差异。对尚不能解决的瓶颈，说明它限制的业务范围及临时措施。

最后建立计量看板，将计算、存储、传输与请求映射到业务和责任人，列出教学估算或实际报价的适用条件。为费用变化设置通知与处理动作，安排测试资源到期回收，并保留账单行、指标和变更记录。评审时应能同时回答能力是否够用、工作由谁完成、超出预期后如何发现和处理。

10 小结：走向全球基础设施（C2）

云计算把IT能力的取得方式变为远程、按需和可计量的服务。5条特征帮助判断交付方式，服务模型帮助划分控制范围，责任共担、弹性假设和计量清单则把选择落到运营任务。判断方案是否成立，要同时看业务结果、承担责任的人和支撑结论的证据。

接下来需要回答：这些能力实际部署在哪里，不同位置之间的距离和故障边界如何影响服务。C2将从云的全球基础设施出发，建立理解区域与可用区的基础。