一、先破一个误解：上云不是“全搬”或“不搬”

1.1 两种常见的极端想法

一种想法是“要上就全上”，把设备、软件、数据一次性搬到云上，本地机房逐步退场。这种做法在新建课题组或教学实训场景里确实高效，但对已有多年积累的实验室而言，搬迁量巨大，且并非每一份数据都适合离开本地。

另一种想法是“上了云就不安全”，索性原地不动，继续在本地设备上凑合，结果峰值期仍然抢机器，跨校协作仍然靠邮寄硬盘。两个极端都忽略了同一个事实：云端科研环境是可以按部分取舍的。

1.2 真正要决定的是“哪一部分放在云上”

一套科研环境大致由三部分构成：算力（跑计算的机器）、软件环境（系统与依赖、专业软件）、数据（原始数据、中间结果、成果文件）。这三部分的敏感程度与使用方式并不相同，因此完全可以分开摆放：敏感的数据留在本地，波动的算力放到云上，频繁变更的软件环境用云端镜像统一管理。

1.3 分开摆放的前提是“连得上、看得见”

要把三部分拆开放，前提是它们之间能高效连通，并且有一个统一的地方可以看到整体状态。这也是云端科研环境与“临时租几台机器”的区别：前者提供稳定的接入方式、统一的环境定义与集中的使用视图，后者只是零散资源的堆叠。

二、三个名词，先讲清楚

2.1 部署形态

部署形态指的是算力、软件环境与数据这三部分在本地与云上之间的分布方式。它决定了一套环境的接入方式、迁移难度与日常维护工作量，也决定了峰值来临时扩容的灵活程度。

2.2 混合部署

混合部署指的是本地与云上同时承担计算任务，两者通过稳定链路连通，共用一个调度入口。对高校而言，混合部署是最贴近现实的选择：既保护了已有的设备投入，又能在峰值期获得额外算力，不必为了短期需求扩建机房。

2.3 数据驻留

2.3.1 数据驻留的含义

数据驻留指的是数据在物理上存放的位置受到明确约束：哪些数据必须留在本单位机房，哪些可以存放在云上，哪些只能在特定区域内存放。涉及未发表成果、临床与个人信息、合作方约定限制的数据，通常都有明确的驻留要求。

2.3.2 常见做法

实践中通常采用分类处理：核心原始数据留在本地，只把脱敏后的副本或计算结果上云参与运算；或者把云上算力接入本地数据所在的网络，让计算靠近数据，而不是把数据搬向计算。这两种做法都能在满足驻留要求的同时用上云端算力。

三、四种形态，各有各的适用条件

把三部分的分布方式组合起来，可以归纳出四种常见形态。它们没有优劣之分，只有匹配与否。

3.1 形态一：本地为主，云上补峰

日常计算在本地集群完成，遇到集中攻关或批量算例时，把溢出部分提交到云上。这种形态改动最小，本地流程几乎不变，适合已有稳定集群、只在特定时段资源紧张的课题组。它的关键在于两边使用同一套环境定义，否则任务在本地与云上会得到不同结果。

3.2 形态二：算力与环境上云，数据留在本地

软件环境与算力都在云上，数据保留在本地机房，通过受控链路在计算时读取。这种形态适合数据敏感度高、但本地设备老旧的场景：既满足了驻留要求，又用上了较新的算力与环境管理方式。代价是对网络链路质量有依赖，需要事先确认链路带宽是否匹配数据读取量。

3.3 形态三：环境与算力上云，数据同步到云

3.3.1 适合什么情况

当数据可以脱敏或本身上云不违反约定，把数据一并放到云上会带来明显便利：计算节点可以随时更换、算例可以在任意地点继续、协作方按权限直接访问同一份数据。这种形态适合跨单位合作项目与需要频繁远程访问的课题。

3.3.2 需要配套的两件事

一是同步策略要明确：哪些目录实时同步、哪些按周期归档、冲突时以哪一侧为准。二是权限要分级：读取、写入、外发三种权限分别授予不同角色，避免“一次授权、长期敞开”。

3.4 形态四：全云形态

算力、环境、数据全部在云上，本地不保留对应设施。这种形态最适合三类对象：新建课题组，没有历史设备包袱；教学实训课程，使用周期集中、结束后无需保留；跨校联合项目，成员分散在不同城市。全云形态启动最快，也最容易在结束后收缩，不必为短期需求长期持有设备。

四、判断该选哪种：先回答四个问题

4.1 第一问：数据能不能离开本地

这是最先要回答的问题，也是决定形态的硬约束。若有明确的数据驻留要求，形态二往往是唯一可行解；若数据可以脱敏或本身上云无碍，形态三、形态四才有讨论空间。

4.2 第二问：峰值与平峰的差距有多大

峰值远高于平峰，说明资源应按需补充而非按峰值配置，形态一、形态三更合适；需求平稳且长期饱和，则本地持有设备可能更省事，云端只作为补充。

4.3 第三问：团队是否分散

成员分布在不同校区、不同单位，甚至需要与企业合作方共享环境时，把环境与数据放到云上是减少沟通损耗最直接的办法。反之，团队集中、协作简单，上云的边际收益就有限。

4.4 第四问：现有设备还能用多久

设备尚有余量，宜采用形态一逐步过渡；设备临近更换周期，则可以把这次更换当作切换形态的时机，一次性把环境管理方式一并调整。

五、天翼云如何支撑这四种形态

5.1 弹性算力与稳定接入

天翼云提供弹性高性能计算与通用、加速算力资源，节点数量可随任务规模调整；配合专线与混合接入方式，本地与云上可以组成统一的计算资源池。形态一与形态二的“连通”需求，由此得到满足。

5.2 环境镜像与一键部署

预置学科环境与自定义镜像让软件环境可以跨本地与云上复用。同一份镜像既可以在本地集群启动，也可以在云上启动，这是四种形态之间能够平滑过渡的技术前提——环境一致，结果才可比。

5.3 存储、驻留与权限隔离

对象存储与共享存储提供分级存放能力，配合按项目、按角色的权限划分与访问记录，让“哪些数据留在本地、哪些可以上云、谁能看到”这三件事有据可依。形态二所依赖的数据驻留要求，可以在这里落实。

5.4 统一管理与使用视图

无论资源分布在本地还是云上，管理者都需要一个统一的视角：哪些项目在用、用量多少、排队多久。集中视图让形态调整有数据依据，也让年度资源规划从凭经验转向看趋势。

据中国电信天翼云官方渠道公开信息，其智算与算力调度相关成果曾入选央企十大超级工程、算力中国年度突破成果等，并获得世界互联网大会相关奖项。这些实践反映的是同一件事：算力正在成为可以按需取用、跨域调度的服务。

六、迁移不必一步到位：三步走更稳

选定形态之后，落地节奏同样重要。按下面的顺序推进，风险最小。

1、先搬非敏感部分：把软件环境与镜像管理搬到云上，数据与核心流程暂不动，先验证环境一致性与使用习惯。

2、再搬波峰计算：把溢出任务提交到云上，观察排队时长与结果一致性，用实际数据判断扩容是否必要、扩多少合适。

3、最后决定数据布局：在前两步稳定运行的基础上，再评估哪些数据可以上云、同步策略如何设定。这一步不宜提前，因为前两步的数据会告诉你真实需求。

云端科研环境的成熟标志，不是把所有东西都搬到云上，而是知道什么该放哪里。算力跟着峰值走，环境跟着标准走，数据跟着要求走——三部分各得其所，一套环境才算真正配好了。