Kiểm thử tải nhẹ và chất lượng dữ liệu feed

1. Tại sao ChatGPT App cần kiểm thử tải?

Trong web cổ điển, kiểm thử tải thường gắn với hình ảnh “hàng triệu RPS, cụm máy khổng lồ, pizza cho SRE”. Với ChatGPT App và các máy chủ MCP, thực tế đơn giản và — may mắn thay — rẻ hơn. Về nguyên tắc bạn đã quen với SLO, nhưng hãy xem SLO/observability và chất lượng feed tương tác thế nào dưới tải.

Đặc điểm chính: ChatGPT chờ hoàn tất tool call để tiếp tục sinh câu trả lời. Người dùng thấy luồng token rất đẹp, nhưng ngay khi mô hình quyết định gọi công cụ, phép màu của stream kết thúc — cho đến khi backend phản hồi. Nếu MCP hoặc ACP server của bạn đôi khi trả lời 8–10 giây thay vì mục tiêu 2–4, UX sẽ biến từ “trợ lý kỳ diệu” thành “lại một trang web chậm nữa”.

Cộng thêm một ngân sách timeout rất chặt: đối với các lần gọi công cụ, OpenAI đặt trần khoảng hàng chục giây (con số chính xác phụ thuộc chế độ, nhưng hãy nghĩ trong khoảng 30–60 giây, còn về UX — tốt nhất trong 5–10 giây). Nếu tại đỉnh tải các tool calls của bạn bỗng mất 25–30 giây, về hình thức vẫn trong giới hạn, nhưng dưới góc nhìn người dùng thì đã coi như “hỏng”.

Điểm thứ hai: chúng ta không quá quan tâm RPS trừu tượng, mà là mức độ đồng thời. Với App trên Store, 50–100 người dùng hoạt động đồng thời là hoàn toàn thực tế; đó mới là thứ ta muốn kiểm tra, chứ không phải “chịu nổi 50k RPS của GET /health tổng hợp hay không”.

Và cuối cùng, ChatGPT App là một stack:

flowchart LR
  User --> ChatGPT
  ChatGPT -->|tools/call| MCP["MCP server GiftGenius"]
  MCP --> DB["CSDL feed quà tặng"]
  MCP --> ACP["Checkout / ACP backend"]
  ACP --> PSP["Cổng thanh toán / Stripe"]

Nếu không kiểm tra xem stack này vận hành thế nào dưới tải nhỏ nhưng thực tế, thì bất kỳ chiến dịch promo nào hoặc được lên trang chọn lọc của Store đều có thể nhanh chóng biến nó thành slide “làm sản phẩm LLM sai cách”.

Trong bài này, “kiểm thử tải nhẹ” là các lần chạy ngắn (thường 1–10 phút) nhằm kiểm tra:

• hệ thống có chịu được đỉnh online kỳ vọng hay không;
• p95/p99 độ trễ có vượt SLO hay không;
• có phát sinh lỗi, timeout và rate‑limit từ API bên ngoài hay không.

Song song, ta xem mặt còn lại của chất lượng — dữ liệu product feed (sau đây gọi tắt là “feed”), thiếu nó thì GiftGenius sẽ không còn “Gift” lẫn “Genius”.

Trong bài, trước tiên ta xử lý kiểm thử tải nhẹ cho MCP/ACP (nên tải gì và tải thế nào, xem metric nào), rồi gắn nó với observability (độ trễ, lỗi, tài nguyên, webhooks và log), và nửa sau nói về chất lượng feed và cách nó “bắn” bất ngờ dưới tải.

2. Tải cái gì: không phải ChatGPT, mà là API của bạn

Cần chốt một ý để khỏi nhầm về sau: kiểm thử tải được thực hiện trực tiếp vào backend của chúng ta — máy chủ MCP, các endpoint ACP, webhooks — chứ không qua UI ChatGPT.

Có vài lý do.

• Thứ nhất, tiết kiệm. Nếu bắn các tool calls thực qua ChatGPT, bạn sẽ trả tiền token và đồng thời đụng giới hạn của ChatGPT, trong khi thứ bạn cần kiểm thử là code của chính mình.
• Thứ hai, tính dự đoán. Khi gọi trực tiếp /mcp hoặc /api/checkout, bạn kiểm soát được kịch bản, không phụ thuộc việc mô hình có quyết định gọi công cụ vào lúc đó hay không.
• Thứ ba, sự minh bạch. Dưới tải, bạn muốn thấy rõ: 2000 request vào MCP trong 5 phút, phân phối độ trễ ra sao, đồ thị CPU thế nào. Nếu tải thông qua ChatGPT, một lớp nhiễu và giới hạn bổ sung chỉ làm bức tranh thêm rối.

