MIG-11 · ประสบการณ์
ผมดำเนินการย้ายระบบและคัตโอเวอร์ โดยเตรียมโรลแบ็กไว้พร้อมก่อนจะแตะต้องระบบที่ใช้งานจริง
ผมย้ายระบบโดยไม่มีดราม่า ไม่ว่าจะเป็นออนเพรมิสถึงออนเพรมิส ออนเพรมิสขึ้นคลาวด์ หรือการอัปเกรดเวอร์ชัน ผมเขียนแผนการเปลี่ยนแปลงและโรลแบ็กขึ้นมาก่อน จากนั้นจึงทำคัตโอเวอร์ภายในช่วงเวลาที่เราตกลงกันไว้ และตรวจสอบเทียบกับจุดตรวจที่ชัดเจน ถ้าจุดตรวจใดไม่ผ่าน ผมก็โรลแบ็ก ส่วนนั้นเป็นความรับผิดชอบของผม ไม่ใช่เรื่องที่คุณต้องมาค้นพบเองตอนตีสอง
01 · สิ่งที่ผมทำ
เนื้องานจริง
- ย้ายเวิร์กโหลดออนเพรมิสระหว่างโฮสต์ คลัสเตอร์ และดาต้าเซ็นเตอร์ ด้วยการย้ายแบบ P2V และ V2V โดยลดดาวน์ไทม์ให้น้อยที่สุด
- ยกระบบออนเพรมิสขึ้นคลาวด์ ครอบคลุมทั้งแอปพลิเคชัน ข้อมูล DNS และการพึ่งพาด้านตัวตน ไม่ใช่แค่ตัวเครื่องเสมือนเท่านั้น
- ดำเนินการอัปเกรดเวอร์ชันให้กับระบบปฏิบัติการ ไฮเปอร์ไวเซอร์ และบริการหลัก พร้อมเส้นทางถอยกลับที่ผ่านการทดสอบแล้ว
- เขียนลำดับขั้นตอนคัตโอเวอร์และโรลแบ็กไว้ก่อนที่จะมีการเปลี่ยนแปลงใดๆ กับระบบที่ใช้งานจริง เพื่อให้ทั้งสองทิศทางถูกบันทึกเป็นเอกสารไว้ก่อน
- กำหนดช่วงเวลาบำรุงรักษา จุดตรวจการตรวจสอบ และผู้ที่อนุมัติในแต่ละจุด
- ย้ายสตอเรจและข้อมูลพร้อมการตรวจสอบเช็กซัมและการกระทบยอด เพื่อไม่ให้มีสิ่งใดหายไปเงียบๆ ระหว่างการขนย้าย
- ตรวจสอบการเสริมความแข็งแกร่งด้านความปลอดภัยและการตั้งค่าซ้ำอีกครั้งหลังการย้าย เพื่อให้สภาพแวดล้อมใหม่ไม่อ่อนแอกว่าของเดิม
02 · สิ่งที่คุณจะได้รับ
สิ่งที่เหลืออยู่กับคุณในตอนท้าย
- แผนการเปลี่ยนแปลงที่จัดทำเป็นเอกสารและโรลแบ็กที่เขียนไว้ ทั้งคู่ผ่านการตรวจทานก่อนช่วงเวลาทำงานจะเริ่มขึ้น
- คัตโอเวอร์ที่ราบรื่นภายในช่วงเวลาที่ตกลงกัน ตรวจสอบเทียบกับจุดตรวจ แทนที่จะใช้การคาดเดา
- เส้นทางถอยกลับที่ใช้งานได้จริง โดยผมเป็นผู้รับผิดชอบหากจุดตรวจใดไม่ผ่าน
- หลักฐานหลังการย้ายที่ยืนยันว่าสภาพแวดล้อมใหม่ได้รับการตั้งค่าและเสริมความแข็งแกร่งด้านความปลอดภัยอย่างถูกต้อง
- เอกสารส่งมอบงานที่ทีมของคุณอ่านและทำซ้ำตามได้ เพื่อให้องค์ความรู้ไม่หายไปพร้อมกับผม
03 · เครื่องมือและความรู้
สิ่งที่ผมใช้ทำงานในด้านนี้
04 · วิธีที่ผมทำงาน
วางแผน กำหนดขอบเขต และรับผิดชอบจนจบ
เริ่มจากการพูดคุยเพื่อกำหนดขอบเขตงาน 30 นาที และการประเมินเป็นลายลักษณ์อักษรภายในวันเดียวกันว่างานนี้เหมาะสมกันดีหรือไม่ จากนั้นผมจะแมปการพึ่งพากันของระบบที่แท้จริง ไม่ใช่แค่เซิร์ฟเวอร์ที่เห็นได้ชัด แล้วเขียนแผนการเปลี่ยนแปลงแบบเรียงลำดับ พร้อมแนบโรลแบ็กไว้ ก่อนที่ระบบที่ใช้งานจริงแม้แต่ระบบเดียวจะถูกย้าย เราตกลงกันเรื่องช่วงเวลาทำงาน จุดตรวจการตรวจสอบ และเกณฑ์การถอยกลับไว้ล่วงหน้า จึงไม่มีการด้นสดกลางคันระหว่างคัตโอเวอร์ ผมทำคัตโอเวอร์ภายในช่วงเวลานั้น ตรวจทุกจุดตรวจทีละจุด และหากมีจุดใดไม่ผ่าน ผมก็โรลแบ็กกลับไปยังสถานะที่ทราบว่าใช้งานได้ เมื่อเสร็จสิ้น คุณจะได้รับทั้งหลักฐานและขั้นตอนที่เขียนไว้เป็นเอกสาร เพื่อให้คนถัดไปเดินตามเส้นทางเดียวกันได้
05 · คำถาม
คำถามที่ดี คำตอบที่ตรงไปตรงมา
คุณทำให้ดาวน์ไทม์คาดการณ์ได้อย่างไร?
ด้วยการทำคัตโอเวอร์ภายในช่วงเวลาที่กำหนด โดยมีลำดับขั้นตอนตายตัวและจุดตรวจที่ชัดเจน ก่อนเริ่มงานเรารู้อยู่แล้วว่าความสำเร็จในแต่ละขั้นตอนหน้าตาเป็นอย่างไร และแต่ละขั้นตอนควรใช้เวลาเท่าใด ช่วงเวลาทำงานจึงเป็นสิ่งที่วางแผนไว้ ไม่ใช่แค่ความหวัง
ถ้าการย้ายระบบเกิดผิดพลาดกลางคันระหว่างคัตโอเวอร์จะเกิดอะไรขึ้น?
ผมจะโรลแบ็กกลับไปยังสถานะที่ทราบว่าใช้งานได้ล่าสุด โดยใช้เส้นทางถอยกลับที่เขียนและตรวจทานไว้แล้วก่อนเริ่มงาน การโรลแบ็กถูกตัดสินใจไว้ล่วงหน้า และเป็นหน้าที่ของผมที่จะลงมือทำ ไม่ใช่สิ่งที่เราต้องมานั่งคิดกันตอนอยู่ภายใต้แรงกดดัน
คุณทำการย้ายจากออนเพรมิสขึ้นคลาวด์ได้ไหม หรือทำได้แค่ออนเพรมิสถึงออนเพรมิส?
ได้ทั้งสองแบบ รวมถึงการอัปเกรดเวอร์ชันด้วย การย้ายจากออนเพรมิสขึ้นคลาวด์จะให้ความสำคัญเป็นพิเศษกับเรื่องตัวตน (identity), DNS, การเคลื่อนย้ายข้อมูล และการพึ่งพากันของระบบ เพราะจุดเหล่านี้คือที่ที่การย้ายขึ้นคลาวด์มักจะพังมากกว่าตัวเวิร์กโหลดเอง
06 · ประสบการณ์ที่เกี่ยวข้อง
งานในด้านใกล้เคียงที่ผมทำ
ต้องการให้ดูแลงานนี้ไหม?
บอกผมมาว่าคุณกำลังพยายามย้ายอะไร และติดอยู่ตรงไหน แค่ไม่กี่ประโยคก็เพียงพอสำหรับการเริ่มต้นแล้ว และข้อความจะส่งตรงถึงกล่องจดหมายของผม