วิธีสร้างหน้าสถานะระบบ: คอมโพเนนต์ เหตุการณ์ และการตรวจ uptime

หน้าสถานะระบบบอกผู้ใช้ของคุณในที่เดียวว่าบริการของคุณทำงานอยู่หรือไม่ การสร้างหน้านี้ต้องมีรายการคอมโพเนนต์ (เว็บไซต์ API การชำระเงิน อีเมล) สถานะปัจจุบันของแต่ละตัว เหตุการณ์พร้อมการอัปเดตที่มีเวลากำกับ ประวัติเหตุการณ์ที่ผ่านมา และการสมัครรับการแจ้งเตือนเป็นตัวเลือกเสริม ตัวหน้าเองเรียบง่าย แต่การตัดสินใจที่สำคัญคือ “จะรันที่ไหน” หน้าสถานะระบบต้องยังทำงานได้แม้แอปของคุณล่ม จึงไม่ควรใช้โฮสติ้ง ฐานข้อมูล หรือ pipeline การดีพลอยชุดเดียวกับสิ่งที่มันรายงาน

หน้าสถานะระบบมีไว้ทำอะไร

เมื่อมีบางอย่างพัง ผู้ใช้อยากรู้สามเรื่อง คือ เป็นปัญหาเฉพาะฉันหรือเปล่า คุณรู้เรื่องนี้แล้วหรือยัง และจะแก้เสร็จเมื่อไร หน้าสถานะระบบตอบได้ทั้งสามข้อโดยไม่ต้องมีตั๋วซัพพอร์ตถล่มเข้ามา และเมื่อเวลาผ่านไป ประวัติเหตุการณ์ที่เห็นได้ชัดพร้อมบันทึกที่ตรงไปตรงมาก็สร้างความไว้วางใจ เพราะแสดงให้เห็นว่าคุณรับมือกับปัญหาอย่างไร

มันไม่ใช่บันทึกการเปลี่ยนแปลง (changelog) ฟีเจอร์ใหม่ไปอยู่ที่หน้า changelog ส่วนการขัดข้องและการบำรุงรักษาอยู่ที่นี่

หน้านี้ต้องมีอะไรบ้าง

ข้อมูล

สถานะของคอมโพเนนต์มักเป็นรายการคงที่สั้นๆ คือ Operational (ทำงานปกติ), Degraded performance (ประสิทธิภาพลดลง), Partial outage (ใช้งานได้บางส่วน), Major outage (ล่มทั้งหมด) และ Under maintenance (อยู่ระหว่างบำรุงรักษา)

หน้าต่างๆ

• หน้าสถานะสาธารณะ: แบนเนอร์ภาพรวม (“ทุกระบบทำงานปกติ” หรือสถานะที่แย่ที่สุดในขณะนั้น) คอมโพเนนต์แต่ละตัวพร้อมสถานะ เหตุการณ์ที่กำลังเกิดขึ้นพร้อมการอัปเดต การบำรุงรักษาที่กำลังจะมาถึง และแถบประวัติ 90 วันหากคุณมีข้อมูลการตรวจสอบ
• หน้าเหตุการณ์: ไทม์ไลน์การอัปเดตทั้งหมดของเหตุการณ์หนึ่ง พร้อม URL ของตัวเอง เพื่อให้ฝ่ายซัพพอร์ตส่งลิงก์ได้
• ประวัติ: เหตุการณ์ที่ผ่านมาแยกตามเดือน
• ติดตาม: สมัครรับอีเมลพร้อมการยืนยัน และตั้งค่ารับการแจ้งเตือนรายคอมโพเนนต์
• แอดมิน: สร้างเหตุการณ์ โพสต์อัปเดต เปลี่ยนสถานะคอมโพเนนต์ และกำหนดเวลาบำรุงรักษา

สิทธิ์การเข้าถึง