Bộ endpoint điển hình để kiểm thử tải cho GiftGenius:

• endpoint của MCP server hiện thực hoá JSON‑RPC tools (/mcp hoặc tương tự);
• một‑hai endpoint ACP để tạo và hoàn tất checkout (trong chế độ sandbox của cổng thanh toán);
• có thể — endpoint xử lý webhooks từ cổng thanh toán để xem hành vi lúc đỉnh sự kiện.

Giả sử chúng ta có Next.js 16 backend, chạy MCP server trên /api/mcp, và ACP server với endpoint /api/checkout/create.

3. Kịch bản smoke‑load mini cho GiftGenius

Hãy tưởng tượng PM của chúng ta tin vào tương lai tươi sáng và nói: “Đỉnh tải thực tế — 50 người dùng đồng thời, mỗi người vào, chọn quà và đôi khi đi tới bước thanh toán”.

Với kiểm thử tải nhẹ, đủ để mô phỏng khoảng 30–50 “virtual users” (VU), mỗi người thực hiện chuỗi:

1. Gọi công cụ giftgenius.search_gifts (tìm quà theo hồ sơ và ngân sách).
2. Gọi giftgenius.get_gift_details cho vài sản phẩm trong kết quả.
3. (Đôi khi) gọi endpoint ACP create_checkout_session cho một sản phẩm.

Tất cả đều qua HTTP trực tiếp tới MCP/ACP của chúng ta, không dùng ChatGPT.

Gọi JSON‑RPC tới MCP

Ví dụ payload yêu cầu tới MCP (đơn giản hoá):

const body = {
  jsonrpc: "2.0",
  id: "test-" + Math.random(),
  method: "tools/call",
  params: {
    toolName: "giftgenius.search_gifts",
    arguments: {
      occasion: "birthday",
      budget: 50,
      interests: ["sport", "books"],
    },
  },
};

Trong dự án thực, cấu trúc có thể hơi khác, nhưng nguyên lý là vậy: một phương thức JSON‑RPC, bên trong là tool và tham số.

4. Viết script tải đơn giản bằng TypeScript

Bước đầu, ta hiện thực phần đơn giản nhất của kịch bản — gọi giftgenius.search_gifts tới MCP. Trước tiên viết một Node.js script bằng TypeScript để gửi các request tới /api/mcp và đo độ trễ; sau đó mới thêm checkout và luồng phức tạp hơn.

HTTP client cơ bản

Giả sử ta có .env với MCP_URL=http://localhost:3000/api/mcp.

// scripts/loadTest.ts
import "dotenv/config";

const MCP_URL = process.env.MCP_URL!;

async function callSearchGifts() {
  const body = {
    jsonrpc: "2.0",
    id: `search-${Date.now()}-${Math.random()}`,
    method: "tools/call",
    params: {
      toolName: "giftgenius.search_gifts",
      arguments: { occasion: "birthday", budget: 50 },
    },
  };

  const started = Date.now();
  const res = await fetch(MCP_URL, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(body),
  });
  const latencyMs = Date.now() - started;
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  return latencyMs;
}

Bạn có thể thêm parsing JSON đơn giản cho response, nhưng để đo latency/error rate thì thế này là đủ.

Chạy đồng thời nhiều yêu cầu

Ta cần điều khiển số lượng request đồng thời. Đơn giản nhất là dùng số “virtual users” cố định và yêu cầu mỗi người thực hiện N request liên tiếp.

async function runVirtualUser(iterations: number) {
  const latencies: number[] = [];
  for (let i = 0; i < iterations; i++) {
    try {
      const ms = await callSearchGifts();
      latencies.push(ms);
    } catch (e) {
      console.error("Error in VU:", e);
      latencies.push(-1); // đánh dấu lỗi
    }
  }
  return latencies;
}

Giờ ta có thể chạy, ví dụ, 20 virtual users:

async function main() {
  const users = 20;
  const iterations = 10;

  const tasks = Array.from({ length: users }, () =>
    runVirtualUser(iterations),
  );

  const results = await Promise.all(tasks);
  const all = results.flat();
  // ...tính toán số liệu
}

main().catch((e) => console.error(e));

