Trong những cuộc họp xử lý sự cố Telco, có một câu hỏi nghe rất bình thường nhưng lại khiến cả phòng im lặng: “Hệ thống nó bị làm sao?”
Không phải vì câu hỏi này khó mà vì nó chạm đúng một thực tế khá phổ biến trong vận hành: đội vận hành không thực sự nhìn thấy chuyện gì đang xảy ra bên trong hệ thống. Câu trả lời hiếm khi đến ngay, đội ngũ thường phải mất một đến hai giờ lục log, ghép manh mối từ nhiều nguồn, rồi cuối cùng là ngồi lại tranh luận xem hệ thống nào đúng, hệ thống nào sai.
Bài viết này nằm trong series chia sẻ kinh nghiệm thiết kế và vận hành hệ thống Telco. Bài trước tôi đã nói về transaction boundary. Bài này là phần tiếp theo, trực tiếp chuyển từ khái niệm sang một thiết kế vận hành cụ thể.
> Tham khảo bài viết: Đứt gãy transaction boundary: Một trong những nguyên nhân gây thất thoát doanh thu
Tôi không bàn về việc dựng thêm dashboard hay chọn tool monitoring nào. Điều tôi muốn chia sẻ là một bài học mà đội của tôi đã mất khá nhiều thời gian mới hiểu rõ: nếu hệ thống không được thiết kế để chứng minh hành trình của một giao dịch từ đầu đến cuối, thì dù có bao nhiêu công cụ, mọi phân tích sự cố vẫn chỉ dừng ở mức suy luận.
Một case điển hình: nhìn thấy lỗi ở một nơi, nhưng gốc rễ nằm ở nơi khác
Để dễ hình dung, tôi kể một case cụ thể mà đội của tôi từng gặp.
Hệ thống bán hàng bị cao tải và treo liên tục, ảnh hưởng khoảng 15 phút bán hàng ngay giữa ngày. Nhìn vào phần nổi, ai cũng nghĩ lỗi nằm ở hệ thống bán hàng. Phía đội kinh doanh thì gọi xuống đúng kiểu rất quen thuộc trong vận hành: “Hệ thống lại lỗi rồi, em check gấp cho anh xem sao nó lại lỗi với, anh đang bán hàng mà chả bán được gì cả, hệ thống cứ quay quay ấy”.
Ở bề mặt của vấn đề, nhận định đó hoàn toàn hợp lý. Nhưng khi đào sâu hơn, nguyên nhân gốc lại không nằm ở hệ thống bán hàng. Một hệ thống khác bị lỗi, liên tục truy cập vào cơ sở dữ liệu dùng chung, đẩy tải lên cao và kéo hệ thống bán hàng chết theo.
Cái tốn kém nhất không phải 15 phút downtime hôm đó. Mà là cả giai đoạn sau đó: đội vận hành phải trực liên tục, cứ cao tải là lại chữa cháy, cho tới khi thực sự tìm đúng nguyên nhân. Trong suốt thời gian đó, không ai có thể trả lời chắc chắn một câu rất cơ bản: giao dịch đang đi tới đâu, bị gãy ở chỗ nào, và do hệ thống nào gây ra.
Nhìn lại, điểm đau thật sự không phải là hệ thống bị lỗi. Mà là đội vận hành đang ở trong trạng thái mù, không có cách nào nhìn thấy rõ chuyện gì đang xảy ra bên trong.
Observability không phải là có nhiều màn hình giám sát, mà là chứng minh được hành trình
Observability (khả năng quan sát) là năng lực hiểu rõ trạng thái bên trong của một hệ thống phức tạp dựa trên việc phân tích các tín hiệu đầu ra bên ngoài. Nó giúp kỹ sư không chỉ biết khi nào hệ thống lỗi mà còn hiểu tại sao lỗi, thông qua việc thu thập log, các chỉ số và dấu vết truy vấn.
Trong bối cảnh Telco, tôi chốt lại một nguyên tắc rõ ràng cho đội sau case đó và vài case tương tự:
-
Observability = chứng minh được timeline của một giao dịch end-to-end. Không chứng minh được thì không vận hành được.
Nghe thì đơn giản. Nhưng để làm được điều đó, hệ thống phải được thiết kế cho nó ngay từ đầu, chứ không phải chờ sự cố xảy ra rồi mới bắt đầu đi lục.
Giao dịch không có mã định danh xuyên suốt thì mọi truy vết đều là phỏng đoán
Trong Telco, một giao dịch hiếm khi nằm trong một hệ thống duy nhất. Nó đi qua nhiều hệ khác nhau, từ CRM, bán hàng, quản lý tài nguyên cho đến tính cước. Để theo dõi được hành trình đó, mỗi giao dịch cần có một mã định danh xuyên suốt, thường gọi là transaction-id, tức một định danh duy nhất gắn với giao dịch ngay từ đầu và đi theo nó qua tất cả các hệ thống.
Không có transaction-id thì câu hỏi giao dịch đang ở đâu gần như không có câu trả lời chắc chắn. Mọi phân tích đều là đoán.
Và nếu transaction-id bị đứt ở tầng thanh toán thì việc truy vết giao dịch từ đầu đến cuối bị gãy đúng ở chỗ nhạy cảm nhất. Khi đó đội vận hành lại quay về cách truy vết thủ công: dò theo số điện thoại, theo thời gian, dựa vào kinh nghiệm rồi suy luận tương đối. Cuộc họp xử lý sự cố lại rơi vào vòng lặp quen thuộc.
Hành trình giao dịch cần một lớp ghi nhận riêng, không phụ thuộc vào logic của từng hệ thống
Nhiều đội để mỗi hệ thống tự ghi log theo cách riêng rồi sau đó cố ghép lại để suy ra hành trình giao dịch. Cách này gần như luôn dẫn đến chậm hoặc sai.
Tôi thấy cần một cách tiếp cận khác: một lớp ghi nhận riêng, tách hẳn khỏi logic nghiệp vụ của từng hệ, chỉ làm đúng một việc là giữ lại trạng thái hành trình của giao dịch: đã qua mốc nào, chưa qua mốc nào, và mốc nào được coi là hợp lệ để tính tiền.
Tôi hay gọi lớp này là journal layer. Nó không xử lý nghiệp vụ, không cố ôm domain của hệ nào. Nó chỉ ghi nhận hành trình theo đúng thứ tự thời gian, đủ để khi có sự cố, mọi người cùng nhìn vào một bản timeline duy nhất thay vì phải đối chiếu bảy cái log với bảy cách ghi khác nhau.
Lớp này tồn tại để trả lời nhanh hai câu hỏi: giao dịch đang kẹt ở bước nào, và vì sao nó kẹt.
Cố ghép log từ nhiều nơi để suy ra hành trình là sai lầm phổ biến nhất
Đây là lỗi tôi gặp nhiều nhất và nó rất phổ biến vì trông có vẻ là cách làm tự nhiên. Trong thiết kế hệ thống, kiểu cách làm tưởng hợp lý nhưng thực tế gây hại thường được gọi là anti-pattern.
Nhiều đội chọn cách ghép log từ từng hệ thống lại với nhau để cố suy ra hành trình giao dịch, thay vì thiết kế hành trình đó ngay từ đầu để có thể truy vết được. Trường hợp ghép được thì kết quả đến rất chậm, còn trường hợp ghép không được thì cuộc họp xử lý sự cố lại kết thúc bằng tranh luận thay vì kết luận.
Trong Telco, cái chậm này không chỉ đơn giản là chậm. Nó thường đồng nghĩa với việc hệ thống đang xử lý những giao dịch liên quan trực tiếp đến tiền, mà không ai biết chắc mình đang đúng hay đang sai ở chỗ nào và cũng không có cơ sở để sửa cho đúng.
Kiểu lỗi khó phát hiện nhất: mọi thứ đều đúng, chỉ có thời điểm là sai
Đây là kiểu lỗi tôi muốn tách riêng ra để nói, vì nó rất đặc trưng trong Telco và cực kỳ khó phát hiện.
Rất nhiều lỗi trong Telco không phải do dữ liệu sai. Dữ liệu hoàn toàn đúng, nhưng nó đến không đúng lúc hoặc không đúng thứ tự. Tôi gọi chung kiểu này là temporal issue, tức lỗi liên quan đến thời gian. Hệ thống vẫn xử lý theo đúng logic của mình, nhưng logic đó đang chạy trên một sự thật đã cũ.
Ví dụ, một sự kiện đến muộn vài giây có thể khiến hệ thống tính tiền theo gói cũ thay vì gói mới. Một sự kiện đến sai thứ tự có thể khiến hệ thống hiểu nhầm trạng thái kích hoạt dịch vụ. Hoặc một sự kiện mất dấu giữa chừng có thể khiến toàn bộ giao dịch bị treo mà không ai hay.
Hậu quả là những quyết định liên quan trực tiếp đến tiền, từ chiết khấu, chính sách giá cho đến mốc tính cước, bị lệch mà từng hệ thống vẫn tưởng mình đang xử lý đúng. Kiểu lỗi này không báo đỏ, không crash, không có alert. Nó chỉ lộ ra khi đối soát cuối kỳ hoặc khi khách hàng phản ánh.
Và khi đó, chi phí không chỉ là tiền mà còn là niềm tin.
Làm observability kiểu này không miễn phí, nhưng không làm thì trả giá đắt hơn nhiều
Tôi không muốn vẽ ra một bức tranh toàn màu hồng.
Thiết kế observability theo hướng chứng minh được timeline giao dịch, tức khả năng dựng lại đường đi của giao dịch theo đúng trình tự thời gian với đầy đủ bằng chứng tại mỗi mốc, là có chi phí thật. Hệ thống sẽ phải ghi log nhiều hơn, thậm chí cần import log vào cơ sở dữ liệu riêng để tra cứu nhanh. Dev phải tốn thêm công sức để truyền transaction-id xuyên suốt và ghi nhận theo từng bước. Toàn đội cũng cần kỷ luật thiết kế rõ ràng hơn để đảm bảo trace không bị đứt ở tầng thanh toán.
Nhưng đổi lại, những gì đội vận hành mua được còn cụ thể hơn những gì phải trả..
Thời gian khoanh vùng sự cố giảm từ hàng giờ xuống vài phút. Biết rõ ai đang kéo cơ sở dữ liệu, kéo ở đâu và vì sao. Không còn tình trạng chữa cháy lặp lại sai chỗ, kiểu hệ thống bán hàng chết thì cứ sửa bán hàng trong khi nguyên nhân nằm ở hệ thống khác. Và quan trọng nhất, các quyết định liên quan đến tiền được bám vào mốc hợp lệ để tính tiền, thay vì dựa trên trạng thái mà không ai chắc chắn là còn đúng.
Trước khi họp xử lý sự cố, hãy trả lời 4 nhóm câu hỏi này
Trong các buổi xử lý sự cố, tôi thường dùng một checklist đơn giản để xác định hệ thống đang thực sự quan sát được hay vẫn đang ở trạng thái mù.
Nhóm A: Nền tảng
-
[ ] Transaction-id có được tạo ngay khi giao dịch bắt đầu và đi xuyên suốt qua tầng thanh toán hay không
-
[ ] Có lớp journal giữ trạng thái hành trình giao dịch cùng các mốc hợp lệ để tính tiền hay không
Nếu thiếu một trong hai, phần còn lại gần như không có nền tảng để hoạt động.
Nhóm B: Khả năng dựng lại timeline
-
[ ] Đội có thể dựng lại hành trình một giao dịch từ đầu đến cuối trong vòng 30 phút hay không
-
[ ] Có thể chỉ ra giao dịch kẹt ở đâu và vì sao bằng bằng chứng cụ thể hay không
Nhóm C: Nhận diện temporal issue
-
[ ] Đội có phân biệt được sự kiện đến muộn, đến sai thứ tự hay mất dấu giữa chừng hay không
-
[ ] Có phát hiện được sai lệch trước khi đến kỳ đối soát hay không, đặc biệt ở các luồng kích hoạt dịch vụ, đăng ký và thanh toán
Nhóm D: Kiểm tra anti-pattern
-
[ ] Đội có đang phải ghép log từ từng hệ thống để cố suy ra hành trình giao dịch hay không
Nếu đó là dấu hiệu rõ nhất cho thấy observability chưa được thiết kế mà chỉ đang được chắp vá.
Nếu bốn nhóm trên mà có từ hai nhóm trở lên không đạt, thì thực tế hệ thống vẫn đang vận hành dựa trên phỏng đoán.
Tóm lại
Observability không phải là có nhiều dashboard. Observability là khả năng chứng minh hành trình của một giao dịch bằng transaction-id, xuyên suốt từ đầu đến cuối.
Trong Telco, mỗi sự cố nhìn riêng lẻ có thể giống một bug. Nhưng khi nhìn tổng thể, phần lớn vấn đề nằm ở chỗ không kiểm soát được hành trình giao dịch. Transaction-id, journal layer và khả năng dựng lại timeline không phải là lý thuyết. Đó là những thứ quyết định bạn đang chữa cháy hay đang thực sự kiểm soát được hệ thống.
Cùng theo dõi BiPlus để đón chờ các bài viết tiếp theo trong series Inside Telco Systems nhé!
Về tác giả
Quoc Dinh – Co-founder | Phó Giám đốc
Bạn có một ý tưởng phần mềm nhưng chưa biết nên bắt đầu từ đâu, cũng không chắc phải làm thế nào để hiện thực hóa nó. Đây là giai đoạn then chốt, bởi chỉ cần đưa ra những quyết định sai ngay từ đầu, cả doanh nghiệp có thể bị ảnh hưởng nghiêm trọng.
Vì vậy, hãy để tôi đồng hành cùng bạn. Tôi có hơn chín năm kinh nghiệm làm Software Development Engineer, chuyên phát triển, nâng cấp và triển khai các hệ thống phần mềm trong ngành viễn thông, đặc biệt là mảng BCCS (Billing, Charging and Customer Care System). Ngoài ra, tôi cũng đã có hơn hai năm làm việc tại thị trường quốc tế, trong đó có Peru.
“Quoc là một Tech PM vừa có trách nhiệm vừa có năng lực. Anh ấy rất thành thạo các dự án Samsung 3PD và luôn là người đầu tiên mọi người nghĩ đến khi gặp sự cố. Được làm việc cùng anh ấy thật sự rất thoải mái.”
— Mr. Minsu Jang, PMO Consultant tại S-Core.
Bạn đã sẵn sàng sở hữu sản phẩm phần mềm đột phá tiếp theo chưa? Let’s connect!
