Giới thiệu
Trong thế giới Core Banking, đặc biệt là phân hệ Loan Origination System (LOS – Hệ thống khởi tạo khoản vay), ranh giới giữa một Kỹ sư thực thụ và một người viết code thông thường nằm ở cách họ quản lý Configuration (tham số). Hệ thống nào vẫn đang vận hành với việc lưu Business Rules trong Database, thực chất đang tiềm ẩn rủi ro hệ thống rất lớn.
Nhiều đội ngũ chọn đưa Configuration Data vào Database vì sự tiện lợi: Ops (Đội ngũ vận hành) có thể thay đổi ngay lập tức thông qua các công cụ Admin mà không cần thực hiện quy trình deploy phức tạp. Tuy nhiên, đây lại là một sự đánh đổi vô cùng nguy hiểm cho sự ổn định của hệ thống.
Cái bẫy Tiện lợi và 3 nhược điểm cốt lõi của DB-based Config
Việc quản lý cấu hình trực tiếp trong DB lộ ra những lỗ hổng bảo mật và vận hành nghiêm trọng:
- Thiếu quy trình kiểm duyệt minh bạch: Audit Log trong DB thường chỉ mang tính chất ghi nhận sau khi sự cố đã xảy ra. Rất khó để thực hiện quy trình review (đánh giá) minh bạch, đa bên trước khi một record (bản ghi) cấu hình quan trọng được cập nhật.
- Quá tải khi mở rộng (Scalability): Khi hệ thống mở rộng với hàng trăm Loan Product (Sản phẩm vay), việc quản lý cấu trúc JSON/Data phức tạp trong table sẽ trở nên cực kỳ khó kiểm soát và dễ sai sót.
- Phản ứng dây chuyền từ sai lầm con người: Chỉ cần một thao tác sai sót của Ops trên Admin Tool, hệ thống sẽ tiếp nhận tham số lỗi ngay lập tức mà không có cơ chế tự động ngăn chặn hoặc validation (xác thực) nào đủ mạnh ở tầng DB.
Dịch chuyển sang GitOps: Đối xử với Rules như Source Code
Đã đến lúc đối xử với Underwriting Rules (Các quy tắc thẩm định như Base Rate, Risk Factor, LTV Ratio…) như Source Code quan trọng. Hãy biến chúng thành First-class Citizen (thành phần được ưu tiên cấp cao) trong Git Repository.
Trong mô hình này, mọi thay đổi cấu hình bắt buộc phải đi qua quy trình Pull Request (PR). Quá trình này giúp chấm dứt việc can thiệp cấu hình tùy tiện. Tech Lead hoặc PM (Quản lý sản phẩm) sẽ thực hiện Code Review và kiểm chứng từng thay đổi nhỏ. Quy trình này là bắt buộc để đảm bảo chất lượng và tính bền vững của hệ thống.
Bên cạnh đó, việc tích hợp CI Pipeline (Quy trình tích hợp tự động) cho phép loại bỏ ngay những cấu hình không hợp lệ trước khi chúng được áp dụng. Quy trình tự động này sẽ giúp giảm thiểu tối đa sai sót đến từ rủi ro con người.
Giải quyết bài toán Configuration Drift và tầm quan trọng của cơ chế Read-only
Thách thức lớn nhất đối với GitOps là Configuration Drift – hiện tượng xảy ra khi có sự can thiệp trực tiếp vào DB trên môi trường Production để hot-fix (sửa lỗi nhanh). Giải pháp tối ưu là sử dụng một Reconciler (Công cụ đồng bộ) chạy định kỳ để phát hiện và đồng bộ hóa mọi sai lệch.
Git Repo nên được xem là Single Source of Truth (Chân lý duy nhất). Reconciler sẽ tự động ghi đè mọi thay đổi không hợp lệ trên DB để đưa hệ thống về đúng trạng thái đã được kiểm duyệt trên Git.
Tuy nhiên, cần lưu ý: Reconciler chỉ nên đóng vai trò là lớp kiểm toán an toàn kép (Double Paranoia Check). Để ngăn chặn lỗ hổng thời gian (race condition) khi công cụ Change Data Capture (CDC) ở mạch dưới bắt nhầm dữ liệu từ các thao tác sửa chữa thủ công trên DB và làm nhiễu loạn toàn bộ hệ thống Cache trước khi Reconciler kịp quét, quyền can thiệp (Write access) trực tiếp vào Config DB phải được cấu hình thu hồi hoàn toàn. Config DB lúc này giữ vai trò là “Read-only” đối với con người.
Tối ưu hiệu năng: Kiến trúc Multi-level Caching và CDC
Để đảm bảo hiệu năng tối đa cho hệ thống giao dịch tốc độ cao, cấu hình từ Git không chỉ được lưu trữ bề mặt mà còn phải được phân bổ đi qua nhiều tầng Cache, kết hợp cùng cơ chế Cache Refresher đồng bộ mạnh mẽ. Cơ sở dữ liệu (DB) lúc này lùi lại đóng vai trò là lớp lưu trữ kiên cố (Persistent Layer), không phải là nơi ứng dụng trực tiếp truy vấn liên tục.
Đặc biệt, các hệ thống thẩm định giá (Pricing) hay chấm điểm tín dụng (Scoring) đòi hỏi độ trễ cực thấp (Ultra-low Latency) ở cấp độ mili-giây. Do đó, mô hình đa tầng Cache (Multi-level Caching) là thành phần bắt buộc trong kiến trúc.
Sự kết hợp giữa L1/L2 Cache và Cache Refresher đảm bảo hai yếu tố then chốt:
- Hiệu suất truy xuất tuyệt đối: Ứng dụng sẽ ưu tiên đọc thông số ngay từ Local Cache (L1) trong bộ nhớ vùng chạy. Nếu xảy ra trường hợp Cache Miss, hệ thống mới truy vấn đến Distributed Cache (L2 – ví dụ Redis). DB chỉ được cấp quyền truy cập phục vụ trong những kịch bản Fallback hoặc Audit.
- Tính nhất quán hệ thống liên tục: Bất kỳ thay đổi hợp lệ nào từ quy trình GitOps, sau khi cập nhật vào DB, sẽ ngay lập tức được Change Data Capture (CDC) hoặc Webhook tiếp nhận. Hệ thống Cache Refresher lập tức đẩy lệnh Invalidate (Làm mới) đến mọi node ứng dụng đang chạy. Nhờ đó, các node tự động nạp lại quy tắc kinh doanh mới một cách mượt mà không tạo ra thời gian gián đoạn (Zero-downtime).
Lời khuyên
Quản lý cấu hình trong Database thường bộc lộ nhiều rủi ro khi hệ thống mở rộng. Chuyển sang GitOps là tiêu chuẩn của các kiến trúc chuyên nghiệp, nơi sự an toàn và tính kỷ luật luôn được ưu tiên cao hơn sự tiện lợi tạm thời.
Nhiều đội ngũ có thể vẫn chấp nhận rủi ro: Áp dụng DB Config cho nhanh thay vì thiết lập quy trình GitOps chuẩn chỉnh. Mặc dù cách này tiết kiệm công sức ban đầu, nhưng hệ lụy là toàn bộ khối kỹ thuật có thể mất rất nhiều thời gian khắc phục sự cố sau này, chỉ để truy vết một lỗi nhập liệu nhỏ nhặt trong cấu hình lãi suất.
Khi xảy ra sự cố nghiêm trọng gây thất thoát tài chính, những dòng log cơ bản trong cơ sở dữ liệu sẽ không đủ thiết thực để giúp doanh nghiệp kiểm soát triệt để các rủi ro hệ thống.
Trích: Huy Võ – Kỹ Sư Công Nghệ tại National Australia Bank (NAB) & TymeBank
