BÁO CÁO NGHIÊN CỨU HIỆU NĂNG, TỔNG HỢP NỘI DUNG VÀ SO SÁNH ĐỐI CHIẾU HỆ THỐNG MOE FINANCE#

Tài liệu tham chiếu:

• docs/01_inputs/Agile business requirement 1.xlsx (Yêu cầu nghiệp vụ thô từ Client)
• docs/01_inputs/performance-requirements-v0.2.docx (Bản dự thảo đặc tả hiệu năng v0.2)
• docs/02_specifications/performance-requirements-v1.0.docx / .md (Đặc tả yêu cầu hiệu năng v1.0 hoàn chỉnh)
• docs/02_specifications/CLIENT_PERFORMANCE_ASSUMPTION_INTERVIEW_NOTE.txt (Biên bản phỏng vấn & xác nhận từ Client)
• docs/02_specifications/Agile_Business_Requirements_Enterprise.xlsx (Làm rõ nghiệp vụ cấp doanh nghiệp)

MỤC LỤC TỔNG QUAN#

1. PHẦN I: ĐÁNH GIÁ CHUYÊN SÂU QUÁ TRÌNH RESEARCH ("RESEARCH ĐÃ ỔN CHƯA?")
   • 1.1. Đánh giá tổng quan mức độ trưởng thành (Readiness Scorecard)
   • 1.2. Những điểm xuất sắc đã được củng cố vững chắc (Strengths & Validated Facts)
   • 1.3. Những điểm tồn tại rủi ro & Khoảng trống kỹ thuật cần tháo gỡ (Technical Gaps & Risks)
   • 1.4. Kết luận & Điều kiện tiên quyết để nghiệm thu Research
2. PHẦN II: TÓM TẮT TOÀN DIỆN NỘI DUNG ĐẶC TẢ HIỆU NĂNG (3-TIER LOSSLESS SUMMARY)
   • 2.1. Tier 1: Tóm lược điều hành cấp cao (Executive Brief - TL;DR)
   • 2.2. Tier 2: Trụ cột kỹ thuật, Ma trận SLA & Giải pháp Ca biên (Technical Deep-Dive)
   • 2.3. Tier 3: Kế hoạch phân công (RACI), Thuật ngữ chuẩn hóa & FAQ Stakeholder
3. PHẦN III: MA TRẬN SO SÁNH ĐỐI CHIẾU 3 CHIỀU (CROSS-COMPARISON MATRIX)
   • 3.1. Bảng ma trận đối chiếu 3 chiều chi tiết (Client Raw vs v0.2 vs v1.0)
   • 3.2. Phân tích sự chuyển dịch tư duy kiến trúc (Architectural Mindset Evolution)
4. PHẦN IV: KHUYẾN NGHỊ THỰC THI & LỘ TRÌNH TRIỂN KHAI TIẾP THEO

PHẦN I: ĐÁNH GIÁ CHUYÊN SÂU QUÁ TRÌNH RESEARCH ("RESEARCH ĐÃ ỔN CHƯA?")#

1.1. Đánh giá tổng quan mức độ trưởng thành (Readiness Scorecard)#

Quá trình nghiên cứu và kỹ nghệ yêu cầu (Requirements Engineering) từ tài liệu thô ban đầu đến phiên bản v1.0 đã có một bước nhảy vọt vượt bậc về chất lượng. Nhóm kỹ thuật đã chuyển dịch thành công một tập yêu cầu nghiệp vụ cấp cao (High-Level Business Requirements) thành một bộ đặc tả kiểm thử hiệu năng cấp doanh nghiệp (Enterprise Performance Test Specification) có tính định lượng cao.

KẾT LUẬN CHUNG VỀ ĐỘ SẴN SÀNG (OVERALL READINESS: 7.8/10): Nghiên cứu đã RẤT ỔN về mặt Kiến trúc và Thiết kế Kịch bản Tải (Test Design & Sizing), đủ điều kiện để triển khai chạy đo kiểm cơ sở (Round 1 Baseline). Tuy nhiên, CHƯA THỂ COI LÀ HOÀN TẤT TUYỆT ĐỐI nếu chưa thực hiện 3 điều kiện tiên quyết: (1) Trình Product Owner ký duyệt chính thức các Giả định [Assumption]; (2) Hiệu chỉnh Mock Server phản ánh đúng độ trễ biến thiên; và (3) Bổ sung NFR chuyên biệt cho AI Chatbot & ML Model.

1.2. Những điểm xuất sắc đã được củng cố vững chắc (Strengths & Validated Facts)#

