Đứt gãy transaction boundary: Một trong những nguyên nhân gây thất thoát doanh thu

Bài trước tôi nói về ranh giới giao dịch, tức transaction boundary. Đây là khái niệm nền để đọc bài này cho đúng.

>>> Transaction boundary (ranh giới giao dịch) là phạm vi xác định điểm bắt đầu và kết thúc của một quy trình kỹ thuật, đảm bảo toàn bộ các bước bên trong thực hiện thành công (commit) hoặc toàn bộ bị hủy bỏ/hoàn tác (rollback) nếu có lỗi. Nó giúp duy trì tính nhất quán dữ liệu, ví dụ như chuyển tiền ngân hàng (trừ tiền A, cộng tiền B).

Trong kỹ thuật hệ thống, một giao dịch (transaction) thường được hiểu là một đơn vị công việc hoặc hoàn tất trọn vẹn, hoặc coi như chưa từng xảy ra. Từ đó suy ra transaction boundary là mốc mà bạn có thể khẳng định giao dịch đã hoàn tất theo nghĩa nghiệp vụ và có thể chịu trách nhiệm về các hệ quả phía sau như tính tiền, ghi nhận doanh thu và đối soát.

Trong Telco, mỗi hệ có thể đúng theo cách của nó. Nhưng cả hành trình vẫn sai nếu không có một mốc chung mà mọi hệ cùng đồng thuận giao dịch đã xong. Bài này sẽ thực chiến hơn. Khi sự cố xảy ra trong hành trình Order to Activate, tôi phân loại thế nào để không mất hai ngày chỉ để tranh luận hệ nào đúng.

>>> Order to Activate – O2A (Yêu cầu kích hoạt/Lệnh kích hoạt) trong Telco là quy trình kỹ thuật và thương mại nhằm bật dịch vụ cho khách hàng sau khi họ đã đăng ký hoặc mua sản phẩm. Đây là bước chuyển đổi từ một số thuê bao, SIM, hoặc dịch vụ “trên giấy tờ” thành dịch vụ có thể hoạt động thực tế trên mạng lưới.

Tôi chọn luồng Order to Activate trong rất nhiều luồng dịch vụ của Telco làm ví dụ xuyên suốt bài này vì tính phổ biến của nó, đi qua nhiều hệ thống và thể hiện nhất các vấn đề nền liên quan ranh giới giao dịch. Các kiểu sự cố trong bài không chỉ xảy ra khi đăng ký thuê bao mới mà lặp lại ở đăng ký đổi SIM, nâng gói hay đăng ký dịch vụ cáp quang (FTTH – Fiber To The Home).

Nội dung sẽ gồm 5 phần:

1. Một tình huống thất thoát doanh thu nhìn như một bug

2. Vì sao cần control point để chốt trạng thái billable

3. Bốn kiểu sự cố hay gặp trong Order to Activate

4. Hướng dẫn phân loại sự cố

5. Quick win làm được trong hai đến bốn tuần

Bug thì nhỏ nhưng lỗ thủng kinh tế là thật

Trong nhiều hệ thống, vấn đề không nằm ở chuyện tích hợp sai hay gửi yêu cầu sang nhầm nơi, những lỗi kiểu đó thường khá rõ và dễ phát hiện.

Vấn đề nằm ở chỗ khác. Quyết định tính cước và thu tiền được đưa ra dựa trên một trạng thái không còn khớp với hành trình thực tế. Tích hợp có thể vẫn đúng, dữ liệu ở từng hệ có thể vẫn đúng tại thời điểm nó được ghi nhận nhưng chỉ cần trạng thái tại thời điểm ra quyết định bị lệch nhịp so với dòng thời gian của giao dịch, hệ thống vẫn có thể tính đúng theo một sự thật đã cũ.

Tôi từng gặp một tình huống đáng nhớ.

Dịch vụ thu 10.000 đồng mỗi tháng. Chính sách cho phép nếu khách chỉ có 2.000 hay 3.000 đồng thì vẫn được đăng ký và ghi nợ phần còn lại, nghĩa là cho dùng trước và thu bù sau.

Có một nhánh xử lý dùng để kiểm tra và chặn dịch vụ trong một số trường hợp đặc biệt. Khi nhiều giao dịch đi qua tổng đài rơi vào nhánh này, chúng bị lỗi hàng loạt. Vấn đề là mỗi khi giao dịch thất bại, hệ thống hoàn lại toàn bộ 10.000 đồng, trong khi theo chính sách thì đáng ra chỉ trừ 2.000 đến 3.000 đồng và ghi nợ phần còn lại.

Ban đầu, chỉ xác định là một lỗi kĩ thuật thông thường, nhưng bản chất nó là một lỗ hổng kinh tế. Và khi khách hàng biết được và có lợi, cũng là lúc cơ hội trục lợi. Với dịch vụ giá trị nhỏ nhưng số lượng lớn, sai lệch kiểu này tích lũy thành thất thoát doanh thu đáng kể.

