Runbook Cutover

ระลูก migration เดียว ตั้งแต่การ freeze สองสัปดาห์ไปถึงการตรวจสอบย้อนหลัง เวลาด้านล่างถือว่าหน้าต่าง weekend และ migration 10–30 racks; ระลูกที่ใหญ่กว่าจะถูกแยกแทนที่จะขยาย สองอย่างที่ทำให้นี่เป็น runbook ไม่ใช่แผน: ทุกขั้นตอนมีเจ้าของที่ระบุชัด และเกณฑ์ go/no-go ตัดสินใจสัปดาห์ก่อนคืนที่ไม่มีใครคิดได้ชัด

T	เวลา	การดำเนิน	เจ้าของ	รายละเอียด
T-14d	สองสัปดาห์ก่อน	อนุมัติการเปลี่ยนแปลง ระลูกล็อกแล้ว	ผู้นำการอพย้าย	คำขออนุมัติการเปลี่ยนแปลง เนื้อหาระลูกตรึงแล้ว ทุกอย่างที่ไม่อยู่ในรายการที่ T-14 จะไม่ migrate ในระลูกนี้ — การเพิ่มเติมช่วงท้ายคือวิธีที่ระลูกสะอาดกลายเป็น incident
T-7d	หนึ่งสัปดาห์ก่อน	Target ติด rack, ต่อสาย, ให้ power, เข้าถึงได้	วิศวกรรมภาคสนาม	ระบบแทนที่หรือระบบรับ ติดตั้งที่เป้าหมาย บนวงจรที่ถูกต้อง พร้อม out-of-band access ที่ได้ทดสอบจากนอกเครือข่ายองค์กร
T-72h	วันอังคาร	Dry run การ validation script	เจ้าของแอปพลิเคชัน	รัน post-move checks เทียบกับ production estate ปัจจุบัน หากการตรวจสอบล้มเหลวตอนนี้ มันไม่ใช่ migration failure เวลา 2 a.m. วันเสาร์ — มันเป็น broken check
T-48h	วันพุธ	DNS TTL ลดเหลือ 300 วินาที	วิศวกรรมเครือข่าย	ลดล่วงหน้าเพียงพอ เพื่อให้ resolver ทุกตัวรับ TTL สั้นก่อน cutover
T-24h	วันพฤหัสบดี	Backup เต็มจำนวนและทดสอบการ restore	ทีม Backup	ยืนยัน restorable แล้ว ไม่ใช่เพียงเสร็จสิ้น Backup ที่ไม่มีใครพยายาม restore คือความเชื่อ ไม่ใช่การควบคุม
T-4h	วันศุกร์ 17:00	Change freeze เริ่มต้น bridge เปิด	ผู้นำ Migration	หยุด change ที่ไม่เกี่ยวข้องทั้งหมดทั่วระบบ Bridge call เปิดกับเจ้าของ infrastructure, network, application และทีม on-site
T-0	วันศุกร์ 21:00	Go / no-go #1	ผู้นำ Migration + business sponsor	ตรวจสอบเกณฑ์ออกเสียง: backup ยืนยันแล้ว target ถึงได้ ทีมครบ ไม่มี P1 ที่อื่น No หนึ่งก็ไม่ได้เลย เลื่อนไปเสียสุดสัปดาห์ แต่ดำเนินการบน no ที่ไม่มั่นใจ เสียไตรมาส
T+0:15	วันศุกร์ 21:15	Graceful shutdown, delta sync สุดท้าย	เจ้าของ application	หยุด application ตามลำดับ dependency delta replication สุดท้าย flush แล้ว ระบบต้นทาง mark read-only เพื่อไม่ให้มีการเขียนข้อมูลไปยัง site ที่กำลังจะว่าง
T+1:00	วันศุกร์ 22:00	Decommission จากต้นทาง โหลด ขนส่ง	วิศวกรรมภาคสนาม	ติดป้ายชื่อ rail และสาย cable เมื่อออกมา ถ่ายรูปด้านหน้าและด้านหลัง cabinet ทั้งหมดก่อนปลดเชื่อมใดๆ — เครื่องมือ rollback ที่เร็วที่สุด
T+4:00	วันเสาร์ 01:00	รับ ติด rack เคเบิล เปิดระบบ	วิศวกรรมสนาม	เปิดระบบจ่ายไฟแบบจัดกลุ่มทีละรอบแทนการเปิดพร้อมกันทั้งหมด เพื่อให้ breaker ที่ tripped สามารถระบุตัวเองได้แทนที่จะทำให้ row ล่มสลาย
T+7:00	วันเสาร์ 04:00	Go / No-go #2 — นาฬิกา Rollback	ผู้นำการโยกย้าย	จุดสุดท้ายที่ rollback ยังเป็นไปได้ภายในช่วงเวลาที่ตั้งไว้ หากระบบไม่ได้รับไฟและไม่สามารถเข้าถึงได้ตามเวลาที่กำหนด ให้ทำการ rollback — การตัดสินใจได้ทำไปแล้วที่ T-14 ไม่ใช่ตอนนี้
T+8:00	วันเสาร์ 05:00	Network Cutover, DNS ชี้ไปยังจุดใหม่	วิศวกรรมเครือข่าย	Routing เปลี่ยนแปลง, นโยบาย Firewall ถูกเปิดใช้งาน, DNS records ชี้ไปยังจุดใหม่. Monitoring ควรแสดงสีเขียวจากเซิร์ฟเวอร์ใหม่ก่อนที่จะบอกให้ใครรู้ว่ามันทำงานได้
T+10:00	วันเสาร์ 07:00	ผ่านการตรวจสอบอัตโนมัติ	เจ้าของ Application	Script เดียวกันจาก dry run ใช้กับ target เดี๋ยวนี้ ผ่านหรือไม่ผ่าน ไม่ใช่ความคิดเห็น
T+14:00	วันเสาร์ 11:00	การตรวจสอบและลงนามอนุมัติทางธุรกิจ	ผู้สนับสนุนทางธุรกิจ	ผู้ใช้ที่ระบุชื่อทำการธุรกรรมจริง ลงนามอนุมัติเป็นลายลักษณ์อักษรสำหรับแต่ละ Application และมันเป็นความรับผิดชอบของเจ้าของแอปพลิเคชันมากกว่า Migration Team
T+24:00	วันอาทิตย์ 21:00	ปลดเปิด Freeze, Hypercare เริ่มต้น	ผู้นำการโยกย้าย	ปลดเปิด Freeze, ให้การสนับสนุนระดับสูงเป็นเวลา 5 วันทำการ และระบบต้นทางรักษาไว้ตามเดิมจนกว่า Hypercare จะปิด
T+7d	ศุกร์ถัดไป	บทวิจารณ์ย้อนหลัง, Runbook อัปเดต	ผู้นำการโยกย้าย	การแก้ไขที่บันทึกในรันบุ๊ก ขณะที่รายละเอียดยังชัดเจน Wave ทุกครั้งในภายหลังจะสืบทอดการแก้ไขเหล่านี้

