اختبار المرونة

تعريف اختبار المرونة: الفشل والتعافي

يستخدم الدليل الرئيسي المرونة بمعناها الواسع — السلوك تحت الحمل وتحت الفشل وتحت الهجوم. أما هذا الدليل فيتناول جانب الفشل والتعافي: ما يحدث حين يتعطل جزء من النظام وهو يحمل حركة عادية.

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

يضع المعيار ISO/IEC 25010:2023 هذه الخصائص تحت الموثوقية (Reliability)، ويقسمها إلى الخلوّ من الأعطال (Faultlessness) والتوافر (Availability) وتحمّل الأعطال (Fault Tolerance) وقابلية التعافي (Recoverability). ويمارس اختبار المرونة الثلاث الأخيرة مباشرة: هل الخدمة متاحة حين يُحتاج إليها؟ وهل تعمل كما يُراد رغم أعطال العتاد أو البرمجيات؟ وبعد الانقطاع، هل تستعيد البيانات المتأثرة وتعود إلى الحالة المطلوبة؟ وهندسة الفوضى (Chaos Engineering) هي الصيغة التجريبية للعمل نفسه، وتفضّل مبادئها إجراء التجارب على حركة الإنتاج متى أمكن ذلك بأمان.

وفي فرق اختبار الأداء يأتي اختبار المرونة عادةً بعد اختبار الإجهاد: البيئة نفسها ونموذج عبء العمل نفسه ومولّد الحمل نفسه، مع عطل مضاف. ويغطي درس «اختبار الإجهاد» في مسار تعلم ضمان الجودة التعافي بعد الحمل الزائد؛ أما اختبار المرونة فيغطي التعافي بعد عطل، تحت حمل عادي.

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

اختبار المرونة مقابل اختبار الأداء

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

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

• السؤال: الأداء — ما سرعة النظام وكم حملاً يحتمل قبل أن ينكسر؟ المرونة — ماذا يحدث للمستخدمين حين يتعطل جزء منه، وما سرعة تعافيه؟
• ما يتغيّر: الأداء — الحمل (المستخدمون ومعدل الطلبات وحجم البيانات والمدة). المرونة — صحة مكوّن واحد (زمن الاستجابة والأخطاء والتوقف المفاجئ وفقدان الشبكة وامتلاء القرص).
• ما يبقى ثابتاً: الأداء — كل المكونات سليمة. المرونة — حمل واقعي ثابت.
• المدخلات: الأداء — نموذج عبء العمل ومخطط الحمل وبيانات الاختبار. المرونة — خط أساس الحالة المستقرة والفرضية والعطل ونطاق الأثر وشروط الإيقاف.
• معايير النجاح: الأداء — زمن الاستجابة عند المئينين 95 و99 والإنتاجية ومعدل الخطأ عند حمل محدد، وحد السعة. المرونة — نسبة النجاح أثناء العطل، وظهور الوضع المخفَّض، وانطلاق التنبيه، وزمن التعافي مقابل RTO وRPO، وعدم فقدان البيانات أو تكرارها.
• الأدوات المعتادة: الأداء — JMeter وk6 وLocust. المرونة — وكلاء الأعطال (Toxiproxy) ومحاكيات HTTP وChaos Mesh وLitmusChaos وAWS FIS وAzure Chaos Studio، مع مولّد حمل.

                    Performance testing                      Resilience testing
Question            How fast is it, and how much load can    What do users get when one part fails,
                    it carry before it breaks?               and how fast does it recover?
What changes        The load: users, request rate, data      The health of one component: latency,
                    volume, duration                         errors, crashes, network, full disk
What stays fixed    Every component is healthy               A realistic, steady load
Inputs              Workload model, load profile,            Steady-state baseline, hypothesis,
                    test data                                fault, blast radius, abort conditions
Pass criteria       p95/p99 latency, throughput and error    Success rate during the fault, degraded
                    rate at a stated load; capacity limit    mode shown, alert fired, recovery time
                                                             vs RTO/RPO, no lost or duplicated data
Typical tools       JMeter, k6, Locust                       Fault proxies (Toxiproxy), HTTP mocks,
                                                             Chaos Mesh, LitmusChaos, AWS FIS,
                                                             Azure Chaos Studio + a load generator
Output              Latency curves, capacity figure          Experiment record: expected vs observed,
                                                             findings, follow-up actions

متطلبات المرونة: RTO وRPO وأهداف مستوى الخدمة والأوضاع المخفَّضة

يحتاج اختبار المرونة إلى ما يحتاجه اختبار الحمل: هدف مكتوب كرقم قبل التشغيل. وتغطي خمسة أنواع من المتطلبات معظم الأنظمة.

ورقة المتطلبات أدناه مثال لعملية الدفع في «بستان ماركت» (متجر خيالي)، وكل سطر فيها اختبار: هدف نجاح 99.5% خلال 3 ثوانٍ على 30 يوماً؛ وإن أبطأ مزوّد الدفع حتى 3 ثوانٍ يكتمل الدفع بزمن p95 لا يتجاوز 4 ثوانٍ، مع احتساب عمليات الدفع التي تتجاوز 3 ثوانٍ من ميزانية الخطأ (نحو 3% من ميزانية الشهر عن كل ساعة إذا تجاوزها 10% منها)؛ وإن تعطّل تظهر رسالة واضحة بأن السلة محفوظة، دون خطأ 500 ودون خصم مكرر؛ وتعود الخدمة خلال 60 ثانية من تعافيه؛ وعند فقدان منطقة تتحول قاعدة الطلبات إلى النسخة البديلة بهدف زمن تعافٍ 15 دقيقة وهدف نقطة تعافٍ دقيقة واحدة.

