دليل الحوادث لتطبيقات بدون كود: اكتشاف، فرز، استعادة

ما هو هذا الدليل ومتى تستخدمه

الحادث هو أي مشكلة غير متوقعة تمنع الناس من استخدام تطبيقك، تجعله بطيئًا بشكل مؤلم، أو تعرض البيانات للخطر. في التطبيقات بدون كود، قد يظهر ذلك على شكل فشل مفاجئ في تسجيل الدخول، شاشات مكسورة بعد تغيير، أتمتات خلفية توقفت عن العمل، أخطاء في واجهات برمجة التطبيقات، أو سير عمل "ناجح" يكتب قيمًا خاطئة في قاعدة البيانات بصمت.

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

هذا الدليل مخصّص لأي شخص يتعامل مع التطبيق عندما تسير الأمور بشكل خاطئ: البنّاءون الذين ينشرون تغييرات، مسؤولو التشغيل أو المنصة الذين يديرون النشر والوصول، فرق الدعم التي تتلقى التقارير أولاً، ومالكو المنتج أو الأعمال الذين يقيّمون الأثر والأولويات.

هو خفيف المقاس عمدًا، ومناسب للفرق التي تبني على منصات مثل AppMaster حيث قد يكون لديك منطق بصري، خدمات مولدة، وخيارات نشر متعددة.

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

لا يغطي إعادة تصميم بُنية طويلة الأمد، تحريات أمنية عميقة، أو إجراءات امتثال معقدة. إذا كنت تتعامل مع بيانات منظّمة أو بنية تحتية حرجة، أضف خطوات أشد صرامة فوق هذا الدليل.

قبل أن يتعطل أي شيء: حدّد خط الأساس والأدوار

تشعر الحوادث بالفوضى عندما لا تعرف كيف يبدو "المعتاد". حدّد خط الأساس حتى يتمكن الفريق من اكتشاف المشاكل الحقيقية بسرعة. لإحدى تطبيقات بدون كود، إشارات البدايات عادة تأتي من مزيج صحة المنصة، مقاييس الأعمال، والناس.

اكتب الإشارات التي ستراقبها يوميًا، ليس فقط أثناء الانقطاعات. من الشائع مراقبة مدة التشغيل، معدل الأخطاء، البطء في الشاشات، تسجيلات الدخول الفاشلة، فشل المدفوعات، وارتفاع تذاكر الدعم أو رسائل المستخدمين.

عرف شدة الحوادث بلغة بسيطة حتى يمكن لأي شخص استخدامها:

• SEV1: معظم المستخدمين لا يستطيعون استخدام التطبيق، أو المال/الأمن في خطر.
• SEV2: ميزة رئيسية معطلة، لكن هناك حل بديل.
• SEV3: مشكلات طفيفة، مستخدمون محدودون، أو أخطاء تجميلية.

حدد أهداف استجابة تُبقي وتيرة العمل. أمثلة للأهداف: التأكيد خلال 5 دقائق، نشر التحديث الأول خلال 15 دقيقة، والسعي لاستقرار خلال 60 دقيقة (حتى إن كان الإصلاح الكامل يستغرق أطول).

قرّر الأدوار قبل أن تحتاجها. سمِّ من يمكنه إعلان الحادث، ومن يقوده، ومن يكون احتياطيًا إن كان ذلك الشخص غير متاح. في فرق AppMaster، غالبًا ما يكون هذا الشخص هو صاحب منطق Business Process، بالإضافة إلى احتياطي يمكنه التعامل مع النشر أو التصدير.

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

الكشف والتأكد: هل هذا حقيقي وما مدى سوءه

أكد الأثر قبل أن تشرع في النظر إلى لوحات المراقبة. اطلب سؤالًا واضحًا واحدًا: من لا يمكنه فعل ماذا الآن؟ "فريق الدعم لا يمكنه فتح التذاكر" أكثر فائدة من "التطبيق بطيء". إن أمكن، أعد إنتاج المشكلة باستخدام نفس الدور والجهاز مثل المستخدم المتأثر.

