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

أساسيات التعافي من الكوارث: RTO و RPO

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

أساسيات التعافي من الكوارث: RTO و RPO

كل نظام إنتاجي سيتعرض للفشل في نقطة ما. السؤال ليس هل سيحدث ذلك — بل كم من الوقت يستطيع العمل أن يتحمل هذا الفشل، وكم من البيانات يمكنه تحمل خسارتها. هدف وقت التعافي (RTO) وهدف نقطة التعافي (RPO) هما الرقمان اللذان يُشكّلان أساس كل نقاش حول التعافي من الكوارث. قبل أن تُصمم نشرًا متعدد المناطق على Kubernetes أو مجموعة Aurora متعددة المدرب الرئيسي، تحتاج إلى الحصول على هذين الرقمين موقَّعَين من أصحاب المصلحة — لأنهما يحددان التكلفة أكثر من أي قرار معماري آخر ستتخذه.

ما الذي تعنيه RTO و RPO فعليًا

RTO (هدف وقت التعافي) هو الحد الأقصى المقبول للمدة بين حدث الكارثة واستعادة الخدمة للمستخدمين. يجيب على السؤال: "كم من الوقت يمكننا أن نكون خارج الخدمة؟" هدف RTO مدته أربع ساعات يعني أن الخدمة يجب أن تكون تشغيلية ومجتازة لفحوصات الصحة في غضون أربع ساعات من إعلان الحادث — وليس أربع ساعات من لحظة اكتشاف أحدهم للمشكلة.

RPO (هدف نقطة التعافي) هو الحد الأقصى المقبول لعمر البيانات التي يجب استردادها بعد الكارثة. يجيب على السؤال: "كم من البيانات يمكننا خسارتها؟" هدف RPO مدته ساعة واحدة يعني أنه بعد التعافي، قد يكون حالة النظام متأخرة بحد أقصى ساعة واحدة عن آخر نقطة تحقق متسقة قبل الفشل. المعاملات المكتوبة في الـ 59 دقيقة الأخيرة قبل الحدث قد تكون ببساطة مفقودة.

RTO يقيس الوقت؛ RPO يقيس البيانات. إنهما محوران مستقلان. قد يتطلب نظام التداول المالي RPO يقترب من الصفر (لا صفقات مفقودة) لكنه يتحمل RTO مدته 30 دقيقة. أما خط أنابيب التحليلات الدُفعية الليلية فقد يقبل RPO لـ 24 ساعة لكنه يحتاج فقط ساعة من RTO، لأن إعادة تشغيل يوم كامل من المهام مكلف وليس خطيرًا.

طيف التكاليف

يوجد كلا الهدفين على طيف يمتد من "الاحتياطي البارد" (رخيص، بطيء) إلى "الاحتياطي الساخن" (مكلف، فوري). يعرض الرسم البياني أدناه استراتيجيات التعافي الأربع الأساسية مقابل نطاقات RTO و RPO الخاصة بها.

الاستراتيجيات الأربع الأساسية للتعافي من الكوارث مرسومة مقابل التكلفة والتعقيد (محور رأسي) وسرعة التعافي (محور أفقي).

اشتقاق أهداف واقعية

إن RTO و RPO هما قرارات تجارية مُخفَّية في أرقام هندسية. دور مهندس SRE أو مهندس المنصات هو ترجمة تأثير الأعمال إلى تكلفة، ثم السماح لأصحاب المصلحة بالاختيار. تتكون عملية الاشتقاق القياسية من ثلاث خطوات:

قيّم تكلفة وقت التوقف. الإيرادات المفقودة في الدقيقة، وبنود عقوبات SLA، وتكاليف ارتفاع طلبات الدعم، والضرر بالسمعة. معالج المدفوعات الذي يخسر 50,000 دولار في الدقيقة سيموّل بسعادة معمارية نشطة-نشطة.
قيّم تكلفة فقدان البيانات. هل يمكن إعادة تشغيل المعاملات المفقودة من أحداث المصادر الأعلى؟ هل توجد متطلبات تنظيمية (PCI-DSS، HIPAA، SOX) تفرض حدًا أقصى لـ RPO بموجب القانون؟
عيّن متطلبات الأعمال لمستويات التعافي. عبّر عن كل هدف كقدرة بنية تحتية ملموسة، ثم سعّره.

اختبر دائمًا أرقامك مقابل ميزانية الأخطاء الفعلية. إذا كان هدف SLO هو 99.9% من وقت التشغيل (43 دقيقة شهريًا كميزانية خطأ) وهدف RTO هو 4 ساعات، فبإمكانك تحمل حادث واحد فقط كل 6 أشهر دون حرق كامل الميزانية. إذا كان هدف SLO هو 99.99% (4.3 دقائق شهريًا)، فإن RTO لمدة 4 ساعات غير متوافق رياضيًا — تحتاج إلى RTO أقل من 4 دقائق.

قياس RTO و RPO الحاليين

قبل تصميم استراتيجية تعافٍ جديدة، قس مكانك الفعلي. تتمثل الطريقتان القياسيتان في تمرين التعافي (يُغطى في الدرس الثامن) ومراقبة تأخير النسخ المتماثل باستمرار. فيما يلي كيفية كشف تأخير النسخ المتماثل في Postgres كمقياس لـ Prometheus والتنبيه عند انتهاك ميزانية RPO:

-- نفّذ على الخادم الأساسي PRIMARY. يُعيد التأخير بالثواني لكل نسخة احتياطية.
SELECT
    application_name,
    state,
    EXTRACT(EPOCH FROM (now() - pg_last_xact_replay_timestamp())) AS lag_seconds,
    sent_lsn,
    replay_lsn,
    (sent_lsn - replay_lsn) AS byte_lag
FROM pg_stat_replication;

غلّف هذا الاستعلام في مُصدِّر Prometheus مخصص (أو استخدم postgres_exporter مع ملف استعلام مخصص) واضبط قاعدة تنبيه. إذا كان RPO هو 5 دقائق، يُطلق التنبيه قبل وقت كافٍ من الخرق:

# prometheus/rules/dr.yml
groups:
  - name: disaster_recovery
    rules:
      - alert: ReplicationLagExceedsRPO
        expr: pg_replication_lag_seconds > 240   # تحذير 4 دقائق قبل RPO بـ 5 دقائق
        for: 1m
        labels:
          severity: critical
          runbook: https://wiki.internal/runbooks/pg-replication-lag
        annotations:
          summary: "تأخير النسخ المتماثل {{ $value }}ث يتجاوز حد RPO البالغ 4 دقائق"
          description: |
            النسخة الاحتياطية {{ $labels.application_name }} متأخرة {{ $value }} ثانية عن الخادم الأساسي.
            ميزانية RPO هي 300 ثانية. تحقق من انقطاع الشبكة أو تشبع I/O في النسخة الاحتياطية.

تتآكل أهداف التعافي بصمت. نظام بدأ بـ RPO مدته 15 دقيقة يمكن أن يتحول إلى RPO فعلي لمدة 3 ساعات خلال 18 شهرًا بينما يزداد حجم البيانات ويتراكم تأخير النسخ المتماثل — دون أن يحدّث أحد خطة التعافي. جدوّل مراجعة ربع سنوية لمقاييس التعافي بنفس الطريقة التي تجدول بها مراجعات السعة. عامل "RTO المقاس" و"RPO المقاس" كـ SLIs: تتبعهما في لوحات التحكم وأنشئ تنبيهًا عند اقترابهما من 80% من الحد المتعاقد عليه.

RTO مقابل RPO في Kubernetes والأحمال عديمة الحالة

بالنسبة للخدمات عديمة الحالة التي تعمل على Kubernetes، يتحكم في RTO عادةً وقت جدولة Pod بالإضافة إلى تقارب مسبار الاستعداد — غالبًا 30 إلى 90 ثانية في مجموعة مُحسَّنة جيدًا. النقاش الأدق يتعلق بالأحمال ذات الحالة: قواعد البيانات، إزاحات طوابير الرسائل، ذواكر التخزين المؤقت الموزعة. هنا تتسبب انتهاكات RPO في أضرار فعلية.

خطأ شائع هو افتراض أن "لدينا منطقة احتياطية في us-west-2" يعني وجود RTO محدد. هذا غير صحيح — إلا إذا كان لديك منطق تجاوز فشل آلي، وقيم TTL لـ DNS مُسخَّنة مسبقًا، وبرامج نصية لترقية قاعدة البيانات، وتم توقيت التسلسل بأكمله تحت الحمل في تمرين مُحاكاة. خطة التعافي غير المختبرة لها RTO مجهول. عاملها على أنها لانهائية حتى يُثبَت العكس.

المستويات الأربعة: تعيين الطبقات لأنظمة حقيقية

على نطاق شركات التقنية الكبرى، تُصنَّف الخدمات حسب الأهمية الحرجة، ولكل مستوى عقد RTO/RPO منشور يُطبَّق على مستوى المنصة:

المستوى 0 (حرج للإيرادات): نشط-نشط متعدد المناطق، RPO = 0 (نسخ متزامن)، RTO < 30 ثانية. أمثلة: الدفع، المصادقة. التكلفة: 3 إلى 5 أضعاف البنية التحتية لمنطقة واحدة.
المستوى 1 (يواجه العملاء، غير مُعيق): Pilot Light، نسخ غير متزامن، RPO < 5 دقائق، RTO < 15 دقيقة. أمثلة: البحث، التوصيات، قراءات الملف الشخصي.
المستوى 2 (داخلي / مقبول في وضع تراجع الأداء): Warm Standby، RPO < ساعة، RTO < ساعتين. أمثلة: استيعاب التحليلات، لوحات التحكم الداخلية.
المستوى 3 (دُفعي / غير حرج): Cold Standby أو استعادة من نسخة احتياطية، RPO < 24 ساعة، RTO < 8 ساعات. أمثلة: التقارير الليلية، دفاتر علوم البيانات.

تبني الدروس المتبقية في هذا الدرس التعليمي كل طبقة: معمارية النسخ الاحتياطي، والنسخ المتماثل عبر المناطق، وآليات تجاوز الفشل، والتعافي المدفوع بـ GitOps، واختبار يوم الألعاب. كل قرار يعود إلى RTO و RPO اللذين حددتهما هنا. احصل على هذين الرقمين بشكل خاطئ — أو اتركهما غير محددين — وستتحول كل المقايضة اللاحقة إلى تخمينات.