关于我们如何管理多站点达芬奇工作流的概述

过去的几年里，和你们中的许多人一样，我们频繁在家里工作。起初，这是出于必要（疫情关系），但后来这变得更像是一种生活方式的自主选择。在我们所在的大华盛顿特区，人们常常会花2到3个小时在车里，堵在上下班的车流中。这特别烦人！

几年前，我们的工作流是基于单一工作地点设置的——我们在马里兰州银泉有个工作室。这不仅意味着那里是我们日复一日工作的地方，也意味着所有数据都在那里存储和输入/输出。

当团队中的每个人每天都来工作的时候，这个集中式的地点很棒，但当疫情来袭的时候，我们就不得不迅速改变方向找到在家工作的最佳方式。而这发展到现在，我们现在基本在哪儿都能工作了。

我们一直被问到建立这样的多站点工作流需要什么组件的问题。在本期的 The Offset Podcast 中，我们会讨论一下我们工作流的主要支撑部分。

这包括：

• 利用BMD云托管我们的项目数据库
• 利用TrueNas的NAS设置
• 使用SyncThing保持工作地点之间的同步
• 网速快的重要性

还有一些其他领域这集我们暂时没有讲到，但未来的集数里还会提到，包括实时推流，利用交换机控制远程调色会议，等等。

——罗比和乔伊

罗比：在今天的节目中，我们探讨的是工作流，而这不仅仅是一般的工作流，而是乔伊和我每天在项目中实际使用的工作流。欢迎收听/收看。

罗比：大家好，我是罗比·卡曼（Robbie Carman）

乔伊：我是乔伊·迪安那（Joey D’Anna）

罗比：欢迎继续收看Offset播客的这一集。乔伊，今天我们讨论的是工作流。这是人们每天都津津乐道的事情——在我们这个圈子，后期制作，以及完成片制作领域都是如此。当然，有很多不同类型的工作流，但我们经常，差不多每周，都会被问到我们在彼此之间和我们的不同地点之间建立的是什么样的工作流。

罗比：我今天想探讨一下这个问题，因为我们通常会回答很多问题——就像我之前说的——但据我所知我们还没有做过任何比较特别的事情。我们只是把很多不同的部分连到一起让事情变得更有效率。但在开始介绍我们的工作流之前，让我们先谈谈我们所面临的情况和一些挑战。

罗比：我们也正在努力克服这些，因为我们还是遇到过一些挑战的。大家都知道我们有一间办公室，是我们的主办公设施，我们经常在那儿审片。我们在那儿工作。那是我们整个音频小组的基地。但如你所见，乔伊那儿的房间其实就在他家的地下室里。

罗比：我家地下室也有类似的设置。所以我们有这么三个地点，但我们经常碰面，结果就变成了这里有些媒体文件，那里也有些媒体文件和项目的情況。而且多年来，乔——我不想说我们为此做得很艰苦，因为我们有一些我们自己会采用的变通方式——要不你先描述一下我们的早期工作方式，以及我们是如何到达那一步的，然后再聊聊我们现在是怎么做的？

乔伊：好。就像罗比所说的，我们做这个多站点共享工作流到现在已做了很久。我们两个在疫情前就开始在家工作了，而多年来我们一直在移动媒体文件，移动项目，并以各种不同的方式合作项目。一开始事情总是很简单：好了，这是所有的客户媒体文件了，对吧？

乔伊：我们会下载下来，我会在我这边下载，或者你在你那边下载。

罗比：用硬盘。

乔伊：或者用硬盘，之后我会复制硬盘，把它拿到办公室或交给罗比，这样他就能把硬盘带回家了。我可能会在我这端按我想要的方式于存储区域建立一个项目，组织整理好所有文件夹。然后罗比在他那端也会这么做。

乔伊：而当我们需要来回移动一些东西时，我们会导出一个DRP，一个达芬奇项目，然后他会在他那边打开它。重新链接所有媒体。有时这是个简单的过程，有时不是——取决于我们是否使用了不同的命名方式或不同的硬盘盘符，或者是否是从不同的平台到不同的平台。

乔伊：我们就这样来来回回。所以当文件要回到我这边时，我就得做相反的事，基本就是撤销罗比之前为了他那边行得通所做的一切，好让我这边行得通。这个过程包含了很多低效率的环节。因此，随着软件的进化和我们流程的内部进化，我们经历了几个非常重要的步骤，以让这一切的运作基本上天衣无缝。

罗比：是的，我觉得有几件事值得一提：早年，我们两个都有点……我们一起工作差不多十年了。你会有做事情的偏好，比如你命名的方式，你组织管理事情的方式，而我会有我的偏好。

罗比：而且，你知道，我觉得我们之间的简化步骤做得很有默契。但有时候还是得侦探似的“破译”对方的操作。比如：你把这些从客户那儿拿来的测试图或者你从音频团队得到的混音放到哪里去了？所以除了比如我们如何传输各种文件那类的机械的步骤之外，还有一些组织管理层面的东西。

罗比：我在那个时期最大的痛点，尤其针对达芬奇、DRP和项目文件，就是要保持同步，是吧？你得了解比如眼下用的是这个项目的最新版本，这是最新的时间线，哦那是你做XYZ的那个项目。这是一个真正的挑战。