Điều khiến việc điều tra bế tắc không phải vì lỗi quá khó mà vì thiếu ba thứ cơ bản.

1. Thiếu log đủ chi tiết để dựng lại dòng thời gian

2. Thiếu transaction ID, tức mã định danh duy nhất cho một giao dịch xuyên suốt nhiều hệ thống

3. Thiếu khả năng đối chiếu dữ liệu nguồn giữa các hệ liên quan nên không chứng minh được vì sao hệ thống ra quyết định tính tiền như vậy

Khi không có một mốc chung để chốt trạng thái nào là hợp lệ cho tính tiền, các nhánh xử lý lỗi rất dễ hoàn sai, trừ sai hoặc ghi nhận sai. Mất tiền thường bắt đầu từ một chỗ như vậy.

Tình huống này đã có thể không xảy ra, hoặc ít nhất được phát hiện sớm hơn, nếu ngay từ đầu có một điểm giữ trạng thái và chốt mốc được phép tính tiền. Đó là lý do phần tiếp theo nói về control point.

Control point: Điểm giữ mạch hành trình và bảo vệ ranh giới giao dịch

>>> Control point (Điểm kiểm soát – CP) là các vị trí, bước, hoặc công đoạn quan trọng trong một quy trình, hệ thống hoặc dự án nơi các biện pháp kiểm soát được thiết lập để theo dõi, quản lý, và đảm bảo chất lượng, an toàn hoặc tiến độ.

Trong bài này, control point cần trả lời rõ ba câu hỏi.

• Giao dịch đang ở bước nào? Đã qua mốc nào? Mốc nào được coi là hợp lệ để đi qua ranh giới tính tiền, tức billable, nghĩa là đủ điều kiện để tính và thu tiền theo nghiệp vụ?

• Nếu không có control point, mỗi hệ tự xử theo logic riêng và transaction boundary biến thành niềm tin dẫn đến việc bạn có rất nhiều mảnh rời nhưng không có dòng thời gian đủ tin cậy cho một giao dịch.

• Trong nhiều trường hợp tôi đã trải qua, control point cần được tách khỏi logic nội bộ của từng hệ thống như CRM, Sales hay Billing và nằm ở một lớp điều phối riêng.

Lớp điều phối này thường được gọi là orchestration, tức cơ chế điều phối luồng xử lý giữa nhiều hệ. Đi kèm là một dạng nhật ký trạng thái theo thời gian, có thể hiểu như transaction journal, nơi ghi lại các mốc trạng thái tối thiểu của giao dịch, gắn transaction ID xuyên suốt và chốt mốc billable.

Mục tiêu không phải tạo thêm một hệ thống mới. Mục tiêu ở đây là không để quyết định liên quan tới tiền bị chi phối bởi trạng thái cục bộ của từng hệ.

4 kiểu sự cố Order to Activate dễ làm đứt gãy ranh giới giao dịch

Tôi không cố làm danh sách cho đẹp. Đây là những kiểu mà vào phòng xử lý sự cố là gặp.

1. Timeout và retry gây ra trùng giao dịch

Nguy hiểm nhất là tình huống hệ thống “làm lại” một đoạn của giao dịch trong khi đoạn trước đó thực ra đã làm xong.

Ví dụ, bước A đã xử lý thành công rồi. Nhưng vì bị chậm phản hồi hoặc báo lỗi nhầm, hệ thống lại chạy bước B thêm một lần nữa. Nếu không có một mã giao dịch duy nhất đi theo từ đầu đến cuối để nhận ra “đây vẫn là cùng một giao dịch”, hệ thống rất dễ xử lý lặp.

Hậu quả thường rơi vào hai dạng:

• Bị trừ tiền hai lần hoặc ghi nhận thu tiền lặp

• Bị giữ tài nguyên hai lần, ví dụ giữ hai suất, hai số, hai gói

Tệ hơn nữa là nhánh xử lý lỗi như hoàn tiền hoặc bù trừ cũng bị chạy lặp. Khi đó sai lệch không còn là lệch trạng thái cho vui nữa, nó thành sai lệch về tiền và rất khó truy vết đầy đủ để sửa cho đúng.

2. Provisioning xong nhưng phản hồi bị bỏ lỡ hoặc lệch nhịp

>>> Provisioning là quá trình cấu hình dịch vụ để khách dùng được, ví dụ mở quyền truy cập, gán cấu hình dịch vụ, kích hoạt dịch vụ trên mạng.

Kiểu này hay bị chốt vội là “lỗi tích hợp”, tức lỗi ở chỗ các hệ thống gọi qua lại với nhau. Nghe thì hợp lý, nhưng thường chỉ đúng phần ngọn.

