TOR ย้ายระบบขึ้น Cloud ภาครัฐ ควรระบุอะไรบ้าง

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

บทความนี้เขียนสำหรับเจ้าหน้าที่ IT คณะกรรมการจัดทำร่างขอบเขตของงาน (TOR) และเจ้าหน้าที่พัสดุของหน่วยงานรัฐที่กำลังจะจ้างย้ายระบบขึ้นคลาวด์ เนื้อหาเน้นการเปลี่ยนเรื่องทางเทคนิคให้เป็นข้อกำหนดและหลักฐานตรวจรับ ส่วนวิธีย้ายระบบ ต้นทุน และ cloud region ในไทยอยู่ใน คู่มือ Cloud Migration ในไทย วิธีจัดซื้อจัดจ้างและหัวข้อ TOR งานซอฟต์แวร์ทั่วไปอยู่ในคู่มือจ้างพัฒนาระบบ IT ภาครัฐ และ TOR สำหรับจ้างดูแลระบบเดิมอยู่ใน TOR จ้างดูแลระบบเดิม เอกสารทางการที่อ้างถึงตรวจ ณ วันที่ 7 พฤศจิกายน 2026 (พ.ศ. 2569) กติกาคลาวด์ภาครัฐหลายเรื่องยังเป็นร่างและเปลี่ยนมาแล้วหลายครั้ง

TOR ย้ายระบบขึ้นคลาวด์ต่างจาก TOR จ้างพัฒนาหรือจ้างดูแลระบบอย่างไร?

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

ความต่างนี้ทำให้ TOR ต้องมีสี่เรื่องที่ TOR ประเภทอื่นมักไม่มี

• ปลายทางและชั้นข้อมูล ระบบใดไปอยู่บนบริการแบบใด และข้อมูลชั้นใดต้องเก็บในประเทศ
• แผนย้ายที่ถอยกลับได้ ระบบนำร่อง ช่วงหยุดระบบ เกณฑ์ go/no-go เกณฑ์ rollback และการเดินระบบคู่ขนาน
• หลักฐานว่าข้อมูลย้ายครบและถูกต้อง ไม่ใช่เพียงหน้าจอที่เปิดได้
• ต้นทุนหลังย้ายและการออกจากผู้ให้บริการ ใครจ่ายค่าคลาวด์ ข้ามปีงบประมาณอย่างไร และย้ายออกได้อย่างไร

ก่อนร่าง TOR หน่วยงานต้องรู้กติกาคลาวด์ภาครัฐเรื่องใดบ้าง?

กติกาที่เกี่ยวข้องมีทั้งที่มีผลบังคับแล้วและที่ยังเป็นร่าง ตารางนี้สรุปสถานะ ณ วันที่ 7 พฤศจิกายน 2569 จากเอกสารที่เราตรวจได้ ไม่ใช่รายการครบทุกฉบับ

ที่มาของนโยบายคือ คณะกรรมการดิจิทัลเพื่อเศรษฐกิจและสังคมแห่งชาติ ครั้งที่ 1/2566 (22 ธันวาคม 2566) เห็นชอบแนวทางการขับเคลื่อนนโยบายการใช้คลาวด์เป็นหลัก (Cloud First Policy) ในระยะ 5 ปี ตามที่อ้างไว้ในภาคผนวกของมาตรฐานคลาวด์ของ กกม. เราไม่พบมติคณะรัฐมนตรีเรื่อง Cloud First ที่ตรวจจากแหล่งทางการได้ จึงไม่อ้างวันที่ของมติดังกล่าว

ตามเอกสารประกอบการประชุมกลุ่มย่อยของสำนักงานพัฒนารัฐบาลดิจิทัล (สพร.) (24 ธันวาคม 2568) มติครั้งที่ 3/2568 ยังมอบหมายให้กระทรวงดิจิทัลเพื่อเศรษฐกิจและสังคม (ดศ.) เป็นผู้บริหารจัดการบริการคลาวด์ภาครัฐ (Government Cloud Management) และนิยาม National Cloud ว่าเป็นการรวมระบบคลาวด์กลางภาครัฐ (GDCC) กับคลาวด์ของหน่วยงานรัฐ ภายใต้มาตรฐานเดียวกัน โดยเชื่อมทุกระบบเข้ากับระบบบริหารจัดการคลาวด์กลาง (Cloud Management Platform หรือ CMP) ของ ดศ. เอกสารเดียวกันแสดงว่าแนวทางเปลี่ยนไประหว่างปี 2568 เช่น การประชุมครั้งที่ 1/2568 (21 กรกฎาคม 2568) ให้ใช้ Sovereign Cloud กับข้อมูลชั้นลับมากและลับที่สุด แต่ตารางจำแนกข้อมูลที่เห็นชอบเมื่อ 28 พฤศจิกายน 2568 เหลือเฉพาะชั้นลับที่สุด บทความนี้อ้างฉบับล่าสุดที่ตรวจได้ และกติกาอาจเปลี่ยนอีก ก่อนร่างให้ยืนยันกับ สพร. สำนักงานคณะกรรมการดิจิทัลเพื่อเศรษฐกิจและสังคมแห่งชาติ (สดช.) และเจ้าหน้าที่งบประมาณของหน่วยงาน

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

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

