大數(shù)據(jù)遷移的五大陷阱和風險

計算機系統(tǒng)之間的數(shù)據(jù)傳輸或存儲格式從來就不是一個輕松的任務，特別是當它涉及結構化和非結構化的數(shù)據(jù)。
    "復雜的數(shù)據(jù)遷移工作意味著超負荷運行和延遲都是很長常見的"，Arvind Singh（以下簡稱辛格），芝加哥一家企業(yè)的數(shù)據(jù)解決方案提供商的聯(lián)合創(chuàng)始人兼CEO表達了以上觀點。
    在《信息周刊》的一次電話采訪中，Arvind Singh概述了10個常見的數(shù)據(jù)遷移問題，其中包括五個陷阱和五個風險，以此警告企業(yè)應該竭力避免。
   大數(shù)據(jù)遷移的五大陷阱
    陷阱#1：未能吸引業(yè)務線和業(yè)務用戶開始。
    當公司合并多個系統(tǒng)整合到一個--通常發(fā)生在兼并后--他們需要從確定正確的商業(yè)用途開始。
    你需要確定誰知道和理解業(yè)務數(shù)據(jù)，"辛格說。
    "誰是你業(yè)務的專家？這當然不是IT或系統(tǒng)集成商。"
    換句話說，把那些數(shù)據(jù)使用精英搬進遷移項目。
    畢竟，只有他們才能將那些操作系統(tǒng)玩轉一旦上線。
    陷阱#2：沒有數(shù)據(jù)管理策略和組織結構。
    "你已經將系統(tǒng)A的數(shù)據(jù)移動到系統(tǒng)B，但誰擁有管理結構？誰有權利在系統(tǒng)中創(chuàng)建、批準、編輯或刪除數(shù)據(jù)？"辛格問。
    還有一些問題必須解決：你設置了數(shù)據(jù)管理了嗎？有一個業(yè)務流程來管理數(shù)據(jù)周期嗎？另外，你有數(shù)據(jù)管理員在公司嗎？

陷阱#3：在原始系統(tǒng)數(shù)據(jù)質量差。
    公司經常意識不到一個"原有評估"是至關重要的數(shù)據(jù)遷移工作鋪墊。
    "了解原始系統(tǒng)里的數(shù)據(jù)的質量是一個巨大的陷阱，但企業(yè)常常不愿意花足夠的時間，"辛格說。
    必須要考慮的問題：現(xiàn)有的數(shù)據(jù)支持新用戶嗎？它缺少什么？你打算怎么做，你現(xiàn)在不能夠做什么？
    一個詳細的評估讓企業(yè)能夠更容易地估計需要的工作量來成功地遷移原始數(shù)據(jù)。
    陷阱#4：忽略驗證和定義業(yè)務規(guī)則。
    你公司的業(yè)務和驗證規(guī)則可能不是最新的。
    "難以讓人相信一個公司在達成業(yè)務規(guī)則時花了多短的時間，更不用說確保數(shù)據(jù)符合業(yè)務規(guī)則，"辛格說。
    "換句話說，你認為你有一個業(yè)務規(guī)則，但是你的現(xiàn)有數(shù)據(jù)是否匹配，細致，或遵循這個規(guī)定？"
    此外，審計人員需要確保數(shù)據(jù)從原始系統(tǒng)到新的系統(tǒng)是有效的，特別是當這個遷移涉及關鍵信息，如金融、庫存、和就業(yè)數(shù)據(jù)。
    陷阱#5：未能驗證和測試數(shù)據(jù)遷移過程。
    不要以為這是最后一步了。
    你絕對絕對要確保在整個過程中你一直在驗證和測試，"辛格說。
    必須要考慮的問題：你打算怎樣測試數(shù)據(jù)？誰將測試和評估？ 誰將簽署它嗎？以及誰將是數(shù)據(jù)的最終消費者？
    “這一過程必須貫穿項目的始終，但不幸的是公司通常"不花足夠的時間校準數(shù)據(jù)的測試和驗證”辛格說。

大數(shù)據(jù)遷移的五大風險
   風險#1：被委托進行數(shù)據(jù)遷移項目的員工缺乏實戰(zhàn)經驗。
    一個公司的員工可能非常擅長他們所做的事，但這并不意味著他們是在數(shù)據(jù)管理、遷移和治理是專家。
    "他們是數(shù)據(jù)的創(chuàng)作者和消費者，但是他們并不是完全熟練運用工具、過程、服務、模板和加速器，"辛格說。
   風險#2：你的團隊太依賴工具的開發(fā)工作。
    這個問題往往是導致缺乏經驗的員工。一個數(shù)據(jù)遷移項目通常是IT部門的事，但可能并沒被專業(yè)訓練過。遷移工具使用不當最終會遷移了錯誤數(shù)據(jù)。"這是類似于把垃圾傳來傳去，"辛格說。
    你的目標，當然是快速、可靠地傳輸數(shù)據(jù)。重要的是你如何運用數(shù)據(jù)遷移工具，和"你搭配的有什么樣的加速器和模板，"辛格說。
   風險#3：交叉對象依賴性。
    "我無法告訴你我有多少次坐在會議上，（客戶）說，"我們剛剛發(fā)現(xiàn)了一個全新的資料來源，我們甚至都不知道自己需要移動的'，"辛格說。
    交叉對象依賴常常很晚才被發(fā)現(xiàn)。一個復雜的項目可能會有60、70、甚至80個不同的數(shù)據(jù)對象中來自一百個左右的應用程序。
    "當我們與客戶談生意時，我們尋找丟失的數(shù)據(jù)塊，或者相關數(shù)據(jù)，"辛格說。
    事實上，交叉對象依賴性--并在后來發(fā)現(xiàn)新的數(shù)據(jù)來源的過程--是主要的風險，可以打亂你的遷移的時間表。
   風險#4：試圖在一個大的上傳之后去上線。
    這是一個災難，辛格說，因為你在假設一切都是完美的，你將能夠簡單地點擊一個按鈕，和所有的數(shù)據(jù)將負載得完美無瑕。 "這是個很大的風險，"他說。"你需要一個項目時間軸，復雜的，長期的測試負載的道路。"
   風險#5：預算超支由于不適當?shù)姆秶驕蕚涔ぷ鞯那啡薄?br />     這經常發(fā)生在，當一個組織認為它的系統(tǒng)集成商（SI）會照顧到這些細節(jié)。
    "大多數(shù)系統(tǒng)集成商通常不處理數(shù)據(jù)只是說，'我將連接管道使原始數(shù)據(jù)移動到一個目標系統(tǒng)'，"辛格說。
    "在現(xiàn)實階段，我們可以調用到數(shù)據(jù)遷移項目，"他說，"人們說：'看，數(shù)據(jù)沒有捆綁在一起，我們無法進行用戶測試。'"
    這個問題，當然，會導致成本超支和毀壞的時間表。
    如今IT 面臨的最大挑戰(zhàn)之一，是風險評估。風險的度量和影響評估不是一門確切的科學，而是有工具、過程和原理，可用于確保組織很好地被保護，高級管理層消息靈通。在我們的Measuring Risk： A Security Pro's Guide測量風險中：一個安全專業(yè)人員的指導報告中，我們推薦工具來評估安全風險和提供一些想法供有效地將結果數(shù)據(jù)投入到業(yè)務中去。