ระบบสำรองข้อมูลระบบธุรกิจ 2026 – สิ่งที่ปกป้องได้คือการกู้คืน ไม่ใช่จำนวนสำเนา

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

ทำไม “สำรองข้อมูลได้” กับ “กู้คืนได้” จึงเป็นคนละเรื่อง

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

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

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

ช่องว่างนี้ปรากฏเป็นตัวเลขชัดเจนในผลสำรวจแนวโน้มการใช้ประโยชน์จาก IT ขององค์กร ปี 2026 โดย JIPDEC ช่วงเวลาสำรวจคือ 16 ถึง 20 มกราคม 2026 กลุ่มเป้าหมายคือบริษัทในประเทศญี่ปุ่นที่มีพนักงานตั้งแต่ 50 คนขึ้นไป จำนวน 1,107 บริษัท โดยผู้ตอบเป็นผู้รับผิดชอบด้านกลยุทธ์ IT และความมั่นคงปลอดภัยสารสนเทศ ผลสำรวจพบว่าอัตราที่เคยติดแรนซัมแวร์อยู่ที่ 45.8% และ สัดส่วนที่ไม่สามารถกู้คืนระบบและข้อมูลได้โดยไม่จ่ายค่าไถ่อยู่ที่ 13.0% ตัวเลขหลังนี้เพิ่มขึ้นจากการสำรวจครั้งก่อนที่ 10.5%

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

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

ทำไมฐานการผลิตในไทยยังคงเป็นเป้าหมายของแรนซัมแวร์ในปี 2026

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

จากการรวบรวมของ Check Point Software Technologies กรณีการโจมตีด้วยแรนซัมแวร์ที่ถูกเปิดเผยระหว่างเดือนกรกฎาคมถึงกันยายน 2024 มีมากกว่า 1,230 กรณี และในจำนวนนั้น 13% เกิดขึ้นในภูมิภาคเอเชียแปซิฟิก เมื่อมองเป็นรายภูมิภาคแล้วนี่ไม่ใช่ขนาดที่มองข้ามได้ นอกจากนี้ สำนักงานคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติของไทย (NCSA) ระบุว่าความเสียหายจากแรนซัมแวร์ภายในประเทศไทยในปี 2023 เพิ่มขึ้นเป็น 1.5 เท่าเมื่อเทียบกับปี 2022 แนวโน้มขาขึ้นนี้ไม่ได้ยกเว้นประเทศที่มีฐานผลิตญี่ปุ่นกระจุกตัวอยู่อย่างไทย

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

การเป็นภาคการผลิตทำให้เงื่อนไขแย่ลง

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

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

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

การปกป้องฐานการผลิตในไทยให้ครอบคลุมถึงสายการผลิตนั้นเกินขอบเขตของระบบสารสนเทศเพียงอย่างเดียว เรื่องการแยกส่วนฝั่งเครือข่ายควบคุมนั้นเราได้กล่าวถึงไว้ในความปลอดภัย OT (Operational Technology) – คู่มือปฏิบัติสำหรับโรงงานปี 2026 แล้ว ส่วนบทความนี้จะเจาะลึกเฉพาะการออกแบบการสำรองข้อมูลและการกู้คืน

3 รูปแบบคลาสสิกที่การสำรองข้อมูล “ทำงานอยู่” แต่กู้คืนไม่ได้

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

รูปแบบที่ 1 – ไม่เคยทดสอบเลยสักครั้ง

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

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

รูปแบบที่ 2 – วางไว้บนเครือข่ายเดียวกับระบบโปรดักชัน

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

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

รูปแบบที่ 3 – ขั้นตอนการกู้คืนผูกกับตัวบุคคล

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

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

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

เงื่อนไขของ “ชุดสำรองที่กู้คืนได้จริง” จากกรณีศึกษาของ Nichirei

แล้วชุดสำรองที่กู้คืนได้จริงเป็นอย่างไร กรณีที่ถูกเปิดเผยในปี 2026 ใช้เป็นตัวอย่างอ้างอิงได้ดี

