ระบบมอนิเตอร์โรงงาน 2026 | เวลาที่รู้ตัวกำหนดความเสียหาย

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

ความเสียหายจากปัญหาไอทีในโรงงานเกิดจากการรู้ตัวช้า มากกว่าการที่เหตุนั้นเกิดขึ้น

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

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

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

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

ในงานสำรวจที่ทำกับองค์กรขนาดใหญ่ มีการรายงานความเสียหายเป็นเงินจำนวนมากต่อการหยุดระบบ 1 ชั่วโมง และ Cost of IT Downtime ของ OutageCost.com ก็อ้างอิงผลสำรวจของ ITIC และ Uptime Institute ในทำนองเดียวกัน อย่างไรก็ตาม ตัวเลขเหล่านั้นมาจากองค์กรขนาดใหญ่ที่มีศูนย์กลางอยู่ในสหรัฐอเมริกา จึงนำมาทาบกับโรงงานญี่ปุ่นขนาดกลางในประเทศไทยตรง ๆ ไม่ได้ ทั้งโครงสร้างอุตสาหกรรมและขนาดของธุรกรรมที่ได้รับผลกระทบเมื่อระบบหยุดนั้นต่างกัน บทความนี้จึงอ้างถึงงานสำรวจเหล่านั้นเพียงในฐานะข้อมูลประกอบบริบทว่า “ในองค์กรขนาดใหญ่ก็มีผลสำรวจในระดับนี้อยู่” และไม่นำมาใช้ในการประมาณการของกรณีตัวอย่างเลยแม้แต่น้อย ความเสียหายของโรงงานตัวเองต้องคำนวณจากเงื่อนไขของโรงงานตัวเอง

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

ระบบมอนิเตอร์คืออะไร – แบ่งเป็น 3 ประเภท คือ การมีชีวิต ประสิทธิภาพ และล็อก

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

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

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

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

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

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

มีสิ่งที่ต้องตัดสินใจก่อนคำถามว่าจะจ้างข้างนอกไหม – การแบ่งบทบาทกับการเอาต์ซอร์สงานไอที

เมื่อยกเรื่องระบบมอนิเตอร์ขึ้นมา คำถามแรกที่ออกมามักเป็น “จ้างข้างนอกทำได้ไหม” เพราะการที่ฐานปฏิบัติการในไทยมีผู้ดูแลระบบสารสนเทศเพียง 1 หรือ 2 คน หรือบางทีก็เป็นงานควบนั้นเป็นเรื่องปกติมาก จึงเป็นปฏิกิริยาที่เข้าใจได้

เบื้องหลังปฏิกิริยานี้ยังมีเรื่องความยากในการสรรหาบุคลากรอยู่ด้วย ผลสำรวจของ JETRO ระบุว่า บริษัทญี่ปุ่นในประเทศไทยที่ตอบว่าปัญหาขาดแคลนบุคลากรไอทีอย่างโปรแกรมเมอร์นั้น “รุนแรงมาก” หรือ “ค่อนข้างรุนแรง” มีอยู่ 56.7% ซึ่งใกล้เคียงกับ 58.2% ของทั้งภูมิภาคเอเชียและโอเชียเนีย สาเหตุที่ยกมาได้แก่ การลดลงของประชากรวัยแรงงาน ความสามารถในการแข่งขันด้านการสรรหาที่ลดลงเมื่อเทียบกับกลุ่มทุนไทยและบริษัทโครงสร้างพื้นฐาน และความสนใจต่อบริษัทญี่ปุ่นที่ลดลงหลังจากภาษาญี่ปุ่นถูกภาษาเกาหลีแซงหน้าในการเลือกภาษาต่างประเทศที่สองของการสอบเข้ามหาวิทยาลัย พูดง่าย ๆ คือ ทางออกที่ว่าเพิ่มคนแล้วเฝ้าระบบถึงกลางคืนนั้นเป็นทางที่หยิบมาใช้ได้ยากตั้งแต่ต้น

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

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

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

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

