揭開大型主機的接縫，以進行逐步現代化

背景脈絡

主機架構承載了各種對客戶業務營運至關重要的服務。我們的計畫特別專注於為英國和愛爾蘭的消費者洞察而設計的資料平台。主機架構上的這個特定子系統包含大約 700 萬行程式碼，歷經 40 年開發而成。它提供了英國和愛爾蘭產業大約 50% 的功能，但從執行時間的角度來看，佔用了大約 80% 的 MIPS（每秒百萬條指令）。該系統非常複雜，而複雜性進一步加劇，這是因為網域責任和疑慮分散在舊有環境的多個層級中。

客戶決定放棄主機架構環境有幾個原因，如下所述

1. 系統變更緩慢且昂貴。因此，企業難以跟上快速變化的市場，阻礙了創新。
2. 執行主機架構系統相關的營運成本很高；客戶面臨著核心軟體供應商即將調漲價格的商業風險。
3. 雖然我們的客戶具備執行主機架構所需的技能組，但已證明很難找到具有此技術堆疊專業知識的新專業人士，因為此網域中的熟練工程師人數有限。此外，就業市場並未提供許多主機架構的機會，因此人們沒有誘因去學習如何開發和操作它們。

消費者子系統的高階檢視

下圖從高層級的角度顯示消費者子系統中的各種元件和參與者。

大型主機支援兩種不同的工作負載類型：批次處理，以及針對產品 API 層的線上交易。批次工作負載類似於一般所謂的資料管線。它們涉及從外部提供者/來源或其他內部大型主機系統擷取半結構化資料，然後進行資料清理和建模，以符合消費者子系統的要求。這些管線包含各種複雜性，包括身分搜尋邏輯的實作：在英國，與擁有社會安全號碼的美國不同，沒有居民的通用唯一識別碼。因此，在英國和愛爾蘭營運的公司必須採用自訂演算法，才能準確地判斷與該資料相關的個人身分。

線上工作負載也呈現出顯著的複雜性。API 要求的協調是由多個內部開發的架構管理，這些架構透過在資料儲存庫中查詢來決定程式執行流程，同時透過分析程式碼的輸出處理條件分支。我們不應忽視此架構為每個客戶套用的自訂化程度。例如，某些流程會透過特別設定進行協調，以因應實作細節或與我們客戶線上產品互動的系統的特定需求。這些設定最初是例外的，但隨著我們的客戶擴充其線上服務，它們可能會隨著時間推移而變成常態。
這是透過資格引擎實作的，該引擎跨層運作，以確保存取產品和基礎資料的客戶經過驗證和授權，可以擷取原始或彙總資料，然後透過 API 回應公開給他們。

逐步淘汰舊系統：原則、優點和考量

考量到消費者子系統的範圍、風險和複雜性，我們相信以下原則將與我們成功執行此計畫緊密連結

• 早期風險降低：從一開始就開始工程，實作「快速失敗」方法將有助於我們及早找出潛在的陷阱和不確定性，從而防止計畫交付的延誤。這些是
• 結果相等性：客戶強調在既有舊系統和新系統之間維持結果相等性的重要性（請注意，這個概念與功能相等性不同）。在客戶的舊系統中，會為每個消費者產生各種屬性，而且由於嚴格的產業法規，維持連續性對於確保合約遵循至關重要。我們需要在早期主動找出資料中的差異，立即處理或說明差異，並在早期建立與客戶及其各自客戶的信任和信心。
• 跨功能需求：大型主機是一種效能極高的機器，而雲端上的解決方案是否能滿足跨功能需求，則存在不確定性。
• 提早提供價值：與客戶合作可確保我們能找出我們可以提早提供的最關鍵業務功能子集，確保我們能將系統分解成較小的增量。這些增量代表整體系統的薄層。我們的目標是反覆且頻繁地建立在這些薄層上，協助我們加速在領域中的整體學習。此外，透過薄層作業有助於減少團隊所需的認知負擔，進而防止分析癱瘓並確保持續提供價值。為了達成此目標，一個建構於大型主機周圍的平台，可提供對客戶遷移策略的更好控制，扮演了至關重要的角色。使用暗黑啟動和金絲雀釋出等模式將使我們能順利過渡到雲端。我們的目標是達成無聲的遷移程序，讓客戶能在系統之間無縫過渡，而不會造成任何明顯影響。這只能透過全面的比較測試和持續監控兩個系統的輸出才能達成。

