# INF — Infrastructure & Deployment Design — e-commerce

| | |
|---|---|
| **Version** | 1.1 |
| **Date** | 2026-09-15 |
| **Author** | SA (qua skill `sa-2-architecture`, chế độ `go`, hoạt động `inf`) |
| **Status** | 🟡 Draft *(duyệt từng phần — xem `Approved by`; AG2 cần cả ba vai trò Tech Lead/Security/Ops-SRE ký, mới có một chữ ký thay có điều kiện — **chưa đủ điều kiện chuyển `🔵 Approved`**)* |
| **Approved by** | Tech Lead: **Điều phối dự án** (uỷ quyền, chế độ chạy thử — ký thay theo ngoại lệ `DEC-01`, **không phải chữ ký Tech Lead thật**) — duyệt **từng phần** bản v1.0 · 2026-09-15: chấp nhận topology AWS `ap-southeast-1`, bảng đối chiếu `INF↔TCO` (§10), HA/auto-scaling split ECS Nhóm Giao dịch/Nhóm Hỗ trợ A 2/2 – B 6/4 (`ASM-42`, `OQ-055` giữ mở), kế hoạch diễn tập DR 3 kịch bản (ngày thật `OQ-056` chờ Ops/SRE — điều kiện tiên quyết AG2), observability, CI/CD blue-green (`ADR-016` ứng viên), network/egress, IaC Terraform (`ADR-017` ứng viên). Chốt **TẠM** `OQ-058`: giữ nguyên `TCO` — **KHÔNG** thêm replica Redis ở kịch bản A, chấp nhận SPOF với hành vi fail-closed theo `FAIL` — `OQ-058` **giữ nguyên mở**, chờ PO xác nhận cuối. Đồng ý để SA viết `ADR-016`/`ADR-017` (`Proposed`) cùng `ADR-014`/`ADR-015` ở lượt hoạt động `adr` kế tiếp. `OQ-054` (cross-region snapshot Payment vs `ADR-009`) **giữ nguyên mở**. **KHÔNG ký thay Ops/SRE** — header `Approved by → Ops/SRE` giữ `—`. Security: **—** *(chưa ký)* · Ops/SRE: **—** *(chưa ký)*. `Confidence` giữ 🔴; Status giữ 🟡 Draft; AG2 chưa ký. |
| **Source** | `02-architecture/SAD_e-commerce_v1.0.md` v1.3 §4, §7, §10, §11 (`OQ-026/027`, `ASM-22/23`) · `02-architecture/QAS_e-commerce_v1.0.md` §A3 (`QAS-002/005/006/007/008/009/013/014`) · `02-architecture/ASR_e-commerce_v1.0.md` §B2 (`ASR-001/002/005/006/007/009/010/011/012/013/014`) · `02-architecture/FAIL_e-commerce_v1.0.md` v1.1 §1, §3, §7, §10 (`FM-01…13`, `OQ-035/036/037/039`) · `02-architecture/DAT_e-commerce_v1.0.md` §7.2, §8.2, §9, §11 (`OQ-045/046`) · `02-architecture/SEC_e-commerce_v1.0.md` §1, §2.4, §5, §6 (`OQ-048…053`, `DEC-28`) · `02-architecture/adr/ADR-005…006, 009…012_*.md` · `01-context/TCO_e-commerce_v1.0.md` §3.1–§3.2 · `01-context/CTX_e-commerce_v1.0.md` §3 (`CON-04/05/08`) · `01-context/ARISK_e-commerce_v1.0.md` §6 (`POC-01/POC-02`) · `00-index/OQ_e-commerce.md` (`OQ-008/020/022/026/027/036/046/050`) · `00-index/DEC_e-commerce.md` (`DEC-01…28`) · `e-commerce/docs/sections/09-van-hanh-kiem-thu.md` §9.3–§9.5 *(chỉ tái dùng khung CI/CD/rollback/RTO-RPO của tài liệu P1 gốc — điều chỉnh lại cho kiến trúc P2: 2 ECS service + Payment thay vì ~10 microservice, bỏ Kafka/MSK/OpenSearch)* |
| **Scope** | Toàn sàn e-commerce theo P2 (`SAD v1.3 §7` deployment view): hạ tầng AWS `ap-southeast-1`, HA/DR, scale, observability, CI/CD, kế hoạch diễn tập DR trước AG2. Hoạt động 7/9 của `sa-2-architecture` — không sửa `SAD`/`ICD`/`DAT`/`SEC`/`FAIL`/`ADR` đã có |
| **Confidence** | 🔴 Giả định chưa xác minh — theo yêu cầu điều phối, tiếp nối `Confidence` 🔴 của toàn bộ artifact GĐ2 trước đó. AG1 chưa ký thật; AG2 chưa tới hạn; `POC-01`/`POC-02`/diễn tập DR/diễn tập inject lỗi đều **chưa chạy**; mọi con số auto-scaling/pool/timeout hạ tầng dưới đây là **đề xuất SA chưa kiểm chứng**, gắn `OQ`/`ASM` tương ứng. |

## Change Log

| Version | Date | Người sửa | Thay đổi | ADR/DEC |
|---|---|---|---|---|
| 1.0 | 2026-09-15 | SA (qua skill `sa-2-architecture`, chế độ `go`, hoạt động `inf`) | Bản đầu — hoạt động 7/9 của `sa-2-architecture`. Topology AWS `ap-southeast-1` (VPC/subnet/AZ, ALB+WAF, 2 ECS Fargate service Nhóm Giao dịch/Nhóm Hỗ trợ + Payment Service tách biệt, RDS chính Multi-AZ + RDS Payment, ElastiCache Redis, SQS FIFO+EventBridge+DLQ, S3+CloudFront, Secrets Manager/KMS, NAT) — đối chiếu từng dòng với `TCO §3.2` (bảng §10), phát hiện 1 điểm chưa khớp bản chất (cross-region snapshot Payment trong `TCO` vs "không multi-region" của `ADR-009`, ghi `OQ-054`), không tự sửa `TCO`/`ADR`. Đề xuất split ECS task Nhóm Giao dịch/Nhóm Hỗ trợ (A: 2/2, B: 6/4) khớp đúng tổng `TCO` (`OQ-055`, nối `OQ-026`). Thiết kế HA (Multi-AZ, health check, auto-scaling A→B theo `QAS-009`), DR (RPO≤15’/RTO≤1h theo `QAS-008`/`ADR-009`, backup/PITR, kế hoạch diễn tập DR 3 kịch bản kèm tiêu chí PASS/FAIL đo thật, đề xuất hạn trước AG2 — `OQ-022` ngày thật chờ Ops/SRE), observability (log/metric/trace/dashboard/alert theo `QAS-013`/`ADR-010`, DLQ 14 ngày + alert lag >5 phút theo `OQ-036`/`DEC-22`, on-call theo `CON-08` + `OQ-008`), CI/CD (pipeline build→test→scan→deploy, blue-green cho 3 ECS service, migration schema trong pipeline theo `OQ-045`), network/security group + egress đối tác ngoài (`OQ-057`), IaC (Terraform, đề xuất) + FIT ứng viên GĐ3 (`FIT-34…38`). Thêm `OQ-054…063`, `ASM-42…46`. Ghi ngoại lệ tiếp tục gate `DEC-29` (nối `DEC-28`). Đề xuất 2 `ADR` ứng viên mới (chiến lược triển khai blue-green, công cụ IaC) cho hoạt động `adr` kế tiếp — **không viết `ADR` ở lượt này** (ngoài phạm vi `inf`). `Confidence` 🔴 toàn bộ. | `DEC-29` |
| 1.0 | 2026-09-15 | Điều phối dự án (thay mặt Tech Lead, ngoại lệ `DEC-01`) — tác vụ **sign/approve** | Duyệt **từng phần**: ghi nhận nội dung topology AWS `ap-southeast-1`, bảng đối chiếu `INF↔TCO` (§10), HA/auto-scaling split ECS GD/HT A 2/2 – B 6/4 (`ASM-42`, `OQ-055`), kế hoạch diễn tập DR 3 kịch bản (`OQ-022`/`OQ-056`, ngày thật chờ Ops/SRE — điều kiện tiên quyết AG2), observability, CI/CD blue-green (`ADR-016` ứng viên), network/egress, IaC Terraform (`ADR-017` ứng viên). Chốt **TẠM** `OQ-058`: giữ `TCO`, **KHÔNG** thêm replica Redis ở kịch bản A, chấp nhận SPOF với fail-closed theo `FAIL` — `OQ-058` giữ nguyên mở, chờ PO. Đồng ý viết `ADR-016`/`ADR-017` (`Proposed`) cùng `ADR-014`/`ADR-015` ở lượt `adr` kế tiếp. `OQ-054` (cross-region snapshot vs `ADR-009`) giữ nguyên mở. **KHÔNG ký thay Ops/SRE** — header `Approved by → Ops/SRE` giữ `—`. Security chưa ký. Không đổi nội dung chuyên môn nào của tài liệu. `Confidence` giữ 🔴; Status giữ 🟡 Draft; AG2 chưa ký. Ghi thêm `DEC-30`. | `DEC-30` |
| 1.1 | 2026-09-15 | SA (qua skill sa-2-architecture, chế độ `go`, hoạt động `adr`) | **Chỉ link ADR, không đổi nội dung.** `ADR-016` (blue-green qua AWS CodeDeploy) và `ADR-017` (IaC Terraform), cả hai `Proposed`, vừa được viết theo đề xuất đã duyệt TẠM ở `DEC-30` — thay các dòng "chưa viết, ngoài phạm vi `inf`" ở §7.2 và §11 bằng đường dẫn thật; cập nhật bảng Truy vết §13. `OQ-056`/`OQ-020` (điều kiện `Accepted` `ADR-016`) và `OQ-060` (điều kiện `Accepted` `ADR-017`) giữ nguyên mở. Không sửa nội dung chuyên môn nào khác của `INF`. Ghi `DEC-31` (tiếp nối `DEC-01…30`). | `ADR-016`, `ADR-017`, `DEC-31` |

> Sơ đồ thắng về **quan hệ và luồng** (ai gọi ai, theo thứ tự nào).
> Bảng/văn bản thắng về **ràng buộc và con số** (số task, ngưỡng scale, RTO/RPO, retention).
> Mâu thuẫn ngoài hai loại trên là lỗi tài liệu, phải sửa chứ không phải chọn bên (`D12`).

---

## 0. Ghi chú Preflight & ngoại lệ gate

AG1 chưa được ký chính thức; AG2 (gate của chính GĐ2) càng chưa tới hạn. Theo `SKILL.md`: hoạt
động 1 (`QAS`) → 2 (`ASR`) → 3 (`SAD`) đã hoàn tất và được duyệt từng phần (`DEC-12/14/16`);
`ICD`/`DAT`/`SEC`/`FAIL`/`ADR` (hoạt động 4, 5, 6, 8, 9) cũng đã chạy và duyệt từng phần
(`DEC-17…28`) — điều kiện đầu vào cho `inf` đã đủ.

Người dùng (vai điều phối dự án chạy thử) đã được cảnh báo lại AG1/AG2 chưa qua và **khẳng định
muốn tiếp tục**. Ghi ngoại lệ tại:

> **DEC-29 (SA)** — Tiếp tục `sa-2-architecture` (hoạt động 7 — `INF`) cho e-commerce trong khi
> AG1 chưa ký thật và AG2 chưa tới hạn — tiếp nối `DEC-01…28`.
> **Quyết định:** Dựng `INF` (topology, HA/DR, scale, observability, CI/CD, network/security,
> IaC) dựa trên `SAD §7` + `TCO §3.2` đã duyệt từng phần, giữ `Confidence 🔴` cho tới khi: (a)
> AG1 ký thật, (b) `POC-01`/`POC-02` chạy xong, (c) diễn tập DR (`QAS-008`/`ADR-009`) và diễn tập
> inject lỗi (`QAS-013`/`ADR-010`) chạy xong PASS, (d) `OQ-010`/`OQ-026`/`OQ-027` (số đội thật,
> khớp `TCO`, vị trí Identity) được Tech Lead/Ops trả lời.
> **Người quyết:** Điều phối dự án (đại diện PO, dự án chạy thử).
> **Radar (ước lượng):** ~4 — chi phí đảo ngược thấp (tài liệu hạ tầng sửa được qua version mới,
> chưa là Terraform code thật) · bán kính ảnh hưởng: hoạt động `sa-3-enablement` phụ thuộc `INF`
> này, nhưng bản thân *việc ghi tài liệu dưới ngoại lệ* thì nhỏ · chạm `QAS-008/009/013` Must
> trực tiếp (đang thiết kế hạ tầng hiện thực hoá) nhưng chưa cam kết thi công (chưa IaC thật) ·
> không ràng buộc dài hạn tự thân · không tranh cãi mới → **ghi `DEC-nn`, không cần `ADR`**
> (`decision-radar.md §1–§2`).
> **Hệ quả nếu không chấp nhận ngoại lệ:** dừng GĐ2 ở hoạt động `fail`, không có `INF` để `AGD`/
> `FIT` (GĐ3) và Ops dùng làm đầu vào chuẩn bị go-live — chậm tiến độ chạy thử tương ứng thời gian
> xử lý các `OQ` đang mở, đặc biệt `OQ-022` (lịch diễn tập DR, điều kiện tiên quyết AG2).

