CompertMe

دراسة حالة 07 · منصة لبيانات المنافسين · تطوير وتشغيل وصيانة

قطاع افتقر إلى بيانات السوق بات يملكها الآن

نجمع البيانات من 188 موقعًا للمنافسين وفق جدول محدد، ونحتفظ بكل تغير في الأسعار بصورة دائمة، ونتيح البحث في سجل التراخيص الحكومي من داخل برنامج المتاجر الخاص بالعميل.

بقلم Hesham Ghoniem، المهندس الرئيسي ·

القطاع
تحليل بيانات المنافسين وهندسة البيانات
طبيعة العمل
مستمر · تصميم وتطوير وتشغيل وصيانة
نطاق العمل
منصة زحف للمواقع · معالجة الصور · لوحة تحكم للموظفين · سوق إلكتروني عام · واجهة API خاصة
التقنيات
PHP
Laravel 9
MongoDB
Redis
Horizon
DigitalOcean
  • 188 — موقعًا للمنافسين تحت المتابعة
  • 9 — فئات من الحيوانات، إلى جانب المربّين وسجلات التفتيش
  • 100 — عطل لم يُعالج قبل إيقاف جمع البيانات من الموقع تلقائيًا
  • 10 — أنواع مختلفة من الأعطال يبلّغ عنها النظام بدلًا من أن يظل صامتًا
  • كل دقيقة — جمع الصور الجديدة وتحويلها ورفعها

نظرة عامة

لم تكن أسعار المنافسين معروفة. أنهينا الاعتماد على التخمين.

لم تتوافر بيانات عن السوق في القطاع الذي يعمل فيه عميلنا. لم يكن أحد يعرف أسعار المنافسين، أو ما يُباع بالفعل، أو أيّ المربّين يحمل ترخيصًا حقيقيًا. كانت قرارات التسعير تعتمد على المكالمات الهاتفية وما يتناقله العاملون في القطاع، وعلى بضع ساعات يقضيها أحدهم أحيانًا في تصفح موقع منافس.

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

لم تكن قراءة البيانات هي التحدي الأصعب؛ بل بناء نظام يواصل تقديم بيانات صحيحة حين يغيّر منافس تصميم موقعه يوم الثلاثاء.

العطل الذي لا ينتبه إليه أحد

أخطر ما قد يصيب منصة بيانات ليس توقفها، بل زاحف لا يعيد أي بيانات، وشركة ترى في الشاشة الفارغة خبرًا سارًا.

التحديات

ست مشكلات، وأخطرها يبدو خبرًا سارًا.

لكل موقع بنية مختلفة، ولا يرغب أيّ منها في أن تجمع الأنظمة بياناته

188 موقعًا تعني 188 بنية مختلفة للصفحات. بعضها طُوّر خصيصًا منذ عقود. وبعضها يعتمد على منصات متاجر تُنشئ الصفحة داخل المتصفح بعد تحميلها، فلا يحتوي الكود المصدري للصفحة على بيانات مفيدة. ويرصد عدد من هذه المواقع الزيارات الآلية المتكررة ويحظرها.

لا توجد صيغة بيانات مشتركة في هذا القطاع، ولا مصدر بيانات متاح للجميع، ولا معيار موحد. كل موقع يحتاج إلى معالجة مستقلة.

تتغير المواقع دون إنذار، وتعطل أداة الاستخراج يبدو كأنه نتيجة فارغة صحيحة

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

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

التعطل دون تنبيه هو الخطر الذي لا يراقبه أحد

هذه هي المشكلة السابقة نفسها، لكن على مستوى أوسع. الزاحف الذي يتوقف ويرسل تنبيهًا يُصلح خلال ساعة. أما الزاحف الذي يعيد حقولًا فارغة دون تنبيه طوال 6 أسابيع، فيفسد كل قرار يستند إلى بياناته خلال تلك الفترة. لا يرسل أي تنبيه لأنه يبدو من الخارج كأنه يعمل بصورة طبيعية.

الصور هي الجزء المكلف، وتدفقها لا يتوقف

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

