Tích hợp bên thứ ba

Tích hợp bên thứ ba là gì?

Rất ít thứ trong một sản phẩm thương mại điện tử hay fintech do đội bạn tự làm hết. Tiền đi qua cổng thanh toán (MoMo, VNPay, thẻ ngân hàng). Xác minh danh tính đi qua nhà cung cấp eKYC. Mã OTP đi qua nhà cung cấp SMS. Đơn hàng đi qua đơn vị vận chuyển (GHN, GHTK). Mỗi cái là một hệ thống của người khác, chạy trên máy chủ của người khác, theo lịch bảo trì của người khác.

Hệ quả quan trọng nhất với BA/PO: code của đội bạn có thể đúng hoàn toàn mà khách hàng vẫn không đặt được hàng. Nhưng khách không phân biệt được điều đó — với họ chỉ có một câu: "app của các anh lỗi". Nên dù chỗ hỏng nằm bên kia ranh giới, trạng thái mà khách nhìn thấy vẫn luôn là việc của ta, và nó phải được viết ra trong spec chứ không phải để dev tự nghĩ.

Thêm một điều dễ bất ngờ: môi trường test thường không nối tới hệ thống thật của nhà cung cấp mà nối tới bản sandbox của họ. Sandbox trả lời nhanh, không bao giờ bận, không áp giới hạn và luôn cho kết quả thành công. Nghĩa là mọi trạng thái lỗi mà bạn quan tâm nhất lại chính là những trạng thái không tự xuất hiện khi test.

Baseline — bạn hiểu

• Sản phẩm chạy trên các nhà cung cấp (thanh toán, eKYC, SMS/OTP, vận chuyển) — lỗi và giới hạn của họ ảnh hưởng tới ta ngay cả khi code ta đúng.
• Môi trường staging thường không có nhà cung cấp thật, nên các trạng thái lỗi không tự xuất hiện khi test.
• Khách hàng không nhìn thấy ranh giới đó; trạng thái hiển thị cho họ luôn là trách nhiệm của ta.

Working — bạn làm được

• Biết ranh giới nhà cung cấp và ta trong luồng của mình: bước nào đi ra ngoài, mất bao lâu, hỏng thì ai chịu.
• Spec trạng thái chờ và trạng thái thất bại cho mọi bước đi qua nhà cung cấp — kể cả trường hợp họ không trả lời gì cả.
• Kiểm tra giới hạn của từng nhà cung cấp trước khi cam kết một con số quy mô với stakeholder.

Cơ chế hoạt động

Ví dụ theo cấp độ

Cơ bản — Khách báo "đã trừ tiền mà không có đơn": lỗi ở ta hay ở cổng thanh toán?

Tình huống: khách nhắn vào trang chăm sóc khách hàng: "Tôi thanh toán bằng MoMo, tiền đã bị trừ nhưng trong app không có đơn nào." Trong nhóm chat của đội, câu đầu tiên mọi người hỏi nhau là "lỗi của mình hay lỗi của MoMo?" — và thường không ai trả lời được, nên ticket nằm im nửa ngày.

Chia luồng thành ba đoạn, mỗi đoạn hỏng theo một kiểu khác nhau:

1. Ta gửi yêu cầu tạo giao dịch sang cổng thanh toán.
2. Cổng thanh toán xử lý và trừ tiền của khách.
3. Cổng thanh toán báo kết quả về cho ta, và ta ghi nhận đơn hàng.

Tiền đã bị trừ nghĩa là đoạn 1 và đoạn 2 đã xong. Vấn đề nằm ở đoạn 3 — hoặc họ chưa báo về, hoặc họ đã báo mà ta xử lý lỗi. Chỉ riêng việc nói được câu này đã thu hẹp phạm vi từ cả luồng xuống một đoạn.

Hai thứ phải lấy trước khi hỏi bất kỳ ai:

