الخلاصة

  • بدأت حادثة حرجة في MKC1 عند 11:10 بالتوقيت العالمي يوم 19 أغسطس، وطالت عدة رفوف وعُقد مع اضطرابات محتملة في GPU وDOKS وإدارة العناقيد.
  • عند 19:34 صنفت DigitalOcean الحادثة بأنها محلولة بعد تعافي مستوى التحكم والخدمات العامة، لكنها قالت في التحديث نفسه إن GPU Droplets ما زالت متأثرة وإن استعادة جميع العُقد مستمرة.

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

ظهر التنبيه الأول عند 11:10:06 بالتوقيت العالمي. قالت الشركة إن مشكلة تؤثر في عدة رفوف وعُقد داخل MKC1 قد تعطل أحمال GPU وتجعل عُقد العمل في DigitalOcean Kubernetes، أو DOKS، تدخل حالة NotReady. وصُنفت الحادثة ذات أثر حرج.

عند 12:22 أعلنت DigitalOcean أنها حددت السبب الجذري وبدأت خطوات المعالجة، من دون أن تكشف ماهية السبب. وشمل نطاق الأثر المذكور أحمال GPU وخدمة Serverless Inference وعُقد DOKS، إضافة إلى احتمال تعذر الوصول إلى نقاط API الخاصة بـKubernetes أو تنفيذ عمليات إدارة بعض العناقيد. وعند 15:28 كانت الفرق لا تزال تعيد الاتصال والعُقد إلى الخدمة، من دون أرقام للرفوف أو العُقد أو العناقيد أو العملاء.

جاء الفصل الأوضح عند 18:59. قالت DigitalOcean إن مستوى التحكم الإقليمي بات سليماً بالكامل. وعملت CPU Droplets وManaged Databases وLoad Balancers وBlock Storage وSpaces بصورة طبيعية. كما عادت عمليات إنشاء Droplets وتغيير أحجامها وإدارتها، وأصبح الوصول إلى مستويات التحكم في DOKS ممكناً. هذه دلائل حقيقية على تعافي البنية المشتركة.

لكن النصف الآخر من التحديث سجل واقعاً مختلفاً. بقيت GPU Droplets في MKC1 غير متصلة أو متعذرة الوصول. وكان من الممكن أن تظل عُقد GPU العاملة في DOKS بحالة NotReady، وأن تبقى نقاط الاستدلال المعتمدة على GPU غير متاحة. قالت الشركة إنها ستراقب مستوى التحكم لفترة قصيرة ثم تغلق الحادثة الإقليمية، فيما تنتقل تحديثات عملاء GPU إلى رسائل مخصصة عبر Slack والبريد الإلكتروني بدلاً من صفحة الحالة.

تم الإغلاق عند 19:34:54. أعاد البيان الأخير تأكيد سلامة مستوى التحكم وخدمات CPU والمنصة، لكنه أضاف أن GPU Droplets لا تزال متأثرة وأن الفرق تعمل على استعادة جميع العُقد. لذلك لا تمثل الساعات الثماني والدقائق الأربع والعشرون والثواني الثماني والأربعون انقطاعاً موحداً لكل المنتجات. إنها مدة سجل عام تغير نطاقه مع تعافي طبقات مختلفة.

يزيد توقيت إطلاق الإقليم من أهميته. فقد افتتحت DigitalOcean MKC1 في 4 أغسطس، أي قبل الحادثة بخمسة عشر يوماً. وصفت الإعلان مركز البيانات بأنه مبرد بالكامل بالسائل ويشغل وحدات NVIDIA B300، مع خدمات حوسبة وDOKS وقواعد بيانات وتخزين وشبكات وApp Platform وFunctions منذ الإطلاق. لا تربط الأدلة الحادثة بالتبريد أو طراز GPU، ولا تبرر وصف الإقليم الجديد بأنه غير ناضج. لكنها تجعل الواقعة اختباراً مبكراً وعلنياً لعملية الاستعادة في إقليم يبيع قدرة GPU كعنصر أساسي.

يوضح DOKS الفرق بين طبقتي التحكم والتنفيذ. تدير DigitalOcean مستوى تحكم Kubernetes، بينما تعمل تطبيقات العميل على عُقد العمل. عودة API تعيد القدرة على رؤية العنقود وإدارته، لكنها لا تعيد المسرّع الموجود على عقدة ما زالت NotReady. وتوثق الشركة خاصية لاستبدال عُقد العمل تلقائياً، إلا أنها معاينة عامة اختيارية وتتطلب شروطاً وفترات سماح وإجراءات وحدوداً للمعالجات المتزامنة. لا يثبت سجل الحادثة أن العملاء المتأثرين فعّلوها أو أنها أصلحت هذه العُقد.

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

لهذا يحتاج المشغل إلى قراءة عدة مقاييس: هل مستوى التحكم قابل للوصول، وهل عُقد العمل في Ready، وهل يمكن تخصيص المسرّعات، وهل نقاط الاستدلال تستجيب، وهل يحقق التطبيق هدفه؟ في 19 أغسطس عادت هذه المقاييس في أوقات مختلفة. أُغلقت الحادثة العامة بعدما استقرت الطبقات المشتركة، فيما بقيت موارد GPU النادرة في مسار استعادة خاص بالعملاء.

المصادر