考量上述原則和需求，我們選擇了增量式舊系統取代方法，並結合雙重執行。實際上，對於我們在雲端重建的每個系統薄層，我們計畫提供相同輸入給新系統和現有系統，並平行執行它們。這讓我們可以擷取兩個系統的輸出，並檢查它們是否相同，或至少在可接受的容許範圍內。在此脈絡中，我們定義增量式雙重執行為：使用過渡架構來支援將功能逐薄層地從舊有環境中取代，進而讓目標系統和現有系統能暫時平行執行並提供價值。

我們決定採用此架構模式，以在提供價值、及早發現和管理風險、確保結果均等以及在整個計畫期間為我們的客戶維持順利轉型之間取得平衡。

逐步淘汰舊系統的方法

為了完成將功能卸載到我們的目標架構，團隊與大型主機中小型企業 (主題專家) 和我們客戶的工程師密切合作。此協作促進了對現有現狀環境的充分了解，無論是在技術還是業務功能方面；它幫助我們設計了一個過渡架構，以將現有大型主機連接到雲端系統，後者是由計畫中的其他交付工作流程開發的。

我們的做法始於將消費者子系統分解為具體的業務和技術領域，包括資料載入、資料擷取和彙總，以及可透過面向外部的 API 存取的產品層級。
由於我們客戶的業務目的，我們很早就意識到我們可以利用一個主要的技術界線來組織我們的計畫。客戶的工作負載在很大程度上是分析性的，主要處理外部資料以產生洞察力，然後將其銷售給客戶。因此，我們看到了一個將我們的轉型計畫分成兩部分的機會，一部分圍繞資料策展，另一部分圍繞資料服務和產品用例，使用 資料互動作為一個界線。這是識別出的第一個高層級界線。
接著，我們需要進一步將計畫分解成更小的增量。
在資料策展方面，我們發現資料集在很大程度上彼此獨立地管理；也就是說，儘管存在上游和下游依賴關係，在策展過程中沒有資料集的糾纏，即輸入資料集與其輸入檔案有一對一的對應。。
然後，我們與中小企業密切合作，以找出技術實施中的接縫（如下所述），以規劃如何為任何給定的資料集提供雲端遷移，最終達到可以按任何順序傳遞的層級（資料庫寫入器處理管線接縫、粗略接縫：批次管線步驟移交作為接縫，以及最細緻：資料特性接縫）。只要上游和下游依賴關係可以從新的雲端系統交換資料，這些工作負載就可以獨立於彼此進行現代化。
在服務和產品方面，我們發現任何給定的產品都使用了我們的客戶所建立的 80% 的功能和資料集。我們需要找到不同的方法。在調查向客戶銷售存取權的方式後，我們發現我們可以採用「客戶區隔」方法來逐步交付工作。這需要找到最初購買較小百分比功能和資料的客戶子集，以減少交付第一個增量的範圍和時間。後續增量將建立在先前工作的基礎上，讓進一步的客戶區隔可以從現有架構轉換到目標架構。這需要使用不同的接縫和過渡架構，我們將在資料庫讀取器和下游處理作為接縫中討論。
實際上，我們對從業務角度來看作為一個整體運作但被建置為可以獨立遷移到雲端的不同元素的元件進行了徹底分析，並將其設定為一系列的循序增量。

接縫

我們的過渡架構主要受到我們可以在主機內部發現的舊有接縫的影響。您可以將它們視為程式碼、程式或模組相遇的交界點。在舊有系統中，它們可能在策略性位置被有意設計，以提高模組化、可擴充性和可維護性。如果是這樣，它們可能會在整個程式碼中脫穎而出，儘管當一個系統已經開發了數十年，這些接縫往往會隱藏在程式碼的複雜性中。接縫特別有價值，因為它們可以被策略性地用來改變應用程式的行為，例如攔截主機內部的資料流，允許將功能卸載到新的系統。

