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

مشروع: خطة التعافي من الكوارث

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

مشروع: خطة التعافي من الكوارث

كل ما تناولناه في هذا الدرس التعليمي — اشتقاق RTO وRPO، ومعمارية النسخ الاحتياطي، والنسخ المتماثل عبر المناطق، وآليات تجاوز الفشل، والتعافي المدفوع بـ GitOps، واختبار يوم الألعاب، ونمذجة التكاليف — يتجمع هنا. يقودك هذا الدرس خلال كتابة خطة تعافٍ كاملة وبمستوى الإنتاج لنظام عملي واقعي. ستُنتج الأداتين اللتين تهمان فعلًا أثناء الحوادث الحقيقية: وثيقة استراتيجية التعافي ("ماذا ولماذا") وكتيب التشغيل ("كيف، بالضبط، الآن"). كل ما عدا ذلك تعليق.

النظام النموذجي

النظام المستهدف هو OrderFlow، منصة SaaS متعددة المستأجرين لإدارة الطلبات. مواصفاته:

150,000 شركة نشطة يوميًا، ذروة 80,000 طلب/ثانية عند الدفع.
PostgreSQL 16 أساسي (db-primary.us-east-1) مع نسختين للقراءة؛ Aurora Global Database كنسخة احتياطية عبر المناطق في us-west-2.
Apache Kafka (MSK) لبث الأحداث — أحداث الطلبات، وتحديثات المخزون، وإشارات الدفع.
مجموعة Redis 7 لحالة الجلسة وعدادات تحديد المعدل.
Kubernetes 1.30 (EKS) في us-east-1 الأساسية، ومجموعة احتياطية دافئة في us-west-2 (مُعدَّة بسعة 30%؛ تُوسَّع للسعة الكاملة خلال ~8 دقائق عبر Karpenter).
بنية تحتية تُدار بـ Terraform؛ جميع بيانات K8s في مستودع GitOps (ArgoCD).
تأثير الإيرادات: 120,000 دولار لكل دقيقة توقف عند الدفع. 2,400 دولار/دقيقة عند تراجع الأداء في غير الدفع.

اشتق RTO وRPO من تأثير الإيرادات، لا من الحدس. بمعدل 120 ألف دولار/دقيقة، حتى دقيقتان من توقف الدفع تكلفان 240 ألف دولار. ترقية Aurora Global Database الثانوي في أقل من 60 ثانية تكلف ~18 ألف دولار شهريًا في حركة مرور النسخ المتماثل. الحساب يبرر المعمارية تلقائيًا.

الجزء الأول — وثيقة استراتيجية التعافي

القسم 1: الأهداف وتصنيف الطبقات. كل خدمة في OrderFlow مُصنَّفة بطبقة، موقَّعة من نائب رئيس الهندسة والمدير المالي:

الطبقة 0 — الدفع والمدفوعات: RTO < 60 ثانية، RPO = 0 (كتابة أمامية متزامنة عبر Aurora Global DB). نشط-سلبي مع ترقية تلقائية.
الطبقة 1 — واجهة برمجة قراءة الطلبات، المصادقة، المخزون: RTO < 5 دقائق، RPO < 30 ثانية. Pilot-light مع نسخ غير متزامن؛ يُرقَّى عند تنبيه PagerDuty.
الطبقة 2 — التقارير، استيعاب التحليلات، Webhooks: RTO < 30 دقيقة، RPO < 5 دقائق. Warm standby؛ Kafka MirrorMaker 2 يجسر كلتا المنطقتين.
الطبقة 3 — الأدوات الداخلية، دفاتر علوم البيانات: RTO < 4 ساعات، RPO < ساعة. استعادة من نسخة S3 احتياطية عبر المناطق.

القسم 2: نظرة عامة على المعمارية. يعرض الرسم البياني أدناه طوبولوجيا المنطقتين مع مسارات تدفق البيانات وحدود الترقية.

طوبولوجيا DR ثنائية المنطقة لـ OrderFlow: النسخ المتزامن في Aurora يضمن RPO=0 للطبقة 0؛ Kafka MirrorMaker 2 غير المتزامن للطبقتين 1-2؛ S3 CRR للطبقة 3. Route 53 يقطع الـ DNS تلقائيًا عند فشل المنطقة الأساسية.

القسم 3: سيناريوهات الفشل والنطاق المُعلَن. تغطي خطة التعافي أربع فئات كوارث مُعلَنة:

فشل منطقة التوفر — يُعالَج بتعدد مناطق التوفر داخل us-east-1؛ لا يُطلق تجاوز فشل المنطقة. RTO: <2 دقيقة.
فشل المنطقة الكاملة — us-east-1 غير قابلة للوصول أو تنتهك SLO. يُطلق تجاوز الفشل الكامل إلى us-west-2. هذا ما يغطيه كتيب التشغيل.
تلف البيانات — تلف منطقي من نشر خاطئ أو خطأ في التطبيق. تجاوز فشل المنطقة لا يُفيد؛ الاستجابة هي الاستعادة في نقطة زمنية من نسخ Aurora الاحتياطية أو S3 المُؤرشَف بـ WAL.
هجوم فدية / حادث أمني — عزل؛ لا تتجاوز الفشل إلى نسخة مُصابة محتملة. استعادة من نسخة S3 احتياطية غير قابلة للتغيير مع Object Lock.

