對於持牌交易所而言，「維持線上運作」並非使用者體驗（UX）問題——而是執照合規問題。 根據 RMO DAX（認可市場營運商——數位資產交易所）框架，馬來西亞證券委員會要求具備營運韌性：即在硬體故障、雲端服務中斷、網路攻擊或資料中心損失的情況下，能夠在承諾的時間內恢復交易並保護客戶資產。 本文將逐步闡述完整的業務連續性計畫（BCP）與災難復原（DR）設計，涵蓋從恢復目標時間（RTO）與恢復點目標（RPO）分層、多站點架構，到交易匹配引擎與錢包的故障轉移、備份與對帳、事件應變、客戶資產保護、測試、保險及準備金等環節，並著重說明如何將這些能力轉化為可經稽核的實際方案，而非僅止於簡報投影片。

1. 證監會（SC）對營運韌性的要求

證監會（SC）在《RMO DAX 指引》、現場檢查清單及牌照續期審查中，著重於營運韌性的三個層面。首先，關鍵系統必須具備書面業務連續性計畫（BCP），涵蓋所有已識別的關鍵業務功能——包括交易對帳、結算、錢包、存取款、客戶盡職調查（KYC）及客戶支援。 其次，平台必須定期進行測試並保存完整紀錄，且測試結果須納入改善循環。第三，在系統中斷期間，客戶資產必須保持安全且可追溯，且平台事後必須能向 SC 及審計師證明資產未遭遺失、挪用或錯誤入帳。監管機構不接受「盡最大努力」的說法； 他們要求針對每一項關鍵功能，均須明確定義恢復時間目標（RTO）與恢復點目標（RPO）、負責人、升級處理流程，以及向監管機構和客戶發送通知的時限。業務連續性計畫文件必須至少每年進行一次審查，並在重大架構變更、上市規則變更或關鍵外包供應商更換後予以更新，且須於規定期限內應證監會要求提交相關文件。 除 RMO DAX 之外，交易平台還必須符合資本市場法規、反洗錢（AML）要求，以及證監會關於網路安全與技術風險管理的指引，並將韌性與內部控制、資訊安全及外包治理相整合，以確保文件內容相互一致。

2. RTO/RPO 分級

並非每個系統都需要亞秒級的恢復能力，且盲目將所有系統以「主動-主動」模式運行，將使成本推升至難以維持的水平。我們建議依據業務影響程度劃分為四個層級。第一層級為核心交易系統——配對引擎、即時風險管理、市場數據、訂單閘道——其 RTO 為數分鐘，RPO 接近於零，這意味著已配對的交易絕不能遺失。 第二級為基金與清算系統——包括資金帳戶、對帳、入帳、提領審核等——其 RTO 為數十分鐘，RPO 為數秒至數分鐘；可接受短暫延遲，但不得出現會計錯誤。第三級為帳戶與支援系統——包含登入、KYC、服務單、通知等——其 RTO 為數小時。 第四層級為非關鍵系統，例如行銷、報表及商業智慧（BI），其 RTO 為一天或更長時間。分級必須基於每小時停機造成的實際損失、客戶與監管機構的容忍度，以及復原的成本效益——而非技術團隊的偏好。 各項目標應明文載入內部服務水準協議（SLA）中，且可對外披露的部分應在客戶協議及狀態頁面上公開，以確保市場預期與平台能力相符。 分級並非「設定後便不再理會」：業務量增長、新產品（如期貨、收益）以及客戶結構的變化，都可能使原本非關鍵的系統升級為關鍵系統，因此應至少每年重新檢視分級表與業務影響分析。

3. 主動-主動架構與多站點災難復原