เลเยอร์ที่ 4 ที่โรงงานในไทยมักมองข้าม – คุณภาพไฟฟ้า

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

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

สถานการณ์ไฟฟ้าของประเทศไทยมีลักษณะเฉพาะที่ต่างจากญี่ปุ่น คำอธิบายของ Biz Info Log ระบุว่าในประเทศไทยนั้นไฟตกชั่วขณะพบได้บ่อยกว่าไฟดับสนิท และเกิดขึ้นหลายครั้งต่อปีแม้ในเขตเมืองของกรุงเทพมหานคร เพราะไฟตกชั่วขณะฟื้นคืนภายในไม่กี่วินาที ไฟส่องสว่างจึงเพียงกะพริบ และเครื่องจักรการผลิตก็ยังเดินต่อได้ แต่เซิร์ฟเวอร์และสวิตช์เครือข่ายบางครั้งทนช่วงไม่กี่วินาทีนี้ไม่ไหวและรีสตาร์ต

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

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

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

กรณีตัวอย่าง | นับเหตุขัดข้องที่โรงงานชิ้นส่วนโลหะในจังหวัดพระนครศรีอยุธยา

จากตรงนี้ไปเราจะดูด้วยตัวเลขที่เป็นรูปธรรม สิ่งที่จะกล่าวต่อไปนี้เป็น กรณีตัวอย่างจากการประมาณการของเราเอง ไม่ใช่ตัวเลขของบริษัทที่มีอยู่จริง ขอให้ดูที่ขั้นตอนว่าเวลาสูญไปตรงไหนเท่าไร และแปลงเป็นเงินอย่างไร มากกว่าจะดูที่ตัวเงิน

สมมติฐานเป็นดังนี้ โรงงานแปรรูปชิ้นส่วนโลหะสัญชาติญี่ปุ่นในจังหวัดพระนครศรีอยุธยา ทำชิ้นส่วนยานยนต์ มีพนักงาน 210 คน สภาพแวดล้อมไอทีประกอบด้วยเซิร์ฟเวอร์แบบติดตั้งในองค์กรที่ติดตั้งระบบบริหารการผลิต 1 เครื่อง ไฟล์เซิร์ฟเวอร์ 1 เครื่อง และเครือข่ายภายในโรงงานที่มีสวิตช์ 8 ตัว กับจุดกระจายสัญญาณไร้สาย 12 จุด ผู้ใช้งานระบบบริหารการผลิตเป็นประจำมี 48 คน ใช้ตรวจสอบข้อมูลคำสั่งซื้อ ออกใบสั่งงาน บันทึกผลการผลิต และจัดทำคำสั่งจัดส่ง

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

ตารางต่อไปนี้คือการนับเหตุขัดข้องที่เกิดขึ้นที่โรงงานนี้ในรอบ 1 ปี แยกตามสาเหตุ

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

สิ่งที่ควรสังเกตในตารางนี้คือสัดส่วนของสาเหตุ เหตุขัดข้องที่มาจากซอฟต์แวร์และอุปกรณ์มี 6 ครั้ง ในขณะที่เหตุที่มาจากคุณภาพไฟฟ้ามีถึง 8 ครั้ง สัดส่วนของเหตุจากไฟฟ้าในทั้งหมด 14 ครั้ง คือ 8 หารด้วย 14 ได้ประมาณ 57% ทั้งที่มากกว่าครึ่งมีต้นเหตุอยู่ฝั่งไฟฟ้า แต่เวลาถกเรื่องการมอนิเตอร์ กลับแทบไม่มีใครพูดถึงไฟฟ้าเลย

