1. Bài toán: một regression hiệu năng ẩn dưới lỗi chức năng
Trong một hệ thống fintech xử lý giao dịch chuyển tiền, chất lượng không chỉ là 'đúng' mà còn là 'kịp'. Một endpoint xác nhận giao dịch có thể trả về kết quả chính xác nhưng chậm tới mức vi phạm SLA, và độ chậm ấy đôi khi lại là nguyên nhân gốc của một lỗi chức năng ở thượng nguồn: client timeout rồi retry, sinh giao dịch trùng. Bài viết này tích hợp ba trụ cột — k6 để tạo tải và đo hiệu năng, Playwright để kiểm chức năng E2E, và observability (traces, metrics, logs, Grafana) để tương quan hai loại tín hiệu ấy trong CI.
Ràng buộc nghiệp vụ khắc nghiệt: p95 độ trễ của endpoint xác nhận phải dưới 400ms ở tải 2.000 giao dịch/giây, tỉ lệ lỗi dưới 0.1%, và tiền phải cân sổ kép tuyệt đối. SLO này không phải khẩu hiệu mà là cổng chặn trong pipeline: nếu ngưỡng k6 vỡ, build đỏ; nếu test chức năng Playwright đỏ, ta phải truy ngược qua trace để biết liệu nguyên nhân có phải là chính regression hiệu năng vừa phát hiện hay không.
2. Kiến trúc quan sát được: traces, metrics, logs
Observability đứng trên ba trụ: traces (dấu vết một request đi xuyên các service), metrics (số đo tổng hợp như p95, error rate), và logs (bản ghi sự kiện chi tiết). Trong pipeline này, cả k6 và Playwright đều gắn một trace id chung vào request, để khi một giao dịch chậm hay hỏng, ta lần được toàn bộ đường đi của nó qua các microservice và đọc trên Grafana. Đây là điều biến 'test đỏ' từ một bí ẩn thành một câu chuyện có thể điều tra.
❓ Trong ba trụ observability, cái nào quan trọng nhất khi điều tra một giao dịch chậm?
Không có cái nào 'quan trọng nhất' một cách tuyệt đối, nhưng trace là điểm khởi đầu tốt nhất cho một giao dịch cụ thể chậm. Metrics cho biết 'p95 tăng' nhưng không nói request nào; logs cho chi tiết nhưng rời rạc và khó nối; trace cho toàn bộ đường đi của đúng request đó qua các service kèm thời lượng mỗi span. Từ span nghẽn trong trace, ta nhảy sang logs của service đó để đọc chi tiết, và soi metrics để biết vấn đề là cá biệt hay hệ thống. Ba trụ bổ sung nhau; trace là sợi nối chúng.
3. SLO, ngưỡng và bất biến làm oracle kép
Ở đây oracle có hai mặt. Mặt hiệu năng: ngưỡng k6 (thresholds) định nghĩa SLO thành điều kiện pass/fail — p95 dưới 400ms, tỉ lệ lỗi HTTP dưới 0.1%. Mặt chức năng: bất biến nghiệp vụ — mỗi giao dịch chuyển tiền phải bảo toàn tổng số dư (tiền không tự sinh hay biến mất), và idempotency đảm bảo một lệnh chuyển chỉ thực thi một lần. Test đạt chỉ khi cả hai oracle đều xanh; một endpoint nhanh nhưng làm mất tiền, hay đúng tiền nhưng chậm hơn SLA, đều là thất bại.
- SLO trễ: p95 < 400ms, p99 < 900ms ở 2.000 giao dịch/giây.
- SLO lỗi: tỉ lệ lỗi HTTP < 0.1%; không có 5xx trong 10 phút cửa sổ.
- Bất biến tiền: tổng debit == tổng credit sau mọi lô giao dịch.
- Bất biến idempotency: cùng một transfer key → đúng một bút toán.
💬 Bình luận (0)
Chưa có bình luận nào. Hãy là người đầu tiên!