هندسة الأداء

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

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

أهداف هندسة الأداء

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

نهج هندسة الأداء

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

الاستهلال

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

الاسترسال

وخلال هذه المرحلة الحاسمة، يتم تحليل العمليات التجارية الحرجة إلى حالات الاستخدام الحرجة. وسيتم تحليل مثل حالات الاستخدام هذه، حسب الحاجة، لتحولات صفحة واحدة (شاشة). وهذه هي حالات الاستخدام التي ستخضع لـاختبار الأداء النصي. ونوعية المتطلبات التي تتعلق بهندسة الأداء هي متطلبات غير وظيفية، أو NFR. في حين أن المتطلب الوظيفي يتعلق بماهي العمليات التجارية التي يتعين القيام بها، والأداء المتعلق بالمتطلبات الغير وظيفية سوف يتعلق بمدى سرعة أداء هذه العملية التجارية في ظل ظروف محددة.

مفهوم «ظروف محددة» هو أمر ضروري. وسوف يتجلى ذلك في المثال:

• غير صالح—ينبغي للنظام الاستجابة إلى إدخال المستخدم في غضون 10 ثانية.
• صالح—لحالة استخدام ABC ينبغي للنظام الاستجابة إلى إدخال المستخدم في غضون 5 ثوان لمتوسط تحميل 250 مستخدم نشط و2000 مستخدم مسجل 95 ٪ من الوقت، أو في غضون 10 ثوان لذروة تحميل 500 مستخدم نشط و4000 مستخدم مسجل 90 ٪ من الوقت.

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

لا تقتصر المتطلبات الغير وظيفية عن حالات الاستخدام. فيجب تحديد أحجام النظام العامة. وستصف هذه تحميل النظام العام خلال فترة زمنية محددة، وتحديد عدد كل نوع من المعاملات التجارية التي سيتم تنفيذه في كل وحدة من الوقت. الأحجام العامة عادة ماتصف يوم عمل نموذجي، ومن ثم يتم تقسيمها لكل ساعة. وهذا يصف كيفية اختلاف تحميل النظام على مدار اليوم. فعلى سبيل المثال: 1200 معاملة ألف، و300 معاملة باء، و3300 معاملة جيم، وغيرها في يوم عمل معين؛ ثم في ساعة 1 سيتم تنفيذ عدد معين من ألف وباء وجيم وغيرها، وفي ساعة 2 سيتم تنفيذ عدد معين، وهلم جرا. وغالبا ما يتم تنسيق المعلومات في شكل جداول للتوضيح. إذا نفذ المعاملات طبقات مستخدمين مختلفة، سيتم دمج هذه المعلومات أيضا في توثيق NFR. وأخيرا، يمكن تصنيف المعاملات إلى نوع عام، عادة كتفاعل المستخدم، وتوليد التقرير، وتجهيز الدفعات. وسيتم استخدام أحجام النظام الموثقة في وثائق NFR كمدخلات لكلا من اختبار تحميل واختبار تحمل النظام من خلال اختبار الأداء.

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

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

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

البناء

في المرحلة الأولية من هذه المرحلة يتتطلب عددا من أداة الأداء التابعة للأنشطة. وهي تشمل:

• تحديد الأعضاء الرئيسين في فريق التطوير كخبراء أساسيين في الأدوات المحددة
• تحديد أداة تنميط للتنمية / بيئة اختبار وحدة مكون
• تحديد أداة اختبار وحدة (مكون) آلية للتطوير / بيئة اختبار وحدة مكون؛ يتم استخدام هذا عندما لا يوجد واجهة مستخدم رسومية لتسيير المكونات قيد التطوير
• تحديد أداة آلية لتسيير وحدة (مكونات) من جانب الخادم للتطوير / بيئة اختبار وحدة مكون
• تحديد أداة آلية متعددة المستخدمين قادرة التحريك النصي نهاية إلى نهاية للتطوير / بيئة اختبار وحدة مكون؛ وتستخدم لتنفيذ حالات استخدام موجهة الشاشة
• تحديد أداة اختبار قاعدة بيانات لتحميل البيانات للتطوير / بيئة اختبار وحدة مكون؛ وهذا مطلوب لضمان اختيار محسن قاعدة البيانات لمسارات تنفيذ صحيحة ولتمكين إعادة تهيئة وإعادة تحميل قاعدة البيانات حسب الحاجة
• نشر أدوات الأداء لفريق التطوير
• يجب تقديم عروض وتدريبات لأعضاء فريق التطوير على الأدوات المختارة

وينبغي على عضو ممارسة هندسة الأداء ورؤساء فريق تطوير التقنية أن يعملوا معا لتحديد أفضل أداء للممارسات لفريق التطوير. وبشكل مثالي ينبغي لمنظمة التطوير ام يكون لديها بالفعل مجموعة من أفضل الممارسات، ولكن في كثير من الأحيان لا تشمل ولا تؤكد على أفضل الممارسات والتي تؤثر على أداء النظام.