กลุ่มบริษัท Nichirei ตรวจพบเหตุการณ์ที่สงสัยว่าเป็นการโจมตีทางไซเบอร์เมื่อเวลาประมาณ 6.50 น. ของวันที่ 13 กรกฎาคม 2026 และตั้งศูนย์บัญชาการฉุกเฉินทันที พร้อมตัดการเชื่อมต่อระบบทั้งกลุ่มเป็นการฉุกเฉิน ผลของการรับมือนี้ทำให้สามารถทยอยกลับมาเปิดงานจัดส่งของคลังสินค้าห้องเย็นและโรงงานอาหารได้ตั้งแต่วันที่ 17 กรกฎาคม 2026 ซึ่งเป็น 4 วันหลังเกิดเหตุ และเห็นแนวโน้มกลับสู่การเดินงานปกติได้ภายในราว 1 สัปดาห์

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

สองเงื่อนไขที่สร้างความเร็วนี้

จากเนื้อหาที่ถูกเปิดเผย เงื่อนไขที่สร้างความเร็วนี้สรุปได้เป็นสองข้อ

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

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

การเดินงานแบบลดทอนที่ทำควบคู่ไปด้วย

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

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

RTO และ RPO สองไม้บรรทัด – ทำไมจึงต้องกำหนดต่างกันในแต่ละงาน

ตรงนี้ขอนิยามสองคำที่อยู่ใจกลางของการออกแบบระบบ การออกแบบ RTO และ RPO เป็นงานที่ต้องทำก่อนการเลือกผลิตภัณฑ์สำรองข้อมูล

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

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

การกำหนดค่าเดียวทั้งองค์กรจะพังเสมอ

ถ้าพยายามกำหนดสองค่านี้เป็นค่าเดียวกันทั้งองค์กร จะพังไปทางใดทางหนึ่งในสองทาง

ถ้าปรับให้เท่ากับเกณฑ์ที่เข้มที่สุด ค่าใช้จ่ายจะพุ่ง การตั้ง RPO ของทุกระบบไว้ที่ 1 ชั่วโมงและ RTO ไว้ที่ 4 ชั่วโมง แปลว่าปกป้องโฟลเดอร์แชร์และสภาพแวดล้อมทดสอบด้วยมาตรฐานเดียวกัน ซึ่งคุณค่าที่ปกป้องกับค่าใช้จ่ายไม่สมดุลกัน

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

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

กำหนดก่อนว่าใครเป็นคนตัดสิน

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

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

ตาราง A ตารางออกแบบ RTO และ RPO แยกตามประเภทงาน

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

วิธีอ่านตาราง

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

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

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

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

ขั้นตอนแปลงตารางนี้เป็นฉบับของบริษัทคุณ

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

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

กฎ 3-2-1 และการออกแบบแบบ Immutable – ทำไมจึงต้องมี “สำเนาที่ลบไม่ได้”

เมื่อ RTO และ RPO ถูกกำหนดแล้ว ถัดไปคือเรื่องวิธีการ มาตรฐานที่ใช้อ้างอิงตรงนี้คือกฎ 3-2-1 ซึ่งเป็นแนวคิดว่าให้มีสำเนาข้อมูล 3 ชุด วางบนสื่อบันทึกที่ต่างกัน 2 ชนิด และเก็บ 1 ชุดในจำนวนนั้นไว้คนละสถานที่

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

สำเนาทั้ง 3 ชุดมีชะตากรรมร่วมกันหรือไม่

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

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

Immutable หรือสำเนาที่ลบไม่ได้

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

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

ออฟไลน์คือไม้ตายสุดท้าย

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

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

เขียนการแยกส่วนออกมาเป็น 3 ชั้น

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

แบบคลาวด์กับแบบออนพรีมิส แบบไหนเป็นจริงกว่าสำหรับฐานการผลิตในไทย

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

ค่าบริการจริง

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

