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

เริ่มจากบริการที่ธุรกิจต้องใช้

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

ปรับ Threshold และเส้นทางแจ้งเหตุ

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

ซ้อมเหตุและตรวจการส่งต่อ

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

รายการตรวจสอบก่อนนำไปใช้

  • ผูกอุปกรณ์กับบริการธุรกิจและเจ้าของ
  • ตั้งเกณฑ์ตามข้อมูลพื้นฐานและช่วงงาน
  • กำหนด Maintenance และเส้นทาง Escalation
  • ทดสอบ Alarm ถึงผู้รับและตรวจบริการหลังแก้

ตัวชี้วัดคือเหตุที่มีเจ้าของ เวลารับเรื่อง แจ้งเตือนซ้ำ และเวลาที่บริการกลับมาใช้ได้ ส่งแผนผังสาขาแบบไม่ระบุความลับให้ KTNBS เพื่อเตรียมการประเมิน Monitoring

แจ้งเตือนทุกค่าเกิน Threshold ดีหรือไม่?

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

อุปกรณ์กลับมา Online แปลว่าบริการปกติหรือไม่?

ต้องตรวจระดับบริการหรือแอปที่ธุรกิจใช้อีกขั้นหนึ่ง

ปรึกษา KTNBS และขอ Demo ตามโจทย์องค์กร ↗

แหล่งอ้างอิง