读数据保护：工作负载的可恢复性03构建自己的框架.png

1. 构建自己的框架

1.1. 数据保护工作会影响本组织的各个方面

• 1.1.1. 听取各种人员的意见并征得他们的同意，其中有技术人员，也有非技术人员

• 1.1.2. 建立各种评审委员会(review board)

1.2. 文档模板

• 1.2.1. 目标阐述

  • 1.2.1.1. 尽可能简洁地阐述这份文档的目标，篇幅控制在一段或两段之内

• 1.2.2. 执行纲要

  • 1.2.2.1. 要在此部分给拥有审批权的人提供足够的信息

• 1.2.3. 修订历史

  • 1.2.3.1. 所有的文档都应该及时更新

    1.2.3.1.1. 随时应对变化

  • 1.2.3.2. 帮助你了解正在看的是哪个版本，并且让你知道文档是经过了怎样的修订才变成现在这样的

• 1.2.4. 签名页

  • 1.2.4.1. 数据保护计划对你的组织至关重要，因此在开发这样一个项目时，必须明确责任

  • 1.2.4.2. 确保每一位关键的审批人与主题专家(Subject Matter Expert, SME)都愿意遵循该计划，并在文档的最终版（也就是确定版）上签名

• 1.2.5. 工作策略/工作范围

  • 1.2.5.1. 有助于把该文档所要强调的某些主题给界定清楚

• 1.2.6. 词汇表（术语表）

  • 1.2.6.1. 对参与审批的非主题专家来说尤其有帮助

• 1.2.7. 附录

1.3. 评审委员会/咨询委员会的工作流程

• 1.3.1. 建立一套良好的评审体制，能够帮助你聚合不同的观点，让你不会忽略掉某个与该系统的部件或需求有重要关系的意见

• 1.3.2. 需求评审

  • 1.3.2.1. 安排各个部门的成员都来参与需求评审这一环节，而且还要有一名高管，以确保整个组织都能对这个项目感到满意

  • 1.3.2.2. CIO（Chief Information Officer，首席信息官）是很合适的人选

    1.3.2.2.1. 既了解组织所使用的技术，又知道组织会以何种策略来使用这些技术

• 1.3.3. 设计评审

  • 1.3.3.1. 从那些与特定技术有关的团队里选择成员来组成设计评审委员会(Design Review Board, DRB)，这些人能够提供自己的见解，让你知道某项技术应该如何在本组织中实现

  • 1.3.3.2. 架构评审委员会(Architecture Review Board, ARB)

  • 1.3.3.3. 初步设计评审(Preliminary Design Review, PDR)

    1.3.3.3.1. 先让设计方案经历这个小环节，以确保该方案已经遵守了相关的要求

  • 1.3.3.4. 生产准备状态评审(Production Readiness Review, PRR)

    1.3.3.4.1. 在设计方案已全部做好并经过最终测试之后执行的，它的目标是让大家都能够最后再看一遍，以确认没有漏掉什么东西

• 1.3.4. 操作评审

  • 1.3.4.1. 在生产环境（也就是正式的工作环境）中运行该服务的运营团队召集在一起，让他们参与这一环节，以充分了解自己所要执行的是什么样的操作

  • 1.3.4.2. 完成操作评审（operation review，也叫运营评审）后，应该形成一份使用说明，以充当该系统的用户手册

• 1.3.5. 变更评审

  • 1.3.5.1. 变更咨询委员会(Change Advisory Board, CAB)，该委员会应该是技术组织里的一部分，用来在实施最终方案之前，把方案里有可能对本组织的日常运营造成影响的那些变化之处审核一遍

  • 1.3.5.2. 检查方案里提到的变化对本组织是否合适，以防其破坏该组织的整体工作

• 1.3.6. 项目管理

  • 1.3.6.1. 要使用稳健的项目管理手段来推进数据保护计划，这可以帮助你协调工作，给相关人员提供资源并安排好各项任务的时间

  • 1.3.6.2. 让你总是能够按时拿出应该交付的东西，并确保这个计划顺利施行

2. 设计并构建数据保护系统

2.1. 在设计环节，你的目标跟收集需求时类似，也是让大家对设计方案达成共识

2.2. 起草多种设计方案

• 2.2.1. 每种方案的价格、实际恢复时间(Recovery Time Actual, RTA)、实际恢复点(Recovery Point Actual,RPA)都不同，而且执行该方案的人所需具备的操作水平也不一样

• 2.2.2. 第一种方案，总应该是那种“无论要什么都尽量安排，别担心花多少钱”的方案，该方案只考虑怎样满足需求文档里定义的RPO与RTO

  • 2.2.2.1. 让大家有一个很好的参照物，知道这个所谓的完美方案或理想方案需要花费多少资金

• 2.2.3. 第二好的方案（second-best solution，次佳方案）

  • 2.2.3.1. 自身可能有一些问题需要稍后解决

  • 2.2.3.2. 方案减少了初期需要投入的资金，让我们能等到以后真正需要执行某些操作时再投入

• 2.2.4. 故障是没有什么规律的，因此，把恢复出来的这些文件都整理到故障之前的正常状态，并不像你想的那么轻松，有时还不如干脆少备份一些文件，等到恢复数据时再重制那些丢掉的文件