1. Thoát khỏi cái bẫy "Mô hình đồ chơi" (Toy Prototype Trap) của bản v0.2:
   • Trong bản v0.2, nhóm thiết kế giả định hệ thống là "training prototype" chỉ với 10 cán bộ, 20 phụ huynh đồng thời và tập dữ liệu mẫu $N$ không rõ kích thước.
   • Lên bản v1.0, qua buổi phỏng vấn trực tiếp với Client (CLIENT_PERFORMANCE_ASSUMPTION_INTERVIEW_NOTE.txt), hệ thống đã được xác định là nền tảng tài chính quốc gia phục vụ Bộ Giáo dục Singapore.
2. Xác nhận được toàn bộ số liệu nhân khẩu học (Demographics Confirmed):
   • Đã chốt trực tiếp với Client các con số: 500 cán bộ MOE HQ, 60.000 giáo vụ tại 300 trường học (mỗi trường 200 user), 2.000.000 tài khoản phụ huynh đăng ký, khung giờ hoạt động chính thức (8:00 - 19:00 với cán bộ; 6:00 - 02:00 sáng hôm sau với phụ huynh).
3. Mô hình suy diễn lưu lượng khoa học (Concurrency Derivation):
   • Khi Client từ chối đưa ra số VU đồng thời và ủy quyền cho nhóm kỹ thuật tự tính toán, nhóm đã áp dụng chuẩn e-Services của Chính phủ Singapore:
     • Tỷ lệ phụ huynh đồng thời cao điểm: $0.225% \times 2.000.000 = 4.500\text{ VU}$.
     • Tỷ lệ cán bộ giáo vụ đồng thời cao điểm: $\sim 0.83% \times 60.500 = 500\text{ VU}$.
     • Tổng lưu lượng chịu tải cao điểm chuẩn hóa: $5.000\text{ VU}$ (với tải thường nhật là $2.500\text{ VU}$, tải căng thẳng Stress là $7.500\text{ VU}$, và tải đột biến Spike là $10.000\text{ VU}$).
4. Phân tách ranh giới rõ ràng (Explicit Scoping):
   • Phân biệt minh bạch giữa phần triển khai ngay trong Sprint 1-2 (Req 1: Tài khoản, Req 3: Biểu phí, Req 8: Cổng phụ huynh, Req 9: Thanh toán) và phần hoãn lại Sprint sau (Req 2: Top-Up ngân sách, Req 4: FAS/Trợ cấp, Req 5: Hồ sơ giấy, Req 6: Theo dõi ngân sách, Req 7: Giả lập góc nhìn, Req 10: Nộp FAS hộ gia đình). Kiến trúc dữ liệu vẫn được dự trù đủ chỗ cho quy mô toàn quốc.
5. Thiết kế giải pháp ca biên có chiều sâu kỹ thuật:
   • Đưa ra cơ chế khóa lạc quan (Optimistic Locking) với mã phản hồi HTTP 409 Conflict khi 2 giáo vụ sửa cùng học sinh.
   • Cơ chế ủy thác 2 pha (Two-Phase Commit / Atomic Hold) cho thanh toán kết hợp (vừa trừ tài khoản vừa quẹt thẻ).
   • Cơ chế máy trạng thái CLOSING_PENDING chống xung đột tiền tệ khi tài khoản hết hạn đúng lúc đang thực hiện thanh toán.

1.3. Những điểm tồn tại rủi ro & Khoảng trống kỹ thuật cần tháo gỡ (Technical Gaps & Risks)#

1.4. Kết luận & Điều kiện tiên quyết để nghiệm thu Research#

ĐÁNH GIÁ CUỐI CÙNG: Quá trình Research ĐÃ ĐẠT 85% ĐỘ TRƯỞNG THÀNH cần thiết cho giai đoạn lập kế hoạch kiểm thử (Test Planning). Tài liệu v1.0 là một bản đặc tả chất lượng rất cao, chặt chẽ và bám sát thực tế hơn v0.2 nhiều lần.

4 ĐIỀU KIỆN TIÊN QUYẾT TRƯỚC KHI BẮT ĐẦU CHẠY LOAD TEST:

1. Tổ chức buổi họp ký duyệt Gate C1: Trình bày bảng 5. Open Questions và bảng 2.6 Consolidated Thresholds cho PM/PO để chuyển đổi toàn bộ nhãn màu vàng [Assumption] thành nhãn màu xanh lá [Approved/Confirmed].
2. Cấu hình Mock Server có biến thiên độ trễ (Latency Jitter & Fault Injection): Đảm bảo Mock Payment Gateway mô phỏng đúng $400\text{ms} - 800\text{ms}$ và có tỷ lệ trả về timeout/error ngẫu nhiên ($0.5%$).
3. Thống nhất cấu hình môi trường Test: Xác định tài nguyên cụm Pod Kubernetes (bao nhiêu replicas, bao nhiêu vCPU, bao nhiêu worker thread cho Batch job).
4. Chốt giới hạn API AI: Nhận hạn ngạch API chính thức từ khách hàng trước khi mở kịch bản kiểm thử tải AI Assistant.

PHẦN II: TÓM TẮT TOÀN DIỆN NỘI DUNG ĐẶC TẢ HIỆU NĂNG (3-TIER LOSSLESS SUMMARY)#

Tuân thủ nghiêm ngặt kỹ thuật tổng hợp không suy hao thông tin (Lossless 3-Tier Cognitive Synthesis), toàn bộ nội dung của đặc tả v1.0 được cấu trúc thành 3 tầng nhận thức:

+-------------------------------------------------------------------------+
|  TIER 1: EXECUTIVE BRIEF (TL;DR)                                        |
|  Bản chất hệ thống, Phân kỳ Sprint, Quy mô quốc gia & Tóm tắt kết luận |
+-------------------------------------------------------------------------+
                                     |
                                     v
+-------------------------------------------------------------------------+
|  TIER 2: TRỤ CỘT KỸ THUẬT, MA TRẬN SLA & GIẢI PHÁP CA BIÊN (DEEP-DIVE)   |
|  - 4 Phân hệ Core: Req 1 (Account/Batch), Req 3 (School/Fee),            |
|                    Req 8 (Parent/SingPass), Req 9 (Payment)             |
|  - Ma trận ngưỡng định lượng (P90/P95/P99, Batch, Error Rate)            |
|  - Mô hình 4 bài test: Load (5k), Stress (7.5k), Spike (10k), Soak (8h)  |
|  - Giải pháp ca biên: Optimistic Lock, 2PC, CLOSING_PENDING             |
|  - Sơ đồ tương tác kiến trúc (Mermaid State / Sequence / Flow)          |
+-------------------------------------------------------------------------+
                                     |
                                     v
+-------------------------------------------------------------------------+
|  TIER 3: KẾ HOẠCH HÀNH ĐỘNG, THUẬT NGỮ CHUẨN HÓA & FAQ STAKEHOLDER      |
|  Checklist RACI theo vai trò, Từ điển thuật ngữ & Giải đáp thắc mắc      |
+-------------------------------------------------------------------------+

2.1. Tier 1: Tóm lược điều hành cấp cao (Executive Brief - TL;DR)#

1. Hệ thống là gì và phục vụ ai?
   • Hệ thống Quản lý Tài chính Bộ Giáo dục Singapore (MOE Finance System) là nền tảng số hóa quản lý tài khoản giáo dục cho toàn bộ công dân nhí Singapore từ 7 đến 16 tuổi, phục vụ thu - chi học phí, quản lý trợ cấp tài chính (FAS) và hỗ trợ thanh toán trực tuyến cho phụ huynh.
2. Quy mô dân số & Nền tảng thiết kế:
   • Hệ thống được thiết kế theo quy mô cấp quốc gia: 60.500 cán bộ (500 MOE HQ + 60.000 giáo vụ tại 300 trường học), 2.000.000 tài khoản phụ huynh, và ~400.000 tài khoản học sinh đang hoạt động (~40.000 học sinh/lứa tuổi).
3. Phân kỳ phạm vi chuyển giao (Sprint Scope):
   • Sprint 1 & Sprint 2: Tập trung 4 yêu cầu giao dịch cốt lõi: Tạo/đóng tài khoản giáo dục tự động (Req 1); Quản lý biểu phí nhà trường (Req 3); Cổng dịch vụ phụ huynh qua SingPass (Req 8); và Thanh toán học phí đa phương thức (Req 9).
   • Các Sprint tiếp theo: Mở rộng nạp tiền ngân sách (Req 2), quy trình trợ cấp tài chính FAS & Machine Learning chấm điểm (Req 4), hồ sơ giấy offline (Req 5), thống kê ngân sách (Req 6), giả lập góc nhìn (Req 7), nộp đơn FAS gia đình (Req 10).