ให้งวดแรกเป็นงานสำรวจและออกแบบ ส่งมอบรายการระบบที่ยืนยันจากของจริง แผนผังความเชื่อมโยงที่ตรวจกับการใช้งานจริง เช่น การเชื่อมต่อเครือข่ายและ log แผนการย้ายแยกเป็นกลุ่ม (wave) และรายงานส่วนที่ต่างจาก TOR การเลือกว่าระบบใดควรย้ายแบบเดิมหรือควรปรับสถาปัตยกรรม อยู่ใน ย้ายระบบเก่าสู่ Cloud-Native ถ้าการสำรวจพบงานมากกว่าที่ TOR ระบุ ให้เขียนไว้ล่วงหน้าว่าจะจัดการอย่างไร เพราะการแก้สัญญากลางทางทำได้จำกัดตามมาตรา 97 ของ พ.ร.บ. การจัดซื้อจัดจ้างฯ ตามที่อธิบายไว้ในบทความ TOR จ้างดูแลระบบเดิม

ร่างมาตรฐานแนวทางการใช้คลาวด์ของ สพร. (ธันวาคม 2568) แบ่งการย้ายระบบเป็นสี่ขั้น คือ ประเมินความเสี่ยงและต้นทุนระยะยาวเทียบกับการคงระบบเดิม เลือกรูปแบบการย้าย ย้ายและทดสอบทีละขั้น และบริหารหลังย้าย ทั้งการคุมต้นทุนเทียบงบและการปรับระบบต่อเนื่อง ลำดับนี้สอดคล้องกับตัวอย่างการแบ่งเป็นห้างวดในหัวข้อการตรวจรับด้านล่าง

เขียนปลายทางอย่างไรโดยไม่ระบุยี่ห้อ?

พ.ร.บ. การจัดซื้อจัดจ้างและการบริหารพัสดุภาครัฐ พ.ศ. 2560 มาตรา 9 ห้ามกำหนดคุณลักษณะเฉพาะของพัสดุให้ใกล้เคียงกับยี่ห้อใดยี่ห้อหนึ่งหรือผู้ขายรายใดรายหนึ่งโดยเฉพาะ เว้นแต่พัสดุนั้นมียี่ห้อเดียวหรือต้องใช้อะไหล่ของยี่ห้อใด TOR จึงควรกำหนดปลายทางเป็นคุณลักษณะที่ต้องการ เช่น ที่ตั้งของข้อมูลขณะจัดเก็บ ชนิดบริการ (IaaS, PaaS หรือ SaaS) หลักฐานรับรองที่ต้องแสดง การเชื่อมต่อกับระบบที่กำหนด และเงื่อนไขการย้ายข้อมูลออก ไม่ใช่ชื่อผู้ให้บริการหรือชื่อบริการ ข้อความแต่ละข้อขัดกับมาตรา 9 หรือไม่ ให้หน่วยพัสดุพิจารณา

ปลายทางที่หน่วยงานรัฐเลือกได้แบ่งเป็นสามกลุ่ม

• ระบบคลาวด์กลางภาครัฐ (Government Data Center and Cloud service หรือ GDCC) ตามข่าวของ NT (14 มีนาคม 2566) สดช. มอบหมายให้ บมจ. โทรคมนาคมแห่งชาติ (NT) ดำเนินการ และหน่วยงานขอใช้ผ่านระบบ GDCC Smart Request Service เราตรวจสถานะผู้ดำเนินการและเงื่อนไขบริการปี 2569 ไม่ได้ ให้ยืนยันกับ สดช. โดยตรง ถ้าปลายทางเป็น GDCC ให้ TOR แยกให้ชัดว่าส่วนใดหน่วยงานขอใช้จาก GDCC เอง ส่วนใดเป็นงานของผู้รับจ้าง ทรัพยากรพร้อมเมื่อใด และใครเป็นผู้ประสาน
• คลาวด์ที่หน่วยงานจัดหาเอง รวมถึงผู้ให้บริการที่มี region ในไทย (รายการและสถานะอยู่ในตาราง cloud region ในไทย) ใช้ได้เมื่อเข้าเงื่อนไขของแนวทางจัดหาปีนั้น และต้องเชื่อมต่อ CMP ตามแนวทางปี 2570 (ดูหัวข้อค่าใช้จ่ายด้านล่าง)
• ศูนย์ข้อมูลของหน่วยงานหรือแบบผสม (hybrid) สำหรับระบบที่ยังไม่ควรย้าย หรือข้อมูลที่ต้องอยู่ในการควบคุมของหน่วยงาน

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

ชั้นของข้อมูลกำหนดปลายทางและที่ตั้งข้อมูลอย่างไร?

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

หมายเหตุของตารางมีสองข้อที่ควรนำไปเขียนใน TOR ข้อแรก "ข้อมูลที่ควรอยู่ในประเทศไทย" หมายถึงข้อมูลที่จัดเก็บในสถานะพัก (data at rest) ไม่รวมข้อมูลระหว่างรับส่งหรือระหว่างประมวลผล TOR จึงควรระบุที่ตั้งของข้อมูลขณะจัดเก็บ รวมถึง backup, snapshot และ log ไม่ใช่เพียงที่ตั้งของเครื่อง ข้อสอง ถ้าหน่วยงานปรับหรือยกเลิกชั้นความลับภายหลัง ปรับรูปแบบการใช้คลาวด์ตามชั้นใหม่ได้ ซึ่งเป็นเหตุผลอีกข้อที่ต้องมีข้อออกจากระบบ

