بروفايل واحد على جهازين في الوقت نفسه: اختبار تعارض الكتابة وملكية الجلسة قبل مشاركة الفريق

المشاركة ليست مجرد إرسال ملف بروفايل

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

حدد معنى «المشاركة» في نظامك

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

ارسم حدود البيانات التي يمكن أن تتعارض

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

افصل القفل المحلي عن القفل الموزع

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

اختبر ملكية الجلسة باستخدام جيل متزايد

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

اختبار تعارض إعداد واحد

أنشئ بروفايل اختبار خاليًا من بيانات حقيقية. افتحه من جهازين أو عميلين في بيئة منفصلة وفق نموذج النظام، ثم غيّر إعدادًا غير حساس من الجهاز الأول، وفي اللحظة نفسها غيّر الإعداد ذاته من الثاني. سجّل revision لكل تعديل، والنتيجة التي عرضتها الواجهتان، والقيمة النهائية في التخزين. هل يرفض النظام الكتابة الثانية؟ هل يدمجها؟ هل يطبق last-write-wins دون تنبيه؟ لا تصف أي سياسة بأنها صحيحة دائمًا؛ المطلوب أن تكون محددة ومتوقعة ومعلنة، وأن لا تخفي فقد تعديل أحد الموظفين.

اختبار تعارض مجموعتين مستقلتين

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

ما الذي يحدث للكوكيز عند فتح جلستين؟

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

اختبار مهام الأتمتة أثناء انتقال الملكية

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

مصفوفة حالات انقطاع الشبكة

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

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

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

كيف تقدم خيارًا مفهومًا للفريق؟

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

أخطاء شائعة ومتى ترفض الادعاء بالنجاح

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

المراجع والقراءة المتصلة

لإدارة تسليم البروفايل دون فقد السياق راجع إيجي تاج: https://egytag.com/ar/articles/تسليم-بروفايل-بين-أعضاء-الفريق-بدون-فقد-السياق . أما هذا الدليل فيركز على تعارض الكتابة وملكية الجلسة المتزامنة. توضح وثائق SQLite أساليب القفل والتزامن في https://www.sqlite.org/lockingv3.html ، وتشرح PostgreSQL مفهوم التحكم المتزامن في https://www.postgresql.org/docs/current/mvcc.html . لا يعني استخدام أي قاعدة بيانات أن مشاركة مجلد متصفح حي بين جهازين آمنة تلقائيًا؛ يجب اختبار تصميم المنتج الفعلي ومسار تخزينه.