إذا عالج النظام الصور أثناء الزحف نفسه، فإما أن يُثقل الخوادم أو يتأخر عدة أيام عن الصور الواردة. وإذا أهمل حذف الملفات غير اللازمة، تنمو تكاليف التخزين بلا حد.

كانت أهم بيانات التراخيص موجودة في موقع حكومي

تنشر هيئة الترخيص الوطنية تراخيص المربّين والتجار وتقارير التفتيش في صفحات ويب وملفات PDF ممسوحة ضوئيًا. يستطيع من يطالعها واحدة تلو الأخرى استخدامها بسهولة، لكنها لا تناسب إطلاقًا موظف متجر يحتاج إلى التحقق من مربٍّ والعميل واقف أمامه.

مراعاة خوادم الآخرين متطلب تقني، وليست مجرد لباقة

المنصة التي ترسل الطلبات إلى 188 موقعًا بأقصى سرعة لا تختلف في نظر تلك المواقع عن هجوم إلكتروني، وستُحظر خلال أسبوع، وهذا ما تستحقه. كان علينا تصميم النظام ليتأنى عمدًا في إرسال الطلبات، مع قدرته على العمل بهذا الحجم باستمرار.

آلية الإيقاف الوقائي · دون أن يكون أحد مستيقظًا

كيف توقف المنصة جمع البيانات تلقائيًا

لم يكن جمع البيانات أصعب متطلبات هذه المنصة، بل رفض جمع بيانات خاطئة تلقائيًا، في الساعة 3 صباحًا، دون أن يكون أحد مستيقظًا.

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

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

ثانيًا، تبلّغ المنصة عن 10 أنواع مختلفة من الأعطال، لأن عبارة «لم يعمل» لا تساعد على الإصلاح. لكل نوع مشكلة مختلفة وحل مختلف، وتصل تفاصيله إلى قناة في Slack وبالبريد الإلكتروني، بدلًا من الاكتفاء بملف سجل لا يفتحه أحد.

عشرة أنواع من الأعطال، لكل منها بلاغ مستقل

  • خطأ في الخادم
  • خطأ في الزاحف
  • محتوى الصفحة فارغ
  • القيم المستخرجة فارغة
  • استجابة قاعدة البيانات فارغة
  • استجابة غير عددية
  • تعذّر تنزيل ملف
  • بنية ملف قديمة
  • ملف مفقود
  • تجاوز عدد تقارير التفتيش الحد الأقصى

هذا هو أساس التصميم

يتعامل النظام مع النتيجة الفارغة بوصفها خللًا يستدعي المتابعة، لا إجابة.

ثالثًا، توقف المنصة جمع البيانات من المواقع التي تتسبب في الأعطال تلقائيًا.

يسجل النظام كل عطل على الموقع الذي تسبب فيه. وعندما يتراكم على موقع واحد 100 عطل لم يُعالج، توقف المنصة جميع زواحفه فورًا، وتضع عليه علامة تفيد بتعطيله بسبب الأعطال، وترسل بريدًا بعنوان Action Required يذكر اسم النطاق، وتنشر تنبيهًا في قناة العمليات على Slack.

لا تطلب إذنًا ولا تنتظر تدخل أحد. تستبعد الموقع الذي بدأ يرسل بيانات مضللة من مصادر البيانات إلى أن يصلحه أحد.

وتستأنف جمع البيانات منها تلقائيًا أيضًا.

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

توقف عند 100 عطل، واستئناف تلقائي

يرتفع عداد الأعطال على مقياس يحمل علامة عند 100. عند بلوغ الحد، تتوقف زواحف الموقع وينفذ النظام 3 إجراءات: بريد بعنوان Action Required، وتنبيه على Slack، ووضع علامة على الموقع بأنه معطّل. ويُظهر إطار ثانٍ أصغر انخفاض العدد إلى أقل من 100 واستئناف الزواحف عملها تلقائيًا.

يمكن لأي فريق بناء آلية إيقاف. القيمة هنا أن لا أحد يحتاج إلى تذكّر إعادة التشغيل.

الزاحف الذي يتوقف ويرسل تنبيهًا يُصلح خلال ساعة. أما الذي لا يعيد بيانات ولا ينبّه أحدًا فيفسد قرارات 6 أسابيع. صمّمنا النظام لمواجهة الحالة الثانية.

