HOSE quá tải
Chuyện sàn giao dịch chứng khoán TP.HCM (HOSE) quá tải chắc ai cũng biết rồi. Phần mềm HOSE đang sử dụng do Thái Lan tài trợ từ những ngày đầu lập sàn ở thế kỷ trước, không dễ gì sửa chữa, nâng cấp.
FPT nói rằng họ có thể xử lý sự cố bằng cách xây dựng một hệ thống xài tạm, 3 tháng hoàn thành, trong lúc chờ HOSE chuyển đổi sang phần mềm KRX của Đại Hàn. Tôi thấy đây là một đề xuất táo bạo nhưng cũng đầy rủi ro.
Thứ nhất, giữa lúc dầu sôi lửa bỏng thế này mà các công ty chứng khoán phải thử nghiệm với cả hệ thống tạm của FPT và hệ thống lâu dài KRX. Tập trung vào một hệ thống còn chưa biết có làm được hay không, không biết thời gian và nhân lực đâu làm cả hai?
Thứ hai, có gì đảm bảo giải pháp của FPT sẽ xử lý được lượng tải lớn? FPT có thể có kinh nghiệm làm phần mềm cho sàn Hà Nội (HNX) nhưng HNX có lượng giao dịch rất nhỏ so với HOSE. Theo thống kê phiên giao dịch ngày 12/03/2021, khối lượng khớp lệnh của HNX là cỡ 95 triệu chứng khoán, tổng giá trị vào khoảng 1600 tỉ đồng. Cùng ngày, khối lượng khớp lệnh của HOSE là 5,6 tỉ chứng khoán, tổng giá trị vào khoảng 13000 tỉ đồng.
Cuối cùng, có gì đảm bảo 3 tháng sẽ xong? Tôi không biết FPT làm sao để ra con số 3 tháng này. Mới đầu ông Trương Gia Bình tuyên bố "2 tháng xong luôn", nhưng giờ đã thành 3-4 tháng và cũng có ý kiến phải cần ít nhất 6 tháng.
Dân làm phần mềm thường lạc quan. Cái gì dễ, biết làm ngay, họ sẽ nói 1 tiếng xong, nhưng kỳ thực có thể kéo dài vài ngày. Cái gì chưa biết làm, họ sẽ nói 3 tháng. Đây là "ám hiệu" để ngầm nói rằng thật sự tôi không biết dự án sẽ kéo dài bao lâu. Kinh nghiệm 10 năm làm phần mềm ở Google của tôi cho thấy kỳ thực không có cách gì lên kế hoạch chính xác một dự án phần mềm phức tạp như thế này. Mọi con số đều là đoán mò. Mọi thiết kế trên giấy đều sẽ đổ bể khi viết dòng code đầu tiên. Mọi dự án phần mềm đều trễ hẹn và một khi đã trễ thì càng thêm người càng làm dự án trễ hơn.
Tôi không rõ Bộ Tài chính và HOSE đã quyết định như thế nào. Tôi thấy chỉ nên chọn hoặc FPT hoặc KRX, không nên làm cả hai cùng lúc. Nếu đã có kế hoạch sử dụng KRX, phương án khả dĩ nhất là tập trung toàn bộ nguồn lực để đưa hệ thống này online. Trong thời gian chờ đợi thì nên tìm cách tối ưu hệ thống hiện có của Thái Lan và sử dụng các biện pháp hành chính để giảm tải cho sàn.
Dẫu chọn giải pháp gì đi chăng nữa, tôi chúc các anh chị em kỹ sư làm việc trong dự án này nhiều sức khỏe và hi vọng họ sẽ thành công. Thú thật tôi cũng muốn làm. Thông qua bạn bè, tôi cũng đã liên hệ với Bộ Tài chính để hỏi coi có hỗ trợ (miễn phí) được gì không. Tôi không có nhiều thời gian, nhưng đây là một dự án khó, rất thú vị, nhiều ý nghĩa, không kỹ sư nào không muốn nhào vào giải quyết.
Tôi nghĩ ít nhất tôi có thể phản biện, đánh giá độc lập giải pháp mới, hoặc tìm cách tối ưu hệ thống hiện tại. Nếu không có mã nguồn ta có thể tính đến phương án dịch ngược để thay đổi phần mềm ở mức binary. Nếu làm được thì đó sẽ là một cú hack ngoạn mục. Nếu vấn đề quá khó tôi không giải quyết được, tôi có thể tìm các chuyên gia khác ở Silicon Valley. Ở đây không thiếu người Việt Nam có kinh nghiệm trực tiếp xây dựng các hệ thống cực lớn, có khả năng xử lý hàng trăm ngàn đến hàng triệu yêu cầu mỗi giây.
Bộ lịch sự cảm ơn, nói họ đã có phương án giải quyết và cũng đã nhận được sự hỗ trợ từ nhiều chuyên gia hàng đầu thế giới rồi. Tôi nghĩ mọi thứ sẽ sớm ổn thôi, bà con an tâm. Nếu mua chứng khoán không được thì ta chuyển sang mua bitcoin vậy ;-).
Comments
Việc upgrade lên phiên bản mới đã khó nay lại chọn 1 trong 2 thì càng khó hơn. Sao không đơn giản là mua luôn giải pháp và dịch vụ của 1 nước phát triển mà lại đi làm song song nhỉ?
Với yêu cầu hệ thống có khả năng scale (mở rộng theo thời gian khi số lượng giao dịch ngày càng tăng theo thời gian) và xử lý tầm 1 triệu transactions per second ở thời điểm hiện tại.
PS: hiện tại sàn HOSE chỉ có khả năng xử lý vài chục transactions per second theo như em đọc báo, :))
Em nghĩ vấn đề nằm ở chỗ sàn HOSE (với quy mô như vậy) không có phương án xử lý việc này từ sớm hơn, ít gây thiệt hại hơn.
Duong: tôi không có nhiều kinh nghiệm thiết kế hệ thống stock exchange nên nếu muốn làm cũng phải nghiên cứu, chứ không thể muốn là viết ra được. Thiết kế hệ thống distributed, chịu được tải lớn và có tốc độ xử lý nhanh thì tôi có biết chút đỉnh, nhờ học lóm khi review thiết kế của đồng nghiệp.
chắc khối đất diễn :)
Rất muốn học hỏi thêm từ anh.
Câu này hay quá a, nhất là trong trường hợp hệ thống liên quan đến tiền như HOSE lại càng phức tạp hơn rất nhiều. Thay đổi một dòng code thôi cũng rén chứ đừng nói là làm lại một hệ thống như vậy
Câu này của bạn cũng có lý, nhưng nếu nhìn ở một khía cạnh khác, thì thị trường chứng khoán ở VN cũng mới thành lập từ 1998, kinh tế thì mới mở cửa từ vài chục năm ngắn ngủi. Nếu so với Anh hay Mỹ thì thị trường họ cũng vài trăm năm, hành lang pháp lí đầy đủ, vv.
Nên mình thích đưa ra những đóng góp để có thể đưa các lĩnh vưc ở VN có thể áp dụng và thực tế để tiến bộ từng ngày hơn là so sánh khập khiễng.
Về vấn đề nghẽn lệnh vv (với hệ thống phức tạp và liên quan đến tiền thì chuyện này ko khó hiểu), thì quan trọng là HOSE có tư tưởng cải tiến, tham khảo những người như anh thái, và từng bước áp dụng công nghệ để cải thiện hệ thống.
Có mấy cái New SQL database có thể thực hiện trăm ngàn đến triệu ACID transactions/ second. Scale app servers thì đơn giản.
10K QPS thì có thể, chắc chủ yếu là read query để update share prices, còn TPS cho giao dịch thì chắc thấp hơn nhiều.
Nói túm lại kẹt sàn thì thì có nhiều lý do nhưng để kẹt nhiều lần và tổn thất của đối tác và khối retail ai mất ai đc? Lý do kẹt là gì? Lối công suất thì throttle, sàn nào ko throttle thằng nào vượt mưc pps thì storm control khoá mõm nó, còn lỗi hệ thống thì ai trigger cái gì trigger, chứ kiểu kẹt sàn đòi upgrade lên KRX với timeline là ba tháng thì nói lên trình độ và mức độ chuyên nghiệp của lãnh đạo sàn