Hiện đại hóa hệ thống viễn thông: Đừng chỉ thay core, hãy thay tư duy

“Thay đổi nhỏ cũng phải qua 5 team và 3 tuần.”

Tôi nghe câu này nhiều đến mức không còn coi nó là lời than vãn nữa. Với tôi, đó là một tín hiệu kỹ thuật.

Khi chỉ sửa một gói cước hay chương trình khuyến mại nhỏ mà phải đi vòng qua CRM, rồi tới Sales & Inventory, rồi chạm tới Billing & Payment thì vấn đề thường không nằm ở năng lực của các đội nhóm.

Vấn đề nằm ở cách các hệ thống đang phụ thuộc lẫn nhau, và cách mỗi hệ thống hiểu trạng thái giao dịch theo một kiểu riêng.

Khi một thay đổi nhỏ kéo theo cả chuỗi sai lệch

Tôi từng gặp một tình huống rất đời thường. Đội kinh doanh chỉ muốn thêm một điều kiện bán gói cước. Hệ thống CRM cập nhật điều kiện khách hàng. Hệ thống bán hàng cập nhật quy tắc bán. Nhìn bề ngoài mọi thứ đều ổn.

Nhưng đến kỳ chốt số liệu, báo cáo đối soát bắt đầu lệch.

Không phải kiểu lệch lớn đến mức sập hệ thống. Đó là kiểu lệch rất khó chịu, khi từng nhóm giao dịch nhìn riêng thì có vẻ đúng, nhưng ghép lại một cách toàn trình thì nó lại sai.

Cuối cùng, nguyên nhân nằm ở hệ thống quản lý tài nguyên, tức inventory. Có những giao dịch đã giữ chỗ tài nguyên ở trạng thái reserved, nhưng chưa được kích hoạt sang activated vì một bước phía sau bị retry nhiều lần hoặc bị timeout. Trong khi đó, hệ thống tính cước lại ghi nhận doanh thu theo một logic khác.

Đêm hôm đó, cả đội ngồi đọc log từng dòng. Mỗi hệ thống đều kể 1 câu chuyện riêng “có vẻ đúng”, nhưng khi ghép các câu chuyện đó trên 1 bức tranh tổng thể và toàn trình thì nó sai.

Hiện đại hóa không phải thay core, mà là giảm cái giá phải trả cho mỗi lần thay đổi

Ở những khoảnh khắc như vậy, nhiều người sẽ đề xuất thay core.

Theo trải nghiệm của tôi, hiện đại hóa hệ thống viễn thông không phải là thay một hệ thống cũ bằng một hệ thống mới. Hiện đại hóa là giảm cái giá phải trả cho mỗi lần thay đổi, nghĩa là thay đổi nhanh hơn, ít rủi ro hơn và khi có lệch thì truy được nó lệch ở đâu và vì sao.

Một nhận định có phần gắt nhưng thường đúng. Bạn không loại bỏ được các phụ thuộc giữa hệ thống, bạn chỉ chuyển chỗ của chúng mà thôi.

Nếu bạn thay cả một khối lớn nhưng không thiết kế lại ranh giới trách nhiệm giữa CRM, Sales/Inventory và Billing/Payment, các phụ thuộc sẽ quay trở lại dưới hình hài khác. Bản đồ ánh xạ dữ liệu phức tạp hơn. Thời gian chạy song song hệ cũ và hệ mới kéo dài hơn. Vận hành kép mệt mỏi hơn

Điểm đau thật nằm ở ranh giới giao dịch

Nút thắt chính thường không nằm ở lớp tích hợp giữa các hệ thống, mà nằm ở ranh giới giao dịch, hay transaction boundary.

Mỗi hệ thống tự định nghĩa thế nào là hoàn thành theo một kiểu riêng:

• CRM coi xong theo nghĩa A

• Sales/Inventory coi xong theo nghĩa B

• Billing/Payment coi xong theo nghĩa C