🔴 **Nhắc quan trọng:** chưa `POC-01`/`POC-02`, chưa diễn tập DR, chưa diễn tập inject lỗi — mọi
con số auto-scaling/ngưỡng cảnh báo/kích thước instance dưới đây là **mục tiêu thiết kế**, không
phải kết quả đã đo. `AGD`/`FIT`/`IaC` thật (Terraform) là công việc của `sa-3-enablement`, ngoài
phạm vi tài liệu này.

---

## 1. Tóm tắt

| | |
|---|---|
| **Cloud / vùng** | AWS `ap-southeast-1` (Singapore) — kế thừa `TCO §3` (`ASM-11`); ràng buộc lãnh thổ VN (`CON-06`/NĐ13) chưa xác nhận cần cư trú dữ liệu trong nước (`OQ-007` Pháp chế, `CTX`) |
| **Mô hình chạy** | ECS Fargate — 3 service triển khai: **Nhóm Giao dịch**, **Nhóm Hỗ trợ**, **Payment** (`ADR-001` Proposed, `ADR-012` Proposed) |
| **Chịu được mất gì** | 1 AZ (Multi-AZ toàn bộ compute/data); **không** chịu được mất toàn vùng `ap-southeast-1` ở MVP (`ADR-009` PA-1) |
| **RTO / RPO** | Nhóm giao dịch cốt lõi (Payment/Cart&Order/Identity): **RPO ≤15 phút / RTO ≤1 giờ** (`QAS-008`/`ADR-009`) · **chưa từng diễn tập** — kế hoạch diễn tập ở §5.4, `OQ-022` |
| **Chi phí/tháng ở tải dự kiến** | Kịch bản A: **≈ $2.409/tháng (≈ 60,2 triệu VND)** · Kịch bản B: **≈ $5.862/tháng (≈ 146,6 triệu VND)** — khớp `TCO §3.2`, xem đối chiếu §10 |
| **Điểm chưa khớp `TCO` phát hiện ở lượt này** | 1 điểm bản chất (`OQ-054` — cross-region snapshot Payment trong `TCO` vs quyết định "không multi-region" của `ADR-009`) — không tự sửa, xem §10 |

---

## 2. Môi trường

| Môi trường | Mục đích | Cấu hình so với prod | Dữ liệu | Ai truy cập được |
|---|---|---|---|---|
| dev | Phát triển, tích hợp nhanh | ~15–20% Production (đề xuất SA, chưa xác nhận — `TCO §3.2` chỉ gộp chung "non-prod ~35%") | Dữ liệu sinh (seed script) | Dev team |
| stg | **Đo `QAS`**, UAT, integration test với sandbox đối tác | ~35% Production theo `TCO §3.2` — **KHÔNG cùng công suất prod** (xem cảnh báo dưới) | Ẩn danh hoá (không PII/KYC thật, theo `SEC §5`) | Dev + QA + Tech Lead; Ops/SRE cho diễn tập DR/chaos |
| prod | Vận hành thật | 100% (§3, §9) | Thật | Ops/SRE + Admin qua IAM role có audit; không ai truy cập DB Production trực tiếp trừ khẩn cấp có phê duyệt (kế thừa `docs/09 §9.3.2`) |

🔴 **Câu hỏi bắt buộc đã trả lời một phần:** stg chạy ở **~35% công suất** RDS/ECS so với prod
(`r6g.xlarge`/`t4g.medium` giảm size — cụ thể chưa chốt kích cỡ instance stg, `OQ-062`). Điều này
làm sai lệch trực tiếp việc đo `QAS-002` (checkout p95 ≤3s) và `QAS-006` (RDS gộp) nếu chạy thẳng
trên stg với cấu hình thu nhỏ — **`POC-01`/`POC-02` phải chạy trên cấu hình instance PROD thật**
(`ARISK §6` đã ghi rõ "cấu hình instance thật", không phải stg thu nhỏ) để không tự lừa mình theo
đúng cảnh báo `SKILL.md` mục 7.

| `QAS` cần đo | Đo được trên stg (cấu hình thu nhỏ)? | Nếu không, đo ở đâu | Sai số ước tính |
|---|---|---|---|
| `QAS-002` (checkout p95 ≤3s) | 🟡 Một phần — đo được luồng logic/timeout, nhưng số tuyệt đối không đại diện | Staging với **cấu hình tạm nâng lên bằng prod** trong cửa sổ chạy `POC`/load test, hạ lại sau | Không định lượng được nếu không nâng cấu hình — biên độ RDS nhỏ hơn có thể khiến p95 đo được cao hơn thực tế 20–50% (ước lượng, chưa đo) |
| `QAS-005`/`QAS-006` (`POC-01`/`POC-02`) | ❌ Không — `ARISK §6` đã quy định rõ chạy trên "cấu hình instance thật" | Staging, **nâng tạm** lên đúng cấu hình prod (`r6g.xlarge`, SQS FIFO thật) chỉ trong thời gian chạy POC | N/A — đây chính là lý do `POC` phải chạy đúng cấu hình, không phải trên bản thu nhỏ |
| `QAS-008` (DR drill) | ✅ Có — diễn tập DR chạy trên staging trước, không cần đúng size (đo RTO/RPO theo tỷ lệ, quy trình là chính, không phải hiệu năng tuyệt đối) | — | Thấp — quy trình failover không phụ thuộc kích cỡ instance |
| `QAS-013` (alert ≤1 phút) | ✅ Có — chaos/inject lỗi không phụ thuộc kích cỡ instance | — | Thấp |

---

## 3. Sơ đồ triển khai

*Mức: **Deployment view**, bổ sung chi tiết VPC/subnet/AZ so với `SAD §7` (SAD chưa thiết kế ranh
giới mạng con chi tiết — ghi rõ ở `SAD §10` "thuộc hoạt động `inf`"). Vùng: AWS `ap-southeast-1`,
2 AZ (`ap-southeast-1a`, `ap-southeast-1b`).*

```mermaid
flowchart TB
    subgraph INTERNET["Internet"]
        Users["Guest/Customer/Seller/Admin"]
        ExtPay["VNPay · Momo"]
        ExtShip["GHN · GHTK"]
        ExtNotif["Email/SMS Provider"]
    end

    subgraph VPC["VPC — ap-southeast-1 (đề xuất CIDR 10.0.0.0/16, chưa chốt)"]
        subgraph AZa["AZ a (ap-southeast-1a)"]
            subgraph PubA["Public subnet A"]
                WAFa["WAF"]
                ALBa["ALB (node A)"]
                NATa["NAT Gateway A"]
            end
            subgraph AppA["Private subnet A — ứng dụng"]
                GDa["ECS task — Nhóm Giao dịch"]
                HTa["ECS task — Nhóm Hỗ trợ"]
                PAYa["ECS task — Payment (SG riêng)"]
            end
            subgraph DataA["Private subnet A — dữ liệu"]
                RDSMa[("RDS chính — writer/AZ a")]
                RDSPa[("RDS Payment — writer/AZ a")]
                Redisa[("Redis — primary")]
            end
        end
        subgraph AZb["AZ b (ap-southeast-1b)"]
            subgraph PubB["Public subnet B"]
                ALBb["ALB (node B)"]
                NATb["NAT Gateway B"]
            end
            subgraph AppB["Private subnet B — ứng dụng"]
                GDb["ECS task — Nhóm Giao dịch"]
                HTb["ECS task — Nhóm Hỗ trợ"]
                PAYb["ECS task — Payment (SG riêng)"]
            end
            subgraph DataB["Private subnet B — dữ liệu"]
                RDSMb[("RDS chính — standby/AZ b (+ read replica, chỉ kịch bản B)")]
                RDSPb[("RDS Payment — standby/AZ b")]
                Redisb[("Redis — replica, chỉ kịch bản B — SPOF ở kịch bản A, §4.3")]
            end
        end
        CM["AWS Cloud Map / ECS Service Connect\n(service discovery GD↔HT nội bộ)"]
        SQS[("SQS FIFO + EventBridge + DLQ")]
        S3[("S3 (asset/KYC)")]
        CF["CloudFront"]
        SM["Secrets Manager"]
        KMS["KMS (CMK)"]
    end

    Users -->|"1 · HTTPS, sync"| WAFa
    Users -->|"1 · HTTPS, sync"| ALBb
    WAFa -->|"2 · HTTPS, sync"| ALBa
    ALBa -->|"3 · HTTP, sync"| GDa
    ALBa -->|"3 · HTTP, sync"| HTa
    ALBa -->|"3 · HTTP, sync, SG riêng"| PAYa
    ALBb -->|"3 · HTTP, sync"| GDb
    ALBb -->|"3 · HTTP, sync"| HTb
    ALBb -->|"3 · HTTP, sync, SG riêng"| PAYb

    GDa -->|"4 · Service Connect, sync, JWT (SEC PA-3)"| HTa
    GDa -.->|"4 · cross-AZ nếu cần"| HTb
    CM -.-> GDa
    CM -.-> HTa

    GDa -->|"5 · SQL, sync"| RDSMa
    HTa -->|"5 · SQL, sync"| RDSMa
    PAYa -->|"6 · SQL, sync"| RDSPa
    RDSMa -.->|"sync replication, Multi-AZ"| RDSMb
    RDSPa -.->|"sync replication, Multi-AZ"| RDSPb
    GDa -->|"7 · cache, sync"| Redisa
    Redisa -.->|"replication, chỉ kịch bản B"| Redisb

    GDa -->|"8 · publish, async"| SQS
    PAYa -->|"8b · publish, async"| SQS
    SQS -->|"9 · consume, async"| HTa
    SQS -->|"9 · consume, async"| HTb

    GDa -->|"10 · S3 API, sync"| S3
    CF --> S3
    GDa -.->|"secret fetch"| SM
    PAYa -.->|"secret fetch"| SM
    SM -.-> KMS
    RDSMa -.-> KMS
    S3 -.-> KMS

    GDa -.->|"egress qua NAT"| NATa --> ExtNotif
    HTa -.->|"egress qua NAT"| NATa --> ExtShip
    PAYa -.->|"egress qua NAT"| NATa --> ExtPay
```

**Legend:** ▭ tài nguyên compute · hình trụ = data store · nét liền = đường gọi đồng bộ hoặc kết
nối trực tiếp có nhãn giao thức · nét đứt = quan hệ hạ tầng (replication, service discovery, lấy
secret, egress qua NAT) · ranh giới `VPC` = ranh giới mạng ngoài cùng · ranh giới `AZ a`/`AZ b` =
ranh giới sẵn sàng · Payment (`PAYa`/`PAYb`) có **security group riêng**, không chung với Nhóm
Giao dịch/Nhóm Hỗ trợ (`ASR-002`).