แนวทาง National Cloud ให้ข้อมูลภาครัฐจัดเก็บในราชอาณาจักรไทยเป็นหลัก ถ้าจำเป็นต้องใช้บริการที่เก็บข้อมูลนอกประเทศ เช่น ไม่มีบริการเทียบเคียงในประเทศ หรือเพื่อการสำรองข้อมูล (disaster recovery) ให้อยู่ในดุลยพินิจของหัวหน้าส่วนราชการ โดยต้องกำกับดูแลให้ความเป็นเจ้าของ อำนาจควบคุม และการบริหารจัดการข้อมูลยังอยู่ภายใต้กฎหมายไทย ในระยะแรกแนวทางนี้ยกเว้นระบบด้านความมั่นคงและบริการโครงสร้างพื้นฐานสำคัญทางสารสนเทศ (CII) ออกจากเกณฑ์ปกติไว้ก่อน ถ้าระบบมีข้อมูลส่วนบุคคล การส่งข้อมูลไปต่างประเทศยังต้องเป็นไปตาม PDPA มาตรา 28 และ 29 ซึ่งสรุปไว้แล้วในหัวข้อข้อมูลต้องอยู่ในไทยไหม ระบบที่ดึงข้อมูลประชาชนจากหลายหน่วยงาน เช่น ระบบสารสนเทศสวัสดิการ ควรจัดชั้นข้อมูลให้เสร็จก่อนเลือกปลายทาง

ข้อกำหนดด้านความปลอดภัยควรเขียนอะไร?

มาตรฐานคลาวด์ของ กกม. ที่มีผลแล้ว

ประกาศคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ เรื่อง มาตรฐานด้านการรักษาความมั่นคงปลอดภัยไซเบอร์ระบบคลาวด์ พ.ศ. 2567 ประกาศในราชกิจจานุเบกษา เล่ม 141 ตอนพิเศษ 248 ง วันที่ 10 กันยายน 2567 และประกาศ สกมช. เรื่อง แผนบูรณาการเพื่อขับเคลื่อนการดำเนินการตามมาตรฐานฯ พ.ศ. 2569–2573 (7 สิงหาคม 2569) ระบุว่ามาตรฐานนี้มีผลบังคับใช้ 10 กันยายน 2569 ซึ่งตรงกับข้อ 2 ของประกาศในราชกิจจานุเบกษาที่ให้ใช้บังคับเมื่อพ้นกำหนดสองปีนับแต่วันประกาศ สาระที่กระทบ TOR ตามสำเนาประกาศพร้อมภาคผนวก (สำเนาก่อนประกาศในราชกิจจานุเบกษา ข้อ 2 ในสำเนานี้ยังเขียนว่าหนึ่งปี ให้ยึดฉบับในราชกิจจานุเบกษา) มีดังนี้

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

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

ตารางแบ่งความรับผิดชอบ

ผู้ให้บริการคลาวด์รายใหญ่อธิบายหลักความรับผิดชอบร่วม (shared responsibility model) ในแนวเดียวกัน AWS ระบุว่าความรับผิดชอบของลูกค้าขึ้นกับบริการที่เลือก Google Cloud ระบุว่าใน IaaS ความรับผิดชอบด้านความปลอดภัยส่วนใหญ่เป็นของลูกค้า และ Huawei Cloud ระบุว่าผู้เช่าดูแลการตั้งค่าบริการ เครือข่ายเสมือน ระบบปฏิบัติการ ข้อมูล บัญชี และการจัดการกุญแจ ร่างมาตรฐานของ สพร. อ้างแบบจำลองของ NCSC สหราชอาณาจักร ซึ่งอธิบายว่าส่วนที่ลูกค้าต้องดูแลลดลงเมื่อเปลี่ยนจาก IaaS ไป SaaS

เมื่องานย้ายระบบมีสามฝ่าย คือหน่วยงาน ผู้รับจ้าง และผู้ให้บริการคลาวด์ TOR ควรมีตารางที่ระบุผู้รับผิดชอบของแต่ละส่วน ทั้งระหว่างโครงการและหลังส่งมอบ

หลักฐานรับรองของผู้ให้บริการคลาวด์

ตามเอกสารของ สพร. แนวทางการขึ้นทะเบียนผู้ให้บริการคลาวด์ที่คณะกรรมการพัฒนารัฐบาลดิจิทัลเห็นชอบเมื่อ 28 พฤศจิกายน 2568 แบ่งเป็นสามระดับ ระดับ 1 ใช้ CSA STAR, ISO/IEC 27001, ISO/IEC 20000 และ ISO/IEC 27701 และให้บริการข้อมูล Official ระดับ 2 เพิ่ม ISO/IEC 27017 และ ISO/IEC 27018 และให้บริการข้อมูล Official กับ Protected ได้ ระดับ 3 เพิ่มมาตรการเฉพาะ เช่น เครือข่ายที่แยกออก (isolated network) และให้บริการเฉพาะข้อมูล Highly Protected การรับรองมีอายุ 3 ปี มติเดียวกันให้ สพร. ปรับปรุงร่างมาตรฐานที่เกี่ยวข้องและเสนอคณะกรรมการฯ เห็นชอบก่อนประกาศบังคับใช้ มาตรฐานที่จะทำให้เกณฑ์นี้มีผลบังคับจึงยังเป็นร่าง ถ้า TOR จะขอหลักฐานเหล่านี้ ควรเขียนให้ตรงกับลักษณะของแต่ละมาตรฐาน

