Độ tin cậy: lời hứa bạn bán cho người dùng
Một hệ thống AI nhanh và rẻ nhưng hay sập thì vô dụng. Độ tin cậy (reliability) là nền móng của lòng tin. AI Infra PM dùng ngôn ngữ SRE để định lượng lời hứa này: SLI, SLO, error budget.
- SLI (Service Level Indicator) — chỉ số đo được, ví dụ tỉ lệ request thành công, độ trễ p95, TTFT.
- SLO (Service Level Objective) — mục tiêu bạn cam kết, ví dụ "99,9% request thành công", "p95 < 800ms".
- SLA — cam kết hợp đồng có ràng buộc pháp lý/tiền phạt (thường lỏng hơn SLO nội bộ).
Error budget: ngân sách được phép sai
Đây là công cụ tư duy đắt giá. SLO 99,9% uptime nghĩa là bạn được phép lỗi 0,1% — đó là error budget. Trong 30 ngày, 99,9% cho phép ~43 phút downtime.
Error budget biến độ tin cậy từ tuyệt đối thành có thể quản trị: còn budget thì đội được phép tung tính năng mới, chấp nhận rủi ro; cạn budget thì đóng băng thay đổi, dồn sức ổn định hệ thống. Nó chấm dứt cuộc cãi vã "nhanh hay ổn định" bằng một con số.
Vì sao độ tin cậy AI khó hơn hệ thống thường
- Phụ thuộc nhà cung cấp bên thứ ba. Nếu bạn gọi API mô hình ngoài, downtime của họ là downtime của bạn.
- Suy giảm âm thầm về chất lượng. Hệ thống vẫn trả 200 OK nhưng câu trả lời sai/vô nghĩa — uptime nói "ổn" trong khi người dùng khổ. Cần SLI chất lượng, không chỉ SLI kỹ thuật.
- Tải bùng nổ + cold start. Đỉnh đột ngột gặp GPU chưa kịp scale → lỗi hàng loạt.
- Chi phí downtime kép. Vừa mất doanh thu vừa vẫn trả tiền GPU.
Các mẫu thiết kế tăng độ tin cậy
- Fallback model. Mô hình chính lỗi/quá tải → tự chuyển sang mô hình nhỏ hơn/nhà cung cấp dự phòng. Giảm chất lượng còn hơn sập hẳn.
- Timeout + retry có kiểm soát. Đặt timeout hợp lý; retry có backoff, tránh retry-bão làm sập thêm.
- Rate limiting & load shedding. Khi quá tải, chủ động từ chối một phần request để bảo vệ phần còn lại — thà phục vụ tốt 90% còn hơn làm hỏng 100%.
- Graceful degradation. Tắt tính năng phụ để giữ tính năng lõi sống.
Ví dụ error budget trong hành động
Đội đặt SLO p95 < 500ms, uptime 99,9%. Giữa tháng, một bản deploy làm p95 vọt lên 900ms suốt 2 ngày, đốt 70% error budget. Theo chính sách error budget, đội tạm dừng mọi thay đổi tính năng, tập trung tối ưu/rollback tới khi latency về ngưỡng. Không tranh cãi cảm tính — con số quyết định.
Khung tư duy đặt SLO
- Bắt đầu từ tác động tới người dùng, không từ khả năng kỹ thuật.
- Chọn 2–4 SLI thật sự phản ánh trải nghiệm (gồm cả 1 SLI chất lượng).
- Đặt SLO khả thi — 100% là bẫy, cực kỳ tốn kém và bất khả thi.
- Gắn error budget với chính sách hành động rõ ràng.
- Rà soát định kỳ; SLO là văn bản sống.
Checklist vận hành
- [ ] Định nghĩa SLI kỹ thuật + ít nhất 1 SLI chất lượng.
- [ ] Đặt SLO có con số, kèm error budget và chính sách khi cạn budget.
- [ ] Có fallback model / nhà cung cấp dự phòng.
- [ ] Cấu hình timeout, retry-backoff, rate limiting, load shedding.
- [ ] Giám sát (dashboard + alert) theo p95/p99, không theo trung bình.
- [ ] Chạy postmortem không đổ lỗi sau mỗi sự cố.
Sai lầm thường gặp
- Đặt SLO 100%. Tốn kém vô lý và luôn thất bại về mặt kỹ thuật.
- Chỉ đo uptime kỹ thuật. Bỏ lọt suy giảm chất lượng — người dùng khổ mà dashboard xanh.
- Không có fallback. Một điểm lỗi duy nhất kéo sập cả sản phẩm.
- Retry không backoff. Biến sự cố nhỏ thành thác lỗi (retry storm).