— Hesham Ghoniem، المهندس الرئيسي

ما بنيناه

ست مراحل، من أداة استخراج لكل موقع إلى خانة بحث في برنامج متاجر العميل.

المرحلة الأولى · 45 عملية مساعدة مشتركة

أداة استخراج لكل موقع، ومجموعة أدوات مشتركة تدعمها جميعًا

لكل منافس مجموعة صغيرة من التعليمات، مقسمة إلى خطوات: العثور على الإعلانات، وقراءة الإعلان، وقراءة بيانات المربّي، والتحقق من النتيجة. وعندما يتغير موقع، نصلح أداة استخراجه وحدها وتستمر أدوات المواقع الـ187 الأخرى في العمل.

تعمدنا إبقاء أدوات الاستخراج بسيطة. فالجزء الأهم هو مجموعة الأدوات المشتركة التي تعتمد عليها، وتضم 45 عملية مساعدة في نحو 1,000 سطر: استخراج النص من موضع محدد، أو قيمة سمة، أو النص بين علامتين، أو كل ما يأتي بعد آخر ظهور لعبارة، أو قيمة من رابط، وتحويل تاريخ إلى طابع زمني، والتحقق من صحة رابط. لذلك نركّب أداة الاستخراج الجديدة من هذه العمليات، ولا نكتب محلّلًا من الصفر.

المرحلة الثانية · ثماني أدوات استخراج، 115 موقعًا

أداة استخراج واحدة لعدة مواقع

تستخدم المواقع المبنية على المنصة نفسها أداة استخراج مشتركة. تغطي 8 أدوات مشتركة 115 موقعًا من أصل 188، منها أداة تتولى وحدها 75 متجرًا يعمل بنظام الامتياز التجاري، وأخرى طُوّرت خصيصًا لمتاجر تعتمد على منصة تجارية شائعة.

يحتاج 73 موقعًا إلى أداة استخراج مخصصة لكل منها، بينما لا تحتاج المواقع الـ115 الأخرى إلى ذلك. هذه النسبة هي ما يميز المنصة عن مجموعة ضخمة من السكربتات.

كيف نجمع البيانات من 188 موقعًا

3 أشرطة بأطوال متناسبة مع القيم. تستخرج 8 أدوات مشتركة البيانات من 115 موقعًا. ومن بينها 75 متجر امتياز تجاري تتولاها أداة مشتركة واحدة. أما المواقع الـ73 الأخرى فيحتاج كل منها إلى أداة مخصصة.

المرحلة الثالثة · السعر والتوافر

سجل للتغيرات يتجاوز حفظ القيمة الحالية

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

بهذا تتحول جولات الزحف المتعاقبة إلى سجل للأسعار، ويستطيع العميل تحديد اليوم الذي خفّض فيه منافس أسعاره بدقة. وتتابع الآلية نفسها توافر المعروض، فتتعرف المنصة على ما باعه المنافس فعلًا، وتميزه عما توقف فقط عن الإعلان عنه.

تعطّل الاستخراج يؤخر التحديث دون أن يمحو السجل التاريخي

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

المرحلة الرابعة · حتى عشر ثوانٍ قبل كل طلب

جمع البيانات بتأنٍّ مقصود وعلى نطاق واسع

تنتظر المنصة مدة عشوائية تصل إلى 10 ثوانٍ قبل كل طلب صادر. وترسل الطلبات عبر اتصالات إقليمية تتبدل بالتناوب. أما المواقع التي لا تُنشئ صفحاتها إلا داخل المتصفح، فتجلبها المنصة باستخدام متصفح فعلي يعمل دون واجهة رسومية أو خدمة لعرض الصفحات.

والنتيجة منصة تجمع البيانات من 188 موقعًا باستمرار، وتبدو لكل منها كزائر بطيء لا يلفت الانتباه.

المرحلة الخامسة · Laravel · طابور مهام متكامل

إعادة بناء نظام معالجة الصور على أسس سليمة

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

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