• هدف زمن التعافي (RTO) — يعرّفه NIST SP 800-34 بأنه المدة الإجمالية التي يمكن أن تبقى فيها مكونات نظام المعلومات في مرحلة التعافي قبل أن تتضرر رسالة الجهة أو عملياتها. ويقيس اختبار المرونة زمن التعافي الفعلي، من العطل إلى عودة الخدمة الطبيعية، ويقارنه بالهدف.
• هدف نقطة التعافي (RPO) — في المرجع نفسه: النقطة الزمنية التي يجب أن تُستعاد البيانات إليها بعد الانقطاع، أي كم من أحدث البيانات يحتمل العمل خسارته. ويقيسه اختبار التحويل إلى النسخة البديلة (Failover) بمقارنة آخر السجلات المكتوبة قبل العطل بما هو موجود بعد التعافي.
• هدف مستوى الخدمة (SLO) وميزانية الخطأ (Error Budget) — يعرّف كتاب Google SRE هدف مستوى الخدمة بأنه قيمة مستهدفة أو نطاق قيم لمستوى خدمة يقيسه مؤشر (SLI)، مثل نسبة الطلبات الناجحة. وميزانية الخطأ هي الفشل الذي يترك الهدف له مجالاً: مع هدف نجاح 99.5% على 30 يوماً و2,000,000 طلب يُسمح بفشل 10,000 طلب. وتتحقق اختبارات المرونة من صمود الهدف حين يُحتوى العطل، وتُخطَّط تجارب الإنتاج بحيث لا تستهلك إلا جزءاً صغيراً متفقاً عليه من الميزانية. والوضع المخفَّض ليس مجانياً أيضاً: الطلبات التي يقدّمها خارج الهدف تستهلك من الميزانية، وينبغي أن تذكر المتطلبات كم.
• الأوضاع المخفَّضة — ما يفعله المنتج بدل الفشل: وضع القراءة فقط (يتصفح العميل ويرى طلباته لكنه لا ينشئ طلباً جديداً)، أو بيانات من الذاكرة المؤقتة (أسعار عمرها حتى 10 دقائق)، أو الطابور (يُقبل الطلب ويُرسل بريد التأكيد لاحقاً)، أو إيقاف ميزة غير أساسية (إخفاء التوصيات). ويحتاج كل وضع إلى مُطلِق ورسالة للمستخدم وشرط خروج يمكن اختبارها.
• زمن الاكتشاف والتعافي — مدى سرعة انطلاق التنبيه، ومدى سرعة عودة الخدمة إلى حالتها المستقرة بعد انتهاء العطل دون أي خطوة يدوية.

Resilience requirements - Bustan Market checkout (fictional example)

SLO          99.5% of checkout requests succeed within 3 s, rolling 30 days
             error budget 0.5%: about 10,000 of 2,000,000 requests a month may fail
Payments     slow (answers in up to 3 s): checkout completes, p95 <= 4 s, errors <= 1%;
             checkouts over 3 s still count against the SLO: at about 2,800 an hour,
             10% over 3 s spends ~280 (about 3% of the monthly budget) per hour
             failing: "Card payment is unavailable - your basket is saved",
             no HTTP 500, no duplicate charge; breaker opens, retries stop
             recovered: normal checkout within 60 s, no restart
Price cache  lost: prices read from the database, at most 200 queries/s, p95 <= 1.5 s
Order DB     zone loss: failover to the replica, RTO 15 min, RPO 1 min
E-mail       service down: orders accepted, confirmations queued, sent within 1 h
Detection    alert "checkout errors" to on-call within 5 min of user errors above 5%

تصميم تجربة مرونة

كل اختبار مرونة تجربة لها توقع مكتوب. وتصف مبادئ هندسة الفوضى (Principles of Chaos Engineering) شكلها: عرّف الحالة المستقرة (Steady State) بوصفها مُخرَجاً قابلاً للقياس يدل على السلوك الطبيعي، وافترض أنها ستستمر، وأدخل متغيرات تعكس أحداثاً واقعية، ثم حاول دحض الفرضية بالبحث عن فرق. والحالة المستقرة تخص المخرجات التي يشعر بها المستخدم — الإنتاجية ومعدل الخطأ ومئينات زمن الاستجابة — لا المقاييس الداخلية مثل استهلاك المعالج. ومن الإشارات الذهبية الأربع في كتاب SRE تشكّل زمن الاستجابة والحركة والأخطاء معايير الحالة المستقرة، ويبقى التشبّع، وهو الرابعة، أداة التشخيص التي تفسّرها.

اكتب الفرضية بحيث يمكن أن تفشل: «حين يجيب API الدفع أبطأ بثانيتين، يواصل الدفع النجاح لـ 99% على الأقل من الطلبات بزمن p95 أقل من 4 ثوانٍ، لأن مهلة العميل 3 ثوانٍ ومجمّع الاتصالات مُحجَّم لها». والفرضية التي تسمّي الآلية تخبرك أين تنظر حين تفشل.

• متغير واحد في كل مرة. احقن عطلاً واحداً بحجم واحد، ليكون لتغيّر النتيجة سبب واحد. ولا تجمع الأعطال إلا بعد نجاح كلٍّ منها منفرداً.
• نطاق الأثر (Blast Radius). حدّد مسبقاً البيئة، ونسبة النسخ أو الحركة، والمستخدمين (حسابات اختبار فقط، أو نسبة صغيرة من الحركة الحقيقية)، والمدة. ابدأ بالأصغر ولا توسّع إلا بعد نجاح.
• شروط الإيقاف. اكتب الحدود التي تنهي التجربة فوراً — مثلاً أخطاء يراها المستخدم فوق 5% لمدة دقيقتين، أو أي تنبيه من فريق خارج التجربة — ومن يعلن التوقف. ويستطيع مولّد الحمل تطبيق جزء منها: حدود k6 المعلَّمة بـ abortOnFail توقف التشغيل فور تجاوزها.
• مخرج مُجرَّب. يجب أن يعمل الأمر الذي يزيل العطل قبل حقنه؛ جرّبه مرة على نظام سليم.
• قابلية الرصد (Observability) قبل الحقن. تأكد أن لوحات المتابعة تعرض مقاييس الحالة المستقرة والعطل نفسه (زمن استجابة الاعتمادية وحالة قاطع الدارة). فإن لم ترَ العطل لن ترى أثره، وإن فات المراقبةَ عطلٌ محقون فتلك أول نتيجة.
• خط الأساس ثم العطل ثم التعافي. سجّل ما لا يقل عن ⁦10–15⁩ دقيقة من الحالة المستقرة قبل الحقن، وأبقِ العطل مدة كافية لتستقر المقاييس، وواصل القياس بعد إزالته حتى تعود الحالة المستقرة.

