Cloud Strategy · WHITE FORCES KNOWLEDGE
Cloud Readiness Checklist ก่อนย้ายระบบธุรกิจขึ้น Cloud
เผยแพร่ · ตรวจทานล่าสุด · อ่านประมาณ 5 นาทีการย้าย Cloud ไม่ใช่เพียงเปิดเซิร์ฟเวอร์ใหม่ ต้องเข้าใจ dependency และออกแบบการดูแลหลังย้ายไปพร้อมกัน
สำรวจ workload และ dependency
บันทึก OS, database, integration, ปริมาณข้อมูล ช่วงใช้งานหนัก และผู้ใช้ที่ได้รับผลกระทบ เพื่อเลือกวิธีย้ายและลำดับที่ปลอดภัย
จุดที่มักพลาดคือ dependency ที่มองไม่เห็น เช่น โปรแกรมบัญชีที่ผูกกับเครื่องพิมพ์ในสำนักงาน ไลเซนส์ซอฟต์แวร์ที่ผูกกับฮาร์ดแวร์เดิม หรือระบบที่อ้างอิง IP ภายในแบบตายตัว การไล่สาย dependency เหล่านี้ก่อนย้ายใช้เวลาน้อยกว่าการมานั่งแก้ตอนระบบล่มหลังย้ายมาก ควรเขียน diagram ให้เห็นว่าระบบไหนคุยกับระบบไหน แล้วให้คนหน้างานช่วยตรวจว่าครบ
วางสิทธิ์ Backup และ Recovery
แยกบัญชีบุคคลกับ service account เปิด MFA กำหนด RPO/RTO และทดสอบกู้จริง การเห็นว่า backup สำเร็จยังไม่เท่ากับกู้คืนได้
RPO คือปริมาณข้อมูลที่ยอมเสียได้เมื่อเกิดเหตุ ส่วน RTO คือเวลาที่ยอมให้ระบบหยุดได้ สองค่านี้ควรมาจากฝั่งธุรกิจ ไม่ใช่ฝั่งเทคนิค เพราะเป็นตัวกำหนดงบและวิธีสำรองข้อมูลโดยตรง เมื่อกำหนดแล้วต้องซ้อมกู้คืนจริงอย่างน้อยปีละครั้งหรือเมื่อระบบสำคัญเปลี่ยน และบันทึกเวลาที่ใช้จริงเทียบกับเป้า ถ้ากู้ไม่ทันตามเป้า แปลว่าแผนยังไม่ใช้ได้จริง
ย้ายแบบมีทางถอย
เริ่มจากระบบเสี่ยงต่ำ ทดสอบ load กับ monitoring และกำหนด cutover/rollback ก่อนปิดระบบเดิมหรือย้าย workload สำคัญ
ช่วงเปลี่ยนผ่านควรให้ระบบเดิมกับระบบใหม่ทำงานคู่ขนานระยะหนึ่ง โดยกำหนดชัดว่าข้อมูลชุดไหนถือเป็นชุดจริง เมื่อระบบใหม่นิ่งครบตามเกณฑ์ที่ตั้งไว้ เช่น ผ่านช่วงใช้งานหนักโดยไม่มีเหตุขัดข้องสำคัญ จึงประกาศ cutover และเก็บระบบเดิมไว้ในสถานะอ่านอย่างเดียวอีกระยะหนึ่ง เผื่อกรณีต้องตรวจสอบย้อนหลังหรือถอยกลับฉุกเฉิน
ตัวอย่างสถานการณ์การใช้งานจริง
ลองนึกถึงบริษัทที่มีไฟล์เซิร์ฟเวอร์เก่าในสำนักงานหนึ่งเครื่อง เก็บทั้งเอกสารงาน ไฟล์บัญชี และฐานข้อมูลโปรแกรมขาย เมื่อเครื่องเริ่มเสียบ่อยจึงตัดสินใจย้ายขึ้น Cloud ถ้าย้ายโดยไม่สำรวจก่อน อาจพบภายหลังว่าโปรแกรมขายรุ่นเก่าไม่รองรับการทำงานผ่านอินเทอร์เน็ต หรือสาขาที่เน็ตช้าเปิดไฟล์ใหญ่ไม่ไหว ลำดับที่ปลอดภัยกว่าคือย้ายไฟล์เอกสารทั่วไปก่อนเพราะเสี่ยงต่ำ แล้วจึงประเมินโปรแกรมขายแยกว่าควรอัปเกรด เปลี่ยนเป็นบริการแบบ SaaS หรือคงไว้ในเครื่องเดิมที่ดูแลดีขึ้น
อีกกรณีคือธุรกิจที่รันระบบซื้อขายหรือ EA ที่ต้องทำงานต่อเนื่อง การย้ายไปใช้ VPS ช่วยตัดปัญหาไฟดับและเน็ตหลุดที่บ้าน แต่ต้องวางแผนเรื่อง monitoring และการเข้าถึงเครื่องเมื่อเกิดเหตุ ไม่ใช่เพียงเช่าเครื่องแล้วจบ เพราะความต่อเนื่องของระบบขึ้นกับการดูแลมากพอ ๆ กับตัวโครงสร้างพื้นฐาน
ขั้นตอนดำเนินงานที่แนะนำ
แผนการย้ายที่ดีแบ่งเป็นขั้นชัดเจน มีเกณฑ์ผ่านของแต่ละขั้นก่อนไปต่อ
- สำรวจและจัดทำทะเบียนระบบบันทึกทุก workload พร้อม OS ฐานข้อมูล ผู้ใช้ ปริมาณข้อมูล และ dependency ระหว่างกัน
- จัดกลุ่มตามความเสี่ยงแยกระบบเสี่ยงต่ำ กลาง สูง แล้ววางลำดับย้ายจากเสี่ยงต่ำไปสูง
- ออกแบบปลายทางและสิทธิ์เลือกรูปแบบบริการ วางโครงสร้างบัญชี เปิด MFA และแยกสิทธิ์ผู้ดูแลกับผู้ใช้ทั่วไป
- กำหนด RPO/RTO และแผนสำรองตกลงกับฝั่งธุรกิจว่ายอมเสียข้อมูลและเวลาหยุดได้แค่ไหน แล้วออกแบบ backup ให้ตอบโจทย์นั้น
- ย้ายนำร่องและทดสอบย้ายระบบแรกที่เสี่ยงต่ำ ทดสอบการใช้งานจริง load และการกู้คืน ก่อนประกาศใช้
- cutover ระบบหลักและทบทวนย้ายระบบสำคัญเมื่อระบบนำร่องนิ่ง พร้อมแผน rollback และทบทวนต้นทุนจริงหลังย้ายทุกไตรมาส
เช็กลิสต์ก่อน cutover
- ทะเบียนระบบและ dependency ครบ ผ่านการตรวจโดยคนหน้างาน
- บัญชีผู้ดูแลแยกจากบัญชีบุคคล เปิด MFA ทุกบัญชีสิทธิ์สูง
- backup ตั้งเวลาอัตโนมัติ มีสำเนานอกระบบหลัก และทดสอบกู้คืนแล้วจริง
- monitoring แจ้งเตือนถึงคนรับผิดชอบ ไม่ใช่แจ้งเข้ากล่องที่ไม่มีใครอ่าน
- ทดสอบช่วงใช้งานหนักหรือจำลอง load ใกล้เคียงของจริงแล้ว
- มีแผน rollback เป็นลายลักษณ์อักษร และรู้ว่าใครสั่งถอยได้
- ประเมินต้นทุนรายเดือนหลังย้าย รวมค่า transfer และ backup แล้ว
- แจ้งผู้ใช้ล่วงหน้าเรื่องช่วงเปลี่ยนผ่านและช่องทางแจ้งปัญหา
เปรียบเทียบรูปแบบการใช้งาน
ระบบแต่ละตัวอาจลงเอยคนละรูปแบบ ไม่จำเป็นต้องเหมือนกันทั้งองค์กร
| ประเด็น | On-premise | VPS / IaaS | SaaS |
|---|---|---|---|
| การควบคุม | ควบคุมได้ทั้งหมด รวมถึงฮาร์ดแวร์ | ควบคุมระดับ OS และซอฟต์แวร์ | ควบคุมเฉพาะการตั้งค่าที่ผู้ให้บริการเปิดให้ |
| ภาระดูแล | ดูแลเองทุกชั้น ตั้งแต่ไฟฟ้าถึงแอปพลิเคชัน | ผู้ให้บริการดูแลฮาร์ดแวร์ เราดูแล OS ขึ้นไป | ผู้ให้บริการดูแลเกือบทั้งหมด |
| ต้นทุน | ลงทุนก้อนแรกสูง มีค่าเสื่อมและค่าดูแล | จ่ายรายเดือนตามสเปกที่ใช้ ปรับขนาดได้ | จ่ายรายเดือนต่อผู้ใช้หรือปริมาณการใช้ |
| เหมาะกับ | ข้อกำกับเข้มงวด หรือ workload เฉพาะทาง | ระบบที่ต้องการควบคุมแต่ไม่อยากดูแลฮาร์ดแวร์ | งานมาตรฐาน เช่น อีเมล เอกสาร บัญชี |
ข้อผิดพลาดที่พบบ่อย
- ย้ายทุกอย่างพร้อมกันในคราวเดียวเมื่อเกิดปัญหาจะแยกไม่ออกว่ามาจากระบบไหน และไม่มีทางถอยเพราะปิดระบบเดิมไปแล้ว
- เชื่อว่า backup สำเร็จเท่ากับกู้ได้ไฟล์สำรองที่ไม่เคยทดสอบกู้ อาจเปิดไม่ได้หรือขาดข้อมูลสำคัญ ต้องซ้อมกู้จริงเป็นระยะ
- ใช้บัญชีผู้ดูแลร่วมกันทั้งทีมเมื่อเกิดเหตุจะตามไม่ได้ว่าใครทำอะไร และพนักงานที่ลาออกยังอาจเข้าถึงระบบได้
- ลืมคิดค่าใช้จ่ายแฝงค่า transfer ข้อมูลออก ค่า backup และค่า snapshot สะสม อาจทำให้บิลจริงสูงกว่าที่ประเมินมาก
- ไม่มีเจ้าของระบบหลังย้ายCloud ไม่ได้ดูแลตัวเอง ต้องมีคนรับผิดชอบ patch, monitoring และทบทวนสิทธิ์อย่างสม่ำเสมอ
คำถามที่พบบ่อย
ข้อมูลบน Cloud ปลอดภัยกว่าเก็บเองไหม
ผู้ให้บริการรายใหญ่มีมาตรการระดับศูนย์ข้อมูลที่ธุรกิจทั่วไปทำเองได้ยาก แต่ความปลอดภัยฝั่งการตั้งค่า สิทธิ์ และรหัสผ่านยังเป็นหน้าที่ของเรา เหตุข้อมูลรั่วจำนวนมากเกิดจากการตั้งค่าผิดหรือบัญชีถูกขโมย ไม่ใช่ตัวผู้ให้บริการถูกเจาะ
ควรย้ายระบบไหนขึ้นก่อน
เริ่มจากระบบที่เสี่ยงต่ำและได้ประโยชน์ชัด เช่น ไฟล์เอกสาร อีเมล หรือระบบทดสอบ เพื่อให้ทีมคุ้นกับเครื่องมือและกระบวนการ แล้วจึงย้ายระบบสำคัญเมื่อมีบทเรียนและ monitoring พร้อม
ระบบเก่ามากย้ายขึ้น Cloud ได้ไหม
บางระบบย้ายแบบยกเครื่องเดิมขึ้นไปได้ แต่ควรประเมินก่อนว่าคุ้มไหม เพราะระบบเก่าบางตัวไม่รองรับการทำงานระยะไกล หรือมีเงื่อนไขไลเซนส์ผูกกับเครื่อง บางกรณีเปลี่ยนไปใช้บริการสำเร็จรูปที่ทำงานแทนกันได้จะถูกและยั่งยืนกว่า
ต้องมีคน IT ประจำไหมหลังย้าย
ต้องมีผู้รับผิดชอบเสมอ แต่ไม่จำเป็นต้องจ้างประจำ ธุรกิจขนาดเล็กจำนวนมากใช้บริการ Managed Service ที่ดูแล patch, backup และ monitoring ให้ตามรอบ สิ่งสำคัญคือระบุในสัญญาให้ชัดว่าใครทำอะไร และธุรกิจถือสิทธิ์เจ้าของบัญชีเองเสมอ
แหล่งอ้างอิง
กรอบคิดที่ใช้อ้างอิงแนวปฏิบัติในบทความนี้
- AWS Well-Architected Framework — หลักออกแบบระบบบน Cloud
- NIST Special Publication 800-145 — นิยาม Cloud Computing
- CIS Benchmarks — แนวทางตั้งค่าระบบอย่างปลอดภัย