بعد ذلك، حدّد مدى الانتشار. هل هو حساب واحد، شريحة عملاء، أم الجميع؟ اجعل الانقسامات السريعة: المنطقة، نوع الحساب، الويب مقابل المحمول، وميزة واحدة مقابل التطبيق كله. في أدوات بدون كود، قد يبدو الشيء عالميًا بينما هو في الحقيقة قاعدة أذونات أو شاشة واحدة معطلة.

ثم تحقق مما تغير. ارجع 1-2 ساعات للوراء بحثًا عن نشر، تبديل إعداد، تعديل مخطط قاعدة بيانات، أو استيراد بيانات. على منصات مثل AppMaster، تغييرات في العمليات التجارية، نماذج البيانات، أو إعدادات المصادقة قد تؤثر على عدة تدفقات دفعة واحدة حتى إن بدا واجهة المستخدم سليمة.

قبل أن تُحمّل تطبيقك اللوم، استبعد الاعتماديات الخارجية. قد تفشل مزودات البريد/الرسائل، المدفوعات (مثل Stripe)، والتكاملات (Telegram، خدمات AWS، واجهات AI) أو تُقيّد الطلبات. إذا تعطل التطبيق فقط عند إرسال رسائل أو تحصيل دفعات، فالمشكلة قد تكون أعلى في السلسلة.

استخدم قائمة قرار بسيطة:

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

بمجرد تصنيف الشدة والنطاق، يمكنك الانتقال من "هل هو حقيقي؟" إلى "ماذا نفعل أولًا؟" دون تخمين.

فرز الخطوات (أول 30 دقيقة)

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

عيّن الأدوار حتى لا يتداخل العمل. حتى في فريق صغير، تسمية المالكين تقلل الأخطاء تحت الضغط. على الأقل ستحتاج:

• قائد الحادث: يحافظ على التركيز، يحدد الأولويات، ويقرّر الاحتواء مقابل الاسترجاع
• المنفّذ: يحقق ويطبق التغييرات
• التواصل: ينشر التحديثات لأصحاب المصلحة والدعم
• كاتب الملاحظات: يسجل الإجراءات، الأوقات، والنتائج

اكتب أمرين واضحين: ما تعرفه يقينًا، وما هي فرضيتك الحالية. "المعروف" قد يكون: معدل الأخطاء ارتفع، نقطة نهاية محددة تفشل، المتأثر فقط هو المحمول. الفرضية قد تكون خاطئة، لكنها يجب أن توجه الاختبار التالي. حدّث كلاهما أثناء التعلم.

أثناء عدم الاستقرار، ضع وتيرة تحديث كل 15 دقيقة. إن لم يتغير شيء، اذكر ذلك. التحديثات المنتظمة توقف النقاشات الجانبية وتمنع تكرار أسئلة "أية أخبار؟".

اختر أول إجراء احتواء. الهدف تقليل الضرر بسرعة، حتى لو لم تعرف السبب الجذري بعد. التحركات الأولى النموذجية تتضمن إيقاف الوظائف الخلفية، تعطيل علم ميزة محفوف بالمخاطر، تحديد الحركة إلى وحدة معينة، أو التبديل إلى إعداد معروف آمن. في AppMaster، غالبًا ما يعني هذا إيقاف تدفق معين في Business Process Editor أو إخفاء مسار واجهة المستخدم الذي يسبب الفشل مؤقتًا.

إذا لم يحسّن الاحتواء المقاييس خلال فترة واحدة من الإيقاع، ابدأ تخطيط الاسترجاع بالتوازي.

استقرار أولًا: احتواء الأثر

بمجرد تأكيد أنه حادث حقيقي، انتقل من "البحث عن الخطأ" إلى "إيقاف النزيف". الاستقرار يشتري لك وقتًا. كما يحمي المستخدمين والإيرادات والبيانات أثناء التحقيق.

ابدأ بأصغر تغيير يقلل الضرر. غالبًا ما يكون الاحتواء أسرع من إصلاح كامل لأنك تستطيع تعطيل ميزة جديدة، إيقاف سير عمل، أو حجب مسار إدخال محفوف بالمخاطر دون إعادة بناء.