• Mã giao dịch phía nhà cung cấp (transaction id, mã tham chiếu). Đây là số duy nhất mà cả ta và họ cùng tra được. Không có nó thì mọi cuộc trao đổi với nhà cung cấp đều dừng ngay ở câu "anh cho tôi mã giao dịch", và mất thêm một vòng hỏi khách.
• Thời điểm chính xác kèm múi giờ, vì hệ thống của họ có thể ghi log theo múi giờ khác.

Bug report copy được nguyên văn:

Khách 09xxxxxxxx, đơn DH-88421, ngày 12/08 lúc 20:14 (giờ Việt Nam).
Thanh toán MoMo, mã giao dịch phía MoMo: 2408122014xxxx, số tiền 349.000đ.
Tiền đã bị trừ — khách gửi ảnh biến động số dư lúc 20:14.
Trên hệ thống ta: đơn đang ở trạng thái "Chờ thanh toán", không có bản ghi nào
trong bảng giao dịch sau 20:14.

Câu hỏi cho dev: mình có nhận được kết quả nào từ MoMo cho mã giao dịch này không?
  - Có, nhưng xử lý lỗi  -> việc của mình, ưu tiên cao.
  - Không nhận được gì   -> cần đối soát với MoMo, và mình phải có cơ chế
                            tự hỏi lại trạng thái thay vì chỉ ngồi chờ họ báo.

Học được: "lỗi ở đâu" không phải câu hỏi cảm tính. Nó được trả lời bằng một mã giao dịch và đúng một câu hỏi: ta có nhận được kết quả từ họ không. Và dù câu trả lời là gì, khách vẫn là khách của ta — nên đơn kẹt ở "Chờ thanh toán" mà không ai xử lý là vấn đề của ta, không phải của MoMo.

Trung bình — Vẽ ranh giới rồi spec trạng thái cho từng bước đi ra ngoài

Tình huống: bạn spec luồng mở tài khoản có xác minh danh tính. Người dùng chụp CCCD, chụp khuôn mặt, hệ thống gửi sang nhà cung cấp eKYC để đối chiếu.

Bước 1 — liệt kê từng bước và đánh dấu bước nào ra khỏi hệ thống của ta:

Bước 2 — mọi bước đánh dấu "Có" đều cần đủ bốn trạng thái, thiếu một cái là một lỗ hổng:

Điều mà chỉ BA nghĩ ra được: phân biệt "họ trả lời là không đạt" với "họ không trả lời". Trong code, nếu không ai spec, hai trường hợp này rất dễ bị gộp làm một nhánh lỗi chung. Nhưng với người dùng thì một bên nghĩa là "ảnh của tôi có vấn đề", một bên nghĩa là "hệ thống đang hỏng". Nói nhầm sẽ khiến khách chụp đi chụp lại năm lần, càng chụp càng thất vọng, rồi bỏ luôn việc mở tài khoản — và trong báo cáo, con số đó hiện ra dưới dạng "tỷ lệ hoàn tất eKYC thấp", không ai biết nguyên nhân.

Các dòng viết vào spec, copy được:

• "Mọi lần gọi nhà cung cấp eKYC đều lưu mã yêu cầu của họ vào bản ghi hồ sơ, kể cả khi lần gọi đó thất bại."
• "Quá 60 giây chưa có kết quả: chuyển màn hình sang trạng thái 'đang xử lý', cho phép người dùng thoát ra và gửi thông báo khi có kết quả. Không bắt người dùng ngồi nhìn vòng quay."
• "Người dùng chụp lại quá 3 lần: dừng gọi tự động và chuyển sang kiểm tra thủ công — mỗi lần gọi đều tính phí theo hợp đồng."
• "AC: ngắt kết nối tới nhà cung cấp trên môi trường test thì màn hình phải hiện trạng thái 'hệ thống xác minh đang bận', không được treo vô hạn và tuyệt đối không được hiện 'CCCD không hợp lệ'."

