نظرة عامة على الحالة
تتبع هذه الحالة تطبيق Windows انهار فقط بعد حوالي شهر من التشغيل المستمر. لم تكن الخطوة المهمة هي تخمين السبب الجذري مبكرًا، بل تحديد نقاط الملاحظة التي يجب أن تكون موجودة قبل أن يمكن تضييق السبب بشكل موثوق.
الأعراض
- ظهر الانهيار فقط بعد وقت تشغيل طويل
- لم يخبر شكل الفشل على الفور ما إذا كان متعلقًا بالذاكرة أو handles أو شيء آخر
- كان لا بد من ضغط إعادة الإنتاج لأن الانتظار شهرًا كان غير واقعي
القيود
- تضمن مسار المشكلة إعادة اتصال الكاميرا وسلوك الحالات الشاذة
- لم تكن سجلات المسار العادي وحدها كافية
- كان يجب ملاحظة نمو الموارد بمرور الوقت، وليس فقط في لحظة الانهيار
ما لاحظناه
- مقاييس heartbeat مثل
Handle CountوPrivate BytesوThread Count - سجلات الحدود حول بدء الجلسة وإعادة الاتصال والإيقاف
- سجلات دورة حياة مزدوجة لـ create/open/register و close/dispose/unregister
كيف ضيقنا النطاق
بدلاً من معاملته فقط كانهيار غامض في تشغيل طويل، ضغط العمل إعادة الإنتاج حول إعادة الاتصال ومسارات الفشل. جعل ذلك من المعقول جدًا معالجة المشكلة باعتبارها تحقيق تسرب handle بدلاً من مطاردة انهيار عامة.
كيف حسّنّاه
- عززنا المراقبة بحيث تكون اتجاهات النمو مرئية قبل الانهيار النهائي
- جعلنا حدود الملكية أسهل للتتبع في السجلات
- نظمنا النتيجة بحيث يمكن لاختبار مسارات الفشل البناء عليها لاحقًا
الخدمات التي ترتبط بها هذه الحالة
ترتبط هذه الحالة بـالتحقيق في الأخطاء وتحليل السبب الجذري لعزل الأعطال التي لا تظهر إلا بعد التشغيل الطويل، وتطوير تطبيقات ويندوز لإعادة تنظيم السجلات وإعادة الاتصال والرصد التشغيلي من جانب التطبيق.