Product Management
Đăng nhập
ESC

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

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

Bài 5 — Agent incident response: phân loại, khoanh vùng, giảm nhẹ

Đã đọ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.

Khi incident xảy ra, thứ quý nhất là thời gian. Agent incident response rút ngắn giai đoạn "hiểu chuyện gì đang xảy ra" (triage) và đề xuất/thực thi bước giảm nhẹ (mitigation) trong khi con người còn đang tỉnh dậy.

Ba pha của agent trong incident

  • Triage (phân loại): đây là gì, nghiêm trọng cỡ nào, ảnh hưởng ai.
  • Localize (khoanh vùng): service nào, do thay đổi nào, tầng nào.
  • Mitigate (giảm nhẹ): rollback, scale, feature-flag off, drain node — hành động đảo ngược được để cầm máu.
Lưu ý: agent giảm nhẹ, không chữa gốc. Root-cause fix là việc của người, sau khi hệ thống ổn định.

Các bước xây agent incident

  • Nhận và phân loại severity tự động:
def classify(alert, metrics):
    if metrics.user_facing and metrics.err_rate > 0.05:
        return "SEV1"   # ảnh hưởng người dùng, nghiêm trọng
    if metrics.err_rate > 0.02:
        return "SEV2"
    return "SEV3"
  • Khoanh vùng bằng correlation. Agent tự hỏi: có deploy gần đây không? Có alert liên quan ở service phụ thuộc không? Traffic có bất thường không (DDoS)?
  • Chọn mitigation theo cây quyết định (runbook):
Có deploy gần đây trùng thời điểm? --> Rollback
Spike traffic bất thường?          --> Scale up / bật rate-limit
Một dependency downstream chết?     --> Feature-flag tắt tính năng phụ thuộc
Một node lỗi phần cứng?            --> Drain node, reschedule pod
  • Áp dụng chính sách autonomy theo severity:
- SEV3 rủi ro thấp → agent tự mitigate. - SEV1 → agent đề xuất + gọi người ngay, không tự quyết bước lớn.

  • Mở war-room và cập nhật liên tục. Agent tạo Slack channel, đăng timeline, tag người on-call.

Ví dụ luồng SEV2

  • Alert LatencySpike trên search-api, p95 từ 200ms → 3s.
  • Agent: không có deploy gần đây → loại giả thuyết regression.
  • Agent kiểm tra dependency: elasticsearch báo circuit breaker open.
  • Agent khoanh vùng: search-api chậm vì ES quá tải.
  • Mitigation từ runbook: bật feature-flag disable_fuzzy_search (giảm tải ES), đồng thời báo on-call.
  • p95 về 400ms. Agent đăng cập nhật, giữ incident mở để người điều tra ES.

Khung tư duy: OODA cho incident

Observe (đọc alert/metric) → Orient (khoanh vùng, so runbook) → Decide (chọn mitigation theo severity + autonomy policy) → Act (thực thi hoặc escalate). Lặp lại cho tới khi ổn định.

Checklist agent incident tốt

  • [ ] Phân loại severity tự động và đúng
  • [ ] Luôn kiểm tra "có change gần đây không" đầu tiên
  • [ ] Mitigation chỉ chọn hành động đảo ngược được
  • [ ] Autonomy scale theo severity (SEV1 luôn có người)
  • [ ] Tạo war-room + timeline tự động
  • [ ] Không tuyên bố resolved khi chỉ mới mitigate

Sai lầm thường gặp

  • Agent cố chữa gốc trong lúc cháy. Nhiệm vụ lúc này là cầm máu, không phải phẫu thuật.
  • Không escalate SEV1 kịp. Hành động lớn ở SEV1 phải có người xác nhận.
  • Bỏ qua bước kiểm tra change gần đây. ~70% incident đến từ một thay đổi vừa xảy ra.
  • Đóng incident sau mitigate. Triệu chứng hết không nghĩa là nguyên nhân hết.
  • Mitigation không đảo ngược được. Đừng để agent xóa dữ liệu hay tắt vĩnh viễn thứ gì.

Ví dụ war-room tự động

Khi agent phân loại một sự cố là SEV1/SEV2, một trong những việc giá trị nhất nó làm là dựng war-room ngay để mọi người có nơi phối hợp:

def open_war_room(incident):
    channel = slack.create_channel(f"inc-{incident.id}-{incident.service}")
    slack.post(channel, f"SEV{incident.sev}: {incident.summary}")
    slack.post(channel, f"Đã thử: {incident.actions_taken}")
    slack.invite(channel, oncall_for(incident.service))
    incident.timeline_channel = channel
    return channel

Sau đó agent liên tục đăng cập nhật vào channel (metric mới, hành động vừa làm, kết quả) để timeline được ghi lại tự động — cực kỳ quý cho postmortem sau này. Không ai phải nhớ "lúc đó mình đã làm gì", vì agent đã ghi hết.

Phân biệt mitigation và resolution

Một nhầm lẫn tai hại là coi "metric đã ổn" là "đã giải quyết". Ví dụ: agent tắt feature-flag fuzzy_search làm p95 về bình thường — nhưng nguyên nhân gốc (Elasticsearch quá tải) vẫn còn nguyên. Nếu đóng incident lúc này, sự cố sẽ tái diễn ngay khi bật lại flag. Mitigation = triệu chứng hết; Resolution = nguyên nhân được sửa. Agent chỉ được phép mitigate và giữ incident mở; người xác nhận resolution.

Tóm tắt

Agent incident response = triage nhanh + khoanh vùng bằng correlation + mitigate bằng hành động đảo ngược được, với autonomy điều chỉnh theo severity. Dùng vòng OODA, luôn kiểm tra change gần đây trước, dựng war-room + timeline tự động, và nhớ: agent cầm máu (mitigate), người chữa gốc (resolve).

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