الإنتاج مشتعل في التطوير — ما هو، الأسباب وخوارزمية العمل

ماذا يعني «الإنتاج مشتعل» وأنواع الأعطال

عبارة «الإنتاج مشتعل» (كل شيء توقف) تصف حالة تكون فيها بيئة الإنتاج تعمل بشكل غير صحيح وتأثر المستخدمون. يمكن أن يظهر العطل كعدم توفر كامل للتطبيق (شاشة فارغة، خطأ 502)، عدم توفر جزئي (وحدة الدفع لا تعمل لكن الوظائف الأخرى متاحة)، أو تدهور في الأداء (تحميل بطيء جداً). شدة الحادث تحددها نسبة المستخدمين المتأثرين ومدة الانقطاع.

وفقاً لـ Atlassian Statuspage (2025)، متوسط وقت التوقف لتطبيقات الهاتف المحمول في 2024 كان 27 دقيقة لكل حادث. الأسباب الأكثر شيوعاً: تراجع الكود بعد النشر (34%)، انقطاع مزود الخدمة السحابية (22%)، مشاكل قاعدة البيانات (18%)، أخطاء التكوين (15%) وهجمات DDoS (11%). الخلاصة: معظم الأعطال ناتجة عن تغييرات قام الفريق بإدخالها بنفسه، وليس عن عوامل خارجية.

من المهم التمييز بين crash (تعطل التطبيق على جهاز العميل) وانقطاع الخلفية (عدم توفر الخادم). crash يُصلح عادةً بإصلاح سريع لكود العميل، بينما انقطاع الخلفية يتطلب تغييرات في البنية التحتية أو إعادة نشر الخدمة. مقاييس المراقبة: للعميل — معدل خلوه من الأعطال، للخادم — معدل خطأ 5xx وزمن الاستجابة p95. APM (مراقبة أداء التطبيق) — Sentry, New Relic, Datadog — يساعد في تحديد نوع العطل بسرعة.

شدة الحوادث: P0، P1، P2 ومعايير التصنيف

تصنيف موحد للشدة هو أساس الاستجابة السريعة. بدونه يضيع الفريق وقتاً في مناقشة «كم هذا عاجل» بدلاً من التصرف. المقياس الكلاسيكي: P0 (حرج) — التطبيق غير متاح كلياً أو تتسرب بيانات المستخدمين، زمن الاستجابة — فوري؛ P1 (عالي) — وظيفة حرجة لا تعمل لـ 50%+ من المستخدمين، زمن الاستجابة — 15 دقيقة؛ P2 (متوسط) — وظيفة غير حرجة غير متاحة لبعض المستخدمين، زمن الاستجابة — ساعة واحدة.

P0 يتطلب تصعيداً فورياً: مهندس المناوبة يوقف أي عمل حالي ويتحول إلى الحادث. إذا لم تُحل المشكلة خلال 10 دقائق — يتم إشراك قائد التقنية. إذا بعد 30 دقيقة — تصعيد إلى مدير الهندسة. لحوادث P0 يُسمح بانتهاك أي عمليات: عمل إصلاح سريع دون مراجعة كاملة للكود، النشر مباشرة في الإنتاج، تجاهل قواعد حماية الفروع. التجاوز الطارئ يجب أن يكون متفقاً عليه مسبقاً على مستوى الفريق.

جدول الشدة

من المهم جداً عدم الخطأ في تقدير الشدة نزولاً. حوادث P0 و P1 المصنفة كـ P2 تؤدي إلى استجابة متأخرة وزيادة وقت التوقف. القاعدة: إذا كنت في شك — اختر P0. التصنيف الزائد أفضل من التصنيف الناقص: من الأفضل عقد اجتماع إضافي بدلاً من خسارة ساعة من وقت الاسترداد.

أول 10 دقائق: خوارزمية العمل أثناء العطل

يبدأ المؤقت: من لحظة وصول تنبيه أو رسالة من مستخدم. أول 10 دقائق هي الأكثر أهمية. الخوارزمية: 1) تأكيد المشكلة — التأكد من أن المشكلة حقيقية (ليست إنذاراً كاذباً)؛ 2) إيقاف النزيف — تقليل التأثير فوراً (تراجع، مفتاح ميزة، حجب نقطة النهاية)؛ 3) التواصل — الكتابة في القناة العامة #incident: ما حدث، الشدة، ما يتم فعله. أول 10 دقائق لا تُقضى في تحليل السبب الجذري.

بالتوازي مع إيقاف النزيف، يبدأ مهندس واحد التشخيص وآخر يتولى التواصل. قنوات التواصل: قناة Slack #incident (للفريق)، صفحة الحالة (للمستخدمين)، البريد الإلكتروني/الرسائل النصية للتصعيد (للإدارة). كل 15 دقيقة — تحديث للحالة بمعلومات: ما المعروف، ما يتم فعله، وقت الاسترداد المقدر. صفحة الحالة (StatusPage, Statuspal) تعرض وقت التشغيل وتاريخ الحوادث للمستخدمين الخارجيين.

كيفية إيقاف النزيف: التراجع، مفتاح الميزة والإصلاح السريع

أول وأهم قاعدة: لا تحاول إصلاح المشكلة في الإنتاج. إذا تسبب إصدار جديد في العطل — تراجع إلى الإصدار المستقر السابق. إذا كان العطل ناتجاً عن ميزة محددة موجودة خلف مفتاح ميزة — simplemente قم بتعطيل المفتاح. إذا لم يكن التراجع ولا المفتاح متاحين — قم بإصلاح سريع بأقل تغيير. التراجع هو الخيار الأكثر أماناً لأنه يعيد إلى حالة كانت تعمل بالفعل.