罗比：我们最终会得到一个文件夹，里面有20或30个DRP，来自审片会议结束之后或后期审片会议，而我们会给它们不同的命名。然后我们很快就被搞糊涂了，然后我们就觉得：不不不，我们必须得解决这个问题。

乔伊：这种合作有点打击了团队合作的积极性，对吧？因为如果这是一个从一个地点到另一个地点再回来的过程，我不能说：嘿，罗比，你能快速看一下这条时间线上的这个镜头吗？毕竟我自己来解决我自己的问题可能花费的时间更少，反之亦然。

乔伊：如今，我们俩会惯常分享项目中非常细节的内容。比如：你能在我给节目这一幕调色的时候解决这个遮罩问题吗？你来调第一幕，我来调第二幕好吗？基本上在我们的工作时间里，如果需要帮助，我们总是可以向对方寻求帮助。而且因为工作流是无缝衔接的，所以这样做不会给我们带来不便。

乔伊：然而在旧的DRP方法中，问题得在我们合作前足够严重才能证明这么来来回回倒腾是有必要的，而现在我们则可以直接说：好的，那你做这个，我做那个，且我们很快就能把事情做完。

罗比：没错，而且我要说明一点——我觉得很多人听到这里可能会觉得：是啊，我每天都在自己工作室里都这么做。当你和某人在同一处工作并且你们共用同一个存储区域之类的，这样做会更容易。但当两人在不同的地方工作——就我们的情况来说，实际上是在好几个不同的地方——我们甚至可能不是每天都会去这些地方，而在这些地方我们需要这些媒体文件，事情就会变得更困难。我希望能够在去到办公室的时候，不必移动任何东西或做任何操作，只要坐在办公室桌前就能看到：没错，那些就是我或乔伊昨晚做完留在家里的项目，而我们眼下立刻就能开工。所以乔伊，我觉得对我来说，我们可以把工作流拆分成几个部分。我觉得对很多人来说，最难理解的是接收媒体文件的部分，是吧？

罗比：当然，大家都知道同步网络这个词很久了，对。比如这里有个U盘或者硬盘。你把它从一个系统转移到另一个系统。但这种方法有很多问题。我想你刚刚提到了其中之一，那就是不同平台，不同硬盘映射。

罗比：你能详细解释一下这个吗？

乔伊：好的。有一件我们还没提到，但我觉得它挺重要，应该加入到这个整体方案中的事情是，我们不仅有三个不同的站点，我们有两种——有时取决于我们如何配置计算机——或三种不同的平台。是的，我们可能有一套Linux达芬奇——我们过去因为各种原因断断续续地使用过。

乔伊：但是目前，我们主要使用的是Mac和Windows上的达芬奇。在我的调色室里，我有一套Windows达芬奇和一套Mac达芬奇。而在办公室，我们只有一套Windows达芬奇。罗比的调色室有两套Mac达芬奇，而这些不同系统的达芬奇都以不同方式处理媒体文件。因此，存储的主要问题是多方面的。第一，要获取一个项目所有信息——基本就是指所有文件——然后给到全部三个站点；第二，但当有人在某个地方做出更改时，你得确保这个更改在所有站点都一样发生了。

乔伊：因此，如果我下载了混音文件，我需要把这些混音文件发送到办公室和罗比家里。我还需要罗比能够从客户那里下载一个测试图，然后我能拿到测试图，办公室也能拿到测试图，而不需要我们进行任何人工干预。这是一部分。下一部分是文件路径和硬盘映射，这其实大致分成两方面。

乔伊：一是技术问题，一是组织管理问题。技术问题是，Mac和PC的硬盘运行方式不同。你可以在Windows电脑上用D盘或者E盘，然后在Mac或者Linux上用斜杠加盘符，斜杠加什么什么的，斜杠NMT，斜杠随便什么，具体看你是怎么装载系统的。而达芬奇有个叫做映射装载的非常棒的功能来处理这个问题。

乔伊：你基本上可以定义所有的存储以及它们在其他系统上的位置。比方说，在我们的系统上，在Mac 和Linux上是斜杠盘符斜杠DC Color这样。而如果我们使用Windows系统，我们就会把映射装载设置成那个，但在Mac上我们会把映射装载设置为R盘。

乔伊：我们会有R盘的原因是因为我们所有的Windows计算机把DC Color存储用文件夹都设置为R。这样的话，我们就只会在Unix样式路径和Windows样式路径之间转换路径。在Mac和Linux上，文件会始终在斜杠盘符文件夹中，而在Windows上则是始终在R盘，于是我们只需要做一次映射装载，即在不同的平台之间关联，而不是在我的房子和办公室之间、办公室和罗比家之间，以及我家和罗比家之间设置映射装载。

罗比：绝对如此。我觉得这方面还有些事情需要进一步探索：第一，我们不使用外接可移动硬盘，是吧？我觉得这是很多人都会遇到的挑战——很多人都会觉得：我有个硬盘，拔出来就行了……我们要更细节地进行扩展的这整个想法都基于我们本质上有固定存储空间。

