ToB企服应用市场:ToB评测及商务社交产业平台

标题: 读数据保护：工作负载的可恢复性03构建自己的框架 [打印本页]

---

作者: 星球的眼睛    时间: 2024-12-4 14:15
标题: 读数据保护：工作负载的可恢复性03构建自己的框架

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. >  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. >  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. >  1.3.3.3.1. 先让设计方案经历这个小环节，以确保该方案已经遵守了相关的要求

复制代码

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

1. >  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)是执行人
  

1. >  3.2.2.1.1. 实际执行任务的人

复制代码

• 3.2.2.2. A(Accountable)是负责人
  

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

复制代码

• 3.2.2.3. C(Collaborator)是协作人
  

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

复制代码

• 3.2.2.4. I(Informed)是知情人
  

1. >  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. 这次变更安排在什么时间做？须要多长时间才气做完？
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4