Alert Management เป็นหัวใจของการทำ on-call ที่ดี — แค่ส่งการแจ้งเตือนเข้า email หรือ Slack ยังไม่พอ เพราะเมื่อมีหลาย service หลายทีม notification จะท่วมท้นจนทีมเริ่มเบื่อหน่าย (alert fatigue) และพลาดเหตุการณ์สำคัญ PagerDuty และ Opsgenie เป็น platform ที่ออกแบบมาสำหรับ on-call rotation โดยเฉพาะ มี escalation policy, schedule, และ integration กับเครื่องมือ monitoring ยอดนิยมครบถ้วน

บทความนี้จะอธิบายแนวคิดของ on-call rotation ฟีเจอร์สำคัญของ PagerDuty และ Opsgenie การตั้งค่า escalation policy ที่ดี พร้อมตัวอย่างการ integrate กับ Prometheus Alertmanager เพื่อให้การจัดการ incident ในทีมเป็นระบบและมีประสิทธิภาพ

ทำไมต้องใช้ On-Call Platform แยก

การส่งการแจ้งเตือนผ่าน email หรือ Slack มีข้อจำกัดหลายข้อ email อาจไปค้างใน spam, Slack notification ปิดเงียบได้ง่าย ไม่มีการ escalate อัตโนมัติเมื่อไม่มีคนรับ และไม่รองรับ rotation ตามเวลา on-call platform ช่วยแก้ปัญหาเหล่านี้ด้วยการโทรศัพท์/SMS/push notification ไปยังคนที่รับผิดชอบ และ escalate ไปคนถัดไปหากไม่มี acknowledge ภายในเวลาที่กำหนด

• Guaranteed delivery — โทรศัพท์ + SMS + push notification พร้อมกัน ไม่พลาดแน่นอน
• Escalation Policy — ถ้าคน primary ไม่รับ 5 นาที ระบบจะส่งต่อ secondary โดยอัตโนมัติ
• On-Call Schedule — ตั้งตาราง rotation ได้เป็นสัปดาห์/เดือน พร้อม handoff อัตโนมัติ
• Incident Timeline — เก็บ log การตอบสนอง ใช้ทำ postmortem ภายหลังได้
• Integration — รองรับ Prometheus, Datadog, New Relic, CloudWatch, Zabbix, ฯลฯ

PagerDuty: ฟีเจอร์หลัก

PagerDuty เป็นผู้นำตลาด on-call platform มาตั้งแต่ปี 2009 มีโมเดลที่เรียกว่า “Service” ซึ่งเป็นกลุ่มของ incident ที่มาจาก monitoring system เดียวกัน โดยแต่ละ Service จะผูกกับ Escalation Policy ที่กำหนดว่า event จะถูกส่งไปหาใครก่อน หลังและนานเท่าไรจึงจะ escalate

การสร้าง Service ใน PagerDuty เริ่มจาก Services → New Service → เลือก Integration Type (Prometheus, Datadog, ฯลฯ) → กำหนด Escalation Policy → ได้ Integration Key (หรือ URL) ที่ใช้ config ฝั่ง monitoring system

# ตัวอย่าง Alertmanager config ส่ง alert ไปยัง PagerDuty
receivers:
  - name: pagerduty-critical
    pagerduty_configs:
      - routing_key: 'YOUR_INTEGRATION_KEY_HERE'
        severity: '{{ .CommonLabels.severity }}'
        description: '{{ .CommonAnnotations.summary }}'
        details:
          firing: '{{ .Alerts.Firing | len }}'
          cluster: '{{ .CommonLabels.cluster }}'
          alertname: '{{ .CommonLabels.alertname }}'

Opsgenie: ทางเลือกจาก Atlassian

Opsgenie เป็น platform เดียวกันในตระกูล Atlassian (Jira, Confluence) มีจุดเด่นที่ราคาถูกกว่า PagerDuty พอสมควร และ integration กับ Jira Service Management ดีมาก เหมาะกับทีมที่ใช้ Atlassian ecosystem อยู่แล้ว แนวคิดใกล้เคียงกัน มี Team, Schedule, Escalation, Integration

# Alertmanager config ส่ง alert ไปยัง Opsgenie
receivers:
  - name: opsgenie-critical
    opsgenie_configs:
      - api_key: 'YOUR_API_KEY'
        message: '{{ .CommonAnnotations.summary }}'
        priority: '{{ if eq .CommonLabels.severity "critical" }}P1{{ else }}P3{{ end }}'
        tags: '{{ .CommonLabels.alertname }}'
        responders:
          - name: 'sre-team'
            type: 'team'

