🌍 Planning for Disaster — التخطيط للكوارث في AWS
تُعد هذه الوحدة دليلك المتكامل لفهم استراتيجيات التعافي من الكوارث (Disaster Recovery — DR) في البيئة السحابية لـ AWS. ستتعرف من خلالها على كيفية تصميم بنى تحتية تتحمل الأعطال وتتعافى بسرعة من الأحداث غير المتوقعة باستخدام مبادئ AWS Well-Architected Framework. تمنحك هذه الوحدة الأدوات والمفاهيم اللازمة لبناء خطط استمرارية أعمال فعّالة تحمي بياناتك وتطبيقاتك بأقل تكلفة وأعلى كفاءة.
1️⃣ Failures Can Occur at Any Scale — الأعطال قد تحدث على أي نطاق
📖 لماذا نفترض أن كل شيء سيتعطل؟
صرّح Werner Vogels — نائب الرئيس وكبير مسؤولي التكنولوجيا في Amazon — مراراً بأن "كل شيء يتعطل، كل الوقت". هذا المبدأ الأساسي يوجّه تصميم البنى السحابية الحديثة: لا تتعامل مع الفشل كاحتمال شاذ بل كحقيقة مؤكدة. تصنف الأعطال إلى ثلاثة مستويات: أحداث صغيرة النطاق (كخادم واحد يتوقف) وأحداث كبيرة النطاق (تؤثر على عدة موارد عبر مناطق توفر) وأحداث عالمية (تأثير واسع يطال عدداً كبيراً من المستخدمين). لكن الحجم ليس كل شيء — فخادم واحد يستضيف سجلات العملاء ليس حدثاً صغيراً، ومصفوفة خوادم قراءة فقط ليست حدثاً كبيراً.
📋 مستويات الأعطال الثلاثة:
صرّح Werner Vogels — نائب الرئيس وكبير مسؤولي التكنولوجيا في Amazon — مراراً بأن "كل شيء يتعطل، كل الوقت". هذا المبدأ الأساسي يوجّه تصميم البنى السحابية الحديثة: لا تتعامل مع الفشل كاحتمال شاذ بل كحقيقة مؤكدة. تصنف الأعطال إلى ثلاثة مستويات: أحداث صغيرة النطاق (كخادم واحد يتوقف) وأحداث كبيرة النطاق (تؤثر على عدة موارد عبر مناطق توفر) وأحداث عالمية (تأثير واسع يطال عدداً كبيراً من المستخدمين). لكن الحجم ليس كل شيء — فخادم واحد يستضيف سجلات العملاء ليس حدثاً صغيراً، ومصفوفة خوادم قراءة فقط ليست حدثاً كبيراً.
- أحداث صغيرة النطاق (Small-scale): خادم واحد يتوقف أو يصبح غير متصل.
- أحداث كبيرة النطاق (Large-scale): موارد متعددة تتأثر، ربما عبر مناطق توفر (Availability Zones) بأكملها.
- أحداث عالمية (Global-scale): فشل واسع الانتشار يؤثر على عدد كبير من المستخدمين والأنظمة.
على سبيل المثال شركة تجارة إلكترونية تعتقد أن خادم قواعد البيانات لديها "مستقر ولن يتعطل".
في أحد الأيام يتعرض الخادم لعطل في اللوحة الأم ويتوقف تماماً لمدة 6 ساعات.
تخسر الشركة مبيعات بقيمة 2 مليون دولار لأنها لم تخطط لسيناريو الفشل.
لو طبقت مبدأ "كل شيء يتعطل" لكانت أنشأت نسخة احتياطية في منطقة توفر أخرى واستمرت أعمالها دون انقطاع.
في أحد الأيام يتعرض الخادم لعطل في اللوحة الأم ويتوقف تماماً لمدة 6 ساعات.
تخسر الشركة مبيعات بقيمة 2 مليون دولار لأنها لم تخطط لسيناريو الفشل.
لو طبقت مبدأ "كل شيء يتعطل" لكانت أنشأت نسخة احتياطية في منطقة توفر أخرى واستمرت أعمالها دون انقطاع.
🔑 المبدأ الذهبي: لا تفكر في الفشل كاستثناء نادر. افترض أن الأعطال — صغيرة وكبيرة — يمكن وستحدث. استثمر في التخطيط والتدريب وتوثيق العمليات حسب تكلفة الانقطاع المحتملة.
2️⃣ Avoiding and Planning for Disaster — تجنب الكوارث والتخطيط لها
📖 كيف يتعامل المعماري مع الكوارث من ثلاث زوايا؟
يصمم المعماريون البنى السحابية لتجنب الكوارث وفي نفس الوقت ينفذون خططاً للتعافي منها عند حدوثها. يتم ذلك عبر ثلاثة محاور رئيسية: تحمل الأعطال (Fault Tolerance) لتوفير التكرارية وتحمل فشل المكونات الفردية، النسخ الاحتياطي (Backup) لحماية البيانات وضمان استمرارية الأعمال، والتعافي من الكوارث (Disaster Recovery) وهو مجموعة السياسات والإجراءات لاستعادة البنية التحتية الحيوية بعد أي كارثة — سواء كانت عطل أجهزة أو برامج أو انقطاع شبكة أو حتى ضرر مادي كالحريق أو الفيضان.
📋 المحاور الثلاثة للتعامل مع الكوارث:
يصمم المعماريون البنى السحابية لتجنب الكوارث وفي نفس الوقت ينفذون خططاً للتعافي منها عند حدوثها. يتم ذلك عبر ثلاثة محاور رئيسية: تحمل الأعطال (Fault Tolerance) لتوفير التكرارية وتحمل فشل المكونات الفردية، النسخ الاحتياطي (Backup) لحماية البيانات وضمان استمرارية الأعمال، والتعافي من الكوارث (Disaster Recovery) وهو مجموعة السياسات والإجراءات لاستعادة البنية التحتية الحيوية بعد أي كارثة — سواء كانت عطل أجهزة أو برامج أو انقطاع شبكة أو حتى ضرر مادي كالحريق أو الفيضان.
- تحمل الأعطال (Fault Tolerance): تكرارية تتحمل فشل مكون فردي أو متعدد (أقراص صلبة، خوادم، اتصالات شبكة).
- النسخ الاحتياطي (Backup): حماية البيانات وضمان استمرارية الأعمال رغم التحدي المتزايد لكثافة البيانات.
- التعافي من الكوارث (Disaster Recovery): استعادة البنية التحتية والأنظمة بعد أي حدث سلبي يؤثر على استمرارية الأعمال.
على سبيل المثال شركة خدمات مالية تطبق المحاور الثلاثة معاً.
تستخدم Multi-AZ لتحمل الأعطال بحيث إذا تعطلت منطقة توفر كاملة يعمل الأخرى.
تنشط AWS Backup لنسخ قواعد البيانات يومياً إلى Amazon S3.
تعد خطة DR كاملة تنقل التطبيق إلى منطقة AWS أخرى خلال دقائق إذا دمر حريق مركز البيانات الأساسي.
تستخدم Multi-AZ لتحمل الأعطال بحيث إذا تعطلت منطقة توفر كاملة يعمل الأخرى.
تنشط AWS Backup لنسخ قواعد البيانات يومياً إلى Amazon S3.
تعد خطة DR كاملة تنقل التطبيق إلى منطقة AWS أخرى خلال دقائق إذا دمر حريق مركز البيانات الأساسي.
3️⃣ Factors That Influence Disaster Planning Strategies — العوامل المؤثرة في استراتيجيات التخطيط للكوارث
📖 ما هي العوامل الأربعة التي تحدد استراتيجية التعافي من الكوارث؟
يعتمد تصميم استراتيجيات التعافي من الكوارث على تقييم العمل لمستوى الفشل الذي يمكن تحمله. أربعة عوامل رئيسية يحددها العميل بالتعاون مع معماري السحابة: سرعة التعافي المطلوبة (Time Dependency)، مقدار فقدان البيانات المسموح به (Data Loss)، الاحتياجات المختلفة حسب الموقع الجغرافي (Geographic Location)، وموازنة تكلفة الاستعداد مع مخاطر الأعمال (Cost).
📋 العوامل الأربعة:
يعتمد تصميم استراتيجيات التعافي من الكوارث على تقييم العمل لمستوى الفشل الذي يمكن تحمله. أربعة عوامل رئيسية يحددها العميل بالتعاون مع معماري السحابة: سرعة التعافي المطلوبة (Time Dependency)، مقدار فقدان البيانات المسموح به (Data Loss)، الاحتياجات المختلفة حسب الموقع الجغرافي (Geographic Location)، وموازنة تكلفة الاستعداد مع مخاطر الأعمال (Cost).
- الاعتماد على الوقت (Time Dependency): ما مدى السرعة التي يجب بها معالجة المشكلة لتجنب تأثير الأعمال؟
- فقدان البيانات (Data Loss): ما مقدار ونوع البيانات المقبول فقدانها؟
- الموقع الجغرافي (Geographic Location): هل يؤثر الكارثة على مناطق AWS متعددة؟ هل تختلف متطلبات التعافي بين المناطق؟
- التكلفة (Cost): هل تمثل التكلفة المستوى الصحيح بالنظر إلى تأثير الأعمال والمخاطر؟
على سبيل المثال شركة محاماة لديها سجلات عملاء من 10 سنوات مضت.
تمثل هذه السجلات جزءاً ضئيلاً من الإيرادات الحالية — فقدانها مقبول.
لكن سجلات العام الحالي تمثل 80% من الإيرادات — يجب حمايتها بنسخ احتياطي كل ساعة.
هذا التمييز بين البيانات يسمح بتخصيص ميزانية التعافي للبيانات الأكثر أهمية فقط.
تمثل هذه السجلات جزءاً ضئيلاً من الإيرادات الحالية — فقدانها مقبول.
لكن سجلات العام الحالي تمثل 80% من الإيرادات — يجب حمايتها بنسخ احتياطي كل ساعة.
هذا التمييز بين البيانات يسمح بتخصيص ميزانية التعافي للبيانات الأكثر أهمية فقط.
🔑 نصيحة عملية: ابدأ بالأساسيات: أنشئ نسخاً احتياطية لتخزين البيانات وقواعد البيانات والخوادم الحيوية. ثم اعمل تدريجياً على تحسين المقاييس الأربعة ورفع قدرة الأعمال على الحد من تأثير الكوارث.
4️⃣ Determining RPO — تحديد هدف نقطة الاسترداد
📖 ما هو RPO وكيف يحسب؟
Recovery Point Objective (RPO) هو الحد الأقصى المقبول لفقدان البيانات بعد حادثة فقدان غير مخطط لها، ويُعبر عنه بالوقت. مثلاً، RPO بمقدار 8 ساعات يعني أن آخر نسخة احتياطية يجب ألا يتجاوز عمرها 8 ساعات عند وقوع الكارثة. إذا حدثت الكارثة في العاشرة مساءً، يجب أن يستعيد النظام كل البيانات الموجودة قبل الثانية مساءً.
📋 خطوات حساب RPO:
Recovery Point Objective (RPO) هو الحد الأقصى المقبول لفقدان البيانات بعد حادثة فقدان غير مخطط لها، ويُعبر عنه بالوقت. مثلاً، RPO بمقدار 8 ساعات يعني أن آخر نسخة احتياطية يجب ألا يتجاوز عمرها 8 ساعات عند وقوع الكارثة. إذا حدثت الكارثة في العاشرة مساءً، يجب أن يستعيد النظام كل البيانات الموجودة قبل الثانية مساءً.
- حدد الحد الأقصى لعدد السجلات المقبول فقدانها (مثلاً 800 سجل).
- استخدم الأنماط الحالية لتحديد معدل إنشاء السجلات (مثلاً 100 سجل في الساعة).
- احسب RPO بقسمة العدد المقبول على المعدل (800 ÷ 100 = 8 ساعات).
على سبيل المثال تطبيق لإدارة مواعيد عيادة طبية يولد 50 موعداً في الساعة.
تقرر العيادة أن فقدان 200 موعد مقبول لأن المرضى يمكنهم إعادة الحجز.
إذن RPO = 200 ÷ 50 = 4 ساعات — نسخ احتياطي كل 4 ساعات كافٍ.
إذا تعطل الخادم عند منتصف الليل، تستعيد العيادة جميع المواعيد قبل الثامنة مساءً.
تقرر العيادة أن فقدان 200 موعد مقبول لأن المرضى يمكنهم إعادة الحجز.
إذن RPO = 200 ÷ 50 = 4 ساعات — نسخ احتياطي كل 4 ساعات كافٍ.
إذا تعطل الخادم عند منتصف الليل، تستعيد العيادة جميع المواعيد قبل الثامنة مساءً.
5️⃣ Determining RTO — تحديد هدف وقت الاسترداد
📖 ما هو RTO وكيف يختلف عن RPO؟
Recovery Time Objective (RTO) هو الحد الأقصى المقبول من الوقت الذي يمكن أن تظل فيه عملية الأعمال معطلة بعد وقوع الكارثة. بينما يهتم RPO بكم البيانات المفقودة، يهتم RTO بسرعة العودة إلى العمل. فمثلاً، إذا كان RTO ساعة واحدة وحدثت الكارثة في العاشرة مساءً، يجب استعادة الخدمة بحلول الحادية عشرة. تحدد الشركة عادة RPO و RTO المقبولين بناءً على الأثر المالي — خسارة الأعمال والضرر بالسمعة — ثم تخطط حلولاً بتكلفة فعالة تلبي هذه المقاييس.
📋 مثال حساب RTO:
Recovery Time Objective (RTO) هو الحد الأقصى المقبول من الوقت الذي يمكن أن تظل فيه عملية الأعمال معطلة بعد وقوع الكارثة. بينما يهتم RPO بكم البيانات المفقودة، يهتم RTO بسرعة العودة إلى العمل. فمثلاً، إذا كان RTO ساعة واحدة وحدثت الكارثة في العاشرة مساءً، يجب استعادة الخدمة بحلول الحادية عشرة. تحدد الشركة عادة RPO و RTO المقبولين بناءً على الأثر المالي — خسارة الأعمال والضرر بالسمعة — ثم تخطط حلولاً بتكلفة فعالة تلبي هذه المقاييس.
- تحدد شركة تذاكر لحفلات موسيقية أن خدمتها يمكن استعادتها خلال ساعتين.
- تحسب الشركة أنها ستبدأ بخسارة الإيرادات بعد ساعتين من التوقف.
- RTO المقبول = ساعتين — إذا حدثت الكارثة عند 9 مساءً، تعود الخدمة قبل 11 مساءً.
على سبيل المثال منصة تعليم أونلاين تقدم دورات مباشرة.
توقف المنصة لمدة 30 دقيقة يعني فقدان 500 طالب في منتصف المحاضرة — خسارة سمعة فورية.
لذلك تختار المنصة RTO = 15 دقيقة وتستثمر في بنية Multi-AZ لتحقيق هذا الهدف.
بالمقابل، منصة للمحتوى المسجل يمكنها تحمل RTO = 4 ساعات لأن الطلاب يمكنهم المتابعة لاحقاً.
توقف المنصة لمدة 30 دقيقة يعني فقدان 500 طالب في منتصف المحاضرة — خسارة سمعة فورية.
لذلك تختار المنصة RTO = 15 دقيقة وتستثمر في بنية Multi-AZ لتحقيق هذا الهدف.
بالمقابل، منصة للمحتوى المسجل يمكنها تحمل RTO = 4 ساعات لأن الطلاب يمكنهم المتابعة لاحقاً.
💡 مقارنة بين RPO و RTO:
| وجه المقارنة | RPO | RTO |
|---|---|---|
| المعنى | كمية البيانات المقبول فقدانها (بالوقت) | مدة التوقف المقبولة (بالوقت) |
| السؤال | كم من البيانات يمكننا خسارته؟ | كم من الوقت يمكننا البقاء معطلين؟ |
| التركيز | تكرار النسخ الاحتياطي | سرعة استعادة الخدمة |
| المقياس | دقائق / ساعات بين النسخ | دقائق / ساعات حتى العودة |
6️⃣ Preparing a BCP — إعداد خطة استمرارية الأعمال
📖 ما هي خطة استمرارية الأعمال (BCP)؟
Business Continuity Plan (BCP) هو نظام للوقاية من التهديدات المحتملة للشركة والتعافي منها. تتكون BCP من أربعة عناصر: تحليل تأثير الأعمال (Business Impact Analysis)، تقييم المخاطر (Risk Assessment)، خطة التعافي من الكوارث (Disaster Recovery Plan)، و RPO و RTO المحددين والمقيّمين. خطة التعافي من الكوارث هي جزء من BCP — ليس من المنطقي الحفاظ على أهداف DR عدوانية إذا كانت أهداف العمل لا يمكن تحقيقها بسبب تأثير الكارثة على عناصر خارج نطاق حملك. مثلاً، الزلزال قد يمنع نقل المنتجات المباعة عبر تطبيق التجارة الإلكترونية — حتى لو عمل التطبيق بشكل مثالي.
📋 مكونات BCP:
Business Continuity Plan (BCP) هو نظام للوقاية من التهديدات المحتملة للشركة والتعافي منها. تتكون BCP من أربعة عناصر: تحليل تأثير الأعمال (Business Impact Analysis)، تقييم المخاطر (Risk Assessment)، خطة التعافي من الكوارث (Disaster Recovery Plan)، و RPO و RTO المحددين والمقيّمين. خطة التعافي من الكوارث هي جزء من BCP — ليس من المنطقي الحفاظ على أهداف DR عدوانية إذا كانت أهداف العمل لا يمكن تحقيقها بسبب تأثير الكارثة على عناصر خارج نطاق حملك. مثلاً، الزلزال قد يمنع نقل المنتجات المباعة عبر تطبيق التجارة الإلكترونية — حتى لو عمل التطبيق بشكل مثالي.
- تحليل تأثير الأعمال (BIA): تحديد العمليات الحيوية وتأثير توقفها.
- تقييم المخاطر (Risk Assessment): تحديد التهديدات المحتملة واحتمال حدوثها.
- خطة التعافي من الكوارث (DR Plan): الإجراءات التفصيلية لاستعادة البنية التحتية والتطبيقات.
- أهداف RPO و RTO: المقاييس المحددة والقابلة للقياس.
على سبيل المثال سلسلة مطاعم تعد BCP شاملة.
يحلل الفريق أن نظام الطلبات الأونلاين هو الأكثر حيوية — خسارته تعني فقدان 60% من الإيرادات.
يحددون RTO = 30 دقيقة و RPO = 5 دقائق لهذا النظام.
أما نظام المخزون الداخلي فلديه RTO = 24 ساعة لأنه يمكن تشغيله يدوياً مؤقتاً.
تراجع الخطة كل 6 أشهر وتحدثها بناءً على تغيرات الأعمال.
يحلل الفريق أن نظام الطلبات الأونلاين هو الأكثر حيوية — خسارته تعني فقدان 60% من الإيرادات.
يحددون RTO = 30 دقيقة و RPO = 5 دقائق لهذا النظام.
أما نظام المخزون الداخلي فلديه RTO = 24 ساعة لأنه يمكن تشغيله يدوياً مؤقتاً.
تراجع الخطة كل 6 أشهر وتحدثها بناءً على تغيرات الأعمال.
🔑 تذكير مهم: BCP وثيقة حية يجب تقييمها وتعديلها باستمرار بناءً على احتياجات الأعمال والموارد المطلوبة للوفاء بالمواعيد النهائية.
مثل تأمين منزلك — لا تتوقع حدوث حريق كل يوم، لكنك تدفع قسط التأمين السنوي وتجري فحصاً دورياً لأنك تعلم أن الحياة غير متوقعة.
هكذا هي BCP: استثمار صغير الآن يحميك من خسائر كارثية لاحقاً.
وكما أن خطة الإخلاء في المباني تُختبر بانتظام عبر تدريبات الحريق، فإن خطة DR يجب اختبارها عبر Game Day دورية.
هكذا هي BCP: استثمار صغير الآن يحميك من خسائر كارثية لاحقاً.
وكما أن خطة الإخلاء في المباني تُختبر بانتظام عبر تدريبات الحريق، فإن خطة DR يجب اختبارها عبر Game Day دورية.
✅ خلاصة: استراتيجيات التخطيط للكوارث
- الأعطال حتمية — افترض "كل شيء يتعطل، كل الوقت" وصمم بنيتك وفقاً لذلك.
- ثلاثة محاور للتعامل مع الكوارث: تحمل الأعطال والنسخ الاحتياطي والتعافي من الكوارث.
- أربعة عوامل تحدد استراتيجية DR: سرعة التعافي وفقدان البيانات والموقع الجغرافي والتكلفة.
- RPO يقيس فقدان البيانات المسموح به بالوقت — يحدد تكرار النسخ الاحتياطي.
- RTO يقيس وقت التوقف المسموح به — يحدد سرعة استعادة الخدمة.
- BCP هي خطة شاملة لاستمرارية الأعمال تتضمن DR Plan و RPO و RTO.
- BCP وثيقة حية يجب تحديثها باستمرار حسب احتياجات الأعمال.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| Disaster Recovery (DR) | التعافي من الكوارث | مجموعة سياسات وإجراءات لاستعادة البنية التحتية والأنظمة بعد وقوع كارثة. |
| Fault Tolerance | تحمل الأعطال | قدرة النظام على مواصلة العمل عند فشل أحد مكوناته. |
| Recovery Point Objective (RPO) | هدف نقطة الاسترداد | الحد الأقصى لفقدان البيانات المقبول مقاساً بالوقت. |
| Recovery Time Objective (RTO) | هدف وقت الاسترداد | الحد الأقصى لوقت التوقف المقبول بعد الكارثة. |
| Business Continuity Plan (BCP) | خطة استمرارية الأعمال | نظام للوقاية من التهديدات المحتملة للشركة والتعافي منها. |
| Business Impact Analysis (BIA) | تحليل تأثير الأعمال | تحديد العمليات الحيوية وتأثير توقفها على الأعمال. |
| Risk Assessment | تقييم المخاطر | عملية تحديد وتحليل التهديدات المحتملة واحتمال حدوثها وتأثيرها. |
1️⃣ DR Plans Span More Than One Region — خطط التعافي تمتد لأكثر من منطقة
📖 لماذا يجب أن تمتد خطة DR عبر مناطق متعددة؟
لنطاق خطة التعافي من الكوارث بشكل صحيح، يجب أن تفكر في استخدام AWS ككل. معظم المؤسسات تستخدم مزيجاً من الخدمات التي يمكن تصنيفها في خمس فئات: التخزين (Amazon S3)، الحوسبة (Amazon EC2)، قواعد البيانات (Amazon RDS)، الشبكات وتوصيل المحتوى (Amazon VPC)، وخدمات التنسيق والنشر ضمن الإدارة والحوكمة (AWS CloudFormation). عند وقوع كارثة، ستوجه RPO و RTO الخاصة بك خطط النسخ الاحتياطي والاستعادة عبر كل فئة. توفر AWS مناطق متعددة حول العالم لتختار الأنسب لموقع التعافي.
📋 فئات الخدمات الخمس في خطة DR:
لنطاق خطة التعافي من الكوارث بشكل صحيح، يجب أن تفكر في استخدام AWS ككل. معظم المؤسسات تستخدم مزيجاً من الخدمات التي يمكن تصنيفها في خمس فئات: التخزين (Amazon S3)، الحوسبة (Amazon EC2)، قواعد البيانات (Amazon RDS)، الشبكات وتوصيل المحتوى (Amazon VPC)، وخدمات التنسيق والنشر ضمن الإدارة والحوكمة (AWS CloudFormation). عند وقوع كارثة، ستوجه RPO و RTO الخاصة بك خطط النسخ الاحتياطي والاستعادة عبر كل فئة. توفر AWS مناطق متعددة حول العالم لتختار الأنسب لموقع التعافي.
- التخزين (Storage): Amazon S3 و Amazon EBS و Amazon EFS.
- الحوسبة (Compute): Amazon EC2 والحاويات والخدمات غير الخادمة.
- قواعد البيانات (Database): Amazon RDS و Amazon DynamoDB.
- الشبكات (Networking): Amazon VPC و Route 53 و ELB.
- النشر والأتمتة (Deployment & Orchestration): AWS CloudFormation و AWS OpsWorks.
على سبيل المثال شركة تعمل في منطقة us-east-1 — احتمال تعطل المنطقة بالكامل ضئيل جداً لكنه ممكن.
قد يكون السبب نيزكاً أو زلزالاً أو خطأ بشرياً في المركز الرئيسي.
لذلك تنشئ الشركة بنية مكررة في منطقة us-west-2.
تستخدم S3 CRR لنسخ البيانات و CloudFormation لإعادة نشر البنية في دقائق.
قد يكون السبب نيزكاً أو زلزالاً أو خطأ بشرياً في المركز الرئيسي.
لذلك تنشئ الشركة بنية مكررة في منطقة us-west-2.
تستخدم S3 CRR لنسخ البيانات و CloudFormation لإعادة نشر البنية في دقائق.
2️⃣ Storage and Backup Building Blocks — مكونات التخزين والنسخ الاحتياطي
📖 ما هي طبقات التخزين المختلفة في AWS؟
يتكون التخزين السحابي في AWS من مزيج من التخزين على مستوى الكتلة (Amazon EBS)، التخزين على مستوى الملفات (Amazon EFS و Amazon FSx)، والتخزين الكائني (Amazon S3 و Amazon S3 Glacier). تستخدم المؤسسات أيضاً خدمات تربط مركز البيانات المحلي بالسحابة مثل AWS DataSync الذي ينقل كميات كبيرة من البيانات عبر الإنترنت أو AWS Direct Connect.
📋 خدمات التخزين الرئيسية:
يتكون التخزين السحابي في AWS من مزيج من التخزين على مستوى الكتلة (Amazon EBS)، التخزين على مستوى الملفات (Amazon EFS و Amazon FSx)، والتخزين الكائني (Amazon S3 و Amazon S3 Glacier). تستخدم المؤسسات أيضاً خدمات تربط مركز البيانات المحلي بالسحابة مثل AWS DataSync الذي ينقل كميات كبيرة من البيانات عبر الإنترنت أو AWS Direct Connect.
- Amazon EBS: تخزين على مستوى الكتلة للأجهزة الافتراضية، نسخ احتياطي عبر اللقطات (Snapshots).
- Amazon EFS و Amazon FSx: تخزين على مستوى الملفات، نسخ احتياطي تلقائي إلى S3.
- Amazon S3: تخزين كائني بمتانة 11 تسعات (99.999999999%)، يدعم النسخ عبر المناطق (CRR).
- Amazon S3 Glacier: تخزين أرشيفي منخفض التكلفة للبيانات غير المستخدمة بكثرة.
- AWS DataSync: نقل البيانات بين التخزين المحلي و AWS بشكل مجدول ومؤتمت.
على سبيل المثال شركة إعلامية تخزن آلاف الفيديوهات عالية الدقة.
تستخدم Amazon S3 Standard للفيديوهات الأكثر مشاهدة (أقل من 30 يوماً).
ينقلها S3 Lifecycle Policy إلى S3 Standard-IA بعد 30 يوماً ثم إلى S3 Glacier بعد 90 يوماً.
تستخدم AWS DataSync لنقل نسخة احتياطية كاملة إلى منطقة AWS ثانية كل ليلة.
تستخدم Amazon S3 Standard للفيديوهات الأكثر مشاهدة (أقل من 30 يوماً).
ينقلها S3 Lifecycle Policy إلى S3 Standard-IA بعد 30 يوماً ثم إلى S3 Glacier بعد 90 يوماً.
تستخدم AWS DataSync لنقل نسخة احتياطية كاملة إلى منطقة AWS ثانية كل ليلة.
3️⃣ Configuring Cross-Region Replication — تكوين النسخ عبر المناطق
📖 كيف تحمي بيانات S3 عبر المناطق؟
S3 Cross-Region Replication (CRR) هي ميزة تنسخ الكائنات تلقائياً من حاوية مصدر في منطقة إلى حاوية وجهة في منطقة أخرى. للتهيئة، يجب تحديد الحاوية الوجهة ودور IAM يمنح S3 صلاحية النسخ. تحتفظ الكائنات المنسوخة ببياناتها الوصفية، ويمكن أن تنتمي الحاوية الوجهة لفئة تخزين مختلفة. يمكنك استخدام S3 Replication Time Control (S3 RTC) للوفاء باتفاقيات مستوى الخدمة (SLA) لنسخ البيانات خلال 15 دقيقة. فئات التخزين S3 Standard و S3 Standard-IA و S3 Glacier مصممة لتحمل فقدان منطقة توفر كاملة عبر تخزين الكائنات تلقائياً في ثلاث مناطق توفر على الأقل.
📋 خطوات تكوين CRR:
S3 Cross-Region Replication (CRR) هي ميزة تنسخ الكائنات تلقائياً من حاوية مصدر في منطقة إلى حاوية وجهة في منطقة أخرى. للتهيئة، يجب تحديد الحاوية الوجهة ودور IAM يمنح S3 صلاحية النسخ. تحتفظ الكائنات المنسوخة ببياناتها الوصفية، ويمكن أن تنتمي الحاوية الوجهة لفئة تخزين مختلفة. يمكنك استخدام S3 Replication Time Control (S3 RTC) للوفاء باتفاقيات مستوى الخدمة (SLA) لنسخ البيانات خلال 15 دقيقة. فئات التخزين S3 Standard و S3 Standard-IA و S3 Glacier مصممة لتحمل فقدان منطقة توفر كاملة عبر تخزين الكائنات تلقائياً في ثلاث مناطق توفر على الأقل.
- أضف تهيئة النسخ إلى الحاوية المصدر في S3.
- حدد الحاوية الوجهة في المنطقة الثانية.
- حدد دور IAM يمنح صلاحيات النسخ.
- اختر S3 RTC للنسخ خلال 15 دقيقة مع SLA مضمون.
- يمكن تعيين ملكية مختلفة للكائنات في الحاوية الوجهة.
على سبيل المثال منصة للتجارة الإلكترونية تخزن صور المنتجات في S3 Standard في منطقة eu-west-1.
تفعّل CRR إلى حاوية في منطقة ap-southeast-1.
إذا تعطلت منطقة eu-west-1 بالكامل، تظل صور المنتجات متاحة فوراً من منطقة آسيا.
تستخدم S3 RTC لضمان نسخ أي صورة جديدة خلال 15 دقيقة — حماية إضافية للبيانات الحيوية.
تفعّل CRR إلى حاوية في منطقة ap-southeast-1.
إذا تعطلت منطقة eu-west-1 بالكامل، تظل صور المنتجات متاحة فوراً من منطقة آسيا.
تستخدم S3 RTC لضمان نسخ أي صورة جديدة خلال 15 دقيقة — حماية إضافية للبيانات الحيوية.
4️⃣ EBS Volume Snapshots — لقطات أحجام EBS
📖 كيف تحمي بيانات EBS وتنسخها بين المناطق؟
يمكنك نسخ بيانات أحجام EBS إلى Amazon S3 عبر أخذ لقطات (Snapshots) في نقطة زمنية. اللقطات هي نسخ احتياطية تزايدية — تحفظ فقط الكتل التي تغيرت منذ آخر لقطة، مما يقلل وقت الإنشاء وتكاليف التخزين. بعد إنشاء اللقطة واكتمال نسخها إلى S3، يمكنك نسخها بين المناطق. يمكنك استخدام Amazon Data Lifecycle Manager لأتمتة إنشاء اللقطات والاحتفاظ بها وحذفها، مما يساعد في فرض سياسات النسخ الاحتياطي المنتظمة وحماية البيانات القيّمة وتقليل تكاليف التخزين.
📋 مزايا لقطات EBS:
يمكنك نسخ بيانات أحجام EBS إلى Amazon S3 عبر أخذ لقطات (Snapshots) في نقطة زمنية. اللقطات هي نسخ احتياطية تزايدية — تحفظ فقط الكتل التي تغيرت منذ آخر لقطة، مما يقلل وقت الإنشاء وتكاليف التخزين. بعد إنشاء اللقطة واكتمال نسخها إلى S3، يمكنك نسخها بين المناطق. يمكنك استخدام Amazon Data Lifecycle Manager لأتمتة إنشاء اللقطات والاحتفاظ بها وحذفها، مما يساعد في فرض سياسات النسخ الاحتياطي المنتظمة وحماية البيانات القيّمة وتقليل تكاليف التخزين.
- نسخ احتياطي تزايدي — يحفظ الكتل المتغيرة فقط.
- يمكن نسخ اللقطات بين المناطق (Cross-Region Snapshot Copy).
- استعادة فورية — الحجم الجديد يبدأ كنسخة طبق الأصل، يُحمّل البيانات في الخلفية.
- أتمتة عبر Amazon Data Lifecycle Manager للإنشاء والاحتفاظ والحذف.
- أحجام EBS منسوخة عبر عدة خوادم في منطقة توفر لتحمل فشل أي مكون منفرد.
على سبيل المثال شركة استضافة تدير آلاف الخوادم الافتراضية.
تستخدم Amazon Data Lifecycle Manager لأخذ لقطة EBS لكل خادم يومياً.
تحتفظ بـ 7 لقطات للسبوع الماضي ولقطة شهرية لمدة عام.
تنسخ اللقطات تلقائياً إلى منطقة AWS ثانية — إذا احترق مركز البيانات، تستعيد كل الخوادم في المنطقة البديلة خلال ساعات.
تستخدم Amazon Data Lifecycle Manager لأخذ لقطة EBS لكل خادم يومياً.
تحتفظ بـ 7 لقطات للسبوع الماضي ولقطة شهرية لمدة عام.
تنسخ اللقطات تلقائياً إلى منطقة AWS ثانية — إذا احترق مركز البيانات، تستعيد كل الخوادم في المنطقة البديلة خلال ساعات.
5️⃣ File System Replication — نسخ أنظمة الملفات
📖 كيف تحمي ملفاتك وأنظمة الملفات عبر المناطق؟
نسخ أنظمة الملفات هو ممارسة أفضل تضمن استمرار الوصول إلى ملفاتك بعد الكارثة. AWS DataSync ينقل البيانات بين نظامي Amazon EFS أو Amazon FSx for Windows File Server أو بين التخزين المحلي والتخزين السحابي. يمكن استخدامه عبر AWS Direct Connect أو الإنترنت. FSx for Windows File Server يأخذ نسخاً احتياطية تلقائية يومياً ويخزنها في S3 مع فترة احتفاظ افتراضية 7 أيام. مثل معظم فئات S3، تنسخ Amazon EFS و FSx البيانات عبر مناطق التوفر. إذا تطلب DR حلاً متعدد المناطق، فاستخدم DataSync لنسخ أنظمة الملفات إلى منطقة ثانية.
نسخ أنظمة الملفات هو ممارسة أفضل تضمن استمرار الوصول إلى ملفاتك بعد الكارثة. AWS DataSync ينقل البيانات بين نظامي Amazon EFS أو Amazon FSx for Windows File Server أو بين التخزين المحلي والتخزين السحابي. يمكن استخدامه عبر AWS Direct Connect أو الإنترنت. FSx for Windows File Server يأخذ نسخاً احتياطية تلقائية يومياً ويخزنها في S3 مع فترة احتفاظ افتراضية 7 أيام. مثل معظم فئات S3، تنسخ Amazon EFS و FSx البيانات عبر مناطق التوفر. إذا تطلب DR حلاً متعدد المناطق، فاستخدم DataSync لنسخ أنظمة الملفات إلى منطقة ثانية.
على سبيل المثال شركة محاماة لديها آلاف المستندات القانونية على Amazon EFS.
تستخدم AWS DataSync لنسخ نظام الملفات بالكامل يومياً إلى منطقة AWS ثانية.
إذا تعطلت منطقة us-east-1، يواصل المحامون العمل من المنطقة البديلة دون فقدان أي مستند.
DataSync يضمن نقل البيانات بشكل محسّن مع إدارة النطاق الترددي والمرونة التلقائية.
تستخدم AWS DataSync لنسخ نظام الملفات بالكامل يومياً إلى منطقة AWS ثانية.
إذا تعطلت منطقة us-east-1، يواصل المحامون العمل من المنطقة البديلة دون فقدان أي مستند.
DataSync يضمن نقل البيانات بشكل محسّن مع إدارة النطاق الترددي والمرونة التلقائية.
6️⃣ Recovering Compute Infrastructure — استعادة بنية الحوسبة
📖 كيف تستعيد قدرات الحوسبة بسرعة بعد الكارثة؟
يمكنك ترتيب استرداد تلقائي (Auto Recovery) لأجهزة EC2 عند فشل فحص حالة الأجهزة الأساسية. يعاد تشغيل الجهاز (على أجهزة جديدة إذا لزم الأمر) مع احتفاظه بمعرّفه وعناوين IP وإعدادات التهيئة. Amazon Machine Images (AMIs) هي صور مُعدّة مسبقاً بأنظمة تشغيل وقد تتضمن حزم تطبيقات. في سياق التعافي من الكوارث، توصي AWS بتهيئة AMIs مخصصة تطلق كجزء من إجراءات الاسترداد. الـ Golden AMI هو صورة معدّة بجميع التطبيقات والخدمات اللازمة لوظيفتها المحددة.
📋 ممارسات استعادة الحوسبة:
يمكنك ترتيب استرداد تلقائي (Auto Recovery) لأجهزة EC2 عند فشل فحص حالة الأجهزة الأساسية. يعاد تشغيل الجهاز (على أجهزة جديدة إذا لزم الأمر) مع احتفاظه بمعرّفه وعناوين IP وإعدادات التهيئة. Amazon Machine Images (AMIs) هي صور مُعدّة مسبقاً بأنظمة تشغيل وقد تتضمن حزم تطبيقات. في سياق التعافي من الكوارث، توصي AWS بتهيئة AMIs مخصصة تطلق كجزء من إجراءات الاسترداد. الـ Golden AMI هو صورة معدّة بجميع التطبيقات والخدمات اللازمة لوظيفتها المحددة.
- EC2 Auto Recovery: استرداد تلقائي عند فشل الأجهزة الأساسية مع الحفاظ على الإعدادات.
- Golden AMI: صورة خادم بجميع التطبيقات اللازمة جاهزة للإطلاق الفوري.
- نصوص User Data تسحب أحدث كود من مستودع الأكواد عند النشر.
- تحديث AMI بشكل دوري بآخر تحديثات النظام والتطبيقات.
على سبيل المثال فريق DevOps في شركة تكنولوجيا مالية يعد Golden AMI شهرياً.
يبدأ الصورة من نظام تشغيل نظيف، يثبت Java و Tomcat وإعدادات الأمان.
عند النشر، يستخدم User Data لسحب أحدث كود من CodeCommit.
بهذه الطريقة، لا يحتاجون لصورة جديدة مع كل تحديث للكود، فقط عند تغيير إعدادات النظام الأساسية.
يبدأ الصورة من نظام تشغيل نظيف، يثبت Java و Tomcat وإعدادات الأمان.
عند النشر، يستخدم User Data لسحب أحدث كود من CodeCommit.
بهذه الطريقة، لا يحتاجون لصورة جديدة مع كل تحديث للكود، فقط عند تغيير إعدادات النظام الأساسية.
7️⃣ Harnessing EventBridge for Regional Failover — استخدام EventBridge للتحويل بين المناطق
📖 كيف يؤتمت Amazon EventBridge التحويل بين المناطق؟
Amazon EventBridge يوفر الآن نقاط نهاية عالمية (Global Endpoints) تزيد من مرونة البنى متعددة المناطق. نقطة النهاية العالمية هي نقطة نهاية Route 53 مُدارة توجّه الأحداث إلى حافلات الأحداث في أي من المنطقتين حسب صحة الخدمة في المنطقة الأساسية. مقياس IngestionToInvocationStartLatency يقيس الوقت من استيعاب الحدث إلى استدعاء الهدف الأول — أي فترة تأخير عالية تتجاوز 30 ثانية قد تشير إلى اضطراب في الخدمة وتفعّل التحويل التلقائي.
📋 مزايا النقاط النهائية العالمية لـ EventBridge:
Amazon EventBridge يوفر الآن نقاط نهاية عالمية (Global Endpoints) تزيد من مرونة البنى متعددة المناطق. نقطة النهاية العالمية هي نقطة نهاية Route 53 مُدارة توجّه الأحداث إلى حافلات الأحداث في أي من المنطقتين حسب صحة الخدمة في المنطقة الأساسية. مقياس IngestionToInvocationStartLatency يقيس الوقت من استيعاب الحدث إلى استدعاء الهدف الأول — أي فترة تأخير عالية تتجاوز 30 ثانية قد تشير إلى اضطراب في الخدمة وتفعّل التحويل التلقائي.
- نقطة نهاية Route 53 مُدارة توجّه الأحداث بناءً على صحة الخدمة.
- تحويل تلقائي (Failover) عند اكتشاف اضطراب في المنطقة الأساسية.
- مراقبة عبر مقياس IngestionToInvocationStartLatency (حد التنبيه: 30 ثانية).
- استعادة البيانات وتحويل التوجيه إلى خوادم عاملة دون تدخل يدوي.
على سبيل المثال تطبيق لتتبع الشحنات يستخدم EventBridge لمعالجة أحداث تحديث حالة الشحنة.
في حالة اضطراب في المنطقة الأساسية، تكتشف نقطة النهاية العالمية ارتفاع كمون الأحداث.
توجّه تلقائياً جميع الأحداث الجديدة إلى المنطقة الثانوية التي تعمل بشكل طبيعي.
يستمر التطبيق في معالجة التحديثات دون أي توقف مرئي للعملاء.
في حالة اضطراب في المنطقة الأساسية، تكتشف نقطة النهاية العالمية ارتفاع كمون الأحداث.
توجّه تلقائياً جميع الأحداث الجديدة إلى المنطقة الثانوية التي تعمل بشكل طبيعي.
يستمر التطبيق في معالجة التحديثات دون أي توقف مرئي للعملاء.
8️⃣ Designing for Resiliency and Recovery — تصميم المرونة والتعافي في الشبكات
📖 ما أدوات الشبكات التي تساعد في التعافي من الكوارث؟
عند التعافي من كارثة، غالباً ما تحتاج لتعديل إعدادات الشبكة لتحويل النظام إلى موقع آخر. Route 53 يوفر موازنة تحميل وتوجيه شبكي مع قدرة التحويل بين نقاط نهاية متعددة وحتى إلى موقع ثابت على S3. Elastic Load Balancing (ELB) يوزع حركة المرور عبر أجهزة EC2 متعددة — يمكن حجز موازن تحميل مسبقاً ليبقى اسم DNS معروفاً. Amazon VPN يمدّ توبولوجيا الشبكة المحلية إلى السحابة، و AWS Direct Connect يوفر اتصالاً مخصصاً من مركز البيانات المحلي إلى AWS بتكلفة أقل ونطاق ترددي أعلى.
📋 خدمات الشبكات الرئيسية لـ DR:
عند التعافي من كارثة، غالباً ما تحتاج لتعديل إعدادات الشبكة لتحويل النظام إلى موقع آخر. Route 53 يوفر موازنة تحميل وتوجيه شبكي مع قدرة التحويل بين نقاط نهاية متعددة وحتى إلى موقع ثابت على S3. Elastic Load Balancing (ELB) يوزع حركة المرور عبر أجهزة EC2 متعددة — يمكن حجز موازن تحميل مسبقاً ليبقى اسم DNS معروفاً. Amazon VPN يمدّ توبولوجيا الشبكة المحلية إلى السحابة، و AWS Direct Connect يوفر اتصالاً مخصصاً من مركز البيانات المحلي إلى AWS بتكلفة أقل ونطاق ترددي أعلى.
- Route 53: موازنة تحميل قائمة على DNS وتحويل تلقائي بين نقاط النهاية.
- ELB: توزيع حركة المرور وتحمل الأعطال — تبسيط تنفيذ DR باسم DNS معروف مسبقاً.
- Amazon VPN: تمديد الشبكة المحلية إلى VPC لاستعادة التطبيقات الداخلية.
- AWS Direct Connect: اتصال مخصص من مركز البيانات المحلي إلى AWS بموثوقية أعلى.
على سبيل المثال تطبيق مصرفي يتطلب أعلى مستويات التوفر.
يستخدم Route 53 مع سياسة توجيه قائمة على الصحة — إذا فشل فحص الصحة في المنطقة الأساسية، يوجّه Route 53 كل الحركة إلى المنطقة الثانوية فوراً.
ELB موزّع مسبقاً في كل منطقة يوزع الحركة عبر أجهزة EC2 المتعددة.
اتصال AWS Direct Connect مخصص يضمن سرعة وموثوقية استثنائية لنقل البيانات بين مراكز البنك و AWS.
يستخدم Route 53 مع سياسة توجيه قائمة على الصحة — إذا فشل فحص الصحة في المنطقة الأساسية، يوجّه Route 53 كل الحركة إلى المنطقة الثانوية فوراً.
ELB موزّع مسبقاً في كل منطقة يوزع الحركة عبر أجهزة EC2 المتعددة.
اتصال AWS Direct Connect مخصص يضمن سرعة وموثوقية استثنائية لنقل البيانات بين مراكز البنك و AWS.
💡 مقارنة أدوات الشبكات لـ DR:
| الخدمة | الوظيفة الرئيسية | دورها في DR |
|---|---|---|
| Route 53 | موازنة تحميل وتوجيه DNS | تحويل تلقائي بين نقاط النهاية الأساسية والثانوية |
| ELB | توزيع حركة المرور | توزيع الحمل عبر أجهزة EC2 في موقع التعافي |
| Amazon VPN | اتصال آمن بالشبكة المحلية | تمديد الشبكة الداخلية للسحابة لاستعادة التطبيقات |
| AWS Direct Connect | اتصال مخصص ومباشر | نقل سريع ومتسق بين المركز المحلي و AWS |
9️⃣ Supporting Database Recovery — دعم استعادة قواعد البيانات
📖 كيف تحمي قواعد بيانات Amazon RDS و DynamoDB؟
Amazon RDS يسمح بتخزين لقطات (Snapshots) في منطقة منفصلة، واستخدام النسخ المتماثلة للقراءة (Read Replicas) مع نشر Multi-AZ. بمزج الاثنين، تبني استراتيجية DR مرنة. القراءة المتماثلة يمكن ترقيتها إلى قاعدة بيانات مستقلة عند الحاجة ويمكن إنشاؤها في نفس المنطقة أو منطقة مختلفة. DynamoDB يدعم نسخ الجداول بالكامل واستعادة أي نقطة زمنية (Point-in-Time Recovery) والجداول العالمية (Global Tables) التي تنسخ الجداول تلقائياً عبر المناطق لتطبيقات متعددة النشاط (Multi-Active) تبقى متاحة حتى عند كارثة على مستوى المنطقة.
📋 ميزات استعادة قواعد البيانات:
Amazon RDS يسمح بتخزين لقطات (Snapshots) في منطقة منفصلة، واستخدام النسخ المتماثلة للقراءة (Read Replicas) مع نشر Multi-AZ. بمزج الاثنين، تبني استراتيجية DR مرنة. القراءة المتماثلة يمكن ترقيتها إلى قاعدة بيانات مستقلة عند الحاجة ويمكن إنشاؤها في نفس المنطقة أو منطقة مختلفة. DynamoDB يدعم نسخ الجداول بالكامل واستعادة أي نقطة زمنية (Point-in-Time Recovery) والجداول العالمية (Global Tables) التي تنسخ الجداول تلقائياً عبر المناطق لتطبيقات متعددة النشاط (Multi-Active) تبقى متاحة حتى عند كارثة على مستوى المنطقة.
- RDS: مشاركة اللقطات مع 20 حساباً آخر، نسخ اللقطات بين المناطق، Read Replicas عبر المناطق.
- Multi-AZ: نشر احتياطي تلقائي عبر مناطق التوفر مع تجاوز الفشل التلقائي.
- RDS Read Replicas: نسخ للقراءة فقط، يمكن ترقيتها لقاعدة بيانات مستقلة عند الحاجة.
- DynamoDB: نسخ الجداول بالكامل، استعادة نقطة زمنية، جداول عالمية (Global Tables).
على سبيل المثال تطبيق للتجارة الإلكترونية يستخدم Amazon RDS لقاعدة بيانات الطلبات.
يفعّل Multi-AZ لتحمل فشل منطقة توفر ويضيف Read Replica عبر المناطق.
لكل طلب، نسخة احتياطية تلقائية — لقطة يومية تنسخ إلى منطقة ثانية.
إذا تعطلت المنطقة الأساسية بالكامل، ترقّى النسخة المتماثلة لقاعدة بيانات مستقلة ويستقبل التطبيق الطلبات دون فقدان أي بيانات.
يفعّل Multi-AZ لتحمل فشل منطقة توفر ويضيف Read Replica عبر المناطق.
لكل طلب، نسخة احتياطية تلقائية — لقطة يومية تنسخ إلى منطقة ثانية.
إذا تعطلت المنطقة الأساسية بالكامل، ترقّى النسخة المتماثلة لقاعدة بيانات مستقلة ويستقبل التطبيق الطلبات دون فقدان أي بيانات.
🔟 Replicating and Redeploying Environments — نسخ وإعادة نشر البيئات
📖 كيف تستخدم CloudFormation و OpsWorks في DR؟
AWS CloudFormation يمثل البنية التحتية كاملة كنص (Infrastructure as Code) يمكن استخدامه لنسخ البيئات الإنتاجية المعقدة في دقائق — إلى منطقة جديدة أو VPC جديد. هذا القالب يصبح المصدر الوحيد للحقيقة للبنية التحتية. CloudFormation يوفّر الموارد بطريقة قابلة للتكرار، مما يسمح ببناء وإعادة بناء البنية التحتية دون إجراءات يدوية. AWS OpsWorks يدير التطبيقات عبر مجموعات الخوادم ويوفر استبدالاً تلقائياً للأجهزة — إذا فشل جهاز، يُستبدل تلقائياً. استخدم OpsWorks في مرحلة الإعداد لقولبة البيئة وادمجه مع CloudFormation في مرحلة الاسترداد.
📋 خدمات الأتمتة لنسخ البيئات:
AWS CloudFormation يمثل البنية التحتية كاملة كنص (Infrastructure as Code) يمكن استخدامه لنسخ البيئات الإنتاجية المعقدة في دقائق — إلى منطقة جديدة أو VPC جديد. هذا القالب يصبح المصدر الوحيد للحقيقة للبنية التحتية. CloudFormation يوفّر الموارد بطريقة قابلة للتكرار، مما يسمح ببناء وإعادة بناء البنية التحتية دون إجراءات يدوية. AWS OpsWorks يدير التطبيقات عبر مجموعات الخوادم ويوفر استبدالاً تلقائياً للأجهزة — إذا فشل جهاز، يُستبدل تلقائياً. استخدم OpsWorks في مرحلة الإعداد لقولبة البيئة وادمجه مع CloudFormation في مرحلة الاسترداد.
- CloudFormation: قوالب نصية للبنية التحتية بأكملها — انسخ البيئات في دقائق.
- Elastic Beanstalk: تحميل ونشر حزم التطبيقات وإعادة نشر الإصدارات السابقة.
- OpsWorks: إدارة طبقات التطبيق مع الاستبدال التلقائي للأجهزة الفاشلة.
على سبيل المثال شركة لديها 50 جهاز EC2 و VPC معقدة مع 6 شبكات فرعية وقواعد أمان وموازن تحميل.
بدلاً من إعادة بناء كل شيء يدوياً بعد الكارثة، طوّرت قالب CloudFormation خلال مرحلة الإعداد.
عند وقوع الكارثة، تنفذ القالب في منطقة جديدة — في 15 دقيقة تكون البيئة جاهزة تماماً.
تستخدم OpsWorks لطبقات التطبيق — إذا فشل جهاز أثناء الاسترداد، يُستبدل تلقائياً دون تدخل.
بدلاً من إعادة بناء كل شيء يدوياً بعد الكارثة، طوّرت قالب CloudFormation خلال مرحلة الإعداد.
عند وقوع الكارثة، تنفذ القالب في منطقة جديدة — في 15 دقيقة تكون البيئة جاهزة تماماً.
تستخدم OpsWorks لطبقات التطبيق — إذا فشل جهاز أثناء الاسترداد، يُستبدل تلقائياً دون تدخل.
✅ خلاصة: التخطيط للتعافي من الكوارث في AWS
- خطط DR تمتد عبر خمس فئات خدمات: التخزين والحوسبة وقواعد البيانات والشبكات والنشر.
- S3 CRR و EBS Snapshots و RDS Snapshots تحمي بياناتك عبر المناطق.
- DataSync ينقل أنظمة الملفات بين المناطق للحماية من الكوارث الإقليمية.
- Golden AMIs و EC2 Auto Recovery تسرّع استعادة قدرات الحوسبة.
- EventBridge Global Endpoints يؤتمت التحويل التلقائي بين المناطق بناءً على صحة الخدمة.
- Route 53 و ELB و AWS Direct Connect أدوات شبكية أساسية لتحقيق DR.
- RDS Read Replicas و DynamoDB Global Tables توفر استمرارية لقواعد البيانات عبر المناطق.
- CloudFormation و OpsWorks يؤتمتان نسخ وإعادة نشر البيئات في دقائق.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| Cross-Region Replication (CRR) | النسخ عبر المناطق | نسخ كائنات S3 تلقائياً من حاوية في منطقة إلى حاوية في منطقة أخرى. |
| EBS Snapshot | لقطة حجم التخزين | نسخة احتياطية تزايدية لحجم EBS تُخزّن في S3 وتُنسخ بين المناطق. |
| DataSync | مزامنة البيانات | خدمة لنقل كميات كبيرة من البيانات بين التخزين المحلي و AWS بشكل مجدول. |
| Golden AMI | صورة ذهبية | AMI معدّة بجميع التطبيقات والخدمات اللازمة لوظيفتها، جاهزة للإطلاق الفوري. |
| EventBridge Global Endpoint | نقطة نهاية عالمية | نقطة نهاية Route 53 مُدارة توجّه الأحداث بين المناطق حسب صحة الخدمة. |
| Read Replica | نسخة متماثلة للقراءة | نسخة للقراءة فقط من قاعدة بيانات RDS يمكن ترقيتها لقاعدة بيانات مستقلة. |
| Global Tables (DynamoDB) | جداول عالمية | جداول DynamoDB تنسخ تلقائياً عبر مناطق متعددة لتطبيقات متعددة النشاط. |
| AWS CloudFormation | تشكيل السحابة | خدمة لتعريف البنية التحتية ككود — قوالب نصية تنشر البيئات بشكل متكرر. |
1️⃣ Common Disaster Recovery Patterns on AWS — أنماط التعافي الشائعة
📖 ما هي الأنماط الأربعة للتعافي من الكوارث؟
تستخدم المؤسسات أربعة أنماط شائعة للتعافي من الكوارث، كل منها مناسب لمزيج مختلف من RPO و RTO وفعالية التكلفة: النسخ الاحتياطي والاستعادة (Backup and Restore)، الضوء التجريبي (Pilot Light)، الاحتياطي الدافئ (Warm Standby)، والمواقع المتعددة (Multi-Site). كلما زادت سرعة التعافي المطلوبة، زادت التكلفة. Backup and Restore هو الأقل تكلفة لكنه الأبطأ، بينما Multi-Site هو الأسرع لكنه الأغلى.
تستخدم المؤسسات أربعة أنماط شائعة للتعافي من الكوارث، كل منها مناسب لمزيج مختلف من RPO و RTO وفعالية التكلفة: النسخ الاحتياطي والاستعادة (Backup and Restore)، الضوء التجريبي (Pilot Light)، الاحتياطي الدافئ (Warm Standby)، والمواقع المتعددة (Multi-Site). كلما زادت سرعة التعافي المطلوبة، زادت التكلفة. Backup and Restore هو الأقل تكلفة لكنه الأبطأ، بينما Multi-Site هو الأسرع لكنه الأغلى.
💡 مقارنة أنماط التعافي الأربعة:
| النمط | وقت الاسترداد (RTO) | فقدان البيانات (RPO) | التكلفة النسبية |
|---|---|---|---|
| Backup & Restore | ساعات | ساعات | منخفضة |
| Pilot Light | عشرات الدقائق | عشرات الدقائق | متوسطة |
| Warm Standby | دقائق | دقائق | مرتفعة |
| Multi-Site | فوري تقريباً | لحظي | الأعلى |
2️⃣ Backup and Restore Pattern — نمط النسخ الاحتياطي والاستعادة
📖 كيف يعمل نمط النسخ الاحتياطي والاستعادة؟
نمط Backup and Restore هو أول وأبسط أنماط DR. مناسب للتخفيف من فقدان البيانات أو تلفها والكوارث الإقليمية. في البيئات التقليدية، تُنسخ البيانات احتياطياً وتُرسل خارج الموقع بانتظام — لكن استعادتها قد تستغرق وقتاً طويلاً. Amazon S3 يوفر وجهة سهلة الوصول لبيانات النسخ الاحتياطي. يمكن استخدام DataSync أو S3 Transfer Acceleration لأتمتة أو تسريع النقل. سياسة دورة حياة S3 Lifecycle Configuration تنقل البيانات إلى فئات تخزين أقل تكلفة مثل S3 Standard-IA أو S3 Glacier مع تقدم عمر البيانات.
📋 مراحل النمط:
نمط Backup and Restore هو أول وأبسط أنماط DR. مناسب للتخفيف من فقدان البيانات أو تلفها والكوارث الإقليمية. في البيئات التقليدية، تُنسخ البيانات احتياطياً وتُرسل خارج الموقع بانتظام — لكن استعادتها قد تستغرق وقتاً طويلاً. Amazon S3 يوفر وجهة سهلة الوصول لبيانات النسخ الاحتياطي. يمكن استخدام DataSync أو S3 Transfer Acceleration لأتمتة أو تسريع النقل. سياسة دورة حياة S3 Lifecycle Configuration تنقل البيانات إلى فئات تخزين أقل تكلفة مثل S3 Standard-IA أو S3 Glacier مع تقدم عمر البيانات.
- مرحلة الإعداد (Preparation): إنشاء نسخ احتياطية للأنظمة الحالية، تخزينها في Amazon S3، توثيق إجراءات الاستعادة.
- عند وقوع الكارثة (In Case of Disaster): استرجاع النسخ من S3، بناء البنية التحتية المطلوبة (عبر CloudFormation)، استعادة النظام من النسخ الاحتياطي، توجيه حركة المرور إلى النظام الجديد (تعديل سجلات DNS).
على سبيل المثال شركة محاسبة تخزن نسخاً احتياطية لسجلات 10 سنوات في S3 Glacier.
تستخدم S3 Lifecycle Policy: النسخ اليومية تبقى في S3 Standard لمدة 7 أيام، ثم تنتقل إلى S3 Standard-IA لشهر، ثم إلى S3 Glacier بعد 90 يوماً.
إذا احترق المكتب، تستأجر خوادم EC2 في منطقة AWS، تسترجع النسخ من Glacier، وتستأنف العمل خلال 24 ساعة — بتكلفة شبه معدومة للتخزين طويل الأمد.
تستخدم S3 Lifecycle Policy: النسخ اليومية تبقى في S3 Standard لمدة 7 أيام، ثم تنتقل إلى S3 Standard-IA لشهر، ثم إلى S3 Glacier بعد 90 يوماً.
إذا احترق المكتب، تستأجر خوادم EC2 في منطقة AWS، تسترجع النسخ من Glacier، وتستأنف العمل خلال 24 ساعة — بتكلفة شبه معدومة للتخزين طويل الأمد.
3️⃣ AWS Storage Gateway for Backup and Restore — استخدام AWS Storage Gateway
📖 كيف يساعد AWS Storage Gateway في النسخ الاحتياطي؟
AWS Storage Gateway هو خدمة تخزين هجينة تمكّن التطبيقات المحلية من استخدام التخزين السحابي لـ AWS. يتصل من خلال جهاز افتراضي (VM) أو جهاز Hardware Gateway ببروتوكولات التخزين القياسية: NFS و SMB و VTL و iSCSI. يوفر الخدمة ثلاث واجهات أساسية: بوابة الملفات (File Gateway)، بوابة الحجم (Volume Gateway)، وبوابة الشريط (Tape Gateway).
📋 واجهات Storage Gateway الثلاث:
AWS Storage Gateway هو خدمة تخزين هجينة تمكّن التطبيقات المحلية من استخدام التخزين السحابي لـ AWS. يتصل من خلال جهاز افتراضي (VM) أو جهاز Hardware Gateway ببروتوكولات التخزين القياسية: NFS و SMB و VTL و iSCSI. يوفر الخدمة ثلاث واجهات أساسية: بوابة الملفات (File Gateway)، بوابة الحجم (Volume Gateway)، وبوابة الشريط (Tape Gateway).
- File Gateway: تخزين واسترجاع الكائنات في S3 عبر NFS/SMB مع ذاكرة مؤقتة محلية للبيانات الأكثر استخداماً.
- Volume Gateway: أقراص تخزين كتلة عبر iSCSI مع لقطات EBS للنسخ الاحتياطي — يمكن الوصول إليها عبر EC2.
- Tape Gateway: مكتبة أشرطة افتراضية — يواصل تطبيق النسخ الاحتياطي الحالي استخدامه مع أرشفة الأشرطة في S3 Glacier.
على سبيل المثال مستشفى لديه نظام سجلات طبية محلي يعمل منذ 15 عاماً.
بدلاً من استبدال النظام بالكامل، ينصب Storage Gateway كجهاز افتراضي على خادمه المحلي.
تكتب السجلات مباشرة إلى Amazon S3 عبر File Gateway — مع احتفاظها بنسخة محلية للوصول السريع.
إذا تعطل الخادم المحلي، تُشغّل أجهزة EC2 وتصل لنفس البيانات في S3 فوراً — بدون فقدان أي سجل.
بدلاً من استبدال النظام بالكامل، ينصب Storage Gateway كجهاز افتراضي على خادمه المحلي.
تكتب السجلات مباشرة إلى Amazon S3 عبر File Gateway — مع احتفاظها بنسخة محلية للوصول السريع.
إذا تعطل الخادم المحلي، تُشغّل أجهزة EC2 وتصل لنفس البيانات في S3 فوراً — بدون فقدان أي سجل.
4️⃣ Pilot Light Pattern — نمط الضوء التجريبي
📖 ما هو نمط الضوء التجريبي وكيف يعمل؟
يصف نمط Pilot Light نهج DR حيث تعمل نسخة احتياطية مصغرة من بيئتك بشكل دائم. التشبيه يأتي من سخان الغاز — شعلة صغيرة (الضوء التجريبي) تبقى مشتعلة حتى عندما يكون السخان مطفياً، ويمكنها إشعال الفرن بأكمله بسرعة. في هذا النمط، Pilot Light هو قاعدة البيانات الثانوية التي تعمل دائماً.
وقت الاسترداد أسرع من النسخ الاحتياطي لأن المكونات الأساسية تعمل بالفعل وتُحدّث باستمرار. العناصر الأساسية تشمل خوادم قواعد البيانات — وهي النواة الحيوية — وكل شيء آخر يمكن توفيره بسرعة حولها باستخدام AMIs جاهزة.
📋 مراحل نمط Pilot Light:
- مرحلة الإعداد: تكوين أجهزة EC2 لنسخ الخوادم، إنشاء AMIs للخوادم الحيوية، تشغيل هذه الخوادم واختبارها وتحديثها بانتظام.
- عند وقوع الكارثة: تشغيل الموارد تلقائياً حول النواة المنسوخة، توسيع النظام حسب الحاجة لحركة الإنتاج، تحويل DNS إلى النظام الجديد عبر Route 53.
🔑 الفرق الرئيسي: في Pilot Light، النواة الحيوية (قاعدة البيانات) تعمل دائماً — بعكس Backup and Restore حيث كل شيء متوقف. هذا يقلص وقت الاسترداد من ساعات إلى دقائق.
على سبيل المثال شركة لتوصيل الطعام تبقي قاعدة بيانات الطلبات في RDS Multi-AZ تعمل في منطقة ثانوية.
لديها AMIs جاهزة لخوادم الويب والتطبيقات — متوقفة لكن محدثة.
عند تعطل المنطقة الأساسية، تشغّل الـ AMIs في دقيقة — تتصل بقاعدة البيانات الثانوية — ويُحدّث Route 53 التوجيه.
الطلبات الجديدة تصل فوراً إلى الخوادم الجديدة — توقف لا يتجاوز 5 دقائق.
لديها AMIs جاهزة لخوادم الويب والتطبيقات — متوقفة لكن محدثة.
عند تعطل المنطقة الأساسية، تشغّل الـ AMIs في دقيقة — تتصل بقاعدة البيانات الثانوية — ويُحدّث Route 53 التوجيه.
الطلبات الجديدة تصل فوراً إلى الخوادم الجديدة — توقف لا يتجاوز 5 دقائق.
مثل شعلة الغاز التجريبية في المدفأة — شعلة صغيرة جداً تبقى مشتعلة طوال الصيف.
عند أول برد، تشعل الشعلة المدفأة بكامل طاقتها في ثوانٍ.
هكذا Pilot Light: بنية مصغرة تعمل دائماً، جاهزة للتوسع الفوري عند الكارثة.
الفرق عن المدفأة: لا تحتاج لصيانة مستمرة — AWS يدير الأجهزة ويضمن تحديث البرامج.
عند أول برد، تشعل الشعلة المدفأة بكامل طاقتها في ثوانٍ.
هكذا Pilot Light: بنية مصغرة تعمل دائماً، جاهزة للتوسع الفوري عند الكارثة.
الفرق عن المدفأة: لا تحتاج لصيانة مستمرة — AWS يدير الأجهزة ويضمن تحديث البرامج.
5️⃣ Warm Standby Pattern — نمط الاحتياطي الدافئ
📖 ما هو نمط الاحتياطي الدافئ؟
نمط Warm Standby يشبه Pilot Light لكن مع المزيد من الموارد العاملة مسبقاً. هو سيناريو DR حيث تعمل نسخة مصغرة كاملة الوظائف من البيئة بشكل دائم في السحابة — امتداد لعناصر Pilot Light مع تقليل وقت الاسترداد لأن بعض الخدمات تعمل دائماً. تعمل الخوادم على أسطول من أجهزة EC2 بأصغر الأحجام الممكنة — غير موسعة لحمولة الإنتاج الكاملة لكنها كاملة الوظائف. يمكن أيضاً استخدام هذه البيئة لأعمال غير إنتاجية كالاختبار وضمان الجودة. عند الكارثة، يحوّل Route 53 إلى النظام الثانوي الذي يتوسع بسرعة — إما بإضافة أجهزة EC2 جديدة (التوسع الأفقي) أو تكبير الأحجام الحالية (التوسع العمودي).
📋 مراحل نمط Warm Standby:
نمط Warm Standby يشبه Pilot Light لكن مع المزيد من الموارد العاملة مسبقاً. هو سيناريو DR حيث تعمل نسخة مصغرة كاملة الوظائف من البيئة بشكل دائم في السحابة — امتداد لعناصر Pilot Light مع تقليل وقت الاسترداد لأن بعض الخدمات تعمل دائماً. تعمل الخوادم على أسطول من أجهزة EC2 بأصغر الأحجام الممكنة — غير موسعة لحمولة الإنتاج الكاملة لكنها كاملة الوظائف. يمكن أيضاً استخدام هذه البيئة لأعمال غير إنتاجية كالاختبار وضمان الجودة. عند الكارثة، يحوّل Route 53 إلى النظام الثانوي الذي يتوسع بسرعة — إما بإضافة أجهزة EC2 جديدة (التوسع الأفقي) أو تكبير الأحجام الحالية (التوسع العمودي).
- مرحلة الإعداد: مشابهة Pilot Light لكن جميع المكونات تعمل 24/7 — غير موسعة لحركة الإنتاج. اختبار مستمر للمكونات عبر المعاملات الاصطناعية.
- عند وقوع الكارثة: تحويل حمولة الإنتاج الأكثر حيوية فوراً مع تعديل DNS. التوسع تلقائياً ليشمل كل حمولة الإنتاج.
على سبيل المثال شركة للتجارة الإلكترونية تشغّل موقعاً بالكامل في منطقة أساسية.
في منطقة ثانوية، تشغّل نسخة مصغرة: خادما ويب صغيران وقاعدة بيانات بحجم مخفّض.
يومياً، يمررون 5% من حركة المرور عبر المنطقة الثانوية للتحقق من عملها.
عند انقطاع المنطقة الأساسية، يوجّه Route 53 100% من الحركة إلى المنطقة الثانوية.
يكتشف Auto Scaling زيادة الحمل ويطلق 20 خادماً إضافياً — الموقع يعمل بكامل طاقته خلال دقيقتين.
في منطقة ثانوية، تشغّل نسخة مصغرة: خادما ويب صغيران وقاعدة بيانات بحجم مخفّض.
يومياً، يمررون 5% من حركة المرور عبر المنطقة الثانوية للتحقق من عملها.
عند انقطاع المنطقة الأساسية، يوجّه Route 53 100% من الحركة إلى المنطقة الثانوية.
يكتشف Auto Scaling زيادة الحمل ويطلق 20 خادماً إضافياً — الموقع يعمل بكامل طاقته خلال دقيقتين.
6️⃣ Multi-Site Pattern — نمط المواقع المتعددة
📖 ما هو نمط المواقع المتعددة؟
نمط Multi-Site هو الأكثر تكلفة والأسرع استرداداً. يعمل نظام كامل الوظائف في منطقة ثانية في نفس وقت النظام الأساسي — في تهيئة نشاط-نشاط (Active-Active). كلا الموقعين يمكنه دعم طاقة الإنتاج الكاملة. تستخدم خدمة DNS تدعم التوجيه الموزون (Weighted Routing) مثل Route 53 — نسبة من حركة المرور تذهب إلى كل موقع. عند الكارثة، تُعدّل الأوزان لترسل كل الحركة إلى البيئة السحابية. يمكن استخدام EC2 Auto Scaling لأتمتة الزيادة في السعة. التكلفة تحددها حركة الإنتاج العادية — في مرحلة الاسترداد، تدفع فقط مقابل ما تستخدمه للمدة التي تحتاج فيها بيئة DR بكامل طاقتها.
📋 مراحل نمط Multi-Site:
نمط Multi-Site هو الأكثر تكلفة والأسرع استرداداً. يعمل نظام كامل الوظائف في منطقة ثانية في نفس وقت النظام الأساسي — في تهيئة نشاط-نشاط (Active-Active). كلا الموقعين يمكنه دعم طاقة الإنتاج الكاملة. تستخدم خدمة DNS تدعم التوجيه الموزون (Weighted Routing) مثل Route 53 — نسبة من حركة المرور تذهب إلى كل موقع. عند الكارثة، تُعدّل الأوزان لترسل كل الحركة إلى البيئة السحابية. يمكن استخدام EC2 Auto Scaling لأتمتة الزيادة في السعة. التكلفة تحددها حركة الإنتاج العادية — في مرحلة الاسترداد، تدفع فقط مقابل ما تستخدمه للمدة التي تحتاج فيها بيئة DR بكامل طاقتها.
- مرحلة الإعداد: مشابهة Warm Standby لكن بتكوين للتوسع الكامل. الخوادم تعمل وجاهزة لاستقبال الحركة. تقييم تكلفة ترخيص النظام المكرر بالكامل.
- عند وقوع الكارثة: تحويل كل حمولة الإنتاج فوراً إلى الموقع الاحتياطي — خطوة واحدة فقط.
🔑 سياسات التوجيه في Route 53: توجيه جغرافي (Geolocation Routing) يوجّه الطلبات حسب موقع المصدر — مناسب لحوكمة البيانات. توجيه الكمون (Latency Routing) يرسل الطلبات لمنطقة بأقل زمن استجابة — مناسب لتحسين الأداء.
على سبيل المثال منصة عالمية للأخبار المالية — كل ثانية توقف تكلفها آلاف الدولارات.
تشغّل بنية كاملة متطابقة في ثلاث مناطق AWS: us-east-1 و eu-west-1 و ap-southeast-1.
Route 53 بتوجيه الكمون يرسل كل مستخدم لأقرب منطقة — أدنى زمن استجابة.
إذا تعطلت منطقة us-east-1 بالكامل، يوجّه Route 53 حركتها بين المنطقتين الأخريين فوراً.
لا توقف ولا فقدان بيانات — لكن التكلفة الشهرية ثلاثة أضعاف البنية أحادية المنطقة.
تشغّل بنية كاملة متطابقة في ثلاث مناطق AWS: us-east-1 و eu-west-1 و ap-southeast-1.
Route 53 بتوجيه الكمون يرسل كل مستخدم لأقرب منطقة — أدنى زمن استجابة.
إذا تعطلت منطقة us-east-1 بالكامل، يوجّه Route 53 حركتها بين المنطقتين الأخريين فوراً.
لا توقف ولا فقدان بيانات — لكن التكلفة الشهرية ثلاثة أضعاف البنية أحادية المنطقة.
💡 مقارنة متقدمة لأنماط DR:
| المعيار | Backup & Restore | Pilot Light | Warm Standby | Multi-Site |
|---|---|---|---|---|
| البنية قيد التشغيل | لا شيء | النواة فقط (قاعدة البيانات) | نسخة مصغرة كاملة | نسخة كاملة |
| وقت الاسترداد | ساعات | عشرات الدقائق | دقائق | فوري |
| التكلفة النسبية | $ (تخزين فقط) | $$ (نواة + AMIs) | $$$ (خوادم صغيرة 24/7) | $$$$ (نسخة كاملة) |
| حالة الاستخدام | بيانات غير حيوية | تطبيقات متوسطة الأهمية | تطبيقات حيوية | تطبيقات حرجة (RTO فوري) |
7️⃣ Practice Game Day Exercises — تمارين يوم الممارسة
📖 لماذا يُختبر حل DR بانتظام؟
من أفضل الممارسات اختبار حل التعافي من الكوارث باستمرار لضمان عمله كما هو متوقع. Game Day هي تمارين عملية تختبر سيناريوهات عندما تتعطل أنظمة حيوية — أو حتى مناطق AWS بأكملها. ماذا لو تعطل أسطول كامل من الخوادم؟ تأكد من أن النسخ الاحتياطية واللقطات و AMIs تُنشأ ويمكن استخدامها لاستعادة البيانات بنجاح. اختبر إجراءات الاستجابة للتأكد من فعاليتها وإلمام الفرق بها.
📋 نصائح Game Day:
من أفضل الممارسات اختبار حل التعافي من الكوارث باستمرار لضمان عمله كما هو متوقع. Game Day هي تمارين عملية تختبر سيناريوهات عندما تتعطل أنظمة حيوية — أو حتى مناطق AWS بأكملها. ماذا لو تعطل أسطول كامل من الخوادم؟ تأكد من أن النسخ الاحتياطية واللقطات و AMIs تُنشأ ويمكن استخدامها لاستعادة البيانات بنجاح. اختبر إجراءات الاستجابة للتأكد من فعاليتها وإلمام الفرق بها.
- تأكد من إنشاء النسخ الاحتياطية واللقطات و AMIs وإمكانية استخدامها فعلاً.
- راقب نظام المراقبة الخاص بك — تأكد من أن التنبيهات تعمل.
- حدد RTO و RPO واعمل على تحسينهما قدر الإمكان.
- اختبر إجراءات الاستجابة — تأكد من أن الفرق تعرف كيفية تنفيذها عملياً.
- نظّم Game Days بشكل دوري لاختبار استجابة سير العمل والفِرق.
على سبيل المثال شركة تقنية تجري Game Day كل ربع سنة.
في أحد التمارين، قاموا بمحاكاة تعطل منطقة us-east-1 بالكامل.
اكتشفوا أن نص CloudFormation الخاص بهم لم يُحدّث منذ 8 أشهر — يفشل عند التنفيذ.
صحّحوا النص وأضافوه إلى جدول المراجعة الشهري.
في التمرين التالي، نجح التحويل الكامل في 12 دقيقة فقط.
في أحد التمارين، قاموا بمحاكاة تعطل منطقة us-east-1 بالكامل.
اكتشفوا أن نص CloudFormation الخاص بهم لم يُحدّث منذ 8 أشهر — يفشل عند التنفيذ.
صحّحوا النص وأضافوه إلى جدول المراجعة الشهري.
في التمرين التالي، نجح التحويل الكامل في 12 دقيقة فقط.
🔑 المبدأ الذهبي: "مسار التعافي الوحيد الذي يعمل هو المسار الذي تختبره باستمرار." — حكمة من AWS.
✅ خلاصة: أنماط التعافي من الكوارث
- أربعة أنماط DR شائعة: Backup & Restore و Pilot Light و Warm Standby و Multi-Site.
- Backup & Restore الأقل تكلفة لكن أعلى RTO — مناسب للبيانات غير الحيوية.
- Pilot Light يحتفظ بنواة حيوية (قاعدة بيانات) تعمل دائماً — استرداد أسرع بتكلفة متوسطة.
- Warm Standby نسخة مصغرة كاملة الوظائف — استرداد بدقائق ويمكن استخدامها للاختبار.
- Multi-Site الأسرع والأغلى — بنية Active-Active كاملة في مناطق متعددة.
- AWS Storage Gateway يوفر ثلاث واجهات (ملفات/حجم/شريط) للنسخ الاحتياطي الهجين.
- اختبر حل DR بانتظام عبر Game Day — مسار التعافي الوحيد الذي يعمل هو المختبر.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| Backup and Restore | النسخ الاحتياطي والاستعادة | نمط DR يعتمد على نسخ البيانات احتياطياً واستعادتها عند الحاجة — أبطأ وأقل تكلفة. |
| Pilot Light | الضوء التجريبي | نمط DR يحافظ على نواة حيوية (قاعدة بيانات) تعمل دائماً للتوسع السريع عند الكارثة. |
| Warm Standby | الاحتياطي الدافئ | نمط DR يشغّل نسخة مصغرة كاملة الوظائف 24/7 للتوسع السريع عند الحاجة. |
| Multi-Site | متعدد المواقع | نمط DR يشغّل بنية كاملة في مناطق متعددة بتكوين Active-Active. |
| AWS Storage Gateway | بوابة تخزين AWS | خدمة تخزين هجينة تصل التطبيقات المحلية بسحابة AWS عبر ثلاث واجهات. |
| Game Day | يوم الممارسة | تمرين عملي لاختبار استجابة سير العمل والفِرق لسيناريوهات الكوارث المحاكاة. |
| S3 Lifecycle Policy | سياسة دورة حياة S3 | قاعدة آلية تنقل البيانات بين فئات تخزين S3 حسب عمرها لتوفير التكاليف. |
1️⃣ Well-Architected Best Practices for DR — أفضل ممارسات الإطار
📖 كيف يوجّه AWS Well-Architected Framework التخطيط للكوارث؟
AWS Well-Architected Framework يتكون من ستة ركائز، كل ركيزة تتضمن أفضل الممارسات وأسئلة يجب مراعاتها عند تصميم الحلول السحابية. هذا القسم يسلط الضوء على أفضل الممارسات من الركائز الأكثر صلة بهذه الوحدة: الموثوقية (Reliability) والتميز التشغيلي (Operational Excellence) والأمان (Security).
AWS Well-Architected Framework يتكون من ستة ركائز، كل ركيزة تتضمن أفضل الممارسات وأسئلة يجب مراعاتها عند تصميم الحلول السحابية. هذا القسم يسلط الضوء على أفضل الممارسات من الركائز الأكثر صلة بهذه الوحدة: الموثوقية (Reliability) والتميز التشغيلي (Operational Excellence) والأمان (Security).
2️⃣ Failure Management — إدارة الأعطال والتخطيط للتعافي
📖 كيف تدير الأعطال وفقاً للإطار؟
كمعماري سحابة، تحتاج لفهم كيفية إنشاء بنية تدعم نظام الوقاية والتعافي لمنظمتك. بناء أعباء عمل مرنة (Resilient Workloads) يهيئ لأي حدث يمنع عبء العمل من تحقيق أهداف أعماله في موقعه الأساسي. إدارة الأعطال (Failure Management) خطوة ضرورية لتحقيق المرونة، والتخطيط للتعافي من الكوارث جزء منها. أفضل الممارسات: تحديد أهداف الاسترداد للتوقف وفقدان البيانات (RTO و RPO) بناءً على احتياجات الأعمال، استخدام استراتيجيات استرداد محددة لتحقيق الأهداف، واختبار تنفيذ التعافي بانتظام — مسار التعافي الوحيد الذي يعمل هو المختبر باستمرار.
📋 أفضل ممارسات إدارة الأعطال:
كمعماري سحابة، تحتاج لفهم كيفية إنشاء بنية تدعم نظام الوقاية والتعافي لمنظمتك. بناء أعباء عمل مرنة (Resilient Workloads) يهيئ لأي حدث يمنع عبء العمل من تحقيق أهداف أعماله في موقعه الأساسي. إدارة الأعطال (Failure Management) خطوة ضرورية لتحقيق المرونة، والتخطيط للتعافي من الكوارث جزء منها. أفضل الممارسات: تحديد أهداف الاسترداد للتوقف وفقدان البيانات (RTO و RPO) بناءً على احتياجات الأعمال، استخدام استراتيجيات استرداد محددة لتحقيق الأهداف، واختبار تنفيذ التعافي بانتظام — مسار التعافي الوحيد الذي يعمل هو المختبر باستمرار.
- حدد أهداف الاسترداد (RTO و RPO) بناءً على تأثير الأعمال — كل عبء عمل له أهداف مختلفة.
- اختر استراتيجية DR (نسخ احتياطي أو ضوء تجريبي أو احتياطي دافئ أو متعدد المواقع) — المفاضلة بين سرعة التعافي والتكلفة.
- احمِ من كارثة البيانات — البيانات المنسوخة باستمرار قد لا تحمي من التلف ما لم تستخدم الإصدارات واللقطات.
- اختبر تنفيذ DR بانتظام للتحقق من تحقيق RTO و RPO.
على سبيل المثال شركة طيران لديها ثلاثة أنظمة: حجز التذاكر (حيوي — RTO = 5 دقائق)، تسجيل الوصول (مهم — RTO = 30 دقيقة)، وتقارير الصيانة (غير حيوي — RTO = 48 ساعة).
تختار لنظام الحجز نمط Multi-Site بتكلفة عالية، ولنظام الصيانة Backup & Restore.
تختبر نظام الحجز شهرياً — في أحد الاختبارات تكتشف أن النسخة الاحتياطية تالفة بسبب خطأ في الإصدارات السابقة.
تصحح المشكلة وتضيف فحص سلامة تلقائي بعد كل نسخة.
تختار لنظام الحجز نمط Multi-Site بتكلفة عالية، ولنظام الصيانة Backup & Restore.
تختبر نظام الحجز شهرياً — في أحد الاختبارات تكتشف أن النسخة الاحتياطية تالفة بسبب خطأ في الإصدارات السابقة.
تصحح المشكلة وتضيف فحص سلامة تلقائي بعد كل نسخة.
3️⃣ Manage Workload and Operations Events — إدارة أحداث سير العمل والعمليات
📖 كيف تتواصل مع العملاء أثناء الكوارث؟
ركيزة التميز التشغيلي تشمل القدرة على دعم التطوير وتشغيل أعباء العمل بفعالية واكتساب رؤية للعمليات. أحد أفضل الممارسات التشغيلية هو تعريف خطة تواصل للعملاء لحالات الانقطاع (Customer Communication Plan for Outages). اختبر خطة التواصل بانتظام — مثلاً، شركة Any Company Retail ترسل إشعاراً بالبريد الإلكتروني لعملائها عند تأثر الخدمة وتقدم صفحة حالة (Status Page) تعرض معلومات فورية عن صحة النظام. تختبر خطة التواصل في بيئة التطوير مرتين سنوياً.
ركيزة التميز التشغيلي تشمل القدرة على دعم التطوير وتشغيل أعباء العمل بفعالية واكتساب رؤية للعمليات. أحد أفضل الممارسات التشغيلية هو تعريف خطة تواصل للعملاء لحالات الانقطاع (Customer Communication Plan for Outages). اختبر خطة التواصل بانتظام — مثلاً، شركة Any Company Retail ترسل إشعاراً بالبريد الإلكتروني لعملائها عند تأثر الخدمة وتقدم صفحة حالة (Status Page) تعرض معلومات فورية عن صحة النظام. تختبر خطة التواصل في بيئة التطوير مرتين سنوياً.
على سبيل المثال منصة للخدمات المصرفية الرقمية تعد خطة تواصل شاملة.
عند انقطاع الخدمة: (1) تُحدّث صفحة الحالة خلال دقيقة، (2) ترسل إشعاراً للعملاء عبر التطبيق، (3) تنشر تحديثاً على Twitter خلال 5 دقائق، (4) ترسل بريداً إلكترونياً للشركات المتضررة.
كل ربع سنة، تجري تمارين محاكاة للانقطاع وتقيّم سرعة وفعالية التواصل.
نتيجة لذلك، حتى في أسوأ الانقطاعات، يبقى العملاء على علم ولا يفقدون الثقة.
عند انقطاع الخدمة: (1) تُحدّث صفحة الحالة خلال دقيقة، (2) ترسل إشعاراً للعملاء عبر التطبيق، (3) تنشر تحديثاً على Twitter خلال 5 دقائق، (4) ترسل بريداً إلكترونياً للشركات المتضررة.
كل ربع سنة، تجري تمارين محاكاة للانقطاع وتقيّم سرعة وفعالية التواصل.
نتيجة لذلك، حتى في أسوأ الانقطاعات، يبقى العملاء على علم ولا يفقدون الثقة.
4️⃣ Establish an Emergency Access Process — إنشاء عملية وصول طارئة
📖 كيف يضمن الأمن الوصول الطارئ أثناء الكوارث؟
ركيزة الأمان تتطلب إنشاء عملية وصول طارئة (Emergency Access Process) للوصول إلى أعباء العمل في حالة نادرة من مشكلة في موفر الهوية المركزي. صمم عمليات لأنماط فشل مختلفة قد تؤدي لحالة طارئة — مثلاً، إذا فشل موفر الهوية المركزي أو تغيرت تهيئة الاتحاد في السحابة، قد لا يتمكن المستخدمون من الدخول إلى السحابة. عملية الوصول الطارئة تمنح المسؤولين المصرح لهم الوصول إلى موارد السحابة بوسائل بديلة لإصلاح مشاكل تهيئة الاتحاد أو أعباء العمل. الوثائق الجيدة والاختبار المنتظم يقللان وقت الاستجابة للطوارئ.
📋 خطوات إنشاء الوصول الطارئ:
ركيزة الأمان تتطلب إنشاء عملية وصول طارئة (Emergency Access Process) للوصول إلى أعباء العمل في حالة نادرة من مشكلة في موفر الهوية المركزي. صمم عمليات لأنماط فشل مختلفة قد تؤدي لحالة طارئة — مثلاً، إذا فشل موفر الهوية المركزي أو تغيرت تهيئة الاتحاد في السحابة، قد لا يتمكن المستخدمون من الدخول إلى السحابة. عملية الوصول الطارئة تمنح المسؤولين المصرح لهم الوصول إلى موارد السحابة بوسائل بديلة لإصلاح مشاكل تهيئة الاتحاد أو أعباء العمل. الوثائق الجيدة والاختبار المنتظم يقللان وقت الاستجابة للطوارئ.
- صمم عمليات لأنماط فشل مختلفة لموفر الهوية المركزي.
- حدد المسؤولين المصرح لهم للوصول البديل في الطوارئ.
- وثّق العملية بشكل كامل واختبرها عبر Game Day.
- تأكد من إمكانية الوصول إلى وحدة التحكم AWS Management Console عبر وسائل بديلة.
على سبيل المثال شركة تستخدم AWS IAM Identity Center للدخول الموحد (Federation).
في أحد الأيام، يتعطل خادم Active Directory المحلي — لا يمكن لأي موظف الدخول إلى AWS.
لحسن الحظ، أعدّت الشركة عملية وصول طارئة: مستخدم IAM رئيسي بكلمة مرور قوية مخزنة في AWS Secrets Manager مع صلاحية الوصول لثلاثة مسؤولين فقط.
يستخدم أحد المسؤولين MFA من جهاز آمن، يدخل لوحة التحكم، ويصلح تهيئة الاتحاد — تعود الخدمة في 20 دقيقة بدلاً من أيام.
في أحد الأيام، يتعطل خادم Active Directory المحلي — لا يمكن لأي موظف الدخول إلى AWS.
لحسن الحظ، أعدّت الشركة عملية وصول طارئة: مستخدم IAM رئيسي بكلمة مرور قوية مخزنة في AWS Secrets Manager مع صلاحية الوصول لثلاثة مسؤولين فقط.
يستخدم أحد المسؤولين MFA من جهاز آمن، يدخل لوحة التحكم، ويصلح تهيئة الاتحاد — تعود الخدمة في 20 دقيقة بدلاً من أيام.
✅ خلاصة: تطبيق إطار الهندسة المتقنة على التخطيط للكوارث
- حدد أهداف الاسترداد (RTO و RPO) بناءً على تأثير الأعمال — كل عبء عمل له احتياجات مختلفة.
- اختر استراتيجية DR مناسبة مع الموازنة بين سرعة التعافي والتكلفة.
- احمِ من كارثة البيانات عبر الإصدارات واللقطات — النسخ المستمر لا يحمي من التلف.
- اختبر تنفيذ DR بانتظام — مسار التعافي الوحيد الذي يعمل هو المختبر باستمرار.
- عرّف خطة تواصل للعملاء لحالات الانقطاع واختبرها نصف سنوياً.
- أنشئ عملية وصول طارئة للمسؤولين عند فشل موفر الهوية المركزي.
📖 جدول المصطلحات
| المصطلح (English) | الترجمة | المفهوم |
|---|---|---|
| Resilient Workload | عبء عمل مرن | نظام قادر على الاستمرار في تحقيق أهداف أعماله رغم الأعطال أو الاضطرابات. |
| Failure Management | إدارة الأعطال | مجموعة الممارسات للتعرف على الأعطال والاستجابة لها والتعافي منها. |
| Customer Communication Plan | خطة تواصل العملاء | خطة محددة مسبقاً لإبلاغ العملاء والمستخدمين بحالات الانقطاع وتقدم التعافي. |
| Status Page | صفحة الحالة | صفحة ويب تعرض معلومات فورية عن صحة النظام ومدى توفر الخدمات. |
| Emergency Access Process | عملية الوصول الطارئ | إجراءات تسمح للمسؤولين المصرح لهم بالوصول إلى السحابة بوسائل بديلة عند الطوارئ. |
| Federation | الاتحاد | آلية تسمح للمستخدمين بالمصادقة عبر موفر هوية خارجي للوصول إلى موارد AWS. |
1. A media company has a critical application in us-east-1 (RDS + EC2 behind ALB). They need RPO of 15 minutes and RTO of 1 hour. Which DR strategy meets these requirements?
Correct! Warm standby provides RPO of minutes and RTO of minutes to an hour. It runs a scaled-down copy with data replication and scales up on failover.
Incorrect. The correct answer is C. Warm standby meets the 15-min RPO and 1-hour RTO requirements cost-effectively.
2. A hospital's patient management system requires that no more than 1 minute of patient data can be lost in a disaster. What RPO must the architecture support?
Correct! RPO is the maximum acceptable data loss measured in time. If no more than 1 minute of data can be lost, RPO must be 1 minute or less.
Incorrect. The correct answer is C. RPO defines max acceptable data loss in time. "No more than 1 minute" means RPO = 1 minute or less.
3. A company has backup & restore with daily snapshots (RPO 24h, RTO 12h). They want RTO of 4 hours with minimal cost increase. Which change is MOST effective?
Correct! Automation with CloudFormation and pre-warmed AMIs reduces RTO by eliminating manual steps. Pre-warming means AMIs are already in the recovery region ready to launch.
Incorrect. The correct answer is B. Automating recovery directly reduces RTO. More frequent snapshots help RPO, not RTO.
4. A company uses S3 CRR between eu-west-1 and eu-central-1. Compliance requires replicated data available in the destination within 15 minutes. Which feature should they enable?
Correct! S3 RTC guarantees 99.99% of objects replicate within 15 minutes with a service-level agreement and monitoring.
Incorrect. The correct answer is B. S3 RTC provides a guaranteed 15-minute replication SLA — standard CRR is best-effort without time guarantee.
5. A company runs e-commerce on EC2 in a single Region. They want fault tolerance at the Availability Zone level. Which change provides the BEST fault tolerance?
Correct! Deploying across multiple AZs with an ALB and Auto Scaling provides AZ-level fault tolerance. If one AZ fails, traffic routes to healthy instances.
Incorrect. The correct answer is B. AZ fault tolerance requires distributing instances across multiple AZs behind a load balancer.
6. A company needs to back up 50 TB of on-premises files to AWS with automated scheduling and integrity verification. Which service?
Correct! DataSync is designed for automated, scheduled on-premises to AWS transfers with built-in checksum integrity verification.
Incorrect. The correct answer is B. DataSync handles large-scale scheduled transfers with incremental sync and integrity verification.
7. A critical application needs the lowest possible RTO and RPO with automatic failover between Regions. Which DR strategy?
Correct! Multi-Site Active-Active runs in both regions with automatic Route 53 failover, providing near-zero RTO and near-zero RPO.
Incorrect. The correct answer is D. Multi-Site Active-Active provides the lowest RTO/RPO at the highest cost.
8. A company uses AWS Backup. They need daily backups for 30 days, weekly for 3 months, monthly for 1 year. Which feature should they use?
Correct! AWS Backup lifecycle rules automatically transition and expire recovery points based on age, supporting multiple retention tiers.
Incorrect. The correct answer is B. Lifecycle rules in backup plans automate retention transitions and expirations.
9. A DynamoDB table stores user session data. They need protection against accidental writes/deletes and the ability to restore to any point in the last 35 days. Which feature?
Correct! PITR continuously backs up DynamoDB tables and enables restoration to any point within the last 35 days with 1-second granularity.
Incorrect. The correct answer is A. PITR provides continuous backups with 1-second granularity for 35 days.
10. A company wants to test DR by simulating failover without impacting production. They need to validate CloudFormation templates in the recovery region. What should they do?
Correct! Game Days simulate failures in a controlled environment, validating recovery templates and processes without production impact.
Incorrect. The correct answer is B. Game Days are the recommended practice for testing DR procedures safely.
🚀 الخاتمة
في هذه الوحدة تعلمنا كيف نفكر في الكوارث ليس كاستثناءات نادرة بل كحقائق حتمية — "كل شيء يتعطل، كل الوقت" كما يقول Werner Vogels. استعرضنا استراتيجيات التخطيط للكوارث بما فيها RPO و RTO وخطة استمرارية الأعمال (BCP) والعوامل الأربعة المؤثرة: الوقت وفقدان البيانات والموقع والتكلفة. انتقلنا إلى التخطيط العملي في AWS عبر خمس فئات خدمات — التخزين والحوسبة وقواعد البيانات والشبكات والنشر — مع خدمات مثل S3 CRR و EBS Snapshots و RDS Read Replicas و CloudFormation. استعرضنا الأنماط الأربعة للتعافي من الكوارث — من Backup & Restore الأقل تكلفة إلى Multi-Site الأسرع — وأخيراً طبقنا مبادئ AWS Well-Architected Framework لإدارة الأعطال والتواصل مع العملاء والوصول الطارئ. تذكر دائماً: اختبر حل DR بانتظام — مسار التعافي الوحيد الذي يعمل هو المختبر باستمرار.