Azure Fundamentals · บทเรียน

การทดสอบ DR โดยไม่กระทบระบบ

ดำเนินการทดสอบการสลับใช้งานไปยังเครือข่ายแยกเพื่อยืนยันแผนการกู้คืนตั้งแต่ต้นจนจบ วัด RTO จริง และบันทึกช่องว่างที่ต้องแก้ไข

การทดสอบ DR โดยไม่กระทบระบบ เป็นบทเรียน Azure Fundamentals ฟรีบน CoddyKit นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Azure Fundamentals และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Azure Fundamentals มีบทเรียนทั้งหมด 4 บทเรียน

เหตุใดการทดสอบ DR จึงจำเป็นอย่างยิ่ง

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

ฟีเจอร์การสลับระบบทดสอบ

Test Failover เป็นฟีเจอร์ใน Azure Site Recovery ที่มีมาให้ในตัว ช่วยให้คุณจำลองการสลับระบบไปยังภูมิภาคสำรองได้ โดยไม่รบกวนระบบที่ใช้งานจริง ระหว่างการสลับระบบทดสอบ ASR จะสร้างสำเนาของ VM ที่จำลองแบบไว้ในเครือข่ายเสมือนแบบแยกในภูมิภาคสำรอง VM ของระบบที่ใช้งานจริงยังคงทำงานตามปกติในภูมิภาคหลัก ผู้ใช้จริงจึงไม่มีความเสี่ยง

# Trigger a test failover for a recovery plan:
az site-recovery recovery-plan test-failover \
  --resource-group myRG \
  --vault-name myRecoveryVault \
  --name myRecoveryPlan \
  --failover-direction PrimaryToRecovery \
  --network-id '/subscriptions/.../virtualNetworks/testFailoverVNet'

การแยกสภาพแวดล้อมทดสอบ

VNet ทดสอบที่แยกออกมาต้องไม่มีการเชื่อมต่อกับระบบที่ใช้งานจริง เพื่อป้องกันไม่ให้ VM ทดสอบเขียนข้อมูลลงฐานข้อมูลจริงโดยไม่ตั้งใจ ส่งอีเมลถึงลูกค้าจริง หรือเรียกใช้ธุรกรรมการชำระเงิน ให้สร้าง test failover VNet โดยเฉพาะ ซึ่งไม่มีการเพียร์กับ VNet ของระบบที่ใช้งานจริงและไม่มีการเข้าถึงอินเทอร์เน็ต จากนั้นใช้ VNet นี้สำหรับการฝึกซ้อม DR โดยเฉพาะ

# Create an isolated test VNet for DR drills:
az network vnet create \
  --resource-group drRG \
  --name testFailoverVNet \
  --address-prefix 10.99.0.0/16 \
  --subnet-name testSubnet \
  --subnet-prefix 10.99.1.0/24
# NOTE: Do NOT peer this VNet to any production VNet

สิ่งที่ต้องตรวจสอบระหว่างการทดสอบ DR

การทดสอบ DR ควรตรวจสอบเกณฑ์เฉพาะดังต่อไปนี้:

เวลาเริ่มต้น — VM ทั้งหมดเริ่มทำงานภายในช่วงเวลาที่คาดไว้หรือไม่
การเริ่มต้นแอปพลิเคชัน — แอปพลิเคชันเริ่มต้นได้อย่างถูกต้องเมื่อเชื่อมต่อกับฐานข้อมูลที่กู้คืนแล้วหรือไม่
ความสมบูรณ์ของข้อมูล — ข้อมูล ณ จุดกู้คืนมีความสอดคล้องและครบถ้วนหรือไม่
Actual RTO — วัดเวลาที่ผ่านไปทั้งหมดตั้งแต่เรียกใช้การสลับระบบจนแอปพลิเคชันเริ่มให้บริการคำขอ
การทำงานของสมุดงาน — สคริปต์ระบบอัตโนมัติทั้งหมดทำงานเสร็จสมบูรณ์หรือไม่

การวัด Actual RTO