وينبغي إدخال مفهوم تطبيق الأجهزة هنا بمشاركة منظمة مراقبة تقنية المعلومات. والعديد من نظم مراقبة البائع لديهم قدرات الأداء، وهم غالبا ما يعملون في نظام التشغيل، والشبكة، ومستويات الخادم؛ على سبيل المثال استخدام وحدة المعالجة المركزية، واستخدام الذاكرة، ومدخلات/مخرجات القرص، ولخوادم منصة جافا، النسخة التجارية يتضمن أداء آلة جافا الأفتراضية جمع القمامة. ولكن هذا النوع من الرصد لا يسمح بتتبع مستوى أداء حالة الاستخدام. والوصول إلى هذا المستوى من القدرة على الرصد يمكن ان يقتضي أن يكون التطبيق نفسه مجهزاً. وبدلا من ذلك، يمكن استخدام مجموعة أدوات رصد والتي تعمل على مستوى التحول. (من الأمثلة على ذلك تقنية Cx من TeaLeaf، و Foglight من Quest Software، و RUM من هوليت باكارد، و SuperAgent من NetQoS، أو ClientVantage من Compuware). وكان يجب على فريق الرصد تحديد الاحتياجات في المرحلة السابقة، ويجب عليه العمل مع فريق التطوير لضمان تضمُن رصد مستوى حالة الاستخدام.

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

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

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

على سبيل المثال: لنفترض أننا يمكن أن تحسن 70 ٪ من وحدة نمطية بموازتها، وتعمل على 4 وحدات معالجة مركزية بدلا من وحدة معالجة مركزية واحدة. إذا كان α هو جزء من العملية الحسابية المتتابعة، و (α - 1) هو الجزء الذي يمكن أن يكون بشكل متوازي، اذن فالسرعة القصوى التي يمكن تحقيقها باستخدام المعالجات P تَعطى وفقا لـ قانون أمدال:

في هذا المثال سوف نحصل على: 1/(.3+(1-.3)/4) == 2.105. ولمضاعفة قوة المعالجة لأربعة أضعاف نقوم بمضاعفة الأداء (من 1 وحتي 2.105). ونحن الآن في الطريق إلى إضعاف الواردات. وإذا داومنا على مضاعفة القدرة الحاسوبية مرة أخرى من 4 إلى 8 معالجات سنحصل على 1/(.3+(1-.3)/8) == 2.581. اذن فعند مضاعفة قوة المعالجة مرة أخرى فسوف نحصل على تحسن الأداء بحوالي الخَمس (من 2.105 وحتى 2.581).

الانتقال

خلال هذه المرحلة النهائية يتم نشر النظام إلى بيئة الإنتاج. وهناك حاجة لعدد من الخطوات التحضيرية. وهذه تشمل:

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

وبمجرد أن يتم نشر النظام الجديد، ستلتقط العمليات الجارية أنشطة الأداء، بما في ذلك :

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

إدارة الخدمة

في المجال التشغيلي (النشر بعد الإنتاج) تركز هندسة الأداء في المقام الأول على ثلاثة مجالات هي : إدارة مستوى الخدمة، وإدارة سعة الخدمة، وإدارة المشاكل

إدارة مستوى الخدمة

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

إدارة سعة الخدمة

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

إدارة المشاكل

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

الرصد

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

1. من الممكن إبرام اتفاقات مستوى الخدمة في مستوى حالات الاستخدام.
2. من الممكن تشغيل وإيقاف الرصد في نقاط دورية أو دعم حل المشاكل.
3. تمكن توليد تقارير منتظمة.
4. تمكن القدرة على تتبع الاتجاهات على مر الزمن—مثل تأثير زيادة أحمال المستخدم ومجموعات البيانات المتزايدة في مستوى أداء حالة الاستخدام.

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

انظر أيضًا

• إدارة سعة الخدمة
• إدارة خدمات المعلوماتية

(ITIL)

• قابلية التوسع
• هندسة البرمجيات
• جودة البرمجيات
• فحص البرمجيات
• هندسة أنظمة

لمزيد من القراءة

• Modern trend in Performance Engineering
• A Performance Engineering Strategy
• A Performance Process Maturity Model
• Exploring UML for Performance Engineering
• Introduction to Modeling Based Performance Engineering
• Leveraging ITIL to Improve Application Performance
• Patterns & Practices Performance Engineering
• Performance and Scalability of Distributed Software Architectures
• Performance Engineering Best Practices (High Level)
• Performance Assurance: A Cynic's Brief Collection of Dos and Don'ts
• Principles of Capacity Management
• Software Engineering and Performance: A Road-map
• The Vicious Cycle of Computer Systems Performance and IT Operational Costs
• Microsoft Windows Server Performance Team
• Gathering Performance Requirements