RESILIENCE EXPERIMENT RX-<nnn>          Owner: <name>          Date: <yyyy-mm-dd>

Service -> dependency   <service> -> <dependency>
Steady state            <metric = value>, measured for <n> min before injection
Hypothesis              When <fault> hits <dependency>, <service> will <behaviour>
                        because <mechanism>; <metric> stays <limit>.
Fault (one variable)    <type>, <size>, <duration>, injected with <tool>
Blast radius            <environment>; <share of instances or traffic>; <which users>
Traffic                 <synthetic rate, or share of real traffic>
Observe                 <dashboards, logs, traces, alert names>
Abort if (any one)      <user-facing errors > x% for y min> | <p95 > z s>
                        | <alert from a team outside the experiment>
Abort method            <command or button>, last tried on <date>
Pass if                 <criteria compared with the steady state>
Recovery check          steady state back within <t> after removal, no manual step,
                        data reconciled (no lost or duplicated records)
Result                  pass | fail | aborted     Findings: <ids>     Follow-ups: <tickets>

جرّبها: فاحص صحة API جرّبها: محلّل زمن الاستجابة

قائمة الأعطال: ما الذي يُحقن وما الذي يُراقب

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

• تأخر الاعتمادية — أضف 500 مللي ثانية، ثم تأخيراً أقل قليلاً من مهلة المستدعي وآخر أكبر منها قليلاً. راقب: هل ينتهي الاستدعاء عند المهلة المضبوطة، وهل تبقى مجمّعات الاتصالات أو الخيوط دون امتلاء، وهل تحافظ نقاط النهاية التي لا تستخدم الاعتمادية على سرعتها المعتادة.
• استجابات الخطأ — اجعل الاعتمادية تعيد 500، أو 503 مع ترويسة Retry-After، أو 429. راقب: هل تقتصر إعادة المحاولة على الأخطاء القابلة لإعادة المحاولة، وهل تُحترم Retry-After، وهل يرى المستخدم رسالة محددة لا خطأ 500 خاماً.
• انتهاء المهلة والتعليق — تقبل الاعتمادية الاتصال ولا تجيب أبداً. راقب: هل تنهي مهلتك أنت الاستدعاء (لا المهلة الافتراضية لنظام التشغيل بعد دقائق)، وهل تُحرَّر الموارد التي كان يحجزها.
• التوقف المفاجئ وإعادة التشغيل — أوقف عملية أو حاوية أو نسخة خادم أثناء الحركة. راقب: هل تُخرجها فحوص الصحة من التوزيع، وهل تُعاد الطلبات الجارية بأمان أو تفشل بوضوح، وهل يبقى العمل المنتظر في الطابور محفوظاً، وهل تعود النسخة بعد إعادة التشغيل.
• انقسام الشبكة وفقدان الحزم — أسقط ⁦5–10%⁩ من الحزم، أو اقطع الاتصال بين مكوّنين. راقب: هل يظهر الفقدان كزمن استجابة بسبب إعادة الإرسال، وهل ترفض مخازن البيانات العنقودية الكتابات المتعارضة على جانبي الانقسام، وهل تُستعاد الاتصالات بعد التئامه.
• امتلاء القرص — املأ وحدة التخزين المستخدمة للسجلات أو الملفات المؤقتة أو قاعدة البيانات. راقب: هل يصل تنبيه قبل الامتلاء، وهل تفشل الكتابات بخطأ واضح بدل إفساد البيانات، وهل تتعافى الخدمة بعد تحرير المساحة.
• انحراف الساعة (Clock Skew) — قدّم ساعة عقدة واحدة أو أخّرها بضع دقائق. راقب: التحقق من الرموز (يسمح RFC 7519 بهامش صغير فقط لحقلي exp وnbf، عادةً لا يتجاوز بضع دقائق)، وفحوص صلاحية الشهادات، والمهام المجدولة، وكل ما يرتّب الأحداث حسب الطابع الزمني.
• انتهاء صلاحية الشهادات وبيانات الاعتماد — اترك شهادة اختبار تنتهي، أو ألغِ مفتاح API أو سراً. راقب: هل يظهر خطأ واضح يسمّي السبب، وهل يصل تنبيه قبل الانتهاء بأيام، وهل يسري التدوير دون إعادة نشر.
• فقدان منطقة أو إقليم — أوقف كل النسخ في منطقة توافر واحدة، أو حوّل قاعدة البيانات إلى نسختها البديلة. راقب: هل تحمل السعة المتبقية الحمل، وزمن التحويل مقابل RTO، والبيانات المفقودة مقابل RPO، وتغييرات DNS أو موزّع الحمل.
• عاصفة إعادة المحاولات (Retry Storm) — أسقط اعتمادية ثم أعدها بينما يعيد عملاء كثيرون المحاولة. راقب: كم استدعاءً تتلقاه الاعتمادية لكل طلب مستخدم، وهل ينشر التراجع مع التشويش العشوائي المحاولات على الزمن، وهل تتعافى الاعتمادية بدل أن تسقط من جديد.
• فشل الذاكرة المؤقتة — أوقف الذاكرة المؤقتة (Cache) أو أفرغها بحيث يخطئ كل طلب. راقب: حمل قاعدة البيانات أثناء البدء البارد، وزمن الاستجابة، وهل يحدّ التطبيق عدد الطلبات التي تعيد بناء المدخل نفسه، وهل يقدّم بيانات قديمة حيث تسمح المتطلبات.
• تراكم طابور الرسائل — أوقف المستهلكين 30 دقيقة ثم شغّلهم. راقب: تنبيهات عمق الطابور وعمر الرسائل، وما يفعله المنتجون حين يمتلئ الطابور، وزمن التصريف، ومعالجة كل رسالة مرة واحدة (يجب أن يكون المستهلكون آمنين للتكرار لأن إعادة التسليم تحدث).

