قصة عميل · Nasma Cooling
اكتشفت Nasma Cooling في يومها الأول صفوفاً تُفقد بصمت منذ ثلاثة أسابيع
كان تغيير في مخطط أحد المصادر يُسقط قراءات العدادات دون أن يفشل تشغيل واحد.
- حالات فقدان صامت للصفوف منذ الإطلاق
- 0
- تغييراً في المخطط رُصدت في الربع الأول
- 37
- من جداول الفوترة في موعدها
- 99.6%
المشكلة
توفّر Nasma Cooling المياه المبرّدة لتكييف الهواء إلى 1,900 مبنى في دبي وأبوظبي. وتصل قراءات العدادات الذكية كل 15 دقيقة، فتُحمَّل في BigQuery وتغذّي الفوترة والتنبؤ وتطبيق العملاء عبر Dagster وdbt Cloud.
كانت كل عمليات التشغيل خضراء. لكن عندما غيّر أحد مورّدي العدادات نوع حقل واحد من عدد صحيح إلى نص، توقّف ربط داخلي (inner join) بصمت عن مطابقة نحو 2% من القراءات. لم يفشل شيء؛ كانت الأرقام أقل بقليل فحسب، وبقيت كذلك ثلاثة أسابيع.
ما الذي تغيّر
في اليوم الأول، نبّهت فحوص الحجم في Tessel إلى أن أحد نماذج التجهيز يتلقى منذ أوائل مارس صفوفاً أقل من النمط الذي تعلّمته له. وتتبّعت الحادثة سبب الانخفاض حتى تغيير النوع في المصدر، وأضاف طلب دمج (pull request) تحويلاً صريحاً للنوع (cast) واختباراً لعدد الصفوف.
أصبح كريم منصور، مهندس التحليلات، يرى كل تغيير في مخطط أي مصدر قبل أن يصل إلى الفوترة. ورصدت Tessel في ربعها الأول 37 تغييراً، وصمدت وعود الحداثة على جداول الفوترة بنسبة 99.6% من الوقت.
منظومة الأدوات: Dagster، dbt Cloud، BigQuery، GitHub، Slack.
مراحل الإطلاق
-
اليوم الأول
ربط Dagster وBigQuery، واكتشاف انخفاض الحجم خلال ساعات.
-
الأسبوع الثاني
دمج إصلاح تحويل النوع واختبار عدد الصفوف، وإعادة تشغيل الفوترة للأسابيع المتأثرة.
-
الشهر الثالث
تفعيل تعليقات مسار البيانات على كل طلب دمج في مشروع dbt Cloud.
اكتشفت تغييراً في مخطط المصدر كان يُسقط الصفوف بصمت منذ ثلاثة أسابيع.
احصل على النتيجة نفسها مع أدواتك
سنشغّل Tessel على نسخة من مشروعك خلال العرض التوضيحي، لترى حوادثك أنت.