ออกแบบ Escalation Policy ที่ดี

Escalation policy คือกฎที่กำหนดว่า incident จะถูกส่งต่ออย่างไรเมื่อไม่มีคนรับ ตัวอย่าง 3-tier escalation ที่ทีม SRE ส่วนใหญ่นิยมใช้

• Level 1 (0-5 นาที) — ส่งไปยัง primary on-call engineer โทร + SMS + push
• Level 2 (5-15 นาที) — ส่งไปยัง secondary on-call ถ้า primary ไม่ acknowledge
• Level 3 (15+ นาที) — ส่งไปยัง manager หรือ entire team ถ้ายังไม่มีคนรับ

ควรตั้งเวลา escalation ให้สมเหตุสมผล ถ้าสั้นเกินไปจะ escalate ก่อนคนจะกดรับทัน ถ้านานเกินไปจะล่าช้าเกินไปกว่า notification จะถึงคนต่อไป 5-10 นาทีเป็นค่ามาตรฐานที่ใช้ได้ดีในกรณีส่วนใหญ่

On-Call Schedule และ Rotation

Rotation ที่ดีควรคำนึงถึงภาระของคนในทีม รูปแบบที่นิยมใช้ได้แก่

• Weekly Rotation — เปลี่ยนทุกสัปดาห์ วันจันทร์ 9:00 am เหมาะกับทีมเล็ก 3-5 คน
• Follow-the-Sun — แบ่งตามโซนเวลา EU/Asia/Americas ทำให้ไม่มีใครต้องตื่นกลางดึก เหมาะกับบริษัทข้ามชาติ
• Primary + Secondary — มีคน primary รับเหตุการณ์หลัก และ secondary สำรอง เพื่อลด burnout
• Weekday + Weekend แยก — บางคนอาจชอบรับ shift weekend เพื่อแลกกับการพักวันธรรมดา

Alert Routing และ Severity

ไม่ใช่การแจ้งเตือนทุกตัวควรปลุกคนกลางดึก ควรแบ่ง severity ให้ชัดเจนและ route ตาม priority

Severity	ตัวอย่าง	Notification	เวลาที่ควรตอบสนอง
P1 / Critical	service ล่ม, database down	โทร + SMS + push ทันที	< 5 นาที
P2 / High	latency สูงผิดปกติ, error rate เพิ่ม	push + Slack	< 15 นาที
P3 / Medium	disk ใกล้เต็ม 80%, memory สูง	Slack เท่านั้น	ในชั่วโมงงาน
P4 / Low	informational, reminder	email	ดูเมื่อสะดวก

Integration กับ Prometheus Alertmanager

ตัวอย่างการ route alert จาก Alertmanager ไปยัง on-call platform ตาม severity

route:
  receiver: 'default'
  group_by: ['alertname', 'cluster']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty-critical'
      continue: true
    - match:
        severity: warning
      receiver: 'slack-warnings'

receivers:
  - name: 'default'
    slack_configs:
      - api_url: 'SLACK_WEBHOOK_URL'
  - name: 'pagerduty-critical'
    pagerduty_configs:
      - routing_key: 'PD_KEY'
  - name: 'slack-warnings'
    slack_configs:
      - api_url: 'SLACK_WEBHOOK_URL'
        channel: '#alerts-warnings'

Postmortem และ Incident Review

ทั้ง PagerDuty และ Opsgenie เก็บ timeline ของทุก incident ไว้โดยอัตโนมัติ ตั้งแต่เวลาที่เหตุการณ์เข้า เวลา acknowledge เวลา resolve และใครทำอะไรบ้าง ข้อมูลนี้สำคัญมากสำหรับการทำ blameless postmortem เพื่อเรียนรู้จาก incident และปรับปรุงระบบในระยะยาว

สรุป

การมี on-call platform เช่น PagerDuty หรือ Opsgenie ช่วยให้การจัดการ incident เป็นระบบ ลด fatigue และมั่นใจได้ว่าเหตุการณ์สำคัญจะถึงคนที่รับผิดชอบเสมอ การออกแบบ escalation policy, schedule, และ severity routing ให้เหมาะสมเป็นกุญแจสำคัญที่ทำให้ทีมทำงานได้ยั่งยืนในระยะยาวโดยไม่ burnout

สำหรับทีมที่เริ่มต้น Opsgenie มีแผน Free ที่รองรับ 5 users และ integration พื้นฐานฟรี ส่วน PagerDuty มี Free tier 5 users ในบาง feature — ทดลองใช้ดูก่อนตัดสินใจว่าเหมาะกับ workflow ของทีมมากกว่า