إذا كنت تشك في فساد البيانات، أوقف الكتابات أولًا. قد يعني ذلك تعطيل النماذج مؤقتًا، إيقاف الأتمتة التي تحدث سجلات، أو حجب نقطة نهاية API التي تستقبل تحديثات. قراءة البيانات الخاطئة مؤلمة، لكن الكتابة الخاطئة تضاعف عمل التنظيف.

إذا كان المستخدمون مقفلين خارج التطبيق، اعتبر تسجيل الدخول أولوية قصوى. تحقق من إعدادات المصادقة وتدفق الدخول قبل أي شيء آخر. كل إصلاح آخر أبطأ إذا كان المستخدمون (وفريقك) لا يستطيعون الوصول إلى التطبيق.

إن كان التطبيق بطيئًا أو يتوقف، قلل الحمل وأزل المسارات المكلفة. أوقف الشاشات الثقيلة، أوقف الوظائف الخلفية، وعطّل التكاملات الجديدة التي تسبّب ارتفاع الطلبات. في AppMaster، قد يكون الاحتواء بسيطًا مثل تعطيل Business Process إشكالي أو إزالة إجراء واجهة مستخدم يطلق سلسلة مكلفة.

اجعل الإجراءات متعمدّة وموثّقة. تحت الضغط، يكرر الفريق خطوات أو يلغي إصلاحًا عن طريق الخطأ. دون كل تغيير والنتيجة.

تسلسل استقرار بسيط:

• أوقف عمليات الكتابة إن كان الفساد ممكنًا، وتأكد أن السجلات الجديدة لم تعد تتغير.
• عطّل علم الميزة أو الأتمتة أو التكامل الأحدث في الجدول الزمني.
• احمِ الوصول: استعد تسجيل الدخول والجلسات للمدراء أولًا، ثم لجميع المستخدمين.
• قلّل الحمل بإيقاف وظائف الدُفعات وإزالة أباطأ مسار مستخدم.
• سجّل كل إجراء بالطابع الزمني والمالك والأثر الملاحظ.

الهدف أن تكون "آمنًا وقابلًا للاستخدام"، لا "محلولًا بالكامل". بمجرد احتواء الأثر، يمكنك تشخيص بهدوء واختيار الاسترجاع أو الإصلاح المناسب.

خيارات الاسترجاع وفحوص المخاطر

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

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

استخدم هذه فحوص المخاطر لتقرر إن كان الاسترجاع آمنًا:

• تغييرات في مخطط قاعدة البيانات: قد يفشل الاسترجاع إذا كانت النسخة القديمة تتوقع جداول أو حقول مختلفة.
• الكتابات غير القابلة للعكس: رد الأموال، تغييرات الحالة، أو رسائل مرسلة لا يمكن التراجع عنها.
• الوظائف المجمعة والويب هوكس: قد تعيد المنطق الأقدم معالجة عناصر أو تفشل على حمولات جديدة.
• الاعتماديات الخارجية: قد يكون سلوك المدفوعات، البريد/الرسائل، أو تكاملات Telegram قد تغيّر.

ضع قاعدة بسيطة للمضي/التوقف قبل أي تغيير. اختر 2-3 مقاييس يجب أن تتحسن خلال 10-15 دقيقة بعد الإجراء، مثل معدل الأخطاء، نجاح تسجيل الدخول، إتمام الدفع، أو زمن استجابة API. إن لم تتحرك بالطريقة الصحيحة، أوقف وفكّر في استراتيجية بديلة.

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

التواصل أثناء الحادث

الصمت يُفاقم الحوادث. استخدم طريقة بسيطة ومتكرّرة لإبقاء الناس مطّلعين بينما يحقق الفريق.

ابدأ بتحديثات داخلية. أخبر من سيتلقون الأسئلة أولًا، ومن يمكنه إزالة العوائق. اجعلها قصيرة وموضوعية. عادة ما تحتاج إلى:

• الدعم أو نجاح العملاء: ماذا يرى المستخدمون وماذا يقولون الآن
• المبيعات أو فرق الحسابات: أي حسابات متأثرة وماذا لا تعدّ به
• البنّاءون/الهندسة: ما الذي تغير، ما الذي يُسترجع، ومن يعمل عليه
• جهة اتصال تنفيذية: الأثر، المخاطر، ووقت التحديث التالي
• مالك واحد يوافق الصياغة الخارجية

للتحديثات الخارجية، التزم بما تعرفه. تجنّب التكهن بالسبب أو لوم بائع. المستخدمون أساسًا يريدون ثلاثة أشياء: التأكيد، الأثر، ومتى ستحدثهم مرة أخرى.

قوالب رسائل بسيطة

احفظ سطر حالة واحد متسق عبر القنوات:

• الحالة: قيد التحقيق | محدد | جارٍ التخفيف | قيد المراقبة | مُحل
• الأثر: "بعض المستخدمين لا يستطيعون تسجيل الدخول" أو "المدفوعات تفشل للطلبات الجديدة"
• الحل المؤقت: "أعد المحاولة خلال 10 دقائق" أو "استخدم التطبيق المحمول بينما الويب متوقف" (فقط إن كان صحيحًا)
• التحديث التالي: "التحديث التالي الساعة 14:30 بتوقيت UTC"

إذا كان المستخدمون غاضبين، اعترف أولًا ثم كن محددًا: "نعلم أن إتمام الشراء يفشل لبعض العملاء. نحن نسترجع التغيير الأخير الآن. التحديث التالي خلال 30 دقيقة." لا تعد بمواعيد نهائية أو ائتمانات أو إصلاحات دائمة أثناء الحادث.

محلول أم مراقبة

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

تشخيص السبب: فحوص سريعة تضيق الاحتمالات

بمجرد استقرار الأمور، انتقل من إطفاء الحرائق إلى جمع أقل مجموعة من الحقائق التي تشرح الأعراض. الهدف ليس السبب الجذري المثالي، بل سبب محتمل يمكنك التصرف بناءً عليه دون تفاقم الحادث.

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

فحوص سريعة (15 دقيقة)

نفّذ رحلة مستخدم حقيقية واحدة من البداية للنهاية بحساب اختبار عادي. هذه غالبًا أسرع إشارة لأنها تلمس الواجهة، المنطق، قاعدة البيانات، والتكاملات.

ركّز على مجموعة صغيرة من الفحوص:

• إعادة إنتاج رحلة واحدة: تسجيل دخول، تنفيذ الإجراء الرئيسي، وتأكيد النتيجة.
• تحديد الخطوة البطيئة/الفاشلة: تحميل الصفحة، نداء API، حفظ في قاعدة البيانات، أو webhook.
• فحص البيانات الحديثة: مسح آخر 20-50 سجلًا للبحث عن مكررات، حقول مفقودة، أو إجماليات غير متوافقة.
• التحقق من التكاملات: محاولات الدفع الأخيرة (مثل Stripe)، تسليم الويب هوكس، وأي رسائل (بريد/رسائل قصيرة أو Telegram).
• تأكيد سياق التغيير: ماذا نُشر، نُكوّن، أو نُهجر قبل الارتفاع مباشرة؟

إذا كنت على AppMaster، فإن هذا غالبًا يترجم بسهولة إلى خطوة Business Process، تغيير Data Designer، أو تغيير إعداد النشر.

القرار: الإبقاء على التخفيف أم إصلاح للأمام

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

سيناريو مثال: فشل نشر أثناء ساعات العمل

الساعة 10:15 صباحًا يوم ثلاثاء. فريق ينشر تغييرًا صغيرًا على بوابة عملاء مبنية على AppMaster. في غضون دقائق، يبدأ المستخدمون برؤية صفحات بيضاء بعد تسجيل الدخول، وتتوقف الطلبات الجديدة عن الوصول.

يلاحظ الدعم ثلاث تذاكر بنفس الرسالة: "تسجيل الدخول يعمل، ثم البوابة لا تحمل أبدًا." في نفس الوقت، تُظهر المراقبة ارتفاعًا في أخطاء 500 على التطبيق الويب وانخفاضًا في نداءات API الناجحة. تعامل معها كحادث حقيقي.

