الخلاصة

  • أفادت DigitalOcean باحتمال وقوع أخطاء عند إنشاء عناقيد Managed Databases من Cloud Control Panel أو عبر طلبات API؛ ولم تصف الحادث على أنه توقف شامل لقواعد البيانات القائمة.
  • امتد السجل العام 6 ساعات و18 دقيقة و57.959 ثانية حتى المراقبة و9 ساعات و21 دقيقة و54.719 ثانية حتى الحل، بينما انتقل النطاق المعلن من Global ومناطق متعددة إلى NYC1 وNYC3.

لون المكوّن في صفحة الحالة لا يجيب دائماً عن السؤال الذي يهم فريق التشغيل. قد تكون المنطقة معروضة باللون الأخضر، ومع ذلك تفشل معاملة محددة يحتاجها العميل. هذا ما أظهره حادث “Managed Databases Creation” لدى DigitalOcean: النص أبلغ عن تعذر إنشاء عناقيد جديدة، في حين بقيت صفوف NYC1 وNYC3 النهائية من operational إلى operational.

بدأ الحادث في 23 أغسطس عند 05:11:37 بالتوقيت العالمي. قالت DigitalOcean إنها تحقق في مشكلة بمنتج Managed Database وإن المستخدمين قد يواجهون أخطاء أثناء إنشاء العناقيد عبر Cloud Control Panel وطلبات API. وانتقل مكوّن Managed Databases - Global من التشغيل الطبيعي إلى الأداء المتدهور.

عند 07:06:56، قالت الشركة إن مشكلة إنشاء العناقيد تؤثر في مناطق متعددة، وإن المهندسين ينفذون إجراء تخفيف لإعادة التزويد الطبيعي. لم تحدد الرسالة المناطق، ولم تذكر عدد العملاء أو نسبة الطلبات الفاشلة أو ما إذا كان المساران يتعطلان بالطريقة نفسها.

عند 11:30:34، أصبح الوصف الجغرافي أكثر تحديداً. أعلنت DigitalOcean تنفيذ الإصلاحات اللازمة التي أثرت في إنشاء عناقيد Managed Databases في NYC3 وNYC1. وقالت إن المستخدمين ينبغي أن يكونوا قادرين الآن على إنشاء عناقيد جديدة، ثم انتقلت إلى مراقبة الاستقرار.

عند 14:33:31، أعلنت الشركة حل الحادث. وذكرت أن المشكلة التي كانت تمنع إنشاء العناقيد في NYC3 وNYC1 انتهت، وأن العملاء يستطيعون الإنشاء بصورة طبيعية. بقي تصنيف الأثر minor وأصبحت الحالة النهائية resolved.

من البداية إلى المراقبة مضت 6 ساعات و18 دقيقة و57.959 ثانية. واستمرت المراقبة 3 ساعات ودقيقتين و56.760 ثانية. أما الفترة الكاملة في السجل حتى الحل فبلغت 9 ساعات و21 دقيقة و54.719 ثانية. هذه أزمنة بين تحديثات المزوّد، وليست دليلاً على تعطل مستمر ومتماثل لكل عميل.

النطاق الجغرافي لا يسمح باستنتاج واحد نهائي عن كامل الفترة. بدأ بمكوّن Global، ثم قالت DigitalOcean “مناطق متعددة”، وانتهت التحديثات بتسمية NYC1 وNYC3. لا يوضح السجل هل ضيّق التحقيق النطاق، أم تعافت مناطق أخرى أبكر، أم كان المكوّن العالمي مجرد عنوان واسع في البداية.

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

وفي المقابل، لا يوفر السجل شهادة بأن كل عنقود قائم كان سليماً بلا استثناء. الاستنتاج المسؤول أضيق: العملية التي سمّاها المزوّد علناً هي الإنشاء، ولا توجد بيانات منشورة توسع الأثر إلى جميع أحمال البيانات الحالية.

تشرح وثائق DigitalOcean المسار المعتاد للإنشاء. يستطيع العميل استخدام لوحة التحكم أو doctl أو واجهة API. وتعرض الوثائق نقطة POST /v2/databases، حيث يحدد الطلب المحرك والمنطقة والحجم ضمن المدخلات المطلوبة.

قبول الطلب ليس نهاية العملية. تصف وثائق عميل Python المورد الجديد بحالة أولية creating، ثم ينتقل إلى online عندما يصبح جاهزاً لاستقبال الحركة. وتشير وثائق PostgreSQL إلى أن التزويد يستغرق عادة خمس دقائق أو أكثر.

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

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

صفوف المكوّنات توضح حدود العرض الموجز. في التحديثين الأخيرين ظهرت NYC1 وNYC3 تشغيلية قبل التحديث وبعده، بينما وصف النص إصلاح معاملة الإنشاء ثم حلها. الحالة المجمعة للمنطقة لا تقيس بالضرورة توافر كل عملية في مستوى التحكم.

لم تنشر DigitalOcean سبباً جذرياً. لا يحدد السجل التحقق من الطلب، أو الجدولة، أو السعة، أو الشبكة، أو التخزين، أو محرك قاعدة البيانات، أو بوابة API، أو التنسيق الداخلي. وتشرح الوثائق العامة شكل الخدمة الطبيعي، لكنها لا تكشف موضع الفشل في هذا الحادث.

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

الحادث محلول في السجل العام، لكن درسه يتجاوز صفحة الحالة. الاعتماد السحابي يشمل القدرة على إنشاء الحالة التالية، لا مجرد استمرار الموارد الحالية. وعندما تتعطل تلك القدرة، تصبح معاملة مستوى التحكم نفسها جزءاً من استمرارية العمل.

المصادر