التعافي من الكوارث وتعدد المناطق

استراتيجيات التعافي من الكوارث

18 دقيقة الدرس 2 من 27

استراتيجيات التعافي من الكوارث

كل استراتيجية للتعافي من الكوارث هي، في جوهرها، مقايضة بين متغيرين حددتهما في الدرس الأول: RTO وRPO. يُقدّم السوق أربعة أنماط معيارية — النسخ الاحتياطي والاستعادة، والضوء التجريبي، والاستعداد الدافئ، والنشاط المزدوج — تمتد عبر طيف التكلفة مقابل وقت التعافي بالكامل. اختيار النمط الخطأ يُهدر ملايين الدولارات أو يتركك مع RTO لا تستطيع تحقيقه فعلاً حين تُظلم المنطقة. يُخصّص هذا الدرس الأنماط الأربعة بدقة، ويعرض البنية التحتية خلف كل منها، ويمنحك الحكم اللازم للاختيار.

الاستراتيجيات الأربع بنظرة عامة

قبل الغوص في كل استراتيجية، استوعب الطيف: مع التقدم من النسخ الاحتياطي والاستعادة نحو النشاط المزدوج، تزداد التكلفة وينخفض وقت التعافي. لا وجود لغداء مجاني — كل دقيقة تُقتطع من RTO تُدفع في حوسبة احتياطية قائمة، وتكرار البيانات، وتعقيد تشغيلي. يُبيّن الرسم البياني أدناه موضع كل من الأنماط الأربعة على الطيف.

الاستراتيجيات الأربع للتعافي من الكوارث مُرسَّمة مقابل التكلفة ووقت التعافي. التحرك يميناً وأسفل يكلف أكثر لكن يُحقق RTO/RPO شبه صفري.

الاستراتيجية الأولى: النسخ الاحتياطي والاستعادة (Backup-Restore)

ما هي: تُنسَخ جميع بيانات الإنتاج احتياطياً إلى تخزين متين (S3، GCS، Azure Blob) وفق جدول زمني. لا توجد بنية تحتية قيد التشغيل في منطقة التعافي من الكوارث. عند وقوع كارثة، يُؤسَّس المكدس بالكامل من الصفر — قوالب IaC، ونسخ AMI، وصور الحاويات — وتُستعاد البيانات من أحدث نسخة احتياطية. يُعاد إنشاء كل شيء عند الطلب.

متى تستخدمها: بيئات التطوير والاختبار، والأدوات الداخلية، وأعباء العمل الدفعية، وأي نظام تقبل فيه الجهة تجارياً بساعات من التوقف. شركة ناشئة بـ SLA مدته 4 ساعات RTO وساعة RPO تدفع جزءاً ضئيلاً مما ستكلفه الاستراتيجية النشطة المزدوجة.

أنماط الفشل الإنتاجي المهمة: أكثر الكوارث شيوعاً في النسخ الاحتياطي والاستعادة هي اكتشاف أن نسخك الاحتياطية تالفة أو غير مكتملة فقط حين تحتاجها. ومنها أيضاً انجراف حالة Terraform/Pulumi — فـ IaC الذي كان يعمل قبل ستة أشهر لم يعد يتطابق مع البيئة الحالية. وتُقدَّر وقت التأسيس البارد تقديراً أقل من الواقع دائماً في حسابات RTO: تشغيل أسطول من 500 مثيل EC2، وتشغيل الترحيلات، وتدفئة الذواكر المؤقتة يستغرق روتينياً 3–4 ساعات حتى مع الأتمتة الكاملة.

مصيدة إنتاجية: الفرق التي تختار النسخ الاحتياطي والاستعادة لأنه "رخيص" كثيراً ما تنسى ميزانية تمارين الاستعادة المنتظمة. إن لم تكن قد استعدت فعلاً من نسخك الاحتياطية في منطقة التعافي، فليس لديك خطة تعافٍ من الكوارث — لديك أمنية. توصي AWS باختبار الاستعادة شهرياً لأعباء العمل من المستوى الأول. التحقق التلقائي من الاستعادة (الاستعادة إلى حساب اختبار، تشغيل اختبار دخان، إرسال تنبيه Slack) يجب أن يكون مهمة cron، لا تمريناً يدوياً ربع سنوي.