Học được: ranh giới ta và nhà cung cấp không phải kiến thức kỹ thuật, nó là danh sách những chỗ spec của bạn phải có thêm trạng thái. Đánh dấu xong các bước đi ra ngoài, bạn biết chính xác mình còn thiếu bao nhiêu màn hình — và đó là những màn hình không ai vẽ nếu bạn không yêu cầu.

Nâng cao — Nhà cung cấp cho 100 request mỗi phút, chiến dịch cần 500

Tình huống: marketing chốt flash sale 20:00 ngày 20/08, dự kiến 5.000 đơn trong giờ đầu. Mỗi đơn gửi một mã OTP qua SMS để xác nhận, cộng một tin nhắn báo đặt hàng thành công — tức hai tin cho mỗi đơn. Trong buổi họp, bạn đã gật đầu.

Con số thật, tính ra sau khi về bàn. Đây là phép tính lẽ ra phải làm trước khi gật đầu, và nó chỉ mất hai phút:

5.000 đơn trong 60 phút, nhưng không rải đều:
  mười phút đầu chiếm khoảng một nửa   ->  2.500 đơn trong 10 phút
                                       ->  250 đơn mỗi phút
  mỗi đơn 2 tin (OTP + báo thành công) ->  500 tin nhắn mỗi phút ở đỉnh

Hợp đồng với nhà cung cấp SMS: 100 request mỗi phút; vượt thì họ trả về
lỗi 429 và không gửi.
  ->  thiếu 400 khe mỗi phút, suốt mười phút đông nhất của chiến dịch.

Chú ý phép tính trung bình, vì nó ru ngủ: 5.000 đơn chia đều 60 phút chỉ là 83 đơn mỗi phút, nghe như 100 khe mỗi phút vẫn còn thừa. Con số 83 đó sai theo hai cách cùng lúc, và hai cái sai nhân vào nhau chứ không cộng:

5.000 đơn / 60 phút                              ~  83 đơn/phút   <- mức trung bình
  x 3   mười phút đầu đông gấp ba mức trung bình  ->  250 đơn/phút
  x 2   mỗi đơn tốn hai khe, không phải một       ->  500 tin nhắn/phút ở đỉnh

500 tin nhắn/phút = gấp năm lần trần 100 request/phút của nhà cung cấp.

Cái làm hỏng chiến dịch không bao giờ là mức trung bình. Khi so lưu lượng với giới hạn của nhà cung cấp, luôn so ở đỉnh, và luôn so đúng đơn vị mà họ đếm — họ đếm request, không đếm đơn hàng.

Cái bẫy, gọi tên thẳng: đừng cam kết một con số quy mô trước khi đọc giới hạn của từng nhà cung cấp trong luồng đó. Giới hạn này không nằm trong code của ta, không ai trong đội dev nhìn thấy nó hằng ngày, và nó không lộ ra ở môi trường test — sandbox của nhà cung cấp thường không áp cùng giới hạn với hệ thống thật. Nghĩa là mọi thứ chạy hoàn hảo trong suốt quá trình chuẩn bị, cho tới đúng 20:03 ngày mở bán.

Cái giá, nếu chạm trần. 400 tin mỗi phút bị từ chối — nhưng con số phải mang vào cuộc họp không phải số tin, mà số khách. Và nó phụ thuộc vào việc ta có ưu tiên OTP hay không:

• Không phân loại ưu tiên: dòng tin gửi ra là một nửa OTP, một nửa báo thành công, nên trong 100 khe mỗi phút chỉ khoảng 50 mã OTP đi qua. 250 khách bắt đầu đặt hàng mỗi phút mà chỉ 50 người nhận được mã: 200 khách mỗi phút không hoàn tất được, tức khoảng 2.000 khách trong mười phút đầu.
• Đã ưu tiên OTP tuyệt đối (tin báo thành công bị xếp hàng lại hết): 100 khe vẫn chỉ phục vụ được 100 trong 250 khách mỗi phút, tức 150 khách mỗi phút, khoảng 1.500 khách. Nói cách khác, xếp hàng ưu tiên chỉ giảm được thiệt hại từ 2.000 xuống 1.500 — nó không cứu được chiến dịch. Trần vẫn phải nâng, và phải nâng từ trước.