確定技術接縫和有價值的交付增量是一個共生過程；技術領域的可能性提供了我們可用於規劃增量的選項，而這反過來又推動了支援程式所需的中間架構。在此，我們深入探討技術細節，討論我們規劃和設計的解決方案，以針對我們的客戶啟用增量舊有系統取代。重要的是要注意，這些解決方案在我們參與期間不斷改進，因為我們獲得了更多知識；有些甚至已部署到測試環境，而其他則處於尖峰狀態。當我們在其他大型主機現代化程式中採用此方法時，這些方法將根據我們最新的實務經驗進一步改進。

外部介面

我們檢查了主機對資料提供者和我們客戶的客戶公開的外部介面。我們可以在這些整合點上套用事件攔截，以允許外部工作負載轉移到雲端，因此從他們的角度來看，遷移將是無聲的。有兩種介面進入主機：提供者透過檔案傳輸提供資料給我們客戶的檔案傳輸，以及客戶與產品層互動的基於 Web 的 API 組合。

批次輸入作為接縫

我們發現的第一個外部接縫是檔案傳輸服務。
提供者可以透過兩種途徑傳輸包含半結構化格式資料的檔案：與底層檔案傳輸服務互動的檔案上傳的基於 Web 的 GUI（圖形使用者介面），或直接透過 FTP 傳輸檔案到服務以進行程式化存取。

檔案傳輸服務根據每個提供者和檔案，決定主機上應更新哪些資料集。這些資料集會反過來透過在批次作業排程器上設定的資料集觸發器執行相關管線。

假設我們可以在雲端重建每個管線（請注意，稍後我們將深入探討如何將較大的管線分解成可行的區塊），我們的做法是在雲端建立個別管線，並與主機並行執行，以驗證它們是否產生相同的輸出。在我們的案例中，這可透過在檔案傳輸服務上套用額外的設定來實現，該設定將上傳分岔到主機和雲端。我們能夠使用類似的生產檔案傳輸服務，但使用虛擬資料，在測試環境中執行，來測試此方法。

這將允許我們在雲端和大型主機上同時執行每個管道，只要有需要，就能確信沒有差異。最終，我們的做法是對檔案傳輸服務套用額外的設定，防止大型主機資料集進一步更新，因此讓現有管道停用。由於我們沒有完成管道的端到端重建，因此無法自行測試此最後步驟，但我們的技術 SME 熟悉檔案傳輸服務中有效停用大型主機管道的必要設定。

API 存取作為接縫

此外，我們對外部 API 採用類似的策略，找出圍繞著向客戶公開的既有 API Gateway 的縫隙，代表他們進入消費者子系統的入口點。

根據雙重執行，我們設計的方法是將代理伺服器放在 HTTPS 呼叫鏈的頂端，盡可能接近使用者。我們正在尋找可以同時並行執行兩個呼叫串流（現有大型主機和雲端上新建立的 API）並回報其結果的解決方案。

實際上，我們計畫對新的產品層使用 暗黑啟動，透過廣泛且持續監控其輸出，及早對人工製品產生信心。我們沒有優先在第一年建立此代理伺服器；要發揮其價值，我們需要在產品層面重建大部分功能。然而，我們的目的是在 API 層可以執行任何有意義的比較測試時立即建立它，因為此元件在協調暗黑啟動比較測試中扮演關鍵角色。此外，我們的分析強調我們需要留意產品層產生的任何副作用。在我們的案例中，大型主機產生副作用，例如帳單事件。因此，我們需要進行侵入式大型主機程式碼變更，以防止重複並確保客戶不會被重複計費。

類似於批次輸入縫隙，我們可以並行執行這些要求，只要有需要就能執行。不過，最終我們會在代理伺服器層使用 金絲雀釋出，逐一將客戶切換到雲端，因此逐步減少大型主機執行的工作負載。