تلف البيانات هو السيناريو الأكثر خطورة. يُنسخ النسخ المتماثل كل كتابة تالفة إلى الاحتياطي بأمانة. بحلول وقت اكتشاف المشكلة، قد تكون النسخة مُصابة بالتساوي. مسار التعافي النظيف الوحيد هو الاستعادة في نقطة زمنية إلى لقطة مأخوذة قبل نافذة التلف — لهذا يجب اختبار PITR ربع سنوي، وليس سنويًا فقط.

الجزء الثاني — كتيب التشغيل: تجاوز فشل المنطقة الكاملة

كتيب التشغيل إجراء مُرقَّم وعلى مستوى الأوامر يُنفَّذ من قِبَل مهندس مناوب في الساعة الثالثة صباحًا تحت الضغط. كل خطوة يجب أن تكون لا لبس فيها، ومكتفية بذاتها، ومرتبطة بإجراء التراجع. فيما يلي كتيب تشغيل تجاوز فشل منطقة OrderFlow في هيكله التنفيذي الأساسي.

الشروط المسبقة (تحقق قبل إعلان التعافي):

تم إنشاء حادث PagerDuty والإقرار به؛ تم تعيين قائد الحادث.
تأكيد: us-east-1 غير قابلة للوصول أو تنتهك SLO لأكثر من 3 دقائق متتالية وفقًا لـ Alertmanager.
تأكيد: الفشل ليس تلفًا في البيانات (تحقق من سجلات أخطاء Aurora قبل المتابعة).
إبلاغ الراعي التنفيذي في #incidents-exec.

# ── الخطوة 1: ترقية Aurora Global DB الثانوي (الطبقة 0) ──────────────────────
# يفصل مجموعة الثانوي ويُرقّيها لكاتب مستقل.
# المدة المتوقعة: 60-90 ثانية.

aws rds failover-global-cluster \
  --global-cluster-identifier orderflow-global \
  --target-db-cluster-identifier \
    arn:aws:rds:us-west-2:123456789012:cluster:orderflow-west \
  --region us-west-2

# استطلاع حتى تصبح الحالة == "available"
watch -n 5 "aws rds describe-db-clusters \
  --db-cluster-identifier orderflow-west \
  --region us-west-2 \
  --query 'DBClusters[0].Status' --output text"

# ── الخطوة 2: تحديث Secret نقطة نهاية قاعدة البيانات ────────────────────────
aws secretsmanager update-secret \
  --secret-id orderflow/db/writer-endpoint \
  --secret-string '{"host":"orderflow-west.cluster-xyz.us-west-2.rds.amazonaws.com","port":5432}' \
  --region us-west-2

# ── الخطوة 3: توسيع مجموعة EKS الاحتياطية للسعة الإنتاجية الكاملة ─────────
export DR_CTX="arn:aws:eks:us-west-2:123456789012:cluster/orderflow-west"

kubectl --context $DR_CTX scale deployment \
  checkout-api order-read-api auth-service inventory-api payment-worker \
  --replicas=20 -n orderflow

kubectl --context $DR_CTX get pods -n orderflow -w

# ── الخطوة 4: التحقق من مزامنة ArgoCD على المجموعة الاحتياطية ───────────────
argocd context dr-west
argocd app sync orderflow-checkout --prune
argocd app sync orderflow-api --prune
argocd app wait orderflow-checkout orderflow-api --health --timeout 300

# ── الخطوة 5: تحويل Route 53 DNS (قد تكون الأتمتة قد فعلت ذلك بالفعل) ───────
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABC \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "api.orderflow.io",
        "Type": "A",
        "AliasTarget": {
          "HostedZoneId": "Z35SXDOTRQ7X7K",
          "DNSName": "orderflow-west-alb.us-west-2.elb.amazonaws.com",
          "EvaluateTargetHealth": true
        }
      }
    }]
  }'

# ── الخطوة 6: اختبار دخان الدفع ──────────────────────────────────────────────
curl -sf https://api.orderflow.io/health | jq .
# النتيجة المتوقعة: {"status":"ok","region":"us-west-2","db":"connected","kafka":"connected"}

إجراءات ما بعد التجاوز لا تقل أهمية عن التجاوز نفسه. بعد تأكيد الخطوات أعلاه:

إعلان اكتمال تجاوز الفشل في PagerDuty وSlack؛ تحديث صفحة الحالة.
إعادة ضبط إزاحات مجموعات المستهلكين في Kafka للخدمات التي لم تتمكن من الإفراغ بنظافة — تحقق من ضمانات معالجة ازدواجية (مفاتيح الاتساق) قبل استئناف المستهلكين.
تسخين مجموعة Redis: تُعاد عدادات تحديد المعدل إلى الصفر (مقبول)، لكن يجب إعادة ملء مفاتيح الجلسة. تحقق من أن خدمة المصادقة تتحمل فقدان الجلسة بسلاسة (إعادة تسجيل الدخول القسرية).
مراقبة إنتاجية الكتابة في مجموعة Aurora الاحتياطية وتأخر النسخ المتماثل لنسخها الجديدة للقراءة خلال أول 30 دقيقة.
جدولة نافذة الفشل العكسي — عادةً خارج ساعات الذروة، بعد 48 ساعة على الأقل من تأكيد استقرار استعادة المنطقة الأساسية.

