ما هو تصميم الأنظمة؟

ما هو تصميم الأنظمة؟

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

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

نطاق تصميم الأنظمة

يقع تصميم الأنظمة عند تقاطع هندسة البرمجيات والأنظمة الموزعة والبنية التحتية. يشمل قرارات على مستويات متعددة:

• البنية المعمارية عالية المستوى — ما الخدمات الموجودة؟ كيف تتواصل مع بعضها؟ أين تُخزَّن البيانات؟
• نمذجة البيانات — كيف تُهيكل البيانات وتُخزَّن وتُستعلَم؟
• تصميم واجهات البرمجة (API) — ما العقود التي تُعرضها الخدمات لبعضها وللعملاء؟
• استراتيجية التوسع — كيف يتعامل النظام مع 10× أو 1000× من حركة المرور؟
• الموثوقية ومعالجة الأعطال — ماذا يحدث عند تعطل خادم أو انقطاع الشبكة؟
• الاهتمامات التشغيلية — كيف يُراقَب النظام ويُنشَر ويُصحَّح؟

لماذا يهمنا تصميم الأنظمة؟

تأمل خدمة اختصار روابط. نموذج أولي يعمل يمكن كتابته في ~50 سطراً من الكود. لكن تشغيل ذلك النموذج على مستوى Bitly — 10 مليار إعادة توجيه شهرياً — يتطلب حل مشاكل مختلفة كلياً:

• كيف تُنشئ رموزاً قصيرة فريدة دون قفل عالمي؟
• أين تُخزِّن 10 مليارات تعيين URL بكفاءة؟
• كيف تخدم 4,000 طلب إعادة توجيه في الثانية بكمون أقل من 10 مللي ثانية؟
• ماذا يحدث عند عدم توفر قاعدة بياناتك الأساسية لمدة 30 ثانية؟
• كيف تُضيف تحليلات (عدد النقرات، البيانات الجغرافية) دون إبطاء عمليات إعادة التوجيه؟

لا تملك أيٌّ من هذه الأسئلة سطراً واحداً من الكود كإجابة. تتطلب قرارات معمارية — طبقات التخزين المؤقت، واختيارات قواعد البيانات، وطوبولوجيا النسخ المتماثل، وقوائم انتظار الرسائل — وهذا هو نطاق تصميم الأنظمة.

المتطلبات الوظيفية مقابل المتطلبات غير الوظيفية

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

المتطلبات الوظيفية تصف ما يفعله النظام — الميزات والسلوكيات المرئية للمستخدمين والعملاء:

• يمكن للمستخدمين لصق رابط طويل والحصول على رمز قصير.
• زيارة الرابط القصير تُعيد توجيه المتصفح إلى الرابط الأصلي.
• تنتهي صلاحية الروابط بعد 30 يوماً ما لم يُحدَّد مدة مخصصة.
• يمكن للمستخدمين عرض تحليلات النقرات على روابطهم.

المتطلبات غير الوظيفية تصف مدى جودة أداء النظام لعمله — سمات الجودة التي تُقيِّد التصميم:

• التوفر: وقت تشغيل 99.99% (نحو 52 دقيقة توقف في السنة).
• الكمون: يجب أن تكتمل عملية إعادة التوجيه في أقل من 20 مللي ثانية عند النسبة المئوية 99.
• معدل المعالجة: معالجة 50,000 رابط جديد يومياً؛ وخدمة 4,000 طلب إعادة توجيه في الثانية عند الذروة.
• المتانة: يجب ألا يُفقد أي رابط مُخزَّن بعد تأكيده للمستخدم.
• قابلية التوسع: يجب أن يتعامل النظام مع ارتفاع حركة المرور 10 مرات دون تدخل يدوي.
• الأمان: لا يمكن تخمين الروابط؛ ولا يمكن للمستخدمين الكتابة فوق روابط بعضهم.

المتطلبات غير الوظيفية هي ما يقود معظم القرارات المعمارية المثيرة للاهتمام:

• متطلب الكمون الأقل من 20 مللي ثانية يُجبرك على إضافة طبقة تخزين مؤقت (جولة قاعدة بيانات وحدها تستغرق 1–10 مللي ثانية، والشبكة تُضيف المزيد).
• متطلب المتانة يُجبرك على النسخ المتزامن قبل الإقرار بعملية الكتابة.
• متطلب قابلية التوسع يُجبرك على جعل خوادم التطبيق عديمة الحالة حتى تتمكن من إضافة المزيد دون تنسيق الحالة.
• متطلب التوفر بنسبة 99.99% يُجبرك على التكرار في كل طبقة ومعالجة دقيقة للأعطال الجزئية.

تصميم الأنظمة في الواقع مقابل المقابلات

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

في مقابلة التصميم، أنت تضغط تلك العملية التكرارية في 45 دقيقة. المحاور لا يبحث عن تصميم مثالي — بل يقيّم ما إذا كنت تستطيع:

1. طرح الأسئلة الصحيحة قبل البدء.
2. ترجمة المتطلبات إلى أرقام ملموسة.
3. اتخاذ المقايضات المعمارية وتبريرها.
4. تحديد المشاكل الصعبة واقتراح حلول معقولة.
5. التواصل بوضوح خلال التفكير.

كلا السياقين — المشاريع الفعلية والمقابلات — يشتركان في نفس الأساس: فهم واضح لـما يجب أن يفعله النظام (المتطلبات الوظيفية) وفي ظل أي ظروف (المتطلبات غير الوظيفية). هذا الوضوح هو نقطة البداية لكل تصميم جيد.

ما يغطيه هذا المقرر

على مدار الدروس العشرة القادمة، ستتعلم عملية تصميم الأنظمة الكاملة من المبادئ الأولى:

• كيفية جمع المتطلبات وتحسينها (الدروس 2–3)
• كيفية تقدير الحجم بحسابات خشنة سريعة (الدرس 4)
• المقاييس الأساسية — الكمون ومعدل المعالجة والتوفر — وما تعنيه بشكل ملموس (الدرس 5)
• الخصائص الجوهرية التي يجب أن يمتلكها كل نظام كبير (الدرس 6)
• كيفية التفكير في المقايضات بشكل صريح (الدرس 7)
• اللبنات البنائية الأساسية التي ستستخدمها في تقريباً كل تصميم (الدرس 8)
• كيفية ترجمة المتطلبات إلى مخطط معماري (الدرس 9)
• مشروع تطبيقي شامل يربط كل شيء معاً (الدرس 10)

بنهاية المقرر، ستمتلك عملية قابلة للتكرار للتعامل مع أي مشكلة تصميم أنظمة — في المقابلات، وفي اجتماعات مراجعة البنية المعمارية، وفي القرارات اليومية التي تُشكّل أنظمة الإنتاج.