如何分階段推動跨雲端與地端系統的 MFT 現代化

在不影響既有合作夥伴整合、工作流程或業務運作的情況下，實現受管檔案傳輸（MFT）現代化

您的架構審查委員會早在一年前就已核准檔案傳輸現代化計畫。從紙面上看，這項任務相當明確：淘汰零散的指令碼與各式廠商工具，整合至具備完善治理與稽核能力的平台，同時確保任何一項合作夥伴整合都不會因此中斷。

然而，當有人真正盤點現有環境後，情況卻完全不同：共有 400 個仍在運作的工作流程、4 套不同的憑證儲存機制，以及大量由前任員工留下、邏輯未經文件化的指令碼。

在這樣的背景下，全面推倒重來與其說是現代化計畫，不如說是在拿企業自身的系統可用性下注。這正是為什麼受管檔案傳輸（MFT）現代化更適合採取分階段推動的方式。

分階段的現代化方法，可以協助組織降低遷移風險、強化治理能力、逐步消除技術債，並建立標準化的檔案傳輸機制，同時避免影響既有的業務流程。

先從實際運作中的環境與流程著手，再根據每個階段的驗證結果，逐步擴大集中式管理與控管的範圍。若執行得當，這種方式也能回答每位架構師在核准新平台之前都會思考的一個問題：

這會不會只是再增加一個需要維護與防守的新孤島？還是它能真正融入我們現有的系統環境？

MFT 混合雲現代化的架構考量

每一套分階段的現代化計畫，背後都有一項關鍵的架構決策：管理與執行是否應該放在同一個地方？

以閘道器（Gateway）為核心的 MFT 架構，會讓每個檔案都經由檔案傳輸伺服器本身傳送。因此，當您要將 MFT 的涵蓋範圍擴展至新的區域或新的網路邊界時，就意味著必須再建置一套完整的伺服器實例。Progress Automate MFT 則採用不同的架構。透過協調器－代理程式（coordinator-agent）拓撲，將雲端託管的管理主控台與負責實際傳輸資料的代理程式分離。您可以在管理主控台中設計及治理任務，而代理程式則部署在資料所在的位置附近，負責執行資料傳輸。管理主控台從資料傳輸路徑之外進行協調與控管。

不同於閘道器導向及單體式架構會將所有傳輸都經由集中式 MFT 伺服器處理，Automate MFT 將協調與執行分離，讓組織無須重新設計既有的資料傳輸路徑，就能逐步擴展集中式治理能力。

由於執行與控制彼此解耦，您可以依照現有環境的實際需求部署代理程式，而不必強迫所有工作流程都採用同一種架構模式：

自託管代理程式（Self-hosted agent）僅會建立對外連線，並透過 HTTPS／TLS 進行通訊，因此不需要為了 Automate MFT 開放任何對內的防火牆連線。

至於供應商鎖定（lock-in），這個問題值得比「部署彈性」更直接地回答。檔案傳輸採用標準通訊協定，因此合作夥伴端根本不會知道底層發生了任何變更；端點與憑證定義則存放於可供您盤點的共用程式庫（shared libraries）中。

其他系統則可透過 REST API 與平台進行整合。真正無法直接遷移的是在管理主控台中建立的工作流程邏輯（task logic），因此必須如實估算這部分的重建成本。

接著，再將這項成本與您目前正在承擔的那些未文件化指令碼進行比較——這些指令碼甚至無法完整盤點，反而才是您目前真正難以量化的技術債。

第一階段：在動手變更任何內容之前，盤點所有傳輸流程

如果跳過盤點，就不是省下這項工作，而只是把一次服務中斷延後發生。完整的盤點應包含以下五個部分：

• 所有現行工作流程：包括排程觸發、事件觸發及手動執行的流程

• 所有端點與連線

• 所有正在使用的憑證與通訊協定：包括 SSH 金鑰與 TLS 憑證、SFTP 與 FTPS

• 所有附帶使用的臨時指令碼或驗證步驟

• 每個工作流程所負責的業務窗口

最後這一項往往最容易被團隊忽略，卻也是最容易造成問題的一環。

想像一下：某個工作流程順利完成遷移，測試也全部通過，大家便繼續往下進行。三週後，一家交易夥伴打電話來詢問，為什麼再也收不到採購單確認通知。

原來，盤點時漏掉了一個傳輸完成後的通知指令碼，而且這個指令碼從未被正式文件化。當初撰寫它的人早已在兩次組織改組前就離職了。

如果這樣的情況發生在 400 個工作流程中的每一個環節，您就會明白，為什麼這份盤點資料早在實際開始遷移之前，就已經決定了分階段現代化能否成功。