罗比：比如：我们在工作设施里有NAS，我们在家也有NAS，你家有，我家也有。所以这些文件路径一旦建立起来基本总是相同的。对吧？它们不会变，对吧？比如斜杠加盘符，斜杠加DC Color——一直在那儿，斜杠加“R”或“R:”等等，它们总是出现在窗口地址栏，然后……因为我觉得有些人可能是刚上手达芬奇的映射装载，但我总是……直到今天，我都很惊讶有多少人会说：“哇，我一直不知道原来可以点击那个小文件图标，它居然能改。”

乔伊：其实从达芬奇第六版开始就有了，我不明白为什么世界上其他的平台都没有这个功能。

罗比：对，其它平台都没有，就是这样。

乔伊：看着很简单，但能省不少时间。

罗比：确实如此。简单来说就是，一旦你设置了一个映射装载，比如，如果你想把盘符/DC Color映射到R盘，然后把R盘设置为映射装载，基本上它的工作原理是：任何时候在文件路径中，软件一旦读取到/盘符/DC Color，就会把它映射到R盘，反之亦然。

罗比：对吧？所以这个映射装载工作流的真正优势，一部分在于——这部分我们稍后会在我们开始同步媒体的时候解释——我们永远不需要重新链接任何东西，对吗？只要映射装载被设置好，我就可以打开这个项目，即使我在不同的平台上，对吧？

乔伊：是的。这就是标准化部分的用武之地。你记得我之前提过的吗：分成两方面，有技术部分，也就是映射装载，然后是操作部分，也就是标准化。第一，我们可以使用映射装载，因为我们标准化了跨所有平台的装载点。就像我说的，所有的Linux，所有的Windows，所有的Mac在它们的生态系统中都有着相同的装载路径。

乔伊：所以我们只是用映射装载来串连起两边。但还有另一件事我们很久以后才真正花心思去做——但我认为这在你团队协作，即使这个团队一共只有两个人时，真的真的很重要——那就是我们现在有了一个专用的模板化项目文件夹结构。这意味着每个项目都有相同的文件夹结构，而第一个……呃，这有点像在达芬奇中使用固定节点结构，是吧？

乔伊：你一开始想到它的时候，会觉得：“好吧，这会带来很多限制”，但如果你把它建得很大，就不会有这个问题了。因此，我们的文件夹结构基本上会有一个专用的文件夹，里面装着任何项目中我们可能需要的东西，而在任何特定项目中，我们可能会用到这些文件夹10%的空间。但在我多年后期制作工作经验中，我发现最好的组织管理方式就是自动找到一个合适的地方来存放东西。

乔伊：如果你有合适的地方存放东西，那里就会变成你的默认存放位置。所以即使你时间紧迫，即使你在赶工，你也会先进入正确的存放位置，而不是为了快点做完草率把东西都丢在桌面上，做些杂乱无章的操作。因为现在我们所有项目工作站点的项目文件夹结构都一样，而映射也都一样，装载也都一样。

乔伊：确实是这样。我可以在桌面开一个项目。我可以去我的协助工作站桌面——那是一台Windows设备——打开同样的项目。我可以开车去办公室，打开同一个项目。我可以打电话给罗比说，罗比，你能看看这个项目的第二个镜头吗？而他可以直接打开项目，找到第二个镜头。

乔伊：而我们的进度都是一致的，不需要重新链接媒体文件。

罗比：绝对如此。这就是我们组织管理项目的方式。我们用一个叫做Post Haste的工具——这是个在Mac平台上很流行的广为人知的工具。它让你能够任意自动创建那些文件夹结构。这是件好事：我们组织管理的基本上都针对客户提供的东西，以及我们自己创建或管理的东西。

罗比：所以在我的客户文件夹中，我们有一个统一的媒体文件夹——如果他们给我们一份Premiere Pro项目或类似的东西的话。我们会有一个放烘焙文件的文件夹，我们也会有一个放修复和VFX文件之类内容的文件夹。在我们的文件夹中，我们会有文件夹装音频和平面图形文件——可能是其他供应商那边发过来的。

罗比：我们有一个文件夹装放映文件和最终输出。这么做的重点不在于锁定，以及让人们采用我们的文件夹结构，而更多是在于考虑某种文件夹结构是否对你和你那头的使用端有效，然后坚持使用这种文件结构，是吧，这样你每一次都会清楚知道：哇噢，我要为这条时间线找合适的参考文件。

罗比：你猜怎么着？然后你就能马上在客户资料和参考内容里找到你要的东西了。就是这样。这些都是可重复的，并且很容易找到。

乔伊：而且我们确实花了不少时间才走到这一步。没有任何原因，只是因为我们当时工作方式很正常。我们工作得很顺利，项目进来了，项目完成了，项目出去了。没有什么戏剧性的大问题需要解决。所以我们那会儿都没坐下来说：好吧，我们暂停片刻，考虑一下实际的工作流、文件夹结构和标准化。

乔伊：是的，而等后来我们真的这么做了，我们做了些迭代，是吧？我们尝试了一些东西，用真正的项目尝试，更新换代工作流后锁定了它。这很重要。任何时候如果你要构建一套模板化工作流的话，先试一下，并准备好做出改变，最终你则会把它锁定下来。但是我们有一些早期项目可能并不完全符合这个结构，因为我们仍然在调整和探索它。

