Đối với một sàn giao dịch được cấp phép, việc “duy trì hoạt động trực tuyến” không phải là vấn đề về trải nghiệm người dùng (UX) — mà là vấn đề liên quan đến giấy phép. Theo khung quy định RMO DAX (Nhà điều hành thị trường được công nhận – Sàn giao dịch tài sản kỹ thuật số), Ủy ban Chứng khoán Malaysia yêu cầu khả năng phục hồi hoạt động: khả năng khôi phục giao dịch và bảo vệ tài sản của khách hàng trong thời gian cam kết khi xảy ra sự cố phần cứng, sự cố đám mây, tấn công mạng hoặc mất mát trung tâm dữ liệu. Bài viết này trình bày chi tiết thiết kế BCP/DR hoàn chỉnh, từ phân tầng RTO/RPO và kiến trúc đa địa điểm đến chuyển đổi dự phòng cho hệ thống khớp lệnh và ví, sao lưu và đối chiếu, ứng phó sự cố, bảo vệ tài sản khách hàng, thử nghiệm, bảo hiểm và dự trữ, với trọng tâm là cách biến những khả năng này thành các chương trình có thể kiểm toán được thay vì chỉ là những bản trình chiếu trên slide.

1. Yêu cầu của SC về Khả năng phục hồi hoạt động

SC tập trung vào ba tầng khả năng phục hồi hoạt động trong các hướng dẫn RMO DAX, danh sách kiểm tra tại chỗ và các cuộc đánh giá gia hạn giấy phép. Thứ nhất, các hệ thống quan trọng phải có kế hoạch BCP bằng văn bản bao quát tất cả các chức năng kinh doanh quan trọng đã được xác định — khớp lệnh, thanh toán bù trừ, ví điện tử, nạp và rút tiền, xác minh danh tính khách hàng (KYC) và hỗ trợ khách hàng. Thứ hai, các nền tảng phải thực hiện các cuộc kiểm tra định kỳ và lưu giữ hồ sơ đầy đủ, với kết quả kiểm tra được sử dụng để cải thiện quy trình. Thứ ba, tài sản của khách hàng phải được đảm bảo an toàn và có thể truy vết trong thời gian gián đoạn dịch vụ, và các nền tảng phải có khả năng chứng minh sau đó với SC và các kiểm toán viên rằng tài sản không bị mất mát, chiếm dụng hoặc ghi sai. Các cơ quan quản lý không chấp nhận khái niệm “nỗ lực tối đa”; họ yêu cầu các mục tiêu RTO/RPO được xác định rõ, người chịu trách nhiệm, quy trình báo cáo sự cố và thời hạn thông báo cho cả cơ quan quản lý và khách hàng đối với từng chức năng quan trọng. Tài liệu Kế hoạch Ứng phó Sự cố (BCP) phải được rà soát ít nhất hàng năm và cập nhật sau các thay đổi lớn về kiến trúc hệ thống, quy tắc niêm yết hoặc thay thế các nhà cung cấp dịch vụ bên ngoài chính, đồng thời phải được cung cấp cho SC theo yêu cầu trong thời hạn quy định. Ngoài RMO DAX, các nền tảng cũng phải tuân thủ luật pháp về thị trường vốn, các yêu cầu về chống rửa tiền (AML) và hướng dẫn của SC về an ninh mạng và quản lý rủi ro công nghệ, tích hợp khả năng phục hồi với kiểm soát nội bộ, an ninh thông tin và quản trị thuê ngoài để các tài liệu không mâu thuẫn với nhau.

2. Phân cấp RTO/RPO

