读数据保护：工作负载的可恢复性02收集需求

1. 要点

1.1. 数据保护并不是IT里面最出彩的部分

• 1.1.1. 让这个组织知道自己可能遭受哪些风险

• 1.1.2. 与该组织内具有核心竞争力的IT产品通常没有什么联系

1.2. 做数据保护所需的资源通常很昂贵，而且这些资源并不会体现在该组织卖给客户的最终产品里

• 1.2.1. 没人会情愿为这种保单付费

1.3. 在开始花费大量预算做数据保护之前，必须先确保自己所要构建的这套数据保护方案，确实将企业在这方面的需求涵盖了进来

2. 组织的工作内容

2.1. 作为数据保护者，你必须尽力构建出能够保护所有数据与所有人的最佳方案

• 2.1.1. 全面了解这个组织的情况，有助于你更好地拟定数据保护方案

2.2. 从组织本身，以及该组织提供的服务或产品入手，来理解这个组织里面的数据，以确定其中哪些数据最重要

2.3. 在开始处理你收集到的这些信息之前，必须先构建一套框架给自己使用，以便通过该框架来处理信息，另外还要构建一套文档系统，用以记录信息

3. 收集需求

3.1. 把与数据保护计划有关的重要人物找出来，搞清楚这些人的要求，只有这样，你做的计划才能有效施行

3.2. 确定RPO与RTO

• 3.2.1. 恢复点目标（Recovery Point Objective, RPO；也叫目标恢复点）​

• 3.2.1.1. 出现灾难时最多能够容忍多少数据丢失

• 3.2.2. 恢复时间目标（Recovery Time Objective, RTO；也叫目标恢复时间）​

• 3.2.2.1. 遇到灾难之后必须在多长时间内恢复数据

3.3. 寻找SME

• 3.3.1. 对于数据保护工作来说，组织里的每个人都是你的客户

• 3.3.2. SME（主题专家）

• 3.3.2.1. 数据是不是必须始终保持上线（而不允许暂时下线）​

>  3.3.2.1.1. 可能无法将数据恢复到发生故障的那一刻，但我们可以将其恢复到发生故障前一个小时的样子

• 3.3.2.2. 数据创造者

>  3.3.2.2.1. 知道数据是从哪里来的，也知道它是从哪个部门来的

>  3.3.2.2.2. 只有先搞清楚数据产生自哪个部门，我们才能知道数据丢失时从头开始重建数据是不是特别复杂

>  3.3.2.2.3. 可能来自生产与运营团队

>  3.3.2.2.4. 可能来自负责收集产品管理、组织及业务等方面信息的团队

>  3.3.2.2.5. 可能来自数据服务团队

>  3.3.2.2.6. 从合规团队与网络安全团队里面选一位成员参与，因为这两种团队的人，会对你提出一些与数据的存储方式和使用方式有关的重要需求

>  3.3.2.2.7. 有很多渠道都能接触本组织的数据

>  3.3.2.2.8. 数据的变化频率不同，具体如何变化，要看该组织的内部工作流程

  >   3.3.2.2.8.1. 一定要问清楚他们每小时或每天处理多少个事件或多少项事务，这样你才能知道数据在这个系统中的周转速度

  >   3.3.2.2.8.2. 数据库与数据服务团队交流时，要记得收集相关信息，搞清楚数据保存在什么地方，以及这些数据实际占用多少空间

• 3.3.2.3. 管理者

>  3.3.2.3.1. 跟管理层的成员交流，因为他们更了解本组织的实际运作情况

>  3.3.2.3.2. 知道本组织的产品需要在多长时间内交付给客户

>  3.3.2.3.3. 认真地跟他们讨论本组织在数据保护上能投入多少资金，这样的讨论必须谈到钱的问题

  >   3.3.2.3.3.1. 做好这方面的准备，你就应该能把RTO给确定下来了

• 3.3.2.4. 法务专家

>  3.3.2.4.1. 在数据保护上采取的做法，一定要符合该组织所应遵守的法律法规

>  3.3.2.4.2. 隐私是一个越来越受重视的问题，很多zf都提出了与该问题有关的法律要求

3.4. 厘清需求

• 3.4.1. 技术人员与非技术人员都不能漏掉，如果某些内容对于跟你谈话的人来说显得太过艰深，那你还要找个翻译，把这些内容通俗地转述给对方

• 3.4.2. 要珍惜他们的时间，所以你应该把谈话的节奏安排好

• 3.4.2.1. 分3次或4次谈，每次谈20min，要比一次谈一整个小时好

• 3.4.2.2. 他们每天都有紧迫的任务需要完成，他们要确保本组织能够把目前的事情做好

• 3.4.3. 应该与每位SME单独谈，而不要同时找多位SME谈