4. Lưu lượng tải đỉnh & Ngưỡng SLA then chốt:
   • Hệ thống thiết kế chịu tải cao điểm chuẩn 5.000 người dùng đồng thời (VU) (4.500 phụ huynh + 500 cán bộ).
   • SLA phản hồi giao dịch tra cứu: $P95 \le 1.5 - 2.0\text{ giây}$, $P99 \le 2.5 - 3.0\text{ giây}$.
   • SLA phản hồi ghi dữ liệu/thanh toán: $P95 \le 2.0 - 3.0\text{ giây}$, $P99 \le 3.0 - 5.0\text{ giây}$.
   • Tỷ lệ lỗi cho phép: $< 0.1%$ ở tải chuẩn, $\le 1.0%$ ở tải căng thẳng cực hạn.
   • Batch Job xử lý 40.000 học sinh hoàn tất trong $\le 15\text{ phút}$ (hoặc 400.000 tài khoản trong $\le 45\text{ phút}$).

2.2. Tier 2: Trụ cột kỹ thuật, Ma trận SLA & Giải pháp Ca biên (Technical Deep-Dive)#

A. Bóc tách 4 Trụ cột Nghiệp vụ trong Phạm vi Kiểm thử

B. Ma trận Ngưỡng Chấp thuận Hiệu năng Định lượng (Consolidated SLA Matrix)

C. Thiết kế Kịch bản Tải Đa Tầng (Load Modeling Architecture)

D. Giải pháp Kiến trúc Xử lý Các Ca Biên Kỹ thuật Hiểm hóc

• ⚠️ Vấn đề Hai cán bộ ở cùng trường hoặc giữa trường và HQ cùng mở hồ sơ một học sinh và bấm Lưu chênh nhau vài mili-giây, dẫn tới mất mát dữ liệu (Lost Update).
• 🛡️ Giải pháp v1.0 Áp dụng cơ chế Khóa lạc quan (Optimistic Locking) kèm trường version trong cơ sở dữ liệu.
  • Người dùng bấm Lưu trước: Thành công, version tăng lên $N+1$.
  • Người dùng bấm Lưu sau: Hệ thống phát hiện version gửi lên ($N$) cũ hơn DB ($N+1$), lập tức trả về mã lỗi HTTP 409 Conflict kèm thông báo trực quan, từ chối ghi đè và yêu cầu người dùng nạp lại dữ liệu mới nhất.

• ⚠️ Vấn đề Phụ huynh thanh toán hóa đơn 100$ bằng cách trừ 40$ từ tài khoản giáo dục và quẹt thẻ online 60$. Nếu phần online thất bại do mất mạng ngân hàng, 40$ tài khoản giáo dục sẽ bị "treo" hoặc bị mất.
• 🛡️ Giải pháp v1.0 Áp dụng mô hình Giao dịch phân tán 2 pha (2-Phase Commit / Atomic Reservation):

1. Nhiệm vụ hành động ngay lập tức (Immediate Action Items)#

1. Trình ký Biên bản Phê duyệt Giả định (Sign-off Meeting):
   • Lấy bảng 5. Open Questions trong tài liệu v1.0 làm nội dung họp chính với Product Owner và Project Manager.
   • Chốt chính thức bằng văn bản cho 3 câu hỏi sống còn: (1) Thời gian chạy Batch Job $\le 15\text{ phút}$ hay nới lỏng?; (2) Ngưỡng lỗi $< 0.1%$ có được chấp nhận?; (3) Tỷ lệ phụ huynh đồng thời $5.000\text{ VU}$ đã thỏa mãn yêu cầu nghiệp vụ chưa?
2. Kỹ thuật hóa Mock Servers:
   • Không được dùng hardcoded response. Viết thêm logic delay ngẫu nhiên có phân phối chuẩn (Gaussian distribution) cho Mock SingPass ($150 - 250\text{ms}$) và Mock Cổng thanh toán ($400 - 800\text{ms}$).
   • Bổ sung kịch bản giả lập lỗi mạng ngân hàng ($1%$ trả về timeout hoặc mã từ chối giao dịch) để kiểm chứng cơ chế giải phóng tiền giữ chỗ (Release Hold) của tính năng Thanh toán kết hợp.
3. Chiến lược sinh dữ liệu mẫu (Data Seeding Strategy):
   • Viết script tạo dữ liệu tự động đạt đủ các cột mốc: 350 trường, 50.000 lớp, 60.500 tài khoản giáo vụ, 2.000.000 tài khoản phụ huynh và 400.000 tài khoản học sinh có phân bổ độ tuổi đều từ 7 đến 16 tuổi.
   • Đảm bảo các chỉ mục (Indexes) trên cơ sở dữ liệu Postgres/MySQL được đánh đúng trước khi bơm dữ liệu tải.

Báo cáo được tổng hợp và xuất bản tự động theo tiêu chuẩn kỹ nghệ tài liệu Antigravity.