🔴 **Quyết định mới của `INF` (giải quyết khoảng trống `SAD §7`/`OQ-028`):** cơ chế kết nối thật
giữa Nhóm Giao dịch ↔ Nhóm Hỗ trợ (`IF-021`/`IF-022`) là **AWS Cloud Map + ECS Service Connect**
(service discovery gốc của ECS, không cần thêm cụm/sidecar mesh) — **không dùng App Mesh**
(đúng lưu ý `SAD §7` v1.2 "không tự thêm hạ tầng mới ngoài phạm vi" và khớp `SEC OQ-050`/`DEC-28`
đã chọn TẠM PA-3 service JWT ở tầng ứng dụng, không cần mTLS hạ tầng). Xác thực giữa 2 service
dùng **service JWT** (`SEC §2.4`, chờ `ADR-015` ở hoạt động `adr` kế tiếp — ngoài phạm vi `inf`).
Đây là quyết định cấu hình mạng (radar ước lượng ~3 — đảo ngược thấp, đổi sang App Mesh sau này
là bổ sung không phải viết lại), **không cần `ADR`**, ghi `DEC-nn` là đủ (`decision-radar.md §2`)
— xem §12 Decisions.

**Bảng thành phần:**

| Thành phần | Môi trường | Số bản *(A / B — `TCO §3.2`)* | Cấu hình | Vùng/AZ | Ranh giới tin cậy |
|---|---|---|---|---|---|
| WAF + ALB | Prod | Managed (Multi-AZ, không đếm instance) | OWASP Core Rule Set (`SEC TB1`) | 2 AZ | Internet → VPC |
| **ECS Fargate — Nhóm Giao dịch** *(mới tách khỏi dòng gộp `TCO`, §10)* | Prod | **A: 2 tasks × 1vCPU/2GB · B: 6 tasks × 1vCPU/2GB** *(đề xuất SA — `OQ-055`, chờ Tech Lead/Ops)* | Auto-scaling riêng theo `ASR-014` (§4.2) | Multi-AZ (private subnet ứng dụng) | VPC nội bộ — cùng SG với Nhóm Hỗ trợ trừ port dành cho Service Connect |
| **ECS Fargate — Nhóm Hỗ trợ** | Prod | **A: 2 tasks × 1vCPU/2GB · B: 4 tasks × 1vCPU/2GB** *(đề xuất SA — `OQ-055`)* | Auto-scaling riêng, ngưỡng khác Nhóm Giao dịch (§4.2) | Multi-AZ | VPC nội bộ |
| ECS Fargate — Payment | Prod | A: 2 tasks × 0,5vCPU/1GB · B: 4 tasks × 0,5vCPU/1GB *(khớp `TCO` nguyên trạng, không đổi)* | SG/IAM riêng hoàn toàn | Multi-AZ (private subnet riêng) | Cao nhất — PCI-DSS SAQ A (`ASR-002`) |
| RDS chính | Prod | A: `r6g.xlarge` Multi-AZ · B: `r6g.2xlarge` Multi-AZ + 1 read replica (chỉ Catalog đọc, `DAT §7.2`/`OQ-046`) | schema-per-module (`ADR-006`) | Multi-AZ | Chỉ Nhóm Giao dịch/Nhóm Hỗ trợ |
| RDS Payment | Prod | A: `t4g.medium` Multi-AZ · B: `r6g.large` Multi-AZ | Tách biệt hoàn toàn (`ADR-002`) | Multi-AZ | Chỉ Payment |
| ElastiCache Redis | Prod | **A: `r6g.large` × 1 node — KHÔNG có replica (SPOF, §4.3)** · B: `r6g.xlarge` × 1 + 1 replica (HA) | Session/ownership/giỏ hàng | A: 1 AZ (SPOF) · B: Multi-AZ | Chỉ Nhóm Giao dịch |
| SQS FIFO + EventBridge + DLQ | Prod | Managed | Message group = `seller_id`; DLQ riêng mỗi queue, retention **14 ngày** (`OQ-036`/`DEC-22`, TẠM) | Managed | Publish (GD/Payment) vs consume (HT) |
| S3 + CloudFront | Prod | Managed | KMS SSE, versioning cho bucket KYC | Managed | Public (asset) vs private (KYC) |
| Secrets Manager + KMS | Prod | Managed | DB credentials, API key đối tác, JWT signing key — mỗi module 1 secret riêng (`SEC §6`) | Managed | Theo IAM task role, cô lập theo module |
| NAT Gateway | Prod | 2 (1/AZ) | | 2 AZ | Egress duy nhất cho private subnet ra đối tác ngoài |
| Non-prod (dev/stg) | Dev/Stg | ~35% Production compute/RDS (`TCO §3.2`) | Cấu hình thu nhỏ (§2) — **cần nâng tạm khi chạy `POC`/đo `QAS`** | `ap-southeast-1`, **VPC/account riêng** (đề xuất, `OQ-062`) | Tách biệt hoàn toàn với Production |

---

## 4. Tính sẵn sàng (HA)

### 4.1 Cơ chế chuyển đổi theo thành phần

| Thành phần | Chịu được mất | Cơ chế chuyển đổi | Thời gian chuyển *(ước tính, chưa đo)* | Tự động? | Đã thử chưa |
|---|---|---|---|---|---|
| ECS Fargate (GD/HT/Payment) | 1 task, 1 AZ | ALB health check (interval 15s, unhealthy threshold 3 lần) loại task lỗi; ECS scheduler khởi task mới ở AZ còn lại | ~1–3 phút *(`ASM-45`, chưa đo)* | ✅ | ☐ |
| ALB | 1 AZ | Managed Multi-AZ, tự động | N/A (không downtime) | ✅ | N/A (AWS managed) |
| RDS chính / RDS Payment | 1 AZ (mất writer) | RDS Multi-AZ synchronous replication → failover tự động sang standby | Theo SLA AWS công khai ~60–120s *(chưa tự đo)* | ✅ | ☐ — nằm trong kế hoạch diễn tập §5.4 (kịch bản 2) |
| ElastiCache Redis — kịch bản B | 1 node (có replica) | Multi-AZ với automatic failover (ElastiCache) | ~60s theo tài liệu AWS *(`ASM-44`, chưa tự đo)* | ✅ | ☐ |
| **ElastiCache Redis — kịch bản A** | **KHÔNG chịu được mất node — SPOF** | Node mới được ElastiCache tự khởi tạo lại (nếu bật snapshot) hoặc cache rỗng | ~5–10 phút để node mới sẵn sàng *(ước tính, chưa đo)*; dữ liệu cache mất hoàn toàn (không phải source of truth, `D7`) nhưng ownership-check/session Guest phụ thuộc Redis (`ADR-007`) → **có gián đoạn dịch vụ trong lúc chờ**, xem §4.3 | ✅ (tạo lại node) / ❌ (không failover, vì không có replica) | ☐ |
| SQS FIFO + EventBridge | Managed, đa AZ nội tại | AWS quản lý hoàn toàn | N/A | ✅ | N/A |
| NAT Gateway | 1 AZ | 2 NAT Gateway (1/AZ), route table theo AZ | N/A (route riêng theo AZ, không có "chuyển đổi" — mỗi AZ dùng NAT của chính nó) | ✅ (theo thiết kế) | ☐ |

### 4.2 Auto-scaling — kịch bản A → B (`QAS-009`, `ASR-014`)

🔴 Toàn bộ ngưỡng dưới đây là **đề xuất SA**, chưa Tech Lead/Ops xác nhận, chưa đo tải thật
(`POC-01`/`POC-02` mới đo throughput SQS/RDS, chưa đo hành vi auto-scaling ECS) — ghi `OQ-055`.

| Nhóm | Metric | Ngưỡng kích hoạt scale-out | Ngưỡng scale-in | Min task | Max task | Thời gian scale *(ước tính)* |
|---|---|---|---|---|---|---|
| **Nhóm Giao dịch** (Catalog/Cart&Order/Identity) | Target tracking: `ALBRequestCountPerTarget` **và** CPU (lấy giá trị kích hoạt sớm hơn) | CPU > 60% trong 3 phút, hoặc request/target > ngưỡng tương ứng ~2.000 concurrent/task *(suy từ `QAS-009` A=2.000 concurrent/2 task)* | CPU < 30% trong 10 phút | **2** (kịch bản A) | **12** *(2× kịch bản B=6, dự phòng đột biến ×2 chưa kiểm chứng — khớp "Ngoài phạm vi" `SAD §10`)* | Cooldown scale-out 60s, scale-in 300s *(đề xuất, chưa đo)* |
| **Nhóm Hỗ trợ** (Seller/Commission/Promotion/Review/Notification/Shipping) | CPU + độ trễ (age) tin nhắn SQS đang chờ xử lý (consumer lag) | CPU > 70% trong 5 phút, hoặc `ApproximateAgeOfOldestMessage` > 60s | CPU < 30% trong 15 phút | **2** | **8** | Cooldown scale-out 90s, scale-in 300s |
| Payment | CPU (ít nhạy tải hơn vì COD đồng bộ nhẹ, VNPay/Momo đã bất đồng bộ theo `ADR-013`) | CPU > 65% trong 3 phút | CPU < 30% trong 10 phút | **2** (A) | **4** (B, khớp `TCO`, không mở rộng thêm vì PCI-DSS scope hẹp) | Cooldown tương tự Nhóm Giao dịch |

🔴 **`ASR-014` yêu cầu scale riêng Nhóm Giao dịch** — bảng trên đáp ứng bằng 2 auto-scaling policy
độc lập (2 ECS service riêng, đúng `OQ-026` đã chốt TẠM). Nếu Tech Lead/Ops xác nhận ngược lại ở
`OQ-026` (chỉ 1 service gộp), toàn bộ bảng này phải viết lại thành 1 policy chung.

**Giới hạn trên và nút thắt kế tiếp** *(kịch bản tải ×3 của `TCO`)*

| Thứ tự | Thành phần nghẽn trước | Ở mức tải nào | Cách gỡ | Chi phí |
|---|---|---|---|---|
| 1 | RDS chính (đọc + ghi gộp, `ADR-006`) | Khi CPU RDS > 75% liên tục — có thể xảy ra trước khi ECS chạm max task, vì RDS là tài nguyên chung không scale ngang tự động | Tách read replica thêm (đã có 1 ở kịch bản B) hoặc tách Catalog ra RDS riêng (theo điều kiện xét lại `ADR-006 §7`) | Instance lớn hơn hoặc thêm replica — chưa ước tính, ngoài `TCO` hiện tại |
| 2 | Message group SQS FIFO của 1 seller volume cao (`ADR-005 §7`) | Khi 1 seller vượt trần throughput riêng của group đó | Theo dõi/cảnh báo riêng theo seller (chưa thiết kế — việc phát sinh của `ADR-005`, xem §6.4) | Không phát sinh chi phí hạ tầng, chỉ engineering effort |
| 3 | ECS Nhóm Giao dịch chạm max=12 | Tải vượt kịch bản B ×2 (~20.000 concurrent) | Nâng max, đánh giá lại kiến trúc (ngoài phạm vi thiết kế hiện tại theo `SAD §10`) | Cần TCO mới |

### 4.3 Điểm hỏng đơn (SPOF) còn lại

| Thành phần | Vì sao chưa dự phòng | Rủi ro | Kế hoạch |
|---|---|---|---|
| **ElastiCache Redis kịch bản A (1 node, không replica)** | `TCO §3.2` kịch bản A chỉ tính 1 node để tiết kiệm chi phí (`ASM-11`) — chưa có yêu cầu HA ở mức tải thấp | Mất node → gián đoạn ownership-check/session Guest (`ADR-007`) cho tới khi node mới sẵn sàng (~5–10 phút ước tính); **không mất dữ liệu nghiệp vụ** (Redis không phải source of truth, `D7`) nhưng có gián đoạn dịch vụ | `OQ-058` — hỏi PO/Ops có chấp nhận rủi ro này ở kịch bản A hay muốn thêm 1 replica ngay (chi phí +~$92/tháng ước tính theo đơn giá `TCO §3.1`, chưa xác nhận) |
| VPC/region `ap-southeast-1` | `ADR-009` chọn PA-1 — không multi-region ở MVP, vì chi phí chưa có trong ngân sách | Mất toàn vùng → toàn hệ thống down, RTO thực tế vượt xa 1 giờ (khôi phục sang region khác là dự án riêng) | Đã ghi trong `ADR-009 §5` "Cái quyết định này khoá lại" — chấp nhận có ý thức, xét lại khi PO duyệt ngân sách multi-region |
| NAT Gateway (theo AZ) | Mỗi AZ có NAT riêng — nếu AZ đó down, task trong AZ đó cũng down theo (không phải NAT là nguyên nhân chính) | Trùng với SPOF "mất 1 AZ" đã có cơ chế chuyển đổi ở §4.1 — không phải SPOF độc lập | Không cần kế hoạch riêng |
| Cấu hình DNS/Route53 (chưa thiết kế) | Chưa có trong phạm vi `SAD`/`INF` lượt này — domain/SSL đã có ở `TCO §4` nhưng cấu hình failover DNS chưa thiết kế | Nếu ALB endpoint đổi mà không có health-check DNS, có thể kéo dài downtime khi có sự cố tầng ngoài ALB (hiếm, vì ALB tự Multi-AZ) | Ghi nhận — mức độ ưu tiên thấp vì ALB đã Multi-AZ, không phải SPOF cấp bách |

