下载掌阅APP，畅读海量书库
立即打开
必须把该准备的文档全都准备好，你的工作才算完成。就算你设计了一套相当精妙的数据保护系统，如果没人会用这个系统，那意味着你的工作并没有完成。你必须把该系统的用法写成文档，让没有参与设计的那些人也能明白如何使用该系统，而不需要你在旁边指导。
每个人都必须知道自己在这个新数据保护系统里面的地位。你可以先画一张RACI图，以明确各团队在利用数据保护服务所提供的各种操作来完成任务时，分别扮演什么样的角色：R（Responsible）是执行人，A（Accountable）是负责人，C（Collaborator）是协作人，I（Informed）是知情人。
执行人
实际执行任务的人。
负责人
为任务顺利完成或产品顺利交付而负责的人。
协作人
帮助实际执行人完成某项任务的人。
知情人
需要了解任务执行进度的人。
你应该把各团队通过这个数据保护系统所要完成的各项任务列出来，然后指出每个团队在执行这项任务的过程中所扮演的角色。例如表2-1就是一张典型的RACI图。通过这张图，我们很容易看出谁是执行人、谁是负责人、谁是协作人，以及谁是关注工作进度的知情人。
表2-1：一张典型的RACI图
在让数据保护系统正式上线之前，你应该先确保与该系统有关的这些团队都赞同使用这套系统，这对后续的数据保护工作很有帮助。一定要让ORB（Operation Review Board，运行评审委员会）审查你的RACI图，并向他们提出问题，以此搞清楚你的这个新系统会不会对本组织造成什么影响。
在你开始把这个数据保护系统与本组织生产重要数据的工作系统融合起来的时候，一定要确保所有的文档都已及时更新，并确保这套文档已经把这个数据保护系统所涉及的人全都覆盖到了。你在前面已经编写了需求文档与设计文档，现在应该来编写这个叫作操作手册、运行说明或标准操作流程（Standard Operating Procedure, SOP；也称为标准作业程序）的东西了。无论叫什么，其指的都是同一个东西。编写这个东西，是为了让大家了解该系统如何与本组织的日常运作相配合。你现在必须把操作文档落实到位，这样一份文档，当然应该由这个系统的设计者（也就是你自己）来牵头安排编写。
你必须跟RACI图里提到的每个团队会面，例如系统管理团队以及网络运维中心（Network Operation Center, NOC），并收集他们的需求，看看他们想让你把什么东西写在文档里面，他们可能想通过这些东西来明确本团队在执行某项操作时的职责。你可以从每个团队里选定一个人，让这个人去熟悉其团队在执行某项操作时应该扮演的角色，并令其撰写相关的初稿，这对你与他们都很有帮助。由于他们是在日常工作中接触这个数据保护系统的人，因此，从他们的角度写出来的东西是很有价值的。
现在我们先花点时间，说说这个大家都知道但却都不愿意去碰的事情，也就是撰写文档。我们都有自己觉得很有意思的工作要做。自己把这个系统管理好，要比写文档告诉别人怎么运行这个系统容易得多。
所以，你应该像一位销售员那样，随时准备给大家解释写文档的好处，让大家知道，要想有效且有序地操纵这套数据保护系统，文档是必不可少的，而这样的说明书、手册或者SOP，最好能由拿这个系统执行实际任务的人来写，而不应该由从未做过这些事的人来写。你在劝说别人写文档的时候，可以采用下面这样的说法：
我跟你说，写文档才是你最应该做的事情……你想去度假？想休息一天？想整晚睡个好觉？想去更高、更好的位置上工作？可是，如果这个系统有问题，大家总是找你来解决，那前面这些就都不要想了。你是不是觉得，系统有问题时大家总是找我，那说明我很重要啊！千万不要有这样的感觉，你不要以为这意味着你的位置坐得很稳，实话告诉你，只要公司愿意花钱雇别人，咱们之中的每个人都是随时可能让公司给换掉的。既然这样，那还不如把文档写好，让他们在遇到问题的时候去查文档，去加班修复这个问题，而不要半夜把你给叫起来，这样你才能够安心地度假、休息、睡觉……
这份操作说明（也就是SOP或者操作手册）应该像早前的设计文档与需求文档一样，遵循相应的模板。你应该把这份文档写得相当完备，而且可以把前面那两份文档也当作附录添加进来，这样的话，如果操作人员想要更详细地了解该系统所提供的服务（为什么会做成这样），那么可以查阅这些附件。文档里要有这项服务的概述、文档的修订记录，以及一张签名页，让每个与执行该服务有关的部门都签字同意。
另外，这种操作说明应该按照各项操作（也就是各项任务）的执行频率，列出许多份清单，每一份清单都对应于日常工作中的某一项常规任务。清单中的各条目，就是我们在执行该任务时所要确认的各个事项，如果操作人员的时间比较紧迫，那么可以把手册复印一份，每做完其中一项，就在此项前面的框里做个记号。
文档还应该有FAQ（Frequently Asked Question，常见问题解答）区，用来详细解释我们在操作过程中可能会遇到的一些复杂问题。
一定要写上联系信息，其中包括各大供应商的联系方式，让我们能够在某组件发生故障时，联系到提供该组件的那家供应商里负责提供支持的人员，另外，还要让操作人员能够联系到受这项服务影响的各个部门的负责人，以及应该得到通知的各位高管。联系信息里面要包含手机号，而且要注明遇到紧急情况时，应该优先以什么样的方式来联系这些人。
最后还应该有一个部分，给操作人员列出有可能出现的各种状况，并针对每种状况撰写一段小结，同时给出解决办法。另外还要留出一定篇幅，以便引用解决此类问题时所留下的记录（这种记录叫作tracking support ticket），这样操作人员可以由此看出，以前是否发生过同类问题，如果发生过，那么是如何解决的。
笔者建议至少保留一份纸质的手册，把它放在活页夹里，让操作人员能够方便地查阅。现在我们总是喜欢用云端服务与wiki存放文档，然而在系统或网络出现故障时，这些形式都无法保证我们能够很快地找到手册并据此恢复服务。打印这样一份手册，似乎是在浪费纸，但有了这份纸质手册，以后停电时你就不用在机房里使劲回想服务器的启动顺序了，而是可以直接翻开手册来执行操作。
这个系统已经设计出来并经过测试，而且文档也已准备完毕，现在应该把它正式纳入工作环境。这个时候，该轮到CAB（变更咨询委员会）发表意见了。
你的技术组织里应该有一个定期开会的CAB，用来在改变正式的工作环境之前审查这些变更，从而评估其对客户的影响。如果你的组织里还没有这样的CAB，那就设法召集一个。CAB可以通过下面这套简单的问题，确保变更之后的环境能够稳定地运作：
·你要修改的是什么？
·这个新的东西有没有经过全面测试？
·这次变更可能影响或者将要影响哪些服务？
·如果变更后的效果不理想，我们怎样退回到变更前的状态？
·这次变更安排在什么时候做？需要多长时间才能做完？
CAB让本组织内的每个人都能了解工作环境的变化情况，从而更及时地意识到有可能出现的问题，并在确实出现问题时尽快退回到变更前的状态。如果你的组织现在还没有CAB，那就设立一个这样的委员会。另外可以再指定一位变更经理（change manager；也称变更管理者），这位经理专门负责CAB以及CAB所要监管的事务。
在将这个数据保护系统纳入正式的生产环境之前，你应该先把整套文档（尤其是其中的操作手册）拿给CAB看，让他们全部审查一遍。如果这些委员会成员选择得都比较恰当，那么CAB里面的许多人，应该在前面提到的各种评审委员会里出现过，因此他们应该已经了解你打算上线的这个数据保护系统了。
这也是一个需要反复执行的过程。你要仔细听取CAB成员的意见，并配合他们的工作。如果他们担心某项改动会产生问题，并且需要与之有关的数据来做出判断，那你就应该收集这些数据，让他们根据这些数据重新评估这项改动是否合适。如果他们对你说，目前还有其他地方正在修改，让你把你要改的地方先放一放，那你就先耐心等待。如果一次改动很多地方，那万一出现问题，就很难确定这个问题到底是由哪一项改动引发的。等到他们让你改的时候，你再着手修改。
凡是要对数据保护服务做出修改（例如要升级软件或做数据恢复测试），都应该先告知CAB。他们对维持工作环境稳定是很有帮助的，请大家相信笔者的话。