Như vậy sẽ tạo ra khoảng 200 lần gọi MCP, một phần trong số đó chạy song song, tức là đạt mức độ đồng thời khá cao.

Tính p95 và error rate

Thêm một tiện ích nhỏ để tính percentile và lỗi. Nhắc lại: p95 là giá trị mà 95% request có độ trễ thấp hơn nó.

function percentile(values: number[], p: number) {
  const sorted = values.filter(v => v >= 0).sort((a, b) => a - b);
  if (!sorted.length) return 0;
  const idx = Math.floor((p / 100) * (sorted.length - 1));
  return sorted[idx];
}

function errorRate(values: number[]) {
  const total = values.length;
  const errors = values.filter(v => v < 0).length;
  return (errors / total) * 100;
}

Và trong main thêm phần in ra:

const p95 = percentile(all, 95);
const p99 = percentile(all, 99);
const errRate = errorRate(all);

console.log(`Total: ${all.length}`);
console.log(`p95: ${p95} ms, p99: ${p99} ms`);
console.log(`Error rate: ${errRate.toFixed(2)}%`);

Giờ bạn đã có script smoke‑load tối thiểu có thể chạy local hoặc staging trước khi release. Như vậy bạn không đụng tới ChatGPT, không đốt token, và tập trung hoàn toàn vào MCP của mình.

Với ACP và checkout thì sao

Tương tự, thêm helper callCreateCheckoutSession để gọi endpoint ACP. Quan trọng là dùng chế độ test/sandbox của cổng thanh toán để không tạo đơn hàng thật. Lần gọi điển hình sẽ là POST với JSON:

async function callCreateCheckoutSession(productId: string) {
  const started = Date.now();
  const res = await fetch("http://localhost:3000/api/checkout/create", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ productId, test: true }),
  });
  const latencyMs = Date.now() - started;
  if (!res.ok) throw new Error(`HTTP ${res.status}`);
  return latencyMs;
}

Sau đó, trong runVirtualUser bạn có thể áp dụng pattern: 3 lần tìm kiếm → 1 lần checkout, để mô phỏng phễu “tìm kiếm nhiều hơn mua”.

5. Công cụ chuyên dụng: k6 (nhưng dùng đơn giản)

Node script rất tốt cho “bước vào tối thiểu”, nhưng đôi khi thuận tiện hơn khi dùng công cụ chuyên biệt như k6, viết kịch bản bằng JavaScript, còn runtime bằng Go (tức là nhanh).

Ví dụ một kịch bản k6 nhỏ cho MCP:

// loadtest-mcp.js
import http from "k6/http";
import { check, sleep } from "k6";

export const options = {
  stages: [
    { duration: "30s", target: 30 },
    { duration: "2m", target: 30 },
  ],
};

export default function () {
  const payload = JSON.stringify({
    jsonrpc: "2.0",
    id: `search-${Math.random()}`,
    method: "tools/call",
    params: {
      toolName: "giftgenius.search_gifts",
      arguments: { occasion: "birthday", budget: 50 },
    },
  });

  const res = http.post(__ENV.MCP_URL, payload, {
    headers: { "Content-Type": "application/json" },
  });

  check(res, { "status is 200": (r) => r.status === 200 });
  sleep(1);
}

Lệnh chạy:

MCP_URL=http://localhost:3000/api/mcp k6 run loadtest-mcp.js

k6 tự tính p95/p99 và error rate, vẽ báo cáo đẹp — sau đó bạn có thể xuất ra Grafana và các hệ thống khác.

Quan trọng là ngay cả với những công cụ như vậy, mục tiêu của chúng ta vẫn như cũ: không phải chịu nổi triệu RPS, mà là đảm bảo khi tải gấp 5–10× đỉnh kỳ vọng, hệ thống không sụp và p95 vẫn nằm trong SLO.

6. Xem gì trong (và sau) khi chạy tải

Chúng ta đã bàn về metric và SLO, giờ “đặt chân xuống đất” trong ngữ cảnh tải.

Thứ nhất, độ trễ (latency). Với các tool của MCP như search_gifts, bạn đã tự đặt mục tiêu kiểu “p95 < 2–3 giây”. Trong lúc smoke‑load, hãy xem p95/p99 có bò lên 2–3 lần hay không. Đồng thời so với baseline: nếu trước khi đổi code p95 là 400 ms, còn sau đó — 1500 ms, dù về hình thức vẫn trong SLO, thì cũng đáng phải xem lại.