🔴 Hệ thống nào cũng còn SPOF — liệt kê ra là chuyên nghiệp; giả vờ không có mới là vấn đề.

---

## 5. Khôi phục thảm hoạ (DR)

### 5.1 Mục tiêu và cơ chế khôi phục

| | |
|---|---|
| **Nhóm phạm vi** | Payment, Cart & Order, Identity & Access — "nhóm giao dịch cốt lõi" (`ASR-010`) |
| **Kịch bản thảm hoạ tính tới** | Mất 1 AZ · hỏng RDS primary (dữ liệu lỗi logic, không phải mất AZ) · xoá nhầm dữ liệu · mất Redis. **Không tính** mất toàn vùng (`ADR-009` PA-1) |
| **RTO mục tiêu** | **≤ 1 giờ** (nguồn: `QAS-008`, kế thừa nguyên trạng từ `SAD.md §5.3.2`/`§9.5.2` gốc — **chưa phải SLA hợp đồng đã ký với PO**, xem `CTX DRV-05`) |
| **RPO mục tiêu** | **≤ 15 phút** (nguồn: `QAS-008`) |
| **Cách khôi phục** | RDS Multi-AZ tự động failover (mất AZ, §4.1) hoặc PITR restore (hỏng dữ liệu logic/xoá nhầm) — xem runbook §5.3 |
| **RTO đo được thực tế** | 🔴 **Chưa đo** — chưa từng diễn tập |
| **Lần diễn tập gần nhất** | 🔴 **Chưa từng** — xem kế hoạch §5.4 |
| **Tần suất diễn tập đề xuất** | 2 lần/năm sau lần đầu (kế thừa đề xuất `ADR-009 §6`), điều chỉnh theo kết quả |

### 5.2 Backup & PITR

| Data store | Cơ chế | Tần suất/độ trễ | Retention | Cross-AZ | Cross-region |
|---|---|---|---|---|---|
| RDS chính | Automated Backup + PITR (WAL continuous archiving) | Continuous (đạt RPO ≤15 phút — cần xác nhận tần suất archive log thật đủ nhanh, `OQ-055` mở rộng) | Đề xuất 7 ngày (chưa chốt — khác với con số 35 ngày ở tài liệu P1 gốc `docs/09 §9.5.3`, cần Tech Lead xác nhận số cho P2, `OQ-059-b` gộp vào `OQ-045` phạm vi migration/backup) | ✅ (Multi-AZ synchronous) | ❌ — `TCO §3.2` có dòng "cross-region snapshot (Payment)" nhưng **mâu thuẫn với `ADR-009` PA-1**, xem `OQ-054` |
| RDS Payment | Automated Backup + PITR | Continuous | Đề xuất 7 ngày, riêng biệt khỏi RDS chính (`ADR-002`) | ✅ | ❌ — cùng `OQ-054` |
| ElastiCache Redis | Không PITR (cache, không phải source of truth, `D7`) — chỉ snapshot định kỳ tuỳ chọn để giảm thời gian "cache lạnh" sau sự cố | N/A (không cần RPO cho cache) | N/A | Chỉ kịch bản B (replica) | ❌ |
| S3 (KYC, asset) | Versioning bật cho bucket KYC (khôi phục object bị xoá/ghi đè nhầm) | Continuous (mỗi write là 1 version) | Đề xuất giữ version cũ 90 ngày rồi chuyển lifecycle sang Glacier | N/A (S3 tự đa AZ) | 🔴 Chưa chốt — chỉ cần nếu Pháp chế/Security yêu cầu (`OQ-007`), chưa có trong `TCO` |
| SQS FIFO/EventBridge DLQ | Retention **14 ngày** (`OQ-036`/`DEC-22`, TẠM) | N/A | 14 ngày | Managed | Managed |

### 5.3 Runbook failover (tóm tắt — chi tiết đầy đủ thuộc tài liệu vận hành `sa-3-enablement`)

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
   CloudWatch alarm đã cấu hình ở §6, đối chiếu `QAS-013`).
2. **Mất 1 AZ:** không can thiệp thủ công cho ECS/ALB/RDS Multi-AZ (tự động, §4.1) — Ops xác
   nhận qua dashboard, không chặn nghiệp vụ trừ khi failover RDS vượt ngưỡng bất thường.
3. **Hỏng RDS primary do lỗi dữ liệu logic (không phải mất AZ):** dùng PITR restore về thời điểm
   trước sự cố lên instance mới; **không mở lại luồng thanh toán cho tới khi đối soát xong**
   (kế thừa nguyên tắc `docs/09 §9.5.3` bước 5 — ưu tiên đúng đắn tài chính hơn tốc độ).
4. **Mất Redis (kịch bản A, không replica):** chấp nhận gián đoạn ownership-check/session Guest
   trong lúc ElastiCache tạo node mới; **không cần restore dữ liệu** (cache, không phải nguồn sự
   thật) — khi node mới lên, hệ thống tự "làm nóng lại" cache theo truy vấn thực tế.
5. **Xác minh toàn vẹn tài chính** trước khi mở lại Payment (đối chiếu `ReconciliationLog`, kế
   thừa nguyên tắc `docs/09 §9.5.3`).
6. **Thông báo & escalation** theo `QAS-013`/`CON-08` — xem §6.5.

🔴 Runbook đầy đủ (lệnh thao tác cụ thể, ai bấm nút gì) là sản phẩm của `sa-3-enablement`
(`AGD`), tài liệu này chỉ định khung quy trình.

### 5.4 Kế hoạch diễn tập DR — điều kiện tiên quyết AG2 (`OQ-022`, `DEC-12`)

🔴 **Đây là mục quan trọng nhất của `INF`** — `ADR-009`/`QAS-008` đều ghi rõ "RTO/RPO chưa diễn
tập là RTO/RPO trên giấy". Ba kịch bản dưới đây **phải chạy trước khi ký AG2**; ngày thật vẫn chờ
Ops/SRE xác nhận (`OQ-022`), nhưng kế hoạch (kịch bản, bước, tiêu chí PASS/FAIL, ai làm, môi
trường) đã đủ chi tiết để lên lịch ngay khi có Ops/SRE.

| # | Kịch bản | Môi trường | Các bước | Tiêu chí PASS | Tiêu chí FAIL | Ai làm | Công cụ |
|---|---|---|---|---|---|---|---|
| DR-1 | **Mất 1 AZ** (giả lập bằng cách chặn traffic tới AZ đó, không thật sự tắt AZ AWS) | Staging (nâng tạm lên cấu hình gần prod), sau đó lặp lại ở Production giờ thấp điểm nếu DR-1 PASS ở staging | 1) Đo baseline (p95 checkout, uptime) trước khi bắt đầu. 2) Dùng AWS Fault Injection Simulator hoặc chặn route table/SG để cô lập 1 AZ khỏi traffic. 3) Quan sát ALB tự loại AZ lỗi, ECS scheduler khởi task mới ở AZ còn lại, RDS Multi-AZ failover (nếu writer nằm ở AZ bị cô lập). 4) Đo thời gian từ lúc cô lập tới lúc hệ thống phục vụ bình thường trở lại (RTO thực đo). 5) Đo lượng dữ liệu/giao dịch bị ảnh hưởng trong cửa sổ đó (RPO thực đo — kỳ vọng 0 vì đây là mất AZ, không mất dữ liệu, RDS Multi-AZ đồng bộ). 6) Khôi phục traffic bình thường, xác nhận không còn task "mồ côi" | RTO đo được ≤ 1 giờ; RPO đo được = 0 (không mất giao dịch nào vì Multi-AZ đồng bộ); không lỗi 5xx kéo dài > 5 phút liên tục trong lúc chuyển đổi | RTO > 1 giờ, hoặc mất giao dịch, hoặc lỗi 5xx > 5 phút liên tục | Ops/SRE chủ trì, Tech Lead quan sát/xác nhận số liệu | AWS Fault Injection Simulator hoặc thao tác Security Group/Route table thủ công; CloudWatch dashboard đo thời gian thực |
| DR-2 | **Mất RDS primary** (giả lập bằng reboot-with-failover hoặc force failover qua AWS Console/CLI) | Staging trước, Production giờ thấp điểm nếu PASS ở staging (khuyến nghị **không** chạy DR-2 thật trên Production writer chính cho tới khi DR-1 và DR-2 đã PASS ở staging ≥1 lần) | 1) Đo baseline. 2) Trigger `aws rds reboot-db-instance --force-failover` (hoặc tương đương) trên RDS chính (staging trước). 3) Đo thời gian từ lúc trigger tới lúc ứng dụng (Nhóm Giao dịch/Nhóm Hỗ trợ) ghi/đọc thành công trở lại (RTO). 4) Kiểm tra giao dịch đang xử lý tại thời điểm failover có bị mất/trùng không (RPO + kiểm tra idempotency `ADR-004`). 5) Lặp lại riêng cho RDS Payment | RTO đo được ≤ 1 giờ (kỳ vọng thực tế thấp hơn nhiều — Multi-AZ failover thường < 2 phút theo AWS SLA công khai, nhưng phải **đo thật**, không giả định); RPO đo được ≤ 15 phút; không giao dịch nào bị double-write/mất do idempotency đã có (`ADR-004`) | RTO > 1 giờ, RPO > 15 phút, hoặc phát hiện giao dịch bị mất/trùng không được idempotency bắt | Ops/SRE + DBA chủ trì, Tech Lead xác nhận số liệu | AWS CLI/Console, CloudWatch, `ReconciliationLog` (kiểm tra sau) |
| DR-3 | **Mất Redis** (giả lập bằng xoá node hoặc force-failover ElastiCache) | Staging trước | 1) Đo baseline. 2) Xoá/force-failover node Redis. 3) Quan sát hành vi ownership-check/session Guest khi Redis không sẵn sàng (`ADR-007` — có fallback gọi thẳng Identity & Access không, hay lỗi hoàn toàn?). 4) Đo thời gian tới khi node mới sẵn sàng và cache "nóng lại". 5) Với kịch bản A (không replica): đo downtime dịch vụ thực tế trong lúc chờ node mới | Xác nhận có đường fallback (không phải lỗi cứng hoàn toàn) khi Redis mất — nếu không có fallback, đây là **phát hiện quan trọng cần ghi `ARISK` mới**, không phải điều kiện PASS/FAIL đơn thuần | Hệ thống lỗi cứng hoàn toàn (không phục vụ được request nào) khi Redis mất, không có fallback nào | Ops/SRE + Tech Lead (backend module `CMP-02`/`CMP-04`) | Xoá node thủ công qua AWS Console (staging), theo dõi log ứng dụng |

**Hạn đề xuất:** trong vòng 2 tuần kể từ khi Ops/SRE được xác định (`OQ-008`) và trước khi trình
AG2 — đây là **đề xuất của SA**, ngày thật vẫn là `OQ-022`, chờ Ops/SRE xác nhận lịch cụ thể.

**Kết quả diễn tập ghi vào:** `ARISK_e-commerce_v1.0.md` (mục mới, theo đúng cách `POC-01`/`POC-02`
đã ghi) — không ghi trực tiếp vào `INF` này để tránh phải bump version mỗi lần có kết quả mới; `INF`
sẽ dẫn chiếu khi có.

---

## 6. Quan sát được (Observability)

### 6.1 Log / Metric / Trace

