在 VFX/动画工作室，把几百名艺术家的 Windows 工作站在线迁移到 Linux，乍听起来像是一场冒险。有人已经走过了这条路，结论很一致：别把它当成单纯的 IT 项目，它本质上是一场组织变革。下面整理了一些经历过类似迁移的 sysadmin 的真实经验，每个环节都有值得参考的细节。
先问自己：用户知道吗？团队支持 Linux 吗？
很多技术团队容易忽略一个问题：艺术家们是否“上船”了？有评论直指要害：“他们知道这件事吗？还是说完全不知情？”在 VFX 公司，艺术家的创作工具高度个性化，他们依赖 Windows 上的特定软件、快捷键、插件甚至是 GPO 下发的网络盘映射。如果只是 IT 单方面决定迁移，阻力会非常大。
同样重要的是 IT 团队自身的能力。有人提醒：“你们团队在部署、管理和支持 Linux 用户方面有多少经验？”Ansible/Terraform 能解决自动化部署，但日常的故障排查、用户请求、驱动问题、软件兼容性……都需要有经验的 Linux 支持人员。如果公司没有打算采购企业级支持（比如 Red Hat 订阅），完全靠自己“winging it”，风险极高。
测试，反复测试：没人能预测每个人的真实工作流
这是几乎所有人都强调的一点。“你必须要测试，天哪你必须测试。不可能知道每个人到底是怎么工作的，每个团队都有一点点不同。”在 VFX 工作室，不同部门可能使用不同的渲染器、合成软件、资产浏览器甚至特定的 Wacom 驱动配置。纸上列出的软件清单，和艺术家实际每天的操作往往差距很大。
建议的做法：先建立一个原型环境，挑选两三个有代表性的部门做小范围试点，让他们在实际项目里用 Linux 工作站工作一段时间，记录所有抱怨和缺失的功能。然后在试点过程中不断调整系统镜像、默认配置和软件包。有评论提到“试点部署”是非常关键的一步。
自动化部署与配置：Ansible + Terraform 是主流组合
对于基础系统交付和配置管理，被提及最多的组合是：Ansible Tower（或 AWX）配合 Terraform（或 OpenTofu）。有人明确说：“我就是用这套组合做了几个部门的迁移。”不过，这取决于你的基础设施是裸机还是虚拟化。如果是虚拟机，Terraform 可以用来编排 VM 生命周期；如果是物理工作站，可能需要 Kickstart 或类似的无人工介入安装机制，再用 Ansible 做后续的配置漂移管理。
没有统一的“正确”答案，但工具的核心思路是：系统镜像必须不可变或可重复构建，所有配置（包括用户组、安全策略、挂载点、桌面环境设置）都写进代码里。这样一旦某个部门需要特殊调整，只需要修改分支或变量即可。
原来 GPO 给的，Linux 上用什么替代？
Windows 的 GPO 曾经控制着安全基线、桌面壁纸、软件分发、网络驱动器映射、PowerShell 脚本等。迁到 Linux 后，这些功能需要重新实现。从评论中可以总结出几个方向：
- 用 SSSD / FreeIPA 替代 AD 域控，处理身份验证和策略
- 用 Ansible playbook 替代 GPO 的用户配置（比如设置默认 shell、环境变量、桌面图标）
- 用 Saltstack 或 Puppet 也可以，但 Ansible 在 VFX 行业更常见
- 网络共享、打印机映射可以通过 systemd automount 或桌面端脚本完成
但不要低估这些“看起来简单”的部分。有人特别提到：“那些纸面上看起来容易，实际上变成一堆恐龙粪的事情”往往就发生在边缘场景——比如某些艺术家需要访问一个只支持 Windows 的插件存储服务器，或者某个部门依赖一个只能在 IE 里运行的老旧资产管理工具。
最坏的情况：员工偷买 MacBook
评论里有一个尖锐的警告：“让我猜猜，一个月后你的员工会忍无可忍，然后自掏腰包买一批 MacBook。”这看起来是玩笑，但在 VFX 行业其实很常见。如果新系统让艺术家的工作效率下降了 30%，他们就会绕过 IT 部门寻找替代方案。
还有一个现实观点：如果你的公司经济状况不良到需要从 Windows 迁到 Linux 来省钱，那这本身就是一个危险信号——尤其是当工作室有 400 名艺术家时。这类迁移不会比采购 Mac 更便宜，除非把支持和培训成本都算清楚。
一个实际的处理顺序
根据这些经验，一个稳妥的推进路径大概是：
- 成立一个由 IT 和艺术家代表组成的试点小组，明确迁移目标（成本、性能、还是技术栈演进）
- 在 Rocky Linux 9 + KDE 上准备最小可用镜像，装上行业常见软件（如 Maya、Nuke、Blender、Houdini 等）
- 给试点小组用 1-2 个月，期间记录所有兼容性问题，并定期迭代镜像
- 用 Ansible/Terraform 把基础环境代码化，同时建立分发渠道（如本地镜像仓库）
- 向全公司公开试点结果，举行 Q&A 和培训，让所有用户都提前知道变更时间线
- 分批次迁移，先从操作系统使用比例较高的“技术艺术家”开始，最后迁移 Windows 重度依赖部门
迁移本身不是技术难题，难的是让所有人相信这件事值得做。如果 400 人的工作室里，有一半人都愿意配合测试，那成功的可能性已经超过一半了。