Khi đó, lỗi không dừng lại ở một chỗ. Nó lan qua nhiều hệ thống và chỉ bộc lộ rõ ở những nơi tốn tiền nhất như khâu đối soát, khâu điều chỉnh lại cước và các cuộc gọi khiếu nại lên tổng đài.

Thiết kế lại theo luồng kinh doanh, không phải theo ranh giới hệ thống

Với hệ thống BSS/OSS, ranh giới giao dịch nên bám theo một luồng nghiệp vụ cụ thể, chẳng hạn luồng Order-to-Activate, thay vì bám theo ranh giới kỹ thuật của từng hệ thống.

Nói cụ thể hơn, không nên để mỗi hệ thống tự đặt ra trạng thái riêng rồi hy vọng chúng tự khớp với nhau. Cần có một xương sống trạng thái chung cho toàn bộ luồng giao dịch, có thể là một state machine hoặc một transaction journal mà tất cả các hệ thống cùng nhìn vào.

Một vài câu hỏi tối thiểu cần được trả lời rõ ràng trước khi đi xa hơn.

Đơn hàng đang ở bước nào trong toàn bộ luồng xử lý, tài nguyên đã được giữ chỗ hay chưa, dịch vụ đã được kích hoạt hay chưa, hệ thống tính cước được phép ghi nhận doanh thu từ mốc nào thì mới được coi là hợp lệ, khi phải thực hiện lại một bước xử lý thì ai là người chịu trách nhiệm chống trùng giao dịch, và khi phát hiện sai lệch thì ai là người chịu trách nhiệm bù trừ và điều chỉnh?

Khả năng quan sát hệ thống không chỉ là có dashboard

Để ranh giới giao dịch thực sự có ý nghĩa trong vận hành, cần gọi đúng tên một thứ hay bị xem nhẹ. Đó là observability, tức khả năng quan sát hệ thống một cách xuyên suốt.

Trong bối cảnh này, observability không phải là có vài dashboard đẹp mắt. Thứ thực sự cần là khả năng theo dõi hành trình giao dịch từ đầu đến cuối thông qua end-to-end tracing, kết hợp với một mã định danh dùng chung gọi là correlation ID đi xuyên suốt các bước.

Mục tiêu là trong vòng vài phút, đội vận hành phải trả lời được câu hỏi này. Giao dịch đang ở đâu trong chuỗi CRM → Sales/Inventory → Billing/Payment, và nó bị lệch vì retry kỹ thuật, vì dữ liệu đầu vào, hay vì logic trạng thái?

Nếu không quan sát xuyên suốt được, câu chuyện hiện đại hóa rất dễ trở thành bài toán đổi sang kiến trúc mới nhưng vẫn mù như cũ.

Thay đổi không đáng sợ, nếu hệ thống được thiết kế đúng cách

Nỗi sợ khi thay đổi trong các hệ thống viễn thông thường không đến từ việc con người không chịu đổi. Nó đến từ một hệ thống được thiết kế sao cho mỗi lần đổi là một lần đánh cược lớn.

Hiện đại hóa, nếu nhìn đúng, không chỉ là thay công nghệ cho mới. Đó là giảm rủi ro và giảm ma sát cho mỗi lần thay đổi nhỏ nhất. Và bước đầu tiên không phải là vẽ lại kiến trúc hay thay core cho xong, mà là gọi đúng tên những chỗ đang đau.

Trong bài tiếp theo của series Inside Telco Systems, tôi sẽ đi vào luồng Order-to-Activate và mổ đúng điểm hay gây sai lệch nhất. Đó là trạng thái tài nguyên trong inventory, đặc biệt là ranh giới giữa giữ chỗ và kích hoạt. Đây là nơi mà cả tốc độ ra thị trường lẫn chi phí đối soát thường cùng bị đốt, nhưng nhiều tổ chức lại không nhận ra.

Khi coi mỗi thay đổi là một lần thử lửa cho thiết kế hệ thống, chúng ta sẽ nhìn hiện đại hóa bớt màu công nghệ hơn và nhiều màu trách nhiệm kiến trúc hơn.

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

Về tác giả