تعمل معالجة الصور وفق جدول دقيق: جمع الصور الجديدة ورفعها إلى التخزين السحابي كل دقيقة، والتحقق منها كل 5 دقائق، وتحديث الإحصاءات ونسخ قاعدة البيانات احتياطيًا كل 6 ساعات، وأعمال التنظيف يوميًا. ترسل كل مرحلة تقاريرها إلى قناة مستقلة في Slack، فيظهر تراكم المهام خلال دقائق بدلًا من أيام.

المرحلة السادسة · التعرف على النصوص · واجهة خاصة

إتاحة البحث في بيانات موقع حكومي من خانة واحدة

خصصنا أداة لاستخراج بيانات التراخيص والتفتيش من موقع هيئة الترخيص الوطنية، وعالجنا وثائق التفتيش الممسوحة ضوئيًا بالتعرف على النصوص لتصبح قابلة للبحث. ثم وحّدنا صيغة البيانات في سجل يتيح البحث بالاسم أو رقم الترخيص أو العنوان، مع قصر النتائج على التراخيص السارية حاليًا.

ثم أتحنا السجل عبر واجهة خاصة. عندما يكتب موظف متجر اسم مربٍّ في برنامج العميل، يصل الطلب إلى هذه المنصة التي تعيد بيانات حاملي التراخيص بعد التحقق منها.

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

دورة مكتملة في أربع خطوات

دورة مكتملة من 4 خطوات: موقع هيئة الترخيص بما يحويه من صفحات ويب وملفات PDF ممسوحة ضوئيًا، ثم الزاحف والتعرف على النصوص، ثم سجل التراخيص المتاح عبر واجهة خاصة، ثم موظف يكتب اسم مربٍّ في برنامج متجره، وتعود الدورة إلى البداية.

بحث للتحقق من البيانات بالرجوع إلى السجل العام، يقتصر على التراخيص السارية حاليًا.

دراسة حالة ذات صلة: منصة إدارة عمليات متاجر التجزئة متعددة الفروع

برنامج المتاجر الذي تكتمل عنده هذه الدورة.

تفاصيل التشغيل · لوحة تحكم الموظفين

داخل مركز التحكم

المنصة التي تجمع البيانات من 188 موقعًا ستواجه دائمًا عطلًا في جزء منها؛ فهناك موقع يغيّر تصميمه في كل وقت. المهم أن يتمكن المسؤولون عن التشغيل من رؤية هذه الأعطال، فهي ستحدث على أي حال.

لذلك خصصنا جزءًا كبيرًا من العمل للوحة تحكم الموظفين، بعيدًا عن الزحف نفسه: 47 مسارًا لخدمة من يحافظون على صحة البيانات.

أين تظهر الأعطال: نظام واحد لا واجهتان منفصلتان

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

لوحات تحكم مستقلة لفئات الحيوانات

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

حالة الزواحف ظاهرة بوضوح

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

موظفون يراجعون جودة البيانات بدلًا من افتراض صحتها

خصصنا 3 شاشات لرصد البيانات الخاطئة التي لم يصاحبها تنبيه: شاشة لمراجعة السجلات المجمعة من موقع، وتقرير بالسجلات ذات الحقول الناقصة، وشاشة لمراجعة عينة عشوائية تعرض سجلات يختارها النظام عشوائيًا ليفحصها شخص. أضفنا الأخيرة لأن بعض الأخطاء لا تستطيع قاعدة آلية اكتشافها.

ربط حقول كل موقع بإعدادات يعدّلها الموظفون

تحدد الإعدادات الحقول التي يوفرها كل موقع والأعمدة المقابلة لها في المنصة، دون الحاجة إلى تعديل الكود. لذلك تصبح إضافة موقع يشبه موقعًا قائمًا مهمة إدارية في معظمها.

مراقبة قاعدة البيانات وإحصاءات مستمرة

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

ونسخ احتياطي تلقائي للنظام كله

نسخ احتياطي لقاعدة البيانات كل ليلة إلى التخزين السحابي، مع مهمة تحذف النسخ القديمة حتى لا ينمو التخزين بلا حد، وأداة تنظيف تحذف الملفات التي لم تعد مرتبطة بسجلات، ومهمة تجدّد الروابط الموقّعة التي تحمي الصور المخزنة.