| Loại | Công cụ | Ghi gì | Giữ bao lâu | Ai đọc | Chi phí/tháng |
|---|---|---|---|---|---|
| Log | CloudWatch Logs (managed, khớp `ADR-010` PA-1) | Request log (không PII thô — log-scrubber mask `email`/`phone`/`account_number` theo `SEC §5.1`), application log theo `correlation_id` = header `X-Request-Id` (`ICD OQ-031`, đề xuất Tech Lead xác nhận tên header) | Đề xuất 30 ngày hot (CloudWatch) rồi archive S3 Glacier 90 ngày thêm (🔴 chưa chốt, `OQ-059`) | Dev + Ops/SRE (không unrestricted — theo IAM role) | Trong `TCO §3.2` dòng "Observability" (~$357 A / ~$1.033 B) |
| Metric | CloudWatch Metrics | CPU/memory ECS, connection/CPU RDS, cache hit ratio Redis, SQS `ApproximateAgeOfOldestMessage`/`NumberOfMessagesSent`, ALB 5xx rate, target response time | 15 tháng (CloudWatch mặc định cho metric đã aggregate) | Ops/SRE, dashboard chia sẻ Tech Lead | Trong dòng Observability trên |
| Trace | AWS X-Ray | Luồng checkout xuyên `ALB→GD→(HT/Payment)→RDS/SQS`, tỉ lệ lấy mẫu đề xuất 10% (100% cho request lỗi) — **chưa chốt tỉ lệ**, `OQ-059` | Mặc định X-Ray 30 ngày | Dev + Ops/SRE khi debug latency | Trong dòng Observability trên |
| **Cộng** | | | | | **≈ $357/tháng (A) · ≈ $1.033/tháng (B)** — khớp `TCO §3.2` |

**Correlation id:** header request `X-Request-Id` (đề xuất SA ở `ICD OQ-031`) — ALB/API Gateway
sinh nếu client không gửi, map 1-1 vào `traceId` (X-Ray) và field `correlation_id` trong mọi dòng
log ứng dụng, xuyên suốt Nhóm Giao dịch → Nhóm Hỗ trợ → Payment → SQS consumer. **Chưa Tech Lead
xác nhận tên header** — nếu đổi, chỉ cần đổi tên field, không ảnh hưởng kiến trúc.

### 6.2 Dashboard đề xuất

| Dashboard | Đối tượng xem | Nội dung chính |
|---|---|---|
| "Sức khoẻ giao dịch cốt lõi" | Ops/SRE, Tech Lead | 5xx rate + p95 latency của Payment/Cart&Order/Identity, uptime rolling 30 ngày (đối chiếu ngân sách lỗi `QAS-007`), auto-scaling hiện tại (task count vs max) |
| "Message backbone" | Ops/SRE | SQS lag theo message group (đặc biệt seller volume cao, `ADR-005 §7`), DLQ depth, EventBridge fan-out lag |
| "Chi phí" | PO/Tech Lead | Chi phí AWS thực tế theo dịch vụ, đối chiếu `TCO §3.2` hàng tháng (rà chênh lệch >20% — chuẩn bị cho `CONF` GĐ4) |

### 6.3 Cảnh báo

| Cảnh báo | Điều kiện | Mức | Báo cho ai | `QAS` |
|---|---|---|---|---|
| 5xx tăng đột biến — Nhóm giao dịch cốt lõi | Health check fail liên tục **> 1 phút** cho Payment/Cart&Order/Identity | Trang (page) 24/7 | On-call theo `CON-08`/`OQ-008` (§6.5) | `QAS-013` |
| p95 checkout vượt ngưỡng | p95 `POST /v1/checkout` > 3s liên tục 5 phút | Trang giờ hành chính, escalate nếu kéo dài | On-call | `QAS-002` |
| SQS lag / DLQ | `ApproximateAgeOfOldestMessage` > **5 phút** (`OQ-036`/`DEC-22`, TẠM) | Vé giờ hành chính, trang nếu ảnh hưởng nhóm cốt lõi | Ops/SRE theo domain consumer (chưa phân công cụ thể tên người — `OQ-036` phần "ai xử lý" vẫn mở) | `QAS-005`, `FM-09/10` |
| Message group riêng lẻ nghẽn (1 seller volume cao) | Lag riêng 1 message group > 5s kéo dài > 5 phút | Vé giờ hành chính | Ops/SRE | `ADR-005 §7` |
| RDS CPU/connection pool | CPU > 75% > 3 lần/tuần giờ cao điểm, hoặc connection pool exhaust | Trang nếu exhaust, vé nếu CPU cao | DBA/Ops | `ADR-006 §7` |
| Circuit breaker mở (FM-01/02/03/04/12/13) | Bất kỳ lần mở nào (`FAIL §3.1`) | Vé, trang nếu mở > 5 phút liên tục | On-call theo module | `QAS-002` |
| Chi phí AWS bất thường | Chi phí ngày > 150% trung bình 7 ngày trước | Vé giờ hành chính | Ops/PO | `TCO §3.2` |

🔴 **Cảnh báo không ai xử lý là cảnh báo sẽ bị tắt tiếng.** Mọi cảnh báo trên cần một người nhận
thật (§6.5) — hiện chưa có tên cụ thể vì `OQ-008` (số người Ops) còn mở.

### 6.4 Error budget (`QAS-007`)

| | |
|---|---|
| Mục tiêu | 99,9%/tháng cho Catalog/Checkout/Payment/Identity (`QAS-007`) ⇒ ngân sách lỗi **43 phút/tháng** |
| Loại trừ | Bảo trì có báo trước **≤ 2 giờ/tháng** (`OQ-020`/`DEC-12`, TẠM — chưa PO xác nhận số cuối) |
| Theo dõi | Dashboard "Sức khoẻ giao dịch cốt lõi" (§6.2), tính rolling 30 ngày |
| Ràng buộc lên CI/CD | Chiến lược deploy (§7) phải **không** tự tiêu tốn ngân sách lỗi — chọn blue-green/rolling zero-downtime, không chọn "deploy có downtime ngắn" dù chỉ vài giây mỗi lần (tích luỹ nhiều lần release/tháng có thể ăn hết 43 phút) |

### 6.5 Vận hành thường ngày & on-call

| Việc | Ai làm | Tần suất | Tài liệu |
|---|---|---|---|
| Trực sự cố (on-call) | Ops/SRE theo `CON-08`: **ca hành chính + escalation 24/7 cho sự cố nghiêm trọng ảnh hưởng nhóm giao dịch cốt lõi** — số người/nội bộ hay thuê ngoài **chưa xác nhận** (`OQ-008`, mở) | Liên tục | Escalation chain: on-call → Tech Lead → PO (thứ tự đề xuất, chưa xác nhận) |
| Vá bảo mật (SCA/dependency) | Dev + Ops (theo cảnh báo Trivy/Snyk ở CI/CD, §7) | Theo phát hiện, ưu tiên Critical/High trong 7 ngày (đề xuất, chưa chốt SLA) | `SEC §7` |
| Kiểm tra backup khôi phục được | Ops/SRE | Theo tần suất diễn tập DR (§5.4) | §5 |
| Rà chi phí | Ops/PO | Hàng tháng, đối chiếu `TCO §3.2` | §10 |

**Năng lực đội vận hành** *(từ `CON-05`/`CON-08`)*: số người/kỹ năng thật **chưa xác nhận**
(`OQ-008`) — thiết kế trên giả định "đủ người trực ca hành chính + escalation 24/7 khi cần", theo
đúng `CON-08`. Nếu đội thật nhỏ hơn giả định "team MVP chuẩn" (`DEC-02`), khả năng đáp ứng ngưỡng
ack ≤15 phút (`QAS-013`) và tần suất diễn tập DR 2 lần/năm có thể không khả thi — đây là đánh đổi
PO/PM phải quyết (`D10`), không phải SA tự chọn giả định lạc quan hơn thực tế đội. Chi phí đào tạo/
tuyển dụng nếu thiếu người: xem `TCO §5`/`ASM-14`.

---

## 7. CI/CD

### 7.1 Pipeline build → test → scan → deploy

*Điều chỉnh từ khung `docs/09 §9.3.1` (viết cho kiến trúc P1, ~10 microservice + Kafka) sang P2
(3 đơn vị triển khai: Nhóm Giao dịch, Nhóm Hỗ trợ, Payment) — bỏ bước liên quan Kafka/MSK/
OpenSearch, thêm bước scan theo `SEC §7`.*

```mermaid
flowchart LR
    Commit["Commit / PR"] --> Build["Build\n(container image/service, tag = commit SHA)"]
    Build --> Unit["Unit test\n(coverage gate — ngưỡng chưa chốt, OQ-060)"]
    Unit --> SAST["SAST\n(SonarQube/Semgrep)"]
    SAST --> SCA["SCA/container scan\n(Trivy image + Snyk dependency)"]
    SCA --> Migration["Schema migration dry-run\n(Flyway — OQ-045, mỗi schema module riêng)"]
    Migration --> Integration["Integration test\n(Staging, sandbox VNPay/Momo/GHN/GHTK — ARISK-03/04)"]
    Integration --> DeployDev["Deploy → Dev\n(auto)"]
    DeployDev --> DeployStg["Deploy → Staging\n(auto sau Dev pass)"]
    DeployStg --> UAT["UAT + Performance/Security test\n(k6, security regression FIT-29..33)"]
    UAT --> Approval["Phê duyệt thủ công\n(Product Owner + Tech Lead — tách vai trò)"]
    Approval --> DeployProd["Deploy → Production\n(blue-green, §7.2)"]
```

**Ngưỡng chặn:**

| Bước | Chặn nếu | Nguồn |
|---|---|---|
| Unit test | Coverage giảm so với baseline hoặc test đỏ (ngưỡng % cụ thể chưa chốt cho P2 — `docs/09` đề xuất 70%/50% cho P1, cần Tech Lead xác nhận lại cho P2, `OQ-060`) | `docs/09 §9.1.1` (tham khảo) |
| SAST | Phát hiện lỗ hổng theo policy đã cấu hình (SonarQube quality gate) | `SEC §7` |
| SCA/container scan | **Trivy/Snyk phát hiện Critical/High chưa có ngoại lệ được phê duyệt** — chặn deploy (khớp yêu cầu người duyệt) | `SEC §7`, `docs/09 §9.3.1` |
| Migration dry-run | Migration không tương thích ngược (không theo expand-contract, `DAT §8.2`) — kiểm tra tự động một phần (linter script), phần còn lại cần review thủ công | `DAT §8.2`, `OQ-045` |
| Integration test | Fail idempotency webhook (`ADR-004`), fail contract `ICD` | `ICD`, `ADR-004` |
| UAT/Security regression | FR Must không Pass; `FIT-29…33` (secret scan, service-authn, webhook signature, audit completeness, TLS/HSTS) đỏ | `SEC §11` |
| Deploy Production | Thiếu phê duyệt thủ công (PO + Tech Lead, tách vai trò người phê duyệt/người deploy) | `docs/09 §9.3.2` |

### 7.2 Chiến lược deploy — zero/low-downtime

| | Quyết định | Vì sao |
|---|---|---|
| **Chiến lược** | **Blue-green (AWS CodeDeploy cho ECS)** cho cả 3 service (Nhóm Giao dịch, Nhóm Hỗ trợ, Payment) | Tương thích ngân sách lỗi chặt (43 phút/tháng, `QAS-007`) — rolling update vẫn có short window request có thể chạm task đang tắt, blue-green chuyển traffic dứt điểm sau health check pass, rollback tức thời (chuyển lại traffic) nếu phát hiện lỗi sau khi đã live |
| Thời gian downtime cho phép | **0** theo thiết kế (blue-green không có cửa sổ mất traffic nếu health check đúng) — nằm gọn trong ngân sách lỗi `QAS-007` | |
| **Cách rollback** | Chuyển traffic ALB về target group cũ (green→blue) — tức thời (giây), không cần redeploy | CodeDeploy hỗ trợ sẵn |
| Migration schema | **Expand-contract** (thêm cột/bảng trước, xoá sau — kế thừa nguyên tắc `docs/09 §9.5.1`/`DAT §8.2`) — chạy trước bước deploy code mới trong pipeline (§7.1), tương thích ngược để rollback code không gặp schema mới không hiểu | `DAT §8.2`, `OQ-045` (công cụ Flyway/Liquibase chưa chốt) |
| Cờ tính năng (feature flag) | 🔴 Chưa chốt công cụ (LaunchDarkly/tự xây bảng config) — đề xuất SA: bảng config đơn giản trong RDS chính (schema `platform`), không cần SaaS bên thứ ba ở MVP; dùng cho rollout tính năng rủi ro cao (đổi luồng thanh toán/hoa hồng, theo `docs/09 §9.3.2`) | `OQ-060` |
| Ai được bấm deploy Production | Tech Lead (thực hiện) sau khi PO phê duyệt (tách vai trò — segregation of duties) | `docs/09 §9.3.2` |