內部介面

接著，我們對大型主機內的內部元件進行分析，找出可以利用來將更精細的功能移轉到雲端的特定縫隙。

粗略接縫：資料互動作為接縫

主要的重點領域之一是程式間普遍的資料庫存取。在此，我們從找出寫入、讀取或同時對資料庫執行這兩個動作的程式開始我們的分析。將資料庫本身視為縫隙，讓我們可以拆解依賴資料庫作為程式之間連接的流程。

資料庫讀取器

關於資料庫讀取器，為了在雲端環境中啟用新的資料 API 開發，主機系統和雲端系統都需要存取相同的資料。我們分析了我們挑選為第一個客戶區段遷移的第一個候選產品存取的資料庫表格，並與客戶團隊合作提供資料複製解決方案。這會使用資料變更擷取 (CDC) 技術將必要的表格從測試資料庫複製到雲端，以將來源與目標同步化。透過利用 CDC 工具，我們能夠近乎即時地將必要的資料子集複製到雲端上的目標儲存體。此外，複製資料讓我們有機會重新設計其模型，因為我們的客戶現在可以存取不只是關聯式的儲存體（例如，文件儲存體、事件、鍵值和圖形）。存取模式、查詢複雜度和架構彈性等準則有助於決定要將資料的每個子集複製到哪個技術堆疊中。在第一年，我們從 DB2 建立到 Kafka 和 Postgres 的複製串流。

在這個時間點，透過從資料庫讀取程式實作的功能可以逐步重新建置，然後再遷移到雲端。

資料庫寫入器

關於資料庫寫入器，這些寫入器大多是由在主機系統上執行的批次工作負載組成，在仔細分析流入和流出這些寫入器的資料後，我們能夠套用萃取產品線來識別可以獨立執行（作為同一個流程的一部分執行只是我們可以變更的實作細節）的個別網域。

透過使用這些原子單元以及其各自的接縫處，其他工作串流可以開始在雲端上重新建置其中一些管線，並將輸出與主機系統進行比較。

除了建置過渡架構外，我們的團隊還負責提供其他工作串流用來設計其資料管線和產品的一系列服務。在這個特定案例中，我們在主機系統上建置批次工作，透過將檔案放到檔案傳輸服務中以程式化方式執行，這會萃取和格式化這些管線在主機系統上產生的記錄，因此讓我們的同事能夠透過自動化比較測試對其工作進行嚴密的回饋迴路。在確保結果保持相同後，我們對未來的做法是讓其他團隊逐一切換每個子管線。

子管線產生的成品可能需要在大型主機上進行後續處理（例如：線上交易）。因此，當這些管線日後完成並移至雲端時，我們選擇的方法是使用舊系統模擬，並將資料複製回大型主機，只要依賴此資料的功能也會移至雲端即可。為達成此目的，我們考慮使用相同的 CDC 工具將資料複製至雲端。在此情況下，在雲端處理的記錄會儲存在串流上的事件中。讓大型主機直接使用此串流似乎很複雜，無論是在建置或測試系統回歸時，而且需要對舊有程式碼採取更具侵入性的方法。為了降低此風險，我們設計了一個轉換層，將資料轉換回大型主機可以處理的格式，就像這些資料是由大型主機本身產生的。這些轉換函式如果很簡單，可以由您選擇的複製工具支援，但就我們而言，我們假設需要建置自訂軟體與複製工具搭配使用，以滿足雲端的其他需求。這是我們常見的場景，企業會利用從頭重建現有處理程序的機會，來改善這些程序（例如：讓它們更有效率）。

總之，與客戶端的 SME 密切合作，有助於我們挑戰大型主機上現有批次工作負載的實作，並找出具有更明確資料邊界的替代離散管線。請注意，由於我們與 SME 定義的邊界，我們處理的管線並未重疊在相同的記錄上。在後面的章節中，我們將探討我們必須處理的更複雜案例。

粗略接縫：批次管線步驟移交

