Giải cứu tích hợp API cho hệ thống hiện có
- Câu trả lời ngắn:* Việc tích hợp API bị lỗi phải được kiểm tra trước khi bất kỳ ai tiếp tục vá nó. Quyết định đúng đắn phụ thuộc vào việc liệu sự cố có phải là sự cố ánh xạ nhỏ, thiếu lớp điều khiển hay thiết kế hệ thống bị hỏng.
# Quá trình tích hợp không thành công trông như thế nào
Các triệu chứng có thể nhìn thấy thường dễ mô tả:
- Đôi khi đồng bộ hóa bản ghi nhưng không phải lúc nào cũng vậy
- Hồ sơ thất bại là vô hình cho đến khi ai đó phàn nàn
- Xuất hiện đơn hàng hoặc hóa đơn trùng lặp
- Cập nhật chứng khoán trễ hoặc sai
- Việc tích hợp bị hỏng sau một thay đổi cài đặt nhỏ
- Nhân viên lập bảng tính để “kiểm tra kỹ” việc tích hợp
- Nhà phát triển ban đầu không còn nữa
Những vấn đề này không chỉ là kỹ thuật. Họ làm tổn hại đến niềm tin vào hệ thống. Sau khi nhóm ngừng tin tưởng vào sự tích hợp, họ sẽ bắt đầu giải quyết vấn đề đó.
# Trình tự kiểm tra cứu hộ
Chúng tôi không bắt đầu bằng cách viết lại mã. Chúng tôi bắt đầu bằng cách tìm ra mô hình thất bại.
- Lập bản đồ quy trình dự kiến. Việc tích hợp nhằm mục đích gì?
- Lập bản đồ quy trình thực tế. Nhân viên đang làm gì bên ngoài hệ thống?
- Thu thập các mẫu không đạt. Hồ sơ sai, trùng lặp, thiếu hồ sơ và vấn đề về thời gian.
- Kiểm tra nhật ký và tải trọng. Xác nhận xem lỗi bắt đầu từ nguồn, phần mềm trung gian hay đích.
- Kiểm tra các quy tắc về nguồn gốc sự thật. Xác định hệ thống nào sở hữu từng trường.
- Xem lại xác thực. Tìm những bản ghi xấu nào đáng lẽ phải bị chặn.
- Quyết định vá lỗi, ổn định hoặc xây dựng lại. Chọn con đường có rủi ro thấp nhất dựa trên bằng chứng.
Đây là phiên bản dành riêng cho việc tích hợp của kiểm tra hệ thống và cứu hộ ERP.
# Vá, ổn định hoặc xây dựng lại
| Tìm kiếm | Con đường tốt nhất |
|---|---|
| Một lỗi ánh xạ | Vá và kiểm tra một lô được kiểm soát |
| Thiếu nhật ký | Thêm ghi nhật ký trước khi thay đổi logic nghiệp vụ |
| Đăng bài trùng lặp | Thêm tính bình thường và các tài liệu tham khảo bên ngoài độc đáo |
| Hồ sơ xấu vào đích | Thêm xác thực và hàng đợi ngoại lệ |
| Giả định về quy trình làm việc là sai | Thiết kế lại quy trình trước khi mã hóa |
| Không có mã hoặc quyền truy cập | Xây dựng lại sự tích hợp xung quanh các quy tắc được ghi lại |
Mục tiêu không phải là giải cứu mã xấu bằng mọi giá. Mục tiêu là bảo vệ hoạt động kinh doanh với cách khắc phục ít rủi ro nhất.
# Tại sao việc giải cứu thường trở thành việc thiết kế lại quy trình làm việc
Nhiều hoạt động tích hợp không thành công vì chúng được xây dựng dựa trên việc truyền dữ liệu chứ không phải một quy trình. Ví dụ: "gửi đơn đặt hàng tới ERP" nghe có vẻ đơn giản cho đến khi trả lại, giao hàng một phần, kho chi nhánh, giá cả và phê duyệt dành riêng cho khách hàng xuất hiện.
Khi những quy tắc đó là có thật, quá trình tích hợp cần có một lớp quy trình làm việc chứ không chỉ là tập lệnh.
Câu hỏi thường gặp
# Bạn có thể cứu một phần tích hợp mà không có nhà phát triển ban đầu không?
Thỉnh thoảng. Nếu mã và thông tin đăng nhập có sẵn, việc tiếp quản sẽ dễ dàng hơn. Nếu không, chúng tôi vẫn có thể kiểm tra quy trình làm việc hiện tại và thiết kế tích hợp thay thế.
# Làm cách nào để tránh gián đoạn hoạt động trực tiếp trong quá trình cứu hộ?
Chúng tôi tách biệt đường dẫn đồng bộ hóa rủi ro, thử nghiệm với số lượng bản ghi hạn chế và tránh những thay đổi hàng loạt cho đến khi hiểu được kiểu lỗi.
# Vá hay xây dựng lại có rẻ hơn không?
Nó phụ thuộc vào việc thiết kế ban đầu có hợp lý hay không. Việc vá lỗi chỉ rẻ hơn khi lỗi được thu hẹp và khả năng tích hợp có thể duy trì được.
- Kiểm tra sự tích hợp của tôi*