ระดับราคาโดยทั่วไปมักถูกอ้างอิงว่า เครื่อง PC หนึ่งเครื่องเริ่มต้นราว 1,000 เยนต่อเดือน เซิร์ฟเวอร์ขนาด 1TB อยู่ระหว่าง 20,000 ถึง 50,000 กว่าเยนต่อเดือน และแบบคิดตามจำนวนผู้ใช้อยู่ราว 300 ถึง 900 เยนต่อเดือน

จากรายการนี้มีสองเรื่องที่ควรอ่านออก เรื่องแรกคือระหว่างบริการแบบคิดตามจำนวนผู้ใช้ด้วยกันเองมีช่องว่างด้านราคา และหนึ่งในปัจจัยของช่องว่างนั้นคือ ระยะเวลาเก็บรักษา ตัวอย่างชัดเจนคือส่วนต่างระหว่างการเก็บ 3 ปีกับการเก็บไม่จำกัดของ AvePoint Cloud Backup และยังมีบริการที่ราคาต่อหน่วยขยับตามขนาดองค์กรอย่าง Veeam Data Cloud for Microsoft 365 ด้วย ระยะเวลาเก็บรักษาไม่ได้ถูกกำหนดด้วย RPO แต่ถูกกำหนดด้วย “จะรู้ตัวเมื่อไร” การลบผิดพลาดหรือการทุจริตจากภายในบางครั้งเพิ่งถูกเปิดโปงหลังผ่านไปหลายเดือน เรื่องที่สองคือค่าบริการรายเดือนของเซิร์ฟเวอร์ 1TB แบบคิดตามความจุมีช่วงกว้างตั้งแต่ 20,000 ถึง 50,000 เยนกว่า ขนาด 1TB เท่ากันก็ขยับได้มากตามความถี่ในการสำรอง จำนวนรุ่นที่เก็บ และวิธีคิดค่าโอนถ่ายข้อมูลตอนกู้คืน เวลาขอใบเสนอราคา ขอให้ยืนยัน ค่าใช้จ่ายที่เกิดขึ้นตอนกู้คืน ด้วยเสมอ ไม่ใช่ดูแค่ความจุ โครงสร้างที่ค่าเก็บรักษาในภาวะปกติถูกแต่ค่าดึงข้อมูลออกแพงลิบ จะสร้างเหตุผลให้ลังเลที่จะกู้คืนในวินาทีสำคัญ

แกนการตัดสินใจสำหรับฐานการผลิตในไทย

แกนตัดสินว่าจะเลือกคลาวด์หรือออนพรีมิสสำหรับฐานการผลิตในไทยมี 3 ข้อ

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

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

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

การใช้ควบคู่กันคือรูปแบบพื้นฐาน

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

ตาราง B ต้นทุน 5 ชั้นของระบบสำรองข้อมูล

ถ้าดูค่าใช้จ่ายจากใบเสนอราคาก้อนเดียว จะแยกไม่ออกว่าข้อเสนอที่ถูกนั้น “ถูก” หรือ “ขอบเขตแคบ” จึงต้องแยกเป็นชั้น

สมมติฐานของโรงงานตัวอย่าง

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

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

เหตุผลและวิธีอ่านของแต่ละชั้น

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

ชั้นที่ 2 อ้างอิงจากค่าบริการแบบคิดตามจำนวนผู้ใช้ โดยใช้ระดับ 3,840 เยนต่อผู้ใช้ต่อปีของบริการที่เก็บย้อนหลัง 3 ปี คูณผู้ใช้ 40 คน ได้เป็น 153,600 เยน ถ้าเลือกยืดระยะเวลาเก็บรักษาเป็นไม่จำกัด ชั้นนี้ก็จะสูงขึ้น

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

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

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

ชั้นที่ตัดได้กับชั้นที่ตัดไม่ได้

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

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

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

ความสัมพันธ์ระหว่างกฎหมายคุ้มครองข้อมูลส่วนบุคคลของไทย (PDPA) กับระบบสำรองข้อมูล

การถกเรื่องการสำรองข้อมูลและ ดิแซสเตอร์รีคัฟเวอรี มักไหลไปทางเทคนิค แต่ในประเทศไทยเรื่องนี้เชื่อมกับข้อกำหนดทางกฎหมายโดยตรง

