ماذا يحدث بعد نشر الواجهة الأمامية؟ مراقبة فعّالة تعمل حقًا

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

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

لماذا لا تكفي مراقبة الخادم للواجهة الأمامية

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

أخطاء الواجهة الأمامية مختلفة. قد ترمي JavaScript استثناءً فقط على Safari 15 يعمل على iPhone قديم مع اتصال بطيء. قد تنجح استدعاءات API، لكن منطق العرض ينكسر بصمت بسبب فشل تحميل سكربت طرف ثالث. يرى المستخدم صفحة فارغة أو مؤشر تحميل عالق، لكن خادمك لا يعلم بوجود أي خطأ.

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

معدل الخطأ في المتصفح: الإشارة الأولى

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

تشمل الأمثلة الشائعة:

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

لالتقاط هذه الأخطاء، تحتاج إلى أداة مراقبة مستخدم حقيقي (RUM) تجمع الاستثناءات وتتبعات المكدس وسياق المتصفح من المستخدمين الفعليين. أدوات مثل Sentry أو Datadog RUM أو New Relic Browser تعمل عن طريق إضافة سكربت صغير إلى صفحتك يعترض الأخطاء غير المعالجة ويرسلها إلى مجمع مركزي.

إليك مثال بسيط لكيفية إعداد معالج أخطاء عام والتقاط أداء تحميل الصفحة في تطبيقك:

// Global error handler for uncaught exceptions
window.onerror = function (message, source, lineno, colno, error) {
  const errorData = {
    message: message,
    source: source,
    line: lineno,
    column: colno,
    stack: error ? error.stack : null,
    url: window.location.href,
    userAgent: navigator.userAgent
  };
  // Send error data to your monitoring endpoint
  fetch('/api/log-error', {
    method: 'POST',
    body: JSON.stringify(errorData),
    headers: { 'Content-Type': 'application/json' }
  });
};

// Capture page load performance
window.addEventListener('load', function () {
  const perfData = window.performance.timing;
  const pageLoadTime = perfData.loadEventEnd - perfData.navigationStart;
  console.log('Page load time (ms):', pageLoadTime);
  // Send to monitoring service
  fetch('/api/log-performance', {
    method: 'POST',
    body: JSON.stringify({ loadTime: pageLoadTime, url: window.location.href }),
    headers: { 'Content-Type': 'application/json' }
  });
});

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

وقت تحميل الصفحة: ما يشعر به المستخدمون فعليًا

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

يعتمد وقت تحميل الصفحة على عدة عوامل:

  • حجم حزم JavaScript الخاصة بك
  • عدد طلبات الشبكة التي تقوم بها صفحتك
  • سرعة شبكة المستخدم وزمن الوصول
  • قوة معالجة الجهاز
  • كيفية تعامل شفرتك مع العرض والتفاعل

يمكن لأدوات RUM أن تظهر لك توزيع أوقات التحميل عبر قاعدة المستخدمين بأكملها. قد ترى أن المستخدمين في منطقة واحدة يعانون من أوقات تحميل تبلغ 3 ثوانٍ بينما ينتظر المستخدمون في منطقة أخرى 8 ثوانٍ. أو أن مستخدمي الأجهزة المحمولة على شبكات 3G لديهم تجربة مختلفة تمامًا عن مستخدمي سطح المكتب على الألياف البصرية.

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

تفاعل المستخدم: هل عمل الزر فعليًا؟

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

هنا يأتي دور المراقبة التركيبية (Synthetic Monitoring). تكتب سكربتات آلية تحاكي رحلة مستخدم عبر تطبيقك. ينقر السكربت على الأزرار، ويملأ النماذج، ويتنقل بين الصفحات، ويتحقق من أن كل خطوة تكتمل بنجاح.

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

  1. تحميل الصفحة الرئيسية
  2. البحث عن منتج
  3. إضافة المنتج إلى السلة
  4. الانتقال إلى الدفع
  5. ملء تفاصيل الشحن
  6. إرسال الطلب
  7. التحقق من ظهور صفحة تأكيد الطلب

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

المراقبة التركيبية ليست بديلاً عن RUM. إنها تعطيك فحوصات محكومة وقابلة للتكرار، لكنها لا تلتقط التنوع الكامل لبيئات المستخدم الحقيقية. استخدم كلاهما معًا.

دمج المراقبة في خط أنابيب النشر

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

إليك تسلسل عملي:

  1. نشر النسخة الجديدة من الواجهة الأمامية إلى الإنتاج
  2. انتظار انتشار CDN (عادة بضع دقائق)
  3. تشغيل مجموعة من الاختبارات التركيبية ضد روابط الإنتاج المباشرة
  4. الانتظار من خمس إلى عشر دقائق لتجميع بيانات RUM من المستخدمين الحقيقيين
  5. التحقق من معدل الخطأ ومقاييس وقت التحميل مقابل حدودك
  6. إذا تجاوز أي مقياس الحد، قم بتشغيل تراجع تلقائي أو إخطار فريق الاستجابة

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

قائمة تحقق عملية لمراقبة إصدار الواجهة الأمامية

  • تثبيت أداة RUM تلتقط أخطاء JavaScript وأوقات التحميل وسياق المتصفح
  • إعداد تنبيهات لتغيرات معدل الخطأ بعد كل نشر
  • إنشاء اختبارات تركيبية لرحلات المستخدم الحرجة
  • تشغيل الاختبارات التركيبية تلقائيًا بعد كل نشر
  • تحديد حدود مقبولة لمعدل الخطأ ووقت التحميل
  • تكوين تراجع تلقائي أو إخطار عند تجاوز الحدود
  • مراجعة بيانات المراقبة بانتظام لرصد الاتجاهات، وليس فقط الحوادث

الخلاصة

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