ทุกคนเห็นสิ่งที่เผยแพร่ มีเพียงทีมของคุณเท่านั้นที่โพสต์ได้ ถ้าทำได้ ให้แยกการล็อกอินของแอดมินออกจากระบบล็อกอินหลักของแอป เพื่อว่าเมื่อผู้ให้บริการยืนยันตัวตนล่ม คุณจะไม่ถูกล็อกออกจากหน้าสถานะระบบของตัวเอง

การตัดสินใจสำคัญ: ทำให้มันเป็นอิสระ

นี่คือจุดที่หน้าสถานะระบบที่สร้างเองมักพลาด ถ้าหน้าสถานะระบบของคุณ:

• รันบนเซิร์ฟเวอร์หรือบัญชีโฮสติ้งเดียวกับแอป
• อ่านจากฐานข้อมูลเดียวกัน
• อยู่หลังการตั้งค่าโดเมนหรือ CDN เดียวกัน
• หรือถูกดีพลอยผ่าน pipeline เดียวกัน

การขัดข้องหลายครั้งก็จะดึงมันลงไปด้วย ในช่วงเวลาที่ผู้คนต้องการมันมากที่สุด ขั้นตอนที่ควรทำ:

• โฮสติ้งแยกต่างหาก โปรเจกต์หรือผู้ให้บริการคนละเจ้ากับแอปหลัก
• ซับโดเมนของตัวเอง เช่น status.example.com ชี้ DNS แยกต่างหาก ดูวิธีการทำงานของโดเมนและ DNS
• ข้อมูลของตัวเอง เหตุการณ์เก็บในที่เก็บข้อมูลของหน้าสถานะระบบ ไม่ใช่ฐานข้อมูลของแอป
• หน้าสำรองแบบ static ทีมบางทีมทำให้หน้าสาธารณะเป็น static แล้วสร้างใหม่ทุกครั้งที่มีการอัปเดต จึงมีอะไรให้พังน้อยมาก

อัปเดตด้วยมือหรือตรวจอัตโนมัติ

ด้วยมือ (เริ่มตรงนี้)

ทีมของคุณโพสต์เหตุการณ์และเปลี่ยนสถานะคอมโพเนนต์ด้วยมือจากหน้าแอดมิน หลายหน้าสถานะระบบทำงานแบบนี้ในทางปฏิบัติ เพราะการตัดสินใจของคนอย่าง “การชำระเงินบางประเภทช้า” มีประโยชน์กว่าจุดสีแดงอัตโนมัติ

เพื่อรู้เรื่องปัญหาให้เร็ว ใช้ตัวตรวจ uptime จากภายนอกที่ตรวจแอปของคุณทุกๆ หนึ่งนาทีโดยประมาณ และแจ้งเตือนทางอีเมล SMS หรือแชต บริการตรวจสอบหลายรายมีแพ็กเกจฟรี

อัตโนมัติ

การทำงานอัตโนมัติหมายถึงมีบางอย่างตรวจแต่ละคอมโพเนนต์เป็นประจำและอัปเดตสถานะ ต้องมีโค้ดที่รันตามตารางเวลาจากภายนอกโครงสร้างหลักของแอป มีสองรูปแบบที่พบบ่อย:

• ตัวตรวจภายนอกเรียกหน้าสถานะระบบของคุณผ่านwebhook เมื่อการตรวจล้มเหลวหรือกลับมาปกติ แล้วหน้าสถานะระบบจะอัปเดตคอมโพเนนต์นั้น
• งานตามกำหนดเวลา ในโฮสติ้งของหน้าสถานะระบบเอง ที่ ping แต่ละคอมโพเนนต์และบันทึกผล ตรวจสอบว่าโฮสติ้งของคุณจัดการงานตามเวลาอย่างไรก่อนพึ่งพามัน คู่มือเรื่องการรันงานเบื้องหลังอธิบายตัวเลือกต่างๆ