Không nhận được OTP nghĩa là không đặt hàng được, không phải đặt chậm. Cộng thêm: tổng đài quá tải vì tất cả cùng gọi một lúc, đội vận hành không biết chuyện gì đang xảy ra vì hệ thống của ta không báo lỗi gì cả (lỗi nằm ở phía họ), và flash sale chỉ diễn ra một lần nên không có cách nào "chạy lại". Doanh thu mất đi trong mười phút đó không lấy lại được bằng bất kỳ bản vá nào.

Năm việc phải làm, theo đúng thứ tự:

1. Hỏi con số trước khi gật đầu. Ba câu, hỏi thẳng nhà cung cấp hoặc đọc trong hợp đồng: "Giới hạn bao nhiêu request mỗi giây và mỗi phút?", "Vượt thì bị chặn hay bị tính thêm tiền?", "Có nâng tạm thời cho một ngày cụ thể được không, cần báo trước bao lâu?"
2. Đăng ký nâng trần trước. Nhiều nhà cung cấp nâng được nếu báo trước 5–10 ngày làm việc. Đây là việc của tuần này, không phải chiều 20/08.
3. Xếp hàng và phân loại ưu tiên — nhưng phải tính sức chứa của hàng đợi. "SMS chứa mã OTP thuộc nhóm phải gửi ngay; SMS báo đặt hàng thành công được xếp hàng lại." Ở đỉnh, riêng OTP đã cần 250 khe nên nó chiếm trọn 100 khe mỗi phút và không còn khe nào cho tin báo thành công: cả 250 tin mỗi phút đều dồn vào hàng đợi, chạm 2.000 tin vào khoảng phút thứ tám. Tệ hơn, hết đỉnh cũng không có chỗ trả nợ — 2.500 đơn còn lại rải trên 50 phút là 50 đơn mỗi phút, nhân hai vẫn đúng 100 khe, tức dư ra không khe nào để đẩy hàng đợi đi. Vì vậy dòng viết vào spec là: "Hàng đợi tin báo thành công vượt 2.000 thì ngừng xếp thêm và chuyển sang báo trong ứng dụng — không nuôi một hàng đợi không bao giờ vơi, vì một tin nhắn tới sau nửa tiếng chẳng còn tác dụng gì."
4. Spec sẵn hành vi khi bị chặn. "Nhà cung cấp trả về 429: thử lại sau 1, 2, rồi 5 giây, tối đa 3 lần. Vẫn 429 thì hiện cho khách 'Mã xác nhận đang tới chậm hơn bình thường, bạn chờ thêm một chút' kèm nút gửi lại bị khoá 60 giây, đồng thời gửi cảnh báo vào kênh trực của đội vận hành. Không hiện 'Gửi mã thất bại' rồi đứng im, vì khách sẽ bấm lại liên tục và làm hàng đợi tệ hơn."
5. Cân nhắc nhà cung cấp dự phòng — trước, không phải lúc 20:05. "Có nhà cung cấp SMS thứ hai đã tích hợp sẵn và được thử định kỳ; khi tỷ lệ lỗi của nhà cung cấp chính vượt 20% trong 5 phút thì tự chuyển sang dự phòng." Đây là quyết định có chi phí (phí tích hợp, phí duy trì), nên nó phải được đưa ra ở bàn họp chứ không phải trong lúc chữa cháy.

Câu hỏi bạn phải hỏi trong buổi họp chốt chiến dịch, trước khi gật đầu: "Con số 5.000 đơn này đi qua những nhà cung cấp nào, và giới hạn của từng bên là bao nhiêu?" Nếu chưa ai trả lời được thì câu trả lời cho marketing chưa phải là "được", mà là "để tôi xác nhận trong hai ngày". Một câu đó là toàn bộ phần việc của BA ở đây.

