حذف 300 جيجابايت خلال ثوانٍ: ماذا نتعلم من حادثة قاعدة بيانات GitLab؟

نُفذ أمر في نافذة الطرفية الخطأ. وخلال ثوانٍ، اختفى نحو 300 جيجابايت من خادم PostgreSQL الأساسي لخدمة GitLab.com.

قد تبدو القصة كأنها خطأ ارتكبه مهندس واحد. لكنها لم تكن كذلك. الأمر الخاطئ بدأ الحادث، لكن النسخ الاحتياطية المعطلة، وضعف المراقبة، وهشاشة إجراءات التكرار، وعدم اختبار خطة الاستعادة حولته إلى توقف استمر نحو 18 ساعة.

وقعت الحادثة في 31 يناير 2017. وثقت GitLab ما حدث علناً، ونشرت تقريراً تفصيلياً، وبثت عملية الاستعادة مباشرة.[1][2] وأعاد مقطع على Instagram القصة إلى التداول مؤخراً.[6]

الدرس ما زال صالحاً: مهمة النسخ الاحتياطي التي لم تنجح في اختبار استعادة فعلي ليست ضماناً، بل افتراضاً.

ماذا حدث؟

كانت GitLab.com تعتمد على خادم PostgreSQL أساسي ونسخة ثانوية. أدى ارتفاع الحمل على قاعدة البيانات إلى تأخر النسخة الثانوية. حذف الخادم الأساسي أجزاء WAL قبل أن تتمكن النسخة الثانوية من استلامها، ولم يكن لدى GitLab أرشيف WAL يمكن استخدامه لاستكمال السجل المفقود.[2]

بدأ الفريق إعادة بناء النسخة الثانوية باستخدام `pg_basebackup`. بدت الأداة وكأنها تنتظر من دون مخرجات مفيدة، بينما لم تكن إجراءات الاستعادة مؤتمتة أو موثقة بصورة كافية. أثناء تكرار محاولات الإصلاح، أراد أحد المهندسين مسح مجلد بيانات PostgreSQL على الخادم الثانوي، لكنه نفذ الأمر على الخادم الأساسي.[2]

أوقف المهندس الأمر بعد ثانية أو ثانيتين، لكن الضرر وقع بالفعل. ذكر تقرير GitLab الأولي أن المتبقي كان نحو 4.5 جيجابايت فقط من أصل قرابة 300 جيجابايت من بيانات الإنتاج.[1]

لماذا فشلت وسائل الحماية؟

كان حذف قاعدة البيانات أول فشل فقط. كشفت الاستعادة عن مشكلات أخرى:

1. كانت مهمة `pg_dump` المجدولة تستخدم أدوات PostgreSQL 9.2 مع قاعدة بيانات تعمل بالإصدار 9.6، ولذلك فشلت عملية النسخ.

2. أرسلت المهمة إشعارات الخطأ بالبريد الإلكتروني، لكن الخادم المستقبل رفضها لأنها لم تكن موقعة باستخدام DMARC.

3. كان مخزن النسخ الاحتياطية على S3 فارغاً.

4. كانت لقطات أقراص Azure مفعلة لخوادم أخرى، لكنها لم تكن مفعلة لخوادم قواعد البيانات.

5. لم تكن هناك جهة مسؤولة عن اختبار الاستعادة دورياً، لذلك اكتشف الفريق أن مسار التعافي معطل أثناء الأزمة.[2]

استعادت GitLab في النهاية نسخة من بيئة الاختبار أُنشئت قبل الحادث بنحو ست ساعات. استغرق نقل البيانات من التخزين البطيء إلى الإنتاج قرابة 18 ساعة. وقدرت الشركة أنها فقدت نحو 5,000 مشروع و5,000 تعليق و700 حساب مستخدم أُنشئت خلال الفترة المفقودة. لم تُحذف مستودعات Git أو صفحات Wiki لأنها كانت محفوظة بصورة منفصلة.[2]

ما الذي كان يجب فعله؟

كان يمكن لتصميم أكثر أماناً أن يقلل فقدان البيانات وزمن الاستعادة:

1. أرشفة WAL باستمرار خارج خوادم قاعدة البيانات. يتيح ذلك الاستعادة بين النسخ الكاملة والوصول إلى نقطة زمنية محددة.

2. حفظ النسخ الاحتياطية في نطاق فشل منفصل. يجب ألا تسمح بيانات الاعتماد نفسها بحذف الإنتاج ومستودع النسخ الاحتياطية من الجلسة نفسها.

3. اختبار الاستعادة آلياً. ينبغي لمهمة مجدولة استعادة النسخة في بيئة معزولة، وتشغيل PostgreSQL، والتأكد من أن قاعدة البيانات قابلة للاستخدام.