核心交易系統應在同一城市或雲端區域內的兩個資料中心或可用區域之間以「主動-主動」模式運行。兩者均承載實際流量，負載平衡可在數秒內完成故障轉移，同時低延遲的同步複製可確保狀態保持強一致性。 主動-主動架構可處理設施及可用區域故障，但無法應對整個區域的網路中斷、廣泛的雲端區域停機，或城市級災難。因此，必須在不同地理區域設置遠端災難復原站點，通常採用異步複製、秒至分鐘級的 RPO（恢復點目標），以及分鐘至十分鐘級的 RTO（恢復時間目標），以便在區域性故障後接管運作。 多雲端或混合部署可進一步降低供應商鎖定風險，但必須誠實考量跨雲端延遲、時鐘同步、映像一致性及營運複雜度；切勿為了「多雲端」而犧牲匹配效能。 設計原則是「故障即預設」：每個元件都有對等夥伴，任何單一故障都會被隔離並自動進行故障轉移，而非由人工耗時整夜進行修復。流量管理應支援狀態檢查、加權切換、金絲雀部署，以及單一斷路器緊急停止機制，以確保故障轉移本身不會觸發第二起事故。

4. 配對引擎故障轉移

配對引擎是狀態最複雜且最難進行故障轉移的元件。主節點持有記憶體中的訂單簿和持倉資料；熱備援節點會即時重播預寫日誌，但不會直接為客戶端提供服務。 當主節點發生故障時，備用節點僅在確認日誌完整性並追上主節點最後確認的持倉後，才會晉升為主節點；客戶端透過閘道器或配置中心重新連線，未確認的訂單由客戶端重新提交，而已確認的交易則由日誌決定。 升格過程必須防止「腦裂」現象——即兩個節點都認為自己是主節點——否則將導致交易重複成交及餘額損毀。典型的模式是採用租約加上分散式鎖定，確保僅持有有效租約且擁有最新日誌的節點才能升格；舊主節點在恢復後，必須以備用節點身分重新加入並重新同步。 在極端情況下，與其基於不一致的資料恢復交易，不如暫停交易片刻並進行手動狀態確認。配對系統的故障轉移還必須與下游的清算、風險管理、錢包、市場資料及通知系統協調；否則，配對系統雖已恢復，但其餘系統尚未恢復，將導致半掛起狀態——即可以下單但無法成交，或已成交但未入帳。

5. 錢包與私鑰災難恢復

錢包災難復原的首要原則是：災難復原絕不能削弱金鑰安全性。 具備地理分散備份的冷錢包多簽（multisig）機制本身即是業務連續性計畫（BCP）的一部分；任何單一地區、個人或服務供應商均不得單方面移動資產。多方計算（MPC）金鑰分片應跨區域、跨雲端服務供應商及跨實體媒體儲存，且分片的生成、輪替與恢復流程須明文載入政策並定期接受稽核。 熱錢包節點應採用多實例運行，以確保單一故障不會阻斷廣播或收據掃描；金鑰與份數絕不離開安全域（HSM、MPC 節點或簽署者），且災難恢復環境僅複製簽署工作流程與節點狀態，絕不複製明文金鑰。 恢復演練必須驗證完整情境：即使整個區域完全癱瘓，平台仍能從存活區域進行簽名與提領，同時多簽名批准政策、風險限額及內部人員管控措施仍持續生效。 災難復原站點中的存取權限、核准者及稽核日誌必須與生產環境同樣嚴格，以免災難復原成為安全弱點。針對區塊鏈層級的重組及節點故障，平台還需具備節點冗餘、平行鏈節點，以及最終一致性對帳機制。

6. 備份、對帳與復原

備份必須同時滿足 RPO（恢復點目標）與可驗證的可恢復性。生產環境資料庫需進行完整備份加上增量備份，並搭配持續的日誌傳輸；此外，帳本、交易及存取款紀錄還需寫入 WORM 或物件鎖定儲存裝置，其保留期限須足夠長，以滿足監管追蹤要求。 僅靠備份是不夠的：必須能夠從備份重建系統並進行對帳。從備份還原完整環境後，須逐筆對帳鏈上餘額、用戶餘額、交易及資金流動，確保這四者一致，且任何差異皆可追溯至特定交易。 應執行自動化每日對帳並產生獨立報告，並在災難復原（DR）環境中定期進行「從備份重建完整環境」的演練；否則復原能力將無法確認。備份安全性同樣重要：離線副本必須經過加密、分拆保管，並存放於異地，以防止勒索軟體同時加密生產環境與備份資料。 恢復流程必須落實職責分離，確保沒有任何單一管理員能同時刪除備份與日誌。恢復時間本身必須針對 RTO 進行驗證，特別是在資料量不斷增長的情況下；分片、快照及平行還原是控制恢復時間的常見管控措施。