การเปลี่ยนสถานะอัตโนมัติอาจกระพริบ (ขึ้น ลง ขึ้น) เมื่อเครือข่ายช้า ให้ต้องล้มเหลวสองถึงสามครั้งก่อนเปลี่ยนสถานะ และให้คนยืนยันก่อนประกาศการขัดข้องระดับรุนแรง

การเขียนอัปเดตเหตุการณ์

• โพสต์ให้เร็ว “เรากำลังตรวจสอบรายงานการเข้าสู่ระบบไม่สำเร็จ” ภายในไม่กี่นาที ดีกว่าข้อความที่สมบูรณ์แบบอีกหนึ่งชั่วโมงต่อมา
• บอกสิ่งที่ผู้ใช้สังเกตเห็น ไม่ใช่สิ่งที่พังภายใน
• สัญญาเวลาของการอัปเดตครั้งถัดไป แล้วทำให้ได้
• ปิดด้วยสรุปสั้นๆ เมื่อแก้ไขเสร็จ: เกิดอะไรขึ้น นานเท่าไร และคุณกำลังจะเปลี่ยนอะไร

พรอมต์แรกที่ใช้ได้จริง

สร้างหน้าสถานะระบบแบบ standalone สำหรับแอป Parcelio ของเรา โดยโฮสต์แยกต่างหากที่ status.parcelio.com คอมโพเนนต์: Website, Tracking API, Notifications, Payments แต่ละตัวมีสถานะเป็น Operational, Degraded performance, Partial outage, Major outage หรือ Under maintenance หน้าสาธารณะแสดงแบนเนอร์ภาพรวมโดยใช้สถานะที่แย่ที่สุดในขณะนั้น คอมโพเนนต์แต่ละตัวพร้อมสถานะ เหตุการณ์ที่กำลังดำเนินอยู่พร้อมการอัปเดตที่มีเวลากำกับเรียงจากใหม่ไปเก่า การบำรุงรักษาที่กำลังจะมาถึง และรายการเหตุการณ์ที่ผ่านมาแยกตามเดือน เหตุการณ์แต่ละรายการมีหน้าของตัวเอง เพิ่มหน้าแอดมินที่มีรหัสผ่านเพื่อสร้างเหตุการณ์ (หัวข้อ ระดับผลกระทบ คอมโพเนนต์ที่เกี่ยวข้อง) โพสต์อัปเดต (ข้อความและสถานะ: Investigating, Identified, Monitoring, Resolved) เปลี่ยนสถานะคอมโพเนนต์ และกำหนดเวลาบำรุงรักษา เพิ่ม endpoint POST /api/check-result ที่รับชื่อคอมโพเนนต์และ up/down จากตัวตรวจภายนอก ป้องกันด้วยโทเคนลับ และตั้งสถานะเป็น Degraded เฉพาะเมื่อ down ติดกันสามครั้ง เก็บทุกอย่างในฐานข้อมูลของแอปนี้ ดีไซน์เรียบง่าย สงบ และโหลดเร็วบนโทรศัพท์

ขั้นตอนการสร้าง

1. หน้าสาธารณะและแอดมินที่มีเหตุการณ์แบบแมนนวล เท่านี้ก็เป็นหน้าสถานะระบบที่ใช้งานได้แล้ว
2. โฮสต์แยกต่างหาก และชี้ซับโดเมนมาที่นั่น
3. หน้าเหตุการณ์และประวัติ
4. ช่วงบำรุงรักษา
5. การติดตาม การสมัครด้วยอีเมลแบบยืนยันสองชั้น และการแจ้งเตือนเมื่อมีเหตุการณ์หรืออัปเดตใหม่ ต้องใช้ผู้ให้บริการอีเมล ดูวิธีส่งอีเมลจากแอปของคุณ
6. Webhook ของตัวตรวจ หากต้องการการเปลี่ยนสถานะอัตโนมัติ
7. ซ้อมทดสอบ สร้างเหตุการณ์ปลอม โพสต์อัปเดต ปิดเหตุการณ์ ตรวจอีเมล แล้วลบ