يقوم قائد الحادث بتأكيد سريع: جرّب تسجيل الدخول كمستخدم اختبار على سطح المكتب والمحمول، وتحقق من وقت آخر نشر. التوقيت يطابق النشر، لذا تفترض أن التغيير الأخير متورط حتى يثبت العكس.

قد تبدو أول 30 دقيقة هكذا:

• احتواء: ضع البوابة في وضع صيانة (أو عطّل علم الميزة المتأثر مؤقتًا) لإيقاف المزيد من المستخدمين عن الوصول إلى التدفق المكسور.
• اتخاذ قرار الاسترجاع: إذا بدأ الفشل مباشرة بعد النشر ويؤثر على عدد كبير من المستخدمين، استرجع أولًا.
• التواصل: انشر تحديثًا داخليًا قصيرًا (ما الذي تعطل، الأثر، الإجراء الحالي، وقت التحديث التالي). أرسل رسالة مختصرة للعملاء بأنكم على علم وتعملون على حل.
• استعادة: أعد نشر النسخة المعروفة الجيدة (أو أعد التراجع عن الوحدة المحددة). اختبر تسجيل الدخول، تحميل لوحة القيادة، وإجراء أساسي مثل "إنشاء تذكرة" أو "إجراء طلب".
• مراقبة: راقب معدل الأخطاء، نجاح تسجيل الدخول، وحجم تذاكر الدعم لمدة 10-15 دقيقة قبل إعلان الاستقرار.

بحلول 10:40 صباحًا، تعود الأخطاء إلى الوضع الطبيعي. تتابع المراقبة بينما يؤكد الدعم تباطؤ وصول التذاكر الجديدة.

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

أخطاء شائعة تُفاقم الحوادث

معظم الحوادث تتفاقم لسببين: يترك الناس النظام يواصل إلحاق الضرر أثناء التحقيق، أو يجرون تغييرات متعددة بسرعة كبيرة. هذا الدليل يهدف لحمايتك من كليهما.

فخ شائع هو التحقيق بينما التطبيق ما زال يكتب بيانات خاطئة. إن كان سير عمل يتكرر، تكامل ينشر مكررات، أو خلل في الأذونات يسمح للمستخدمين الخطأ بتعديل السجلات، أوقف العملية المخالفة أولًا. في AppMaster، قد يعني ذلك تعطيل Business Process، إيقاف تكامل وحدة، أو تقييد الوصول مؤقتًا حتى يتوقف الانتشار.

فخ آخر هو "الإصلاح بالتخمين". عندما يضغط عدة أشخاص ويغيرون إعدادات، تفقد الخط الزمني. حتى التعديلات الصغيرة مهمة أثناء الحادث. اتفق على مُحرّك واحد، احتفظ بسجل تغييرات بسيط، وتجنّب تراكم التعديلات على مجهولات.

أخطاء تتكرر وتطيل الانقطاعات:

• التحقيق أولًا وتأخير الاحتواء بينما تستمر الكتابات الخاطئة أو الإجراءات المكررة
• إجراء تغييرات متعددة دفعة واحدة بدون ملاحظات، فلا يمكنك معرفة ما الذي ساعد أو أضر
• الانتظار قبل التواصل، أو إرسال تحديثات غامضة تثير أسئلة أكثر من الثقة
• الاسترجاع الأعمى دون فحص حالة قاعدة البيانات أو الوظائف المجمعة، الرسائل، أو الويب هوكس
• إنهاء الحادث دون خطوة تحقق واضحة

التواصل جزء من التعافي. شارك ما تعرفه، ما لا تعرفه، ومتى سيكون التحديث التالي. "نسترجع وسنؤكد أن أحداث الفوترة صحيحة خلال 15 دقيقة" أفضل من "نبحث في الأمر."

لا تُغلق الحادث لمجرد توقف الأخطاء. تحقق بقائمة قصيرة: تحميل الشاشات الرئيسية، حفظ السجلات الجديدة بشكل صحيح، تشغيل الأتمتات الحرجة مرة واحدة، وتصريف أو إيقاف السجلات المتأخرة (الطوابير، المحاولات، الوظائف المجدولة).