Gốc rễ của lỗi này là bài toán điểm kiểm soát (control point). Tức phải có một nơi giữ được trạng thái tối thiểu của giao dịch trên toàn hành trình, để biết giao dịch đang ở bước nào. Và khi hệ thống bên dưới không trả kết quả hoặc trả kết quả quá muộn, chính điểm kiểm soát đó phải là nơi quyết định có nên thực hiện lại bước vừa rồi hay không và quyết định dựa trên quy tắc nào. Nếu không có điểm kiểm soát này, hệ thống phía trên buộc phải suy đoán. Mà đã suy đoán thì rất dễ làm sai nhịp, dẫn đến cả hành trình đi lệch.

3. Rating và charging lệch vì trạng thái cập nhật sai thời điểm

Thứ bạn bán cho khách là một kiểu, cách hệ thống hiểu để tính phí lại là một kiểu khác. Quyết định thu tiền được đưa ra dựa trên một trạng thái của giao dịch đã không còn đúng nữa. Càng nhiều chính sách khuyến mãi, gói kèm và ngoại lệ, khả năng lệch giữa “được phép tính tiền” và “chưa được phép tính tiền” càng cao nếu không có một ranh giới rõ ràng để chốt.

Một dạng rất hay gặp trong viễn thông là các sự kiện liên quan đến tính cước và thu tiền không đến đúng lúc hoặc đến không đúng thứ tự. Thông tin bản thân nó có thể vẫn đúng nhưng nó đến sai thời điểm so với diễn biến thật của giao dịch.

Khi đó, hệ thống tính cước theo chu kỳ có thể ghi nhận vào sai kỳ thanh toán hoặc ghi nhận dựa trên trạng thái cũ của khách hàng, trước khi thay đổi gói hay dịch vụ.

Những lỗi kiểu này thường chỉ lộ ra khi tổng kết và đối soát cuối kỳ. Đến lúc quay lại lần theo thì không còn đủ dấu vết để dựng lại trọn vẹn hành trình của giao dịch. Còn khi phải bù trừ cho khách, bạn chạm thẳng vào tiền và vào mức độ khách còn tin nhà mạng đến đâu.

4. Inventory lệch nhịp tạo trạng thái nửa vời

>>> Inventory là hệ thống quản lý tài nguyên dịch vụ như số thuê bao, SIM hay gói cước (tồn kho).

Hệ thống quản lý tài nguyên rất dễ tạo ra những trạng thái dở dang. Có khi tài nguyên đã được giữ chỗ cho một khách hàng (reserved) nhưng chưa được kích hoạt để khách thực sự dùng được. Có khi đã kích hoạt xong (activated) nhưng thông tin cập nhật sang các hệ thống khác lại chưa đúng.

Khi những trạng thái dở dang kiểu đó được phản ánh sang hệ thống tính cước hoặc hệ thống thu tiền, bước đối soát sau này sẽ là nơi phơi ra toàn bộ sai lệch.

Cách phân loại sự cố Order to Activate trong war room

>>> Trong ngành viễn thông (telco), War Room (Phòng chiến tranh/Phòng tác chiến) là một không gian vật lý hoặc ảo được thiết lập khẩn cấp để tập trung các nhân sự kỹ thuật, quản lý và chuyên gia hàng đầu nhằm giải quyết các sự cố nghiêm trọng (Major Incident) hoặc các tình huống khủng hoảng ảnh hưởng đến mạng lưới viễn thông

Thứ tự phân loại ở đây là để tiết kiệm thời gian, không phải để “đúng quy trình” cho đẹp.

Khi vào xử lý, tôi ưu tiên theo thứ tự sau:

• Đầu tiên là mức độ ảnh hưởng tới khách hàng. Tiếp theo là tiền, theo hướng xem dòng tiền thực (payment) trước rồi mới đến ghi nhận và hóa đơn (billing). Sau đó mới nhìn tới phần cấu hình và kích hoạt dịch vụ (provisioning). Hệ thống quản lý tài nguyên (inventory) là điểm kiểm chứng quan trọng khi cần đối chiếu.

Câu hỏi đầu tiên tôi hay đặt ra với đội vận hành và đội phát triển vẫn là: gần đây có thay đổi gì không? Thay đổi này có thể được hiểu là có nâng phiên bản, thay đổi cấu hình hay triển khai bản mới nào gần với thời điểm sự cố hay không?

Sau đó, tôi chọn một giao dịch mẫu và dựng lại toàn bộ hành trình của nó. Giao dịch đó đã đi qua những mốc nào? Còn đang kẹt ở mốc nào? Có mốc nào hệ thống xử lý xong rồi nhưng không ai nhận hay không? Và quan trọng nhất, quyết định tính tiền ở mốc nào, dựa trên trạng thái nào của giao dịch?