乔伊：这没关系。这永远都是个过程，但只要努力让所有人都保持在同一进度，就会产生巨大的影响。

罗比：我觉得这有点像节食或者锻炼计划，对吧？好像我会比你更有罪恶感一点：比如有时候我会偷懒，直接把文件随便丢进去什么的。但这是这么一种情况：你做得越多，这就越成为习惯，你就越能看到它的好处——就像那些节食或者锻炼计划之类的。

罗比：我觉得这种迭代是很重要的。早年，比方说，我没有意识到，小写文件夹命名会让你发疯。对吧？呃……

乔伊：我知道这完全不合理，但我喜欢大写文件夹命名。

罗比：行。现在我们已经讲过映射装载和文件路径的部分了。我们也已经讨论了一种标准化的文件夹结构。那么，我们实际上是怎么把媒体文件从A点传输到B点传输到C点的呢？这到底是怎么运作的呢？

乔伊：大家都知道这个问题有很多解决方案，对你来说所谓的“正确答案”就是任何适合你的方案。但是对我们来说，我们的需求通常是我们不想去找云服务提供商，我们不想在云服务里镜像存储所有东西，因为这要么会变得非常慢，要么会非常昂贵。我们需要能够可靠地在三个不同的地方之间来回传递，我们要能够控制它，因为我们有很多非常庞大的项目，永远不需要移动。

乔伊：比如我可能会在一部电影上工作很长一段时间，从不需要在办公室或者罗比家里做相关的工作。而且我们并不想把我们一路在做的所有操作都同步。我们希望能这样：OK，这个项目，勾选，然后送去办公室，送去乔伊家，送去罗比家，而这个项目则送去罗比家和办公室。

乔伊：所以我们需要能够引导什么样的项目进入什么样的存储位置，因为就像罗比说的，我们在每一个位置都有NAS，而虽然现在存储已经变得非常便宜，它毕竟不是免费的。同时媒体文件正在变得越来越大。所以我们确实需要做一些管理工作。我们最初使用Resilio Sync——原本它还叫BitTorrent Sync。

罗比：没错。

乔伊：Resilio Sync是一款非常酷的产品。当时有很多人用它，做得很成功。但我们最终关闭了它，因为我们遇到了一些各种各样的技术问题。

罗比：我应该补充一点：我们还在一台位于特定工作地点的电脑而不是NAS系统上本地运行Resilio Sync。所以可以用一台Mac，一台备用 Mac或PC，在任何多工作地点作为应用程序运用Resilio Sync。

乔伊：是的。所以为了管理它，你得去那台电脑上操作，对吧？所以我们最终决定使用一款非常酷的开源软件Syncthing。Syncthing基本上可在任何系统的后台运行，这也意味着我们可以在我们实际的NAS系统虚拟机里运行它，而这也可以在不同的NAS平台上运行。

乔伊：所以如果你在使用Synology、QNAP或TrueNAS——我们用的是后者——它们中的大多数都有虚拟机功能，而你可以在你的NAS上直接运行Syncthing，这意味着它能够以超快速度索引文件、扫描文件以及来回发送文件，而且它不会给你的调色系统带来负担。而且Syncthing还为你提供了一个网页端用户界面。

乔伊：你可以从网络中的任何地方访问网页端用户界面。所以我可以跳到我的iPad，说：“嘿，罗比，我现在发你这个项目。”然后点击，就大功告成了。因为所有的路径在我的NAS上可用，而且Syncthing也在NAS上运行。我们基本可以有……我们只需要一份事项列表，里面是各个项目和它们同步到哪里。而在我们作出更改时它会监视文件夹，在不同位置来回上传文件。

乔伊：它有一个垃圾箱功能，在过去“救”过我们，因为当时，有人删除了一个远程站点的东西，然后它会传递这个删除操作到其他站点，以保持一切同步。你可以设置一个偏好选项，把它移动到一个隐藏的垃圾箱文件夹而不是删除它。这样的话，如果我删掉一半的项目，你猜怎么着？

乔伊：即使我可能已经把它从我系统里删除了。但这些文件还在办公室，也还在罗比家里，因为程序没有从罗比的存储空间里删除它们，只是把它们放进了垃圾箱。

罗比：这是个很好的观点。我稍后会展开讲讲。我认为重要的是要留意那些经常在这种技术中使用的短语——它以此区别于人们会用来工作的其他方式。这是一种点对点的设置。我会从我的NAS传输到办公室NAS，再到乔伊的NAS，等等。

罗比：无论这个客户直接在哪里运作，我们都不会首先使用中继点。这样人们可能会说：是的，当然，我合作使用媒体文件，但我可能首先会同步到，比如我的谷歌Drive或Dropbox或Frame.io。那种情况下，你其实是上传到了云服务中的某个中继点。

罗比：然后在另一个使用端就要把它再下载下来。这样沿着这条链就已经有三个而不是两个点了。我们已经注意到，从速度的角度来看，它的速度是两端管线所能支持的最快速度。所以对我们来说，这基本上意味着来回传输都是千兆位的速度。所以我们……

乔伊：看到ProRes文件在Syncthing以每秒900MB的速度传输真是很酷。因为这就像是：罗比你能把那个你想让我看一眼的项目发给我吗？当然。一键传输。好的，我已经收到了——如果是个小项目的话。