ข้อจำกัด 72 ชั่วโมง

กฎหมายคุ้มครองข้อมูลส่วนบุคคลของไทย (PDPA) กำหนดให้ผู้ควบคุมข้อมูลส่วนบุคคลต้องรายงานต่อคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (PDPC) ภายใน 72 ชั่วโมง นับแต่ทราบเหตุการละเมิดข้อมูล และหากมีความเสี่ยงที่จะกระทบสิทธิของบุคคล ต้องแจ้งเจ้าของข้อมูลส่วนบุคคลพร้อมกันไปกับการแจ้ง PDPC ด้วย โดยกรณีที่ผู้ได้รับผลกระทบมีหลายราย กำหนดให้ดำเนินการผ่านช่องทางสาธารณะ เช่น สื่อมวลชน

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

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

สถานะของ ISO 27001

อีกเรื่องที่ควรจับไว้คือ กระทรวงดิจิทัลเพื่อเศรษฐกิจและสังคมของไทย (MDES) ยอมรับการได้รับการรับรอง ISO 27001 เป็นหลักฐานว่าเป็นไปตามมาตรฐานความมั่นคงปลอดภัยขั้นต่ำ การได้ใบรับรองไม่ได้เป็นใบยกเว้นความผิดตามกฎหมาย แต่ใช้เป็นเครื่องมืออธิบายว่าเป็นไปตามมาตรฐานได้

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

เส้นแบ่งระหว่างดิแซสเตอร์รีคัฟเวอรีกับการสำรองข้อมูล

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

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

กลไกที่ทำให้การซ้อมกู้คืน (Restore Test) ไม่กลายเป็น “พิธีกรรม”

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

เส้นทางคลาสสิกที่ทำให้กลายเป็นพิธีกรรม

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

วิธีป้องกันการกลายเป็นพิธีกรรมไม่ใช่การเพิ่มจำนวนครั้งของการซ้อม แต่คือ การนิยามเกณฑ์ผ่านหรือไม่ผ่านของการซ้อมด้วยตัวเลข

เขียนเกณฑ์ผ่านด้วย RTO และ RPO

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

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

4 รายการที่ต้องบันทึก

ขอให้กำหนดรายการที่ต้องบันทึกทุกครั้งที่ซ้อมไว้ตายตัว 4 รายการ ได้แก่ เวลาที่วัดได้จริงตั้งแต่เริ่มจนกลับมาเปิดดำเนินงาน ข้อมูล ณ จุดเวลาที่กู้คืนได้ (RPO ที่วัดได้จริง) งานที่ติดขัดระหว่างทางพร้อมเวลาที่ใช้ไป และจุดที่ข้อความในคู่มือกับงานจริงไม่ตรงกัน

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

ให้ใครเป็นคนทำ

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

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

ประเด็นเฉพาะของระบบบริหารการผลิตและระบบงานหลัก – การผูกกับต้นทุนโรงงานหยุด

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

คำนวณต้นทุนโรงงานหยุดด้วยตัวเลขของบริษัทตัวเอง

เวลาอธิบายความสมเหตุสมผลของ RTO ต่อผู้บริหาร หลักฐานที่แข็งแรงที่สุดคือต้นทุนของการหยุด ตรงนี้ค่าเฉลี่ยของบริษัทอื่นไม่มีความหมาย จำเป็นต้องคำนวณด้วยตัวเลขของบริษัทตัวเอง

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

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

ความยากเฉพาะตัวของการกู้คืนระบบบริหารการผลิต

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

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

กำหนดลำดับการกู้คืนไว้ล่วงหน้า

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

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

ช่องว่างระหว่างมาตรฐานสำนักงานใหญ่กับฐานการผลิตในพื้นที่ – 3 รูรั่วที่เกิดในฐานต่างประเทศ

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

รูรั่วที่ 1 – มาตรฐานไม่ได้เผื่อโครงสร้างของพื้นที่

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

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