• ISO/IEC 27001:2022 เป็นมาตรฐานข้อกำหนดของระบบบริหารความมั่นคงปลอดภัยสารสนเทศที่ตรวจรับรองได้ ให้ขอใบรับรองพร้อมขอบเขตการรับรองที่ครอบคลุมบริการและพื้นที่ให้บริการที่จะใช้
• ISO/IEC 27017 (ฉบับปัจจุบันคือ ISO/IEC 27017:2026 ฉบับที่ 2 เผยแพร่ 27 กรกฎาคม 2026) และ ISO/IEC 27018:2025 เป็นแนวทางมาตรการควบคุมสำหรับบริการคลาวด์และการคุ้มครองข้อมูลส่วนบุคคลบนคลาวด์สาธารณะ ให้ขอหลักฐานว่าการตรวจประเมินครอบคลุมมาตรการตามเอกสารเหล่านี้ และระบุว่ายอมรับฉบับใด เพราะใบรับรองที่ออกไปแล้วอาจอ้างฉบับเก่า
• CSA STAR ระดับ 1 เป็นการประเมินตนเอง ระดับ 2 เป็นการตรวจโดยบุคคลที่สาม ให้ระบุระดับที่ต้องการและตรวจรายชื่อใน STAR Registry ได้

ข้อมูลส่วนบุคคลที่ผู้รับจ้างเข้าถึงระหว่างย้ายระบบ ให้มีข้อตกลงการประมวลผลข้อมูล (DPA) ตามหัวข้อในคู่มือจ้างพัฒนาระบบ IT ภาครัฐ

แผนย้ายระบบใน TOR ต้องมีอะไรบ้าง?

กลไกของ cutover และ rollback เช่น การซ้อม การลด DNS TTL และการ sync ข้อมูลล่วงหน้า อธิบายไว้แล้วในหัวข้อวางแผน cutover และ rollback สิ่งที่ TOR ต้องทำคือเปลี่ยนกลไกเหล่านั้นเป็นข้อกำหนดที่มีตัวเลขของหน่วยงานและมีหลักฐาน

• ระบบนำร่อง (pilot) ระบุว่าย้ายระบบใดก่อน หรือให้ผู้รับจ้างเสนอในงวดสำรวจ พร้อมเกณฑ์ผ่านที่เขียนไว้ก่อนเริ่ม ผลของระบบนำร่องใช้ปรับแผนของ wave ถัดไป
• ช่วงหยุดระบบ (cutover window) ระบุช่วงวันเวลาที่หน่วยงานยอมให้หยุดได้ของแต่ละระบบ [__ ชั่วโมง ในช่วง __] และนิยามว่าอะไรนับเป็นการหยุด เช่น ผู้ใช้ทำธุรกรรมหลักไม่ได้
• เกณฑ์ go/no-go รายการตรวจก่อนสลับระบบ ผู้มีอำนาจตัดสินใจ และเวลาสุดท้ายที่ยังถอยกลับได้
• เกณฑ์ rollback เงื่อนไขที่ต้องถอยกลับ เช่น ข้อมูลกระทบยอดไม่ตรง ธุรกรรมสำคัญทดสอบไม่ผ่าน หรือเกินช่วงหยุดที่ประกาศ และวิธีนำข้อมูลที่เกิดบนปลายทางกลับไประบบเดิม ให้ซ้อม rollback อย่างน้อยหนึ่งครั้งก่อนวันจริง
• การเดินระบบคู่ขนาน (parallel run) สำหรับระบบที่ต้องเทียบผลลัพธ์ ระบุระยะเวลา [__] ระบบใดเป็นข้อมูลหลักระหว่างนั้น วิธีเทียบผล และใครจ่ายค่าทรัพยากรที่เดินซ้อนกัน
• การกระทบยอดข้อมูล (data reconciliation) นับจำนวนระเบียนและ checksum ต่อตาราง เทียบยอดรวมของข้อมูลที่เป็นตัวเลข และให้เจ้าของข้อมูลสุ่มตรวจรายการทางธุรกิจ ผลต้องออกเป็นรายงานที่ลงนาม
• ช่วงดูแลใกล้ชิดหลังย้าย (hypercare) และการปิดระบบเดิม ระบุระยะเวลา [__] และเงื่อนไขก่อนปิดระบบเดิม เช่น พ้นช่วงที่ถอยกลับได้ และทดสอบกู้คืน backup บนปลายทางผ่านแล้ว

RTO และ RPO ใน TOR