罗比：是的。我觉得在自己的NAS的系统上运行这个的额外好处，就像你提到的，就是那些机器，那些盒子通常会一直运行。所以不用担心电脑休眠了，或者有人把笔记本电脑从网络上断开了，或者之类之类的问题。

罗比：这些都是固定资产。软件总是在监测和关注媒体文件的进入。我记得你提到了清理垃圾的事。我认为另一件非常重要的事，也是我们过去在Resilio之类的平台遇到过麻烦的事，就是这些同步工具处理冲突的方式。比方说，举个例子：假设你还在下载的时候同时同步了一些东西，或者你在我创建一个文件夹的同时也在创建一个文件夹，Syncthing里有一套强大的工具来管理这些操作。就像是：嘿，我发现到这个文件不同步。你可能需要查看并解决这个问题。这也为你节省了些时间。

乔伊：是的。而且因为它在这个很不错的基于web的操作面板，所以很多时候，我们可以轻松地主动管理它。如果我们渲染时长一个小时的ProRes 444文件，我只需点击暂停同步，因为我不希望它在渲染的同时试图扫描该文件，然后在最后再重新扫描一遍。

乔伊：所以它总是在后台那儿运行着，很容易访问和使用。我甚至可以进入虚拟专用网络（VPN），从我的手机上获取它，因为我们所做的一切就是给Syncthing下操作指令。而我们不会在眼下正在访问的那台机器上移动数据。

罗比：是的，所以从实际使用的角度来看，如果我们——就像乔之前提到的，当我们首次开始讨论寻求帮助或寻求解决办法的能力的时候——我们通常会这么做：“嘿，乔，我需要你给这个镜头做一些……比如一些视效方面的‘魔法’。”

罗比：他的回答会是：“好的，当然。把项目同步给我就行。”然后我点击两个按钮，然后一瞬间就——取决于项目有多大——文件就传输到他那里去了，反之亦然。假设我有个客户把硬盘送到了我家，但我会在办公室和他们一起审片。

罗比：那就很简单了：我把硬盘拷贝到这，点击同步到办公室，而第二天早上我去办公室的时候，你猜怎么着？一切就都已经准备好，可以开工了。所以它对于数据的转移是非常有价值的。我觉得结合你之前提到的其他两件事——文件路径和固定的文件夹结构，这就像是在同一个系统上工作：无论你人在哪里操作，媒体文件都会同步出现在那里，这太方便了。

乔伊：是的。我认为这是个很好的开端，引出了另一个非常、非常重要的因素。这个因素相对较新，但在概念上非常、非常重要，那就是：我们如何与跨多个站点的项目进行交互。

罗比：没错。

罗比：就像你之前说的，过去你不得不为此大费伤脑筋。比如：这是正确的项目版本吗？那个段落的时间线是什么？我觉得当时我们就像是，天哪，这可以完全不用这么费劲的。而且我们已经讲到过……我知道我们已经做过很多培训课程，讲解过真正的协作工作流，以及在达芬奇里设置这种工作流。

罗比：但这一切都建立在你们以同个网络工作的基础上，对吧？你们都在同个地方。

乔伊：是啊。而我们已经在这个话题上钻研了很多年了。我们一直试图建立自己的VPN，基于云计算的共享数据库服务器，但我们从来没能让它达到满足我们工作需要的水平，因为达芬奇数据库连接到 PostgreSQL，这是一个行业标准的数据库，但达芬奇与它的“对话”方式非常关键。而这在像互联网这样的高延迟连接中，它的速度永远不够快。但是达芬奇17……是达芬奇17吗？

罗比：我觉得是达芬奇17。

乔伊：达芬奇17完全重写了那个连接，专门为了让它快到可以通过互联网使用。这就是BMD云在这儿能用上的原因。但如果你想要的话，它也允许你制作自己的私有云数据库服务器。

罗比：是的。所以我们决定——在观望了很长时间之后，正如你所说，我们已经尝试过VPN，我们尝试过各种各样的东西。当BMD团队推出BMD云和支持数据库的时候，我想我们首先想到的就是：我们可不想付额外的钱给别人去做任何事。

乔伊：我们可以自己建。这样就可以我们自己建了，对吧？

罗比：我们可以自己建。那么，我们是从哪里入手，为什么入手，以及我们当时做了什么呢？

乔伊：我……我开始捣鼓虚拟机，VPN服务器，我们打算自己内部做完这一切。因为同样，达芬奇里能让云服务起作用的技术也能让私人数据库服务器起作用。两者没什么不同。所以你可以自己解决这个问题。而等我搞定了所有IT方面的事情，处理好了一切，那么我需要三个办公室都使用同一个VPN吗？

乔伊：然后一直保持这样？也许我不想。如果我想出于其他理由让一个VPN从我的手机接入我自己家呢？我会想同时运行三个不同的VPN服务器吗？我会想主动管理和安全保护所有这些东西吗？呃……并不。如果你有一个庞大的IT团队，且已经为其他工作搭建好了云基础设施，那这是个很好的选择。

乔伊：但是对于我们来说，每个数据库5美元一个月，而你做的只是登录进去。所以我们基本上所有的项目都在BMD云上。