🔴 Chiến lược deploy blue-green cho toàn bộ 3 service là quyết định thiết lập tiền lệ (radar ước
lượng ~6 — đảo ngược trung bình, bán kính toàn hệ thống, chạm trực tiếp `QAS-007` Must, ràng buộc
một release, không tranh cãi) — theo `decision-radar.md §2`, đạt ngưỡng `ADR` bắt buộc. Xem
[`adr/ADR-016_blue-green-deploy-aws-codedeploy.md`](adr/ADR-016_blue-green-deploy-aws-codedeploy.md)
(`Proposed`). Điều kiện `Accepted`: Ops/SRE xác nhận năng lực vận hành CodeDeploy + chạy thử
blue-green/rollback thành công ở staging (`OQ-056`), PO xác nhận số cuối `OQ-020`.

### 7.3 Phân quyền Production & secret trong pipeline

| Hạng mục | Thiết kế |
|---|---|
| CI/CD → AWS | **OIDC federation** (GitHub Actions/GitLab CI ↔ AWS IAM role tạm thời) — không dùng access key dài hạn nhúng pipeline (kế thừa `docs/09 §9.3.2`) |
| Secret trong pipeline | Lấy từ **AWS Secrets Manager** tại thời điểm chạy (`SEC §6`), không lưu trong biến môi trường CI dạng plaintext lâu dài, không commit vào repo — quét rò rỉ bằng Gitleaks/TruffleHog (`SEC FIT-29`) |
| Audit CI/CD | Log ai trigger deploy, phiên bản nào, thời điểm nào — audit trail hạ tầng, khác `audit_log` nghiệp vụ (`DAT`) |

---

## 8. Network & Security groups

### 8.1 Security group theo thành phần

| SG | Áp dụng cho | Inbound | Outbound |
|---|---|---|---|
| `sg-alb` | ALB | 443 từ Internet (0.0.0.0/0, qua WAF) | 80/443 tới `sg-ecs-gd`, `sg-ecs-ht`, `sg-ecs-pay` |
| `sg-ecs-gd` | ECS Nhóm Giao dịch | 80 từ `sg-alb`; port Service Connect từ `sg-ecs-ht` (nội bộ) | 5432 tới `sg-rds-main`; 6379 tới `sg-redis`; 443 tới SQS/EventBridge/S3/Secrets Manager (qua VPC endpoint hoặc NAT); port Service Connect tới `sg-ecs-ht` |
| `sg-ecs-ht` | ECS Nhóm Hỗ trợ | 80 từ `sg-alb`; port Service Connect từ `sg-ecs-gd` | 5432 tới `sg-rds-main`; 443 tới SQS/EventBridge/S3/Secrets Manager; 443 tới NAT (egress GHN/GHTK/Email-SMS) |
| `sg-ecs-pay` | ECS Payment — **cô lập, không chung SG với GD/HT** (`ASR-002`) | 80 từ `sg-alb` **chỉ route Payment** | 5432 tới `sg-rds-payment` (chỉ SG này); 443 tới NAT (egress VNPay/Momo); 443 tới Secrets Manager (chỉ secret của Payment) |
| `sg-rds-main` | RDS chính | 5432 từ `sg-ecs-gd`, `sg-ecs-ht` | — |
| `sg-rds-payment` | RDS Payment | 5432 **chỉ từ** `sg-ecs-pay` | — |
| `sg-redis` | ElastiCache Redis | 6379 **chỉ từ** `sg-ecs-gd` | — |

🔴 **Không có SG nào cho phép Nhóm Hỗ trợ/Payment kết nối trực tiếp RDS Payment hoặc Redis** —
đúng nguyên tắc cô lập `ASR-002`/`ADR-002` và "chủ duy nhất" `D7`.

### 8.2 Private subnet cho dữ liệu

RDS chính, RDS Payment, ElastiCache Redis đặt **hoàn toàn trong private subnet** (không route
public), không có Elastic IP, không truy cập được từ Internet — chỉ qua ECS task trong cùng VPC.
Đúng yêu cầu (f).

### 8.3 Egress tới đối tác ngoài (VNPay/Momo/GHN/GHTK/Email-SMS)

| Đối tác | Qua NAT Gateway? | IP allowlist đối tác yêu cầu? | Static outbound IP cần thiết? |
|---|---|---|---|
| VNPay | ✅ (từ `sg-ecs-pay`) | 🔴 **Chưa xác nhận** — chưa có tài liệu tích hợp/sandbox thật (`CON-04`, `ARISK-03`) | Nếu VNPay yêu cầu allowlist IP nguồn: NAT Gateway đã có Elastic IP cố định theo AZ — đủ điều kiện kỹ thuật, chỉ cần đăng ký 2 IP (1/AZ) với VNPay |
| Momo | ✅ (từ `sg-ecs-pay`) | 🔴 Chưa xác nhận | Tương tự — 2 Elastic IP NAT |
| GHN | ✅ (từ `sg-ecs-ht`) | 🔴 Chưa xác nhận (`ARISK-04`) | Tương tự |
| GHTK | ✅ (từ `sg-ecs-ht`) | 🔴 Chưa xác nhận | Tương tự |
| Email/SMS Provider | ✅ (từ `sg-ecs-ht`, qua `CMP-09` Notification) | 🔴 Chưa chọn nhà cung cấp (`TCO OQ-016`) | Chưa xác định |

🔴 **`OQ-057` (mới):** VNPay/Momo/GHN/GHTK/Email-SMS có yêu cầu IP allowlist cho outbound traffic
từ sàn không? Nếu có, cần đăng ký 2 Elastic IP (1/AZ, gắn NAT Gateway) với từng đối tác trước
go-live — việc này **không phát sinh chi phí thêm** (Elastic IP đã tính trong giá NAT Gateway ở
`TCO §3.1`) nhưng cần thời gian phối hợp hành chính với đối tác. Hỏi: Tech Lead (khi có tài liệu
tích hợp thật từ 4 đối tác, cùng điều kiện với `ARISK-03/04`).

---

## 9. Chi phí — tham chiếu `TCO`

Toàn bộ con số chi phí trong tài liệu này **tham chiếu nguyên trạng** `TCO_e-commerce_v1.0.md
§3.1–§3.2` — không tính lại, không đổi đơn giá/tỷ giá (`ASM-11`/`ASM-12` vẫn 🔴 chưa xác minh,
thuộc trách nhiệm `TCO`, không phải `INF`). Bảng đối chiếu chi tiết ở §10.

---

## 10. Đối chiếu với `TCO` *(bắt buộc theo `D9` — từng dòng)*

| Hạng mục | `INF` §3/§4/§6 | `TCO §3.2` | Khớp |
|---|---|---|---|
| Compute — Nhóm Giao dịch + Nhóm Hỗ trợ (tổng) | A: 2+2=4 tasks×1vCPU/2GB · B: 6+4=10 tasks×1vCPU/2GB | A: ~4 tasks×1vCPU/2GB (gộp) · B: ~10 tasks×1vCPU/2GB (gộp) | ✅ **Khớp về tổng số** — split GD/HT là đề xuất mới của `INF` (`OQ-055`), chưa Tech Lead/Ops xác nhận nhưng không đổi tổng cost |
| Compute — Payment | A: 2 tasks×0,5vCPU/1GB · B: 4 tasks×0,5vCPU/1GB | A: 2 tasks×0,5vCPU/1GB · B: 4 tasks×0,5vCPU/1GB | ✅ Khớp hoàn toàn |
| CSDL (RDS chính + Payment) | A: `r6g.xlarge`+`t4g.medium` Multi-AZ · B: `r6g.2xlarge`+1 replica + Payment `r6g.large` | Giống hệt | ✅ Khớp |
| Cache (Redis) | A: `r6g.large`×1 (không replica) · B: `r6g.xlarge`×1+1 replica | Giống hệt | ✅ Khớp — nhưng §4.3 mới **phát hiện và ghi rõ** hệ quả SPOF kịch bản A mà `TCO` không đề cập (không phải lỗi `TCO`, chỉ là `TCO` không có cột "rủi ro HA") |
| Message broker (SQS/EventBridge) | Managed, ~750K msg/tháng (A) / ~2,25M msg/tháng (B) | Giống hệt | ✅ Khớp |
| S3/CloudFront | ~500GB (A) / ~1,5TB (B) | Giống hệt | ✅ Khớp |
| WAF/ALB/NAT | Giống `TCO` | Giống `TCO` | ✅ Khớp |
| **Backup & DR** | Automated backup + PITR, **không cross-region** (theo `ADR-009` PA-1) | Dòng "Backup & DR" ghi **"Automated backup + cross-region snapshot (Payment)"**, ≈$30 (A)/≈$60 (B) | 🔴 **KHÔNG khớp bản chất** — xem `OQ-054` |
| Observability | CloudWatch Logs/Metrics + X-Ray, ~$357 (A)/~$1.033 (B) | Giống hệt | ✅ Khớp |
| Non-prod | ~35% Production | ~35% Production | ✅ Khớp về tỷ lệ; kích cỡ instance cụ thể của non-prod chưa chốt (`OQ-062`) |
| **Tổng/tháng** | ≈ $2.409 (A) / ≈ $5.862 (B) | ≈ $2.409 (A) / ≈ $5.862 (B) | ✅ Khớp |

🔴 **`OQ-054` (mới) — phát hiện quan trọng nhất của mục đối chiếu này:** `TCO §3.2` tính một
khoản nhỏ (~$30/A, ~$60/B) cho **"cross-region snapshot (Payment)"** trong dòng "Backup & DR",
nhưng `ADR-009` (chiến lược HA/DR cho nhóm giao dịch cốt lõi, bao gồm Payment) đã chọn **PA-1 —
không multi-region ở MVP**, với lý do rõ ràng "chưa có trong ngân sách đã duyệt". Hai khả năng:
(1) khoản chi phí này trong `TCO` chỉ là **bản sao snapshot sang region khác** để phòng thảm hoạ
tối hậu (không kèm hạ tầng compute/failover chủ động ở region đó) — nếu vậy, nó **không mâu
thuẫn** với "không multi-region active-passive" của `ADR-009`, nhưng cần ghi rõ: khôi phục từ
snapshot cross-region này (nếu dùng tới) sẽ **KHÔNG đạt RTO ≤1 giờ** đã cam kết (restore RDS từ
snapshot qua region khác thường mất nhiều giờ) — đây là "van an toàn cuối cùng", không phải một
phần của cam kết RTO/RPO chính; (2) hoặc khoản chi phí này là sai sót/thừa trong `TCO`, nên bỏ
nếu PO/Ops xác nhận không cần. **Không tự sửa `TCO` hay `ADR-009`** — trình cả hai khả năng.
**Hỏi:** Tech Lead + Ops/SRE + PO. **Hệ quả nếu chọn hướng (1):** giữ nguyên chi phí `TCO`, thêm
1 dòng rõ ràng vào `ADR-009`/`INF` rằng cross-region snapshot Payment là biện pháp phụ, không nằm
trong cam kết RTO≤1h. **Hệ quả nếu chọn hướng (2):** `TCO §3.2` giảm ~$30–60/tháng (không đáng kể
so với tổng, không đổi kết luận "P2 rẻ hơn P1").

---

## 11. Infrastructure as Code (IaC) — đề xuất cho GĐ3

*Không viết code Terraform/CDK thật ở lượt này (thuộc `sa-3-enablement`) — chỉ chốt hướng và tiêu
chí FIT ứng viên.*

| | Đề xuất | Vì sao |
|---|---|---|
| Công cụ | **Terraform** | Đa cloud-agnostic hơn CDK (dù hiện chỉ dùng AWS), cộng đồng module lớn cho ECS/RDS/ElastiCache, không khoá vào 1 ngôn ngữ lập trình cụ thể (CDK cần TypeScript/Python) — phù hợp năng lực team chưa xác nhận rõ (`CON-05`) |
| Cấu trúc state | Tách state theo môi trường (dev/stg/prod) và theo nhóm tài nguyên (network, data, compute) — giảm blast radius khi `terraform apply` | Giảm rủi ro 1 lệnh apply làm hỏng toàn bộ hạ tầng |
| Drift detection | Chạy `terraform plan` định kỳ (đề xuất hàng ngày) trên CI, cảnh báo nếu có drift chưa giải thích | Đúng yêu cầu (h) — fitness function `FIT-34` |
| Tag policy | Bắt buộc tag `Project`, `Environment`, `Owner`, `CostCenter` trên mọi tài nguyên — enforce bằng AWS Config rule hoặc Terraform Sentinel/OPA policy | Phục vụ rà chi phí (§6.2 dashboard "Chi phí") và audit |