ความเอนเอียงตามฤดูกาลก็ชัดเจน ในทั้งหมด 14 ครั้ง เกิดในหน้าฝน 9 ครั้ง และหน้าแล้ง 5 ครั้ง ที่มาของความเอนเอียงนี้จะเห็นได้เมื่อแยกตามสาเหตุ เหตุจากซอฟต์แวร์และอุปกรณ์ 6 ครั้งแบ่งเป็นหน้าฝน 3 ครั้งและหน้าแล้ง 3 ครั้ง คือ 50% พอดีทั้งสองฝั่ง จึงไม่มีลักษณะตามฤดูกาล ส่วนเหตุจากคุณภาพไฟฟ้า 8 ครั้งแบ่งเป็นหน้าฝน 6 ครั้งและหน้าแล้ง 2 ครั้ง สัดส่วนหน้าฝนอยู่ที่ 75% ความเอนเอียงตามฤดูกาลจึงมาจากฝั่งไฟฟ้าแทบทั้งหมด

ทำไมเหตุขัดข้องจึงกระจุกตัวในหน้าฝน – ไฟตกชั่วขณะและแบตเตอรี่ UPS เสื่อม

เหตุผลที่เหตุขัดข้องจากไฟฟ้ากระจุกตัวในหน้าฝนอยู่ที่สภาพอากาศเอง คอลัมน์ของ PC Support Thailand ที่ Thai Jiyu Land นำเสนอ ระบุว่าในประเทศไทย ช่วงหน้าฝนตั้งแต่เดือนพฤษภาคมถึงตุลาคมจะเกิดไฟดับและไฟตกชั่วขณะจากพายุฝนและฝนฟ้าคะนองบ่อยครั้ง ทำให้ความเสี่ยงที่เซิร์ฟเวอร์และอุปกรณ์เครือข่ายจะเสียหายสูงขึ้น ความเสียหายจากฟ้าผ่าโดยตรงนั้นมีจำนวนครั้งน้อยกว่าความแกว่งของแรงดันไฟชั่วขณะที่เกิดขึ้นในระบบส่งไฟฟ้ามาก

เมื่อมองจากฝั่งโรงงาน ปรากฏการณ์นี้แสดงออกมาในรูปแบบที่เข้าใจยากมาก ข้อเท็จจริงที่ว่าเซิร์ฟเวอร์รีสตาร์ตในบ่ายวันที่ฝนตกหนักนั้นยังเหลืออยู่ แต่ไม่มีบันทึกใดเลยว่าแรงดันไฟตอนนั้นเป็นอย่างไร วันรุ่งขึ้นผู้รับผิดชอบจะรายงานว่า “เมื่อวานเซิร์ฟเวอร์ล่ม” และผู้บริหารจะสั่งว่า “ช่วยหาสาเหตุด้วย” แต่มันหาไม่ได้ สิ่งที่ไม่มีบันทึกย่อมตรวจสอบไม่ได้

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

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

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

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

ทำไมกว่าจะรู้ตัวจึงใช้เวลาถึง 2.4 ชั่วโมง

ที่โรงงานนี้ ระยะเวลาเฉลี่ยตั้งแต่เหตุขัดข้องเกิดขึ้นจนฝ่ายบริหารงานทั่วไปรับรู้อยู่ที่ 2.4 ชั่วโมง เมื่อแยกย่อยว่าทำไมจึงนานขนาดนี้ ก็จะเห็นหลายขั้นตอน

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

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

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

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

เมื่อมองทั้ง 4 ขั้นนี้จะเห็นจุดร่วม คือทุกขั้นล้วนขึ้นอยู่กับการตัดสินใจของคนและการติดต่อของคน การอบรมคนให้เร็วขึ้นนั้นในทางทฤษฎีก็ทำได้ แต่การให้คนตรวจพบการหยุดของเซิร์ฟเวอร์ที่ไม่มีใครใช้ในกะกลางคืนนั้นเป็นไปไม่ได้ในเชิงหลักการ ตรงนี้คือเหตุผลเชิงแก่นแท้ที่ทำให้ต้องมีกลไกที่เรียกว่าการมอนิเตอร์