7. DDoS、雲端服務中斷與網路安全應變

DDoS 是東南亞交易所服務中斷的最常見原因，其發生頻率與峰值規模皆持續攀升。 防禦應採分層架構：上游反 DDoS 清洗機制吸收流量型攻擊，CDN 與 WAF 緩解應用層 CC 攻擊，API 閘道實施細粒度速率限制與異常流量阻擋，後端服務僅對已經清洗的源站開放。 雲端區域服務中斷可透過多站點與跨區域故障轉移來處理；切換期間應將 DNS TTL 設定為較低值，同時需監控 DNS 服務供應商與憑證的可用性，以避免形成單點故障。 針對入侵與勒索軟體，核心原則包括最小權限、網路分段、金鑰輪替、特權存取審批以及離線備份——即使生產環境已加密，一份乾淨的離線副本仍能實現復原，並將資料外洩的影響降至最低。 每個外部依賴項都需要備援方案與降級機制：若支付合作夥伴停機，則切換支付通道或暫停法幣入金；若 KYC 服務供應商停機，則將 KYC 流程轉至人工審核佇列；若市場數據源出現異常，則切換數據來源並暫停受影響的交易代碼； 若鏈上節點運作異常，則應切換節點並提高確認次數門檻。每項降級措施都應寫入運作手冊，以便值班人員能依照程序行事，而非在壓力下臨時應變。

8. 事件應變與通訊

業務連續性計畫（BCP）不僅關乎技術，更涉及流程與組織架構。平台應建立事件指揮系統：值班的 SRE 或運維工程師為第一響應者，根據事件嚴重性啟動戰情室，並明確界定技術處理、內部溝通、外部溝通、法律／合規以及客戶支援等角色，同時制定升級時限與決策權限。 嚴重等級通常依據影響範圍、財務風險及法規敏感性來設定；P1 級事件要求所有相關人員須於數分鐘內投入應對，且高層主管須在規定時限內介入。 對外溝通必須在承諾的時間內發布——例如在確認重大事件後 30 至 60 分鐘內——透過狀態頁面、應用程式推播、官方社群管道及媒體，說明影響範圍、處理進度及預計完成時間，以避免因沉默而引發的恐慌與謠言。 向安全委員會（SC）提交的報告必須遵守許可證及指引規定的截止期限：在規定時限內發出初步通知，事件結案後進行根本原因分析與補救措施，並針對重大事件主動進行事後檢討。 內部方面，應完整保存時間軸、決策紀錄、行動紀錄及通訊紀錄，既供事後檢討之用，亦可於日後向稽核人員及監管機構證明應對措施符合規範。

9. 服務中斷期間的客戶資產保護

客戶資產保護是營運韌性的終極目標。首先，資產必須進行隔離：客戶的法幣與加密貨幣須與平台自有資產分開存放，且冷錢包比例、熱錢包限額及多簽署政策均須可供公眾驗證。 其次，在系統中斷期間，平台仍須能夠完成關鍵的存款確認與提領核准；若無法處理，則須明確公告延遲處理及補償規則，以確保鏈上存款不會因平台停機而遺失。 第三，平台應能透過定期的默克爾樹儲備證明、獨立託管報告，或證明 100% 備抵的審計意見等機制，證明停機前後的償付能力。 第四，用戶協議必須明確界定系統中斷、回滾及賠償的責任歸屬，包括不可抗力、鏈層級異常及第三方故障等情況，以避免事後爭議。 第五，因系統中斷期間無法進行操作而蒙受損失的客戶，需要一套明確的索賠與補償管道，該管道應根據事件性質由風險準備金或保險提供資金支持，而非以泛泛的「系統維護」為由搪塞。將上述內容寫入政策僅是第一步；真正的考驗在於能否在事件發生時確實執行。