Không phải hệ thống nào cũng cần khả năng phục hồi trong vòng dưới một giây, và việc vận hành mọi hệ thống theo mô hình active-active một cách mù quáng sẽ đẩy chi phí lên mức không bền vững. Chúng tôi đề xuất bốn cấp độ dựa trên tác động kinh doanh. Cấp độ một là giao dịch cốt lõi — hệ thống khớp lệnh, quản lý rủi ro thời gian thực, dữ liệu thị trường, cổng đặt lệnh — với RTO tính bằng phút và RPO gần như bằng không, có nghĩa là các giao dịch đã khớp không được phép bị mất. Cấp độ hai là quỹ và thanh toán bù trừ — ví điện tử, đối chiếu, ghi có, kiểm tra rút tiền — với RTO là hàng chục phút và RPO từ vài giây đến vài phút; sự chậm trễ ngắn là có thể chấp nhận được nhưng không được phép xảy ra sai sót kế toán. Cấp độ ba là tài khoản và hỗ trợ — đăng nhập, KYC, phiếu yêu cầu, thông báo — với RTO là vài giờ. Cấp độ bốn là các hệ thống không quan trọng như tiếp thị, báo cáo và BI, với RTO là một ngày hoặc hơn. Việc phân cấp phải dựa trên mức tổn thất thực tế mỗi giờ ngừng hoạt động, mức độ chấp nhận của khách hàng và cơ quan quản lý, cũng như lợi ích chi phí của việc khôi phục — chứ không dựa trên sở thích của đội ngũ kỹ thuật. Mỗi mục tiêu cần được ghi rõ trong SLA nội bộ, và các phần có thể công bố cần được thể hiện trong thỏa thuận khách hàng và trang trạng thái để kỳ vọng của thị trường phù hợp với khả năng của nền tảng. Việc phân cấp không phải là việc “thiết lập một lần rồi bỏ quên”: sự tăng trưởng về khối lượng, các sản phẩm mới (hợp đồng tương lai, thu nhập) và sự thay đổi cơ cấu khách hàng có thể nâng tầm các hệ thống trước đây không quan trọng, do đó, bảng phân cấp và phân tích tác động kinh doanh cần được kiểm tra lại ít nhất mỗi năm một lần.

3. Chế độ Hoạt động-Hoạt động và Phục hồi Thảm họa Đa Vị trí

Hoạt động giao dịch cốt lõi nên chạy theo mô hình Active-Active trên hai trung tâm dữ liệu hoặc vùng sẵn sàng (AZ) trong cùng một thành phố hoặc khu vực đám mây. Cả hai đều xử lý lưu lượng thực tế, và cân bằng tải chuyển đổi dự phòng trong vài giây trong khi sao chép đồng bộ độ trễ thấp duy trì trạng thái nhất quán mạnh. Chế độ Active-Active xử lý được sự cố tại cơ sở hoặc khu vực sẵn sàng (AZ) nhưng không đối phó được với mất kết nối mạng toàn khu vực, sự cố ngừng hoạt động trên diện rộng của khu vực đám mây hoặc thảm họa quy mô thành phố. Do đó, cần có một địa điểm DR từ xa ở khu vực địa lý khác, thường sử dụng sao chép không đồng bộ, RPO từ vài giây đến vài phút và RTO từ vài phút đến mười phút để tiếp quản sau sự cố khu vực. Việc triển khai đa đám mây hoặc lai giúp giảm thiểu sự phụ thuộc vào nhà cung cấp, nhưng phải tính đến độ trễ giữa các đám mây, đồng bộ hóa đồng hồ, tính nhất quán của hình ảnh và độ phức tạp trong vận hành; không nên hy sinh hiệu suất đồng bộ vì lý do “đa đám mây”. Nguyên tắc thiết kế là “lỗi là mặc định”: mỗi thành phần đều có một thành phần tương đương, bất kỳ sự cố đơn lẻ nào cũng được cách ly và chuyển đổi tự động thay vì được con người khắc phục qua đêm. Quản lý lưu lượng phải hỗ trợ kiểm tra tình trạng hoạt động, chuyển đổi có trọng số, triển khai thử nghiệm và dừng khẩn cấp bằng một công tắc ngắt mạch để việc chuyển đổi dự phòng không gây ra sự cố thứ hai.

4. Chuyển đổi dự phòng của bộ xử lý khớp lệnh