เมื่อติดตั้งระบบมอนิเตอร์แล้ว เวลาในการตรวจพบจะสั้นลงแค่ไหน

เมื่อติดตั้งการมอนิเตอร์สถานะการมีชีวิตพร้อมการแจ้งเตือนตามเกณฑ์ เวลาจนกว่าจะตรวจพบจะสั้นลงเหลือเฉลี่ย 9 นาที หรือคิดเป็น 0.15 ชั่วโมง ส่วนประกอบของ 9 นาทีนี้ก็ชัดเจน

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

จากนั้นบวกด้วยเวลาในการส่งการแจ้งเตือน คือหลายสิบวินาทีตั้งแต่ตัดสินว่าผิดปกติจนกระทั่งการแจ้งเตือนไปถึงอีเมลหรือแชต รวมแล้วจึงลงตัวที่ระดับเฉลี่ย 9 นาที

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

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

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

จะประเมินมูลค่าของการลดเวลาตรวจพบ 1 ชั่วโมงอย่างไร

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

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

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

อีกรายการหนึ่งคือเวลาของกำลังคนที่เข้ามารับมือ เมื่อเกิดเหตุขัดข้อง ผู้ดูแลระบบสารสนเทศและผู้ดูแลการบริหารการผลิตต้องละงานหลักมารับมือ หากเกิดนอกเวลาทำงานก็กลายเป็นการทำงานล่วงเวลาโดยตรง

ตารางต่อไปนี้คือการไล่บวกทั้ง 2 รายการโดยแยกเป็นราคาต่อหน่วยและจำนวน

ค่ารอของรถบรรทุกขาออกอยู่ที่ 800 บาทต่อชั่วโมงต่อคัน จำนวนคันที่ได้รับผลกระทบเฉลี่ย 1.2 คัน คูณกันได้ 960 บาทต่อชั่วโมง กำลังคนที่รับมือมี 2 คน ค่าแรงต่อชั่วโมง 350 บาท ได้ 700 บาทต่อชั่วโมง รวมกันแล้ว 1 ชั่วโมงที่ระบบหยุดโดยไม่มีใครรู้มีมูลค่า 1,660 บาท

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

ประมาณการของเราเอง | เทียบผลรายปีจากการตรวจพบเร็วขึ้นกับค่าใช้จ่ายของระบบมอนิเตอร์

เมื่อวัตถุดิบครบแล้ว เราก็คำนวณผลรายปีได้

จำนวนเหตุขัดข้องต่อปีคือ 14 ครั้ง เวลาที่ย่นได้ต่อ 1 ครั้งคือ 2.25 ชั่วโมง เวลารวมที่ย่นได้ในหนึ่งปีจึงเท่ากับ 14 คูณ 2.25 ได้ 31.5 ชั่วโมง เมื่อนำ 31.5 ชั่วโมงนี้คูณด้วยมูลค่าความเสียหาย 1,660 บาทต่อชั่วโมง จะได้ยอดที่ลดลงได้ต่อปีเท่ากับ 52,290 บาท

อีกด้านหนึ่งคือค่าใช้จ่ายในการติดตั้งระบบมอนิเตอร์ ค่าใช้จ่ายเริ่มต้นซึ่งรวมการสร้างเซิร์ฟเวอร์มอนิเตอร์หรือบริการคลาวด์ การติดตั้งเอเจนต์บนอุปกรณ์แต่ละตัว การตั้งค่าการ์ดจัดการเครือข่ายของ UPS การสร้างแดชบอร์ด และการตั้งค่าเส้นทางการแจ้งเตือน อยู่ที่ 180,000 บาท ค่าบริการมอนิเตอร์รายเดือนซึ่งรวมการมอนิเตอร์สถานะการมีชีวิตและการแจ้งเตือน อยู่ที่ 28,000 บาทต่อเดือน คิดเป็นรายปีคือ 28,000 คูณ 12 ได้ 336,000 บาท

เมื่อวางทั้งสองด้านเรียงกันจะได้ดังนี้

