sys-analysis-design/e-commerce/docs/sections/09-van-hanh-kiem-thu.md

section, title, status, version, reviewer_notes

section	title	status	version	reviewer_notes
09	Kế hoạch vận hành & Kiểm thử	approved	1

9. Kế hoạch vận hành & Kiểm thử (Testing & Deployment)

Đầu vào: 00-project-brief.md (profile: scale=large, hasPayment=true, hasPII=true, cloud AWS, Dev/Staging/Production, on-call giờ hành chính + escalation 24/7); 02-phan-tich-yeu-cau.md (FR-01..FR-27, NFR-01..NFR-08); 03-kien-truc.md (11 service, môi trường 3.3, tích hợp bên thứ ba 3.4); 05-thiet-ke-du-lieu.md v3 (backup/RTO-RPO 5.3.2, retention 5.3.6); 06-luong-xu-ly.md v2 (Business Rules BR-01..BR-15, sequence checkout/payout/KYC/dispute/login); 08-bao-mat.md v2 (§8.1–8.5, OWASP, findings F10/F11/F12/F14 tồn đọng).

Right-sizing: scale=large + hasPayment=true + hasPII=true → áp dụng đầy đủ pipeline CI/CD nhiều bước (build → test → scan → deploy theo môi trường), monitoring/alerting chi tiết theo NFR, và kế hoạch DR có RTO/RPO phân nhóm theo mức độ nghiêm trọng của service — không có mục nào được rút gọn thành "không áp dụng" ở phần này.

9.1 Chiến lược kiểm thử (Test Strategy)

9.1.1 Unit Testing

Hạng mục	Nội dung
Phạm vi	Business logic thuần trong từng service — đặc biệt các công thức/quy tắc phức tạp: BR-01 (tách đơn theo seller), BR-02 (giữ tồn kho), BR-03 (tính hoa hồng), BR-04/BR-05 (kỳ giữ tiền/điều kiện release payout), BR-06/BR-07/BR-08 (loyalty), BR-09 (điều kiện coupon), BR-10 (điều kiện huỷ đơn), BR-11 (điều kiện review), BR-12 (chính sách MFA/lockout — §8.1.1a), BR-13 (duyệt KYC), BR-14 (dispute), BR-15 (fallback vận chuyển)
Trách nhiệm	Đội phát triển sở hữu từng service (Identity, Catalog, Cart & Order, Payment, Seller Management, Commission & Payout, Promotion & Loyalty, Review, Notification, Shipping & Fulfillment, Audit & Compliance) — mỗi PR bắt buộc kèm unit test cho logic mới/sửa
Công cụ	JUnit/Jest/PyTest tuỳ stack thực thi (kiến trúc sư chưa ràng buộc ngôn ngữ cụ thể ở mục 3 — giả định stack backend phổ biến cho microservices, VD Node.js/Java/Go); coverage tối thiểu khuyến nghị 70% cho module business logic của Cart & Order, Payment, Commission & Payout (service tài chính/giao dịch cốt lõi); 50% cho service ít rủi ro hơn (Review, Notification)
Ngưỡng chặn merge	Build fail nếu coverage giảm so với baseline hoặc unit test đỏ — enforce ở bước "test" của pipeline CI/CD (9.3)

9.1.2 Integration Testing

Hạng mục	Nội dung
Phạm vi	(a) Giao tiếp đồng bộ REST giữa BFF ↔ service nội bộ (VD Cart & Order ↔ Catalog khi reserve tồn kho — BR-02); (b) luồng bất đồng bộ qua Message Broker (Kafka/MSK) — OrderPlaced, PaymentConfirmed, OrderDelivered, CommissionCalculated, PayoutScheduled, SellerApproved, các domain event ghi audit_log; (c) tích hợp bên thứ ba ở môi trường Staging dùng sandbox: VNPay/Momo (sandbox), GHN/GHTK (sandbox), Google/Facebook OAuth (test app), email/SMS provider (test mode)
Trách nhiệm	QA + đội backend liên quan; test theo ranh giới bounded-context (mục 3.1) — không kiểm thử xuyên transaction DB vật lý (vì database-per-service, chỉ có FK logic qua event)
Công cụ	Postman/Newman hoặc REST-assured cho API; Testcontainers (Kafka, PostgreSQL) hoặc môi trường Staging thực để test contract giữa producer/consumer event; contract testing (Pact) khuyến nghị cho các cặp service có API nội bộ thay đổi thường xuyên (VD Cart & Order ↔ Commission & Payout)
Trọng tâm rủi ro cao	Idempotency của webhook thanh toán (chống replay, mục 4/8 v3), saga đặt hàng → thanh toán → trừ kho → hoa hồng (BR-01/02/03), fallback vận chuyển GHN→GHTK (BR-15)

9.1.3 UAT (User Acceptance Testing)

Hạng mục	Nội dung
Phạm vi	Toàn bộ FR Must (FR-01, 03–09, 12, 17–19, 21–26) theo kịch bản nghiệp vụ đầu-cuối trên môi trường Staging (dữ liệu ẩn danh hoá, không PII/KYC thật — theo mục 3.3); FR Should/Could (FR-02, 10, 11, 13–16, 20, 27) kiểm thử nếu đã hoàn thành trong phạm vi release
Trách nhiệm	Product Owner + đại diện nghiệp vụ (vận hành sàn, CSR, đại diện seller nếu có) xác nhận; QA chuẩn bị kịch bản, môi trường, dữ liệu test
Kịch bản tiêu biểu	Checkout đa seller trọn vẹn (duyệt → giỏ hàng → thanh toán → theo dõi đơn → nhận hàng → đánh giá); seller onboarding từ đăng ký đến payout đầu tiên; CSR xử lý một khiếu nại từ đầu đến khi payout bị loại/được release
Điều kiện thoát (exit criteria)	100% kịch bản UAT cho FR Must đạt "Pass"; các FR Should/Could không đạt được ghi nhận là known-issue có kế hoạch khắc phục trước go-live hoặc lùi sau go-live theo quyết định Product Owner

