ไอเดีย #68: ระบบ Status Page และตรวจ uptime

เคยไหมครับ ลูกค้าโทรมาบอกว่า "เว็บเข้าไม่ได้ตั้งแต่เมื่อเช้า" แล้วเราเพิ่งรู้ตอนนั้น ทั้งที่ระบบล่มมาหลายชั่วโมงแล้ว สำหรับฟรีแลนซ์หรือทีมเล็กที่ดูแลเว็บลูกค้าหลายสิบเว็บ การมีระบบตรวจ uptime ที่แจ้งเตือนทันที พร้อม Status Page ให้ลูกค้าเข้ามาดูเองว่าระบบปกติหรือกำลังแก้ไข จะช่วยลดทั้งความเสียหายและสายโทรศัพท์ได้เยอะ แถมเป็นโปรเจกต์ที่ทำแล้วได้ใช้เองทุกวัน

ใครจะใช้

• นักพัฒนา/DevOps — ตั้งค่า endpoint ที่ต้องตรวจ รับแจ้งเตือน บันทึก incident
• ผู้ดูแลโปรเจกต์ — เขียนประกาศ incident และ maintenance
• ลูกค้า/ผู้ใช้ปลายทาง — เปิด status page ดูสถานะและประวัติ

ฟีเจอร์ขั้นต่ำ (MVP)

• เพิ่ม monitor: HTTP(S) URL, method, status code ที่คาดหวัง, keyword ที่ต้องเจอใน response, timeout, ความถี่
• ตรวจ TCP port และวันหมดอายุของ SSL certificate
• Worker ตรวจตามรอบ เก็บ response time และผลลัพธ์
• ยืนยันว่าล่มจริงด้วยการตรวจซ้ำก่อนแจ้ง (กัน false alarm)
• แจ้งเตือนเมื่อล่มและเมื่อกลับมา ผ่าน LINE, อีเมล หรือ webhook
• Status page สาธารณะ แสดงแต่ละบริการ uptime ย้อนหลัง และ incident ที่เกิดขึ้น
• สร้าง/อัปเดต incident แบบ timeline: investigating → identified → monitoring → resolved

ต่อยอดได้อีก

• ตรวจจากหลายตำแหน่ง (multi-region) แล้วโหวตว่าล่มจริงไหม
• Heartbeat monitor สำหรับ cron job: ถ้าไม่ ping เข้ามาตามเวลาให้แจ้งเตือน
• ประกาศ maintenance ล่วงหน้าและปิดการแจ้งเตือนชั่วคราว
• ให้ผู้ใช้กด subscribe รับข่าว incident

โครงข้อมูลตั้งต้น

• monitor — id, project_id, name, type, target, interval_sec, timeout_ms, expected_status, keyword, is_paused
• check_result — monitor_id, checked_at, is_up, status_code, response_ms, error
• incident — id, project_id, title, status, impact, started_at, resolved_at
• incident_update — id, incident_id, status, message, created_at
• notify_channel — id, project_id, type, config_json

ระดับความยาก และสิ่งที่จะได้เรียนรู้

ปานกลาง

• ออกแบบ scheduler/worker ที่ตรวจหลายร้อย endpoint พร้อมกันโดยไม่ทับกัน (queue + concurrency)
• คำนวณ uptime เปอร์เซ็นต์จากข้อมูลจำนวนมาก และทำ rollup รายชั่วโมง/รายวัน
• จัดการ state ขึ้น-ลง เพื่อไม่ให้แจ้งเตือนซ้ำรัว ๆ
• ทำหน้า status page ที่เบาและ cache ได้

ข้อควรระวัง

• ตัวระบบตรวจไม่ควรอยู่บนเซิร์ฟเวอร์เดียวกับเว็บที่ถูกตรวจ ไม่อย่างนั้นล่มพร้อมกันก็ไม่มีใครแจ้ง
• ถ้าให้ผู้ใช้ใส่ URL ได้อิสระ ต้องกัน SSRF ไม่ให้ยิงเข้า IP ภายในหรือ metadata ของ cloud
• status page ไม่ควรเปิดเผยรายละเอียดภายใน เช่น IP เซิร์ฟเวอร์ หรือ error message ดิบ

ตอนนี้แต่ละคนใช้อะไรตรวจ uptime เว็บลูกค้ากันอยู่ครับ แล้วอะไรที่ยังขาดไปสำหรับการใช้งานแบบไทย ๆ? อีกเรื่องคือ ควรตรวจทุกกี่วินาทีถึงจะสมดุลระหว่างความไวกับภาระเซิร์ฟเวอร์ มาคุยกัน ใครทำเสร็จแล้วแปะ status page มาอวดในกระทู้ได้เลย