Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 6 — Mở rộng có kiểm soát: canary, rate limit và ngân sách

Đã đọc 0/8 mục · còn khoảng 3 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Scale không có nghĩa là "bật hết cho mọi người ngay". Scale an toàn là mở van từ từ, đo, rồi mở tiếp — đồng thời đặt trần để một sự cố không thể phá vỡ toàn hệ thống hay đốt sạch ngân sách. Bài này gộp ba kỹ thuật: canary/progressive rollout, rate limit, và cost cap.

Progressive rollout (canary)

Phát hành cho một phần nhỏ user trước (ví dụ 1%), theo dõi SLO và guardrail, rồi tăng dần 1% → 5% → 25% → 100%. Nếu tín hiệu xấu, tự động dừng và rollback (nối với Bài 5). Ưu điểm: sự cố chỉ ảnh hưởng nhóm nhỏ.

# quyết định định tuyến user vào phiên bản mới theo % rollout
def use_new_version(user_id):
    bucket = stable_hash(user_id) % 100     # 0..99, ổn định theo user
    return bucket < flags.get("new_version_pct")   # ví dụ 5 => 5% user

Dùng hash ổn định theo user để cùng một người luôn ở cùng nhánh, tránh trải nghiệm chập chờn.

Rate limit nhiều tầng

Agent gọi LLM và tool bên thứ ba vốn có hạn mức. Đặt trần ở nhiều tầng để tự bảo vệ:

  • Theo user: chống lạm dụng và vòng lặp vô hạn (ví dụ 30 request/phút/user).
  • Theo tool: tránh vượt quota API bên ngoài.
  • Toàn cục: trần tổng để không kéo sập nhà cung cấp hay chính bạn.
if not limiter.allow(user_id, limit=30, window="1m"):
    return "Bạn thao tác hơi nhanh, vui lòng thử lại sau ít giây."
if not limiter.allow("tool:refund_api", limit=100, window="1m"):
    queue_for_later(request)   # xếp hàng thay vì làm sập API đối tác

Cost cap và ngắt mạch (circuit breaker)

Đặt trần chi phí theo giờ/ngày. Khi vượt ngưỡng cảnh báo, giảm cấp (dùng model rẻ hơn, tắt tool đắt); khi vượt trần cứng, circuit breaker mở và chuyển sang fallback an toàn thay vì tiếp tục đốt tiền. Cũng dùng circuit breaker cho tool hay lỗi: sau N lỗi liên tiếp thì ngừng gọi tool đó một khoảng, tránh dồn lỗi.

Khung tư duy: mỗi bước tăng tải hỏi 3 điều

  • SLO có còn xanh ở % hiện tại không?
  • Chi phí/request có ổn định khi tải tăng, hay đang phình?
  • Tôi có rollback được ngay nếu bước tiếp theo hỏng không?
Chỉ mở van tiếp khi cả ba đều "có".

Các bước làm

  • Bắt đầu canary 1%, đặt cổng SLO tự động cho mỗi mốc tăng.
  • Cài rate limit ở tầng user, tool và toàn cục với giá trị hợp lý.
  • Đặt cost cap theo giờ/ngày, kèm mức giảm cấp và trần cứng.
  • Thêm circuit breaker cho tool hay lỗi và cho ngưỡng chi phí.
  • Tự động dừng rollout khi guardrail/SLO vi phạm, không chờ người bấm.

Checklist scale

  • [ ] Rollout theo % có cổng SLO tự động ở mỗi mốc.
  • [ ] Rate limit ở tầng user, tool, toàn cục.
  • [ ] Cost cap với mức giảm cấp và trần cứng.
  • [ ] Circuit breaker cho tool lỗi và cho chi phí.
  • [ ] Sự cố ở canary không lan ra ngoài nhóm nhỏ.

Sai lầm thường gặp

  • Big-bang 100%. Một lỗi nhỏ thành sự cố toàn hệ thống.
  • Không có trần chi phí. Vòng lặp agent hoặc lưu lượng tăng đột biến đốt sạch ngân sách.
  • Rate limit chỉ ở một tầng. Bảo vệ user nhưng vẫn làm sập API đối tác, hoặc ngược lại.
  • Rollout thủ công không cổng. Người mệt sẽ tăng % ẩu khi số liệu chưa ổn.
Bài sau bàn về vòng lặp và hành động của agent — nơi "mở rộng" gặp rủi ro thật sự về an toàn.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi