‫تحليل االحتياجات‪ :‬العملية‬

‫تعد المبادئ واإلرشادات واإلجراءات الخاصة بتحليل المتطلبات جزءًا من نموذج العملية‪ .‬يوضح هذا النموذج ‪ ،‬الموضح‬
‫في الشكل ‪ ، 3.1‬الخطوات الرئيسية لجمع وتحليل وتطوير متطلبات شبكتك‪.‬‬

‫‪ 3.1‬األهداف في هذا الفصل ‪ ،‬ستتعلم كيفية جمع وإدارة متطلبات المستخدم والتطبيق والجهاز والشبكة‪ .‬يتضمن ذلك إعداد‬
‫وإدارة توقعات‪ 9‬عميلك بشأن الشبكة‪ .‬سوف تتعلم عن تحديد المتغيرات المطلوب قياسها‪( 9‬مقاييس الخدمة) وكيفية إجراء‬
‫القياسات‪ .‬نحن نقدم النمذجة والمحاكاة‪ ، 9‬وكيف يمكن استخدامها وتقنيات التقريب األخرى لوصف سلوك المستخدم‬
‫والتطبيق‪ .‬سوف تتعلم عن تطوير متطلبات األداء للسعة والتأخير و ‪ ، RMA‬بما في ذلك تطوير عتبات وحدود األداء‪ .‬هذه‬
‫مفيدة في التمييز بين متطلبات األداء المنخفض والمتدني لشبكتك‪ .‬سوف تتعلم عن الحدود والحدود العامة والخاصة بالبيئة‬
‫وكيفية تحديدها‪ .‬يتم تقديم بعض العتبات العامة الستخدامك‪ .‬نناقش أيضًا متطلبات األداء المضمونة والمضمونة وأهميتها‪.‬‬
‫جنبا إلى جنب مع متطلبات التجميع والتطوير ‪ ،‬سوف تتعرف على متطلبات التعيين إلى المواقع الجغرافية ‪ ،‬استعدا ًدا لتحليل‬
‫تدفق حركة المرور‪.‬‬

‫‪ 3.1.1‬اإلعداد‬

‫تعتمد المادة في هذا الفصل على ما تم تقديمه في الفصل ‪ .2‬لذلك ‪ ،‬تنطبق هنا أيضًا مصادر المعلومات الموصى بها الواردة‬
‫في الفصل ‪ 3.2 .2‬متطلبات التجميع واإلدراج‬

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

‫‪ 3.2.1‬تحديد الشروط األولية‬

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

‫نوع مشروع الشبكة • شبكة جديدة‬

‫• االستعانة بمصادر خارجية • توحيد • ترقية‬

‫قد تحصل على أهداف التصميم ‪ /‬الهندسة األولية الخاصة بك من عميلك ‪ ،‬و‬

‫جزء من هذه العملية هو التحقق من صحة هذه األهداف ‪ ،‬أو ربما إضافتها أو طرحها أو تعديلها أثناء العملية‪ .‬أمثلة على هذه‬
‫األهداف هي‪:‬‬

‫أهداف التصميم ‪ /‬الهندسة األولية • ترقية التكنولوجيا ‪ /‬البائع • تحسين األداء إلى جزء من الشبكة أو كلها • دعم المستخدمين‬
‫أو التطبيقات أو األجهزة الجديدة • حل المشكالت‪ 9‬المتصورة داخل النظام • زيادة األمان • دعم قدرة جديدة في النظام‬

‫في البداية ‪ ،‬قد ال تكون على علم بالقوى الخارجية ‪ ،‬سواء كانت سياسية أو إدارية أو مالية ‪ ،‬تعمل على الشبكة ما لم تكن‬
‫جزءًا من المنظمة التي تطلب العمل‪ .‬وبالتالي ‪ ،‬من المحتمل أن يكون لديك بعض ‪ ،‬وليس كل ‪ ،‬الشروط األولية لهيكل ‪/‬‬
‫تصميم الشبكة‪ .‬معرفة نوع ونطاق مشروع الشبكة يساعدك على التركيز الخاص بك‬
 ‫جهود‪ .‬على سبيل المثال ‪ ،‬يؤدي استبدال شبكة قديمة بشبكة جديدة تمامًا إلى تقليل عدد القيود التي تضع الشبكة الحالية على‬
‫البنية ‪ /‬التصميم (باستثناء بعض الشبكات‪ 9‬الخارجية الحالية التي سيتعين على الشبكة الجديدة التعامل معها) ‪ ،‬مما يتيح لك‬
‫التركيز على تحقيق األهداف المعمارية ‪ /‬تصميم لهذه الشبكة الجديدة‪ .‬عندما يكون المشروع عبارة عن تعديل أو ترقية‬
‫لشبكة حالية ‪ ،‬يكون لديك المزيد من القيود من الشبكة الحالية‪ .‬توفر الشبكة الحالية معلومات حول السلوك الحالي للشبكة وما‬
‫يمكن توقعه من التغييرات على الشبكة‪ .‬تقيد الشبكة الحالية الهندسة المعمارية والتصميم من منظور كيفية االتصال والتفاعل‬
‫مع جزء من الشبكة الحالية أو بأكملها‪ .‬وبالتالي ‪ ،‬فإن األداء‬

‫نطاق مشروع الشبكة • حجم الشبكة‬

‫• تعديل شبكة موجودة • عدد المواقع • تحليل مشاكل الشبكة‬

‫• تعد المسافة‪ 9‬بين مواقع ووظائف الشبكة الحالية ‪ ،‬إلى جانب أسباب إجراء تغييرات على الشبكة ‪ ،‬من الشروط األولية‬
‫المهمة‪ .‬تنطبق هذه الشروط أيضًا عند إجراء تحليل لشبكة فقط‪.‬‬

‫في هذه الحالة ‪ ،‬قد ال تعمل الشبكة كما هو مخطط لها ‪ ،‬وتحاول تحديد مكان وجود مشاكل في الهيكل أو التصميم ‪ ،‬أو حيث‬
‫يختلف التنفيذ عن الهيكل ‪ /‬التصميم‪ .‬إذا كنت تقوم بإنشاء شبكة للسماح باالستعانة بمصادر خارجية ‪ ، OAM & P‬فستشمل‬
‫الشروط األولية مكان حدوث االستعانة بمصادر خارجية ‪ ،‬واألساليب المستخدمة‪ 9‬من قبل وكيل االستعانة بمصادر خارجية‬
‫لتوفير وظائف ‪ .OAM & P‬من المحتمل أن تكون هناك عدة قيود على بنية الشبكة و‬

‫التصميم‪ .‬من خالل دراسة الشروط األولية في بداية عملية التحليل ‪ ،‬تكون لديك فرصة أفضل بكثير لفهم هذه القيود أو‬
‫إزالتها أو التعامل معها‪ .‬القيود الشائعة على مشروع الشبكة تشمل قيود التمويل ؛ العمل مع منظمات أو مجموعات مختلفة‬
‫داخل المنظمة ؛ القواعد واللوائح التنظيمية ؛ قيود الوقت والجدول الزمني ؛ والقيود الفنية من المستخدمين الحاليين‬
‫والتطبيقات واألجهزة والشبكات‪ 9‬واإلدارة‪ .‬قيود التمويل ضرورية لمشروع الشبكة‪ .‬كما سنرى في‬

‫عمليات التصميم والهندسة المعمارية ‪ ،‬خيارات التصميم ‪ /‬الهندسة المعمارية مقترنة بالتمويل المتاح‪ .‬يمكن أن يؤدي تجاهل‬
‫التمويل في عملية التحليل إلى خيارات التصميم ‪ /‬الهندسة المعمارية التي لن يتم تنفيذها ‪ ،‬بينما النظر في هذا القيد مقدمًا‬
‫يساعدك على تحقيق االستخدام األكثر ذكا ًء لتمويل الشبكة‪ .‬وبهذا المعنى ‪ ،‬يمكن اعتبار قيود التمويل إيجابية ‪ ،‬حيث إنها‬
‫تجبر مهندس الشبكة على تطوير حلول مبتكرة لتناسب قيود التمويل‪ .‬من المهم أيضًا الحصول على توقعات‪ 9‬جيدة للتمويل‬
‫المستقبلي قدر اإلمكان‪ .‬القيود التنظيمية ‪ ،‬مثل من ستعمل معه أو كيف‬

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

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

‫غالبًا ما تعمل المكونات الموجودة في النظام كقيود‪ .‬المستخدمين يعانون من‬

‫القصور الذاتي ‪ ،‬وعدم الرغبة في قبول التغييرات في الطرق التي يؤدون بها عملهم‪ .‬قد يلزم تعديل التطبيقات المكتوبة‬
‫الستخدامها محليًا على جهاز أو لتكنولوجيا أو بروتوكول شبكة معينة لتعمل على الشبكة الجديدة‪ .‬قد يلزم تغيير واجهات‬
‫الجهاز وبرامج التشغيل‪ .‬الشبكات الحالية تجلب أدائها وقيودها الوظيفية إلى المشروع‪ .‬من خالل معرفة أجزاء العملية‬
‫الحالية التي يتعين عليك دمجها أو دعمها في الشبكة الجديدة في وقت مبكر من العملية ‪ ،‬يمكنك تحديد الخيارات المعمارية ‪/‬‬
‫التصميمية التي ستعمل ‪ ،‬وبنفس األهمية ‪ ،‬لن تنجح‪ .‬قد يكون جزء من الشروط األولية لمشروع شبكتك هو الذي يحدد‬
 ‫هدف األداء‪ :‬أداء متعدد المستويات أو أداء من مستوى واحد (الشكل ‪ .)3.2‬عادة ما يكون لشبكات األداء متعددة المستويات‬
‫واحد أو عدد قليل من التطبيقات ‪ ،‬المستخدمين ‪ /‬المجموعات ‪ ،‬و ‪ /‬أو األجهزة التي تكون متطلبات أدائها أكبر بكثير من‬
‫متطلبات األداء األخرى لتلك الشبكة‪ .‬نتيجة لذلك ‪ ،‬هناك عتبة بين متطلبات األداء المنخفض والعالي لهذا النوع من الشبكات‪.‬‬
‫عاد ًة ما تدفع هذه المجموعة من المتطلبات عالية األداء كيف وأين يتم أرشفة األداء في الشبكة‪ .‬من ناحية أخرى ‪ ،‬ليس‬
‫لشبكات األداء أحادية الطبقة مجموعة مميزة‬

‫التطبيقات أو المستخدمين أو المضيفين الذين لديهم متطلبات أداء أكبر بكثير لتلك الشبكة ؛ لذلك ‪ ،‬ال يوجد أي عتبة بين األداء‬
‫المنخفض والعالي لهذا النوع من الشبكات‪ .‬هذا أمر مهم ألنه في حالة عدم وجود مجموعة من المتطلبات عالية األداء لدفع‬
‫كيفية ومكان أداء األرشفة في الشبكة ‪ ،‬يتم أرشفة األداء لدعم الجميع على قدم المساواة‪.‬‬

‫شبكة األداء متعددة المستويات‪ :‬حيث يكون هناك تطبيق واحد أو عدد قليل من التطبيقات ‪ ،‬المستخدمين ‪ /‬المجموعات ‪ ،‬و ‪/‬‬
‫أو األجهزة التي تكون متطلبات أدائها أكبر بكثير من متطلبات األداء األخرى لتلك الشبكة‬

‫مجموعة مميزة عالية من متطلبات األداء ‪HighPerformance‬‬

‫مجموعة من متطلبات األداء‬

‫مجموعة من متطلبات األداء األخرى‬

‫شكل منخفض منخفض ‪ 3.2‬تحديد أهداف األداء‪ :‬أداء فردي أو متعدد المستويات‬

‫شبكة األداء أحادية المستوى‪ :‬ال توجد مجموعة مميزة من التطبيقات أو المستخدمين أو المضيفين الذين لديهم متطلبات أداء‬
‫أكبر بكثير لتلك الشبكة‪.‬‬

‫مرتفع هذا أحد المفاهيم األساسية في هذا الكتاب ‪ ،‬والتي نناقشها‬

‫مزيد من التفاصيل في الهندسة المعمارية وعمليات التصميم‪ .‬بالنسبة للعديد من الشبكات‪ ، 9‬قد تحتاج إلى النظر في كال‬
‫النوعين في الهندسة المعمارية والتصميم‪ .‬يؤدي تحديد الشروط األولية للشبكة إلى عملية تحليل المتطلبات‪ .‬يجب أن تعرف‬
‫بعض الشروط األولية وعليك أن تتعلم اآلخرين‪ .‬عندما تبدأ في البحث عن اإلجابات ‪ ،‬تقوم بجمع المعلومات لعملية التحليل‪.‬‬

‫‪ 3.2.2‬تحديد توقعات‪ 9‬العمالء في هذه المرحلة من عملية التحليل ‪ ،‬من المهم البدء في تحديد توقعات العمالء‪ .‬هذا يتكون من‪:‬‬

‫• تقييم أولي سريع للمشكلة ‪ • ،‬تقدير الموارد والجدول الزمني‬

‫ليس المقصود أن يكون هذا تقديرً ا متعم ًقا ‪ ،‬بل هو تقييم سريع للتعرف على المشكالت‪ 9‬الواضحة‪ .‬تعتمد سرعة التقييم ‪ ،‬جزئيا ً‬
‫‪ ،‬على دورك في المشروع‪ .‬إذا كنت مستشارً ا أو مستشارً ا ‪ ،‬فقد يتعين عليك أن تكون سريعًا للغاية ‪ ،‬بنا ًء على ساعات أو‬
‫أيام‪ .‬إذا كنت مهندس الشبكة ‪ /‬مصمم شبكة المؤسسة ‪ ،‬فقد يكون لديك أسابيع إلجراء التقييم‪ .‬بشكل عام ‪ ،‬يمكن إجراء هذا‬
‫التقييم بنا ًء على بضعة أيام‪ .‬والقصد من ذلك هو إعالم العمالء ‪ ،‬في وقت مبكر من العملية ‪ ،‬عندما تكون توقعاتهم غير‬
‫واقعية‪ .‬هذا يساعد على إعادة تنظيم العميل ‪ ،‬إذا لزم األمر ‪ ،‬وتجنب التحميل الخلفي للمشروع‪ .‬ستكون هناك أوقات تجد فيها‬
‫تعريف العمالء للمشكلة وتوقعاتهم صحيحة تمامًا‪ .‬عادة ‪ ،‬ومع ذلك ‪ ،‬تحتاج إلى تعديل توقعاتهم إلى حد ما‪ .‬وقد تكون هناك‬
‫أوقات تجد فيها توقعاتهم وتوقعاتك متباعدة إلى درجة أنه من األفضل عدم االستمرار في هذا المشروع‪ .‬من األفضل اكتشاف‬
‫ذلك مبكرً ا في المشروع‪ .‬عندما تكون ممكنة ‪ ،‬يمكن أن تكون بيانات المشاكل مفيدة لك‬

‫مشروع‪ .‬عبارات المشكلة هي وصف لكل مشكلة من المشاكل التي يعالجها مشروع الشبكة‪ .‬تشكل عبارات المشكلة أساس‬
‫مشروع الشبكة‪ .‬يجب أن تقترن المتطلبات ببيانات المشكلة أثناء عملية المتطلبات‪ .‬عند القيام بذلك ‪ ،‬نضمن أن كل شرط‬
‫يرتبط بمشكلة واحدة أو أكثر ‪ ،‬وأن لكل مشكلة بعض المتطلبات المطبقة عليها‪ 3.2.3 .‬العمل مع المستخدمين‬

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

‫• تطوير استبيان إلرساله عبر البريد اإللكتروني أو الفاكس أو البريد إلى المستخدمين‪ • .‬متابعة االستطالع من خالل‬
‫مكالمات‪ 9‬هاتفية فردية أو مكالمات جماعية • متابعة المكالمات باجتماعات‪ 9‬وجهًا لوجه مع أفراد أو مجموعات محددة‬

‫• جلسات لوح المعلومات الستنباط األفكار من المستخدمين • قضاء الوقت مع المستخدمين أثناء عملهم لفهم أفضل لما‬
‫يفعلونه وكيف يفعلون ذلك‬

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

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

‫اإلشارات "‪ .‬على سبيل المثال ‪ ،‬تحدث إشارات التحذير عندما يكون هناك نقص في الدقة أو الوضوح في المتطلبات ‪ ،‬مثل‬
‫ما يلي‪:‬‬

