٤ — الصيانة والأعطال

ما الذي يجب أن يُنسَخ احتياطيًّا

ثلاثة أشياء، وفقدان أيّها له أثر مختلف:

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

ووحدة hr_data تحمل .instance_id الذي يرتبط به الترخيص، لا البيانات فحسب.

الطبقة المجانية في أوراكل بلا SLA. النسخة الاحتياطية خارج الخادم — لا لقطة على نفس المضيف.

تحديث النظام لكل المستأجرين

docker build -t hr_system:latest .

ثم أعد نشر stacks المستأجرين من Portainer. لأن الجميع يعمل على صورة واحدة مشتركة، البناء مرة واحدة يكفي — وهذا نصف سبب توحيد الصورة.

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

نقل مستأجر قائم إلى خادم الحاويات

الخطر الحقيقي ليس في البيانات بل في أجهزة البصمة.

كل جهاز عند العميل مضبوط على عنوان خادم. بعد النقل:

• جهاز مضبوط على الدومين (<الشركة>.onz.one/iclock) يتبع الـ DNS تلقائيًّا ولا يحتاج لمسًا.
• جهاز مضبوط على IP:منفذ مباشرةً ينقطع لحظة النقل، ويحتاج تعديلًا يدويًّا عند العميل.

افحص إعداد ADMS داخل كل جهاز قبل تحديد موعد النقل. جهاز منقطع يعني بصمات ضائعة، والبصمات تدخل الأجر.

الترتيب الآمن: مستأجر تجريبي جديد على الخادم الجديد أولًا، بشهادة اختبارية، دون لمس ما يعمل. ثم انقل الباقي واحدًا واحدًا.

أعطال متكرّرة

الحاوية تقلع ثم تسقط

راجع سجلّها في Portainer. الأشيع: الصورة غير موجودة، أو معمارية خاطئة (صورة x86 على خادم ARM — انظر الخادم).

port is already allocated

في مسار بلِسك وحده. شيء آخر على الخادم يمسك المنفذ. المخصِّص يقرأ ss -Hltn قبل الحجز، فإن حدث هذا فالأرجح أن SSH كان مقطوعًا وقتها وسُجِّل في السجل.

في مسار Traefik لا معنى لهذا الخطأ — لا حاوية تنشر منفذًا.

المستأجر يعطي 502

الحاوية ساقطة أو ليست على شبكة tenants. Traefik وجد الموجّه ولم يجد خلفيّةً حيّة.

رفع ملف كبير في اللوحة يقول «CSRF غير صالح»

ليس CSRF. تجاوُز post_max_size يجعل PHP يرمي جسم الطلب كله، فيصل $_POST فارغًا ويبدو كهجوم. CsrfMiddleware يكشف هذه الحالة ويشرحها، لكن إن رأيتها في مسار قديم فارفع post_max_size وupload_max_filesize في php.ini، أو انشر الإصدار برابط بدل الرفع.

أمر بلِسك «نجح» ولم يفعل شيئًا

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

بقيت هذه بلا حلّ بعد

توثيق أمين يقول ما لا يفعله النظام:

• لا تنبيه حين يسقط جهاز بصمة. لا معالجة لـ devicestatus، فلا تعرف بالانقطاع إلّا بالصدفة أو من التقارير.
• لا سجلّ لأعطال الجهاز. errorlog غير معالَج.
• لا منع لتكرار البصمة. لا قيد فريد على attendance_records: إعادة إرسال دفعة — بعد انقطاع شبكة أو إعادة تشغيل — تُدخل البصمة مرتين. الأثر مالي مباشر: بصمة خروج مكرّرة تغيّر ساعات العمل، والساعات تدخل الأجر. الإصلاح قيد فريد على (employee_id, check_time, device_id) مع INSERT OR IGNORE.
• قوالب ناقصة عند العميل القائم: خمسة قوالب محفوظة لأربعة عشر مستخدمًا. تسعة موظفين بصمتهم على الجهاز وحده. القدرة مبنية والقوالب لم تُسحب فحسب — أقرب فجوة للإغلاق فورًا.