• 2.2.5. 为了满足RTO，你必须尽快把数据恢复到正常状态，为此，你可能会削减你所恢复并整理的数据量，但是又不能减得太过，那样就无法满足RPO了

  • 2.2.5.1. 必须把话说得很周到

2.3. 评审设计方案

• 2.3.1. 设计评审委员会(DRB)

• 2.3.2. 根据最终的需求文档做个小结，然后从这个小结出发，深入探索其中某些细节问题的具体处理方式,并把这些做法记录下来

  • 2.3.2.1. 一定要把你对RPO的要求写下来，而且要写出你为了满足RTO还必须做哪些工作

• 2.3.3. 等到确定最终的设计方案之后，你就可以将其完整地写成文档，并让大家轮流签字了

2.4. 挑选部件并以此构建数据保护系统

• 2.4.1. 准确测定恢复数据所花的时长，以确认该系统满足了需求文档里面写的SLA

• 2.4.2. 制订操作计划并编写操作文档了

3. 编写操作文档

3.1. 必须把该准备的文档全都准备好，你的工作才算完成

• 3.1.1. 必须把该系统的用法写成文档，让没有参与设计的那些人也能明白如何使用该系统，而不需要你在旁边指导

3.2. 界定每个人的操作角色

• 3.2.1. 每个人都必须知道自己在这个新数据保护系统里面的地位

• 3.2.2. RACI图

  • 3.2.2.1. R(Responsible)是执行人

    3.2.2.1.1. 实际执行任务的人

  • 3.2.2.2. A(Accountable)是负责人

    3.2.2.2.1. 为任务顺利完成或产品顺利交付而负责的人

  • 3.2.2.3. C(Collaborator)是协作人

    3.2.2.3.1. 帮助实际执行人完成某项任务的人

  • 3.2.2.4. I(Informed)是知情人

    3.2.2.4.1. 需要了解任务执行进度的人

• 3.2.3. 一定要让ORB（Operation Review Board，运行评审委员会）审查你的RACI图，并向他们提出问题，以此搞清楚你的这个新系统会不会对本组织造成什么影响

3.3. 编写操作文档

• 3.3.1. 要确保所有的文档都已及时更新，并确保这套文档已经把这个数据保护系统所涉及的人全都覆盖到了

• 3.3.2. 操作手册、运行说明或标准操作流程（Standard Operating Procedure, SOP；也称为标准作业程序）

• 3.3.3. 从在日常工作中接触这个数据保护系统的人的角度写出来的东西是很有价值的

3.4. 劝说大家编写文档

• 3.4.1. 大家都知道但却都不愿意去碰的事情，也就是撰写文档

• 3.4.2. 文档是必不可少的，而这样的说明书、手册或者SOP，最好能由拿这个系统执行实际任务的人来写，而不应该由从未做过这些事的人来写

3.5. 文档模板

• 3.5.1. 操作说明（也就是SOP或者操作手册）应该像早前的设计文档与需求文档一样，遵循相应的模板

• 3.5.2. 文档里要有服务的概述、文档的修订记录，以及一张签名页，让每个与执行该服务有关的部门都签字同意

• 3.5.3. 每一份清单都对应于日常工作中的某一项常规任务

  • 3.5.3.1. 如果操作人员的时间比较紧迫，那么可以把手册复印一份，每做完其中一项，就在此项前面的框里做个记号

• 3.5.4. FAQ（Frequently Asked Question，常见问题解答）区

  • 3.5.4.1. 用来详细解释我们在操作过程中可能会遇到的一些复杂问题

• 3.5.5. 联系信息

  • 3.5.5.1. 一定要写上联系信息，其中包括各大供应商的联系方式，让我们能够在某组件发生故障时，联系到提供该组件的那家供应商里负责提供支持的人员

  • 3.5.5.2. 让操作人员能够联系到受这项服务影响的各个部门的负责人，以及应该得到通知的各位高管

  • 3.5.5.3. 联系信息里面要包含手机号，而且要注明遇到紧急情况时，应该优先以什么样的方式来联系这些人

• 3.5.6. 给操作人员列出有可能出现的各种状况，并针对每种状况撰写一段小结，同时给出解决办法

  • 3.5.6.1. tracking support ticket

• 3.5.7. 至少保留一份纸质的手册，把它放在活页夹里，让操作人员能够方便地查阅

  • 3.5.7.1. 有了这份纸质手册，以后停电时你就不用在机房里使劲回想服务器的启动顺序了，而是可以直接翻开手册来执行操作

3.6. 纳入工作环境

• 3.6.1. 凡是要对数据保护服务做出修改（例如要升级软件或做数据恢复测试），都应该先告知CAB

• 3.6.2. 还没有CAB，那就设立一个这样的委员会

  • 3.6.2.1. 再指定一位变更经理（change manager；也称变更管理者），这位经理专门负责CAB以及CAB所要监管的事务

• 3.6.3. 轮到CAB（变更咨询委员会）发表意见了

  • 3.6.3.1. 你要修改的是什么？

  • 3.6.3.2. 这个新的东西有没有经过全面测试？

  • 3.6.3.3. 这次变更可能影响或者将要影响哪些服务？

  • 3.6.3.4. 如果变更后的效果不理想，我们怎样退回到变更前的状态？

  • 3.6.3.5. 这次变更安排在什么时候做？需要多长时间才能做完？