أفيتو تربط نماذج LLM باختبارات الفوضى وترفع تغطية الحوادث من 22% إلى 41%

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

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

من تقرير الحادث إلى التحقق في بيئة الإنتاج

كان خط المعالجة يثري نص تقرير LSR بالمراسلات المأخوذة من المحادثة المرتبطة به، ثم يطرح على النموذج ستة أسئلة منفصلة. وكان النموذج يلخص السبب والعرض، ويقيّم إمكانية إجراء اختبار فوضى، ويتحقق من مصير Action Items، ويمنح السيناريو تقييما من 0 إلى 10، ويختار حالات شذوذ من مكتبة داخلية. كانت النتائج تحفظ في MongoDB، بينما كان Elasticsearch ينشئ فهرسا متجهيا للبحث عن الحوادث المتشابهة.

بهذه الطريقة، حصلت أفيتو على 432 استنتاجا يجري تحديثها تلقائيا عبر 408 خدمات. ووفقا لتقييم النموذج، يمكن إعادة إنتاج 41% من الأعطال التي خضعت للتحليل باستخدام أدوات موجودة أو مخطط لها. أما باستخدام LitmusChaos وحده، الذي يعمل أساسا على مستوى وحدات pod، فكانت النسبة نحو 22%. وكاد منسق النطاق Kratos أن يضاعف التغطية المحتملة بفضل سيناريوهات تستهدف قواعد البيانات والشبكة.

من الأمثلة البسيطة تبديل العقدة الرئيسية في Redis. يمكن للاختبار التقليدي إنهاء عملية أو حذف وحدة pod، لكن ذلك لا يعادل إعادة انتخاب فعلية لعقدة primary داخل replica set. لذلك أضاف الفريق سيناريو trigger-primary-re-election لكل من MongoDB وRedis. ويستخدم هذا السيناريو في 95.6% من عمليات التشغيل التلقائية: إذ تختبر الخدمات في مواجهة تبديل حقيقي للعقدة الرئيسية، لا محاكاة تقريبية له.

أين يخطئ نموذج LLM

لا تعني الدرجة المرتفعة التي يمنحها النموذج أن الاختبار مفيد بالضرورة. في إحدى الحالات، كان سبب العطل إعدادا غير صحيح في Nginx بعد إصلاح ثغرة أمنية. منح نموذج LLM السيناريو 10 من 10 واقترح إضافة زمن استجابة للشبكة. وكانت الأعراض متشابهة بالفعل: أخطاء HTTP، وانتهاء المهل، وعدم توفر المستندات. لكن اختبار الفوضى لم يكن قادرا على تغيير إعدادات نظام تابع لجهة خارجية، ولذلك لم يكن ليعيد إنتاج السبب الجذري مطلقا.

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

ما الذي يمكن الاستفادة منه

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

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