罗比：是的。

乔伊：它们都在云数据库里。为了安全起见，我们仍然为所有东西做本地备份。但在钱这方面，这不值得我们花时间去当“IT专家”来实现这些。

乔伊：而且这也不值得冒险让我们的网络暴露在安全问题之下。

罗比：是的，我认为有些人，不管出于什么原因：比如他们用的是TPN，或者出于其他安全原因，他们不得不隔离访问……总之他们有充分的理由在内部重建这种技术。这可以完全在你的控制之下，而且会更安全一点。不过话虽如此，BMD目前使用行业标准的AWS作为这类操作的支柱，所以它是安全且易于使用的。而如你所说，每个数据库花费5美元，而我记得——如果我错了请纠正我——我记得这能支持这种情况：花5美元，每个数据库能有10个用户，之类之类的。

乔伊：10个共享用户，项目数量无限。从实际操作的角度来看，我们基本每个主要版本的达芬奇都创建了一个新的数据库，并备份旧版本内容。但是在任何给定时间点，我们会有一个或两个数据库，所以我们的花费是5或10美元一个月。

罗比：所以从实际操作角度来看，所有这一切意味着在达芬奇内部，比起从我的网络或从我所在的网络上的某个服务器开一个本地数据库或共享数据库，我们选择登录到BMD云。它的操作和功能和任何其他数据库一样，比如达芬奇的SQL数据库。但这是有好处的，对吧？

罗比：于是我继续操作，把一个项目同步给乔伊，我们暂且称之为——因为没有更好的叫法——XYZ项目。我把它放进数据库。然后我再次往里面添加一些媒体文件，而这也都在我的NAS上。我要做的第一件事，就是点击Syncthing里的按钮，把那个标准文件夹从我的NAS分给乔伊。几分钟后，乔伊就能拿到那个文件夹了。

罗比：他要做的就是打开达芬奇，找到我刚创建的项目。他打开它——你猜怎么着？经由方便快捷的路径映射和所有其他操作，一切都已经是在线的了。

乔伊：一切都准备好了。

罗比：他只需要直接发消息问我：嘿，罗比，是什么镜头？我说：镜头17。

罗比：他说：好的，我已经在上面做了一版调色了。打开看看。看看你怎么想。事实上，这样做太流畅了，我可以在只读模式下打开项目——如果他已打开了只读模式的话——直接看他做了什么操作就行了。但是这甚至能运作得比这还要好，因为云数据库当然也支持真正的协作模式。而在此之前，这种模式实际上在你提到的开发方面是受到限制的。

罗比：之前是仅限于在单个网络上进行协作，对吧？在网络上搞一套共享数据库服务器。在那个地点的所有人都能这样做。但现在我们可以通过我们的云数据库复制所有这些真正的协作功能。所以如果我们想同时工作，比如我说：乔伊，你能跟在我后面在Fusion里做这些转描工作吗，因为我完全不懂Fusion。

罗比：你就可以说：当然可以。我们在合作中习惯的所有功能、时间线所有权、片段所有权，所有这些东西都像魔法一样流畅运作。

乔伊：是的。在性能方面，我再怎么强调这点也不为过：我无法区分我是在云数据库还是本地数据库工作。就是因为它们已经非常好地解决了缓存和数据流的问题，以至于可以在单个用户或协作中流畅地工作。在我们讨论协作会发生的一些意外问题之前，最后一件事是我想提一下你讨论过的TPN和隔离之类的话题。

乔伊：其实有一个令人满意的中间地带，因为虽然我们没有做具体的大制片厂TPN认证之类的事情，但我们仍然非常关心我们的客户的数据安全和隐私，努力确保我们不会泄出任何不该泄露到外部的内容，以及避免发生安全方面的糟糕事件。

乔伊：因此，作为整体工作原则，我们没有把我们的达芬奇系统连接到互联网上，是吧？我的主达芬奇系统并不在线。我自己手动把所有东西导进导出，然后我所有的电子邮件沟通以及其他操作都发生在旁边的一台Mac Studio上。但是这也带来了一个问题，如果主达芬奇不在线，那你要怎么做云数据库呢？

乔伊：其实是，主达芬奇不在线，但仍在网络上。我实际上已经创建了防火墙规则，想法是这样：那好，在这个以太网端口不要让任何互联网流量出入这台Mac Pro。但可以允许与BMD云数据库的连接——这在我们的防火墙花个5分钟就能配置好。你也许可以在任何防火墙上这样做，甚至可以在你家里的互联网路由器上。

乔伊：组合端口和主机，添加到白名单，设立规则：嘿，允许这个操作，但不允许其他任何操作，这并不是件非常复杂的事。所以没错，如果我在主机上打开网页浏览器，我什么都看不到。如果我尝试更新Mac OS，我什么都看不到。如果我试图下载某个文件，我也是看不到任何东西，而我打开达芬奇，它会弹出一个云登录窗口，我输入我的用户名和密码就登进去了。所以你是可以通过这样的操作，置身于合理的安全性和便利度的中间地带的，可以安全隔离你的设备，但又不需要让它完全封闭起来，只靠经过认证的U盘出入系统。

