🧭 Phần 4: Escalation & Quản lý đa nguồn Alert

🔔 Vấn đề thực tế

• Mỗi hệ thống có công cụ giám sát riêng (Prometheus, Datadog, ELK...)
• Alert gửi tới nhiều kênh: Email, Slack, PagerDuty, vs...
• Nếu không quản lý đúng cách → alert bị bỏ sót, trễ phản hồi

🎯 Mục tiêu chương này

• Tích hợp nhiều nguồn cảnh báo về một luồng thống nhất
• Thiết lập chính sách Escalation rõ ràng
• Đảm bảo alert đến đúng người – đúng thời điểm – đúng kênh

🔄 Quy trình Escalation là gì?

Escalation = chuỗi các bước gửi alert → leo thang nếu chưa được xử lý trong thời gian cho phép

Ví dụ:

Alert → Gửi on-call 1 (15 phút)
   ↓ Nếu không phản hồi
→ Gửi on-call 2 hoặc leader (30 phút)
   ↓ Nếu vẫn không phản hồi
→ Ping team lead hoặc call điện thoại

🧠 Các thành phần chính của Escalation Policy

🌐 Kết nối đa nguồn Alert

Tất cả route về một trung tâm alert (như Alertmanager, Opsgenie...)

✅ Checklist Escalation & Alert Routing

• Có chính sách escalation rõ ràng theo từng mức độ sự cố
• Mỗi alert đều có chủ sở hữu (team hoặc role)
• Tích hợp được đa nguồn alert (Prometheus, Datadog...)
• Có retry hoặc fallback nếu alert không gửi được
• Có thống kê phản hồi: alert nào phản hồi chậm?
• Có log mọi hành động alert: gửi lúc nào, tới ai

📦 Mô hình Escalation và Alert Routing

    [Prometheus]     [Datadog]     [CloudWatch]
          ↓               ↓               ↓
      ┌───────────────────────────────┐
      │       Alert Router (vs-incident / Opsgenie)       │
      └───────────────────────────────┘
                    ↓
        [On-call Primary] → [Escalation Target 1] → [Leader]

🔧 Công cụ hỗ trợ

• Prometheus Alertmanager
• Opsgenie, PagerDuty
• versus-incident (tool minh hoạ trong sách)
• VictorOps, ElastAlert (ELK)

📌 Kết luận: Escalation đúng cách + tích hợp alert đa nguồn giúp giảm missed alert, đảm bảo on-call phản ứng nhanh và hiệu quả.

Chương tiếp theo sẽ trình bày cách đo lường độ tin cậy qua SLI/SLO/Error Budget 📊