读数据维护：作业负载的可恢复性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. 在整个需求评定过程中，你的人物始终是给我们提出问题，并搜集我们的定见