🔴 Chọn Terraform làm công cụ IaC chính là quyết định thiết lập tiền lệ, ràng buộc dài hạn (đảo
ngược tốn nhiều tuần nếu đổi công cụ sau khi đã có code thật) — radar ước lượng ~7, đạt ngưỡng
`ADR` bắt buộc. Xem [`adr/ADR-017_iac-terraform.md`](adr/ADR-017_iac-terraform.md) (`Proposed`).
Điều kiện `Accepted`: Tech Lead + Ops/SRE xác nhận công cụ (`OQ-060`) và năng lực vận hành.

**`FIT` ứng viên cho GĐ3:**

| `FIT` | Kiểm tra | Công cụ | Chạy ở đâu |
|---|---|---|---|
| `FIT-34` | Drift detection — hạ tầng thật khớp Terraform state | `terraform plan` định kỳ / driftctl | CI, hàng ngày |
| `FIT-35` | Tag policy — mọi tài nguyên có đủ 4 tag bắt buộc | AWS Config rule / OPA | CI + AWS Config liên tục |
| `FIT-36` | Đúng 2 ECS service (GD/HT) + 1 Payment tồn tại, đúng SG cô lập theo §8.1 | Terraform plan review + AWS Config | CI/CD (trùng `ADR-012 FIT-16`, mở rộng thêm kiểm tra SG) |
| `FIT-37` | Blue-green deploy tự động rollback khi health check fail sau khi chuyển traffic | CodeDeploy hook test | Staging, trước mỗi major release |
| `FIT-38` | Pipeline chặn deploy khi Trivy/Snyk phát hiện Critical/High chưa có ngoại lệ | CI/CD test (giả lập lỗ hổng) | CI, định kỳ kiểm tra pipeline tự nó hoạt động đúng |

---

## 12. Quyết định ghi nhận ở mức `DEC` (không đạt ngưỡng `ADR`)

| Quyết định | Radar ước lượng | Lý do không cần `ADR` |
|---|---|---|
| Cơ chế service discovery nội bộ GD↔HT: AWS Cloud Map + ECS Service Connect (không App Mesh) | ~3 | Đảo ngược thấp (đổi sang App Mesh sau là bổ sung, không viết lại), bán kính hẹp (chỉ ảnh hưởng cấu hình network nội bộ), không chạm `QAS` Must trực tiếp (latency thêm không đáng kể, kế thừa đường găng đã có timeout ở `FAIL`), không tranh cãi |
| Auto-scaling metric: target tracking CPU + request count (không dùng custom metric phức tạp hơn ở bản đầu) | ~3 | Điều chỉnh được dễ dàng qua console/Terraform, không ràng buộc dài hạn |
| Environment tách VPC/account riêng cho non-prod (đề xuất, `OQ-062`) | ~4 | Đảo ngược trung bình (tách account sau khi đã chạy chung tốn công di chuyển nhưng không phải viết lại code) — ghi `DEC`, không `ADR`, nhưng vẫn cần `OQ-062` xác nhận trước khi triển khai thật |

---

## 13. Truy vết

| `INF` §/mục | `QAS` | `ASR` | `ADR` | `CMP` | `FM` |
|---|---|---|---|---|---|
| §3 Topology | `QAS-009` | `ASR-001`, `ASR-012`, `ASR-002` | `ADR-001`, `ADR-002`, `ADR-012` | `CMP-01…15` | — |
| §4 HA/auto-scaling | `QAS-002`, `QAS-009` | `ASR-014`, `ASR-007` | `ADR-012` | `CMP-04`, `CMP-15` | — |
| §5 DR | `QAS-008` | `ASR-010` | `ADR-009` | `CMP-02`, `CMP-04`, `CMP-11` | — |
| §6 Observability | `QAS-013`, `QAS-007` | `ASR-011` | `ADR-010` | `CMP-02`, `CMP-04`, `CMP-11` | `FM-09`, `FM-10` |
| §7 CI/CD | `QAS-007` | — | `ADR-016` | Toàn bộ `CMP` triển khai được | — |
| §8 Network/Security | `QAS-010`, `QAS-011` | `ASR-002`, `ASR-007` | `ADR-002` | `CMP-01`, `CMP-11`, `CMP-14`, `CMP-15` | — |
| §11 IaC | — | — | `ADR-017` | — | — |

---

## 14. Giả định & Ngoài phạm vi

**Giả định** *(tiếp số toàn dự án, bắt đầu `ASM-42`)*:

| ID | Giả định | Cách xác minh | Nếu sai |
|---|---|---|---|
| `ASM-42` | Split ECS task Nhóm Giao dịch/Nhóm Hỗ trợ đề xuất (A: 2/2, B: 6/4) phản ánh đúng ý `TCO §3.2` khi gộp thành 1 dòng "monolith" — tức là `TCO` đã tính đủ tiền cho *tổng* task bất kể chia thế nào | Tech Lead/Ops xác nhận ở `OQ-026`/`OQ-055` | Nếu `TCO` thực ra chỉ tính đủ cho 1 service duy nhất (không đủ overhead vận hành 2 service riêng — VD 2 load balancer target group, 2 service discovery entry): chi phí thực tế có thể cao hơn `TCO` một khoản nhỏ (không đáng kể theo kinh nghiệm AWS — ECS service không tính phí riêng, chỉ tính theo task) |
| `ASM-43` | Auto-scaling target tracking (CPU 60%/70%, request count) đủ nhanh để bắt kịp tốc độ tăng tải thật của flash sale (chưa biết tốc độ tăng — `QAS-009` chỉ có 2 điểm A/B, không có đường cong tăng) | Đo thật trong `POC-01`/`POC-02` mở rộng hoặc diễn tập tải riêng cho auto-scaling (chưa có kế hoạch, đề xuất bổ sung ở GĐ3 `FIT`) | Nếu tải tăng nhanh hơn tốc độ scale (thường ECS Fargate cần 1-3 phút để task mới sẵn sàng): có thể có cửa sổ ngắn quá tải trước khi auto-scaling bắt kịp — cân nhắc pre-scale thủ công trước sự kiện flash sale đã biết trước lịch |
| `ASM-44` | ElastiCache Multi-AZ (kịch bản B) failover tự động trong ~60 giây theo tài liệu công khai AWS | Diễn tập DR-3 (§5.4) đo thật | Nếu chậm hơn nhiều: tăng thời gian gián đoạn ownership-check, cần xét lại kiến trúc fallback (VD cache-aside với timeout ngắn gọi thẳng DB) |
| `ASM-45` | ECS task thay thế sau khi 1 AZ down mất ~1-3 phút (health check + scheduler + container start) | Diễn tập DR-1 (§5.4) đo thật | Nếu lâu hơn: RTO tổng thể của nhóm giao dịch cốt lõi có nguy cơ tiệm cận giới hạn 1 giờ nhanh hơn dự kiến khi cộng dồn nhiều thành phần phục hồi tuần tự |
| `ASM-46` | Cửa sổ bảo trì ≤2 giờ/tháng (`OQ-020`, TẠM) đủ cho mọi hoạt động deploy/migration định kỳ kể cả nâng cấp minor version RDS | PO xác nhận số cuối ở `OQ-020`; Ops theo dõi thực tế sau go-live | Nếu không đủ: một số bảo trì phải tính vào ngân sách lỗi 43 phút/tháng, giảm biên độ cho sự cố thật |

**Ngoài phạm vi:**

- IaC (Terraform) thật, `AGD` runbook chi tiết, `FIT` chạy trên CI thật — thuộc `sa-3-enablement`.
- Multi-region active-passive — đã loại ở `ADR-009`, chỉ xét lại nếu PO duyệt ngân sách bổ sung.
- OpenSearch — P2 hoãn dùng, kế thừa nguyên trạng `SAD §10`/`TCO §3.2` (không có trong `TCO` cho
  P2 kịch bản A/B, không thiết kế hạ tầng cho nó ở tài liệu này).
- Cấu hình DNS/Route53 failover chi tiết, chứng chỉ SSL cụ thể — tham chiếu `TCO §4`, chưa thiết
  kế chi tiết ở `INF` này (mức độ ưu tiên thấp, ALB đã Multi-AZ).
- Chi tiết connection pool/bulkhead theo con số cụ thể (`OQ-037` của `FAIL`) — chờ kết quả
  `POC-02`, `INF` chỉ ghi nhận đây là cấu hình cần thiết lập ở tầng RDS parameter group khi có số.
- Giá cả/đơn giá AWS — không tính lại, tham chiếu nguyên trạng `TCO` (`ASM-11`/`ASM-12`).

---

## 15. Open Questions

| ID | Câu hỏi | Hỏi ai | Từ ngày | Chặn gì | Hệ quả nếu trả lời ngược |
|---|---|---|---|---|---|
| `OQ-054` | `TCO §3.2` tính "cross-region snapshot (Payment)" (~$30/A, ~$60/B) trong dòng Backup & DR — có mâu thuẫn với `ADR-009` (chọn PA-1, không multi-region) không, hay đây chỉ là snapshot phụ không nằm trong cam kết RTO≤1h? | Tech Lead + Ops/SRE + PO | 2026-09-15 | §10 đối chiếu `TCO`; nội dung `ADR-009`/`INF §5.2` | Nếu là (1) snapshot phụ: giữ nguyên, chỉ cần ghi rõ nó không tính vào RTO cam kết. Nếu là (2) sai sót: `TCO` giảm ~$30-60/tháng, không đổi kết luận P2 rẻ hơn P1 |
| `OQ-055` | Xác nhận split ECS task đề xuất giữa Nhóm Giao dịch/Nhóm Hỗ trợ (A: 2/2, B: 6/4) và ngưỡng auto-scaling (CPU 60%/70%, request count) — nối `OQ-026` | Tech Lead + Ops/SRE | 2026-09-15 | §4.2, §10; cấu hình Terraform thật ở GĐ3 | Nếu Tech Lead muốn tỷ lệ khác (VD 3/1 thay vì 2/2 ở kịch bản A): đổi bảng §3/§4, không đổi tổng chi phí `TCO` |
| `OQ-056` | Nối `OQ-022` — lịch diễn tập DR thật (DR-1/2/3 ở §5.4) là ngày nào? SA đề xuất trong vòng 2 tuần kể từ khi xác định Ops/SRE, trước khi trình AG2 | Ops/SRE | 2026-09-15 | Điều kiện tiên quyết ký AG2 (`DEC-12`) | Không diễn tập trước AG2 ⇒ RTO/RPO vẫn "trên giấy", Security/Ops có thể từ chối ký AG2 với lý do chính đáng |
| `OQ-057` | VNPay/Momo/GHN/GHTK/Email-SMS có yêu cầu IP allowlist cho traffic outbound từ sàn không? Nếu có, cần đăng ký 2 Elastic IP NAT với từng đối tác | Tech Lead (khi có tài liệu đối tác thật) | 2026-09-15 | §8.3; thời điểm phối hợp hành chính với đối tác trước go-live | Nếu không xử lý trước go-live và đối tác yêu cầu allowlist: toàn bộ traffic outbound bị chặn ở phía đối tác, phát hiện muộn ngay trước/sau go-live |
| `OQ-058` | Chấp nhận ElastiCache kịch bản A không có replica (SPOF, §4.3) hay muốn thêm 1 replica ngay (chi phí ước tính +~$92/tháng theo đơn giá `TCO §3.1`, chưa xác nhận chính xác)? | PO + Ops/SRE | 2026-09-15 | §4.3; cấu hình ElastiCache thật ở GĐ3 | Giữ nguyên (chấp nhận SPOF): tiết kiệm chi phí nhưng có gián đoạn ownership-check khi mất node Redis (ước 5-10 phút, chưa đo). Thêm replica: tăng chi phí nhỏ, giảm rủi ro gián đoạn |
| `OQ-059` | Xác nhận: (a) retention log CloudWatch/S3 archive, (b) tỉ lệ lấy mẫu X-Ray trace, (c) retention backup RDS (đề xuất 7 ngày, khác 35 ngày ở tài liệu P1 gốc) | Tech Lead + Ops/SRE | 2026-09-15 | §6.1, §5.2; chi phí lưu trữ thực tế | Retention ngắn hơn: giảm chi phí nhưng giảm khả năng điều tra sự cố cũ. Dài hơn: tăng chi phí lưu trữ |
| `OQ-060` | Xác nhận công cụ IaC (Terraform, đề xuất) và ngưỡng coverage unit test cho P2 (đề xuất kế thừa 70%/50% từ tài liệu P1, cần xác nhận lại cho kiến trúc mới) | Tech Lead | 2026-09-15 | §11 (`ADR-017` ứng viên); §7.1 pipeline | Nếu chọn CDK thay Terraform: cần kỹ năng TypeScript/Python cho hạ tầng, ảnh hưởng `CON-05` (năng lực team) |
| `OQ-061` | *(nối `OQ-037` của `FAIL`/`DAT`)* Kích thước connection pool RDS theo module (ghi checkout vs đọc catalog) và pool HTTP theo từng adapter đối tác ngoài — phụ thuộc kết quả `POC-02` chưa chạy | DBA + Tech Lead | 2026-09-15 | Cấu hình RDS parameter group thật ở GĐ3 | Pool sai kích thước: nghẽn checkout (quá nhỏ) hoặc lãng phí connection/cạn tổng pool RDS (quá lớn) |
| `OQ-062` | Non-prod (dev/stg) nên tách VPC riêng trong cùng account hay tách hẳn AWS account riêng (đề xuất SA: account riêng theo AWS Organizations, best practice cô lập blast radius + rà chi phí)? | Tech Lead + Ops/SRE | 2026-09-15 | §2, §3 (bảng thành phần "Non-prod") | Account riêng: cô lập tốt hơn nhưng thêm chi phí quản lý cross-account (IAM, networking). Cùng account khác VPC: đơn giản hơn nhưng rủi ro cấu hình sai lan sang prod cao hơn |
| `OQ-063` | *(nối `OQ-008`, không lặp lại — chỉ nhắc)* Đội Ops/SRE thật (nội bộ/thuê ngoài, quy mô) — chặn trực tiếp khả năng đáp ứng on-call §6.5 và tần suất diễn tập DR §5.4 | PM/SRE | 2026-09-12 *(đã mở từ `CTX`)* | §5.4, §6.5 | Xem `CTX OQ-008` — không lặp lại hệ quả ở đây |