Cơ chế khớp lệnh là thành phần có trạng thái phức tạp nhất và khó chuyển đổi nhất. Máy chủ chính lưu trữ sổ lệnh và vị thế trong bộ nhớ; máy dự phòng nóng tái tạo nhật ký ghi trước theo thời gian thực nhưng không phục vụ khách hàng. Khi máy chủ chính gặp sự cố, máy chủ dự phòng chỉ được thăng cấp sau khi xác nhận nhật ký đã đầy đủ và bắt kịp vị thế cuối cùng đã được xác nhận của máy chủ chính; khách hàng kết nối lại qua cổng hoặc trung tâm cấu hình, các lệnh chưa được xác nhận sẽ được khách hàng gửi lại, và các giao dịch đã được xác nhận được xác định dựa trên nhật ký. Quá trình thăng cấp phải ngăn chặn tình trạng "split-brain" — khi hai nút đều tin rằng mình là nút chính — điều này sẽ gây ra các giao dịch trùng lặp và số dư bị hỏng. Mô hình điển hình là kết hợp giữa cơ chế thuê (lease) và khóa phân tán (distributed lock) để đảm bảo chỉ nút nắm giữ quyền thuê hợp lệ và nhật ký mới nhất mới có thể thăng cấp; nút chính cũ, khi phục hồi, phải tham gia lại với tư cách là nút dự phòng và đồng bộ lại. Trong trường hợp khẩn cấp, việc tạm dừng giao dịch trong thời gian ngắn kèm theo xác nhận trạng thái thủ công sẽ tốt hơn so với việc tiếp tục giao dịch trên dữ liệu không nhất quán. Quá trình chuyển đổi dự phòng của hệ thống khớp lệnh cũng phải được phối hợp với các hệ thống hạ lưu như thanh toán bù trừ, quản lý rủi ro, ví điện tử, dữ liệu thị trường và thông báo; nếu không, hệ thống khớp lệnh sẽ phục hồi nhưng các hệ thống còn lại thì không, dẫn đến tình trạng “nửa hoàn chỉnh” trong đó lệnh có thể được đặt nhưng không được khớp, hoặc được khớp nhưng không được ghi có.

5. Phục hồi thảm họa (DR) cho ví và khóa riêng

Nguyên tắc đầu tiên của khôi phục thảm họa (DR) cho ví là DR không được làm suy yếu bảo mật khóa. Ví lạnh đa chữ ký (multisig) với các bản sao lưu phân tán về mặt địa lý vốn đã là một phần của Kế hoạch Tiếp tục Hoạt động (BCP); không một khu vực, cá nhân hay nhà cung cấp nào được phép chuyển dịch tài sản một cách đơn phương. Các phần chia sẻ khóa MPC phải được lưu trữ trên nhiều khu vực, nhà cung cấp đám mây và phương tiện vật lý, với quy trình tạo, luân chuyển và khôi phục phần chia sẻ được quy định trong chính sách và được kiểm toán định kỳ. Các nút ví nóng chạy đa phiên bản để một sự cố không làm gián đoạn việc phát sóng hoặc quét giao dịch đến; khóa và phần chia sẻ không bao giờ rời khỏi miền an toàn — HSM, nút MPC hoặc người ký — và môi trường DR sao chép quy trình ký và trạng thái nút, không bao giờ sao chép khóa dưới dạng văn bản thuần túy. Các bài tập khôi phục phải xác minh toàn bộ kịch bản: ngay cả khi toàn bộ một khu vực bị ngắt kết nối, nền tảng vẫn có thể ký và rút tiền từ khu vực còn hoạt động trong khi chính sách phê duyệt đa chữ ký, giới hạn rủi ro và các biện pháp kiểm soát nội bộ vẫn có hiệu lực. Quyền truy cập, người phê duyệt và nhật ký kiểm toán tại địa điểm DR phải nghiêm ngặt như trong môi trường sản xuất để DR không trở thành điểm yếu về bảo mật. Đối với việc tái tổ chức ở cấp độ chuỗi và sự cố nút, các nền tảng cũng cần có tính dự phòng nút, các nút chuỗi song song và đối chiếu nhất quán cuối cùng.

6. Sao lưu, đối chiếu và khôi phục

