持續測試企業架構

在成功構建新的 IT 企業架構之後，就應該對該架構進行測試了。測試可以證明您和您的團隊的辛苦工作沒有付之東流。通過對新架構進行壓力測試，您將瞭解架構的弱點在哪裡，以及架構對企業的適應情況如何。

既然已經構建好自己的企業架構，您必須對其進行測試。新技術，尤其是處於前沿的技術，將具有一些需要解決的缺陷。測試資訊科技 (IT) 架構應該面面俱到。測試應該包括硬體、應用程式和負責這些系統的人員。

測試是破壞東西併為之獲得報酬的理想方法。雖然沒有任何人希望自己的 IT 系統被破壞，但它們很可能會遭到破壞。通過測試常見故障，您可以幫助論證附加的冗餘成本的合理性。在整個測試過程中，交流是非常重要的。提醒測試使用者可能發生的問題以及在那些問題發生時應該做什麼，這樣有助於逐漸培養起對專案及其成員的信心。

準備

在準備測試您的架構時，必須首先決定要測試什麼內容。諸如將 CRT 監視器更換為平板顯示器等簡單的變更顯然不需要嚴格的測試。但是新的光纖中樞應該用新的應用程式和硬體進行負載測試。與 IT 團隊會談以決定如何最好地花時間進行測試。

測試具有三個功能：測試使您可以確定新應用程式在生產環境中的執行情況將會如何，驗證冗餘在故障狀態下的工作情況將會如何，以及幫助確定您的團隊成員對問題的反應情況如何。應用程式測試可能是相當簡單但是非常緊張的過程。應用程式可能具有數百個很少使用但是必須測試的功能。例如，會計應用程式具有一些在月末執行的與稅收相關的任務，以及其他僅在年末執行的與稅收相關的任務。最好在稅務人員到來之前讓這些功能可以正常工作。

技能和能力

在測試之前，展望、回顧以及從每個角度檢查整個企業。考慮其優勢和弱點。通過對整個企業的徹底評估，您將瞭解哪些系統需要最全面的測試。如果可能的話，測試應該僅涉及非生產系統。如果測試必須牽涉到生產系統，應該向管理人員說明對測試的需要以及為什麼測試會影響活動的系統，並計劃適當的停機時間。此外，應確保將要測試的任何活動系統存在良好的備份。通過還原到虛擬伺服器並將資料集與活動的單元作比較來驗證備份是否良好。

虛擬環境

通過使用虛擬系統簡化測試環境的建立。虛擬系統很容易建立、破壞和還原。首先建立一個標準伺服器，並克隆該伺服器以建立其他伺服器。在安裝任何應用程式之後，許多虛擬 PC 程式允許您建立當前設定的快照，以便於發生故障後還原。這樣做的好處在於，您可以在數分鐘而不是數小時內建立一個新伺服器。

VMware 提供了用於建立自定義虛擬環境的廣泛選擇。您可以從不需要基礎作業系統的專用虛擬機器（virtual machine，VM）軟體中做出選擇，並且可以一次執行多個伺服器。使用 VMware 的最大優點在於其具有與多個作業系統一起工作的能力、輕鬆的配置以及測試工具。

還可以使用幾種網路模擬器來幫助測試新的配置和評估故障轉移場景。雖然大多數模擬器是為認證測試準備工作而設計的，但是相對於購買實際硬體，模擬器能夠以很低的成本構建虛擬伺服器環境，從而提供極大的好處。

檢查清單和人員準備

在新的企業架構已經為啟動準備就緒的情況下，建立一個核心繫統的檢查清單，並列出那些需要測試的備份系統。從團隊保留的文件中可以明顯看出哪些是核心系統。核心系統將是組織賴以生存而不可或缺的硬體和軟體。通常，此類系統包括關鍵伺服器、網路中樞和諸如電子郵件及語音等訊息部分，如圖 1 所示。

圖 1. 核心系統

