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

آليات التحويل التلقائي عند الفشل

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

آليات التحويل التلقائي عند الفشل

التحويل عند الفشل (Failover) هو الفعل التشغيلي المتمثل في إعادة توجيه حركة المرور — أو ترقية نظام احتياطي — عندما يصبح الموقع الأساسي غير صحي. إذا نُفِّذ بشكل سيئ، فإنه يطيل فترة التوقف. أما إذا نُفِّذ بشكل صحيح، فإنه يمر دون أن يلاحظه العملاء. يحلل هذا الدرس المكونات الثلاثة المترابطة التي تجعل التحويل موثوقًا على نطاق واسع: فحوصات الصحة، ونظام DNS، وكتب التشغيل (أو ما يقابلها من أتمتة).

فحوصات الصحة: الإشارة التي تقود كل شيء

قرار التحويل لا يعلو على جودة الإشارة التي تؤدي إلى اتخاذه. لكل طبقة في المنظومة آلية فحص صحة خاصة بها، ويجب أن تكون هذه الفحوصات متعددة الطبقات — لا تكفي فحصة واحدة في بيئة الإنتاج.

فحوصات موازن الحمل — فحوصات صحة هدف ALB/NLB، تتوقع HTTP 200 على نقطة نهاية خفيفة (مثل /healthz) كل 10 ثوانٍ مع حد ثلاث إخفاقات. هذه تتحكم في حركة المرور على مستوى المثيل، لا على مستوى المنطقة.
فحوصات Route 53 — ترسل طلبات كل 10 أو 30 ثانية من ثلاث نقاط تواجد AWS أو أكثر حول العالم. الحد: ثلاثة إخفاقات متتالية. يمكن أن تكون من نوع HTTP/HTTPS/TCP؛ ولـ HTTPS يُتحقق من شهادة TLS. يمكن تسلسلها: تصبح "فحصة محسوبة" صحية فقط عندما تكون N من M فحصات فرعية صحية — مفيد لحالات مثل "المنطقة صحية إذا كانت 2 من 3 مناطق توافر تخدم الطلبات".
المراقبون الاصطناعيون — تشغّل CloudWatch Synthetics أو Datadog Browser Tests سيناريوهات متصفح حقيقية كل دقيقة من مناطق متعددة. يمكن لـ canary فاشل أن يقلب فحصة Route 53 عبر إنذار CloudWatch ← قاعدة EventBridge ← تحديث Route 53 (Lambda).

الفحوصات السطحية مقابل العميقة: نقطة نهاية /healthz تعيد 200 لأن خادم HTTP حي بينما مجمع اتصالات قاعدة البيانات مستنفَد ستجعل المثيل يبدو صحيحًا وهو في الواقع عاجز عن خدمة الطلبات. الفحوصات العميقة التي تتتبع مسار الطلب الكامل تكشف هذا، لكنها تضيف زمن استجابة وقد تصبح هي نفسها مصدرًا للحمل. الحل الوسط القياسي: فحصة سطحية لموازن الحمل (سريعة ورخيصة) وفحصة عميقة لفحصة Route 53 الإقليمية التي تقود قرار التحويل (أبطأ، لكن القرارات ذات الأثر الكبير تستحق بيانات أفضل).

أنماط التحويل عبر DNS

DNS هو نقطة الدخول الأساسية للتحويل الإقليمي لأنه آخر تبعية مشتركة بين المناطق. سياستا توجيه Route 53 الرئيسيتان المستخدمتان في DR هما توجيه التحويل عند الفشل وتوجيه الأوزان المرتبط بفحوصات الصحة.

تحويل Route 53 النشط-السلبي: تخدم المنطقة الأساسية جميع حركة المرور عندما تكون صحية؛ عند فشل فحوصات الصحة، يقوم Route 53 تلقائيًا بالتوجيه إلى المنطقة الثانوية.

المعاملات الرئيسية التي يجب على المهندسين معرفتها في الإنتاج:

TTL — الرافعة الأكثر أثرًا. بالنسبة لسجلات الطوارئ، اضبط TTL على 60 ثانية (بعض الفرق تنزل إلى 30 ثانية). عند TTL=300 (خمس دقائق)، يحتفظ العملاء بالسجل القديم A لمدة خمس دقائق بعد أن يقلبه Route 53 — أي خمس دقائق من الانقطاع الكامل لكل طلب يصطدم بالسجل المنتهي صلاحيته. الثمن هو زيادة حجم استعلامات DNS (وبالتالي رسوم Route 53 لكل استعلام)، وهو ضئيل مقارنةً بالأثر على RTO.
Evaluate Target Health — لسجلات الاسم المستعار (alias) التي تشير إلى موازنات الحمل ALB، يؤدي تمكين هذا الخيار إلى نشر صحة ALB في Route 53 دون الحاجة إلى مورد فحصة صحة منفصل.
مدة TTL للعودة — عندما يتعافى المصدر الأساسي، سيبدأ Route 53 في إعادة سجله. اضبط TTL أعلى منفصلًا للسجل الثانوي حتى تستنزف حركة المرور منه تدريجيًا بدلًا من التأرجح مرة واحدة.