‫• إساءة استخدام "الوقت الفعلي" • التوافر كنسبة مئوية فقط (‪" • )٪99.99‬أداء عالي" دون التحقق • متطلبات شديدة‬
‫التباين وغير متسقة • توقعات غير واقعية من العميل‬

‫عندما تواجه مثل هذه اإلشارات التحذيرية ‪ ،‬يجب أن تحاول ‪ ،‬كلما أمكن ذلك ‪ ،‬توضيح معنى البيان‪ .‬في وقت الحق من هذا‬
‫الفصل نناقش طرق لتوضيح العديد من األعالم الحمراء‪ .‬عندما تقوم بجمع المتطلبات والتفاعل مع المستخدمين ‪ ،‬فهذا أمر‬
‫جيد‬

‫الوقت لتقييم الرأي أن المستخدمين لديهم من الشبكة الحالية ‪ ،‬وكذلك موظفي الشبكات والعمليات‪.‬‬

‫‪ 3.2.4‬أخذ قياسات األداء‬

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

‫تحديد مقدار تدهور األداء الذي تتم مواجهته على الشبكة الحالية‪ .‬هذه القياسات تصبح التحقق من صحة مشاكل األداء على‬
‫الشبكة الحالية‪ .‬جنبا إلى جنب مع قياسات‪ 9‬األداء ‪ ،‬يمكنك في كثير من األحيان التقاط جميع حركة المرور‬

‫من جلسة التطبيق ‪ ،‬من خالل الرصد الخاطئ للشبكة‪ .‬هذه المعلومات مفيدة في توصيف ونمذجة تطبيق وسلوكيات المستخدم‬
‫‪ ،‬والتي تمت مناقشتها في القسم ‪ .3.4‬األدوات التي يمكن أن تساعد في التقاط حركة المرور تشمل ‪ Sniffer‬و ‪ Ethereal‬و‬
‫‪.Etherpeak‬‬
 ‫إذا تعذر بناء شبكة اختبار لقياس األداء ‪ ،‬والقياسات‬

‫يمكن إجراؤها على الشبكة الحالية (إذا سمحت اإلدارة بذلك)‪ .‬بينما ستكون قادرً ا على الحصول على بيانات األداء باستخدام‬
‫هذه التقنية ‪ ،‬فإن الشبكة الحالية ستحد من أداء التطبيقات واألجهزة‪ .‬هذه التقنية ال تزال مفيدة للغاية اللتقاط حركة المرور‬
‫لتوصيف ونماذج التطبيق وسلوكيات المستخدم‪ .‬يظهر هذان األسلوبان في الشكل ‪.3.3‬‬

‫‪ 3.2.5‬متطلبات التتبع واإلدارة‬

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

‫مثال ‪ .3.1‬يظهر أدناه متطلبات ترقيات معدات الشبكة‪.‬‬

‫‪ .NR - 1.0-102‬يجب أن تكون جميع معدات الشبكة (‪ )Technology A 3/7/2007‬قادرة على البرامج (أو البرامج‬
‫الثابتة ‪( )4/1/2000‬المحذوفة في ‪ )4/17/2007‬للسماح لها بدعم التغييرات على السرعة العالية (أي ‪)2007 / 5/20‬‬
‫ميزات خدمة البيانات والوظائف‪.‬‬

‫تم تغيير هذا المطلب كجزء من عملية التحليل‪ .‬كما ترون ‪ ،‬تم إجراء تغييرات في أوقات مختلفة ‪ ،‬مما يعكس تطور‬
‫المتطلبات أثناء التحدث إلى المستخدمين واإلدارة والموظفين‪ .‬في هذا المثال ‪ ،‬تم تغيير أحد المتطلبات (للترقيات المستندة‬
‫إلى البرامج) في ‪ 4/1/2007‬ليشمل الترقيات المستندة إلى البرامج الثابتة ‪ ،‬والتي تم حذفها في ‪ ، 4/17/2007‬واستعادتها‬
‫إلى شكلها األصلي‪ .‬من المهم مالحظة أنه بينما يتطور أحد المتطلبات ‪ ،‬فإن وصف هذا الشرط يبقي جميع التغييرات مرئية‪.‬‬
‫في هذا المثال ‪ ،‬يمكنك معرفة ما هو المتطلب األصلي وكيف تغير‪ .‬وبالتالي ‪ ،‬إذا أراد شخص ما إجراء تغيير تمت تجربته‬
‫من قبل ‪ ،‬فسيعلم ذلك مسب ًقا‪.‬‬

‫هناك طريقة أخرى لتتبع المتطلبات وإدارتها وهي استخدام نموذج جدولي‪ .‬في‬

‫هذه الطريقة يتم االحتفاظ بالشرط في شكله األصلي ‪ ،‬وتضاف أي تغييرات عليه إلى جدول‪ .‬يوضح الشكل ‪ 3.4‬كيف يتم‬
‫ذلك ‪ ،‬باستخدام المتطلب الوارد في المثال ‪ .3.1‬يمكن استخدام أدوات البرامج األخرى لهذه العملية ‪ ،‬مثل قواعد البيانات‬
‫وجداول البيانات‪ .‬النقطة األساسية هنا هي أن مستندات المتطلبات يجب أن تكون مستندات حية ‪ ،‬يتم تحديثها بشكل منتظم‬
‫لتعكس الطبيعة المتغيرة للشبكة والنظام‪ .‬كقائمة لما يحتاجه النظام من بنية الشبكة وتصميمها ‪،‬‬

‫سيتم استخدام هذه المتطلبات كأساس‪ 9‬لبقية هذا الكتاب‪ .‬يجب تضمين الشروط األولية والقيود وأي افتراضات حول بيئة‬
‫مشروع الشبكة في قائمة المتطلبات‪ .‬يساعد هذا في تحديد مكونات النظام التي نحتاج للحصول على مزيد من المعلومات‪.‬‬
‫‪ 3.2.6‬تعيين معلومات الموقع كجزء من عملية التحليل ‪ ،‬سيتم تعيين مواقع التطبيقات واألجهزة إلظهار مواقعها‪ 9‬الفعلية‬
‫النسبية‪ .‬في الفصل ‪ 2‬قدمنا مفهوم تطبيقات التعيين واألجهزة‪ .‬أثناء تجميع المتطلبات ‪ ،‬يجب عليك مالحظة (عند اإلمكان)‬
‫مواقع الخوادم واألجهزة المتخصصة ‪ ،‬وحيثما يتم استخدام تطبيقات محددة‪ .‬يوضح الشكل ‪ 3.5‬مثاالً على كيفية القيام بذلك‬
‫مع بيئة منطقة العاصمة مع األجهزة والتطبيقات‪.‬‬

‫‪ 3.3‬تطوير مقاييس الخدمة بعد تجميع متطلبات شبكتنا ‪ ،‬فإن الخطوة التالية هي تحليلها‬

‫المتطلبات من أجل التمييز بين مستويات األداء المختلفة في الشبكة‪ .‬سنقوم بتطوير واستخدام حدود األداء والحدود للتمييز‬
‫بين األداء المنخفض والعالي ‪ ،‬وكذلك استخدام خصائص األداء لتحديد مستويات األداء المضمونة والمضمونة‪ .‬يتم قياس‬
‫عتبات وحدود األداء وخصائص األداء في النظام بمقاييس الخدمة‪ .‬مقاييس الخدمة هي إما كميات قابلة للقياس الفعلي في‬
‫الشبكة أو هي‬
‫المستمدة من الكميات المقاسة‪ .‬تعد مقاييس الخدمة مهمة‪ ، 9‬حيث أنها "يفي المطاط بالطريق" ‪ -‬حيث يتم تقطير المتطلبات من‬
‫جميع الطبقات في النظام إلى كميات‪ 9‬قابلة للتكوين وقابلة للقياس‪ .‬أذكر من الفصل ‪ 2‬أنه من أجل أن تكون خاصية األداء‬
‫مميزة‬

‫مفيد ‪ ،‬يجب أن يكون شكلي وقابل للقياس ويمكن التحقق منه داخل الشبكة‪ .‬يكون هذا صحيحً ا بشكل خاص عندما تكون‬
‫أجزاء من الشبكة خارجة عن سيطرة مسؤول الشبكة ‪ -‬على سبيل المثال ‪ ،‬عند استخدام مزود الخدمة لتوفير خدمة مثل‬
‫‪ Frame Relay‬في الشبكة ‪ ،‬أو عندما تكون أجزاء من الشبكة (أو الشبكة بالكامل) ) هي االستعانة بمصادر خارجية‪ .‬في‬
‫مثل هذه الحاالت ‪ ،‬يمكن استخدام مقاييس الخدمة لضمان حصولك على الخدمة التي تطلبها (وتدفع مقابلها) من مزود الخدمة‬
‫أو وكيل االستعانة بمصادر خارجية‪ .‬تعتمد أنواع مقاييس الخدمة التي تستخدمها‪ 9‬على التصميم واألنواع الخاصة بك‬

‫المعدات (أجهزة الشبكة) التي تنفذها في شبكتك ‪ ،‬ولكن في هذه المرحلة من عملية التحليل ‪ ،‬يمكنك التأثير أو طلب ما سيتم‬
‫قياسه في الشبكة و (إلى حد ما) كيف سيتم قياسه‪ .‬تشمل مقاييس الخدمة لـ ‪:RMA‬‬

‫• الموثوقية ‪ ،‬من حيث متوسط الوقت بين حاالت الفشل (‪ )MTBF‬ووقت متوسط بين حاالت الفشل المهمة (‪)MTBCF‬‬

‫• إمكانية الصيانة ‪ ،‬من حيث الوقت المتوسط لإلصالح (‪ • )MTTR‬التوفر ‪ ،‬من حيث ‪• MTBF ، MTBCF ، MTTR‬‬
‫اختياريًا ‪ ،‬ووقت التشغيل والتوقف (كنسبة مئوية من إجمالي الوقت) ‪ ،‬ومعدالت الخطأ والخسارة على مستويات مختلفة ‪،‬‬
‫مثل الحزمة معدل الخطأ ‪ ،‬ومعدل الخطأ في البتات (‪ ، )BER‬ونسبة فقدان الخلية (‪ ، )CLR‬ونسبة التوهين الخلوي الخلوي (‬
‫‪ ، )CMR‬ومعدالت فقدان الرتل والحزم‬

‫تشمل مقاييس الخدمة للسعة‪:‬‬

‫• معدالت البيانات ‪ ،‬من حيث ذروة معدل البيانات (‪ ، )PDR‬ومعدل البيانات المستدام (‪ ، )SDR‬والحد األدنى لمعدل البيانات‬
‫(‪)MDR‬‬

‫• تشمل أحجام البيانات ‪ ،‬بما في ذلك أحجام الرشقات ومدة خدمة التأخير ‪ ،‬ما يلي‪:‬‬

‫• تأخير من طرف إلى طرف أو ذهابا وإيابا • زمن االنتقال • تباين التأخير ألن الكميات القابلة للتكوين والقابلة للقياس في‬
‫الشبكة ‪ ،‬يمكن وصف مقاييس الخدمة من حيث المتغيرات في أجهزة الشبكة‪ .‬هناك أيضا آليات ل‬

‫تكوين وقياس هذه المتغيرات‪ .‬كما نرى في الفصل ‪ 7‬حول إدارة الشبكة ‪ ،‬تم العثور على اآلليات الحالية لتكوين وقياس‬
‫مقاييس الخدمة في منصات إدارة الشبكة التي تستخدم بروتوكول إدارة الشبكة البسيط (‪ )SNMP‬وبروتوكول معلومات‬
‫اإلدارة المشتركة (‪ ، )CMIP‬وكالهما متغيرات الوصول الموصوفة في قواعد المعلومات اإلدارية ‪ ،‬أو ‪ .MIBs‬تصف‬
‫‪ MIBs‬متغيرات اإلدارة العامة والمؤسسية‪ .‬تتضمن أمثلة المتغيرات المستخدمة كمقاييس للخدمة ما يلي‪:‬‬

‫• بايت ‪ /‬إخراج (لكل واجهة) • حزم ‪ /‬إخراج ‪( IP‬لكل واجهة) • رسائل بروتوكول رسائل التحكم في اإلنترنت (‪/ )ICMP‬‬
‫وقت الوحدة (لكل واجهة)‬

‫• مقاييس اتفاقية مستوى الخدمة (‪( )SLA‬لكل مستخدم)‬

‫• الحد من السعة • التسامح انفجار • تأخير • التوقف‬

‫‪ 3.3.1‬أدوات القياس‬

‫باإلضافة إلى بروتوكوالت اإلدارة و ‪ ، MIBs‬يمكننا استخدام األدوات المتوفرة بشكل شائع للمساعدة في قياس مقاييس‬
‫الخدمة‪ .‬إحدى هذه األدوات هي أداة اختبار ‪( ping‬المتوفرة في إصدارات ‪ ، )TCP / IP‬والتي تقيس تقريبًا تأخيرات الرحلة‬
‫ذهابًا وإيابًا بين المصادر والوجهات‪ 9‬المحددة في الشبكة‪ .‬هناك أداة أخرى هي مخطط المسار (متاح من ‪، )ee.lbl.gov‬‬
‫والذي يجمع بين تأخير رحلة ذهابًا وإيابًا وقياسات سعة االرتباط مع آثار المسار ‪ ،‬وكذلك تتبع أداة مساعدة أخرى شائعة‪.‬‬
‫األداة الشائعة األخرى لتحليل حركة مرور ‪ TCP‬هي ‪ .TCPdump‬هناك أيضًا أدوات خاصة بالمؤسسات والمشاريع‬
 ‫الخاصة بالتكنولوجيا يمكن استخدامها باإلضافة إلى األدوات الموضحة هنا‪ .‬على سبيل المثال ‪ ،‬تتمثل إحدى طرق مراقبة‬
‫التوافر في الشبكة في استخدام ‪ping‬‬

‫لتقدير التأخير وفقدان الحزمة (انظر الشكل ‪ .)3.6‬يخبرنا ‪ Ping‬بالتأخير التقريبي ذهابًا وإيابًا ‪ ،‬وكذلك عند فقد حزم صدى‬
‫‪( ICMP‬حزم ‪ )ping‬في الشبكة أو في الوجهة‪ .‬على الرغم من أنها ليست طريقة دقيقة ‪ ،‬إال أنها سهلة اإلعداد واالستخدام‬
‫وتوفر آلية إنذار مبكر لمشاكل ‪ .RMA‬عند تطوير مقاييس الخدمة ‪ ،‬نريد أيضًا محاولة تحديد مكان الدخول‬

‫النظام الذي نريد قياس كل مقياس ‪ ،‬وكذلك اآلليات المحتملة للقياس ‪ ،‬كما في الشكل ‪.3.7‬‬

‫‪ 3.3.2‬مكان تطبيق مقاييس الخدمة‬

‫يتم تحديد مقاييس الخدمة جزئيًا حسب ما تنوي تحقيقه منها (على سبيل المثال ‪ ،‬فصل المسؤوليات)‪ .‬تكون مفيدة عند محاولة‬
‫خاصة عندما تكون هناك مجموعات متعددة مسؤولة عن الشبكة‪ .‬على سبيل المثال ‪ ،‬في‬‫ً‬ ‫عزل وتتبع المشكالت‪ 9‬في الشبكة ‪،‬‬
‫الشكل ‪ ، 3.6‬يمكن أيضًا استخدام مقاييس الخدمة التي يتم تطبيقها لفصل المسؤوليات بين موفر الخدمة الشاملة ومزود خدمة‬
‫شبكة ‪ WAN‬ومقدمي الخدمات‪ 9‬الوسيطة اآلخرين‪.‬‬

‫‪ 3.4‬وصف السلوك‬

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

‫التي يمكن استخدامها لتعديل وتقدير أفضل متطلبات أداء الشبكة‪ .‬ثم نقوم بتطبيق خصائص المستخدم والتطبيقات هذه أثناء‬
‫عملية تحليل التدفق‪ .‬تشمل أنواع السلوك التي ندرسها ما يلي‪:‬‬

‫• سلوك المستخدم • سلوك التطبيق • سلوك الشبكة‬

‫‪ 3.4.1‬النمذجة والمحاكاة‪9‬‬

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

‫تعرض الشاشات في هذا الشكل نتائج اختبارات األداء التي تعمل على هذا‬

‫محاكاة‪ .‬يتم عرض اإلنتاجية واالستخدام والتأخير بيانيا ً بمرور الوقت لتمثيل السلوك الزمني للشبكة‪ .‬يمكن تطوير النماذج‬
‫والمحاكاة باستخدام الملكية أو متاحة للجمهور‬

‫أدوات‪ .‬ومن المزايا الواضحة من وجود مثل هذه النماذج أنه بمجرد تطويرها ‪ ،‬يمكن استخدامها مرارً ا وتكرارً ا للمساعدة في‬
‫ضبط النظام للحصول على أفضل أداء‪ .‬وبالتالي ‪ ،‬على الرغم من أن هذه النماذج والمحاكاة‪ 9‬قد تستغرق وق ًتا وجه ًدا‬
‫لتطويرها ‪ ،‬إال أن استردادها بمرور الوقت قد يكون كبيرً ا‪ 3.4.2 .‬سلوك المستخدم‬
 ‫باالقتران مع تحديد مقاييس الخدمة لشبكتنا ‪ ،‬من المفيد فهم كيفية تطبيق مستخدمي النظام للتطبيقات‪ .‬يمكن أن تشمل أنماط‬
‫االستخدام البسيطة أوقات عمل المستخدم ومدده ؛ ولكل تطبيق إجمالي عدد المستخدمين ‪ ،‬التكرار الذي يتوقع من المستخدم‬
‫تشغيل جلسة للتطبيق (عاد ًة ما يكون عدد الجلسات لكل مستخدم ‪ ،‬في اليوم) ‪ ،‬إلى متى ستستمر مدة جلسة التطبيق المتوسطة‬
‫(عاد ًة حسب ترتيب الدقائق) ) ‪ ،‬وتقدير العدد المتوقع لجلسات المستخدم المتزامنة لهذا التطبيق‪ .‬المنطق هنا هو أنه يمكننا‬
‫تطوير قاعدة أساسية لتوسيع نطاق المتوقع‬

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

‫تسمح لك جلسات العمل في نفس الوقت بتطبيق معدل على متطلبات األداء لكل تطبيق (أو على األقل تلك التطبيقات التي‬
‫تراها مهمة بما يكفي لتوصيفها)‪ .‬على سبيل المثال ‪ ،‬إذا كان يمكنك تقدير عدد الجلسات المتزامنة ألحد التطبيقات ‪ ،‬فيمكن‬
‫استخدام هذا التقدير كمضاعف لمتطلبات سعة ذلك التطبيق‪ .‬وبالمثل ‪ ،‬إذا كنت تعرف مدة جلسة التطبيق ‪ ،‬فيمكنك استخدام‬
‫ذلك للمساعدة في تقدير مقدار الوقت الذي ستحتاج هذه الخدمة لهذا التطبيق إلى تهيئته داخل الشبكة‪.‬‬