資料庫可能不是您唯一可以使用的接縫處。就我們而言，我們有資料管線，除了將其輸出結果保留在資料庫中之外，還會提供整理過的資料給下游管線進行後續處理。

對於這些場景，我們首先找出管線之間的交握。這些通常包含保留在平面/VSAM（虛擬儲存體存取方法）檔案中的狀態，或可能是 TSQ（暫時儲存佇列）。以下顯示管線步驟之間的這些交接。

舉例來說，我們正在尋找設計，用於移轉下游管線，讀取上游儲存的整理平面檔案。大型主機上的此下游管線會產生一個 VSAM 檔案，線上交易會查詢此檔案。由於我們計畫在雲端建置此事件驅動管線，因此我們選擇利用 CDC 工具將此資料從大型主機中取出，然後轉換成事件串流，供雲端資料管線使用。與我們之前報告的類似，我們的過渡架構需要使用轉換層（例如：架構轉換）和 CDC 工具，將在雲端產生的成品複製回大型主機。

透過使用我們先前找出這些交握，我們能夠建置並測試此攔截，針對一個範例管線，並使用相同的做法設計雲端上游/下游管線的進一步移轉，利用舊系統模擬回饋大型主機必要的資料，以進行下游處理。除了這些交握之外，我們對大型主機進行了非瑣碎的變更，以允許提取資料並回饋。不過，我們仍然透過在核心重新使用相同的批次工作負載，並在邊緣使用不同的工作觸發器，來將風險降到最低。

細緻接縫：資料特性

在某些情況下，上述關於內部接縫發現和過渡策略的方法並不足夠，因為我們專案發生了這種情況，原因在於我們希望切換工作負載的大小，因此會轉化為更高的業務風險。在我們的其中一個場景中，我們使用離散模組來提供資料載入管道：身分管理。

消費者身分管理是一個複雜的空間，在我們的案例中，它是我們客戶的差異化因素；因此，他們無法負擔從新系統產生的結果，其準確性低於英國和愛爾蘭人口的主機系統。若要成功將整個模組移轉到雲端，我們需要建立數十個身分搜尋規則及其所需的資料庫作業。因此，我們需要進一步將其分解，以保持變更的規模較小，並能頻繁地傳遞以降低風險。

我們與中小企業和工程團隊緊密合作，目的是找出資料和規則中的特徵，並將它們用作接縫，這將使我們能夠逐步將此模組切換到雲端。經過分析，我們將這些規則分為兩個不同的群組：簡單和複雜。
簡單規則可以在兩個系統上執行，前提是它們提供不同的資料區段（即上游的獨立管道），因此它們代表進一步分解身分模組空間的機會。它們代表在檔案擷取期間觸發的大多數（約 70%）。這些規則負責建立現有身分和新資料記錄之間的關聯。
另一方面，複雜規則是由資料記錄觸發的，表示需要變更身分，例如建立、刪除或更新。這些規則需要小心處理，且無法逐步移轉。這是因為對身分的更新可以由多個資料區段觸發，而在兩個系統中並行操作這些規則可能會導致身分漂移和資料品質下降。它們需要一個系統在某個時間點建立身分，因此我們設計了一種大爆炸移轉方法。

在我們最初對主機系統上的身分模組的了解中，擷取資料的管道會觸發 DB2 上的變更，從而產生身分、資料記錄及其關聯的最新檢視。

此外，我們識別出一個離散的身分模組，並改進此模型以反映我們與中小企業發現的系統更深入的了解。此模組提供來自多個資料管道的資料，並將簡單和複雜規則套用至 DB2。

現在，我們可以套用我們前面寫到的相同技術於資料管道，但我們需要對身分管道採取更細緻且逐步的方法。
我們計畫處理可以在兩個系統上執行的簡單規則，但有一個警告，它們在不同的資料區段上執行，因為我們只能有一個系統維護身分資料。我們使用批次管線步驟移交，並套用事件攔截來擷取和分岔資料（暫時，直到我們可以確認在系統移交之間沒有遺失任何資料）來提供給大型主機上的身分管線。這將允許我們對擷取的檔案採取分而治之的方法，在雲端執行平行工作負載，這將執行簡單規則並套用變更到大型主機上的身分，並逐步建立它。有許多規則屬於簡單類別，因此我們需要目標身分模組上的功能，以防需要觸發尚未實作的規則時，可以回退到大型主機。這看起來如下

