คู่มือการย้ายระบบขึ้น Cloud สำหรับองค์กร ตั้งแต่การประเมินจนถึงการเปลี่ยนระบบ

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

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

การเลือกภูมิภาคต้องมาก่อน ภูมิภาคที่ตั้งอยู่ในประเทศ (หากมี) มี Availability Zone หลายแห่งเพื่อความทนทาน และมีความหน่วงต่ำสำหรับผู้ใช้ในประเทศ AWS Asia Pacific (Bangkok) Region (ap-southeast-7) เป็นตัวอย่างหนึ่ง ซึ่งเปิดทางเลือกให้องค์กรที่มีผู้ใช้ในประเทศไทย จากเดิมที่ตลอดยุค Cloud ส่วนใหญ่ต้องให้บริการผ่านสิงคโปร์ สำหรับระบบที่ไวต่อความหน่วง และองค์กรที่นโยบายหรือหน่วยงานกำกับต้องการให้ข้อมูลอยู่ในประเทศ ภูมิภาคในประเทศคือจุดเริ่มต้นโดยปริยาย

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

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

ทุกสิ่งใน Landing Zone ที่กำหนดเป็นโค้ดได้ควรกำหนดเป็นโค้ด ได้แก่ บัญชีและนโยบายขององค์กร เครือข่ายและการกำหนดเส้นทาง การจัดการตัวตนและ Role การบันทึก Log และร่องรอยการตรวจสอบ กุญแจเข้ารหัส นโยบายการสำรองข้อมูล งบประมาณและการแจ้งเตือน เราเลือกใช้ Terraform เพราะเป็นแบบ Declarative ไม่ผูกกับผู้ให้บริการรายใด และตรวจทานได้ใน Pull Request เดียวกับโค้ดแอปพลิเคชัน

แนวปฏิบัติบางประการช่วยให้จัดการได้ง่าย จัดเก็บ State ไว้ภายนอกพร้อมกลไกล็อก โดยแยกหนึ่ง State ต่อหนึ่งสภาพแวดล้อมและต่อหนึ่งส่วนประกอบเชิงตรรกะ เพื่อไม่ให้ความผิดพลาดในจุดหนึ่งทำให้อีกจุดเสียหาย สร้าง Module ขนาดเล็กที่ตั้งชื่อชัดเจนสำหรับสิ่งที่ต้องสร้างซ้ำ (บริการพร้อม Container Definition, กฎของ Load Balancer, IAM Role และ Log Group) และกำหนดเวอร์ชัน ติด Tag ทุกทรัพยากรด้วยเจ้าของ สภาพแวดล้อม แอปพลิเคชัน และศูนย์ต้นทุน จาก Module การติด Tag เพียงชุดเดียว เพราะการควบคุมต้นทุนในภายหลังต้องอาศัยข้อมูลนี้ รัน Plan ทุกครั้งที่มีการเปลี่ยนแปลง กำหนดให้ต้องผ่านการตรวจทาน และ Apply จาก Pipeline แทนการ Apply จากเครื่องส่วนตัว ตรวจจับ Drift ตามกำหนดเวลา และถือว่าการแก้ไขผ่าน Console ด้วยมือเป็นเหตุการณ์ที่ต้องแก้ไขให้ตรงกัน ไม่ใช่เรื่องปกติแบบใหม่

ผลลัพธ์คือ สภาพแวดล้อมสำหรับระลอกที่สองเป็นเพียง Pull Request หนึ่งรายการ ไม่ใช่โครงการใหม่ทั้งโครงการ

คู่มือปฏิบัติงานทุกฉบับมีหัวข้อการย้อนกลับ แต่มีไม่กี่ทีมที่เคยทำจริง ควรซักซ้อมการสลับระบบทั้งหมดอย่างน้อยหนึ่งครั้งในสภาพแวดล้อมที่ไม่ใช่ Production โดยใช้บุคลากรชุดเดียวกัน รายการตรวจสอบเดียวกัน และจับเวลา แล้วจึงซักซ้อมการย้อนกลับ กำหนดเกณฑ์ Go/No-go ไว้ก่อนวันจริง (การทดสอบใดต้องผ่าน ผู้มีส่วนได้ส่วนเสียรายใดต้องยืนยัน ภายในเวลาใด) และระบุผู้ตัดสินใจเพียงคนเดียว กำหนดจุดที่ย้อนกลับไม่ได้ให้ชัดเจน คือช่วงเวลาที่ธุรกรรมใหม่มีอยู่เฉพาะในระบบเป้าหมาย และการย้อนกลับหมายถึงต้องกระทบยอดข้อมูลด้วยมือ

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