هندسة الفوضى يجب أن تختبر ما تعتمد عليه فعليًا_

هندسة الفوضى سهلة الاستهانة بها.

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

الأرضية الوسطى المفيدة هي:

اختبر أنماط الفشل التي تدعيها بنية نظامك أنها تتحملها.

## السؤال الصحيح

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

- ما الذي يكتشف الفشل؟
- ما الذي يُحفز الانتقال؟
- ما هي الحالة المفقودة أو المتأخرة؟
- كيف ينتقل المرور؟
- كيف يعرف المشغلون ما إذا كانت العملية نجحت؟

إذا كانت تلك الإجابات موجودة فقط في رسم تخطيطي، فالنظام لم يثبت بعد.

## لماذا تعمل أيام الألعاب بشكل أفضل من العشوائية

تمارين الفشل المنظم عادة ما تكون أكثر قيمة من الاضطرابات العمياء.

إنها تتيح لك:

- تحديد فرضية
- اختيار نطاق تحطم آمن
- التقاط المقاييس قبل وبعد
- تعلم شيء قابل للتنفيذ

هذا هو حلقة الهندسة الأفضل بكثير من "كسر الأشياء وانتظار الحظ".

## ابدأ بالاعتماديات الحقيقية

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

- قاعدة بيانات رئيسية غير متاحة
- زيادة تراكم الطابور
- زيادة مهلة الاعتماديات
- فشل DNS أو اكتشاف الخدمة
- منطقة واحدة تعتبر غير صحية

تظهر هذه الاختبارات ما إذا كانت منطق التحويل حقيقية أو مجرد افتراض.

## الهدف هو الثقة، لا الأداء

هندسة الفوضى تكون قيمة عندما تحول ادعاءات المرونة إلى سلوك ملحوظ.

إذا علمتك التجربة:

- أي تنبيه ينطلق
- كم من الوقت يستغرق التعافي
- ما إذا كان النظام قد تدهور بأمان

فقد قامت بعملها.

## قراءة إضافية

- [مبادئ هندسة الفوضى](https://principlesofchaos.org/)
- [AWS Well-Architected: Reliability](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)