• 3.4.3.1. 可能会让其中某些专家受到其他专家影响，而无法纯粹地表达出他们本来的观点

• 3.4.3.2. 单独与这些SME谈过之后，可能会听到一些相互冲突的观点，这可以等到稍后评审需求的时候再去解决

3.5. 评审需求

• 3.5.1. 将每个部门的需求全都收集下来并整理清楚了

• 3.5.2. 掌握了足够的信息，知道本组织的数据都存放在哪些地方，以及每个地方存放了多少数据

• 3.5.3. 关于数据的产生速度与变化速度，现在也应该清楚了

• 3.5.4. 知道本组织的服务或产品需要花多长时间来创造或交付，进而会知道在某些数据（乃至全部数据都）无法访问时，各个部门能够撑多久

• 3.5.5. 把收集到的众多需求做成演示文稿，并邀请与数据保护有重要关系的人来审查这些需求

• 3.5.5.1. 能够劝说本组织以及其中的数据创造者支持你的计划，另外还应该有负责运行基础设施的那些技术团队里面的一些关键人物

• 3.5.5.2. 要解决的问题界定清楚，然后将你从各个部门收集到的需求放到这份演示文稿（也就是幻灯片）里面，让这份资料能够反映出各团队的期望

• 3.5.5.3. 这个阶段是在核实每个部门所提出的需求，看看这些需求怎样才能更好地融为一体

• 3.5.5.4. 不一定要把预算与报价详细列出来，但你可以大致算算这个计划需要花费多少资金，这样就可以更好地给大家解释，让大家知道他们所提出的需求得花多少钱才能实现

• 3.5.6. 服务水平协议

• 3.5.6.1. Service-Level Agreement, SLA

• 3.5.6.2. 通过这个协议来体现大家所认同的RPO与RTO

• 3.5.6.3. 数据保护必须使用大量的网络资源及存储设备（包括固态的存储设备与其他类型的存储设备）​，还有可能用到磁带

>  3.5.6.3.1. 导致你的数据保护服务必须耗费一些时间与资金才能生效

>  3.5.6.3.2. 数据保护服务所使用的网络带宽，通常比本组织的其他服务要多

• 3.5.6.4. 数据保护服务所使用的网络带宽，通常比本组织的其他服务要多

• 3.5.6.5. 提前做好测算，搞清楚自己的数据恢复计划必须做到什么样的效果，才能达到你对（内部）客户承诺的相应服务水平，这样他们到时就不会因为你的计划没有达到预期水平，或他们期望的水平超出了此计划的实际水平而责怪你了

• 3.5.7. charge-back计费模式

• 3.5.7.1. charge-back计费模式（model，或称计费模型）​，意味着每个部门都要为它所使用的服务量而承担资金责任

• 3.5.7.2. 部门需要为这些数据所占用的空间付费，这能够促使他们仔细思考，是否真的要把所有的数据都纳入保护范围

• 3.5.7.3. 保护数据所用的这些基础设施并不是免费的（较为重要的数据应该优先得到保护）​

• 3.5.8. 数据分级

• 3.5.8.1. 花些时间给需要保护的数据做分级

• 3.5.8.2. 并不是所有的数据都同等重要，其中相当大一部分数据，其实都可以在必要时丢弃，而不会影响本组织的正常运作

• 3.5.8.3. 数据分级的概念会直接影响你的RPO与RTO

• 3.5.8.4. 保护数据要花钱，但绝对不能为了省钱而把必须保护的数据漏掉

• 3.5.8.5. 数据保护计划的要义，就是在本组织遇到问题时能够尽快恢复必要的数据，数据只有先得到保护，才谈得上如何恢复

3.6. 结束需求评审

• 3.6.1. 评审时每个人都有各自的观点，他们都会站在自身的立场上探讨本组织的事务

• 3.6.2. 给每一个参与讨论的人分配至少10min时间，并让大家都明白，这样的会面是为了确定本组织在数据保护方面的需求（而不是纯粹为了吵架）​

• 3.6.3. 要做好记录

• 3.6.3.1. 如果你发现大家所达成的共识还有需要修改的地方，那就据此更新演示文稿，让大家再重新审查一遍

• 3.6.4. 结束需求评审之后，把结论填充到文档模板里，并将这份文档轮流传给参与评审的每一个人，让他们亲笔签名

• 3.6.4.1. 面对这样一份需要签字并为此负责的文件时，肯定会多花一些时间，先确认自己真的明白文件里说的是什么意思，然后才会在书写签名的那个地方留下名字

• 3.6.5. 让其中一些人进入DRB（设计评审委员会）​，以便参与后续的设计评审环节

• 3.6.5.1. 让评审需求的人来审查你根据这些需求所做的设计，总是有好处的

• 3.6.6. 在整个需求评审过程中，你的角色始终是给大家提出问题，并征集大家的意见