4. مراقبة جاهزية الاستعادة بدلاً من مراقبة تشغيل المهمة فقط. يجب التنبيه عند تقادم آخر نسخة متحقق منها، أو وجود فجوات في WAL، أو فشل فحص السلامة، أو عدم تنفيذ اختبار الاستعادة.

5. وضع ضوابط على العمليات الخطرة في الإنتاج. استخدم مؤشرات واضحة جداً لبيئة الإنتاج، وملفات وصول منفصلة، وموافقة زميل قبل الأوامر التدميرية، وأدلة تشغيل مجربة تقلل الاجتهاد أثناء الحوادث.

التكرار مفيد لاستمرارية الخدمة، لكنه ليس نسخة احتياطية مستقلة. قد تتعطل النسخة الثانوية أو تتلف أو تُمسح عمداً أثناء الصيانة، وهذا ما حدث في هذه الواقعة.

دور أداة CYBERTEC pg_hardstorage

`pg_hardstorage` من CYBERTEC هي أداة مفتوحة المصدر للنسخ الاحتياطي والاستعادة في PostgreSQL للإصدارات من 15 إلى 18. تعمل كملف تنفيذي مستقل على خادم النسخ الاحتياطي، وتتصل عبر بروتوكول التكرار في PostgreSQL، وتنشئ نسخاً أساسية، وتبث WAL باستمرار. ولا تحتاج إلى تثبيت مكون داخل خادم قاعدة البيانات.[3][4]

يعالج هذا التصميم عدداً من نقاط الضعف التي ظهرت في حادثة GitLab:

• يتيح بث WAL المستمر الاستعادة إلى وقت محدد أو LSN أو نقطة استعادة مسماة.

• يمكن حفظ النسخ على خادم منفصل أو في إحدى وجهات التخزين البعيدة المدعومة.

• كل نسخة مبنية على التخزين الموجه بالمحتوى مستقلة بذاتها، ولذلك لا يؤدي حذف نسخة قديمة إلى تعطيل نسخة أحدث.

• يفحص الأمر `pg_hardstorage verify` سلامة النسخة، بينما يثبت اختبار الاستعادة الفعلي أن PostgreSQL يستطيع العمل بالبيانات المستعادة.

• تفحص اختبارات ما قبل التشغيل إعدادات التكرار، ويمكن إرسال المقاييس إلى Prometheus وGrafana للمراقبة.[3][4]

لن تمنع `pg_hardstorage` المهندس من حذف المجلد الخطأ. لا توجد أداة نسخ احتياطي تجعل كل أمر تدميري مستحيلاً. لكن إذا وقعت حادثة مشابهة اليوم على إصدار PostgreSQL مدعوم، فإن مستودع `pg_hardstorage` المعزول والمراقب بصورة صحيحة يمكن أن يحتفظ بنسخة الأساس وWAL اللازمين للاستعادة إلى لحظة تسبق الحذف مباشرة.[4]

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

كيف تعزز PGEE منصة PostgreSQL بالكامل؟

تعالج `pg_hardstorage` جانب النسخ الاحتياطي والاستعادة، بينما يعزز إصدار CYBERTEC PostgreSQL للمؤسسات، أو PGEE، المنصة المحيطة به. تشمل ميزات الأمان تشفير البيانات الشفاف TDE، وإخفاء البيانات والتعتيم، وتشفير شيفرة PL/pgSQL، والصلاحيات المرتبطة بالوقت. وتضيف PGEE إعدادات افتراضية محسنة وتسريعاً لأجهزة Intel، إلى جانب أدوات تشغيل مثل PGWatch، وتتبع خطط التنفيذ النشطة، والفحص الآلي للحوادث، واقتراح الفهارس عبر `pg_qualstats`، والجدولة المدمجة، وإعادة تنظيم التخزين آلياً.[7]

تعالج هذه الميزات جوانب مختلفة من المخاطر. يحمي TDE ملفات قاعدة البيانات المخزنة، ويقلل إخفاء البيانات من التعرض خارج الإنتاج، وتساعد المراقبة الفرق على اكتشاف المشكلات مبكراً. ويمكن للتوافر العالي عبر Patroni إبقاء الخدمة عاملة عند تعطل إحدى العقد. لكن أياً من هذه المزايا لا يغني عن نسخة احتياطية مستقلة مع اختبار فعلي للاستعادة إلى نقطة زمنية محددة.

خطط دعم PGEE

