Azure Fundamentals · درس

تحديد RTO وRPO وطبقات الاسترداد

صنّف أحمال العمل حسب درجة الأهمية، وعيّن أهداف RTO وRPO، واربطها بقدرات الاسترداد في Azure وتواتر النسخ المتماثل المناسبين

تحديد RTO وRPO وطبقات الاسترداد درس مجاني في Azure Fundamentals على CoddyKit. هذا هو الدرس 1 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Azure Fundamentals، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Azure Fundamentals 4 دروس في المجموع.

أساسيات تخطيط استمرارية الأعمال

تخطيط استمرارية الأعمال (BCP) هو عملية ضمان استمرار وظائف الأعمال الحيوية أثناء الكارثة وبعدها. وفي الحوسبة السحابية، يعني ذلك تصميم أنظمة يمكنها التعافي من الأعطال ضمن حدود مقبولة للوقت وفقدان البيانات. ويحدد مقياسان أساسيان — RTO وRPO — معنى «المقبول» لكل حمل عمل.

هدف وقت التعافي (RTO)

هدف وقت التعافي (RTO) هو أقصى مدة مقبولة يمكن أن يظل فيها النظام غير متصل بالإنترنت بعد وقوع كارثة. وهو يجيب عن السؤال: «كم من الوقت يمكن للأعمال تحمّل توقف هذا التطبيق؟». ويُعبَّر عن RTO بوحدات زمنية، مثل الساعات أو الدقائق أو الثواني. فقد يكون RTO لنظام معالجة المدفوعات 15 دقيقة، بينما قد يكون لبوابة الموارد البشرية الداخلية 24 ساعة.

# RTO examples by workload type:
# Payment processing: RTO = 15 minutes
# E-commerce storefront: RTO = 1 hour
# Internal reporting: RTO = 4 hours
# Archive/audit data: RTO = 24 hours

# Shorter RTO = more expensive architecture required
# (warm standby, active-active, auto-failover)

هدف نقطة التعافي (RPO)

هدف نقطة التعافي (RPO) هو أقصى مقدار مقبول من فقدان البيانات مقاسًا بالوقت. وهو يجيب عن السؤال: «ما مقدار البيانات التي يمكن للأعمال تحمّل فقدانها؟». إذا كان RPO ساعة واحدة، تقبل المؤسسة فقدان ما يصل إلى ساعة واحدة من المعاملات. ويحدد RPO مدى تكرار ضرورة إجراء نسخ احتياطي للبيانات أو نسخها بشكل متماثل. ويتطلب RPO البالغ 0 نسخًا متماثلًا متزامنًا، وهو مكلف وقد يؤثر في أداء الكتابة.

# RPO examples:
# Financial transactions: RPO = 0 (no data loss tolerated)
# E-commerce orders: RPO = 5 minutes
# User-generated content: RPO = 1 hour
# Configuration/metadata: RPO = 24 hours

# Shorter RPO = more frequent replication or synchronous writes
# = higher cost and possibly higher latency

RTO مقابل RPO: الفرق الأساسي

من المهم عدم الخلط بين RTO وRPO:

RTO يتعلق بالوقت — مدة توقف النظام
RPO يتعلق بالبيانات — مقدار البيانات المفقودة

قد يكون للنظام RTO قصير (تعافٍ سريع) لكن RPO طويل (قبول فقدان كبير للبيانات)، أو العكس. والمثالي هو أن يكون كلاهما قصيرًا، لكن تحقيق ذلك يتطلب استثمارًا كبيرًا في النسخ المتماثل وسعة الاستعداد الفوري.

تصنيف أحمال العمل حسب الأهمية

لا تتمتع جميع أحمال العمل بالأهمية نفسها. ويتمثل نهج شائع في تصنيف أحمال العمل ضمن طبقات التعافي استنادًا إلى تأثيرها في الأعمال:

الطبقة 1 (بالغة الأهمية للمهمة) — RTO/RPO صارمان، وتكلفة أعلى (مثل المدفوعات ومنصات التداول)
الطبقة 2 (مهمة للأعمال) — RTO/RPO متوسطان (مثل CRM وERP)
الطبقة 3 (غير مهمة) — RTO/RPO مرنان، وتكلفة أقل (مثل بيئات التطوير والمحفوظات)

ربط الطبقات بخيارات التعافي في Azure

ترتبط طبقات التعافي المختلفة بإمكانات مختلفة في Azure:

الطبقة 1 — عمليات الكتابة متعددة المناطق في Cosmos DB، ومجموعات تجاوز الفشل التلقائي في SQL، وبنية نشطة-نشطة، وTraffic Manager
الطبقة 2 — Azure Site Recovery إلى منطقة ثانوية، والنسخ المتماثل الجغرافي لـ SQL (نسخة متماثلة للقراءة)، ونسخ احتياطية يومية مع الاحتفاظ بها لمدة 30 يومًا
الطبقة 3 — Azure Backup مع جداول أسبوعية، ومن دون نسخ متماثل، والاستعادة من لقطة

حساب تكلفة التوقف

لتبرير الاستثمار في بنية ذات RTO منخفض، احسب تكلفة التوقف لحمل العمل. ويشمل ذلك الإيرادات المفقودة، وغرامات اتفاقيات مستوى الخدمة المفروضة على العملاء، وفقدان إنتاجية الموظفين، والضرر الذي يلحق بالسمعة. إذا بلغت تكلفة ساعة واحدة من التوقف 500,000 دولار، فمن السهل تبرير إنفاق 50,000 دولار شهريًا على إعداد نشط-نشط. استخدم هذه الأرقام لبناء مبرر تجاري لطبقة التعافي المناسبة.