Các bản sao lưu phải đáp ứng cả RPO và khả năng phục hồi có thể xác minh được. Cơ sở dữ liệu sản xuất thực hiện sao lưu toàn bộ và sao lưu gia tăng kèm theo việc chuyển nhật ký liên tục; các bản ghi sổ cái, giao dịch và nạp/rút tiền được ghi thêm vào bộ nhớ WORM hoặc bộ nhớ khóa đối tượng với thời gian lưu trữ đủ dài để đáp ứng yêu cầu truy xuất nguồn gốc theo quy định. Chỉ sao lưu thôi là chưa đủ: bạn phải có khả năng tái tạo hệ thống từ bản sao lưu và thực hiện đối chiếu. Sau khi khôi phục toàn bộ môi trường từ bản sao lưu, cần đối chiếu từng dòng số dư trên chuỗi, số dư người dùng, giao dịch và dòng tiền để đảm bảo bốn yếu tố này khớp nhau, với bất kỳ sự chênh lệch nào đều có thể truy vết đến một giao dịch cụ thể. Thực hiện đối chiếu tự động hàng ngày để tạo báo cáo độc lập, và tiến hành các bài kiểm tra định kỳ “phục hồi toàn bộ môi trường từ bản sao lưu” tại trung tâm phục hồi thảm họa (DR); nếu không, khả năng phục hồi sẽ không được đảm bảo. Bảo mật bản sao lưu cũng quan trọng không kém: các bản sao ngoại tuyến phải được mã hóa, lưu trữ theo hình thức chia sẻ quyền quản lý và tại địa điểm khác để phần mềm tống tiền không thể mã hóa cả hệ thống sản xuất và bản sao lưu cùng lúc. Quá trình khôi phục phải thực thi nguyên tắc phân chia nhiệm vụ để không có quản trị viên nào có thể xóa cả bản sao lưu và nhật ký. Thời gian khôi phục phải được xác minh so với RTO, đặc biệt khi khối lượng dữ liệu tăng lên; phân mảnh, ảnh chụp nhanh và khôi phục song song là các biện pháp kiểm soát phổ biến để kiểm soát thời gian khôi phục.

7. DDoS, sự cố đám mây và phản ứng an ninh mạng

DDoS là nguyên nhân phổ biến nhất gây ra sự cố ngừng hoạt động cho các sàn giao dịch ở Đông Nam Á, và cả tần suất lẫn quy mô đỉnh điểm của các cuộc tấn công này đều không ngừng gia tăng. Hệ thống phòng thủ cần được thiết kế theo nhiều lớp: hệ thống lọc chống DDoS ở phía thượng nguồn hấp thụ các cuộc tấn công theo khối lượng, CDN và WAF giảm thiểu các cuộc tấn công CC ở lớp ứng dụng, cổng API thực thi giới hạn tốc độ chi tiết và chặn lưu lượng bất thường, và các dịch vụ phía sau chỉ được tiếp xúc với các nguồn đã qua lọc. Các sự cố ngừng hoạt động ở khu vực đám mây được xử lý thông qua cơ chế chuyển đổi dự phòng đa địa điểm và xuyên khu vực; thời gian tồn tại (TTL) của DNS nên được duy trì ở mức thấp trong quá trình chuyển đổi, đồng thời cần theo dõi tính sẵn sàng của nhà cung cấp DNS và chứng chỉ để tránh điểm lỗi duy nhất. Đối với các cuộc xâm nhập và ransomware, các nguyên tắc cốt lõi là nguyên tắc đặc quyền tối thiểu, phân đoạn mạng, luân chuyển khóa, phê duyệt quyền truy cập đặc quyền và sao lưu ngoại tuyến — ngay cả khi môi trường sản xuất được mã hóa, một bản sao ngoại tuyến sạch sẽ vẫn cho phép khôi phục và hạn chế tác động của việc rò rỉ dữ liệu. Mọi phụ thuộc bên ngoài đều cần có phương án dự phòng và cơ chế hạ cấp: chuyển sang kênh thanh toán khác hoặc tạm dừng các cổng nạp tiền fiat nếu đối tác thanh toán gặp sự cố; chuyển quy trình KYC sang hàng đợi kiểm tra thủ công nếu nhà cung cấp KYC gặp sự cố; chuyển sang nguồn dữ liệu thị trường khác và tạm dừng các mã chứng khoán bị ảnh hưởng nếu nguồn cấp dữ liệu có dấu hiệu bất thường; chuyển sang các nút chuỗi khác và nâng ngưỡng xác nhận nếu các nút hoạt động bất thường. Mỗi phương án giảm tải cần được ghi vào sổ tay hướng dẫn để nhân viên trực ca có thể hành động theo quy trình thay vì phải ứng biến trong tình huống căng thẳng.

8. Ứng phó sự cố và Truyền thông

