模型配方​

云服务商C对数据入站（上传到云）免费或低价，对数据出站（下载到本地或其他云）采用阶梯式高价计费。当企业客户E将核心业务数据D迁移上云后，形成“数据重力”。未来如需数据迁移、混合云架构、备份到本地或其他云时，将面临巨额“数据出口税”，形成强经济锁定。

方法名称​

非对称带宽定价与数据重力锁定模型

逐步思考推理​

1. 定价结构设计：P_in ≈ 0（入站），P_out >> C_cost（出站），采用阶梯定价或95峰值计费
2. 客户上云：E被低存储成本吸引，迁移VTB数据，成本Cost_init ≈ V×P_store
3. 数据积累：业务运行产生新数据ΔV，总数据V_total增长
4. 迁移需求：E需数据出口做分析、备份、迁移到多云，成本Cost_migrate = V_total×P_out
5. 锁定决策：若Cost_migrate > β×Annual_Bill，放弃迁移，接受锁定
6. 后续剥削：C可提高其他服务价格，E因转换成本高而接受

数学方程式​

- 月度费用：M(t) = f(BW_out(t), P_out) + g(Storage(t), P_store)
- 迁移成本：Cost_migrate = V_total × P_out + Cost_downtime
- 锁定条件：Cost_migrate > γ × TCO_alternative

精度/密度/误差/强度​

识别精度：高（定价公开）
伤害密度：高（迁移成本可达数百万美元）
执行误差：低（自动计费）
规避强度：中（商业自由但可能反垄断）

底层规律​

1. 转换成本理论 2. 两部分定价 3. 数据重力 4. 锁定效应

典型场景​

1. AWS/Google云对出站数据收费$0.05-0.12/GB
2. 企业从云存储下载PB级数据做本地分析
3. 多云迁移时数据出口成本超过新云一年费用

变量说明​

C：云服务商；E：企业客户；P_in/P_out：入站/出站单价；V_total：总数据量；Cost_migrate：迁移成本；BW_out：出站带宽

状态机​

S0：低价吸引 → S1：数据迁移 → S2：业务运行 → S3：出口需求 → S4：成本评估 → S5：锁定接受 → S6：价格上涨 → S7：持续剥削

数学特征​

- 客户LTV/CAC：低CAC获客，高LTV剥削
- 转换成本量化：Switching_Barrier = V_total×P_out + ...
- 定价优化：max Π = f(P_out)考虑弹性与监管风险

行为特征​

语言：“入站免费”、“存储低至$0.023/GB”
行为：出口费用在定价页不显眼；账单明细复杂
业务：云厂商带宽收入占比高；催生云成本优化行业

时序流程​

t0：上传V0TB，成本C0
t1：月度出口BW_out(t)，费用M(t)
t2：迁移决策时V_total = V0+ΣΔV
t3：计算Cost_migrate
t4：若Cost_migrate过高则放弃

复杂度​

时间：锁定随时间增强
空间：需管理海量数据计费
系统：扭曲竞争，巩固垄断

法律与道德​

法律：反垄断法差别待遇；格式条款无效
道德：透明度缺失；阻碍创新；剥削性定价
裁决：反垄断调查；合同诉讼；集体诉讼
证据：定价方案；账单分析；迁移成本报告；内部文件

关联知识​

云计算定价；反垄断；数据迁移；供应商锁定

模型配方​

云厂商C提供托管K8s服务（如EKS、AKS、GKE），其控制平面API与标准K8s API存在专有扩展和不可迁移的配置。客户E使用这些扩展后，其应用配置、网络策略、存储类等无法迁移到其他K8s发行版，形成深度技术锁定。

方法名称​

容器编排控制平面扩展锁定模型

逐步推理​

1. 兼容性宣传：声称“CNCF认证”，支持标准API
2. 专有扩展：推出云原生负载均衡、存储类、网络策略等专有CRD
3. 最佳实践引导：文档、教程、QuickStart大量使用专有扩展
4. 架构依赖：E的微服务架构深度集成专有扩展
5. 迁移障碍：迁移到其他K8s需重写配置，可能需重构应用
6. 锁定强化：新功能只通过专有扩展提供，标准API功能滞后

数学方程式​

- 锁定强度：L = (N_proprietary)/(N_total)
- 迁移工作量：W_migrate = α×N_proprietary×LoC_per_extension
- 成本效益比：ROI_migrate = (Cost_savings)/(W_migrate×Cost_dev)

典型场景​

1. AWS EKS的ALB Ingress Controller
2. GKE的Cloud Run for Anthos
3. AKS的Azure CNI网络插件
4. 使用云厂商CSI驱动器的有状态应用

状态机​

S0：选择托管K8s → S1：使用标准API → S2：引入专有扩展 → S3：架构依赖 → S4：多云需求 → S5：迁移评估 → S6：放弃或重构

证据取证​

1. 检查yaml文件中的apiVersion字段
2. 分析CustomResourceDefinition清单
3. 比对storageclass、ingressclass配置
4. 审计Helm charts中的云厂商特定值

配方​

云商提供1/3年预留实例折扣，但合同包含“回收条款”：若客户提前终止或使用量不足，需补缴折扣差价+罚金。企业为获得折扣而过度承诺，业务变化时面临巨额罚金。

数学​

罚金Penalty = Σ(RI_unused × (On-demand_rate − RI_rate) × Remain_months) + Fixed_fee

法律​

可能违反《民法典》的公平原则和情势变更原则

配方​

云市场对ISV采用阶梯分成：首年80/20分成（卖家80%），次年降至70/30，第三年60/40。ISV为保持高分成需不断投入营销资源，实质被锁定在平台生态。

状态机​

开发应用→上架市场→获得客户→分成下降→投入营销→更多依赖→更难离开

P7-0001

虚拟机世代强制淘汰模型

定期淘汰旧代虚拟机实例类型，强制用户迁移到新代，新代价格更高但性价比提升有限

P7-0002

专用实例预留折扣陷阱

承诺预留实例折扣，但实际使用中通过限制资源调度、可用区绑定等方式降低折扣价值

P7-0003

Spot实例价格突然飙升模型

在特定时间（如重大事件、节假日）突然大幅提高Spot实例价格，导致用户应用意外终止

P7-0004

自定义镜像导出格式封闭

自定义虚拟机镜像只能以专有格式导出，无法直接在其他云平台使用

P7-0005

安全启动密钥托管绑定

强制使用平台托管的密钥进行安全启动，用户无法控制密钥，也无法迁移到其他平台

P7-0006

GPU实例驱动绑定模型

GPU实例预装特定版本驱动，与平台深度绑定，升级困难，兼容性问题多

P7-0007

裸金属服务器固件锁定

裸金属服务器的固件更新必须通过平台进行，且固件包含专有代码，无法自行管理

P7-0008

自动伸缩组冷却期滥用

设置过长的自动伸缩冷却期（如10分钟），响应延迟，用户被迫过度预配资源

P7-0009

抢占式实例优雅终止失效

抢占式实例被回收时，优雅终止信号发送但实际立即终止，导致数据丢失

P7-0010

预留实例灵活性限制

预留实例无法在实例类型、区域、可用区之间灵活转换，利用率低

P7-0011

实例元数据服务劫持

通过实例元数据服务强制注入平台监控、安全代理，性能开销大且无法移除

P7-0012

虚拟机导入导出税

对虚拟机镜像的导入、导出收取高额数据传输费，即使在同一区域内

P7-0013

CPU积分耗尽惩罚

突发性能实例的CPU积分耗尽后，性能骤降至基准线以下，而非平滑下降

P7-0014

实例类型升级路径锁定

特定实例类型只能升级到平台指定的新类型，无法选择更优替代方案

P7-0015

本地存储数据丢失风险

本地SSD/HDD存储的数据在实例终止时永久丢失，但平台不提供充分警告

P7-0016

自定义CPU拓扑不可用

不允许用户自定义CPU拓扑（如NUMA节点分配），影响高性能计算应用

P7-0017

实时迁移强制中断

平台进行维护性实时迁移时不提供足够通知，且迁移期间网络连接中断

P7-0018

实例启动依赖服务

实例启动依赖平台内部服务（如元数据服务），这些服务故障导致所有实例无法启动

P7-0019

资源预留碎片化

资源预留（如IP地址、存储）分散在不同可用区，无法合并使用，造成浪费

P7-0020

实例生命周期挂钩陷阱

生命周期挂钩执行时间过长或失败时不提供重试机制，导致自动伸缩失败

P7-0021

自定义内核模块禁止

禁止用户安装自定义内核模块，即使有合法需求（如特定硬件驱动）

P7-0022

安全更新强制重启

安全更新强制在业务高峰时段重启实例，不提供推迟选项

P7-0023

实例命名解析绑定

实例内部DNS解析强制指向平台DNS，无法使用自定义DNS服务器

P7-0024

时间同步服务劫持

强制使用平台NTP服务，该服务偶尔有较大时间漂移，影响分布式系统

P7-0025

控制台串口访问收费

对虚拟机串口访问（紧急恢复）按小时收费，价格高昂

P7-0026

实例克隆功能限制

实例克隆功能仅限在同一区域内，且目标实例类型受限

P7-0027

自定义BIOS设置禁止

禁止用户调整虚拟机BIOS设置（如虚拟化扩展、安全启动）

P7-0028

实例挂起恢复收费

实例挂起状态仍按低费率收费，但恢复后需重新预热，性能受影响

P7-0029

热迁移兼容性限制

热迁移仅支持特定实例类型和配置，其他配置需冷迁移导致服务中断

P7-0030

实例预定系统缺陷

预定实例的系统不显示真实库存，用户预定后被告知无资源

P7-0031

资源标签数量限制

限制每个资源的标签数量（如50个），无法进行精细化管理

P7-0032

实例关联资源删除

删除实例时不提示关联资源（如弹性IP、卷），导致资源泄漏和继续计费

P7-0033

自定义监控间隔收费

自定义监控数据采集间隔（如5秒）需额外付费，标准间隔（1分钟）不满足需求

P7-0034

性能基准数据失真

公布的实例性能基准数据在理想环境下测得，实际使用中无法达到

P7-0035

实例放置策略隐藏

不公开实例在物理服务器上的放置策略，无法优化性能（如避免噪声邻居）

P7-0036

专用主机租赁陷阱

专用主机租赁承诺专属物理机，实际可能与其他租户共享底层资源

P7-0037

实例恢复点目标虚高

承诺的实例恢复点目标（RPO）在实际灾难中无法达到

P7-0038

自定义镜像存储收费

自定义镜像按GB每月收费，但无法选择压缩或差异存储

P7-0039

实例规格不对称

实例的vCPU、内存、网络带宽配比不合理，用户被迫选择更高规格

P7-0040

抢占式实例预测误导

提供的抢占式实例中断预测不准确，用户无法可靠规划

P7-0041

自动伸缩依赖负载均衡器

自动伸缩组必须绑定平台负载均衡器，无法使用第三方方案

P7-0042

实例休眠功能缺陷

实例休眠后恢复，部分设备状态丢失（如GPU显存内容）

P7-0043

自定义启动脚本限制

自定义启动脚本（cloud-init）执行时间有限制，复杂脚本可能被截断

P7-0044

资源组绑定销售

必须将实例放入资源组才能使用某些功能，但资源组有数量限制

P7-0045

实例连接代理收费

通过堡垒机或连接代理访问实例需额外付费

P7-0046

虚拟机生成兼容性

新一代虚拟机与旧代不兼容，迁移需重装应用

P7-0047

实时性能监控延迟

控制台显示的性能监控数据有5-10分钟延迟，无法实时响应问题

P7-0048

实例克隆网络重置

克隆实例时网络配置（如MAC地址）重置，影响许可证绑定

P7-0049

自定义调度算法不可用

不允许用户自定义虚拟机调度算法，无法优化资源利用

P7-0050

实例终止保护绕过

即使启用终止保护，平台维护操作仍可强制终止实例

P7-0001

云计算/平台商业策略与技术锁定

产品生命周期管理与强制升级

定期淘汰旧代虚拟机实例类型，强制用户迁移到新代，新代价格更高但性价比提升有限。

商业模型/锁定策略

平台定义代际T，在时间t发布公告，在t+Δt停止旧代实例销售，在t+Δt+δt强制终止旧代实例。迁移成本C_mig迫使用户接受新价格P_new > P_old。

虚拟机世代强制淘汰引擎

1. 策略制定：平台根据硬件更新周期和市场策略，定义实例代际集合 G = {g1, g2, ..., gn}，并为每个代际设置生命周期函数 L(gi, t)。3. 公告与停售：在时间T_announce，对目标代际g_old发布淘汰公告。在T_stop_sale = T_announce + ΔT1 后停止创建g_old实例。4. 强制终止：在T_terminate = T_stop_sale + ΔT2 后，强制终止所有运行的g_old实例。5. 迁移引导：提供迁移工具，但新代g_new定价为P_new，其性价比提升函数 φ(P_new, Perf_new, P_old, Perf_old) ≈ 1 + ε，其中ε为微小正数。
数学方程：
• 实例状态：S(instance) ∈ {Active(g_old), Active(g_new), Terminated}
• 生命周期函数：L(g, t) = 1 if t < T_terminate(g) else 0
• 用户决策：若 C_mig + ∫[t, ∞] (P_new - P_old) dt < C_rewrite，则迁移。其中C_rewrite为应用重构成本。

时间控制精度高（Δt精确到日），性价比提升ε主观性强、难量化，用户感知误差大。

产品生命周期理论、锁定效应、转移成本。

公有云IaaS服务（如AWS EC2， Azure VMs， Google CE的旧代实例淘汰）。

T_announce: 公告时间；T_stop_sale: 停售时间；T_terminate: 终止时间；g_old: 旧实例类型；g_new: 新实例类型；P_old, P_new: 新旧价格；Perf_old, Perf_new: 新旧性能基准；C_mig: 迁移成本（时间、风险）；ε: 宣称的性能价格比提升率。

状态：{可用， 已公告， 停售， 终止}。迁移决策状态：{评估， 测试， 迁移中， 完成}。强制终止为吸收态。

集合论：代际集合G，实例集合I。
逻辑：IF (t >= T_terminate(g_old)) THEN S(instance)=Terminated。
优化：用户面临成本最小化问题：min(C_mig + ∑P_new, C_rewrite)。
代数：价格与性能的线性或非线性关系比较。
拓扑：服务可用性空间在淘汰事件后发生收缩。

通过公告、邮件、控制台提醒进行沟通。行为是单向、强制的。业务上推动硬件更新和ARPU提升。

可能涉及服务等级协议(SLA)中关于变更通知的条款。需评估“合理通知期”是否充分。或违反初始承诺的“长期支持”暗示。

1. t0: 内部决策确定淘汰目标g_old。
2. t1: 发布公告A(t1, g_old, T_terminate)。
3. t1< t < T_terminate: 用户接收信息，评估选项。
4. t = T_stop_sale: CreateInstance(g_old) API返回错误。
5. t = T_terminate: ∀ i ∈ I where i.type == g_old, ForceTerminate(i)。
方程：事件序列 E = {A(t1), S(T_stop_sale), F(T_terminate)}

顺序序列（公告->停售->终止）。对用户而言是乱序事件，打乱原有规划。

决策复杂度对用户为O(n*m)，n为实例数，m为迁移方案数。平台执行为O(1)。

硬件折旧周期、云计算经济学、客户关系管理、应用迁移技术。

P7-0002

云计算/平台商业策略与技术锁定

预留定价与资源调度博弈

承诺预留实例折扣，但实际使用中通过限制资源调度、可用区绑定等方式降低折扣价值。

商业模型/定价策略

提供预留实例RI，承诺折扣率d。但在资源池R中，为RI分配低优先级或受限子集R_ri ⊆ R。当R_ri资源紧张时，RI实例启动延迟高或失败，迫使用户使用按需实例。

预留实例折扣稀释引擎

1. 资源分区：平台将物理资源池R划分为多个逻辑池：按需池R_od，预留池R_ri，Spot池R_spot。设R_ri容量为C_ri。2. 调度策略：当用户启动RI实例时，调度器S优先尝试在R_ri中分配。若R_ri中满足条件的资源不足，则进入队列等待或返回“容量不足”错误，而非从R_od调配。3. 折扣实现：计费系统应用折扣d于RI实例的小时费率。但若因上述调度问题导致RI实例无法启动，用户实际使用的按需实例不享受折扣。4. 价值稀释：用户购买RI预付费用F_upfront，期望获得总节省S_expected = (P_od - P_ri) * T_commit。实际节省S_actual = ∑(P_od - P_ri) * T_usable，其中T_usable << T_commit，因为部分时间实例不可用。
数学方程：
• 资源分配函数：Allocate(instance_type, isRI) -> resource ∈ R_ri if isRI and available(R_ri) >0 else null.
• RI利用率：U_ri = T_usable / T_commit ≤ 1。
• 实际折扣率：d_actual = 1 - (F_upfront + P_ri*T_usable) / (P_od * T_commit)。 当U_ri < 1时，d_actual < d。

折扣率d承诺精确，但实际实现依赖不透明的调度算法和资源余量C_ri，误差大。

资源分配博弈、价格歧视、承诺与兑现的不完全契约理论。

公有云预留实例（如AWS RI, Azure RIs, Google CUD）。

d: 承诺折扣率；F_upfront: 预付费用；P_od, P_ri: 按需、预留小时单价；T_commit: 承诺期限；R, R_ri, R_od: 总资源池、预留池、按需池；C_ri: 预留池容量；U_ri: 预留实例实际利用率；S(instance_type, isRI): 调度函数。

状态：{资源充足(RI可用)， 资源紧张(RI排队/失败)， 资源耗尽(RI完全不可用)}。用户实例状态：{RI运行中， RI启动失败， 使用OD运行}。

博弈论：平台与用户的非合作博弈，平台在提供折扣和保障资源间权衡。
概率：RI可用性是一个概率事件P(Available_RI) = C_ri / Demand_RI。
优化：平台优化总收益：Max Σ(F_upfront + P_riT_usable + P_od(T_commit - T_usable))。
集合：资源池的集合划分与包含关系。

营销材料强调折扣d，合同条款细则中提及“容量最佳努力”。客服沟通时强调RI是容量预约，不保证100%可用性。

需审查预留实例的服务条款，特别是关于“容量可用性”和“服务等级”的描述。可能构成误导性宣传。

1. 用户购买RI，预付F_upfront，获得承诺折扣d。
2. 用户请求启动RI实例。
3. 调度器检查R_ri容量。IF available(R_ri) >= request THEN 分配资源，启动成功，按P_ri计费。ELSE 返回“InsufficientCapacity”错误或进入等待队列。
4. 用户因业务急需，改用按需实例启动，按P_od计费。
5. 计费周期结束，计算实际节省S_actual。
方程：Launch_Result = S(instance_type, true); Cost = if Launch_Result==Success then P_ri else P_od

并行与条件序列。用户启动RI和OD可能是顺序（先尝试RI后OD）或根据策略并行尝试。

用户决策复杂度O(1)每次启动。平台调度复杂度与资源池规模相关。

资源调度算法、容量规划、服务等级协议(SLA)、消费者权益保护法。

P7-0003

云计算/平台商业策略与技术锁定

动态定价与市场供需操纵

在特定时间（如重大事件、节假日）突然大幅提高Spot实例价格，导致用户应用意外终止。

定价模型/市场机制

Spot价格P_spot(t)通常基于空闲资源供需。平台通过预测或主动触发，在时间窗口Δt内，将P_spot(t)提高至远高于按需价格P_od，即 ∃ t0, s.t. ∀ t ∈ [t0, t0+Δt], P_spot(t) > P_od + δ。用户出价上限Bid < P_spot(t)导致实例中断。

Spot实例价格尖峰引擎

1. 价格模型：基础价格模型 P_base(t) = f(Supply(t), Demand(t))，其中f是未公开函数。2. 事件检测：监控系统识别特殊事件E（如节假日、大型活动、竞对故障），预测需求激增。3. 价格干预：在事件E的预期时间窗口W_E内，引入价格调整因子α(t) > 1，使得 P_spot(t) = α(t) * P_base(t)。α(t)可以是一个尖峰函数，如α(t) = 1 + k * exp(-(t - t_peak)² / 2σ²)。4. 实例回收：对每个Spot实例i，实时比较用户出价Bid_i与P_spot(t)。若Bid_i < P_spot(t)，则发送中断通知，并在短暂宽限期后终止实例。
数学方程：
• 动态价格：P_spot(t) = max( P_base(t), α(t) * P_base(t) )。
• 中断条件：Interrupt(i, t) = 1 if Bid_i < P_spot(t) else 0。
• 价格尖峰函数：α(t) = 1 + A * Indicator(t ∈ W_E)，其中A为大幅增量，或更复杂的随时间变化的函数。

价格预测困难，尖峰发生时间点和幅度A具有高不确定性，用户模型误差大。

市场微观结构、价格弹性、行为经济学中的“诱饵效应”（与按需实例对比）。

公有云竞价（Spot）实例市场。

P_spot(t): 时刻t的Spot价格；P_base(t): 基础价格（基于供需）；P_od: 按需价格；Bid_i: 用户对实例i的出价；Supply(t), Demand(t): 时刻t的资源供给与需求；α(t): 价格调整因子；W_E: 特殊事件时间窗口；A: 价格尖峰幅度；σ: 尖峰宽度参数。

实例状态：{运行中(Bid >= P_spot)， 中断警告， 终止}。市场价格状态：{平稳， 波动， 尖峰}。

随机过程：P_spot(t)可建模为具有跳跃的随机过程（如跳跃扩散过程）。
时间序列：价格数据具有季节性、趋势性和突发性。
最优化：用户需优化出价Bid以平衡成本与中断风险：min E[Cost] + λ * P(Interrupt)。
博弈：平台与大量用户之间的非对称信息博弈。

API提供价格历史，但不公开预测算法。价格突变时无预警。业务上通过制造不确定性，促使用户转向更稳定的按需或Savings Plan。

需审查Spot实例服务条款，通常明确声明价格可变且实例可能随时被回收。用户需自担风险，法律挑战困难。

1. 持续监控资源供需和外部事件。
2. 当检测到事件E或决定调整时，计算新的P_spot(t)。
3. 每秒/每分钟更新P_spot(t)并发布。
4. 对每个运行中的Spot实例i，检查条件Bid_i < P_spot(t)。
5. 若条件为真，触发中断流程：发送警告 -> 等待宽限期（如2分钟）-> 终止实例。
6. 实例终止后，资源释放回资源池。
方程：∀i ∈ SpotInstances: if (Bid_i < P_spot(current_time)) then ScheduleTermination(i, grace_period)

分布式序列（价格更新与实例检查并行），对每个实例的条件检查是顺序的。

价格计算复杂度取决于模型f，一般为O(1)或O(log N)。实例检查复杂度O(N)，N为Spot实例数。

金融市场微观结构、拍卖理论、容错计算、弹性伸缩策略。

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

...

P7-0100

云计算/平台商业策略与技术锁定

数据依赖与快照管理

虚拟机快照形成链式依赖但不直观显示，删除中间快照可能导致依赖链断裂，但平台不充分警告。

数据管理/用户界面与体验

快照S_n依赖前一个快照S{n-1}，形成链D = [S0, S1, ..., Sn]。删除中间快照S_k (0<k<n)会使其后所有快照S{k+1}...Sn失效，但UI仅显示简单列表，不展示依赖图。删除操作确认提示弱。

快照链依赖隐藏引擎

1. 快照生成：创建第一个快照S0（基础盘）。后续每个快照S_i仅存储自S{i-1}以来的差异数据，形成增量链。依赖关系为有向链：S0 ← S1 ← ... ← Sn。
2. 存储抽象：对用户展示为独立的快照对象列表L = {S0, S1, ..., Sn}。隐藏邻接矩阵A，其中A[i][j]=1 if S_j 直接依赖于 S_i。
3. 删除操作：用户请求删除快照S_k。系统检查依赖链。若k=0，需合并所有差异数据到S1或创建新基础盘，成本高。若0<k<n，则断开链：S{k-1} → S{k+1}变为不连续，S{k+1}及之后快照因找不到基础数据而失效。
4. 风险提示：仅在删除操作确认对话框显示简单文字警告，不可视化影响范围。
数学方程：
• 依赖关系：D是偏序集，(S_i, S_j) ∈ D iff i < j。
• 删除操作：Delete(S_k) 产生新依赖集 D' = D \ {(S_i, S_k), (S_k, S_j) for all i<k<j} ∪ Merge(S{k-1}, S{k+1})? 实际上，若k非端点，合并复杂，常直接使S_{k+1}...Sn失效。
• 有效快照集：Valid(D) = {S_i

存在路径从S0到S_i in D}。

依赖关系对用户是100%隐藏的，删除操作的成功/失败是确定的，但后果（数据丢失）的严重性未被充分传达。

图论（有向无环图DAG）、数据版本管理、人机交互中的透明度原则。

任何提供增量快照功能的云存储服务（如AWS EBS Snapshots, Azure Disk Snapshots, Google PD Snapshots）。

S_i: 第i个快照；D: 依赖关系集合；L: 用户可见的快照列表；A: 邻接矩阵（平台内部）；k: 用户欲删除的快照索引；Valid(D): 当前依赖关系下有效的快照集合。

快照状态：{有效， 失效}。删除操作状态：{请求， 验证， 执行（合并或标记失效）， 完成}。

图论：快照链是一个有向路径图。删除中间节点会破坏图的连通性。
集合论：有效快照集是依赖关系D下的一个子集。
逻辑：IF Delete(S_k) AND k>0 AND k<n THEN ∀ j>k, Invalidate(S_j)。
组合数学：删除一个快照后，剩余快照的有效组合数发生变化。

控制台UI以平铺列表展示快照，按时间排序。删除按钮明显，确认对话框警告文字小且不醒目。文档可能深埋解释。

服务条款可能声明用户需自行管理快照依赖关系。但若UI设计存在误导，可能违反关于清晰信息呈现的消费者保护规定。

1. 用户从列表L中选择快照S_k，点击“删除”。
2. 系统计算依赖集D，找出所有直接和间接依赖S_k的快照集合R = {S_j

(S_k, S_j) ∈ D*}。
3. 如果R非空，弹出确认对话框：“删除此快照将影响后续快照X个。是否继续？”，其中X=

R

P7-0004

云计算/平台商业策略与技术锁定

数据格式与供应商锁定

自定义虚拟机镜像只能以专有格式导出，无法直接在其他云平台使用。

技术锁定/数据可移植性障碍

平台定义专有镜像格式F_proprietary。当用户导出镜像时，系统将通用格式（如VMDK， VHD）转换为F_proprietary，并可能添加加密或特定元数据。导入时仅支持F_proprietary或有限几种格式。

专有镜像格式转换引擎

1. 格式定义：平台内部使用一种封装格式F_proprietary = Encap(V_data, M_metadata, E_key)，其中包含加密部分或特定校验和。
2. 导出转换：用户请求导出镜像I。系统读取I的原始数据V_data和元数据M_src，通过转换函数T将其转换为F_proprietary: F_out = T(I) = Encap(V_data, M_platform, E_key)。M_platform包含平台特定信息。
3. 兼容性破坏：转换过程可能改变磁盘分区表、引导扇区信息或磁盘标识符，导致其他虚拟化平台无法识别或启动。
4. 导入限制：平台导入功能设计为仅能正确解析F_proprietary格式，或对通用格式的兼容性实现不完整（如不支持某些虚拟硬件版本）。
数学方程：
• 导出函数：Export(I) = F_proprietary。
• 导入函数：Import(F) = I' if Parse(F)成功 else Error。
• 跨平台兼容性：Compatible(F_proprietary, Platform_other) ≈ 0。

格式转换在数据层面可能是无损的，但在兼容性层面引入100%的“误差”（无法直接使用）。

供应商锁定理论、转换成本、数据格式战争。

任何提供自定义镜像（AMI， 自定义镜像）导出功能的云平台。

I: 原始镜像；V_data: 镜像数据；M_src, M_platform: 源元数据和平台添加的元数据；E_key: 可能的加密密钥；F_proprietary: 专有格式；T: 格式转换函数；Parse: 格式解析函数。

镜像状态：{运行中， 已停止， 快照， 导出中， 已导出(F_proprietary)}。跨平台使用状态：{不可用， 需转换， 可用}。

集合论：镜像格式集合 {通用格式} 与 {专有格式} 交集小。
函数映射：导出函数T是从通用格式空间到专有格式空间的单射或非满射。
拓扑：数据可移植性空间被格式壁垒分割。

控制台提供“导出镜像”功能，但格式下拉菜单中只有1-2种专有选项。文档中提及“支持标准格式”，但实际操作中标准格式导入常失败。

可能违反数据可移植性相关法规或行业准则。若平台宣传“开放”但实际限制，可能构成误导性陈述。

1. 用户选择镜像I，点击“导出”。
2. 系统提示选择格式，选项列表O={F_proprietary, (可能有一个不常用的通用格式)}。
3. 用户选择F_proprietary。
4. 系统后台执行T(I)，生成文件F_out，提供下载链接。
5. 用户下载F_out，尝试在其他云平台导入。
6. 其他平台解析F_out失败，或启动后出现驱动、配置错误。
方程：F_out = Encode(I, F_proprietary); Result_other_cloud = Boot(Import_other(F_out)); Success(Result_other_cloud) = False

顺序序列（用户操作触发系统转换）。跨平台尝试是另一个独立的顺序序列。

转换复杂度O(size(I))。用户解决兼容性问题的复杂度高，涉及手动转换、驱动注入等。

虚拟磁盘格式（VMDK， VHD， QCOW2）、镜像封装、虚拟化平台兼容性、数据迁移工具。

P7-0005

云计算/平台商业策略与技术锁定

安全启动与密钥控制

强制使用平台托管的密钥进行安全启动，用户无法控制密钥，也无法迁移到其他平台。

技术锁定/安全功能绑定

平台提供安全启动服务，但密钥对(K_public, K_private)由平台生成并托管在硬件安全模块(HSM)中。用户镜像的引导加载程序必须用K_public签名。启动时，固件用K_private验证签名。用户无法导出K_private或替换为自有密钥。

托管安全启动密钥引擎

1. 密钥生成与托管：平台在硬件安全模块(HSM)中生成密钥对：K_platform = GenKey()。私钥K_private永久保存在HSM中，不导出。公钥K_public嵌入平台固件或提供给用户用于签名。
2. 镜像签名强制：用户创建自定义镜像时，若启用安全启动，必须使用平台提供的K_public或其衍生证书对引导组件（bootloader， kernel）进行签名：Sig = Sign(Component, K_private_platform)。
3. 启动验证锁定：实例启动时，固件使用内置的K_public_platform验证签名。验证失败则拒绝启动。用户无法添加其他信任的根密钥。
4. 迁移阻断：由于其他平台没有K_private_platform，无法为迁移后的镜像生成有效签名，导致安全启动失败。
数学方程：
• 签名：Sig = S(Hash(Component), K_private_platform)。
• 验证：Verify(Sig, Hash(Component)， K_public_platform) = True/False。
• 迁移可行性：Feasible(Migrate(I)) = False if SecureBoot(I)=True and Key_Control=Platform。

密码学操作精度高，但用户控制度为0，形成完全锁定。

公钥基础设施(PKI)、信任根、供应商锁定。

支持UEFI安全启动的云虚拟机实例（如AWS Nitro， Azure Trusted Launch）。

K_platform: 平台密钥对；K_private_platform: 平台私钥（托管）；K_public_platform: 平台公钥；Component: 引导组件；Sig: 数字签名；HSM: 硬件安全模块。

镜像状态：{未签名， 已签名(平台密钥)， 已签名(用户密钥)-不支持}。启动状态：{安全启动验证中， 验证通过， 验证失败}。

密码学：基于非对称加密的数字签名与验证。
逻辑：IF SecureBoot_Enabled THEN MUST Verify(Sig, K_public_platform)。
集合论：可信密钥集合T = {K_public_platform}，用户无法扩展T。

安全启动被宣传为增强安全的功能。UI上提供启用/禁用选项，但启用后密钥管理部分为灰色或提示“由平台管理”。文档说明密钥不可导出。

可能涉及对加密密钥控制权的法规。若平台声称“用户拥有完全控制权”但实际控制密钥，可能构成虚假宣传。

1. 用户创建镜像I，启用安全启动选项。
2. 平台提示“密钥将由平台管理”。
3. 用户构建引导组件C。
4. 用户调用平台签名API：Sig = Platform_Sign(C)。（内部使用K_private_platform）。
5. 将Sig与C打包进镜像I。
6. 启动实例时，固件加载C，用内置K_public_platform验证Sig。
7. 验证通过则启动，否则终止。
8. 用户尝试导出镜像并导入其他平台：其他平台固件使用不同的K_public_other验证Sig，失败。
方程：Boot_Success = Verify(Sig, Hash(C), K_public_platform)

顺序序列。签名和验证是密码学顺序操作。

签名/验证复杂度为O(n)密码学操作。用户迁移的复杂度无限大（无法完成）。

UEFI安全启动规范、PKI、硬件安全模块(HSM)、数字签名、可信计算。

P7-0006

云计算/平台商业策略与技术锁定

硬件驱动与软件栈绑定

GPU实例预装特定版本驱动，与平台深度绑定，升级困难，兼容性问题多。

技术锁定/驱动兼容性

平台在GPU实例的公共镜像中预装定制版驱动D_platform。该驱动与平台的虚拟化层、监控代理深度集成。系统设计为阻止用户安装官方驱动D_official，或使D_official安装后无法正常工作。

GPU驱动锁定引擎

1. 驱动定制：平台基于官方驱动D_official，修改其部分代码或配置，生成定制驱动D_platform = Modify(D_official, Hooks)。Hooks是与平台虚拟化、管理、监控交互的钩子。
2. 预装与锁定：实例初始化时，自动安装D_platform。系统可能通过内核模块签名验证、依赖关系破坏（如libc版本）或服务冲突，阻止D_official的安装或加载。
3. 升级障碍：当用户需要新版本驱动以支持特定CUDA版本或功能时，平台提供的D_platform更新滞后。用户尝试安装新版D_official时，会遇到上述锁定机制。
4. 兼容性牺牲：D_platform可能为了平台集成稳定性，牺牲了对最新GPU功能或第三方软件（如特定AI框架版本）的支持。
数学方程：
• 驱动安装函数：Install(Driver) = Success if Driver == D_platform or (Driver == D_official and Bypass_Check()) else Failure。
• 兼容性函数：Compatibility(App, Driver) = High if Driver == D_official else Medium/Low (取决于平台定制程度)。

驱动功能基本正常，但与最新生态的兼容性存在“误差”或延迟。锁定机制的成功率接近100%。

软件供应链控制、依赖关系管理、锁定效应。

提供GPU加速实例的云平台（如AWS EC2 P/G实例， Azure NC/ND系列， Google Cloud A2/V100）。

D_platform: 平台定制驱动；D_official: GPU厂商官方驱动；Hooks: 平台集成钩子；App: 上层应用（如CUDA， TensorFlow）；Kernel_Mod_Sig: 内核模块签名。

驱动状态：{平台预装， 用户安装官方（成功）， 用户安装官方（失败）}。实例功能状态：{全功能， 部分功能受限， 不兼容}。

图论：软件依赖关系图，平台驱动引入了额外的依赖边（指向平台服务）。
逻辑：IF (Kernel_Module_Sign_Check == ON) THEN Load_Module(D_official) fails。
集合：可用驱动集合被限制为{D_platform}的子集。

实例描述中写明“预装GPU驱动”。用户尝试安装其他驱动时，遇到安装错误、签名错误或性能下降。平台文档可能警告“不支持自行安装驱动”。

可能涉及反竞争行为，如果平台通过技术手段不合理地限制用户选择硬件厂商提供的标准驱动。

1. 实例启动，云初始化程序cloud-init运行。
2. cloud-init执行脚本，安装或验证D_platform。
3. 用户登录，尝试安装D_official。
4. 安装程序检测到已安装D_platform，提示冲突或尝试卸载旧驱动。
5. 卸载D_platform可能失败，或卸载后导致系统不稳定。
6. 若强制安装D_official，系统重启后可能因内核模块签名无效或缺少平台钩子而加载失败，或GPU设备无法识别。
方程：System_State = f(D_platform, D_official); Stable(System_State) is max when D_official = null

顺序序列（启动预装 -> 用户尝试替换）。失败后可能进入回滚序列。

用户解决驱动问题的复杂度高，涉及内核调试、签名管理。

GPU架构、内核模块、设备驱动模型、CUDA生态、操作系统包管理。

P7-0007

云计算/平台商业策略与技术锁定

硬件固件控制权剥夺

裸金属服务器的固件更新必须通过平台进行，且固件包含专有代码，无法自行管理。

技术锁定/硬件管理权剥夺

平台提供裸金属服务器，但其基板管理控制器(BMC)和系统固件(BIOS/UEFI)的更新包F_update由平台签名和分发。用户无法从硬件厂商直接获取或安装官方固件。固件中可能包含与平台管理平面通信的专有模块M_proprietary。

裸金属固件锁定引擎

1. 固件定制：平台从硬件厂商获得基础固件F_base，注入专有管理模块M_proprietary，并用自己的密钥签名，生成F_platform = Sign(F_base + M_proprietary, K_private_platform)。
2. 更新通道控制：BMC的更新接口仅接受由K_private_platform签名的固件包。用户上传厂商官方固件F_official时，签名验证失败。
3. 管理依赖：M_proprietary模块负责与平台管理节点通信，上报硬件状态、接收指令。没有它，平台可能将服务器标记为离线或不可管理。
4. 功能与安全滞后：平台固件更新节奏慢于厂商，用户无法及时获取安全补丁或新功能（如新CPU微码）。
数学方程：
• 固件验证：Verify(F, K_public_platform) = True if F signed by K_private_platform else False。
• 更新函数：Update(F) = Success if Verify(F, K_public_platform) else Failure。
• 服务器管理状态：Manageable(Server) = True if M_proprietary is running and connected。

固件功能正常，但用户控制权为0。安全更新延迟时间Δt可能很大。

硬件信任根、供应链安全、锁定效应。

提供裸金属即服务(BMaaS)的云平台。

F_base: 基础固件；F_platform: 平台签名固件；F_official: 硬件厂商官方固件；M_proprietary: 平台专有管理模块；K_private_platform: 平台签名私钥；BMC: 基板管理控制器。

固件状态：{出厂版本， 平台版本V1， 平台版本V2， 更新失败}。服务器管理状态：{可管理， 不可管理}。

密码学：基于签名的固件完整性验证。
逻辑：IF (Firmware_Update_Request) THEN CHECK Verify(F, K_public_platform)。
图论：管理依赖图，服务器节点依赖于平台管理模块M_proprietary。

控制台提供“更新固件”按钮，但只能从平台列表中选择版本。尝试通过IPMI或其他带外管理接口直接更新会被拒绝。文档声明“固件由平台统一管理”。

用户购买了裸金属服务器的使用权，但固件控制权的剥夺可能超出“管理服务”的合理范围，涉及对硬件资产控制权的争议。

1. 硬件厂商发布新固件F_official，修复安全漏洞CVE。
2. 平台评估、测试并定制F_official，生成F_platform，此过程耗时Δt。
3. 平台在控制台发布F_platform供用户选择。
4. 用户发起更新请求，选择F_platform。
5. 平台管理服务通过BMC接口推送F_platform。
6. BMC验证签名通过，执行更新。
7. 用户尝试通过厂商工具直接更新F_official，BMC验证签名失败，拒绝更新。
方程：Update_Allowed(F) = Verify(F, K_public_platform); Δt = T_platform_release - T_official_release