أدوات الاستعادة مهمة، لكن الحوادث الكبيرة تحتاج أيضاً إلى خبراء يستجيبون خلال زمن متفق عليه. تقدم Worlber ثلاثة مستويات لدعم PGEE، ويشمل الاشتراك ترخيص البرنامج والتحديثات والدعم وفق الفئة المختارة، بينما تُحسب تكاليف البنية التحتية بصورة منفصلة.[7][8]

• القياسية: PGEE: اختياري; التوفر: 8x5; زمن استجابة SLA: ساعة واحدة; أهم خدمات الدعم: إصلاحات PostgreSQL، ودعم سبعة إصدارات تاريخية، وتشغيل PostgreSQL في Docker

• الاحترافية: PGEE: اختياري; التوفر: 8x5; زمن استجابة SLA: 45 دقيقة; أهم خدمات الدعم: مزايا الخطة القياسية، إضافة إلى نظام التذاكر ودعم الاستعادة الطارئة

• المؤسسات: PGEE: مشمول; التوفر: 24x7; زمن استجابة SLA: 30 دقيقة; أهم خدمات الدعم: دعم غير محدود للإصدارات والتذاكر، والاستعادة الطارئة، والدخول عن بعد، وضبط الاستعلامات البطيئة، ومدير حساب مخصص

بالنسبة إلى منشأة يتسبب توقف قاعدة بياناتها في توقف الإيرادات أو الخدمات العامة، فإن خطة المؤسسات هي الأقرب لطبيعة هذه الحادثة: توفر دعماً على مدار الساعة، وزمن استجابة مستهدفاً قدره 30 دقيقة، ومساعدة في الاستعادة الطارئة، وتشخيصاً مباشراً عن بعد.[7][8]

معيار عملي لقياس جاهزية الاستعادة

يجب أن تتمكن أي خدمة PostgreSQL في الإنتاج من الإجابة عن خمسة أسئلة في أي وقت:

1. متى اكتملت آخر نسخة أساسية بنجاح؟

2. هل حماية WAL مستمرة، وهل توجد أي فجوات؟

3. متى نجح آخر اختبار استعادة آلي؟

4. ما مقدار البيانات الذي يمكن للمنشأة تحمّل فقدانه، وما الزمن المطلوب لإعادة الخدمة؟

5. هل يستطيع حساب إنتاج مخترق حذف النسخ الاحتياطية أيضاً؟

إذا كانت إحدى الإجابات مجهولة، فخطة التعافي غير مكتملة.

صمم النظام ليستعيد الخدمة، لا ليفترض مشغلين بلا أخطاء

لم تكن أقوى خلاصة في تقرير GitLab هي مطالبة المهندسين بعدم ارتكاب الأخطاء. أوصى التقرير ببناء بيئة تسمح بوقوع الخطأ من دون أن يتحول إلى ضرر طويل أو غير قابل للإصلاح.[2]

توفر Worlber بنية PostgreSQL اعتماداً على PostgreSQL Community وCYBERTEC PGEE، مع التوافر العالي عبر Patroni، وتشفير البيانات الشفاف TDE، وإمكانات النسخ الاحتياطي المؤتمت.[5] وبالنسبة للمنشآت في المملكة العربية السعودية، تبدأ الخطوة العملية التالية بمراجعة جاهزية التعافي وفق أهداف قابلة للقياس لنقطة الاستعادة وزمن الاستعادة.

المصادر

• [[1] GitLab.com database incident](https://about.gitlab.com/blog/2017/02/01/gitlab-dot-com-database-incident)

• [[2] Postmortem of database outage of January 31](https://about.gitlab.com/blog/2017/02/10/postmortem-of-database-outage-of-january-31)

• [[3] pg_hardstorage product page](https://www.cybertec-postgresql.com/en/products/pg-hardstorage)

• [[4] pg_hardstorage repository and documentation](https://github.com/cybertec-postgresql/pg_hardstorage)

• [[5] Worlber PostgreSQL services](https://worlber.sa/en)

• [[6] Instagram reel that inspired this article](https://www.instagram.com/reel/DeKKf55Dekh)

• [[7] Worlber CYBERTEC PGEE features and support packages](https://worlber.sa/en/services/cybertec-postgresql)

• [[8] Worlber PGEE pricing and support FAQ](https://worlber.sa/en/pricing)

اجعل خطة استعادة PostgreSQL قابلة للاختبار

تساعد Worlber المنشآت السعودية على نشر PostgreSQL Community وCYBERTEC PGEE مع التوافر العالي عبر Patroni، والتشفير، والمراقبة، والنسخ الاحتياطي المؤتمت، وخطط دعم مرتبطة بأهداف التعافي.

تحدث مع Worlber عن جاهزية استعادة PostgreSQL