Kế hoạch liên tục kinh doanh (BCP) không chỉ liên quan đến công nghệ mà còn bao gồm quy trình và tổ chức. Các nền tảng nên thiết lập hệ thống chỉ huy sự cố: kỹ sư SRE hoặc kỹ sư vận hành trực ca là người phản ứng đầu tiên, phòng chỉ huy được kích hoạt tùy theo mức độ nghiêm trọng, và các vai trò về xử lý kỹ thuật, truyền thông nội bộ, truyền thông bên ngoài, pháp lý/tuân thủ và hỗ trợ khách hàng được xác định rõ ràng kèm theo thời hạn nâng cấp và quyền quyết định. Mức độ nghiêm trọng thường được xác định dựa trên tác động, rủi ro tài chính và tính nhạy cảm về quy định; sự cố P1 yêu cầu tất cả mọi người phải tham gia trong vòng vài phút và sự tham gia của ban lãnh đạo trong một khoảng thời gian xác định. Truyền thông bên ngoài phải được thực hiện trong thời gian cam kết — ví dụ: 30 đến 60 phút sau khi xác nhận sự cố lớn — thông qua trang trạng thái, thông báo đẩy trên ứng dụng, các kênh xã hội chính thức và phương tiện truyền thông, giải thích tác động, tiến độ và thời gian dự kiến hoàn thành để tránh sự hoảng loạn và tin đồn do sự im lặng gây ra. Các báo cáo gửi cho SC phải tuân thủ các thời hạn theo giấy phép và hướng dẫn: thông báo ban đầu trong khoảng thời gian quy định, tiếp theo là phân tích nguyên nhân gốc rễ và khắc phục sau khi sự cố được giải quyết, kèm theo báo cáo tổng kết chủ động đối với các sự cố lớn. Trong nội bộ, hãy lưu giữ một dòng thời gian đầy đủ, nhật ký quyết định, hồ sơ hành động và nhật ký thông tin liên lạc để phục vụ cho việc phân tích sau sự cố cũng như chứng minh sau này với các cơ quan kiểm toán và cơ quan quản lý rằng phản ứng đã tuân thủ các quy định.

9. Bảo vệ tài sản của khách hàng trong thời gian ngừng hoạt động

Bảo vệ tài sản của khách hàng là mục tiêu cuối cùng của khả năng phục hồi hoạt động. Thứ nhất, tài sản phải được tách biệt: tiền pháp định và tiền điện tử của khách hàng được lưu giữ riêng biệt với tài sản sở hữu của nền tảng, với tỷ lệ ví lạnh, giới hạn ví nóng và chính sách đa chữ ký có thể kiểm chứng công khai. Thứ hai, trong thời gian gián đoạn dịch vụ, nền tảng vẫn phải có khả năng hoàn tất các xác nhận nạp tiền và phê duyệt rút tiền quan trọng, hoặc phải công bố rõ ràng các quy định về thời gian trì hoãn và bồi thường để đảm bảo tiền nạp trên chuỗi không bị mất do nền tảng ngừng hoạt động. Thứ ba, nền tảng phải có khả năng chứng minh khả năng thanh toán trước và sau sự cố thông qua các cơ chế như bằng chứng dự trữ theo cây Merkle định kỳ, báo cáo lưu ký độc lập hoặc ý kiến kiểm toán chứng minh tỷ lệ bảo đảm 100%. Thứ tư, thỏa thuận khách hàng phải quy định rõ ràng trách nhiệm pháp lý đối với sự cố ngừng hoạt động, khôi phục hệ thống và bồi thường, bao gồm các trường hợp bất khả kháng, sự cố ở cấp độ chuỗi khối và sự cố từ bên thứ ba, nhằm ngăn chặn tranh chấp sau sự cố. Thứ năm, những khách hàng bị mất tiền do không thể thực hiện giao dịch trong thời gian ngừng hoạt động cần có một kênh khiếu nại và bồi thường rõ ràng, được tài trợ bởi quỹ dự phòng rủi ro hoặc bảo hiểm tùy theo tính chất của sự cố, thay vì chỉ nhận được lời từ chối chung chung là “bảo trì hệ thống”. Viết tất cả những điều này vào chính sách là bước đầu tiên; thử thách thực sự là thực thi nó trong điều kiện xảy ra sự cố.

10. Kiểm tra và Cải tiến Liên tục