Thứ hai, error rate. Dưới tải thường lòi ra những điều bất ngờ: pool kết nối DB cạn, 429 từ API ngoài, timeout khi gọi cổng thanh toán. Ở tải bình thường, error rate nên gần 0; trong smoke‑load có thể có vài lỗi lẻ tẻ, nhưng chắc chắn không phải 5–10%.

Thứ ba, tài nguyên: CPU, bộ nhớ, đôi khi — số lượng file descriptor và kết nối mở. Tùy hạ tầng, nhưng ý chính đơn giản: bạn không muốn thấy CPU 100% ở 30 VU và GC chiếm nửa thời gian.

Thứ tư, webhooks. Nếu có kịch bản commerce, điểm kết thúc đơn hàng thường phụ thuộc vào việc xử lý webhook thành công từ cổng thanh toán. Hãy nhìn không chỉ tốc độ request ở ACP mà còn độ trễ “webhook tới → ta xử lý thành công”.

Cuối cùng, log. Log có cấu trúc với trace_id/checkout_session_id cho phép sau khi chạy tải, bạn lấy vài request chậm nhất hoặc bị lỗi và lần theo chuỗi: MCP → API ngoài → ACP → webhook. Điều này đặc biệt hữu ích nếu dưới tải bạn thấy đuôi p99 kỳ lạ.

7. Chất lượng dữ liệu feed: từ cấu trúc đến ngữ nghĩa

Ta đã xem độ trễ, lỗi và tài nguyên dưới tải. Nhưng ngay cả khi mọi SLO này đều đạt mục tiêu, trải nghiệm người dùng vẫn có thể “vỡ vụn” vì dữ liệu kém.

Chuyển sang chủ đề lớn thứ hai: dữ liệu. Trong app commerce như GiftGenius, product feed (feed sản phẩm) không phải “thứ gì đó trên đĩa”, mà là nhiên liệu cho LLM và agent. Nếu feed là rác, mô hình sẽ không “tự nghĩ” ra giá và tồn kho giúp bạn.

Nghĩ về chất lượng feed theo ba lớp sẽ tiện hơn.

Mức cấu trúc

Đây là tính hợp lệ cơ bản của dữ liệu:

• JSON parse hợp lệ.
• Tất cả trường bắt buộc có mặt: id, name, price, currency, imageUrl, availability v.v.
• Kiểu giá trị đúng kỳ vọng: giá là số, availability là enum, categories là mảng chuỗi.
• Không có trùng id.

Một phần đã được bạn bao phủ bằng contract test khi mô tả JSON Schema/Zod schema cho feed. Giờ cần áp dụng các schema này cho dữ liệu thực tế.

Ví dụ Zod schema đơn giản cho phần tử feed của GiftGenius:

import { z } from "zod";

export const giftItemSchema = z.object({
  id: z.string().min(1),
  name: z.string().min(3),
  description: z.string().optional(),
  price: z.number().positive(),
  currency: z.enum(["USD", "EUR", "GBP"]),
  imageUrl: z.string().url(),
  inStock: z.boolean(),
  tags: z.array(z.string()).default([]),
});

Schema của toàn bộ feed đơn giản là z.array(giftItemSchema).

Mức nghiệp vụ (ngữ nghĩa)

Cấu trúc hợp lệ nhưng xét theo nghiệp vụ lại vô lý:

• Giá 0 hoặc 0.01 cho mặt hàng đắt tiền.
• Tiền tệ không đúng thị trường (USD cho hàng chỉ bán bằng EUR).
• inStock = true, nhưng ngày cập nhật cuối cùng đã nửa năm trước.
• Danh mục có 1000 biến thể không được chuẩn hoá.

Cho mức này, nên thêm các kiểm tra bổ sung và “quy tắc thường thức”. Ví dụ:

const businessRules = (item: GiftItem) => {
  const problems: string[] = [];

  if (item.price > 10000) {
    problems.push("giá cao bất thường");
  }
  if (!item.inStock && item.tags.includes("bestseller")) {
    problems.push("bestseller nhưng không còn hàng");
  }
  return problems;
};

Các kiểm tra này có thể chạy như một nightly job hoặc khi tạo feed mới.

Mức LLM

Mô hình rất thông minh, nhưng cũng có “tật riêng”:

• Mô tả chứa đầy HTML, thẻ thừa và văn bản kỹ thuật.
• Trộn ngôn ngữ (nửa feed tiếng Nga, nửa tiếng Anh) mà không chỉ rõ locale.
• “Tên SEO” quá dài kiểu “Mua quà tốt nhất siêu‑đỉnh gấp gáp giá rẻ”.

