Hạ tầng cho các nền tảng giao dịch số doanh nghiệp

Các nền tảng số phục vụ doanh nghiệp — hợp đồng điện tử, hoá đơn điện tử, định danh, tài trợ thương mại, khảo thí, bảo hiểm — có một điểm chung ít được nói tới: tải của chúng không đều. Có nền tảng cả năm nhàn rỗi rồi dồn hết vào một kỳ; có nền tảng tăng theo từng chiến dịch của khách hàng doanh nghiệp.

Đặc điểm đó làm cho cách đầu tư cũ — mua phần cứng theo đỉnh — trở thành lãng phí phần lớn thời gian, và vẫn thiếu đúng vào lúc cần nhất.

Container hoá không phải là đóng gói lại rồi chạy

Phần dễ của việc chuyển sang container là viết Dockerfile. Phần khó nằm ở những giả định mà ứng dụng cũ mang theo: ghi file lên đĩa cục bộ, lưu session trong bộ nhớ tiến trình, dựa vào một job chạy trên đúng một máy, hoặc cấu hình nằm trong file được sửa tay.

• Trạng thái tách ra khỏi tiến trình: session và cache đưa ra ngoài, file đưa sang object storage.
• Cấu hình đưa vào biến môi trường và secret, không nằm trong image.
• Job định kỳ chuyển sang cơ chế có khoá, để nhiều bản chạy song song không làm việc trùng.
• Health check phân biệt được “đang sống” và “sẵn sàng nhận tải” — hai thứ này khác nhau, và nhầm lẫn giữa chúng là nguyên nhân phổ biến của lỗi khi rollout.

Bỏ qua bước này thì hệ thống vẫn chạy trên Kubernetes, nhưng không mở rộng được — và đội vận hành sẽ giữ số bản sao ở đúng một, vì tăng lên là sai dữ liệu.

Phát hành từng phần thay vì phát hành toàn bộ

Với nền tảng nhiều người dùng, rủi ro không nằm ở việc phát hành thường xuyên mà ở việc phát hành cho toàn bộ người dùng cùng lúc. Progressive delivery đổi câu hỏi từ “bản này có lỗi không” thành “bản này có lỗi với bao nhiêu phần trăm người dùng, và ta phát hiện sau bao lâu”.

• Canary theo tỷ lệ tăng dần, với chỉ tiêu tự động quyết định tiếp tục hay dừng.
• Feature flag để tách thời điểm triển khai mã khỏi thời điểm bật tính năng.
• Quay lui bằng cách tắt cờ, nhanh hơn nhiều so với triển khai lại phiên bản trước.
• Quét bảo mật trong pipeline: SAST, SCA và quét image, chặn ngay tại bước phát hành.

Ứng dụng mở rộng theo tải thay vì nâng cấp phần cứng — và phát hành từng phần để giảm rủi ro.

Chi phí đi theo tải, nhưng chỉ khi có người theo dõi

Chạy trên Kubernetes không tự làm chi phí hợp lý. Autoscaling đặt sai ngưỡng có thể đắt hơn máy chủ cố định, và request/limit khai quá tay khiến cluster phải giữ tài nguyên cho những pod không dùng đến. Phần tiết kiệm thật đến từ việc đo tải thực rồi chỉnh, và lặp lại việc đó theo quý.

Chỉ số nên theo dõi là chi phí trên một giao dịch hoặc một người dùng hoạt động. Nhìn tổng hoá đơn thì không phân biệt được tăng vì kinh doanh lớn lên hay tăng vì cấu hình sai.

Kết quả

Các nền tảng vận hành ổn định ở quy mô lớn, phát hành nhanh với phạm vi rủi ro được giới hạn, và chi phí hạ tầng đi theo nhu cầu thực thay vì theo đỉnh dự phòng.

Số liệu chi tiết theo từng nền tảng chỉ được đưa vào tài liệu có sự đồng ý của khách hàng.