此圖沒有顯示完整的網路關係圖中存在的詳細資訊；相反，其旨在突出顯示對業務操作最至關重要的企業部分。

為新系統最可能出現的那些問題準備支援人員和使用者，這樣可以幫助減少幫助臺呼叫。您的團隊成員應該收集他們已經知道的問題（例如應用程式掛起）的列表，並構建已知修復方法的列表。

決定何時可以進行測試是最困難的麻煩事情之一。要在工作日期間尋找一個所有人都可以待命的時間可能相當棘手，因此下班後也許是不錯的時間選擇。但是，您可能會遇到來自不希望在工作上花更多時間的團隊成員或不希望支付加班工資的老闆的抵制。最好的平衡是決定執行測試所需的人員和執行測試的最佳時間。可以向其他團隊成員分配“待命”職責，僅在需要時才讓他們加入。

此時，您已經為新的架構選定了遵從性標準。有些系統具有特定的故障點，必須在投入生產執行之前對這些故障點進行測試。諸如防火牆或安全應用程式元件等專案需要在經過驗證後才能支援實時資料。

構建應該測試的專案以及如何執行該測試的特定檢查清單。附加的檢查清單內容可以包括：

• 測試之前和之後的資料狀況的螢幕截圖。
• 單獨的特定任務清單。
• 按執行任務的小組劃分的檢查清單。構建伺服器硬體的小組可能與載入和配置應用程式的人員不同。

文件過程

測試將會積累文件。測試是將日常工作過程應用於新的 IT 架構。

您至少應該擁有三種型別的文件：歷史記錄、過程 和災難恢復。第一種型別，即歷史記錄文件，應該包括有關架構中的一切是如何構建的詳細資訊。此文件應該包含工作流關係圖和有關各個部分如何連線的說明。隨著架構的發展，次要的細節可能會被遺忘——例如，某個文件可能解釋了工資單軟體連線到倉庫資料庫，因為訂單採集人員的獎金與其資料採集的準確性掛鉤（請參見圖 2）。由於此設定對倉庫資料庫是透明的，倉庫資料庫管理員（database administrator，DBA）在做出更改前必須清楚該連線。

圖 2. 倉庫無線關係圖

過程文件包括每日、每週或每月任務的檢查清單。示例包括每日的磁帶備份更換過程、檢查日誌或報告問題。有些系統可能需要例行的維護才能繼續高效地執行。每日的過程一般分配給負責那些方面的特定人員或小組。擁有任務的詳細步驟不僅有助於確保正確和按時地完成任務，而且還有助於讓那些工作人員暫時替代其他人員。過程應該包括常見錯誤和如何糾正那些錯誤，以及用於向企業引入新硬體和應用程式的標準安裝過程。由於此任務將經歷多個小組的工作，因此您必須擁有特定於每個小組的文件。如圖 3 所示的文件流程圖可幫助列出先決條件和每個小組所負責的任務。

圖 3. 伺服器設定文件流

對於不常見的錯誤，您必須擁有災難恢復文件。這個專門的文件是歷史記錄文件和每日過程的組合。雖然您無法為每個災難做計劃，但是許多恢復過程是重疊的。用於諸如啟動伺服器等簡單任務的文件過程起初好像微不足道，但是在測試災難場景時卻可能是信心的來源。當意外發生時，支援人員很快變得驚慌失措的情況並不鮮見。隨著有關某個停止響應的基於伺服器的應用程式的呼叫湧入，幫助臺的壓力開始上升。包括常識性細節的良好文件將會有所幫助，因為負責解決問題的人員可能忘了伺服器重啟會影響其他系統。

針對災難的文件過程還應該包括在災難開始時和災難得到解決時應該通知誰。此類工作人員可以包括值班經理、部門主管，甚至包括公司的主要領導。

有關災難恢復準備工作的資料已有很多。請參見參考資料以獲得指向更多資訊的連結。

