實戰：從Unix遷移到Linux
從Unix向Linux遷移所要做的第一個步驟就是準備好一個測試環境。你的團隊可能缺乏Linux的相關經驗，有一個測試環境用來學習是非常必要的（不用擔心誤操作破壞任何東西）。
讓我們來討論以下代碼和程序。你的系統運行JAVA還是C語言？是否存在什么第三方的工具需要遷移？它們是否能遷移到Linux上？
假設你用的是C語言。再假設你有一些代碼需要遷移到LINUX系統上去。建議使用GNU（gcc）程序，因為它符合工業標準，是Linux下天生的編譯器。用其它平臺編譯的程序將需要重新編譯一次。
關于編譯你的業務代碼有兩種方法可供選擇。第一個方法是在你已有的環境中進行編譯，這種情況下你要準備好所有需要的工具，包括源代碼和編譯好的文件。如果你考慮這種方法的話，務必在你的測試環境中進行，千萬不要在生產環境里做。
另一個方法是將你的所有數據和代碼都移動到新環境里，然后用原型環境來運行進行測試。這種情況需要考慮硬件平臺。如果你計劃遷移硬件平臺，也許有些和硬件相關的代碼會有麻煩，最糟糕的例子可能會迫使你重寫代碼。
在遷移過程中，務必確認你的開發人員也參與其中，并且不要假設任何事情。充分考慮包括API，系統呼叫，streams和庫支持等方面因素。確保你完全明白你的目標。這些因素是你在實施之前做評估以及確認所有和應用相關的庫和依存關系的關鍵所在。用這種方法可以讓你迅速確認在新的LINUX環境下哪些產品是可用的以及在哪能找到它們。
毫無疑問的，用JAVA編寫的程序相對用C寫的程序來說，遷移起來要快速一些。除了你的應用程序之外，你還需要確認測試環境，用戶界面需求，平臺依賴限制，中間件和內部的技術水平。每一個方面都存在一些風險。
升級應用
升級過程中最重要的部分就是應用程序了。在一些案例中，應用被很容易地遷移到新系統中，也沒有額外的工作需要做。而在另一些案例中，你不得不在你的新平臺中重編譯它們。遷移軟件有時在重編譯完程序之后就完成了，然后就是運行驗證測試來確保一切都沒有問題。
遷移過程應當包含開發和測試。當你遷移你的系統時，請首先確認你遷移數據庫所要采用的方法。那些需要內核擴展和驅動程序的應用不太容易實施，部分原因是大部分內核API都不是按嚴格標準來設計的。
應用是否采用了第三方的軟件組件，比如數據庫工具，應用服務或者其它中間件？這些會增加遷移的復雜性。應用是32位的還是64位的？如果你要將32位平臺遷移至64位，你將花費更多的時間來實施。你的應用如何和數據庫通訊？它使用如ODBC的數據庫交互界面或者如C++之類的編程語言嗎？這些因素你都應該充分考慮。站在一個員工的立場，盡量讓有這方面項目經驗的人來實施會比較穩妥。
檢驗穩定性和性能
應用問題一般在運行的頭幾個星期就會被發現，工程師在這個時段會對即將面對的問題有個模糊的概念。這時你也許會想再重新復核一些項目計劃來調整交付日期。
測試對驗證穩定性非常重要，包括功能和性能。不要花費了200萬美元開發一個新系統之后只愿意再花兩千美元用來測試。測試的順序一般如下：
- 負責遷移的工程師進行應用的模塊測試。
- 應用工程師進行功能測試。
- 然后是用戶驗收測試，或者簡稱UAT。這時有真實的系統用戶來進行的測試。
- 性能功能是進行性能測試。
- 在測試過程中，本質上遷移的應用是在壓力環境下進行測試，這樣以確保系統能處理相應的負載。你應該完成基本測試，它們都是在你現有的生產環境下進行以獲取性能快照。
- 你的目標是以穩定性和性能為導向進行的相似的測試。嘗試攻擊你的系統。利用一些如惠普的loadrunner等的工具來模擬5倍于常用操作產生的系統負載。
- 接下來是找出漏洞－在遷移到生產環境之前就要做。你應該在它們遷移到生產環境之前抓住機會調試程序從而找出問題所在。利用測試過程，另外不要只是讓你的系統管理員們來驗證系統。公司里業務部門的用戶不僅應該參與進來，而且應該加入用戶驗收測試計劃的編寫。就算你的系統在舊環境中非常穩定，也仍然要確認它們被充分測試。
【編輯推薦】