اكتب كتيب التشغيل قبل أن تحتاجه، ثم أتمته قدر الإمكان. يمكن تغليف الخطوات 1-4 أعلاه كوثيقة AWS Systems Manager Automation واحدة وتشغيلها بنقرة واحدة أو webhook واحد من PagerDuty. المشغّل لا يزال يؤكد كل مرحلة، لكن الأوامر ومنطق الاستطلاع ومعالجة الأخطاء مُرمَّزة مسبقًا ومُصدَّرة — ليست مُكتَبة من الذاكرة في الساعة الثالثة صباحًا. هذا هو الفرق بين RTO بالدقائق الأربع وواحد بالأربعين دقيقة.

الجزء الثالث — قياس الجاهزية باستمرار

خطة التعافي التي تُتحقق منها في عمليات تدقيق سنوية فقط هي وثيقة مسؤولية، وليست أداة تشغيلية. اربط هذه التنبيهات الثلاثة بـ Alertmanager الموجود لديك. تجعل هذه التنبيهات الوضع الراهن للتعافي مرئيًا كل ساعة من كل يوم دون الحاجة لفحص بشري:

# prometheus/rules/dr-readiness.yml
groups:
  - name: dr_readiness
    rules:

      # تنبيه إذا تجاوز تأخير النسخ المتماثل في Aurora Global DB ميزانية RPO
      - alert: AuroraGlobalReplicationLag
        expr: aws_rds_aurora_global_db_replication_lag_milliseconds / 1000 > 10
        for: 2m
        labels:
          severity: critical
          tier: "0"
        annotations:
          summary: "تأخير Aurora Global DB {{ $value }} ث > حد RPO 10 ث"

      # تنبيه إذا تجاوز تأخير MirrorMaker 2 في Kafka حد RPO الطبقة 1 (30 ثانية)
      - alert: KafkaMirrorMaker2Lag
        expr: kafka_consumer_lag_sum{consumer_group="mm2-orderflow"} > 15000
        for: 5m
        labels:
          severity: warning
          tier: "1"
        annotations:
          summary: "تأخير MM2 {{ $value }} قد ينتهك حد RPO 30 ثانية"

      # تنبيه إذا لم يُتحقق من كتيب التشغيل منذ أكثر من 90 يومًا
      - alert: DRRunbookStaleness
        expr: time() - dr_runbook_last_validated_timestamp > 7776000
        for: 0m
        labels:
          severity: warning
        annotations:
          summary: "لم يُتحقق من كتيب تشغيل التعافي منذ 90 يومًا"

التنبيه الثالث — قِدَم كتيب التشغيل — يستحق اهتمامًا خاصًا. اربطه بمقياس تُحدّثه في Prometheus (عبر push gateway أو مُصدِّر اصطناعي) في كل مرة تُكمل فيها يوم ألعاب أو تمرين تعافٍ. إذا تجاوز المقياس 90 يومًا دون تحديث، يُطلق التنبيه ويُجبر على إعادة التحقق. هذا يمنع الانجراف الصامت حيث يصف كتيب التشغيل نظامًا لم يعد موجودًا.

قائمة التحقق من خطة التعافي المكتملة

قبل أن تُعلن خطة التعافي "منجزة"، تأكد من احتوائها على جميع ما يلي. هذه هي القائمة التي يستخدمها المهندس الرئيسي في شركة التقنية الكبرى خلال مراجعة التصميم:

RTO وRPO لكل طبقة، موقَّعان من أصحاب مصلحة الأعمال.
مخطط معماري يُظهر مسارات النسخ المتماثل، وتجاوز فشل DNS، وحدود الترقية.
نطاق صريح: أي سيناريوهات الفشل مُغطاة، وأيها خارج النطاق ولماذا.
كتيب تشغيل مُرقَّم بأوامر حقيقية، ومخرجات متوقعة، وإجراءات تراجع لكل خطوة.
مسار استعادة من تلف البيانات (إجراء PITR) منفصل عن كتيب تجاوز الفشل الإقليمي.
تنبيهات مراقبة مستمرة مرتبطة بعتبات RTO/RPO.
جدول يوم الألعاب (ربع سنوي كحد أدنى للطبقة 0)، مع تخزين النتائج ومقارنتها عبر الزمن.
قوالب اتصال مُحضَّرة مسبقًا (صفحة الحالة، Slack التنفيذي، البريد الإلكتروني للعملاء).
نموذج التكلفة: كم تكلف هذه المعمارية في الحالة المستقرة مقابل خلال DR المُعلَن؟
المالك ودورية المراجعة: من يُحدِّث هذه الوثيقة، ومتى تنتهي صلاحيتها؟

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