قائمة تحقق سريعة يمكنك تشغيلها تحت الضغط

عندما ينهار شيء، سيحاول عقلك تنفيذ عشرة مهام في وقت واحد. استخدم هذه القائمة للبقاء هادئًا، حماية الناس، واستعادة الخدمة.

علّق هذا القسم حيث سيراه فريقك فعليًا.

• أكد أنه حقيقي وحدد النطاق (5 دقائق): تحقّق مما إذا كانت التنبيهات تطابق ما يبلغ عنه المستخدمون. دون ما الذي يفشل (تسجيل الدخول، الدفع، لوحة الإدارة)، من المتأثر، ومنذ متى. إن أمكن، أعد إنتاج المشكلة في جلسة نظيفة (تصفح خاص أو حساب اختبار).

خُذ دقيقة واحدة لتسمية مالك للحادث. شخص واحد يقرر، والباقون يدعمون.

• استقر واحتوِ (10 دقائق): أوقف النزيف قبل البحث عن السبب الجذري. عطّل المسار المحفوف (علم ميزة، لافتة مؤقتة، إيقاف الطوابير) واختبر رحلة مفتاحية من البداية للنهاية. اختر الرحلة الأهم للأعمال.

• استعد الخدمة (10-20 دقيقة): اختر الإجراء الأكثر أمانًا: استرجع إلى آخر نسخة معروفة جيدة أو طبق إصلاحًا بسيطًا. على منصات مثل AppMaster، قد يعني ذلك إعادة نشر بناء سابق أو التراجع عن التغيير الأخير، ثم تأكيد عودة معدلات الخطأ وزمن الاستجابة إلى الطبيعي.

• تواصل (دائمًا): انشر تحديث حالة قصير يوضح المتأثر، ما على المستخدم فعله، ووقت التحديث التالي. زود الدعم بنص من جملتين كي يقول الجميع الشيء نفسه.

• أغلق بشكل نظيف (قبل أن تنسى): سجّل ما حدث، ما الذي غيّرته، ووقت استعادة الخدمة. عيّن خطوات متابعة مع مالك وتاريخ استحقاق (تحسين المراقبة، سد ثغرة اختبار، تنظيف بيانات، إصلاح لاحق).

بعد الحادث: تعلّم، أصلح، ومنع التكرار

الحادث لا يُعتبر "منتهيًا" بمجرد عودة التطبيق. أسرع طريقة لتقليل وقت التوقف في المستقبل هي توثيق ما حدث بينما الذاكرة لا تزال طازجة، ثم تحويل هذا التعلم إلى تغييرات صغيرة وواقعية.

جدول مراجعة ما بعد الحادث قصيرة خلال 2-5 أيام. اجعلها بلا لوم وعملية. الهدف ليس محاسبة أحد، بل جعل الحادث التالي أسهل في التعامل.

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

حوّل الدروس إلى مهام مع مالكين وتواريخ استحقاق. ركز على أصغر التغييرات التي تمنع نفس الفشل:

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

اختر إجراء وقائي واحد لكل حادث، حتى لو كان صغيرًا. "أي تغيير في الأدوار يحتاج مُراجعًا ثانيًا" أو "يجب تشغيل ترحيلات البيانات أولًا على نسخة استنساخ بيئة الاختبار" يمكن أن يمنع تكرار الانقطاعات.

احتفظ بهذا الدليل بجانب عملية البناء والنشر. إن كنت تبني باستخدام AppMaster، دوّن أين تُنشر كل تطبيق (AppMaster Cloud، AWS، Azure، Google Cloud، أو الاستضافة الذاتية)، من يمكنه إعادة النشر بسرعة، ومن يمكنه الاسترجاع. إن أردت موطنًا واحدًا لتوثيق ذلك، الاحتفاظ به بجانب ملاحظات مشروع AppMaster الخاصة بك (appmaster.io) يجعل الوصول أسهل عندما تكون الدقائق ثمينة.