Một Kế hoạch Ứng phó Sự cố (BCP) chưa từng được kiểm tra thì coi như không tồn tại. Việc kiểm thử cần được thực hiện theo từng tầng. Tầng một là các bài tập trên bàn, trong đó lãnh đạo và các vai trò chủ chốt mô phỏng một kịch bản sự cố để xác thực quy trình, vai trò và các mẫu thông báo. Tầng hai là các bài tập chuyển đổi dự phòng thành phần, tắt nguồn vật lý một cơ sở dữ liệu, nút hoặc vùng sẵn sàng trong khung thời gian thử nghiệm (canary) hoặc ngoài giờ cao điểm để xác thực cảnh báo, chuyển đổi dự phòng tự động và khôi phục. Tầng ba là chuyển đổi DR toàn hệ thống, di chuyển toàn bộ hệ thống sản xuất sang địa điểm DR trong một khoảng thời gian rồi quay lại, bao gồm các chức năng khớp lệnh, ví điện tử, thanh toán bù trừ, cổng thanh toán và thông báo. Tầng bốn là các hoạt động đội đỏ-xanh/tím và kỹ thuật gây rối, cố ý tạo ra sự cố và mô phỏng các cuộc tấn công để phát hiện các điểm yếu tiềm ẩn. Mỗi cuộc diễn tập cần có kế hoạch, các chỉ số quan sát, kế hoạch khôi phục và báo cáo tổng kết; danh sách các vấn đề được sử dụng để khắc phục với người chịu trách nhiệm cụ thể và thời hạn hoàn thành. Tần suất hợp lý là diễn tập trên bàn hàng quý, diễn tập thành phần một đến hai lần mỗi quý, chuyển đổi toàn bộ hệ thống ít nhất mỗi năm một lần, cùng với các cuộc diễn tập đột xuất sau những thay đổi lớn về kiến trúc. Các hồ sơ diễn tập nên được lưu giữ trong nhiều năm làm bằng chứng cho các cuộc kiểm tra tại chỗ của SC.

11. Bảo hiểm, Quỹ dự phòng và Sự phụ thuộc vào bên thứ ba

Các biện pháp kiểm soát kỹ thuật không thể bù đắp mọi tổn thất; bảo hiểm và quỹ dự phòng là hàng phòng thủ cuối cùng. Quỹ dự phòng rủi ro thường được tài trợ từ một phần trăm phí giao dịch, thặng dư thanh lý và vốn chuyên dụng, dùng để bù đắp tổn thất cho khách hàng do sự cố nền tảng, vi phạm an ninh và gian lận nội bộ; nguồn vốn, điều kiện sử dụng và quy trình phê duyệt của quỹ này cần được công bố. Bảo hiểm thương mại có thể được phân tầng: bảo hiểm tội phạm/bảo quản tài sản cho các trường hợp xâm phạm và trộm cắp tài sản quan trọng, bảo hiểm trách nhiệm mạng cho các cuộc tấn công và gián đoạn kinh doanh, cùng bảo hiểm D&O (Trách nhiệm của Ban Lãnh đạo và Quản lý) cho các quyết định quản lý, với mức bồi thường được xác định dựa trên số dư ví lạnh, khối lượng giao dịch hàng ngày và kỳ vọng của cơ quan quản lý. Các yếu tố phụ thuộc vào bên thứ ba cũng phải được đưa vào Kế hoạch Ứng phó Sự cố (BCP): nhà cung cấp dịch vụ đám mây, nhà cung cấp giải pháp chống DDoS, dịch vụ xác minh danh tính (KYC), hệ thống thanh toán, nguồn cấp dữ liệu thị trường, nút chuỗi khối và cổng thanh toán tiền pháp định đều là những điểm có thể gây sự cố. Các hợp đồng nên xác định các điều khoản SLA, quyền sở hữu dữ liệu, điều khoản rút lui và di chuyển, cũng như hợp tác khẩn cấp; các nhà cung cấp quan trọng cần có các phương án thay thế và bằng chứng về khả năng phục hồi của chính họ (SOC 2, ISO 27001, giấy phép theo quy định). Các bên thứ ba quan trọng nên được đánh giá lại và xem xét thường xuyên để đảm bảo nền tảng không chỉ mạnh mẽ mà không bị sụp đổ hoàn toàn chỉ vì sự cố của một nhà cung cấp duy nhất.

12. Triển khai Kế hoạch Ứng phó Sự cố (BCP) và Phục hồi Thảm họa (DR) của SoonTech