稽核

文件是任何企業的一個有生命和不斷髮展的實體。隨著 IT 結構的增長和變更，文件和測試過程也必須增長和變更。當文件變更時，您必須測試文件以確保其仍然是準確的。

假設在一年以後，您的公司升級了電子郵件軟體。與以前的版本相比，這個新軟體具有稍微不同的郵箱還原方法。如果沒有在災難恢復文件中更新這些變更，則會減緩工程師執行恢復的過程。這不僅導致工程師不愉快，而且等待電子郵件伺服器的人員還可能對還原功能所花的時間長度非常不滿。

通過計劃安排全年中定期的架構元件測試，您可以更新和改進已經建立的文件。這些定期測試還可以培養支援人員的信心。因此，即使某個事故沒有成規可循（並且大多數事故都沒有成規可循），團隊成員也擁有從測試中獲得的經驗，從而在壓力下做出更好的決策。

稽核您的測試結果會對整個企業的信心產生很大的影響。大多數測試僅由高階管理人員檢視，這些人員可能就是控制資金的相同人員。通常，他們不是技術人員，因此對測試和結果的解釋是非常有用的。

使用諸如 IBM® Rational® 等變更管理軟體來跟蹤應用程式變更可以對應用程式測試進行管理。諸如 Numara Track-It （參見 參考資料） 等幫助臺應用程式可以生成報告，以評估何處正在出現新問題。此資訊可用於建立更符合企業需要的測試。您可以建立測試來驗證問題修復是永久性的，並且同樣的問題不會重現。

不要擔心產生負面結果的測試。在測試時，失敗是一件好事情，因為失敗發生在受控的環境中，而不是發生在生產過程中。利用失敗作為學習機會。系統為什麼會失敗？該失敗是否可以避免？是否存在可防止生產中發生失敗的方法？此外，不要嘗試在稽核報告中隱藏失敗情況。利用這些失敗來強調來自於這些失敗的成功。指出為什麼沒有在開發中預見到問題，或者團隊在問題出現時的反應情況如何。

遵從性

可能需要測試及其結果來滿足對某些標準的遵從性義務，例如 Sarbanes-Oxley (SOX) 法案、Payment Card Industry (PCI) 或 Health Insurance Portability and Accountability Act (HIPAA)。這其中有些標準設定了必須保留測試結果的時間長度。取決於組織與其客戶的關係，可能會對這其中一些測試結果進行共享。

您可能會疑惑，為什麼要在此階段為遵從性而費心呢？當您執行測試時，您是在測試遵從性標準。遵從性的目標不應該是達到 最低要求，而是超過 最低要求。

由第三方執行遵從性測試和稽核可能比內部執行這些任務更有益。第三方將產生有關如何看待稽核和遵從性的更中肯的觀點。稽核可在外部或在內部執行。外部測試一般是最容易的，因為大多數稽核企業都可以從他們所在的位置執行測試，並且只需很少的設定。測試某些功能或事件的內部遵從性稽核可能相當麻煩。第三方將需要了解 IT 狀況，並且需要知道必須測試哪些元件。

使用信譽卓著的稽核企業將會在共享結果時擁有更好的名望。諸如 Solutionary 或 Ambiron Trustwave 等公司（參見 參考資料）專業從事特定行業和遵從性的稽核和測試。這些企業是用於確定您的特定行業需要哪些標準和測試的理想資訊源。

工具和技術

由於沒有任何兩個架構是以同樣的方式構建的，所以測試技術也不會是相同的。建立關鍵元件的測試指標需要花一些時間，因此應該與您的團隊協商。一個很好的起點是使用 The Open Group （參見 參考資料）釋出的 IT 架構指導原則。類似地，Tetworks （參見 參考資料） 推出了一個可測試應用程式的開放原始碼工具箱。