Ở mức này cần đưa dữ liệu về dạng thân thiện:

• Loại bỏ thẻ HTML hoặc chuyển về plaintext.
• Chuẩn hoá ngôn ngữ mô tả (hoặc ít nhất ghi rõ locale).
• Cắt bớt tên quá dài và thông tin trùng lặp.

Một phần có thể tự động hoá (ví dụ qua các script tiền xử lý), và một phần — trao đổi với đội phụ trách nhập liệu cho feed.

8. Thực hành: validator cho feed của GiftGenius

Thêm vào dự án một script validateFeed.ts đọc JSON feed, kiểm tra bằng Zod và tính các metric chất lượng cơ bản.

// scripts/validateFeed.ts
import { readFile } from "fs/promises";
import { giftItemSchema } from "../src/schema/giftItem";

async function main() {
  const raw = await readFile("data/gift-feed.json", "utf-8");
  const data = JSON.parse(raw);

  const items = giftItemSchema.array().parse(data);
  console.log(`Tổng số sản phẩm: ${items.length}`);

  const missingImages = items.filter(i => !i.imageUrl).length;
  console.log(`Thiếu ảnh: ${missingImages}`);
}

main().catch((e) => {
  console.error("Feed validation failed:", e);
  process.exit(1);
});

Ở đây ta dùng cùng một contract như MCP server, tức là contract test và kiểm tra feed cùng dùng một schema — điều này giảm mạnh khả năng sai biệt.

Tiếp theo, có thể thêm các kiểm tra nghiệp vụ và metric như:

• tỷ lệ sản phẩm không có mô tả;
• tỷ lệ sản phẩm có giá bất thường thấp/cao;
• số lượng trùng id hoặc trùng name + price.

Các con số này có thể gửi lên hệ thống metric (Prometheus, Datadog, v.v.) và đặt SLO riêng cho chất lượng dữ liệu — tương tự như SLO cho code.

9. Tải và feed liên quan thế nào

Đôi khi “hiệu năng” và “chất lượng dữ liệu” có vẻ không mấy liên quan. Thực tế, chúng đan xen khá chặt.

Ví dụ liên hệ:

• Dưới tải, một phần request đi vào các nhánh logic “hiếm” vốn ít gặp. Ví dụ, hàng có kiểu giảm giá đặc biệt hoặc shipping không chuẩn. Nếu feed ở các chỗ này bẩn, bạn có thể nhận cả lỗi lẫn suy giảm hiệu năng nghiêm trọng (đống validate, exception, logic fallback).
• Nếu feed quá ồn (mô tả dài với HTML, tag vô nghĩa), MCP server phải tải và serialize nhiều dữ liệu hơn, trực tiếp ảnh hưởng thời gian xử lý tool-call và kích thước phản hồi.
• Ở phần commerce, feed kém có thể dẫn tới nhiều lần checkout “rỗng”, khi người dùng chọn sản phẩm bất ngờ hết hàng. Điều này ảnh hưởng UX và metric ACP (tăng số intent không thành công).

Nhìn theo ma trận sẽ tiện:

Ở đây, kiểm thử tải đóng vai trò “đèn pin”: nó giúp soi ra các vùng của feed vốn hiếm khi bị đụng tới trong ngày thường, nhưng khi lưu lượng tăng lại bắt đầu “bắn”.

10. Tích hợp vào quy trình release của GiftGenius

Về quy trình, mọi thứ ở trên không nên là “một lần trước prod đầu tiên”. Trong chương trình học các module 16 (“Production, mạng và mở rộng”) và 17 (“Quan sát và chất lượng”), cách làm này được gắn như một phần của release checklist: trước khi release, bạn không chỉ chạy unit/contract/E2E, mà còn chạy smoke‑load ngắn cộng kiểm tra feed.

Pipeline tối thiểu hợp lý trước khi deploy phiên bản mới:

1. Unit + contract + integration test xanh.
2. Smoke‑load ngắn với MCP/ACP trên staging nếu có thay đổi code quan trọng (logic tìm kiếm, làm việc với DB, checkout).
3. Validator feed chạy không lỗi, các metric cơ bản của feed (số bản ghi hỏng, tỷ lệ thiếu ảnh, v.v.) trong ngưỡng chấp nhận.
4. Dashboard và alert được cập nhật theo các endpoint và SLO mới.
5. Nếu fail, có kế hoạch rollback: tắt tính năng bằng flag hoặc rollback build.

