Nền tảng chịu tải cao, tuân thủ và luôn sẵn sàng cho ngân hàng

Trong hệ thống giao dịch tài chính, độ tin cậy không phải một mục tiêu để phấn đấu. Nó là điều kiện để được phép hoạt động. Điều đó đổi bản chất công việc: thay vì tối đa hoá tốc độ phát hành rồi xử lý hậu quả, phải quản trị được đánh đổi giữa tốc độ và ổn định bằng con số.

Đa vùng: câu hỏi thật là active-active hay active-passive

“Kiến trúc đa vùng” là một cụm từ dễ đồng ý và khó thực hiện, vì nó che mất câu hỏi quyết định: hai vùng cùng nhận tải, hay một vùng chờ. Chọn active-active thì phải giải quyết ghi đồng thời và xung đột dữ liệu. Chọn active-passive thì đơn giản hơn nhiều nhưng phải trả giá bằng thời gian chuyển đổi, và phải chấp nhận rằng vùng dự phòng chỉ đáng tin đến mức lần diễn tập gần nhất.

Quyết định này không nên xuất phát từ tầng ứng dụng mà từ RPO. RPO gần bằng không thì lựa chọn ở tầng dữ liệu bị thu hẹp rất nhanh, và chi phí tăng theo. RPO tính bằng phút thì mở ra nhiều phương án rẻ hơn đáng kể. Chốt RPO trước khi chọn công nghệ là cách tránh mua một giải pháp đắt hơn mức nghiệp vụ cần.

DR chỉ có thật khi đã diễn tập

Một kế hoạch DR có RTO/RPO viết trong tài liệu nhưng chưa từng được chạy thì không khác một giả định. Diễn tập là chỗ phát hiện những thứ không nằm trong sơ đồ: bản ghi DNS còn TTL dài, một chứng chỉ chỉ tồn tại ở vùng chính, một quyền truy cập mà người trực đêm không có.

• Diễn tập theo lịch, có kịch bản, và ghi lại thời gian thực tế từng bước.
• So thời gian thực tế với RTO đã cam kết — chênh lệch là hạng mục phải xử lý, không phải ghi chú.
• Diễn tập cả đường quay về vùng chính, không chỉ đường chuyển sang vùng dự phòng.
• Kiểm tra khôi phục backup định kỳ; một backup chưa từng khôi phục là một backup chưa được xác nhận.

Độ tin cậy là một chỉ số có thể quản trị: đặt SLO, đo error budget, và diễn tập sự cố trước khi nó xảy ra.

Error budget: cách nói “không” mà không cần tranh luận

SLO và error budget giải quyết một vấn đề tổ chức nhiều hơn là vấn đề kỹ thuật. Khi đội phát triển muốn phát hành nhanh và đội vận hành muốn ổn định, cuộc tranh luận thường kết thúc bằng quyền lực chứ không bằng dữ liệu. Error budget đổi nó thành một phép tính: còn ngân sách thì phát hành, hết ngân sách thì dừng tính năng và trả nợ độ tin cậy.

Ở hệ thống có mùa cao điểm, ngân sách này còn dùng để quyết định thời điểm đóng băng thay đổi — dựa trên mức tiêu thụ thực tế, thay vì dựa vào cảm nhận về mức độ rủi ro.

Giám sát bảo mật liên tục và dấu vết phục vụ kiểm toán

Yêu cầu kiểm toán ở khối tài chính thường xuất hiện dưới dạng một câu hỏi rất cụ thể: ai đã truy cập cái gì, khi nào, và bằng quyền nào. Trả lời được câu đó trong vài phút hay vài ngày là khác biệt giữa một hệ thống được thiết kế để giải trình và một hệ thống chỉ được thiết kế để chạy.

• Log tập trung, bất biến, có thời gian lưu đủ theo yêu cầu kiểm toán.
• Truy cập đặc quyền qua đường có ghi vết, không dùng tài khoản dùng chung.
• Giám sát bảo mật liên tục, gắn với quy trình xử lý sự cố theo mức độ.
• Kiểm soát thay đổi để mỗi thay đổi trên production truy được về một yêu cầu đã phê duyệt.

Kết quả

Nền tảng chịu tải qua mùa cao điểm, có đường phục hồi đã được diễn tập, đáp ứng yêu cầu tuân thủ và kiểm toán, và được vận hành theo kỷ luật SRE để cân bằng giữa tốc độ phát hành và độ ổn định.

Chỉ số cụ thể theo từng khách hàng không được công bố ở đây; chúng chỉ xuất hiện trong tài liệu có sự đồng ý của khách hàng.