Học được: giới hạn của nhà cung cấp là một điều khoản hợp đồng chứ không phải một thông số kỹ thuật — nên nó thuộc về BA/PO, không phải về dev. Và nó có một đặc tính khó chịu: chỉ lộ ra đúng vào lúc đông khách nhất, tức là lúc đắt nhất để phát hiện.

Áp dụng khi viết spec

Với mỗi luồng có bước đi qua nhà cung cấp, ticket của bạn phải trả lời được năm câu:

1. Bước nào trong luồng này đi ra khỏi hệ thống của ta, và mất bao lâu là bình thường?
2. Trạng thái chờ hiển thị thế nào, và người dùng có được thoát ra rồi nhận thông báo sau không?
3. Ta phân biệt "họ trả lời là thất bại" với "họ không trả lời" như thế nào, và người dùng thấy hai câu khác nhau chứ?
4. Mã giao dịch phía họ được lưu ở đâu, kể cả khi lần gọi đó thất bại?
5. Giới hạn request của họ là bao nhiêu, và lưu lượng dự kiến của ta là bao nhiêu?

Câu hỏi nên hỏi dev

• "Luồng này gọi những nhà cung cấp nào, ở những bước nào?"
• "Mình chờ họ tối đa bao nhiêu giây rồi mới bỏ cuộc? Sau đó màn hình hiện gì?"
• "Mình có lưu mã giao dịch của họ không, và tra ở đâu khi khách khiếu nại?"
• "Nếu họ gửi kết quả về hai lần thì hệ thống có tạo hai đơn không?"
• "Môi trường test đang nối tới sandbox hay hệ thống thật của họ? Sandbox có áp giới hạn giống thật không?"
• "Giới hạn request theo hợp đồng là bao nhiêu, và mình đang dùng tới đâu vào giờ cao điểm?"
• "Khi họ chậm hoặc lỗi, đội mình có được cảnh báo tự động không hay phải chờ khách báo?"

Sai lầm thường gặp

• Viết spec như thể bước gọi nhà cung cấp diễn ra tức thì và luôn thành công.
• Gộp "họ trả lời là không đạt" với "họ không trả lời" thành một thông báo lỗi chung.
• Không lưu mã giao dịch phía họ, nên mọi khiếu nại đều phải hỏi lại khách hàng.
• Coi test xanh trên sandbox là bằng chứng hệ thống chạy được ở quy mô thật.
• Cam kết quy mô chiến dịch trước khi kiểm tra giới hạn của từng nhà cung cấp.
• Không xử lý trường hợp họ gửi kết quả hai lần, dẫn tới ghi nhận trùng trong luồng tiền.
• Đổ lỗi cho nhà cung cấp và dừng lại ở đó, trong khi màn hình khách nhìn thấy vẫn chưa được spec.
• Không có ai được cảnh báo khi nhà cung cấp hỏng — sự cố được phát hiện bởi tổng đài.

Definition of done — dấu hiệu bạn đã đạt

• Bạn vẽ được ranh giới ta và nhà cung cấp cho mọi luồng trong khu vực của mình.
• Mọi bước đi qua nhà cung cấp trong spec của bạn đều có đủ trạng thái chờ, thất bại có lý do, và không trả lời.
• Bạn biết giới hạn request của từng nhà cung cấp trước khi cam kết quy mô với stakeholder.
• Mọi ticket sự cố liên quan tới nhà cung cấp bạn gửi đi đều có mã giao dịch và thời điểm kèm múi giờ.

Đi sâu hơn

• API (request/response) — chính là cách ta và nhà cung cấp nói chuyện với nhau ở mỗi bước qua ranh giới.
• Webhook vs polling — hai cách nhà cung cấp báo kết quả về, và vì sao có những thứ không bao giờ tức thì.