รูรั่วที่ 2 – การรายงานหยุดอยู่แค่ “ดำเนินการอยู่”

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

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

รูรั่วที่ 3 – อำนาจการกู้คืนไม่ได้อยู่ในพื้นที่

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

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

ลำดับการเริ่มดำเนินการ – 90 วันแรก

การทบทวนระบบถ้าขยายขอบเขตจะลงจอดไม่ได้ จึงขอเสนอวิธีเดินเรื่องที่ตัดแบ่งด้วยกรอบ 90 วัน

30 วันแรก – นับสถานะปัจจุบัน

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

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

วันที่ 31 ถึงวันที่ 60 – ทำตาราง 2 ใบ

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

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

วันที่ 61 ถึงวันที่ 90 – ซ้อมกับ 1 ระบบ

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

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

หลัง 90 วัน

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

5 ความผิดพลาดที่พบบ่อย

ขอจัดระเบียบความผิดพลาดที่พบซ้ำ ๆ ในการสร้างระบบ

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

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

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

ทำไมระบบสำรองข้อมูลระบบธุรกิจจึงสำคัญ

สิ่งที่สำคัญไม่ใช่การสำรองข้อมูล แต่คือการกู้คืนได้จากชุดสำรองนั้น ในผลสำรวจแนวโน้มการใช้ประโยชน์จาก IT ขององค์กร ปี 2026 ของ JIPDEC อัตราที่เคยติดแรนซัมแวร์อยู่ที่ 45.8% และสัดส่วนที่กู้คืนไม่ได้โดยไม่จ่ายค่าไถ่อยู่ที่ 13.0% ซึ่งเพิ่มขึ้นจากการสำรวจครั้งก่อนที่ 10.5% ในภาคการผลิตอัตราที่เคยติดสูงกว่านั้นอีกที่ 57.1% และสัดส่วนที่กู้คืนล้มเหลวแม้จ่ายค่าไถ่ไปแล้วอยู่ที่ 18.2% การจ่ายเงินไม่ใช่หลักประกันของการกู้คืน การทำให้ตัวเองอยู่ในสภาพที่กู้คืนได้ด้วยกำลังตนเองจึงเป็นเงื่อนไขตั้งต้นของความต่อเนื่องทางธุรกิจ

RTO กับ RPO ต่างกันอย่างไร

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

ค่าใช้จ่ายของการสำรองข้อมูลขึ้นคลาวด์อยู่ที่เท่าไร

ตัวอย่างค่าบริการที่ถูกเปิดเผยระบุว่า แบบคิดตามความจุ ขนาด 100GB เริ่มต้นที่ 3,000 เยนต่อเดือน (36,200 เยนต่อปี) และขนาด 1TB เริ่มต้นที่ 20,000 เยนต่อเดือน ส่วนบริการแบบคิดตามจำนวนผู้ใช้สำหรับ Microsoft 365 มีตั้งแต่ระดับเริ่มต้น 3,840 เยนต่อผู้ใช้ต่อปี ไปจนถึงระดับ 9,822 ถึง 10,913 เยนต่อปี ระดับราคาโดยทั่วไปมักถูกอ้างอิงว่า เครื่อง PC หนึ่งเครื่องเริ่มต้นราว 1,000 เยนต่อเดือน เซิร์ฟเวอร์ 1TB อยู่ระหว่าง 20,000 ถึง 50,000 กว่าเยนต่อเดือน และแบบคิดตามจำนวนผู้ใช้อยู่ราว 300 ถึง 900 เยนต่อเดือน ในการประมาณการของโรงงานตัวอย่างในบทความนี้ เมื่อรวมค่าใช้พื้นที่จัดเก็บและการสำรอง Microsoft 365 เข้ากับชั่วโมงงานซ้อม สภาพแวดล้อมสแตนด์บาย และการจัดทำเอกสารตรวจสอบแล้ว จำนวนเงินต่อปีอยู่ที่ 1,669,600 เยน

