存储解决方案：如何处理灾难恢复中的人为因素_存储备份

    无论你的软件种类，无论你有怎样的计划，灾难恢复都不可避免地需要人的干预。假如人为干预不能够奏效，你的计划就会失效。因此必须优化灾难恢复计划里人的因素。

    最近，我去一家流行的连锁餐馆吃饭，发现我们的餐桌服务员非常烦躁不安。当我们点菜时，我们说了两遍，他才疯狂地把我们说的东西写下来，我们不得不重复我们所点的菜和他确认。我看着他经过厨房旁边的终端，那个终端通常是会把所点的菜目输入到餐厅的计算机系统里，他把手写的菜目交给了厨房里的什么人，然后疯狂地又抄写了一遍我们所点的菜。

    接下来，厨房里什么人发出了些很难听的声音，声音之大，以至于我们坐在餐厅里都听见了。这让我很好奇，事后，我问服务员发生什么事情了。看起来计算机系统出故障了，更糟糕的是，一些带着特定号码的点菜单被送到了每个服务员那里，而一个半小时之后，服务员才告诉治理人员这些号码本身有问题。服务员必须从乱糟糟的垃圾中找到该找的东西来保住他们的薪水。服务速度非常慢，服务员们都不知所措，等到风波平静之后，他们中的四个人被辞退或者主动提出辞职。

    这个例子对于灾难恢复来说可能过于简单，但是它却反应出在灾难恢复计划中，我们经常忽略的一个环节：人的因素。

    推卸责任的代价     无论什么级别的一名员工，从最低级别的助理到CIO，试图掩盖自己的错误，转嫁到灾难恢复计划或转嫁到别的什么无辜的员工头上，就会造成更大的损害，并损害士气。而且这种行为会使你的公司的功能性和财产的安全性受到威胁。

    因此，你的灾难恢复计划必须尽可能地不受这些人为因素的影响。假如一个人的错误引发了灾难，但由于这个人掩盖了自己的错误，灾难恢复系统不能够正确发现造成灾难的原因，那你的恢复计划就是失败的。你必须有一个目标，可靠性意味着你的灾难恢复计划必须能够跟踪人对系统的操作，不然你的灾难恢复计划就是不完善的。

    清楚地说明     绝大部分灾难恢复计划都假设所有的参与者都有同样的愿望，强烈地希望尽快把危机处理掉。这些计划的编写者从来没有考虑过会有人对此有不同的想法，或者甚至做出不道德的行为。让我们回到文章开始那个餐馆的例子，我敢打赌无论是谁为他们做的灾难恢复计划，都没有考虑到服务生带来的安全漏洞，以及楼面经理的瞎指挥可能带来的灾难后果。

    因此，在制定灾难恢复计划的时候，考虑人的决策和任务的影响，对于过程文档进行存档以供日后分析使用非常重要。而且这些过程文档需要被保存相当长的一段时间，这样，某一个错误的责任就不会被从一个人被推给另一个人。

    你如何建立目标，对于操作过程进行可供复查的跟踪和记录？下面的一些方法你可以参考。

清楚定义所有的任务目标，并为所有的任务建立文档机制。通常在一个灾难恢复计划里，一个任务仅仅是被简单地划分到某个部门或者某个经理的名下。而在计划之中，没有包含任何对每一个恢复流程的清楚定义，也没有规定针对每一个任务，应该有怎样的文档机制。这些看起来额外的步骤是非常重要的！当出现了一个错误，你就能够对问题进行追查，并加强你的计划。
公布并分发整个计划给每个人，无论他是什么级别的职员。当你知道自己的角色是什么，你也知道别人的角色是什么，你就更有可能完成自己所承担的任务。这种公开的做法对于每个人非常平等。假如你是CIO，就更要给其他人做好榜样。假如你不是，完成好自己的任务。
在计划里建立起清楚的人员失误应对计划。一个好的计划应该是有自我意识的；它应该意识到自己是有可能失败的。所以“撤退”（fallback）程序应该是系统恢复计划的一部分，以应对系统恢复出现问题或被拖延的情况。计划里，人力决策和需要人完成的任务也需要清楚地写在计划里。作为恢复计划的一部分，每一个工作都有可能失败，假如这种情况出现，该如何应对？这就需要有一个“撤退”计划。由于计划是公开的，所有的参与者都了解其他人出了差错会造成什么影响，这就形成了另外一个推动因素。

    跟踪轨迹

    捕捉人的行为，并把它们客观地，以数字文件的形式，安全地保存起来，这很轻易做到。不用担心这样做你会引发另一个层面的存档问题，或者是没有合适的工具使用。下面是一些零散的建议。

建立你的灾难日志数据库，并内嵌报告。让人们汇报他们的恢复工作是非常好的一个办法，通过电话或者私下接触的交流是非常重要的，但是还要求所有被完成的任务都必须毫不含糊地被记录下来，并进行存档。电子邮件是不够的。纸质的记录也是不够的。假如你的灾难日志是一个数据库，即便是简单临时的基于SQL的数据库，你都有能力建立起针对任务、针对用户的机制（或者两者兼而有之），并且能够根据已经完成的工作报告安排后面应该进行的恢复工作。假如员工知道他们的任务使别的任务受到影响，只有他们能够及时提交报告完成灾难日志才能够保障恢复的顺利进行，他们就会非常努力地工作，并尽可能详尽地做好记录和存档。
在企业网络架构里，假如混乱仅仅是存在于某个特定的系统而不是全局，就有可能在某台信息服务器或者一台功能比较强大的服务器上内嵌一个恢复程序。假如特定的系统出了问题，你的网络仍然是正常的，你就可以通过企业的信息系统来完成恢复工作，并进行报告。这样做除了具有上面的那些好处，还能够大大加快你的恢复速度。
不要仅仅依靠电子邮件，链接需要认真对待。假如由于你的网络状况和服务器的分布情况、人员的分布情况等，使得你的灾难恢复计划需要在远距离控制，电子邮件可能是一种有效的沟通方式。但是，仅仅发送警告电子邮件是不够的。承担恢复工作的协调人必须收到确认，但是电子邮件在确认某项工作的完成状况方面，有些力不从心。不过，电子邮件里内置的链接将能够引导用户访问你的信息服务器。不过这样的访问接入应该是针对特定任务，特定用户的，并且应该被具体记录。