H3C CloudOS 云操作系统深度解析：架构设计与核心能力

云平台上线三个月后，通常会有人来问一个技术之外的问题："这台虚拟机是谁的？能不能关掉？"

那一瞬间你会发现：云平台上线之后第一个变复杂的不是技术栈，是账。 而这个问题之所以能问出来，正是因为云操作系统已经悄悄完成了一件比虚拟化更根本的事——它把资源的所有权换成了分配权。

#一、定位：它是一种分配制度

虚拟化解决的是"一台物理机怎么切成多台"。云操作系统解决的是另一个问题：在一个组织里，谁有权拿到多少资源、通过什么流程拿、用完之后怎么算、怎么还。

这两件事经常被混为一谈，因为它们的界面长得一样（都是"创建虚拟机"的按钮）。但差异在按钮之外：

看第四行和第五行：它们已经不是技术问题了。这就是为什么"上一套云平台"经常卡在组织层面而不是技术层面——它要求组织先承认"资源是有主的"。

#二、架构分层：在哪里和 OpenStack / K8s 重叠

云操作系统的分层，用一句话可以概括：上面是组织语义，下面是资源语义，中间是翻译层。

服务目录 / 门户 / 审批流        ← 组织语义（角色、流程、SLA）
   ↓
计量与配额 / 计费 / 报表        ← 翻译层（把技术量折算成组织量）
   ↓
编排与调度（虚拟化 / 容器 / 裸金属）
   ↓
资源池（计算 / 存储 / 网络 / 镜像）
   ↓
物理基础设施

值得注意的是，中间这两层和 OpenStack、Kubernetes 是有能力重叠的。现实中常见的两种做法：

• 云操作系统自己把编排做完整（管理面与编排面同源），好处是一致，代价是生态绑定。
• 云操作系统站在 OpenStack/K8s 之上做治理（编排交给成熟底座），好处是底座能力不用重造，代价是跨越两层排查问题——一次故障要从"门户报错"一路追到"底层调度器为什么拒绝"。

这不是"哪种更好"，而是：你愿意把复杂度放在同一层，还是分在两层的接缝上。 前者看起来自研多，后者在出故障时更难定位。选之前先确认自己团队更擅长哪一侧。

#三、被低估的三件事：配额、审批、回收

产品介绍通常重点讲编排和调度，因为那部分最能体现技术含量。但真正决定这套东西能不能长期跑下去的是另外三件：

配额。 配额不是"限制用户"，是给资源池划出可预测的边界。没有配额的共享池，资源会被少数人的习惯性超配吃光，然后所有人一起变慢。配额的关键是"按什么维度设"：vCPU/内存/存储/实例数？只按一个维度设配额，等于没设。

审批。 审批流的价值不是"拦住申请"，而是留下决策记录。一个没有审批的云平台，在出账的时候无法回答"这批资源是为什么开的"。但审批也不能太重——审批链每长一环，绕开它的动机就强一分（直接找管理员开、或者在自己机器上偷偷跑）。

回收。 见下一节，它值得单独说。

这三件事有一个共同特征：它们在功能演示里全都看不到，但在第二年全部会变成主要矛盾。这也是几乎所有私有云项目的共同节奏——第一年比谁功能多，第二年开始比谁收得回来。

#四、租户隔离：分清哪些边界是真的

多租户讲得很多，但落到可验证的层面，隔离只有四类边界，强度差别非常大：

要看清楚第二行：配额是政策，不是隔离机制。把配额当成安全边界，是把"不方便"误当成"不可能"。真正的隔离得靠网络与凭证。

这里还有一个特别容易出事的地方：镜像。一个租户上传的镜像里如果带有后门或硬编码凭证，它被别的租户使用时就变成了一条跨租户通道。所以私有云的镜像仓库通常需要比公有云更严格的入库审核（这一点和公有云的角色正好相反——公有云靠规模化与自动化校验，私有云只能靠流程）。

#五、计量：把技术资源翻译成组织语言

计量这件事听起来是财务需求，其实它首先是个技术设计问题：你要以多细的粒度记录资源使用，决定了你事后能回答多细的问题。

现实里最常见的困境是：第一年不做计量，第二年被要求分摊成本时，历史数据已经取不回来了。 所以哪怕暂时不做计费，也建议从第一天开始把"实际使用"记下来——数据可以先不用，但不能不采。

#六、回收为什么最难

回收难，表面上是因为"怕删错"。深层原因是三条，没有一条是技术问题：

1. 所有权不明。 虚拟机创建时没有登记责任人，半年后只能靠猜。这是流程缺失，不是工具缺失。
2. 停机需要一个承担后果的人。 关掉之后业务出问题，责任归谁？在没有明确规则的组织里，没人愿意签这个字。
3. 验证成本高于收益。 确认一台机器确实没人用，往往要问一圈人；而省下的那点资源，对提问者没有直接收益。

对应的可行做法也就三条，都是制度性的：

• 创建即登记：责任人字段设为必填，且不能填"待定"。
• 默认到期：给每个资源一个到期时间，到期不是自动删，是自动进入待确认队列并通知责任人。这一步把"我主动去关"换成"你不续期就等于同意关"，动机结构完全反过来了。
• 给回收者记功：如果回收动作没有任何正向反馈，它永远不会成为习惯。

第三条听起来像管理学，不是技术。但对私有云来说，它就是运维的一部分——技术手段只能把回收变得低成本，不能把它变得"有人愿意做"。

#七、落地顺序：先能审计，再谈自助

如果让我排一个顺序（这是我自己的偏好，不是厂商推荐）：

1. 资源池 + 配额 + 责任人字段：先把"资源有主"这件事立起来。
2. 计量数据采集：可以不做报表，但必须先存下来。
3. 审计日志：谁在什么时候改了什么，必须可查。这一步是后面所有治理的前提。
4. 审批流：在有了前三步之后再加，否则审批只是在制造绕过的动机。
5. 自助服务目录：最后做。自助的前提是边界清晰，边界不清晰的自助等于把混乱自动化。

反过来（先上自助目录、后补治理）也能跑，只是第二年的返工量会大得多。

#八、这篇没写什么

• 没写具体产品的部署步骤与参数。 版本差异大，且这类内容的价值随时间衰减很快，请以你手上的版本手册为准。
• 没写与公有云的对比。 这是一个真实但独立的问题（成本、合规、弹性、组织成熟度四条线），塞进这里会让两边都讲不清。
• 没写容器平台的关系。 云操作系统与 K8s 的边界正在变化中，现在下结论为时过早；第二节只标出了重叠区域。
• 没给"该不该上"的结论。 这个问题取决于你的组织是否已经承认"资源有主"，而这只有你自己能回答。

如果只带走一句：云操作系统真正交付的东西不是虚拟化能力，是一套可审计的分配制度。 评估它的时候，不要看它能开多少种资源，要看它能不能回答"这台机器是谁的、为什么还在"。