Product Management
Đăng nhập
ESC

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

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

Bài 4 — Xây agent deploy: canary, health check và auto-rollback

Đã đọc 0/10 mục · còn khoảng 4 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.

Đây là use case "kinh điển" và an toàn nhất để bắt đầu: agent giám sát deploy, chạy health check, và tự rollback khi phát hiện suy giảm. Rollback là hành động đảo ngược được → hợp autonomous.

Luồng deploy có agent giám sát

  • CI đẩy phiên bản mới dạng canary (5–10% traffic).
  • Agent theo dõi metric của canary trong cửa sổ quan sát (ví dụ 10 phút).
  • Agent so sánh canary vs baseline (phiên bản cũ).
  • Nếu canary khỏe → agent promote lên 100%. Nếu xấu → agent rollback ngay.

Các bước triển khai

  • Định nghĩa SLO cho phép (guardrail số học). Ví dụ: error rate canary không vượt quá 1.5× baseline, p95 latency không tăng quá 20%.
  • Viết health-check tool:
def evaluate_canary(service, window_min=10):
    base = get_metrics(f"{service}-stable", window_min)
    canary = get_metrics(f"{service}-canary", window_min)
    checks = {
        "error_rate": canary.err <= base.err * 1.5,
        "latency_p95": canary.p95 <= base.p95 * 1.2,
        "has_traffic": canary.requests >= 50,   # đủ mẫu để tin
    }
    return {"healthy": all(checks.values()), "checks": checks}
  • Logic quyết định của agent:
def supervise_deploy(service):
    result = evaluate_canary(service)
    if not result["checks"]["has_traffic"]:
        return wait_or_escalate("Chưa đủ traffic để đánh giá")
    if result["healthy"]:
        promote(service)           # đảo ngược được: có thể rollback sau
        return log("Promote canary thành công")
    else:
        rollback(service)          # đảo ngược được: an toàn
        open_incident(service, result["checks"])
        return log("Rollback do canary không đạt SLO")
  • Bắt buộc điều kiện has_traffic. Đừng promote/rollback khi mẫu quá nhỏ — dễ nhiễu thống kê. Nếu chưa đủ, agent chờ hoặc escalate.
  • Ghi lý do quyết định. Mỗi promote/rollback kèm bảng checks để người review hiểu vì sao.

Khung tư duy: quyết định canary

Đủ traffic? --No--> Chờ thêm / escalate
   |Yes
Đạt tất cả SLO? --Yes--> Promote
   |No
Rollback + mở incident + báo on-call

Ví dụ thực tế

Deploy checkout-api v2.3.1 dạng canary 10%. Sau 8 phút:

  • error_rate canary = 4.1%, baseline = 0.3% → 13× > ngưỡng 1.5×. Fail.
  • Agent rollback canary về stable, mở incident kèm log NullPointerException, báo on-call qua Slack. Người dùng gần như không cảm nhận vì chỉ 10% traffic bị ảnh hưởng trong 8 phút.

Vì sao rollback hợp autonomous

  • Đảo ngược được: stable vẫn đang chạy, rollback chỉ là chuyển traffic về.
  • Tín hiệu rõ: SLO là số, không mơ hồ.
  • Chi phí khi sai thấp: rollback nhầm chỉ mất một lần deploy, không mất dữ liệu.
Đối lập: promote lên 100% rủi ro hơn một chút — nhiều team yêu cầu agent chỉ đề xuất promote, người bấm duyệt.

Sai lầm thường gặp

  • Bỏ qua điều kiện đủ mẫu (has_traffic). Quyết định trên 3 request là đánh bạc.
  • Ngưỡng SLO tuyệt đối thay vì tương đối. "error < 1%" cứng nhắc; so với baseline mới phản ánh regression thật.
  • Cửa sổ quan sát quá ngắn. Nhiều lỗi chỉ lộ sau vài phút warm-up.
  • Rollback nhưng không dọn canary. Để lại pod canary lỗi gây rối metric lần sau.
  • Không mở incident khi rollback. Rollback là triệu chứng, không phải chữa gốc — phải có ticket điều tra.

Checklist trước khi bật auto-rollback trên production

  • [ ] SLO định nghĩa dạng tương đối so với baseline, không tuyệt đối cứng
  • [ ] Có điều kiện has_traffic (đủ mẫu) trước mọi quyết định
  • [ ] Cửa sổ quan sát đủ dài để qua giai đoạn warm-up
  • [ ] Rollback tự dọn pod canary lỗi sau khi chuyển traffic
  • [ ] Mỗi promote/rollback ghi bảng checks làm lý do
  • [ ] Rollback luôn mở incident để điều tra root cause
  • [ ] Promote lên 100% để ở chế độ require_approval (rủi ro hơn rollback)

Tích hợp vào pipeline CI/CD thực tế

Agent deploy không sống tách biệt — nó là một stage trong pipeline. Sau khi CI đẩy canary, một job gọi agent giám sát và chặn (block) pipeline cho tới khi agent kết luận:

# .gitlab-ci.yml (rút gọn)
canary_supervise:
  stage: verify
  script:
    - python -m agent.supervise_deploy --service checkout-api --window 10
  # exit code 0 = healthy -> pipeline promote; !=0 = agent đã rollback

Cách này biến agent thành một "quality gate" tự động: deploy xấu bị chặn ngay tại pipeline, không cần người canh màn hình Grafana lúc nửa đêm. Đây là điểm giao thoa đẹp nhất giữa agent và CI/CD truyền thống.

Tóm tắt

Agent deploy an toàn dựa trên canary + SLO tương đối + điều kiện đủ mẫu. Rollback tự động là ứng viên autonomous lý tưởng vì đảo ngược được và tín hiệu rõ. Luôn ghi lý do quyết định, mở incident để điều tra nguyên nhân gốc, và tích hợp agent như một quality gate ngay trong pipeline CI/CD.

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