9.1.4 Performance Testing (gắn NFR cụ thể)

NFR	Kịch bản tải	Ngưỡng chấp nhận	Công cụ
NFR-01	Duyệt catalog/tìm kiếm sản phẩm (FR-04) ở tải bình thường và tải đỉnh mô phỏng flash sale	p95 response time < 2 giây	k6/JMeter/Gatling, chạy trên môi trường Staging có cấu hình gần Production (mục 3.3)
NFR-01	Checkout & thanh toán (FR-06, FR-07) ở tải đỉnh	p95 hoàn tất checkout < 3 giây, kể cả khi Catalog/Search đang chịu tải đỉnh song song	k6/JMeter, kịch bản kết hợp đồng thời checkout + browse
NFR-02	Load test mô phỏng flash sale: tăng dần từ tải bình thường lên hàng chục nghìn concurrent users, đo khả năng cache (Redis)/CDN hấp thụ tải đọc và message queue hấp thụ đột biến ghi (đặt hàng)	Không tăng lỗi 5xx đáng kể; queue lag (thời gian xử lý event OrderPlaced→PaymentConfirmed→CommissionCalculated) không vượt ngưỡng cảnh báo (xem 9.4); không xảy ra oversell (BR-02) dưới tải đồng thời cao	k6 (ramping-arrival-rate), theo dõi qua APM/dashboard mục 9.4
NFR-03	Chaos/failover test: chủ động tắt 1 instance của service giao dịch cốt lõi (Cart & Order, Payment, Identity) trong lúc có tải	Auto-scaling/Multi-AZ tự phục hồi, downtime cảm nhận bởi client tối thiểu, không vi phạm mục tiêu uptime 99.9% trong cửa sổ kiểm thử	AWS Fault Injection Simulator hoặc kịch bản thủ công (dừng task ECS)
Trách nhiệm	Đội DevOps/SRE chủ trì kịch bản và hạ tầng đo; đội backend hỗ trợ phân tích bottleneck theo service
Tần suất	Trước mỗi lần go-live/major release, và định kỳ trước mùa cao điểm (VD trước các đợt khuyến mãi lớn dự kiến)

Ghi chú: NFR-01/NFR-03 là giả định mặc định đã chốt ở brief (chưa có SLA hợp đồng thực tế xác nhận) — nếu số liệu tải thực tế sau go-live khác biệt đáng kể so với giả định "large" ở mục 1/5, cần điều chỉnh lại kịch bản/ngưỡng performance test (đã ghi trong openQuestions).

9.1.5 Security Testing (dựa trên findings mục 8)

Hạng mục	Nội dung	Nguồn
SAST (Static Application Security Testing)	Quét mã nguồn mỗi lần build trong CI/CD (SonarQube hoặc Semgrep) — tập trung vào các endpoint ghi dữ liệu (checkout, KYC upload, commission rule) theo rủi ro A03 Injection đã nêu ở mục 8.3	§8.3 A03
SCA/Dependency scanning	Snyk/Trivy/Dependabot quét lỗ hổng thư viện của mọi service (container ECS Fargate/EKS) — chặn build nếu phát hiện lỗ hổng mức Critical/High chưa có bản vá	§8.3 A06
DAST/Penetration test	Pentest ứng dụng hàng năm + ASV scan hàng quý nếu phạm vi PCI-DSS SAQ A yêu cầu (mục 8.4) — ưu tiên các luồng thanh toán, KYC upload, webhook	§8.4
Kiểm thử theo finding tồn đọng mục 8	F10 (MSK ACL/TLS — kiểm tra service không liên quan không subscribe được topic PII/tài chính); F11 (khi endpoint pre-signed URL KYC được bổ sung ở mục 4 — kiểm tra TTL ≤5 phút, không lộ file_url_s3 trực tiếp); F12 (khi mã lỗi 423 ERR_ACCOUNT_LOCKED được bổ sung — kiểm tra hành vi khoá/mở khoá đúng theo bảng §8.1.1a); F13 (khi endpoint GET /v1/admin/audit-logs được bổ sung — kiểm tra chỉ scope admin:audit:read truy cập được, dữ liệu nhạy cảm đã redact theo §8.2.5a)	§8.5 F10, F11, F12, F13
Account lockout / brute-force	Test chủ động: đăng nhập sai liên tiếp theo ngưỡng từng vai trò (Customer/Seller 5 lần → khoá 15 phút; Platform Admin 3 lần → khoá 30 phút — §8.1.1a); xác minh không lộ "email có tồn tại hay không" ở thông báo lỗi thông thường	§8.1.1a
OAuth/social login	Test giả mạo state (kỳ vọng 400 ERR_OAUTH_STATE_INVALID), test email trùng tài khoản có sẵn (kỳ vọng 409 ERR_ACCOUNT_LINK_REQUIRED, không auto-merge)	§8.1.1, §8.3
Webhook replay/idempotency	Gửi lại IPN VNPay/Momo với timestamp quá hạn hoặc gatewayTransactionRef trùng lặp — kỳ vọng bị từ chối/không lặp side-effect	§8.3 A08
PII masking trong log	Kiểm tra log CloudWatch/APM không lộ email/phone/account_number đầy đủ ở môi trường Production	§8.2.3
Trách nhiệm	Security champion trong mỗi đội (do chưa có đội Security/Compliance Officer riêng theo brief) phối hợp DevOps chạy scan tự động trong pipeline; pentest/ASV scan thuê ngoài định kỳ