ระหว่างการทดสอบ ให้เริ่มจับเวลาทันทีที่เรียกใช้การสลับระบบทดสอบ หยุดจับเวลาเมื่อยืนยันได้ว่าแอปพลิเคชันทำงานสมบูรณ์แล้ว (การตรวจสอบความสมบูรณ์ของตัวจัดสรรภาระงานส่งคืน 200 OK) เวลานี้คือ Actual RTO ของคุณ เปรียบเทียบกับ RTO เป้าหมาย หาก Actual RTO สูงกว่าเป้าหมาย ให้ระบุคอขวด เช่น VM เริ่มต้นช้า การเริ่มต้นฐานข้อมูลใช้เวลานาน หรือการเผยแพร่ DNS ล่าช้า แล้วแก้ไขปัญหาเหล่านั้น

# During DR test, record timestamps:
# T0: Test failover triggered
# T1: All VMs in group 1 (database) running
# T2: All VMs in group 2 (app tier) running
# T3: All VMs in group 3 (web tier) running
# T4: Health probe returns 200 OK on all instances
# Actual RTO = T4 - T0
# Compare to target RTO, document any gaps

การตรวจสอบข้อมูล ณ จุดกู้คืน

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

# Example data verification after test failover:
# 1. Connect to recovered database
# 2. Run: SELECT COUNT(*) FROM orders WHERE created_at > DATEADD(hour, -1, GETUTCDATE())
# 3. Compare count to production database count for the same window
# 4. Check for any orphaned records or constraint violations

การล้างข้อมูลหลังการสลับระบบทดสอบ

เมื่อการทดสอบเสร็จสิ้น คุณต้อง ล้างทรัพยากรการสลับระบบทดสอบ ซึ่งได้แก่ VM ทดสอบ ดิสก์ และอินเทอร์เฟซเครือข่ายในภูมิภาคสำรอง Azure Site Recovery มีการดำเนินการ 'Cleanup test failover' ในพอร์ทัล ซึ่งจะลบทรัพยากรทดสอบทั้งหมดโดยอัตโนมัติ หากลืมล้างข้อมูล จะทำให้เสียค่าใช้จ่ายและทำให้ภูมิภาคสำรองเต็มไปด้วยทรัพยากรเก่าที่ไม่ได้ใช้งาน

# Trigger cleanup after test failover:
az site-recovery recovery-plan test-failover-cleanup \
  --resource-group myRG \
  --vault-name myRecoveryVault \
  --name myRecoveryPlan \
  --notes 'Test completed. RTO = 22 minutes. All checks passed.'

การบันทึกผลการทดสอบ DR

หลังการทดสอบ DR แต่ละครั้ง ให้จัดทำ รายงานการทดสอบ ซึ่งประกอบด้วย วันที่และขอบเขตของการทดสอบ Actual RTO และ RPO ที่ทำได้ รายการตรวจสอบหัวข้อการตรวจสอบพร้อมสถานะผ่าน/ไม่ผ่าน ช่องว่างหรือความล้มเหลวที่พบ และการดำเนินการแก้ไขที่วางแผนไว้ รายงานนี้มีประโยชน์ต่อการตรวจสอบการปฏิบัติตามข้อกำหนด (ISO 27001, SOC 2, HIPAA) และการติดตามพัฒนาการด้านความพร้อมของ DR ในระยะยาว

ความถี่ในการทดสอบ DR

แนวทางปฏิบัติที่ดีที่สุดของอุตสาหกรรมและกรอบการปฏิบัติตามข้อกำหนดมักกำหนดให้ทดสอบ DR อย่างน้อย ปีละครั้ง แต่องค์กรจำนวนมากทดสอบ ทุกไตรมาสหรือแม้แต่ทุกเดือนสำหรับเวิร์กโหลดระดับ Tier 1 การทดสอบที่ถี่ขึ้นช่วยตรวจพบการคลาดเคลื่อนของการตั้งค่าได้เร็วขึ้น และสร้างความมั่นใจรวมถึงความชำนาญให้ทีม ควรทำให้การตั้งค่าและการตรวจสอบการทดสอบเป็นระบบอัตโนมัติมากที่สุด เพื่อลดความพยายามที่ต้องใช้ในการทดสอบบ่อยครั้ง

