أصدرت OpenAI مؤخرًا تقريرًا مفصلاً عن انقطاع خدمات ChatGPT وSora لمدة 4 ساعات و10 دقائق في 11 ديسمبر. أثرت هذه الحادثة على العديد من المستخدمين وجذبت اهتمامًا واسع النطاق. ويشرح التقرير بالتفصيل سبب العطل، والصعوبات التي واجهها المهندسون، والعملية النهائية لاستعادة الخدمة، مما يوفر دروسًا قيمة للفرق الفنية الأخرى. ويشرح التقرير بوضوح السبب الجذري للفشل، بالإضافة إلى سلسلة من إجراءات الطوارئ التي اتخذها المهندسون عند مواجهة حادث تحطم طائرة تحكم، وهو ما يعكس قدرة OpenAI على الاستجابة لحالات الطوارئ.
في الأسبوع الماضي (11 ديسمبر)، تعطلت خدمات ChatGPT وSora من OpenAI لمدة 4 ساعات و10 دقائق، مما أثر على العديد من المستخدمين. الآن، تصدر OpenAI رسميًا تقريرًا مفصلاً عن انقطاع ChatGPT.
وببساطة، كان السبب الجذري لهذا الفشل هو تغيير بسيط، لكنه أدى إلى عواقب وخيمة. تم منع المهندسين من الوصول إلى سطح التحكم في اللحظة الحرجة ولم يتمكنوا من التعامل مع المشكلة في الوقت المناسب. فيما يتعلق بهذا الفشل، أطلق مهندسو OpenAI بسرعة عددًا من الإصلاحات بعد اكتشاف المشكلة، بما في ذلك تقليل حجم المجموعة، وحظر الوصول إلى الشبكة إلى واجهة برمجة تطبيقات إدارة Kubernetes، وزيادة موارد خادم Kubernetes API. وبعد عدة جولات من الجهود، تمكن المهندسون أخيرًا من استعادة الوصول إلى جزء من مستوى التحكم Kubernetes واتخذوا خطوات لتحويل حركة المرور إلى مجموعات صحية، مما أدى في النهاية إلى تحقيق الاسترداد الكامل للنظام.
وقع الحادث في الساعة 3:12 مساءً بتوقيت المحيط الهادئ حيث نشر المهندسون خدمة قياس عن بعد جديدة لجمع مقاييس مستوى التحكم Kubernetes (K8S). ومع ذلك، كان تكوين الخدمة واسعًا جدًا عن غير قصد، مما تسبب في قيام كل عقدة في كل مجموعة بتنفيذ عمليات K8S API كثيفة الاستخدام للموارد في نفس الوقت. تسبب هذا الموقف بسرعة في تعطل خادم API، مما تسبب في فقدان مستوى بيانات K8S لمعظم المجموعات لقدرات الخدمة.
تجدر الإشارة إلى أنه على الرغم من أن مستوى بيانات K8S يمكن نظريًا أن يعمل بشكل مستقل عن مستوى التحكم، فإن وظيفة DNS تعتمد على مستوى التحكم، مما يجعل من المستحيل على الخدمات التواصل مع بعضها البعض. عندما يتم تحميل عمليات API بشكل زائد، تتلف آلية اكتشاف الخدمة، مما يؤدي إلى شلل الخدمة بأكملها. على الرغم من اكتشاف المشكلة خلال 3 دقائق، إلا أن المهندس لم يتمكن من الوصول إلى مستوى التحكم لاسترجاع الخدمة، مما أدى إلى حالة "حلقة لا نهائية". وقد منعهم تحطم طائرة التحكم من إزالة الخدمة التي بها مشكلات، مما جعل عملية الاسترداد مستحيلة.
بدأ مهندسو OpenAI على الفور في استكشاف طرق مختلفة لاستعادة المجموعة. لقد حاولوا تقليل حجم المجموعة لتقليل تحميل واجهة برمجة التطبيقات (API) على K8S ومنعوا الوصول إلى واجهة برمجة تطبيقات الإدارة K8S حتى تتمكن الخوادم من استئناف العمليات العادية. بالإضافة إلى ذلك، قاموا أيضًا بتوسيع تكوين الموارد لخادم K8S API للتعامل بشكل أفضل مع الطلبات. وبعد سلسلة من الجهود، استعاد المهندسون أخيرًا السيطرة على مستوى التحكم K8S، وتمكنوا من حذف الخدمة المعيبة واستعادة المجموعة تدريجيًا.
خلال هذه الفترة، قام المهندسون أيضًا بنقل حركة المرور إلى المجموعات السليمة المستعادة أو المضافة حديثًا لتقليل الحمل على المجموعات الأخرى. ومع ذلك، نظرًا لمحاولة العديد من الخدمات التعافي في نفس الوقت، مما أدى إلى تشبع حدود الموارد، تطلبت عملية الاسترداد تدخلًا يدويًا إضافيًا، واستغرق استرداد بعض المجموعات وقتًا طويلاً. من خلال هذه الحادثة، من المتوقع أن تتعلم OpenAI من تجربتها وتتجنب "العزلة" مرة أخرى عند مواجهة مواقف مماثلة في المستقبل.
تفاصيل التقرير: https://status.openai.com/incidents/ctrsv3lwd797
أبرز النقاط:
سبب الفشل: تسببت التغييرات الصغيرة في خدمة القياس عن بعد في زيادة التحميل على عمليات K8S API، مما أدى إلى شلل الخدمة.
معضلة المهندس: يؤدي تحطم طائرة التحكم إلى عدم إمكانية الوصول إلى المهندسين، مما يجعل من المستحيل التعامل مع المشكلة.
⏳ عملية الاسترداد: من خلال تقليل حجم المجموعة وزيادة الموارد، تمت استعادة الخدمة أخيرًا.
على الرغم من أن هذا الحادث تسبب في انقطاع الخدمة، إلا أنه زود OpenAI أيضًا بخبرة قيمة، مما دفعهم إلى تحسين بنية النظام وخطط الطوارئ الخاصة بهم، وزيادة تحسين استقرار الخدمة، وتزويد المستخدمين بضمانات خدمة أكثر موثوقية. أعتقد أن OpenAI ستتعلم من هذه الحادثة، وستواصل تحسين تقنيتها، وستقدم تجربة أفضل للمستخدمين.