เมื่อนำผลรายปี 52,290 บาท หารด้วยค่าบริการรายปี 336,000 บาท จะได้ 15.6% ยังไม่ทันนับค่าใช้จ่ายเริ่มต้น 180,000 บาทเข้าไป ลำพังค่าใช้จ่ายรายเดือนก็ยังไม่ครอบคลุม

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

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

ลำพังการตรวจพบเร็วขึ้นยังคืนทุนไม่ได้ – เหตุผลที่ไม่ตีมูลค่าผลอีกด้านหนึ่ง

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

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

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

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

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

ในทางปฏิบัติ เราแนะนำให้อธิบายโดยแยกเป็น 2 ส่วน ส่วนแรกคือผลจากการย่นเวลาตรวจพบซึ่งแสดงเป็นเงินได้ ในกรณีตัวอย่างคือ 52,290 บาทต่อปี ส่วนที่สองคือส่วนที่ไม่ตีเป็นเงิน แต่ระบุเหตุการณ์ที่ต้องการป้องกันออกมาเป็นรายการรูปธรรม เช่น สภาพที่ฐานข้อมูลหยุดจนบันทึกผลการผลิตของทั้งวันไม่ได้ สภาพที่เซิร์ฟเวอร์เสียโดยไม่มีใครรู้ว่าการสำรองข้อมูลไม่ได้ทำงาน และสภาพที่ไฟตกชั่วขณะในหน้าฝนแล้ว UPS ประคองไม่ไหวจนระบบบริหารการผลิตล้ม ในการขออนุมัติภายในองค์กร รายการแบบนี้กลับได้ผลมากกว่าจริง ๆ เพราะการเรียงเหตุการณ์รูปธรรมที่ “ถ้าเกิดขึ้นแล้วเดือดร้อน” มีความหมายต่อผู้ตัดสินใจมากกว่าการแสดงตัวเลข 15.6%

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

3 แกนของการออกแบบระบบมอนิเตอร์ – วัดอะไร ถึงไหนคือผิดปกติ และส่งถึงใคร

ขอแปลงเนื้อหาทั้งหมดข้างต้นเป็นภาษาของการออกแบบ สิ่งที่ต้องกำหนดในการออกแบบการมอนิเตอร์มี 3 อย่าง

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

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

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

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

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

รูปแบบความล้มเหลวที่พบบ่อยในการตั้งค่าเกณฑ์

การออกแบบเกณฑ์คือจุดแยกที่ใหญ่ที่สุดซึ่งทำให้โครงการมอนิเตอร์ล้มเหลวในทางเนื้อหา ขอยกความล้มเหลวที่พบบ่อยมาดังนี้

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

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

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

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

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

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

ล็อกของระบบมอนิเตอร์กับ PDPA – ระยะเวลาจัดเก็บและสิทธิ์การเข้าถึง

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

พระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลของไทย หรือ PDPA มีผลบังคับใช้เต็มรูปแบบเมื่อวันที่ 1 มิถุนายน 2022 คำอธิบายของ KPMG ระบุว่าผู้ประกอบการที่อยู่ในขอบเขตมีหน้าที่จัดทำบันทึกการประมวลผลข้อมูลส่วนบุคคล และในกรณีที่มีการประมวลผลที่มีความเสี่ยงสูงก็มีหน้าที่แต่งตั้งเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคลหรือ DPO ด้วย ทั้งนี้ การประมวลผลข้อมูลที่เกี่ยวข้องกับการติดตามพฤติกรรมของเจ้าของข้อมูลก็ถูกจัดว่าอาจอยู่ในขอบเขตของกฎหมาย

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