**Nhắc AG2:** cần **Tech Lead + Security + Ops/SRE ký**. `INF` là artifact cuối cùng cần Ops/SRE
ký trực tiếp (`workflow.md §2`) — hoạt động còn lại của GĐ2 là `fail` (đã xong, `DEC-21/22`) và
`adr` (12+1 ADR đã viết, cộng 2 ADR ứng viên mới từ `INF`: `ADR-016` blue-green, `ADR-017`
Terraform, cộng `ADR-014`/`ADR-015` đang chờ từ `DAT`/`SEC`).

---

## Tự chấm

### ① Bảng tự chấm Gate AG2 *(`workflow.md §2` — dòng liên quan `INF`)*

| # | Tiêu chí | ☐/✅ | Ghi chú |
|---|---|---|---|
| — | `ASR`/`QAS`/`SAD`/`ADR`/`ICD`/`DAT`/`SEC`/`FAIL` | ✅ *(đã đạt ở các hoạt động trước, duyệt từng phần)* | Xem artifact tương ứng |
| 1 | `INF` — topology môi trường, HA/DR có **RTO/RPO bằng số**, chiến lược scale, observability | ✅ *(nội dung đầy đủ)* / 🔴 *(chưa đo thật)* | §3–§6: RTO≤1h/RPO≤15’ có số, HA Multi-AZ, scale A→B có ngưỡng, observability có log/metric/trace/dashboard/alert — nhưng **chưa diễn tập** (`OQ-022/056`), `Confidence` giữ 🔴 |
| — | `sa-conformance` báo coverage `ASR → ADR/CMP` ≥ 100% | 🟡 Không đổi bởi `INF` | `INF` không tạo `ASR`/`CMP` mới, chỉ hiện thực hoá — coverage đã đạt 15/15 ở `SAD §4.3` |

**Kết luận tự chấm (riêng phần `INF`):** Đủ nội dung theo checklist AG2 dòng `INF` — có RTO/RPO
bằng số, kế hoạch diễn tập DR cụ thể (3 kịch bản, tiêu chí PASS/FAIL đo thật), auto-scaling có
ngưỡng, observability đủ 3 trụ (log/metric/trace) + alert + error budget, CI/CD có pipeline đủ
bước + chiến lược deploy zero-downtime, network/security group đầy đủ, đối chiếu `TCO` từng dòng
(1 điểm chưa khớp bản chất đã ghi `OQ-054`, không tự sửa). **Chưa đủ điều kiện ký AG2** vì: (a)
chưa diễn tập DR/inject lỗi thật, (b) `POC-01`/`POC-02` chưa chạy, (c) `OQ-008` (đội Ops thật)
còn mở — ba điều này đều **ngoài khả năng của việc viết tài liệu**, cần hành động thật của
Ops/SRE/Tech Lead.

### ② Checklist D1–D12

| # | Mục | ☐/✅ | Ghi chú |
|---|---|---|---|
| D1 | Một ADR một quyết định | N/A | `INF` không viết `ADR` mới ở lượt này — chỉ đề xuất 2 ứng viên (`ADR-016`, `ADR-017`) cho hoạt động `adr` kế tiếp, mỗi ứng viên đã tách đúng 1 quyết định |
| D2 | Không NFR định tính | ✅ | Mọi ngưỡng (RTO/RPO, auto-scaling, alert, retention) đều có con số hoặc đánh dấu rõ "chưa chốt" kèm `OQ` |
| D3 | Nêu phương án bị loại + lý do gắn `CON`/`QAS` | ✅ *(kế thừa)* | Deploy strategy: nêu rõ vì sao chọn blue-green thay vì rolling (gắn `QAS-007`); Service discovery: nêu rõ vì sao không chọn App Mesh (gắn giới hạn phạm vi đã ghi ở `SAD §7`); các phương án lớn khác (multi-region, message backbone, DB) đã có `ADR` riêng, `INF` chỉ hiện thực hoá |
| D4 | Sơ đồ khai báo mức + legend | ✅ | §3 khai báo "Deployment view", có legend đầy đủ (ranh giới mạng, AZ, loại đường nối); §7.1 khai báo loại (pipeline flowchart) |
| D5 | Interface có chủ/contract | N/A | Không phải phạm vi `INF` — đã có ở `ICD` |
| D6 | Phụ thuộc ngoài process có timeout/retry | N/A | Đã có ở `FAIL` — `INF` chỉ bổ sung network/SG cho phép các phụ thuộc đó chạy được, không thiết kế lại timeout/retry |
| D7 | Một chủ sở hữu dữ liệu | ✅ *(kế thừa)* | §5.2 Backup/PITR tôn trọng đúng ranh giới `ADR-002`/`ADR-006` (RDS chính vs RDS Payment tách biệt) |
| D8 | Ràng buộc có FIT hoặc nhãn khuyến nghị | ✅ | §11 đề xuất `FIT-34…38`; các mục chưa có FIT (VD "ai xử lý DLQ theo domain") đánh dấu rõ "chưa chốt", không giả vờ đã có |
| D9 | Con số hạ tầng quy ra tiền + nguồn; `INF` khớp `TCO` | ✅ *(1 điểm ngoại lệ đã ghi rõ)* | §10 đối chiếu từng dòng — khớp toàn bộ trừ 1 điểm bản chất (`OQ-054`), không tự sửa `TCO` |
| D10 | Không quyết định thay người có thẩm quyền | ✅ | §4.3 (SPOF Redis kịch bản A — trình `OQ-058` kèm chi phí, không tự chọn), §5.2 (`OQ-054` — trình 2 khả năng, không tự sửa `TCO`/`ADR-009`), §7.2 (đề xuất blue-green nhưng đánh dấu cần `ADR-016` — không tự "Accepted") |
| D11 | Có mục "Ngoài phạm vi" + `ASM-nn` | ✅ | §14 đầy đủ — `ASM-42…46` có cách xác minh/hệ quả |
| D12 | Câu quy định thẩm quyền sơ đồ vs văn bản | ✅ | Có ngay sau Change Log |

### ③ Bảng đối chiếu với bộ BA

| `BA` | Nội dung | `INF` tương ứng | Khớp? | Hành động |
|---|---|---|---|---|
| `docs/09 §9.5.2` (RTO/RPO gốc, kiến trúc P1) | Payment/Cart&Order/Identity: RPO≤15’/RTO≤1h; Commission&Payout/Seller: RPO≤1h/RTO≤4h; Catalog/Promotion/Shipping: RPO≤1h/RTO≤8h; Review/Notification/Audit: RPO≤24h/RTO≤24h | `INF §5.1` chỉ thiết kế DR cho nhóm giao dịch cốt lõi (khớp `ASR-010`/`QAS-008`, đúng phạm vi P2 hiện tại) | 🟡 Một phần | `INF` **chưa** thiết kế DR chi tiết cho Nhóm Hỗ trợ (Commission/Seller/Catalog/Promotion/Review/Notification) — ngoài phạm vi yêu cầu người duyệt lượt này (chỉ yêu cầu nhóm giao dịch cốt lõi); ghi nhận là khoảng trống cần bổ sung ở lượt `inf` tiếp theo hoặc trước AG2 nếu Ops/SRE yêu cầu |
| `docs/09 §9.3.1` (CI/CD, kiến trúc P1, 10 microservice) | Pipeline build→test→SAST→SCA→integration→deploy dev/stg/prod, canary rollout | `INF §7.1` — điều chỉnh còn 3 đơn vị triển khai (không phải 10), bỏ Kafka-specific test, đổi canary→blue-green | ✅ Đã điều chỉnh đúng theo P2, không sao chép nguyên trạng P1 | Không cần hành động — đã ghi rõ trong Change Log là "điều chỉnh, không tái dùng nguyên trạng" |
| `docs/09 §9.4.1` (Metrics/alert, kiến trúc P1) | Alert theo NFR-01…08, kênh PagerDuty/OpsGenie | `INF §6.3` — giữ cùng nguyên tắc alert (health check ≤1 phút, escalation 24/7) nhưng bỏ Kafka consumer lag (đổi thành SQS `ApproximateAgeOfOldestMessage`) | ✅ Đã điều chỉnh | Không cần hành động |
| `QAS-008`/`ADR-009` (SA) | RPO≤15’/RTO≤1h, chưa diễn tập | `INF §5.4` — kế hoạch diễn tập cụ thể | ✅ | `INF` là nơi hiện thực hoá điều kiện `ADR-009 §3` đã đặt ra — không lệch |

### ④ Danh sách `OQ` mở kèm người phải trả lời, chặn gì

Xem §15 (`OQ-054…063` mới) cộng các `OQ` còn mở từ toàn dự án — sổ đầy đủ tại
`00-index/OQ_e-commerce.md`. Ba câu quan trọng nhất trước khi trình AG2: **`OQ-056`**
(nối `OQ-022`, lịch diễn tập DR — điều kiện tiên quyết `DEC-12`), **`OQ-063`** (nối `OQ-008`,
đội Ops thật — chặn cả on-call §6.5 lẫn khả năng thực hiện diễn tập DR §5.4), **`OQ-054`**
(mâu thuẫn TCO/ADR-009 về cross-region snapshot Payment).

**Nhắc:** `ADR-014` (outbox, theo `DAT`), `ADR-015` (service JWT, theo `SEC`), `ADR-016`
(blue-green) và `ADR-017` (Terraform, theo `INF`) đã được viết ở lượt hoạt động `adr` kế tiếp —
GĐ2 nay đủ 9/9 hoạt động, 17 `ADR` tổng cộng, tất cả `Proposed`. Cần chạy `sa-conformance` để cập
nhật `DTM`/`ADL` và kiểm coverage trước khi trình AG2 (Tech Lead + Security + Ops/SRE ký).