# Terraform: Route 53 active-passive failover with health check
resource "aws_route53_health_check" "primary" {
  fqdn              = "api-primary.internal.example.com"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/healthz"
  failure_threshold = 3
  request_interval  = 10

  tags = { Name = "primary-region-healthcheck" }
}

resource "aws_route53_record" "api_primary" {
  zone_id = var.hosted_zone_id
  name    = "api.example.com"
  type    = "A"
  ttl     = 60

  set_identifier = "primary"

  failover_routing_policy {
    type = "PRIMARY"
  }

  health_check_id = aws_route53_health_check.primary.id
  records         = [var.primary_alb_ip]
}

resource "aws_route53_record" "api_secondary" {
  zone_id = var.hosted_zone_id
  name    = "api.example.com"
  type    = "A"
  ttl     = 60

  set_identifier = "secondary"

  failover_routing_policy {
    type = "SECONDARY"
  }

  # No health_check_id — secondary is always returned when primary fails
  records = [var.secondary_alb_ip]
}

التحويل عبر كتب التشغيل

حتى لو كنت تخطط لأتمتة التحويل في نهاية المطاف، يجب على كل فريق أولًا كتابة كتاب تشغيل والتدرب عليه. كتب التشغيل هي المرجع الحقيقي لما يعنيه "التحويل" فعلًا في نظامك. تكشف عن التبعيات الخفية (قائد Redis sentinel، مجموعة مستهلك Kafka MirrorMaker، فهرس النسخ المتقاطعة في Elasticsearch) التي ستحتاج إليها الأتمتة على أي حال.

يتكون كتاب تشغيل DR على مستوى الإنتاج من خمسة أقسام:

معايير القرار — الشروط الصريحة التي تُشغِّل كتاب التشغيل. ليس "الموقع بطيء" بل "كانت فحصة صحة Route 53 في حالة UNHEALTHY لمدة دقيقتين على الأقل وأكد المراقب الاصطناعي من eu-west-1 الفشل." تُسبب المحفزات الغامضة حوادث تحويل مبكرة أو فائتة.
الفحوصات التمهيدية — تأكيد جاهزية المنطقة الثانوية فعلًا (تأخر النسخ أقل من 30 ثانية، تجمع EC2 الدافئ في حالة ACTIVE، الأسرار مُحدَّثة). الفشل في هذا الفحص يحوّل حادثة واحدة إلى حادثتين.
خطوات مُرتَّبة مع تراجع — لكل خطوة مالك ونتيجة متوقعة وإجراء تراجع. مثال: "ترقية نسخة RDS ← التحقق من نجاح الكتابة ← تحديث إعداد التطبيق ← المتابعة؛ في حالة فشل الترقية، نبّه مسؤول قاعدة البيانات المناوب وانتظر."
قالب التواصل — تحديث مُعَدّ مسبقًا لصفحة الحالة ورسالة Slack داخلية جاهزة للنسخ واللصق تحت الضغط.
التحقق بعد التحويل — قائمة مراجعة من الاختبارات الدخانية (المعاملات الاصطناعية، مقاييس الأعمال الرئيسية، عمق الطابور) التي تؤكد أن المنطقة الثانوية تخدم بشكل صحيح فعلًا قبل خفض درجة الحادثة.

التحويل التلقائي

يقلل التحويل التلقائي من وقت رد فعل الإنسان من 5–30 دقيقة إلى 30–120 ثانية، لكنه يُدخل خطر الدماغ المشقوق (split-brain) أو محفز إيجابي كاذب يتسبب في تحويل غير ضروري. الحلول المضادة هي القرارات القائمة على النصاب وقواطع الدائرة.

# AWS Lambda: automated Route 53 failover triggered by CloudWatch Alarm
# (Simplified — production versions include idempotency checks and SNS alerts)
import boto3, os

r53  = boto3.client('route53')
sns  = boto3.client('sns')

PRIMARY_RECORD_ID   = os.environ['PRIMARY_RECORD_ID']
SECONDARY_RECORD_ID = os.environ['SECONDARY_RECORD_ID']
ZONE_ID             = os.environ['HOSTED_ZONE_ID']
TOPIC_ARN           = os.environ['ALERT_TOPIC_ARN']