Nếu không có một mã giao dịch duy nhất đi theo xuyên suốt (transaction ID), tôi coi đó là một nguyên nhân gốc thuộc dạng “mù”. Đã mù ở mức giao dịch thì những bước sau phần nhiều chỉ là chữa cháy tạm thời.

3 việc có thể bắt đầu ngay trong 2-4 tuần

Đây không phải để làm cho gọn gàng về mặt hình thức, mà để đội vận hành và đội sản phẩm yên tâm hơn khi hệ thống có sự cố. 3 việc này nhắm vào một mục tiêu rất cụ thể: khi có vấn đề xảy ra, bạn nhìn ra được giao dịch đang ở đâu trong hành trình, tiền đang ở đâu trong luồng thu và hệ nào đã ghi nhận điều gì.

Điều bạn nhận lại từ ba việc này là sự chắc tay hơn khi xử lý vấn đề. Thay vì ngồi trong war room để suy đoán và tranh luận, đội vận hành và đội phát triển có thể dựng lại dòng thời gian của một giao dịch dựa trên dấu vết rõ ràng. Bạn cũng phát hiện sớm những sai lệch tiền bạc kiểu âm thầm, nhất là sau một lần thay đổi phiên bản hoặc cấu hình. Quan trọng hơn, bạn giữ được ranh giới giữa mốc đã được phép tính và thu tiền với mốc chưa được phép, để trạng thái không lệch nhịp rồi kéo tiền lệch theo.

1. Ghi log theo từng bước của hành trình và thống nhất cách đặt log giữa các đội

Mục tiêu không phải tạo thật nhiều log mà là dựng được dòng thời gian của một giao dịch từ lúc bắt đầu đến lúc kết thúc, kể cả khi giao dịch thất bại giữa chừng. Khi các đội đặt log theo cùng một cách, bạn có thể ghép các mảnh lại thành một câu chuyện hoàn chỉnh, thay vì mỗi hệ kể một kiểu và không khớp nhau.

2. Gắn mã giao dịch xuyên suốt, đặc biệt qua các bước liên quan tới billing và charging

Mã giao dịch xuyên suốt giúp bạn theo dõi một giao dịch đi qua nhiều hệ thống mà không bị đứt đoạn. Nó đặc biệt quan trọng ở những chỗ liên quan đến tính cước theo kỳ và luồng thu tiền, vì đây là nơi dễ phát sinh xử lý lặp. Khi có mã này, hệ thống và cả con người đều có căn cứ để nhận ra đây có phải cùng một giao dịch hay không, từ đó giảm rủi ro trừ tiền trùng, hoàn tiền trùng hoặc bù trừ sai.

3. Dựng bảng theo dõi bất thường gắn với thay đổi gần nhất

Bảng theo dõi này giúp bạn nhìn ra bất thường sớm, thay vì đợi tới lúc đối soát cuối kỳ mới vỡ ra. Mỗi khi nâng phiên bản hoặc thay đổi cấu hình, bạn có thể theo dõi các dấu hiệu nhạy cảm như tỷ lệ thất bại tăng, hoàn tiền tăng bất thường hoặc các giao dịch có biểu hiện tính tiền không khớp chính sách. Cách làm này không chỉ để bắt lỗi nhanh mà còn để khoanh vùng nguyên nhân theo mốc thay đổi, rút ngắn đáng kể thời gian điều tra.

Việc tốn công nhất nhưng đáng giá nhất vẫn là ghi log theo từng bước và chuẩn hóa giữa nhiều bên. Tốn lưu trữ, tốn công, dễ bị phản đối nhưng nếu bạn từng ngồi war room mà không chứng minh được vì sao hệ thống ra quyết định tính tiền như vậy, bạn sẽ hiểu vì sao nó đáng.

Nếu nhìn riêng lẻ, mỗi sự cố trên hành trình đặt hàng đến kích hoạt dịch vụ trông như một bug. Nhưng nếu nhìn xuyên suốt, nó thường là hệ quả của ranh giới giao dịch bị đứt. Điểm điều phối, mã giao dịch xuyên suốt và log chuẩn hóa không phải là lý thuyết. Đó là ba thứ quyết định bạn đang chữa cháy hay đang thực sự kiểm soát.

Trong bài tiếp theo của series Inside Telco Systems, tôi sẽ nói về khả năng quan sát hệ thống theo một cách rất cụ thể. Làm sao để dùng một mã giao dịch duy nhất đi xuyên suốt hành trình, dựng được dòng thời gian của giao dịch và chỉ ra ranh giới giao dịch bị đứt ở đâu. Mục tiêu là những lỗi do lệch thời điểm không còn âm thầm bào mòn tiền và niềm tin của bạn nữa.

Cùng theo dõi BiPlus để đón chờ các bài viết tiếp theo trong Series nhé!