استعادة كوارث متعددة المناطق تتمرّن عليها فعلًا

استعادة الكوارث هي جزء المعمارية الذي أرجو أكثر من غيره أن يذهب عمله سدى — والجزء الذي أثق فيه بالرجاء أقل من أي شيء. على منصة serverless مؤسسية قدتُها — AWS Lambda وخطوط SQS فوق Aurora PostgreSQL، بأهداف استرجاع صارمة في العقد — شغّلنا طوكيو منطقةً أساسية وأوساكا احتياطية. ما يلي هو ما جعل ذلك حقيقيًا: ليس المخطط، بل القرارات حول الاستنساخ والكود والتمرين.

مجموعة وحدات واحدة، منطقتان

الخيار التأسيسي: أوساكا ليست مشروعًا ثانيًا. إنها ملف متغيرات ثانٍ.

عاشت كل البنية التحتية في وحدات Terraform (نحو أربع وعشرين وحدة عبر نحو عشر بيئات)، والمنطقتان تطبّقان الوحدات نفسها بمدخلات مختلفة. يبدو ذلك ممارسة قياسية — وهو كذلك — لكن الانضباط الذي يفرضه هو ميزة الـ DR الفعلية:

• لا انحراف، بحكم البناء. لا تستطيع المنطقة الاحتياطية أن تبتعد بصمت عن الأساسية، لأنه لا يوجد كود خاص بالاحتياطية تبتعد فيه. تغيير security group يدخل الوحدة وتستلمه المنطقتان في الـ apply التالي.
• منطقة الـ DR قابلة للبناء دائمًا. أخوف وضعيات الـ DR منطقة احتياطية جُمّعت يدويًا قبل سنتين. منطقتنا كان يمكن هدمها وإعادة تطبيقها، أي أننا عرفنا أن الوصفة كاملة — لا شيء يعيش فقط في تاريخ نقرات أحدهم في الـ console.
• ضبط التكلفة يبقى صادقًا. مدخلات على مستوى المنطقة تسمح للاحتياطية بالعمل رشيقة (نسخ أصغر، replicas أقل) مع بقائها متطابقة بنيويًا. المقايضة صريحة في ملف متغيرات بدل أن تكون ضمنية في قرارات تحجيم منسية.

ما الذي يُستنسخ، وبأي سرعة

ليست كل حالة تستحق معاملة الاسترجاع نفسها. صنّفنا الحالة في ثلاث درجات:

الدرجة	ماذا	الآلية	تحمّل الفقد
1	البيانات العلائقية (سجلّ الطلبات الرسمي)	استنساخ Aurora عبر المناطق	ثوانٍ من التأخر
2	الكائنات (ملفات مرفوعة، مخرجات مولّدة)	استنساخ S3 عبر المناطق	دقائق، لاإتزامنيًا
3	حالة قابلة للاشتقاق (caches، تكدّس الطوابير)	لا تُستنسخ — يعاد بناؤها	زمن إعادة البناء

الدرجة 3 هي محل الجدل. استنساخ محتوى الطوابير عبر المناطق معقّد ونادرًا ما يستحق: تكدّس SQS عملٌ في منتصف الطريق، ومراحل خطّنا كانت أصلًا عديمة التأثر بالتكرار (لا بد أن تكون — تسليم at-least-once يفرضه). عند التحويل تعيد الأنظمة الأصلية الإرسال أو يعيد المشغّلون الإطلاق، وتمتص اللاتأثرية التكرارات. كتبنا ذلك سياسةً كي لا يحرق أحدهم ربع سنة في بناء استنساخ طوابير لا نحتاجه.

أما الحوسبة فهي عائد الـ serverless: دوال Lambda وتعريفات الـ API مجرد كود وإعدادات، حاضرة في المنطقتين بفضل الوحدات المشتركة. لا أسطول دافئ يجب ترقيعه.

الـ runbook هو المنتَج

كان runbook التحويل وثيقة مرقّمة، وترتيبها حامل للوزن:

1. الإعلان — دورٌ مسمّى يقرر أن التحويل بدأ؛ الغموض هنا يكلف أكثر من أي خطوة تقنية.
2. تجميد الاستقبال — أوقف قبول عمل جديد في المسار الأساسي كي تتوقف الحالة عن الحركة.
3. الترقية — احتياطي Aurora يصبح قابلًا للكتابة في أوساكا.
4. إعادة التوجيه — DNS/التوجيه ينقل الحركة إلى حزمة أوساكا.
5. التصريف والمطابقة — أعد إطلاق أعمال الخط المقطوعة؛ اللاتأثرية تتكفل بالتداخل.
6. التحقق — تسلسل فحوص مؤتمت بالسكربتات، لا فحص بالمزاج.

درسان من التمرين:

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

المحيط غير اللامع

مراجعات الـ DR تهوس بقواعد البيانات وتقفز فوق التبعيات المملة التي تجعل المنطقة صالحة للاستخدام فعلًا: تخطيط VPC رباعي الطبقات، قواعد جدار الشبكة، IAM، مفاتيح KMS، المراقبة والإنذارات — كلها يجب أن توجد في أوساكا قبل اليوم السيئ. بعضها محدود النطاق بالمنطقة بطرق تفاجئ الناس، ولهذا بالضبط كانت كلها داخل الوحدات. وحزمة التدقيق كذلك: إذا سقطت المنطقة الأساسية، فلا يجوز أن يسقط معها أثر الأدلة (CloudTrail، وVPC Flow Logs، وجداول Athena فوقها).

الخلاصة التي أسلّمها لفريق يبدأ: عامل الـ DR كميزة منتَج لها مالك وميزانية وإيقاع اختبار. التقنية — استنساخ Aurora، وS3 CRR، وتناظر Terraform — طريق ممهّد. ما يفصل القدرة عن المخطط أن أحدًا تمرّن عليها، ووقّتها، وأصلح ما وجدته ساعة الإيقاف.