顺序序列。平台发布更新和用户尝试自行更新是两个独立的时间线。

用户绕过锁定的复杂度极高，需要物理访问或破解签名。

服务器硬件管理（BMC， IPMI）、UEFI固件、安全启动、供应链管理。

P7-0008

云计算/平台商业策略与技术锁定

自动伸缩响应延迟策略

设置过长的自动伸缩冷却期（如10分钟），响应延迟，用户被迫过度预配资源。

策略模型/性能与成本博弈

自动伸缩组(ASG)策略中，冷却期参数T_cooldown被设置为一个较大的固定值（如300秒， 600秒）。在伸缩活动（扩容或缩容）完成后，ASG在T_cooldown时间内忽略其他伸缩告警。

长冷却期策略引擎

1. 冷却期定义：ASG在每次伸缩活动（增加或减少实例）后，进入冷却状态C。在C状态下，由CloudWatch告警触发的伸缩动作被挂起。
2. 策略设置：平台为ASG设置默认冷却期T_cooldown_default，且允许调整的上限T_cooldown_max也较大。UI或CLI工具可能不提示最佳实践值。
3. 响应延迟：当负载在冷却期内再次波动时，ASG无法响应，导致性能下降（扩容延迟）或资源浪费（缩容延迟）。
4. 过度预配激励：为了应对冷却期带来的响应延迟，用户倾向于设置更高的基线容量（Base Capacity）或更保守的告警阈值，导致资源利用率降低，成本增加。
数学方程：
• ASG状态：S(t) ∈ {Cooldown, Active}。
• 冷却期启动：S(t) = Cooldown for t ∈ [T_activity, T_activity + T_cooldown]。
• 告警抑制：During S(t)==Cooldown, Ignore(Alarm)。
• 用户成本：Cost_user = Cost_overprovision + Cost_performance_penalty。其中Cost_overprovision与基线容量正相关。

冷却期计时精确，但时长设置与业务负载模式不匹配，导致响应“误差”。

控制理论（抑制振荡）、容量规划、激励错配。

所有提供自动伸缩组服务的云平台。

T_cooldown: 冷却期时长；T_activity: 伸缩活动完成时间；S(t): ASG状态函数；Alarm: 监控告警；Base_Capacity: 基线实例数。

ASG状态：{活动(可伸缩)， 冷却(不可伸缩)}。实例数量状态：{稳定， 扩容中， 缩容中}。

时间序列分析：负载L(t)与实例数I(t)的关系，冷却期引入了响应延迟τ=T_cooldown。
优化：用户需在响应速度与伸缩振荡间权衡。平台默认值可能不在用户最优解上。
微分方程：dI/dt = f(L(t) - I(t))，但在冷却期内f被强制为0。

控制台ASG配置页面，冷却期参数默认值大且可调范围宽。文档可能提及冷却期用于“防止过于频繁的伸缩”，但未给出基于负载模式的设置指导。

通常属于服务配置自由度范畴。但如果默认值明显不合理且导致用户普遍受损，可能涉及服务设计缺陷。

1. 时间t0，负载上升触发扩容告警A1。
2. ASG执行扩容动作，增加实例，在t1完成。
3. ASG进入冷却期，状态S(t)=Cooldown until t1+T_cooldown。
4. 时间t2 (t1 < t2 < t1+T_cooldown)，负载再次飙升触发告警A2。
5. 由于处于冷却期，A2被忽略。
6. 应用在t2到t1+T_cooldown期间性能下降。
7. 用户手动提高基线容量或调小T_cooldown。
方程：if (now - last_scaling_activity_time) < T_cooldown then ignore_scaling_alarm()

顺序序列（告警->伸缩->冷却->告警被忽略）。

决策复杂度低，但性能影响大。用户需要反复试验找到合适的T_cooldown。

自动控制原理、监控与告警、负载预测、容量管理。

P7-0009

云计算/平台商业策略与技术锁定

资源回收信号处理缺陷

抢占式实例被回收时，优雅终止信号发送但实际立即终止，导致数据丢失。

系统实现缺陷/可靠性陷阱

抢占式实例回收流程设计为：1. 发送中断警告信号（如SIGTERM， metadata flag）。2. 等待短暂宽限期T_grace（如2分钟）。3. 强制终止。但实现中，步骤1和步骤3之间的间隔T_actual可能远小于T_grace，甚至为0。

优雅终止失效引擎

1. 信号发送：当平台决定回收实例I时，首先通过实例元数据服务或内部信号机制设置一个标志Flag_interrupt = True，并/或向实例操作系统发送SIGTERM信号。
2. 宽限期承诺：文档承诺在设置标志或发送信号后，有T_grace（如120秒）的宽限期供实例进行清理（保存状态、结束进程）。
3. 实际执行缺陷：负责资源回收的组件（Hypervisor或管理节点）在触发信号后，可能由于调度延迟、资源压力或bug，立即或很快（T_actual << T_grace）执行硬终止（如SIGKILL、直接关闭电源）。
4. 后果：依赖于优雅终止流程的应用（如数据库写检查点、分布式系统状态同步）没有足够时间完成，导致数据损坏或状态不一致。
数学方程：
• 承诺的终止时间：T_termination_promised = T_signal + T_grace。
• 实际的终止时间：T_termination_actual = T_signal + T_actual, where T_actual ~ U(0, T_grace) 或 T_actual = ε (接近0)。
• 数据丢失风险：P(data_loss) ∝ 1 / (T_actual)，当T_actual → 0时，风险→1。

信号发送本身是精确事件，但宽限期T_actual存在巨大不确定性（误差），可能从0到T_grace均匀分布或严重左偏。

分布式系统共识、故障处理、服务等级协议(SLA)的模糊地带。

抢占式（Spot）实例、可中断实例。

T_signal: 中断信号发送时间；T_grace: 承诺的宽限期；T_actual: 实际的宽限期；Flag_interrupt: 中断标志；I: 实例。

实例状态：{运行中， 中断信号已发送， 优雅终止中， 已终止}。信号发送与硬终止可能合并为一个状态迁移。

概率论：T_actual是一个随机变量，其分布未知且对用户不透明。
可靠性工程：优雅终止的成功率 = P(T_actual >= T_required)，其中T_required是应用所需的最小清理时间。
最优化：用户需在成本（使用Spot）和风险（数据丢失）间权衡。

文档承诺“通常在收到中断信号后有两分钟时间”。控制台或元数据显示中断标志。但实例实际存活时间远短于两分钟。

若SLA明确承诺了宽限期但未兑现，构成服务违约。但SLA措辞常为“通常”、“大约”，留有解释空间。