جرّبها: مولّد استجابات خطأ وهمية جرّبها: فاحص شهادة SSL جرّبها: فاحص انتهاء صلاحية JWT

كيف تختبر كل نمط من أنماط المرونة

يصف كتاب Release It! لمايكل نايجارد أنماط استقرار تُبقي الفشل محلياً — منها المهل وقواطع الدارة والحواجز والفشل السريع (Fail Fast) والتخلّص من الحمل (Shed Load). وتضيف القائمة أدناه إعادة المحاولة مع التراجع، والتكرار الآمن، والتدهور الرشيق، وهي مأخوذة من كتاب SRE وRFC 9110 لا من ذلك الفهرس، لكنها تُختبر بالطريقة نفسها. ومعرفة أن النمط موجود في الكود ليست كمعرفة أنه يعمل بإعداداتك؛ ولكل نمط اختبار يثبته.

• المهل (Timeouts) — احقن تأخيراً أقل قليلاً من المهلة وآخر أكبر منها قليلاً، وتحقق من أن الاستدعاء ينتهي عند القيمة المضبوطة. وفي سلسلة استدعاءات يجب أن تكون مهلة كل طبقة أقصر من مهلة مستدعيها؛ ويوصي كتاب SRE بتمرير موعد نهائي واحد عبر الطلب كله، حتى تتوقف الخدمة اللاحقة عن العمل على طلب تخلّى عنه العميل.
• إعادة المحاولة مع التراجع الأسّي والتشويش العشوائي (Exponential Backoff and Jitter) — عُدّ الاستدعاءات التي تتلقاها الاعتمادية لطلب مستخدم واحد. فإعادة المحاولة تتضاعف عبر الطبقات: في مثال كتاب SRE تحوّل ثلاث طبقات، تعيد كلٌّ منها ثلاث مرات، إجراءً واحداً من المستخدم إلى 64 محاولة على قاعدة البيانات. تحقق من سقف المحاولات وسقف التأخير، ومن أن التأخيرات عشوائية (فلا تصل محاولات العملاء الكثيرين في موجات)، ومن أن إعادة المحاولة تقتصر على الإخفاقات القابلة لذلك (انتهاء مهلة أو 503، لا 400 ولا 422)، ومن احترام Retry-After مع 429 و503.
• قواطع الدارة (Circuit Breakers) — ارفع معدل الفشل فوق عتبة القاطع وتحقق من أنه ينفتح (تفشل الاستدعاءات في أجزاء من الثانية بدل انتظار المهل)، وأنه بعد مهلة إعادة الضبط يسمح باستدعاء تجريبي (نصف مفتوح)، وأنه ينغلق من جديد حين تتعافى الاعتمادية. وينبغي أن تظهر تغيّرات حالته في المقاييس أو السجلات.
• الحواجز (Bulkheads) — استنفد مجمّع الاتصالات أو الخيوط الخاص باعتمادية واحدة، وتحقق من أن نقاط النهاية التي تستخدم اعتماديات أخرى تحافظ على زمن استجابتها المعتاد. هذا فحص الاحتواء: شريك بطيء واحد لا يجوز أن يُسقط الخدمة كلها.
• التكرار الآمن (Idempotency) — أرسل الطلب نفسه مرتين، ومرة أخرى بعد انتهاء مهلة المحاولة الأولى، وتحقق من أن له أثراً واحداً: طلب واحد وخصم واحد. يعرّف RFC 9110 الطريقتين PUT وDELETE بأنهما آمنتان للتكرار، وPOST بأنها ليست كذلك، فطلب POST الذي قد يُعاد يحتاج إلى مفتاح تكرار (Idempotency Key) يزيل الخادم التكرار على أساسه.
• التدهور الرشيق (Graceful Degradation) — أوقف الاعتمادية وتحقق من ظهور الوضع المخفَّض المذكور في المتطلبات، ومن إعلام المستخدم، ومن عودة المنتج إلى الوضع الكامل وحده بعد التعافي. فالأوضاع المخفَّضة نادراً ما تُمارَس في التشغيل العادي، ولهذا بالضبط تحتاج إلى اختبار.
• التخلّص من الحمل وتحديد المعدل (Load Shedding and Rate Limiting) — ادفع الحركة فوق السعة وتحقق من أن الطلبات الزائدة تُرفض مبكراً وبتكلفة قليلة (429 أو 503، ويُفضَّل مع Retry-After، خلال أجزاء من الثانية)، وأن الحركة المهمة محمية قبل الأقل أهمية، وأن الطلبات المقبولة ما زالت تحقق هدف مستوى الخدمة. ويعرّف RFC 6585 الحالة 429 Too Many Requests.

جرّبها: محاكي رموز حالة API جرّبها: مولّد استجابات خطأ وهمية جرّبها: مولّد اختبارات الطلبات المتزامنة

كيف تنظّم جلسة اختبار مرونة (يوم التمرين — Game Day)

جلسة اختبار المرونة — وتسمى عادةً يوم التمرين (Game Day) — تمرين مجدول ومحدود الوقت يحقن فيه الفريق أعطالاً مخططة في النظام ويتدرّب على الاستجابة لها، فيُختبر الأشخاص وأدلة التشغيل (Runbooks) والتنبيهات مع البرمجيات. ويصف إطار AWS Well-Architected أيام التمرين بأنها محاكاة لأحداث في بيئات شبيهة بالإنتاج لاختبار الأنظمة والإجراءات واستجابة الفرق، بمشاركة الفرق نفسها التي ستتعامل مع الحدث الحقيقي، وعلى جدول منتظم.

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

