التعلّم من حوادث الإنتاج

لماذا يهم

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

وبالنسبة إلى المختبِر، كل حادثة دليلٌ عن نهج الاختبار لا تقدّمه أي مراجعة: فهي تُظهر بالضبط أين لم يطابق الواقعَ أساسُ الاختبار (Test Basis) أو مستوياتُه أو بيئاتُه أو مراجعُ الاختبار (Test Oracles). واستخدام هذا الدليل دون لوم يُبقي حزمة الانحدار مرتبطة بمخاطر حقيقية لا بالتخمين.

من الحادثة إلى الوقاية: حلقة التغذية الراجعة

يبدأ هذا الدرس من حيث ينتهي الرصد. والترتيب مهم: استعد الخدمة أولاً، ثم ابحث في الأسباب، ثم غيّر الاختبارات والعملية أخيراً بعد أن تتضح الحقائق.

بمصطلحات ISTQB، ما يواجهه المستخدمون في الحادثة إخفاقٌ (Failure): النظام لا يؤدي ما هو مطلوب منه. وقد يكون سببه عيباً في الشيفرة، لكنه قد يكون أيضاً الإعدادات أو البيانات أو السعة أو خدمة طرف ثالث؛ لذلك تحدد المراجعة ماذا أخفق ولماذا قبل أن تقرر أن الحل إصلاحٌ واختبار جديد.

• الرصد والإعلان: تنبيه أو فحص اصطناعي (Synthetic Check) أو بلاغ من عميل يفتح سجلَّ حادثة فيه الوقت والأثر ومالكٌ مسؤول.
• التخفيف (Mitigation): أوقف الضرر بالتراجع عن الإصدار (Rollback) أو بمفتاح ميزة (Feature Flag) أو بتغيير في الإعدادات. والتخفيف ليس الإصلاح، بل يمنحك وقتاً لإيجاده.
• إعادة بناء الجدول الزمني: عمليات النشر وتغييرات الإعدادات والتنبيهات والسجلات والقرارات، كلها بمنطقة زمنية واحدة.
• عقد مراجعة ما بعد الحادثة دون لوم: الأثر، والجدول الزمني، والأسباب المساهمة، وبنود العمل.
• تحليل فجوة الاختبار: أي اختبار أو فحص أو مراجعة كان يمكن أن يكشف المشكلة، وعلى أي مستوى، ولماذا لم يكشفها.
• الوقاية والتحقق: أضف اختبارات الانحدار والإجراءات الأخرى، لكلٍّ منها مالك وموعد، وتأكد من إنجازها.

مراجعات ما بعد الحادثة دون لوم

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

ومعنى «دون لوم» (Blameless) أن المراجعة تبحث عن الأسباب المساهمة في النظام والعملية، لا عن شخص تعاقبه، وتفترض أن الجميع تصرّفوا بحسن نية وفق المعلومات التي كانت لديهم. وهذا أمر عملي لا مجاملة: فمن يخشى اللوم يُغفل التفاصيل، فتفوت المراجعةَ الأسبابُ الحقيقية. ولا يعني ذلك غياب المساءلة، فلكل بند عمل مالكٌ مسمّى.

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

من مراجعة الحادثة إلى فجوات الاختبار واختبارات الانحدار

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

• شرط اختبار أو حالة اختبار غائبة: لم يذكر المتطلب ولا تحليل المخاطر هذا الموقف، أو لم يصل إليه تصميم الاختبار، كغياب القيم الحدّية عند الحافة. أضف الشرط أو معيار القبول أو حالة الاختبار.
• مستوى اختبار خاطئ: كان هناك اختبار، لكنه شامل من البداية إلى النهاية (End-to-End) على المسار السعيد (Happy Path) وحده، واختبار الوحدة أو اختبار API يصل إلى الفرع المعيب بسهولة أكبر.
• بيانات أو بيئة غير واقعية: بيانات الاختبار أو المحاكيات أو المنطقة الزمنية أو الإعدادات أو الأحجام تختلف عن الإنتاج.
• مرجع اختبار ضعيف: نُفّذ الاختبار لكنه لم يتحقق من النتيجة التي أخطأت، كأن يفحص رمز حالة HTTP دون عدد مرات الخصم.
• اختبار لم يُشغَّل: تُخطّي، أو عُزل لأنه متذبذب (Flaky)، أو لم يدخل ضمن اختيار اختبارات الانحدار لهذا التغيير.
• فجوة رصد: اكتشف المستخدمون المشكلة قبل المراقبة. وهذا الإجراء يخص المراقبة لا حزمة الاختبارات.

جرّبها: مولّد سيناريوهات الانحدار جرّبها: مولّد حالات الاختبار

مثال تطبيقي: خصم مزدوج بعد إصدار

حادثة افتراضية في متجر إلكتروني: خفّض الإصدار ⁦7.3⁩ مهلة وحدة الدفع (Payment Client) من ⁦30⁩ ثانية إلى ⁦10⁩ ثوانٍ. وتحت الحِمل كان المزوّد يجيب أحياناً بعد أكثر من ⁦10⁩ ثوانٍ، فتعيد وحدة الدفع المحاولة بمرجع دفع جديد يعامله المزوّد دفعةً جديدة، فخُصم من بعض العملاء مرتين.