Nền tảng sàn giao dịch nhãn trắng của SoonTech dành cho các nhà điều hành được cấp phép tại Malaysia coi khả năng phục hồi hoạt động là một năng lực hàng đầu. Hệ thống khớp lệnh hỗ trợ chuyển đổi dự phòng chính-dự phòng nóng (primary-hot-standby) với sao chép nhật ký giao dịch (WAL) và cơ chế bầu chọn lãnh đạo dựa trên thời gian thuê (lease-based leader election), có thể triển khai trong các cấu trúc mạng hoạt động song song (active-active) hoặc DR từ xa (remote-DR) được thiết kế phù hợp với các mục tiêu RTO/RPO của khách hàng. Lớp ví tích hợp với các giải pháp MPC và đa chữ ký (multisig), với các phần chia sẻ khóa được phân tán trên các khu vực và nhà cung cấp khác nhau, đồng thời quy trình ký kết trong môi trường DR vẫn duy trì chính sách bảo mật như ban đầu mà không làm giảm tiêu chuẩn an ninh. Các mô-đun sao lưu tích hợp, lưu trữ WORM và đối chiếu tự động hỗ trợ đối chiếu bốn chiều hàng ngày giữa số dư trên chuỗi, sổ cái, giao dịch và chuyển tiền, kèm theo báo cáo kiểm toán có thể xuất ra. Các mô-đun giám sát và ứng phó sự cố bao quát cơ sở hạ tầng, ứng dụng, chỉ số kinh doanh và các sự kiện trên chuỗi, kèm theo cảnh báo dựa trên mức độ nghiêm trọng, công cụ phòng điều hành khẩn cấp, trang trạng thái và các mẫu thông báo cho khách hàng nhằm rút ngắn thời gian phản hồi. Về mặt tuân thủ, nền tảng cung cấp các mẫu tài liệu BCP, hồ sơ diễn tập, định dạng báo cáo sự cố và giao diện lưu trữ dữ liệu theo yêu cầu của các cuộc thanh tra tại chỗ của SC, đồng thời có thể tích hợp với SOC, đơn vị lưu ký và các công ty bảo hiểm của khách hàng. Đội ngũ triển khai của SoonTech hợp tác với khách hàng thông qua phân tích tác động kinh doanh, phân cấp RTO/RPO, đánh giá kiến trúc, hỗ trợ diễn tập và tài liệu dành cho cơ quan quản lý, thay vì chỉ đơn thuần bàn giao phần mềm.

13. Khuyến nghị triển khai cho doanh nghiệp

Đối với các nền tảng đang xin hoặc đã có giấy phép RMO DAX của Malaysia, chúng tôi khuyến nghị một lộ trình gồm bốn bước. Bước đầu tiên là phân tích tác động kinh doanh: xác định các chức năng kinh doanh quan trọng, các mối phụ thuộc, các điểm lỗi duy nhất và thời gian ngừng hoạt động tối đa có thể chấp nhận được, đồng thời lập danh mục phân cấp. Bước hai là kiến trúc mục tiêu: lựa chọn mô hình active-active, DR dự phòng ấm hoặc sao lưu lạnh cho từng cấp độ, tránh đầu tư quá mức vào các hệ thống không quan trọng đồng thời đảm bảo các hệ thống cốt lõi đáp ứng các yêu cầu của cơ quan quản lý và kỳ vọng của khách hàng. Bước ba là quy trình và chính sách: chuyển đổi các quy trình ứng phó sự cố, truyền thông, kiểm thử, khôi phục sao lưu và quản lý bên thứ ba thành các tài liệu hướng dẫn thực thi cụ thể, đồng thời đào tạo toàn bộ kỹ sư trực ca. Bước bốn là xác thực liên tục thông qua các cuộc diễn tập, giám sát, kiểm toán và phân tích sau sự cố để Kế hoạch Tiếp tục Hoạt động (BCP) trở thành năng lực vận hành liên tục thay vì một dự án nhất thời. Sự ủng hộ từ cấp lãnh đạo rất quan trọng: khả năng phục hồi cần được đặt ngang hàng với vốn, bảo hiểm và tuân thủ trong các cuộc họp quản lý, vì nó quyết định liệu nền tảng có thể tồn tại sau một sự cố hay không. Tránh hai thái cực — kiến trúc hoành tráng nhưng thiếu quy trình và diễn tập, hoặc tài liệu hướng dẫn mà không bao giờ được áp dụng. Sự kết hợp giữa hai yếu tố này là điều SC mong muốn và cũng là điều thực sự bảo vệ khách hàng.

Câu hỏi thường gặp

Câu hỏi 1: Ai nên thiết lập RTO và RPO?

Đáp: Bộ phận kinh doanh, tuân thủ và công nghệ nên cùng nhau xác định các chỉ tiêu này, với sự phê duyệt của ban lãnh đạo. Bộ phận công nghệ cung cấp dữ liệu về tính khả thi và chi phí, nhưng việc đặt mục tiêu một cách riêng rẽ sẽ khiến chúng tách rời khỏi thực tế kinh doanh và quy định. Các mục tiêu được đưa vào SLA và được xem xét lại sau những thay đổi lớn.

