Bài 7 — On-call agent: phân loại, escalate và trực đêm

On-call là gánh nặng lớn nhất của đời DevOps: bị đánh thức lúc 3h sáng bởi alert mà 60% là nhiễu (noise). On-call agent làm lớp lọc và phản ứng đầu tiên (first responder), chỉ đánh thức người khi thật cần.

Vai trò của on-call agent

• Lọc nhiễu (deduplicate & suppress): gộp alert trùng, dập alert đã biết là nhiễu.
• Tự xử việc quen thuộc: chạy runbook cho các alert lặp lại, rủi ro thấp.
• Escalate đúng người, đúng lúc: khi vượt khả năng, đánh thức người với đầy đủ context.

Cây quyết định on-call

Alert đến
  |
  ├─ Trùng alert đang mở? --> Gộp, không tạo mới
  ├─ Trong danh sách known-noise? --> Suppress, chỉ log
  ├─ Có runbook tự động? --> Chạy runbook
  │     ├─ Giải quyết xong? --> Đóng, log, KHÔNG đánh thức người
  │     └─ Không xong? --> Escalate kèm những gì đã thử
  └─ Không có runbook / SEV1? --> Escalate người ngay

Các bước triển khai

• Xây bảng dedup theo fingerprint. Cùng service + cùng loại lỗi trong cửa sổ thời gian → một incident:

def fingerprint(alert):
    return f"{alert.service}:{alert.type}"

def should_page(alert, open_incidents):
    fp = fingerprint(alert)
    if fp in open_incidents:
        open_incidents[fp].count += 1
        return False          # đã có người/agent xử lý
    return True

• Duy trì danh sách known-noise có thời hạn. Alert DiskUsage trên node test luôn nhiễu → suppress, nhưng có expiry để không mù vĩnh viễn.

• Thử runbook trước khi page. Agent chạy mitigation tự động; chỉ escalate nếu thất bại.

• Escalate kèm "context pack". Khi phải đánh thức người, gửi gói: alert, những gì agent đã thử, kết quả, giả thuyết. Người vào việc trong 30 giây thay vì 15 phút.

{
  "summary": "checkout-api 5xx 12%, nghi regression v2.3.1",
  "tried": ["rollback canary -> vẫn lỗi", "restart pod -> không đổi"],
  "hypothesis": "DB connection pool cạn",
  "next_suggested": "tăng pool size hoặc rollback full",
  "links": ["grafana...", "logs..."]
}

• Tôn trọng escalation policy. Sau N phút không ai ack → agent leo lên người tiếp theo/manager.

Khung tư duy: agent là bộ lọc, không phải bức tường

Mục tiêu KHÔNG phải chặn mọi alert khỏi con người — mà là giảm alert vô ích, tăng chất lượng alert thật. Một agent dập nhầm alert nghiêm trọng còn tệ hơn không có agent. Khi nghi ngờ → escalate (fail toward human).

Ví dụ đêm trực

02:14 — HighErrorRate checkout-api. Agent: không trùng, không known-noise, có runbook. Chạy rollback canary → error vẫn cao. Agent thử restart pod → không đổi. Vượt runbook → escalate on-call kèm context pack "nghi DB pool cạn". Kỹ sư dậy, đọc gói 20 giây, tăng pool size, hết lỗi. Tổng thời gian người bị chiếm: 5 phút thay vì cả tiếng dò từ đầu.

Sai lầm thường gặp

• Suppress quá tay. Danh sách known-noise không có expiry → agent mù trước sự cố thật.
• Escalate mà không kèm context. Người bị dựng dậy vẫn phải điều tra từ số 0 — mất luôn giá trị agent.
• Không tôn trọng escalation policy. Agent "cố tự xử" trong khi không ai được báo là cực kỳ nguy hiểm.
• Dedup theo ID thay vì fingerprint. Cùng sự cố nhưng khác alert ID vẫn page nhiều lần.
• Không fail toward human. Khi bất định, agent im lặng thay vì báo — che giấu incident.

Đo hiệu quả on-call agent

Để biết agent thật sự giúp ích hay chỉ tạo cảm giác an tâm giả, hãy theo dõi vài con số cụ thể mỗi tuần:

• Alert-to-page ratio: trong 100 alert, bao nhiêu thật sự đánh thức người? Tỷ lệ này càng giảm (một cách an toàn) càng tốt.
• Escalation precision: khi agent page, bao nhiêu % thật sự cần người? Thấp nghĩa là agent "kêu cứu" thừa.
• Missed incident: có sự cố thật nào bị agent suppress nhầm không? Đây là con số PHẢI bằng 0 hoặc rất gần 0.
• Số đêm on-call không bị đánh thức: chỉ số hạnh phúc con người.

Nếu alert-to-page giảm mà missed-incident vẫn 0, agent đang làm đúng việc: cắt nhiễu mà không cắt tín hiệu thật.

Vì sao 'fail toward human' là mặc định

Khi agent gặp tình huống bất định — không có runbook, không rõ severity, tín hiệu mâu thuẫn — lựa chọn an toàn luôn là escalate người, dù có thể gây phiền. Lý do: chi phí của một lần đánh thức nhầm (người mất 10 phút) nhỏ hơn nhiều so với chi phí một incident nghiêm trọng bị agent âm thầm bỏ qua (mất dữ liệu, downtime kéo dài, mất niềm tin khách hàng). Thiết kế agent để nghiêng về phía an toàn, không phải phía im lặng.

Tóm tắt

On-call agent là first responder: lọc nhiễu, tự xử việc quen, và escalate đúng người kèm context pack. Nó là bộ lọc chứ không phải bức tường — khi nghi ngờ luôn nghiêng về đánh thức người (fail toward human). Đo bằng alert-to-page ratio và missed-incident, và làm đúng, nó trả lại cho team những đêm ngủ yên.