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

1. Xung đột ghi đồng thời khi 2 giáo vụ sửa cùng một học sinh (Concurrent Staff Edit)

• 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.

2. Ca biên thanh toán kết hợp (Split Payment Race Condition)

• 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):

3. Đóng tài khoản khi đang có giao dịch thanh toán dở dang (Account Closure Conflict)

• Vấn đề: Batch Job chạy lúc 02:00 sáng để đóng tài khoản của học sinh tròn 16 tuổi và chuyển tiền về CPF, đúng lúc phụ huynh đang thực hiện giao dịch thanh toán học phí lúc 01:59.
• Giải pháp v1.0: Áp dụng máy trạng thái trung gian CLOSING_PENDING:

2.3. Tier 3: Kế hoạch phân công (RACI), Thuật ngữ chuẩn hóa & FAQ Stakeholder#

A. Ma trận Trách nhiệm Thực thi (RACI Matrix)

(Ghi chú: R = Responsible - Người thực hiện; A = Accountable - Người phê duyệt/chịu trách nhiệm chính; C = Consulted - Người tham vấn; I = Informed - Người được thông báo).

B. Từ điển Thuật ngữ Chuẩn hóa (Glossary)

• SingPass: Hệ thống định danh điện tử quốc gia của Chính phủ Singapore, đóng vai trò Cổng xác thực danh tính duy nhất cho phụ huynh.
• CPF (Central Provident Fund): Quỹ Tiết kiệm Trung ương Singapore, nơi toàn bộ số dư còn lại của tài khoản giáo dục sẽ tự động chuyển về sau khi học sinh tròn 16 tuổi.
• MOEFAS / SBFAS: MOEFAS là Chương trình Trợ cấp Tài chính tiêu chuẩn cấp quốc gia của Bộ Giáo dục; SBFAS là Quỹ Trợ cấp riêng do từng trường tự chủ duyệt ngân sách.
• Virtual Users (VU): Số lượng người dùng ảo được sinh ra từ công cụ kiểm thử tải (như k6, JMeter) nhằm mô phỏng hành vi của người dùng thực.
• Percentile (P90, P95, P99): Chỉ số bách phân vị đo độ trễ. Ví dụ: $P95 \le 2.0\text{s}$ nghĩa là $95%$ tổng số yêu cầu gửi lên máy chủ phản hồi trong vòng dưới $2.0$ giây, chỉ có tối đa $5%$ yêu cầu vượt quá con số này.
• Optimistic Locking: Cơ chế khóa lạc quan không giam giữ tài nguyên DB, chỉ so sánh số hiệu phiên bản (version) lúc ghi để ngăn ngừa ghi đè dữ liệu xung đột.
• Two-Phase Commit (2PC): Giao dịch phân tán 2 pha đảm bảo tính nguyên tử (Atomicity): hoặc là cả tài khoản nội bộ và cổng ngân hàng đều hoàn tất, hoặc là hủy bỏ và hoàn tiền toàn bộ.

C. Bảng Giải đáp Thắc mắc Thường gặp của Stakeholder (FAQ)

Q1: Tại sao hệ thống có 2 triệu phụ huynh mà kiểm thử tải cao điểm chỉ chạy 5.000 VU? Con số này có quá thấp không?

Trả lời: Không hề thấp. Có sự khác biệt cốt lõi giữa Tổng số tài khoản đăng ký (Registered Pool) và Số người cùng bấm nút tại một thời điểm (Concurrent Active Users). Theo số liệu vận hành thực tế của các dịch vụ công Chính phủ Singapore (như GovTech e-Services), tỷ lệ đồng thời của người dân thường dao động từ $0.1%$ đến $0.3%$. Với $2.000.000$ tài khoản phụ huynh, tỷ lệ $0.225%$ tương ứng $4.500\text{ VU}$. Khi cộng thêm $500$ cán bộ giáo vụ ($~1%$ của $60.500$ cán bộ), tổng tải đồng thời $5.000\text{ VU}$ sinh ra lưu lượng cực lớn (khoảng $1.000 - 2.500\text{ Requests/Giây}$ tùy thuộc think-time). Ngoài ra, tài liệu v1.0 đã dự phòng kịch bản Stress $7.500\text{ VU}$ và Spike $10.000\text{ VU}$ để thử thách sức chịu đựng tối đa của hệ thống.