警告：正式環境只能證明工作流程確實能執行；要真正理解它，則需要完整的盤點。在遷移之前，先釐清它的相依關係、負責人，以及可能的故障情境。

完成盤點後，接著依照工作流程的模式進行分類。對於使用相同端點、相同憑證的週期性檔案傳輸，應將其集中定義在共用程式庫中，以單一定義取代原本散落在 40 個工作流程中的 40 份複本。

第二階段：選擇代理程式，先從小規模試行

代理程式的選擇，應直接根據前一階段完成的盤點結果來決定。凡是涉及內部網路共用目錄、本機目錄，或部署於地端的 Progress MOVEit Transfer 伺服器，都應在防火牆後方部署自託管代理程式（self-hosted agent）。

至於雲端儲存空間之間的檔案傳輸，則可使用 Progress 託管代理程式（Progress-hosted agent），完全不需要在您的私有網路中留下任何部署元件。

如果代理程式選擇錯誤，結果可能是兩種極端：不是將原本應受保護的基礎架構暴露出去，就是為根本不需要的代理程式付費。

試行階段應選擇少量、具高價值但低風險的工作流程。最複雜的合作夥伴整合則應留到整套模式驗證成功後再處理。

整個試行可分為四個步驟：

1. 讓相關利害關係人就涉及的 DNS 與防火牆變更達成共識。

2. 安裝並註冊代理程式，然後將原有任務的邏輯與排程遷移至 Automate MFT。

3. 在非正式環境中，從頭到尾驗證整個工作流程。

4. 正式上線執行，同時持續觀察沙盒環境未能發現的問題。

專業提示：由於自託管代理程式只會建立對外連線，因此試行階段不應需要新增任何對內的防火牆規則。如果某個預計遷移的工作流程確實需要新增入站規則，應將此視為一項警訊，在遷移之前重新檢視架構設計。

如果能在不變更防火牆規則的情況下完成上述四個步驟，您就能取得第三階段所需的實際驗證依據。

第三階段：透過並行運作爭取時間，逐步擴大集中管理

在遷移剩餘合作夥伴的過程中，您現有的 MFT 閘道器與 Automate MFT 可以並行運作，並以受控批次逐步完成遷移。這是在正式環境中、沒有維護時段的情況下，實現零中斷遷移的一種方式。

這段並行運作期間同時也是一項重要的驗證依據。在投入更多預算或淘汰任何既有系統之前，可以先讓真實的生產流量經由 Automate MFT 傳輸，以實際運作結果建立信心。

隨著信心逐步建立，再有計畫地擴大集中管理範圍。代理程式集區（Agent pools） 可以將多個自託管代理程式組成一個集區，讓平台在集區內進行負載平衡，並在其中一個代理程式發生故障時自動切換至其他代理程式。對多數站點而言，這也就不需要另外建置每個站點的高可用性叢集。

任務版本控制（Task versioning） 則會保留最近 200 個任務版本，另外最多可儲存 100 個具名版本，因此如果修改內容造成問題，可以一步回復到先前的版本。

其中最關鍵的部分是 REST API。現有的協調與整合工具可以透過 REST API 觸發及監控檔案傳輸，讓檔案傳輸作業能與其他系統一樣，呈現在現有的監控儀表板中。

在安全團隊的關注事項中，合規性通常會優先於其他問題。Automate MFT 已完成 SOC 2 Type 1 與 HIPAA 稽核，並提供支援 GDPR 準備工作的功能。截至 2026 年 8 月，相關功能包括集中式金鑰管理、多因素驗證（MFA）、單一登入（SSO），以及可針對各工作流程設定的角色型存取控制（RBAC）。

其中最後一項控管在遷移期間尤其重要，因為它可以避免尚未完成遷移的環境同時採用兩套不同的權限模型。

當舊有工作流程完成遷移後，就逐步淘汰對應的舊版節點。**遷移進度決定淘汰時程。**如此一來，在下一次架構審查時，您就能提出一套有充分依據的分階段計畫，最終成果可以很簡單地概括為：

「全部完成切換，而且沒有任何系統中斷。」

這一季就從盤點開始。簽署任何合約可以先等等。先找出團隊目前能盤點到的每一個現行檔案傳輸工作流程，並為每個流程指定一位負責人。

一週之內，您就能知道哪些工作流程適合進行試行，以及哪些流程在接近正式切換日期之前，還需要進一步釐清。

評估您的 MFT 環境。與 零壹科技 專家安排討論，找出適合遷移的工作流程，並制定分階段的現代化路線圖。

資料來源: Progress Blogs