隨著雲端身分模組的新建置版本發布，我們將看到較少屬於簡單類別的規則透過回退機制套用。最終，只有複雜的規則會透過該部分可見。正如我們先前提到的，這些需要一次全部移轉，以將身分漂移的影響降至最低。我們的計畫是針對雲端資料庫複本逐步建立複雜規則，並透過廣泛的比較測試驗證其結果。

一旦建立所有規則，我們將發布此程式碼並停用回退到大主機的策略。請記住，在發布此程式碼後，大型主機身分和關聯資料實際上會成為由雲端身分模組管理的新主儲存體的複本。因此，需要複製才能讓大型主機繼續正常運作。

正如先前在其他部分提到的，我們的設計採用舊版模擬和防損毀層，它會將資料從大型主機轉換成雲端模型，反之亦然。此層包含跨系統的一系列轉接器，確保資料會從大型主機流出，以便雲端使用事件驅動資料管線使用，並作為平面檔案傳回大型主機，以允許現有的批次作業處理它們。為簡化起見，上述圖表未顯示這些轉接器，但它們會在資料跨系統流動時每次實作，無論接縫有多精細。遺憾的是，我們在此處的工作主要是分析和設計，我們無法採取下一步並驗證我們的假設，除了執行尖峰測試以確保可以採用 CDC 工具和檔案傳輸服務以以所需格式將資料傳送進出大型主機。在大型主機周圍建立所需的架構，以及反向工程現有管線以收集需求所需的時間相當長，而且超過計畫第一階段的時間範圍。

細緻接縫：下游處理移交

類似於用於上游管道來提供下游批次工作負載的方法，舊式模擬適配器用於在線流程的遷移。在現有系統中，客戶 API 呼叫會觸發一系列產生副作用的程式，例如帳單和稽核記錄，這些記錄會持續儲存在大型主機上的適當資料儲存區（主要是期刊）。

為了成功地逐步將在線流程轉移到雲端，我們需要確保這些副作用會直接由新系統處理，從而增加雲端的範圍，或提供適配器回到大型主機，以執行和協調負責這些副作用的基礎程式流程。在我們的案例中，我們選擇使用 CICS 網路服務來執行後者。我們建置的解決方案已針對功能需求進行測試；跨功能需求（例如延遲和效能）無法驗證，因為在第一階段取得類似生產環境的大型主機測試環境具有挑戰性。下圖顯示，根據我們的適配器實作，已遷移客戶的流程會是什麼樣子。

值得注意的是，適配器計畫為暫時性的架構。當雲端能夠自行處理這些副作用後，它們將不再具有有效用途，屆時我們計畫將資料複製回大型主機，以持續提供連續性，直到不再需要為止。

資料複製以支援新產品開發

建立在上述的逐步方法上，組織可能有一些產品構想，這些構想主要是基於大型主機上核心資料的分析或彙總資料。這些構想通常較不需要即時資訊，例如報告使用案例或彙總過往期間的資料。在這些情況下，可以透過明智地使用資料複製來更早解鎖業務優勢。
如果執行得當，這可以透過較小的前期投資來促成新產品開發，進而為現代化工作帶來動能。
在我們最近的專案中，我們的客戶已經踏上這趟旅程，使用 CDC 工具將核心表格從 DB2 複製到雲端。

雖然這在促成新產品推出方面很棒，但它也有一些缺點。

除非您在複製資料庫時採取步驟抽象架構，否則您的新雲端產品會在建置後立即與舊式架構結合。這可能會阻礙您在目標環境中可能想要進行的任何後續創新，因為您現在在變更應用程式核心時會增加一個拖累因素；但這次情況更糟，因為您不會想要再次投資於變更您剛資助的新產品。因此，我們提出的設計包括從複製品資料庫進一步投影到最佳化儲存區和架構，而新產品將建置在這些儲存區和架構之上。

這將使我們有機會重構架構，有時將資料模型的部分移至非關聯式儲存，這將能更好地處理在中小企業中觀察到的查詢模式。

在批次工作負載遷移後，為了讓所有儲存保持同步，您可能需要考慮直接對新的主資料庫執行寫回策略（以前稱為複本），進而回饋至大型主機上的 DB2（儘管批次與舊架構之間的耦合度會更高），或將 CDC 和適應層的方向從最佳化儲存作為來源，以及新的主資料庫作為目標（您可能需要為每個資料區段分別管理複製，例如一個資料區段從複本複製到最佳化儲存，另一個區段則相反）。

結論

從大型主機卸載時有多項事項需要考慮。根據您希望從大型主機上遷移的系統大小，這項工作可能需要相當長的時間，而且增量雙重執行成本不容忽視。這將花費多少取決於各種因素，但您不能期望透過並行執行兩個系統來節省成本。因此，企業應及早尋求產生價值，以取得利害關係人的認同，並為多年的現代化計畫提供資金。我們將增量雙重執行視為團隊對業務需求快速回應的推手，與敏捷和持續交付實務並行。

首先，您必須了解整體系統環境以及系統的進入點為何。這些介面扮演著重要的角色，允許將外部使用者/應用程式遷移到您正在建立的新系統。您可以在整個遷移過程中重新設計您的外部合約，但這將需要大型主機和雲端之間的適應層。

其次，您必須找出大型主機系統提供的業務功能，並找出實作這些功能的基礎程式之間的縫合。以功能為導向有助於確保您不會建立另一個糾結的系統，並在適當的層級保持責任和問題的分離。您將發現自己正在建立一系列適配器，這些適配器將公開 API、使用事件或將資料複製回大型主機。這可確保在大型主機上執行的其他系統可以保持原樣運作。最佳實務是將這些適配器建置為可重複使用的元件，因為您可以根據具體需求將它們用於系統的多個區域。

第三，假設您嘗試遷移的功能是有狀態的，您可能需要複製主機可存取的資料。這時可以使用 CDC 工具來複製資料。了解資料複製的 CFR（跨功能需求）非常重要，有些資料可能需要快速複製通道到雲端，而您選擇的工具理想上應提供此功能。現在有很多工具和架構可供您考慮並針對您的特定場景進行調查。有許多 CDC 工具可供評估，例如我們針對 DB2 表格查看 Qlik Replicate，更具體地說，針對 VSAM 儲存查看 Precisely Connect。

雲端服務供應商也在這個領域推出新產品；例如，Google Cloud 最近推出的 Dual Run 推出了自己的專有資料複製方法。

如需更全面的觀點，了解如何動員團隊團隊來交付此規模的工作計畫，請參閱我們的同事 Sophie Holden 所撰寫的文章 “Eating the Elephant”。

最後，還有其他事項需要考慮，本文中簡要提到。其中，測試策略將扮演至關重要的角色，以確保您正確建置新系統。自動化測試縮短了建置目標系統的交付團隊的回饋迴路。比較測試確保兩個系統在技術角度上展現相同的行為。這些策略與合成資料產生和製作資料混淆技術結合使用，可以更精細地控制您打算觸發的場景並驗證其結果。最後但並非最不重要的一點是，製作比較測試確保在 Dual Run 中執行的系統隨著時間推移，會產生與舊系統相同的結果。在需要時，至少會從外部觀察者的角度比較結果，例如與系統互動的客戶。此外，我們可以比較中間系統結果。

希望這篇文章讓您了解在踏上主機卸載旅程時需要考慮的事項。我們參與了一個多年計畫的最初幾個月，我們討論的一些解決方案處於非常早期的構思階段。儘管如此，我們從這項工作中學到了很多，我們認為這些想法值得分享。將您的旅程分解成可行的有價值步驟總是需要背景，但我們希望我們的學習和方法可以幫助您入門，這樣您就可以更上一層樓，投入製作，並啟用您自己的路線圖。