無論什么級別的一名員工，從最低級別的助理到CIO，試圖掩蓋自己的錯誤，轉嫁到災難恢復計劃或轉嫁到別的什么無辜的員工頭上，就會造成更大的損害，并損害士氣。而且這種行為會使你的公司的功能性和財產的安全性受到威脅。
因此，你的災難恢復計劃必須盡可能地不受這些人為因素的影響。如果一個人的錯誤引發(fā)了災難，但由于這個人掩蓋了自己的錯誤，災難恢復系統(tǒng)不能夠正確發(fā)現(xiàn)造成災難的原因，那你的恢復計劃就是失敗的。你必須有一個目標，可靠性意味著你的災難恢復計劃必須能夠跟蹤人對系統(tǒng)的操作，不然你的災難恢復計劃就是不完善的。
清楚地說明
絕大部分災難恢復計劃都假設所有的參與者都有同樣的愿望，強烈地希望盡快把危機處理掉。這些計劃的編寫者從來沒有考慮過會有人對此有不同的想法，或者甚至做出不道德的行為。讓我們回到文章開始那個餐館的例子，我敢打賭無論是誰為他們做的災難恢復計劃，都沒有考慮到服務生帶來的安全漏洞，以及樓面經理的瞎指揮可能帶來的災難后果。
因此，在制定災難恢復計劃的時候，考慮人的決策和任務的影響，對于過程文檔進行存檔以供日后分析使用非常重要。而且這些過程文檔需要被保存相當長的一段時間，這樣，某一個錯誤的責任就不會被從一個人被推給另一個人。
你如何建立目標，對于操作過程進行可供復查的跟蹤和記錄？下面的一些方法你可以參考。
- 清晰定義所有的任務目標，并為所有的任務建立文檔機制。通常在一個災難恢復計劃里，一個任務僅僅是被簡單地劃分到某個部門或者某個經理的名下。而在計劃之中，沒有包含任何對每一個恢復流程的清晰定義，也沒有規(guī)定針對每一個任務，應該有怎樣的文檔機制。這些看起來額外的步驟是非常重要的！當出現(xiàn)了一個錯誤，你就能夠對問題進行追查，并加強你的計劃。
- 公布并分發(fā)整個計劃給每個人，無論他是什么級別的職員。當你知道自己的角色是什么，你也知道別人的角色是什么，你就更有可能完成自己所承擔的任務。這種公開的做法對于每個人非常平等。如果你是CIO，就更要給其他人做好榜樣。如果你不是，完成好自己的任務。
- 在計劃里建立起清晰的人員失誤應對計劃。一個好的計劃應該是有自我意識的；它應該意識到自己是有可能失敗的。所以“撤退”（fallback）程序應該是系統(tǒng)恢復計劃的一部分，以應對系統(tǒng)恢復出現(xiàn)問題或被拖延的情況。計劃里，人力決策和需要人完成的任務也需要清晰地寫在計劃里。作為恢復計劃的一部分，每一個工作都有可能失敗，如果這種情況出現(xiàn)，該如何應對？這就需要有一個“撤退”計劃。由于計劃是公開的，所有的參與者都了解其他人出了差錯會造成什么影響，這就形成了另外一個推動因素。
跟蹤軌跡
捕捉人的行為，并把它們客觀地，以數(shù)字文件的形式，安全地保存起來，這很容易做到。不用擔心這樣做你會引發(fā)另一個層面的存檔問題，或者是沒有合適的工具使用。下面是一些零散的建議。
- 建立你的災難日志數(shù)據(jù)庫，并內嵌報告。讓人們匯報他們的恢復工作是非常好的一個辦法，通過電話或者私下接觸的交流是非常重要的，但是還要求所有被完成的任務都必須毫不含糊地被記錄下來，并進行存檔。電子郵件是不夠的。紙質的記錄也是不夠的。如果你的災難日志是一個數(shù)據(jù)庫，即便是簡單臨時的基于SQL的數(shù)據(jù)庫，你都有能力建立起針對任務、針對用戶的機制（或者兩者兼而有之），并且能夠根據(jù)已經完成的工作報告安排后面應該進行的恢復工作。如果員工知道他們的任務使別的任務受到影響，只有他們能夠及時提交報告完成災難日志才能夠保障恢復的順利進行，他們就會非常努力地工作，并盡可能詳盡地做好記錄和存檔。
- 在企業(yè)網(wǎng)絡架構里，如果混亂僅僅是存在于某個特定的系統(tǒng)而不是全局，就有可能在某臺信息服務器或者一臺功能比較強大的服務器上內嵌一個恢復程序。如果特定的系統(tǒng)出了問題，你的網(wǎng)絡仍然是正常的，你就可以通過企業(yè)的信息系統(tǒng)來完成恢復工作，并進行報告。這樣做除了具有上面的那些好處，還能夠大大加快你的恢復速度。
- 不要僅僅依靠電子郵件，鏈接需要認真對待。如果由于你的網(wǎng)絡狀況和服務器的分布情況、人員的分布情況等，使得你的災難恢復計劃需要在遠距離控制，電子郵件可能是一種有效的溝通方式。但是，僅僅發(fā)送警告電子郵件是不夠的。承擔恢復工作的協(xié)調人必須收到確認，但是電子郵件在確認某項工作的完成狀況方面，有些力不從心。不過，電子郵件里內置的鏈接將能夠引導用戶訪問你的信息服務器。不過這樣的訪問接入應該是針對特定任務，特定用戶的，并且應該被詳細記錄。
