Nâng cấp một bot đang chạy production khác hoàn toàn với làm demo. Sai một bước có thể làm hỏng dữ liệu thật của khách. Bài này là quy trình migration từng bước, có đường lui ở mỗi giai đoạn.
Nguyên tắc vàng: nâng cấp dần, luôn có đường lui
Đừng "big bang" thay cả bot trong một đêm. Dùng chiến lược song song và mở dần lưu lượng (progressive rollout), giống blue-green deployment.
Quy trình migration 7 bước
- Chốt baseline & KPI: đo tỷ lệ thành công, thời gian xử lý, tỷ lệ fail của RPA hiện tại. Đây là mốc so sánh.
- Chạy shadow mode: agent chạy song song RPA nhưng không hành động thật — chỉ ghi log "nếu là tôi thì tôi làm X". So sánh với quyết định RPA/người.
- Đo độ khớp: agent khớp bao nhiêu % với đáp án đúng? Phân tích các case lệch.
- Canary 5-10%: cho agent xử lý thật một phần nhỏ lưu lượng, rủi ro thấp trước.
- Giám sát chặt & mở dần: nếu KPI ổn, tăng dần lên 25% → 50% → 100%.
- Giữ RPA cũ làm fallback: mọi lúc có thể tắt agent, quay về luồng cũ bằng feature flag.
- Dọn dẹp sau ổn định: khi agent chứng minh ổn định vài tuần, mới cân nhắc lược bớt code cũ.
Shadow mode (pseudocode)
def process(item):
rpa_result = rpa_handle(item) # LUỒNG THẬT, vẫn quyết định
if SHADOW_AGENT_ON:
try:
agent_result = agent_handle(item) # KHÔNG hành động thật
log_compare(item.id, rpa_result, agent_result)
except Exception as e:
log_error("shadow_fail", e) # lỗi shadow KHÔNG ảnh hưởng thật
return rpa_result
Shadow mode cho bạn dữ liệu để tự tin mà không rủi ro gì cho khách.
Router theo phần trăm (canary)
import random
def route(item):
if random.random() < ROLLOUT_PCT and eligible(item):
return agent_handle(item) # luồng mới
return rpa_handle(item) # luồng cũ, an toàn
Tăng ROLLOUT_PCT từ từ, theo dõi KPI sau mỗi lần tăng.
Bảng cổng an toàn (go/no-go) để mở rộng lưu lượng
| Giai đoạn | Điều kiện để tiến tiếp |
|---|---|
| Shadow → Canary | Độ khớp ≥ 95% ở case quan trọng, không có lỗi nghiêm trọng |
| 10% → 25% | KPI không tệ hơn baseline, chi phí token trong dự toán |
| 25% → 100% | Ổn định ≥ 1-2 tuần, có runbook xử lý sự cố |
Kế hoạch rollback
- Feature flag tắt agent trong < 1 phút.
- Định nghĩa rõ "điều kiện kích hoạt rollback": ví dụ tỷ lệ lỗi > X%, chi phí token vượt Y, hoặc phàn nàn khách tăng.
- Diễn tập rollback ít nhất một lần trước khi lên production.
Khung tư duy: "Chứng minh, đừng tin"
Mỗi lần mở lưu lượng phải dựa trên dữ liệu đo được, không dựa vào cảm giác "chắc ổn". Shadow mode và canary tồn tại để chứng minh trước khi giao việc thật.
Checklist migration
- [ ] Đã đo baseline/KPI trước khi bắt đầu
- [ ] Chạy shadow mode và phân tích case lệch
- [ ] Có feature flag rollback nhanh, đã diễn tập
- [ ] Rollout theo canary tăng dần, có cổng go/no-go
- [ ] RPA cũ còn nguyên làm fallback trong suốt migration
- [ ] Có runbook và người trực trong giai đoạn mở rộng
Sai lầm thường gặp
- Big bang thay cả bot: rủi ro cực cao, không có đường lui.
- Bỏ qua shadow mode: giao việc thật cho agent khi chưa có bằng chứng nó đúng.
- Không đo baseline: không biết agent tốt hơn hay tệ hơn.
- Xóa code RPA cũ quá sớm: mất fallback khi agent gặp case lạ.
- Không diễn tập rollback: đến lúc sự cố mới phát hiện nút tắt không hoạt động.
- Mở 100% ngay sau canary tốt một ngày: mẫu quá nhỏ, chưa gặp case hiếm.
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