thansettakij
thansettakij
ดาต้าเซ็นเตอร์ล่ม ธุรกิจเสียหาย ใครรับผิดชอบ

ดาต้าเซ็นเตอร์ล่ม ธุรกิจเสียหาย ใครรับผิดชอบ

ดาต้าเซ็นเตอร์ล่ม ธุรกิจเสียหาย ใครรับผิดชอบ ตอนที่ 1 มุมผู้ใช้บริการและผู้ประกอบการดาต้าเซ็นเตอร์ โดย ดร.ธัชพล โปษยานนท์

จากระบบหยุดชะงักและข้อจำกัดของ SLA สู่การพิสูจน์ความเสียหายและการฟื้นธุรกิจ

เมื่อระบบของผู้ให้บริการหยุด ธุรกิจของลูกค้าก็หยุดได้

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

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

ดร.ธัชพล โปษยานนท์

ผู้เกี่ยวข้องไม่ได้เสียหายแบบเดียวกัน

ความเสี่ยงเชื่อมโยงกันเป็นห่วงโซ่

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

AI Data Centre ทำให้ความเสี่ยงเข้มข้นขึ้น เพราะอุปกรณ์ประมวลผลมีมูลค่าสูง ใช้ไฟและความเย็นมาก และอาจพึ่งระบบหล่อเย็นด้วยของเหลว Swiss Re ชี้ถึงความเสี่ยงจากน้ำ ความเย็น ไฟฟ้า และการกระจุกตัวของมูลค่าในศูนย์ข้อมูลยุค AI [2] ระบบสำรองจึงต้องแยกจุดพึ่งพาร่วมจริง ไม่ใช่มีเพียงอุปกรณ์สองชุดแต่ยังใช้สถานีไฟฟ้า เส้นทางสื่อสาร หรือทีมเดียวกัน

หกเหตุการณ์ที่ต้องแยกสาเหตุและผู้รับภาระ

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

ภาพที่ 1  ตัวอย่างภัยที่เกิดขึ้นและรายการที่อาจเข้าเงื่อนไขเรียกร้อง

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

SLA ไม่เท่ากับการชดเชยความเสียหายทั้งหมด

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

สิ่งที่ผู้ใช้บริการและผู้ประกอบการต้องเทียบกันก่อนเกิดเหตุ

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

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

ฟื้นบริการพร้อมรักษาหลักฐาน

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

หลักฐานที่ควรเก็บให้ครบ

อย่าด่วนสรุปสาเหตุจากอาการที่เห็น

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

การฟื้นต้องวัดจากบริการธุรกิจที่กลับมาใช้ได้

RTO คือเวลาที่ตั้งเป้าจะกู้บริการกลับ ส่วน RPO คือช่วงข้อมูลย้อนหลังที่ยอมสูญเสียได้ การทดสอบต้องครอบคลุมระบบต้นทาง ปลายทาง Identity เครือข่าย ข้อมูล และความพร้อมของทีม ไม่ใช่เพียงยืนยันว่าเซิร์ฟเวอร์เปิดได้ ระหว่างกู้คืนต้องตรวจความสมบูรณ์ของข้อมูล ทดสอบรายการธุรกิจแบบ end to end และให้เจ้าของบริการยืนยันก่อนเปิดใช้งาน

ก่อนระบบหยุด ทั้งสองฝ่ายต้องตกลงอะไร

ห้าคำถามที่ควรตอบได้ก่อนเกิดเหตุ

  1. หากผู้ให้บริการหยุด ธุรกิจของเราจะเสียหายอะไรและมากเพียงใด
  2. เครดิต SLA สิทธิเรียกร้องตามสัญญา และกรมธรรม์ของเรารองรับส่วนใด
  3. ส่วนที่ไม่คุ้มครองหรือเกินวงเงิน ใครรับภาระและมีสภาพคล่องเพียงพอหรือไม่
  4. เรามีหลักฐานพิสูจน์สาเหตุและผลเสียหาย พร้อมขั้นตอนแจ้งเหตุหรือไม่
  5. ผลทดสอบล่าสุดยืนยันว่าบริการและข้อมูลกลับมาได้ภายในเวลาที่ธุรกิจต้องการหรือไม่

บทสรุป

คำตอบของ “ใครรับผิดชอบ” ต้องเริ่มจากการรู้ว่าใครเสียหาย มีสิทธิอะไร และหลักฐานอยู่ที่ใด ก่อนเชื่อมไปสู่ 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