1. 平台资源调度器决定回收实例I。
2. 向实例I的元数据服务写入interruption-notice，并发送SIGTERM（设计）。
3. （缺陷发生点）​ 资源回收线程/进程可能因超时或竞争条件，几乎同时发送了SIGKILL或调用硬终止API。
4. 实例I被强制终止，清理脚本未完成。
5. 用户应用发现数据不一致。
方程：if (recycle_decision(I)) { set_flag(I); send_signal(I, SIGTERM); // 可能被快速跳过 sleep(T_actual); // T_actual ≈ 0 force_terminate(I); }

顺序序列，但步骤3与步骤2的间隔可能极短，近乎并行或倒序（先终止后发信号？）。

对用户而言，处理此问题的复杂度高，需要实现应用层的状态持久化和快速恢复。

操作系统信号处理、进程生命周期、资源调度、容错设计。

P7-0010

云计算/平台商业策略与技术锁定

预留资源灵活性限制

预留实例无法在实例类型、区域、可用区之间灵活转换，利用率低。

商业模型/资源灵活性限制

预留实例RI购买时绑定特定属性A = {实例类型T， 区域R， 可用区Z， 租期L， 付款选项P}。修改函数Modify(RI, A')仅支持A'的有限子集，且可能收取费用或损失价值。

预留实例灵活性限制引擎

1. 属性绑定：用户购买RI时，选择一组属性A。平台创建RI对象，其状态为Active(A)。
2. 修改规则：平台定义可修改的属性集合M ⊆ A。通常M很小，例如可能只允许在同一实例家族内修改大小（T.size），或同一区域内修改可用区（Z）。不允许跨区域（R）、跨实例家族（T.family）或缩短租期（L）。
3. 价值计算：若允许修改，平台重新计算RI的剩余价值V_remaining，并根据新旧属性价格差收取调整费F_adjust。计算过程不透明：V_remaining' = Opaque_Calc(RI, A, A')。
4. 利用率锁定：当用户业务变化，需要不同属性A时，由于Modify(RI, A)不被允许或成本过高，RI利用率U下降，甚至完全闲置。
数学方程：
• RI价值函数：V(RI, t) = f(预付费用， 已使用时间， 小时费率折扣)。
• 修改可行性：Feasible_Modify(RI, A') = True if A' ∈ Allowed_Set(A) else False。
• 修改后成本：Cost_modify = F_adjust + [V(RI_new) - V(RI_old)]，通常V(RI_new)被低估。
• 利用率：U = (实际使用的RI小时数) / (总承诺小时数)。当业务需求偏离A时，U下降。

属性绑定是精确的，但修改规则的灵活性（集合M的大小）与宣传存在“认知误差”。价值计算存在不透明误差。

期权理论（限制了行权条件）、灵活性价值、锁定效应。

所有提供预留实例的云平台。

A: 预留实例属性集{T， R， Z， L， P}；M: 可修改属性子集；V: 预留实例价值；F_adjust: 调整费；U: 利用率。

RI状态：{活跃(A)， 修改请求中， 修改后活跃(A')， 闲置}。业务需求状态：{匹配A， 不匹配A}。

集合论：属性空间A，可修改子空间M。业务需求空间D。当D ∩ M(A) = ∅ 时，锁定发生。
优化：用户购买RI时面临决策：选择A以最大化未来U的期望值E[U]，但未来D不确定。
博弈：平台通过限制M，促使用户为变化的D购买多个RI或转向按需。

营销强调“灵活性”和“节省”。但在修改UI中，很多选项是灰色的。调整费用计算器复杂且结果出人意料。

需审查预留实例的修改条款。如果营销材料夸大灵活性而实际限制严格，可能涉及误导性广告。

1. 用户购买RI，属性A。
2. 一段时间后，业务需求变为A，其中A∉ M(A)。
3. 用户在控制台尝试修改RI属性为A，系统提示“不支持此修改”或显示高昂的调整费用。
4. 用户放弃修改，RI利用率U下降。
5. 用户可能被迫为新需求A购买新的RI或使用按需实例。
方程：if (Modify_Request(RI, A*)) { if (A* in M(A)) { quote = Calculate_Adjustment(RI, A, A*); if (quote.cost_acceptable) Modify(RI, A*); else Decline; } else { Error(“Operation not supported”); } }

顺序序列（购买 -> 需求变化 -> 尝试修改 -> 受阻）。

用户决策复杂度高，需要预测未来需求。修改操作的复杂度O(1)，但成本计算不透明。

金融期权、容量规划、需求预测、云计算计费。

P7-0011

云计算/平台商业策略与技术锁定

系统服务强制注入与资源占用

通过实例元数据服务强制注入平台监控、安全代理，性能开销大且无法移除。

技术锁定/系统控制权剥夺

实例启动时，平台通过cloud-init或镜像预装，将监控代理A_monitor和安全代理A_security作为系统服务或内核模块安装并设置为自动启动。这些代理以高权限运行，占用CPU、内存、网络和I/O资源，且卸载会导致实例功能异常或无法通过平台控制台管理。

强制代理注入引擎

1. 注入机制：实例启动脚本（如cloud-init）从元数据服务获取用户数据user-data，并执行平台预设的脚本S_platform。S_platform包含安装和配置A_monitor和A_security的命令。
2. 持久化与自保护：安装脚本将代理注册为系统服务（如systemd unit），并设置重启策略。代理进程可能监控自身状态，被终止后自动重启。部分代理以内核模块形式存在，难以卸载。
3. 资源占用：代理进程持续运行，消耗资源R_agent = {CPU%, MEM_MB, NET_KBps, IOPS}。在小型实例上，R_agent占比可能显著。
4. 移除后果：如果用户强制停止或卸载代理，平台监控数据缺失，安全合规状态告警，甚至可能触发自动化响应（如隔离实例）。控制台的部分管理功能（如系统日志查看、性能图表）依赖这些代理。
数学方程：
• 实例总资源：R_total = {CPU_total, MEM_total, ...}。
• 代理资源占用：R_agent = f(A_monitor) + g(A_security)。
• 用户可用资源：R_user = R_total - R_agent。
• 管理功能依赖：Console_Function_X_Available = True if A_monitor is running。

资源占用R_agent可以测量，但无法消除。对用户而言，R_user是“误差”，即承诺资源与实际可用资源的差值。

系统特权、资源竞争、隐形成本。

所有提供高级监控、安全或管理功能的云平台实例。

A_monitor, A_security: 监控和安全代理；S_platform: 平台启动脚本；R_total, R_agent, R_user: 总资源、代理占用资源、用户可用资源；user-data: 用户数据。

代理状态：{已安装且运行， 已停止， 已卸载}。实例管理状态：{全功能， 功能受限（代理停止）， 异常（代理卸载）}。

资源分配：R_total被划分为R_agent和R_user，R_agent通常不可配置。
图论：管理功能与代理进程之间存在依赖边。
优化：用户无法优化R_agent，只能接受或选择其他平台。

实例详情页显示CPU/内存使用率，其中包含代理消耗，但未明确区分。文档可能列出代理及其功能，但未强调其资源开销和不可移除性。尝试卸载时收到警告或操作失败。

服务条款可能规定平台有权安装管理软件。但关于资源占用和可移除性的透明度可能不足。若代理开销过大，可能违反关于提供承诺规格的隐含保证。

1. 实例启动，cloud-init运行。
2. cloud-init获取元数据，执行S_platform。
3. S_platform安装并启动A_monitor和A_security。
4. 实例启动完成，用户登录发现额外进程消耗资源。
5. 用户尝试systemctl stop platform-agent。
6. 代理可能自动重启，或停止后控制台监控图表停止更新。
7. 用户尝试卸载软件包，操作可能失败（依赖关系被破坏），或成功后实例被标记为“不兼容”。
方程：on instance_boot: execute(S_platform); S_platform includes: install(A_monitor); install(A_security); start_service(A_monitor); start_service(A_security)

顺序序列（启动->注入->运行）。用户干预是另一个触发序列。

用户移除代理的复杂度高，可能破坏系统。资源开销是恒定复杂度O(1)的持续消耗。

操作系统服务管理、进程监控、cloud-init、资源核算。

P7-0012

云计算/平台商业策略与技术锁定

数据迁移成本壁垒

对虚拟机镜像的导入、导出收取高额数据传输费，即使在同一区域内。

定价模型/数据重力增强

数据传输定价函数C_transfer(Data, Source, Destination)对出口流量（从云平台到互联网）收费P_out。镜像导入通常免费或低价，但导出操作被定义为“出口”，即使目标在同一区域的其他账户或服务，也按P_out收费。

镜像导出税引擎

1. 流量分类：所有从云平台存储服务（如S3， EBS Snapshot）流向互联网或用户本地环境的流量，均被分类为“数据传出”（Data Transfer OUT）。
2. 镜像导出路径：当用户导出镜像时，数据从平台内部存储系统，经过网络边界，到达用户指定的外部目标（如另一个云账户的存储桶、用户本地）。平台计费系统将此路径标记为出口。
3. 高定价：出口单价P_out显著高于入口单价P_in（通常为0）。对于大型镜像（如数百GB），导出成本C_export = Size_Image * P_out可能非常高昂。
4. 锁定效应：高额的导出成本C_export构成了数据迁移的财务壁垒，增加了用户切换到其他平台的转移成本。
数学方程：
• 导出成本：C_export = Size(Image) * P_out。
• 迁移总成本：C_migration = C_export + C_import_other_cloud + C_downtime + ...。
• 锁定强度：Lock_Strength ∝ C_export / C_annual。年费越高，导出成本相对越低，但大镜像的绝对成本仍构成壁垒。

流量计量精确到GB，但定价策略与物理成本（同一数据中心内）的偏离构成“价格误差”。

数据重力、转移成本、定价策略。

所有对数据传出收费的云平台，特别是镜像导出功能。

Size(Image): 镜像大小（GB）；P_out: 数据传出单价（$/GB）；C_export: 导出成本；Source, Destination: 数据的源和目的地（用于计费判断）。

镜像状态：{存在， 导出中， 已导出}。成本状态：{未发生， 已计费}。

最优化：用户决策：迁移 if (Benefits_new_platform - C_migration) > Benefits_current。高C_export降低迁移倾向。
网络流：数据从云平台存储节点到用户指定目的地的流量，被计费系统视为一个有成本的流。

定价页面列出“数据传出”费用。导出镜像时，UI会显示预估时间，但可能不突出显示费用。账单中出现“区域间数据传输”或“到互联网的数据传输”费用项。

定价本身是公开的，通常合法。但若在用户创建镜像时未充分提示未来导出的高成本，可能涉及透明度问题。

1. 用户在控制台选择镜像I，点击“导出”。
2. 系统提示选择目标位置（另一个区域、另一个云、本地）。
3. 用户选择目标（如S3桶）。
4. 系统开始传输数据，从内部存储到目标。
5. 计费系统监控此数据流，累计数据量D_out。
6. 计费周期结束时，费用 = D_out * P_out。
7. 用户收到账单，发现高额导出费用。
方程：C_export = Σ (packet_size) for all packets from cloud_storage to external_destination * P_out

顺序序列（用户操作触发数据传输和计费）。

成本计算复杂度O(1)。用户决策复杂度高，需要权衡迁移收益与成本。

数据传输定价、内容分发网络(CDN)成本、数据迁移工具。

P7-0013

云计算/平台商业策略与技术锁定

性能积分惩罚机制

突发性能实例的CPU积分耗尽后，性能骤降至基准线以下，而非平滑下降。

性能模型/资源分配博弈

突发性能实例分配基准性能P_base和积分桶B。实例以高于P_base的性能P_burst运行时消耗积分，空闲时累积积分。当积分余额B_balance ≤ 0时，实例性能被限制到P_penalty，且P_penalty < P_base。

CPU积分惩罚引擎

1. 积分机制：实例每秒获得I_earn积分（空闲时），以高于P_base的性能P运行每秒消耗I_consume(P)积分。B_balance初始为B_initial，上限为B_max。
2. 积分耗尽判定：实时监控B_balance。当B_balance <= 0时，触发惩罚模式。
3. 惩罚性能：在惩罚模式下，实例CPU性能被限制到P_penalty，一个显著低于P_base的值（例如，P_base可能是CPU的20%，而P_penalty可能是5%）。
4. 恢复延迟：即使负载降低，实例也需要在B_balance恢复到正数后，才能退出惩罚模式，回到P_base。这导致性能曲线出现陡降和缓慢恢复，而非围绕P_base的平滑波动。
数学方程：
• 积分变化：dB_balance/dt = I_earn - I_consume(P(t)), 约束 0 ≤ B_balance ≤ B_max。
• 性能函数：P(t) = P_burst if B_balance > 0 and demand > P_base; P_base if B_balance > 0 and demand ≤ P_base; P_penalty if B_balance ≤ 0。
• 其中 P_penalty < P_base。
• 用户体验：性能从P_burst直接跌至P_penalty，落差巨大。

积分计算和性能限制是精确的，但性能从P_burst到P_penalty的突变与用户预期的“平滑降至P_base”存在巨大“体验误差”。

令牌桶算法、服务质量(QoS)、行为经济学中的损失厌恶。

提供突发性能实例的云平台（如AWS T系列， Azure B系列）。

P_base: 基准CPU性能；P_burst: 突发CPU性能；P_penalty: 惩罚CPU性能；B_balance: 当前积分余额；B_initial, B_max: 初始和最大积分；I_earn: 积分赚取速率；I_consume(P): 积分消耗函数。

实例性能状态：{突发模式(P_burst)， 基准模式(P_base)， 惩罚模式(P_penalty)}。积分桶状态：{有余额， 耗尽}。

控制理论：具有滞回和饱和的非线性控制系统。当B_balance<=0时，系统进入深度负反馈状态（P_penalty）。
微分方程：B_balance的动态变化如上所述。
最优化：用户需预测负载并选择实例规格，以避免进入惩罚区。

文档说明积分机制和基准性能。但惩罚

P7-0013

云计算/平台商业策略与技术锁定

性能积分惩罚机制

突发性能实例的CPU积分耗尽后，性能骤降至基准线以下，而非平滑下降。

性能模型/资源分配博弈

突发性能实例分配基准性能P_base和积分桶B。实例以高于P_base的性能P_burst运行时消耗积分，空闲时累积积分。当积分余额B_balance ≤ 0时，实例性能被限制到P_penalty，且P_penalty < P_base。

CPU积分惩罚引擎

1. 积分机制：实例每秒获得I_earn积分（空闲时），以高于P_base的性能P运行每秒消耗I_consume(P)积分。B_balance初始为B_initial，上限为B_max。
2. 积分耗尽判定：实时监控B_balance。当B_balance <= 0时，触发惩罚模式。
3. 惩罚性能：在惩罚模式下，实例CPU性能被限制到P_penalty，一个显著低于P_base的值（例如，P_base可能是CPU的20%，而P_penalty可能是5%）。
4. 恢复延迟：即使负载降低，实例也需要在B_balance恢复到正数后，才能退出惩罚模式，回到P_base。这导致性能曲线出现陡降和缓慢恢复，而非围绕P_base的平滑波动。
数学方程：
• 积分变化：dB_balance/dt = I_earn - I_consume(P(t))，约束 0 ≤ B_balance ≤ B_max。
• 性能函数：P(t) = P_burst if B_balance > 0 and demand > P_base; P_base if B_balance > 0 and demand ≤ P_base; P_penalty if B_balance ≤ 0。
• 其中 P_penalty < P_base。
• 用户体验：性能从P_burst直接跌至P_penalty，落差巨大。

积分计算和性能限制是精确的，但性能从P_burst到P_penalty的突变与用户预期的“平滑降至P_base”存在巨大“体验误差”。

令牌桶算法、服务质量(QoS)、行为经济学中的损失厌恶。

提供突发性能实例的云平台（如AWS T系列， Azure B系列）。

P_base: 基准CPU性能；P_burst: 突发CPU性能；P_penalty: 惩罚CPU性能；B_balance: 当前积分余额；B_initial, B_max: 初始和最大积分；I_earn: 积分赚取速率；I_consume(P): 积分消耗函数。

实例性能状态：{突发模式(P_burst)， 基准模式(P_base)， 惩罚模式(P_penalty)}。积分桶状态：{有余额， 耗尽}。

控制理论：具有滞回和饱和的非线性控制系统。当B_balance<=0时，系统进入深度负反馈状态（P_penalty）。
微分方程：B_balance的动态变化如上所述。
最优化：用户需预测负载并选择实例规格，以避免进入惩罚区。

文档说明积分机制和基准性能。但惩罚性能P_penalty常被弱化或隐藏。当性能骤降时，用户监控发现CPU利用率极低但应用卡顿。

服务规格描述中若未明确说明惩罚性能低于基准性能，可能构成误导。若SLA仅适用于实例“运行”状态，而不保障最低性能，则难以追责。

1. 实例启动，B_balance = B_initial。
2. 负载升高，P(t) > P_base，消耗积分，dB/dt < 0。
3. 当B_balance <= 0时，系统立即将CPU配额限制为P_penalty。
4. 应用性能骤降。
5. 即使负载降至P_base以下，由于B_balance仍<=0，性能保持P_penalty。
6. 空闲一段时间后，积分累积，B_balance > 0，性能恢复至P_base或P_burst。
方程：if (B_balance <= 0) { set_cpu_quota(P_penalty); } else { set_cpu_quota(min(P_burst, demand)); }

顺序序列（积分消耗->耗尽->惩罚->恢复）。惩罚的进入是突变的，恢复是渐进的。

状态监控和切换复杂度O(1)。用户性能优化的复杂度高，需精确建模负载和积分。

操作系统CPU调度（CFS）、服务质量(QoS)、容量规划、性能基准测试。

P7-0014

云计算/平台商业策略与技术锁定

实例升级路径控制

特定实例类型只能升级到平台指定的新类型，无法选择更优替代方案。

产品策略/升级锁定

平台定义实例家族F，包含代际G1, G2, ...。当用户将实例类型从T_old (∈ F, G1) 升级时，系统只允许升级到预定义的T_new (∈ F, G2)。即使存在其他家族F‘的性能/价格更优实例T_alt，升级路径被阻断。

实例升级路径锁定引擎

1. 路径定义：平台维护一个升级关系图R，其中顶点是实例类型，有向边(T_a, T_b)表示允许从T_a升级到T_b。通常R是一个树状或链状结构，而非完全图。
2. 升级验证：用户发起升级请求Upgrade(Instance_I, Target_T)。系统验证(Current_Type(I)， Target_T) ∈ R。若不在R中，请求被拒绝。
3. 商业导向：关系图R的设计通常引导用户升级到平台当前主推或利润率更高的实例类型，而非客观最优。
4. 机会成本：用户无法利用其他家族可能更合适的实例（如计算优化型转为内存优化型），导致资源浪费或性能不佳。
数学方程：
• 实例类型空间：Τ。
• 允许的升级关系：R ⊆ Τ × Τ，通常非对称、非完全。
• 升级函数：Upgrade(I, T_target) = Success if (Type(I), T_target) ∈ R else Failure。
• 用户最优选择：T_optimal = argmax_{t in Τ} Value(Perf(t)， Price(t), 业务需求)。但常因T_optimal ∉ {t

(Type(I), t) ∈ R}而不可达。

升级操作的成功/失败是确定的。但用户获得的价值与最优价值之间存在“机会误差”。

路径依赖、转换成本、产品线管理。

云控制台或API中的实例修改/升级功能。

Τ: 所有实例类型集合；R: 允许的升级关系图；Type(I): 实例I的当前类型；T_target: 目标类型；T_optimal: 对用户最优的类型。

实例类型状态：{当前类型T_old， 可升级类型集 {T

(T_old, T) ∈ R}， 不可升级类型集}。

图论：升级关系R是一个有向图。用户被限制在从当前类型节点出发的可达子图中选择。
集合论：可选升级目标是当前类型节点的出边邻居集合。
最优化：用户的最优化问题定义域被R限制，可能找不到全局最优解。

控制台修改实例类型界面，下拉列表中只显示有限的几个选项。文档可能列出“推荐升级路径”。尝试通过API升级到列表外的类型会报错。

属于平台产品策略自由。但如果平台宣称“灵活升级”而实际限制严格，可能产生误导。

1. 用户选择实例I，发起修改实例类型请求。
2. 系统查询R，找出所有T满足 (Type(I)， T) ∈ R，生成列表L。
3. 向用户展示L（或在API中只接受L中的类型）。
4. 用户选择T_new ∈ L，升级成功。
5. 用户尝试通过其他方式（如工单、特定API参数）请求升级到T_alt ∉ L，被系统拒绝。
方程：`Allowed_Targets = {t in Τ

(Type(I), t) in R}; if (T_target in Allowed_Targets) then migrate(I, T_target) else error()`

P7-0015

云计算/平台商业策略与技术锁定

临时存储风险告知不足

本地SSD/HDD存储的数据在实例终止时永久丢失，但平台不提供充分警告。

风险模型/信息不对称

实例配置中包含本地存储卷V_local，其生命周期与实例绑定。在实例终止操作Terminate(Instance)的确认流程中，关于V_local数据丢失的警告信息W不明显（如小字体、无二次确认）。用户容易忽略并误操作。

本地存储风险弱化引擎

1. 存储关联：创建实例时，若附加了本地存储卷V_local，平台建立绑定关系B(Instance, V_local)。
2. 终止操作设计：用户触发终止操作。确认对话框显示文本T，其中包含关于删除弹性卷、弹性IP的警告，但关于V_local的警告信息W_local可能被折叠、置于末尾或用不显眼的图标表示。
3. 信息处理：用户注意力有限，容易关注主要警告（如“删除实例”），而忽略W_local。决策函数D_user基于感知到的风险R_perceived，而R_perceived << R_actual (实际数据丢失风险)。
4. 后果：用户确认终止，实例和V_local被永久删除，关键数据丢失。
数学方程：
• 风险实际值：R_actual = Value(Data_on_V_local)。
• 风险感知值：R_perceived = f(Salience(W_local), User_Expertise)。其中显著度Salience(W_local)由平台设计决定，通常较低。
• 用户决策：Proceed_Terminate = True if (User_Intention_Weight > R_perceived)。由于R_perceived小，易成立。
• 平台责任规避：通过显示W_local（无论多不明显）声称已履行告知义务。

数据丢失的后果是100%的，但风险告知的有效性（用户感知率）存在巨大误差。

行为经济学（有限注意力、决策疲劳）、人机交互(HCI)、信息披露。

提供本地实例存储（Instance Store, Local SSD）的实例创建和终止操作。

V_local: 本地存储卷；B: 绑定关系；W_local: 关于V_local数据丢失的警告信息；Salience(): 信息显著度函数；R_actual, R_perceived: 实际与感知风险。

实例状态：{运行中(有V_local)， 终止请求(确认对话框)， 已终止(V_local丢失)}。用户认知状态：{未察觉风险， 已察觉风险}。

概率：数据丢失事件概率P(loss) = P(User_Proceeds_Terminate

V_local exists) * 1。平台通过设计影响P(User_Proceeds...)。
信息论：警告信息W_local的信息量可能足够，但传递到用户的有效信息因呈现方式而衰减。
最优化：平台在“用户体验”（简化流程）和“风险规避”间权衡，常倾向于前者。

终止实例时，复选框“删除关联的弹性存储卷”很醒目，但“连接到该实例的本地存储将被删除”这行字位于下方小字体描述中。

可能违反消费者保护法中关于“清晰和显著”披露重要风险的规定。若用户能证明因设计缺陷导致未获有效告知，平台可能需承担部分责任。

1. 用户对实例I（挂载了V_local）点击“终止”。
2. 系统弹出确认对话框，标题为“终止实例？”，列出警告项List = [“实例将停止”， “弹性IP将解绑”， “弹性卷EBS将被删除”(如果附加了)， (小字)“任何实例存储卷上的数据将丢失”]。
3. 用户快速浏览，勾选“我确认...”复选框，点击“确认”。
4. 系统执行Terminate(I)，并销毁V_local。
方程：if (user_confirms) { delete(I); delete(V_local); } // 其中user_confirms的决策基于incomplete information

顺序序列（用户操作->系统提示->用户确认->系统执行）。关键风险信息在提示步骤中呈现不足。

流程复杂度O(1)。用户恢复数据的复杂度无限大。

P7-0016

云计算/平台商业策略与技术锁定

硬件拓扑抽象与隔离

不允许用户自定义CPU拓扑（如NUMA节点分配），影响高性能计算应用。

技术锁定/性能隔离

平台将物理服务器的CPU和内存资源虚拟化后，以统一的vCPU和内存资源形式呈现。用户无法感知或指定虚拟机的NUMA（非统一内存访问）亲和性。虚拟机可能被跨NUMA节点调度，导致内存访问延迟不一致，性能下降。

CPU拓扑隐藏与调度引擎

1. 资源抽象：物理服务器有N个NUMA节点。平台将总CPU核C_total和总内存M_total抽象为资源池，创建虚拟机时从中分配vCPU和内存，不暴露NUMA边界。
2. 调度策略：虚拟机调度器S将虚拟机放置到物理核心上，其策略可能忽略NUMA亲和性以追求资源利用率最大化。虚拟机获得的vCPU可能来自不同NUMA节点，其内存也可能被分配到非本地节点。
3. 性能影响：对于内存密集型、延迟敏感型应用（如HPC， 大型数据库），跨NUMA节点访问内存的延迟显著高于本地访问，导致应用性能P_actual < P_expected。
4. 控制缺失：平台不提供API或配置让用户指定NUMA策略（如固定vCPU到物理核范围、内存大页分配在本地节点），剥夺了性能调优的关键手段。
数学方程：
• NUMA延迟矩阵：L[i][j]表示从节点i访问节点j内存的延迟，i=j时L_local最小。
• 虚拟机放置：Placement(VM) = {(vCPU_p, core_c), (Mem_m, node_n)}，其中核心c和节点n的关系由平台决定，对用户未知。
• 平均访问延迟：L_avg(VM) = (1/M) Σ Σ Access_Pattern * L[core_of(vCPU)][node_of(Mem)]，由于缺乏亲和性，L_avg高。
• 性能函数：P_actual = g(L_avg)，通常g是减函数。

性能损失比例因应用而异，难以量化但确实存在。用户对底层拓扑的认知为0，存在“信息误差”。

非统一内存访问架构、虚拟化开销、资源调度。

所有通用计算实例，特别是大规格虚拟机，用于高性能计算、数据库等场景。

N: 物理机NUMA节点数；L[][]: NUMA延迟矩阵；Placement(): 虚拟机在物理硬件的放置映射；Access_Pattern: 应用的内存访问模式。

虚拟机调度状态：{未调度， 已调度(跨NUMA)， 已调度(NUMA对齐)-理想情况}。应用性能状态：{预期性能， 实际性能(受损)}。

图论：物理拓扑是一个多部图。虚拟机资源分配是图上的一个子图匹配问题，平台求解时不考虑延迟权重最小化。
优化：平台优化资源利用率，用户希望优化延迟，两者目标冲突。
组合数学：将vCPU和内存分配到物理位置是一个组合分配问题。

实例规格表只列出vCPU和内存，无NUMA信息。用户请求获得NUMA视图或控制权时，客服或文档回应“由系统自动优化，不支持自定义”。

属于平台实现细节，通常不构成服务承诺。但若用户为高性能场景付费，却无法获得相应架构控制权，可能引发关于服务是否“适销”的争议。

1. 用户启动一个大规格实例（如32vCPU， 128GiB）。
2. 平台调度器选择一台物理主机，其上有2个NUMA节点，各16核64GiB。
3. 调度器为虚拟机分配0-15, 20-35号物理核心（跨节点），内存从两个节点各分配64GiB。
4. 虚拟机操作系统看到32个连续的vCPU和连续内存空间。
5. 应用运行，内存访问频繁跨节点，性能不佳。
6. 用户尝试通过OS工具（如numactl）调优，但因vCPU与物理核映射不透明，效果有限。
方程：L_avg = (∑_i ∑_j L[Node(vCPU_i)][Node(Mem_j)] * AccessRate_ij) / TotalAccess

并行序列：应用运行与平台调度是两个独立过程。用户性能调优尝试是在结果发生后。

平台调度复杂度是其内部问题。用户诊断和缓解性能问题的复杂度高。

计算机体系结构（NUMA）、虚拟化技术、操作系统调度、性能剖析工具。

P7-0017

云计算/平台商业策略与技术锁定

维护操作的服务中断

平台进行维护性实时迁移时不提供足够通知，且迁移期间网络连接中断。

运维模型/服务可用性博弈

平台计划对底层物理主机进行维护（如固件升级、硬件更换）。计划对虚拟机进行实时迁移（Live Migration）。但迁移事件通知N发送时间T_notice过晚（如<5分钟），或迁移执行期间网络连接会短暂中断Δt_network（如几秒），导致有状态连接断开。

强制实时迁移引擎

1. 维护计划：平台检测到物理主机H需要维护，计划在时间T_maintenance开始。为减少影响，对H上的虚拟机采用实时迁移。
2. 通知缺陷：通知N（如事件日志、邮件）可能在T_maintenance前不久（如5分钟）才生成。对于需要复杂准备（如 draining connections）的应用，时间不足。
3. 迁移执行：执行实时迁移。尽管内存和CPU状态可迁移，但网络虚拟化层面可能涉及虚拟网卡或虚拟交换机的重新绑定，导致网络连接中断Δt_network > 0。
4. 影响：用户应用遇到短暂但突然的网络断开，TCP连接重置，WebSocket断开，事务可能失败。平台可能将“实例运行”状态等同于“服务可用”，忽略网络中断。
数学方程：
• 通知提前量：ΔT_notice = T_maintenance - T_notice。通常ΔT_notice很小。
• 服务中断时长：Δt_outage = Δt_network。虽然Δt_network短，但非零。
• 应用受影响概率：P_affected = f(应用对网络中断的敏感性)。对于有状态服务，P_affected可能很高。
• 平台SLA计算：平台可能认为只要实例未重启，就不算停机时间，从而SLA不受影响。

迁移本身成功率高，但通知时间ΔT_notice和网络中断Δt_network与用户期望（无感迁移）存在“体验误差”。

高可用性设计、计划内维护、服务等级协议(SLA)的度量。

任何可能对底层硬件进行维护的云平台。

T_maintenance: 计划维护时间；T_notice: 通知时间；ΔT_notice: 通知提前量；Δt_network: 迁移期间网络中断时长；H: 物理主机。

实例迁移状态：{运行于H， 迁移中， 运行于H'}。网络连接状态：{连通， 中断， 恢复}。

时间序列：在时间点T_maintenance发生状态迁移事件。
可靠性工程：服务可用性A = 1 - (总中断时间/总时间)。平台可能将Δt_network排除在“中断时间”外。
最优化：平台在维护效率与用户影响间权衡，常优先前者。

控制台“事件”页面或健康面板可能显示计划事件，但用户不常查看。邮件通知可能被归类为“非紧急”。迁移期间的网络中断在文档中可能以“可能发生短暂网络闪断”轻描淡写。

SLA通常定义“服务不可用”的严格条件（如实例状态为“停止”）。网络闪断可能不满足该条件，用户难以索赔。但若未提供“合理”通知，可能违反服务条款。

1. 平台检测主机H需维护，计划T_maintenance。
2. 在T_notice = T_maintenance - 5min 创建事件通知N。
3. 用户可能未及时看到N。
4. 在T_maintenance，平台对H上实例发起实时迁移。
5. 迁移过程中，虚拟网络设备切换，导致实例网络流量丢失约2秒。
6. 应用连接断开。
7. 迁移完成，实例在新主机H'运行，网络恢复。
方程：if (t == T_maintenance) { for vm on H: live_migrate(vm); // includes network_disconnect(vm, duration=Δt_network) }

顺序序列（计划->通知->执行）。对用户应用而言，网络中断是乱序的突发故障事件。

迁移操作复杂度高（平台负责）。用户应对复杂度高，需实现应用层重连逻辑。

实时迁移技术、虚拟网络、高可用架构、监控与告警。

P7-0018

云计算/平台商业策略与技术锁定

启动依赖与单点故障

实例启动依赖平台内部服务（如元数据服务），这些服务故障导致所有实例无法启动。

系统设计/依赖风险

实例启动过程P_boot包含必须步骤S_meta：从实例元数据服务(IMDS)获取配置（如SSH密钥、用户数据）。IMDS是一个区域性或全局性服务。若IMDS不可用，S_meta步骤失败，导致P_boot整体失败，无论底层计算资源是否充足。

实例启动单点依赖引擎

1. 启动链定义：实例启动流程P_boot = [S1, S2, ..., S_meta, ..., Sn]。S_meta是获取动态配置的关键步骤。
2. 依赖服务：S_meta通过网络调用依赖外部服务IMDS。IMDS的可用性A_imds < 1。
3. 故障传播：当IMDS故障（A_imds = 0）时，所有尝试执行S_meta的实例启动请求都会失败，失败率P_failure_boot = 1，即使计算、存储、网络资源均正常。
4. 影响范围：这导致区域性的实例启动能力瘫痪，影响新实例创建、自动伸缩、故障恢复等关键运维操作。
数学方程：
• IMDS可用性：A_imds。
• 实例启动成功率：P_success_boot = A_imds * (1 - P_other_failures)。当A_imds → 0时，P_success_boot → 0。
• 启动时间：T_boot = T_other + T_meta，其中T_meta受IMDS响应时间影响，故障时T_meta → ∞（超时）。
• 系统脆弱性：整个实例启动能力的脆弱性V ∝ 1 / A_imds。

IMDS可用性A_imds通常很高（如99.99%），但一旦故障，影响是100%的，即“误差”是灾难性的。

系统可靠性（串联系统）、单点故障、微服务架构的依赖风险。

任何实例启动依赖元数据或配置服务的云平台。

P_boot: 实例启动流程；S_meta: 依赖元数据服务的步骤；IMDS: 实例元数据服务；A_imds: IMDS可用性；P_success_boot: 实例启动成功率。

实例启动状态：{启动中(前置步骤)， 等待元数据， 启动成功， 启动失败(元数据超时)}。IMDS服务状态：{健康， 故障}。

可靠性工程：启动流程是一个串联系统，其整体可靠性是各步骤可靠性的乘积。S_meta成为最弱链路。
概率：P(启动失败) = 1 - A_imds * (1 - p)，其中p是其他步骤的失败概率，通常很小。
图论：实例启动流程是有向无环图(DAG)，其中包含对IMDS节点的外部依赖边。

当实例启动失败时，错误信息可能为“等待元数据超时”或“实例状态停留在’pending’”。平台健康状态板可能显示“实例创建服务降级”。

SLA通常针对单个实例的运行可用性，而非创建能力。因此，即使区域性实例创建功能瘫痪，也可能不违反SLA。但这暴露了架构风险。

1. 用户请求创建实例。
2. 平台分配计算、存储、网络资源成功。
3. 实例开始引导，执行cloud-init等初始化程序。
4. cloud-init尝试访问IMDS获取user-data或凭证。
5. 此时IMDS服务故障，请求超时或失败。
6. cloud-init步骤失败，实例操作系统可能无法完成配置，或启动后无法加入集群。
7. 实例启动超时，被平台标记为“不健康”并终止。
方程：if (IMDS.status != healthy) { for each booting instance: instance.boot_status = stuck; }

顺序序列，但大量实例的启动尝试在S_meta步骤形成并发请求，压垮或依赖于IMDS。

启动单个实例的复杂度O(1)，但依赖服务故障使其变为O(∞)(无限重试)。

微服务架构、服务发现、容错设计、系统初始化（cloud-init）。

P7-0019

云计算/平台商业策略与技术锁定

资源预留的碎片化

资源预留（如IP地址、存储）分散在不同可用区，无法合并使用，造成浪费。

资源管理/碎片化锁定

用户在不同可用区AZ1， AZ2， ... 创建了子网、IP地址、存储卷等资源R。这些资源被绑定到特定的AZ，无法跨AZ合并、迁移或统一分配。当用户业务重心转移或某个AZ资源不足时，其他AZ的预留资源被闲置，形成碎片。

资源分区碎片化引擎

1. AZ绑定：平台设计上，许多资源R具有AZ属性，R.az = AZ_x。创建后不可更改。
2. 需求分布变化：用户业务对资源的需求D(t)在AZ间分布可能变化。例如，初始需求D_az1高，用户预留了大量R在AZ1。后期需求转向AZ2，但R_az1无法迁移到AZ2。
3. 资源僵化：预留的资源R_az1成为沉没成本。用户要么在AZ2创建新资源（额外开销），要么忍受AZ1的次优部署（如更高延迟）。
4. 利用率下降：总体资源利用率U = (∑az Used(R_az)) / (∑az Reserved(R_az))。由于R_az无法调剂，当需求分布与预留分布不匹配时，U下降。
数学方程：
• 资源向量：R = (R_az1, R_az2, ..., R_azN)。
• 需求向量：D(t) = (D_az1(t), D_az2(t), ..., D_azN(t))。
• 利用约束：Used(R_azi) ≤ R_azi，且无法将R_azi调配给D_azj (i≠j)。
• 浪费：Waste = Σ_i max(0, R_azi - D_azi(t))。当D(t)变化时，Waste可能增加。
• 转移成本：用户若要改变R的分布，需删除旧资源（可能丢失配置）并创建新资源，产生成本C_recreate。

资源计量精确，但资源僵化导致的浪费Waste是动态的、难以预测的“效率误差”。

资源分配与调度、库存管理、沉没成本。

所有具有可用区概念的云资源，如子网、弹性IP（某些区域）、特定类型的存储卷。

R_azi: 在可用区i预留的资源量；D_azi(t): 在时间t，可用区i的资源需求量；Waste: 总浪费量；C_recreate: 重建资源成本。

资源状态：{已预留(AZ_i)， 使用中， 闲置}。业务需求状态：{与预留匹配， 与预留不匹配}。

线性代数：资源向量R和需求向量D。利用率问题是在约束Used_i ≤ R_i下的优化问题，且R_i不可转移。
最优化：用户需在初始预留时预测未来的D(t)分布，是一个不确定条件下的决策问题。
库存理论：R是多地点的库存，面临需求不确定性和转运不灵活性。

控制台显示资源及其所属可用区。删除资源时可能会警告“此操作不可逆”。当用户尝试将弹性IP从一个AZ关联到另一个AZ的实例时，会失败并提示“资源不在同一可用区”。

属于平台架构设计，通常合法。但若平台宣传“灵活”而资源实际上高度僵化，可能存在宣传与事实不符。

1. 用户在AZ1创建了子网Subnet1和10个弹性IP EIPs_az1，用于主要业务。
2. 业务扩展，需要在AZ2部署以降低延迟给另一地区用户。
3. 用户尝试将EIPs_az1关联到AZ2的实例，失败。
4. 用户在AZ2申请新的EIPs_az2，产生新费用。
5. AZ1的EIPs_az1和Subnet1容量闲置，但可能仍产生少量费用或占用配额。
方程：if (Resource.az != Instance.az) { Attach(Resource, Instance) = Failure; }

并行序列：不同AZ的资源独立管理。业务需求变化是随时间序列。

管理复杂度O(N)，N为AZ数量。优化资源分配的复杂度高，需预测和规划。

网络架构、负载均衡、容灾设计、资源预留规划。

P7-0020

云计算/平台商业策略与技术锁定

生命周期钩子可靠性缺陷

生命周期挂钩执行时间过长或失败时不提供重试机制，导致自动伸缩失败。

系统设计/可靠性陷阱

自动伸缩组(ASG)生命周期挂钩Hook配置了一个超时时间T_timeout和结果通知。当Hook执行脚本运行时间T_exec > T_timeout，或脚本以非零退出码失败时，ASG默认行为是放弃挂钩并继续生命周期操作（如终止实例），而不进行重试。

生命周期挂钩单次尝试引擎

1. 挂钩执行：当ASG触发生命周期动作（如启动新实例后launching，终止实例前terminating），会调用用户配置的Hook脚本。
2. 超时机制：平台为Hook执行设置一个固定的超时T_timeout（如300秒）。如果Hook脚本在T_timeout内未返回成功信号，则视为超时。
3. 失败处理：无论Hook失败（返回错误码）还是超时，平台的默认策略都是记录事件并继续执行原始的生命周期动作。不提供自动重试机制。
4. 后果：对于执行时间不确定的Hook（如安装大型软件、等待外部依赖），极易超时，导致实例未完成配置就被标记为“健康”投入服务，或在未完成清理时被终止。
数学方程：
• Hook执行时间：T_exec ~ Distribution (可能长尾)。
• 成功条件：Hook_Success = (Exit_Code == 0) AND (T_exec ≤ T_timeout)。
• ASG决策：IF Hook_Success THEN Proceed_With_Next_Step ELSE { Log_Failure; Proceed_With_Original_Action } // 无重试。
• 系统可靠性：ASG动作的整体成功率P_success_asg = P(Hook_Success) * P(other)。由于无重试，P(Hook_Success)低则整体成功率低。

Hook成功与否是确定的，但因其脆弱性导致的整体流程失败概率被放大，存在“可靠性误差”。

分布式事务、最终一致性、容错设计。

自动伸缩组的生命周期挂钩（实例启动和终止）。

Hook: 生命周期挂钩脚本；T_timeout: 挂钩执行超时时间；T_exec: 实际执行时间；Exit_Code: 脚本退出码；P_success_asg: ASG动作成功率。

挂钩执行状态：{等待执行， 执行中， 成功， 失败， 超时}。ASG动作状态：{等待挂钩， 挂钩完成(成功/失败)， 继续动作}。

概率论：P(Hook_Success) = P(T_exec ≤ T_timeout) * P(Exit_Code=0)。无重试下，这是最终成功率。
可靠性工程：挂钩是一个串联的可靠性环节。无重试相当于没有冗余。
最优化：用户需优化脚本使其在T_timeout内必然成功，这通常很困难。

控制台ASG配置页面可以设置挂钩和超时。文档说明超时和失败行为。当挂钩失败时，ASG活动历史中会记录一条失败事件，但伸缩流程继续。

属于服务实现细节。但如果文档未清晰说明无重试机制及其影响，可能使用户对自动化可靠性产生误解。

1. ASG需要扩容，启动新实例I。
2. 实例进入“Pending:Wait”状态，执行Launching类型挂钩脚本H。
3. 脚本H执行，例如从外部源下载软件包，网络慢导致T_exec增长。
4. 当T_exec > T_timeout（如300秒）时，平台标记挂钩为“超时”。
5. ASG不再等待，将实例I状态直接转为“InService”，尽管H未完成。
6. 负载均衡器将流量导入I，但I上应用未安装完成，请求失败。
方程：if (hook_start_time + T_timeout < now) { hook_status = timeout; resume_lifecycle_action(); }

顺序序列，但有一个并行的超时计时器。超时事件会中断顺序流程。

挂钩执行复杂度由用户脚本决定。用户实现可靠初始化的复杂度高，需外部状态协调。

配置管理、持续部署、弹性伸缩、监控与自愈。

P7-0021

云计算/平台商业策略与技术锁定

系统内核模块白名单

禁止用户安装自定义内核模块，即使有合法需求（如特定硬件驱动）。

技术锁定/系统安全强制

平台通过安全策略（如SELinux， 内核模块签名强制）和配置，将内核锁定在“模块签名验证”模式，且只信任平台预置的签名密钥。用户编译或安装的第三方内核模块无法加载。

内核模块白名单引擎

1. 启动策略：实例内核启动参数设置module.sig_enforce=1，要求所有加载的内核模块必须经过数字签名验证。
2. 密钥控制：平台将自有的签名公钥嵌入内核或初始RAM磁盘。不提供机制让用户添加自己的签名密钥。
3. 模块加载拦截：当用户尝试insmod或modprobe加载自定义模块时，内核校验模块签名，与平台密钥不匹配，拒绝加载并记录错误。
4. 需求压制：用户无法安装特定硬件（如新型USB设备、特定网卡）的驱动、性能调优模块或安全监控工具，限制了实例的定制能力和功能扩展。
数学方程：
• 模块签名验证：Verify_Signature(Module, K_public_platform) = True/False。
• 加载函数：Load_Module(Module) = Success if Verify_Signature(Module, K_public_platform) else Failure。
• 用户能力集：Capability_user = {标准内核功能} ，不包含{通过自定义模块扩展的功能}。

验证机制100%有效，用户自定义模块加载成功率为0。功能缺失是绝对的。

操作系统安全、可信计算、供应商控制。

所有注重“安全合规”或使用特定虚拟化技术的云实例。

Module: 内核模块文件；K_public_platform: 平台的内核模块签名公钥；module.sig_enforce: 内核启动参数。

内核状态：{模块签名强制开启}。模块加载状态：{尝试加载， 验证失败， 加载被拒绝}。

密码学：基于非对称加密的签名验证。
逻辑：IF (module.sig_enforce) THEN require valid signature。
集合论：可加载模块集合是平台已签名模块集合的子集。

用户尝试加载模块时，系统日志显示“Required key not available”或“Operation not permitted”。文档或知识库文章声明“不支持自定义内核模块以确保安全”。

通常被视为安全加固措施，属于平台合理的安全策略。但如果用户因业务需求（如特定硬件支持）必须加载模块，且平台未提供替代方案，可能构成不合理的限制。

1. 用户编译或获取了一个内核模块mymodule.ko。
2. 用户运行sudo insmod mymodule.ko。
3. 内核检查mymodule.ko的签名。
4. 由于该模块由用户编译，未用平台私钥签名，验证失败。
5. 内核返回错误“Module signature verification failed”，拒绝加载。
方程：if (verify_signature(module, platform_key) == false) { return -EKEYREJECTED; }

顺序序列（用户命令触发内核验证）。

用户绕过此限制的复杂度极高（需自定义内核）。

Linux内核安全模块、数字签名、设备驱动开发。

P7-0022

云计算/平台商业策略与技术锁定

安全更新强制重启策略

安全更新强制在业务高峰时段重启实例，不提供推迟选项。

运维模型/业务连续性博弈

平台发布主机级安全更新U。更新需要重启底层物理机或虚拟机。平台安排的重启时间窗口W_reboot是固定的，可能落在用户业务的峰值时段T_peak。用户无法将重启推迟到自己的维护窗口W_maintenance。

强制安全更新调度引擎

1. 更新发布：平台识别安全漏洞，生成补丁U。规划在时间窗口W_platform = [T_start, T_end]内分批重启受影响实例。
2. 调度不灵活：W_platform是平台单方面决定的，可能基于其运维便利性或全球统一时间，未考虑不同用户、不同区域的业务周期差异。
3. 用户影响：如果W_platform与用户的T_peak重叠，重启将导致业务中断，损失Revenue_loss。用户希望将重启推迟到自己的W_maintenance，但平台不允许或机制复杂（如需工单申请，批准不确定）。
4. 风险转移：平台通过强制重启履行了其安全责任，但将业务中断风险转移给了用户。
数学方程：
• 平台重启窗口：W_platform。
• 用户业务高峰：T_peak ⊆ [0, 24h] (每日)。
• 用户维护窗口：W_maintenance。
• 冲突概率：P_conflict =

W_platform ∩ T_peak

/

W_platform

。平台调度可能使P_conflict较高。
• 用户损失：Loss_user = Revenue_loss if W_platform ∩ T_peak ≠ ∅。
• 平台风险规避：平台优先满足其安全合规时间线。

重启事件是确定的，但发生时间与用户业务周期的冲突是“时间误差”，导致损失。

风险管理、调度理论、责任划分。

需要主机级安全更新的云平台（如应对Meltdown, Spectre等CPU漏洞）。

W_platform: 平台强制重启时间窗口；T_peak: 用户业务高峰时段；W_maintenance: 用户维护窗口；U: 安全更新；Revenue_loss: 业务中断造成的收入损失。

实例更新状态：{待更新， 计划重启时间已安排， 已重启}。用户业务状态：{高峰， 低谷}。

调度理论：在多个用户共享的平台上进行批处理作业（重启）调度，目标函数是平台运维效率，而非最小化用户影响。
集合论：时间窗口的交集运算。
博弈：平台与用户之间关于风险和时间控制的博弈。

通过“计划事件”或健康面板通知用户重启时间。通知中写明“此时间无法更改”或“请联系支持协商”。用户请求推迟时，客服回应“为保障安全，需按计划执行”。

服务条款可能赋予平台进行必要维护的权利。但“必要”的定义和“合理通知”的界定可能存在争议。若强制重启造成重大损失，用户可能主张平台未尽合理注意义务。

P7-0023

云计算/平台商业策略与技术锁定

DNS解析服务劫持

实例内部DNS解析强制指向平台DNS，无法使用自定义DNS服务器。

技术锁定/网络服务控制

实例的网络配置（如/etc/resolv.conf）在启动时被平台（通过DHCP或cloud-init）强制设置为指向平台内部的DNS服务器IP（如169.254.169.253）。用户修改此配置后，重启网络服务或实例后会被重置。

DNS强制重写引擎

1. 网络配置注入：实例启动时，DHCP服务器或cloud-init脚本提供网络配置，其中包括DNS服务器地址DNS_platform。
2. 配置文件写入：该配置被写入/etc/resolv.conf，并可能设置文件属性为不可变（immutable），或由守护进程监控并恢复。
3. 用户修改失效：用户手动修改/etc/resolv.conf，或通过netplan/systemd-resolved配置自定义DNS。当实例重启、网络服务重启或平台代理运行时，修改被覆盖，恢复为DNS_platform。
4. 控制后果：用户无法使用企业内部DNS、公共DNS（如8.8.8.8）或第三方DNS服务进行域名解析，限制了网络策略（如内部域名解析、特定地理路由）。
数学方程：
• 平台DNS设置：DNS_platform。
• 用户期望DNS：DNS_user。
• 实际生效DNS：DNS_effective(t)。通常，DNS_effective(t) = DNS_platform，除了用户修改后到下次平台重写前的短暂窗口期。
• 重置函数：After event E (reboot, network restart)， Write(/etc/resolv.conf, DNS_platform)。
• 用户控制度：用户对DNS_effective的稳态控制度 ≈ 0。

DNS配置在多数时间被精确控制为平台设定值。用户自定义配置的持久性为0。

网络命名与寻址、DHCP协议、系统配置管理。

所有云平台的默认网络配置。

DNS_platform: 平台提供的DNS服务器地址；DNS_user: 用户希望使用的DNS服务器地址；/etc/resolv.conf: DNS配置文件；E: 触发配置重置的事件（重启、服务重启）。

DNS配置状态：{平台默认， 用户已修改， 已被重置回平台默认}。

动力系统：DNS配置状态是一个具有吸引子（平台默认状态）的系统。用户修改是短暂扰动，系统会回归吸引子。
控制论：平台通过一个负反馈循环来维持DNS配置的设定值。

用户登录实例，查看/etc/resolv.conf，发现指向不认识的IP。尝试修改并保存成功，但重启网络后恢复原状。文档可能提到“建议使用平台DNS以实现内部名称解析”。

通常属于平台提供的网络服务的一部分。但如果强制使用平台DNS导致用户无法遵守内部安全策略（如所有流量必须通过企业DNS过滤），可能产生合规冲突。

1. 实例启动，DHCP客户端运行，从平台DHCP服务器获取IP、网关、DNS（DNS_platform）。
2. DHCP客户端将DNS_platform写入/etc/resolv.conf。
3. 用户修改/etc/resolv.conf，指向DNS_user。
4. 用户重启实例或执行sudo systemctl restart systemd-resolved。
5. 网络服务重启过程再次调用DHCP或平台配置脚本，用DNS_platform覆盖/etc/resolv.conf。
6. 用户配置失效。
方程：on network_reinit: resolve_conf_content = generate_resolv_conf(dns_servers=DNS_platform)

顺序循环：平台设置 -> 用户修改 -> 事件触发 -> 平台重置 -> ...

用户实现持久化自定义DNS的复杂度中等，需深入了解系统配置管理（如禁用cloud-init的某些模块、配置netplan）。

DNS协议、DHCP、操作系统网络配置、systemd-resolved。

P7-0024

云计算/平台商业策略与技术锁定

时间同步服务控制与质量降级

强制使用平台NTP服务，该服务偶尔有较大时间漂移，影响分布式系统。

技术锁定/服务质量控制

实例的网络时间协议客户端被配置为仅指向平台内部NTP服务器N_platform。该服务器集群可能因负载、网络或维护问题，偶尔产生显著的时间偏移ΔT，且用户无法配置备用外部NTP源。

强制NTP与服务质量降级引擎

1. 配置强制：通过DHCP或镜像初始化，将/etc/ntp.conf或systemd-timesyncd配置为仅使用平台NTP服务器（如169.254.169.123）。用户修改配置后可能被重置。
2. 服务质量波动：N_platform作为一个共享服务，其时间准确性受其自身硬件时钟、负载和网络条件影响。时间误差ΔT(t)是一个随机过程，均值可能接近0，但方差Var(ΔT)较大，存在长尾，即偶尔出现较大偏移（跳变）。
3. 影响放大：对于依赖精确时间戳的分布式系统（如分布式数据库、事务系统、监控告警），时间不同步会导致数据不一致、事务冲突或告警误报。系统容忍度ε很小，当

ΔT(t)

> ε时，系统可能出错。
4. 替代路径封锁：防火墙规则或网络路由阻止实例访问公共NTP服务器（如pool.ntp.org），强制流量走向N_platform。
数学方程：
• 实例时钟：C_instance(t) = C_true(t) + ΔT(t)。
• 平台NTP服务误差：ΔT(t) ~ Distribution(μ≈0, σ²较大)，存在厚尾。
• 同步约束：dC_instance/dt通过N_platform校正，但校正源本身有误差。
• 系统错误条件：Error_occurred = 1 if

ΔT_i(t) - ΔT_j(t)

> ε for any two instances i, j。

长期平均时间误差可能尚可，但误差方差大，导致超出容忍阈值的“异常事件”概率不可忽视。

时钟同步协议（NTP）、服务质量、随机过程。

所有云实例的默认时间同步配置。

N_platform: 平台NTP服务器地址；ΔT(t): 实例时钟相对于真实时间的偏移；ε: 分布式系统可容忍的最大时钟差；Var(ΔT): 时间偏移的方差。

时间同步状态：{同步中， 已同步(误差小)， 失步(误差大)}。NTP服务状态：{健康， 降级}。

随机过程：ΔT(t)建模为具有随机扰动的过程（如维纳过程）。
概率：P(

ΔT

> ε) 不可忽略。
控制理论：时钟同步是一个反馈控制系统，但参考源（平台NTP）本身有噪声。

P7-0025

云计算/平台商业策略与技术锁定

紧急恢复功能货币化

对虚拟机串口访问（紧急恢复）按小时收费，价格高昂。

商业策略/功能付费墙

平台提供串口访问功能S（如AWS EC2 Instance Connect， Serial Console），允许用户在网络故障时访问实例控制台。该功能被标记为高级或独立服务，按启用时间T_enabled收费，费率R_serial远高于基础计算费率。

串口访问计费引擎

1. 功能隔离：将串口访问功能从标准实例访问（如SSH）中剥离，作为独立服务S。
2. 按需计费：对S的计费基于实例启用该功能的时间长度T_enabled，即使使用时间很短。费率R_serial设置较高，可能接近甚至超过低规格实例本身的小时费用。
3. 需求刚性：串口访问通常在紧急情况下（SSH/RDP失败）使用，需求缺乏弹性。用户为应对小概率故障，不得不支付持续费用或承担风险。
4. 替代成本高：用户自行搭建带外管理（如IPMI）在云中不可行，因此S是唯一选择。
数学方程：
• 标准实例费用：Cost_instance = R_instance * T_running。
• 串口访问费用：Cost_serial = R_serial * T_enabled。通常 R_serial ≈ k * R_instance， k在0.1到1之间甚至更高。
• 总拥有成本：TCO = Cost_instance + Cost_serial + ...。
• 用户决策：启用S会增加固定成本；不启用则风险R_risk = P(need_serial) * Impact(no_serial)。平台通过提高R_serial，从用户的风险规避心理中获利。

计费是精确的。但将基础运维功能（控制台）单独高价收费，与用户预期存在“价值误差”。

价格歧视、需求弹性、风险管理。

提供虚拟机串行控制台访问的云平台。

S: 串口访问服务；T_enabled: 服务启用时长；R_serial: 串口服务费率；R_instance: 实例基础费率；P(need_serial): 需要串口访问的概率；Impact: 无法访问的损失。

串口服务状态：{禁用， 启用(计费中)}。实例访问状态：{网络可访问， 仅串口可访问， 不可访问}。

经济学：价格弹性低的服务可以定高价。串口访问是典型的低弹性服务（必需品， 无替代品）。
概率与成本：期望成本 E[Cost] = Cost_serial + P(need_serial)*Impact。平台通过设置R_serial，使用户的E[Cost]最小化策略倾向于支付Cost_serial。

控制台有“启用串行控制台”选项，旁边标注“按小时收费”。定价页面显示该服务费率。用户在实例无法SSH时，被迫启用该功能并支付费用。

属于市场定价行为。但如果平台在营销中强调“易于管理”却对关键恢复功能额外高价收费，可能被认为是不公平的商业行为。

1. 用户创建实例，默认不启用串口访问S。
2. 某日实例网络配置错误，SSH无法连接。
3. 用户登录云控制台，尝试通过串口访问进行修复。
4. 控制台提示“需先启用串行控制台功能，该功能将产生额外费用”。
5. 用户勾选同意并启用S。
6. 用户通过串口修复问题，耗时30分钟。
7. 即使只用了30分钟，计费系统按T_enabled（可能从启用到手动禁用）计费，产生一笔费用。
方程：if (serial_console_accessed) { charge += R_serial * max(1 hour, time_enabled); }

顺序序列（故障发生->寻求恢复->启用付费功能->使用->付费）。

功能启用复杂度O(1)。用户成本决策复杂度涉及风险评估。

带外管理、系统恢复、定价策略。

P7-0026

云计算/平台商业策略与技术锁定

实例克隆的地理与规格约束

实例克隆功能仅限在同一区域内，且目标实例类型受限。

技术锁定/数据与配置可移植性限制

平台提供实例克隆功能Clone(Source_Instance, Target_Config)，但限制目标区域必须与源区域相同（Region_target == Region_source），且目标实例类型T_target必须属于平台定义的允许列表L_allowed，该列表是源实例类型T_source的子集，而非全部可用类型。

受限实例克隆引擎

1. 区域锁定：克隆操作被限制在同一个区域（Region）内。跨区域克隆需要用户手动创建镜像、复制镜像、再在新区域启动实例，过程繁琐。
2. 类型过滤：允许的目标类型列表L_allowed通常只包含与T_source相同或相近世代的实例类型，可能排除更便宜或更合适的其他类型。例如，从计算优化型C5克隆时，不能直接克隆到内存优化型R5。
3. 流程简化表象：克隆功能被宣传为“快速复制”，但实际限制削弱了其灵活性，使用户无法通过克隆实现跨区域容灾或灵活的规格调整。
4. 诱导升级：L_allowed可能倾向于引导用户克隆到更新的、更贵的实例类型。
数学方程：
• 克隆函数：Clone(I_src, Region_target, T_target) = Success if (Region_target == Region_src) AND (T_target ∈ L_allowed(T_src)) else Failure。
• 用户理想目标集：T_ideal = {所有可用实例类型} ∩ {满足用户需求的类型}。
• 实际可选集：T_actual = L_allowed(T_src)。通常 T_actual ⊂ T_ideal。
• 跨区域成本：若需跨区域，用户需执行：CreateImage(I_src) -> CopyImage(Region_src, Region_target) -> LaunchInstance(Image, Region_target, T_target)，成本和时间增加。

克隆操作在约束内成功。但约束本身使用户无法达到最优目标，存在“灵活性误差”。

产品功能设计、转换成本、区域化架构。

云控制台或API中的“创建类似实例”或“克隆实例”功能。

I_src: 源实例；Region_src, Region_target: 源和目标区域；T_src, T_target: 源和目标实例类型；L_allowed(T_src): 允许从T_src克隆到的类型集合。

克隆操作状态：{参数校验中， 校验通过(区域和类型)， 校验失败， 执行中， 完成}。

集合论：实例类型空间被划分为不相交的克隆等价类。克隆只能在等价类内进行。
图论：克隆关系是一个有向图，节点是实例类型，边表示允许克隆。该图通常不是完全连通图。
最优化：用户寻找最优(T_target, Region_target)的问题被分解为两个受约束的子问题。

控制台克隆界面中，“区域”下拉框灰色显示为源区域不可改。“实例类型”下拉列表只显示部分选项。API文档中列出克隆的参数限制。

属于平台功能限制，通常合法。但若宣传“轻松复制到任何区域和类型”而实际受限，则构成虚假宣传。

1. 用户选择实例I_src，点击“克隆”或“启动更多类似实例”。
2. 界面预填了源实例的配置，但“区域”字段被锁定为Region_src。
3. 用户尝试修改“实例类型”，发现下拉列表中只有类型集L_allowed(T_src)，例如只有C5a, C5n，而没有C4, M5等。
4. 用户若想克隆到Region_dst，必须放弃克隆功能，转而创建自定义镜像，然后手动在Region_dst启动新实例。
方程：if (region_target != region_src) { return error("Cross-region clone not supported"); } if (type_target not in allowed_clone_types[type_src]) { return error("Unsupported target type"); }

顺序序列（用户发起克隆->系统验证->执行或拒绝）。跨区域手动流程是另一个更长的顺序序列。

克隆操作复杂度O(1)。用户实现跨区域或跨类型复制的复杂度高。

镜像复制、实例配置、区域化服务。

P7-0027

云计算/平台商业策略与技术锁定

虚拟化层硬件抽象控制

禁止用户调整虚拟机BIOS设置（如虚拟化扩展、安全启动）。

技术锁定/硬件访问隔离

平台提供的虚拟机BIOS/固件界面是只读或极度简化的，隐藏了大多数高级设置选项（如Intel VT-x/AMD-V虚拟化扩展、CPU功率管理、安全启动控制、启动顺序）。用户无法根据应用需求进行调优。

虚拟BIOS锁定引擎

1. 固件抽象：平台使用统一的虚拟固件映像，该映像移除了用户可访问的设置菜单，或仅暴露少数几个无关紧要的选项。
2. 配置硬编码：关键硬件特性（如虚拟化扩展）在虚拟机创建时根据实例类型硬编码启用或禁用，运行时不可更改。
3. 需求冲突：某些应用（如嵌套虚拟化、特定性能调优、自定义安全启动链）需要修改这些设置。用户无法满足需求，被迫寻找替代方案或接受性能损失。
4. 控制权剥夺：这剥夺了用户对虚拟硬件环境的底层控制权，使其完全依赖平台默认配置。
数学方程：
• 虚拟机配置空间：C_vm = {可配置的BIOS/固件参数集合}。
• 平台暴露的集合：C_exposed ⊆ C_vm，且

C_exposed

很小。
• 用户可修改集合：C_modifiable ⊆ C_exposed，通常C_modifiable = ∅。
• 应用需求集合：C_required。可能存在C_required ⊄ C_exposed，导致需求无法满足。
• 实例功能：Functionality(VM) = f(C_vm_fixed)，其中C_vm_fixed由平台设定，用户无法改变f。

配置被100%锁定。用户可调整度为0，与期望的灵活性格格不入。

虚拟化技术、系统固件、硬件抽象层。

所有通用虚拟机实例。需要嵌套虚拟化或特定硬件特性的场景。

C_vm: 虚拟机的完整配置空间；C_exposed: 向用户暴露的配置子集；C_required: 应用所需的配置子集；f: 虚拟机功能函数。

虚拟机固件状态：{已加载(平台默认配置)}。用户交互状态：{进入设置界面， 查看只读选项， 退出}。

集合论：C_exposed是C_vm的真子集。用户操作被限制在C_exposed上。
函数映射：虚拟机创建函数CreateVM(type)隐式地确定了C_vm_fixed，用户无法干预。
信息论：用户关于C_vm的信息被平台隐藏，信息不对称。

启动实例时，按传统键（如F2）可能无法进入BIOS设置，或进入后只有寥寥几个不可更改的选项。文档说明“不支持修改BIOS设置”。

属于平台对虚拟化环境的控制权，通常合法。但如果平台宣传“提供完整的x86兼容环境”而实际上缺失关键配置能力，可能构成误导。

1. 用户启动实例，尝试在启动初期按F2进入BIOS设置。
2. 系统可能无反应，或显示一个极简的、只有“系统信息”、“启动顺序”（但不可改）等选项的界面。
3. 用户寻找“虚拟化技术”、“CPU配置”、“安全启动”等选项，不存在。
4. 用户尝试通过平台API或元数据服务修改，无对应接口。
5. 用户应用（如需要运行嵌套虚拟机）因虚拟化扩展未按需配置而失败。
方程：BIOS_Settings = Platform_Default_Policy(instance_type); User_Modifiable_BIOS_Settings = {};

顺序序列（用户尝试访问->发现受限->放弃）。

P7-0028

云计算/平台商业策略与技术锁定

挂起状态计费与性能惩罚

实例挂起状态仍按低费率收费，但恢复后需重新预热，性能受影响。

商业策略/性能与成本博弈

平台提供实例挂起功能Suspend(Instance)，将实例内存状态写入存储并释放计算资源。挂起期间按大幅降低但仍非零的费率R_suspend计费。恢复时，实例需要从存储加载内存状态，且由于CPU缓存、内存页等冷启动，性能在预热期T_warmup内低于正常水平P_normal。

挂起-恢复计费与性能模型

1. 挂起状态定义：实例状态从“运行”转为“挂起”。计算资源（CPU， 内存）被回收，内存内容被保存到持久存储（如EBS）。
2. 计费策略：挂起期间，停止计算资源计费，但可能收取存储内存状态的费用，综合费率为R_suspend，满足 0 < R_suspend < R_running。
3. 恢复过程：恢复操作Resume(Instance)从存储读取内存状态，重新分配计算资源。实例进入“运行”状态，但：
a. 加载延迟：恢复时间T_resume与内存大小成正比。
b. 性能预热：恢复后，由于CPU缓存为空、内存页未激活、JIT编译未完成等，应用性能P(t)在时间t < T_warmup时低于稳态性能P_normal，即P(t) = P_normal * g(t)，其中g(t)是随时间从低值增长到1的函数。
4. 成本-性能权衡：用户为节省成本选择挂起，但需承担恢复后的性能损失和延迟。
数学方程：
• 运行成本：Cost_running = R_running * T_running。
• 挂起成本：Cost_suspend = R_suspend * T_suspend。
• 恢复后性能：P(t) = P_normal * (1 - α * exp(-t/τ))，其中α是初始性能损失比例，τ是预热时间常数。T_warmup ≈ kτ。
• 总成本与性能损失：用户需权衡节省的成本ΔCost = Cost_running - Cost_suspend 与 性能损失积分 ∫[0 to T_warmup] (P_normal - P(t)) dt。

计费精确。性能预热函数g(t)是连续的，但用户感知到的可能是突然恢复后的持续低性能，存在“性能恢复预期误差”。

计算机体系结构（缓存、分支预测）、成本会计、决策理论。

支持实例挂起/恢复功能的云平台（如AWS EC2 Hibernation， 部分平台的“停止不计费”但保留实例）。

R_running: 运行费率；R_suspend: 挂起费率；T_suspend: 挂起时长；T_resume: 恢复加载时间；P(t): 恢复后瞬时性能；P_normal: 稳态性能；T_warmup: 预热时长；α, τ: 预热模型参数。

实例状态：{运行， 挂起中， 挂起， 恢复中， 运行(预热)}。性能状态：{正常， 预热中， 预热完成}。

微分方程：性能恢复可以建模为一个指数趋近过程：dP/dt = (P_normal - P)/τ。
经济学：成本节省与性能损失的权衡。用户决策基于对T_suspend和T_warmup的估计。
最优化：寻找最优的挂起阈值时间T*，使得净收益（节省成本 - 性能损失成本）最大。

控制台有“停止实例”或“休眠实例”选项，并提示“会产生较低的存储费用”。实例恢复后，监控显示CPU使用率初期较高（系统预热），应用响应时间变长。

属于服务定价和性能特性描述。若未明确披露恢复后的性能预热期，用户可能基于“完全恢复”的假设决策，产生争议。

1. 用户停止实例，选择“休眠”或“挂起”。
2. 实例内存写入存储，状态变为“已挂起”。计费从R_running变为R_suspend。
3. 几小时后，用户恢复实例。
4. 实例状态先变为“正在启动”，持续T_resume（与内存大小相关）。
5. 实例进入“运行”状态，但应用响应缓慢。系统监控显示初始CPU利用率高（用于页错误处理、缓存填充）。
6. 经过T_warmup时间（可能几分钟），性能逐渐稳定到P_normal。
方程：Cost = (R_running * T_run) + (R_suspend * T_suspend); Performance_after_resume(t) = P_normal * (1 - α * e^(-t/τ))

顺序序列（运行->挂起->(时间流逝)->恢复->预热->运行）。预热过程是指数衰减的时间序列。

挂起/恢复操作复杂度O(内存大小)。用户性能调优复杂度中等，需预热策略。

操作系统休眠机制、存储I/O性能、CPU缓存体系结构、应用预热。

P7-0029

云计算/平台商业策略与技术锁定

实时迁移兼容性筛选

热迁移仅支持特定实例类型和配置，其他配置需冷迁移导致服务中断。

技术锁定/服务可用性分级

平台维护一个支持实时迁移的实例类型和配置白名单L_live。当需要为底层主机维护时，对于白名单内的实例，平台执行实时迁移（无感知）；对于白名单外的实例（如使用本地存储、特定GPU类型、某些网络配置），则执行冷迁移（先停止，再迁移，再启动），导致服务中断。

实时迁移兼容性引擎

1. 兼容性检测：平台根据实例配置C（类型、附加的存储类型、附加的设备等）判断是否支持实时迁移：IsLiveMigratable(C) = True if C ∈ L_live else False。
2. 迁移路径选择：当主机H需要维护时，对于每个实例I：
if IsLiveMigratable(Config(I)): 执行 LiveMigrate(I);
else: 执行 ColdMigrate(I) = Stop(I) -> MigrateStorage(I) -> Start(I)。
3. 中断差异：LiveMigrate保持实例运行状态，中断时间Δt_live ≈ 0。ColdMigrate导致实例停止，中断时间Δt_cold = T_stop + T_migrate + T_start，可能长达数分钟。
4. 诱导选择：平台可能将更昂贵或更新的实例类型纳入L_live，变相鼓励用户升级以获得高可用性。
数学方程：
• 实例配置空间：C。
• 实时迁移支持函数：Support_Live(C) = 1 if C ∈ L_live else 0。
• 维护事件导致的停机时间：Δt_outage(I) = Support_Live(C(I)) * Δt_live + (1 - Support_Live(C(I))) * Δt_cold。
• 期望可用性：E[A(I)] = 1 - (λ * Δt_outage(I))，其中λ是维护事件率。对于不支持实时迁移的实例，E[A]较低。

迁移操作成功与否是确定的。但用户因配置选择导致的可用性差异Δt_cold - Δt_live是显著的“可用性误差”。

高可用性架构、实时迁移技术、服务等级协议。

平台发起的计划内维护事件（硬件维修、固件升级）。

L_live: 支持实时迁移的配置白名单；C(I): 实例I的配置；IsLiveMigratable(): 兼容性判断函数；Δt_live, Δt_cold: 热迁移和冷迁移的中断时间。

实例迁移状态：{待迁移， 实时迁移中， 冷迁移中(已停止)， 迁移完成}。服务中断状态：{无中断， 中断中}。

集合论：实例配置空间被划分为两个集合：可实时迁移和不可实时迁移。
概率与期望：实例的期望停机时间是其配置的函数。
最优化：用户在选择配置时，需在功能/成本与潜在停机风险间权衡。

计划维护通知中可能注明“某些实例可能需要重启”。文档中有一个列表说明哪些实例类型和配置支持实时迁移。用户使用本地存储的实例在维护时总是会重启。

SLA可能对所有实例一视同仁，或对不支持实时迁移的实例有除外条款。若平台未清晰披露哪些配置会导致冷迁移，用户可能基于错误假设（认为所有维护都无感）进行架构设计。

1. 平台检测到主机H需维护，计划在时间T进行。
2. 平台扫描H上所有实例，对每个实例I计算IsLiveMigratable(Config(I))。
3. 对于返回True的实例，安排实时迁移，用户无感知。
4. 对于返回False的实例，平台在T前几分钟发出“实例需要停止”的警告。
5. 在T时刻，这些实例被强制停止，数据迁移后在新主机启动。
6. 实例中断持续Δt_cold。
方程：for instance in host.instances: if instance.config in LIVE_MIGRATION_WHITELIST: live_migrate(instance); else: cold_migrate(instance); // involves stop

并行序列：主机上多个实例的迁移同时或依次进行。对于不支持实时迁移的实例，其冷迁移是顺序的（停止->迁移->启动）。

兼容性判断复杂度O(1)。用户实现高可用架构的复杂度增加，需避免进入冷迁移集合。

实时迁移技术（内存预拷贝、后拷贝）、存储类型（网络存储 vs 本地存储）、设备透传。

P7-0030

云计算/平台商业策略与技术锁定

资源库存信息不透明

预定实例的系统不显示真实库存，用户预定后被告知无资源。

商业策略/信息不对称与承诺失效

平台提供实例预定功能Reserve(Instance_Type, AZ, Quantity)。用户提交预定请求时，系统基于一个乐观的或过时的库存模型I_optimistic进行校验并立即确认预定成功。但在实际履行时间T_fulfillment，真实库存I_real可能不足，导致预定失败，用户被通知无资源。

乐观库存预定引擎

1. 库存模型分离：平台维护两个库存视图：面向用户的前台乐观库存I_optimistic(t)和后台真实物理库存I_real(t)。I_optimistic(t) ≥ I_real(t)，可能包含预测的即将释放的资源或共享池的过度承诺。
2. 预定确认：用户预定请求Req(type, az, qty)在时间T_request到达。系统检查I_optimistic(T_request) >= qty，若满足则立即确认预定成功，生成预定ID，并扣减I_optimistic。
3. 履行失败：在履行时间T_fulfillment（可能是立即，也可能是未来的某个时间点），系统尝试从I_real分配资源。如果I_real(T_fulfillment) < qty，则分配失败。系统通知用户“资源不足，预定失败”。
4. 用户成本：用户可能基于预定成功进行了其他资源规划和安排，失败导致计划打乱。平台可能不承担任何责任。
数学方程：
• 库存动态：dI_real/dt = Supply(t) - Demand(t)。dI_optimistic/dt 基于更乐观的预测或策略。
• 预定请求：Req = (type, az, qty, T_request)。
• 确认条件：Confirm(Req) = True if I_optimistic(T_request) >= qty。
• 履行条件：Fulfill(Req) = True if I_real(T_fulfillment) >= qty。
• 失败概率：P(Fulfillment_Failure) = P(I_real(T_fulfillment) < qty

Confirm(Req)=True)。由于I_optimistic ≥ I_real，此概率>0。

预定确认是即时的，但履行成功率<100%，存在“承诺误差”。

库存管理、收益管理、过度承诺。

实例预定、预留实例购买、容量预留服务。

I_optimistic(t): 乐观库存；I_real(t): 真实库存；Req: 预定请求；qty: 数量；T_request: 请求时间；T_fulfillment: 履行时间。

预定状态：{已提交， 已确认， 履行中， 已履行， 失败(无资源)}。库存状态：{乐观库存充足， 真实库存充足， 真实库存不足}。

排队论/库存理论：将资源视为库存，预定视为提前订单。乐观库存导致超额预订。
概率：履行失败是一个条件概率事件。
博弈：平台在提高预定成功吸引力（高I_optimistic）和降低履行失败风险（高I_real）间博弈。

用户预定实例时，界面显示“可用”并成功下单付款。但在实例启动时间，收到邮件或控制台通知“我们无法完成您的请求，因为所选区域没有足够的容量”。

若用户因预定失败产生业务损失，平台的服务条款通常免除责任。但若平台系统性、频繁地过度承诺，可能涉及虚假交易或误导性商业行为。

1. 用户选择实例类型、区域和数量，点击“预定”。
2. 系统查询I_optimistic，显示充足，允许用户下单并确认预定成功。
3. 用户收到预定确认号，并可能开始进行相关部署准备。
4. 在预定的启动时间（或立即启动时），系统尝试从I_real分配资源。
5. 由于其他用户消耗或预测不准，I_real不足。
6. 系统发送预定失败通知，可能建议用户重试或选择其他区域/类型。
方程：if (I_optimistic >= qty) { confirm_order(); I_optimistic -= qty; } later: if (I_real >= qty) { fulfill_order(); I_real -= qty; } else { notify_failure(); }

顺序序列（请求->乐观确认->(时间延迟)->真实履行尝试->成功/失败）。

库存查询和预定确认复杂度O(1)。用户应对履行失败的复杂度高，需有备用计划。

P7-0031

云计算/平台商业策略与技术锁定

资源元数据容量限制

限制每个资源的标签数量（如50个），无法进行精细化管理。

技术锁定/管理粒度限制

平台对每个资源（如实例、卷、IP）可附加的标签（Tag）数量设置上限N_max（如50个）。标签是键值对，用于资源分类、成本分配、自动化等。当用户需要更复杂的分类（如多维度、多项目、细粒度成本中心）时，标签数量可能超过N_max。

标签数量限制引擎

1. 硬性限制：API和UI强制实施标签数量上限。当尝试为资源R添加第(N_max+1)个标签时，操作失败并返回错误“TooManyTags”。
2. 管理粒度受损：标签是云资源管理的重要元数据。限制N_max迫使用户：
a. 合并多个维度到一个标签值（如Project:Finance-Env:Prod-Region:US），降低可读性和可查询性。
b. 建立外部映射表，增加管理复杂度。
c. 放弃某些维度的标记。
3. 自动化影响：基于标签的自动化策略（如成本报告、安全策略、自动备份）因信息不全而失效或变得复杂。
4. 成本分配困难：在大型组织中，精细的成本分配需要多个标签（部门、项目、成本中心、环境、所有者等），N_max可能不够用。
数学方程：
• 资源R的标签集合：Tags(R) = {(key1, value1), ..., (key_n, value_n)}。
• 约束：

Tags(R)

≤ N_max。
• 用户需求维度：设用户需要标记D个维度。每个维度可能需要一个标签，或一个维度有多个值需要多个标签。理想标签数N_ideal ≥ D。
• 限制导致的信息损失：信息损失 = f(N_ideal - N_max)，当N_ideal > N_max时，损失>0。f可以是无法标记的维度数量，或标签值的编码复杂度增加。

标签数量限制是硬性的，误差为0（超过即失败）。但导致的管理效率损失是难以量化的“功能误差”。

元数据管理、分类学、信息论。

所有支持标签功能的云资源。

Tags(R): 资源R的标签集合；N_max: 每个资源允许的最大标签数；D: 用户需要的标记维度数；N_ideal: 理想标签数量。

资源标签状态：{未标记， 已标记(数量< N_max)， 标签已满(数量= N_max)}。标签操作状态：{添加成功， 添加失败(超限)}。

组合数学：标签是键值对集合。限制数量即限制集合的大小。
信息论：标签承载了关于资源的信息I。限制标签数量限制了I的上限：I ≤ Σ_i H(key_i, value_i)，但受

Tags

≤ N_max约束。
最优化：用户需在N_max个标签内最大化信息价值，是一个带约束的优化问题。

在控制台为资源添加标签时，输入框旁可能显示“最多50个标签”。通过API添加第51个标签时返回错误。文档明确列出限制。

属于平台技术限制，通常合法。但对于企业级用户，这可能妨碍其合规性要求（如需要大量标签进行成本分摊），从而影响服务适用性。

P7-0032

云计算/平台商业策略与技术锁定

资源关联与删除静默

删除实例时不提示关联资源（如弹性IP、卷），导致资源泄漏和继续计费。

商业策略/用户错误诱导

删除实例的操作Delete(Instance)默认不删除与之关联的资源A（如弹性IP、独立EBS卷、网络接口）。操作确认对话框可能只提示“实例将被删除”，而不列出或弱化提示关联资源A将继续存在并计费。

静默关联资源保留引擎

1. 资源关联图：实例I与一组资源A = {EIP1, EBS1, ENI1, ...}关联。这些资源有独立生命周期和计费。
2. 删除操作设计：Delete(I)的默认行为是：删除I，但保留A。确认提示信息M可能为“删除此实例？”，未明确列出A或说明其后续计费。
3. 用户认知偏差：用户可能认为删除实例会清理所有相关资源，尤其是当这些资源是在创建实例时自动创建的。注意力集中在“实例”这个主要对象上，忽略关联资源。
4. 持续计费：资源A在实例I删除后继续存在并产生费用，形成“资源泄漏”。用户可能直到收到账单时才发觉。
数学方程：
• 关联资源集：A(I) = {r

r is attached to I}。
• 删除操作结果：Delete_Default(I) = (I is terminated) ∧ (∀r ∈ A(I), r remains)。
• 用户期望操作：Delete_Expected(I) = (I is terminated) ∧ (∀r ∈ A(I), r is terminated if created_with_I)。
• 成本影响：Cost_leakage = Σ_{r in A(I)} (Rate_r * T_remaining)，其中T_remaining是从实例删除到用户发现并手动删除r的时间。
• 提示有效性：设提示信息M包含关联资源列表的概率为P(M_list)。通常P(M_list)很低。

实例删除操作100%成功。但关联资源的保留与用户预期存在“行为误差”，导致财务损失。

人机交互、认知负荷、默认选项设计。

云控制台或API中的实例终止/删除操作。

I: 实例；A(I): 实例I的关联资源集合；M: 删除确认提示信息；P(M_list): 提示包含关联资源列表的概率；Cost_leakage: 资源泄漏产生的费用。

实例状态：{运行， 删除请求(确认对话框)， 已终止}。关联资源状态：{已附加， 独立存在(泄漏)}。

集合论：删除操作作用于实例集合{I}，而不作用于关联资源集合A(I)。
概率：用户遗漏关联资源的概率与提示信息M的显著度成反比。
图论：资源关系是一个图，删除一个节点（实例）不一定删除其连接的边和相邻节点（关联资源）。

删除实例时，确认对话框可能有一个小字体的“注意：附加的EBS卷不会被自动删除”或根本没有提示。删除后，弹性IP仍显示在控制台中并产生费用。

平台可能主张用户有责任管理自己的资源。但若UI设计存在误导，未以清晰、显著的方式提示持续计费的风险，可能在消费者保护纠纷中处于不利地位。

1. 用户选择实例I，点击“终止”或“删除”。
2. 系统弹出确认对话框，显示消息M：“您确定要终止实例I吗？”（可能附带一行不显眼的小字说明）。
3. 用户确认删除。
4. 系统终止实例I，但保留所有关联的弹性IP、EBS卷、网络接口等。
5. 这些资源继续计费。
6. 用户在下个计费周期发现意外费用。
方程：on delete_instance(I): for resource in attached_resources(I): if not resource.delete_with_instance: keep(resource); charge_for(resource);

顺序序列（用户发起删除->系统提示->用户确认->系统执行删除(部分)）。资源泄漏是静默发生的后续状态。

删除操作复杂度O(1)。用户发现和清理泄漏资源的复杂度中等（需定期审计账单）。

P7-0033

云计算/平台商业策略与技术锁定

监控粒度分级收费

自定义监控数据采集间隔（如5秒）需额外付费，标准间隔（1分钟）不满足需求。

商业策略/功能分级定价

平台提供基础监控服务M_basic，以固定间隔T_basic（

P7-0034

云计算/平台商业策略与技术锁定

性能基准测试环境理想化

公布的实例性能基准数据在理想环境下测得，实际使用中无法达到。

商业策略/信息不对称

平台发布实例性能基准数据P_benchmark（如每秒事务数、带宽、IOPS），这些数据是在隔离的、无干扰的实验室环境中，使用特定工作负载和优化配置测得。用户在实际生产环境中的性能P_real受多租户噪声、网络延迟、存储后端负载等因素影响，通常P_real < P_benchmark。

理想化基准测试与发布引擎

1. 基准环境构建：平台在专用硬件上，使用最优配置（如独占主机、本地NVMe存储、低延迟网络），运行微基准测试（如CPU算力测试、存储顺序读写）以获得最高性能数字P_benchmark。
2. 数据发布：将P_benchmark作为该实例类型的“最大性能”或“基准性能”在规格表中公布。
3. 实际环境差异：用户实例运行在共享硬件上，受“噪声邻居”影响；使用网络存储而非本地存储；运行复杂混合工作负载而非微基准。这些因素引入性能开销ΔP_overhead。
4. 性能差距：用户实际观测到的性能P_real = P_benchmark - ΔP_overhead。ΔP_overhead可能很大且可变，导致用户无法复现基准数据。
数学方程：
• 基准性能：P_benchmark = f_ideal(Workload_benchmark, Environment_ideal)。
• 实际性能：P_real = f_real(Workload_real, Environment_shared) = P_benchmark - ΔP_overhead。
• 性能开销：ΔP_overhead = g(Noise_neighbor, Network_latency, Storage_contention, ...)。
• 期望管理：用户基于P_benchmark规划容量，但实际需要更多实例才能达到预期吞吐量，导致成本超支。

基准数据本身测量精确，但作为用户实际性能的预测指标，存在系统性负偏差，即“性能期望误差”。

性能测试方法论、多租户资源共享、服务质量隔离。

实例规格表、性能白皮书、销售材料中的性能数据。

P_benchmark: 公布的基准性能；P_real: 用户实际性能；Workload_benchmark: 基准测试负载；Environment_ideal: 理想测试环境；ΔP_overhead: 实际环境性能开销。

性能状态：{基准性能(理想)， 实际性能(受干扰)}。用户认知状态：{相信基准， 发现差距}。

统计学：P_real是P_benchmark的一个有偏估计量，偏差为-ΔP_overhead。
最优化：平台通过展示P_benchmark最大化产品吸引力，用户则需要预估ΔP_overhead来做出正确决策。
博弈论：平台与用户之间存在信息不对称，平台拥有ΔP_overhead分布的信息优势。

规格表注明“最高可达XX Gbps带宽”或“高达XXK IOPS”。用户实际测试或生产负载中，性能远低于该值。客服回应“该数据为实验室环境下测得”。

若基准数据被明确标注为“最大”或“实验室”结果，则可能不构成误导。但若以暗示性语言让用户相信是典型性能，则可能违反广告真实性原则。

1. 平台在受控环境中对新型实例进行基准测试，获得性能数据P_benchmark。
2. 平台在官网发布规格表，包含P_benchmark。
3. 用户基于P_benchmark选择实例类型和数量，规划系统容量。
4. 用户在生产环境部署应用，观测到性能P_real。
5. P_real持续低于P_benchmark，用户需扩容实例以满足性能要求，导致成本增加。
方程：P_real = P_benchmark - (noise + network_latency + storage_contention + ...)

时间序列：基准测试在时间T1完成并发布。用户在实际时间T2>T1观测性能。两者环境不同。

基准测试复杂度高。用户性能诊断和容量重规划的复杂度高。

性能基准测试、容量规划、多租户隔离技术。

P7-0035

云计算/平台商业策略与技术锁定

实例放置策略黑盒

不公开实例在物理服务器上的放置策略，无法优化性能（如避免噪声邻居）。

技术锁定/资源调度不透明

平台调度器S将虚拟机实例放置到物理主机上，其放置算法Place(VM, Host)的细节（如是否考虑CPU拓扑、是否避免将高负载实例放在同一主机、是否进行物理隔离）对用户不透明。用户无法知晓其实例与哪些其他租户的实例共享物理机，也无法请求特定的放置策略。

黑盒调度与放置引擎

1. 调度不透明：调度决策基于平台内部的多目标优化（如资源利用率、能效、硬件故障域隔离），这些目标和约束不向用户公开。
2. 噪声邻居问题：由于共享物理资源（CPU缓存、内存带宽、网络I/O），同一主机上的其他实例（“邻居”）的活跃度会影响本实例的性能。用户无法预测或控制邻居的行为。
3. 优化手段缺失：用户无法通过API或配置指定放置偏好，如：“将我的这两个实例放在不同的物理机上以降低相互干扰风险”或“将我的实例与特定类型的其他实例隔离”。
4. 性能波动：实例性能P(t)不仅取决于自身负载，还取决于邻居的负载L_neighbor(t)，即P(t) = f(Self_Load(t), L_neighbor(t))。由于L_neighbor(t)未知且不可控，P(t)出现不可预测的波动。
数学方程：
• 调度函数：Host = S(VM, Resource_Pool, Internal_Policy)。S的内部逻辑未知。
• 实例性能：P_i(t) = g(Resource_Allocated_i, Interference(Workload_j(t) for all j on same host))。
• 干扰函数：Interference() 取决于资源共享粒度和争用程度，对用户是黑盒。
• 用户目标：希望最小化干扰，即选择S使得Interference()最小，但用户无法影响S。

调度结果确定，但调度逻辑和邻居负载信息对用户完全隐藏，存在“信息误差”。

资源调度、多租户隔离、性能干扰。

所有多租户公有云环境。对性能稳定性要求高的应用（如高频交易、实时分析）。

S: 平台调度器；Place(): 放置函数；Host: 物理主机；P_i(t): 实例i在时间t的性能；L_neighbor(t): 邻居实例的负载；Interference(): 性能干扰函数。

实例放置状态：{已调度(主机H)}。主机负载状态：{低干扰， 高干扰}。实例性能状态：{稳定， 波动}。

优化理论：调度是一个黑盒优化问题，用户是观察者而非参与者。
随机过程：邻居负载L_neighbor(t)是一个随机过程，导致P_i(t)也是一个随机过程，方差增大。
博弈论：多个租户的实例在不知情的情况下竞争共享资源，形成非合作博弈。

用户实例性能出现周期性或随机性下降。监控显示自身负载稳定，但底层资源（如CPU等待时间）指标异常。用户无法获取邻居信息或请求迁移。

属于平台内部运营细节，通常无义务公开。但若平台承诺“性能隔离”而实际干扰严重，可能违反SLA。

1. 用户启动一个实例I1，调度器S将其放置在主机H上。
2. 稍后，另一租户的实例I2被调度到同一主机H，并开始运行高负载任务。
3. I1和I2竞争CPU缓存、内存带宽等资源。
4. I1的性能P1下降，但用户只能看到I1自身的指标，看不到I2的存在或负载。
5. 用户尝试联系支持，请求迁移I1以避免干扰，可能被拒绝或告知无此功能。
方程：Host_for_I = S(I, available_hosts); Performance(I, t) = Base_Performance - α * Σ_{J on same host} Load(J, t)

并行序列：多个租户的实例被独立调度到共享主机上，它们的负载在时间上并行运行并相互干扰。

调度器复杂度高（NP难问题）。用户诊断和缓解性能干扰的复杂度高。

资源调度算法、性能隔离技术（如资源份额、缓存分区）、监控与可观测性。

P7-0036

云计算/平台商业策略与技术锁定

专用主机资源共享隐瞒

专用主机租赁承诺专属物理机，实际可能与其他租户共享底层资源。

商业策略/虚假承诺

平台提供“专用主机”服务，承诺将整台物理服务器租给单一用户。但在某些实现中，平台可能在该物理机上运行其自身的控制平面组件、管理虚拟机或与其他“专用主机”租户共享某些底层资源（如网络交换机、存储控制器），导致并非完全物理隔离。

专用主机资源稀释引擎

1. 承诺与营销：服务描述为“单租户物理服务器”、“完全隔离”，使用户相信获得对整台机器所有资源的独占访问权。
2. 实际实现：物理服务器上可能仍运行着：
a. 宿主机管理程序（Hypervisor）及其管理组件。
b. 平台的管理代理（用于监控、计量、安全）。
c. 在某些架构中，网络虚拟化或存储虚拟化层可能由跨多台物理机的共享控制器处理，引入共享点。
3. 资源影响：管理组件会消耗一定的CPU、内存、I/O资源。虽然比例小，但与“完全独占”的承诺存在差距。共享控制器可能成为性能瓶颈或安全攻击面。
4. 信息不对称：用户无法验证物理机上是否只有自己的虚拟机，也无法审计管理组件的资源消耗。
数学方程：
• 物理服务器总资源：R_total = {CPU_cores, RAM, Disk, ...}。
• 承诺可用资源：R_promised = R_total。
• 实际可用资源：R_actual = R_total - R_management - R_shared_overhead。
• 其中R_management是平台管理组件消耗的资源，R_shared_overhead是通过共享基础设施引入的潜在争用开销。
• 资源独占度：Exclusivity = R_actual / R_promised < 1。

物理服务器的所有权是独占的，但资源可用性并非100%，存在“资源独占性误差”。

虚拟化架构、资源管理、服务描述真实性。

“专用主机”、“裸金属实例”等承诺物理隔离的服务。

R_total: 物理机总资源；R_promised: 承诺给用户的资源；R_actual: 用户实际可用的资源；R_management: 管理组件占用资源；Exclusivity: 资源独占度。

专用主机状态：{已分配(给用户)}。资源占用状态：{用户虚拟机占用， 平台管理组件占用}。

集合论：物理资源集合被划分为用户子集和平台管理子集。
最优化：平台在保证用户核心资源的同时，最小化管理开销R_management。
合同理论：服务承诺（完全独占）与实际提供（接近独占）之间存在不完全契约。

营销材料强调“单租户物理服务器”、“完全隔离”。用户登录专用主机后发现一些未知进程运行，或性能测试略低于预期。平台解释这些是必要的管理组件。

若服务合同明确承诺“所有硬件资源专供您使用”，而运行了非用户授权的软件并占用资源，可能构成违约。关键在于“资源”定义的宽泛程度。

1. 用户租赁一台专用主机D。
2. 平台在物理机P上安装基础管理程序和管理代理。
3. 用户获得D的访问权限，并部署自己的虚拟机。
4. 用户通过系统工具发现，除了自己的虚拟机，还有固定的、无法终止的进程（管理代理）在运行，并占用少量CPU和内存。
5. 网络和存储流量可能经过与其他专用主机共享的虚拟化网关。
6. 用户感觉未获得100%纯净的物理机。
方程：Resources_Available_To_User = Total_Hardware_Resources - Hypervisor_Overhead - Management_Agent_Consumption

顺序序列（用户租赁->平台配置->用户使用->发现管理组件）。管理组件在用户使用期间持续运行。

专用主机供应复杂度中等。用户验证资源独占性的复杂度高（需要底层访问权限）。

裸金属云、硬件虚拟化、可信执行环境。

P7-0037

云计算/平台商业策略与技术锁定

恢复点目标承诺虚高

承诺的实例恢复点目标（RPO）在实际灾难中无法达到。

商业策略/服务等级协议(SLA)夸大

平台在SLA或营销材料中承诺其备份或灾难恢复服务能达到恢复点目标RPO_promised（如5分钟）。该承诺基于理想化的测试场景。在实际区域级故障或大规模故障中，由于数据复制延迟、协调开销、资源争用等因素，实际恢复点RPO_actual可能远大于RPO_promised。

乐观RPO承诺引擎

1. RPO定义：RPO指灾难发生时允许丢失的数据的时间量。平台承诺RPO_promised，意味着数据丢失窗口不超过该值。
2. 测试环境：承诺基于小规模、可控的测试，其中复制链路稳定，负载极低。
3. 实际灾难场景：大规模故障时：
a. 跨区域数据复制链路可能拥塞，延迟增加。
b. 故障检测和故障转移协调时间变长。
c. 恢复站点的资源可能不足，导致数据恢复队列等待。
4. RPO失效：综合因素导致最后一次成功复制到故障发生的时间差（即实际数据丢失量）超过RPO_promised，即RPO_actual > RPO_promised。
数学方程：
• 数据复制延迟：L(t) = 基础延迟 + 拥塞延迟(t)。在灾难前拥塞可能加剧。
• 故障检测与决策时间：T_detect + T_failover。
• 实际RPO：RPO_actual = max(复制间隔, L(t_last_successful) + T_detect + T_failover)。
• 其中t_last_successful是最后一次成功复制的时间。
• 承诺差距：ΔRPO = RPO_actual - RPO_promised。在灾难时ΔRPO可能显著为正。

在理想测试中RPO可达标，但在实际压力场景下存在“恢复能力误差”，ΔRPO > 0。

灾难恢复、数据复制、服务等级协议。

提供跨区域备份、多可用区部署、灾难恢复服务的SLA承诺。

RPO_promised: 承诺的恢复点目标；RPO_actual: 实际恢复点目标；L(t): 数据复制延迟；T_detect: 故障检测时间；T_failover: 故障转移时间；ΔRPO: RPO差距。

数据复制状态：{同步中， 同步成功， 同步延迟}。灾难状态：{正常， 故障发生， 恢复中， 已恢复}。

排队论：灾难发生时，恢复请求可能排队，增加恢复时间。
最坏情况分析：SLA承诺通常基于典型情况，而RPO_actual应考虑最坏情况。
可靠性工程：实际RPO是多个随机变量（延迟、检测时间）的函数，其分布尾部可能很厚。

SLA文档写明“设计RPO为5分钟”。实际发生区域中断时，用户恢复后发现数据丢失了15分钟。平台解释为“由于不可预见的极端情况”。

SLA通常包含免责条款，如“尽合理努力”、“在正常运营条件下”。若平台在设计和运营中未为达到承诺RPO采取合理措施，可能仍需承担责任。

1. 平台日常监控数据复制延迟L(t)，通常L(t) < RPO_promised。
2. 发生大规模区域故障，网络拥塞，L(t)急剧上升。
3. 故障检测系统因负载高，T_detect增加。
4. 故障转移协调因多个服务同时故障而变慢，T_failover增加。
5. 最后一次成功复制发生在故障前t_last_successful时刻。
6. 故障发生在t_failure时刻。实际数据丢失 = t_failure - t_last_successful > RPO_promised。
方程：RPO_actual = (t_failure - t_last_successful) = L(t_last_successful) + T_detect + T_failover

时间序列：数据持续复制（周期序列）。故障事件是随机点。故障后的恢复过程是顺序序列。

日常复制复杂度低。灾难时恢复协调复杂度高，且难以预测。

灾难恢复计划、数据复制技术、服务等级协议、高可用性架构。

P7-0038

云计算/平台商业策略与技术锁定

自定义镜像存储计费不灵活

自定义镜像按GB每月收费，但无法选择压缩或差异存储。

商业策略/存储成本锁定

平台对用户创建的自定义镜像I按其所占存储空间大小S（GB）和存储时长T（月）计费，费率R_per_GB_per_month。无论镜像内容是否可被高效压缩，或与基础镜像存在大量重复数据，都按完整大小S计费。用户无法选择启用压缩或仅存储与基础镜像的差异部分。

镜像存储全量计费引擎

1. 镜像创建：用户从实例创建自定义镜像I，其大小S等于实例系统盘的大小（例如100 GB），尽管实际使用量可能只有20 GB。
2. 存储计费：每月费用Cost_image = S * R_per_GB_per_month。
3. 缺乏优化选项：平台不提供：
a. 压缩：在存储前透明压缩镜像，减少S。
b. 差异存储：仅存储I与它所基于的公共基础镜像B之间的差异块Δ。存储Δ而非完整的S。
4. 成本低效：用户为未使用的磁盘空间（空白部分）和与基础镜像重复的数据支付存储费用。这鼓励用户创建更小的系统盘，但可能影响性能。
数学方程：
• 镜像物理大小：S_physical = 磁盘容量。
• 镜像实际使用量：S_used ≤ S_physical。
• 与基础镜像的差异量：S_diff通常远小于S_physical。
• 当前计费：Cost_current = S_physical * R * T。
• 理想计费（如果支持差异存储）：Cost_ideal = S_diff * R * T。
• 存储效率损失：Loss = Cost_current - Cost_ideal = (S_physical - S_diff) * R * T。

计费基于S_physical是精确的，但相对于用户数据实际占用的存储量S_diff，存在“存储效率误差”，导致多付费。

存储效率、数据去重、成本会计。

自定义镜像创建和存储服务。

I: 自定义镜像；S_physical: 镜像物理大小（GB）；S_used: 镜像中实际使用的空间；S_diff: 与基础镜像的差异大小；R: 存储费率（$/GB/月）；T: 存储时长（月）。

镜像存储状态：{活跃， 计费中}。存储效率状态：{全量存储， 差异存储(不可选)}。

信息论：镜像的熵（实际信息量）可能远小于其物理大小。
最优化：用户需在磁盘容量（影响性能）和存储成本间权衡。平台通过不提供差异存储，增加了用户存储成本。
集合论：自定义镜像I可以表示为基镜像B与差异集Δ的并集：I = B ∪ Δ。但计费基于

I

而非

Δ

。

控制台显示自定义镜像大小为系统盘大小（如100GB）。每月账单中有一项“镜像存储：100GB * 0.10=10”。用户无法选择“仅存储差异”或启用压缩。

属于定价策略。但如果平台宣传“高效存储”而实际采用低效的全量存储，可能构成误导。用户可通过创建更小的系统盘来部分规避。

P7-0039

云计算/平台商业策略与技术锁定

实例规格配比扭曲

实例的vCPU、内存、网络带宽配比不合理，用户被迫选择更高规格。

产品策略/捆绑销售

平台定义实例类型T，其资源配置为三元组 (vCPU, Memory, Network_Bandwidth)。对于某些特定工作负载（如内存密集型但计算要求低），平台提供的规格中，内存与vCPU的比率R_mem_per_core可能过高或过低，迫使需要高内存的用户选择附带过多vCPU的规格，反之亦然。网络带宽也可能与计算能力过度捆绑。

规格配比捆绑引擎

1. 规格矩阵设计：平台发布一个有限的实例规格矩阵M，每一行是一个规格。M的设计可能不是均匀覆盖所有可能的(vCPU, Memory)组合，而是在某些区域存在“空洞”。
2. 用户需求匹配：用户工作负载需求为D = (need_vCPU, need_Mem, need_BW)。在矩阵M中寻找满足D的最小规格S_min，使得 S_min.vCPU >= need_vCPU, S_min.Mem >= need_Mem, S_min.BW >= need_BW。
3. 配比失配：由于M的不连续性或不合理性，S_min可能在某个维度上远超用户需求。例如，用户需要16vCPU和64GiB内存，但最小规格是16vCPU/128GiB，导致内存浪费；或者需要高内存比，但最小规格是32vCPU/128GiB，导致vCPU浪费。
4. 成本强加：用户为不需要的额外资源付费。Cost_user = Price(S_min) > Price(D)，其中Price(D)是满足需求D的理想规格的价格。
数学方程：
• 实例规格集合：S = {s_i = (c_i, m_i, b_i)}，其中c=vcpu, m=memory, b=bandwidth。
• 用户需求：D = (c_d, m_d, b_d)。
• 可行规格集：F = {s_i ∈ S

c_i >= c_d, m_i >= m_d, b_i >= b_d}。
• 选择的最小规格：s* = argmin_{s_i in F} Price(s_i)。
• 资源浪费：Waste = (s.c - c_d, s.m - m_d, s.b - b_d)。至少有一个维度上Waste > 0。
• 成本效率：Efficiency = Price(D_ideal) / Price(s) < 1。

规格配置和价格是确定的。但规格矩阵M的设计导致用户无法精确匹配需求，存在“资源配置误差”和相应的“成本效率误差”。

产品线设计、价格歧视、资源捆绑。

选择实例规格进行部署。

S: 实例规格集合；s_i: 第i个规格，包含(vCPU, Memory, Bandwidth)；D: 用户需求；F: 满足需求的可行规格集；s*: 用户最终选择的最小规格；Price(): 定价函数。

规格选择状态：{需求定义， 查找匹配规格， 找到规格(有浪费)， 未找到精确匹配}。

组合优化：用户寻找满足多维资源约束且成本最低的规格，是一个多维背包问题的简化版，但可选集合S很小。
几何：将规格和需求视为多维空间中的点。规格矩阵M是该空间的离散点集。用户需求点D可能不在M中，必须选择M中一个支配D（各维度均>=）且成本最低的点。
经济学：通过捆绑销售，平台可以获取消费者剩余，用户为不需要的资源付费。

用户需要高内存实例，但发现平台提供的规格中，内存大的规格必然搭配更多的vCPU和更高的网络带宽，导致总价远超预期。用户被迫为不需要的vCPU付费。

属于产品定价和配置自由。但若规格配比严重偏离行业标准或常识，可能被视为利用市场地位进行不合理搭售。

1. 用户分析应用需求：需要8vCPU， 64GiB内存， 中等网络带宽。
2. 用户查看实例规格表，发现没有(8,64)的组合。最接近的是：
- 规格A: (8, 32) - 内存不足。
- 规格B: (16, 64) - vCPU超出需求。
3. 用户必须选择规格B，为多出的8个vCPU付费。
4. 或者，用户可以选择两个规格A实例，但增加了管理复杂度。
方程：Find s in S such that s.c >= need_c and s.m >= need_m and s.b >= need_b; Minimize Price(s);

顺序序列（用户定义需求->查询规格表->选择最小可行规格->接受资源浪费）。

规格选择复杂度O(

P7-0040

云计算/平台商业策略与技术锁定

抢占式实例中断预测不准确

提供的抢占式实例中断预测不准确，用户无法可靠规划。

商业策略/风险信息质量

平台为抢占式实例提供中断预测信号P(t)，如“未来N分钟内被中断的概率”。该预测基于历史数据和当前容量情况，但准确率有限。实际中断事件E(t)的发生与预测P(t)相关性低，导致用户无法有效做出应对（如保存状态、启动替代实例）。

抢占式实例中断预测引擎

1. 预测生成：平台根据资源供需情况、预留实例到期、硬件维护计划等因素，计算并发布每个抢占式实例的中断概率P(t)或剩余时间估计T_estimate。
2. 预测不确定性：预测模型可能过于简单，未充分考虑突发性需求或内部调度策略变化。因此，预测误差ε(t) =

E(t) - P(t)

较大。
3. 用户依赖：用户根据P(t)做出决策，例如当P(t)超过阈值θ时，开始执行检查点操作。由于预测不准，可能导致：
a. 误报：P(t)高但未中断，用户执行了不必要的检查点，产生开销。
b. 漏报：P(t)低但实例突然中断，用户丢失状态。
4. 风险转移：平台通过提供预测（即使不准）将中断风险管理的责任部分转移给用户，同时降低因中断导致用户损失而引发的投诉。
数学方程：
• 中断事件：E(t) ∈ {0, 1}，1表示在时间t发生中断。
• 中断预测：P(t) ∈ [0, 1]，表示在时间t预测的中断概率。
• 预测误差：ε(t) =

E(t) - P(t)

。长期平均误差Mean(ε)可能很高。
• 用户决策函数：Action(t) = f(P(t), θ)。例如，f可以是如果P(t) > θ则启动检查点。
• 用户成本：Cost_user = C_checkpoint * N_false_alarm + C_data_loss * N_miss。

预测P(t)本身是一个数值，但其作为E(t)的预测指标，准确率低，存在“预测误差”。

时间序列预测、风险管理、信号处理。

使用抢占式实例的成本敏感型工作负载（如批处理、容错计算）。

E(t): 实际中断事件（二值）；P(t): 预测中断概率；ε(t): 预测误差；θ: 用户决策阈值；C_checkpoint: 检查点成本；C_data_loss: 数据丢失成本。

实例状态：{运行， 中断警告(预测)， 中断中， 已终止}。预测准确状态：{准确， 误报， 漏报}。

统计学：预测P(t)与实际E(t)的相关系数低。预测可以视为一个二分类器，其精确率、召回率可能都不高。
决策理论：用户在不确定预测下做出决策，期望成本最小化。不准确的预测增加了期望成本。
随机过程：中断事件E(t)是一个随机过程，平台试图预测其强度函数λ(t)，但预测不准。

控制台或API显示“此实例可能在60分钟后被中断”。但实例在5分钟后突然中断，或在2小时后仍正常运行。用户无法信赖该预测。

预测通常被声明为“仅供参考，不构成保证”。平台借此规避因中断造成的责任。但若预测系统性偏差极大，可能被视为未提供合理的工具来管理风险。

P7-0041

云计算/平台商业策略与技术锁定

自动伸缩组负载均衡器绑定

自动伸缩组必须绑定平台负载均衡器，无法使用第三方方案。

技术锁定/生态绑定

平台自动伸缩组服务ASG需要绑定一个负载均衡器LB作为流量入口。ASG仅支持绑定平台自家的负载均衡器服务（如ELB, ALB, NLB），不支持绑定用户自建或第三方的负载均衡器。

自动伸缩组负载均衡器锁定引擎

1. 架构强制：创建或配置ASG时，必须指定一个目标组或负载均衡器，且该负载均衡器必须是平台提供的托管服务。
2. 排除替代方案：用户无法将ASG实例注册到：
a. 自己部署在EC2上的负载均衡软件（如HAProxy, Nginx）。
b. 其他云厂商或IDC的负载均衡器。
c. 基于DNS的全局负载均衡器。
3. 增加成本和锁定：用户必须为平台负载均衡器付费，即使其功能过剩或不符合特定需求（如需要特定自定义模块）。这增加了成本并加深了对平台特定服务的依赖。
4. 限制架构灵活性：混合云或多云架构中，希望用统一负载均衡器管理流量时，此限制成为障碍。
数学方程：
• 自动伸缩组配置：Config_ASG = (Launch_Template, MinSize, MaxSize, LB_Target)。
• 允许的LB_Target集合：L_allowed = {平台提供的LB服务}。
• 用户期望的LB_Target集合：L_desired可能包含 L_self_hosted, L_third_party。
• 约束：LB_Target ∈ L_allowed。因此，如果L_desired ⊄ L_allowed，则用户无法使用ASG，或必须接受使用平台LB。
• 额外成本：Cost_extra = Cost_platform_LB - Cost_desired_LB。

绑定操作在约束内成功。但约束本身排除了用户更优或更经济的选择，存在“架构灵活性误差”。

系统设计、供应商锁定、互操作性。

配置自动伸缩组以实现横向扩展的应用。

Config_ASG: 自动伸缩组配置；LB_Target: 负载均衡器目标；L_allowed: 平台允许的负载均衡器集合；L_desired: 用户期望的负载均衡器集合；Cost_extra: 额外成本。

自动伸缩组状态：{创建中(需指定LB)， 运行中(绑定平台LB)}。负载均衡器选项状态：{平台LB可用， 自建LB不可选}。

集合论：允许的负载均衡器集合L_allowed是平台服务集合的一个子集，且是用户可选集合的上限。
图论：架构是一个有向图，从LB到ASG实例的边必须使用平台提供的LB节点类型。
网络效应：通过强制使用平台LB，增加了该服务的用户基数和锁定效应。

在ASG配置向导中，“负载均衡器”下拉菜单只列出平台自家的负载均衡器。文档明确说明“自动伸缩组仅支持与 [平台LB服务] 集成”。尝试通过API指定自建LB的ARN会返回验证错误。

属于平台服务的设计选择。但可能违反某些地区关于反竞争行为的规定，如果该绑定被认定为滥用市场支配地位排除其他负载均衡器供应商。

1. 用户创建自动伸缩组ASG。
2. 在配置页面，必须选择一个“目标组”或“负载均衡器”。
3. 用户只能从平台提供的负载均衡器列表中选择，无法输入自建LB的IP或DNS。
4. 用户若想使用自建HAProxy，必须放弃ASG的自动注册功能，转而编写自定义脚本，在实例启动时向HAProxy注册，增加了复杂度。
5. 用户被迫使用平台LB并支付相应费用。
方程：if (LB_target not in PLATFORM_MANAGED_LB_LIST) { throw error("Unsupported load balancer type"); }

顺序序列（配置ASG->选择LB->发现限制->妥协或寻找变通方案）。

ASG配置复杂度低。用户实现替代方案的复杂度高（需自定义生命周期钩子和脚本）。

自动伸缩、负载均衡、服务发现、基础设施即代码。

P7-0042

云计算/平台商业策略与技术锁定

实例休眠状态保存不完整

实例休眠后恢复，部分设备状态丢失（如GPU显存内容）。

技术限制/状态持久化缺陷

实例休眠功能Suspend_to_Disk将实例的系统内存内容保存到持久存储，但可能不保存某些特定设备（如GPU、TPU、FPGA）的显存或内部状态。恢复时，这些设备状态被重置，导致应用出错或性能下降。

部分状态休眠引擎

1. 休眠过程：休眠时，平台将CPU和系统内存状态保存到存储卷。但对于专用加速器设备（如GPU），其设备驱动和硬件可能不支持完整的上下文保存/恢复，或者平台选择不实现此功能以简化设计。
2. 状态丢失：GPU显存中的模型参数、中间计算结果等数据在休眠后丢失。恢复时，GPU设备被重新初始化，显存为空白。
3. 应用影响：依赖GPU显存中数据的应用（如长时间训练的机器学习任务、科学计算）在恢复后无法继续，必须从头开始或从上一个检查点恢复，造成时间和计算资源浪费。
4. 信息缺失：平台可能不会明确警告用户休眠会导致GPU状态丢失，用户可能误以为休眠是“完全冻结”。
数学方程：
• 实例完整状态：State_full = {CPU_registers, RAM, GPU_memory, GPU_registers, Other_devices_state}。
• 实际保存状态：State_saved = {CPU_registers, RAM}。可能不包括GPU_memory等。
• 恢复后状态：State_resumed = State_saved ∪ State_default_devices，其中State_default_devices是设备的默认初始化状态。
• 状态差异：ΔState = State_full - State_resumed。对于GPU应用，ΔState包含关键数据，导致应用失败。
• 应用连续性：App_continuation_possible = False if ΔState ∩ App_critical_data ≠ ∅。

休眠和恢复操作本身成功。但恢复后的实例状态不完整，与用户期望的“完全状态保存”存在“状态一致性误差”。

操作系统休眠机制、设备驱动程序、加速器架构。

使用GPU、TPU等加速器的实例进行长时间计算任务时使用休眠功能。

State_full: 实例完整状态；State_saved: 实际保存到

P7-0043

云计算/平台商业策略与技术锁定

实例初始化执行时间限制

自定义启动脚本（cloud-init）执行时间有限制，复杂脚本可能被截断。

技术限制/初始化流程控制

平台为实例初始化阶段设置最大执行时间T_max。cloud-init或其他启动脚本必须在此时间内完成，否则将被强制终止，未完成的步骤被跳过。

启动脚本执行时限引擎

1. 启动阶段定义：实例启动过程分为多个阶段，其中cloud-init或用户数据脚本执行阶段被分配固定时间预算T_budget，通常T_budget是T_max的一部分（如整体启动超时时间）。
2. 脚本执行监控：启动管理器监控脚本执行时间T_elapsed。当T_elapsed >= T_max时，管理器发送终止信号（如SIGKILL）给脚本进程。
3. 执行不完整：复杂初始化任务（如安装大型软件包、从网络下载数据、等待外部依赖就绪）可能超时。脚本被强制终止，导致实例配置不完整，服务无法正常启动。
4. 诊断困难：启动失败日志可能仅显示“启动超时”，而不指明是哪个具体步骤慢，用户调试困难。
数学方程：
• 脚本执行时间：T_script = f(Workload, Network_Speed, Disk_IO)。
• 成功条件：Init_Success = 1 if T_script <= T_max else 0。
• 实例状态：Instance_State(t) = {Booting if t < T_max and script_running; Running if Init_Success=1; Failed if Init_Success=0}。
• 用户损失：Loss = Cost_of_partial_config + Downtime_cost。

计时精确。但时间限制T_max是固定的，与脚本实际复杂度不匹配，存在“执行时间预期误差”，导致初始化失败。

进程调度、超时机制、初始化顺序。

任何通过用户数据（user-data）或自定义镜像进行复杂初始化的云实例。

T_max: 启动脚本最大允许执行时间；T_script: 脚本实际执行时间；Workload: 脚本工作负载复杂度；Init_Success: 初始化成功标志。

启动脚本状态：{未开始， 执行中， 完成， 超时终止}。实例启动状态：{等待脚本， 脚本执行中， 启动成功， 启动失败(脚本超时)}。

最优化：用户需在T_max内完成所有初始化任务，这是一个带时间约束的优化问题。
排队论：初始化任务可视为一个服务队列，总服务时间必须小于T_max。
可靠性工程：启动成功率P(Init_Success) = P(T_script ≤ T_max)。

实例启动失败，系统日志显示“cloud-init timeout”。用户必须简化启动脚本，或将其拆解到启动后由cron/systemd执行。文档可能提到启动超时，但未给出明确的T_max值。

属于平台对启动流程的合理性控制。但如果T_max设置过短，且未提供调整机制，导致常规初始化任务频繁失败，则可能构成服务缺陷。

1. 实例启动，开始执行cloud-init。
2. cloud-init解析用户数据，开始执行用户脚本S。
3. 同时，启动管理器启动计时器，计时T_elapsed。
4. 脚本S执行，例如apt-get update && apt-get install -y large-package。
5. 网络慢或包大，T_elapsed接近T_max。
6. 当T_elapsed >= T_max时，管理器终止cloud-init进程。
7. 实例继续启动，但软件包未安装完，服务启动失败。
方程：if (cloud_init_start_time + T_max < now) { kill_process(cloud_init_pid); mark_instance_boot_failed(); }

顺序序列（启动->执行脚本->计时->超时检查->终止）。脚本内部可能是并行下载安装。

脚本执行复杂度由任务决定。用户调试和拆分初始化任务的复杂度高。

操作系统启动、配置管理、cloud-init。

P7-0044

云计算/平台商业策略与技术锁定

资源分组与功能访问绑定

必须将实例放入资源组才能使用某些功能，但资源组有数量限制。

商业策略/功能分级与访问控制

平台引入资源组（Resource Group）概念，作为资源管理和策略应用的基本单元。某些高级功能F（如特定监控视图、成本分配报告、策略继承）仅对属于资源组的实例可用。但每个账户或区域有资源组数量上限N_max_rg。

资源组配额与功能绑定引擎

1. 功能条件访问：平台定义功能集F_set。对于功能f ∈ F_set，其访问条件为：Access(f, Resource) = True iff Resource ∈ RG，其中RG是一个资源组。
2. 资源组配额：账户可创建的资源组数量

RG_set

≤ N_max_rg。N_max_rg可能较小（如200个），对于大型企业或复杂环境可能不够。
3. 管理困境：用户为使用功能F，必须将资源分组。但受限于N_max_rg，可能无法为每个逻辑应用或团队创建独立的资源组，被迫将不相关的资源合并，破坏了资源组的逻辑清晰性，也影响了基于资源组的策略（如权限、预算）的精度。
4. 诱导升级：平台可能通过提高N_max_rg来吸引企业级订阅或额外付费。
数学方程：
• 资源组集合：RG_set = {RG1, RG2, ..., RG_m}, m ≤ N_max_rg。
• 功能访问函数：Access(f, R) = 1 if ∃ RG ∈ RG_set such that R ∈ RG else 0。
• 资源逻辑分区需求：假设用户有P个逻辑项目/团队，理想上需要P个资源组，即P =

RG_ideal

。
• 约束冲突：如果P > N_max_rg，则用户必须合并，即创建映射函数M: RG_ideal -> RG_actual，其中

RG_actual

≤ N_max_rg。这导致信息损失和管理粒度下降。

功能访问控制精确。但资源组数量限制N_max_rg与用户实际管理需求P之间存在“管理粒度误差”。

访问控制、资源组织、配额管理。

需要按项目、环境、团队精细化管理资源和成本的企业账户。

RG_set: 资源组集合；N_max_rg: 资源组数量上限；Access(f, R): 资源R对功能f的访问权限；P: 用户理想资源组数量（逻辑分区数）。

资源状态：{未分组， 已加入资源组RG_x}。功能可用性状态：{可用(资源已分组)， 不可用(资源未分组)}。

集合论：资源组是资源的集合。功能访问定义在资源组集合的幂集上。
组合数学：在N_max_rg限制下，将大量资源分配到有限资源组的方法数。
最优化：用户需在满足功能需求和不超过N_max_rg的条件下，最优地对资源进行分组，以最小化管理混乱。

P7-0045

云计算/平台商业策略与技术锁定

实例访问代理服务货币化

通过堡垒机或连接代理访问实例需额外付费。

商业策略/安全功能货币化

平台提供托管会话管理服务（如SSM Session Manager, Bastion Host），作为访问实例（特别是私有子网实例）的推荐安全方式。该服务按会话时长或数据流量收费，而传统的SSH/RDP直连（如果网络可达）免费。

托管会话计费引擎

1. 安全最佳实践推广：平台文档和架构推荐使用其托管会话服务进行实例访问，理由是更安全（无需开放入站端口、日志记录完整）。
2. 按需计费：该服务通常按会话时间（小时）或通过会话传输的数据量（GB）计费。例如，费率R_session per hour。
3. 成本对比：传统方式下，用户通过公网IP或VPN访问实例，只需支付实例和带宽费用。使用托管会话，增加了会话费用Cost_session = R_session * T_session。
4. 诱导使用：平台可能通过简化配置（如与IAM集成）来降低使用托管会话的门槛，同时将直连访问的配置复杂化（如需要配置和管理安全组、NAT网关等），从而引导用户使用付费服务。
数学方程：
• 会话时长：T_session 从连接建立到断开。
• 会话费用：Cost_session = R_session * ceil(T_session)。（可能按小时取整）
• 总访问成本：Cost_access = Cost_instance_bandwidth + Cost_session。其中Cost_session是新引入的成本项。
• 用户决策：使用托管会话 if (Security_Benefit + Convenience_Benefit) > Cost_session，但平台通过营销夸大前两者，使用户高估收益。

会话计时和计量精确。但将原本可通过标准协议免费实现的功能包装为付费服务，存在“功能货币化误差”，增加了用户成本。

安全即服务、价格歧视、默认选项。

访问没有公网IP或位于私有子网的云实例。

T_session: 会话连接时长；R_session: 会话服务费率（$/小时）；Cost_session: 会话费用；Security_Benefit: 用户感知的安全收益；Convenience_Benefit: 用户感知的便利收益。

实例访问状态：{可通过SSH/RDP直连， 仅可通过会话服务连接}。会话服务状态：{会话中(计费)， 未使用}。

经济学：将安全性和便利性商品化并定价。用户对安全的需求缺乏弹性，平台可收取溢价。
最优化：用户权衡成本、安全性和便利性。平台通过设计使付费选项的感知净收益最大化。

控制台实例连接按钮默认提供“会话管理器连接”选项，而“SSH客户端连接”选项可能隐藏或需要更多配置。定价页面列出会话管理器的价格。

属于增值服务。但如果平台故意弱化或阻碍免费的替代访问方式，迫使用户使用付费服务，则可能构成搭售或限制交易。

1. 用户需要登录私有子网中的实例I进行调试。
2. 控制台提供“连接”按钮，点击后主要推荐“使用会话管理器连接”。
3. 用户点击该选项，浏览器打开一个新的终端窗口连接到实例I。
4. 会话开始，计费系统开始计时。
5. 用户工作30分钟后断开连接。
6. 账单中产生一笔会话管理器费用（如0.1小时 * R_session）。
方程：Session_Cost = Session_Duration_Hours * Hourly_Rate

顺序序列（用户发起连接->选择会话服务->建立会话(开始计费)->工作->断开会话(停止计费)）。

使用会话服务的复杂度低。建立免费直连的复杂度可能更高（需配置网络）。

特权访问管理、堡垒主机、零信任网络。

P7-0046

云计算/平台商业策略与技术锁定

虚拟机代际硬件架构断裂

新一代虚拟机与旧代不兼容，迁移需重装应用。

技术锁定/硬件升级强制迁移

平台发布新一代虚拟机实例类型G_new，基于全新的硬件架构（如从x86切换到ARM， 或从Intel切换到AMD， 或CPU微架构巨变）。旧代G_old的虚拟机镜像（AMI）无法直接在G_new上启动，因为需要不同的内核驱动、固件或指令集支持。

虚拟机代际不兼容引擎

1. 架构切换：G_new使用与G_old不同的CPU ISA（如ARM vs x86）或需要不同的虚拟化扩展、设备驱动。这导致为G_old编译的操作系统内核和驱动程序无法在G_new上运行。
2. 镜像不兼容：平台明确声明G_old的AMI与G_new不兼容。用户尝试在G_new上启动G_old的AMI会失败，错误为“不支持的硬件”或“无法启动”。
3. 迁移成本：用户必须为迁移到G_new创建新的虚拟机镜像，通常需要：
a. 从G_old实例导出应用和数据。
b. 基于G_new兼容的基础镜像启动新实例。
c. 重新安装和配置所有应用软件。
d. 导入数据。
这相当于应用重装，而非简单的“升降级”。
4. 锁定强化：即使用户不希望使用G_new，但由于G_old终将被淘汰（P7-0001），用户最终被迫进行复杂的迁移，增加了对平台的依赖（因为迁移过程复杂，用户更不愿考虑跨云迁移）。
数学方程：
• 虚拟机镜像集合：I = {I_old, I_new}。
• 实例类型兼容性矩阵：C(I, G) ∈ {0, 1}，其中C(I_old, G_new) = 0。
• 启动函数：Launch(I, G) = Success if C(I, G) = 1 else Failure。
• 迁移工作量：Workload_migration = Cost_reinstall + Cost_data_migration + Cost_testing。
• 用户选择：当G_old被淘汰时，用户必须执行Workload_migration以迁移到G_new，或寻找其他平台（可能面临同样问题）。

兼容性判断是精确的。但架构断裂导致的迁移成本Workload_migration与简单重启的预期存在“迁移复杂度误差”。

计算机体系结构、向后兼容性、技术换代。

从Intel x86实例迁移到AWS Graviton (ARM) 实例，或任何涉及CPU架构变更的代际升级。

I_old, I_new: 新旧虚拟机镜像；G_old, G_new: 新旧实例类型；C(I, G): 兼容性函数；Workload_migration: 迁移工作量。

镜像兼容性状态：{兼容于G_old， 兼容于G_new}。迁移状态：{需迁移， 迁移中， 迁移完成}。

集合论：镜像集合和实例类型集合之间存在一个二分图兼容关系。代际切换可能使这个二分图变得不连通。
图论：迁移路径：从(I_old, G_old)状态节点到(I_new, G_new)状态节点，没有直接边，必须经过复杂的“重装”路径。
成本分析：迁移的沉没成本很高，增加了用户粘性。

控制台启动实例时，如果选择G_new实例类型，之前的自定义AMI在“镜像”下拉列表中不可见或显示为灰色。文档明确说明ARM和x86镜像不兼容。

属于技术进步中的合理不兼容。但如果平台在销售G_old时未充分告知未来向G_new迁移的重大困难，用户可能依据“持续兼容”的合理预期进行投入，后因迁移成本过高而受损。

1. 用户一直在使用基于Intel的C5实例（G_old），并创建了自定义AMI_I_x86。
2. 平台推出基于ARM的Graviton C6g实例（G_new），性价比更高。
3. 用户尝试用AMI_I_x86启动C6g实例，启动失败，提示“架构不匹配”。
4. 用户必须：启动一个ARM基础镜像的新实例，手动安装所有软件，配置应用，从旧实例同步数据，测试，然后创建新的AMI_I_arm。
5. 用户完成迁移，旧AMI_I_x86作废。
方程：if (instance_type.arch != image.arch) { fail_launch("Architecture mismatch"); }

顺序序列（使用G_old->G_new发布->尝试启动失败->重装应用->创建新镜像->迁移完成）。

兼容性检查复杂度O(1)。应用重装和数据迁移的复杂度高。

指令集架构、操作系统移植、应用兼容性。

P7-0047

云计算/平台商业策略与技术锁定

监控数据聚合与展示延迟

控制台显示的性能监控数据有5-10分钟延迟，无法实时响应问题。

技术限制/数据新鲜度控制

平台监控服务以固定间隔（如1分钟）从虚拟机监控代理采集指标数据。数据经过聚合、传输、存储和索引后，才能在控制台或API中查询到。此端到端流水线引入延迟ΔT_latency，通常为5-10分钟。

监控数据延迟流水线引擎

1. 数据采集：监控代理每T_interval（如60秒）采集一次指标，生成一个数据点D(t)。
2. 数据传输与处理：D(t)被发送到监控后端，进行验证、聚合（如需）、写入时间序列数据库。此过程耗时ΔT_process。
3. 数据可用性：数据点D(t)在时间 t + ΔT_latency 后才可被查询，其中ΔT_latency = T_interval/2（平均） + ΔT_process + ΔT_index。通常ΔT_process是主要部分。
4. 实时性缺失：当实例发生性能故障（如CPU 100%）时，用户无法在控制台实时看到，必须等待ΔT_latency。这延误了故障检测和响应，尤其对于自动化的伸缩或修复策略。
5. 替代方案缺乏：平台不提供更低延迟（如秒级）的监控数据流，或将其作为付费高级功能。
数学方程：
• 数据采集时间序列：D(t_i), t_i = i * T_interval。
• 数据可用时间：t_available(t_i) = t_i + ΔT_latency。
• 当前可观测数据点：D_observable(now) = D(t_i) where t_i = max{ t_i

t_available(t_i) ≤ now }。
• 信息延迟：Latency_info = now - t_i。通常 Latency_info ≈ ΔT_latency ∈ [5min, 10min]。
• 对自动化的影响：自动化策略基于过时数据决策，可能行动迟缓或不当。

数据本身准确，但存在固定的、已知的“时间延迟误差”ΔT_latency，影响实时性。

数据流水线、监控系统、控制理论中的观测延迟。

依赖控制台或API监控数据进行故障排查和自动化运维的场景。

T_interval: 监控数据采集间隔；ΔT_latency: 端到端数据延迟；D(t_i): 在时间t_i采集的数据点；t_available: 数据点可查询的时间。

数据点状态：{已采集， 传输处理中， 已可查询}。控制台视图状态：{显示延迟数据}。

时间序列分析：观测到的时间序列是原始时间序列的延迟版本：Y(t) = X(t - ΔT_latency)。
控制理论：观测延迟降低了反馈控制系统的稳定性边界，可能导致振荡或响应迟缓。
排队论：监控数据处理流水线可以建模为一个排队网络，ΔT_latency是排队延迟。

控制台监控图表下方有小字“数据延迟约5分钟”。当实例发生故障时，用户刷新控制台，图表显示几分钟前还是正常的。实时故障检测需依赖自定义的、更频繁的日志检查或第三方工具。

服务等级协议(SLA)通常不承诺监控数据的实时性。延迟属于已知的技术限制。但如果延迟过长且未充分披露，影响用户基本运维能力，则可能构成服务可用性问题。

1. 时间t0，实例CPU使用率飙升至100%。
2. 监控代理在t1 = t0 + 30s（假设采集中点）采集到该高CPU数据点D(t1)。
3. 数据点D(t1)被发送，在监控后端处理，在t2 = t1 + ΔT_latency（例如7分钟后）才被写入数据库并可查询。
4. 用户在t0到t2期间查看控制台，看到的仍是正常CPU数据。
5. 在t2之后，用户才能在图表上看到t1时刻的CPU尖峰。
方程：`Data_Visible_At_Time(t) = { D(t')

t' <= t - ΔT_latency }`

流水线序列：采集->传输->处理->存储->索引->查询。每个步骤引入延迟，整体是顺序序列。

P7-0048

云计算/平台商业策略与技术锁定

实例克隆网络标识符重置

克隆实例时网络配置（如MAC地址）重置，影响许可证绑定。

技术限制/网络身份管理

实例克隆功能Clone(Instance)会创建源实例的一个副本，包括其磁盘状态。但是，克隆生成的新实例的网络接口会被分配全新的网络标识符，包括MAC地址、内网IP地址（除非指定）、以及可能的主机名。这与源实例不同。

网络标识符重置引擎

1. 克隆过程：克隆时，源实例的系统盘状态被复制。但网络配置被视为“环境特定”信息，在目标实例启动时被重新生成。
2. MAC地址变更：网络接口控制器（NIC）的MAC地址是全局唯一的。克隆时，平台虚拟化层会为新实例的虚拟NIC生成一个新的MAC地址，而不是复制源实例的MAC。
3. 许可证影响：某些软件许可证（尤其是传统的、以硬件锁形式授权的软件）绑定到特定的硬件标识符，如MAC地址。克隆后，新实例的MAC地址改变，导致许可证失效，软件需要重新激活或授权。
4. 配置不一致：如果应用配置中硬编码了源实例的IP或主机名，克隆后可能也需要更新。
数学方程：
• 源实例网络标识符：ID_src = {MAC_src, IP_src, Hostname_src, ...}。
• 克隆操作：Clone(I_src) -> I_dst。
• 目标实例网络标识符：ID_dst = {MAC_new, IP_new, Hostname_new, ...}，其中 MAC_new != MAC_src (以极高概率)。
• 许可证检查函数：License_Valid(I) = 1 if MAC(I) ∈ Authorized_MAC_List else 0。
• 克隆后许可证状态：License_Valid(I_dst) = 0，因为 MAC_dst ∉ Authorized_MAC_List。
• 用户需将MAC_dst添加到授权列表或联系供应商重新授权。

MAC地址生成是随机的，与源地址不同的概率接近1。这与用户期望的“完全副本”存在“网络身份误差”，导致许可证问题。

网络寻址、软件许可证管理、虚拟化。

使用绑定MAC地址或主机名等硬件标识符的专有软件许可证的场景。

ID_src, ID_dst: 源和目标实例的网络标识符集合；MAC_src, MAC_dst: MAC地址；License_Valid(): 许可证验证函数；Authorized_MAC_List: 已授权的MAC地址列表。

实例网络标识状态：{原始MAC， 新MAC(克隆后)}。许可证状态：{有效， 失效}。

组合数学：MAC地址空间巨大，随机碰撞概率极低，因此克隆后几乎必然不同。
集合论：授权标识符集合是固定的。克隆操作产生的标识符不在该集合中。
函数映射：克隆函数在网络标识维度上不是一个恒等映射，而是一个随机映射。

用户克隆一个已安装并激活了某商业数据库的实例。克隆出的新实例启动后，数据库服务无法启动，日志显示“许可证无效”或“硬件变更”。用户需重新申请许可证。

属于技术实现细节。软件供应商的许可证条款通常禁止克隆或要求在克隆后重新授权。用户需自行管理许可证合规性。

1. 用户有一个运行专有软件S的实例I_src，S的许可证绑定到I_src的MAC地址MAC_old。
2. 用户通过控制台克隆功能创建I_dst。
3. I_dst启动，被分配新MAC地址MAC_new。
4. 软件S启动，检测到MAC地址变为MAC_new，与许可证文件不匹配，拒绝运行或进入试用模式。
5. 用户必须联系软件供应商，为MAC_new申请新许可证，可能涉及额外费用。
方程：if (cloning) { new_instance.mac_address = generate_random_mac(); }

顺序序列（克隆源实例->启动目标实例(分配新MAC)->软件启动检测->许可证失败->重新授权）。

克隆操作复杂度O(磁盘大小)。解决许可证问题的复杂度中等，涉及外部供应商。

软件许可证、硬件标识符、设备驱动。

P7-0049

云计算/平台商业策略与技术锁定

虚拟机调度策略不开放

不允许用户自定义虚拟机调度算法，无法优化资源利用。

技术锁定/资源调度黑盒

平台调度器决定虚拟机在物理机上的放置。其调度算法S是黑盒，用户无法提供自定义策略或偏好（如“将我的这两个实例尽量放置得靠近以减少网络延迟”或“将我的实例与高I/O实例隔离”）。

黑盒资源调度引擎

1. 调度不透明：如前所述（P7-0035），调度算法S的目标函数和约束对用户不可见。用户提交启动请求，S返回一个放置结果，用户只能接受。
2. 无自定义接口：平台不提供API或配置允许用户传递调度提示（scheduling hints），如亲和性（affinity）、反亲和性（anti-affinity）、对特定硬件类型的偏好等。
3. 性能优化受限：用户无法通过调度策略优化应用性能。例如，分布式缓存系统希望实例在同一个机架以减少延迟；批处理任务希望分散在不同物理机以避免资源争用。这些都无法实现。
4. 资源利用率次优：从全局看，平台的调度算法可能优化整体利用率，但对个体用户的应用特征不感知，可能导致用户层面的资源利用率低下（如因干扰导致需要更多实例）。
数学方程：
• 调度请求：Req = {VM specifications, quantity}。
• 调度结果：Placement = S(Req, Cluster_State)，其中S是黑盒函数。
• 用户优化目标：O_user(Placement) ，例如最小化实例间网络延迟，或最大化CPU缓存共享。
• 实际结果：用户无法影响S，因此O_user(Placement)是一个随机变量，其期望值可能远离用户最优值。
• 用户成本：由于次优放置，用户可能需要超额配置资源来达到性能目标，增加成本。

调度结果确定，但调度逻辑对用户隐藏。用户无法使调度结果适配其特定目标，存在“调度适应性误差”。

资源调度、优化理论、算法博弈论。

高性能计算、低延迟分布式系统、对性能干扰敏感的应用。

Req: 虚拟机启动请求；S: 平台调度算法（黑盒）；Placement: 调度放置结果；O_user(): 用户的优化目标函数。

调度过程状态：{请求提交， 调度中(黑盒)， 已调度}。调度结果质量状态：{对用户优， 对用户次优}。

优化理论：用户有一个优化问题，但决策变量（放置）由黑盒函数S控制，用户无法求解。
博弈论：用户是调度博弈的参与者，但策略空间受限，只能提交请求，不能影响调度规则。
随机过程：对用户而言，调度结果可以视为一个随机变量，其分布由S和集群状态决定。

用户启动多个实例，无法控制它们被放置在同一台物理机还是不同物理机。控制台不显示物理位置信息。用户请求支持将某些实例“钉”在一起，被告知不支持。

属于平台核心基础设施的管理权。通常认为这是平台合理的技术自主权。但在某些场景（如HPC），缺乏调度控制可能使服务不适合专业用途。

1. 用户需要启动4个实例组成一个分布式内存缓存集群。
2. 用户依次启动4个实例I1, I2, I3, I4。
3. 调度器S独立地处理每个请求，将I1放在主机H1，I2放在H2，I3放在H1，I4放在H3。
4. 实例间网络延迟不一致，I1与I3延迟低（同主机），但与I2/I4延迟高。
5. 缓存集群性能因跨节点延迟而下降，但用户无法请求将4个实例都调度到同一台主机或同一个机架。
方程：for each vm in request_vms: host = schedule(vm, available_hosts); // schedule() is opaque

并行或顺序序列：多个启动请求被独立调度。调度决策是瞬间的黑盒操作。

调度算法复杂度是平台内部的。用户实现应用层性能优化的复杂度高（需容忍可变性）。

资源调度、高性能计算、软件定义数据中心。

P7-0050

云计算/平台商业策略与技术锁定

实例保护机制存在例外

即使启用终止保护，平台维护操作仍可强制终止实例。

技术限制/服务管理权高于用户配置

平台提供“终止保护”功能，旨在防止用户误操作终止实例。当启用时，通过控制台或API的普通终止操作会被拒绝。但此保护不适用于平台发起的维护操作（如硬件故障、安全漏洞修复需要重启）。

终止保护例外引擎

1. 保护范围定义：终止保护标志P_termination_protection = True时，系统拦截用户发起的TerminateInstanceAPI调用或控制台操作。
2. 平台例外：在内部维护策略中，定义了一组“特权”终止操作O_privileged，这些操作绕过P_termination_protection检查。O_privileged可能包括：
a. 因物理主机硬件故障导致的实例终止。
b. 因安全事件（如漏洞）需要强制隔离或销毁实例。
c. 因用户违反可接受使用政策（AUP）而采取的强制措施。
3. 用户预期不符：用户启用终止保护是期望实例不会被意外终止，但平台例外条款使得实例仍可能在用户不知情或非计划内被终止，导致服务中断。
4. 风险告知不足：关于例外情况的说明可能隐藏在服务条款的深处，用户容易忽略。
数学方程：
• 终止请求：Req = (Action=Terminate, Instance=I, Initiator={User, System})。
• 保护状态：P(I) ∈ {0, 1}。
• 终止决策：Decision(Req) = Allow if (Initiator=System) OR (Initiator=User AND P(I)=0) else Deny。
• 用户可用性期望：A_user_expected = 1 (当P(I)=1时，认为实例不会被终止)。
• 实际可用性：A_actual = 1 - P(System initiates termination)。由于存在系统发起的终止，A_actual ≤ A_user_expected。
• 期望差距：Gap = A_user_expected - A_actual = P(System initiates termination) > 0。

对用户发起的终止操作拦截精确。但系统发起的终止构成了“保护可靠性误差”，使用户的可用性预期落空。

故障处理、安全策略、例外管理。

对实例持续性有极高要求的场景，用户启用终止保护以防误操作。

P(I): 实例I的终止保护状态；Req: 终止请求；Initiator: 请求发起方（用户或系统）；A_user_expected: 用户期望的可用性；A_actual: 实际可用性。

实例保护状态：{终止保护已启用}。终止请求状态：{用户请求(被拒绝)， 系统请求(被执行)}。

逻辑：终止允许的条件是 (Initiator=System) ∨ (¬P(I) ∧ Initiator=User)。这是一个带有例外的逻辑规则。
概率：实例存活概率P(survive) = 1 - P(user_error) - P(system_forced)，其中终止保护只能防御P(user_error)。
集合论：可终止实例集合是 {所有实例} 减去 {被用户保护且未被系统例外的实例}。

控制台实例详情中有“启用终止保护”复选框。文档中可能有一行小字“终止保护不适用于平台发起的维护或执行服务条款所需的操作”。当实例因主机故障突然终止时，用户发现尽管有保护也无济于事。

服务条款通常规定平台有权进行必要的维护和运营操作。终止保护是防止用户误操作的工具，而非高可用性保证。用户需理解其局限性。

1. 用户对关键实例I启用终止保护。
2. 某日，平台检测到宿主机H存在不可修复的硬件故障，需立即关闭。
3. 平台调度系统对H上所有实例（包括I）发起强制终止操作，标记Initiator=System。
4. 终止保护检查发现Initiator=System，允许操作通过。
5. 实例I被终止，用户收到“实例因底层硬件问题而停止”的通知。
6. 用户发现终止保护未起作用。
方程：if (terminate_request.initiator == PLATFORM_SYSTEM) { allow_terminate(); } else if (instance.termination_protection_enabled) { deny_terminate(); } else { allow_terminate(); }

顺序序列（启用保护->系统检测到问题->系统发起终止->绕过保护->实例终止）。系统终止是突发事件。

保护检查复杂度O(1)。用户实现高可用（如多可用区部署）的复杂度高。

高可用性设计、容错、服务等级协议。

P7-0051

云计算/平台商业策略与技术锁定

实例类型区域供应不均衡

特定实例类型只在部分区域提供，用户为使用该实例类型必须将应用部署在特定区域，增加跨区域延迟和数据传输成本。

商业策略/产品区域化投放

平台将新发布的或特定的实例类型（如GPU加速型、高内存型）仅在部分区域（Region）R_subset上线，而非所有区域R_all。用户若需使用该实例类型T_special，必须将资源部署在R_subset内。

实例类型区域分布引擎

1. 区域供应矩阵：定义实例类型可用性矩阵A(T, R) ∈ {0, 1}。对于T_special，∃ R_subset ⊂ R_all，使得 ∀ R ∈ R_subset, A(T_special, R)=1；∀ R ∉ R_subset, A(T_special, R)=0。
2. 用户部署约束：用户应用对实例类型有需求D(T)。若D(T)包含T_special，则部署区域集合必须满足Deploy_Region ∈ R_subset。
3. 成本与延迟增加：用户的其他服务或用户可能位于R_other ∉ R_subset。将应用部署在R_subset会导致：
a. 跨区域数据传输成本Cost_cross_region。
b. 网络延迟增加Latency_increase = Latency(R_subset, R_other) - Latency(R_ideal, R_other)，其中R_ideal是用户原本计划部署的区域。
4. 锁定效应：一旦用户基于T_special在R_subset构建了应用，迁移到其他区域或云平台将面临硬件兼容性和数据迁移的双重挑战。
数学方程：
• 部署区域决策：Deploy_Region = {R

A(T_special, R)=1} ∩ {R

meets_other_constraints(R)}。
• 额外成本：Cost_extra = Σ Data_flow(i, j) * Price_cross_region，其中i ∈ Deploy_Region, j ∈ Other_Regions。
• 延迟惩罚：Latency_penalty = max{ Latency(Deploy_Region, User_location) - Latency_acceptable, 0 }。

实例类型在区域的可用性是精确的。但供应不均衡与用户全局部署需求存在“地理匹配误差”，导致额外成本和延迟。

产品发布策略、区域化运营、网络拓扑。

需要使用特定硬件（如最新GPU、FPGA）或特殊配置（如超大内存）实例的应用。

A(T, R): 实例类型T在区域R的可用性；R_subset: 提供T_special的区域子集；D(T): 应用所需的实例类型集合；Cost_cross_region: 跨区域数据传输单价；Data_flow: 跨区域数据流量。

实例类型状态：{在区域R可用， 在区域R不可用}。用户部署状态：{受限于特定区域， 可自由选择区域}。

集合论：实例类型可用区域是全集的一个子集。用户部署区域选择是该子集与其它约束集合的交集。
图论：将区域视为节点，跨区域流量和延迟视为边的权重。部署决策改变了流量图的源节点。
最优化：用户在实例类型需求、延迟约束和成本之间进行权衡。

控制台选择实例类型时，某些类型在某些区域下拉列表中显示为“不可用”。文档中有一张“区域服务可用性”表。用户为使用A100 GPU实例，必须将训练集群部署在us-east-1，而主要用户在欧洲，导致高延迟。

属于商业决策。但如果平台在销售时承诺全球可用，而后仅在特定区域提供，可能涉及虚假宣传。通常服务条款会注明“服务按区域提供”。

1. 用户应用需要T_special（如G5实例）。
2. 用户检查可用区域，发现仅在us-east-1和ap-northeast-1提供。
3. 用户主要市场和数据源在eu-central-1。
4. 用户被迫在us-east-1部署计算集群。
5. 数据从eu-central-1持续传输到us-east-1，产生跨区域流量费用。
6. 应用响应欧洲用户的请求延迟增加。
方程：if (instance_type == T_special && region not in R_subset) { launch_failed("Instance type not available in this region"); }

顺序序列（识别需求->检查区域可用性->权衡选择->部署到次优区域->承担额外成本）。

P7-0052

云计算/平台商业策略与技术锁定

实例停止状态关联资源持续计费

实例停止（stopped）状态仍对关联资源（如EBS卷、弹性IP）计费，用户误以为停止实例就不产生费用，导致账单意外增加。

定价模型/成本结构分离

实例计费状态函数C_instance(state) = { running_rate if state=running; 0 if state=stopped }。但关联资源如EBS卷、弹性IP的计费函数C_resource(state)与实例状态无关，只要资源存在就持续计费。

关联资源独立计费引擎

1. 状态分离计费：平台将实例本身（计算资源）与关联的存储、网络资源分开计费。
2. 实例停止效应：当实例状态从running变为stopped时，计算资源（vCPU，内存）被释放，C_instance变为0。
3. 关联资源持续存在：EBS卷、弹性IP等资源仍然存在并保持分配状态。它们的计费时钟继续运行：C_ebs = Storage_size * Price_per_GB_month, C_eip = Price_per_hour * T_allocation。
4. 用户认知偏差：用户通常认为“停止实例”等于“暂停所有费用”，忽略了关联资源的持续计费。这导致账单中仍有显著费用，用户感到意外。
5. 清理步骤遗漏：要完全停止费用，用户必须在停止实例后，手动删除（或释放）EBS卷和弹性IP。
数学方程：
• 实例总费用：Cost_total = C_instance(state) + Σ C_resource_i。
• 实例停止时：Cost_total(state=stopped) = 0 + Σ C_resource_i。
• 用户预期费用：Cost_user_expected(state=stopped) ≈ 0。
• 费用误差：Cost_error = Cost_total(state=stopped) - Cost_user_expected = Σ C_resource_i。
• 只有当所有关联资源被删除时，Cost_total才为0。

计费精确。但计费模型与用户“停止即免费”的直觉模型存在“认知误差”，导致账单意外。

成本分解、资源生命周期管理、认知心理学中的心智模型。

开发测试环境、临时性工作负载，用户经常启动和停止实例以节省成本。

C_instance(): 实例计算资源计费函数；state: 实例状态（running, stopped）；C_resource_i: 第i个关联资源的计费函数；Cost_total: 总费用。

实例状态：{运行(计费)， 停止(计算资源不计费)}。关联资源状态：{已分配(计费)， 已释放(不计费)}。账单状态：{有意外费用}。

集合论：总费用是实例费用集合与关联资源费用集合的并集。停止操作只清空实例费用集合。
会计学：费用按资源科目分开核算。用户误将“实例”科目视为总账。
最优化：用户需在节省成本（停止实例）和管理开销（清理资源）之间权衡。

用户停止了一个带100GB EBS卷和弹性IP的实例，以为没有费用了。月底账单显示EBS存储费和弹性IP占用费。控制台停止实例时，没有显著提示关联资源仍会计费。

定价页面会分别列出各项服务的费用。用户有责任了解所使用服务的计费方式。“停止实例不计费”的误解源于用户自身。

1. 用户启动实例I，附加一个EBS卷V，分配弹性IP E。
2. 用户工作完成后，在控制台停止实例I。
3. 实例I状态变为“stopped”，控制台可能显示“实例已停止，不再产生计算费用”。
4. 卷V和弹性IP E仍然存在。
5. 计费系统持续对V和E计费。
6. 用户收到账单，发现仍有费用，才意识到需要手动删除V和释放E。
方程：if (instance.state == STOPPED) { compute_charge = 0; } //但以下继续计费：ebs_charge = volume.size * price_gb; eip_charge = hours_allocated * price_hour;

顺序序列（启动实例并关联资源->停止实例->关联资源持续计费->收到账单->发现意外费用->清理资源）。

停止实例操作复杂度O(1)。全面成本管理的复杂度中等（需跟踪所有资源）。

资源生命周期、成本管理、财务运维。

P7-0053

云计算/平台商业策略与技术锁定

CPU积分累积速率限制

突发性能实例的CPU积分累积速率人为限制，即使实例完全空闲，也需要数天才能累积足够积分，无法应对突发负载。

性能模型/积分经济控制

突发性能实例（如T系列）通过CPU积分机制提供基准性能和突发能力。积分累积函数为Accumulate(t) = min(Burst_balance_max, Burst_balance(t-1) + Earn_rate * Δt)。其中Earn_rate被设置得很低，且Burst_balance_max有上限。

CPU积分限制性累积引擎

1. 积分经济系统：实例有一个CPU积分余额B(t)。当CPU使用率低于基准线时，以速率Earn_rate累积积分；当高于基准线时，消耗积分。
2. 速率限制：Earn_rate很小，例如一个t3.micro实例每小时仅累积6个积分（基准性能为10% CPU）。完全空闲时，一天（24小时）累积144积分。
3. 上限限制：积分余额有上限B_max（如t3.micro为288积分）。即使长期空闲，余额也不会超过B_max。
4. 突发能力不足：一次高CPU突发可能迅速耗尽积分（如以100% CPU运行几分钟）。耗尽后，性能降至基准线（如10%）。由于Earn_rate低，需要很长时间（数小时到数天）才能重新累积足够积分应对下一次突发。
5. 用户预期不符：用户期望“空闲时蓄力，需要时爆发”，但低Earn_rate和B_max使得“蓄力”过程极其缓慢，“爆发”持续时间很短。
数学方程：
• 积分余额：B(t) = min(B_max, B(t-1) + Earn_rate * I_idle(t) * Δt - Consumption(t))，其中I_idle(t)为t时刻是否空闲。
• 突发持续时间：T_burst ≈ B(t_start) / (CPU_usage_burst - CPU_baseline)。
• 累积回满时间：T_recharge = (B_max - B(t_end)) / Earn_rate。由于Earn_rate小，T_recharge可能长达数十小时。
• 性能约束：实际CPU性能P(t) = { CPU_baseline if B(t) ≤ 0; min(CPU_max, CPU_baseline + f(B(t))) otherwise }。

积分计算精确。但低Earn_rate和B_max使得突发性能的可用性与用户“按需突发”的期望存在“性能恢复误差”。

令牌桶算法、资源分配、服务质量。

具有间歇性、不可预测突发负载的Web服务器、开发测试环境。

B(t): t时刻CPU积分余额；B_max: 积分余额上限；Earn_rate: 积分累积速率（积分/小时）；CPU_baseline: 基准CPU性能；T_burst: 最大突发持续时间；T_recharge: 积分回满时间。

积分余额状态：{累积中， 消耗中， 耗尽}。实例性能状态：{基准性能， 突发性能， 性能受限}。

控制理论：积分余额是一个带有输入（Earn_rate）和输出（消耗）的蓄水池。低输入速率导致系统对突发需求的响应恢复缓慢。
排队论：将CPU请求视为顾客，积分视为服务能力。低累积速率导致服务能力恢复慢，队列容易排满。
最优化：用户需选择实例规格，使得Earn_rate和B_max能满足其突发模式，否则需升级实例。

用户运行一个t3.micro实例处理每日一次的批处理任务。任务需要5分钟100% CPU。运行后积分耗尽，性能降至10%。第二天任务运行时，积分只累积了144，仅够支持很短时间的高性能，之后任务因CPU限制而变慢。

属于服务性能规格的明确描述。但营销材料可能强调“突发能力”而弱化“缓慢累积”，导致用户误解。

1. t=0，实例启动，B(0)=初始积分（如30）。
2. 实例空闲24小时，以Earn_rate=6积分/小时累积，B(24)=30+144=174（未达上限288）。
3. t=24，突发负载到来，CPU使用率100%，基准为10%，净消耗速率=90%/小时（假设线性消耗）。
4. 积分快速消耗，约(174积分)/(90积分/小时)≈1.93小时后，B≈0。
5. t≈25.93，积分耗尽，CPU性能被限制在10%。
6. 负载仍在，但任务因CPU限制而极慢。
7. 负载结束后，实例需要约 (288/6)=48小时完全空闲才能回满积分。
方程：B(t+Δt) = min(B_max, B(t) + Earn_rate * Δt - (CPU_usage - Baseline_CPU) * Δt)

时间序列：空闲时积分缓慢线性增长，突发时积分快速线性消耗，耗尽后性能受限。

积分计算复杂度O(1)。用户预测性能和选择合适实例的复杂度中等。

性能建模、容量规划、令牌桶算法。

P7-0054

云计算/平台商业策略与技术锁定

专有虚拟化技术绑定

平台使用专有虚拟化技术（如Nitro、Xen定制版），导致虚拟机镜像无法直接迁移到其他虚拟化平台，需重新配置驱动和内核。

技术锁定/虚拟化层不兼容

平台虚拟化层V_platform使用定制化的虚拟硬件、设备驱动和启动固件。由此生成的虚拟机镜像IMG_platform包含了平台特定的内核模块、驱动程序和配置。该镜像在其他虚拟化环境V_other（如VMware, KVM, 或其他云）中无法直接启动或运行正常。

虚拟化技术不兼容引擎

1. 虚拟硬件差异：V_platform提供特定的虚拟设备集（如NIC型号、磁盘控制器、显卡）。镜像IMG_platform安装了与之匹配的驱动程序D_platform。
2. 启动依赖：镜像的操作系统内核可能包含针对V_platform优化的模块或补丁，并依赖于特定的初始RAM磁盘（initrd）配置。
3. 迁移失败：将IMG_platform直接导入V_other时，启动过程中会因为缺少D_platform或遇到不兼容的虚拟硬件而失败（如内核恐慌、找不到根设备）。
4. 迁移成本：用户必须为V_other准备一个通用的、兼容性好的基础镜像，然后在其中重新安装应用和数据。这相当于应用迁移，而非简单的镜像导出导入。
5. 锁定强化：平台通过提供性能优化（如Nitro的高I/O性能）吸引用户，但代价是增加了未来迁移的难度和成本。
数学方程：
• 虚拟化环境：V = {Hardware_virtual, Drivers, Firmware}。
• 镜像兼容性：Compatible(IMG, V) = 1 if IMG contains drivers for V else 0。
• 平台镜像：IMG_platform 满足 Compatible(IMG_platform, V_platform)=1，但大概率 Compatible(IMG_platform, V_other)=0。
• 迁移工作量：Workload_migration = Cost_reinstall + Cost_data_transfer + Cost_configuration。
• 用户选择：使用V_platform获得性能/功能收益，但承担未来迁移成本Workload_migration的风险。

镜像在原生平台运行正常。但跨虚拟化环境的兼容性为0，与“虚拟机可移植性”的普遍期望存在“环境兼容性误差”。

虚拟化技术、设备驱动、操作系统移植。

从AWS EC2 (Nitro) 迁移到Azure (Hyper-V) 或Google Cloud (KVM)，或迁移到本地VMware环境。

V_platform, V_other: 不同虚拟化环境；IMG_platform: 基于V_platform创建的镜像；Compatible(): 兼容性函数；Workload_migration: 迁移工作量。

镜像兼容性状态：{兼容于V_platform， 不兼容于V_other}。迁移可行性状态：{可直接迁移， 需重构}。

集合论：镜像兼容的环境集合是单点集{V_platform}。
图论：迁移路径上，从IMG_platform到IMG_other没有直接边，必须经过“重构”节点。
依赖分析：IMG_platform对V_platform的驱动和配置存在强依赖。

用户从AWS导出一个AMI（基于Nitro），尝试在VMware vSphere上启动。虚拟机启动时卡在“找不到启动设备”或内核恐慌。文档说明导出的镜像是特定格式（如VMDK），但未说明虚拟硬件兼容性。

属于技术实现差异。平台没有义务确保其镜像与其他供应商环境兼容。但若宣传“开放”或“易迁移”，而实际设置技术壁垒，则可能构成误导。

1. 用户在AWS上基于Amazon Linux 2 AMI启动实例，安装应用，创建自定义AMI_aws。
2. AMI_aws包含AWS Nitro ENA驱动和NVMe驱动。
3. 用户将AMI_aws导出为VMDK文件。
4. 用户在VMware环境中创建虚拟机，挂载该VMDK磁盘。
5. 启动虚拟机，系统尝试加载Nitro驱动，但找不到对应的虚拟硬件，导致启动失败。
6. 用户必须创建一个新的VMware兼容虚拟机，安装通用操作系统，重新部署应用和数据。
方程：if (virtual_hardware != ORIGINAL_PLATFORM_HARDWARE) { boot_failed("Missing drivers for storage/network"); }

顺序序列（在平台创建镜像->导出->导入其他环境->启动失败->诊断->重装系统）。

镜像导出导入复杂度O(镜像大小)。系统重装和配置的复杂度高。

虚拟化、设备驱动、操作系统引导、开放虚拟化格式。

P7-0055

云计算/平台商业策略与技术锁定

实例元数据服务API版本强制升级

实例元数据服务API版本强制升级，旧版本在一定时间后停用，导致用户自动化脚本和配置管理工具突然失效。

技术锁定/API生命周期管理

实例元数据服务提供API端点（如http://169.254.169.254/）供实例内部获取自身信息。平台定义API版本V_current和V_legacy。平台宣布V_legacy将在日期T_deprecation后停用。停用后，对V_legacy端点的请求将返回错误或重定向。

元数据API版本弃用引擎

1. 版本化端点：元数据服务通过URL路径区分版本，如/latest/和/2018-09-24/。平台可能默认将请求重定向到最新版本。
2. 弃用公告：平台发布公告，声明旧版本V_legacy将于未来某个日期T_deprecation停止支持。
3. 强制升级：在T_deprecation之后，访问V_legacy端点的请求可能返回HTTP 404或400错误。依赖于V_legacy的脚本、镜像和工具将突然失效。
4. 升级负担：用户需要查找所有使用元数据服务的代码（可能分布在众多实例、自定义AMI、配置管理模板中），将其更新为使用V_current或版本无关的/latest/端点。这个过程容易遗漏，导致生产中断。
5. 锁定效应：频繁或突然的API弃用迫使用户持续投入资源维护与平台API的兼容性，增加迁移到其他平台的成本（因为其他平台的元数据API不同）。
数学方程：
• API版本集合：V = {V_current, V_legacy, ...}。
• 服务可用性函数：Available(V, t) = 1 if t < T_deprecation(V) else 0。
• 脚本依赖：Script S 使用版本 V_used。
• 失效时间：S fails at time t if V_used = V_legacy and t ≥ T_deprecation(V_legacy)。
• 用户维护成本：Cost_maintenance = Σ (Cost_update(S_i)) for all scripts S_i using deprecated versions。

API版本控制精确。但强制弃用时间表与用户更新周期存在“维护同步误差”，导致服务中断。

API生命周期管理、向后兼容性、技术债务。

任何在实例启动脚本、配置管理工具（如Ansible, Chef）、自定义监控代理中调用实例元数据服务的场景。

V_current: 当前支持的API版本；V_legacy: 已弃用的旧API版本；T_deprecation: 版本弃用时间；Available(V, t): 版本V在时间t的可用性。

API版本状态：{当前， 已弃用(支持中)， 已停用}。脚本状态：{兼容， 不兼容(将失效)， 已失效}。

时间序列：API可用性是一个阶跃函数，在T_deprecation时刻从1跳变为0。
图论：脚本对API版本的依赖构成一个有向边。弃用相当于移除图中的节点，导致依赖它的脚本失效。
风险管理：用户需要在T_deprecation之前完成所有脚本升级，这是一个有时间限制的风险缓解任务。

平台发布公告：“实例元数据服务版本2018-09-24将于2024年6月30日停用”。用户有许多旧的自定义AMI，其cloud-init脚本硬编码了http://169.254.169.254/2018-09-24/meta-data/。停用日后，新启动的实例无法获取元数据，启动失败。

平台通常保留在通知后更改或终止服务的权利。但若弃用通知期过短，或影响大量用户而未提供足够迁移支持，可能引发争议。

1. 时间t0，平台发布公告，V_legacy将于t1停用。
2. 用户有脚本S使用V_legacy端点。
3. 用户在t0到t1期间未更新脚本S。
4. 时间t1，平台禁用V_legacy端点。
5. 在t1之后启动的实例，脚本S调用元数据服务失败，返回404错误。
6. 实例启动或应用配置因缺少元数据而失败。
7. 用户紧急排查，更新脚本指向V_current或/latest/。
方程：if (request_path == "/{V_legacy}/" && current_time > T_deprecation) { return HTTP_404; }

时间驱动序列：公告->（用户升级期）->停用日->脚本失效->故障->修复。

API弃用检查复杂度O(1)。用户全局更新脚本的复杂度高（需搜索所有代码库）。

API版本控制、服务生命周期、配置管理。

P7-0056

云计算/平台商业策略与技术锁定

专用租户实际隔离不彻底与溢价

专用实例（Dedicated Instance）承诺物理隔离，但实际仍可能与其他专用实例共享底层硬件，且价格远高于普通实例。

定价模型/隔离性营销与实现差异

专用实例定价P_dedicated = P_standard * Premium_ratio，其中Premium_ratio > 1。平台承诺专用实例在物理服务器级别隔离，即不与“其他客户”的实例共享硬件。但实际实现中，可能允许同一客户的不同专用实例共享同一台物理机，且硬件故障域可能仍与普通实例共享（如网络、存储）。

专用实例隔离与计费引擎

1. 营销承诺：平台宣传专用实例提供“物理隔离”、“单租户硬件”，暗示更高的安全性和性能稳定性，并据此收取溢价Premium_ratio（如额外30%-100%费用）。
2. 实际实现：
a. 客户内共享：同一AWS账户（或Azure订阅）下的多个专用实例可能被放置在同一个专用主机上。这并未违反“不与其他客户共享”的承诺，但可能不符合用户“完全物理隔离”的预期。
b. 基础设施共享：专用实例仍共享底层数据中心网络、存储阵列和电源。这些共享组件的故障仍会影响专用实例。
3. 性价比质疑：用户支付了高溢价，但获得的额外隔离保障可能有限，特别是对于担心同一账户内不同应用相互干扰的场景。
4. 替代方案：对于需要严格隔离的场景，专用主机（Dedicated Host）提供更明确的物理服务器控制，但价格更高。
数学方程：
• 隔离级别集合：L = {Shared, Dedicated_Instance, Dedicated_Host}。
• 价格函数：Price(L) = Base_Price * Multiplier(L)，其中Multiplier(Dedicated_Instance) > Multiplier(Shared)。
• 实际隔离度：Isolation_Actual(Dedicated_Instance) = Isolation(No_Other_Customers) ∩ Isolation(Possible_Same_Customer_Sharing) ∩ Isolation(Shared_Infrastructure)。
• 用户预期隔离度：Isolation_Expected(Dedicated_Instance) ≈ Isolation(Dedicated_Host)。
• 期望差距：Gap = Isolation_Expected - Isolation_Actual > 0。用户支付了接近Dedicated_Host的溢价，但未获得同等隔离。

计费精确。但实际提供的隔离水平Isolation_Actual与营销暗示的Isolation_Expected存在“隔离性认知误差”。

市场细分、价格歧视、服务质量差异。

有合规性要求（如某些数据主权法规）或对“噪声邻居”效应敏感的应用。

P_dedicated: 专用实例价格；P_standard: 标准实例价格；Premium_ratio: 溢价率；Isolation_Actual(): 实际隔离度函数；Isolation_Expected(): 用户预期隔离度。

实例隔离状态：{共享租户， 专用实例(不与外部分享)， 专用主机}。用户认知状态：{认为完全隔离， 发现可能内部共享}。

集合论：物理服务器的租户集合。专用实例保证该集合是当前客户实例集合的子集，而非单例集。
逻辑：承诺“不与其他客户共享”不等于“不与其他实例共享”。
经济学：价格差异反映了感知价值的差异，而非实际成本的线性增加。

用户购买专用实例以满足安全合规要求，并支付了50%的溢价。后来发现同一账户下的两个专用实例被分配到了同一台专用主机上。文档中可能以小字说明“专用实例可能在同一账户内共享专用主机”。

营销材料需准确描述服务特性。如果明确说明“不与其他AWS账户的实例共享硬件”，则未构成虚假宣传。但用户可能基于“专用”一词产生过度预期。

1. 用户为应用A和B购买两个专用实例DI_A和DI_B，期望物理隔离。
2. 平台调度器将DI_A和DI_B放置在同一个专用物理主机H上，因为它们属于同一账户。
3. 用户通过实例元数据或支持查询，发现DI_A和DI_B有相同的底层主机ID。
4. 用户意识到并未获得完全的物理隔离，同一主机上的DI_A和DI_B仍可能竞争物理资源（如缓存、内存带宽）。
5. 用户若需完全隔离，需购买更贵的专用主机。
方程：if (request.is_dedicated && account == host.dedicated_account) { place_instance_on_host(instance, host); }

顺序序列（购买专用实例->部署->发现共享主机->感到失望->考虑专用主机）。

调度复杂度O(1)。用户验证隔离性和理解服务条款的复杂度中等。

多租户隔离、硬件虚拟化、合规性。

P7-0057

云计算/平台商业策略与技术锁定

自动伸缩冷却期固定不可配置

自动伸缩组冷却期固定或可调范围有限，无法根据应用特性优化，导致过度伸缩或伸缩振荡。

技术限制/自动化策略僵化

自动伸缩组在执行伸缩活动（增加或减少实例）后，会进入一个冷却期T_cooldown。在此期间，不会因告警触发新的伸缩活动。T_cooldown是全局固定值或只能在有限范围（如60-300秒）内调整，无法针对不同应用进行精细优化。

固定冷却期引擎

1. 冷却期作用：防止在指标波动期间过于频繁地触发伸缩，给系统稳定和新实例启动留出时间。
2. 固定值问题：
a. 对于启动慢的应用：如果应用启动需要5分钟，但T_cooldown只有2分钟，则可能在应用还未完全就绪时，再次触发伸缩（如因健康检查未通过），导致过度扩容或振荡。
b. 对于启动快的应用：如果应用启动只需30秒，但T_cooldown为5分钟，则在负载快速变化时，伸缩响应迟钝，可能导致性能下降或资源浪费。
3. 缺乏动态性：理想的冷却期应与应用启动时间、负载变化周期动态匹配。但平台只提供静态的、有限的配置选项。
4. 次优配置：用户被迫选择一个折中的T_cooldown，无法使自动伸缩策略达到最优性能。
数学方程：
• 应用启动时间：T_startup。
• 负载变化周期：T_load_cycle。
• 平台允许的冷却期范围：[T_min, T_max]，通常T_min > 0, T_max有限。
• 用户配置的冷却期：T_config ∈ [T_min, T_max]。
• 最优冷却期：T_optimal = f(T_startup, T_load_cycle, Metric_aggregation_period)。
• 性能损失：Loss =

T_config - T_optimal

。由于T_optimal可能不在[T_min, T_max]内，Loss不可避免。
• 伸缩振荡风险：如果T_config < T_startup，可能导致连续扩容。

冷却期计时精确。但固定的T_config与动态的T_optimal之间存在“策略适应性误差”，导致伸缩行为次优。

控制理论、反馈系统、振荡抑制。

具有不同启动特性的应用，如需要长时间初始化的Java应用与快速启动的Go应用。

T_cooldown: 冷却期时长；T_startup: 应用从启动到可服务的平均时间；T_load_cycle: 负载波动的典型周期；T_min, T_max: 平台允许配置的冷却期最小最大值。

自动伸缩组状态：{冷却中(不可伸缩)， 可伸缩}。伸缩活动状态：{刚刚执行， 等待冷却结束}。

控制理论：自动伸缩是一个反馈控制系统。冷却期相当于一个死区时间或抑制器。固定的死区时间可能导致系统响应过冲或不足。
最优化：寻找最优T_cooldown以最小化总成本（性能损失成本+过度配置成本），受限于平台约束。
动态系统：伸缩行为可以建模为一个离散事件系统，冷却期是状态转移的条件。

用户有一个Java应用，启动需要4分钟。设置冷却期为默认的300秒（5分钟）。当负载激增时，扩容发生，新实例启动。在4-5分钟期间，负载可能仍高，但处于冷却期，无法再次扩容，导致性能瓶颈。如果缩短冷却期，又可能引发振荡。

属于平台服务的可配置参数限制。用户需在其约束内优化。但如果限制过于严格，导致常见场景无法优化，则可能影响服务实用性。

1. 自动伸缩组根据CPU利用率告警触发扩容，增加2个实例。
2. 扩容活动开始，进入冷却期T_cooldown=180秒。
3. 新实例启动，但应用需要T_startup=300秒才能完全就绪并接收流量。
4. 在t=180秒时，冷却期结束，但新实例还未就绪（仍在启动中），CPU利用率仍然很高。
5. 自动伸缩再次触发扩容，又增加2个实例。
6. 最终可能过度扩容，因为第一次扩容的实例还未发挥作用就触发了第二次扩容。
方程：if (time_since_last_scaling < T_cooldown) { ignore_scaling_alarm(); }

时间序列：触发伸缩->开始冷却->（负载可能持续高）->冷却结束->可能再次触发->...。

P7-0058

云计算/平台商业策略与技术锁定

抢占式实例回收预测不透明

抢占式实例回收预测基于不公开的算法，用户无法准确预测实例可用时间，不适合有状态工作负载。

技术锁定/资源可用性黑盒

抢占式实例的价格和可用性由平台根据空闲容量动态决定。平台可能提供一个“回收预测”指示器（如“可能在将来某个时间被回收”），但预测算法P(t)是黑盒，且不提供准确的回收时间概率分布。

抢占式实例回收黑盒引擎

1. 动态定价与回收：抢占式实例的价格随供需波动。当平台需要回收容量时（例如，有按需实例请求），会选择终止部分抢占式实例。回收决策基于内部算法，考虑因素不透明。
2. 预测信息有限：平台可能通过实例元数据或API提供一个“回收通知”，例如在实例被回收前两分钟发出信号。但更长期的预测（如下一小时被回收的概率）不提供。
3. 用户风险：对于有状态工作负载（如数据库、长期运行的计算任务），实例突然终止会导致数据丢失或任务中断。由于无法可靠预测实例能运行多久，用户难以评估风险。
4. 适用场景受限：这迫使抢占式实例仅适用于无状态、可中断、容错的工作负载（如批处理），限制了其应用范围。用户若想用于其他场景，需自行构建复杂的检查点和恢复机制，增加了复杂性。
数学方程：
• 实例存活时间：T_lifetime，是一个随机变量。
• 平台回收预测：提供一个估计值或信号S(t)，但P(T_lifetime < t

S(t)) 的分布未知。
• 用户决策：使用抢占式实例 if (Cost_saving) > (Risk_of_interruption * Cost_interruption)。由于Risk_of_interruption无法准确量化，决策困难。
• 中断成本：Cost_interruption 对于有状态工作负载很高。
• 结果：用户要么承担高风险，要么放弃使用抢占式实例，支付更高的按需费用。

回收事件本身是确定的。但回收时间预测的不透明性导致用户无法量化风险，存在“风险认知误差”。

概率预测、资源管理、风险管理。

希望使用低成本抢占式实例运行非容错工作负载的场景，如开发环境、测试服务器，甚至某些有状态的中间件。

T_lifetime: 实例存活时间（随机变量）；S(t): 平台在时间t提供的回收预测信号；P(T_lifetime < t): 在时间t之前被回收的概率；Cost_interruption: 实例中断造成的损失。

抢占式实例状态：{运行中， 收到回收通知， 已终止}。用户风险状态：{未知， 可接受， 不可接受}。

随机过程：实例存活时间T_lifetime可以建模为一个随机过程，其分布由平台内部状态决定，对用户不可知。
决策理论：用户在不确定条件下做决策。由于缺乏概率信息，无法计算期望效用。
信息经济学：平台拥有信息优势（回收算法），用户处于信息劣势，导致市场效率降低（用户规避风险，使用不足）。

用户启动一个抢占式实例运行一个需要运行数小时的数据库批处理作业。平台控制台只显示“可能被回收”，没有更详细信息。运行两小时后，实例突然被终止，作业失败，数据处于中间状态。元数据服务可能在终止前两分钟提供通知，但对于长时间作业来说太短。

服务条款明确说明抢占式实例可能被随时回收，且不保证可用时长。因此，平台没有义务提供预测。用户需自担风险。

1. 用户启动一个抢占式实例I，运行一个长时间任务。
2. 平台内部容量需求增加，调度器决定回收一些抢占式实例以释放容量。
3. 平台根据不公开的算法选择实例I进行回收。
4. 在终止前两分钟（如果配置），平台通过实例元数据发送回收通知。
5. 两分钟后，实例I被强制终止。
6. 用户任务中断，可能数据丢失。
7. 用户无法预测下一次实例能运行多久，因此不敢将其用于关键任务。
方程：if (need_capacity_for_ondemand()) { spot_instances = select_spot_instances_to_terminate(); terminate(spot_instances); } // selection algorithm is opaque

随机序列：实例启动->运行（随机时长）->平台决定回收->发送通知（可能）->终止。

平台回收决策复杂度内部。用户实现容错和检查点的复杂度高。

P7-0059

云计算/平台商业策略与技术锁定

预留实例转换限制与价值损失

宣传预留实例可转换实例类型，但实际转换选项有限，且转换后剩余价值计算不透明，用户可能蒙受损失。

定价模型/长期承诺灵活性限制

预留实例转换功能允许用户将现有预留实例RI_old转换为新的预留实例RI_new。但转换受规则集R约束：例如，只能转换为特定族内的实例，或价格更高的实例。转换后，RI_old的剩余价值V_remaining被用于抵扣RI_new的费用，但抵扣计算方式C(V_remaining, RI_new)不透明，可能导致价值损失。

预留实例转换价值引擎

1. 转换规则限制：规则集R可能规定：只能在同一实例族内转换、只能转换为价格相同或更高的实例、每年有转换次数限制等。这限制了用户根据实际需求调整的灵活性。
2. 剩余价值计算：RI_old的剩余价值V_remaining是其预付费用中未使用的部分。平台使用一个内部公式计算V_remaining，该公式可能涉及复杂的按比例摊销和折扣计算。
3. 抵扣不透明：当转换为RI_new时，用户需要支付RI_new的全价P_new。V_remaining被用作抵扣，但实际抵扣金额D = C(V_remaining, RI_new)可能小于V_remaining。差额可以视为“转换手续费”或价值损失L = V_remaining - D。
4. 用户决策困难：由于C不透明，用户无法准确计算转换的实际成本和收益，可能做出次优决策，或发现转换后并未节省预期中的费用。
5. 锁定效应：用户被鼓励购买预留实例以获得折扣，但当需求变化时，转换的困难和潜在价值损失使得调整成本高昂，从而被锁定在原有的实例类型上。
数学方程：
• RI_old属性：{Type_old, Term_old, Payment_old, Start_time, Purchase_price}。
• 剩余价值：V_remaining = f(Purchase_price, Start_time, Current_time, Term_old)，f是平台不公开的摊销函数。
• 转换规则：Convertible(RI_old, RI_new) = True if (RI_new符合规则集R) else False。
• 转换成本：Cost_convert = P_new - D，其中D = C(V_remaining, RI_new)，且D ≤ V_remaining。
• 价值损失：L = V_remaining - D ≥ 0。用户损失了部分预付价值。

转换操作本身可执行。但转换规则R和抵扣计算函数C的不透明性，导致用户实际获得的灵活性F_actual和节省S_actual低于预期F_expected和S_expected。

金融工程、摊销计算、合同灵活性。

购买了1年或3年预留实例，但后期因应用架构变化需要调整实例类型的用户。

RI_old, RI_new: 新旧预留实例；V_remaining: 旧实例剩余价值

P7-0060

云计算/平台商业策略与技术锁定

临时存储风险弱化宣传

实例存储（Instance Store）卷宣传为高性能存储，但未充分强调数据在实例终止时永久丢失，用户误用于持久化数据存储。

风险模型/信息不对称

平台在描述实例存储时，突出其性能指标P_perf（高IOPS、低延迟、零成本），而将数据持久性风险R_persistence（数据在实例停止、终止或硬件故障时丢失）的说明置于次要位置或不显著提示。

实例存储风险弱化引擎

1. 性能突出宣传：在实例类型规格表中，用显著字体标明“包含高速本地NVMe SSD存储”，并给出极高的IOPS和吞吐量数字。价格表显示“包含在实例价格中”，暗示“免费”高性能存储。
2. 风险弱化处理：关于数据持久性的警告可能以小字体、脚注或折叠的“重要信息”段落出现，措辞为“实例存储中的数据是临时性的”或“建议用于临时数据”，但未使用“永久丢失”、“无法恢复”等强警告词汇。
3. 用户决策误导：用户被高性能和“免费”吸引，选择该实例类型用于数据库、缓存等场景，误以为数据是持久的，或认为定期备份可覆盖风险，但未意识到实例重启（非终止）也可能导致数据丢失。
4. 损失发生：当实例因计划维护、硬件故障或误操作终止时，所有实例存储数据永久丢失，造成业务中断和数据灾难。
数学方程：
• 用户感知价值：V_perceived = α * P_perf + β * C_cost (α, β 为权重，且α很大，β考虑“免费”)。
• 实际风险：R_actual = P(data_loss) * Impact(data_loss)。其中P(data_loss)在实例生命周期内不为零。
• 信息传递效率：E_info = Salience(P_perf) / Salience(R_persistence) >> 1。即性能信息显著度远高于风险信息。
• 用户损失：Loss = Impact(data_loss) if data_loss occurs。

性能数据精确，但风险告知的有效性（用户认知率）低，存在“风险认知误差”，导致误用。

行为经济学（框架效应、突出显示）、风险沟通、信息披露。

选择包含实例存储的实例类型，特别是用于数据库、缓存、日志处理等对性能有要求的场景。

P_perf: 实例存储性能指标（IOPS， 吞吐量）；R_persistence: 数据持久性风险；Salience(): 信息显著度函数；E_info: 信息传递效率比；Impact: 数据丢失的影响。

实例存储数据状态：{存在(易失)， 已丢失}。用户认知状态：{未察觉风险， 已察觉风险}。

决策理论：用户在信息不完全下决策。平台通过信息呈现方式影响用户对选项的评估。
概率：数据丢失事件概率P(loss)是实例生命周期事件的函数，非零。
最优化：用户本应权衡性能收益与数据丢失风险，但因风险信息被弱化，决策偏向选择实例存储。

实例类型描述页面，用大号字体显示“高达3.5 GB/s的存储带宽”，底部小字“实例存储卷是临时存储”。创建实例时，存储配置部分默认选中“实例存储”，没有强制的确认弹窗。

若平台未以清晰、显著的方式揭示数据丢失的重大风险，导致用户做出错误选择并遭受损失，可能需承担未充分履行告知义务的责任。

1. 用户选择实例类型，看到“包含NVMe SSD存储， 随机读取性能高达400K IOPS”。
2. 用户创建实例，在存储配置中看到附加的实例存储卷，容量已预配，无额外费用。
3. 用户部署数据库，将数据目录放在该卷上以获得高性能。
4. 几周后，实例因底层主机维护被平台终止并迁移。
5. 新实例启动，实例存储卷为空，数据库数据全部丢失，应用无法启动。
方程：if (instance_store_used_for_persistent_data && instance_terminated) { data_loss = 100%; }

顺序序列（选择实例->被性能吸引->部署应用->数据写入实例存储->触发数据丢失事件->数据永久丢失）。

选择实例复杂度低。数据恢复的复杂度无限大。

存储类型、数据持久性、备份与恢复策略。

P7-0061

云计算/平台商业策略与技术锁定

虚拟机导入兼容性白名单限制

虚拟机导入工具只支持有限的操作系统版本和虚拟化格式，旧系统或自定义系统无法导入，强制用户升级或重构。

技术锁定/迁移路径控制

平台虚拟机导入服务定义了一个兼容性列表L_compatible，包含有限的操作系统版本（如Windows Server 2016+， CentOS 7+）和虚拟磁盘格式（如VHD， VMDK）。导入工具在预处理阶段会检查源镜像I_source，如果其OS_version或Format不在L_compatible中，则导入失败。

虚拟机导入兼容性检查引擎

1. 白名单定义：平台基于其支持的虚拟化驱动、内核版本和安全补丁，定义L_compatible = { (OS_type, Version_min), (Format_type) }。
2. 预处理验证：导入工具对上传的虚拟磁盘文件进行分析，检测其操作系统类型、版本和磁盘格式。检查函数Check(I_source) = Pass if (OS, Version) ≥ (OS_min, Version_min) and Format ∈ Supported_Formats else Fail。
3. 强制升级压力：如果用户有一个旧系统（如Windows Server 2008 R2， CentOS 6），即使运行良好，也无法直接导入。用户必须先在原环境升级操作系统到兼容版本，或创建全新的、兼容的虚拟机并迁移应用，过程复杂且有风险。
4. 锁定效应：这增加了从其他环境（如本地数据中心、其他云）迁移到该平台的难度和成本，特别是对于遗留系统。用户可能因此放弃迁移，或被迫接受平台的全套现代化技术栈。
数学方程：
• 源镜像属性：I_source = (OS, Version, Format)。
• 兼容性列表：L_compatible = { (OS_i, V_min_i), Format_j }。
• 导入条件：Import_Possible(I_source) = 1 if ∃ i, j s.t. OS=OS_i AND Version ≥ V_min_i AND Format = Format_j else 0。
• 用户迁移成本：Cost_migration = if Import_Possible=1 then Cost_import else Cost_upgrade + Cost_reinstall + Cost_data_migration。
• 平台通过控制L_compatible的宽松度，影响Cost_migration。

兼容性检查精确。但兼容性列表L_compatible的严格性导致许多现有系统无法直接迁移，存在“迁移路径误差”。

操作系统兼容性、软件供应链、技术迁移。

从本地数据中心或其他云平台迁移虚拟机（“上云”）的场景。

I_source: 源虚拟机镜像属性；L_compatible: 平台支持的兼容性列表；Check(): 兼容性检查函数；Cost_migration: 总迁移成本。

镜像兼容状态：{兼容， 不兼容(OS旧)， 不兼容(格式不支持)}。导入过程状态：{验证中， 验证通过， 验证失败}。

集合论：兼容镜像集合是平台定义的L_compatible。用户源镜像集合与该集合的交集可能为空。
偏序关系：操作系统版本需要满足“大于等于”关系。
最优化：用户需最小化迁移成本。平台通过限制L_compatible，增加了用户选择其他迁移路径（如直接导入）的成本。

用户尝试将本地VMware上的CentOS 6.5虚拟机导入到云平台。上传VMDK文件后，导入工具报错“不支持的操作系统版本。请使用CentOS 7或更高版本。” 用户必须在本地将系统升级到CentOS 7，或在新平台创建CentOS 7实例并手动迁移应用。

平台有权决定其支持的操作系统和格式。但如果营销中宣称“轻松迁移”而实际设置高兼容性壁垒，可能构成误导性宣传。

1. 用户准备本地虚拟机镜像文件（.vmdk），操作系统为Windows Server 2008 R2。
2. 用户登录云控制台，启动虚拟机导入服务，上传该文件。
3. 导入服务分析镜像，检测到OS为Windows Server 2008 R2。
4. 查询L_compatible，发现最小支持版本为Windows Server 2012 R2。
5. 导入失败，返回错误“不支持的操作系统版本”。
6. 用户必须先在本地升级虚拟机到Windows Server 2012 R2或更高，然后重新尝试导入。
方程：if (source_image.os_version < MIN_SUPPORTED_VERSION[os_type]) { return error(“Unsupported OS version”); }

顺序序列（准备镜像->上传->验证->失败->升级系统->重新上传）。升级步骤是一个独立且可能复杂的子序列。

兼容性检查复杂度O(

L

P7-0062

云计算/平台商业策略与技术锁定

安全组默认规则宽松继承

新实例默认继承所在子网的安全组，但该安全组可能过于宽松，用户未及时调整导致安全漏洞。

安全模型/默认配置风险

创建实例时，网络配置部分默认将实例关联到其子网（Subnet）的默认安全组（Default Security Group）D。安全组D通常包含允许所有内部流量和宽松的入站规则（如允许来自0.0.0.0/0的SSH/RDP）。用户若未在创建时或创建后立即修改，实例将暴露在风险中。

宽松默认安全组引擎

1. 默认关联：创建实例的API或控制台，在未显式指定安全组时，自动将实例的网络接口关联到其子网的默认安全组D。
2. 默认规则：安全组D的规则由平台预定义或由用户在创建VPC时继承。常见规则包括：
- 入站：允许来自同一安全组内实例的流量（All traffic），允许来自0.0.0.0/0的SSH(22)和RDP(3389)（便于初始访问）。
- 出站：允许所有流量到0.0.0.0/0。
3. 用户疏忽：用户，特别是新手，可能未意识到需要收紧安全规则，或认为创建后可以稍后修改。攻击者可以利用宽松的规则（如开放的管理端口）进行扫描和攻击。
4. 责任转移：平台通过提供“可修改”的安全组，将安全配置的责任完全转移给用户，但初始的宽松默认值增加了暴露风险。
数学方程：
• 实例安全组集合：S(instance) = { default SG of subnet } if not specified。
• 安全组规则：Rules(SG) = { (protocol, port, source) }。
• 暴露风险：Risk(instance) = Σ_{rule in Rules(S(instance))} Severity(rule)。对于默认规则，Severity(开放SSH给0.0.0.0/0) 很高。
• 风险窗口：T_risk = Time between instance creation and user hardening security groups。由于默认规则宽松，T_risk内风险高。

安全组规则执行精确。但默认安全组规则的宽松性与安全最佳实践存在“安全基线误差”，导致初始配置不安全。

默认安全、最小权限原则、安全配置管理。

新实例创建，特别是通过自动化模板或快速启动向导时。

S(instance): 实例关联的安全组；Rules(SG): 安全组的规则集；D: 默认安全组；Risk: 实例暴露风险；T_risk: 风险窗口时长。

实例安全状态：{默认宽松规则， 已加固}。攻击面状态：{大， 小}。

集合论：允许的流量是规则集合中所有源的并集。默认规则集合包含不希望的源（如0.0.0.0/0）。
图论：网络安全组规则定义了允许的通信图。默认图过于连通。
风险管理：风险是暴露可能性和影响的乘积。默认配置增加了暴露可能性。

控制台创建实例时，网络设置部分“安全组”下拉框默认选中“默认安全组”或子网的默认安全组。用户快速点击下一步完成创建。实例启动后即暴露SSH端口于公网。

平台提供了安全组作为安全工具，但默认配置是其设计选择。用户有责任审查和配置安全设置。但过于宽松的默认值可能被认为未提供合理的默认安全防护。

1. 用户创建新实例，在网络配置页面未修改安全组设置，使用默认值（关联到子网默认安全组D）。
2. 实例启动，获得公网IP。
3. 安全组D规则允许从0.0.0.0/0到TCP端口22的入站流量。
4. 互联网上的扫描器探测到该IP开放了22端口。
5. 攻击者尝试暴力破解SSH密码。
6. 用户稍后登录实例，才发现安全组过于开放，将其修改为仅允许自己IP访问。
方程：if (user_specified_sg == null) { attach_security_group(instance, subnet.default_security_group); }

顺序序列（创建实例->关联默认安全组->实例运行(暴露)->用户发现并加固）。攻击尝试是并行的、持续的事件。

安全组配置复杂度低。监控和响应安全事件的复杂度高。

网络安全、最小权限访问、安全基线配置。

P7-0063

云计算/平台商业策略与技术锁定

实例调度算法不透明

实例启动时的物理服务器调度算法不透明，用户无法优化实例放置（如避免噪声邻居、优化网络延迟）。

技术锁定/资源调度黑盒

平台调度器S在接收到启动实例请求后，从资源池中选择一台物理主机H来承载该实例。选择算法S基于多种内部因素（如资源利用率、硬件故障域、能耗），但其具体逻辑、权重和目标函数对用户不可见。用户无法提供调度偏好或约束。

黑盒实例调度引擎

1. 多目标调度：调度器S优化多维目标O = {利用率， 能效， 容错， 硬件亲和性...}。其决策函数H = S(Instance_Request, Cluster_State)是一个复杂的、不公开的优化过程。
2. 用户信息缺失：用户不知道实例将被调度到哪台物理机，与哪些其他实例共享硬件，也无法请求特定的放置策略（如“将这两个实例放在一起”或“分散放置”）。
3. 性能影响：实例性能受邻居（同主机其他实例）影响。由于调度不透明，用户可能遭遇“噪声邻居”问题，导致性能波动不可预测。对于需要低延迟通信的集群，实例可能被分散在不同机架，增加网络延迟。
4. 优化无能：用户无法通过调度策略来优化应用性能、成本或可用性。例如，无法确保数据库实例和缓存实例部署在邻近位置以降低延迟。
数学方程：
• 集群状态：C(t) = {Host_i, Resource_availability_i, Load_i, ...}。
• 调度函数：Host = S(Request(T, R), C(t))。S是黑盒。
• 实例性能：Perf(instance) = Base_Perf(T) - Interference(Neighbors(Host))。其中Neighbors(Host)对用户未知。
• 用户期望放置：P_desired = argmax Placement_Score(Placement)，其中Placement_Score是用户定义的函数（如延迟最小化）。
• 实际放置：P_actual = S决定的放置。由于无法影响S，P_actual通常不优化Placement_Score。

调度结果确定。但调度逻辑和目标对用户隐藏，用户无法使调度结果适配其特定目标，存在“调度控制误差”。

资源调度、优化理论、多目标决策。

高性能计算、低延迟分布式系统、对性能干扰敏感的应用。

S: 平台调度算法（黑盒）；C(t): 集群状态；Request(T, R): 实例请求（类型T， 区域R等）；Perf: 实例性能；Interference: 邻居干扰函数。

调度过程状态：{请求提交， 调度中(黑盒)， 已调度(至主机H)}。调度结果质量：{对用户优， 对用户次优}。

优化理论：用户有一个优化目标，但决策变量（主机选择）由黑盒优化器控制。
博弈论：多个用户实例的调度形成非合作博弈，但用户无法选择策略。
信息论：调度器拥有完整集群状态信息，用户为零，信息高度不对称。

用户启动多个实例组成集群，无法控制它们被放置在相同还是不同的物理机上。控制台不提供物理位置信息。性能监控显示实例间延迟差异大且不稳定。用户请求支持优化放置，被告知无法控制。

属于平台核心基础设施管理权，通常无可争议。但如果SLA承诺了某些性能指标（如网络延迟），而调度算法导致其无法达到，则可能构成违约。

1. 用户请求启动实例I1，调度器S选择主机H1放置I1。
2. 用户稍后请求启动实例I2，希望与I1低延迟通信。
3. 调度器S选择主机H2放置I2，H2可能与H1在同一机架，也可能在不同机架甚至不同可用区。
4. 用户测量I1与I2间的网络延迟，发现很高（例如>1ms）。
5. 用户无法请求重新调度或指定亲和性规则。
方程：for each launch_request: chosen_host = schedule(request, current_cluster_state); // schedule() is internal and opaque

并行或顺序序列：多个启动请求被独立调度。调度决策是瞬间的黑盒操作。

调度算法复杂度是平台内部的。用户应用层性能优化的复杂度高。

资源调度、数据中心网络拓扑、性能隔离。

P7-0064

云计算/平台商业策略与技术锁定

资源标签缺乏自动传播

资源标签不能自动传播到关联资源（如实例的EBS卷、弹性IP），导致成本分配和资源管理困难。

管理模型/元数据关联性断裂

用户为实例I打上标签Tags(I) = { (key1, value1), ... }。但由实例创建或附加的关联资源R（如EBS卷、弹性IP、网络接口）不会自动继承这些标签。用户必须手动为每个关联资源单独添加标签，过程繁琐易遗漏。

标签非传播引擎

1. 资源独立标签：标签系统设计为每个资源独立维护其标签集合。创建实例时指定的标签仅应用于实例本身。
2. 关联资源创建：当创建实例时，可能会自动创建或附加EBS卷、网络接口等。这些资源创建时要么无标签，要么只有系统生成的默认标签（如名称），不包含用户为实例定义的业务标签。
3. 管理负担：为了实现成本按项目/部门分配，用户需要为每个EBS卷、每个弹性IP等手动添加与实例相同的标签。在自动化部署中，这需要额外的配置步骤，容易遗漏。
4. 成本分配失真：由于关联资源无标签或标签不一致，成本管理工具无法将它们的费用正确归集到对应的业务单元，导致成本报告不准确，出现“未分配”费用。
数学方程：
• 实例标签集：Tags(I)。
• 实例的关联资源集：R(I) = {EBS1, EIP1, ENI1, ...}。
• 关联资源的标签集：Tags(R_i)。通常 Tags(R_i) ∩ Tags(I) = ∅ 或仅包含少量系统标签。
• 成本分配函数：Cost_Allocation(Resource) = f(Tags(Resource))。如果Tags(Resource)为空，则成本进入“未分配”类别。
• 管理开销：Overhead = Σ

R(I)

* Cost_tagging，其中Cost_tagging是标记一个资源的平均开销。
• 信息损失：由于标签不一致，无法对“实例及其所有关联资源”进行统一查询和管理。

标签应用精确。但标签系统缺乏关联性，导致用户在维护标签一致性和获取准确成本分配方面存在“管理效率误差”。

元数据管理、资源图谱、成本会计。

需要精细成本核算和资源管理的企业环境，特别是使用基础设施即代码（IaC）自动创建大量资源时。

Tags(I): 实例的标签集合；R(I): 实例的关联资源集合；Tags(R): 资源的标签集合；Cost_Allocation(): 成本分配函数；Overhead: 标签管理开销。

资源标签状态：{实例已标记， 关联资源未标记， 关联资源已手动标记}。成本分配状态：{可分配， 部分可分配， 不可分配}。

图论：资源及其关联构成一个图。标签是节点的属性。理想情况是标签能沿边传播，但实际不能。
集合论：所有资源的标签集合。由于缺乏传播，相同逻辑实体的资源可能属于不同的标签等价类。
信息论：完整的业务上下文信息（由Tags(I)携带）在资源关联链上衰减。

用户通过CloudFormation创建带EBS卷的实例，并在模板中为实例指定了Department: Engineering标签。部署后，实例有该标签，但自动创建的EBS卷没有。月末成本报告显示实例费用可归到工程部，但EBS存储费用显示为“未分配”。

平台提供标签功能，但如何应用标签是用户的责任。标签缺乏自动传播通常不被视为平台缺陷，而是功能设计选择。

1. 用户通过控制台或API创建实例I，指定标签Project: Phoenix。
2. 实例创建过程中，平台自动创建一个新的EBS卷V并将其附加到I，卷V无用户标签。
3. 实例I运行，产生计算和存储费用。
4. 成本报告周期，计算费用可被Project: Phoenix标签过滤，但EBS卷费用无法被过滤，因为它没有这个标签。
5. 用户必须手动找到卷V，为其添加Project: Phoenix标签。
方程：Tags(created_volume) = {}; // not inheriting from instance

顺序序列（创建实例并指定标签->平台创建关联资源(无标签)->资源运行计费->成本报告不准确->用户手动补救）。

P7-0065

云计算/平台商业策略与技术锁定

自定义镜像共享权限管理复杂

自定义AMI共享给其他账户需要复杂权限配置，且共享后无法撤销，只能删除整个AMI。

技术锁定/镜像分发控制

共享自定义AMI给另一个账户B需要在AMI上添加基于资源的权限策略，指定账户B的ID和允许的操作（如ec2:RunInstances）。一旦共享，无法仅“取消共享”给特定账户，只能修改权限策略（可能涉及复杂JSON编辑）或直接取消所有共享（通过删除权限）。最直接的方法是删除AMI本身。

AMI共享权限刚性引擎

1. 基于资源的策略：AMI的共享通过一个内联的、基于资源的策略文档控制。该策略附加在AMI资源上。
2. 共享操作：用户A通过API或控制台将账户B添加到AMI的启动权限（launch permissions）中。这本质上是向策略文档添加一条允许语句。
3. 撤销困难：
a. 控制台限制：控制台可能只提供“添加账户”功能，没有简单的“移除账户”列表。用户需要直接编辑策略JSON。
b. 无细粒度撤销：如果只想撤销对账户B的共享，而保留对账户C的共享，需要精确编辑策略文档，移除对B的语句而保留对C的。操作容易出错。
c. 核弹选项：最简单的“撤销所有共享”是重置启动权限，但这会同时移除对所有账户的共享。
4. 删除强制：如果用户只想彻底切断与账户B的共享关系，又不想影响其他账户，最保险的方法是创建AMI的新版本（复制），共享新版本给所需账户，然后删除旧AMI。这增加了存储成本和管理复杂度。
数学方程：
• AMI权限策略：P_AMI = { Statement_s1, Statement_s2, ... }，每个Statement包含Principal (账户ID) 和 Action。
• 共享函数：Share(AMI, Account_B) -> P_AMI' = P_AMI ∪ { Statement for Account_B }。
• 撤销函数：Revoke(AMI, Account_B) 的理想实现是 P_AMI'' = P_AMI' \ { Statement for Account_B }。但平台不提供此原子操作，用户需手动构造P_AMI''。
• 操作风险：手动编辑P_AMI可能导致语法错误或意外权限变更。
• 管理成本：Cost_manage(AMI_sharing) 随着共享账户数量增加而非线性增长。

权限策略执行精确。但权限管理的用户界面和API不提供便捷的细粒度撤销操作，存在“权限管理复杂度误差”。

访问控制、权限管理、资源策略。

在组织内多个AWS账户间共享基础镜像或应用镜像。

P_AMI: AMI的权限策略文档；Account_B, Account_C: 其他AWS账户ID；Share(): 共享操作；Revoke(): 撤销共享操作（理想）。

AMI共享状态：{私有， 已共享给账户B， 已共享给多个账户}。权限策略状态：{简单， 复杂}。

集合论：共享账户集合是策略文档中Principal的集合。撤销是从集合中移除一个元素。
逻辑：权限策略是逻辑语句的合取。撤销需要从合取式中移除一个子句。
最优化：用户需在共享便利性和未来管理复杂度间权衡。复杂的撤销机制增加了共享的长期成本。

用户A将自定义AMI共享给部门内的账户B和C用于测试。后来项目调整，需要停止与账户B的共享，但继续允许账户C使用。用户在控制台找不到“移除账户B”的选项。必须通过CLI使用modify-image-attribute命令并提供一个精确的JSON文档来设置权限，只包含账户C。操作不便，易出错。

平台提供了共享功能，但易用性不足通常不构成法律问题。然而，如果因复杂操作导致用户意外泄露AMI给非目标账户，可能引发安全责任问题。

1. 用户A拥有AMI_X，通过控制台共享给账户B和C。
2. 后来需要撤销账户B的权限。
3. 用户A在控制台尝试，发现只有“添加账户”和“重置为私有”按钮，没有“移除”。
4. 用户A通过CLI运行aws ec2 describe-image-attribute查看当前权限，得到包含B和C的JSON。
5. 用户A手动编辑JSON，移除账户B的条目，形成新JSON。
6. 用户A运行aws ec2 modify-image-attribute应用新JSON。
7. 如果JSON格式错误，操作失败，可能破坏现有权限。
方程：# 理想： revoke_share(ami, account_b); # 实际： new_policy = current_policy.remove_statement(for: account_b); set_image_permission(ami, new_policy);

顺序序列（共享给多个账户->决定撤销一个->查询当前策略->手动编辑策略->应用新策略->验证）。操作复杂，容易出错。

共享操作复杂度O(1)。撤销共享的复杂度高（需理解策略语言和手动编辑）。

身份与访问管理、资源策略、JSON。

P7-0066

云计算/平台商业策略与技术锁定

实例生命周期管理API速率限制

实例生命周期管理API（如重启、停止、终止）有速率限制，大规模自动化操作可能被限流，影响运维效率。

技术限制/API流量控制

平台对实例生命周期管理API（如RebootInstances, StopInstances, TerminateInstances）实施速率限制，例如每账户每秒N次请求（RPS）。当自动化脚本或管理系统需要同时操作大量实例（如批量重启、定期停止开发环境）时，可能触达限流阈值，请求被拒绝或延迟，导致操作执行缓慢或失败。

实例API速率限制引擎

1. 速率配额：为每个API操作定义配额Q_api = (Request_Limit, Time_Window)。例如，StopInstances的配额为每秒5次请求。
2. 请求计量：API网关监控每个账户对每个API的调用频率R(t)。如果R(t)超过Q_api.Request_Limit，则后续请求在时间窗口内被限制，返回ThrottlingException或Rate Exceeded错误。
3. 自动化影响：大规模运维操作（如用脚本停止1000个实例）如果以同步循环方式快速调用API，极易触发限流。脚本需要加入指数退避重试逻辑，显著增加了操作时间和复杂度。
4. 运维效率降低：紧急情况下（如安全事件需快速隔离大量实例），速率限制可能阻碍快速响应。批量操作（如每日定时停止开发实例以节省成本）需要更长时间完成，影响资源利用率窗口。
数学方程：
• API请求序列：Req = {req_1, req_2, ...}，req_i 在时间 t_i 发出。
• 速率计算：R(t, Δt) = count{ req_i

t_i ∈ [t-Δt, t] } / Δt。
• 限制条件：Request allowed if R(t, Time_Window) < Request_Limit。
• 操作总时间：T_total = T_operation + T_backoff。由于限流，T_backoff > 0，且可能随实例数量增加而非线性增长。
• 运维效率：Efficiency = Number_of_Instances / T_total。速率限制降低了Efficiency。

API计量和限流精确。但速率限制值Q_api与大规模自动化运维的需求不匹配，存在“运维自动化支持误差”。

API设计、流量控制、排队论。

大规模实例管理，如批量启动/停止、自动伸缩、灾难恢复演练、安全合规扫描与修复。

Q_api: API速率配额（Request_Limit, Time_Window）；R(t, Δt): 在时间窗口Δt内的请求速率；T_total: 完成批量操作的总时间；T_backoff: 因限流导致的退避等待总时间。

API请求状态：{成功， 被限制(需重试)}。批量操作状态：{进行中(可能被限流)， 完成}。

排队论：API请求到达过程，服务台（API端点）有服务速率上限。超过上限的请求进入队列（或丢失）。
控制理论：速率限制是一种流量整形器。
最优化：用户需设计最优的请求调度策略（如分批、添加延迟）以在限流约束下最小化T_total。

用户编写脚本，循环调用StopInstances来停止500个开发实例。脚本以每秒10个实例的速度调用API。几秒后，开始收到ThrottlingException错误。脚本必须加入错误处理和指数退避，停止所有实例的时间从预期的50秒延长到数分钟甚至更长。

API速率限制是平台保护其服务的常见措施。用户需遵守并设计其自动化以适应限制。通常服务条款会提及限制，但具体数值可能不透明。

1. 时间t0，脚本开始，以高速率R发起StopInstances请求。
2. 在t1，API网关检测到该账户的请求速率超过配额Q_api。
3. 从t1开始，部分请求被拒绝，返回ThrottlingException。
4. 脚本捕获异常，等待一段时间（如1秒）后重试。
5. 重试可能再次被限流，触发更长的等待（指数退避）。
6. 最终，所有请求在反复重试后成功，操作完成于t2，其中(t2 - t0) >> (500 / R)。
方程：if (request_rate_for_api[account] > LIMIT) { sleep(backoff_time); backoff_time = min(MAX_BACKOFF, backoff_time * 2); throw ThrottlingException; }

时间序列：请求发送->（可能）被限流->等待->重试->... 成功。这是一个带有反馈的重试序列。

单次API调用复杂度O(1)。实现健壮的批量处理（带退避）的复杂度中等。

P7-0067

云计算/平台商业策略与技术锁定

虚拟机时钟漂移累积

虚拟机时钟漂移随时间累积，即使使用平台NTP服务也无法完全消除，影响时间敏感应用。

技术限制/时间同步精度

虚拟机时钟由虚拟化层模拟的硬件时钟驱动，与物理主机时钟存在微小但持续的频率偏差（漂移率d）。即使虚拟机内运行NTP客户端与平台NTP服务同步，校正也是周期性的，在同步间隔内漂移会累积。长期运行或对时间精度要求极高的应用会受到影响。

虚拟机时钟漂移引擎

1. 虚拟时钟源：虚拟机看到的时钟由管理程序（Hypervisor）提供，其滴答速率可能不完全稳定，或与物理CPU频率绑定，导致虚拟时钟频率与真实时间频率存在微小差异d（如每天漂移几毫秒到几百毫秒）。
2. NTP校正：虚拟机内NTP服务定期（如每64秒）与平台NTP服务器同步，校正系统时间。这是一个离散的校正过程。
3. 漂移累积：在两次NTP同步之间，漂移持续存在。校正通常通过“步进”或“微调”系统时钟进行，但可能无法完全消除长期累积的微小误差，特别是当漂移率d不稳定时。
4. 对应用的影响：对于依赖高精度时间戳的应用（如分布式事务、金融交易、科学实验日志），即使毫秒级的偏差也可能导致数据不一致、排序错误或超时误判。
5. 用户控制有限：用户无法从根本上消除虚拟化引入的漂移，只能通过更频繁的NTP同步（增加负载）或使用外部时间源来缓解，但无法达到物理机的时钟稳定性。
数学方程：
• 虚拟时钟时间：C_vm(t) = ∫_0^t (1 + d(τ)) dτ，其中d(τ)是随时间可能变化的漂移率。
• 真实时间：T_real(t) = t。
• 时钟误差：Error(t) =

C_vm(t) - T_real(t)

。在NTP同步点t_sync，Error(t_sync)被重置到一个较小值，但之后随时间积分再次增长：Error(t) ≈ ∫_{t_sync}^t d(τ) dτ for t_sync < t < t_sync+Δt。
• 长期误差范围：即使有NTP，Error(t)通常在[-ε, +ε]内波动，但ε > 0，且对长期运行实例，

d(t)

的积分可能导致显著偏移。

NTP同步可减少误差，但虚拟化引入的固有漂移d(t)导致无法彻底消除误差，存在“时间精度误差”。

时钟同步、虚拟化开销、控制系统。

分布式数据库、区块链节点、实时交易系统、监控和日志系统（要求精确时间戳）。

C_vm(t): 虚拟机时钟读数；T_real(t): 真实时间；d(t): 时钟漂移率（随机小量）；Error(t): 时钟误差；t_sync: NTP同步时间点；Δt: NTP同步间隔。

虚拟机时钟状态：{同步中， 已同步(误差小)， 漂移中(误差累积)}。NTP服务状态：{健康， 未响应}。

随机过程：漂移率d(t)可建模为一个随机过程（如维纳过程）。时钟误差是其积分。
控制理论：NTP是一个反馈控制器，试图将Error(t)调节到0。但虚拟时钟的“设备”本身有固有噪声d(t)。
微积分：时钟误差是漂移率对时间的积分。

用户运行一个分布式数据库集群，各节点运行在虚拟机上。即使配置了NTP，偶尔仍会出现因时钟偏差导致的写入冲突或事务中止。检查系统日志，发现不同实例间的系统时间有数毫秒到数十毫秒的差异。

属于虚拟化技术的固有局限性。SLA通常不保证时钟精度。但对于明确依赖时间同步的服务（如某些数据库服务），平台可能会提供更高精度的时钟选项（需付费）。

P7-0068

云计算/平台商业策略与技术锁定

实例类型强制退役时间表

实例类型退役时间表强制且不可协商，用户必须在短时间内迁移，即使应用与新版实例不兼容。

产品策略/强制技术升级

平台发布实例类型退役公告，声明实例类型T_old将在未来日期T_retirement后完全停止支持（无法启动新实例，现有实例可能被强制终止）。迁移窗口ΔT = T_retirement - T_announce 可能较短，且平台不提供对T_old的长期支持选项，即使用户应用因驱动、内核或许可证问题无法在新类型T_new上运行。

实例类型强制退役引擎

1. 退役公告：在时间T_announce，平台宣布实例类型T_old将于T_retirement退役。ΔT可能为几个月到一年，但对于复杂的企业应用，可能不足。
2. 迁移压力：用户必须在ΔT内完成：
a. 评估应用与T_new的兼容性。
b. 解决不兼容问题（可能涉及供应商支持、代码修改、重新编译）。
c. 测试和部署到T_new。
3. 不兼容风险：T_new可能使用不同的CPU架构（x86 vs ARM）、虚拟化技术或设备模型，导致原有镜像、驱动或性能特性不工作。用户可能需要投入大量资源进行迁移，甚至重构应用。
4. 强制终止威胁：如果用户在T_retirement前未完成迁移，其T_old实例可能被强制终止，导致业务中断。平台通过此机制淘汰旧硬件和维护负担，但将迁移成本和风险转移给用户。
数学方程：
• 实例类型生命周期：L(T) = { Available if t < T_retirement(T); Deprecated if t ∈ [T_announce, T_retirement); Retired if t ≥ T_retirement }。
• 用户迁移工作量：Workload_migration(T_old -> T_new) = f(Compatibility_issues)。
• 迁移时间需求：T_needed = Workload_migration / Team_velocity。
• 成功迁移条件：T_needed < ΔT。如果ΔT过短或Workload_migration过大，条件不满足，用户面临业务中断风险。
• 平台目标：通过控制ΔT，平衡其硬件更新节奏与用户迁移负担。通常优先考虑前者。

退役时间点精确。但提供的迁移窗口ΔT可能与用户实际所需迁移时间T_needed不匹配，存在“迁移支持误差”，导致用户仓促或被迫升级。

产品生命周期管理、技术换代、风险评估。

使用较旧实例类型（如AWS的M3, C3系列）的长期运行应用。

T_old: 旧实例类型；T_new: 新实例类型；T_announce: 退役公告时间；T_retirement: 退役终止时间；ΔT: 迁移窗口；Workload_migration: 迁移工作量；T_needed: 所需迁移时间。

实例类型状态：{当前， 已公告退役， 已停用}。用户迁移状态：{未开始， 进行中， 完成， 超时}。

调度理论：迁移是一个项目，需要在截止日期（T_retirement）前完成。ΔT是可用时间。
风险管理：迁移失败的风险R = P(T_needed > ΔT) * Impact(业务中断)。
博弈：平台希望快速淘汰旧类型以降低运营成本，用户希望有充足时间平滑迁移。

平台发布：“C5实例类型将于2024年12月31日退役。请迁移到C5a或C6i实例。” 用户应用依赖C5的特定AVX指令集扩展，而C5a（AMD）或C6i（Intel）的扩展集略有不同，导致性能回归或功能异常。用户必须在截止日期前优化代码或寻找替代方案，压力巨大。

服务条款通常允许平台更改或终止服务。但若退役通知期过短，或新实例类型存在重大不兼容却仍强制迁移，可能引发用户关于业务连续性的投诉。

1. t0: 平台发布T_old退役公告，退役日期为t1。
2. 用户评估，发现应用与T_new不兼容，需要驱动更新，但驱动供应商不提供支持。
3. 用户尝试各种变通方案，耗时耗力。
4. 临近t1，用户仍未找到可靠解决方案。
5. 在t1，平台停止T_old实例的启动，并可能开始计划终止现有T_old实例。
6. 用户业务面临中断风险，可能被迫接受有缺陷的迁移或支付高额费用寻求专业服务。
方程：if (current_date > Retirement_Date(instance_type)) { prevent_launch(instance_type); schedule_termination(existing_instances_of_type); }

顺序序列（公告->评估->迁移尝试->（可能）遇到困难->截止日期临近->强制终止风险）。

迁移评估复杂度中等。解决不兼容问题的复杂度可能很高。

硬件生命周期、应用程序兼容性、技术迁移规划。

P7-0069

云计算/平台商业策略与技术锁定

自动伸缩健康检查简单误判

自动伸缩组健康检查基于简单HTTP/TCP检查，应用部分功能故障但检查仍通过，导致不健康实例继续服务。

技术限制/健康探测深度不足

自动伸缩组（ASG）的健康检查可以配置为使用弹性负载均衡器（ELB）的健康检查或EC2状态检查。ELB健康检查通常是对实例的特定端点（如/health）发起HTTP GET请求，或进行TCP连接测试。只要该端点响应2xx/3xx或TCP连接成功，实例即被视为健康。

浅层健康检查引擎

1. 检查机制：健康检查器定期（如每30秒）向配置的端点发送请求。成功条件简单：HTTP状态码成功或TCP端口可连接。
2. 深度不足：检查不验证应用的整体功能状态。例如，数据库连接池可能已耗尽、外部依赖服务可能不可用、内部缓存可能损坏，但/health端点仍可能返回成功，因为它只检查了Web服务器进程是否运行。
3. 流量误导向：ASG将“健康”的实例保持在服务池中，负载均衡器继续将用户流量分发到该实例。用户请求到达该实例后，因深层故障而失败，导致用户体验下降和错误率升高。
4. 自愈延迟：由于健康检查未失败，ASG不会替换该实例。故障可能持续到运维人员手动干预或应用完全崩溃（此时健康检查才会失败）。
5. 用户需自定义：要实现深度健康检查，用户需自定义/health端点包含所有依赖检查，并确保检查不会过于繁重。这增加了应用开发的复杂性。
数学方程：
• 实例健康状态（平台视角）：H_platform(t) = 1 if Health_Check_Probe(t) succeeds else 0。
• 实例真实健康状态：H_real(t) = 1 if All_Critical_Components_Functional(t) else 0。
• 健康误判：Mismatch(t) = 1 if H_platform(t)=1 and H_real(t)=0 else 0。
• 用户影响：Impact = Σ_{t where Mismatch(t)=1} Failed_User_Requests(t)。
• 检测延迟：从H_real(t)变为0到H_platform(t)变为0的时间差Δt_detection可能很长，甚至无限（如果浅层检查始终通过）。

健康检查探测本身是精确的。但探测的深度与应用的真正健康状态存在“健康定义误差”，导致误判。

故障检测、系统监控、探针设计。

任何使用自动伸缩组和负载均衡器的Web服务、API服务。

H_platform(t): 平台检测到的健康状态；H_real(t): 实例真实健康状态；Health_Check_Probe: 健康检查探测函数；Mismatch: 健康状态误判；Δt_detection: 故障检测延迟。

实例健康状态（平台）：{健康， 不健康}。实例真实状态：{完全健康， 部分故障， 完全故障}。

布尔逻辑：健康检查是应用健康的一个必要但不充分条件。
可靠性工程：健康检查的覆盖率（Coverage）不足，无法检测所有故障模式。
最优化：用户需在健康检查的深度（更准确）和开销（更频繁、更复杂）之间权衡。

实例的/health端点只检查Web服务器是否运行。某时刻，实例连接的后端数据库出现问题，但Web服务器进程正常，/health返回200。自动伸缩组认为实例健康，负载均衡器继续分发请求。用户访问网站时，所有需要数据库的页面都返回5xx错误。

平台提供了健康检查机制，但其配置和深度由用户负责。如果因健康检查配置不当导致故障实例持续服务，责任通常在用户。

1. 实例I运行一个应用，其/health端点配置为ELB健康检查。
2. 实例I的后端缓存服务（如Redis）崩溃，导致应用性能严重下降，但Web服务器和/health端点仍可响应。
3. ELB健康检查器请求/health，收到200 OK，标记实例I为健康。
4. 用户请求被路由到实例I，由于缓存缺失，响应极慢或超时，用户体验糟糕。
5. 直到Web服务器进程也因资源耗尽崩溃，健康检查失败，ASG才会替换该实例。
方程：if (http_get(instance_ip:port/health) returns 2xx) { mark_healthy(instance); } else { mark_unhealthy(instance); }

周期序列：健康检查器定期探测。应用故障可能在两次探测之间发生。用户请求是随机到达的序列。

健康检查执行复杂度O(1)。实现和应用深度健康检查的复杂度中等。

负载均衡、健康检查、应用监控、故障注入。

P7-0070

云计算/平台商业策略与技术锁定

预留实例二级市场缺乏流动性

预留实例二级市场流动性差，用户无法轻易转售未使用的预留容量，资金被锁定。

商业策略/市场设计缺陷

平台提供预留实例的二级市场（如AWS Reserved Instance Marketplace），允许用户出售未到期的预留实例。但该市场存在以下问题：1. 买卖价差大；2. 成交速度慢；3. 只能出售整份预留实例，不能分割；4. 平台可能收取高额交易手续费。

预留实例低流动性市场引擎

1. 市场机制：平台运营一个内部的、中心化的市场，供用户挂牌出售（Sell Order）和购买（Buy Order）预留实例。匹配基于价格和时间优先级。
2. 流动性不足表现：
a. 买卖价差大：卖单的最低价格远高于买单的最高价格，难以成交。
b. 成交数量少：市场深度浅，每日成交寥寥。
c. 交易限制：通常要求出售的预留实例剩余期限较长（如1年以上），且不能拆分出售（例如，你有一个3年期的预留实例，不能只卖剩下的一年）。
3. 用户资金锁定：当用户业务变化，不再需要预留实例时，无法快速以合理价格变现，预付的资金成为沉没成本。用户被迫继续使用（即使利用率低）或接受大幅折价出售。
4. 锁定效应：这增加了购买预留实例的长期风险，因为退出机制不顺畅。用户可能因此倾向于选择灵活性更高的按需实例或Savings Plans，但后者也可能有锁定属性。
数学方程：
• 预留实例价值：V_RI(remaining_time) = ∑_{t=remaining} Discounted_Cash_Flow(RI_rate, OnDemand_rate)。
• 市场卖价：P_ask = V_RI * (1 + α)，卖方希望溢价α。
• 市场买价：P_bid = V_RI * (1 - β)，买方希望折价β。
• 成交条件：P_ask ≤ P_bid。由于买卖双方预期不同，且市场薄，常有不成交：P_ask > P_bid。
• 用户损失：如果无法出售，Loss = V_RI (资金被完全锁定)。如果折价出售，Loss = V_RI - P_bid。
• 市场流动性：Liquidity ∝ Trade_Volume / (Spread * Time_to_Fill)。该市场Liquidity很低。

市场价格和交易记录精确。但市场设计导致流动性Liquidity低，与用户期望的“资产可转让”存在“市场效率误差”。

金融市场微观结构、流动性、二手市场。

购买了1年或3年预留实例，但中途业务收缩、转型或退出云平台的用户。

V_RI: 预留实例的剩余价值；P_ask: 卖方报价（要价）；P_bid: 买方报价（出价）；α: 卖方期望溢价率；β: 买方期望折价率；Liquidity: 市场流动性。

预留实例状态：{持有中， 挂牌出售中， 已售出}。市场状态：{有价无市， 流动性差}。

金融经济学：买卖价差（Spread）是衡量流动性的关键指标。价差大表明流动性差。
博弈论：买卖双方在信息不对称和薄市场下的定价博弈。
最优化：用户在购买预留实例时，需考虑其未来的转售价值（折现），但低流动性使得该价值不确定且偏低。

用户购买了一个3年期预付全款的C5.large预留实例。一年后业务调整，不再需要此实例。用户在市场上挂牌出售，要价800（剩余价值约1000）。数月无人问津。买方出价最高只有$500。用户要么接受大幅亏损出售，要么继续持有并支付关联的按需实例费用（如果不使用）。

平台提供市场作为一种“可能”的退出机制，但不保证流动性或价格。购买预留实例本质上是与平台签订的长期合同，用户需自担无法提前退出的风险。

1. 用户决定出售一个剩余价值V_RI=1200的预留实例。<br>2.用户在市场创建卖单，设置要价Pa​sk=1100（折价100）。<br>3.市场上现有买单的最高出价Pb​id=900。
4. 由于P_ask > P_bid，无法自动成交。卖单挂出。
5. 数周过去，没有买方愿意出价高于900。<br>6.用户要么将价格降至900或以下以求成交，承受$300损失；要么撤销卖单，继续持有RI。
方程：if (exists buy_order with price >= sell_order.price) { execute_trade(); } // often condition is false

顺序序列（决定出售->挂牌->等待成交->可能降价->成交/撤销）。等待时间可能很长，是主要部分。

挂牌操作复杂度O(1)。等待成交和价格谈判的复杂度中等，结果不确定。

金融衍生品、二级市场、云计算经济学。

P7-0071

云计算/平台商业策略与技术锁定

专用主机租赁期限刚性

专用主机租赁期限固定（如1年、3年），不支持按月租赁，用户无法应对业务波动。

商业策略/合同灵活性锁定

平台提供专用主机租赁服务，但其购买选项仅包含固定的租期长度集合L = {1年, 3年}。不支持按月租赁或按需即时租赁。一旦购买，用户必须在整个租期T_commit内支付费用，即使实际使用时间T_used < T_commit。

专用主机固定期限租赁引擎

1. 期限选项设计：平台在设计销售界面时，只提供离散的、长期的租期选项L。不提供短期（如月度）或可随时取消的选项。
2. 承诺与计费：用户选择租期T_commit ∈ L，并支付相应费用（可能为预付或分期）。计费系统从购买日开始，在T_commit内持续计费，无论专用主机的实际利用率如何。
3. 业务波动风险：用户业务需求D(t)可能随时间变化。如果需求在T_commit结束前下降，专用主机将出现闲置，但费用仍需照付，导致资源浪费和成本沉没。
4. 退出成本高：用户无法提前退租或转换租期。唯一的退出机制是等待租期结束，或尝试在二级市场转售（如P7-0070所述，流动性差）。
数学方程：
• 可用租期集合：L = {T1, T2, ...}，通常Ti以年为单位。
• 用户选择租期：T_commit ∈ L。
• 总租赁成本：Cost_total = Rate_per_unit * T_commit。
• 用户实际需求时长：T_needed ≤ T_commit，但T_needed可能远小于T_commit。
• 浪费成本：Cost_waste = Rate_per_unit * (T_commit - T_needed)。
• 灵活性缺失：用户无法选择最优的T_commit = T_needed，因为T_needed可能不在L中，或T_needed是动态的。

租赁期限和计费精确。但固定期限选项与动态业务需求不匹配，存在“期限灵活性误差”，导致成本浪费。

合同理论、长期承诺、需求预测。

需要专用主机以满足严格合规或性能隔离要求，但业务负载有季节性或不稳定性的场景。

L: 可用租期选项集合；T_commit: 用户承诺的租期长度；T_needed: 用户实际需要的时长；Rate_per_unit: 单位时间（如月）租金；Cost_waste: 因期限不匹配导致的浪费成本。

专用主机租赁状态：{租用中(期限T_commit)， 闲置(仍在租期内)， 已到期}。业务需求状态：{高， 低}。

集合论：用户需求时长T_needed是一个值，但必须从离散集合L中选择一个≥T_needed的值作为T_commit。
最优化：用户需预测未来T_needed，并在L中选择一个T_commit以最小化期望成本E[Cost_total]，但预测不准和选项有限导致次优。
金融：长期租赁类似于资本支出，将可变成本转化为固定成本，增加了财务风险。

控制台购买专用主机时，租期下拉框只有“1年”和“3年”（全预付或部分预付）。用户为满足一个预计持续9个月的项目需求，被迫选择1年期并支付12个月费用。项目提前结束，最后3个月主机闲置但仍计费。

属于平台定价和产品包装策略。用户需自行评估长期需求风险。但若平台宣传“灵活”而只提供长期固定合同，可能构成误导。

1. 用户业务需要一个专用主机，预计使用6-8个月。
2. 用户在控制台购买专用主机，发现租期选项只有1年和3年。
3. 用户选择1年租期并支付费用。
4. 主机投入使用，项目在7个月后成功结束。
5. 在接下来的5个月里，专用主机闲置，但用户仍需为其支付费用（或已预付）。
6. 用户无法提前退租或转为按月计费。
方程：Available_Terms = {1, 3} // years; Selected_Term = min{t in Available_Terms where t >= Estimated_Need}

顺序序列（评估需求->选择租期（被迫选长）->使用->需求结束->闲置但付费->到期）。

租赁决策复杂度O(1)。管理闲置资产和承担沉没成本的复杂度中等。

资本支出 vs 运营支出、硬件租赁、财务规划。

P7-0072

云计算/平台商业策略与技术锁定

实例元数据服务单点故障

实例元数据服务成为单点故障，该服务中断时实例无法获取关键配置（如IAM角色凭证），即使实例本身正常运行。

系统设计/关键依赖风险

实例元数据服务是一个区域性服务，为区域内所有实例提供启动配置、IAM角色临时凭证等服务。当该服务因故障、网络分区或DDoS攻击而不可用时，依赖其获取凭证或配置的应用将无法正常工作，尽管实例的计算、存储、网络资源本身可能正常。

实例元数据服务单点故障模型

1. 关键依赖：许多云原生应用和平台工具（如AWS SDK, 容器凭证代理）依赖实例元数据服务（IMDS）来获取：
a. IAM角色的临时安全凭证，用于访问其他AWS服务（如S3, DynamoDB）。
b. 用户数据（user-data）用于启动脚本。
c. 实例标识和网络配置信息。
2. 服务架构：IMDS通常设计为一个高可用服务，但仍是逻辑上的单一端点（如169.254.169.254）。区域性故障会导致整个区域的IMDS不可用。
3. 故障影响：当IMDS不可用时，运行中的实例可能因凭证过期无法刷新而失去访问其他服务的权限，导致应用功能中断。新实例无法获取启动配置，启动失败。
4. 韧性缺失：应用设计通常假设IMDS永远可用，缺乏降级或后备机制（如使用预配置的IAM用户密钥，但这违背了最佳安全实践）。
数学方程：
• IMDS可用性：A_imds ∈ [0, 1]。
• 实例功能依赖：设实例I有功能集F，其中子集F_imds ⊆ F 依赖于IMDS。
• 实例有效功能：F_effective(I, t) = F if A_imds(t)=1 else F \ F_imds。
• 应用中断概率：P_outage = P(A_imds=0)。尽管A_imds很高（如99.99%），但一旦为0，影响范围是区域性的。
• 单点故障强度：IMDS的不可用导致大量实例的部分功能同时失效，违反故障隔离原则。

IMDS服务状态明确。但其作为关键依赖，一旦故障，对依赖它的实例功能影响是100%的，存在“架构韧性误差”。

分布式系统、单点故障、微服务依赖。

任何使用IAM角色、实例用户数据、或需要从IMDS获取元数据的应用。

A_imds: 实例元数据服务的可用性；F: 实例的完整功能集合；F_imds: 依赖IMDS的功能子集；F_effective: IMDS故障时的有效功能；P_outage: 因IMDS导致的应用中断概率。

IMDS服务状态：{健康， 故障}。实例功能状态：{全功能， 部分功能受限(因IMDS故障)}。

可靠性工程：系统整体可靠性是各组件可靠性的串联或并联结果。IMDS是一个串联组件，其可靠性直接影响所有依赖它的实例。
图论：将IMDS视为一个中心节点，所有实例都依赖它。这是一个星型拓扑，中心节点是单点故障。
集合论：正常运行的应用集合是IMDS可用时实例集合的子集。

控制台无直接IMDS状态显示。当IMDS故障时，用户实例日志中会出现“无法从实例元数据获取凭证”或“连接169.254.169.254超时”的错误。应用访问S3等服务开始失败。平台健康面板可能显示“实例元数据服务问题”。

IMDS是平台提供的基础设施服务。SLA可能涵盖其可用性。若因IMDS故障导致用户业务损失，用户可能基于SLA索赔，但通常有除外条款和赔偿上限。

1. 实例I正在运行，其应用使用IAM角色凭证定期访问S3。
2. 区域R的IMDS服务因底层存储故障而中断。
3. 实例I上的SDK尝试刷新临时凭证，向IMDS发起请求失败。
4. 现有凭证过期后，应用无法获取新凭证，对S3的访问被拒绝。
5. 应用功能中断，但实例操作系统、CPU、内存、网络均正常。
6. 直到IMDS服务恢复，应用功能才恢复。
方程：if (IMDS.status != healthy) { for instance in region: instance.functions_depending_on_IMDS = degraded; }

并行序列：IMDS故障事件同时影响区域内所有依赖它的实例。每个实例上应用失败是独立但几乎同时发生的事件。

IMDS故障检测和恢复复杂度是平台内部的。应用实现IMDS故障韧性的复杂度高。

身份和访问管理、服务发现、故障隔离。

P7-0073

云计算/平台商业策略与技术锁定

虚拟机热迁移隐性性能损耗

平台热迁移操作导致虚拟机性能暂时下降（如CPU steal time增加），但迁移期间实例仍标记为"运行中"，用户不知情。

运维模型/性能透明度缺失

平台执行虚拟机实时迁移（Live Migration）时，需要在源主机和目的主机之间同步内存页。此过程会消耗额外的CPU周期、内存带宽和网络I/O，导致迁移中的虚拟机性能P(t)在迁移窗口W_migration内下降，但控制台显示的实例状态仍为“运行中”，不反映性能降级。

热迁移性能影响隐藏引擎

1. 迁移过程：热迁移涉及迭代复制内存页。每次迭代时，源主机上虚拟机的vCPU可能被调度出来执行页面复制和压缩，增加了CPU窃取时间（steal time）。同时，内存访问可能因页表更新而略有延迟。
2. 性能影响：迁移期间，虚拟机的有效计算资源减少。性能函数P(t) = P_normal - ΔP_migration(t)，其中ΔP_migration(t)在迁移活跃期为正。
3. 状态信息不匹配：平台监控系统通常将实例状态报告为“运行中”，这是一个二值状态，不反映性能降级。性能监控指标（如CPU利用率）可能显示升高（因steal time），但用户若不深入分析，会认为应用自身问题。
4. 影响应用：对延迟敏感或计算密集型的应用，在迁移窗口内可能经历响应时间增加或吞吐量下降，用户误以为是应用故障或负载问题。
数学方程：
• 实例状态（平台报告）：S_platform(t) ∈ {running, ...}。
• 实例真实性能：P_real(t) = P_baseline - f(Migration_Intensity(t), Workload(t))。
• 迁移窗口：W_migration = [T_start, T_end]。
• 性能下降：ΔP(t) > 0 for t ∈ W_migration。
• 信息差距：用户已知S_platform(t)=running，但不知P_real(t) < P_baseline。当应用性能下降时，用户难以关联到平台迁移事件，除非查看特定系统指标（如%steal）。

迁移操作成功完成。但迁移期间的性能下降ΔP(t)未被明确告警或反映在实例状态中，存在“状态透明度误差”。

实时迁移技术、性能干扰、可观测性。

平台发起的计划内维护（如主机退役、硬件升级）导致的热迁移。

S_platform(t): 平台报告的实例状态；P_real(t): 实例实际性能；P_baseline: 正常性能基线；W_migration: 迁移时间窗口；ΔP(t): 性能下降函数；Migration_Intensity(t): 迁移活动强度。

实例迁移状态：{未迁移， 迁移中(性能受影响)， 迁移完成}。平台显示状态：{运行中}（始终）。

时间序列：P_real(t)在W_migration期间形成一个“凹坑”。平台状态S_platform(t)是一个常数函数。
控制理论：迁移控制器在保证服务连续性的同时，可能未将性能降级作为主要控制目标输出给用户。
最优化：平台在迁移速度（影响ΔP时长）和性能影响（ΔP幅度）间权衡，但用户未被纳入此权衡。

用户应用在某个时间窗口内响应变慢。检查实例监控，发现CPU利用率中的“steal”指标异常升高，但实例状态为“运行中”。查看云平台的事件日志，可能发现一条计划维护事件，但未明确说明会导致性能下降。

服务条款可能允许平台进行维护。但若维护导致性能显著下降而未充分通知，用户可能主张其服务体验受损。通常性能SLA针对的是非维护时段。

1. 平台计划对主机H进行维护，触发对其上虚拟机I的热迁移。
2. 迁移开始于T_start，实例I状态保持“运行中”。
3. 迁移进程占用CPU和内存带宽复制内存页，导致I的应用性能下降，响应延迟增加。
4. 用户收到应用报警，登录控制台查看实例I，状态显示“运行中”，CPU利用率可能显示很高（包含steal time）。
5. 迁移于T_end完成，性能恢复。
6. 用户可能始终不知道性能下降由平台迁移引起。
方程：During (t in migration_window): P_real(t) = P_normal - k * (dirty_page_rate / network_bandwidth); steal_time(t) increased;

时间序列：迁移开始->性能下降持续->迁移结束->性能恢复。应用性能问题报警是此序列中的事件。

迁移操作复杂度高（平台负责）。用户诊断性能问题的复杂度中等（需理解steal time等指标）。

实时迁移、性能监控、虚拟化开销。

P7-0074

云计算/平台商业策略与技术锁定

自动伸缩组混合实例策略约束

自动伸缩组混合实例策略只支持有限实例类型组合，且权重配置不灵活，无法优化成本和性能平衡。

技术限制/策略配置僵化

自动伸缩组混合实例策略允许在伸缩组中启动多种实例类型以优化成本和可用性。但平台限制可用的实例类型组合C_set（如仅限同一实例族内），并且对每种类型配置的权重（或优先级）W_i的调整范围或粒度有限。

混合实例策略限制引擎

1. 策略定义：混合实例策略包含一个实例类型及其对应的权重列表：[(T1, W1), (T2, W2), ...]。权重Wi表示启动该类型实例的偏好或概率。
2. 组合限制：平台只允许从预定义的组合集合C_set中选择。例如，只能混合同一实例族（如C5）的不同大小，而不能混合不同族（如C5和M5）或不同购买选项（如按需、Spot、RI）的特定组合。
3. 权重不灵活：权重Wi可能只能设置为整数，或调整范围有上下限，无法实现精细的比例控制。例如，不能设置70.5%的流量由按需实例承担，29.5%由Spot实例承担。
4. 优化不足：用户希望根据价格、中断率、性能特征动态调整混合策略，以在给定风险偏好下最小化成本。由于组合和权重限制，用户无法实现理论上的最优混合比例，导致成本高于最优或风险超出预期。
数学方程：
• 可用实例类型集合：T_all。
• 允许的混合组合：C_set ⊆ P(T_all)，其中P是幂集，且

C_set

较小。
• 用户选择的组合：C ∈ C_set。
• 权重向量：W = (W_i for T_i in C)，满足 ΣW_i = 1，且W_i ∈ D，D是平台允许的权重值域（如整数百分比）。
• 用户最优组合与权重：(C_optimal, W_optimal) = argmin Cost(Risk_Tolerance)。
• 由于约束C ∈ C_set 和 W_i ∈ D，用户只能实现次优解(C_subopt, W_subopt)。
• 性能/成本损失：Loss = Cost(C_subopt, W_subopt) - Cost(C_optimal, W_optimal)。

策略执行精确。但策略的配置空间（C_set × D）受限，导致用户无法达到全局最优，存在“策略优化误差”。

组合优化、约束规划、投资组合理论。

希望利用多种实例类型（如按需、Spot、多种代际）平衡成本、性能与可用性的工作负载。

C_set: 允许的实例类型组合集合；T_all: 所有实例类型；W: 权重向量；D: 允许的权重值域；Cost(): 成本函数（依赖于风险和价格）；C_optimal, W_optimal: 无约束下的最优组合和权重。

混合策略状态：{配置中(受限于C_set和D)， 已生效}。伸缩结果状态：{按策略混合， 可能偏离用户理想比例}。

组合数学：从T_all中选取实例类型子集，但被限制在C_set内。
线性规划：在约束ΣW_i=1和W_i∈D下，最小化成本。D的离散性可能导致解不是连续最优解。
投资组合理论：混合实例类似于资产组合，在风险（中断）和收益（成本节省）间权衡。限制相当于限制了可投资的资产类别和比例。

控制台配置混合实例策略时，“实例类型”下拉列表可能只允许选择同一实例族的不同规格。“权重”输入框可能只接受整数，或总和必须为100。用户想混合C5、M5和R5实例，并设置精细权重，但发现做不到。

属于平台功能限制。用户需在其约束内进行优化。如果营销声称“灵活混合”而实际限制严格，则可能产生误导。

1. 用户配置自动伸缩组，启用混合实例策略。
2. 用户尝试添加实例类型，发现只能从“C5家族”中选择（如c5.large, c5.xlarge），不能添加m5.large。
3. 用户为c5.large设置权重60，为c5.xlarge设置权重40。想设置c5.2xlarge权重为5.5，但系统只接受整数，被迫设为5或6。
4. ASG按此策略启动实例，但由于权重舍入和组合限制，实际成本节省和性能表现可能略低于用户精确计算的预期。
方程：Allowed_Instance_Types = get_allowed_mix_for_family(selected_family); Weights must be integers and sum to 100;

顺序序列（配置策略->发现限制->妥协设置->策略生效）。ASG按策略启动实例是持续的、按需的事件序列。

P7-0075

云计算/平台商业策略与技术锁定

抢占式实例中断处理时间窗口不足

抢占式实例中断处理钩子执行时间有限（如2分钟），复杂清理任务无法完成，导致数据不一致。

技术限制/容错处理窗口不足

当抢占式实例即将被回收时，平台通过实例元数据服务或信号发送中断通知，并提供一个短暂的宽限期T_grace（通常为2分钟）。用户配置的中断处理脚本（如终止钩子）必须在此时间内完成所有清理工作（保存状态、关闭连接、上传数据），否则实例将被强制终止。

抢占式实例中断处理时限引擎

1. 中断通知：平台检测到需要回收实例，设置元数据标志并/或发送信号（如SIGTERM）。同时启动一个计时器，时长T_grace。
2. 钩子执行：用户预先安装的中断处理脚本被触发。该脚本需要执行一系列清理任务，总执行时间T_cleanup = Σ T_task_i。
3. 时间约束：成功清理的条件是T_cleanup ≤ T_grace。由于T_grace很短（如120秒），对于需要传输大量数据（检查点到S3）、关闭分布式会话或完成长事务的任务，T_cleanup可能超过T_grace。
4. 强制终止：当T_grace期满，无论清理脚本是否完成，平台都会强制终止实例（发送SIGKILL）。未完成的清理任务导致应用状态不一致、数据丢失或部分数据未持久化。
5. 风险增加：这使得抢占式实例不适合用于有复杂状态或严格一致性要求的工作负载，限制了其应用范围。
数学方程：
• 中断通知时间：T_notice。
• 宽限期：T_grace，固定小值。
• 清理任务时间：T_cleanup ~ Distribution，可能有长尾（如依赖网络速度的数据上传）。
• 清理成功条件：Success = 1 if T_cleanup ≤ T_grace else 0。
• 数据丢失风险：P(data_loss) = P(T_cleanup > T_grace)。对于复杂任务，此概率不可忽略。
• 用户应对：要么简化清理任务，要么接受数据丢失风险，要么放弃使用抢占式实例。

计时精确。但提供的宽限期T_grace与复杂清理任务所需时间T_cleanup不匹配，存在“容错时间误差”，导致清理失败风险高。

容错计算、实时系统、截止时间调度。

使用抢占式实例运行有状态批处理作业、机器学习训练、数据处理任务，希望优雅保存状态。

T_grace: 平台提供的优雅终止宽限期；T_cleanup: 用户清理脚本实际执行时间；T_notice: 中断通知时间；Success: 清理成功标志；P(data_loss): 数据丢失概率。

实例中断状态：{运行中， 收到中断通知(开始T_grace)， 清理中， 清理完成/超时， 已终止}。数据状态：{已持久化， 部分持久化， 丢失}。

概率论：清理成功是一个事件，其概率取决于T_cleanup的分布和固定阈值T_grace。
排队论：清理任务可视为一个服务队列，总服务时间需小于T_grace。
最优化：用户需设计清理任务，使其在最坏情况下的执行时间小于T_grace，这通常意味着功能妥协。

抢占式实例运行一个数据处理作业，将结果写入本地磁盘。中断通知到来，脚本开始将结果上传到S3。由于结果文件很大或网络慢，上传耗时超过2分钟。实例被强制终止，部分结果文件未上传成功，数据丢失。

服务条款明确声明抢占式实例可能随时被回收，宽限期是“尽力提供”。用户需自担数据丢失风险。但过短的宽限期可能使“优雅终止”功能形同虚设。

1. 实例I（抢占式）正在运行，收到中断通知，元数据interruption-notice设置为true。
2. 用户配置的cloud-init或systemd服务检测到该标志，启动清理脚本S。
3. 脚本S开始执行，例如压缩日志文件并上传到S3。
4. 同时，平台计时器开始倒计时T_grace（120秒）。
5. 在第115秒，上传尚未完成。在第120秒，平台强制终止实例I。
6. 上传进程被终止，日志文件可能部分上传，状态不一致。
方程：if (interruption_noticed) { start_cleanup_script(); sleep(T_grace); if (cleanup_script_still_running) { force_terminate(); } }

顺序序列（中断通知->启动清理->计时开始->清理执行->计时结束->强制终止）。清理任务内部可能是多个子任务的顺序或并行。

清理脚本复杂度由任务决定。设计满足严苛时限的清理逻辑的复杂度高。

容错设计、检查点技术、信号处理。

P7-0076

云计算/平台商业策略与技术锁定

预留实例范围灵活性虚假宣传

预留实例宣传为"区域级"灵活性，但实际转换选项有限，且每次转换收取手续费，累积成本高。

商业策略/营销与实现差异

平台营销材料强调预留实例（RI）提供“区域级”灵活性，可轻松更改实例类型、操作系统、可用区。实际条款中，可更改的属性集合A_changeable很小，且每次更改操作需支付手续费F_change。多次更改后，累计手续费可能侵蚀RI的折扣收益。

预留实例灵活性误导引擎

1. 灵活性宣传：在官网、博客和销售材料中，使用“灵活”、“轻松更改”等词汇描述RI，并列举“区域级灵活性”作为关键优势，暗示用户可以在区域范围内自由调整RI属性。
2. 实际限制：
a. 可更改属性：用户可更改的属性集A_changeable通常是实例大小（size） within a family，可能不包括实例族（family）、操作系统、租期类型（如从全预付转为无预付）等。
b. 手续费：每次更改操作收取固定费用F_change或基于剩余价值计算的费用。即使更改很小（如从c5.large改为c5.xlarge），也需付费。
3. 累积成本：如果业务需求频繁变化，用户需要进行多次更改，总手续费ΣF_change可能变得显著，抵消了RI相对于按需实例的节省。
4. 误导效应：用户基于“灵活”的宣传购买了RI，但当需要更改时发现限制重重且成本不菲，感觉被误导。这可能导致RI利用率低下或用户被迫接受次优配置。
数学方程：
• RI属性集合：A = {type, OS, region, AZ, tenancy, ...}。
• 宣传的灵活性：A_flex_marketing ≈ A（暗示大部分可改）。
• 实际的灵活性：A_flex_actual = A_changeable ⊂ A，且

A_changeable

小。
• 更改成本：Cost_change = F_change + possible value adjustment。
• 总拥有成本：TCO_RI = RI_Price + Σ Cost_change_i。
• 相对于按需的净节省：Net_Saving = (Cost_OnDemand - TCO_RI)。由于Σ Cost_change_i可能很大，Net_Saving可能为负。
• 营销差距：Gap =

A_flex_marketing

-

A_flex_actual

> 0。

更改操作和手续费收取精确。但实际提供的灵活性（A_flex_actual）和成本与营销宣传（A_flex_marketing）存在“灵活性认知误差”和“成本透明度误差”。

营销法、合同解释、消费者行为。

购买了预留实例，后期因应用架构、性能需求或业务范围变化需要调整实例属性的用户。

A: RI完整属性集；A_flex_marketing: 营销中暗示的可灵活更改的属性集；A_flex_actual: 实际允许更改的属性子集；F_change: 单次更改手续费；Cost_change: 单次更改总成本；TCO_RI: RI总拥有成本。

RI属性状态：{初始配置， 更改请求中(校验A_changeable)， 更改后配置}。用户认知状态：{认为灵活， 发现限制}。

集合论：实际可更改属性是全部属性的一个真子集。营销夸大了这个子集的大小。
最优化：用户决策时，高估了灵活性价值，低估了未来更改成本，导致可能过度购买RI。
博弈：平台通过宣传灵活性促进销售，但通过限制和收费来保护自身收入和减少管理开销。

P7-0077

云计算/平台商业策略与技术锁定

实例存储卷性能波动缺乏保证

实例存储卷性能因物理硬件差异波动大，但平台不提供性能SLA，用户无法获得稳定性能。

技术限制/服务质量不确定性

实例存储（本地SSD/HDD）的性能取决于底层物理硬件的型号、磨损程度以及同一主机上其他实例的I/O活动。平台不为实例存储提供性能SLA（如保证的IOPS、吞吐量）。因此，用户获得的性能P_local(t)是一个方差较大的随机变量。

实例存储性能波动引擎

1. 硬件异构性：数据中心内物理服务器的本地存储硬件可能有多代或多型号混用，其性能基线不同。平台在分配实例时，用户无法选择或知晓将获得何种硬件。
2. 多租户干扰：即使使用专用实例，如果同一物理机上的其他实例也频繁访问其本地存储，可能通过共享的硬件资源（如PCIe通道、内存控制器）产生干扰，导致性能波动。
3. 无性能承诺：在服务条款中，平台明确声明不对实例存储的性能做出任何保证。性能数据仅为“设计目标”或“最大可能”，非承诺。
4. 应用影响：对I/O性能敏感的应用（如高性能数据库、大数据处理）可能因性能波动而出现不可预测的延迟或吞吐量变化，影响服务等级目标（SLO）。用户无法基于一个稳定的性能预期进行容量规划。
数学方程：
• 实例存储性能：P_local(t) = P_hardware_base + ΔP_interference(t) + noise。
- P_hardware_base: 取决于分配到的物理硬件，是一个随机变量，分布未知。
- ΔP_interference(t): 来自邻居或其他系统组件的干扰，随时间变化。
• 性能SLA：平台不提供，即不存在常数P_SLA使得 P(P_local(t) ≥ P_SLA) 有保证。
• 用户预期：用户往往基于平台宣传的“高达XX IOPS”来预期性能，即P_expected ≈ P_marketed_max。
• 性能差距：实际性能P_local(t)可能持续低于P_expected，且波动大。用户无法投诉，因为无SLA违反。

性能可测量，但波动大且无承诺。实际性能P_local(t)与用户基于营销数据产生的期望P_expected存在“性能稳定性误差”和“绝对值误差”。

服务质量、资源隔离、性能可变性。

使用实例存储作为缓存、临时工作区或对延迟有较高要求但非绝对持久化需求的场景。

P_local(t): 实例存储在时间t的性能（IOPS， 带宽）；P_hardware_base: 底层硬件的基础性能（随机变量）；ΔP_interference(t): 性能干扰项；P_marketed_max: 营销宣传的最大性能；P_expected: 用户性能期望。

实例存储性能状态：{高性能， 中等性能， 低性能}。硬件分配状态：{未知型号， 高性能型号， 低性能型号}。

随机过程：P_local(t)可以建模为一个随机过程，具有时变均值和方差。
统计：性能的分布可能具有厚尾，偶尔出现极低性能。
最优化：用户无法优化以获得稳定高性能，因为硬件分配和干扰不可控。

用户启动两个相同配置的实例，都带有实例存储。对它们进行磁盘性能测试，一个的IOPS是10万，另一个只有6万，差异显著。应用在低性能实例上运行缓慢。用户联系支持，被告知实例存储性能因硬件而异，没有保证。

服务条款通常会免责声明性能波动。用户需自担风险。但若宣传的“高达”值与实际常见值相差过大，可能涉及误导。

1. 用户启动一个带本地NVMe SSD的实例I1，进行fio测试，获得IOPS = 120K。
2. 用户稍后启动一个完全相同配置的实例I2，fio测试显示IOPS = 80K。
3. 应用在I2上运行明显更慢。
4. 用户检查监控，确认是磁盘I/O瓶颈。
5. 用户无法通过重启或迁移来“换”到更好的硬件，也无法获得性能补偿。
6. 用户若需要稳定性能，必须使用有SLA的网络存储（如EBS io2），但成本更高。
方程：P_local = random(Hardware_Pool_Performance) - variable(Interference)

随机序列：每次实例启动，随机分配到一种硬件，获得一个基础性能。运行时性能受干扰随机波动。

性能测试复杂度低。应对性能波动的应用设计复杂度高。

存储性能基准测试、硬件异构性、服务质量。

P7-0078

云计算/平台商业策略与技术锁定

虚拟机导出格式转换信息损失

虚拟机导出时格式转换（如VMDK到VHD）可能导致配置信息丢失或兼容性问题，导入其他平台后无法启动。

技术锁定/数据可移植性障碍

平台虚拟机导出功能将内部磁盘格式转换为一种或几种标准格式（如VMDK， VHD， RAW）。在转换过程中，某些虚拟机配置元数据（如虚拟硬件版本、控制器类型、磁盘几何信息）可能丢失或未正确编码。导出的镜像文件在导入其他虚拟化平台时，可能因这些缺失或不匹配的信息而启动失败。

虚拟机导出转换损失引擎

1. 导出转换：用户请求导出镜像I。平台读取内部存储的磁盘数据，通过转换器T生成目标格式文件F_out = T(I, Format_target)。T可能是一个简化的转换器，专注于数据块转换，忽略部分“非关键”元数据。
2. 元数据丢失：例如，从VMware的VMDK（包含丰富的硬件描述）转换为RAW格式时，会丢失磁盘控制器、总线类型等信息。即使转换为VHD，某些高级特性（如差分磁盘链）的支持可能不完整。
3. 兼容性问题：目标虚拟化平台在导入F_out时，需要根据文件中的信息和其默认设置来重建虚拟机配置。如果缺失关键信息，它可能使用不兼容的默认值（如错误的磁盘控制器），导致虚拟机启动时找不到引导设备。
4. 迁移失败：用户经历复杂的导出、传输、导入过程后，最终虚拟机无法启动，需要手动调整配置或使用其他工具重新处理镜像，增加了迁移成本和不确定性。
数学方程：
• 源镜像完整信息：I_full = (Data_blocks, Metadata_m)。
• 导出转换函数：F_out = T(I_full, Format_target)。通常T不是满射，也不是单射，可能存在信息损失：Metadata_lost = Metadata_m \ Metadata_in_F_out。
• 导入函数：I'attempt = Import_other_platform(F_out)。
• 导入成功条件：Success = 1 if I'attempt is bootable else 0。当Metadata_lost包含关键信息时，Success可能为0。
• 迁移工作增加：用户需额外步骤修复I'_attempt（如使用virt-v2v等工具注入驱动和配置）。

数据块转换通常无损。但元数据转换可能不完整，导致导出的镜像文件F_out与源平台内部表示I_full在语义上不完全等价，存在“信息完整性误差”。

数据格式、虚拟化兼容性、信息论。

跨云迁移（如从AWS迁移到Azure， 或迁移到本地VMware）。

I_full: 源虚拟机完整镜像（数据+元数据）；T: 平台导出转换函数；Format_target: 目标格式（如VHD）；F_out: 导出的文件；Metadata_lost: 丢失的元数据；Import_other_platform: 目标平台的导入函数。

镜像状态：{内部格式， 已导出(F_out)， 导入目标平台尝试中， 导入成功/失败}。元数据状态：{完整， 部分丢失}。

信息论：转换过程T可以视为一个通信信道，从源到目标传输虚拟机信息。元数据丢失相当于信道噪声或容量限制。
函数映射：T是从源平台镜像空间到标准格式空间的映射，该映射可能不是一一对应，导致逆映射（导入）不唯一或不存在。
集合论：可成功导入的镜像集合是标准格式空间的一个子集。导出镜像F_out可能不在该子集内。

用户从AWS导出Windows Server实例为VHD文件。将VHD上传到Azure并创建镜像。从该镜像启动Azure虚拟机时，启动失败，错误提示“操作系统未找到”或“磁盘0无法访问”。原因是AWS使用的虚拟SCSI控制器与Azure的默认IDE控制器不兼容，而VHD文件中未包含控制器信息。

平台提供了导出功能，但不保证导出镜像在其他环境的兼容性。用户需自行负责格式转换和兼容性测试。

1. 用户在AWS上将实例I创建为AMI，然后导出该AMI为VMDK文件。
2. 用户下载VMDK文件，并可能需要用qemu-img转换为VHD格式以供Azure使用。
3. 用户将VHD上传到Azure存储账户，并创建Azure镜像。
4. 用户从该镜像创建Azure虚拟机，启动失败。
5. 用户需使用Azure工具（或手动）为VHD注入Azure所需的Linux代理或驱动程序，或调整启动配置，过程复杂。
方程：F_out = Convert(Internal_Image, TO_VMDK); // May lose controller type, generation info

顺序序列（导出->下载->可能二次转换->上传到目标平台->创建镜像->启动实例->可能失败->故障排除）。

导出操作复杂度O(镜像大小)。解决兼容性问题的复杂度高。

虚拟磁盘格式、P2V/V2V迁移工具、操作系统部署。

P7-0079

云计算/平台商业策略与技术锁定

安全组规则数量硬性上限

每个安全组规则数量有硬性限制（如50条入站规则），大型应用需拆分为多个安全组，增加管理复杂性。

技术限制/资源配置上限

平台对每个安全组允许的入站（Ingress）和出站（Egress）规则数量分别设置上限N_max_ingress和N_max_egress（例如各50条）。当应用需要更多规则时，必须创建多个安全组并将它们关联到实例，或者将规则合并（使用CIDR范围），但这会降低安全粒度。

安全组规则配额引擎

1. 配额定义：在账户或VPC级别，每个安全组对象有规则数量限制。例如，最多50条入站规则，50条出站规则。这是硬编码的限制，无法通过支持请求提升（或提升非常有限）。
2. 规则需求增长：复杂的企业应用可能需要对大量特定IP地址（如合作伙伴、内部系统）或端口开放访问。随着微服务拆分，规则数量可能快速增长。
3. 管理复杂度增加：当规则数超过上限时，用户必须：
a. 拆分为多个安全组，并将这些安全组附加到实例。这增加了安全组之间的隐式“与”逻辑管理难度。
b. 合并规则，使用更大的CIDR块，但这扩大了访问范围，违反了最小权限原则。
4. 自动化挑战：基础设施即代码（IaC）模板需要处理规则拆分逻辑，增加了模板的复杂性。对安全组的更改可能需要跨多个资源进行，容易出错。
数学方程：
• 安全组规则集：R = R_ingress ∪ R_egress。
• 规则数量限制：

R_ingress

≤ N_max_ingress,

R_egress

≤ N_max_egress。
• 应用所需规则集：R_needed。可能

R_needed_ingress

> N_max_ingress。
• 解决方案：将R_needed划分为k个子集{R1, R2, ..., Rk}，使得每个

Ri

≤ N_max_ingress。需要创建k个安全组，并全部关联到实例。
• 管理开销：Overhead = f(k)，随着k增加而增加。安全策略的清晰度和可维护性下降。
• 安全粒度损失：如果合并规则，则实际生效的规则集R_actual ≠ R_needed，且可能更宽松。

规则执行精确。但数量限制N_max迫使管理架构复杂化，与简单、集中的安全策略管理愿景存在“管理效率误差”。

访问控制列表、组合爆炸、配置管理。

具有大量上游依赖（需许多入站规则）或需要访问许多下游服务（需许多出站规则）的复杂应用，如API网关、集成平台。

R_ingress, R_egress: 入站和出站规则集合；N_max_ingress, N_max_egress: 规则数量上限；R_needed: 应用实际需要的规则集；k: 所需的安全组拆分数量；Overhead: 因拆分增加的管理开销。

P7-0080

云计算/平台商业策略与技术锁定

实例放置组故障域泄漏

放置组（Placement Group）中一个分区故障可能影响同组其他实例，尽管宣传为隔离故障域。

架构缺陷/故障隔离不彻底

放置组（如AWS的集群置放群组）旨在将实例紧密放置以降低延迟。平台可能宣传其具有“高可用性”配置，将实例分布在多个“分区”以隔离故障。但实际上，这些分区可能共享底层硬件（如机架交换机、电源），导致一个分区的故障（如网络设备故障）扩散影响到其他分区的实例。

放置组故障扩散引擎

1. 放置组结构：放置组PG被逻辑划分为多个分区（Partition）。平台声称实例放置在不同分区可以提供故障隔离，即一个分区失效不影响其他分区。
2. 实际物理依赖：不同分区可能位于同一机架，共享顶部架式交换机（ToR）、电源分配单元（PDU）或冷却系统。如果共享的物理基础设施发生故障，多个分区会同时受影响。
3. 故障扩散：当共享的ToR交换机故障时，即使实例位于PG的不同逻辑分区，它们都会失去网络连接，导致服务中断。这违反了用户对“分区隔离故障”的预期。
4. 信息不透明：用户无法知晓分区的实际物理布局和共享依赖。平台可能不披露这些细节，使用户基于错误的假设（完全隔离）设计高可用架构。
5. 高可用性失效：用户将实例分散在PG的多个分区中，期望实现机架级或更高层级的容错，但实际上仍存在单点故障。
数学方程：
• 放置组分区集合：P = {p1, p2, ..., pn}。
• 物理故障域集合：F = {f1, f2, ...}，如机架、交换机、电源。
• 映射函数：M: P -> 2^F，表示每个分区依赖的物理故障域集合。理想隔离下，对于i≠j，应有M(pi) ∩ M(pj) = ∅。实际可能∃ i≠j, M(pi) ∩ M(pj) ≠ ∅。
• 故障事件：某个物理故障域fk失效。
• 受影响分区：Affected(P, fk) = {pi

fk ∈ M(pi)}。由于共享依赖，

Affected

> 1 的可能性存在。
• 用户风险：用户预期

Affected

= 1（单分区故障），实际可能>1。

分区逻辑划分精确。但分区到物理故障域的映射M可能存在重叠，导致实际故障隔离性低于宣传，存在“隔离性误差”。

故障域建模、高可用性设计、物理拓扑。

使用放置组部署高可用集群，如数据库（如Cassandra, Kafka）、高性能计算集群。

P: 放置组的分区集合；F: 物理故障域集合；M: 分区到物理故障域的映射函数；Affected(P, fk): 受物理故障域fk影响的分区集合。

放置组状态：{分区正常， 分区故障}。物理故障域状态：{正常， 故障}。

图论：分区和物理故障域构成一个二分图。理想隔离是该图是一个完美匹配。实际可能存在一个物理节点连接多个分区节点。
集合论：分区的物理依赖集合。隔离要求这些集合互不相交。实际可能存在交集。
可靠性工程：系统的整体可靠性取决于最弱的一组共享组件。

用户创建一个具有3个分区的放置组，在每个分区启动一个Kafka broker，期望实现机架级容错。某日，承载分区1和分区2的机架的ToR交换机故障，导致两个broker同时离线，Kafka集群无法选举leader，服务完全中断。用户本以为只有1个broker会受影响。

P7-0081

云计算/平台商业策略与技术锁定

资源标签元数据容量限制

资源标签键值长度限制过短（如键128字符、值256字符），无法存储详细元数据或编码信息。

技术限制/元数据表达力约束

平台对标签的键（Key）和值（Value）字符串长度分别设置上限：Max_Key_Len = K, Max_Val_Len = V（例如K=128, V=256）。当创建或修改标签时，系统验证输入字符串长度，超限则拒绝。

标签长度验证引擎

1. 输入验证：用户为资源R提供标签对 (k, v)。系统计算 len(k) 和 len(v)。
2. 长度检查：if len(k) > K or len(v) > V: 操作失败，返回错误“Tag key/value too long”。
3. 信息压缩需求：用户无法存储较长的描述性信息，如完整的错误追踪链接、详细的配置说明、复合属性的序列化字符串（如JSON）。必须对信息进行截断或编码，损失可读性或信息量。
4. 管理粒度受损：在需要精细分类和追溯的场景（如CI/CD流水线传递丰富上下文），标签无法承载足够信息，迫使使用外部系统或更复杂的命名约定。
数学方程：
• 标签对：T = (k, v)。
• 长度约束：`

k

≤ K,

v

≤ V。<br>• 用户期望信息：I_desired，通常可以编码为字符串s，使得

s

可能 > V。<br>• 实际可存储信息：I_stored = truncate_or_encode(I_desired)，使得

I_stored

≤ V`。信息损失 L = I_desired - I_stored。
• 表达能力：标签系统可表达的字符串空间大小为 Σ (K字符集^K) * (V字符集^V)，但用户被限制在此空间内。

长度检查精确。但长度上限K和V与用户存储复杂元数据的需求不匹配，存在“元数据表达力误差”。

信息论、字符串处理、元数据建模。

需要为资源附加详细上下文、合规信息、审计追踪标识的场景。

k, v: 标签键和值字符串；K, V: 平台规定的键/值最大长度；I_desired: 用户希望存储的信息；I_stored: 实际存储的信息（截断/编码后）；L: 信息损失。

P7-0082

云计算/平台商业策略与技术锁定

自定义镜像强制加密与密钥绑定

自定义AMI强制加密，且必须使用平台KMS，无法导出为未加密格式在其他环境使用。

技术锁定/数据可移植性与安全绑定

平台在创建自定义AMI时，默认或强制要求使用平台密钥管理服务（KMS）的客户主密钥（CMK）对AMI进行加密。加密后的AMI无法以未加密格式导出，或导出的镜像文件本身仍处于加密状态，在其他没有该CMK访问权限的环境无法解密启动。

强制AMI加密与导出封锁引擎

1. 加密强制：在创建自定义AMI的流程中，加密选项被默认选中且可能无法取消，或明文提示“必须使用KMS加密”。用户必须选择一个平台KMS中的CMK。
2. 加密过程：AMI的数据块被使用数据加密密钥（DEK）加密，DEK又被指定的CMK加密。加密后的AMI存储在平台内部。
3. 导出限制：导出AMI时，系统只生成加密的镜像文件（如加密的VMDK）。即使选择导出，导出的文件仍需用原CMK解密才能使用。
4. 跨环境阻断：用户无法获得未加密的原始镜像文件。若想在其他云或本地虚拟化环境使用该镜像，由于无法访问原平台KMS，无法解密，导致迁移失败。
5. 安全名义下的锁定：以“增强安全性”为由，行“数据锁定”之实。
数学方程：
• 镜像数据：M。
• 加密函数：E(M, CMK) -> C。其中C是加密镜像，解密需要CMK。
• 导出函数：Export(C) -> F_encrypted。F_encrypted是加密的磁盘文件。
• 解密可行性：Decrypt(F_encrypted) = M iff 拥有 CMK 访问权限。
• 跨平台可行性：Feasible(Use_In_Other_Env) = 拥有 CMK 访问权限。由于CMK不可导出，在其他环境此项为假。
• 锁定强度：镜像被完全锁定在平台内。

加密操作精确。但强制加密和密钥不可移植性导致镜像可移植性为0，与用户“拥有镜像数据”的预期存在“数据控制权误差”。

密码学、密钥管理、供应商锁定。

创建包含敏感数据或专有软件的自定义AMI，并可能考虑未来多云部署或灾备的场景。

M: 原始镜像数据；C: 加密后的镜像；CMK: 客户主密钥（平台KMS托管）；E, Decrypt: 加密和解密函数；F_encrypted: 导出的加密文件。

AMI加密状态：{未加密(可能不可选)， 已加密(使用平台CMK)}。可移植性状态：{可迁移， 不可迁移(因加密)}。

密码学：基于对称加密的密钥包装。解密密钥（CMK）是解锁所有数据的唯一密钥。
逻辑：IF (AMI created) THEN MUST be encrypted with KMS_CMK。导出的是密文。
集合论：可使用镜像的环境集合是拥有CMK访问权的环境集合，通常是原平台账户的子集。

控制台创建AMI时，“加密”选项默认勾选，KMS密钥下拉框必选。文档说明“为安全起见，自定义AMI必须加密”。尝试导出AMI时，没有“不加密导出”的选项。

平台可以安全合规为由要求加密。但若完全不提供导出明文镜像的机制（即使经过严格审批），可能妨碍用户的数据主权和业务连续性，在极端情况下（如平台服务终止）造成灾难性后果。

1. 用户从实例创建自定义AMI，在加密设置中必须选择一个KMS密钥（或使用默认）。
2. AMI创建成功，处于加密状态。
3. 用户尝试将AMI复制到另一个区域或导出到S3。
4. 复制或导出成功，但生成的新AMI或S3文件仍是加密状态，且绑定原CMK。
5. 用户尝试在另一个AWS账户（无该CMK权限）或本地VMware使用导出的文件，无法解密，启动失败。
方程：CreateImage(Instance, Encryption={Enabled: True, KmsKeyId: CMK})

顺序序列（创建加密AMI->尝试迁移/导出->发现仍加密->尝试外部使用->失败）。

创建加密AMI复杂度O(1)。解决加密锁定问题的复杂度无限大（无法解决）。

镜像管理、密钥管理、数据加密标准。

P7-0083

云计算/平台商业策略与技术锁定

实例生命周期挂钩超时诊断缺失

实例生命周期挂钩超时后，平台自动继续生命周期操作，但未提供超时原因诊断信息。

运维模型/可观测性缺陷

当实例生命周期挂钩脚本执行时间超过配置的超时时间T_timeout时，平台自动将挂钩状态标记为ABANDON或TIMEOUT，并继续执行原始的生命周期动作（如启动或终止实例）。然而，平台不提供或只提供极少量的关于脚本为何超时的诊断信息（如标准输出、标准错误、资源使用情况）。

挂钩超时黑盒处理引擎

1. 超时监控：平台启动挂钩脚本，并启动计时器。若脚本在T_timeout内未返回成功信号，计时器触发超时事件。
2. 静默失败处理：平台记录一个简单事件，如“生命周期挂钩超时”，然后绕过挂钩继续执行。脚本进程被强制终止。
3. 诊断信息缺失：用户查看挂钩执行历史或事件日志，只能看到“超时”状态，没有：
a. 脚本已执行的输出日志。
b. 脚本被终止前的资源使用（CPU， 内存）。
c. 可能遇到的错误（如网络连接失败、包下载慢）。
4. 排障困难：用户无法区分是脚本逻辑错误、依赖服务不可用，还是资源不足导致的超时。必须通过其他方式（如自定义日志、外部监控）来重现和调试，效率低下。
5. 责任模糊：平台通过不提供详细日志，将调试责任完全推给用户。
数学方程：
• 挂钩执行时间：T_exec。
• 超时条件：T_exec > T_timeout。
• 平台记录：Log = {Hook_ID, Status: “TIMEOUT”, Timestamp}。信息量I_platform = H(Log) 很小。
• 用户所需诊断信息：D_needed = {stdout, stderr, resource_usage, external_dependency_status, ...}。信息量I_needed = H(D_needed) 很大。
• 信息差距：ΔI = I_needed - I_platform > 0。用户处于信息缺失状态。
• 排障成本：Cost_debug 与 ΔI 正相关。

超时检测和状态记录精确。但提供的诊断信息I_platform远少于排障所需I_needed，存在“可观测性误差”，导致调试困难。

分布式调试、日志记录、可观测性。