• التحضير (قبل أسبوع إلى أسبوعين): اختر الخدمة والسيناريوهات من قائمة المخاطر والحوادث الأخيرة؛ واكتب لكل سيناريو فرضية وشرط إيقاف؛ واحصل على موافقة مالك الخدمة؛ وأبلغ فريق المناوبة والدعم والفرق المعتمدة على الخدمة بالموعد والنطاق؛ وتحقق من لوحات المتابعة والتنبيهات؛ وتدرّب على إزالة كل عطل.
• الأدوار: ميسّر (Facilitator) يدير جدول الأعمال ويقرر متى يُنتقل إلى ما بعده؛ ومشغّل (Operator) واحد يحقن الأعطال ويزيلها، فلا يغيّر أحد غيره النظام؛ ومستجيبون (Responders) — مهندسو المناوبة — يتعاملون مع ما يرونه كما يتعاملون مع حادثة حقيقية؛ ومراقبون (Observers) يتابعون اللوحات ويبلّغون؛ ومدوّن (Scribe) يحتفظ بخط زمني بالتوقيتات.
• دليل التشغيل: لكل سيناريو أمر الحقن، والملاحظات المتوقعة، وأمر الإزالة، وشرط الإيقاف، بالترتيب الذي ستُستخدم به. ويعمل المستجيبون من أدلة الحوادث المعتادة لدى الفريق، فتظهر ثغراتها كنتائج.
• السلامة: يحق لأي مشارك إعلان التوقف؛ وعند التوقف يزيل المشغّل كل الأعطال ويتأكد الفريق من عودة الحالة المستقرة قبل أي شيء آخر. لا تبدأ أثناء حادثة حقيقية أو إصدار أو فترة ذروة.
• البيئة: بيئة اختبار مع وكيل أعطال للجولات الأولى؛ وstaging ببنية شبيهة بالإنتاج وحركة اصطناعية لمعظم الجلسات؛ والإنتاج فقط لتجارب نجحت في staging، بنطاق أثر صغير، وميزانية خطأ كافية، وتوقيت خارج الذروة، وشروط إيقاف جاهزة.
• المراجعة (Debrief) في اليوم نفسه: مرّ على كل سيناريو — المتوقع، والملاحظ، ومتى اكتُشف ومن اكتشفه، ومتى تعافى، وما الخطوات اليدوية التي احتاجها. واجعلها خالية من اللوم كما يصف فصل مراجعات ما بعد الحوادث في كتاب SRE: الموضوع هو النظام والإجراء لا الشخص. وتصبح كل نتيجة تذكرة لها مالك وموعد، ويُعاد السيناريو الذي فشل بعد الإصلاح.

RESILIENCE GAME DAY - <service> - <date>, <start>-<end> <time zone>

Goal          <the question this session answers>
Environment   <test | staging | production>    Traffic: <synthetic rate | real share>
Scope         in: <services>    out: <services>
Approved by   <service owner>, <on-call lead>
Notified      on-call, customer support, <dependent teams>, <provider if needed>

Roles
  Facilitator  <name>   runs the agenda, decides when to move on
  Operator     <name>   the only person who injects and removes faults
  Responders   <names>  on-call engineers, respond as in a real incident
  Observers    <names>  watch dashboards and report what they see
  Scribe       <name>   keeps the timeline: time, event, who

Stop rule     anyone may call STOP; the operator removes all faults (<command>)
Abort if      <user-facing errors > x% for y min> | <SLO burn > z> | <real incident>

Agenda
  09:00  Briefing: goal, scenarios, roles, stop rule; baseline dashboards checked
  09:20  Scenario 1  <fault>     hypothesis: <...>     time box 30 min
  10:00  Scenario 2  <fault>     hypothesis: <...>     time box 30 min
  10:40  Scenario 3  <fault>     hypothesis: <...>     time box 30 min
  11:20  All faults removed; steady state confirmed
  11:30  Debrief (blameless): expected vs observed, surprises, runbook and alert gaps
  12:15  Close: findings recorded, follow-up tickets with owners and dates

Record per scenario
  Injected / removed      <hh:mm:ss> / <hh:mm:ss>
  Detected by / at        <alert or person> / <hh:mm:ss>
  Steady state held       yes | no  (<values>)
  Recovered at            <hh:mm:ss>    manual steps: <none | list>
  Findings                <ids>

جرّبها: فاحص عمل الموقع

أدوات اختبار المرونة وأين يعمل كل نوع منها

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

السكربت الذي يلي القائمة مثال لفحص يعمل مع كل دمج، مكتوب لإعدادات العميل في المثال التطبيقي أدناه (مهلة 3 ثوانٍ، ومحاولة إعادة واحدة، وموعد نهائي لعملية الدفع 5 ثوانٍ). يجعل Toxiproxy استدعاء الدفع أبطأ من المهلة، ويتحقق السكربت من أن الدفع يتوقف برمز 503 واضح ضمن موعده النهائي بعد محاولة إعادة واحدة بالضبط، ثم يزيل العطل ويتحقق من نجاح عملية الدفع التالية دون إعادة تشغيل.