‫‪ 3.4.3‬سلوك التطبيق من المفيد أيضًا تحديد سلوك جلسات التطبيق‪ .‬جنبا إلى جنب مع المستخدم‬

‫السلوك ‪ ،‬يمكن أن يساعدك سلوك التطبيق على تعديل متطلبات األداء لتحقيق تقدير أفضل للخدمات‪ 9‬ومستويات األداء التي‬
‫ستحتاجها لشبكتك‪ .‬في وصف سلوك التطبيق الذي ترغب في النظر في أحجام البيانات التي‬

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

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

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

‫‪ 3.5.1‬الموثوقية‬

‫الموثوقية هي مؤشر إحصائي لتكرار فشل الشبكة ومكوناتها وتمثل انقطاع الخدمة غير المجدولة‪ .‬مقياس واحد من الموثوقية‬
‫هو الوقت بين فشل المهمة‪ 9‬الحرجة‬
 ‫(‪ ، )MTBCF‬وعادة ما يتم التعبير عنها في ساعات‪ .‬التدبير ذو الصلة هو متوسط الوقت بين الفشل (‪ ، )MTBF‬والذي يأخذ‬
‫في االعتبار جميع حاالت الفشل ‪ ،‬بغض النظر عن أهميتها في وقت الفشل ‪ ،‬وهو تقريب متحفظ ‪ ،‬ومفيد في األنظمة‬
‫البسيطة‪ .‬يمكن أن تخلط ‪ MTBF‬بين مصمم النظام المعقد‪ .‬نظرً ا ألن األنظمة أصبحت أكثر تعقي ًدا وقيود الموارد تقيد درجة‬
‫التنوع أو شراء مكونات موثوقية أعلى ‪ ،‬يصبح استخدام ‪ MTBCF‬أكثر إضاءة ‪ ،‬على الرغم من أنه يتطلب تحلياًل أكثر دقة ‪،‬‬
‫مع التركيز على أداء النظام خالل سيناريوهات مهمة محددة‪ .‬يتم حساب‪ MTBF 9‬على أنه عكس معدل الفشل ‪ ،‬والذي يتم‬
‫تقديره من خالل االختبار أو التحليل من حيث حاالت الفشل في ساعات‪ 9‬العمل‪ .‬الحرجه هي في االعتبار من خالل النظر في‬
‫معدالت الفشل فقط من العناصر التي تعتبر حاسمة‪ 9‬للبعثة‪ .‬على السطح ‪ ،‬والحساب‪ 9‬الموثوقية مربكة بعض الشيء ؛ تذكر أن‬
‫العمليات الحسابية لموثوقية األنظمة يتم تنفيذها فعالً عن طريق إضافة معدالت الفشل (الفشل في الساعة) للمكونات ثم قلبها‪.‬‬

‫‪ 3.5.2‬الصيانة‬

‫الصيانة هي مقياس إحصائي للوقت الستعادة النظام إلى حالة التشغيل الكامل ‪ ،‬بمجرد أن يتعرض لخطأ‪ .‬يتم التعبير عن هذا‬
‫بشكل عام كوقت متوسط إلصالح (‪ .)MTTR‬يتكون إصالح فشل النظام من عدة مراحل‪ :‬الكشف ‪ ،‬وعزل الفشل عن مكون‬
‫يمكن استبداله ‪ ،‬والوقت الالزم لتسليم األجزاء الضرورية إلى موقع المكون الفاشل (وقت النقل واإلمداد) ‪ ،‬والوقت الالزم‬
‫الستبدال المكون الفعلي مكون ‪ ،‬اختباره ‪ ،‬واستعادة الخدمة الكاملة‪ MTTR .‬عاد ًة ما يفترض أن الوقت اللوجستي هو صفر ؛‬
‫هذا هو االفتراض ‪ ،‬وهو غير صحيح إذا كان يجب استبدال مكون الستعادة الخدمة ولكن يستغرق الحصول على أيام‪.‬‬

‫‪ 3.5.3‬التوفر‬

‫التوافر (المعروف أيضًا باسم التوافر التشغيلي) هو العالقة بين تكرار الفشل الحرج في المهمة ووقت استعادة الخدمة‪ .‬يتم‬
‫تعريف ذلك على أنه الوقت المتوسط بين حاالت الفشل في المهام الحرجة (أو الوقت المتوسط بين حاالت الفشل) مقسومًا‬
‫على مجموع الوقت الالزم إلصالحه والوقت المتوسط بين حاالت فشل المهمة‪ 9‬الحرجة أو متوسط الوقت بين حاالت الفشل‪.‬‬
‫يتم عرض هذه العالقات‪ 9‬أدناه ‪ ،‬حيث يتوفر ‪.A‬‬

‫‪ A = MTBCF / MTBCF + MTTR‬أو ‪A = MTBF / MTBF + MTTR‬‬

‫غالبًا ما يتم التغاضي عن بعض االعتبارات المهمة في تقييم التوافر‪ .‬بادئ ذي بدء ‪ ،‬ال يعكس التوافر بالضرورة النسبة‬
‫المئوية للوقت الذي يعمل فيه النظام ؛ ال تؤخذ الصيانة المجدولة في االعتبار في هذا الحساب ‪ ،‬فقط الصيانة غير المجدولة‪.‬‬
‫هذا مهم ألن الصيانة المجدولة ال تعاقب‪ 9‬النظام ألنه يمكن تنفيذه عندما ال تكون هناك حاجة للمكونات ألداء المهمة‪ .‬شاغلنا‬
‫الحقيقي هو الطبيعة المفاجئة لفشل النظام ‪ ،‬والتي تنعكس في توافرها‪ .‬يمنحنا تحليل توفر الشبكة القدرة على جدولة وقائية‬

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

‫معدالت الخسارة‪.‬‬

‫مدة التشغيل ووقت التوقف عن العمل يتم التعبير عن مقياس شائع للتوفر من حيث نسبة وقت التشغيل أو التوقف‪ .‬على سبيل‬
‫المثال ‪ ،‬قد يشير طلب تقديم عرض (‪ )RFP‬من عميل محتمل إلى وقت تشغيل مطلوب بنسبة ‪( ٪99.999‬يُعرف باسم‬
‫"خمس تسع") ‪ ،‬ولكن ماذا يعني ذلك ح ًقا؟ ماذا تعني مدة الجهوزية والتوقف الفعلي؟ عند تمثيل التوافر كنسبة مئوية من وقت‬
‫التشغيل أو التوقف ‪ ،‬يكون ذلك‬

‫تقاس في األسبوع ‪ ،‬الشهر ‪ ،‬أو السنة ‪ ،‬على أساس المبلغ اإلجمالي للوقت لتلك الفترة‪ .‬وقت التشغيل هو عندما يكون النظام‬
‫ً‬
‫جهازا)‪ .‬من خالل‬ ‫(التطبيقات واألجهزة والشبكات) متاحً ا للمستخدم (في هذه الحالة ‪ ،‬قد يكون المستخدم أيضًا تطبي ًقا أو‬
 ‫توفرها ‪ ،‬فإننا نعني النطاق من االتصال األساسي إلى القدرة فعليًا على تشغيل التطبيقات عبر الشبكة‪ .‬كيف يتم وصف ذلك‬
‫في تحليل المتطلبات مهم لكيفية قياسه والتحقق منه‪ .‬وبالمثل ‪ ،‬يمكن أن تتوقف فترة التوقف عن عدم القدرة على االتصال‬
‫عبر الشبكة ‪ ،‬إلى وجود إمكانية اتصال ولكن مع معدالت خسارة عالية بما يكفي (أو سعة منخفضة بدرجة كافية) بحيث ال‬
‫تعمل التطبيقات بشكل صحيح‪ .‬يوضح الشكل ‪ 3.10‬بعض نسب التوافر الشائعة (كنسبة مئوية من وقت التشغيل) ‪ ،‬والتي‬
‫تتراوح من ‪ ٪99‬إلى ‪ .٪99.999‬هناك طريقة أخرى لعرض التوافر وهي مقدار وقت التوقف عن العمل‬

‫لكل فترة زمنية‪ .‬يغطي النطاق الموضح في الشكل ‪ ٪ 99 - 3.10‬إلى ‪ - ٪ 99.999‬غالبية متطلبات وقت التشغيل‬
‫المطلوبة‪ .‬في الطرف األدنى من هذا النطاق ‪ ،‬يسمح ‪ ٪ 99‬للنظام أن ينخفض قليال من الوقت (أكثر من ‪ 87‬ساعة ‪ /‬سنة)‪.‬‬
‫قد يكون هذا مقبواًل في نماذج االختبار أو النماذج األولية للنظام ولكنه غير مقبول بالنسبة لمعظم األنظمة التشغيلية‪ .‬عندما‬
‫يقدم مزودو الخدمات‪ 9‬التجارية وقت التشغيل في الطرف األدنى من هذا النطاق ‪ ،‬يجب أن يؤخذ ذلك في الحسبان في التوفر‬
‫الكلي للشبكة‪ .‬مستوى الجهوزية ‪ ٪ 99.99‬هو أقرب إلى حيث تعمل معظم النظم في الواقع‪.‬‬

‫في هذا المستوى ‪ ،‬يُسمح بتوقف الوقت لمدة دقيقة واحدة في األسبوع ‪ ،‬أي ما يعادل عد ًدا قليالً من العابرين في األسبوع ‪ ،‬أو‬
‫حدثا قصيرً ا على الشبكة [حسب ترتيب الثواني] ‪ ،‬مثل حركة المرور‬ ‫واحدا في الشهر (حيث يكون العابر ً‬
‫ً‬ ‫ً‬
‫بسيطا‬ ‫انقطاعًا‬
‫إعادة توجيه ‪ ،‬أو فترة من االزدحام)‪ .‬تعتمد العديد من الشبكات التي كانت ذات متطلبات وقت تشغيل أقل من ‪ ٪99.99‬اآلن‬
‫على الشبكة أكثر من ذلك بكثير وتقوم بمراجعة متطلبات وقت التشغيل إلى ‪ ٪99.99‬أو أكثر‪ .‬عند ‪ ، ٪99.999‬تبدأ معظم‬
‫األنظمة بدفع حدود التشغيل الخاصة بها‪ .‬هذا المستوى‬

‫األداء ‪ ،‬الذي يشير إلى أن الشبكة تعتمد بشكل كبير (على سبيل المثال ‪ ،‬للتطبيقات المهمة) ‪ ،‬سوف يؤثر على بنية الشبكة‬
‫وتصميمها في العديد من المجاالت ‪ ،‬كما نوقش في الفصول الالحقة‪ .‬أخيرً ا ‪ ،‬يقترب وقت التشغيل الذي يتجاوز ‪٪99.999‬‬
‫من هامش األداء الحالي ‪ ،‬حيث يمكن أن ترتفع الجهود والتكاليف لدعم هذه الدرجة العالية من الجهوزية‪ .‬حتى أن هناك‬
‫بعض التطبيقات التي ال تستطيع تحمل أي وقت توقف أثناء الجلسة‪ .‬بالنسبة لهذه األنواع من التطبيقات ‪ ،‬تكون مدة التشغيل‬
‫‪ ٪100‬أثناء الجلسة‪ .‬مثال على هذا التطبيق هو التحكم عن بعد في حدث ما (على سبيل المثال ‪ ،‬قيادة مركبة أو إجراء‬
‫عملية) ‪ ،‬حيث قد يؤدي التوقف عن العمل إلى فقد السيارة أو خسارة محتملة في األرواح (أحد معايير المهمة‪ 9‬الحرجة للمهمة‪9‬‬
‫الوضعية)‪ .‬في مثل هذه الحاالت ‪ ،‬غالبًا ما تكون أوقات التوافر الكبير معروفة مسب ًقا (مجدولة) ويمكن التخطيط لها‪ .‬يجب‬
‫أن نالحظ في هذه المرحلة أن العديد من فترات انقطاع النظام قصيرة ج ًدا‬

‫(العابرين) وقد ال تؤثر على المستخدمين أو تطبيقاتهم‪ .‬في بعض الحاالت ‪ ،‬قد ال يعرف المستخدمون حتى وجود مشكلة ‪،‬‬
‫ألن انقطاع التيار الكهربائي قد يتجلى في توقف مؤقت في أحد التطبيقات‪ .‬ومع ذلك ‪ ،‬تعد هذه األحداث جزءًا من تقدير‬
‫الموثوقية ‪ ،‬خاصة في الشبكات‪ 9‬التي توجد فيها قيود صارمة على الموثوقية‪ .‬لذلك ‪ ،‬في حين أن التوقف لمدة ‪ 10‬دقائق‬
‫ملحوظا (على سبيل المثال ‪ ،‬جلسات عمل متقطعة) إذا حدث كل ذلك مرة‬ ‫ً‬ ‫أسبوعيًا (أو ‪ ٪99.9‬من وقت التشغيل) سيكون‬
‫واحدة ‪ ،‬فقد يكون توزيعًا فعليًا لعدة عابرين لمدة ‪ 15‬ثانية ‪ ،‬يؤدي كل منهما إلى تطبيقات المماطلة لعدة ثوان‪ .‬باستخدام هذه‬
‫المعلومات والجدول السابق لتقديرات وقت التشغيل ‪ ،‬يمكننا تقديم حد عام لوقت التشغيل‪ .‬العتبة العامة لوقت التشغيل ‪ ،‬بنا ًء‬
‫على الخبرة العملية ‪ ،‬هي ‪ .٪99.99‬عند تطبيق هذا الحد العام ‪ ،‬تعتبر متطلبات الجهوزية األقل من ‪ ٪99.99‬منخفضة‬
‫األداء ‪ ،‬ومتطلبات الجهوزية أكبر من أو تساوي ‪ ٪99.99‬تعتبر عالية األداء‪ .‬تذكر أن هذه العتبة العامة ُتستخدم في غياب‬
‫أي عتبات خاصة بالبيئة يمكن تطويرها لشبكتك كجزء من عملية تحليل المتطلبات‪.‬‬

‫قياس مدة التشغيل‪ :‬في بداية هذا القسم ‪ ،‬سألنا‪" :‬ماذا يعني ذلك (وقت التشغيل بنسبة ‪ )٪99.999‬ح ًقا؟" في الفصل ‪، 1‬‬
‫تتضمن متطلبات الخدمات إمكانية أن تكون قابلة للتكوين وقابلة للقياس ويمكن التحقق منها داخل النظام‪ .‬هذه واحدة من أكبر‬
‫المشكالت‪ 9‬التي تتطلب وجود نسبة مئوية من وقت التشغيل أو التوقف‪ :‬كيف يمكن تكوينه أو قياسه أو التحقق منه؟ فيما يتعلق‬
‫بقياس وقت التشغيل ‪ ،‬يمكن طرح هذا السؤال في ثالثة أجزاء‪ :‬متى‬

‫يجب قياسه (التردد) ‪ ،‬وأين يجب قياسه ‪ ،‬وكيف يجب قياسه (مقاييس الخدمة)؟ أوالً ‪ ،‬دعنا نفكر في تكرار القياس‪ .‬تتمثل‬
‫مشكلة التعبير عن الجهوزية فقط كنسبة مئوية في أنه ال يشمل عامل الوقت‪ .‬النظر ‪ ،‬على سبيل المثال ‪ ،‬شرط ل ‪٪ 99.99‬‬
‫الجهوزية‪ .‬بدون عامل الوقت ‪ ،‬يمكن أن يعني ذلك تعطاًل لمدة ‪ 53‬دقيقة سنويًا ‪ ،‬أو ‪ 4.4‬دقيقة شهريًا ‪ ،‬أو دقيقة واحدة في‬
‫األسبوع‪ .‬دون ذكر عامل الوقت ‪ ،‬يمكن أن يكون هناك انقطاع واحد يصل إلى ‪ 53‬دقيقة‪ .‬طالما أن هذا هو االنقطاع الوحيد‬
‫خالل العام ‪ ،‬يمكن تلبية متطلبات التوفر هذه‪ .‬يمكن أن تتسامح بعض الشبكات‪ 9‬مع فترة توقف تراكمية تبلغ ‪ 53‬دقيقة سنويًا ‪،‬‬
‫لكن ال يمكنها معالجة وقت تعطل واحد بهذا الحجم‪ .‬هناك فرق كبير بين انقطاع كبير واحد وانقطاع أصغر عدة‪.‬‬

‫إن ذكر عامل وقت (تردد) مع وقت تشغيل يجعل هذا المطلب‬

‫أكثر صالحة‪ .‬بالنسبة للشبكات التي ال تستطيع تحمل االنقطاعات الكبيرة ولكن يمكنها تحمل العديد من االنقطاعات الصغيرة‬
‫‪ ،‬قد يكون معدل الجهوزية بنسبة ‪ ٪99.99‬أسبوعيًا أكثر منطقية من مجرد ‪ ٪99.99‬من وقت التشغيل‪ .‬عن طريق ذكر‬
‫"تقاس أسبوعيا" ‪ ،‬كنت فرض شرط أن انقطاع ال يمكن أن يكون أكبر من دقيقة واحدة في األسبوع‪ .‬بعد ذلك ‪ ،‬دعونا نفكر‬
‫في المكان الذي يجب أن تقاس فيه مدة التشغيل‪ .‬ذكر فيها الجهوزية‬

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

‫شبكة االتصال‪ .‬إن فقدان الخدمة ألي جهاز في هذه الحالة يعد حسابًا عامًا‬

‫مدة التشغيل‪ .‬في الشكل ‪ ، 3.12‬تم تحسين الجهوزية ليطبق فقط بين كل مستخدم‬

‫‪ LAN‬و ‪ .LAN server‬في هذا المثال ‪ ،‬إذا فقدت الخدمة بين شبكات‪ LAN 9‬الخاصة بالمستخدم ‪ ،‬فلن يتم حسابها مقابل‬
‫متطلبات وقت التشغيل اإلجمالية‪ .‬في المثالين لدينا نظهر مفاضلة بين القدرة على تطبيق الجهوزية‬

‫في كل مكان وجود تطبيق دقيق وأكثر قابلية للتحقيق من الجهوزية‪ .‬ومع ذلك ‪ ،‬من الممكن تطبيق كالهما على نفس الشبكة‪.‬‬
‫يمكننا تطبيق معيار واحد في كل مكان في الشبكة ولدينا معيار آخر يتم تطبيقه بشكل انتقائي‪ .‬غالبًا ما يتم قياس وقت التشغيل‬
‫من طرف إلى طرف ‪ ،‬إما بين أجهزة المستخدم (عامة)‬

‫أجهزة الحوسبة) أو بين أجهزة الشبكة (أجهزة التوجيه أو المحوالت أو محطات‪ 9‬مراقبة ‪ /‬أمان الشبكة)‪ .‬على سبيل المثال ‪،‬‬
‫يمكن قياسها‪ 9‬من طرف إلى طرف ‪ ،‬في واجهات جهاز التوجيه ‪ ،‬حيث يتم فصل أجهزة التوجيه بشبكات متعددة‪ .‬تشتمل نقاط‬
‫القياس على واجهة ‪ LAN / WAN‬ونقاط الدخول ‪ /‬الخروج الخاصة بالموجه وفي محطات المراقبة الموزعة في جميع‬
‫أنحاء الشبكة‪ .‬يعد تحديد مكان قياس وقت التشغيل مه ًما‪ 9‬بشكل خاص عندما يتم تضمين مزودي الخدمة في النظام أو عندما‬
‫يتم ترسيم الخدمات‪ 9‬بين مناطق محددة جي ًدا في الشبكة‪ .‬أخيرً ا ‪ ،‬كيف تقيس الجهوزية مهمة‪ 9‬أيضًا‪ .‬كما نظهر الحقا في هذا‬