9.2 Kịch bản kiểm thử (Test Cases)

Quy ước: mỗi TC-xx gắn đúng 1 FR-xx. Chỉ viết test case khi FR có acceptance criteria đủ rõ để suy ra Given-When-Then; trường hợp FR/BR còn thiếu số liệu cụ thể (VD ngưỡng VND hạng thành viên, công thức hoàn tiền dispute), test case nêu rõ phần chưa kiểm thử được và dẫn sang openQuestions.

9.2.1 Khách hàng & tài khoản

TC	FR	Priority	Given	When	Then
TC-01	FR-01	Must	Guest chưa có tài khoản, nhập email hợp lệ chưa tồn tại	Gửi POST /v1/auth/register với email/mật khẩu hợp lệ (≥10 ký tự)	Tài khoản Customer được tạo, password_hash lưu bằng bcrypt/argon2id, trả 201
TC-02	FR-01	Must	Tài khoản Customer tồn tại, nhập sai mật khẩu 5 lần liên tiếp trong thời gian ngắn	Gửi POST /v1/auth/login lần thứ 6	user_account.locked_until = now + 15 phút (§8.1.1a); phản hồi không tiết lộ email có tồn tại hay không; lần đăng nhập tiếp theo trong 15 phút bị từ chối ngay không so khớp mật khẩu
TC-03	FR-02	Could	Email a@x.com đã có tài khoản email/password, chưa liên kết OAuth	Đăng nhập Google bằng cùng email a@x.com	Hệ thống không tự merge tài khoản; trả 409 ERR_ACCOUNT_LINK_REQUIRED, yêu cầu xác minh sở hữu email trước khi liên kết
TC-04	FR-03	Must	Customer đã đăng nhập, có 1 địa chỉ mặc định	Thêm địa chỉ giao hàng mới và đặt làm mặc định	Địa chỉ mới được lưu với is_default=true; địa chỉ cũ tự động chuyển is_default=false

9.2.2 Catalog, giỏ hàng & checkout

TC	FR	Priority	Given	When	Then
TC-05	FR-04	Must	Catalog có sản phẩm thuộc nhiều seller/category	Guest tìm kiếm theo từ khoá + lọc theo category	Kết quả trả về đúng sản phẩm khớp bộ lọc, thời gian phản hồi p95 < 2s (NFR-01)
TC-06	FR-05	Must	Giỏ hàng trống của Guest (theo session_id)	Thêm sản phẩm từ Seller A và Seller B vào cùng giỏ hàng	Cart chứa CartItem với seller_id khác nhau trong cùng một Cart
TC-07	FR-06	Must	Giỏ hàng có sản phẩm từ 2 seller, đủ tồn kho	Gọi POST /v1/checkout	Hệ thống tạo 1 Order cha và 2 OrderSeller con tương ứng 2 seller (BR-01); Order.totalAmount = tổng OrderSeller.subtotalAmount
TC-08	FR-06	Must	Sản phẩm trong giỏ hàng có quantity_available - quantity_reserved < quantity yêu cầu	Gọi POST /v1/checkout	Trả 409 ERR_CONFLICT, không tạo Order, không tăng quantity_reserved (BR-02)
TC-09	FR-07	Must	Đơn hàng ở trạng thái pending_payment, khởi tạo thanh toán VNPay	VNPay gửi IPN với chữ ký hợp lệ, timestamp trong 5 phút	Payment.status=success; event PaymentConfirmed được publish; Order/OrderSeller.status=confirmed
TC-10	FR-07	Must	Một giao dịch VNPay đã được xác nhận thành công (gatewayTransactionRef đã ghi nhận)	VNPay gửi lại IPN trùng gatewayTransactionRef (retry tự nhiên của gateway) hoặc timestamp lệch > 5 phút	Hệ thống trả 200 OK không lặp side-effect (idempotent) cho retry hợp lệ; từ chối 400 ERR_VALIDATION cho timestamp quá hạn — không tạo PaymentConfirmed lần 2
TC-11	FR-08	Must	OrderSeller.status=pending	Customer gọi huỷ đơn	Đơn chuyển cancelled (BR-10)
TC-11b	FR-08	Must	OrderSeller.status=packed	Customer gọi huỷ đơn	Bị từ chối — Customer phải dùng luồng đổi trả/khiếu nại (FR-09) thay vì huỷ trực tiếp (BR-10)
TC-12	FR-09	Must	OrderSeller.status=delivered	Customer gửi POST /v1/orders/{orderId}/return-requests	Tạo ReturnRequest(status=requested); nếu PayoutHold liên quan đang holding, chuyển disputed_frozen (BR-14a)
TC-13	FR-10	Should	Customer đã đăng nhập	Thêm sản phẩm vào wishlist, sau đó xoá	WishlistItem được tạo rồi xoá; không cho trùng lặp (UNIQUE customer_id, product_id)
TC-14	FR-11	Should	Customer đã mua order_item X, OrderSeller.status=delivered	Gửi đánh giá rating 5 sao cho sản phẩm trong order_item X	Review được tạo thành công (BR-11)
TC-14b	FR-11	Should	OrderSeller.status=confirmed (chưa giao hàng)	Gửi đánh giá cho sản phẩm chưa nhận	Bị từ chối — không cho phép đánh giá trước khi delivered (BR-11)
TC-15	FR-12	Must	Đơn hàng vừa chuyển PaymentConfirmed	Notification Service consume event	Email/SMS xác nhận đơn hàng được gửi tới Customer trong thời gian hợp lý (không chặn luồng checkout chính)
TC-16	FR-13	Should	Coupon SALE10 đang active, còn lượt dùng, đơn hàng đạt min_order_amount	Áp coupon tại checkout	Giảm giá đúng theo type/value (BR-09); ghi PromotionUsage UNIQUE theo (promotion_id, order_id)
TC-16b	FR-13	Should	Coupon đã hết usage_limit	Áp coupon tại checkout	Bị từ chối, không áp dụng giảm giá (BR-09)

9.2.3 Loyalty, đa ngôn ngữ/tiền tệ

TC	FR	Priority	Given	When	Then
TC-17	FR-14	Should	OrderSeller với subtotalAmount = 250,000đ chuyển delivered	Loyalty Service consume event OrderDelivered	LoyaltyTransaction(type=earn, points=25) theo BR-06 (floor(250000/10000)=25) — lưu ý: cách tính trên subtotalAmount từng OrderSeller là giả định của mục 6, cần xác nhận chủ dự án trước go-live (xem openQuestions)
TC-17b	FR-14	Should	LoyaltyAccount.points_balance = 500	Customer đổi 300 điểm lấy giảm giá	Giảm giá 30,000đ được áp dụng, points_balance còn 200, ghi LoyaltyTransaction(type=redeem, points=-300) theo bội số 100 (BR-08)
TC-18	FR-15	Should	Sản phẩm có product_i18n cho vi, en, ja	Customer chuyển ngôn ngữ hiển thị sang en rồi ja	Tên/mô tả sản phẩm hiển thị đúng bản dịch tương ứng; ngôn ngữ chưa có bản dịch fallback về vi (mặc định)
TC-19	FR-16	Could	Sản phẩm giá 500,000 VND, exchange_rate USD đã cấu hình	Customer xem trang sản phẩm với hiển thị tiền tệ USD	Giá quy đổi tham khảo hiển thị đúng theo rate_to_vnd; giao dịch checkout vẫn thực hiện bằng VND (không thanh toán trực tiếp ngoại tệ)

9.2.4 Seller, KYC, commission & payout

TC	FR	Priority	Given	When	Then
TC-20	FR-17	Must	Seller mới đăng ký, upload đủ 3 tài liệu bắt buộc (business_license, id_card_front, id_card_back)	Admin duyệt verified cho cả 3 tài liệu	Seller.status=active, event SellerApproved publish (BR-13)
TC-20b	FR-17	Must	Seller đã upload đủ tài liệu	Admin từ chối 1 tài liệu (rejected)	Seller.status=rejected kèm reason; Seller có thể nộp lại (quay về pending_kyc)
TC-21	FR-18	Must	Seller sở hữu ProductVariant với quantity_available=10	Seller cập nhật tồn kho thành 20 và đổi giá bán	inventory_stock.quantity_available=20, product_variant.price_amount cập nhật; sản phẩm khác của seller khác không bị ảnh hưởng
TC-22	FR-19	Must	Seller A có đơn order_seller X; Seller B không liên quan tới X	Seller B gọi GET /v1/seller/orders/{X}	Trả 403 ERR_FORBIDDEN_OWNERSHIP (kiểm soát ownership §8.1.2); Seller A gọi cùng endpoint → trả dữ liệu thành công
TC-23	FR-20	Should	Seller có CommissionTransaction và Payout trong kỳ gần nhất	Seller xem GET /v1/seller/payouts	Hiển thị đúng doanh thu, hoa hồng, trạng thái payout (scheduled/processing/paid/failed) chỉ của chính seller đó
TC-24	FR-21	Must	Category "Điện tử" chưa có CommissionRule hiệu lực	Admin cấu hình commission_percent=8%, effective_from=hôm nay	CommissionRule mới được tạo, có hiệu lực từ ngày chỉ định; đơn hàng phát sinh sau đó tính hoa hồng theo BR-03; action ghi audit_log (CommissionRuleUpdated)
TC-25	FR-22	Must	PayoutHold.hold_until_date đã qua, không có Dispute mở cho order_seller liên quan	Job payout hàng tuần chạy	PayoutHold.release_status=released, CommissionTransaction.net_amount được gộp vào Payout mới của seller (BR-04/BR-05)
TC-25b	FR-22	Must	Payout.status=processing được gửi ngân hàng	Ngân hàng từ chối batch (lỗi định dạng)	Payout.status=failed; hệ thống không tự động thử lại; Admin gọi POST /v1/admin/payouts/{payoutId}/retry thủ công sau xác minh; hành động ghi audit_log
TC-26	FR-23	Must	Seller đang active, bị phát hiện vi phạm	Admin khoá seller (PATCH /v1/admin/sellers/{sellerId}/status)	Seller.status=suspended; seller không thể đăng sản phẩm/nhận đơn mới cho tới khi được Admin mở khoá lại; action ghi audit_log
TC-27	FR-24	Must	Sản phẩm đang active, bị báo cáo vi phạm	Admin ẩn sản phẩm toàn sàn	Product.status=hidden_by_admin; sản phẩm không còn hiển thị ở Catalog/Search (kể cả khi seller vẫn active)