def handler(event, context):
    alarm_state = event['detail']['state']['value']

    if alarm_state != 'ALARM':
        return  # Only act on transition to ALARM

    # Disable the primary health check so Route 53 routes to secondary
    r53.update_health_check(
        HealthCheckId=PRIMARY_RECORD_ID,
        Disabled=True,
    )

    sns.publish(
        TopicArn=TOPIC_ARN,
        Subject='DR FAILOVER TRIGGERED',
        Message=(
            'Automated failover initiated. Primary health check disabled.\n'
            'Validate secondary region before closing incident.'
        ),
    )

القاعدة الذهبية للتحويل التلقائي: أتمت الكشف وتبديل DNS، لكن اشترط موافقة بشرية على ترقية قاعدة البيانات. أتمتة DNS منخفضة الخطورة — يمكن عكسها في ثوانٍ. أتمتة ترقية نسخة RDS أو تحويل Kafka MirrorMaker عالية الخطورة لأن عكسها بشكل نظيف أمر صعب في حال كان "الفشل" مجرد تذبذب شبكي عابر.

تحويل RDS: Aurora مقابل Multi-AZ القياسي

يستخدم Aurora Global Database نقطة نهاية كاتب مستندة إلى DNS. ترقية منطقة ثانوية إلى كاتب تستغرق 1–2 دقيقة (SLA من AWS: أقل من دقيقة لـ RPO مع التحويل المُدار المخطط). تحويل Multi-AZ القياسي لـ RDS داخل المنطقة فقط؛ التحويل بين المناطق يتطلب نسخة للقراءة وترقية يدوية أو مكتوبة بالبرمجة. الفرق مهم: Aurora Global مناسب لـ RTO أقل من دقيقتين؛ RDS القياسي عبر المناطق مناسب لـ RTO من 5–30 دقيقة حسب مستوى الأتمتة.

التحويل للمكونات عديمة الحالة مقابل ذات الحالة

الخدمات عديمة الحالة (خوادم API، العمال) — يكفي تبديل DNS. تقبل المنطقة الجديدة حركة المرور فورًا بمجرد اجتياز فحوصات الصحة. يجب تهيئة تجمعات التوسع الدافئة (EC2 Auto Scaling predictive، EKS Karpenter) مسبقًا حتى لا تبدأ المنطقة الثانوية من الصفر تحت الحمل الكامل.
الخدمات ذات الحالة (قواعد البيانات، التخزين المؤقت، طوابير الرسائل) — تتطلب ترقية صريحة والتحقق من تأخر النسخ. بالنسبة لـ Redis، يوفر ElastiCache Global Datastore تحويلًا تلقائيًا عبر المناطق مع RPO أقل من ثانية. بالنسبة لـ Kafka، يتطلب MirrorMaker 2 في الوضع النشط-السلبي إعادة ضبط يدوية لإزاحة مجموعة المستهلكين بعد الترقية.

أدفئ المنطقة الثانوية دائمًا. في Netflix وما يماثلها من المؤسسات، تحافظ المنطقة الثانوية على 20–25 % على الأقل من طاقة الإنتاج في جميع الأوقات، مع توسع تلقائي يصل إلى 100 % خلال نافذة التحويل. البدء البارد لمنطقة من الصفر تحت حركة المرور الكاملة — التوسع التلقائي من الصفر، سحب صور الحاويات، إحماء JVM — يضاعف RTO الفعلي عادةً. تكلفة الطاقة الخاملة ضئيلة للغاية مقارنةً بتكلفة الانقطاع الممتد.

مقاييس التحويل التي يجب تتبعها

في منظومة مراقبة DR لديك، يجب أن تكون المقاييس التالية جاهزة بلوحات معلومات وإنذارات قبل أي تدريب:

HealthCheckPercentageHealthy — مقياس Route 53 في CloudWatch؛ إنذار عند أقل من 100 % للحصول على تحذير مبكر.
ReplicaLag — تأخر نسخة RDS/Aurora بالثواني؛ إنذار عند أكثر من 30 ثانية.
MirrorMaker2 replication latency — تأخر النسخ عبر المناطق لـ Kafka؛ إنذار عند أكثر من 60 ثانية.
وقت انتشار DNS — القياس من لحظة تبديل فحصة الصحة إلى أول طلب يصل إلى المنطقة الثانوية؛ تتبع النسبة المئوية 99 عبر المناطق.
وقت أول بايت في المنطقة الثانوية — خط أساسي لزمن استجابة المراقب الاصطناعي الشامل، للتمييز بين "بطيء" و"فاشل".