ระดับของบทลงโทษก็ไม่เบาเลย คำอธิบายของ One Asia Lawyers แสดงให้เห็นว่าการฝ่าฝืนอาจถูกปรับทางปกครองสูงสุด 5,000,000 บาท และปรับทางอาญาสูงสุด 1,000,000 บาท การติดตั้งระบบมอนิเตอร์มักเดินหน้าไปตามความสะดวกของฝ่ายสารสนเทศ แต่ผู้เกี่ยวข้องต้องมีความเข้าใจร่วมกันว่าการจัดการล็อกเป็นประเด็นทางกฎหมายด้วย

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

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

แนวทางการนำไปใช้ | 4 ขั้นตอน

สุดท้ายนี้ ขอเรียบเรียงขั้นตอนการติดตั้งระบบมอนิเตอร์จริง

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

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

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

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

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

คำถามที่พบบ่อย

ระบบมอนิเตอร์ของโรงงานควรเริ่มจากอะไร

ขอให้เริ่มจากการมอนิเตอร์สถานะการมีชีวิตและการมอนิเตอร์ฝั่งไฟฟ้า การมอนิเตอร์สถานะการมีชีวิตตั้งค่าง่ายที่สุด และจับเหตุขัดข้องที่สร้างความเสียหายมากที่สุดคือการหยุดสนิทได้ ส่วนฝั่งไฟฟ้ามีลำดับความสำคัญสูงในฐานะเงื่อนไขเฉพาะของโรงงานในไทย ในกรณีตัวอย่าง เหตุขัดข้อง 8 ครั้งจาก 14 ครั้งต่อปี คิดเป็นราว 57% มีต้นเหตุจากคุณภาพไฟฟ้า การมอนิเตอร์ประสิทธิภาพและล็อกมีประโยชน์ แต่การออกแบบเกณฑ์ต้องใช้ข้อมูลในภาวะปกติ ลำดับที่สมจริงจึงคือใส่การมอนิเตอร์สถานะการมีชีวิตก่อนแล้วเก็บข้อมูลไปพลาง อนึ่ง ขอให้ทำการสำรวจเป้าหมายและนิยาม “อะไรคือปกติ” ให้เสร็จก่อนการเลือกเครื่องมือ

ติดตั้งระบบมอนิเตอร์แล้วจะพบเหตุขัดข้องเร็วขึ้นแค่ไหน

ในการประมาณการของกรณีตัวอย่าง สภาพที่ขึ้นอยู่กับการแจ้งของผู้ใช้งานซึ่งใช้เวลาเฉลี่ย 2.4 ชั่วโมง ลดลงเหลือเฉลี่ย 9 นาที หรือ 0.15 ชั่วโมง เมื่อติดตั้งการมอนิเตอร์สถานะการมีชีวิตพร้อมการแจ้งเตือนตามเกณฑ์ ย่นได้ 2.25 ชั่วโมงต่อ 1 ครั้ง คิดเป็นอัตราการย่นราว 94% อย่างไรก็ตาม สิ่งที่การมอนิเตอร์ย่นได้มีเพียงเวลาจนกว่าจะตรวจพบ ส่วนเวลาตั้งแต่ตรวจพบจนกู้คืนสำเร็จนั้นไม่เปลี่ยน และหากยังไม่กำหนดผู้รับการแจ้งเตือนในช่วงกลางคืนและวันหยุด ต่อให้ตรวจพบเร็วขึ้น การเริ่มรับมือก็ไม่ได้เร็วขึ้น การจะให้เกิดผลจึงต้องติดตั้งโดยรวมการออกแบบเส้นทางการแจ้งเตือนเข้าไปด้วย

ค่าใช้จ่ายของระบบมอนิเตอร์คืนทุนได้ด้วยการย่นเวลาตรวจพบอย่างเดียวหรือไม่

