سجل تشغيل قابل لإعادة التحليل: كيف تحقق في مهام المتصفح دون إعادة آثارها؟

إعادة التحليل ليست إعادة تنفيذ الأوامر

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

ما الذي يجب أن يمثله الحدث؟

الحدث ليس سطرًا يقول «تم النقر» فحسب. يحتاج معرف تشغيل runId، ومعرف خطوة stepId، ورقم محاولة attempt، وطابعًا زمنيًا، ونسخة تعريف سير العمل، ونوع الحدث، والنتيجة، ومراجع إلى المدخلات والمخرجات المناسبة. عند محاولة فتح صفحة، قد تسجل بدء الملاحة ونتيجة الاستجابة وحالة التبويب. وعند قرار النقر، تسجل وصف الهدف وعدد التطابقات وسبب اختيار العنصر. لا تضع كلمات مرور أو Cookies أو رموز وصول داخل الحدث؛ استبدلها بمعرفات مرجعية أو قيم منقحة. الهدف أن يكون السجل مفيدًا دون أن يتحول إلى نسخة من أسرار المستخدم.

اجعل ترتيب الأحداث قابلًا للفهم

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

ثبت نسخة سير العمل ومدخلاته

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

حدد ما الذي يمكن إعادة بنائه حتميًا

بعض القرارات حتمية إذا امتلكت المدخلات نفسها، مثل الانتقال من حالة pending إلى completed عند وصول حدث نجاح موثق. لكن قراءة DOM حي أو استجابة API أو رقم عشوائي أو ساعة النظام ليست مدخلات ثابتة. عند Replay تحليلي استخدم النتائج المحفوظة لتلك القراءات، ولا تطلبها من الموقع مجددًا. وإذا كانت معلومة أساسية غير مسجلة، ضع علامة «لا يمكن إعادة البناء» بدل تخمينها. هذه الصراحة تجعل السجل دليلًا تشخيصيًا لا قصة مفبركة. يمكن الاحتفاظ بلقطة محدودة من DOM أو مرجع إلى صورة عند نقاط القرار الحساسة، مع احترام الخصوصية.

فصل النية عن النتيجة

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

كيف تسجل المحاولات المتكررة؟

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

أضف لقطات حالة عند نقاط مختارة

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

صمم قارئ Replay لا يملك تنفيذًا مباشرًا

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

ماذا تفعل عند فجوة في الأحداث؟

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

مصفوفة حقول عملية

ابدأ بحقول ثابتة: runId و stepId و attempt و sequence و eventType و timestamp و source و workflowVersion و outcome. أضف حقولًا اختيارية مثل tabId و profileRef و targetLocator و responseStatus و externalOperationId و evidenceRef. لا تضع تفاصيل الشبكة كلها في كل حدث؛ اجعلها مراجع إلى أثر تشخيصي محفوظ عند الحاجة. احرص على أن يتضمن كل حدث نسخة schemaVersion لتتمكن من قراءة السجلات القديمة بعد تحديث التطبيق. وإذا أضفت حقلًا جديدًا فلا تغير معنى الحقول القديمة بصمت؛ استخدم ترحيلًا واضحًا أو قارئًا يدعم الإصدارات المختلفة.

اختبر القارئ قبل الاعتماد عليه

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

المصادر والروابط الداخلية

تقدم OpenTelemetry نموذجًا موحدًا لبيانات السجلات في https://opentelemetry.io/docs/specs/otel/logs/data-model/ ، وتشرح Temporal مفاهيم سجل أحداث تنفيذ سير العمل في https://docs.temporal.io/workflow-execution . يمكن قراءة دليل إيجي تاج عن سجل خطوات Workflow في https://egytag.com/ar/articles/كيف-تصمم-workflow-يترك-سجلا-واضحا-لكل-خطوة-topic-20261016-02 ، ودليل منع تشغيل المهمة مرتين في https://egytag.com/ar/articles/تصميم-scheduler-يمنع-تشغيل-نفس-المهمة-مرتين . الخلاصة: اجمع أدلة كافية لإعادة تفسير القرار، واحتفظ بحالة «غير معروف» عند نقص الدليل، ولا تخلط التحليل الآمن بإعادة تنفيذ الآثار الحية.