1. 要点
1.1. 数据保护并不是IT里面最出彩的部分
- 1.1.1. 让这个构造知道本身可能遭受哪些风险
- 1.1.2. 与该构造内具有核心竞争力的IT产品通常没有什么接洽
1.2. 做数据保护所需的资源通常很昂贵，而且这些资源并不会体现在该构造卖给客户的最终产品里
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.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.1. 跟管理层的成员交流，因为他们更了解本组织的实际运作情况
- > 3.3.2.3.2. 知道本组织的产品需要在多长时间内交付给客户
- > 3.3.2.3.3. 认真地跟他们讨论本组织在数据保护上能投入多少资金，这样的讨论必须谈到钱的问题
- > 3.3.2.3.3.1. 做好这方面的准备，你就应该能把RTO给确定下来了
- > 3.3.2.4.1. 在数据保护上采取的做法，一定要符合该组织所应遵守的法律法规
- > 3.3.2.4.2. 隐私是一个越来越受重视的问题，很多zf都提出了与该问题有关的法律要求
- 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. 在整个需求评审过程中，你的脚色始终是给各人提出题目，并征集各人的意见
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
