Tích hợp hiệu năng & chất lượng: AI agent + k6 + observability

1. Bối cảnh & oracle: SLO là chân lý, không phải 'chạy nhanh'

Chúng ta làm việc trên một nền tảng fintech xử lý ví điện tử và thanh toán QR cho khoảng ba triệu người dùng, cao điểm giờ trưa và tối lên tới mười hai nghìn giao dịch mỗi phút. Với hệ thống tiền bạc, 'nhanh' không phải một cảm giác mà là một cam kết đo được: SLO nói rằng p95 của API tạo giao dịch phải dưới bốn trăm mili-giây và tỉ lệ lỗi phải dưới nửa phần trăm trong cửa sổ trượt năm phút. Bài viết này ghép ba mảnh thường bị làm rời rạc: kiểm thử tải bằng k6, một AI agent để đề xuất kịch bản và đọc trace/metric, và observability để nhìn xuyên hệ thống. Điểm mấu chốt đặt lên đầu tiên: oracle của chúng ta là SLO, chứ không phải 'màn hình phản hồi mượt'.

Vì sao phải nhấn mạnh oracle? Bởi một bài kiểm thử tải mà chỉ in ra 'đã gửi mười nghìn request' thì không nói được điều gì về sức khỏe hệ thống. Chúng ta cần khẳng định những bất biến có ý nghĩa: dưới tải mục tiêu, p95 vẫn nằm trong ngân sách; không có request nào trả về mã 5xx quá ngưỡng; không giao dịch nào bị ghi hai lần khi client thử lại; và độ trễ hàng đợi ghi sổ kế toán không phình ra vô hạn. AI agent trong kiến trúc này không được phép tự phán 'đạt' hay 'trượt' — nó chỉ đề xuất kịch bản và tóm tắt bằng chứng, còn quyết định gate vẫn dựa trên ngưỡng SLO mã hóa cứng và một người review.

2. Ranh giới của AI agent: nó đề xuất, con người quyết

AI agent ở đây có ba nhiệm vụ rõ ràng và một danh sách dài những việc nó không được làm. Nó được phép: đọc đặc tả OpenAPI và lịch sử traffic để đề xuất hồ sơ tải (ramp-up, số VU, phân bố endpoint); đọc kết quả k6 cùng metric và trace để tóm tắt điểm nghẽn; và gợi ý ngưỡng cảnh báo dựa trên dữ liệu lịch sử. Nó không được phép: tự sửa ngưỡng SLO, tự đánh dấu một lần chạy là 'đạt', hay tự merge thay đổi vào nhánh chính. Ranh giới này quan trọng vì mô hình ngôn ngữ có thể ảo giác (ハルシネーション) — nó có thể 'tự tin' kết luận sai nếu ta để nó tự phán quyết.

Để chống ảo giác, ta áp dụng grounding: mọi kết luận của agent phải trích dẫn số liệu thật từ tệp kết quả k6 (summary.json) hoặc từ hệ observability, kèm mã truy vết. Nếu agent nói 'endpoint /pay chậm ở p99', câu đó phải đi kèm giá trị p99 cụ thể và khoảng thời gian lấy mẫu. Reviewer con người đọc bản tóm tắt có trích dẫn, đối chiếu nhanh với dashboard, rồi mới bấm phê duyệt. Cách này giữ tốc độ mà không đánh đổi độ tin cậy: agent làm phần đọc-tổng-hợp tốn công, con người giữ phần phán quyết.

• Agent ĐƯỢC: đề xuất hồ sơ tải, tóm tắt điểm nghẽn có trích dẫn, gợi ý ngưỡng cảnh báo.
• Agent KHÔNG: sửa SLO, tự phán đạt/trượt, tự merge.
• Con người GIỮ: định nghĩa SLO, phê duyệt gate, sở hữu ca rủi ro cao (thanh toán, hoàn tiền).

3. Định nghĩa SLO/SLI thành mã: nguồn sự thật duy nhất

Trước khi viết bất kỳ kịch bản k6 nào, ta cần cố định SLI (chỉ số ta đo) và SLO (ngưỡng ta cam kết) dưới dạng mã có thể diff và review. SLI của chúng ta gồm: độ trễ p95 và p99 của các endpoint quan trọng, tỉ lệ lỗi phân theo mã trạng thái, và thông lượng thành công. SLO đặt ngân sách cụ thể trên từng SLI. Việc mã hóa vào một tệp YAML duy nhất giúp cả k6, hệ cảnh báo và cổng CI đọc chung một nguồn — không ai được phép giữ 'ngưỡng riêng' trong đầu. Đây chính là oracle mà mọi thành phần khác phải phục tùng.

# slo.yaml — nguồn sự thật duy nhất cho oracle hiệu năng
service: wallet-payment-api
window: 5m            # cửa sổ trượt đánh giá
slos:
  - sli: latency_p95_ms
    endpoint: POST /v1/transactions
    threshold: 400     # p95 < 400ms
    comparator: "<"
  - sli: latency_p99_ms
    endpoint: POST /v1/transactions
    threshold: 900
    comparator: "<"
  - sli: error_rate
    scope: all
    threshold: 0.005   # < 0.5%
    comparator: "<"
  - sli: throughput_ok_rps
    scope: all
    threshold: 150     # phải chịu >= 150 rps thành công
    comparator: ">="
guardrails:
  agent_may_edit: false   # agent KHÔNG được sửa file này
  human_approver: "qa-lead"

Lưu ý cách chúng ta gắn comparator rõ ràng cho từng SLI. Điều này quan trọng vì có chỉ số cần nhỏ hơn (độ trễ, tỉ lệ lỗi) và có chỉ số cần lớn hơn (thông lượng thành công). Khi cổng CI đọc tệp này, nó không đoán chiều so sánh mà tuân theo đúng khai báo. Trường 'agent_may_edit: false' được chương trình CI thực thi cứng: nếu agent gửi PR chạm vào slo.yaml, pipeline tự động từ chối. Nhờ vậy oracle không thể bị bào mòn một cách vô tình hay cố ý.

4. Agent đề xuất hồ sơ tải từ đặc tả & traffic thật

Bước đầu tiên của agent là biến hiểu biết về hệ thống thành một hồ sơ tải có căn cứ. Thay vì đoán 'chạy một nghìn VU', agent đọc phân bố endpoint trong bảy ngày traffic gần nhất, nhận ra rằng tạo giao dịch chiếm khoảng sáu mươi phần trăm, tra cứu số dư chiếm ba mươi phần trăm, phần còn lại là lịch sử và hồ sơ. Nó đề xuất một hồ sơ ramp-up phản ánh đúng tỉ lệ đó và mô phỏng cao điểm giờ trưa. Quan trọng: agent xuất ra đề xuất dưới dạng JSON có cấu trúc để con người review, chứ không tự chạy.