ให้ใช้นิยามที่ตรวจได้ เช่น ตาม NIST SP 800-34 Rev. 1 RPO คือจุดเวลาที่ข้อมูลต้องกู้คืนได้ถึงหลังเกิดเหตุ และ RTO คือระยะเวลารวมสูงสุดที่ระบบอยู่ระหว่างการกู้คืนได้ ก่อนจะกระทบภารกิจขององค์กร ตัวเลขให้หน่วยงานกำหนดจากผลกระทบและงบประมาณ เช่น "RTO ไม่เกิน [__ ชั่วโมง] และ RPO ไม่เกิน [__ นาที] สำหรับระบบ __" ตัวเลขในวงเล็บเป็นช่องให้เติม ไม่ใช่ค่าที่เราแนะนำ และให้ผลทดสอบกู้คืนบนปลายทางเป็นหลักฐานว่าทำได้จริง

หลีกเลี่ยงคำว่า "ไม่มีการหยุดให้บริการ (zero downtime)" ถ้าไม่มีนิยามและวิธีวัด เพราะกรรมการตรวจไม่ได้ และผู้ยื่นข้อเสนอจะตีราคาเผื่อความเสี่ยงที่ไม่รู้ขนาด

คณะกรรมการตรวจรับควรตรวจอะไรในแต่ละงวด?

ระเบียบกระทรวงการคลังว่าด้วยการจัดซื้อจัดจ้างและการบริหารพัสดุภาครัฐ พ.ศ. 2560 ข้อ 175 (2) ให้คณะกรรมการตรวจรับพัสดุตรวจให้ถูกต้องครบถ้วน "ตามหลักฐานที่ตกลงกันไว้" และถ้ามีการตรวจสอบทางเทคนิค อาจเชิญผู้ชำนาญการหรือผู้ทรงคุณวุฒิมาให้คำปรึกษาได้ ส่วนข้อ 27 ให้มติของคณะกรรมการตรวจรับเป็นเอกฉันท์ (รายละเอียดอยู่ในบทความ TOR จ้างดูแลระบบเดิม) งานย้ายระบบจึงควรมีหลักฐานรายงวดที่กรรมการทุกคนตรวจได้ตรงกัน ตัวอย่างการแบ่งงวด:

ถ้างวดใดต้องตรวจทางเทคนิคต่อหน้ากรรมการ เช่น สร้างสภาพแวดล้อมใหม่จาก Infrastructure as Code หรือกู้คืน backup ให้เขียนวิธีตรวจไว้ใน TOR เพื่อให้ทั้งกรรมการและผู้รับจ้างเตรียมได้ตรงกัน ก่อนใช้งานจริงให้ยืนยันฉบับล่าสุดของระเบียบฯ กับหน่วยพัสดุ

ข้อออกจากระบบและการกันผูกขาดควรเขียนอย่างไร?

ร่างมาตรฐานแนวทางการใช้คลาวด์ของ สพร. ให้วางแผนออกจากระบบคลาวด์ (cloud exit) ตั้งแต่ขั้นวางแผนการย้าย เพื่อป้องกันการผูกขาดกับผู้ให้บริการรายเดียว (vendor lock-in) สัญญาควรกำหนดเรื่องการส่งคืนข้อมูล ระยะเวลาเก็บรักษา การสนับสนุนหลังยกเลิก ค่าใช้จ่าย และการเคลื่อนย้ายข้อมูล ข้อมูลต้องอยู่ในรูปแบบที่ย้ายข้ามระบบได้ ต้องทดสอบการถ่ายโอนและตรวจความสมบูรณ์ แล้วลบข้อมูลจากระบบเดิมอย่างปลอดภัยตามกฎหมายคุ้มครองข้อมูลส่วนบุคคล พร้อมตรวจและรายงานผลการทำลายข้อมูล ร่างนี้ยังไม่ใช่มาตรฐานที่ใช้อ้างได้ แต่ข้อออกจากระบบด้านล่างเป็นเรื่องที่ TOR ควรมีอยู่แล้วไม่ว่ามาตรฐานจะออกเมื่อใด

• การส่งคืนข้อมูล รูปแบบไฟล์ที่ใช้ได้โดยไม่ต้องพึ่งบริการเฉพาะของผู้ให้บริการ ระยะเวลาที่ต้องส่งคืน [__ วัน] และใครจ่ายค่าส่งข้อมูลออก
• การตั้งค่าระบบที่สร้างใหม่ได้ Infrastructure as Code หรือเอกสารการตั้งค่าที่ครบพอให้ผู้รับจ้างรายอื่นสร้างสภาพแวดล้อมใหม่ได้ อยู่ใน repository ของหน่วยงานตั้งแต่งวดเตรียมปลายทาง
• บัญชีผู้ดูแลและกุญแจเข้ารหัส อยู่ในการควบคุมของหน่วยงาน มีทะเบียนบัญชีที่อัปเดตทุกงวด
• การใช้บริการเฉพาะของผู้ให้บริการ ให้ผู้รับจ้างระบุในแผนว่าจุดใดใช้บริการที่ย้ายออกยาก และทางเลือกเมื่อต้องย้าย
• การลบข้อมูลและหลักฐาน ลบข้อมูลจากระบบเดิมเมื่อพ้นช่วงถอยกลับ และลบจากปลายทางเดิมเมื่อออกจากผู้ให้บริการ พร้อมหลักฐาน
• สัญญาครบกำหนดหรือบอกเลิกก่อนกำหนด ข้อออกจากระบบทั้งหมดข้างต้นต้องใช้ได้ทั้งสองกรณี ส่วนการส่งต่องานดูแลระบบทั่วไปใช้ข้อที่อธิบายไว้ในบทความ TOR จ้างดูแลระบบเดิม และรายการรับมอบใน เปลี่ยนผู้รับจ้างดูแลระบบ: ต้องรับมอบอะไรบ้าง