ในกรณีตัวอย่างคืนทุนไม่ได้ เวลาที่ย่นได้ต่อปีคือ 14 ครั้งคูณ 2.25 ชั่วโมง ได้ 31.5 ชั่วโมง คูณด้วยมูลค่าความเสียหาย 1,660 บาทต่อชั่วโมง ได้ผล 52,290 บาทต่อปี ในขณะที่ค่าบริการมอนิเตอร์รายปีคือ 28,000 บาทต่อเดือนคูณ 12 เดือน ได้ 336,000 บาท และยังมีค่าใช้จ่ายเริ่มต้น 180,000 บาทเพิ่มเข้ามา เมื่อนำผลหารด้วยค่าบริการรายปีจะได้เพียง 15.6% คุณค่าของการมอนิเตอร์อยู่ที่ผลของการหยุดความผิดปกติเล็ก ๆ ก่อนที่มันจะโตเป็นการหยุดครั้งใหญ่มากกว่า แต่เพราะผลนั้นขึ้นอยู่กับสมมติฐานเรื่องความน่าจะเป็น บทความนี้จึงจงใจไม่ตีเป็นมูลค่า

ถ้ามี UPS แล้วจะป้องกันเหตุขัดข้องจากไฟฟ้าได้หรือไม่

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

การจัดเก็บล็อกของระบบมอนิเตอร์มีข้อควรระวังตาม PDPA หรือไม่

PDPA ของไทยมีผลบังคับใช้เต็มรูปแบบเมื่อวันที่ 1 มิถุนายน 2022 และการประมวลผลข้อมูลที่เกี่ยวข้องกับการติดตามพฤติกรรมของเจ้าของข้อมูลถูกจัดว่าอาจอยู่ในขอบเขตของกฎหมาย อย่างไรก็ตาม ไม่อาจสรุปได้ว่าล็อกของระบบมอนิเตอร์ต้องเป็นข้อมูลส่วนบุคคลเสมอไป อัตราการใช้ CPU และเวลาตอบสนองไม่เชื่อมโยงกับบุคคล แต่ล็อกการเข้าถึงที่มีรหัสผู้ใช้งานอาจเชื่อมโยงได้ ในทางปฏิบัติขอให้กำหนด 3 ข้อตั้งแต่ตอนติดตั้ง คือกำหนดระยะเวลาจัดเก็บจากวัตถุประสงค์แล้วลบเมื่อพ้นกำหนด จำกัดสิทธิ์การเข้าถึงแดชบอร์ด และไม่เก็บรายการที่ไม่จำเป็นต่อการรับมือเหตุขัดข้อง ส่วนการตัดสินรายกรณีขอให้ปรึกษาผู้เชี่ยวชาญ

สรุป

ขอเรียบเรียงประเด็นสำคัญ

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

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

ในการประมาณการของกรณีตัวอย่าง โรงงานแปรรูปชิ้นส่วนโลหะในจังหวัดพระนครศรีอยุธยาเกิดเหตุขัดข้อง 14 ครั้งต่อปี ในจำนวนนี้ 8 ครั้ง หรือราว 57% มีต้นเหตุจากคุณภาพไฟฟ้า เมื่อแยกตามฤดูกาลพบว่าเกิดในหน้าฝน 9 ครั้งและหน้าแล้ง 5 ครั้ง ความเอนเอียงนี้มาจากฝั่งไฟฟ้าแทบทั้งหมด เวลาจนกว่าจะตรวจพบเฉลี่ย 2.4 ชั่วโมง เมื่อใส่การมอนิเตอร์สถานะการมีชีวิตพร้อมการแจ้งเตือนตามเกณฑ์จะลดเหลือเฉลี่ย 9 นาที หรือ 0.15 ชั่วโมง ย่นได้ 2.25 ชั่วโมงต่อครั้ง คิดเป็นอัตราราว 94% เวลาที่ย่นได้ต่อปีคือ 31.5 ชั่วโมง คูณด้วยมูลค่าความเสียหาย 1,660 บาทต่อชั่วโมง ได้ผล 52,290 บาทต่อปี

