6.2مشكلات متكررة (playbook)
الأساسي في 30 ثانية
- العَرَض أولًا: إعادة إنتاج المشكلة ووصفها قبل المساس بالشيفرة أو الملفات.
- سبب محتمل، لا تخمين: يربط playbook كل عَرَض بالأسباب المعروفة والإجراء المستهدف.
- الشبكة قبل الإجراء: النسخة الاحتياطية وبيئة الاختبار تجنّبان تحويل عطل إلى فقدان بيانات.
خيط سمير — دفتر الحوادث
يحتفظ سمير بدفتر حوادث للمواقع التي يصونها. كل مدخل يسجّل العَرَض الذي يراه المستخدم، والسبب المحتمل، والإجراء الذي حلّ المشكلة. مع الأشهر، تعود نفس العائلات: صفحة بيضاء بعد تحديث، خطأ 500، محتوى مختلط، نموذج صامت، روابط 404 وطلب متوقف.
ردّ الفعل: تسمية العَرَض، التحقق من السبب، تطبيق الإجراء المستهدف — وإصلاح الأساس وراء حادث متكرر.
حادث واحد، عَرَض واحد
الخطأ الأول هو الإصلاح عشوائيًا. نبدأ بإعادة إنتاج الحادث ووصفه بدقة: أي صفحة، أي نموذج، أي مستخدم، وأي بيانات. العَرَض الواضح يختصر زمن التشخيص مسبقًا.
ردّ الفعل الصحيح: الشبكة
قبل أي تدخل محفوف بالمخاطر، نأخذ نسخة احتياطية ونعمل على نسخة عندما يكون ذلك ممكنًا. الهدف ليس تجنّب كل خطأ، بل القدرة على الرجوع دون فقدان المحتوى أو الطلبات.
البحث عن السبب، لا عن المذنب
غالبًا ما يخفي الحادث المتكرر أساسًا ناقصًا: إضافة مهجورة، تحديثات مؤجلة، نسخ احتياطية لم تُختبر قط. معالجة العَرَض لا تكفي إذا عاد السبب الشهر التالي.
| العَرَض | الأسباب المحتملة | الإجراءات |
|---|---|---|
| صفحة بيضاء بعد تحديث | تعارض إضافة، قالب غير متوافق أو ذاكرة PHP غير كافية | استعادة النسخة الاحتياطية، تعطيل الإضافات واحدة تلو الأخرى، قراءة السجلات وزيادة الذاكرة عند الحاجة (N3.1، N5.1) |
| خطأ 500 في الموقع كله | خطأ PHP قاتل، ملف .htaccess تالف أو بلوغ حد الذاكرة | مراجعة سجلات الخادم، استعادة الملف أو النسخة الاحتياطية، إصلاح الإضافة المعطوبة (N3.4، N5.1) |
| محتوى مختلط بعد الانتقال إلى HTTPS | روابط قديمة بصيغة http في قاعدة البيانات أو في قالب | استبدال الروابط، فرض HTTPS والتحقق من الموارد المحمّلة (N3.4، N5.2) |
| نموذج اتصال صامت | إرسال البريد غير مضبوط، غياب SPF/DKIM أو تعارض إضافة | ضبط SMTP، إرسال اختبار حقيقي والتحقق من مجلد الرسائل غير المرغوبة (N3.5) |
| روابط 404 بعد تغيير الروابط الدائمة | قواعد إعادة الكتابة غير مُولَّدة أو تحويلات ناقصة | إعادة حفظ الروابط الدائمة، التحقق من .htaccess وإضافة التحويلات اللازمة (N1.5، N5.2) |
| طلب متوقف أو دفع مرفوض | بوابة في وضع الاختبار، عملة أو بلد غير مضبوط، صفحة طلب معطوبة | التحقق من إعدادات WooCommerce وسجلات الدفع وإعادة طلب تجريبي (N4.1) |
نص جاهز للقول — توصيف حادث (30 ثانية)
«هل يمكنكم إخباري في أي صفحة وأي نموذج وأي مستخدم تظهر المشكلة، ومنذ متى؟ أعيد الإنتاج، أتحقق من السجلات وأصلح السبب قبل الاختبار مجددًا.»
احتفظ به لتأطير حادث مع عميل مستعجل.
نص جاهز للقول — الإعلان عن رجوع إلى الوراء (20 ثانية)
«أستعيد النسخة الاحتياطية لإعادة الموقع إلى العمل، ثم أبحث عن السبب على نسخة. يبقى الموقع العام مستقرًا خلال التشخيص.»
طمئن العميل: الرجوع إلى الوراء ليس فشلًا، بل حماية.
نموذج نسخ ولصق — بطاقة حادث
العَرَض : [صفحة / نموذج / رسالة]
المستخدم : [الملف]
منذ : [التاريخ / الوقت]
أُعيد إنتاجه : نعم / لا
السبب المحتمل : [إضافة / خادم / رابط / إعداد]
الإجراء : [الوصف]
الاختبار بعد الإصلاح : نعم / لا
النسخة الاحتياطية / الرجوع : نعم / لانموذج نسخ ولصق — ترتيب التشخيص
1. وصف العَرَض وإعادة إنتاجه
2. أخذ نسخة احتياطية قبل أي إجراء
3. قراءة سجلات الخادم وWordPress
4. العزل: إضافة، قالب، إعداد، خادم
5. الإصلاح على نسخة إن أمكن
6. اختبار المسار الكامل
7. توثيق السبب والحلموقع تعريفي
الحوادث الأكثر شيوعًا: النموذج، HTTPS، الصفحة البيضاء بعد التحديث.
متجر
إضافة الطلبات والمدفوعات ورسائل التأكيد إلى التشخيص.
موقع عالي الزيارات
مراقبة الذاكرة المؤقتة والخادم وقاعدة البيانات قبل استنتاج مشكلة في WordPress.
دون بيئة تجريب
نسخ احتياطي منهجي والتدخل في ساعات هادئة مع خطة رجوع إلى الوراء.
تحدي 48 ساعة — طبّقه غدًا
خذ ثلاثة حوادث حقيقية أو محاكاة، املأ بطاقة الحادث وطبّق ترتيب التشخيص. دوّن السبب واختبار عدم التكرار. 30 دقيقة.
- أصف العَرَض قبل التصرف.
- أربط العَرَض بسبب محتمل.
- آخذ نسخة احتياطية وأختبر بعد الإصلاح.
بعد تحديث، يعرض الموقع صفحة بيضاء. ما أول إجراء مفيد؟
الحادث المتكرر ليس حادثًا عارضًا: إنه إشارة إلى أساس يجب إصلاحه (إضافة مهجورة، تحديثات مؤجلة، نسخة احتياطية غير مختبرة).