罗比：这点你说得很好。在我们开始聊合作会遇到的意外情况之前，我还想到一件事。我觉得在云端工作会让人们产生恐惧，比方说，如果BMD或AWS坏了怎么办？我能做什么？你知道，关于项目备份的一般建议，无论是实时保存的东西，还是实际的项目备份，还是你想通过导出DRP做的任何操作，这些在云端做当然还是合适的。

罗比：当然，所有这些实践仍然与在云端工作密切相关。但即使在云端，我也不会指望把它当成你唯一的可靠的后备系统。有件事我觉得很多人都没有意识到可能性，因为在过去，你必须用一个完整的数据库，然后你得导出它，得做成.tar或者.zip文件。

罗比：文件体积往往很大，需要一段时间，不然你就得输出单独的DRP。实际上，利用了拖放这个功能，有种更简单的方法可以做到这一点。其实我们只需要简单地高亮显示一个项目，或者一个项目文件夹，甚至是达芬奇项目管理器窗口中的任何内容，你只需要把它拖放到你选择的位置。

罗比：所以，你早上开始工作时打开达芬奇，你做的第一件事就只是点击某些文件，拖到你的Dropbox或谷歌Drive或其他任何你想备份的地方。这倒是个简单的备份方法。正如我所说的，它也遵循数据库内部的文件夹组织。

罗比：所以如果你想把整个项目都备份起来，这也是个很简单的解决方法。

乔伊：是的，我们在互相来往的文件传输中出于很多理由也这样做，比如做完整的一组DRP备份，或者用于存档。我通常只是绑定一个热键来导出DRP。所以每当我觉得：好的，我在这个项目上取得了很大的进展，我就一键导出一个DRP到我的默认导出文件夹，然后同步到云端文件共享。

乔伊：所以我有一个随时运行的DRP备份我所做的一切，以防万一。如果网络崩溃了，我可以直接导入DRP然后回去工作，因为我们的存储不依赖于云端。我们的存储与本地的三个站点同步。所以只要我仍在某处存有那个项目的信息，即使整个互联网瘫痪，我仍然可以继续工作。

罗比：这是一个关于同步来回传输文件的好观点。我知道我们两个都……但我要开你一点玩笑。你就像是一个数据安全方面的……我会说是“有意识的”……但我其实想说的是，你在这个方面很焦虑。

乔伊：偏执。焦虑。没错。

罗比：你害怕丢东西的程度比我认识的任何人都重。伙计们，我没在开玩笑，乔伊会把所有东西备份七遍，但还是会在晚上疯狂焦虑担心丢失数据。

罗比：这样的额外好处之一是——特别是当你在做一些规模很大的可能需要花好多时间才能重建的项目的时候——这真的为我们提供了额外的安全保障。如果我丢掉了一切，如果我的NAS炸了，你猜怎么着？我还在其他两个站点有同步备份。所以它本质上有点像个备份系统，不是最强大的，但有点备份系统那个意思，因为它有这个属性。

罗比：乔伊，在我们结束之前，还有两件事要提。我们之前已经提到了一些协作功能方面的问题。具体来说，我指的不是我们设置项目的方式，而是达芬奇项目内部的协作模式。当你处于协作模式时，你注意到了哪些问题？我注意到了一些，但我很好奇你的想法是什么。

乔伊：好的。重要的是要记住，协作模式本身在达芬奇里就是一个独立模式。有协作项目和非协作项目，你需要去主动打开它。当你打开它后，它确实会产生一些可能的影响。其中最大的问题是，当你处于协作模式时，它不允许你进行动态项目切换。所以要注意这一点。

乔伊：如果你不需要将一个项目设置为协作模式，那你可能最好别把它设成协作模式，因为你会失去动态项目切换的便利性。我们通常的做法是，如果我们需要同时在同一个项目中，我们会说：好的，我现在打开协作模式。然后我们一起做这个项目，然后等情况回到我们中只有一个人在做这个项目时，我们就手动关闭该项目的协作模式。因为这样确实能使其他事情变得更容易。

乔伊：我们看到的另一个问题是，如果你有一个从媒体池到节点树的外部映射，就会遇到一些只有在协作项目中才会出现的奇怪问题，无法正确地链接到其他机器。

罗比：但如果你关闭协作模式，就行得通了。几周前我们有个项目，我在做一些键控，而罗比在做一些调色。然后我说：好的，罗比，键控都弄好了。看起来不错。我们都准备好了。

罗比：你在说什么呀。

乔伊：然后他打开项目，就像这样。然后他努力保持礼貌地说：你确定这些都做完了吗？你确定你调完这些了吗？因为在他那边，节点树中的某些东西并没有在协作模式下互相联通，所有的键控和色彩看起来都很疯狂。而在我的设备上，这些看起来都很正常。于是我们退出来，关闭了协作模式，重新开启项目，结果一切都正常了。

乔伊：所以我唯一想说的是：第一，我们知道这个云部分其实还处于测试阶段。第二，协作功能也在迅速发展。所以如果你看到一些奇怪的东西，不要惊慌。批判性地思考一下：好吧，这可能是个程序漏洞或者协作模式下的工作流问题。