Azure Chaos Studio สำหรับการทดสอบความยืดหยุ่น

Azure Chaos Studio เป็นบริการวิศวกรรมความโกลาหลที่มีการจัดการ ซึ่งช่วยให้คุณจำลองความล้มเหลวที่ควบคุมได้กับทรัพยากร Azure เพื่อทดสอบความยืดหยุ่นของแอปพลิเคชัน คุณสามารถปิด VM ทำให้โซนล้มเหลว จำกัดการใช้ CPU หรือเพิ่มความหน่วงของเครือข่าย เพื่อสังเกตพฤติกรรมของแอปพลิเคชัน ต่างจากการฝึกซ้อม DR ทั่วไป วิศวกรรมความโกลาหลจะทดสอบว่าแอปพลิเคชัน ลดระดับการทำงานได้อย่างเหมาะสม ภายใต้เงื่อนไขที่บางส่วนล้มเหลวหรือไม่

# Chaos Studio experiment: shut down a VM zone
# 1. Create a chaos experiment in the portal
# 2. Select fault: 'VM Shutdown'
# 3. Target: VMs in Zone 1
# 4. Duration: 10 minutes
# 5. Observe: Does Traffic Manager reroute to Zone 2?
# 6. Check: Application health during and after the fault

วงจรการปรับปรุง DR อย่างต่อเนื่อง

การทดสอบ DR จะมีคุณค่ามากที่สุดเมื่อเป็นส่วนหนึ่งของ วงจรการปรับปรุงอย่างต่อเนื่อง: วางแผน → ดำเนินการ → วัดผล → แก้ไข → ทำซ้ำ หลังการทดสอบแต่ละครั้ง ให้แก้ไขช่องว่างที่พบ อัปเดตสมุดงานและเอกสาร แล้วทดสอบอีกครั้ง เมื่อเวลาผ่านไป ช่องว่างระหว่างค่าเป้าหมาย RTO/RPO ที่ระบุไว้กับค่าที่ทำได้จริงควรลดลง จนคุณผ่านการทดสอบทุกครั้งภายในค่าความคลาดเคลื่อนที่ยอมรับได้อย่างสม่ำเสมอ

ตรวจสอบความเข้าใจอย่างรวดเร็ว

ทดสอบความเข้าใจแนวคิด Microsoft Azure Fundamentals (AZ-900) จากบทเรียนนี้

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า การสลับระบบทดสอบ ช่วยจำลองเหตุการณ์ DR โดยไม่รบกวนระบบที่ใช้งานจริง ด้วยการสร้างสำเนา VM ใน VNet ที่แยกออกมา คุณต้อง วัด Actual RTO และตรวจสอบความสมบูรณ์ของข้อมูล ระหว่างการทดสอบ และควร ล้างทรัพยากรทดสอบ พร้อมบันทึกผลหลังการฝึกซ้อมแต่ละครั้ง บทถัดไปเราจะศึกษาการกู้คืนระบบจากภัยพิบัติโดยเฉพาะสำหรับบริการ PaaS เช่น Azure SQL Database

คำถามที่พบบ่อย

บทเรียน “การทดสอบ DR โดยไม่กระทบระบบ” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การทดสอบ DR โดยไม่กระทบระบบ” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Azure Fundamentals ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Azure Fundamentals มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การทดสอบ DR โดยไม่กระทบระบบ”

ดำเนินการทดสอบการสลับใช้งานไปยังเครือข่ายแยกเพื่อยืนยันแผนการกู้คืนตั้งแต่ต้นจนจบ วัด RTO จริง และบันทึกช่องว่างที่ต้องแก้ไข คุณปฏิบัติ Azure Fundamentals ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Azure Fundamentals หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน Azure Fundamentals บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน

บทเรียน “การทดสอบ DR โดยไม่กระทบระบบ” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน Azure Fundamentals นี้ได้ไหม

ได้ บทเรียน Azure Fundamentals ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

← กลับไปที่ Azure Fundamentals