يلخّص المقتطف أدناه المراجعة (التوقيت ⁦UTC+3⁩): نُشر الإصدار الساعة ⁦09:40⁩، ووقع أول خصم مزدوج ⁦09:58⁩ (اكتُشف لاحقاً في سجلات الدفع)، ووصلت أول شكوى إلى الدعم ⁦11:05⁩، وأُعلنت الحادثة ⁦11:30⁩، وخُفّفت ⁦11:50⁩ بإعادة المهلة إلى ⁦30⁩ ثانية عبر الإعدادات، واستُردّت المبالغ المكررة لـ⁦37⁩ طلباً بحلول ⁦15:00⁩. لاحظ أن العملاء، لا المراقبة، هم من رصدوا المشكلة بعد ⁦67⁩ دقيقة من أول خصم مزدوج، وأن معظم بنود العمل اختبارات وفحوص لا إصلاحٌ للشيفرة.

الأسباب المساهمة، دون تسمية أفراد: إعادة المحاولة ترسل مرجع دفع جديداً فلا يتعرّف المزوّد عليها؛ ومتطلب الدفع لم يذكر إعادة المحاولة؛ ومحاكي الدفع في كل بيئات الاختبار يجيب في أقل من ثانية؛ ولا توجد إشارة مراقبة لـ«أكثر من خصم ناجح للطلب الواحد». وبنود العمل كلها للإصدار ⁦7.4⁩: معيار قبول ينص على أن إعادة المحاولة لا تخصم مرتين أبداً (مالك المنتج)، واختبار وحدة يتحقق من أن إعادة المحاولة تعيد استخدام مرجع الدفع الأصلي (المطور)، واختبار API يجيب فيه المحاكي عن الطلب الأول بعد ⁦12⁩ ثانية وعن إعادة المحاولة فوراً، ويُتوقع خصمٌ واحد بالضبط وحالة الطلب PAID (فريق الجودة)، ومحاكي دفع يحاكي الاستجابات البطيئة ويعامل مرجع الدفع المكرر، كما يفعل المزوّد، على أنه الدفعة نفسها (فريق الجودة)، وتنبيه على أي طلب له أكثر من خصم ناجح (فريق العمليات).

• بعد إعلان الحادثة استغرق التخفيف عشرين دقيقة، أما الوقاية فاحتاجت إلى متطلب واختبارين وقدرة جديدة في بيئة الاختبار وتنبيه.
• قبل الإصلاح شُغّل اختبار API على الإصدار ⁦7.3⁩ ففشل بخصمين، ومع الإصلاح نجح. واختبار الانحدار الذي لم يفشل قط أمام العيب لا يثبت شيئاً عنه.
• تستهدف الاختبارات الشرطَ، أي مزوّداً بطيئاً تتبعه إعادة محاولة، لا الطلبات بعينها من الحادثة؛ لذلك تحمي أيضاً كل مسار آخر يستخدم وحدة الدفع نفسها.

INC-0412  Customers charged twice for one order after release 7.3 (fictional)

Impact     37 orders charged twice; all refunded the same day; no data lost
Timeline   all times UTC+3
  09:40  Release 7.3 deployed: payment client timeout 30 s -> 10 s
  09:58  First duplicate charge (found later in the payment logs)
  11:05  First customer complaint to support
  11:30  Incident declared; payments team and QA join
  11:50  Mitigated: timeout back to 30 s by configuration; no new duplicates
  15:00  All duplicate charges refunded
Detection  by customers, 67 minutes after the first duplicate; no alert fired

Contributing causes (no individuals named)
  - A retry after a timeout sends a new payment reference, so the provider
    cannot recognise it as the same payment.
  - The payment requirement said nothing about retries.
  - The payment mock in every test environment answers in under 1 s,
    so the timeout-and-retry path never ran in any test.
  - No monitoring signal for "more than one successful charge per order".

Action items                                                      owner  due
  1  Acceptance criterion: a retried payment never charges twice  PO     7.4
  2  Unit test: a retry reuses the original payment reference     dev    7.4
  3  API test: the mock answers the first call after 12 s, the
     retry at once; exactly one charge, order status PAID         QA     7.4
  4  Payment mock simulates slow answers and, like the provider,
     treats a repeated payment reference as the same payment      QA     7.4
  5  Alert on any order with more than one successful charge      ops    7.4

جرّبها: محوّل الطوابع الزمنية جرّبها: حاسبة الفرق بين التواريخ

أسئلة شائعة

المراجع

• Postmortem Culture: Learning from Failure — Site Reliability Engineering (John Lunney and Sue Lueder)Google / O'Reilly Media · 2016مراجعات ما بعد الحوادث الخالية من اللوم: أيّ الحوادث تستدعيها، وما الذي تسجّله — الأثر والأسباب الجذرية وإجراءات المتابعة — ولماذا يُستبعد منها اللوم.
• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023المنهج التأسيسي لاختبار البرمجيات: مستويات الاختبار وأنواعه وتقنيات تصميم الاختبارات وإدارة الاختبار والأدوات.
• ISTQB GlossaryISTQBالتعريفات القياسية لمصطلحات الاختبار — حالة الاختبار واختبار الانحدار والخطورة والأولوية وتحليل القيم الحدّية وغيرها.