ข้อผิดพลาดที่พบบ่อย

• โฮสต์ไว้กับแอป เป็นข้อผิดพลาดที่พบบ่อยและร้ายแรงที่สุด
• หน้าที่แสดง “ทุกระบบทำงานปกติ” ตลอดเวลา ถ้าไม่เคยแสดงปัญหาเลย ผู้ใช้จะหยุดเชื่อถือ
• ไม่มีเวลากำกับหรือเขตเวลา ควรแสดงเวลาพร้อมเขตเวลาเสมอ
• พึ่งการล็อกอินของแอปหลักสำหรับหน้าแอดมิน
• เงียบระหว่างการอัปเดต “ยังไม่มีการเปลี่ยนแปลง ยังคงแก้ไขอยู่” เป็นการอัปเดตที่ใช้ได้
• สถานะอัตโนมัติที่กระพริบ ให้ต้องล้มเหลวซ้ำๆ ก่อนเปลี่ยนสถานะ

เมื่อบริการหน้าสถานะระบบสำเร็จรูปเป็นตัวเลือกที่ดีกว่า

บริการหน้าสถานะระบบสำเร็จรูปออกแบบมาเพื่อแก้ปัญหาเรื่องความเป็นอิสระโดยเฉพาะ มันรันบนโครงสร้างพื้นฐานแยกต่างหาก จัดการการแจ้งเตือนผู้ติดตามทางอีเมลและ SMS และมักมีการตรวจสอบและการเชื่อมต่อกับเครื่องมือจัดการเหตุการณ์ ถ้า uptime เป็นส่วนหนึ่งของสิ่งที่ลูกค้าจ่ายเงิน หรือคุณมีภาระผูกพันตามสัญญาในการรายงานเหตุการณ์ บริการเฉพาะทางมักคุ้มค่า หลายรายมีแพ็กเกจฟรีหรือราคาต่ำสำหรับทีมเล็ก จึงควรตรวจสอบก่อนสร้างเอง

สร้างเองเมื่อคุณต้องการควบคุมดีไซน์และถ้อยคำเต็มที่ เมื่อความต้องการเรียบง่าย (คอมโพเนนต์ไม่กี่ตัว อัปเดตด้วยมือ) หรือเมื่อหน้าสถานะระบบเป็นส่วนหนึ่งของผลิตภัณฑ์ที่คุณสร้างให้ผู้อื่น

การสร้างด้วย Mythex

ใน Mythex คุณสร้างหน้าสถานะระบบเป็นโปรเจกต์ของตัวเอง แยกจากแอปหลัก ซึ่งทำให้ได้โฮสติ้งแยกและฐานข้อมูลของตัวเอง อธิบายในแชท ตรวจดูในพรีวิวสด แล้วเผยแพร่ จากนั้นเชื่อมซับโดเมนเช่น status.yourdomain.com (โดเมนกำหนดเองอยู่ในแพ็กเกจ Pro) โปรดทราบว่าแอปและฐานข้อมูลที่เผยแพร่ของ Mythex จะหลับเมื่อไม่ได้ใช้งานและตื่นเมื่อมีผู้เข้าชมครั้งถัดไป การโหลดครั้งแรกหลังช่วงเงียบอาจช้ากว่า หน้าที่เรียบง่ายและเบาช่วยได้

Mythex ยังไม่ได้บันทึกเรื่องงานตามกำหนดเวลา ดังนั้นสำหรับการตรวจอัตโนมัติ ให้ใช้ตัวตรวจ uptime จากภายนอกที่เรียก endpoint webhook ในหน้าสถานะระบบของคุณ (ดูสูตร webhooks) อีเมลแจ้งผู้ติดตามผ่านผู้ให้บริการของคุณเอง โดยเก็บคีย์เป็น secret ของโปรเจกต์ (สูตรส่งอีเมล)

คำถาม