对于持牌交易所而言，“保持在线”并非用户体验问题，而是牌照问题。 根据 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. 钱包和私钥灾难恢复

钱包灾难恢复的首要原则是：灾难恢复绝不能削弱密钥安全性。 采用地理分散备份的冷钱包多签名机制本身就是业务连续性计划（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分钟内——通过状态页面、应用推送、官方社交渠道及媒体，说明影响、进展和预计解决时间，以避免因信息真空引发的恐慌和谣言。 向监管机构提交的报告必须遵守许可证和指导方针规定的时限：在规定时限内进行初步通报，事件结案后进行根本原因分析和整改，并对重大事件进行主动复盘。 在内部，应完整保留时间线、决策日志、行动记录和沟通日志，既用于事后分析，也用于日后向审计机构和监管机构证明响应措施符合合规要求。

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 和多签名解决方案集成，密钥份额分布于不同区域和提供商之间，且灾难恢复环境中的签名工作流在保持相同政策的同时，不会降低安全标准。 内置的备份、WORM（写入一次，只读）保留及自动化对账模块，支持对链上余额、账本、交易和资金流动进行每日四向核对，并可导出审计报告。 监控和事件响应模块涵盖基础设施、应用程序、业务指标及链上事件，提供基于严重程度的警报、战情室工具、状态页面以及客户通知模板，以缩短沟通响应时间。 在合规方面，该平台提供 BCP 文档模板、演练记录、事件报告格式以及证券委员会（SC）现场检查所需的数据保留接口，并可与客户的 SOC、托管机构及保险公司进行集成。 SoonTech 的交付团队不仅提供软件，还会通过业务影响分析、RTO/RPO 分级、架构审查、演练协调以及面向监管机构的材料编制等方式与客户紧密合作。

13. 企业实施建议

对于申请或已持有马来西亚 RMO DAX 许可证的平台，我们建议采取四步实施路径。第一步是业务影响分析：识别关键业务功能、依赖关系、单点故障以及最大可容忍停机时间，并编制分级清单。 第二步是目标架构：根据各层级选择主动-主动（active-active）、温灾备（warm DR）或冷备份（cold backup）方案，在确保核心系统满足监管要求和客户期望的同时，避免对非关键系统进行过度投资。 第三步是流程与政策：将事件响应、沟通、测试、备份恢复及第三方管理转化为可执行的操作手册，并对每位值班工程师进行培训。第四步是通过演练、监控、审计和事后分析进行持续验证，使业务连续性计划（BCP）成为一项持续的运营能力，而非一次性项目。 高管支持至关重要：韧性应与资本、保险和合规并列于管理议程之中，因为它决定了平台能否在事件中存活下来。应避免两种极端——缺乏流程和演练的华而不实的架构，或是从未付诸实践的文档。两者的结合正是SC所期望看到的，也是真正能够保护客户的关键。

常见问题

Q1：谁应该设定 RTO 和 RPO？

A：业务、合规和技术部门应共同制定，并经高管批准。技术部门提供可行性及成本数据，但若孤立设定目标，则会脱离业务和监管现实。这些目标应纳入服务水平协议（SLA），并在发生重大变更后重新审视。

Q2：主动-主动架构是否消除了对远程灾备站点的需要？

答：不。主动-主动架构可应对数据中心或可用区故障，但无法应对城市级灾难或大范围云区域中断。拥有核心系统的持牌交易所通常仍需远程灾备站点，以应对区域性故障。

Q3：灾备站点在正常时期是否应承载流量？

A：理想情况下应该——无论是承载少量生产流量，还是通过定期演练——以确保版本、配置和数据与主站点保持同步。闲置的冷备用站点在实际需要时往往无法成功切换；温备用或主动-主动备用模式则更可靠。

Q4：灾备会增加密钥泄露的风险吗？

A：如果设计得当，则不会。灾备仅复制签名工作流和节点，绝不会复制明文密钥；MPC 份额在跨区域间共享且遵循相同的多签名策略，因此灾备不会降低安全门槛。它消除了因单一区域故障导致提现完全受阻的风险。

Q5：演练会影响实际用户吗？

A：组件级演练在“金丝雀”环境或非高峰时段进行，并配备二级回滚机制；全系统切换会先在预发布环境或影子环境中验证，随后再安排实施。在触及生产环境前务必进行隔离验证，若可能影响用户，需提前公告。

Q6：系统故障导致的用户损失由谁承担？

A：客户协议中明确了责任归属；风险储备金和保险将覆盖因平台故障造成的损失。平台系统风险不应转嫁给用户；赔偿将根据事件性质、合同条款及监管要求进行。

结论

运营韧性是持牌交易所的基本能力：监管机构要求的是可验证的恢复能力，而非华而不实的文件。 将恢复时间目标（RTO）/恢复点目标（RPO）分级、多站点架构、撮合与钱包故障转移、备份与对账、事件处理流程、客户资产保护、定期演练以及保险和储备金整合为一个闭环体系，才能使平台在实际发生故障时保护客户、通过监管审查并保持运营。 技术仅是其中一部分；流程、人员、演练以及持续改进同样至关重要。

🌐 与 SoonTech 携手构建安全且可扩展的 Web3 平台。

探索我们针对白标加密货币交易所、预测市场、MPC钱包、撮合引擎、流动性集成及合规性的解决方案。