下载掌阅APP，畅读海量书库
立即打开
你已经知道大家的需求了，而且已经确认自己理解了这些需求，现在应该继续向前推进，真正去构建能够满足这些需求的东西。别担心，你并不是一个人在做。在设计环节，你的目标跟收集需求时类似，也是让大家对设计方案达成共识。你一开始就可以提出许多种满足需求的办法，并权衡每种办法的好处与坏处。
你要提出多种满足需求的设计方案——每种方案的价格、实际恢复时间（Recovery Time Actual, RTA）、实际恢复点（Recovery Point Actual, RPA）都不同，而且执行该方案的人所需具备的操作水平也不一样。（有些方案用起来比较容易，有些用起来则不那么容易。）你现在的任务是初步起草这些方案，让有关各方讨论，以便从中确定大家都赞成的一种方案。
你所提出的第一种方案，总应该是那种“无论要什么都尽量安排，别担心花多少钱”的方案，该方案只考虑怎样满足需求文档里定义的RPO与RTO。这个方案是其他方案的基础，它让大家有一个很好的参照物，知道这个所谓的完美方案或理想方案需要花费多少资金。
然后，看看这个最佳方案里有没有什么可以削减成本的地方，并形成第二好的方案（second-best solution，次佳方案），这个方案仍然能够满足目标，但自身可能有一些问题需要稍后解决。这个方案减少了初期需要投入的资金，让我们能等到以后真正需要执行某些操作时再投入。
比方说，你所在的组织是制作动画电影的。创作团队（也就是数据创造者团队）会产生上千份文件，并且需要对这些文件执行复杂的合成与渲染操作，以创建上千张成品图像。在这个过程中会产生几百万个小文件，这些小文件是为了制作最终的成品文件而产生的。在这种情况下，你只需要把最终的成品文件备份下来，就能够满足需求文档中所界定的RPO了，所以，你需要考虑的是，有没有必要把那几百万个仅起到过渡作用的小文件也备份下来，如果备份，那么会占用一些时间，导致该方案未必能够满足RTO，但如果不备份，那么万一数据丢失，你有可能还得按照创作团队的要求，把这些小文件重新生成一遍。重制这批文件，确实要耗费一定的计算机资源与人力，这本身会增加成本，如果不重制，而是在备份时直接把这些文件也一起备份下来，那么也需要花很大的精力与成本，而且这可能比重制这批文件所花的更多。
你要注意，故障是没有什么规律的，因此，把恢复出来的这些文件都整理到故障之前的正常状态，并不像你想的那么轻松，有时还不如干脆少备份一些文件，等到恢复数据时再重制那些丢掉的文件。
把这些问题记下来，并把你这样权衡的原因解释给那些对资金比较保守的人（也就是不太愿意投入资金的人）听。你要准备好，有人可能会质问：你这个方案跟理想的方案相比，砍掉了一部分成本，然而在数据丢失时重制数据并将其恢复到稳定状态所需的开销，是不是比你砍掉的成本还大？你要论证你砍掉的成本足以涵盖这些开销。
为了满足RTO，你必须尽快把数据恢复到正常状态，为此，你可能会削减你所恢复并整理的数据量，但是又不能减得太过，那样就无法满足RPO了，因此，你必须把话说得很周到。真正的最佳方案总是位于两极之间，你要把这中间每一个值得考虑的方案都考虑到。
到了评审设计方案的阶段，你应该已经研究过各种白皮书与业界的最佳实践手册了，而且也应该已经读过本书第16章了，那一章会详细解释你在设计或更新备份系统时所要注意的一些技术事项。此时，你应该已经跟有可能提供相关产品的供应商联系过了，而且也看过了相关的产品演示，并拿到了初步的报价单。经过斟酌之后，你可能写出了一份50页的文档，里面有丰富的场景、图表、数据流程、成本分析，最后还有一段建议。现在到了确认的时间了，你需要确保与运作及构建该方案有关的每个人，都认同这个方案。
此时应该召集设计评审委员会（DRB）。你要记住，这个委员会的某些成员应该来自与特定技术有关的一些团队，因为他们能够告诉你怎样在本组织内通过相关的技术来实现你的方案，这些团队包括系统工程团队、数据库工程团队、存储与网络工程团队以及网络安全团队。另外，你还应该从数据创造者团队里面挑选SME。这样的人可以在生产团队与运营团队里面找。
你可以根据最终的需求文档做个小结，然后从这个小结出发，深入探索其中某些细节问题的具体处理方式，例如数据保存在哪里、数据如何加密、系统需要占用多大带宽、需要如何来操作等，并把这些做法记录下来。一定要把你对RPO的要求写下来，而且要写出你为了满足RTO还必须做哪些工作。单靠一个人肯定无法搞清所有的事情，因此你要听取技术专家的意见，让他们来帮助你完善这个设计方案。你要认真记录这些意见，SME可能会提出相当好的见解。
反复地听取意见并修改方案。如果你听到某些意见之后，大幅调整了设计方案，那就应该重新架构一遍，然后重新交给DRB评审。如果你做了沙盒演示或完整的概念验证之后，发现效果跟预想的不同，那就把这一情况记录下来，并给DRB讨论。等到确定最终的设计方案之后，你就可以将其完整地写成文档，并让大家轮流签字了。
这是最有意思的一个环节。你要买一大堆东西并把它们拼装在一起。你要配置这个系统，让它能够查询相关的数据集并处理这些数据。你需要准确测定恢复数据所花的时长，以确认该系统满足了需求文档里面写的SLA。你要在几个星期或者一个月的时间里把这个系统跟本组织的生产系统同时运行，以观察该系统是否能够与后者顺畅地配合，然后还要全面测试这个数据保护系统，以证明它确实能满足RPO与RTO这两项指标。（你要记住，之所以走这个流程，就是为了验证该系统能够满足预先设定的恢复目标，而这些目标正是以RPO与RTO这两项指标来体现的。）
太棒了，你已经把数据保护系统构建出来了。现在应该制订操作计划并编写操作文档了。