Như vậy, GiftGenius của bạn không còn là “demo cho DevDay” mà trở thành dịch vụ sẵn sàng lên Store và chịu được đột biến lưu lượng.

11. Lỗi thường gặp khi kiểm thử tải và kiểm tra feed

Lỗi số 1: kiểm thử tải “qua ChatGPT” thay vì vào backend của mình.
Đôi khi muốn “giống thực tế” nên chạy script đi qua UI ChatGPT. Kết quả là đụng giới hạn OpenAI, đốt token và nhận kết quả rất nhiễu. Trong khi vấn đề MCP/ACP có thể bắt được rẻ hơn hàng trăm lần nếu bắn thẳng vào /mcp và /api/checkout.

Lỗi số 2: chỉ tập trung vào thời gian phản hồi trung bình.
“Độ trễ trung bình 500 ms, mọi thứ ổn” — còn p95 là 5 giây thì lại quên. Ta đã bàn trong chủ đề SLO rằng chính phần đuôi phân phối (p95/p99) mới quyết định UX thực. Dưới tải, trung bình thường vẫn ổn, còn đuôi thì phình gấp đôi, gấp ba.

Lỗi số 3: cố dựng “enterprise load” thay vì smoke‑load thực dụng.
Bỏ hàng tháng xây một bãi kiểm thử phức tạp mô phỏng hàng chục nghìn người dùng cho ChatGPT App cỡ GiftGenius — gần như luôn là thừa. Hữu ích hơn là có smoke‑load đơn giản nhưng chạy đều, 50–100 VU với metric rõ ràng.

Lỗi số 4: kịch bản tải không thực tế.
Script gửi một request lặp đi lặp lại, không biến thiên người dùng, ngôn ngữ, loại hàng, và không đụng ACP hay webhooks. Kết quả là bạn kiểm thử một happy‑path nóng, còn các “góc cạnh” thật thì vẫn trong bóng tối. Hãy mô phỏng ít nhất một flow đơn giản nhưng hợp lý: ngân sách khác nhau, sở thích khác nhau, một phần người dùng đi tới checkout, một phần thì không.

Lỗi số 5: kiểm tra feed “bằng mắt” hoặc ngay trên prod.
Feed được tạo, đẩy lên prod, thấy mô hình gợi ý kỳ lạ rồi mới gãi đầu. Trong khi một script đơn giản bằng Zod/JSON Schema có thể cho thấy trong một phút rằng 10% sản phẩm thiếu ảnh, 5% có giá 0, và 3% có tiền tệ XXX. Thiếu kiểm tra tự động cho feed là một trong những nguồn xấu hổ phổ biến nhất ở ứng dụng commerce.

Lỗi số 6: hy vọng LLM “tự hiểu” khi feed kém.
Đúng là mô hình làm được nhiều thứ, nhưng nó sẽ không bịa ra giá đúng hoặc tồn kho. Nếu cùng một sản phẩm trong feed xuất hiện với giá khác nhau, hoặc “còn hàng”/“hết hàng” đồng thời, agent có thể sinh cả ảo giác lẫn trải nghiệm không nhất quán. Trách nhiệm về độ sạch dữ liệu là của bạn, không phải của mô hình.

Lỗi số 7: không liên kết metric feed với SLO tổng thể.
Bạn có thể có MCP và ACP cực nhanh, nhưng nếu 30% sản phẩm trong feed “hỏng”, trải nghiệm người dùng vẫn tệ. Nhiều đội chỉ theo dõi SLO kỹ thuật (độ trễ, error rate) và bỏ qua SLO chất lượng dữ liệu (tối thiểu % SKU hợp lệ, tối đa số trùng, v.v.). Hậu quả là “trên số thì tốt”, nhưng “cảm nhận thì không”.

Lỗi số 8: chạy kiểm thử tải thẳng trên prod mà không chuẩn bị.
Đôi khi ai đó chiều thứ Sáu quyết định “chạy nhanh k6 trên MCP prod”, không báo trước ai. Trường hợp tốt là bạn làm lệch metric thật và làm on‑call hoang mang vì đột biến lưu lượng, xấu hơn là đụng phải rate‑limit của API ngoài hoặc cổng thanh toán. Luôn chạy kịch bản đầu trên staging, còn nếu cần test prod — hãy làm có chủ đích, có khung giờ và thông báo.