乔伊：让我们试着解决这个问题。不要马上觉得是乔伊瞎了，把所有的东西都一阵乱调。

罗比：是的，这绝对是个问题。我注意到了一个类似的问题……而我唯一能做的描述的就是“进展太快”。在这种情况下，所有关于片段所有权的正常规则——特别是在调色页面的时间线上——都和本地一样适用于协作模式，对吧？所以当我在某个片段中的时候，我拥有那个片段。如果你想看到片段中的变化，我需要移到另一个片段，然后你们需要刷新一下之类的。

罗比：我注意到有时候，如果我直接：下一个片段，下一个片段，噢，上一个片段，下一个片段，下一个节点，之类的跳来跳去，在协作模式下的达芬奇可能会觉得有点“困惑”。如果你给它一点时间，它通常会自己解决，但有时这也会成为问题。然后我注意到另一个问题，我确信这只是AWS登录和达芬奇联动的问题，以及它需要多久重新验证一次。

罗比：我登录时好几次都留意到了这个问题：什么功能忽然都没法用了，比如开关我的调色效果，直接没法用了，而且我也没有得到任何来自达芬奇的警告。我发现，十有八九，如果我此时退出达芬奇，下次再启动它时，它会要求我重新认证到云数据库，直接重新登录回来。

罗比：为什么它第一次没响应时不这么做呢，我不知道。但这似乎是解决大多数问题的办法。

乔伊：是的，关于这方面，好消息是你不必太担忧，因为所有这些问题有一条共同原则：如果没有正常的数据库连接，那达芬奇是不会让你破坏项目的。如果你像罗比说的那样在片段之间非常快速地来回跳，而且由于某种原因并没有取得镜头的所有权，色彩控件是不会改变任何东西的，对吧？

乔伊：如果你登出了数据库，并试图从项目中删除一大堆东西，达芬奇不会让你这样做，因为它没有权限进入云并要求：“嘿，删除所有这些东西。”所以，如果你遇到了这些我们也遇到过的奇怪情况，直接退出，登录，再回到项目，你的项目将仍然是完整的。

乔伊：达芬奇做的处理很棒——我认为这点非常非常重要——那就是不让你破坏项目。

罗比：而且这不是在为BMD公司做宣传，或者其他什么的。他们没和我们在做这种合作。老实说，在使用云数据库一年多的时间里，我没有丢失任何一个项目，也没有丢失任何工作或数据。

罗比：而我真的丢了东西的情况，一般都是因为那些很蠢很常规的调色师会搞砸的操作，比如把某个更改波纹操作到4000个调色上，然后把那种事情搞砸。

乔伊：我曾经遇到过AWS失效的问题。当时我们和数据库的连接直接中断了。因为AWS失效了。我还遇到过我的网络连接失效的情况。此时达芬奇就会提示说：嘿，我无法进入数据库。你是否希望：A：导出项目的DRP，因为它将项目保存在内存中。

乔伊：因此，即使它在出错时从云端断开连接，它也允许你将该项目的DRP导出到本地设备，这是一个……

罗比：很重要的防护措施。

乔伊：……很棒的安全措施。当这个问题出现的时候——无论是我的网络连接断了，还是我们的AWS失效了，我所做的就是退出系统，等待AWS重新上线。果然，它再次连接到数据库的那一刻，就像什么都没发生过一样。事实上，这个错误已经消失了，我只是继续工作。我已经导出了备份，然后我继续工作。

罗比：就像我们几分钟前谈到的关于同步媒体文件固有的数据安全性。我觉得我们可以总结的最后一件事就是：没有人说你不能在你的数据库中有多层保护。所以，我觉得很多人正在做或者正在考虑做的一件事就是，他们在本地工作，不管是本地SQL数据库还是网络SQL数据库，甚至是一个项目派生的数据库。

罗比：没有人说，当你想和其他合作者分享的时候，你不能简单地，CMD+CTRL+C，CMD+CTRL+V，然后把它粘贴到云数据库，对吧？可能是……

乔伊：是的。你可以直接通过达芬奇项目管理跨数据库做到这一点。你不需要再导出接着导入了。事实上，右上角现在有一个按钮，可以将选定的项目复制到你任何其他数据库。

罗比：没错。所以如果你是那种对同机构其他人的操作非常焦虑不安的人——也许看着他们工作，或者你还没准备好，或者不知怎么搞砸了，你可以在本地工作，然后在你需要做完这个工作流的其余部分时直接复制到共享数据库。乔伊，我希望大家都能同意我们现在在讨论的内容。

罗比：我们对我们这套工作流非常满意。如果你们有任何问题，我们很乐意回答。我重申：我们不是在从零开始重新发明任何东西，只是把这些不同的要素组合在一起。它使我们能够在多个地点、多个用户的情况下非常高效地工作，而且也不会遇到太多令人头疼的问题。所以没错，目前我们就是这么做的，我们也对此非常满意。

罗比：如果你们部分或全部接收了我们的建议，请告诉我。当然，如果你有任何问题，也请告诉我们。好了，伙计们。好了，这一期的“Offset”播客到此结束。我是罗比·卡曼。

乔伊：我是乔伊·迪安那。感谢收听。

出处：DC Color | The Offset Podcast

编译：Charlie | 盖雅翻译小组