# مثال: خطة AWS Backup مع نسخ عبر المناطق باستخدام Terraform.
# تنسخ احتياطياً مجموعة RDS كل ساعة، وتنسخها إلى منطقة التعافي مع استبقاء 7 أيام.

resource "aws_backup_plan" "rds_hourly" {
  name = "rds-hourly-cross-region"

  rule {
    rule_name         = "hourly"
    target_vault_name = aws_backup_vault.primary.name
    schedule          = "cron(0 * ? * * *)"

    lifecycle {
      delete_after = 7
    }

    copy_action {
      destination_vault_arn = "arn:aws:backup:us-west-2:${var.account_id}:backup-vault:dr-vault"
      lifecycle {
        delete_after = 7
      }
    }
  }
}

resource "aws_backup_selection" "rds" {
  name         = "rds-cluster"
  plan_id      = aws_backup_plan.rds_hourly.id
  iam_role_arn = aws_iam_role.backup.arn

  resources = [
    aws_rds_cluster.primary.arn,
  ]
}

الاستراتيجية الثانية: الضوء التجريبي (Pilot Light)

ما هي: الحد الأدنى من النظام يعمل باستمرار في منطقة التعافي على نطاق ضئيل — عادةً فقط طبقة قاعدة البيانات مع التكرار الحي والصور مُسحوبة مسبقاً لكن غير مشغَّلة. خوادم التطبيق وموازنات الأحمال ومجموعات التحجيم التلقائي موجودة كقوالب IaC لكنها غير مُؤسَّسة. يتضمن التبديل الاضطراري تشغيل طبقة الحوسبة الخاملة وتوجيه DNS.

قياس: الضوء التجريبي في سخّان الغاز — الشعلة صغيرة لا تستهلك تقريباً شيئاً، لكنها تستطيع إشعال الفرن الكامل خلال ثوانٍ. الفكرة ذاتها: بياناتك دافئة دائماً، حوسبتك باردة.

أرقام الحجم في نطاق Google/AWS: عادةً تعمل قاعدة بيانات التعافي في وضع الضوء التجريبي بطاقة 1/8 إلى 1/4 من الإنتاج. لمثيل RDS أساسي بـ 32 vCPU، يُشغَّل الضوء التجريبي نسخة قراءة بـ 4 vCPU تُرقَّى عند التبديل الاضطراري. الفرق في التكلفة الجارية بين النسخ الاحتياطي والاستعادة والضوء التجريبي هو تقريباً تكلفة تلك النسخة المكررة لقاعدة البيانات — غالباً 200–800 دولار شهرياً مقابل ملايين للاستراتيجية النشطة المزدوجة.

ممارسة احترافية: احرص على تحديث صور AMI وصور الحاويات في منطقة التعافي باستمرار، لا فقط عند وقوع الكارثة. الصورة التي دُفعت آخر مرة إلى سجل ECR في منطقة التعافي قبل ستة أشهر لن تحمل أحدث تصحيحات الأمان. أضف خطوة إلى أنبوب CI/CD يدفع الصور إلى كلا سجلَّي المنطقة الأساسية والتعافي مع كل دمج في الفرع الرئيسي.

الاستراتيجية الثالثة: الاستعداد الدافئ (Warm Standby)

ما هي: نسخة مطابقة للإنتاج مُصغَّرة الحجم تعمل باستمرار في منطقة التعافي. قاعدة البيانات مكررة بالكامل (متزامنة أو غير متزامنة تبعاً للمسافة)، وخوادم التطبيق تعمل بطاقة منخفضة — عادةً 20–25% من الإنتاج. عند التبديل الاضطراري، تتوسع مجموعات التحجيم التلقائي إلى الطاقة الإنتاجية الكاملة ويتبدل DNS. الفرق الرئيسي عن الضوء التجريبي: طبقة التطبيق تعمل بالفعل، لكن ليس بالحجم الكامل.

