
ดาต้าเซ็นเตอร์ล่ม ธุรกิจเสียหาย ใครรับผิดชอบ
ดาต้าเซ็นเตอร์ล่ม ธุรกิจเสียหาย ใครรับผิดชอบ ตอนที่ 1 มุมผู้ใช้บริการและผู้ประกอบการดาต้าเซ็นเตอร์ โดย ดร.ธัชพล โปษยานนท์
จากระบบหยุดชะงักและข้อจำกัดของ SLA สู่การพิสูจน์ความเสียหายและการฟื้นธุรกิจ
เมื่อระบบของผู้ให้บริการหยุด ธุรกิจของลูกค้าก็หยุดได้
ลองนึกถึงบริษัทที่รับคำสั่งซื้อ ให้บริการลูกค้า หรือประมวลผลธุรกรรมผ่านระบบคลาวด์ เมื่อดาต้าเซ็นเตอร์หรือบริการต้นทางหยุด ระบบของบริษัทอาจใช้งานไม่ได้ พนักงานทำงานค้าง ลูกค้ารอ และองค์กรมีค่าใช้จ่ายในการย้ายบริการชั่วคราว แม้อาคารและอุปกรณ์ของตนไม่ได้เสียหาย คำถามสำคัญจึงไม่ใช่เพียงว่าเกิดอะไรขึ้น แต่คือใครได้รับผลกระทบ ใครมีหน้าที่ตามสัญญา และบริการจะกลับมาได้เร็วเพียงใด
ความตอนที่ 1 มองจากผู้ใช้บริการและผู้ประกอบการดาต้าเซ็นเตอร์ โดยติดตามลำดับตั้งแต่เหตุขัดข้อง ความเสียหาย สิทธิเรียกร้อง หลักฐาน ไปจนถึงการฟื้นบริการ ส่วนรายละเอียดแบบประกันภัย การคำนวณค่าสินไหม และความเสี่ยงสะสมของบริษัทประกันภัย จะนำเสนอในตอนที่ 2
ผู้เกี่ยวข้องไม่ได้เสียหายแบบเดียวกัน
ความเสี่ยงเชื่อมโยงกันเป็นห่วงโซ่
ดาต้าเซ็นเตอร์ไม่ใช่เพียงห้องที่มีเซิร์ฟเวอร์ แต่เป็นระบบพึ่งพาร่วมของไฟฟ้า UPS เครื่องกำเนิดไฟฟ้า ระบบทำความเย็น น้ำ เครือข่าย ระบบยืนยันตัวตน คลาวด์ ซอฟต์แวร์ และทีมปฏิบัติการ เหตุเดียวจึงอาจลุกลามจากอุปกรณ์หนึ่งไปสู่บริการหลายองค์กรได้ รายงาน Cloud Down ของ Lloyd’s ใช้สถานการณ์จำลองเพื่อแสดงผลกระทบข้ามหลายอุตสาหกรรมจากบริการคลาวด์หยุดชะงัก [1]
AI Data Centre ทำให้ความเสี่ยงเข้มข้นขึ้น เพราะอุปกรณ์ประมวลผลมีมูลค่าสูง ใช้ไฟและความเย็นมาก และอาจพึ่งระบบหล่อเย็นด้วยของเหลว Swiss Re ชี้ถึงความเสี่ยงจากน้ำ ความเย็น ไฟฟ้า และการกระจุกตัวของมูลค่าในศูนย์ข้อมูลยุค AI [2] ระบบสำรองจึงต้องแยกจุดพึ่งพาร่วมจริง ไม่ใช่มีเพียงอุปกรณ์สองชุดแต่ยังใช้สถานีไฟฟ้า เส้นทางสื่อสาร หรือทีมเดียวกัน
หกเหตุการณ์ที่ต้องแยกสาเหตุและผู้รับภาระ
เหตุที่เห็นเหมือนกันจากฝั่งลูกค้า เช่น เข้าใช้ระบบไม่ได้ อาจเกิดจากไฟไหม้ เครื่องทำความเย็นเสีย การตั้งค่าผิด การโจมตีไซเบอร์ หรือผู้ให้บริการภายนอกล่ม แต่ละสาเหตุทำให้หน้าที่ตามสัญญา หลักฐาน และความคุ้มครองต่างกัน ภาพที่ 1 จึงใช้คำว่า“อาจเคลมได้”และเป็นกรณีสมมติ ไม่ใช่ประวัติการจ่ายสินไหมจริง
หลักคิดสำคัญคือแยกความเสียหายของผู้ประกอบการออกจากของลูกค้า ไฟไหม้อาจเชื่อมประกันทรัพย์สินกับธุรกิจหยุดชะงัก. ขณะที่บริการคลาวด์ล่มโดยไม่มีทรัพย์สินเสียหายต้องตรวจ ความคุ้มครองที่รองรับเหตุแบบนั้นโดยเฉพาะ ส่วนความเสียหายที่ลูกค้าเรียกร้องจากผู้ให้บริการต้องพิจารณา ฐานความรับผิดและข้อจำกัดในสัญญาแยก ต่างหาก
SLA ไม่เท่ากับการชดเชยความเสียหายทั้งหมด
เมื่อบริการหยุด ผู้ใช้บริการมักเริ่มจาก SLA แต่เครดิตค่าบริการเป็นเพียงหนึ่งในหลายช่องทาง ผู้ให้บริการอาจคืนค่าบริการตามสูตรและเพดานที่ตกลงไว้ โดยไม่จำเป็นต้องเท่ากับกำไรที่ลูกค้าสูญเสีย ค่าใช้จ่ายย้ายระบบ หรือความเสียหายต่อลูกค้าปลายทาง และบางสัญญากำหนดขั้นตอนหรือระยะเวลาการแจ้งขอเครดิตอย่างเคร่งครัด
สิ่งที่ผู้ใช้บริการและผู้ประกอบการต้องเทียบกันก่อนเกิดเหตุ
- ผู้ใช้บริการต้องเทียบ SLA และสิทธิเรียกร้องตามสัญญากับกรมธรรม์ของตน เพื่อรู้ว่าส่วนใดมีผู้รับภาระและส่วนใดต้องรับเอง
- ผู้ประกอบการต้องเทียบภาระต่อลูกค้ากับกรมธรรม์ของตน เพราะความรับผิดตามสัญญาอาจกว้างกว่าความคุ้มครอง
- ทั้งสองฝ่ายต้องตกลงวิธีแจ้งเหตุ การแบ่งปันข้อมูล และการรักษาหลักฐาน โดยคำนึงถึงการรักษาความลับและความปลอดภัย
- ต้องเปิดเผยเงินหรือเครดิตที่ได้รับจากช่องทางอื่นตามเงื่อนไขที่เกี่ยวข้อง เพื่อหลีกเลี่ยงการชดใช้ซ้ำสำหรับความเสียหายเดียวกัน
แนวทางของ Alliant ใช้การจัดโปรแกรมความเสี่ยงตลอดวงจรโครงการ ตั้งแต่งานก่อสร้าง การเริ่มดำเนินงาน ไปจนถึงทรัพย์สิน เครื่องจักร ธุรกิจหยุดชะงัก ไซเบอร์ และความรับผิดจากบริการ [4] กรอบนี้ช่วยตั้งคำถามได้ดี แต่ต้องแปลงเป็นสัญญาและกรมธรรม์ที่เหมาะกับแต่ละโครงการ
ฟื้นบริการพร้อมรักษาหลักฐาน
การควบคุมเหตุ การฟื้นระบบ และการเก็บหลักฐานต้องดำเนินควบคู่กัน โดยให้ความปลอดภัยของคนและการจำกัดความเสียหายเป็นลำดับแรก จากนั้นแต่งตั้งผู้บัญชาการเหตุ ผู้ดูแลหลักฐาน และผู้ประสานลูกค้า บริษัทประกันภัย หรือนายหน้า บันทึกเหตุผลของการตัดสินใจฉุกเฉิน และแจ้งเหตุตามเวลาที่กำหนด โดยไม่ปล่อยให้การรอเอกสารทำให้ความเสียหายเพิ่มขึ้น
หลักฐานที่ควรเก็บให้ครบ
อย่าด่วนสรุปสาเหตุจากอาการที่เห็น
ระบบความเย็นหยุดอาจเกิดจากเครื่องจักรเสีย การตั้งค่าผิด หรือการเข้าถึงระบบควบคุมโดยไม่ได้รับอนุญาต การระบุสาเหตุผิดอาจทำให้แก้ปัญหาไม่ตรงจุดและกระทบสิทธิเรียกร้อง CISA แนะนำให้รักษาหลักฐานที่สูญหายง่ายและทดสอบข้อมูลสำรองที่แยกจากระบบใช้งาน [3]
การฟื้นต้องวัดจากบริการธุรกิจที่กลับมาใช้ได้
RTO คือเวลาที่ตั้งเป้าจะกู้บริการกลับ ส่วน RPO คือช่วงข้อมูลย้อนหลังที่ยอมสูญเสียได้ การทดสอบต้องครอบคลุมระบบต้นทาง ปลายทาง Identity เครือข่าย ข้อมูล และความพร้อมของทีม ไม่ใช่เพียงยืนยันว่าเซิร์ฟเวอร์เปิดได้ ระหว่างกู้คืนต้องตรวจความสมบูรณ์ของข้อมูล ทดสอบรายการธุรกิจแบบ end to end และให้เจ้าของบริการยืนยันก่อนเปิดใช้งาน
ก่อนระบบหยุด ทั้งสองฝ่ายต้องตกลงอะไร
ห้าคำถามที่ควรตอบได้ก่อนเกิดเหตุ
- หากผู้ให้บริการหยุด ธุรกิจของเราจะเสียหายอะไรและมากเพียงใด
- เครดิต SLA สิทธิเรียกร้องตามสัญญา และกรมธรรม์ของเรารองรับส่วนใด
- ส่วนที่ไม่คุ้มครองหรือเกินวงเงิน ใครรับภาระและมีสภาพคล่องเพียงพอหรือไม่
- เรามีหลักฐานพิสูจน์สาเหตุและผลเสียหาย พร้อมขั้นตอนแจ้งเหตุหรือไม่
- ผลทดสอบล่าสุดยืนยันว่าบริการและข้อมูลกลับมาได้ภายในเวลาที่ธุรกิจต้องการหรือไม่
บทสรุป
คำตอบของ “ใครรับผิดชอบ” ต้องเริ่มจากการรู้ว่าใครเสียหาย มีสิทธิอะไร และหลักฐานอยู่ที่ใด ก่อนเชื่อมไปสู่ SLA สัญญา กรมธรรม์ และความเสี่ยงที่องค์กรต้องรับเอง การออกแบบบริการ สัญญา การแจ้งเหตุ และแผนฟื้นฟูให้สอดคล้องกัน จะลดทั้งเวลาหยุดและข้อพิพาทเมื่อเกิดเหตุจริง
แหล่งอ้างอิง
[1] Lloyd’s และ AIR Worldwide, Cloud Down, 2018
[2] Swiss Re Institute, Insuring AI Data Centre Value Accumulation Risks, 2026
[3] CISA, StopRansomware Guide