• وكلاء الأعطال (Fault Proxies) يقفون بين الخدمة واعتماديتها. فـ Toxiproxy وكيل TCP لمحاكاة ظروف الشبكة والنظام في اختبار الفوضى والمرونة، يضيف «سموماً» (Toxics) مثل التأخير مع التشويش، وتقييد عرض النطاق، وانتهاء المهلة، وإعادة ضبط الاتصال، وتقطيع البيانات، ويُتحكم فيه عبر واجهة HTTP من كود الاختبار. ولأنه يعمل على مستوى TCP فلا يستطيع إعادة حالة HTTP؛ فاقرنه بمحاكاة HTTP لأخطاء 500 و503 و429.
• محاكيات HTTP وبدائلها (Mocks and Stubs) تعيد رموز حالة وأجساماً وتأخيرات مختارة بدل الاعتمادية الحقيقية — وهي أرخص طريقة لاختبار معالجة الأخطاء وإعادة المحاولة في CI. ويعيد محاكي رموز حالة API في هذا الموقع أي رمز من 200 إلى 599 مع تأخير اختياري حتى 10 ثوانٍ للفحوص اليدوية؛ وهو محدود المعدل، فاستخدم محاكاة محلية للتشغيل الآلي بكثافة.
• منصات الفوضى في Kubernetes تحقن الأعطال في الـ Pods والعقد والشبكة حولها. يوثّق Chaos Mesh — وهو مشروع في مرحلة الاحتضان لدى CNCF مبني على الموارد المخصصة في Kubernetes — أعطال الـ Pods، وتأخر الشبكة وفقدان الحزم، وأعطال DNS وHTTP، وضغط المعالج والذاكرة، وأعطال إدخال الملفات وإخراجها، وقفزات الساعة، وأعطال JVM، ويربط التجارب في مسارات عمل (Workflows). أما LitmusChaos، وهو أيضاً في مرحلة الاحتضان لدى CNCF ومصمَّم أصلاً لـ Kubernetes، فيعرّف التجارب كموارد مخصصة ويحكم عليها بمسابير المرونة (Resilience Probes) — فحوص HTTP وأوامر وموارد Kubernetes واستعلامات Prometheus يدخل نجاحها في الحكم.
• خدمات حقن الأعطال السحابية تعمل على موارد المزوّد نفسه. يشغّل AWS Fault Injection Service التجارب من قوالب تضم الإجراءات والأهداف وشروط الإيقاف، وشرط الإيقاف تنبيه CloudWatch يوقف التجربة؛ وتوصي AWS بمرحلة تخطيط وتشغيل في بيئة ما قبل الإنتاج قبل الإنتاج. ويشغّل Azure Chaos Studio أعطالاً مباشرة على الخدمة عبر واجهة إدارة المورد (إيقاف آلة افتراضية، أو تنفيذ تحويل (Failover) لحساب Azure Cosmos DB) وأعطالاً عبر وكيل داخل الآلات الافتراضية (ضغط المعالج، وإنهاء العمليات)؛ وكانت مساحات العمل (Workspaces) الأحدث بسيناريوهات الانقطاع الجاهزة في مرحلة المعاينة العامة عند كتابة هذا الدليل.
• مولّد الحمل يوفر الحركة الثابتة وجزءاً من منطق الإيقاف: JMeter، أو k6 مع حدود على معدل الخطأ وزمن p95.
• أين تعمل: وكلاء الأعطال والمحاكيات مع كل دمج في CI (عدد قليل من الفحوص السريعة الحتمية)؛ وأدوات Kubernetes والسحابة في staging وجلسات ما قبل الإصدار؛ وتجارب الإنتاج فقط مع شروط إيقاف ونطاق أثر صغير وحصة متفق عليها من ميزانية الخطأ. وتضيف إرشادات AWS لهندسة الفوضى أن التجربة التي نجح فيها النظام ينبغي أن تبقى اختبار انحدار آلياً في خط الأنابيب.
• وتجمع استراتيجية اختبار المرونة هذه الطبقات بالترتيب: متطلبات تُكتب أولاً؛ واختبارات أعطال سريعة في CI مع كل دمج؛ وتجارب في staging ويوم تمرين قبل كل إصدار كبير أو تغيير في البنية التحتية؛ وتجارب إنتاج محروسة لما نجح فقط؛ وتكرار المجموعة كلها على جدول، لأن الاعتماديات تتغير حتى حين لا يتغير الكود.

#!/usr/bin/env bash
# Resilience check on every merge (example). docker compose starts the app with
# PAYMENTS_URL=http://toxiproxy:21212, a payments stub on :8080 and Toxiproxy (API on :8474).
set -euo pipefail
TOXI=http://localhost:8474
APP=http://localhost:3000
STUB=http://localhost:8080   # the example stub counts the calls it receives at /__calls

checkout() {  # prints "<status> <seconds>"
  curl -s --max-time 10 -o /dev/null -w '%{http_code} %{time_total}' -X POST "$APP/api/checkout" -H 'Content-Type: application/json' -d @basket.json
}

curl -sf -X POST "$TOXI/proxies" -d '{"name":"payments","listen":"0.0.0.0:21212","upstream":"payments-stub:8080"}' > /dev/null

# 1. Payments slower than the 3 s client timeout. With this client (timeout 3 s, one retry
#    after up to 200 ms, 5 s checkout deadline) the first call times out, the retry is cut
#    off by the deadline, and checkout must answer with a clear 503 in about 5 s.
curl -sf -X DELETE "$STUB/__calls" > /dev/null
curl -sf -X POST "$TOXI/proxies/payments/toxics" -d '{"name":"slow","type":"latency","attributes":{"latency":4000,"jitter":0}}' > /dev/null
read -r status seconds <<< "$(checkout)"
[ "$status" = "503" ] || { echo "FAIL slow payments: got $status, expected 503"; exit 1; }
awk -v s="$seconds" 'BEGIN { exit !(s < 5.5) }' || { echo "FAIL slow payments: took ${seconds}s, deadline is 5 s"; exit 1; }
calls=$(curl -sf "$STUB/__calls")
[ "$calls" = "2" ] || { echo "FAIL slow payments: stub saw $calls calls, expected 2 (one retry)"; exit 1; }
echo "ok   slow payments -> $status in ${seconds}s after $calls calls"

# 2. Fault removed: the next checkout succeeds without a restart
curl -sf -X DELETE "$TOXI/proxies/payments/toxics/slow"
read -r status seconds <<< "$(checkout)"
[ "$status" = "201" ] || { echo "FAIL recovery: got $status, expected 201"; exit 1; }
echo "ok   recovered -> $status in ${seconds}s"

curl -sf -X POST "$TOXI/reset" > /dev/null

جرّبها: محاكي رموز حالة API جرّبها: فاحص صحة API

مثال تطبيقي: عملية الدفع حين يبطؤ API الدفع ويتعطل

يريد «بستان ماركت» (متجر خيالي) أن يعرف ما تفعله عملية الدفع لديه حين يمر مزوّد الدفع بيوم سيئ. تجري التجربة في بيئة staging مطابقة للإنتاج، ويرسل k6 حركة ثابتة قدرها 20 عملية دفع في الثانية من حسابات اختبار. وتمر المدفوعات عبر Toxiproxy (للتأخير) وبديل لمزوّد الدفع (للأخطاء). والإعدادات المعنية: مهلة عميل الدفع 3 ثوانٍ؛ ومحاولة إعادة واحدة بعد مدة تصل إلى 200 مللي ثانية (تشويش عشوائي كامل)، عند انتهاء المهلة أو 503 فقط؛ وموعد نهائي قدره 5 ثوانٍ لطلب الدفع كله؛ وترويسة Idempotency-Key مع كل خصم؛ ومجمّع من 40 اتصالاً؛ وقاطع دارة ينفتح حين يفشل أكثر من 50% من آخر 100 استدعاء.