9.2.5 Tranh chấp, vận chuyển, MFA

TC	FR	Priority	Given	When	Then
TC-28	FR-25	Must	Dispute.status=investigating, CSR đã được gán	CSR quyết định refund qua PATCH /v1/admin/disputes/{disputeId}	Dispute.status=resolved; Payment.status=refunded; PayoutHold liên quan chuyển reversed (loại vĩnh viễn khỏi payout, không bao giờ released — BR-14); action ghi audit_log
TC-28b	FR-25	Must	Dispute.status=investigating	CSR quyết định reject	ReturnRequest.status=rejected; PayoutHold quay lại holding, chờ hold_until_date release bình thường
TC-29	FR-26	Must	OrderSeller.status=confirmed, Ops đóng gói xong	Shipping Service gọi GHN tạo vận đơn thành công	Shipment tạo với tracking_number; OrderSeller.status=shipped; webhook GHN cập nhật delivered → publish OrderDelivered
TC-29b	FR-26	Must	GHN timeout sau 3 lần retry, khu vực giao hàng được GHTK hỗ trợ	Shipping Service fallback	Vận đơn được tạo qua GHTK thay thế (BR-15); nếu cả hai lỗi, đưa vào hàng đợi Ops xử lý thủ công, OrderSeller.status không bị chặn
TC-30	FR-27	Should	role=platform_admin, mfa_enabled=false	Đăng nhập bằng email/password đúng	Đăng nhập thành công nhưng bị chặn hoàn toàn scope admin:* cho tới khi hoàn tất mfa/enroll (BR-12)
TC-30b	FR-27	Should	role=platform_admin, mfa_enabled=true	Đăng nhập đúng mật khẩu	Hệ thống yêu cầu OTP (mfaRequired:true); nhập đúng OTP → nhận accessToken; nhập sai OTP quá 5 lần → challenge token bị vô hiệu

9.2.6 Bảng tổng hợp Test Case → FR (dùng để điền Traceability Matrix mục 2.4)

FR	Test Case
FR-01	TC-01, TC-02
FR-02	TC-03
FR-03	TC-04
FR-04	TC-05
FR-05	TC-06
FR-06	TC-07, TC-08
FR-07	TC-09, TC-10
FR-08	TC-11, TC-11b
FR-09	TC-12
FR-10	TC-13
FR-11	TC-14, TC-14b
FR-12	TC-15
FR-13	TC-16, TC-16b
FR-14	TC-17, TC-17b
FR-15	TC-18
FR-16	TC-19
FR-17	TC-20, TC-20b
FR-18	TC-21
FR-19	TC-22
FR-20	TC-23
FR-21	TC-24
FR-22	TC-25, TC-25b
FR-23	TC-26
FR-24	TC-27
FR-25	TC-28, TC-28b
FR-26	TC-29, TC-29b
FR-27	TC-30, TC-30b

Toàn bộ FR-01..FR-27 đều có ít nhất 1 test case. Một số test case (TC-17, TC-25) có phần "chưa kiểm thử được đầy đủ" vì thiếu số liệu chốt (ngưỡng VND hạng thành viên, công thức hoàn tiền dispute, ngân hàng đối tác cụ thể) — xem openQuestions/findings.

9.3 CI/CD & Bảo mật pipeline

9.3.1 Pipeline build → test → scan → deploy

flowchart LR
    Commit["Commit / Pull Request"] --> Build["Build\n(container image per service)"]
    Build --> UnitTest["Unit Test\n(coverage gate 9.1.1)"]
    UnitTest --> SAST["SAST\n(SonarQube/Semgrep)"]
    SAST --> SCA["Dependency scan\n(Snyk/Trivy/Dependabot)"]
    SCA --> Integration["Integration Test\n(Staging sandbox 9.1.2)"]
    Integration --> DeployDev["Deploy → Dev\n(auto, mọi merge vào nhánh dev)"]
    DeployDev --> DeployStaging["Deploy → Staging\n(auto sau QA sign-off)"]
    DeployStaging --> UAT["UAT + Performance/Security test\n(9.1.3, 9.1.4, 9.1.5)"]
    UAT --> Approval["Phê duyệt thủ công\n(Product Owner + Kiến trúc sư trưởng)"]
    Approval --> DeployProd["Deploy → Production\n(canary/phần trăm rollout — theo feature flag mục 3.3)"]

• Build: mỗi service đóng gói container riêng (khớp mục 3.2 — ECS Fargate/EKS), gắn tag theo commit SHA + semantic version cho release chính thức.
• Test: unit test bắt buộc pass + coverage gate (9.1.1); build fail nếu không đạt.
• Scan: SAST (SonarQube/Semgrep) + SCA (Snyk/Trivy/Dependabot) chạy trên mọi image trước khi cho phép deploy; chặn deploy nếu phát hiện lỗ hổng Critical/High chưa có ngoại lệ được phê duyệt.
• Deploy theo môi trường (khớp mục 3.3):
  • Dev: tự động sau mỗi merge vào nhánh phát triển; feature flag mặc định bật.
  • Staging: tự động sau khi Dev pass, dùng dữ liệu ẩn danh hoá/giả lập (không PII/KYC thật) để chạy Integration/UAT/Performance/Security test.
  • Production: chỉ deploy sau khi UAT pass và có phê duyệt thủ công (Product Owner + Kiến trúc sư trưởng); rollout theo canary/phần trăm người dùng cho tính năng rủi ro cao (thay đổi luồng thanh toán/commission — đã chốt ở mục 3.3).

