通常狀態下,任何系統都無法在沒有定期測試檢查的情況下始終順暢運行。但盡管如此,定期測試系統仍被很多企業忽視。汽車停在倉庫里兩年后還可以正常發動嗎?如果可以,只能說你走運,其實IT系統和汽車發動機一樣,舉個簡單的例子,要是企業沒有定期測試和維護相關系統,站點故障切換很難成功。
對企業來說,完全放棄測試顯然很危險。但如果測試系統的方法不能如實反映出系統的真實使用情況,同樣非常危險。下面七條規則則可以幫助企業更可靠地完成系統測試,并確保測試的過程更充分地反映出系統真實狀況。
第一條:執行真實測試
首先要確保你的測試盡可能接近實際情況。比如你要測試系統進行站點故障切換的能力,就務必要將測試系統與主站點完全隔離開來,在這樣的環境下你可能會發現,整個程序的某些方面(如密碼或程序本身)位于或正依賴于主站點的一些系統。
因此,最好的辦法是將生產環境停運,然后進行測試,但顯而易見這種做法很難得到企業管理層的支持。所以作為測試者就必須投入更多時間,用以確保測試系統沒有依賴基礎設施或服務。
第二條:加入人為因素
同樣,在測試中加入人為因素也很重要。確保所有系統正常運行是一方面,但人員是否準備充分?他們是否記得自己要做什么?是否知道關鍵的說明文檔位于何處、如何才能訪問?是否能夠察覺出緊急情況,并按你希望的方式給予回應呢?
由于企業想測試的系統大多用來應對突發事件,因此了解員工的響應時間以及他們在缺乏指導的情況下執行測試程序的能力,對企業而言與系統是否可靠同樣重要。
第三條:觀察對監控工具的影響
如果你足夠幸運,被獲準可以進行停運生產系統的測試,那么對于監控和警報工具的評估將非常重要,通過測試你可以了解到,它們提供的數據是否足以引導員工進行正確的處理,企業對此還需要進行哪些調整,以便更快速、輕松地發現并查明重大事故。
經驗表明,調動工作人員、確定問題、決定如何應對這一系列舉措所耗費的時間通常比系統恢復需要的時間多很多。而監控和警報工具的質量在整個過程的診斷環節中將起到重大作用。
第四條:使用說明文檔
在進行測試時,要確保企業編制的說明文檔(無論是文本文檔還是圖表),能夠引導相關人員完成整個過程。一般情況下,災難恢復方案等說明文檔只編制一次,經由審查人員過目,而實際需要依賴該文檔的人員卻很少認真查看。如果你不是在一個非常簡單的操作環境,就應該定期維護說明文檔,并確保內容最新且準確,因為在發生事故時,人們往往首先去查看說明文檔,因此確保它的準確性相對重要。
第五條:讓非測試主管人員參與進來
即使你非常清楚測試的系統而不需要說明文檔,也要設想這種情形:你分身無術,抽不開身,于是不太熟悉這些系統的人需要執行測試過程。對這些人來說,精心編制的說明文檔至關重要。因此,讓原本不負責相關系統的團隊成員進行測試大有必要。這樣一來,你不僅可以測試系統,還可以測試說明文檔以及團隊成員,看看他們是否為緊急情況下接過同事的任務作好了充分準備。
第六條:吸取經驗教訓
測試方案最重要的部分是測試完成后有哪些改進和提升。若是發現了系統、說明文檔或團隊的不足之處,就要確保他們在相關方面汲取了經驗教訓,這一點非常重要。如果測試順利完成,則皆大歡喜,但多數情況下,往往是系統的某些部分需要修復、新的團隊成員需要加強培訓、說明文檔需要更新等等。
第七條:重復整個流程
在完成整個測試過程,發現并修復可能存在問題的薄弱環節后,企業還需要重新測試一遍,即使你的測試沒有發現任何問題。對企業而言,測試修復后的系統很重要,它能夠幫助我們了解企業是否真正解決了問題。