ถ้าต้องการคำศัพท์อ้างอิงสำหรับการย้ายข้อมูลและแอปพลิเคชันข้ามผู้ให้บริการ ISO/IEC 19941:2017 กำหนดคำศัพท์และแนวคิดเรื่อง interoperability และ portability ของคลาวด์ไว้

หลังย้ายเสร็จใครจ่ายค่าคลาวด์ และข้ามปีงบประมาณอย่างไร?

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

• ตั้งงบในแผนงานบูรณาการ แนวทางการจัดหาบริการคลาวด์ ปี 2570 ตามเอกสารของ สพร. ให้หน่วยงานขอรับจัดสรรงบด้านคลาวด์ภายใต้แผนงานบูรณาการรัฐบาลดิจิทัล คำขอที่อยู่นอกแผนงานจะไม่ได้รับการพิจารณา ให้จัดหาผ่าน GDCC เป็นอันดับแรก ถ้า GDCC ไม่เพียงพอ ไม่มีบริการที่ต้องการ หรือเป็นการจัดหาต่อเนื่อง ขออนุมัติยกเว้นจากคณะกรรมการบูรณาการฯ เพื่อจัดหาเองได้ หน่วยงานที่จัดหาเองต้องให้ผู้ให้บริการเชื่อมต่อข้อมูลกับ CMP ของ ดศ. และแนวทางนี้ใช้เฉพาะหน่วยงานที่ขอรับจัดสรรงบประมาณแผ่นดิน
• งบโอนข้ามหน่วยรับงบไม่ได้ สรุปผลการประชุมคณะรัฐมนตรี 11 พฤศจิกายน 2568 (เรื่องการขอยกเว้นมติ 26 สิงหาคม 2568 ที่ให้ชะลอการจัดหาคลาวด์) อธิบายว่างบที่ตั้งไว้ในหน่วยรับงบประมาณใด จะโอนหรือนำไปใช้กับหน่วยรับงบประมาณอื่นไม่ได้ตามมาตรา 35 ของ พ.ร.บ. วิธีการงบประมาณ พ.ศ. 2561 เว้นแต่กรณีที่ระเบียบว่าด้วยการโอนงบประมาณรายจ่ายบูรณาการกำหนด เอกสารสรุปนี้ระบุให้ตรวจมติที่เป็นทางการกับสำนักเลขาธิการคณะรัฐมนตรีอีกครั้ง
• ช่องว่างเมื่อบริการต่อเนื่องข้ามปีงบ สาระสำคัญของเรื่องในสรุปเดียวกันอ้างมติคณะกรรมการดิจิทัลเพื่อเศรษฐกิจและสังคมแห่งชาติ ครั้งที่ 3/2567 (22 ตุลาคม 2567) ว่า โครงการคลาวด์ที่ต้องให้บริการต่อเนื่องตั้งแต่ 1 ตุลาคม 2568 ให้เสนอคณะกรรมการวินิจฉัยปัญหาการจัดซื้อจัดจ้างและการบริหารพัสดุภาครัฐ เพื่อขออนุมัติผ่อนผันให้สัญญามีผลย้อนหลัง ตัวอย่างนี้แสดงว่าถ้าไม่วางแผนรอบปีงบ ระบบที่ย้ายเสร็จแล้วอาจไม่มีสัญญารองรับค่าใช้บริการในช่วงต้นปีงบถัดไป

สิ่งที่ TOR ควรระบุจึงมีดังนี้

• ใครจ่ายค่าทรัพยากรคลาวด์ระหว่างย้าย ระหว่างเดินระบบคู่ขนาน และหลังตรวจรับ และค่าใช้บริการอยู่ในสัญญานี้หรือสัญญาแยก
• รูปแบบการคิดค่าบริการ ร่างมาตรฐานของ สพร. ระบุว่าถ้าบริการให้เลือกคิดตามปริมาณการใช้งานจริง (pay-per-use) ต้องพิจารณาแบบนี้เป็นลำดับแรก และให้ใช้เครื่องมือประเมินค่าบริการ (pricing calculator) ที่มีมาตรฐานการจัดทำเพดานงบประมาณ (Not-To-Exceed ceiling)
• รายงานค่าใช้จ่ายรายเดือนแยกตามระบบ การติดแท็กทรัพยากร และการแจ้งเตือนเมื่อใช้ใกล้เพดานที่หน่วยงานกำหนด [__]
• สิ่งที่เกิดขึ้นเมื่อถึงสิ้นปีงบหรือสัญญาค่าบริการขาดช่วง เช่น ผู้ให้บริการต้องไม่ลบข้อมูลภายใน [__ วัน] และขั้นตอนต่ออายุ

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

มีหนังสือเวียนเฉพาะเรื่องการจัดซื้อบริการคลาวด์หรือไม่?