การสำรองข้อมูลกับดิแซสเตอร์รีคัฟเวอรีต่างกันอย่างไร

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

ควรซ้อมกู้คืนบ่อยแค่ไหน

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

สรุป

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

ไม่มีเหตุผลใดที่ฐานการผลิตในไทยจะเป็นข้อยกเว้น ในบรรดากรณีการโจมตีด้วยแรนซัมแวร์ที่ถูกเปิดเผยระหว่างเดือนกรกฎาคมถึงกันยายน 2024 กว่า 1,230 กรณี มี 13% เกิดขึ้นในภูมิภาคเอเชียแปซิฟิก และความเสียหายภายในประเทศไทยในปี 2023 เพิ่มขึ้นเป็น 1.5 เท่าเมื่อเทียบกับปี 2022 ความเสียหายของฐานการผลิตสัญชาติญี่ปุ่นก็มีรายงานข้ามหลายปีทั้งในไทย มาเลเซีย อินโดนีเซีย และเวียดนาม อัตราที่เคยติดแรนซัมแวร์ของภาคการผลิตอยู่ที่ 57.1% และสัดส่วนที่กู้คืนล้มเหลวแม้จ่ายค่าไถ่ไปแล้วอยู่ที่ 18.2%

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

ใจกลางของการออกแบบคือ RTO และ RPO ให้เปลี่ยนตัวเลขตามประเภทงานแทนการใช้ค่าเดียวทั้งองค์กร โดยประกอบขึ้นเป็น ระบบงานหลักใช้ RPO ภายใน 1 ชั่วโมงและ RTO ภายใน 4 ชั่วโมง ด้วยการทำสองชั้นทั้งคลาวด์และออนพรีมิสพร้อมสแนปช็อตแบบแก้ไขลบไม่ได้ ระบบควบคุมสายการผลิตและ SCADA ใช้ RPO ภายใน 24 ชั่วโมงและ RTO ภายในวันทำการถัดไป ด้วย NAS ภายในโรงงานร่วมกับการซิงก์ขึ้นคลาวด์รายสัปดาห์ ไฟล์ที่ใช้ร่วมกันและแบบแปลนใช้ระดับเดียวกันด้วยการสำรองขึ้นคลาวด์แบบเก็บย้อนหลัง 3 รุ่น และอีเมลกับกรุ๊ปแวร์ใช้ภายในไม่กี่ชั่วโมงด้วยบริการสำรองข้อมูลสำหรับ SaaS

ค่าใช้จ่ายแบ่งได้เป็น 5 ชั้น ในการประมาณการของโรงงานตัวอย่างประกอบด้วย ค่าใช้พื้นที่จัดเก็บ 240,000 เยน การสำรอง Microsoft 365 จำนวน 153,600 เยน การซ้อมกู้คืนและชั่วโมงงานปฏิบัติการ 256,000 เยน สภาพแวดล้อมสแตนด์บายสำหรับดิแซสเตอร์รีคัฟเวอรี 720,000 เยน และการจัดทำเอกสารรองรับการตรวจสอบและ PDPA 300,000 เยน รวมทั้งสิ้น 1,669,600 เยน ในจำนวนนี้ชั้นที่ถูกตัดง่ายที่สุดคือชั้นที่ 4 แต่ขอให้เขียนย้อนกลับลงในตารางว่าสิ่งที่ตัดไม่ใช่ค่าใช้จ่าย หากคือคำสัญญาเรื่อง RTO

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

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

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

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