อีกด้านหนึ่ง ค่าใช้จ่ายของการมอนิเตอร์คือค่าเริ่มต้น 180,000 บาท และรายเดือน 28,000 บาท หรือ 336,000 บาทต่อปี เมื่อนำผลหารด้วยค่าบริการรายปีจะได้เพียง 15.6% นั่นคือ ลำพังผลจากการย่นเวลาตรวจพบยังคืนทุนไม่ได้ เราสามารถทำให้ตัวเลขนี้ดูดีได้ แต่ถ้าทำเช่นนั้นมันจะไม่ใช่วัตถุดิบสำหรับการตัดสินใจอีกต่อไป จึงนำเสนอตามที่เป็น คุณค่าที่แท้จริงของการมอนิเตอร์อยู่ที่ผลของการหยุดความผิดปกติเล็ก ๆ ก่อนที่จะโตเป็นการหยุดครั้งใหญ่ แต่เพราะผลนั้นขึ้นอยู่กับสมมติฐานเรื่องความน่าจะเป็น บทความนี้จึงไม่ตีเป็นมูลค่า ทั้งหมดนี้เป็นการประมาณการของเราเองและไม่ใช่ตัวเลขของบริษัทที่มีอยู่จริง ขอให้ดูที่แนวคิดว่าไล่บวกอย่างไรและเรียกอะไรว่าผลได้ถึงไหน มากกว่าจะดูที่ตัวเงิน

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

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

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

ต่อให้ยังอยู่ในขั้นที่ยังไม่ได้ตัดสินว่าควรมอนิเตอร์อะไรก็ไม่เป็นไร TOMAS TECH ให้บริการออกแบบและดูแลโครงสร้างพื้นฐานไอทีสำหรับโรงงานญี่ปุ่นในประเทศไทย และยินดีรับปรึกษาตั้งแต่ขั้นการสำรวจเป้าหมายที่จะมอนิเตอร์และการนิยามร่วมกันว่า “อะไรคือปกติ” เรายินดีรับปรึกษาแม้ไม่ได้ตั้งต้นว่าจะติดตั้งระบบ หากท่านต้องการแปลงเหตุขัดข้องของบริษัทให้เป็นตัวเลขก่อน ขอเชิญติดต่อเราได้ที่ หน้าติดต่อ

ข้อมูลอ้างอิง

• JETRO – สถานการณ์การขาดแคลนบุคลากรและการรับมือ พร้อมจับตาแนวโน้มค่าแรงขั้นต่ำในอนาคต ประเทศไทย ผลสำรวจการขาดแคลนบุคลากรไอทีของบริษัทญี่ปุ่น ภาษาญี่ปุ่น
• ASPIC – เปรียบเทียบบริการ MSP 12 ราย ให้บริการอะไรและมีข้อดีอย่างไร โครงสร้างชั้นของบริการรับมอนิเตอร์ ภาษาญี่ปุ่น
• OutageCost.com – Cost of IT Downtime งานสำรวจความเสียหายจากการหยุดระบบในองค์กรขนาดใหญ่
• Biz Info Log – แม้ในเขตเมืองกรุงเทพก็ต้องระวัง ในไทยไฟตกชั่วขณะพบบ่อยกว่าไฟดับ ความถี่ของไฟตกชั่วขณะในประเทศไทย ภาษาญี่ปุ่น
• Thai Jiyu Land – คอลัมน์ของ PC Support Thailand ตอนที่ 254 ว่าด้วยมาตรการรับมือไฟดับ ไฟดับในหน้าฝนและการเสื่อมของแบตเตอรี่ UPS ภาษาญี่ปุ่น
• KPMG – บริการสนับสนุนการปฏิบัติตามพระราชบัญญัติคุ้มครองข้อมูลส่วนบุคคลของไทย PDPA หน้าที่ตาม PDPA และการแต่งตั้ง DPO ภาษาญี่ปุ่น
• One Asia Lawyers – กรณีการบังคับใช้กฎหมายคุ้มครองข้อมูลส่วนบุคคล PDPA ในประเทศไทย บทลงโทษและการบังคับใช้ PDPA ภาษาญี่ปุ่น