วางแผนย้ายระบบขึ้นคลาวด์: ความเชื่อมโยงระหว่างระบบ การเปลี่ยนระบบ และต้นทุน
แผนย้ายระบบควรระบุให้ชัดว่าจะย้ายอะไร อะไรต้องทำงานต่อได้ตามปกติ และทีมจะรู้ได้อย่างไรว่าผลลัพธ์อยู่ในเกณฑ์ที่ยอมรับได้ ชื่อแพลตฟอร์มเพียงอย่างเดียวตอบคำถามเหล่านี้ไม่ได้
บทความนี้นำเสนอกรอบการวางแผนและตัวอย่างที่ระบุชัดว่าเป็นเรื่องสมมติ ไม่ได้อธิบายงานที่ BEEK ส่งมอบให้ลูกค้า และไม่ได้สัญญาว่าจะประหยัดต้นทุนได้ในระดับใดระดับหนึ่ง
เริ่มจากจัดทำรายการระบบงาน
สำหรับแต่ละแอปพลิเคชัน ให้บันทึกเจ้าของระบบ ผู้ใช้งาน ระบบต้นทางและปลายทาง แหล่งจัดเก็บข้อมูล วิธียืนยันตัวตน ขั้นตอนการปล่อยเวอร์ชันใหม่ และความต้องการด้านการกู้คืน รวมถึงงานที่ตั้งเวลาไว้และขั้นตอนที่ทำด้วยมือ แอปพลิเคชันอาจดูเหมือนทำงานปกติ ทั้งที่งานส่งออกข้อมูลประจำคืนหรือการเชื่อมต่อกับระบบภายนอกหยุดทำงานไปแล้ว
ข้อมูลที่เป็นประโยชน์ในแต่ละรายการ ได้แก่
- กระบวนการธุรกิจที่ระบบรองรับและช่วงเวลาที่ใช้งาน
- ระบบอื่นที่รับส่งข้อมูลกับระบบนี้
- การใช้ทรัพยากรในปัจจุบัน และที่มาของค่าที่วัดได้
- ข้อกำหนดด้านการเก็บรักษาข้อมูล การสำรองข้อมูล และสิทธิ์เข้าถึง
- ผู้รับผิดชอบการทดสอบ และผู้รับผิดชอบการตัดสินใจย้อนกลับระบบ
แนวทางการประเมินระบบงานของ Microsoft (ภาษาอังกฤษ) แยกการประเมินสถาปัตยกรรม โค้ดแอปพลิเคชัน และฐานข้อมูลออกจากกัน ใช้การแยกนี้เพื่อไม่ให้ถือว่าการตรวจสอบความเข้ากันได้ของฐานข้อมูลเป็นการประเมินแอปพลิเคชันที่ครบถ้วนแล้ว
เลือกแนวทางย้ายสำหรับแต่ละระบบงาน
AWS อธิบายแนวทางการย้ายระบบไว้ 7 แบบ ได้แก่ เลิกใช้ระบบ (retire) คงไว้ที่เดิม (retain) ย้ายโดยไม่แก้ไขระบบ (rehost) ย้ายที่ตั้งโดยใช้แพลตฟอร์มเดิม (relocate) เปลี่ยนไปใช้ผลิตภัณฑ์อื่น (repurchase) ปรับแพลตฟอร์มบางส่วน (replatform) และปรับโครงสร้างระบบ (refactor) ตัวเลือกเหล่านี้มีตั้งแต่การคงไว้หรือเลิกใช้แอปพลิเคชัน ไปจนถึงการย้ายโดยเปลี่ยนแปลงระบบในระดับที่ต่างกัน การย้ายระบบขนาดใหญ่ไม่จำเป็นต้องเขียนแอปพลิเคชันใหม่ทุกตัว อ้างอิง: แนวทางกลยุทธ์การย้ายระบบของ AWS (ภาษาอังกฤษ)
บันทึกเหตุผลของแนวทางที่เลือกไว้ด้วย ตัวอย่างเช่น ระบบที่มีอินเทอร์เฟซเสถียรและต้องย้ายภายในกรอบเวลาที่จำกัด อาจได้รับการประเมินต่างจากผลิตภัณฑ์ที่ต้องปรับสถาปัตยกรรม การตัดสินใจปรับระบบให้ทันสมัยกับการเปลี่ยนที่ตั้งของระบบเป็นการตัดสินใจคนละเรื่องกัน แม้จะเกิดขึ้นในโครงการเดียวกันก็ตาม
ตัวอย่างการวางแผนจากระบบสมมติ
ลองพิจารณาแอปพลิเคชันสั่งซื้อสมมติที่มีส่วนติดต่อผู้ใช้บนเว็บ ฐานข้อมูลคำสั่งซื้อ งานนำเข้าข้อมูลสต็อกสินค้าทุกคืน และการแจ้งเตือนทางอีเมล ตัวอย่างนี้ไม่ใช่กรณีศึกษาของลูกค้า
| ส่วนประกอบ | คำถามที่ต้องหาคำตอบ | หลักฐานประกอบการรับมอบ |
|---|---|---|
| เว็บแอปพลิเคชัน | เส้นทางใช้งานใดบ้างที่ต้องทำงานได้หลังเปลี่ยนระบบ? | การทดสอบการเข้าสู่ระบบ การสร้างคำสั่งซื้อ และการเรียกดูคำสั่งซื้อ |
| ฐานข้อมูลคำสั่งซื้อ | จะตรวจสอบระเบียนที่มีการเปลี่ยนแปลงให้ตรงกันอย่างไร? | เอกสารเปรียบเทียบระเบียนระหว่างระบบต้นทางและปลายทาง |
| งานนำเข้าข้อมูลสต็อก | งานเริ่มทำงานจากอะไร และใครเป็นผู้ติดตาม? | การทำงานตามกำหนดเวลาที่สำเร็จ พร้อมการทดสอบกรณีข้อยกเว้น |
| การแจ้งเตือนทางอีเมล | จะจัดการข้อมูลรับรองสิทธิ์และการส่งที่ล้มเหลวอย่างไร? | การทดสอบการส่งแบบควบคุม และการแจ้งเตือนเมื่อส่งไม่สำเร็จ |
ตารางนี้เปลี่ยนคำสั่งกว้างๆ ว่าให้ย้ายแอปพลิเคชัน ให้กลายเป็นงานที่ระบุได้ชัดเจน ส่วนรายการทดสอบ ปริมาณงาน และค่าเกณฑ์ที่ใช้จริง ต้องกำหนดจากข้อกำหนดของแอปพลิเคชันนั้นเอง
ตกลงจุดตรวจสอบสำหรับการเปลี่ยนระบบและการย้อนกลับ
ก่อนเปลี่ยนไปใช้ระบบใหม่ (cutover) ให้กำหนดขอบเขตการหยุดให้บริการที่ยอมรับได้ วิธีระงับการเปลี่ยนแปลงข้อมูลชั่วคราวหรือวิธีซิงค์ข้อมูล ลำดับการตรวจสอบ และผู้ที่มีอำนาจตัดสินใจย้อนกลับระบบ แผนย้อนกลับต้องอธิบายวิธีจัดการข้อมูลใหม่ด้วย ไม่ใช่แค่วิธีเปลี่ยนเส้นทางทราฟฟิกกลับไปที่เซิร์ฟเวอร์เดิม
คำถามที่ควรหาคำตอบให้ชัด เช่น
- ระบบปลายทางต้องผ่านเงื่อนไขใดจึงถือว่าพร้อมรับทราฟฟิก?
- ต้องผ่านการตรวจสอบใดบ้างก่อนเลิกใช้ระบบเดิม?
- ช่วงเวลาที่ยังย้อนกลับระบบได้ยาวนานเท่าใด?
- จะตรวจสอบข้อมูลที่บันทึกเข้ามาระหว่างช่วงเวลานั้นให้ตรงกันอย่างไร?
- หากงานที่ทำงานเบื้องหลังล้มเหลว ใครจะได้รับการแจ้งเตือน?
ไม่มีการรับประกันที่ใช้ได้กับทุกระบบว่าจะไม่มีเวลาหยุดระบบเลย เป้าหมายที่ทำได้จริงขึ้นอยู่กับระบบงานและการออกแบบการเปลี่ยนระบบ
เปรียบเทียบสถานการณ์การดำเนินงานแบบครบถ้วน
การประมาณการที่มีประโยชน์ครอบคลุมมากกว่าค่าประมวลผล ควรพิจารณาพื้นที่เก็บข้อมูล การส่งข้อมูลผ่านเครือข่าย ฐานข้อมูล ใบอนุญาต การติดตามระบบ การสำรองข้อมูล การสนับสนุน งานย้ายระบบ และงานดูแลระบบอย่างต่อเนื่อง ระบุสมมติฐานเบื้องหลังแต่ละรายการ และผู้ที่สามารถยืนยันสมมติฐานเหล่านั้นได้
ต้นแบบวางแผนต้นทุนคลาวด์ของ BEEK แสดงความโปร่งใสในลักษณะนี้ด้วยอัตราสมมติ เมื่อเปลี่ยนค่าที่ป้อน รายละเอียดต้นทุนที่แสดงก็จะเปลี่ยนตาม เครื่องมือนี้เป็นต้นแบบ ไม่ใช่ใบเสนอราคาของ AWS หรือ Azure และไม่ใช่การคาดการณ์ค่าบริการที่คุณจะต้องจ่ายจริง
วางแผนการส่งต่อระบบ
การตรวจสอบที่ผ่านไปด้วยดีไม่ได้ทดแทนการมีผู้รับผิดชอบดูแลระบบอย่างต่อเนื่อง ตกลงให้ชัดว่าใครเป็นผู้จัดการสิทธิ์เข้าถึง ตรวจสอบการสำรองข้อมูล รับมือการแจ้งเตือน ทบทวนต้นทุน และดูแลเอกสารการติดตั้งระบบ แล้วผูกความรับผิดชอบเหล่านี้ไว้กับรายการระบบงาน เพื่อให้ระบบยังดูแลต่อได้หลังทีมย้ายระบบส่งต่องานแล้ว
หากต้องการหารือขอบเขตงาน ดูบริการพัฒนาระบบคลาวด์และย้ายระบบขึ้นคลาวด์ หรือติดต่อ BEEK