Câu hỏi 2: Mô hình active-active có loại bỏ nhu cầu về một địa điểm DR từ xa không?

Đáp: Không. Chế độ hoạt động kép (active-active) xử lý các sự cố tại trung tâm dữ liệu hoặc vùng sẵn sàng, nhưng không xử lý được các thảm họa quy mô thành phố hoặc sự cố ngừng hoạt động trên diện rộng ở khu vực đám mây. Các sàn giao dịch được cấp phép với các hệ thống cốt lõi thường vẫn cần một địa điểm DR từ xa để ứng phó với các sự cố ở cấp khu vực.

Câu hỏi 3: Địa điểm DR có nên xử lý lưu lượng trong thời gian bình thường không?

A: Lý tưởng nhất là có — dù chỉ là một phần nhỏ lưu lượng sản xuất hoặc thông qua các bài tập diễn tập định kỳ — để các phiên bản, cấu hình và dữ liệu luôn đồng bộ với hệ thống chính. Một hệ thống dự phòng “cold standby” không hoạt động thường không thể chuyển đổi khi thực sự cần thiết; các hệ thống dự phòng “warm standby” hoặc “active-active” đáng tin cậy hơn.

Câu hỏi 4: DR có làm tăng rủi ro rò rỉ khóa không?

A: Không, nếu được thiết kế đúng cách. DR sao chép các quy trình ký và các nút, chứ không bao giờ sao chép khóa dưới dạng văn bản thuần túy; các phần chia sẻ MPC được phân tán giữa các khu vực với cùng chính sách đa chữ ký, do đó DR không làm giảm mức độ bảo mật. Nó loại bỏ rủi ro rằng một sự cố khu vực duy nhất có thể chặn hoàn toàn các giao dịch rút tiền.

Câu hỏi 5: Các cuộc diễn tập có ảnh hưởng đến người dùng thực tế không?

A: Các cuộc diễn tập thành phần được thực hiện trong môi trường canary hoặc ngoài giờ cao điểm với khả năng khôi phục cấp hai; các quá trình chuyển đổi toàn bộ được kiểm chứng trước trong môi trường staging hoặc shadow rồi mới được lên lịch. Luôn kiểm tra trong môi trường cách ly trước khi tác động đến môi trường sản xuất, và thông báo trước nếu có khả năng ảnh hưởng đến người dùng.

Câu hỏi 6: Ai sẽ bồi thường cho người dùng khi họ bị thiệt hại do lỗi hệ thống?

A: Thỏa thuận với khách hàng quy định trách nhiệm pháp lý; quỹ dự phòng rủi ro và bảo hiểm sẽ bù đắp các tổn thất do lỗi nền tảng gây ra. Rủi ro hệ thống nền tảng không được chuyển sang người dùng; việc bồi thường tuân theo bản chất sự cố, điều khoản hợp đồng và các yêu cầu quy định.

Kết luận

Khả năng phục hồi hoạt động là năng lực cơ bản của một sàn giao dịch được cấp phép: các cơ quan quản lý yêu cầu khả năng phục hồi có thể kiểm chứng, chứ không phải các tài liệu được soạn thảo kỹ lưỡng. Việc kết nối các yếu tố như phân tầng RTO/RPO, kiến trúc đa địa điểm, chuyển đổi dự phòng cho hệ thống khớp lệnh và ví, sao lưu và đối chiếu, quy trình xử lý sự cố, bảo vệ tài sản khách hàng, các cuộc diễn tập định kỳ, cùng với bảo hiểm và quỹ dự phòng thành một vòng lặp khép kín chính là yếu tố giúp nền tảng bảo vệ khách hàng, vượt qua các cuộc kiểm tra và duy trì hoạt động khi sự cố thực sự xảy ra. Công nghệ chỉ là một phần; quy trình, con người, các cuộc diễn tập và cải tiến liên tục cũng quan trọng không kém.

🌐 Xây dựng các nền tảng Web3 an toàn và có khả năng mở rộng cùng SoonTech.

Khám phá các giải pháp của chúng tôi dành cho Sàn giao dịch tiền điện tử nhãn trắng, Thị trường dự đoán, Ví MPC, Hệ thống khớp lệnh, Tích hợp thanh khoản và Tuân thủ.