أناقة الحلول

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

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

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

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

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

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

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

يمكن رؤية ذلك حتى في RAID. RAID المرآتي بسيط، مجرد قرص أو مجموعة أقراص تكون نسخة طبق الأصل من مجموعة أخرى. بهذه البساطة. RAID التكافئي معقد بحسابات على شريط متغير عبر أجهزة عديدة يجب ترميزه عند الكتابة وفك ترميزه عند فشل جهاز. يفتقر RAID المرآتي إلى هذا التعقيد ويحل مشكلة موثوقية القرص من خلال عمليات نسخ بسيطة وأنيقة موثوقة للغاية ومفهومة جيداً. RAID التكافئي معقد بلا داعٍ مما يجعله هشاً. ومع ذلك، وبإضعاف قدرته على حل المشكلة التي صُمم لها، أصبح في الوقت ذاته يبدو أكثر موثوقية بناءً على عامل وحيد لا غير وهو تعقيده. يقفز العقل البشري فوراً إلى “إنه معقد، إذاً هو أكثر تقدماً، إذاً هو أكثر موثوقية” لكن لا هذا التسلسل ولا ذاك منطقيٌّ. لا يعني التعقيد أنه أكثر تقدماً، ولا يعني كونه متقدماً أنه موثوق، لكن العقل البشري نفسه معقد وسهل التضليل.

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

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

“هل من الضروري فعلاً تقسيم تلك الأقراص إلى مصفوفات منفصلة عديدة؟ إذا كان الأمر كذلك، فما هو المبرر التقني لذلك؟”

“هل التخزين المشترك ضروري فعلاً للمهمة التي تقترحه من أجلها؟”

“هل يبرر العمل فعلاً استخدام تقنيات التوافر العالي الموزّع؟”

“لماذا نستبدل نظاماً بسيطاً كان كافياً بالأمس بنظام أكثر تعقيداً بشكل درامي غداً؟ ما الذي تغيّر مما يجعل تحسيناً كبيراً، مع الحفاظ على البساطة، غير كافٍ بل يستلزم تعقيداً وإنفاقاً بمراتب أكبر مما لم يكن مبرراً سابقاً؟”

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