التوافر العالي والتعافي من الكوارث
مقدمة
تعطل النظام لدقيقة واحدة قد يعني خسائر بمئات الآلاف. التوافر العالي (High Availability) هو قدرة النظام على الاستمرار في تقديم الخدمات في مواجهة الأعطال Hardware، وأخطاء البرمجيات، ومشكلات الشبكة وغيرها من الحالات الشاذة. أمّا التعافي من الكوارث (Disaster Recovery) فهو قدرة النظام على استعادة الخدمة عند وقوع كوارث على نطاق أوسع.
ماذا ستتعلم من هذه المقالة؟
بعد إتمام هذا الفصل، ستكتسب:
- قياس التوافر: فهم معنى "عدد التسعات" وأوقات التوقف المقابلة
- التحويل عند الأعطال: إتقان بنى التوافر العالي مثل الرئيسي-الاحتياطي، والرئيسي-الرئيسي، والمتعدد النشط
- استراتيجيات التعافي من الكوارث: التعرف على مفهومي RPO و RTO وطرق التصميم
- اكتشاف الأعطال: فهم آليات اكتشاف الأعطال مثل نبضات القلب، والتحقيقات، وقواطع الدائرة
- الهندسة الفوضوية: التعرف على كيفية حقن الأعطال استباقيًا للتحقق من مرونة النظام
| الفصل | المحتوى | المفاهيم الأساسية |
|---|---|---|
| الفصل 1 | قياس التوافر | SLA، عدد التسعات، وقت التوقف |
| الفصل 2 | بنية التحويل عند الأعطال | الرئيسي-الاحتياطي، الرئيسي-الرئيسي، تعدد مناطق التوفر، النشط المتعدد جغرافيًا |
| الفصل 3 | تصميم التعافي من الكوارث | RPO، RTO، استراتيجيات النسخ الاحتياطي |
| الفصل 4 | اكتشاف الأعطال والاستعادة | نبضات القلب، قواطع الدائرة، التوسع والانكماش التلقائي |
| الفصل 5 | الهندسة الفوضوية | حقن الأعطال، التحقق من المرونة |
1. قياس التوافر: ماذا يعني "عدد التسعات"؟
يُقاس التوافر عادةً بعدد التسعات، وتكون صيغة الحساب:
التوافر = وقت التشغيل الطبيعي / إجمالي الوقت × 100%
على سبيل المثال، في شهر واحد (30 يومًا = 43200 دقيقة)، إذا توقف النظام لمدة 43 دقيقة، فإن التوافر يكون (43200 - 43) / 43200 ≈ 99.9%. كل تسعة إضافية تقلل وقت التوقف المسموح به بمقدار عشرة أضعاف، وترتفع صعوبة التنفيذ والتكلفة بشكل أُسيّ.
| مستوى التوافر | النسبة | التوقف المسموح شهريًا | التوقف المسموح سنويًا | المتطلبات النموذجية |
|---|---|---|---|---|
| تسعيتان | 99% | 7.3 ساعة | 3.65 يوم | الأدوات الداخلية |
| 3 تسعات | 99.9% | 43 دقيقة | 8.76 ساعة | أنظمة العمل العادية |
| 4 تسعات | 99.99% | 4.3 دقيقة | 52.6 دقيقة | التجارة الإلكترونية، SaaS |
| 5 تسعات | 99.999% | 26 ثانية | 5.26 دقيقة | التمويل، المدفوعات |
ما هو SLA؟
SLA (اتفاقية مستوى الخدمة) هي التزام رسمي بين مزود الخدمة والعميل. على سبيل المثال، تتعهد AWS S3 بتوافر 99.99%، وإذا لم تتحقق، تُعاد نسبة من المبلغ. SLA ليس مجرد مؤشر تقني، بل عقد تجاري — ومخالفة SLA تعني خسارة مالية.
الهوة من 3 تسعات إلى 4 تسعات
3 تسعات (99.9%) تعني إمكانية التوقف 43 دقيقة شهريًا — مشكلة واحدة في النشر واسترجاع يستهلكها بالكامل. 4 تسعات (99.99%) تعني التوقف 4 دقائق فقط شهريًا — وهذا يتطلب بنية توافر عالي كاملة تشمل التحويل التلقائي عند الأعطال، والنشر المتداول، وفحوصات الصحة.
2. بنية التحويل عند الأعطال
التحويل عند الأعطال (Failover) هو الآلية الأساسية للتوافر العالي: عند تعطل العقدة الرئيسية، يتم التبديل تلقائيًا إلى العقدة الاحتياطية للاستمرار في تقديم الخدمة.
نمط الرئيسي-الاحتياطي (Active-Standby)
بنية التوافر العالي الأكثر شيوعًا. تعالج العقدة الرئيسية جميع الطلبات، وتقوم العقدة الاحتياطية بمزامنة البيانات في الوقت الفعلي لكنها لا تعالج الطلبات. عند تعطل الرئيسية، تتولى الاحتياطية تلقائيًا.
الحالة الطبيعية:
العميل ← العقدة الرئيسية (معالجة الطلبات)
العقدة الاحتياطية (مزامنة البيانات، في وضع الاستعداد)
التحويل عند العطل:
العميل ← العقدة الاحتياطية (تتولى كعقدة رئيسية جديدة)
العقدة الرئيسية الأصلية (معطلة، بانتظار الإصلاح)المشكلة الرئيسية هي الانقسام الذهني (Split Brain): عند انقسام الشبكة، تعتقد كل من العقدتين الرئيسية والاحتياطية أن الأخرى معطلة، وتقدمان الخدمة في نفس الوقت، مما يؤدي إلى عدم تناسق البيانات. الحل هو إدخال عُقدة حكم (Quorum) — 3 عُقد على الأقل للتصويت على من هو الرئيسي.
تعدد مناطق التوفر (Multi-AZ)
نشر الخدمة في مراكز بيانات متعددة (مناطق توفر) في نفس المنطقة. انقطاع التيار أو الشبكة في مركز بيانات واحد لا يؤثر على الخدمة ككل. تكون مناطق التوفر لدى مزودي الخدمة السحابية متصلة عادةً بخطوط مخصصة منخفضة زمن الوصول (< 2 مللي ثانية).
النشط المتعدد جغرافيًا (Multi-Region Active-Active)
نشر نسخ خدمات كاملة في مدن مختلفة أو حتى دول مختلفة، بحيث يمكن لكل موقع معالجة الطلبات بشكل مستقل. هذا أعلى مستوى من بنية التوافر العالي، لكنه الأكثر تعقيدًا أيضًا — التحدي الأساسي هو مزامنة البيانات عبر المناطق الجغرافية من حيث زمن الوصول والتناسق.
| البنية | مستوى التوافر | التكلفة | التعقيد | السيناريو المناسب |
|---|---|---|---|---|
| جهاز واحد | 99%~99.9% | منخفضة | منخفض | التطوير والاختبار، الأدوات الداخلية |
| رئيسي-احتياطي | 99.9%~99.99% | متوسطة | متوسط | أنظمة العمل الصغيرة والمتوسطة |
| تعدد مناطق التوفر | 99.99% | عالية | عالٍ | التجارة الإلكترونية، منصات SaaS |
| النشط المتعدد جغرافيًا | 99.999% | عالية جدًا | عالٍ جدًا | التمويل، الإنترنت الكبير |
3. تصميم التعافي من الكوارث: RPO و RTO
يدور تصميم التعافي من الكوارث حول مؤشرين أساسيين:
| المؤشر | الاسم الكامل | المعنى | مثال |
|---|---|---|---|
| RPO | Recovery Point Objective | كمية البيانات المقبول فقدانها | RPO=0 تعني عدم فقدان أي بيانات |
| RTO | Recovery Time Objective | مدة التوقف المقبولة | RTO=5min تعني الاستعادة خلال 5 دقائق |
العلاقة بين استراتيجيات النسخ الاحتياطي و RPO
| طريقة النسخ الاحتياطي | RPO | التكلفة | الشرح |
|---|---|---|---|
| نسخ احتياطي كامل يومي | 24 ساعة | منخفضة | خسارة يوم من البيانات كحد أقصى |
| نسخ احتياطي تزايدي فوري | على مستوى الدقائق | متوسطة | مزامنة مستمرة عبر binlog/WAL |
| التكرار المتزامن | 0 | عالية | يجب أن تنتظر الكتابة تأكيد النسخة |
ليس كل البيانات تحتاج RPO=0
صورة الملف الشخصي للمستخدم يمكن إعادة رفعها إذا فُقدت (يكفي RPO=24h)، لكن سجلات المدفوعات لا يمكن فقدان أي منها (RPO=0). حدد استراتيجية النسخ الاحتياطي بناءً على القيمة التجارية للبيانات، وليس بنهج واحد للجميع.
4. اكتشاف الأعطال والاستعادة
4.1 آليات اكتشاف الأعطال
| الآلية | المبدأ | سرعة الاكتشاف | السيناريو المناسب |
|---|---|---|---|
| فحص نبضات القلب | إرسال حزم نبضات دوريةً، واعتبار العقدة معطلة عند انتهاء المهلة | على مستوى الثواني | اكتشاف بقاء العُقد |
| فحص الصحة | تحقيقات HTTP/TCP لفحص حالة الخدمة | على مستوى الثواني | فحص الخلفية لموازنات الحمل |
| تحقيقات العمل | محاكاة طلبات حقيقية لفحص منطق العمل | من ثوانٍ إلى دقائق | مراقبة التوافر من الطرف إلى الطرف |
كيف يعمل فحص نبضات القلب: ترسل العقدة A كل فترة زمنية محددة (مثل 5 ثوانٍ) إشارة "أنا على قيد الحياة" إلى جهة المراقبة. إذا لم تصل نبضات القلب لعدد N متتالي (مثل 3 مرات)، تُحكم على العقدة A بأنها معطلة. المعلمات الأساسية هي فترة نبضات القلب وعتبة المهلة — فترة قصيرة جدًا تزيد حمل الشبكة، وطويلة جدًا تؤخر اكتشاف العطل.
مستويات فحص الصحة الثلاثة:
- تحقيق البقاء (Liveness): هل العملية لا تزال قيد التشغيل؟ إن لم تكن، أعد تشغيلها
- تحقيق الجاهزية (Readiness): هل يمكن للخدمة قبول الطلبات؟ إن لم تستطع، أزِلها من موازن الحمل
- تحقيق البدء (Startup): هل اكتمل بدء تشغيل الخدمة؟ إن لم يكتمل، انتظر ولا تحكم عليها بالعطل بالخطأ
4.2 آليات الاستعادة التلقائية
| الآلية | الوصف | الأدوات النموذجية |
|---|---|---|
| إعادة التشغيل التلقائية | رفع العملية تلقائيًا بعد انهيارها | systemd، PM2، K8s |
| التوسع والانكماش التلقائي | زيادة النسخ تلقائيًا عند ارتفاع الحمل | K8s HPA، Auto Scaling من مزودي السحابة |
| قاطع الدائرة وتقليل الخدمة | الفشل السريع عند عطل في الخدمة المصبية، لمنع الأعطال المتسلسلة | Hystrix، Sentinel، Resilience4j |
| تحديد المعدل | رفض الطلبات التي تتجاوز السعة مباشرة | Nginx limit_req، تحديد المعدل على البوابة |
تفصيل نمط قاطع الدائرة (Circuit Breaker):
يستلهم قاطع الدائرة من المصهر الكهربائي — عندما يزيد التيار عن الحد ينقطع تلقائيًا، مما يحمي الدائرة الكاملة من الاحتراق. في الخدمات المصغرة، عندما تتعطل الخدمة المصبية، يُقطع قاطع الدائرة، مما يجعل الطلبات تفشل بسرعة بدلاً من الانتظار الأحمق حتى انتهاء المهلة.
حالات قاطع الدائرة الثلاث:
مغلق (طبيعي) ──→ معدل الفشل يتجاوز العتبة ──→ مفتوح (قاطع)
↑ │
│ انتظار فترة التبريد
│ ↓
└── طلب الفحص نجح ←── نصف مفتوح (اختبار)- الحالة المغلقة: تمرير الطلبات بشكل طبيعي، مع حساب معدل الفشل
- الحالة المفتوحة: جميع الطلبات تعود بخطأ مباشرة (فشل سريع)، دون استدعاء الخدمة المصبية
- الحالة نصف المفتوحة: بعد انتهاء فترة التبريد، يُسمح لعدد قليل من طلبات الفحص بالمرور. إذا نجحت، يعود للحالة المغلقة؛ إذا فشلت، يستمر في الحالة المفتوحة
تقليل الخدمة (Fallback) هو استراتيجية مرافقة لقاطع الدائرة: عند تفعيل القاطع، بدلاً من إرجاع خطأ مباشرة، يُعاد نتيجة "احتياطية". مثلًا إذا تعطلت خدمة التوصيات، تُعاد قائمة المنتجات الشائعة؛ إذا فشل تحميل صورة الملف الشخصي، تُعرض الصورة الافتراضية.
5. الهندسة الفوضوية: البحث الاستباقي عن المشكلات
الفكرة الأساسية للهندسة الفوضوية هي: بدلاً من انتظار الأعطال، اصنعها بنفسك، وتحقق من مرونة النظام في بيئة مُتحكم بها.
| الأداة | المُبتكر | القدرة الأساسية |
|---|---|---|
| Chaos Monkey | Netflix | إنهاء النسخ عشوائيًا في بيئة الإنتاج |
| Chaos Mesh | PingCAP | حقن الأعطال في بيئات K8s |
| Litmus | CNCF | إطار هندسة فوضوية سحابية أصلية |
| ChaosBlade | Alibaba | أداة حقن أعطال متعددة السيناريوهات |
خطوات تنفيذ الهندسة الفوضوية
- تحديد الحالة المستقرة: توضيح مؤشرات التشغيل الطبيعي (مثل زمن الوصول P99 < 200ms)
- طرح الفرضية: إذا تعطلت عقدة معينة، يجب أن يستعيد النظام نفسه تلقائيًا خلال 30 ثانية
- حقن العطل: صناعة أعطال ضمن نطاق مُتحكم فيه (أولًا في بيئة الاختبار، ثم في الإنتاج)
- مراقبة النتائج: هل استعاد النظام نفسه كما هو متوقع؟ هل حدثت أعطال متسلسلة؟
- إصلاح نقاط الضعف: تحسين البنية والعمليات بعد اكتشاف المشكلات
الخلاصة
التوافر العالي ليس ميزة، بل قدرة بنائية. يتطلب ضمانه في كل مرحلة من التصميم والتطوير والنشر والتشغيل.
نراجع النقاط الرئيسية في هذا الفصل:
- عدد التسعات: كل تسعة إضافية تقلل وقت التوقف بعشرة أضعاف، وتزداد التكلفة والتعقيد بشكل أُسيّ
- التحويل عند الأعطال: من الرئيسي-الاحتياطي إلى النشط المتعدد جغرافيًا، اختر البنية المناسبة لمتطلبات عملك
- RPO و RTO: صمم استراتيجيات النسخ الاحتياطي والاستعادة بناءً على قيمة البيانات وتحمل العمل
- الأتمتة: اكتشاف الأعطال، إعادة التشغيل التلقائية، قواطع الدائرة وتقليل الخدمة هي البنية التحتية للتوافر العالي
- الهندسة الفوضوية: حقن الأعطال استباقيًا للتحقق من مرونة النظام في بيئة مُتحكم بها
قراءات إضافية
- Site Reliability Engineering - كتاب Google SRE الكلاسيكي
- Chaos Monkey - أداة الهندسة الفوضوية من Netflix
- Release It! - أنماط تصميم بيئة الإنتاج
- Chaos Mesh - منصة الهندسة الفوضوية لـ K8s