الزواحف هي الجزء السهل. مركز التحكم هو ما يجعلها منتجًا بدلًا من تجربة.

— Hesham Ghoniem، المهندس الرئيسي

طريقة عملنا

ثماني قواعد لمواجهة العطل الذي لا ينتبه إليه أحد.

ابدأ بالحالة الأصعب قبل الأسهل

كتبنا أدوات الاستخراج الأولى للمواقع الأصعب تعاملًا. إذا صمد تصميم النظام أمامها، صمد أمام البقية. أما البدء بالمواقع السهلة فلا يكشف شيئًا، وينتج تصميمًا ينهار عند الموقع رقم 40.

صمّم كل مكوّن ليكون قابلًا للاستبدال، باستثناء المحرك

نتوقع تعطل أدوات الاستخراج ونصممها بحيث يسهل الاستغناء عنها. أما الاستثمار فيذهب إلى مجموعة الأدوات المشتركة، والإبلاغ عن الأعطال، ولوحة التحكم؛ وهي الأجزاء التي تعتمد عليها المواقع الـ188 كلها.

ابنِ المراقبة قبل التوسع

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

أعطِ البيانات المخزنة الأولوية على البيانات الواردة

عند التعارض، نحتفظ بالبيانات المخزنة. انقطاع الجمع يسبب إزعاجًا مؤقتًا، أما تلف السجل التاريخي فأثره دائم.

اجعل الإبلاغ عن العطل واضحًا ومحددًا

10 أنواع مستقلة من بلاغات الأعطال بدلًا من رسالة خطأ عامة، يصل كل منها إلى قناة يتابعها شخص فعلًا. عبارة «حدث خطأ ما» ليست بلاغًا مفيدًا.

دع النظام يوقف أجزاءه التي تهدد صحة البيانات

توقف آلية الإيقاف الوقائي جمع البيانات عند 100 عطل دون انتظار أحد، وتستأنفه دون تدخل أيضًا. أي نظام يعتمد على انتباه شخص سيأتي وقت يعتمد فيه على شخص لم ينتبه.

حدّث ما يعاني ضغطًا، لا ما تقادم فحسب

ما زال محرك الزحف الأصلي يشغّل أدوات الاستخراج لأنه يؤدي وظيفته. وأعدنا بناء معالجة الصور باستخدام Laravel وطابور مهام متكامل لأن الضغط الحقيقي كان هناك. إعادة كتابة برنامج يعمل لمجرد إعادة كتابته تعني إنفاق مال العميل على تفضيلاتنا.

راعِ خوادم الآخرين

فترات انتظار مقصودة قبل كل طلب، واتصالات تتبدل بالتناوب، وحمل على كل موقع لا يتجاوز ما يسببه شخص يتصفح ببطء. هذا هو التصرف السليم، وهو أيضًا الأسلوب الوحيد الذي سيظل يعمل بعد سنتين.

التقنيات المستخدمة

ثماني طبقات، والغرض من كل منها.

التخزين

تختلف بنية الإعلانات من موقع لآخر. وبفضل مرونة التخزين، لا تتطلب إضافة موقع جديد تغيير بنية قاعدة البيانات.

  • MongoDB

محرك الزحف

يشغّل جميع أدوات الاستخراج التي حان موعد تشغيلها بالتزامن بدلًا من تشغيلها تباعًا، فلا يعطل موقع بطيء المواقع الـ187 الأخرى. ونركّب الأداة الجديدة من مكوّنات موجودة بدلًا من كتابتها من الصفر.

  • تطوير مخصص باستخدام PHP
  • إرسال الطلبات بالتزامن
  • 45 عملية مساعدة مشتركة

التعامل مع المواقع صعبة الوصول

يقرأ الصفحات التي ينشئها المتصفح بعد التحميل، ويصل إلى المواقع التي تحظر الزيارات المتكررة دون أن يتصرف كهجوم إلكتروني.

  • Headless Chrome
  • ScrapingBee
  • خوادم وسيطة إقليمية تتبدل بالتناوب
  • فترات انتظار عشوائية

معالجة الصور

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

  • PHP 8.1
  • Laravel 9.19
  • Horizon 5
  • Redis
  • Intervention Image
  • التحويل إلى WebP