9.3.2 Phân quyền Production & quản lý secret trong pipeline

Hạng mục	Thiết kế
Truy cập hạ tầng Production	Chỉ đội Ops và Admin được cấp quyền qua IAM role có audit log (đã chốt mục 3.3); không truy cập DB Production trực tiếp trừ khẩn cấp có phê duyệt
CI/CD → AWS	Ưu tiên OIDC federation (GitHub Actions/GitLab CI ↔ AWS IAM role tạm thời) thay vì access key/secret key dài hạn nhúng trong pipeline — giảm rủi ro lộ credential vĩnh viễn
Secret trong pipeline	Toàn bộ secret (DB credentials, API key VNPay/Momo/GHN/GHTK, OAuth client secret) lấy từ AWS Secrets Manager tại thời điểm chạy, không lưu trong biến môi trường CI dạng plaintext lâu dài, không commit vào repository (đã chốt mục 8.2.2)
Phê duyệt deploy Production	Bắt buộc bước phê duyệt thủ công (manual gate) trong pipeline trước khi deploy Production, tách biệt người phê duyệt và người thực hiện deploy (tách vai trò — segregation of duties)
Rollout rủi ro cao	Thay đổi luồng thanh toán/commission bắt buộc dùng canary/feature flag rollout theo phần trăm người dùng tăng dần (đã chốt mục 3.3), không deploy 100% ngay lập tức
Audit CI/CD	Log lại ai trigger deploy, phiên bản nào, thời điểm nào — phục vụ điều tra sự cố; không bắt buộc ghi vào bảng audit_log nghiệp vụ (mục 5.2.11) vì đây là audit trail hạ tầng/vận hành, khác phạm vi audit nghiệp vụ

9.4 Giám sát & Nhật ký (Monitoring & Logging)

9.4.1 Metrics theo NFR

NFR	Metric	Ngưỡng cảnh báo (alert threshold)	Kênh cảnh báo
NFR-01	p95 latency GET /v1/catalog/search, POST /v1/checkout	Cảnh báo khi p95 > 2s (catalog/search) hoặc > 3s (checkout) liên tục 5 phút	PagerDuty/OpsGenie → on-call giờ hành chính, escalation nếu ảnh hưởng giao dịch (mục 3.3/NFR-08)
NFR-02	Concurrent connections, Redis cache hit ratio, Kafka/MSK consumer lag theo topic (OrderPlaced, PaymentConfirmed...)	Cảnh báo khi cache hit ratio < 80% mùa cao điểm, hoặc consumer lag > ngưỡng xử lý trong 2 phút (VD > 1000 message chưa xử lý)	Cảnh báo đội vận hành domain tương ứng (Catalog/Search, Cart & Order)
NFR-03	Uptime/health check theo service (đặc biệt Cart & Order, Payment, Identity — service giao dịch cốt lõi mục 3.1)	Cảnh báo ngay khi health check fail liên tục > 1 phút cho service cốt lõi; escalation 24/7 nếu ảnh hưởng checkout/thanh toán (NFR-08)	Escalation 24/7 cho sự cố nghiêm trọng, giờ hành chính cho sự cố thường
NFR-04	Số lần đăng nhập sai/khoá tài khoản bất thường (failed_login_count tăng đột biến theo IP/khoảng thời gian), số request bị WAF chặn	Cảnh báo khi phát hiện pattern brute-force/credential stuffing (nhiều tài khoản bị khoá cùng lúc từ cùng dải IP)	Security alert riêng, không lẫn với alert vận hành thông thường
NFR-05	Tỷ lệ ghi audit_log thành công cho hành động nhạy cảm (KYC review, commission update, dispute resolve, payout retry, khoá/mở seller — mục 5.2.11)	Cảnh báo nếu phát hiện hành động nhạy cảm không có bản ghi audit_log tương ứng (event bị mất/consumer lỗi)	Cảnh báo đội vận hành Audit & Compliance Service
NFR-08	SLA phản hồi on-call (thời gian từ alert đến acknowledge)	Cảnh báo leo thang (escalate) nếu on-call không acknowledge trong 15 phút cho sự cố nghiêm trọng ảnh hưởng giao dịch	PagerDuty/OpsGenie escalation chain

9.4.2 Log tập trung & masking PII

• Log tập trung: toàn bộ service ghi log qua CloudWatch Logs (hoặc ELK/OpenSearch dùng chung cluster đã có ở mục 3.2 cho search subsystem, cân nhắc tách index riêng cho log vận hành để không ảnh hưởng hiệu năng search nghiệp vụ); tracing phân tán (distributed tracing, VD AWS X-Ray/OpenTelemetry) cho các luồng xuyên nhiều service (checkout, payout) để debug latency.
• Masking PII trong log (khớp mục 8.2.3): bắt buộc log-scrubber middleware ở tầng ứng dụng trước khi ghi log Production — mask email, phone, account_number, không log password/secret_encrypted/gateway_transaction_ref đầy đủ. Áp dụng đồng nhất cho mọi service, kiểm tra lại bằng security test định kỳ (9.1.5).
• Retention log vận hành: khớp mục 5.3.6 — notification_log/shipment_event 90 ngày trước khi archive lạnh; log APM/tracing đề xuất giữ 30-90 ngày (không quy định trong brief, đây là giả định — xem assumptions).
• audit_log (mục 5.2.11/§8.2.5): không thuộc phạm vi log kỹ thuật ở đây — là dữ liệu nghiệp vụ có retention/kiểm soát truy cập riêng (5 năm/10 năm theo resource_type, chỉ scope admin:audit:read).

