Tích hợp hệ thống mới với phần mềm cũ mà không làm gãy vận hành

Bài toán khó nhất trong tích hợp hiếm khi là kỹ thuật. Nó là việc phải thay bánh xe khi xe đang chạy: hệ thống cũ vẫn phải phục vụ khách hàng mỗi ngày trong lúc bạn đấu nối cái mới vào.

Bốn cách kết nối, theo thứ tự nên thử

Nguyên tắc: luôn chọn cách ít xâm phạm hệ thống cũ nhất mà vẫn giải quyết được bài toán. Mỗi bậc đi xuống trong danh sách này là một bậc tăng rủi ro.

1. Hệ thống cũ có API — dùng API

Trường hợp dễ nhất và cũng hiếm nhất. Cần kiểm tra ba điều trước khi mừng: API có giới hạn số lần gọi không, có trả về đủ dữ liệu bạn cần không, và có ai đảm bảo nó sẽ không đổi không báo trước không.

2. Không có API nhưng có cơ sở dữ liệu truy cập được

Đọc trực tiếp từ cơ sở dữ liệu của hệ thống cũ. Bắt buộc phải dùng tài khoản chỉ có quyền đọc. Rủi ro chính là khi hệ thống cũ nâng cấp và đổi cấu trúc bảng, phần tích hợp của bạn gãy mà không ai biết cho tới khi có người phàn nàn. Hãy dựng kiểm tra tự động chạy hàng ngày để phát hiện sớm.

3. Trao đổi qua file

Cách cổ điển nhưng vẫn hiệu quả một cách đáng ngạc nhiên. Hệ thống cũ xuất file CSV theo lịch, hệ thống mới đọc vào. Ưu điểm là không đụng gì vào hệ thống cũ, dễ kiểm tra khi có sai lệch, và ai cũng hiểu được chuyện gì đang xảy ra. Nhược điểm là dữ liệu không tức thời — nếu nghiệp vụ chấp nhận độ trễ 15 phút hay một giờ thì đây thường là lựa chọn tốt nhất về tỉ lệ lợi ích trên rủi ro.

4. Bọc một lớp API bên ngoài hệ thống cũ

Viết một lớp trung gian đứng trước hệ thống cũ, cung cấp API hiện đại cho các hệ thống mới, còn bên trong nó nói chuyện với hệ thống cũ bằng bất kỳ cách nào khả thi. Tốn công nhất nhưng đáng làm khi bạn dự tính sẽ có nhiều hệ thống cần kết nối vào, hoặc khi có kế hoạch thay thế dần hệ thống cũ trong vài năm tới.

Ba câu hỏi quyết định kiến trúc

Đồng bộ hai chiều: nơi mọi thứ hay đổ vỡ

Khi cả hai hệ thống đều được phép sửa cùng một dữ liệu, sớm muộn sẽ có lúc hai bên sửa cùng lúc và giá trị khác nhau. Đây không phải trường hợp hiếm gặp, nó chắc chắn sẽ xảy ra.

Cách xử lý duy nhất bền vững là quy định trước, cho từng trường dữ liệu, bên nào là nguồn sự thật. Ví dụ: địa chỉ khách hàng lấy theo hệ thống CRM, còn công nợ lấy theo hệ thống kế toán. Khi có xung đột, bên không phải nguồn sự thật sẽ bị ghi đè, và hệ thống ghi lại nhật ký để người phụ trách rà lại.

Triển khai mà không làm gián đoạn

• Chạy song song trước khi cắt. Cho hệ thống mới chạy cùng hệ thống cũ ít nhất hai tuần, đối chiếu kết quả hàng ngày. Chênh lệch nào cũng phải giải thích được trước khi tắt hệ thống cũ.
• Chuyển từng nhóm người dùng. Bắt đầu bằng một phòng ban, hoặc một nhóm nhỏ chấp nhận rủi ro. Rút kinh nghiệm rồi mới mở rộng.
• Chuẩn bị đường lùi. Trước mỗi lần cắt chuyển, phải trả lời được: nếu hỏng thì quay về trạng thái cũ mất bao lâu, và ai là người ra quyết định quay lại.
• Không cắt vào thứ Sáu. Nghe có vẻ vụn vặt nhưng đây là kinh nghiệm chung của ngành. Cắt vào thứ Ba, còn ba ngày làm việc để xử lý những gì phát sinh.

Thứ hay bị bỏ quên: dữ liệu bẩn

Hệ thống cũ chạy mười năm thường tích lũy dữ liệu không nhất quán: cùng một khách hàng có ba bản ghi, số điện thoại lưu đủ kiểu định dạng, ngày tháng có bản ghi để trống. Hệ thống mới thường có ràng buộc chặt hơn và sẽ từ chối nhận những dữ liệu này.

Hãy dành thời gian khảo sát chất lượng dữ liệu ngay từ đầu dự án, không phải đến lúc chuyển đổi mới phát hiện. Trong nhiều dự án tích hợp, làm sạch dữ liệu chiếm nhiều thời gian hơn phần lập trình.

Đội ngũ kỹ thuật TRIUNITECH

Bài viết được biên soạn từ kinh nghiệm triển khai hạ tầng và phần mềm của đội ngũ. Không nhận tài trợ, không quảng cáo sản phẩm.