مفتاح الميزة (feature flag) هو أداة قوية لإيقاف النزيف دون نشر. إذا انهارت وحدة الدفع ولكنها معطلة عبر المفتاح — المستخدمون ببساطة لا يرون زر الدفع بدلاً من تلقي شاشة خطأ. المفتاح لا يتطلب بناء، لا يتطلب مراجعة المتجر، ويعمل في ثوانٍ. كل ميزة حرجة يجب أن تكون خلف مفتاح ميزة مع إمكانية التعطيل على مستوى الخادم (تكوين عن بعد). مفتاح الميزة — خط الدفاع الأول.

إذا كان التراجع مستحيلاً (مثلاً، بسبب ترحيل قاعدة بيانات غير قابل للعكس) ولا يوجد مفتاح — الملاذ الأخير: إصلاح سريع بأقل تغيير. يتم إنشاء الإصلاح السريع من أحدث علامة إصدار، ويحتوي فقط على الأسطر اللازمة لإصلاح العطل، ويمر عبر نشر سريع (انظر مقال «الإصلاح السريع — التصحيحات العاجلة»). القاعدة الذهبية: بعد الاستقرار، قم دائماً بتحليل السبب الجذري، حتى لو بدا السبب واضحاً.

تشخيص الأسباب: السجلات، المقاييس والتنبيهات

بعد إيقاف النزيف (أو بالتوازي، إذا كان عدد المهندسين يسمح) يبدأ التشخيص. المصدر الأول — السجلات. التسجيل المركزي (ELK, Grafana Loki, Datadog Logs) يتيح العثور على الأخطاء حسب الطابع الزمني أو معرف المستخدم أو معرف الطلب. مهم: يجب أن تكون السجلات منظمة (JSON) لكي يعمل grep بسرعة. التسجيل المنظم هو متطلب إلزامي لجميع الخدمات.

المصدر الثاني — المقاييس. Grafana, Datadog, New Relic تظهر متى حدثت قمة الأخطاء، على أي نقاط نهاية وبأي رموز حالة. مقارنة المقاييس قبل وبعد النشر تساعد في تحديد المشكلة إلى خدمة أو نقطة نهاية محددة. مقاييس RED (Rate, Errors, Duration) — معيار مراقبة الخدمات المصغرة.

المصدر الثالث — التتبع الموزع (distributed tracing). Jaeger, Zipkin, Datadog APM تظهر مسار الطلب عبر الخدمات المصغرة وتحدد أين بالضبط حدث التأخير أو الخطأ. التتبع مفيد بشكل خاص في الأعطال المتتالية، عندما يتسبب عطل في خدمة واحدة في أخطاء في جميع الخدمات المعتمدة. معرف التتبع يجب أن ينتقل من العميل إلى جميع خدمات الخلفية.

# مثال تشخيص سريع باستخدام kubectl والسجلات
# عرض الحاويات التي بها أخطاء
kubectl get pods --field-selector=status.phase!=Running

# التحقق من سجلات الحاوية المنهارة
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# البحث عن أخطاء في الخدمة لآخر 30 دقيقة
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

مهم: لا تحاول تشخيص السبب قبل إيقاف النزيف. إذا كان 50% من المستخدمين يرون عطلاً — قم بالتراجع أولاً، ثم حلل. استثناء: إذا كان التراجع سيستغرق وقتاً أطول من الإصلاح السريع المباشر (مثلاً، بسبب عدم توافق البيانات). في هذه الحالة، طبق الإصلاح السريع فوراً وقم بتحليل ما بعد الحادث بعد الاستقرار. التشخيص قبل الإصلاح هو نمط خطير يزيد من وقت التوقف.

تحليل ما بعد الحادث: كيفية مراجعة الحوادث دون إلقاء لوم

تحليل ما بعد الحادث (post-mortem) هو مراجعة منظمة للحادث تُجرى بعد 24–72 ساعة من حله. الهدف: فهم لماذا حدث العطل، ولماذا لم تكتشفه المراقبة والاختبارات قبل الإنتاج، وما الذي يجب تغييره في العمليات لمنع التكرار. ثقافة بدون إلقاء لوم هي مبدأ أساسي: يناقش تحليل ما بعد الحادث العمليات والأدوات والتواصل، وليس أخطاء أشخاص محددين.

هيكل وثيقة تحليل ما بعد الحادث: التسلسل الزمني (تسلسل الأحداث بالأوقات)، التأثير (المستخدمون المتأثرون، المدة، الخسائر المالية)، السبب الجذري (السبب التقني الرئيسي)، الاكتشاف (كيف تم اكتشافه، لماذا لم يُكتشف مبكراً)، الاستجابة (ما تم فعله، ما كان يمكن فعله بشكل أسرع)، إجراءات (مهام محددة مع مسؤولين ومواعيد نهائية). الإجراءات يجب أن تكون S.M.A.R.T.: محددة، قابلة للقياس، قابلة للتكليف، واقعية، محددة زمنياً.

الإجراءات النموذجية بعد عطل إنتاج: إضافة مراقبة وتنبيه للمقياس الذي كان صامتاً؛ توسيع تغطية الاختبار للحالة المفقودة؛ إضافة صفحة إلى دليل العمل بخوارزمية خطوة بخطوة لحالة مماثلة؛ تدريب الفريق على الأداة التي استُخدمت بشكل غير صحيح. كل إجراء هو تغيير ملموس يقلل من احتمال تكرار الحادث.