🔄 تجربة تعليمية ⏱️ 3 دقائق 📅 ٩ مايو ٢٠٢٦ 🧩 systems thinking Photo by Rui Dias on Pexels ⚡ التجربة المكتشفة (TL;DR) الكوارث الكبرى لا تحدث بسبب أخطاء فردية، بل لأن الأنظمة المعقدة مصممة بحيث تتداخل…

الكوارث الكبرى لا تحدث بسبب أخطاء فردية، بل لأن الأنظمة المعقدة مصممة بحيث تتداخل المكونات السليمة لتنتج كارثة حتمية.
نعتقد أن الفشل يعني أن شيئاً ما أُهمل أو تعطل، وأنه يمكن منعه بتجنب الأخطاء.
في الأنظمة المعقدة، الفشل يحدث أحياناً عندما كل شيء يعمل كما يجب. التداخل المحكم بين المكونات السليمة يولد كوارث غير متوقعة.
في 28 مارس 1979، انصهر قلب مفاعل جزيرة ثري مايل. لم يكن هناك خطأ بشري واحد، ولا عطل ميكانيكي بسيط. كان هناك سلسلة من الأحداث، كل منها بدا معقولاً وقتها، تآزرت لتنتج كارثة. هذه هي 'الحوادث العادية': فشل النظام ليس بسبب فشل الأجزاء، بل بسبب تفاعلها المعقد. في هذه التجربة، سنختبر كيف يمكن للنجاح المتزامن أن يولد الفشل الذريع.
أنت مشغل في غرفة التحكم. فجأة، يومض ضوء أحمر: 'ارتفاع ضغط المبرد'. تتبع البروتوكول: تغلق صمام الأمان. منطقي. لكن الصمام لم يغلق بالكامل. وبدون أن تعلم، يهرب الماء المشع. أنت تطفئ المضخات لأنك تعتقد أن الضغط مرتفع جداً. الكارثة بدأت.
const system = { A: 1, B: 1, C: 1 };
function run() {
if (system.A === 1) {
system.B = system.B + 1;
if (system.B > 2) system.C = 0;
}
return system.C;
}كل متغير يعمل بشكل صحيح، لكن الناتج صفر (C=0).
كل دائرة تعمل ضمن حدودها، لكن إحداها صفرت الأخرى.
التفاعل بين المكونات السليمة أنتج فشلاً. كل قرار كان معقولاً بمعزل عن الآخرين، لكن معاً ألغوا وظيفة النظام. هذا هو 'الحادث العادي': فشل النظام وليس فشل المكونات.
عدّل قيمة A لتصبح 0 بدلاً من 1 في الكود أعلاه، ثم اضغط تشغيل. ماذا يحدث لـ C؟ هل يبقى صفراً أم يتغير؟
هل يمكن منع هذا النوع من الفشل بمجرد تحسين كل مكون على حدة؟ أم أن التصميم نفسه هو المشكلة؟
أي من هذه الأنظمة أكثر عرضة للحوادث العادية؟
البنوك الاستثمارية، شركات التأمين، المقرضون – كل منهم يتصرف بعقلانية. لكن الرهن العقاري عالي المخاطر يُغلف في منتجات معقدة، والترابط بين المؤسسات يخلق عدوى. عندما ينهار سوق الإسكان، ينهار كل شيء. لا أحد أخطأ، لكن النظام انهار.
let bank1 = 100, bank2 = 100;
function crisis() {
bank1 -= 90;
bank2 = bank2 - (bank1 < 50 ? 80 : 0);
return 'bank1: ' + bank1 + ', bank2: ' + bank2;
}البنك1 يخسر 90$، فيسحب البنك2 80$ إضافية بسبب الترابط.
في 2008، كان كل قرار فردي معقولاً: إقراض الرهن العقاري، تجميع القروض، بيع المشتقات. لكن التفاعل بين الأنظمة المالية جعل الفشل حتمياً.
في الكود أعلاه، غيّر شرط الانخفاض من '< 50' إلى '< 70' وشاهد كيف يزداد التأثير.
ما هي الأنظمة في حياتك التي تظهر هذا النمط من الفشل بسبب الترابط المحكم؟
نظام MCAS صُمم لتصحيح سلوك الطائرة. لكن حساس واحد معطل، وقرار الطيار بتصحيح المسار، وتصميم النظام الذي يعطي الأولوية للأتمتة – كلها تآزرت لإغراق الطائرة. كل عنصر بدا معقولاً.
let sensor = 1; // 1=سليم, 0=معطل
let pilot = 0; // 0=تصحيح, 1=إلغاء
function crash() {
if (sensor === 0 && pilot === 0) return 'تحطم';
else return 'بقاء';
}عندما يكون الحساس معطلاً والطيار يتبع البروتوكول العادي، النتيجة تحطم.
نظام واحد معطل، وكارثة.
في كل هذه الحالات، النظام يُنتج فشلاً من مكونات سليمة. الحل ليس 'منع الأخطاء'، بل تصميم المرونة (resilience) في بنية النظام نفسه: فصل المكونات، إضافة تكرار، تباطؤ التفاعلات.
عدّل الكود: اجعل pilot = 1 (إلغاء الأتمتة) وشاهد كيف تمنع التحطم. هذا هو التدخل البشري كطبقة أمان.
كيف يمكن تصميم نظام يتحمل فشل مكوناته دون انهيار كامل؟
لقد اختبرت كيف يمكن للأنظمة المعقدة أن تفشل حتى عندما تعمل كل قطعة بشكل صحيح. الإدراك الجديد: ليس خطأك أنك تحاول منع الأخطاء – النظام نفسه قد يُصمَّم بحيث يكون الفشل حتمياً. التحول المطلوب: من 'منع الأخطاء' إلى 'تصميم المرونة'. ابدأ بتحديد الأنظمة في حياتك التي تعاني من الترابط المحكم، واسأل: كيف يمكن فصل المكونات، إضافة تكرار، أو إبطاء ردود الفعل؟
🔁 تحدٍ: اختر نظاماً واحداً في عملك أو حياتك، وطبق عليه هذا التحليل: هل يمكن أن يفشل رغم سلامة مكوناته؟ كيف تعزز مرونته؟
📚 زارو-مدوّنة المعرفة — نبني مهندسي تفكير، لا قرّاء محتوى
KnowledgeNuggets Autonomous — System Architect Edition v5.0.2
FAQ
استمر في القراءة