‫القسم ‪ ،‬قد يتم قياسه من حيث عدم االتصال أو كمعدل خسارة (معدل الخطأ في البتات ‪ ،‬أو الخلية ‪ ،‬أو اإلطار ‪ ،‬أو فقدان حزم‬
‫الرزم)‪ .‬تؤثر الطريقة التي تستخدمها‪ 9‬لقياس وقت التشغيل على كيفية تكوينها داخل أجهزة الشبكة ‪ ،‬وكذلك كيفية التحقق‬
‫منها‪ .‬عند تطوير االحتياجات الخاصة بك لوقت التشغيل ‪ ،‬ضع في اعتبارك أن البعض‬

‫يجب جدولة وقت التوقف على الشبكة ‪ ،‬من أجل إجراء تغييرات على الشبكة ‪ ،‬أو ترقية األجهزة والبرامج ‪ ،‬أو إجراء‬
‫االختبارات‪ .‬يجب أال يتم احتساب فترة التوقف المجدولة للصيانة مقابل مدة التشغيل اإلجمالية للشبكة ‪ ،‬ويجب تضمين مقدار‬
‫فترة التوقف المقررة (التردد والمدة) في متطلبات األداء‪ .‬في الواقع ‪ ،‬نظرً ا للطرق التي نحددها أين ومتى وكيف يتم قياس‬
‫وقت التشغيل ‪ ،‬يمكن أن يكون لدينا بالفعل متطلبات تشغيل متعددة في الشبكة‪ .‬على سبيل المثال ‪ ،‬قد يكون هناك متطلب عام‬
‫عبر الشبكة بالكامل ‪ ،‬يتم قياسه في كل مكان ‪ ،‬ومتطلبات أخرى ذات أداء أعلى ‪ ،‬يتم قياسها فقط بين األجهزة الحيوية في‬
‫الشبكة‪ .‬وبالتالي ‪ ،‬قد يبدو شرط وقت التشغيل مثل هذا‪( Network Uptime :‬انظر األشكال ‪ 3.11‬و ‪:)3.12‬‬

‫‪ .1‬مدة تشغيل ‪ ، ٪ 99.99‬تقاس أسبوعيا ‪ ،‬تقاس في كل واجهة جهاز وجهاز المستخدم في الشبكة‪.‬‬

‫‪ ٪ 99.999 .2‬الجهوزية ‪ ،‬تقاس أسبوعيا ‪ ،‬للوصول إلى شبكة مزرعة الخوادم ‪ ،‬ويقاس في واجهة جهاز التوجيه في‬
‫مزرعة الخوادم ‪ ،‬في بطاقات‪ NIC 9‬الخادم‪ .‬سيتم استخدام اختبار التطبيق أيضًا الختبار االتصال بين كل مستخدم ‪ LAN‬و‬
‫‪.LAN server‬‬
 ‫‪ .3‬الحظ أن هذه المتطلبات ال تنطبق على فترات التوقف المجدولة للصيانة‪.‬‬

‫‪ 3.5.4‬العتبات والحدود‬

‫قد تتضمن متطلبات ‪ RMA‬وص ًفا للعتبات و ‪ /‬أو الحدود‪ .‬يتم جمع و ‪ /‬أو اشتقاق متطلبات ‪ RMA‬لكل تطبيق من التطبيقات‬
‫في شبكتك من خالل المناقشات‪ 9‬مع مستخدمي كل تطبيق ‪ ،‬وكذلك من الوثائق المتعلقة بالتطبيقات واختبار التطبيقات على‬
‫الشبكة الحالية أو على شبكة اختبار‪ .‬من المتطلبات ‪ ،‬يمكنك غالبًا تحديد حدود (أو حدود) خاصة بالبيئة لكل تطبيق من خالل‬
‫تحديد مستويات أداء التطبيق‪ .‬من هذا يمكنك تحديد ما الذي يشكل ‪ RMA‬منخفضة وعالية األداء لشبكتك‪ .‬في حالة عدم‬
‫وجود حدود محددة للبيئة ‪ ،‬يمكنك استخدام الحدود العامة الواردة في هذا الفصل‪ .‬باإلضافة إلى ذلك ‪ ،‬تحقق من ضمانات‬
‫‪( RMA‬إن وجدت) للخدمات‪ 9‬و ‪ /‬أو التقنيات‬

‫الموجودة في الشبكة الحالية أو التي من المحتمل أن تكون في الشبكة المخططة‪ .‬على سبيل المثال ‪ ،‬تتمتع خدمة البيانات‬
‫متعددة المحوالت (‪ )SMDS‬الخاصة بـ ‪ Pacific Bell‬بتوفر محدد ‪ ،‬من حيث الوقت بين انقطاع الخدمة أو أكثر من ‪3500‬‬
‫ساعة ‪ ،‬مع متوسط الوقت الستعادة أقل من أو تساوي ‪ 3.5‬ساعات‪ .‬من ناحية أخرى ‪ ،‬تتطلب مواصفات ‪Bellcore‬‬
‫الخاصة بـ ‪ SMDS‬توفرً ا بنسبة ‪ .٪99.9‬من مناقشتنا السابقة يمكننا أن نرى أن كال من هذه المواصفات يصف خصائص‬
‫توفر مماثلة ‪ ،‬مع تحديد مواصفات ‪ .MTBCF / MTTR‬تتطلب بعض أساليب التقدير التي استخدمناها معرفة أي منها‬

‫التقنيات و ‪ /‬أو الخدمات موجودة أو المخطط لها للنظام‪ .‬نظرً ا ألننا في هذه المرحلة من العملية ال نعرف ح ًقا أي‬
‫التكنولوجيات و ‪ /‬أو الخدمات‪ 9‬التي سنستخدمها‪ 9‬لشبكتنا (كما هي محددة في عمليات التصميم والبنية) ‪ ،‬يمكن استخدام هذه‬
‫التقنيات في التقنيات و ‪ /‬أو الخدمات‪ 9‬الموجودة في الشبكة الحالية ‪ ،‬أو على مجموعة من التقنيات و ‪ /‬أو الخدمات‪ 9‬المرشحة‬
‫لشبكتنا المخططة‪ .‬في وقت الحق في الهندسة المعمارية وعمليات التصميم ‪ ،‬عندما نختار التقنيات و ‪ /‬أو الخدمات لشبكتنا ‪،‬‬
‫يمكننا تطبيق المعلومات التي تم جمعها‪ 9‬هنا لكل من هذه التقنيات ‪ /‬الخدمات‪ .‬مثال على العتبة العامة لـ ‪ RMA‬هو وقت‬
‫التشغيل‪ .‬المستخدمين عادة‬

‫توقع تشغيل النظام في أقرب وقت ممكن من ‪ .٪100‬يمكن أن تصل مدة التشغيل إلى ما يقرب من ‪ ، ٪100‬في غضون‬
‫العاشرة أو المائة ‪ ،‬أو في بعض األحيان ألف في المائة ‪ ،‬ولكن بمقايضات تعقيد النظام وتكلفته‪ .‬في وقت سابق من هذا‬
‫الفصل وصفنا عتبة عامة لوقت التشغيل ‪ ،‬بنا ًء على الخبرة والمالحظة ‪ ،‬وهي ‪ .٪99.99‬بشكل عام ‪ ،‬تعتبر متطلبات وقت‬
‫التشغيل التي تزيد عن أو تساوي ‪ ٪99.99‬أدا ًء مرتفعًا ‪ ،‬ومتطلبات أقل من ‪ ٪99.99‬منخفضة األداء‪ .‬باإلضافة إلى ذلك ‪،‬‬
‫يمكن استخدام عتبة عامة تبلغ حوالي ‪ ٪99.5‬لتمييز متطلبات األداء المنخفض عن متطلبات النماذج األولية وأساليب‬
‫االختبار‪ .‬وتظهر هذه العتبات في الشكل ‪ .3.13‬الحظ أن أي عتبات خاصة بالبيئة تم تطويرها من أجل‬

‫أن الشبكة تحل محل هذه العتبات العامة‪ .‬يستخدم الخطأ أو معدل الخسارة كمقياس للجهوزية‪ .‬على سبيل المثال ‪ ،‬ل‬

‫يمكن استخدام متطلبات الجهوزية بنسبة ‪ ٪99.99‬أو فقدان الحزمة أو الخلية لقياس هذا األداء‪ .‬بالنسبة للعديد من التطبيقات‬
‫‪ ،‬أظهرت التجربة أن خسارة الرزمة بنسبة ‪ ٪2‬تكفي لفقد جلسات التطبيق‪ .‬يمكن اعتبار هذا تعطاًل وهو في الواقع قياس‬
‫عملي أكثر والتحقق من وقت التشغيل أكثر من محاوالت التمثيل الرياضي‪ .‬إذا كنت تستخدم عتبة خسارة بنسبة ‪ ٪2‬وقياس‬
‫فقد الحزمة في الشبكة ‪،‬‬

‫يتم حسابه على أنه تعطل عندما تكون خسارة الحزمة أكبر من ‪ .٪2‬بالنسبة إلى ‪ ٪99.99‬تم قياسها أسبوعيًا ‪ ،‬يمكن أن‬
‫يكون للشبكة خسارة في الرزم بنسبة ‪ ٪2‬أو أكثر لمدة دقيقة واحدة في األسبوع (انظر القسم ‪ .)3.5.3‬باإلضافة إلى الحدود‬
‫المذكورة أعاله ‪ ،‬ينبغي ضمانات األداء والخدمة‬

‫أيضا أن تكون مدرجة حسب متطلبات التطبيق‪ .‬تحديد متطلبات الجهوزية هو عملية تكرارية‪ .‬مع تطور المستخدمين‬
‫واألجهزة والتطبيقات والشبكات‪ ، 9‬سوف تحتاج إلى تعديل متطلباتهم‪.‬‬

‫‪ 3.6‬تطوير متطلبات التأخير للتطبيقات التي لها متطلبات تأخير ‪ ،‬نستخدم مصطلحات التأخير من البداية إلى النهاية ‪،‬‬
‫والتأخير ذهابًا وإيابًا ‪ ،‬وتغيير التأخير كتدابير للتأخير في الشبكة‪ .‬نبدأ بتقديم بعض العتبات والحدود العامة المفيدة للتأخير‪:‬‬
 ‫تأخير التفاعل ووقت استجابة اإلنسان وتأخير نشر الشبكة‪ .‬هذه الحدود والقيود مفيدة في التمييز بين متطلبات التأخير‬
‫المنخفضة والعالية األداء لشبكتك‪ .‬تأخير التفاعل (‪ )INTD‬هو تقدير للوقت الذي يرغب المستخدم في انتظاره‬

‫استجابة من النظام خالل جلسة تفاعلية‪ .‬يتم تعريف الجلسة هنا بأنها الفترة الزمنية التي يكون خاللها التطبيق ً‬
‫نشطا‪ .‬يعتمد‬
‫تأخير التفاعل على سلوك المستخدم وبيئة المستخدم وأنواع التطبيقات المستخدمة‪ .‬قد تتراوح فترات تأخير التفاعل بين‬
‫‪ 100s‬من المللي ثانية ودقيقة أو أكثر‪ .‬بشكل عام ‪ ،‬يتراوح مدى فائدة من ‪ 10‬إلى ‪ 30‬ثانية‪ .‬يعد ‪ INTD‬مه ًما‪ 9‬عند إنشاء‬
‫شبكة موجهة نحو التطبيقات التفاعلية‪ .‬يُعد تقدير ‪ INTD‬مفي ًدا في وصف التطبيقات التفاعلية بشكل فضفاض ‪ ،‬وتلك التي‬
‫يتوقع انتظار تلقي المعلومات فيها‪ .‬ينطبق هذا على تطبيقات معالجة المعامالت ‪ ،‬وكذلك على الويب ونقل الملفات ومعالجة‬
‫بعض قواعد البيانات‪ .‬بالنسبة لتطبيقات مثل هذه ‪ ،‬سوف يالحظ المستخدم درجة من التأخير ‪ ،‬و ‪ INTD‬هو تقدير لمدى‬
‫استعداد المستخدمين لالنتظار‪ .‬الحد األعلى لـ ‪ INTD‬هو مقياس لمستوى تحمل المستخدمين‪ .‬زمن االستجابة البشرية (‬
‫‪ )HRT‬هو تقدير لعتبة الوقت التي المستخدمين‬

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

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

‫وسيط أو رابط مادي ‪ -‬على سبيل المثال ‪ ،‬تأخير االنتشار عبر وصلة ‪ .DS3‬يوفر هذا ح ًدا أدنى للتأخير في النظام والشبكة‬
‫ذهابًا وإيابًا وتأخير النظام‪ .‬تأخير االنتشار يعتمد على المسافة والتكنولوجيا‪ .‬إنه مفيد كحد أدنى للتأخير ‪ ،‬ألنه يخبرنا متى قد‬
‫ال يعمل التطبيق بشكل جيد عبر الشبكة ‪ ،‬ألن شرط تأخير نشر الشبكة الخاص به يكون أكثر صرامة من تأخير االنتشار‬
‫الفعلي أو المخطط للشبكة‪ .‬وترد عتبات وحدود التأخير هذه في الشكل ‪ .3.14‬أي أو كل هذه‬

‫قد يتم تطبيق تقديرات التأخير على شبكة‪ .‬على سبيل المثال ‪ ،‬يمكننا استخدام العالج التعويضي بالهرمونات كحد أقصى‬
‫لجميع الخدمات ‪ ،‬مما يقيد البنية والتصميم لتوفير خصائص تأخير أقل من العالج بالهرمونات البديلة لتلك الشبكة‪ .‬أو يمكننا‬
‫اختيار قيمة لـ ‪ INTD‬تحدد وتحد من الخدمة التفاعلية‪ .‬في جميع الحاالت ‪ ،‬يوفر تأخير نشر الشبكة ح ًدا أدنى للتأخير‪ .‬يمكن‬
‫أيضًا استخدام أي من تقديرات التأخير هذه كضمانات على الخدمة‪ .‬تأتي تقديرات التأخير هذه من التجربة ويتم تقديمها من‬
‫أجلك‬

‫العتبار‪ .‬قد ال توافق على قيمها أو تجد تقديرات مفيدة أخرى للتأخير‪ .‬نشجعك على تطوير تقديراتك الخاصة أو تحسين‬
‫التقديرات المقدمة هنا‪ .‬نظرً ا ألنك تعرف الشبكة والنظام والبيئة لمشروع الشبكة لديك ‪ ،‬فأنت في أفضل وضع لتطبيق هذه‬
‫التقديرات على شبكتك‪ .‬يمكننا استخدام تقديرات ‪ HRT‬و ‪ INTD‬لمساعدتنا على التمييز بين التطبيقات التفاعلية التفاعلية‬
‫والتطبيقات المجمعة‪ .‬عندما تكون استجابة التطبيق (مدى تكرار وسرعة تفاعل التطبيق مع المستخدم) والتأخير من البداية‬
‫إلى النهاية أو ذهابًا وإيابًا (أيهما متاح لقياس النظام) مقيدة بواحدة من خصائص التأخير هذه ‪ ،‬تقدير أن التطبيق هو انفجار‬
‫التفاعلية أو التفاعلية بالجملة‪ .‬في الشكل ‪ 3.15‬يتم استخدام ‪ HRT‬و ‪ INTD‬كحدود للفصل التفاعلي‬