RTO في الواقع العملي: العامل المُهيمن على RTO في الاستعداد الدافئ هو وقت انتشار DNS مضافاً إليه وقت توسع ASG. مع TTL منخفضة (60 ثانية) ومجموعات ASG مُدفَّأة مسبقاً، يمكن تحقيق RTO من 5–10 دقائق باستمرار. هذا هو الـ SLA الذي تستهدفه كتب تشغيل SRE للتبديل الاضطراري الإقليمي في Google Cloud للخدمات من المستوى الأول.

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

# Terraform: مجموعة Auto Scaling للاستعداد الدافئ في منطقة التعافي.
# تعمل بطاقة 25% عادةً؛ التبديل الاضطراري يرفع الـ desired إلى 100%.

resource "aws_autoscaling_group" "app_dr" {
  provider = aws.dr_region

  name                = "app-warm-standby"
  min_size            = 2
  max_size            = 40
  desired_capacity    = 4           # 25% من أسطول 16 مثيلاً في الإنتاج
  vpc_zone_identifier = var.dr_private_subnets
  target_group_arns   = [aws_lb_target_group.app_dr.arn]

  launch_template {
    id      = aws_launch_template.app_dr.id
    version = "$Latest"
  }

  tag {
    key                 = "Role"
    value               = "warm-standby"
    propagate_at_launch = true
  }

  lifecycle {
    ignore_changes = [desired_capacity]   # أتمتة التبديل الاضطراري تُعيد الكتابة فوق هذا
  }
}

# سكريبت التبديل الاضطراري: توسع إلى الطاقة الكاملة + تبديل وزن Route53
# شغّله من Lambda أو دليل تشغيل عند إطلاق التبديل الاضطراري:
# aws autoscaling set-desired-capacity \
#   --auto-scaling-group-name app-warm-standby \
#   --desired-capacity 16 \
#   --region us-west-2

الاستراتيجية الرابعة: النشاط المزدوج (Active-Active)

ما هي: حركة مرور الإنتاج مُقسَّمة عبر منطقتين (أو أكثر) في آنٍ واحد. تخدم كلتا المنطقتين حركة مرور المستخدمين الحيّة في جميع الأوقات. لا توجد "منطقة تعافٍ من الكوارث" — كل منطقة أساسية. يُعطل إخفاق منطقة واحدة موازن الأحمال أو طبقة DNS لتوجيه كل حركة المرور إلى المنطقة (المناطق) الناجية، دون أي تدخل يدوي وتبديل اضطراري بأجزاء من الثانية. هكذا تُشغّل AWS وGoogle وNetflix أهم خدماتها.

المشكلات الهندسية الصعبة: النشاط المزدوج ليس مجرد "تشغيل نسختين." المشكلة الصعبة هي اتساق البيانات. مع الكتابة في مناطق متعددة، تحتاج إلى قاعدة بيانات موزعة عالمياً (DynamoDB Global Tables، CockroachDB، Spanner، Cassandra متعدد السيد) تستطيع التعامل مع حل النزاعات. يجب أن تقرر استراتيجية النزاع (آخر كتابة تفوز، CRDTs، الحل على مستوى التطبيق)، وأن تقبل أن الاتساق القوي عبر المناطق يتطلب رحلات ذهاب وإياب عبر المناطق ستهيمن على زمن الاستجابة p99.

آليات توجيه حركة المرور: يستخدم النشاط المزدوج عادةً إحدى ثلاث استراتيجيات توجيه: (1) التوجيه القائم على الزمن الاستجابة عبر Route 53 أو Cloudflare، لإرسال كل مستخدم إلى المنطقة الأقرب؛ (2) التوجيه الموزون، لتقسيم حركة المرور 50/50 أو 70/30 بين المناطق؛ أو (3) توجيه Anycast على طبقة الشبكة، الذي تستخدمه شبكات CDN ومزودو DNS أنفسهم. عند الإخفاق، تُزيل فحوصات الصحة المنطقة الفاشلة من مجموعة التوجيه خلال 30–60 ثانية للمناهج القائمة على DNS، أو دون ثانية للتوجيه القائم على BGP و Anycast.