有些測試可能需要特殊的考慮事項。如果電源發生故障，不間斷電源（uninterruptible power supply，UPS）將接管電源。但是如何開發準確的測試呢？通常，答案是按製造商的說明行事。在此情況下，許多 UPS 都具有自測功能，此功能不會危害插入 UPS 的裝置。

有些測試可能不像檢查各個單獨的元件那樣簡單。在不實際中斷工作的情況下，您如何驗證將生產流量切換到備份資料中心是否成功呢？通過仔細的規劃和清楚的交流，您可以實現這樣的測試，儘管該測試可能要在數小時以後才能完成。

另一個注意事項是測試將要花的時間長度。執行每個測試將要花多少時間？測試將在活動的系統上進行，還是在虛擬系統上通過資料還原來進行？如果測試是在活動的系統上進行的，應該計劃相應的時間以修復測試可能導致的任何破壞，例如路由器或硬碟故障。有多個工具可用於幫助您的測試。有關詳細資訊，請參閱 參考資料。

里程碑

使用以下里程碑來設定目標並保持您的 IT 企業專案不斷向前推進：

• 設定目標：列出需要測試的內容和測試頻率。設定要完成文件的最終期限；否則，文件可能無法完成。尤其是在測試發現過程中的錯誤之後，要確保更新文件。
• 管理：在整個過程中對測試進行管理。確保測試是按照既定的標準進行的，並與團隊成員一起檢查測試結果。
• 交流：與團隊和管理人員進行有關為什麼測試非常重要的交流。測試經常由於其他專案而獲得很低的優先順序，或者經常匆忙地投入生產應用。
• 維護資源： 評估團隊成員擁有的技能集，並讓他們測試各自專長的領域。最好還要對測試以及正常操作中涉及的其他人員進行交叉培訓。這樣做可以為團隊成員提供在受控情形下對故障狀態作出反應的機會。確保將測試新增到您的預算中。這可能意味著需要用於模擬器軟體、測試裝置的預算，如果需要在下班後測試生產裝置，則還可能包括加班工資。預算成本還可能包括對工作人員的專業培訓——如果他們需要有關不熟悉的作業系統或應用程式的速成培訓的話。
• 確定是否需要外部服務：讓外部團體執行稽核也許是有意義的。專業的稽核團體可以全面查詢所有資源並提出正確的問題。如果當前沒有適當的工具來執行詳細的評估，則外部服務會尤為有用。
• 分配角色：現在工作已經展開。向各個團隊成員分配最適合他們的任務，並讓他們自由發揮。
• 維護文件：如果在開始本步驟之前還沒有開始建立文件，現在應該開始了。收集操作規程、程式碼更改和幫助臺規程。現在可能是讓團隊成員對他們實際所做的工作而不是僱傭他們來做的工作進行文件記錄的理想時機。

總結

使測試成為新架構的過程中的一項關鍵職能。良好的測試基礎可以將新系統的功能和新系統背後的冗餘集合在一起。測試您的新企業架構可以說明您和您的 IT 企業團隊成員構建該架構所做的艱苦工作和貢獻。

記住，測試中產生的失敗是好事情。從失敗中學習以加強您的團隊的技能，並建立新測試以確定錯誤是否會再次出現。測試是對企業團隊的作戰訓練。在整個測試階段中，交流非常重要。讓您的團隊之外的成員隨時瞭解何時將會進行測試。並非所有測試都將在正常工作時間中進行，因此要預先為測試時間甚至專用的測試裝置做好計劃和預算。密切記錄架構變更，並構建測試過程來跟蹤那些變更。

關於作者

  Michael Welsh 是一位擁有 15 年經驗的 IT 專業人員，擅長於 IT 安全性、災難恢復和網路方面的工作。他還擁有作業系統、硬體和諸如 Microsoft Exchange Server 等許多伺服器端應用程式方面的淵博知識。Michael 為網站和企業撰寫技術文章和文件。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14751907/viewspace-416157/，如需轉載，請註明出處，否則將追究法律責任。