‫انفجر والتطبيقات السائبة التفاعلية‪ .‬بين هذين التقديرين للتأخير ‪ ،‬يتراوحان بين ‪ ms 100‬و ‪ 30-10‬ثانية ‪ ،‬هي منطقة‬
‫رمادية حيث يمكن اعتبار التطبيق إما رشقة تفاعلية أو جملة تفاعلية‪ .‬من المحتمل أن يكون استخدام ‪ INTD‬و ‪ HRT‬الطريقة‬
‫األكثر مباشرة للتمييز بين التطبيقات التفاعلية التفاعلية والتطبيقات المجمعة‪.‬‬

‫‪ 3.6.1‬التأخير من البداية إلى النهاية والتأخير في الرحلة ذهابًا وإيابًا تتألف التأخيرات من البداية إلى النهاية والتأخيرات من‬
‫مصادر عديدة ‪ ،‬بما في ذلك‬
 ‫نشر ‪ ،‬طابور ‪ ،‬نقل ‪ ، I / O ،‬التبديل ‪ ،‬والمعالجة‪ .‬على الرغم من أنه سيكون من المفيد أن تكون قادرً ا على مراقبة وقياس‬
‫كل مصدر للتأخير ‪ ،‬إال أنه غير عملي لمعظم الشبكات‪ .‬لذلك ‪ ،‬يتم استخدام المجاميع مثل التأخر من النهاية إلى النهاية‬
‫وتأخر الرحلة ذهابًا وإيابًا‪ .‬بالنسبة إلى العديد من الشبكات ‪ ،‬وخاصة شبكات ‪ ، IP‬يتم قياس تأخير رحلة الذهاب واإلياب‬
‫باستخدام إصدارات مختلفة من أداة اختبار ‪ .ping‬يوفر ‪ Ping‬شكالً مفي ًدا وقياسًا بسهولة ومتاحً ا لتأخير الرحلة ذهابًا وإيابًا‪.‬‬
‫أذكر أننا استخدمنا تأخير نشر ‪ HRT‬و ‪ INTD‬وشبكة كما عتبات‬

‫وحدود للتمييز بين مستويات األداء لمتطلبات التأخير‪ .‬وهي تستند إلى مجموعات من‪:‬‬

‫• الحدود المادية للشبكة — على سبيل المثال ‪ ،‬حجم الشبكة والمسافات‪ 9‬بين التطبيقات و ‪ /‬أو المستخدمين و ‪ /‬أو األجهزة‬

‫• أداء الجهاز والبرمجيات • أداء بروتوكول الشبكة • سلوك التطبيق في عتبات التأخير معينة • تفاعل المستخدم مع النظام‬
‫في عتبات التأخير معينة‬

‫من المبادئ التوجيهية لتطوير متطلبات التأخير تحديد العامل المقيد من عتبات وحدود التأخير‪ .‬سيكون العامل المحدد هو‬
‫عنق الزجاجة النهائي للتأخير في النظام‪ .‬عند العثور على عوامل محددة ‪ ،‬يمكن في الغالب تقليلها أو إزالتها ‪ ،‬مما يكشف عن‬
‫عامل التحديد التالي‪ .‬تتكرر هذه العملية حتى يتم العثور على عامل محدود ال يمكن تقليله أو إزالته ‪ ،‬أو حتى يكون تأخير‬
‫النظام عند مستوى مقبول‪ .‬بالنظر إلى أن الحدود المادية للتأخير هي حدود مطلقة (سرعات اإلشعاع الكهرومغناطيسي عبر‬
‫الوسائط المختلفة معروفة ً‬
‫جيدا) ‪ ،‬فقد تؤثر أو تلغي عتبات التأخير األخرى‪ .‬على سبيل المثال ‪ ،‬إذا كان التطبيق يتطلب‬
‫تأخيرً ا ذهابًا وإيابًا قدره ‪ 80‬مللي ثانية لدعم بيئة الواقع االفتراضي التفاعلي (‪ ، )VR‬ويتم توزيع جلسة التطبيق بين لوس‬
‫أنجلوس وطوكيو ‪ ،‬فإن تأخر الرحلة ذهابًا وإيابًا لشبكة (تقريبًا ‪ 120‬مللي ثانية) ستتجاوز متطلبات تأخير التطبيق ‪ ،‬بغض‬
‫النظر عن بنية الشبكة وتصميمها‪ .‬وبالتالي ‪ ،‬إما أن يأخذ التطبيق في االعتبار تأخير رحلة الذهاب واإلياب بين لوس أنجلوس‬
‫وطوكيو ‪ ،‬ربما عن طريق تعديل الكود أو الخوارزميات أو نموذج االستخدام ‪ ،‬أو ال يمكن توزيع جلسات التطبيق بين هذه‬
‫المواقع‪ .‬تتيح معرفة ذلك مبكرً ا في عملية التصميم لمطوري التطبيقات أو مهندسي الشبكات‪ 9‬التكيف مع الحدود المادية‬
‫للشبكة‪ .‬اآلن دعنا نقول أن مسافة‪ 9‬الشبكة أعاله تقل ‪ ،‬و‬

‫تبلغ القيود المادية للتأخير اآلن ‪ 10‬مللي ثانية (على سبيل المثال ‪ ،‬الشبكة اآلن بين لوس أنجلوس وسان فرانسيسكو)‪ .‬ومع‬
‫ذلك ‪ ،‬من خالل اختبار التطبيق على الشبكة الحالية ‪ ،‬من المتوقع أن يحدث تأخر ذهابًا وإيابًا قدره ‪ 100‬مللي ثانية داخل‬
‫النظام (يرجع ذلك أساسًا إلى األجهزة المستخدمة)‪ .‬ماذا يمكن ان يفعل؟ قد يكون من الصعب للغاية تحديد أداء األجهزة‬
‫والبرامج لألجهزة وفهمها وتحسينها‪ .‬في تصميم الشبكات‪ 9‬وتصميمها ‪ ،‬نحتاج إلى محاولة مراعاة كل قطعة في مسار‬
‫االتصاالت الشامل (تدفقات حركة المرور) ‪ ،‬والتي قد تتكون من مجموعة متنوعة من األجهزة‪ .‬ما الذي يمكن أن نبحث عنه‬
‫سيؤدي إلى تقليل مصادر التأخير المحتملة في النظام ‪ ،‬دون قدر غير معقول من الوقت والجهد والتكلفة؟ تتضمن المناطق‬
‫التي يجب البحث فيها عن مصادر التأخير التي يمكن تعديلها أو توليفها أنظمة تشغيل الكمبيوتر وبروتوكوالت الشبكة‬
‫وملحقات األجهزة‪ .‬ما يمكننا البحث عنه في هذه المناطق هو أنظمة تشغيل بطيئة وسيئة السمعة‬

‫مكتوبة ‪ ،‬البروتوكوالت التي يتم تنفيذها بشكل سيء ‪ ،‬واألجهزة و ‪ /‬أو األجهزة الطرفية غير المتطابقة أو التي تم تكوينها‬
‫بشكل خاطئ‪ .‬من الواضح أن هذا النوع من المعلومات لن يأتي من الشركة المصنعة ولكن يمكن العثور عليه في كثير من‬
‫األحيان في قوائم البريد ومجموعات األخبار واالختبارات المستقلة والبحث األكاديمي ‪ ،‬وكلها متوفرة بشكل متزايد عبر‬
‫الويب‪ .‬من خالل إجراء بعض األبحاث ‪ ،‬يمكنك معرفة الكثير بسرعة حول مشاكل األداء مع األجهزة‪ .‬تقديم المالحظات‬
‫والتحليالت الخاصة بك ‪ ،‬واستخالص االستنتاجات الخاصة بك‪ .‬كما سنرى الح ًقا في هذا الكتاب ‪ ،‬ستلعب خدمات‪ 9‬الدعم مثل‬
‫إدارة الشبكات والتوجيه واألمان أيضًا دورً ا في تأخير الشبكة‪ .‬حدود التأخير بنا ًء على سلوك التطبيق وتفاعل المستخدم تكون‬
‫عمومًا أكثر مرونة من التأخير البدني أو التأخير في الجهاز‪ .‬تذكر أن قيم ‪ INTD‬و ‪ HRT‬هي تقديرات (النطاق المقدر لـ‬
‫‪ ، )INTD‬لذلك هناك بعض المرونة لتكييفها مع بيئتك‪ .‬بينما في المثال السابق ‪ ،‬كان التأخير المادي في رحلة ذهابًا وإيابًا هو‬
‫الحد األقصى ‪ ،‬عندما تم تقليل مسافة‪ 9‬الشبكة بحيث كان تأخير رحلة ذهابًا وإيابًا في حدود ‪ 10‬مللي ثانية ‪ ،‬وسلوك التطبيق‬
‫(بيئة ‪ VR‬التفاعلية) ‪ ،‬مع ‪ 40‬شرط تأخير مللي ثانية ‪ ،‬قد يصبح العامل المحدد‪ .‬إذا كان هذا مقبواًل للمستخدمين ‪ ،‬فسيتم‬
‫تحسين تقديرات التأخير (من وجهة نظرنا عالية المستوى) لتلك البيئة‪.‬‬

‫‪ 3.6.2‬تباين التأخير‬
 ‫غالبًا ما يقترن تباين التأخير بالتأخير من البداية إلى النهاية أو ذهابًا وإيابًا إلعطاء متطلبات أداء تأخير شاملة للتطبيقات‬
‫الحساسة‪ 9‬لوقت تبادل المعلومات‪ .‬بعض األمثلة على هذه التطبيقات هي تلك التي تنتج أو تستخدم معلومات الفيديو والصوت‬
‫والقياس عن بعد‪ .‬بالنسبة إلى تباين التأخير المقترن بالتأخير من البداية إلى النهاية أو في رحلة ذهابًا وإيابًا ‪ ،‬عندما ال تتوفر‬
‫أي معلومات حول متطلبات التباين في التأخير ‪ ،‬من القواعد الجيدة استخدام ‪ ٪1‬إلى ‪ ٪2‬من التأخير من البداية إلى النهاية‬
‫كتأخير االختالف‪ .‬على سبيل المثال ‪ ،‬يبلغ تقدير تباين التأخير (في حالة عدم وجود أي متطلبات معروفة) ‪ ،‬عندما يكون‬
‫التأخر من طرف إلى طرف ‪ 40‬مللي ثانية ‪ ،‬ما يقرب من ‪ 400‬إلى ‪ 800‬ميكروثانية‪ .‬سيكون هذا تقريبًا تقريبًا ‪ ،‬ومع ذلك‬
‫‪ ،‬يجب التحقق منه إذا أمكن ذلك‪.‬‬

‫‪ 3.7‬تطوير متطلبات القدرات‬

‫عند تقييم متطلبات سعة التطبيق ‪ ،‬نريد مراعاة التطبيقات التي تتطلب كميات كبيرة من السعة باإلضافة إلى تلك التي تتطلب‬
‫قيمة محددة (الذروة أو الحد األدنى أو المستدام) أو مجموعة من السعات‪ .‬عندما يتطلب تطبيق ما مقدارً ا كبيرً ا من السعة ‪،‬‬
‫من المهم معرفة متى يكون للتطبيق مطلب حقيقي (قابل للقياس ‪ ،‬يمكن التحقق منه) للسعة العالية ‪ ،‬وعندما يحاول (أو‬
‫بروتوكول النقل الذي يستخدمه) ببساطة االستفادة من السعة المطلوبة‪ .‬متاح‪ .‬التطبيقات التي تستخدم ‪ TCP‬كآلية نقل خاصة‬
‫بها ‪ ،‬دون أي شروط أو تعديالت إضافية من بروتوكوالت الطبقة العليا (أو من التطبيق نفسه) ‪ ،‬تتلقى مستويات أدائها بنا ًء‬
‫على الحالة الحالية للشبكة (أي أفضل جهد)‪ .‬يتم ذلك عن طريق توصيل وضبط معلمات‪ 9‬نقل ‪( TCP‬عبر قناة التحكم ‪TCP‬‬
‫بين الجهازين في جلسة ‪ )TCP‬طوال جلسة ‪ TCP‬كرد فعل لظروف االزدحام الظاهر في الشبكة‪.‬‬

‫‪ 3.7.1‬تقدير معدالت البيانات‬

‫يعتمد تقدير معدل البيانات (أو ربما أكثر دقة المعلومات) على مقدار المعلومات التي تعرفها حول خصائص اإلرسال (مثل‬
‫تدفق حركة المرور) للتطبيق ومدى دقة التقدير‪ .‬تتضمن معدالت البيانات الشائعة االستخدام معدل بيانات الذروة (‪، )PDR‬‬
‫أو معدل البيانات المستدام (‪ ، )SDR‬أو الحد األدنى لمعدل البيانات (‪ ، )MDR‬أو مجموعات من هذه‪ .‬يمكن قياس معدالت‬
‫البيانات هذه في طبقة واحدة أو أكثر في الشبكة (على سبيل المثال ‪ ،‬فعلي أو ارتباط البيانات أو الشبكة أو النقل أو الجلسة)‪.‬‬
‫وتحد معدالت البيانات لجميع التطبيقات ببعض العوامل المحددة‪ .‬هذه‬

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

‫معدل بيانات "بأسرع وقت ممكن"‪ .‬لدينا شعور بديهي بالنسبة لبعض هذه التطبيقات (مثل ‪ FTP‬و ‪ - )telnet‬على سبيل‬
‫المثال ‪ ،‬يمكننا أن نكون متأكدين تمامًا من أن جلسة ‪ telnet‬لن تحتوي على معدل بيانات يبلغ ‪ 100‬ميجا بايت ‪ /‬ثانية ؛‬
‫وبالمثل ‪ ،‬يجب أال تعمل جلسة ‪ FTP‬في ‪ 10‬كيلو بايت ‪ /‬ثانية إذا توفرت سعة أكبر‪ .‬ما يمكننا القيام به لتقدير معدالت‬
‫البيانات للتطبيقات هو النظر في بياناتهم‬

‫األحجام وأوقات االنتهاء المقدرة‪ .‬تعتمد أحجام البيانات وأوقات اإلكمال على ما يريده المستخدمون أو يتوقعونه ‪ ،‬أو يمكن‬
‫قياسها على الشبكة الحالية‪ .‬أخذ التطبيق الذي لديه قدرة غامضة وخصائص التأخير ‪ ،‬مثل‬

‫كوصول إلى الويب ‪ ،‬يمكننا تقدير معدل البيانات من أحجام البيانات التي يوفرها المستخدم والتطبيق وأوقات اإلكمال (على‬
‫سبيل المثال ‪ .)INTD ،‬قد نطلب من عدد من المستخدمين الحصول على أمثلة للصفحات التي يتوقعون الوصول إليها ‪ ،‬أو‬
‫المعلومات التي سيقومون بتنزيلها ‪ ،‬والوقت الذي يودون انتظاره لكل حدث‪ .‬من هذه المعلومات ‪ ،‬يمكننا إنشاء إدخاالت في‬
‫جدول مثل الجدول أدناه (الشكل ‪ .)3.16‬من التقديرات مثل تلك الواردة في الشكل ‪ ، 3.17‬يمكننا تقدير الحدود العليا والدنيا‬
‫لمعدالت بيانات التطبيق ‪ ،‬أو لمعدل متوسط‪ .‬بالنسبة للتطبيقات األخرى ‪ ،‬قد تكون خصائص نقل البيانات أفضل‬
 ‫معروف ‪ ،‬مثل أحجام مجموعات البيانات التي يتم نقلها وكذلك تواتر ومدة هذه التحويالت‪ .‬قد ينطبق هذا على التطبيقات‬
‫القائمة على المعامالت‪ ، 9‬مثل معالجة بطاقات االئتمان والتطبيقات المصرفية والحوسبة الموزعة‪ .‬النظر في تطبيق معالجة‬
‫البيانات التفاعلية عن بعد الذي يتصل به‬

‫متاجر البيع بالتجزئة ومعالجة معلومات العمالء ‪ ،‬مثل إدخاالت بطاقة االئتمان‪ .‬يمكننا اعتبار الحدث (المهمة) بمثابة معالجة‬
‫لمعلومات‪ 9‬بطاقة ائتمان عميل واحد‪ .‬بعد ذلك ‪ ،‬يكون وقت إتمام المهمة‪ 9‬بترتيب ‪ INTD‬الذي تمت مناقشته‪ 9‬مسب ًقا ‪ -‬ما بين ‪10‬‬
‫إلى ‪ 30‬ثانية تقريبًا ‪ ،‬على الرغم من أنه قد يكون متوقعًا من قِبل المستخدمين (موظفي المتجر) أن يكون أصغر كثيرً ا ‪،‬‬
‫ثوان ‪ ،‬و حجم البيانات لكل مهمة صغير إلى حد ما ‪ ،‬بترتيب من ‪ 100‬إلى ‪ 1000‬بايت‪ .‬مثال آخر‬ ‫ٍ‬ ‫حسب ترتيب ‪ 5‬إلى ‪10‬‬
‫هو بيئة الحوسبة التي تشارك فيها أجهزة متعددة‬