Q2: Tại sao 6 yêu cầu (Req 2, 4, 5, 6, 7, 10) bị loại khỏi đợt test Sprint 1-2 này? Có phải bỏ quên không?

Trả lời: Hoàn toàn không bỏ quên. Trong mô hình phát triển phần mềm Agile/Scrum, các chức năng được phân phối theo từng phân kỳ tăng trưởng (Sprint Increments). Sprint 1 và 2 tập trung xây dựng nền móng giao dịch cốt lõi: tạo tài khoản, quản lý dữ liệu trường lớp, hiển thị hóa đơn và thanh toán (Req 1, 3, 8, 9). Các tính năng phức tạp như phê duyệt trợ cấp tài chính FAS kèm AI chấm điểm (Req 4) hay quy trình số hóa đơn giấy (Req 5) thuộc về các Sprint sau. Tuy nhiên, kiến trúc hạ tầng và cơ sở dữ liệu ở v1.0 đã được thiết kế sẵn sàng cho quy mô quốc gia 400.000 học sinh để khi lắp ghép các Sprint sau vào sẽ không bị vỡ hiệu năng.

Q3: Nếu Mock SingPass và Mock Ngân hàng phản hồi nhanh bất thường thì kết quả test có giá trị không?

Trả lời: Đó chính là lý do Tiêu chí kiểm thử v1.0 quy định rõ Mock không được chạy ở chế độ "tức thời" (instant stub 0ms). Nhóm phát triển bắt buộc phải gán độ trễ giả lập đúng chuẩn thực tế: SingPass là $150 - 250\text{ms}$, Cổng thanh toán là $400 - 800\text{ms}$. Nếu không cài đặt độ trễ này, các connection pool trên máy chủ backend sẽ giải phóng quá nhanh, dẫn tới kết quả kiểm thử không phản ánh đúng nguy cơ nghẽn mạng ngoài đời thực.

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#

Dưới đây là bảng đối chiếu chi tiết giữa (1) Tài liệu yêu cầu thô từ Client (Agile business requirement 1.xlsx), (2) Bản thảo sơ khai v0.2 (performance-requirements-v0.2.docx), và (3) Bản đặc tả hoàn thiện v1.0 (performance-requirements-v1.0.docx / .md):

3.2. Phân tích sự chuyển dịch tư duy kiến trúc (Architectural Mindset Evolution)#

[BƯỚC 1: TƯ DUY NGHIỆP VỤ THÔ] 
Tài liệu Client: 'Agile business requirement 1.xlsx'
- Chỉ quan tâm tính năng: Có tạo được tài khoản không? Có trả được tiền không? Có AI không?
- Hoàn toàn không có khái niệm về tải, nghẽn mạng, độ trễ, hay xung đột đồng thời.
                   │
                   ▼
[BƯỚC 2: TƯ DUY NỘI SUY SƠ KHAI (MÔ HÌNH NHỎ)]
Bản thảo v0.2: 'performance-requirements-v0.2.docx'
- Thấy được sự cần thiết của kiểm thử tải nhưng tự ti về quy mô, coi là "training prototype".
- Đưa ra con số an toàn nhỏ bé (10 - 20 người dùng).
- Liệt kê hàng loạt bế tắc (14 câu hỏi không lời đáp, 11 giả định không ai kiểm chứng).
                   │
                   ▼
[BƯỚC 3: TƯ DUY HỆ THỐNG DOANH NGHIỆP CẤP QUỐC GIA]
Bản đặc tả v1.0: 'performance-requirements-v1.0.docx'
- Đối thoại trực tiếp với khách hàng để chốt quy mô thật (National Scale: 60.5k staff, 2M parents, 400k accounts).
- Sử dụng mô hình toán học và chuẩn quốc gia (Singapore e-Services benchmark) để nội suy 5.000 VU.
- Thiết kế kiến trúc chịu tải: Phân bổ tài nguyên, khóa lạc quan, 2-phase commit, máy trạng thái ca biên.
- Minh bạch rủi ro bằng cơ chế gắn nhãn màu: Xanh lá [Confirmed] vs Vàng [Assumption].

PHẦN IV: KHUYẾN NGHỊ THỰC THI & LỘ TRÌNH TRIỂN KHAI TIẾP THEO#

Để đưa bộ đặc tả v1.0 vào thực thi thực tế mà không gặp rủi ro pháp lý hay kỹ thuật, nhóm dự án cần thực hiện lộ trình 4 bước hành động cụ thể sau:

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.