10. 測試與持續改進

從未經過測試的業務連續性計畫（BCP）等同於不存在。 測試應分層進行。第一層是桌面演練，由領導層與關鍵角色模擬事件情境，以驗證流程、職責及通訊範本。第二層是組件故障轉移演練，在「金絲雀」測試或非高峰時段實際關閉資料庫、節點或可用區域，以驗證警示、自動故障轉移及回滾機制。 第三層是全堆疊災難復原切換，將整個生產系統移至災難復原站點一段時間後再切回，涵蓋配對、錢包、清算、閘道及通知功能。第四層是紅藍／紫隊演練與混沌工程，透過刻意注入故障並模擬攻擊來揭露隱藏的弱點。 每次演練都需要制定計畫、觀察指標、回滾方案及事後檢討；問題清單會列出具體負責人與截止日期，作為問題修復的依據。合理的演練頻率為：每季進行一次桌面演練，每季進行一至兩次組件演練，每年至少進行一次全堆疊切換演練，並在重大架構變更後進行臨時演練。 演練紀錄應保存數年，作為安全認證（SC）現場查核的佐證。

11. 保險、準備金與第三方依賴關係

技術控制無法涵蓋所有損失；保險與準備金是韌性的最後防線。風險準備金通常由交易手續費的百分比、清算盈餘及專用資本撥付，用於彌補因平台中斷、資料外洩及內部人員詐欺所造成的客戶損失；其資金來源、使用條件及核准流程應予公開。 商業保險可採分層配置：針對關鍵系統遭入侵及盜竊的犯罪／託管保險、針對攻擊及業務中斷的網路責任險，以及針對管理層決策的董事及高管責任險（D&O），其保額應根據冷錢包持倉量、日交易量及監管機構的預期來設定。 第三方依賴關係亦須納入業務連續性計畫（BCP）：雲端服務供應商、防 DDoS 服務供應商、KYC 服務、支付通道、市場數據饋送、區塊鏈節點及法幣閘道，皆為潛在的故障點。 合約應明確定義服務水準協議（SLA）、資料所有權、退出與遷移條款，以及緊急情況下的合作機制；關鍵供應商需具備替代方案，並提供其自身韌性的證明（如 SOC 2、ISO 27001 認證及監管許可）。應定期重新評估與審查關鍵第三方，以免平台本身雖堅固，卻因單一供應商中斷而導致整體系統癱瘓。

12. SoonTech 業務連續性計畫（BCP）／災難復原（DR）實施

SoonTech 專為馬來西亞持牌營運商打造的白標交易所平台，將營運韌性視為首要能力。其配對引擎支援主-熱備援故障轉移機制，採用 WAL 複製與基於租約的領導者選舉機制，可部署於「主動-主動」或「遠端災難復原」拓撲結構中，並根據客戶的 RTO/RPO 目標進行配置。 錢包層整合了 MPC 和多簽名（multisig）解決方案，密鑰分片跨區域及供應商分佈，且災難復原（DR）環境中的簽署工作流程在維持相同政策的前提下，不會降低安全性標準。 內建的備份、WORM 保留及自動化對帳模組，支援針對鏈上餘額、帳本、交易及資金流動進行每日四向比對，並可輸出稽核報告。 監控與事件應變模組涵蓋基礎架構、應用程式、業務指標及鏈上事件，並具備基於嚴重程度的警示機制、戰情室工具、狀態頁面以及客戶通知範本，以縮短通報時間。 在合規方面，該平台提供 BCP 文件範本、演練記錄、事件報告格式以及 SC 現場檢查所需之資料保留介面，並可與客戶的 SOC、託管機構及保險公司進行整合。 SoonTech 的交付團隊不僅僅是交付軟體，更會透過業務影響分析、RTO/RPO 分級、架構審查、演練協調以及面向監管機構的文件，與客戶密切合作。

