譯者 | 陳峻  

策劃 | 云昭

近年來，云遷移（Cloud migration）這個術語頻頻出現在大多數企業的IT話題中。最初，該術語僅代表了將服務從本地基礎架構的服務器上，遷移到AWS EC2之類的云基礎架構上的相關實踐。如今，云遷移的概念已拓展為：包括遷移到托管數據庫、API網關以及可能需要AWS、或Azure來處理某些負載上。當然，如果貴企業屬于金融或公共事業部門的話，則需要遷移到私有云、或是滿足特殊監管要求的公有云。

下面，我將從改進企業文化、實施智能變更以及可觀測性與監控三個方面，和大家討論企業進行云遷移的各項優秀實踐與原則。通過將這些指導原則應用于企業的云遷移工作中，可以幫助大家避免出現目的不清或低效的窘境，從而能夠有組織地通過工具，來穩健地完成遷移工作。

在深入探討優秀實踐之前，讓我們首先談談在云遷移過程中，通常會被用到的不同方法。

云遷移方法之5個R

由于云端環境存在著多樣性、業務需求的復雜性以及行業細分領域的差別性，因此目前尚沒有一種放之四海皆準的云遷移指導方案。不過，傳統企業往往可以借鑒并采取如下5個R中的一種方法，去實踐：

• Rehost（重新托管）：這是一種傳統的搬家式（lift-and-shift）遷移方法。例如，應用程序原本在本地的VM（虛擬機）中運行，現在你需要將它重新部署到云服務環境中運行的VM上。
• Refactor（重構）：它與rehost類似，不同之處在于多了一個諸如：搬起、調整和遷移的中點步驟（midpoint step）。
• Revise（修訂）：這是rehost和refactor的結合。它通常包括重大的應用更改，以更好地利用目標云環境的各項功能。
• Rebuild（重建）：它比Revise方法更進一步，在某些情況下，可能需要通過完全重建應用，以更好地利用云環境的各項功能。
• Replace（替換）：通過這種方法，企業會刪除掉了本地維護的某項功能，并使用第三方措施予以替代。

現在，讓我們把這些方法運用到云端服務的場景中：

• Rehost：可以將那些運行在本地虛擬機中的應用程序，重新部署到運行在多個云服務中的虛擬機上。
• Refactor：可以通過中點步驟，對每個云服務目標進行調整。
• Revise：通過對應用程序進行重大的更改，以利用每個云服務目標的功能。
• Rebuild：通過完全重建應用程序，以利用多個云服務目標的功能。
• Replace：可以利用多個潛在的第三方云服務選項，來替代本地應用的部分功能。

可見，上面提到的多個云服務、專業化的用例以及各種行業的法規，都會快速增加云端遷移的復雜性。對此，企業應當遵循如下三個關鍵性的實踐原則，來理順和簡化云遷移工作。

1、改進企業文化

有過企業管理經驗的人都知道，最困難卻又是最有價值的實踐之一莫過于企業文化的改進。一般來說，可以從“由誰負責技術資產的哪些部分”開始整理，并在嘗試云端遷移之前，明確如下方面：

（1）確定責任

我們可以將RACI矩陣（請參見下圖）技術運用到給定的組件或域上。在遷移期間，它將能夠清楚地表明誰負有責任（responsible）、誰將提供記錄（accountable）、誰可以提供咨詢（consulted）、誰只需被通知（informed）將發生的各種更改即可。由于云服務加快了服務和產品的轉化速度，因此你的企業與團隊應當適應此類變化，而變化所對應的角色也就顯得非常重要了。

（2）跟蹤指標

