Oncall Bot ومراقبة الواجهة الأمامية
تنبيهات تعتمد على التغيّر النسبي في بيانات ClickHouse، مع روبوت محادثة يستعين بنموذج لغوي كبير يحوّل التنبيه إلى سبب جذري محتمل، داخل المحادثة التي يعمل فيها الفريق أصلًا.
- الدور
- Senior Frontend Engineer
- الفترة
- 2025–الآن
- التقنيات
- ClickHouse · Alerting service · LLM API · Kubernetes · Internal chat bot
المشكلة
كان التسرّب الصامت أثناء الانتقال إلى أطراف خارجية، مثل التحقق عبر NFC، يُكتشف بعد أيام من خلال خدمة العملاء. وكانت تنبيهاتنا قائمة على عتبات ثابتة ومليئة بالضجيج، فاعتاد الناس تجاهلها.
النهج
- خطوط أساس نسبية بدل العتبات الثابتة. تشغّل خدمة التنبيهات استعلامات SQL على ClickHouse وتقارن كل مؤشر بالساعة نفسها في الأسبوع الماضي. انخفاض التحويل بنسبة 20% يعني شيئًا مختلفًا في الثالثة فجرًا في طوكيو وعند الظهر في برلين، ولم تعد تقلبات حركة المرور العالمية تثير إنذارات كاذبة.
- تنبيه يصل ومعه السياق. عند إطلاق التنبيه تُنشر بطاقة حادثة في منصة المحادثة الداخلية. ثم تجمع عملية في الخلفية آخر تتبعات أخطاء الواجهة الأمامية من ClickHouse، وإصدار الإعدادات المفعّل من خدمة الإعدادات، وسجلات النشر في Kubernetes، وترسلها في موجّه منظّم إلى واجهة برمجية لنموذج لغوي كبير مخصص للمؤسسات.
- ملخّص داخل المحادثة. يرد الروبوت بسبب جذري محتمل، مثل: انخفاض التحويل في الخطوة 3 في اليابان بنسبة 32%، وخطأ مؤشر فارغ في غلاف جسر NFC، وتغيير في الإعدادات نُشر قبل 15 دقيقة، وانتهاء مهلة بوابة أحد المزوّدين في الخادم.
النتيجة
انخفض زمن الاكتشاف من ساعات أو أيام إلى أقل من 5 دقائق، وانخفض زمن التخفيف بنسبة 65% والتنبيهات الكاذبة بنسبة 80%. وتمت أيضًا متابعة نسبة الإشارة إلى الضجيج في التنبيهات (نسبة التنبيهات المرتبطة بحوادث حقيقية) ومتوسط الوقت بين الأعطال لوحدات الواجهة الأمامية.
لماذا بهذه الطريقة
التنبيه العادي يخبرك فقط بأن شيئًا ما تعطل. أما جمع البيانات وتلخيصها تلقائيًا فيسدّ الفجوة بين المؤشر وفهم الإنسان له، وهناك كان يذهب معظم وقت الاستجابة.