ณ วันที่ตรวจ เราไม่พบหนังสือเวียนของกรมบัญชีกลางที่ว่าด้วยการจัดซื้อหรือเช่าใช้บริการคลาวด์โดยเฉพาะ การจัดหายังเป็นไปตาม พ.ร.บ. การจัดซื้อจัดจ้างฯ พ.ศ. 2560 และระเบียบฯ ร่วมกับมติและแนวทางด้านคลาวด์ข้างต้น วิธีจัดซื้อ ขั้นตอนใน e-GP และการรับฟังความคิดเห็นร่าง TOR อยู่ในคู่มือจ้างพัฒนาระบบ IT ภาครัฐ เรื่องที่ต้องตัดสินใจก่อนร่างคือจะรวมค่าใช้บริการคลาวด์ไว้ในสัญญาเดียวกับงานย้ายระบบ หรือแยกเป็นอีกรายการ แต่ละแบบมีผลต่อการตรวจรับและการต่อสัญญาข้ามปีงบ ให้หารือหน่วยพัสดุและเจ้าหน้าที่งบประมาณ

ข้อผิดพลาดที่พบบ่อยใน TOR ย้ายระบบขึ้นคลาวด์มีอะไรบ้าง?

หลายข้อในตารางเป็นสาเหตุเดียวกับที่ทำให้โครงการ IT ภาครัฐสะดุดโดยทั่วไป ซึ่งสรุปไว้ใน ทำไมโครงการ IT ภาครัฐจึงล้มเหลว

Checklist: หัวข้อที่ TOR Cloud Migration ควรมี

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

1. วัตถุประสงค์ ระยะเวลา และการแบ่งงวดตามขั้นสำรวจ เตรียมปลายทาง นำร่อง ย้ายระบบหลัก และส่งมอบ
2. ภาคผนวกรายการระบบ ความเชื่อมโยง ชั้นข้อมูล ช่วงเวลาที่หยุดได้ และระบบที่ไม่ย้าย
3. งวดสำรวจ: รายการระบบที่ยืนยันแล้ว แผนผังความเชื่อมโยง แผนการย้ายแยก wave และรายงานส่วนที่ต่างจาก TOR
4. ปลายทางที่เขียนเป็นคุณลักษณะ ไม่ระบุยี่ห้อ และเหตุผลตามแนวทางจัดหาคลาวด์ของปีงบนั้น (ใช้ GDCC หรือได้รับอนุมัติยกเว้นให้จัดหาเอง)
5. ที่ตั้งข้อมูลขณะจัดเก็บ รวม backup, snapshot และ log ตามชั้นข้อมูล
6. บัญชี tenant บัญชีผู้ดูแลสูงสุด และบัญชีรับใบแจ้งหนี้ในนามหน่วยงาน
7. ข้อกำหนดตามมาตรฐานความมั่นคงปลอดภัยไซเบอร์ระบบคลาวด์ของ กกม. และหลักฐานที่ผู้รับจ้างต้องส่งประกอบรายงานของหน่วยงาน
8. ตารางแบ่งความรับผิดชอบระหว่างหน่วยงาน ผู้รับจ้าง และผู้ให้บริการคลาวด์ ทั้งระหว่างโครงการและหลังส่งมอบ
9. หลักฐานรับรองของผู้ให้บริการที่ขอ พร้อมขอบเขตและฉบับของมาตรฐานที่ยอมรับ
10. ข้อตกลงการประมวลผลข้อมูลส่วนบุคคล (DPA)
11. ระบบนำร่องและเกณฑ์ผ่าน
12. ช่วงหยุดระบบ เกณฑ์ go/no-go เกณฑ์ rollback การซ้อม และการเดินระบบคู่ขนาน
13. วิธีกระทบยอดข้อมูลและผู้ลงนามรับรอง
14. RTO และ RPO ที่หน่วยงานกำหนด และการทดสอบกู้คืนบนปลายทาง
15. การเชื่อมต่อระบบบริหารจัดการคลาวด์กลาง (CMP) ถ้ากติกากำหนด
16. การตั้งค่าระบบหรือ Infrastructure as Code ใน repository ของหน่วยงาน
17. runbook การถ่ายทอดความรู้ และทะเบียนบัญชีผู้ดูแล
18. ผู้จ่ายค่าคลาวด์แต่ละช่วง รูปแบบการคิดค่าบริการ รายงานค่าใช้จ่าย และเงื่อนไขเมื่อข้ามปีงบ
19. หลักฐานตรวจรับรายงวดและวิธีตรวจทางเทคนิค
20. ข้อออกจากระบบ: ส่งคืนข้อมูล รูปแบบไฟล์ ระยะเวลา ค่าใช้จ่าย และการลบข้อมูลพร้อมหลักฐาน
21. เงื่อนไขการปิดระบบเดิมและการลบข้อมูลจากระบบเดิม
22. เหตุบอกเลิกสัญญาและการส่งมอบเมื่อเลิกก่อนกำหนด (ร่างร่วมกับหน่วยพัสดุ)

ประเมินระบบก่อนย้าย

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

บริการ Cloud ของ UNIXDEV ครอบคลุมการเปรียบเทียบทางเลือก การวางเครือข่าย ตัวตนและสิทธิ์ การตั้งค่าความปลอดภัยพื้นฐาน (security baseline) และ monitoring บนปลายทาง การย้ายระบบตั้งแต่ทำแผนผังความเชื่อมโยง ซ้อมการย้ายข้อมูล จนถึงตกลงขั้นตอน cutover และ rollback และการดูแลระบบต่อเนื่อง งานคลาวด์ของเราทำบน Huawei Cloud, BytePlus Cloud และ Oracle Cloud เป็นหลัก และรองรับ AWS และ GCP ตาม workload