文化改進的另一個組成部分是確定關鍵性指標，并將這些指標記錄下來。有人可能會擔心此舉會暴露出運營效率低下等問題。不過，根據短板原理，一旦存在運營的不衡量，就無法提高整體水平。因此，我們有必要在各個層面進行指標的跟蹤。例如：從應用團隊的角度出發，圍繞并跟蹤網絡和存儲延遲的指標。而對于更高的管理級別，我們需要簡潔清楚地定義與說明服務級別目標（service level objectives，SLO）的組成部分，并盡可能讓更多的團隊知曉并遵守此類標準化的復合性SLO。你也許會說，我們何不用服務水平協議（service level agreements，SLA）來強制保證合同的執行呢？其實，相比SLA，SLO更可以幫助你個組織，了解當前應用的性能與可靠性是如何影響到客戶以及整體業務的。

（3）有效地回答任何有關業務的問題

我們可以將編程的思想延伸到業務上，提高現有業務的可觀察性和監控能力。例如，如果團隊成員需要通過復制和粘貼PromQL的查詢，來響應有關某個業務影響的問題，那么你應該將其視為改進的機會。雖然它可能牽扯到廣泛而復雜的方面，但是在大多數情況下，你以通過將數據存儲與靈活的可視化系統相結合，并有選擇地針對不同級別的查詢予以開發，來實現系統的開放性和可觀察性，并最終達到快速、準確地回答業務問題。

2、實施智能化變更

變更管理往往給人的印象是嚴厲而刻板，變更管理委員會通常只會說“不”。而這顯然不是“智能化變更”的體現。

智能變更是一種使用技術門控（technical gating），而不是流程門控的云遷移方法。換句話說，我們需要通過自動化流程來實施保護，其中包括：端到端測試、持續集成以及分布式跟蹤的證明等。而那些技術門控所無法涵蓋的部分（或需要大量工作才能實現的部分）應當被放置到遷移列表的低優先級的位置。

通常，我們需要為更小或更簡單的工作負載創建技術門控，以便為更復雜的、遵循相似流程的其他部分鋪平道路。同時，我們可以通過迭代式地完成每個部分，直至達到足夠的正確性和功能性水平，以實現云端遷移工作的可重復性。

3、可觀測性和監控

如前所述，在遷移之前，提供系統和應用程序的可觀察性（如果它們尚不具備的話），以便在此基礎上開展各項監控工作，對于驗證云端遷移工作的成敗也是至關重要的。例如，根據是否可與數據庫建立連接，你能判斷其是處于啟動還是關閉狀態。而只有當你以查看到利用率指標、查詢用時以及活動連接計數等參數指標時，才算是真正獲取了數據庫的可觀察性。而有了可觀察性，你可以進一步問出如下問題：

我能夠根據監控數據獲得相應的警報嗎？

我的基礎設施可以基于監控進行自我修復嗎？

我需要多長時間才能根據監控數據找到對應系統和應用的問題根源？

從本質上說，可監控性是云端遷移在決策期間的根據。沒有它，云端遷移就會像是在“黑暗球場中投球”一樣。

相應地，我們也需要有一個統一的管理平臺，來追溯遷移團隊所做的每一次更改、部署以及對系統和應用環境所造成的影響。據此，一旦在云遷移期間發生了任何問題，我們都能夠通過其可觀察性和監控，及時發現并按需回滾或處置。

寫在最后  

實際上，業界還有著許多關于輕松實現云端遷移的優秀實踐，并且具體到各個操作細節的相關介紹書籍。不過，上述三個實踐是從源頭上，為你大家供了如何成功開展云端遷移的“誰”、“什么”、“為什么”的思路。當然，常言道“與其坐而論道,不如起而行之”，你我們以謹慎地選用一個成熟的云服務供應商，采用諸如Lightstep之類，針對企業構建的云原生SRE工具，實現遷移過程中的可觀察觀、監控以及事件響應等關鍵性平臺服務。

譯者介紹

陳峻 （Julian Chen），51CTO社區編輯，具有十多年的IT項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗；持續以博文、專題和譯文等形式，分享前沿技術與新知；經常以線上、線下等方式，開展信息安全類培訓與授課。