فكرة أساسية — النشاط المزدوج بنية معمارية لا ميزة: لا يمكن إضافة النشاط المزدوج على نظام مُصمَّم لمنطقة واحدة. يجب تكرار حالة الجلسة (Redis Cluster أو DynamoDB)، ويجب أن يكون المحتوى الذي يرفعه المستخدمون في مخزن كائنات مكرر عالمياً، ويجب تصميم كل خدمة لمعالجة الطلبات من أي منطقة دون افتراض بيانات محلية فقط. تكلفة إعادة البنية المعمارية هي السبب في حصر النشاط المزدوج للخدمات المهمة للغاية حيث تتجاوز تكلفة التوقف 10,000–100,000 دولار في الدقيقة.

المقارنة المعمارية للبنية التحتية للاستراتيجيات الأربع للتعافي من الكوارث. النشاط المزدوج هو النمط الوحيد الذي تخدم فيه كلتا المنطقتين حركة مرور حية في آنٍ واحد.

اختيار الاستراتيجية الصحيحة

يتحكم في القرار أربعة عوامل: SLA التعاقدي لـ RTO/RPO، تكلفة التوقف في الدقيقة، المتطلبات التنظيمية (بعض اللوائح المالية تُلزم بالاستعداد الدافئ أو أفضل منه)، ومستوى النضج التشغيلي لفريقك. إطار عمل مفيد من AWS Well-Architected:

RTO أكبر من 4 ساعات، RPO أكبر من ساعة: النسخ الاحتياطي والاستعادة. استثمر المدخرات في أتمتة اختبار النسخ الاحتياطي قوية.
RTO من 1–4 ساعات، RPO من 15–60 دقيقة: الضوء التجريبي. احرص على دفء نسخة قاعدة البيانات والصور؛ واقبل وقت توفير الحوسبة الباردة.
RTO أقل من 30 دقيقة، RPO أقل من 5 دقائق: الاستعداد الدافئ. ادفع تكلفة أسطول النسخ المكررة المنخفض الطاقة وأتمتة تبديل DNS وتوسع ASG.
RTO أقل من 60 ثانية أو صفر فقدان بيانات (RPO = 0): النشاط المزدوج. اقبل القيود المعمارية والتكلفة؛ هذا الخيار الوحيد للخدمات الحيوية على نطاق واسع.

ممارسة احترافية — مسار الترقية: هذه الاستراتيجيات ليست دائمة. تبدأ معظم المنصات الناضجة بالنسخ الاحتياطي والاستعادة، وتُثبت انضباط أتمتة IaC، ثم ترقى إلى الضوء التجريبي حين يتشدد الـ SLA. تُشغّل كثير من شركات SaaS الكبيرة الاستعداد الدافئ لسنوات قبل أن تُبرر الأعمال التحول إلى النشاط المزدوج. صمّم كل مستوى بحيث يمكنه التطور: إن كانت قاعدة بيانات DR في وضع الضوء التجريبي هي بالفعل نسخة قراءة RDS متعددة مناطق التوفر مع تكرار عبر المناطق، فإن الترقية إلى الاستعداد الدافئ هي في معظمها إضافة ASG، لا إعادة بناء معمارية.

مقياس حيوي تُفوّته معظم الفرق

عبر الاستراتيجيات الأربع جميعها، المقياس الذي يُحدد ما إذا كان التعافي يعمل فعلاً هو MTTR-DR: متوسط وقت التعافي في حدث تعافٍ حقيقي، مقاساً من لحظة اتخاذ قرار التبديل الاضطراري إلى لحظة خدمة النظام حركة مرور الإنتاج من منطقة التعافي بالطاقة الكاملة. معظم الفرق لا تقيس هذا المقياس إلا في المختبر. كل استراتيجية تعافٍ على الورق تبدو أفضل مما هي في الواقع، لأنك في المرة الأولى التي تُنفّذ فيها تبديلاً اضطرارياً حقيقياً تكتشف أن حالة Terraform في bucket S3 خاطئة، أو أن TTL لـ Route 53 لم تُخفَّض قط، أو أن مجموعة ASG للاستعداد الدافئ تُشغّل AMI عمرها ستة أشهر. اختبر MTTR-DR بأيام تجريبية حقيقية، وهو ما يتناوله الدرس الثامن.