• ข่าวประชาสัมพันธ์ผลสำรวจแนวโน้มการใช้ประโยชน์จาก IT ขององค์กร ปี 2026 – JIPDEC ช่วงสำรวจ 16 ถึง 20 มกราคม 2026 บริษัทในญี่ปุ่นที่มีพนักงาน 50 คนขึ้นไป จำนวน 1,107 บริษัท อัตราที่เคยติดแรนซัมแวร์ 45.8% ภาคการผลิต 57.1% สัดส่วนที่กู้คืนไม่ได้โดยไม่จ่ายค่าไถ่ 13.0% ครั้งก่อน 10.5% ระยะเวลากู้คืนที่พบมากที่สุดคือ 1 สัปดาห์ถึงภายใน 1 เดือน 34.7% ข้อมูลสูญหายหรือเสียหาย 51.3% ความลับรั่วไหล 35.1% ครั้งก่อน 29.3% ภาคการผลิตกู้คืนล้มเหลวแม้จ่ายค่าไถ่แล้ว 18.2%
• แนวโน้มความเสียหายจากแรนซัมแวร์ในอาเซียน – Risk Management Navi การรวบรวมของ Check Point Software Technologies ระบุว่ากรณีที่เปิดเผยระหว่างกรกฎาคมถึงกันยายน 2024 กว่า 1,230 กรณี มี 13% อยู่ในภูมิภาคเอเชียแปซิฟิก สำนักงานคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติของไทยระบุว่าความเสียหายในไทยปี 2023 เพิ่มเป็น 1.5 เท่าของปี 2022 ความเสียหายของฐานการผลิตสัญชาติญี่ปุ่นเกิดในไทยปี 2022 ถึง 2024 มาเลเซียปี 2022 ถึง 2023 อินโดนีเซียปี 2021 และ 2024 เวียดนามปี 2024
• การรับมือการโจมตีทางไซเบอร์และการสำรองข้อมูลของ Nichirei – london3.jp การตรวจพบเมื่อเวลาประมาณ 6.50 น. ของวันที่ 13 กรกฎาคม 2026 และการตั้งศูนย์บัญชาการฉุกเฉิน การตัดการเชื่อมต่อระบบทั้งกลุ่มเป็นการฉุกเฉิน การรอดอยู่ของระบบสำรองข้อมูลที่แยกจากเครือข่ายโปรดักชันทั้งเชิงตรรกะและเชิงกายภาพ การทยอยเปิดงานจัดส่งตั้งแต่วันที่ 17 กรกฎาคม 2026 แนวโน้มกลับสู่การเดินงานปกติในราว 1 สัปดาห์ และการเดินงานแบบลดทอนด้วยใบส่งของเขียนมือ
• คำอธิบายกฎหมายคุ้มครองข้อมูลส่วนบุคคลของไทย PDPA – LOGON International หน้าที่รายงานต่อ PDPC ภายใน 72 ชั่วโมงนับแต่ทราบเหตุการละเมิดข้อมูล การแจ้งเจ้าของข้อมูลส่วนบุคคลเมื่อมีความเสี่ยงต่อสิทธิของบุคคล การแจ้งผ่านช่องทางสาธารณะเมื่อผู้ได้รับผลกระทบมีหลายราย และการที่กระทรวงดิจิทัลเพื่อเศรษฐกิจและสังคมยอมรับ ISO 27001 เป็นหลักฐานว่าเป็นไปตามมาตรฐานความมั่นคงปลอดภัยขั้นต่ำ
• ระดับราคาค่าใช้จ่ายของการสำรองข้อมูลขึ้นคลาวด์ – Security Software Comparison Compe แบบคิดตามความจุ 100GB เริ่มต้น 3,000 เยนต่อเดือน หรือ 36,200 เยนต่อปี 1TB เริ่มต้น 20,000 เยนต่อเดือน Veeam Data Cloud for Microsoft 365 อยู่ที่ 9,822 ถึง 10,913 เยนต่อผู้ใช้ต่อปี AvePoint Cloud Backup เก็บ 3 ปี เริ่มต้น 3,840 เยนต่อปี เก็บไม่จำกัด เริ่มต้น 6,000 เยนต่อปี SysCloud 5,890 เยนต่อผู้ใช้ต่อปี เครื่อง PC หนึ่งเครื่องเริ่มต้นราว 1,000 เยนต่อเดือน เซิร์ฟเวอร์ 1TB อยู่ระหว่าง 20,000 ถึง 50,000 กว่าเยนต่อเดือน แบบคิดตามจำนวนผู้ใช้ราว 300 ถึง 900 เยนต่อเดือน