來源:互聯網
上載者:User
關鍵字
應用程式
供應商
確保
如何在
服務供應商
儘管遷移到一個託管的資料中心設施有著諸多的原因和好處,但這一過程仍然是充滿了各種風險。 以前,當我們需要結束一段與資料中心或雲服務提供者的失敗的合作關係或者服務提供者本身出現故障的時候,我們需要一套「B計畫」。
我們的建議是,IT管理人員應確保他們所在的企業和雲服務提供者之間的合同內要規定好資料的擁有權是屬於企業的。 然而,這只是問題的一部分,我們依然存在如何在事後處理資料的問題。
最終的回應是「這取決於具體的問題具體分析」。 第一個問題是圍繞應用程式創建的資料:你可以在其他地方仍然獲得相同應用程式的存取權限嗎?
如果現有的協定是基礎設施即服務(IaaS)或者平臺即服務(PaaS),那麼你的企業將無論如何必須擁有自己的應用程式,所以,在不同的雲平臺都安裝這樣的應用程式不應該屬於過度安裝的問題。
在雲中移動資料的困難
然而,在軟體即服務(SaaS)的情況下,有可能存在更大的問題。 如果所提供的服務是基於一個標準的應用程式。 例如,SugarCRM或OpenERP,您有可能需要找到另一家服務提供者託管同款應用程式。 在執行方面可能會有所不同,但所需要的應該只是一種提取/轉換/載入(ETL)的行動,以確保資料適合新的服務提供者架構的實施到位。
IT管理人員應該記住,他們之前的服務供應商對於應用程式所作出的任何修改(如撕掉logo標籤或增加任何額外的功能與應用),新的供應商對於這些修改都將需要再次進行。
在許多情況下,從以前的服務提供者那裡獲取任何詳細的變化清單都是不太可能的,所以重新部署這些將是過渡過程中最困難的部分。 這就意味著之前的服務供應商所進行的任何更改,即使是在SaaS環境中的更改,您都必須將其記錄下來並存儲在SaaS環境以外。 有一套完整的服務供應商變更日誌是相當必要的,這樣,如果您的企業在更換服務供應商時,就可以重新進行部署。
真正的問題是當一家企業正在從某傢俱有專有軟體供應商處進行遷移的時候。 這可能是供應商對一款開源的應用程式進行的某些重大的修改,使之從根本上成為了一款新的應用程式。 或者,它可能是一家SaaS供應商所擁有的應用程式,但不允許被任何其他雲供應商在自己的平臺上運行,如Salesforce.com。
然而,儘管Salesforce.com不可能很快遭遇滑鐵盧,但一些較小的專用SaaS供應商是註定要失敗的。
Quocirca建議,您的企業在選擇SaaS供應商之初,需要考慮相關的風險。 如果你的企業還沒有準備好採用軟體作為一種服務,那麼您應該確保對您所選擇的供應商倒閉的風險進行評估,而如果需要從服務提供者處提取系統資料,並需要其在很短的一段時間內以某種另一系統可用的形式,您將需要什麼樣的努力。
SaaS的資料恢復規劃
那些已經將資料轉移到SaaS供應商的企業應該確保有一套B計畫能夠知道在何處獲得一個已知的復原點目標(RPO)和一個已知的恢復時間目標(RTO)。
首先需要確定的是目標應用程式是什麼。 Quocirca建議,這應該是在SaaS供應商中被廣泛採用的一款應用程式,或者應用程式是來自于一家非常大的,並具備很多專有的經濟安全實力的SaaS供應商。
其次需要確定的是兩個系統所使用的系統架構。 匹配欄位名稱和類型是有必要的,以便確保資料移轉過程中的資訊保真。 這也將定義將要進行的提取/轉換/載入活動。
然後,有必要進行測試。 對上述活動能夠正常運作不能僅僅只是停留在假設或期望的階段。 你需要對其進行測試,將資料從現有的環境移動到新的環境。 這不一定必須是遷移到第二家服務供應商處,而只是進行測試,以確保其奏效。
基於成功的測試,你可以創建一個完整的,正式的計畫以便您的企業在最糟糕的情況發生時進行應對。 這同時也應包括啟動該活動計劃需要多長時間,以及在這段停機的時間內,企業的業務將如何繼續在運轉。 這可能會涉及到一些手動過程,在這些手工過程中所收集的任何資料將需要輸入到新的系統。
最後,應當確保在合同中規定的是舊的服務提供者必須從其系統上清除您企業的資料資料,這一點往往被忽視。
(責任編輯:fumingli)