下载掌阅APP，畅读海量书库
立即打开
如果你只需要跟机构里的5个人共事，而你们又都坐在同一间办公室里，那么沟通起来就很容易，你要是想知道做好某项工作的关键点在哪里，根本不用离开办公桌，只需要坐着问他们就行。但大多数情况都不是这样。因此，首先要做的是把与数据保护计划有关的重要人物找出来，搞清楚这些人的要求，只有这样，你做的计划才能有效施行。
任何一项数据保护计划都涉及两个关键指标，一个是恢复点目标（Recovery Point Objective, RPO；也叫目标恢复点），另一个是恢复时间目标（Recovery Time Objective, RTO；也叫目标恢复时间）。这两个话题都会在第4章详细讲解。首先简单说一下，RTO是指遇到灾难之后必须在多长时间内恢复数据，而RPO则是指出现灾难时最多能够容忍多少数据丢失。
根据你对本组织的服务或产品的了解情况列一张清单，将你的内部客户按照部门罗列出来。（其实对于数据保护工作来说，组织里的每个人都是你的客户。）然后，从中寻找这样一些SME（主题专家），他们必须要能够详细了解某个部门所做的事情，了解该部门为保护其数据而提出的要求，以及这些数据是不是必须始终保持上线（而不允许暂时下线）。这些SME通常分成下面几个大类。
这些人知道数据是从哪里来的，也知道它是从哪个部门来的。它可能是由生产流程中所使用的某种智能系统产生的，组织内部的运营人员与生产人员应该会比较熟悉这套流程。它也有可能是由一群水平很高的艺术家、作者与编辑创造的，这些人每小时的工资都很高。它还有可能是由销售部门、客户服务部门或其他某个直接面对（外部）客户的部门产生的。只有先搞清楚数据产生自哪个部门，我们才能知道数据丢失时从头开始重建数据是不是特别复杂。
这些数据创造者可能来自生产与运营团队，也可能来自负责收集产品管理、组织及业务等方面信息的团队，还可能来自数据服务团队。另外还应该从合规团队与网络安全团队里面选一位成员参与，因为这两种团队的人，会对你提出一些与数据的存储方式和使用方式有关的重要需求。
你要记住，有很多渠道都能接触本组织的数据。你可能得把客户数据库、服务数据库、产品数据库、库存数据库、订单数据库与销售记录数据库全都同时考虑到。这些数据的变化频率不同，具体如何变化，要看该组织的内部工作流程。你或许无法在始终保持所有数据上线的前提下，让这些数据得到保护，因此一定要跟数据创造者沟通，以了解RPO的情况。他们会让你明白你的数据恢复系统能够做到何种程度（比方说，我们可能无法将数据恢复到发生故障的那一刻，但我们可以将其恢复到发生故障前一个小时的样子）。
一定要问清楚他们每小时或每天处理多少个事件或多少项事务，这样你才能知道数据在这个系统中的周转速度。跟数据库与数据服务团队交流时，要记得收集相关信息，搞清楚数据保存在什么地方，以及这些数据实际占用多少空间。
你需要跟管理层的成员交流，因为他们更了解本组织的实际运作情况。你一定要知道本组织的产品需要在多长时间内交付给客户，因此应该找一位非技术方面的领导（也就是部门主管）谈谈，这些人更有可能告诉你这方面的信息。
每一位管理者几乎都会对你说，他们想确保所有的数据始终能够得到保护，然而你可以通过跟他们交流，清楚地了解本组织经历的一些波折，把这些情况与你跟数据创造者的讨论结合起来，能够帮助你排定各项需求的优先顺序。
你要知道，这些人总是会说我们这个组织无法接受任何数据下线的情况（这时，你可能得拿出具体的数字，告诉他们，如果想做到这一点，那必须构建一整套冗余系统，该系统需要利用多个地方的多个数据中心，并在这些数据中心之间实时地同步数据，这要花费很多资金）。因此，你必须认真地跟他们讨论本组织在数据保护上能投入多少资金，这样的讨论必须谈到钱的问题。做好这方面的准备，你就应该能把RTO给确定下来了。
你在数据保护上采取的做法，一定要符合该组织所应遵守的法律法规。隐私是一个越来越受重视的问题，很多政府都提出了与该问题有关的法律要求。GDPR（General Data Protection Regulation，通用数据保护条例）是欧盟的法律框架，它规定组织必须能够根据要求完全删除用户的信息，这也包括位于备份及档案资料里的信息。CCPA（California Consumer Privacy Act，加利福尼亚州消费者隐私法案）规定组织必须能够回报所有系统（也包括备份系统）里包含客户信息的那些数据。从本组织的法务或治理团队里找一位SME，让这位专家帮助你检查你所设计的数据保护计划，看该计划能否按照法律法规的要求，访问备份与档案资料之中的数据。比方说，你的组织里面可能会有一位DPO（Data Protection Officer，数据保护官）来处理与欧盟的GDPR有关的合规问题。这样的DPO自然是法务方面的一位SME。
把本组织中的这些SME（主题专家）确定下来之后，就要逐个跟他们交谈，以了解他们的看法，让他们告诉你本组织中的各个部门会提出哪些数据保护方面的需求。你要注意，技术人员与非技术人员都不能漏掉，如果某些内容对于跟你谈话的人来说显得太过艰深，那你还要找个翻译，把这些内容通俗地转述给对方。SME这个称呼本身就意味着这种人一般不是通才，而是某个方面的专才。
注意，你跟SME会面时要带上一些文档与图表，以便向他们解释相关的概念，让他们能够回答你的问题。你应该从他们日常的工作流程中举例子，以便带出你的问题，然后询问他们，如果其中某个环节发生故障该怎么办。比方说，你可以这么问：如果 S:\ 盘打不开，或者OneDrive网盘坏了，该如何处理？这些故障会对组织造成什么影响？这样询问，可以让他们很快进入你的问题。
你要珍惜他们的时间，所以你应该把谈话的节奏安排好。（比方说，分3次或4次谈，每次谈20min，要比一次谈一整个小时好。）虽然你自己的工作是在从长远的角度为本组织着想，但你别忘了，他们跟你不同，他们每天都有紧迫的任务需要完成，他们要确保本组织能够把目前的事情做好。
你应该与每位SME单独谈，而不要同时找多位SME谈，因为那样可能会让其中某些专家受到其他专家影响，而无法纯粹地表达出他们本来的观点。当然，单独与这些SME谈过之后，可能会听到一些相互冲突的观点，这可以等到稍后评审需求的时候再去解决。
拜访过所有这些SME之后，你应该已经将每个部门的需求全都收集下来并整理清楚了，现在是时候把大家叫到一起了。你现在已经知道：这个数据保护计划必须做到什么程度，才能让这些部门在数据受损的情况下及时恢复运转。而且，你应该已经掌握了足够的信息，知道本组织的数据都存放在哪些地方，以及每个地方存放了多少数据。如果有些问题还需要进一步核实，那就再回去找相关的SME谈谈。这确实是一件相当重要的事情，所以一定要做好。
关于数据的产生速度与变化速度，你现在也应该清楚了（这些内容应该会由数据服务团队告诉你）。
另外，你现在应该也知道本组织的服务或产品需要花多长时间来创造或交付，进而会知道在某些数据（乃至全部数据都）无法访问时，各个部门能够撑多久（这些内容应该会由管理团队告诉你）。
把收集到的众多需求做成演示文稿，并邀请与数据保护有重要关系的人来审查这些需求。他们之中应该有管理团队的成员，这些人能够劝说本组织以及其中的数据创造者支持你的计划，另外还应该有负责运行基础设施的那些技术团队里面的一些关键人物，这些人知道如何跟数据打交道。你最好能够把大家全都叫到一起，让每个人可以就自己不太清楚的事情向其他人发问。
首先把你要解决的问题界定清楚，然后将你从各个部门收集到的需求放到这份演示文稿（也就是幻灯片）里面，让这份资料能够反映出各团队的期望。现在还没到设计方案的时候，但你可以先把本组织中每个部门的需求厘清，看看他们认为本部门在遭遇灾难时，需要什么样的支援才能保证继续运作。
你可以灵活利用Microsoft PowerPoint这样的幻灯片软件，但别做得太过华丽。幻灯片里的每张文稿，都应该从比较高的层面着眼。你应该多准备一些时间来跟大家探讨你所演示的内容，而不是仅让他们自己去把这些内容读一遍，那样他们可能会产生各自不同的想法（而没有机会把这些分歧暴露出来）。你要记住，这个阶段是在核实每个部门所提出的需求，看看这些需求怎样才能更好地融为一体。你要尽量控制节奏，让大家把重点放在讨论上，而不是非得争出一个最终的结果。如果你任由大家争着去“推销”各自的结论，那反而破坏了讨论的效果。
在这个环节，不一定要把预算与报价详细列出来，但你可以大致算算这个计划需要花费多少资金，这样就可以更好地给大家解释，让大家知道他们所提出的需求得花多少钱才能实现。
现在应该把服务水平协议（Service-Level Agreement, SLA）展示出来了，你需要通过这个协议来体现大家所认同的RPO与RTO。你要记住，数据保护必须使用大量的网络资源及存储设备（包括固态的存储设备与其他类型的存储设备），还有可能用到磁带。这些资源都有某种形式的物理限制，导致你的数据保护服务必须耗费一些时间与资金才能生效。另外还要记住，数据保护服务所使用的网络带宽，通常比本组织的其他服务要多。
比方说，如果你把数据复制到公用云平台，以便保护这些数据，那你必须要跨越广域网（Wide-Area Network, WAN），而这个广域网的带宽是有限制的。数据到达云端之后，你要考虑的是，如果它占用的云端空间较多，那么开销就比较大，因此你需要确定一个合适的时机，将某些数据移动到开销较低的地方，甚至干脆删除这些数据。在考虑数据恢复这一问题时，为了满足大家商定的RTO，你必须尽量缩短恢复数据所花的时间，然而你同时还要考虑，其中哪些数据必须恢复，哪些数据不一定需要恢复。一味追求数据恢复量，可能会让开销变得过高。总之你要提前做好测算，搞清楚自己的数据恢复计划必须做到什么样的效果，才能达到你对（内部）客户承诺的相应服务水平，这样他们到时就不会因为你的计划没有达到预期水平，或他们期望的水平超出了此计划的实际水平而责怪你了。
charge-back计费模式（model，或称计费模型），意味着每个部门都要为它所使用的服务量而承担资金责任。你应该在需求评审环节提出这个话题供大家讨论。这会对你设计解决方案时所用的办法产生影响。
比方说，销售部门在工作过程中可能会产生数百吉字节（GB）的用户数据，而且在处理完这些数据之后，通常不会专门花时间将多余的文件清理干净。如果他们要求所有的数据都必须得到保护，那你就可以提出这种计费模式，让对方知道，他们的部门需要为这些数据所占用的空间付费，这能够促使他们仔细思考，是否真的要把所有的数据都纳入保护范围。charge-back计费模式能够帮大家意识到：保护数据所用的这些基础设施并不是免费的（较为重要的数据应该优先得到保护）。这就引出了另一个需要讨论的话题，即数据分级。
在这个环节，应该花些时间给需要保护的数据做分级。并不是所有的数据都同等重要，其中相当大一部分数据，其实都可以在必要时丢弃，而不会影响本组织的正常运作。你要拿出一些时间彻底推敲一番，看看哪些数据最为关键，哪些数据比较重要，哪些数据最好能得到保留，以及哪些数据要不要都无所谓，这种数据分级的概念会直接影响你的RPO与RTO。话虽然这样讲，但许多数据保护系统其实都采用一刀切的办法来设计，它们把所有纳入保护的数据都视为“重要的”（important）数据，你们最后说不定也得做成这个样子。
你一定要跟大家强调，虽说保护数据要花钱，但绝对不能为了省钱而把必须保护的数据漏掉。你还要提醒大家注意，数据保护计划的要义，就是在本组织遇到问题时能够尽快恢复必要的数据，数据只有先得到保护，才谈得上如何恢复。
大家都要先把自己的想法放下。评审时每个人都有各自的观点，他们都会站在自身的立场上探讨本组织的事务。其中有些人可能会提出诱导式的问题，或者发出令大家遗憾的评论，你不要把这些话当成是在攻击你本人或攻击你所拟订的数据保护计划。由于这可能是本组织中的各个部门头一次有机会坐到一起，因此应该利用这个机会，热烈讨论一番，消除所有的误解，让大家全都明白，什么样的做法才是本组织应该优先考虑的做法。假如所有的事情都排在第一位，那就没有哪一件事情能够成为真正的头号要务。因此，你要让大家通过这个环节，促进彼此之间的了解，从而明白什么样的事情才是真正应该排在第一位的事情。你应该给每一个参与讨论的人分配至少10min时间，并让大家都明白，这样的会面是为了确定本组织在数据保护方面的需求（而不是纯粹为了吵架）。
要做好记录。如果你发现大家所达成的共识还有需要修改的地方，那就据此更新演示文稿，让大家再重新审查一遍。要尽可能多地这样反复修改、反复讨论，直至大家全都达成一致。你是在设立一套基本的原则，用以界定本组织应该如何保护自身的数据并在数据丢失时予以恢复，这是相当重要的事情，一定要做得稳妥。
结束需求评审之后，把结论填充到文档模板里，并将这份文档轮流传给参与评审的每一个人，让他们亲笔签名。（你可以通过SharePoint这样的平台来做，只要能让每个人都留下正式的数字签名，并确保大家签名的这份文件没有遭到篡改就行。）这是一个相当重要的步骤，因为大家在面对这样一份需要签字并为此负责的文件时，肯定会多花一些时间，先确认自己真的明白文件里说的是什么意思，然后才会在书写签名的那个地方留下名字。其他的办法都不能像这样让他们明确意识到自己的责任。
在敲定这份需求评审文档时，还有一件事需要考虑，就是要让其中一些人进入DRB（设计评审委员会），以便参与后续的设计评审环节。与需求评审委员会相比，设计评审委员会里的高管可能少一些，而技术人员与创造数据的人可能多一些。让评审需求的人来审查你根据这些需求所做的设计，总是有好处的。
在整个需求评审过程中，你的角色始终是给大家提出问题，并征集大家的意见。这正是达成共识的必经之路。你要对他们提出问题，并通过这些问题厘清大家的需求，然后把你所理解的需求告诉他们，让对方确认这正是他们想要的东西。等到大家全都赞同这套需求之后，接下来的一个环节，就是提出一些有可能实现这套需求的办法。换句话说，接下来我们要试着实际构建这个数据保护系统。