خط الأساس، مقاساً 15 دقيقة قبل أي عطل: زمن p95 للدفع 850 مللي ثانية، والنجاح 99.6%، ومتوسط زمن استدعاء الدفع 300 مللي ثانية وزمنه عند p95 420 مللي ثانية، وزمن p95 لصفحات المنتجات 300 مللي ثانية.

• التشغيل 1 — استدعاءات الدفع أبطأ بثانيتين لمدة 20 دقيقة. المتوقع: نحو 2.3 ثانية لكل استدعاء في المتوسط و2.42 ثانية عند p95، أي أقل من مهلة 3 ثوانٍ، فيبقى زمن p95 للدفع 4 ثوانٍ على الأكثر والأخطاء 1% على الأكثر، وصفحات المنتجات بلا تغيير. الملاحظ: زمن p95 للدفع 4.8 ثانية، وp99 5.0 ثانية — أي الموعد النهائي — والأخطاء 3.4%، وصفحات المنتجات 310 مللي ثانية. والمجمّع يفسّر ذلك: وفق قانون ليتل (Little's Law) فإن الاستدعاءات الجارية = معدل الوصول × متوسط زمن الاستدعاء ≈ ⁦20 × 2.3 ≈ 46⁩، وهو أكثر من 40 اتصالاً، فانتظرت عمليات الدفع اتصالاً، وبلغت نسبة 3.4% التي انتظرت أطول من غيرها الموعد النهائي البالغ 5 ثوانٍ ففشلت. فشل. أما الحاجز فصمد: صفحات المنتجات لم تتأثر.
• الإصلاح وإعادة التشغيل — حجّم المجمّع من أسوأ حالة تسمح بها المهلة لمحاولة واحدة: 20 استدعاءً في الثانية × 3 ثوانٍ = 60، مقرّبة صعوداً إلى 64. وحين تنتهي مهل الاستدعاءات وتُعاد قد يتضاعف معدل المحاولات، فلا يغطي أي مجمّع معقول انقطاعاً كاملاً؛ وتلك الحالة متروكة لقاطع الدارة الذي ينفتح ويوقف الاستدعاءات. إعادة التشغيل: زمن p95 للدفع 2.9 ثانية والأخطاء 0.5%. نجاح.
• التشغيل 2 — 30% من استدعاءات الدفع تعيد 503 لمدة 20 دقيقة. المتوقع: مع محاولة إعادة واحدة لا تفشل عملية الدفع إلا إذا فشلت المحاولتان، فينجح ⁦1 − 0.3 × 0.3 = 91%⁩؛ ويرى الباقون رسالة «الدفع بالبطاقة غير متاح — سلتك محفوظة» ولا يرون خطأ 500 أبداً؛ ولا تزيد استدعاءات الدفع على 1.3 ضعف (لكل استدعاء فرصة 30% لمحاولة إعادة واحدة)؛ ولا خصم مكرراً؛ ويبقى القاطع مغلقاً لأن 30% أقل من عتبته البالغة 50%. الملاحظ: نجح 90.8%، ورأى 9.2% الرسالة، ولا أخطاء 500، و1.29 استدعاء لكل عملية دفع، وصفر خصومات مكررة عند مطابقة الطلبات بسجل مفاتيح التكرار لدى البديل، والقاطع مغلق طوال الوقت. نجاح.
• الاكتشاف — يجب أن ينطلق تنبيه «أخطاء الدفع» خلال 5 دقائق. انطلق بعد 7 دقائق و40 ثانية: فهو يحسب المتوسط على 10 دقائق، ومع إخفاقات يراها المستخدم بنحو 9% مقابل خط أساس 0.4% لم يتجاوز المتوسط 5% إلا بعد ما يزيد قليلاً على 5 دقائق، ثم انتظر التنبيه دقيقتين أخريين إضافة إلى فترة تقييمه. فشل؛ فقُصِّرت النافذة إلى 5 دقائق ومدة الانتظار إلى دقيقة، وفي إعادة التشغيل انطلق التنبيه بعد 3 دقائق و50 ثانية.
• التعافي — بعد توقف أخطاء 503 عاد النجاح إلى خط الأساس خلال 35 ثانية دون إعادة تشغيل. نجاح.

Bustan Market (fictional) - checkout -> payment API in staging, k6 at 20 checkouts/s
Baseline (15 min): checkout p95 850 ms, success 99.6%, pages p95 300 ms,
                   payment call mean 300 ms, p95 420 ms
Settings: payment timeout 3 s; 1 retry after up to 200 ms (full jitter); checkout deadline 5 s;
          pool 40; breaker opens at >50% failures in the last 100 calls

Run  Fault (20 min each)       Expected                        Observed                        Result
1    payment calls +2 s        checkout p95 <= 4 s,            p95 4.8 s, errors 3.4%,         FAIL
                               errors <= 1%, pages unchanged   p99 5.0 s (the deadline),
                                                               pool 40/40 busy, pages 310 ms
1b   same, pool 40 -> 64       as run 1                        p95 2.9 s, errors 0.5%          PASS
2    30% of payment calls 503  >= 90% succeed, rest get the    90.8% succeed, 9.2% message,    PASS
                               message, 0 HTTP 500, 0 dupes,   0 HTTP 500, 0 duplicates,
                               calls <= x1.3, breaker closed   x1.29 calls, breaker closed
     - detection               alert within 5 min              alert at 7 min 40 s             FAIL
     - recovery after removal  baseline within 60 s            baseline after 35 s             PASS

Follow-ups: RX-14 pool size = peak calls/s x timeout, in the payment client (done, re-run passed);
                  timeouts with retries can double the attempt rate - left to the breaker
            RX-15 alert window 10 min -> 5 min, pending 2 min -> 1 min (re-run: alert at 3 min 50 s)

جرّبها: محلّل زمن الاستجابة جرّبها: مقارنة أداء API جرّبها: قياس أداء طلبات HTTP

أخطاء شائعة في اختبار المرونة

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

الأسئلة الشائعة

المراجع

• ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023نموذج جودة المنتج: الملاءمة الوظيفية وكفاءة الأداء والتوافق وقابلية التفاعل والموثوقية والأمان وقابلية الصيانة والمرونة.
• NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information SystemsNIST · 2010تخطيط الطوارئ لأنظمة المعلومات، بما فيه تعريفا هدف زمن التعافي (RTO) وهدف نقطة التعافي (RPO) المستخدمان لتحديد أهداف التعافي واختبارها.
• Site Reliability Engineering: How Google Runs Production SystemsGoogle / O'Reilly Media · 2016أهداف مستوى الخدمة وميزانيات الخطأ ومراقبة «الإشارات الذهبية الأربع» والتعامل مع الحمل الزائد — الجانب التشغيلي للمرونة.
• Monitoring Distributed Systems — Site Reliability Engineering (Rob Ewaschuk)Google / O'Reilly Media · 2016إرشادات SRE من Google في المراقبة: المراقبة من الخارج (black-box) مقابل المراقبة من الداخل (white-box)، والإشارات الذهبية الأربع — زمن الاستجابة والحركة والأخطاء والتشبّع.
• Addressing Cascading Failures — Site Reliability Engineering (Mike Ulrich)Google / O'Reilly Media · 2016كيف يحوّل الحمل الزائد وإعادة المحاولات عطلاً واحداً إلى سلسلة أعطال، والدفاعات التي تُختبر: التراجع الأسّي العشوائي، وحدود إعادة المحاولة وميزانيتها، وتمرير المواعيد النهائية، والتخلّص من الحمل، والتدهور الرشيق.
• Postmortem Culture: Learning from Failure — Site Reliability Engineering (John Lunney and Sue Lueder)Google / O'Reilly Media · 2016مراجعات ما بعد الحوادث الخالية من اللوم: أيّ الحوادث تستدعيها، وما الذي تسجّله — الأثر والأسباب الجذرية وإجراءات المتابعة — ولماذا يُستبعد منها اللوم.
• Release It! Second Edition: Design and Deploy Production-Ready Software (Michael T. Nygard)The Pragmatic Bookshelf · 2018أنماط الاستقرار — المهل الزمنية وقواطع الدائرة والحواجز والضغط العكسي — وأنماط الفشل التي يُفترض أن يكشفها اختبار الحمل.
• Circuit Breaker (Martin Fowler)martinfowler.com · 2014نمط قاطع الدارة: الحالات المغلقة والمفتوحة ونصف المفتوحة، وعتبات الفشل وإعادة الضبط — وهو السلوك الذي يجب أن يرصده اختبار المرونة.
• Principles of Chaos Engineeringprinciplesofchaos.org · 2019تعريف هندسة الفوضى ومنهج تجاربها: حالة مستقرة قابلة للقياس، وفرضية، ومتغيرات أعطال واقعية، ونطاق أثر مُقلَّص إلى الحد الأدنى.
• REL12-BP04 Test resiliency using chaos engineering — AWS Well-Architected Framework, Reliability PillarAmazon Web Servicesتشغيل تجارب حقن الأعطال: الحالة المستقرة والفرضية وحواجز الأمان وشروط الإيقاف، وبيئة ما قبل الإنتاج قبل الإنتاج، والإبقاء على التجارب الناجحة كاختبارات انحدار في CI/CD.
• REL12-BP05 Conduct game days regularly — AWS Well-Architected Framework, Reliability PillarAmazon Web Servicesأيام التمرين: محاكاة الأحداث في بيئات شبيهة بالإنتاج لاختبار الأنظمة والإجراءات واستجابة الفرق، بمشاركة الفرق التي تتعامل مع الأحداث الحقيقية، تليها مراجعة تُتابَع دروسها حتى الإنجاز.
• What is AWS Fault Injection Service? — AWS FIS User GuideAmazon Web Servicesخدمة AWS المُدارة لحقن الأعطال: قوالب تجارب تتكوّن من إجراءات وأهداف وشروط إيقاف، وشرط الإيقاف تنبيه CloudWatch يوقف التجربة.
• What is Azure Chaos Studio?Microsoftخدمة Microsoft المُدارة لهندسة الفوضى على Azure: أعطال مباشرة على الخدمة وأخرى عبر وكيل، ومساحات عمل بسيناريوهات انقطاع جاهزة (في المعاينة العامة).
• Basic Features — Chaos Mesh documentationChaos Mesh (CNCF)أنواع الأعطال التي يحقنها Chaos Mesh في Kubernetes — أعطال الـ Pods والشبكة وDNS وHTTP والضغط وإدخال الملفات وإخراجها والوقت والنواة وJVM — ومسارات العمل ولوحة التحكم.
• What is Litmus — LitmusChaos documentationLitmusChaos (CNCF)LitmusChaos، إطار لهندسة الفوضى في مرحلة الاحتضان لدى CNCF يعرّف تجارب الفوضى كموارد مخصصة في Kubernetes.
• Certified Tester Performance Testing (CT-PT)ISTQB · 2018منهج ISTQB التخصصي لاختبار الأداء: المفاهيم الأساسية وقياسات الأداء وأنشطة الاختبار ومهامه والأدوات.
• Grafana k6 documentationGrafana Labsالتوثيق الرسمي لأداة Grafana k6، وهي أداة مفتوحة المصدر وقابلة للتوسعة لاختبار الحمل والأداء.
• RFC 9110: HTTP SemanticsIETF · 2022معاني أساليب HTTP وحقول الترويسات ورموز الحالة والتفاوض على المحتوى، بغضّ النظر عن إصدار البروتوكول.
• RFC 6585: Additional HTTP Status CodesIETF · 2012يعرّف الرموز 428 و429 (طلبات كثيرة جداً) و431 و511، بما فيها ترويسة Retry-After لتحديد المعدل.
• RFC 7519: JSON Web Token (JWT)IETF · 2015يعرّف صيغة JWT — الترويسة والحمولة والتوقيع — والمطالبات المسجّلة iss وsub وaud وexp وnbf وiat وjti.