9.5 Kế hoạch rollback & khôi phục thảm hoạ (Rollback & DR)

9.5.1 Điều kiện rollback

Điều kiện	Hành động
Tỷ lệ lỗi 5xx tăng vượt ngưỡng (VD > 1% request) ngay sau khi rollout canary tính năng mới	Tự động dừng rollout, revert về phiên bản trước đó qua feature flag (không cần rollback toàn bộ deploy nếu tính năng được cô lập bằng flag — mục 3.3)
Phát hiện lỗi nghiêm trọng ảnh hưởng thanh toán/commission sau khi deploy Production	Rollback thủ công ngay lập tức (revert image về version trước), thông báo escalation 24/7 (NFR-08); không rollback dữ liệu tài chính đã ghi nhận — xử lý bằng nghiệp vụ điều chỉnh (adjustment) nếu cần, không xoá/sửa trực tiếp bản ghi payment/payout đã hoàn tất
Job payout hàng tuần thất bại hàng loạt (VD lỗi kết nối ngân hàng)	Không rollback dữ liệu — giữ nguyên Payout.status=failed, cảnh báo Admin, retry thủ công qua endpoint đã có (mục 6.1.4), không tự động replay để tránh double-payout (đã chốt ở mục 3.4/6.1.4)
Migration schema DB gây lỗi ở Staging/Production	Áp dụng chiến lược migration tương thích ngược (backward-compatible, VD expand-contract pattern) cho mọi thay đổi schema service tài chính/PII; rollback code trước, rollback schema sau nếu bắt buộc (tránh mất dữ liệu mới ghi trong lúc rollback)

9.5.2 RTO/RPO (kế thừa từ mục 5.3.2, không thiết kế lại)

Nhóm service	RPO	RTO	Ghi chú
Payment, Cart & Order, Identity & Access (giao dịch cốt lõi)	≤ 15 phút	≤ 1 giờ	Ưu tiên phục hồi đầu tiên — ảnh hưởng trực tiếp doanh thu/uptime NFR-03
Commission & Payout, Seller Management (tài chính nhạy cảm)	≤ 1 giờ	≤ 4 giờ	Payout không realtime nhưng cần audit trail đầy đủ khi khôi phục
Catalog & Inventory, Promotion & Loyalty, Shipping & Fulfillment	≤ 1 giờ	≤ 8 giờ
Review, Notification, Audit & Compliance	≤ 24 giờ	≤ 24 giờ	Không ảnh hưởng giao dịch trực tiếp

Các con số RTO/RPO trên là giả định đã chốt ở mục 5.3.2 (brief không có SLA hợp đồng cụ thể) — mục 9 kế thừa nguyên trạng, không thay đổi.

9.5.3 Quy trình khôi phục (tham chiếu mục 5 — Backup & Recovery)

1. Xác định phạm vi sự cố: service nào bị ảnh hưởng, dữ liệu mất từ thời điểm nào (dựa trên PITR — Point-in-Time Recovery đã bật cho toàn bộ RDS theo mục 5.3.2).
2. Khôi phục RDS: dùng Automated Backup + PITR (retention 35 ngày cho service tài chính/PII cốt lõi, 14 ngày cho service ít quan trọng — mục 5.3.2) để restore về thời điểm trước sự cố; với sự cố quy mô lớn (mất cả region), dùng snapshot cross-region đã cấu hình cho Payment/Commission & Payout/Seller Management.
3. Khôi phục S3 (KYC, ảnh sản phẩm): dùng versioning + cross-region replication đã bật cho bucket KYC (mục 5.3.2) để khôi phục object bị xoá/ghi đè ngoài ý muốn.
4. Đồng bộ lại dữ liệu phái sinh: sau khi RDS của Catalog & Inventory được khôi phục, replay lại event ProductUpdated/ProductCreated (nếu còn lưu trong Kafka/MSK retention window) để đồng bộ lại chỉ mục OpenSearch; nếu event đã hết retention, chạy job re-index toàn bộ từ RDS.
5. Xác minh tính toàn vẹn tài chính: với Payment/Commission & Payout, đối chiếu (reconciliation) dữ liệu khôi phục với payment_reconciliation_log/log đối soát VNPay/Momo trước khi mở lại giao dịch cho service đó — không mở lại luồng thanh toán cho tới khi xác minh xong (ưu tiên đúng đắn dữ liệu tài chính hơn tốc độ khôi phục).
6. Thông báo & escalation: theo NFR-08 — escalation 24/7 cho sự cố nghiêm trọng, cập nhật trạng thái cho stakeholder (Product Owner, Admin) theo chu kỳ đã thống nhất trong runbook vận hành (runbook chi tiết theo từng service là tài liệu vận hành riêng, ngoài phạm vi SAD).

9.6 Assumptions

