إذا كنت تشغّل أكثر من مئة نموذج في dbt، فالأرجح أنك مررت بصباح كهذا: يصل جدول مصدر متأخراً، فيفشل أحد نماذج التجهيز، ويفشل معه كل نموذج يليه في المسار. وأداة التنبيه لديك، وهي تفعل ما طُلب منها بالضبط، ترسل رسالة عن كل واحد منها.
التنبيهات ليست خاطئة، لكنها تتشكّل على هيئة الرسم البياني (DAG) لا على هيئة المشكلة. أربعون رسالة تصف سبباً واحداً، وأكثرها فائدة، أي العطل الأول، يكون عادةً مدفوناً في المنتصف.
البحث عن أول قطعة دومينو
الحل أن نتعامل مع الأعطال على أنها مسألة رسم بياني. بعد كل تشغيل نأخذ كل عقدة فشلت أو تخطّاها التشغيل، ونصعد في المسار إلى أن نصل إلى عقدة إما نجحت أو فشلت لأسبابها الخاصة. تلك العقدة هي السبب المرشّح. وكل ما يليها في المسار وفشل في التشغيل نفسه ينضم إلى الحادثة نفسها.
- العقدة التي فشلت بخطأ خاص بها، ونجحت كل العقد الأم التي تسبقها، هي سبب.
- العقدة التي تخطّاها التشغيل أو فشلت لأن إحدى العقد الأم فشلت هي عَرَض.
- سببان في تشغيل واحد يصبحان حادثتين، حتى لو تداخل نطاق تأثيرهما.
الحالات الصعبة
يصبح الأمر مثيراً للاهتمام عندما لا يفشل شيء. فالمصدر الذي يصل بنصف صفوفه المعتادة لن يعطّل شيئاً، لكن كل نموذج يليه سيكون خاطئاً بصمت. لهذا نعامل شذوذ الحجم والحداثة أيضاً على أنه سبب محتمل، لا الأخطاء وحدها.
السؤال المفيد ليس: ما الذي فشل؟ بل: ما أول شيء تغيّر؟
ما الذي يتغيّر في قناتك
لدى العملاء في شهرهم الأول، يقلّص التجميع بحسب السبب عدد التنبيهات لكل حادثة بنسبة 68%. والأهم أن التنبيه الوحيد المتبقي يسمّي النموذج الذي ينبغي النظر فيه، فتذهب الدقائق العشر الأولى من كل حادثة إلى الإصلاح بدلاً من قراءة السجلات.
إن أردت أن ترى كيف يبدو سجل تنبيهاتك مجمّعاً بحسب السبب، يمكننا تشغيله خلال عرض توضيحي على نسخة من مشروعك.