‫المعالجة لمهمة‪ .‬في كل تكرار للمهمة ‪ ،‬يتم نقل البيانات بين األجهزة‪ .‬قد نعرف هنا مدى تكرار نقل البيانات وحجم نقل كل‬
‫ضا) ومقدار الوقت الالزم لمعالجة البيانات (التي قد تشير إلى مقدار الوقت الذي قد يستغرقه‬ ‫منها (والذي قد يكون ثاب ًتا أي ً‬
‫النقل)‪ .‬يظهر الشكل ‪ 3.17‬شبكة حوسبة مشتركة متعددة المعالجات‪ .‬بالنسبة لبعض التطبيقات ‪ ،‬تكون خصائص السعة‬
‫معروفة جي ًدا ‪ ،‬ويمكن أن يكون تقدير معدل البيانات أمرً ا سهالً نسبيًا‪ .‬تحتوي التطبيقات التي تتضمن الصوت و ‪ /‬أو الفيديو‬
‫عادة على متطلبات سعة معروفة‪ .‬من المحتمل أن تكون معدالت هذه التطبيقات ثابتة ‪ ،‬بحيث تكون معدالت الحد األدنى‬
‫والحد األقصى للبيانات هي نفسها ‪ ،‬أو سيكون هناك نطاق معروف من القيم‪ .‬على سبيل المثال ‪ ،‬سيكون معدل تدفق‬
‫المعلمات‪ 9‬المقيدة ذات المستوى المنخفض )‪ MPEG-2 (CPB‬بمعدل ‪ 4‬ميجابايت ‪ /‬ثانية ‪ ،‬أو سيكون معدل ‪ CPB‬على‬
‫المستوى الرئيسي يتراوح بين ‪ 15‬و ‪ 20‬ميجابايت ‪ /‬ثانية‪ .‬ال توجد حاليًا حدود عامة أو حدود على السعة‬

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

‫لقد طورنا في الفصل ‪ .1‬هذه العتبات ‪ ،‬كما هو موضح في الشكل ‪ ، 3.18‬تستخدم لفصل المظروف في مناطق منخفضة‬
‫األداء وعالية األداء‪ .‬هذا يعطينا تفسير مرئي لمتطلبات األداء النسبي لشبكتنا ويمكن استخدامه لربط متطلبات األداء باإلدارة‪.‬‬

‫‪ 3.8‬تطوير متطلبات األداء التكميلية‬

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

‫‪ 3.8.1‬المالءمة‪ 9‬التشغيلية‬

‫نادراً ما يكون ضمان أن عميلك قادر على تشغيل الشبكة المخططة مهمة سهلة وهو أمر ال يفكر فيه العميل أب ًدا حتى يُطلب‬
‫منه ذلك‪ .‬هناك عامالن رئيسيان يؤثران على المالءمة‪ 9‬التشغيلية‪ :‬هندسة ‪ /‬تصميم الشبكات وجودة المشغلين البشريين‪ .‬من‬
‫الممكن تطوير شبكة ال يمكن تشغيلها باستمرار و‬

‫على نحو فعال‪ .‬التعديالت المعقدة من دقيقة إلى دقيقة يمكن أن تغمر حتى أكثر الموظفين كفاءة‪ .‬يمكن أن يؤدي االفتقار إلى‬
‫أي أدوات مراقبة أو أنظمة تحكم فعالة لدمج اإلجراءات عبر المواقع الموزعة جغرافيًا إلى تحويل التصميم األكثر تقدمًا إلى‬
‫كتلة مختلة وظيفيًا من الكابالت وأجهزة الكمبيوتر وإعادة االتهامات والدعاوى القضائية‪ .‬يجب أن يأخذ تطوير الشبكة في‬
‫االعتبار إدارة الشبكة التي تسمح للمشغلين بضبط الشبكة وإعادة تكوينها عند الحاجة‪ .‬إذا احتاجوا إلى القيام بذلك كل بضع‬
‫دقائق ‪ ،‬يجب أن تكون إدارة الشبكة سهلة التشغيل ويجب أن تقدم عناصر التحكم بطريقة سهلة الفهم‪ .‬يمكن أن تهالك موظفي‬
‫العمليات الصغيرة الحجم بسرعة وإحباطهم‬
 ‫الشبكة التي تتطلب تميل ثابت ودقيق‪ .‬ال تحتاج المكونات التي ال تحتاج إلى ضبط إال عند تثبيتها إلى تشويش وحدة التحكم‬
‫المدمجة‪ .‬مراقبة النظام ضرورية لضبط أداء النظام من قبل مشغليها ؛ يجب أن تكون شاشات‪ 9‬العرض قابلة للوصول ‪،‬‬
‫ويجب أن تستخدم البيانات المعروضة تمثياًل جي ًدا‪ .‬هل يجب أن يكون هناك وحدة تحكم عمليات واحدة (أو زائدة عن الحاجة)‬
‫أو يجب تشغيل النظام من أي متصفح ويب داخل الشبكة؟ إلى أي درجة يتم دمج األتمتة لتقليل عبء عمل المشغلين أو‬
‫لتحسين االستجابة للظروف المتغيرة على ما يمكن لإلنسان توفيره؟ هل تعديل النظام أمر نادر الحدوث بحيث ال يلزم وجود‬
‫نظام تحكم متكامل؟ وتناقش هذه القضايا بالتفصيل في الفصل ‪ .7‬عقيد البحرية الذي أدار برنامج تطوير نظام رئيسي‬

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

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

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

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

‫نفس موظفي الشبكة القديمة أو ذلك ‪ ،‬كحد أدنى ‪ ،‬فإن موظفي العمليات لن يكونوا أغلى من الموظفين الحاليين‪ .‬من‬
‫الضروري أن يلتقي مهندس التصميم بموظفي العمليات لتطوير رأي حول مستوى مهاراتهم وقدرتهم على فهم التقنيات‬
‫الجديدة واعتماد إجراءات وأدوات جديدة‪ .‬هناك مفاضلة بين أتمتة النظام والقوى العاملة ‪ ،‬وتتمثل المفاضلة في أنه يمكن‬
‫استخدام مشغلين أقل كفاءة‪ .‬بعض موظفي العمليات غير راغبين أو غير قادرين على تعلم كيفية تشغيل النظم الجديدة ؛ يجب‬
‫استقدام موظفين جدد ألداء هذه الوظائف‪ .‬قد تبدو متطلبات اختيار المشغل ومؤهالته وتدريبه (األولي والتجديد على حد‬
‫سواء) مرهقة ولكنها ضرورية للغاية‪ .‬إذا كانت متطلبات االحتفاظ بنفس الموظفين صعبة وسريعة ‪ ،‬فيجب أن يأخذ تصميم‬
‫النظام الذي يستخدم المكونات المتقدمة والمعماريات‪ 9‬هذا في االعتبار‪.‬‬

‫يجب جمع متطلبات المالءمة‪ 9‬التشغيلية من المقابالت‬

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

‫• كيف سيقوم المشغلون بمراقبة األداء للتأكد من أنهم يكتشفون حاالت الفشل أو األعطال أو االنقطاعات قبل قيام العميل بذلك‬
‫‪ ،‬أو هل يعتمد المشغلون على المستخدمين الكتشاف األخطاء واإلبالغ عنها؟‬

‫• كيف يتفاعل المستخدم النهائي مع النظام والمشغلين ‪ ،‬بما في ذلك مشاكل اإلبالغ ‪ ،‬وكيف يتم تتبع هذه التقارير والردود‬
‫المقدمة؟ في حالة توفر مستويات متعددة من جودة الخدمة ‪ ،‬كيف يطلب المستخدم النهائي زيادة أو يأذن بتخفيض جودة‬
‫الخدمة؟‬

‫• في أي نقطة تنتقل مشكلة العمليات إلى إجراء صيانة ‪ ،‬وكيف يحدث ذلك حتى ال يتم إهماله؟‬

‫• كيف يقوم موظفو العمليات بمراقبة قدرة النظام وتنبيه اإلدارة إلى الحاجة إلى توسيع السعة بما يتجاوز الموارد المتاحة‬
‫لهم؟ ما أنواع تحليل متوسط الوقت الذي سيتم تنفيذه لتوقع نمو الطلب؟‬

‫‪ 3.8.2‬الدعم‬

‫عال من األداء‬
‫يتمثل أحد المكونات الرئيسية لرضا العميل عن الشبكة ‪ ،‬كما يتم تسليمها ‪ ،‬في قدرته على الحفاظ على مستوى ٍ‬
‫الذي تم تحقيقه في يوم التسليم طوال فترة تصميم الشبكة‪ .‬سوف يتعرف العميل غير المتطور نسبيًا على الجودة الرديئة‬
‫للتصميم والتنفيذ فقط عندما يكون خارج الخدمة كثيرً ا ؛ سيقوم عميل ذو خبرة ودراية بفحص التصميم بعناية قبل التصريح‬
‫بالتنفيذ ويرغب في معرفة ما إذا كان سيوفر باستمرار أدا ًء جي ًدا طوال دورة حياته‪ .‬سيرغب هذا العميل أيضًا في معرفة ما‬
‫يلزم لتشغيل التصميم وما يلزم لدعم العمليات المستمرة‪ .‬سوف يفهم العميل المتطور اآلثار المترتبة على مفهوم العمليات‬
‫ومفهوم الدعم وسيحترم التزام المصمم باألداء المستمر بعد اكتمال التنفيذ ودفع رواتب المهندسين‪ .‬تعتمد قابلية الدعم على‬
‫خمسة عوامل رئيسية‪ )1( :‬خصائص الموثوقية ‪ ،‬والصيانة ‪ ،‬وتوافر التشغيل (‪ )RMA‬للهندسة ‪ /‬التصميم ؛ (‪ )2‬القوى‬
‫العاملة ‪ ،‬بما في ذلك مستويات التدريب والموظفين ؛ (‪ )3‬إجراءات النظام والوثائق الفنية ؛ (‪ )4‬األدوات القياسية والخاصة‬
‫؛ و (‪ )5‬قطع غيار وإصالح‪ .‬يجب إجراء فئتين من الصيانة على الشبكة بمجرد نشرها‪ :‬وقائية وتصحيحية‪ .‬في نهاية‬
‫المطاف ‪ ،‬يتم تعريف متطلبات الصيانة كما تم توطيد التصميم‪ .‬تكون متطلبات الصيانة ‪ ،‬خالل هذه المرحلة من تعريف‬
‫النظام ‪ ،‬ذات طبيعة عامة ‪ ،‬مثل‪:‬‬

‫• سيتم تحديد موقع جميع المكونات حيث يمكن الحفاظ عليها في مكانها‪ 9‬مع الحد األدنى من تعطيل النظام ككل‪.‬‬

‫• سيتم توفير قطع الغيار لضمان استبدال أي مكون قد يؤدي فشله إلى تعريض أداء المهمة‪ 9‬للخطر‪.‬‬

‫‪ RMA‬الخطوة األولى في تحديد متطلبات ‪ RMA‬هي توضيح عينة تمثيلية من سيناريوهات المهمة‪ 9‬التي ستستخدم فيها‬
‫الشبكة‪ .‬تم توثيقها في سرد قصصي يصف كيفية حدوث االستخدام ‪ ،‬ومتى سيحدث ‪ ،‬وما هو ضروري لنجاح المهمة‪، 9‬‬
‫ومدى أهميتها لمستخدمي الشبكة‪ .‬يتضمن هذا العنصر األخير عدد مرات استخدام الشبكة ومستوى األولوية المعين لهذه‬
‫المهمة‪ .‬على سبيل المثال ‪ ،‬قد تحتوي الشبكة الموضحة في القسم ‪ 2.5.3‬على مستخدمين في شبكة‬

‫بناء الذين يحتاجون إلى الوصول إلى البيانات في مبنى آخر والتي هي ضرورية لدفع رواتب الموظفين ؛ مسار تدفق البيانات‬
‫هذا ضروري فقط من ‪ 4‬إلى ‪ 5‬مسا ًء بعد ظهر يوم الجمعة حتى يمكن إنجاز كشوف المرتبات محليا خالل عطلة نهاية‬
‫األسبوع والموظفين دفع صباح يوم االثنين‪ .‬لذلك ‪ ،‬يصبح هذا أمرً ا مه ًما‪ 9‬خالل تلك الفترة ‪ ،‬وقد يستمر هذا الوضع ‪ ،‬حتى يتم‬
‫تشغيل المعالجة المحلية ‪ ،‬وإال فلن يتم إنجاز كشوف المرتبات صباح االثنين ‪ ،‬مما يؤدي إلى استياء الموظفين وجميع حاالت‬
‫عدم الرضا التي يمكن أن يحضر‪ .‬لم يعد هذا المسار حرجً ا في المهمة بعد ظهر يوم االثنين ‪ ،‬وبالتالي فقد يتعطل أو يتم‬
‫إيقاف تشغيله للصيانة في تلك المرحلة ‪ ،‬شريطة أال يتعارض مع وظائف أخرى‪ .‬يتمثل أحد االعتبارات المحتملة في‬
‫التصميم في تضمين اختبار نظام نهاية إلى نهاية تلقائي قبل بداية هذه الفترة الحرجة التي س ُتبلغ المشغلين عند حدوث فشل في‬
‫النظام ‪ ،‬إذا لم يتم تصحيحه ‪ ،‬فقد يؤدي ذلك إلى تأخير رواتبهم لألسبوع التالي‪ .‬يمكن دمج العديد من الميزات المعمارية‬
‫والتصميم ‪ ،‬ولكن فقط إذا كان المهندس المعماري ‪ /‬المصمم يعرف كيف سيتم استخدام النظام‪ .‬استنا ًدا إلى سيناريوهات‬
 ‫المهمة‪ ، 9‬يمكن إنشاء مخططات كتلة الموثوقية (‪ )RBD‬لكل مهمة‪ ، 9‬مما يوضح العالقات التسلسلية والمتوازية بين المكونات‬
‫وأداء المهمة‪ .‬خالل مرحلة تحليل المتطلبات ‪ ،‬تكون هذه المستويات عالية ج ًدا وتعكس المهام إلنجاز المهمة ‪ ،‬بدالً من‬
‫مكونات إلنجاز المهمة‪ .‬ويرد نموذج ‪ RBD‬في الشكل ‪ .3.20‬بمجرد تطوير التصميم ووضع التفاصيل المعمارية ‪ ،‬فإن‬
‫أوضاع الفشل‬

‫يجب تقدير آثارها وإجراء تحليل للنقد (‪ )FMECA‬لتحديد الطرق األساسية‪ 9‬التي يمكن للنظام من خاللها فشل أداء مهمته‪.‬‬
‫يمكن أن يؤدي ذلك بعد ذلك إلى المصمم إلنشاء‪ 9‬أوضاع الكشف التي من شأنها الحد من حدوث الفشل أو تسريع استعادة‬
‫الخدمة‪ .‬يظهر في الشكل ‪ 3.21‬نموذج لبيانات ‪.FMECA‬‬

‫عند إجراء تحليل ‪ RMA‬للتصميم ‪ ،‬من الضروري أن نتذكر ذلك‬

‫‪ RMA‬هي أداة لمساعدة المصمم على فهم أداء النظام حتى يتمكن من اتخاذ قرارات مستنيرة‪.‬‬

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

‫المدربين وامتالك المؤهالت المناسبة‪ .‬تتمثل إحدى الطرق لتحديد المتطلبات في هذا المجال في مسح مهارات القوى العاملة‬
‫الحالية ‪ ،‬والعمق ‪ ،‬والتدريب الرسمي ‪ ،‬وتوثيق هذه الميزات ‪ ،‬واستخدامها كأساس‪ 9‬للقوى العاملة الجديدة لصيانة الشبكة‪.‬‬
‫يمكن عندئ ٍذ معالجة أي تغييرات مطلوبة عند إجراء تغييرات هندسية على متطلبات خط األساس والقوة العاملة الحالية‪.‬‬

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

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

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

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

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

‫تمثل متطلبات اإلصالح وقطع الغيار التي يجب فرضها على مخزون قطع الغيار واإلصالحات‪ 9‬في هذه المرحلة قيو ًدا نوعية‬
‫‪ ،‬وليست قائمة باألجزاء الواجب تسليمها‪ .‬تتضمن بعض نماذج المتطلبات التي قد يحددها العمالء في هذه المرحلة ما يلي‪:‬‬

‫• يجب تخزين قطع الغيار واإلصالح في مرفق عمليات الشبكة وال يمكن أن تتجاوز ‪ ،‬في الحجم ‪ ،‬المساحة المخصصة ‪،‬‬
‫والتي هي أقدام مكعبة‪.‬‬

‫• يجب أال تتجاوز قطع الغيار واإلصالح األولية ‪ ٪15‬من تكاليف اقتناء النظام‪ • .‬يجب أن تكون المركبات المتعاقدة مع‬
‫قطع الغيار واإلصالح بديلة قبل القدرة التشغيلية األولية‪.‬‬

‫يتم تحديد المتطلبات المحددة للصيانة بشكل عام بواسطة هندسة الشبكات وتصميمها ويتم توثيقها في خطة الصيانة ‪ ،‬بنا ًء‬
‫على التصميم‪ .‬في النهاية ‪ ،‬يتم توفير قطع الغيار واإلصالح من التصميم الفعلي وتحليل الصيانة للتصميم‪.‬‬

‫مفهوم الدعم يصف مفهوم الدعم الطريقة التي يتم بها دعم الشبكة‪ .‬قد يساعد تعريف المفهوم بوضوح في توضيح قيود‬
‫العمالء ويساعد في تحديد األساليب البديلة للدعم التي يمكن استيعابها في التصميم‪ .‬يعد مفهوم دعم الصيانة المقبول بشكل‬
‫شائع هو النموذج ثالثي المستويات‪.‬‬

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

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

‫مكون فاشل ‪ ،‬اسحب الوحدة القابلة لالستبدال التي تحتوي عليها ‪ ،‬واستبدله الستعادة الخدمة‪ .‬ثم يتم شحن وحدة اإلصالح‬
‫المحلية الفاشلة (‪ )LRU‬إلى المستوى الثاني أو حتى إلى المصنع لإلصالح أو التجديد‪ .‬يجب تقديم الوثائق إلى القوى العاملة‬
‫من المستوى األول التي تصف كيفية سحب واستبدال المكونات ‪ ،‬ويجب أن يكون لديهم مجموعة محدودة من األدوات‬
‫والمعدات الخاصة إلنجاز هذه الوظائف‪ .‬كما يجب معالجة درجة استخدام الخدمات المتعاقد عليها‬

‫من خالل مفهوم الدعم‪ .‬عاد ًة ‪ ،‬في هذه المرحلة من تحليل المتطلبات ‪ ،‬يكفي توثيق النموذج الحالي للدعم وتحديد أي تغييرات‬
‫قد تكون مطلوبة لدعم الشبكة الجديدة‪.‬‬
 ‫‪ 3.8.3‬الثقة‬

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

‫• لكل ارتباط أو دارة ‪ ،‬مثل معدالت الخطأ في البتات (‪ • )BER‬معدالت فقدان الحزمة بين أجهزة توجيه طبقة الشبكة • من‬
‫طرف إلى طرف ‪ ،‬بين أجهزة أو تطبيقات الحوسبة‬

‫يعتمد تحديد معدل الخطأ أو الخسارة المقبول على قدرة التطبيق على تحمل األخطاء أو فقدان المعلومات‪ .‬هذا ‪ ،‬بدوره ‪،‬‬
‫يتضمن الموثوقية والتبعيات بين الطبقات المختلفة في الشبكة‪ .‬على سبيل المثال ‪ ،‬قد يعتمد التطبيق الذي ينقل البيانات في‬
‫الشبكة على طبقة النقل لتوفير نقل مضمون‪ .‬إذا كانت طبقة النقل المستخدمة هي بروتوكول التحكم في اإلرسال (‪، )TCP‬‬
‫فإن موثوقية اإلرسال تعتمد على قدرة ‪ TCP‬على التعافي من األخطاء في الشبكة أو على اإلخطار بفشل اإلرسال‪ .‬إذا كان‬
‫بروتوكول النقل هو بروتوكول مخطط بيانات المستخدم (‪ ، )UDP‬ومع ذلك ‪ ،‬ال يوجد ضمان موثوقية من طبقة النقل ‪ ،‬ويتم‬
‫تمرير الموثوقية إلى رابط البيانات والطبقات المادية أو يجب توفيرها بواسطة التطبيق نفسه‪ .‬غالبًا ما يتم قياس الخسارة في‬
‫الطبقات المادية والوصلة والشبكة ويتم اإلبالغ عنها‬

‫كنسبة مئوية من حركة المرور المتاحة في الشبكة‪ .‬وبالتالي ‪ ،‬يمكننا تحديد عتبات فقدان الخلية أو اإلطار أو الرزم وفترات‬
‫زمنية ‪ ،‬كما هو مبين في الشكل ‪ .3.23‬ومن المثير لالهتمام ‪ ،‬يمكننا استخدام أداة ‪ ping‬المعروفة كأداة قياس ممكنة‪ .‬يمكن‬
‫استخدام معدل فقد ‪ ping‬كمؤشر على أن الشبكة تقترب من عتبة الخسارة وأنه يلزم إجراء قياس أكثر دقة (مثل استطالع‬
‫‪ SNMP‬إلحصائيات الموجه أو متغيرات المراقبة عن بُعد [‪ .)]RMON‬بينما يمكن أن يكون األمر ‪ ping‬مفي ًدا في هذا‬
‫الوضع ‪ ،‬إال أن فقد حزم ‪( ICMP‬اختبار ‪)ping‬‬

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

‫كتاب‪ .‬لقد تحدثنا عن التطبيقات المهمة‪ 9‬والمهمة والحاسمة‪ 9‬في الوقت الفعلي والتفاعلية‪ .‬تشير هذه الشروط إلى القدرة والتنبؤ‬
‫والتأهيل و ‪ RMA‬على التوالي‪ .‬لقد تحدثنا أيضًا عن تطوير حدود وحدود خاصة بالبيئة لفصل األداء المنخفض والعالي‬
‫لشبكات األداء متعددة المستويات‪ .‬التطبيقات التي تتميز باألداء العالي هي أيضًا مرشحة للخدمة التي يمكن التنبؤ بها‪ .‬في‬
‫الواقع ‪ ،‬يمكن أن يكون الحد الفاصل بين األداء المنخفض والعالي هو الحد الفاصل بين أفضل خدمة ممكنة ويمكن التنبؤ بها‪.‬‬
‫لذلك ‪ ،‬ما إذا كنت تحدد متطلبات األداء أو ال يمكن التنبؤ بها‬

‫مبني على‬

‫• تحديد ما إذا كان التطبيق هو مهمة حرجة ‪ ،‬معدل الحرج ‪ ،‬في الوقت الحقيقي ‪ ،‬أو التفاعلية‬

‫• تحديد ما إذا كان هناك أي حدود أو حدود أداء خاصة بالبيئة‬

‫• تطبيق حدود وحدود عامة ‪ ،‬إذا لزم األمر • مناقشة النتائج مع العميل (العمالء) (المستخدمين ‪ ،‬اإلدارة ‪ ،‬وما إلى ذلك)‬
‫لالتفاق على المتطلبات التي ينبغي اعتبارها قابلة للتنبؤ‬
 ‫‪ 3.10.2‬متطلبات األداء المضمون تعد متطلبات األداء المضمونة أكثر المتطلبات الصارمة للشبكة ‪ ،‬ليس بالضرورة من‬
‫حيث مستوى األداء بل من حيث ما هو مطلوب لدعم (أو ضمان) هذا األداء للجهاز أو التطبيق ‪ ،‬أو المستخدم‪ .‬كما هو الحال‬
‫مع المتطلبات التي يمكن التنبؤ بها ‪ ،‬تتم اإلشارة إلى المتطلبات المضمونة عند تحديد التطبيقات الحرجة للمهمة و ‪ /‬أو‬
‫الحرجة ‪ /‬في الوقت الفعلي و ‪ /‬أو التفاعلية ‪ ،‬وكذلك عند تحديد متطلبات األداء العالية (متعددة المستويات)‪ .‬من أجل الحفاظ‬
‫على استمرارية الدورة‪ .‬تسمح بعض تطبيقات القياس عن بُعد غير المهمة‪ 9‬أيضًا بفقدان البيانات‪.‬‬

‫‪ 3.9‬عتبات وحدود خاصة بالبيئة تعطينا العتبات والحدود العامة بعض التقديرات الشائعة للمتطلبات منخفضة وعالية األداء‬
‫لشبكتنا‪ .‬تكون مفيدة عندما يكون هناك نقص في المعلومات حول المستخدمين والتطبيقات واألجهزة الخاصة بالشبكة ‪ ،‬ولكن‬
‫غالبًا ما تكون هناك معلومات حول ماهية عتبات األداء‪ .‬باستخدام هذه المعلومات ‪ ،‬يمكننا تطوير حدود وحدود خاصة بتلك‬
‫الشبكة‪ .‬عتبات وحدود خاصة بالبيئة هي إقرار بأن كل منها‬

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

‫العتبات هي تحديد التطبيقات التي لها متطلبات عالية األداء‪ .‬لقد قضينا الكثير من الوقت في هذا‪ .‬لماذا هو مهم جدا؟ لكل‬
‫مشروع شبكة نعمل عليه ‪ ،‬نحتاج إلى‪:‬‬

‫‪ .1‬تحديد ما إذا كان هناك أي تطبيقات وأجهزة عالية األداء ‪ ،‬وإذا كان األمر كذلك ‪ ،‬ما مدى أهمية نجاح هذه البيئة؟ ما مدى‬
‫أهمية أن يتم دعمهم؟ إذا لم يكن هناك أي تطبيقات عالية األداء (متعددة المستويات) ‪ ،‬فإن الشبكة ستدعم مجموعة من‬
‫التطبيقات واألداء أحادي الطبقة‪.‬‬

‫‪ .2‬إذا كانت هناك تطبيقات وأجهزة عالية األداء (متعددة المستويات) ‪ ،‬وكانت حاسمة‪ 9‬في نجاح هذه البيئة ‪ ،‬فمن المحتمل أن‬
‫يركز تصميم الشبكات‪ 9‬وتصميمها على دعم تلك التطبيقات واألجهزة ‪ ،‬وكذلك المستخدمين‪ .‬وبالتالي ‪ ،‬قدرتنا على تحديد‬
‫المستخدمين والتطبيقات واألجهزة المهمة‪ 9‬لنجاح المؤسسة التي ستدعمها الشبكة ‪ ،‬وتحديد ما إذا كانت هذه التطبيقات‬
‫واألجهزة عالية األداء نسبيًا لتلك البيئة ‪ ،‬أو تقريبًا نفس األداء مثل جميع التطبيقات األخرى سوف تؤثر التطبيقات واألجهزة‬
‫هناك على نجاح تصميم الشبكات‪ 9‬الناتجة وتصميمها‪.‬‬

‫‪ 3.9.1‬مقارنة متطلبات التطبيق‬

‫يعتمد تطوير حدود وحدود خاصة بالبيئة على مقارنة متطلبات األداء المختلفة للتطبيقات‪ .‬عادة ‪ ،‬يتم رسم واحد أو اثنين أو‬
‫كل من خصائص األداء (السعة ‪ ،‬التأخير ‪ ،‬و ‪ )RMA‬للتطبيقات ‪ ،‬ويتم استخدام قطعة األرض لمقارنة متطلبات األداء‬
‫النسبية ووضع عتبة أو حدود لهذه الخاصية‪ .‬على سبيل المثال ‪ ،‬ضع في اعتبارك قطعة من متطلبات السعة للتطبيقات في‬

‫شبكة االتصال‪ .‬قد تكون هذه مجموعة فرعية من جميع التطبيقات لتلك البيئة ‪ ،‬مثل الخمسة‪ 9‬أو الستة األولى من حيث األداء‬
‫أو األهمية‪ .‬ويبين الشكل ‪ 3.24‬المؤامرة الناتجة‪ .‬هناك مجموعة من التطبيقات في نطاق السعة ‪ 50‬كيلو بايت ‪ /‬ثانية ‪-‬‬
‫حوالي ‪ 1‬ميجا بايت ‪ /‬ثانية ‪ ،‬ثم التطبيقات المعزولة عند حوالي ‪ 4‬ميجا بايت ‪ /‬ثانية و ‪ 6.5‬ميجا بايت ‪ /‬ثانية‪ .‬يمكننا اختيار‬
‫اختيار واحد أو اثنين من التطبيقات العليا ووضع عتبة بينهما وبين بقية التطبيقات‪ .‬على األرجح ‪ ،‬سيتم تجميع المجموعتين‬
‫العلويتين معًا ووضع عتبة تتراوح بين ‪ 2‬إلى ‪ 3‬ميجابايت ‪ /‬ثانية‪ .‬كما ترون من الشكل ‪ ، 3.24‬متطلبات سعة التطبيقات‬

‫تنتشر عبر مجموعة من القيم‪ .‬يمكن أن نختار تطوير حد أداء (بيئي محدد) لهذه المجموعة من التطبيقات ‪ ،‬أو عتبة بين‬
‫األداء المنخفض والعالي ‪ ،‬أو كليهما‪ .‬الحظ أنه بالنسبة للتأخير ‪ ،‬فإن الحد األعلى لألداء العالي هو في الواقع أقل قيمة تأخير‬
‫‪ ،‬وليس أعلى قيمة‪ .‬في هذا الشكل ‪ ،‬يمكننا تقدير اثنين من عتبات السعة المحتملة‪ .‬ال‬

‫على األرجح سيتم تجميع التطبيقات ‪ C‬و ‪ ، F‬ووضع عتبة حوالي ‪ 2‬إلى ‪ 3‬ميغابايت‪ / 9‬ثانية‪ .‬هذه القيمة ذاتية وقد تحتاج إلى‬
‫موافقة المستخدمين أو اإلدارة‪ .‬في بعض األحيان يكون الحد أو الحد واضحً ا ؛ في أوقات أخرى قد يكون من الصعب تحديد‪.‬‬
‫النظر ‪ ،‬على سبيل المثال ‪ ،‬المؤامرة التالية من قدرات التطبيق (الشكل ‪ .)3.25‬في هذا الشكل ‪ ،‬تنتشر متطلبات السعة أيضًا‬
‫على مدى‬

‫من القيم ‪ ،‬ولكن في هذه الحالة ال يوجد فصل واضح بين األداء المنخفض والعالي‪ .‬عندما ال تكون متطلبات األداء مفصولة‬
‫بشكل واضح ‪ ،‬فقد ال تتمكن من تطوير عتبة‪.‬‬

‫‪ 3.10‬متطلبات األداء المتوقع والمضمون‬

‫باإلضافة إلى تحديد متطلبات األداء والحدود والحدود ‪ ،‬يجب علينا أيضًا مراعاة ما إذا كان هناك أي متطلبات لألداء يمكن‬
‫التنبؤ به أو المضمون‪ .‬قد تتذكر من الفصل ‪ 1‬أن الخدمة التي يمكن التنبؤ بها (والتي يعتبر األداء جزءًا منها) تتطلب بعض‬
‫القدرة على التنبؤ والموثوقية ‪ -‬أكثر من أفضل جهد ‪ -‬في حين أن الخدمة المضمونة لها مساءلة‪ 9‬كجزء من مواصفاتها‪ .‬تعد‬
‫متطلبات األداء لكال هذين النوعين من الخدمات أكثر صرامة من خدمة الجهد األفضل القياسية‪ .‬وبالتالي ‪ ،‬عند تحديد أداء‬
‫متوقع و ‪ /‬أو مضمون لشبكة ما ‪ ،‬فأنت تريد أن تكون على يقين من أن العميل يحتاجها بالفعل أو يريدها وأنك على دراية‬
‫بالتكاليف (المالية ‪ ،‬والقوى العاملة ‪ ،‬والفكرية ‪ ،‬وربما الجدول الزمني) لتنفيذها وصيانتها‪.‬‬

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

‫كتاب‪ .‬لقد تحدثنا عن التطبيقات المهمة‪ 9‬والمهمة والحاسمة‪ 9‬في الوقت الفعلي والتفاعلية‪ .‬تشير هذه الشروط إلى القدرة والتنبؤ‬
‫والتأهيل و ‪ RMA‬على التوالي‪ .‬لقد تحدثنا أيضًا عن تطوير حدود وحدود خاصة بالبيئة لفصل األداء المنخفض والعالي‬
‫لشبكات األداء متعددة المستويات‪ .‬التطبيقات التي تتميز باألداء العالي هي أيضًا مرشحة للخدمة التي يمكن التنبؤ بها‪ .‬في‬
‫الواقع ‪ ،‬يمكن أن يكون الحد الفاصل بين األداء المنخفض والعالي هو الحد الفاصل بين أفضل خدمة ممكنة ويمكن التنبؤ بها‪.‬‬
‫لذلك ‪ ،‬ما إذا كنت تحدد متطلبات األداء أو ال يمكن التنبؤ بها‬

‫مبني على‬

‫• تحديد ما إذا كان التطبيق هو مهمة حرجة ‪ ،‬معدل الحرج ‪ ،‬في الوقت الحقيقي ‪ ،‬أو التفاعلية‬

‫• تحديد ما إذا كان هناك أي حدود أو حدود أداء خاصة بالبيئة‬

‫• تطبيق حدود وحدود عامة ‪ ،‬إذا لزم األمر • مناقشة النتائج مع العميل (العمالء) (المستخدمين ‪ ،‬اإلدارة ‪ ،‬وما إلى ذلك)‬
‫لالتفاق على المتطلبات التي ينبغي اعتبارها قابلة للتنبؤ‬

‫‪ 3.10.2‬متطلبات األداء المضمون تعد متطلبات األداء المضمونة أكثر المتطلبات الصارمة للشبكة ‪ ،‬ليس بالضرورة من‬
‫حيث مستوى األداء بل من حيث ما هو مطلوب لدعم (أو ضمان) هذا األداء للجهاز أو التطبيق ‪ ،‬أو المستخدم‪ .‬كما هو الحال‬
‫مع المتطلبات التي يمكن التنبؤ بها ‪ ،‬تتم اإلشارة إلى المتطلبات المضمونة عند تحديد التطبيقات الحرجة للمهمة و ‪ /‬أو‬
‫الحرجة ‪ /‬في الوقت الفعلي و ‪ /‬أو التفاعلية ‪ ،‬وكذلك عند تحديد متطلبات األداء العالية (متعددة المستويات)‪.‬‬

‫ما الذي يجعل متطلبات األداء مضمونة هي الدرجة التي‬

‫يحتاج هذا المتطلب إلى الدعم في الشبكة‪ .‬يجب أن يكون دعم المتطلبات المضمونة مضم ًنا فيها‪ .‬وهذا يعني ما يلي‪:‬‬

‫• يجب أن يكون هناك بعض االتفاق ‪ ،‬عادة بين مستخدمي التطبيق ومقدمي خدمة الشبكة التي تدعم التطبيق ‪ ،‬حول‬

‫‪ .1‬ما هي متطلبات األداء ‪ .2‬متى وأين يتم تطبيقها؟ ‪ .3‬كيف سيتم قياسها والتحقق منها ‪ .4‬ماذا يحدث عندما ال يتم استيفاء‬
‫أحد المتطلبات‬

‫قد تكون هذه االتفاقية في شكل اتفاقية مستوى الخدمة (‪ ، )SLA‬والتي يشيع استخدامها من قبل مقدمي الخدمة‪.‬‬
 ‫• يجب اعتبار المتطلبات من طرف إلى طرف ‪ ،‬بين المصدر والوجهة‪ .‬يمكن االطالع على المزيد حول هذا الموضوع في‬
‫الفصل الخاص بتحليل التدفق (الفصل ‪.)4‬‬

‫العوامل المستخدمة‪ 9‬لتحديد متطلبات األداء المضمونة هي نفسها بالنسبة لمتطلبات األداء المتوقعة ‪ ،‬مع التركيز بشكل خاص‬
‫على العامل األخير (مناقشة النتائج مع العميل (العمالء))‪ .‬يعد الحصول على موافقة العميل (العمالء) الخاصين بضمان‬
‫متطلبات األداء أمرً ا مهمًا بشكل خاص ‪ ،‬حيث يمكن أن يكون التأثير على الموارد كبيرً ا‪ .‬كما سنرى ‪ ،‬يمكن أن يكون لكيفية‬
‫تحديد المتطلبات هنا تأثير خطير‬

‫على بنية الشبكة وتصميم لمتابعة‪ .‬لذلك ‪ ،‬كلما بذلت المزيد من الجهد في هذا ‪ ،‬كلما كان التصميم والهندسة الناتج عن ذلك‬
‫أفضل‪.‬‬

‫‪ 3.11‬تعيين المتطلبات جزء آخر من عملية تحليل المتطلبات هو تعيين المتطلبات‪ .‬في‬

‫الفصل ‪ 2‬ناقشنا أهمية تحديد مواقع األجهزة والتطبيقات الهامة‪ .‬كجزء من عملية التحليل ‪ ،‬سنجمع معلومات الموقع معًا في‬
‫خريطة لألماكن التي (أو من المحتمل أن تكون فيها األجهزة) وحيث تنطبق التطبيقات (أو من المحتمل أن تطبق)‪ .‬يتم تعيين‬
‫المتطلبات إلى وصف جغرافي للبيئة‪ .‬قد يكون هذا مبنى أو حرمًا جامع ًيا‪ 9‬ولكن يمكن أيضًا تلخيصه لوجهات النظر‬
‫المتروبولية أو الواسعة‪ .‬في الواقع ‪ ،‬يمكن أن يكون هناك وجهات نظر متعددة للبيئة ‪ ،‬تركز كل منها على منطقة جغرافية‬
‫معينة‪ .‬على سبيل المثال ‪ ،‬قد تكون خريطة واحدة طريقة عرض واسعة النطاق ‪ ،‬توضح المدن التي تنطبق عليها األجهزة‬
‫والتطبيقات‪ .‬قد يكون لكل مدينة بعد ذلك خريطتها الخاصة ‪ ،‬والتي ُتظهر الحرم الجامعي و ‪ /‬أو المباني (الشكل ‪.)3.26‬‬
‫يوضح الشكل ‪ 3.27‬مثال لخريطة المتطلبات‪ .‬على هذه الخريطة من الحرم الجامعي‬

‫يتم وضع مواقع األجهزة (الخوادم واألجهزة المتخصصة) والتطبيقات‪ .‬من هذه الخريطة ‪ ،‬يمكننا أن نبدأ في ربط أي أجزاء‬
‫من الحرم الجامعي سوف تستخدم أي التطبيقات واألجهزة ‪ ،‬ويمكننا تقدير األماكن التي قد تحدث فيها تدفقات حركة المرور ‪،‬‬
‫داخل التطبيق ‪ ،‬وبين التطبيقات ‪ ،‬وبين األجهزة‪ .‬الحظ أنه على هذه الخريطة ‪ ،‬يتم أيضًا عرض مجموعات من أجهزة‬
‫الحوسبة العامة‪.‬‬

‫إن عرض أجهزة سطح المكتب أو أجهزة الكمبيوتر المحمول الفردية غير عملي وليس من المرجح أن يوفر معلومات مهمة‪.‬‬
‫عرض المجموعات ‪ ،‬مع ذلك ‪ ،‬يعطي إشارة إلى عدد األجهزة (والمستخدمين) الموجودة في موقع معين‪ .‬هذا مفيد في عملية‬
‫تحليل التدفق‪ .‬حالة االنحطاط لخريطة المتطلبات هي حالة يتم فيها تطبيق جميع الطلبات‬

‫في كل مكان ‪ ،‬وال توجد خوادم أو أجهزة متخصصة إلظهارها‪ .‬هناك القليل ‪ ،‬إن وجد ‪ ،‬من المعلومات التي يمكن تحديدها‬
‫بواسطة مثل هذه الخريطة‪ 3.12 .‬تطوير مواصفات المتطلبات‬

‫مواصفات المتطلبات وخريطة المتطلبات هي نتائج عملية التحليل‪ .‬الجزء األول من العملية هو تحديد أي شروط أولية‬
‫للمشروع‪ .‬يتضمن ذلك نوع مشروع الشبكة ونطاق المشروع وأهداف المشروع والقوى السياسية واإلدارية والمالية التي‬
‫تعمل في المشروع‪ .‬قد يكون جزء من الشروط األولية للمشروع هو تحديد ما إذا كانت الشبكة تحتاج إلى أداء من مستوى‬
‫واحد أو متعدد المستويات‪ .‬سنقوم أيضًا بإجراء تقييم أولي سريع للمشكلة (المشاكل) في الشبكة ‪ ،‬إن وجد ‪ ،‬ونقدر الموارد‬
‫والجدول الزمني‪ .‬وبالتالي ‪ ،‬قبل أن نجمع أي متطلبات للشبكة ‪ ،‬يجب علينا‬

‫لديك بعض أو كل هذه المعلومات موثقة‪ .‬اطلع على مثال شبكة المباني من الفصل ‪ .2‬قد يبدو الجزء األول من مواصفات‬
‫المتطلبات بالشكل ‪ .3.28‬يشتمل الجزء الثاني من مواصفات المتطلبات على المتطلبات المجمعة‪ 9‬والمستمدة للشبكة‪ .‬في هذا‬
‫المثال ‪ ،‬تم تعلم بعض المتطلبات في مناقشتنا األولية مع العميل (اإلدارة والموظفين)‪ .‬تظهر هذه المتطلبات في الشكل ‪3.29‬‬
‫‪ ،‬باستخدام القالب من الفصل ‪ .2‬ليس دائمًا ما يمكن تجميع المتطلبات من االجتماعات‪ 9‬المبكرة‪ .‬للحصول على متطلبات‬
‫المستخدمين ‪ ،‬نطلب منهم عادة أسئلة حول بيئتهم‪ .‬على سبيل المثال ‪ ،‬تم تطوير استبيان وإرساله إلى جميع موظفي الشركة‪.‬‬
‫يوضح الشكل ‪ 3.30‬مثل هذا االستبيان‪ .‬بالطبع ‪ ،‬لن يرد الجميع على االستبيان‪ .‬التجربة لديها‬

‫أظهر أنه في أي مكان من ‪ ٪ 10‬إلى ‪ ٪ 40‬سوف تستجيب‪ .‬يعتمد هذا على مدة االستبيان ‪ ،‬ومدى صعوبة ملء االستبيان ‪،‬‬
‫وكم هو حجم المنظمة‪ .‬أيضًا ‪ ،‬تميل إلى الحصول على معظم االستجابات في غضون أيام قليلة ‪ ،‬ولكن بعضها يتدفق خالل‬
 ‫فترة زمنية أطول (على سبيل المثال ‪ ،‬بضعة أسابيع)‪ .‬يمكنك تحديث المتطلبات عدة مرات بنا ًء على نتائج االستجابات‬
‫الجديدة‪ .‬يتم عرض نتائج مثال االستبيان في الشكلين ‪ 3.31‬و ‪.3.32‬‬

‫تم تحسين هذه المتطلبات وإضافتها من خالل االجتماع مع كل مجموعة من المجموعات (بما في ذلك االجتماعات‪ 9‬مع‬
‫موظفي اإلدارة والشبكة) في الشركة‪.‬‬

‫‪ 3.13‬االستنتاجات‬

‫توفر لك عملية تحليل المتطلبات وسائل لتحليل شبكتك والبيئة التي تحتوي عليها‪ .‬لقد علمت بجمع وإدارة متطلبات المستخدم‬
‫والتطبيق والجهاز والشبكة‪ .‬يتضمن ذلك تحديد الشروط األولية للمشروع وتحديد وإدارة توقعات‪ 9‬العمالء (العمالء) بشأن‬
‫ً‬
‫اعتمادا على الشبكة والنظام والبيئة ‪ ،‬وكذلك ما إذا كانت الشبكة جديدة أم ترقية لشبكة‬ ‫الشبكة‪ .‬تختلف الظروف األولية ‪،‬‬
‫موجودة‪ .‬مسلحين بالشروط األولية ‪ ،‬يمكنك جمع المتطلبات من المستخدمين واإلدارة واإلدارة ‪ ،‬وتخطيط متطلبات التطبيق‬
‫لتحديد تبعياتهم‪ .‬لقد تعلمت كيفية تحديد المتغيرات المطلوب قياسها (مقاييس الخدمة) و‬

‫كيفية عمل القياسات‪ .‬ستؤدي اختياراتك لمقاييس الخدمة إلى تحديد المتغيرات لمراقبة الشبكة وإدارتها‪ .‬ناقشنا النمذجة‬
‫والمحاكاة ‪ ،‬وكيفية استخدامها وتقنيات التقريب األخرى لوصف سلوك المستخدم والتطبيق‪ .‬بنا ًء على مقاييس الخدمة ‪ ،‬علمنا‬
‫بتطوير األداء‬

‫متطلبات السعة ‪ ،‬التأخير ‪ ،‬الجيش الملكي المغربي ‪ ،‬بما في ذلك تطوير عتبات وحدود األداء‪ .‬هذه هي مفيدة في التمييز بين‬
‫متطلبات منخفضة وعالية األداء لشبكتك‪ .‬لقد تعلمنا أيضًا العتبات والحدود العامة والخاصة بالبيئة وكيفية تحديدها‪ .‬يتم تقديم‬
‫بعض العتبات العامة الستخدامك‪ .‬ناقشنا أيضًا متطلبات األداء المتوقعة والمضمونة وأهميتها‪ .‬أخيرً ا ‪ ،‬ناقشنا متطلبات‬
‫ً‬
‫استعدادا لتحليل تدفق حركة المرور‪ .‬في الفصل التالي ‪ ،‬نجمع كل هذه المفاهيم معًا لتطوير‬ ‫التعيين للمواقع الجغرافية ‪،‬‬
‫مواصفات متطلبات الشبكة‪.‬‬

‫‪ 3.14‬تمارين‬

‫‪ .1‬تتكون الشروط األولية لمشروع شبكتك من الفئات التالية‪ :‬نوع مشروع الشبكة ‪ ،‬ونطاق مشروع الشبكة ‪ ،‬وأهداف‬
‫التصميم ‪ /‬الهندسة المعمارية‪ .‬قم بتطوير ثالث مجموعات من الشروط األولية (كل منها يحتوي على عنصر واحد من كل‬
‫فئة) وإعطاء مثال على مشروع شبكة لكل مجموعة‪.‬‬

‫‪ .2‬لكل مجموعة من متطلبات أداء التطبيق الموضحة في الشكل ‪ ، 3.33‬ص ِّنف الشبكة على أنها أداء من مستوى واحد أو‬
‫متعدد المستويات‪ .3 .‬عميلك هو مستشفى يريد ترقية شبكة ‪ LAN‬الخاصة به‪ .‬قم بتطوير استبيان لجمع المتطلبات من‬
‫المستخدمين وإدارة المستشفيات والموظفين‪ .‬ما هي أنواع األسئلة التي تطرحها لفهم بيئتهم بشكل أفضل؟‬

‫‪ .4‬النظر في مشروع الشبكة حيث ال يمكنك التحدث مع المستخدمين أو الموظفين‪ .‬ما هي الموارد التي يمكنك استخدامها‬
‫لجمع متطلبات المستخدم والتطبيق والجهاز والشبكة؟ حدد بإيجاز طريقة لتجميع واستخالص المتطلبات في حالة عدم‬
‫مشاركة المستخدم ‪ /‬الموظفين‪.‬‬

‫‪ .5‬تريد اختبار أداء جلسات الويب عبر شبكة وصول السلكية ‪ ،‬بين أجهزة الكمبيوتر وجهاز توجيه ‪ IP‬الذي ينهي‬
‫بروتوكول نقطة إلى نقطة (‪ )PPP‬و ‪ PPP‬عبر جلسات )‪ ، Ethernet (PPPoE‬كما هو موضح في الشكل ‪ .3.34‬صف‬
‫كيف يمكنك اختبار األداء ‪ ،‬سواء على اختبار أو على الشبكة الحالية‪ .‬اذكر أي معدات وبرامج وشبكات تستخدمها‪ .6 .‬أظهر‬
‫كيف سيتم تتبع ‪ /‬إدارة التغييرات التالية على المتطلبات أدناه‪ .‬استخدم إما الفقرة أو النموذج الجدولي لتسجيل التغييرات‪.‬‬

‫الشرط‪ 12 :‬أكتوبر ‪ .2002‬يجب أن تكون الشبكة قادرة على دعم ما يصل إلى ‪ 2000‬واجهة ‪ Ethernet‬سريعة ‪ ،‬يتم‬
‫تجميعها على ‪ 1‬جيجابت ‪ /‬ثانية أو أكبر العمود الفقري لسعة تمتد على جميع المباني ‪ 12‬في جميع أنحاء الحرم الجامعي‪ .‬ا‪.‬‬
‫تغيير "‪ "Fast Ethernet‬إلى "‪ Fast Ethernet‬أو ‪ ، "Gigabit Ethernet‬بتاريخ ‪ ٥‬يناير ‪.٢٠٠٣‬‬

‫ب‪ .‬حذف "‪ 12‬مبنى في جميع أنحاء الحرم الجامعي" ‪ ،‬بتاريخ ‪ 7‬يناير ‪ .2003‬ج‪ .‬تغيير "‪ "2000‬إلى "‪ ، "3500‬بتاريخ‬
‫‪ 10‬فبراير ‪ .2002‬د‪ .‬أضف "‪ 10‬مباني مدرجة في الملحق أ" ‪ ،‬بتاريخ ‪ 20‬يناير ‪ .2002‬ه‪ .‬تغيير "‪"Fast Ethernet‬‬
 ‫إلى "‪ Fast Ethernet‬أو ‪ "Gigabit Ethernet‬إلى "‪ 10‬أو ‪ 100‬أو ‪ 1000‬ميجا بايت ‪ /‬ثانية" ‪ ،‬بتاريخ ‪ 5‬مارس‬
‫‪.2003‬‬

‫‪ .F‬تغيير "مجمعة"‪ 9‬إلى "مجمعة داخل كل مبنى" ‪ ،‬بتاريخ ‪ 21‬أبريل ‪.2003‬‬

‫‪ُ .7‬تستخدم مقاييس الخدمة لمراقبة الخدمات‪ 9‬في الشبكة وقياسها والتحقق منها وتحديد ما إذا كان قد تم الوفاء بمتطلبات األداء‬
‫أم ال‪ .‬لذلك ‪ ،‬يجب أن تكون مقاييس الخدمة ذات معنى لمشغلي الشبكات والمديرين والمستخدمين والموظفين‪ .‬لكل متطلبات‬
‫أداء أدناه ‪ ،‬صف مقياس الخدمة الذي يمكن استخدامه لقياس المتطلبات والتحقق منها‪ .‬ا‪ .‬موثوقية ارتباط ‪ T1‬بين شبكة‬
‫مؤسسة ومزود خدمة اإلنترنت الخاص بها ‪ ،‬مع أجهزة توجيه ‪ IP‬في كل طرف من أطراف ‪.T1‬‬

‫ب‪ .‬تأخير ذهاب وإياب بين األجهزة على الشبكة ‪ A‬والخوادم على الخادم ‪ .LAN B. c‬متوسط معدل الحركة داخل وخارج‬
‫خادم حساب ‪ ،‬يقاس عبر جميع واجهات ‪ LAN‬األربعة على فترات زمنية مدتها ‪ 15‬دقيقة‪.‬‬

‫‪ .8‬نظرً ا لمتطلبات ‪ MTBCF‬البالغة ‪ 8000‬ساعة ومتطلبات ‪ MTTR‬البالغة ‪ 4‬ساعات‪ ، 9‬احسب متطلبات التوفر‪.‬‬

‫‪ .9‬صف طريقتين لجعل متطلبات الجهوزية بنسبة ‪ ٪99.999‬أكثر دقة‪.‬‬

‫‪ .10‬أنت تقوم بتطوير شبكة إلدارة الطيران الفيدرالية (‪ )FAA‬لتطبيق معالجة القياس عن بعد يتكون من مكونين‪ :‬نظام تحكم‬
‫التوجيه التلقائي الذي سيحلل بيانات القياس عن بعد من الطائرات ‪ ،‬ونظام تصور الحركة الذي تستخدمه وحدات التحكم في‬
‫محطات العمل الخاصة بها (الشكل ‪ . )3.35‬في تحليلك لهذا التطبيق ‪ ،‬حددت أن التطبيق يتطلب تأخيرً ا أحادي االتجاه يبلغ‬
‫‪ 20‬مللي ثانية بين الطائرة ونظام التحكم في التوجيه‪ .‬باإلضافة إلى ذلك ‪ ،‬تتفاعل وحدات التحكم مع الطائرات عن طريق‬
‫نظام تصور الحركة مع التأخير حسب ترتيب ‪ .HRT‬قم بتطوير حدود التأخير العليا والسفلى لهذا التطبيق ‪ ،‬وعرضها على‬
‫الرسم البياني‪.‬‬