• Đội phát triển dùng stack ngôn ngữ phổ biến cho microservices (Node.js/Java/Go...) chưa được chốt cụ thể ở mục 3 — công cụ unit test (9.1.1) là ví dụ minh hoạ, cần điều chỉnh theo stack thực tế khi chọn.
• Ngưỡng coverage unit test (70%/50%) là đề xuất của mục 9, không có trong brief/mục 2 — cần đội kỹ thuật xác nhận khi thiết lập pipeline thực tế.
• Ngưỡng cảnh báo cache hit ratio, consumer lag, tỷ lệ lỗi 5xx cho rollback (9.4, 9.5.1) là giá trị đề xuất dựa trên thông lệ vận hành hệ thống quy mô lớn, chưa được xác nhận bởi SLA/KPI cụ thể của chủ dự án.
• Retention log APM/tracing (30-90 ngày) là giả định của mục 9, không có trong brief.
• Công cụ SAST/SCA/APM cụ thể (SonarQube/Semgrep, Snyk/Trivy, X-Ray/OpenTelemetry, PagerDuty/OpsGenie) là đề xuất minh hoạ theo best practice AWS — không phải ràng buộc bắt buộc từ brief (brief không chỉ định công cụ cụ thể).

9.7 Open Questions

• FR-14 (loyalty): điểm thưởng tính trên Order cha hay từng OrderSeller, có gồm phí vận chuyển/thuế hay không (đã nêu ở mục 6.8) — ảnh hưởng trực tiếp kỳ vọng kết quả của TC-17; ngưỡng chi tiêu VND cho từng hạng Bạc/Vàng/Kim Cương chưa có số liệu (ảnh hưởng test hạng thành viên chưa được viết ở mục 9.2 vì thiếu acceptance criteria).
• FR-25/BR-14 (dispute): công thức/mức hoàn tiền (toàn phần hay theo tỷ lệ), ai chịu phí vận chuyển hoàn trả — TC-28 chỉ kiểm thử được luồng trạng thái (refund/reject), chưa kiểm thử được số tiền hoàn cụ thể vì chưa có công thức.
• FR-22/BR-04: số ngày hold payout mặc định (5 ngày) và giới hạn cấu hình theo category (có cho phép Admin đặt ngoài khoảng 3-7 ngày hay không) cần chủ dự án xác nhận trước khi chốt bộ test case performance/payout đầy đủ; ngân hàng đối tác và chuẩn kết nối batch file (SFTP+PGP hay API HTTPS) chưa chốt — ảnh hưởng khả năng viết integration test thực tế cho luồng payout (TC-25b hiện chỉ kiểm thử được nhánh "thất bại + retry thủ công", chưa kiểm thử được kết nối ngân hàng thật).
• Mục 4 (API design) đã "hết vòng sửa" theo ghi chú mục 8 — các finding F11 (endpoint pre-signed URL KYC), F12 (mã lỗi 423 ERR_ACCOUNT_LOCKED), F13 (endpoint đọc audit_log) chưa có endpoint chính thức ở mục 4; test case liên quan (phần trong 9.1.5) chỉ mô tả kỳ vọng khi được bổ sung, chưa thể viết test case thực thi được cho tới khi mục 4 cập nhật.
• SLA phản hồi của Seller trước khi hệ thống tự động mở Dispute từ một ReturnRequest bị từ chối/không phản hồi chưa có số ngày cụ thể (mục 6.8) — chưa thể viết test case timeout cho luồng leo thang tự động.
• Ngân sách/công cụ monitoring cụ thể (PagerDuty/OpsGenie hay giải pháp nội bộ) chưa được xác nhận — ảnh hưởng chi tiết runbook escalation thực tế.

9.8 Findings

targetSection	issue	severity	suggestion
02-phan-tich-yeu-cau (FR-14)	FR-14 không có acceptance criteria đủ chi tiết để viết test case xác nhận số điểm/ngưỡng hạng thành viên chính xác (chỉ kiểm thử được công thức giả định của BR-06/BR-07)	medium	Bổ sung acceptance criteria cụ thể (cách tính trên Order hay OrderSeller, ngưỡng VND từng hạng) ở mục 2 sau khi chủ dự án xác nhận
06-luong-xu-ly (BR-14)	Không có công thức hoàn tiền dispute cụ thể → test case TC-28 chỉ xác minh được chuyển trạng thái, không xác minh được số tiền hoàn đúng/sai	medium	Bổ sung công thức hoàn tiền (toàn phần/theo tỷ lệ) ở mục 6 sau khi có quyết định nghiệp vụ
04-api-design	3 finding bảo mật (F11, F12, F13 — mục 8) chưa có endpoint tương ứng vì mục 4 đã ở trạng thái approved/hết vòng sửa	low	Cần một vòng cập nhật mục 4 (bổ sung endpoint pre-signed URL KYC, mã lỗi 423, endpoint đọc audit_log) trước khi có thể viết security test case thực thi được cho các finding này
08-bao-mat (F10)	ACL/mã hoá theo topic cho Kafka/MSK chưa được cập nhật ở mục 3 (kiến trúc) — chưa thể viết test case xác minh cụ thể ACL nào áp dụng cho topic nào	low	Cần mục 3 bổ sung chi tiết ACL trước khi security test (9.1.5) có thể specify chính xác kịch bản kiểm tra
09 (mục này)	NFR-01/NFR-02/NFR-03 dùng số liệu "giả định mặc định đã chốt" từ brief (chưa có SLA hợp đồng thực tế) — ngưỡng performance test có thể cần điều chỉnh sau go-live	low	Rà soát lại ngưỡng performance/alert sau khi có dữ liệu tải thực tế 1-3 tháng đầu vận hành