# Cost of downtime formula:
# Hourly revenue at risk + (staff hours idle x hourly rate)
# + SLA penalty exposure + estimated reputational cost

# Example:
# Revenue: $100,000/hour
# Staff: 500 people x $60/hour = $30,000/hour idle
# SLA penalties: $5,000/hour
# Total cost of downtime: ~$135,000 per hour

Azure Site Recovery للطبقة 2

تُعد Azure Site Recovery (ASR) الخدمة الأساسية لتحقيق أهداف RTO/RPO للطبقة 2 في Azure. إذ تنسخ ASR الأجهزة الظاهرية باستمرار إلى منطقة ثانوية، ويمكنها بدء تجاوز الفشل خلال دقائق. ويبلغ تواتر النسخ المتماثل لأجهزة Azure الظاهرية كل 30 ثانية (متسقًا مع الأعطال) أو كل ساعة إلى 4 ساعات (متسقًا مع التطبيق)، ما يمنح RPO يقع عادةً ضمن هذا النطاق وفقًا للإعدادات.

# Enable replication for a VM with ASR:
az site-recovery protected-item create \
  --resource-group myRG \
  --vault-name myRecoveryVault \
  --fabric-name 'Primary' \
  --container-name 'asr-a2a-default-eastus-container' \
  --protected-item-name myVM-protected

RPO وتواتر النسخ الاحتياطي

بالنسبة إلى أحمال العمل التي يُقاس فيها RPO بالساعات، يكفي استخدام Azure Backup مع جدول مناسب. فعلى سبيل المثال، يتطلب RPO البالغ 4 ساعات فاصل نسخ احتياطي لا يتجاوز 4 ساعات. ويدعم Azure Backup السياسات المحسّنة التي تتيح جداول نسخ احتياطي كل ساعة لأجهزة Azure الظاهرية. وبالنسبة إلى قواعد البيانات، يمكن للاستعادة إلى نقطة زمنية (PITR) مع النسخ الاحتياطية لسجل المعاملات تحقيق RPO أقل من ساعة واحدة بتكلفة أقل من ASR.

توثيق التزامات RTO وRPO

يجب توثيق أهداف RTO وRPO رسميًا في تحليل تأثير الأعمال (BIA) ومراجعتها من جانب أصحاب المصلحة التقنيين والتجاريين على حد سواء. ويربط BIA كل تطبيق بطبقة التعافي الخاصة به، ويوثق أهداف RTO/RPO، ويحدد خدمات Azure التي ستحقق هذه الأهداف، ويحدد جدول الاختبارات (عدد مرات التحقق من صحة خطة التعافي من الكوارث من خلال التدريبات).

الاختبار مقابل أهداف RTO/RPO

تظل أهداف RTO وRPO طموحة إلى أن يتم التحقق منها من خلال اختبارات التعافي من الكوارث. أثناء اختبار التعافي من الكوارث، قِس الوقت الفعلي اللازم للتعافي (هل يحقق RTO المحدد؟) ومقدار فقدان البيانات الفعلي عند نقطة التعافي (هل يحقق RPO المحدد؟). إذا كشف الاختبار عن فجوات، فحدّث البنية أو الإجراءات حتى تتحقق الأهداف باستمرار. ووثّق نتائج الاختبار لأغراض عمليات تدقيق الامتثال.

تحقق سريع

اختبر مدى فهمك لمفاهيم Microsoft Azure Fundamentals (AZ-900) الواردة في هذا الدرس.

مراجعة الدرس

تعلمت في هذا الدرس أن RTO هو أقصى وقت توقف مقبول، بينما RPO هو أقصى فقدان مقبول للبيانات مقاسًا بالوقت؛ وأن أحمال العمل تُصنَّف ضمن طبقات التعافي التي ترتبط بخدمات Azure محددة؛ وأن الاختبار ضروري للتحقق من إمكانية تحقيق أهداف RTO/RPO. بعد ذلك، سنستكشف خطط التعافي وتجاوز الفشل التلقائي باستخدام Azure Site Recovery.

الأسئلة الشائعة

هل درس «تحديد RTO وRPO وطبقات الاسترداد» مجاني؟

نعم — نص درس «تحديد RTO وRPO وطبقات الاسترداد» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Azure Fundamentals، انتقل إلى CoddyKit PRO. تتضمن دورة Azure Fundamentals 4 دروس في المجموع.

ماذا ستتعلم في «تحديد RTO وRPO وطبقات الاسترداد»؟

صنّف أحمال العمل حسب درجة الأهمية، وعيّن أهداف RTO وRPO، واربطها بقدرات الاسترداد في Azure وتواتر النسخ المتماثل المناسبين تتمرن على Azure Fundamentals مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ Azure Fundamentals؟

لا تُشترط خبرة سابقة. Azure Fundamentals على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 1 من أصل 4.

كم من الوقت يستغرق درس «تحديد RTO وRPO وطبقات الاسترداد»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس Azure Fundamentals هذا؟

نعم. كل درس في Azure Fundamentals يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

← العودة إلى Azure Fundamentals