13. 企業實施建議

針對申請或已持有馬來西亞 RMO DAX 許可證的平台，我們建議採取四步驟路徑。第一步是業務影響分析：識別關鍵業務功能、依賴關係、單點故障及最大可容忍停機時間，並建立分級清單。 第二步是目標架構：針對各層級選擇「主動-主動」、「溫備援」或「冷備份」方案，在確保核心系統符合監管要求與客戶期望的同時，避免對非關鍵系統進行過度投資。 第三步是流程與政策：將事件應變、通訊、測試、備份與復原，以及第三方管理轉化為可執行的運作手冊，並對每位值班工程師進行培訓。第四步是透過演練、監控、稽核及事後檢討進行持續驗證，使業務連續性計畫（BCP）成為持續運作的能力，而非一次性專案。 高層支持至關重要：韌性應與資本、保險及合規並列於管理議程中，因為它決定了平台能否在事件中倖存。應避免兩種極端——缺乏流程與演練的華麗架構，或是從未付諸實行的文件。兩者的結合正是 SC 所期望的，也是真正能保護客戶的關鍵。

常見問題

Q1：誰應該設定 RTO 和 RPO？

A：應由業務、合規與技術部門共同定義，並經高層批准。技術部門提供可行性與成本數據，但若孤立設定目標，將使其脫離業務與監管現實。這些目標應納入服務水準協議（SLA），並在發生重大變更後重新檢視。

Q2：主動-主動架構是否能省去遠端災難復原站點的必要性？

A：不。主動-主動架構可處理資料中心或可用性區域的故障，但無法應對城市級災難或廣泛的雲端區域中斷。擁有執照且與核心系統相連的交易所，通常仍需遠端災難復原站點以因應區域性故障。

Q3：災難復原站點在正常運作期間是否應承載流量？

A：理想情況下應該如此——無論是承載一小部分生產流量，還是透過定期演練——以確保版本、配置和資料與主站保持同步。閒置的冷備援在實際需要時往往無法順利切換；溫備援或主動-主動備援則更為可靠。

Q4：災難復原會增加金鑰洩漏的風險嗎？

A：若設計得當則不會。災難復原僅複製簽署工作流程與節點，絕不會複製明文金鑰；多方計算（MPC）共享資料跨區域且遵循相同的多簽政策，因此災難復原並不會降低安全性標準。它消除了單一區域故障導致提領完全中斷的風險。

Q5：演練會影響實際使用者嗎？

A：組件演練會在「金絲雀」環境或非尖峰時段進行，並具備二級回滾機制；全面切換則會先在預備環境或影子環境中驗證，再進行排程。在觸及生產環境前，務必先在隔離環境中驗證；若可能對使用者造成影響，則須預先公告。

Q6：系統故障造成的用戶損失由誰承擔？

A：客戶協議中已明定責任歸屬；風險準備金與保險將承擔因平台故障所造成的損失。平台系統風險不應轉嫁給用戶；賠償將依據事件性質、合約條款及監管要求而定。

結論

營運韌性是持牌交易所的基本能力：監管機構要求的是可驗證的恢復能力，而非華麗的文件。 將 RTO/RPO 分級、多站點架構、撮合與錢包故障轉移、備份與對帳、事件處理流程、客戶資產保護、定期演練，以及保險與儲備金整合為一個閉環系統，才能讓平台在實際發生故障時，既能保護客戶、通過稽查，又能維持營運。 技術僅是其中一環；流程、人員、演練以及持續改進同樣至關重要。

🌐 與 SoonTech 攜手打造安全且可擴展的 Web3 平台。

探索我們針對白標加密貨幣交易所、預測市場、MPC 錢包、撮合引擎、流動性整合及合規性的解決方案。