التخزين السحابي

الصور والنسخ الاحتياطية الليلية في مساحات تخزين منفصلة للمعارض والملفات والنسخ الاحتياطية، مع تجديد الروابط الموقّعة وفق جدول محدد.

  • DigitalOcean Spaces

الوثائق

يتيح البحث في تقارير التفتيش الحكومية الممسوحة ضوئيًا.

  • التعرف الضوئي على النصوص OCR

التنبيهات

يظهر تراكم المهام أو حدوث عطل خلال دقائق، في القنوات التي يستخدمها الفريق أصلًا.

  • Slack، قناة لكل مرحلة من مراحل المعالجة
  • البريد الإلكتروني عبر Postmark

لوحة التحكم

منها يدير الموظفون تشغيل المنصة فعليًا.

  • تطوير مخصص باستخدام PHP
  • 47 مسارًا

الاختبارات الآلية

تتحقق الاختبارات الآلية من كل تغيير قبل وصوله إلى بيئة الإنتاج.

كيف تعمل المنصة

سبع خطوات، من مهمة تعمل كل دقيقة إلى إجابة داخل برنامج متاجر العميل.

الخطوة 1

الجدولة

تعمل مهمة كل دقيقة، فتستعلم من قاعدة البيانات عن أدوات الاستخراج التي حان موعد تشغيلها، وتحدد موعد تشغيلها التالي، ثم تطلقها جميعًا بالتزامن.

الخطوة 2

الجمع

تجمع أدوات الاستخراج روابط الإعلانات، ثم تزور كل إعلان، مع انتظار قبل كل طلب، واتصال يتبدل بالتناوب، واستخدام متصفح فعلي للمواقع التي تحتاج إليه.

الخطوة 3

المقارنة

يقارن النظام النتائج بالبيانات المخزنة. يضيف الإعلان الجديد، وعند تغير السعر يضيف القيمة السابقة إلى سجل الإعلان. ويعتبر الإعلان الذي اختفى مباعًا. وإذا تعذّر استخراج حقل، يحتفظ بقيمته السابقة بدلًا من استبدالها بقيمة فارغة.

الخطوة 4

التصنيف

يصنّف النظام كل خلل ضمن واحد من 10 أنواع محددة من الأعطال، ويبلّغ عنه ويسجله على الموقع. وعند بلوغ 100 عطل لم يُعالج، تتوقف زواحف الموقع تلقائيًا إلى أن تُعالج الأعطال.

الخطوة 5

إضافة الصور إلى طابور المهام

يضيف النظام الصور إلى طابور المهام بدلًا من معالجتها فورًا. تتولى منظومة مستقلة تنزيلها والتحقق منها وتحويلها ورفعها إلى التخزين السحابي كل دقيقة، وتجري التحقق كل 5 دقائق، وتحذف صور الإعلانات التي اختفت.

الخطوة 6

المراقبة

يتابع الموظفون مركز التحكم: 9 لوحات للفئات، وحالة الزواحف، وقوائم الأعطال، والمهام الفاشلة، وتقارير البيانات الناقصة، وشاشة مراجعة عينة عشوائية لرصد الأخطاء التي لا تكتشفها القواعد الآلية.

الخطوة 7

الإجابة

يرسل برنامج متاجر العميل استعلامًا عندما يكتب الموظف اسم مربٍّ في نظامه. يصل الطلب إلى سجل التراخيص في هذه المنصة، فتعيد بيانات المربّين والتجار والناقلين الذين جرى التحقق منهم وما زالت تراخيصهم سارية.

النتائج

ما تستطيع الشركة فعله الآن ولم يكن ممكنًا من قبل.

رؤية السوق كله بدلًا من جزء محدود منه

نظام واحد يجمع البيانات باستمرار من 188 موقعًا للمنافسين عبر 9 فئات من الحيوانات.

تحديد اليوم الذي خفّض فيه منافس أسعاره

يحتفظ النظام بتغيرات الأسعار في سجل تاريخي بدلًا من استبدالها. تزداد قيمة الأرشيف كل شهر، ولا يُستبدل محتواه كل ليلة.

معرفة ما يُباع فعلًا

