مراقبة الأداء (Monitoring) والتنبيه عند توقف الأتمتة.

مقدمة

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

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

لفهم هذه الصورة بعمق، من المفيد الربط بين المراقبة ومفاهيم سابقة مثل لماذا نحتاج الأتمتة؟ كيف توفر الشركات آلاف الساعات، وكذلك معالجة الأخطاء (Error Handling): كيف تجعل نظامك “مضاداً للكسر”، لأن المراقبة ليست بديلاً عن المعالجة الجيدة، بل طبقة تكشف لك أين ومتى ولماذا بدأ الانهيار.

ما المقصود بمراقبة الأتمتة فعلياً؟

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

في بيئات التشغيل الحديثة، لا يكفي أن تقول إن السكربت “اشتغل”. المطلوب أن تعرف هل اكتمل المسار كاملاً؟ هل أعاد POST البيانات إلى الطرف الآخر؟ هل كانت الاستجابة 200 أم 500؟ وهل تم تحديث السجل النهائي في قاعدة البيانات أم توقف التدفق في المنتصف؟

أهم الإشارات التي يجب تتبعها

• نجاح أو فشل كل تنفيذ.
• مدة التشغيل الكلية لكل مهمة.
• عدد مرات إعادة المحاولة Retries.
• رموز الحالة من الخدمات الخارجية، ويمكن فهمها عبر رموز الحالة (HTTP Status Codes): ماذا يخبرك السيرفر بـ 200 أو 404؟.
• عدد العناصر التي تمت معالجتها فعلاً مقارنة بالمخطط لها.
• فجوات الجدولة في مهام الجدولة الزمنية (CRON Jobs): كيف تجعل السكربت يعمل وأنت نائم.

أنواع الفشل التي يجب التنبيه لها

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

الفئات العملية للأعطال

1. توقف كامل: المهمة لم تبدأ أساساً في موعدها.
2. فشل أثناء التنفيذ: انقطاع الاتصال، خطأ مصادقة، أو استجابة غير متوقعة من Endpoint.
3. نجاح زائف: المهمة اكتملت تقنياً، لكنها لم تنتج بيانات صحيحة.
4. بطء غير طبيعي: التنفيذ استغرق وقتاً أطول من الحد المقبول.
5. تضخم الطوابير: الرسائل أو السجلات المعلقة تتزايد، ما يعني أن خط المعالجة يختنق تدريجياً.

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

بنية مراقبة عملية للأتمتة

البنية الفعالة تبدأ من إنتاج سجل منظم لكل تشغيل. بدل الاكتفاء بطباعة رسائل عشوائية، أنشئ سجلات موحدة تحمل معرف التنفيذ، اسم المهمة، وقت البداية والنهاية، وعدد العناصر المعالجة، وحالة النتيجة النهائية. هنا تظهر أهمية فهم لغة الـ JSON: كيف تقرأ وتكتب البيانات التي تفهمها الآلات لأنها مثالية لحفظ سجلات قابلة للفهرسة والتحليل.

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

ماذا يجب أن يحتوي سجل التنفيذ؟

Execution Log Schema
jobName: اسم المهمة
runId: معرف فريد لكل تشغيل
startedAt: وقت البداية
finishedAt: وقت النهاية
status: success أو failed
itemsProcessed: عدد العناصر المنفذة
errorMessage: وصف الخطأ عند الفشل
upstreamStatusCode: رمز استجابة الخدمة الخارجية

مثال تطبيقي: مراقبة مهمة مجدولة وإرسال تنبيه إلى تلجرام

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

const axios = require("axios");

async function sendTelegramAlert(message) {
  const botToken = process.env.TELEGRAM_BOT_TOKEN;
  const chatId = process.env.TELEGRAM_CHAT_ID;

  await axios.post(`https://api.telegram.org/bot${botToken}/sendMessage`, {
    chat_id: chatId,
    text: message
  });
}

async function runAutomationJob() {
  const startedAt = Date.now();
  const runId = `job_${startedAt}`;

  try {
    const response = await axios.get("https://example.com/api/orders/pending", {
      headers: {
        Authorization: `Bearer ${process.env.API_TOKEN}`
      },
      timeout: 10000
    });

    const itemsProcessed = Array.isArray(response.data) ? response.data.length : 0;
    const durationMs = Date.now() - startedAt;

    console.log(JSON.stringify({
      jobName: "syncPendingOrders",
      runId,
      startedAt,
      finishedAt: Date.now(),
      status: "success",
      itemsProcessed,
      upstreamStatusCode: response.status,
      durationMs
    }));

    if (durationMs > 15000) {
      await sendTelegramAlert(`Warning: syncPendingOrders is slow (${durationMs} ms)`);
    }
  } catch (error) {
    const durationMs = Date.now() - startedAt;
    const statusCode = error.response?.status || 0;
    const errorMessage = error.response?.data || error.message;

    console.log(JSON.stringify({
      jobName: "syncPendingOrders",
      runId,
      startedAt,
      finishedAt: Date.now(),
      status: "failed",
      itemsProcessed: 0,
      upstreamStatusCode: statusCode,
      errorMessage,
      durationMs
    }));

    await sendTelegramAlert(
      `ALERT: syncPendingOrders failed | status=${statusCode} | error=${JSON.stringify(errorMessage)}`
    );
  }
}

runAutomationJob();

متى تستخدم التنبيه الفوري ومتى تستخدم التقرير الدوري؟

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

• تنبيه فوري: توقف مهمة حرجة، فشل المدفوعات، تعطل مزامنة الطلبات.
• تنبيه مجمع: ازدياد الأخطاء غير الحرجة أو بطء الأداء خلال ساعة.
• تقرير دوري: ملخص نجاحات وإخفاقات اليوم، ومتوسط أزمنة التنفيذ.

هذا التصنيف يجعل المراقبة أكثر عقلانية، خصوصاً عندما تتعامل مع عشرات التكاملات بين REST API أو GraphQL، ويمكن مراجعة الفرق بين REST و SOAP و GraphQL: متى نختار كل نوع؟ لفهم أثر طبيعة الواجهة على سلوك المراقبة والاستجابة.

دمج المراقبة مع الأمان والاعتمادية

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

كذلك، لا تجعل المراقبة نفسها نقطة فشل جديدة. إذا تعذر إرسال التنبيه إلى قناة واحدة، حاول استخدام قناة بديلة أو خزّن الحادثة لإعادة المحاولة لاحقاً. هذه الفكرة ترتبط مباشرة بمقال الـ Retries و Backoff: ماذا تفعل عندما يفشل الـ API مؤقتاً؟، لأن التنبيه أيضاً استدعاء خدمة خارجية وقد يفشل بدوره.

أفضل ممارسات عملية قبل إطلاق أي أتمتة

1. عرّف ما الذي يعنيه “النجاح” بدقة، وليس فقط انتهاء السكربت دون Exception.
2. أنشئ Heartbeat لكل مهمة مجدولة للتأكد من أنها عملت في موعدها.
3. راقب مدة التنفيذ وحدد عتبة للبطء قبل الوصول إلى الانهيار.
4. أرسل التنبيهات إلى قناة يراجعها الفريق فعلياً، لا إلى صندوق بريد مهمل.
5. اختبر سيناريوهات الفشل عمداً، مثل إبطال API Key أو تغيير Endpoint.
6. اربط السجلات بمعرفات واضحة لتسهيل التتبع بين الأنظمة المختلفة.

خاتمة

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

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