UNIXDEV ลงทะเบียนเป็นผู้ค้าในระบบ e-GP แล้ว และได้รับการรับรอง ISO 9001:2015, ISO/IEC 29110-4-1:2018 และ ISO/IEC 27001:2022

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

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

แหล่งอ้างอิงและอ่านต่อ

• ประกาศคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ เรื่อง มาตรฐานด้านการรักษาความมั่นคงปลอดภัยไซเบอร์ระบบคลาวด์ พ.ศ. 2567: ราชกิจจานุเบกษา เล่ม 141 ตอนพิเศษ 248 ง วันที่ 10 กันยายน 2567 · สำเนาพร้อมภาคผนวก (สำเนาก่อนประกาศในราชกิจจานุเบกษา ข้อ 2 ในสำเนานี้ยังเขียนว่าหนึ่งปี ให้ยึดฉบับในราชกิจจานุเบกษา)
• ประกาศสำนักงานคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ เรื่อง แผนบูรณาการเพื่อขับเคลื่อนการดำเนินการตามมาตรฐานด้านการรักษาความมั่นคงปลอดภัยไซเบอร์ระบบคลาวด์ พ.ศ. 2569–2573 (7 สิงหาคม 2569, สำเนาที่กรมพัฒนาที่ดินเผยแพร่)
• สพร.: เอกสารประกอบการประชุมกลุ่มย่อย มาตรฐานการบริหารจัดการคลาวด์ภาครัฐ (24 ธันวาคม 2568) มติคณะกรรมการพัฒนารัฐบาลดิจิทัล ครั้งที่ 3/2568 แนวทาง National Cloud การจำแนกข้อมูล การขึ้นทะเบียนผู้ให้บริการ และแนวทางจัดหาปี 2570
• สพร.: (ร่าง) มาตรฐานรัฐบาลดิจิทัล ว่าด้วยแนวทางการใช้คลาวด์ (ธันวาคม 2568 ฉบับเวียนขอความเห็น ปกร่างระบุว่าห้ามใช้หรือยึดเป็นมาตรฐาน) · ร่างประกาศคณะกรรมการพัฒนารัฐบาลดิจิทัลที่เสนอให้ใช้บังคับ 1 ตุลาคม 2570
• สรุปผลการประชุมคณะรัฐมนตรี 11 พฤศจิกายน 2568 (ทำเนียบรัฐบาล thaigov.go.th ข้อ 6 เรื่องคลาวด์ เอกสารระบุให้ตรวจมติที่เป็นทางการกับสำนักเลขาธิการคณะรัฐมนตรีอีกครั้ง)
• NT: ระบบคลาวด์กลางภาครัฐ (GDCC) (14 มีนาคม 2566)
• พ.ร.บ. การจัดซื้อจัดจ้างและการบริหารพัสดุภาครัฐ พ.ศ. 2560: ราชกิจจานุเบกษา เล่ม 134 ตอนที่ 24 ก วันที่ 24 กุมภาพันธ์ 2560 (มาตรา 9, 97)
• ระเบียบกระทรวงการคลังว่าด้วยการจัดซื้อจัดจ้างและการบริหารพัสดุภาครัฐ พ.ศ. 2560: ราชกิจจานุเบกษา เล่ม 134 ตอนพิเศษ 210 ง วันที่ 23 สิงหาคม 2560 (ข้อ 27, 175)
• หลักความรับผิดชอบร่วม: AWS · Google Cloud · Huawei Cloud · NCSC สหราชอาณาจักร
• มาตรฐานสากล: ISO/IEC 27001:2022 · ISO/IEC 27017:2026 · ISO/IEC 27018:2025 · ISO/IEC 19941:2017 · CSA STAR · NIST SP 800-34 Rev. 1 (RTO, RPO)
• บทความที่เกี่ยวข้อง: Cloud Migration ในไทย เริ่มยังไงและประเมินค่าใช้จ่ายจากอะไร
• บทความที่เกี่ยวข้อง: ย้ายระบบเก่าสู่ Cloud-Native
• บทความที่เกี่ยวข้อง: จ้างพัฒนาระบบ IT ภาครัฐ วิธีจัดซื้อ e-GP TOR และงบ MA
• บทความที่เกี่ยวข้อง: TOR จ้างดูแลระบบเดิม
• บทความที่เกี่ยวข้อง: สัญญา MA และ SLA ดูแลระบบ
• บทความทั้งหมดในหมวดระบบ IT สำหรับหน่วยงานภาครัฐ
• บทความทั้งหมดในหมวด Cloud และการย้ายระบบ

บทความโดย UNIXDEV Team · 7 พฤศจิกายน 2026 · สรุปเพื่อประกอบการวางแผน ไม่ใช่คำแนะนำทางกฎหมาย ร่าง TOR ฉบับสุดท้ายให้หน่วยพัสดุและนิติกรของหน่วยงานยืนยัน และกติกาคลาวด์ฉบับปัจจุบันให้ยืนยันกับ สพร. สดช. และ สกมช.