إلى جانب معرفة المعروض للبيع، يرصد النظام تغيرات التوافر ويسجل توقيتها.

التحقق من ترخيص مربٍّ أثناء الحديث مع العميل

أتحنا بيانات موقع حكومي، من صفحات ويب وملفات PDF ممسوحة ضوئيًا، في خانة بحث داخل برنامج متاجر العميل، مع قصر النتائج على التراخيص السارية.

مواصلة العمل بعد تغيير تصميم موقع منافس دون فقدان أي بيانات

تعطّل أداة الاستخراج يؤخر التحديث دون أن يمحو السجل التاريخي.

اكتشاف الخلل قبل استخدام البيانات

10 أنواع محددة من بلاغات الأعطال، وقائمة يعالجها الموظفون، وإيقاف تلقائي لجمع البيانات من أي موقع يتجاوز 100 عطل لم يُعالج.

إضافة موقع مشابه من خلال الإعدادات الإدارية

ربط الحقول جزء من الإعدادات. المواقع التي تستخدم المنصة نفسها تشترك في أداة استخراج: 8 أدوات تغطي 115 موقعًا من أصل 188.

تشغيل المنصة بفريق صغير

47 مسارًا تشغيليًا تتيح للمسؤولين عن المنصة متابعتها من لوحات التحكم بدلًا من قراءة ملفات السجلات.

التطوير بالأرقام

  • 188 موقعًا للمنافسين تحت المتابعة
  • 73 أداة استخراج مخصصة لموقع بعينه
  • 8 أدوات استخراج مشتركة تغطي المواقع الـ115 الأخرى
  • 75 موقعًا تغطيه أكبر أداة استخراج مشتركة
  • 9 فئات من الحيوانات تحت المتابعة
  • 10 أنواع من الأعطال، لكل منها بلاغ مستقل
  • 100 عطل لم يُعالج قبل الإيقاف التلقائي
  • 45 عملية مساعدة في مجموعة أدوات الاستخراج المشتركة
  • 47 مسارًا في لوحة تحكم الموظفين
  • 30 مهمة صيانة مجدولة في المحرك الأصلي
  • 7 / 11 أنواع مهام في الطابور / أوامر الطرفية في نظام معالجة الصور
  • كل دقيقة أقصر فترة بين مرات تشغيل مهمة مجدولة

حالة النظام بوضوح

هذه المنصة تعمل فعليًا، وحُسبت الأرقام أعلاه من نسخة الكود المستخدمة في التشغيل، التي يعود آخر تعديل فيها إلى مايو 2023.

يعمل جيلان من النظام جنبًا إلى جنب عن قصد. يشغّل محرك PHP الأصلي أدوات الاستخراج ولوحة التحكم، ويتولى تطبيق Laravel الأحدث معالجة الصور. هذا قرار مقصود، وليس عملية انتقال توقفت قبل اكتمالها.

أصبحت الإصدارات قديمة الآن. انتهى الدعم الأمني لإصدار PHP 8.1 في ديسمبر 2025، ولإصدار Laravel 9 في فبراير 2024. كما انتقلت حزمة MongoDB المستخدمة في معالجة الصور إلى إدارة MongoDB وتغيّر اسمها، لذلك لم يعد الاسم الوارد في هذه النسخة من الكود هو اسم الحزمة التي تتلقى الصيانة.

يشير العدد 188 إلى أدوات الاستخراج التي أُعدّت في النظام، وهذا ما يثبته الكود. أما عدد الأدوات المفعّلة في أي يوم فهو إعداد تشغيلي، ولا يمكن استنتاجه من الكود وحده.

أعمال ذات صلة

جميع الأعمال

الخطوة التالية

هل تعتمد قراراتك على بيانات قد تكون خاطئة دون أن تنبّهك؟

اعمل مع فريق هندسي يصمّم لمواجهة الأعطال التي تمر دون تنبيه، ويحمي بياناتك الموجودة، ويتولى تشغيل ما يبنيه.

احجز مكالمة استكشافية

حُجبت هوية العميل · حُسب كل رقم من الكود المصدري، في نسخة يعود آخر تعديل فيها إلى مايو 2023 · أكتوبر 2026