เกณฑ์ No-go

ตกลงกันในการอนุมัติการเปลี่ยนแปลง อ่านออกมาดังๆ ในแต่ละ go/no-go ครั้ง การละเมิดเกณฑ์ใดเกณฑ์หนึ่งคือการหยุดดำเนินการ ประเด็นของการบันทึกไว้ล่วงหน้าคือ ในเวลา 4 โมงเช้า ข้อโต้แย้งได้รับการแก้ไขแล้ว

ไม่ได้ยืนยันว่าสำรองข้อมูลสามารถกู้คืนได้
ไซต์เป้าหมายไม่สามารถเข้าถึงได้ผ่าน out-of-band
ผู้จัดการที่ระบุชื่อหายไปจาก bridge
มี P1 ที่ยังดำเนินอยู่ที่ใดก็ตามในระบบ
วงจรของผู้ให้บริการยังไม่ได้รับการยืนยันว่าใช้งานได้
เส้นทาง rollback ไม่ได้ทดสอบตั้งแต่การเปลี่ยนแปลงครั้งสุดท้าย

นาฬิกา rollback

Rollback จึงสามารถดำเนินการได้จริงเมื่อมันพอดีกับหน้าต่างเวลาที่เหลือ วัดเวลาในระหว่าง pilot: ใช้เวลานานเท่าใดในการ re-rack, re-cable, เปิดพาวเวอร์ และ re-point DNS ไปยังไซต์ต้นทาง ลบเวลานั้นออกจากจุดสิ้นสุดของหน้าต่างเวลา และคุณจะได้เวลาตัดสินใจที่แน่นอน — go/no-go ครั้งที่สอง ถ้าถึงเวลานั้นโดยไม่มีไซต์เป้าหมายที่เปิดใช้งานและเข้าถึงได้ หมายความว่าต้อง rollback โดยไม่คำนึงถึงความรู้สึกของทีมว่าใกล้เสร็จ ทีมที่ข้ามขั้นตอนนี้ไม่ได้หลีกเลี่ยง rollback; พวกเขาค้นพบในเวลา 7 โมงเช้า ว่าพวกเขาไม่มีตัวเลือก rollback อีกต่อไป

สิ่งที่ควรนำมา

Rack elevations และแผนภาพการเดินสาย พิมพ์ออกมา — เครือข่ายที่คุณต้องปรึกษาอาจเป็นเครือข่ายที่คุณกำลังย้าย
รูปถ่ายหน้าและหลัง cabinet ทุกตู้ ถ่ายก่อนปลดการเชื่อมต่อใด ๆ
สำรอง optics, patch cables, rails, PDU และสำรองอย่างน้อยหนึ่งรายการของสิ่งใด ๆ ที่มาจากแหล่งเดียว
ข้อมูลประจำตัว out-of-band access ทดสอบจากการเชื่อมต่อโทรศัพท์มือถือ ไม่ใช่เครือข่ายสำนักงาน
แผนการขยายปัญหา พร้อมหมายเลขโทรศัพท์มือถือ รวมถึงเบอร์ติดต่อ remote hands ของผู้ดำเนินการ
Validation script ได้รับการทดสอบกับสภาพแวดล้อมการผลิตแล้วในระหว่าง dry run

ก่อนรันบุ๊ก มาที่แผน

Cutover จึงเกิดขึ้นได้ดีเมื่อการค้นหา (discovery) เกิดขึ้นได้ดี ทำตามรายการตรวจสอบ migration checklist ก่อน จำลองโปรแกรมด้วย cost calculator และสร้างรายชื่อเป้าหมายจาก facility catalog

ใบเสนอราคาสำหรับไซต์เป้าหมาย

บอกเราขนาด wave และตลาด — เราจะส่งคืนสิ่งอำนวยความสะดวกที่เหมาะสมและราคาเปรียบเทียบ