اختبار أداء SAP: ما الذي يجب أن يعرفه قادة تقنية المعلومات

يثبت اختبار أداء SAP، قبل التشغيل الفعلي، أن المعاملات الحرجة والمهام الخلفية والواجهات تحقق أزمنة الاستجابة المتفق عليها تحت أحجام الإنتاج. ابدأه في التصميم، وشغّل اختبارات الحجم والحمل في Realize حين يستقر الإعداد، وأنهِ الدورة قبل اختبار قبول المستخدم (UAT)، واجعل النتائج بوابة للانتقال. هذا الدليل لرؤساء تقنية المعلومات ومديري البرامج وقادة الاختبار في برامج S/4HANA، بما فيها RISE with SAP. ويغطي ما يجب اختباره ومن يملكه وكيف تكتب معايير القبول وما الذي يتغير في السحابة. ابدأ بجدول معايير القبول: إن لم تستطع ملأه، فلست جاهزاً للاختبار.

تُكتشف مشكلات الأداء في برامج SAP بعد التشغيل الفعلي في الغالب. تنتهي مهلة Fiori Tiles حين يسجّل 300 مستخدم دخولهم عند تغيير الوردية. وتتجمد تقارير Z لأن أحداً شغّل استعلاماً مفتوحاً للسنة المالية على جدول فيه 50 مليون سجل. وتتداخل المهام الخلفية أثناء إقفال نهاية الشهر فيتوقف تشغيل الترحيل.

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

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

اختبار الأداء عبر SAP Activate

1. 01

   Explore

   حدّد مخاطر الأداء في التصميم. فالبنية وشكل التقارير يحسمان النتائج قبل كتابة أي شيفرة.

2. 02

   Realize

   شغّل اختبارات الحجم والحمل حين يستقر الإعداد. فالإعداد الجزئي يعطي نتائج مضللة.

3. 03

   قبل UAT

   أكمل دورة الأداء الكاملة قبل UAT، لا كجزء منه.

4. 04

   الانتقال

   اعتمد الانتقال بناءً على معايير القبول المتفق عليها مسبقاً، لا بناءً على الرأي.

5. 05

   الدعم المكثف

   راقب مؤشرات الأداء الحية لمدة 30 إلى 60 يوماً. تظهر معظم حالات التراجع في أول دورة إقفال.

في نظام ECC على قاعدة بيانات تقليدية، كان اختبار الأداء يعني اختبار حمل خادم التطبيقات وقاعدة البيانات: زمن تشغيل ABAP وأداء SQL وجدولة المهام. وكانت الواجهة الأمامية SAP GUI، التي نادراً ما فاجأت أحداً.

في S/4HANA، مع واجهات Fiori الأمامية والإضافات على SAP BTP والتكامل عبر SAP Cloud Integration (CPI)، يعتمد الأداء على عدة طبقات في آن واحد. وقد يكون بطء Fiori Tile ناتجاً عن استدعاء ABAP طويل، أو مهلة بوابة، أو خدمة OData لم تُصمَّم للطلبات المتزامنة، أو زمن انتقال الشبكة في إعداد هجين. واختبار الخلفية وحدها لن يكشفه. أما اختبار المسار كله فسيكشفه.

1. 01تشغيل Tileذروات تسجيل الدخول عند بدء الورديات
2. 02استدعاء ODataمهل البوابة المنتهية، وخدمات غير مبنية للتزامن
3. 03معالجة ABAPاستدعاءات ABAP طويلة التنفيذ
4. 04قراءة قاعدة البياناتتحديدات مفتوحة على جداول كبيرة
5. 05العرضإضافةً إلى زمن انتقال الشبكة للمواقع البعيدة

زمن استجابة واحد، يُقاس من البداية إلى النهاية

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

1. اختبار الحمل يفحص السلوك تحت الحجم المتوقع. والكلمة المفتاحية هي المتوقع. تحتاج إلى أحجام معاملات حقيقية وأعداد مستخدمين وجلسات متزامنة. وكثير من اختبارات الحمل تفشل لأنها استخدمت تقديرات للحجم كان الجميع يعلم أنها متفائلة.
2. اختبار الإجهاد يدفع إلى ما بعد حدود التصميم ليجد أين ينكسر النظام. فإذا كانت الأحجام ستتضاعف خلال ثمانية عشر شهراً، فهو يخبرك هل ستتحمل البنية ذلك، وهل يصبح تحجيم السعة مشكلة قبل المراجعة التالية للبنية التحتية.
3. اختبار التحمّل المطوّل (Soak) يشغّل حملاً ثابتاً لفترة ممتدة ليكشف المشكلات التي تتراكم مع الوقت: تسرب الذاكرة والتجزئة وتنازع سلاسل المهام عبر التشغيلات المتكررة. وهو الاختبار الذي يُتخطى أكثر من غيره، والذي كان سيلتقط إخفاق نهاية الشهر الموصوف أدناه.
4. الاختبار الشامل يتتبع المسار الكامل الذي يسلكه المستخدم: تشغيل Tile واستدعاء OData ومعالجة ABAP وقراءة قاعدة البيانات والعرض. وهو الطريقة الوحيدة لاكتشاف المشكلات التي تختفي حين تُختبر كل طبقة وحدها.

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

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

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

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

مستخدمون في عدة مناطق. يؤثر زمن انتقال الشبكة على كل معاملة. أمر مبيعات يستغرق ثانيتين في بلد الاستضافة قد يبدو معطلاً على بعد 3,000 ميل إن لم يختبره أحد من هناك. وتنقل RISE الاستضافة إلى SAP، لكن زمن الانتقال يظل معتمداً على المنطقة التي تختارها ومسار التوجيه إلى مستخدميك.

اتفق على المعايير مع الأعمال في مرحلة Prepare، قبل تشغيل أي اختبار. ويسمّي كل معيار المعاملة أو المهمة والحمل والحد. تُظهر هذه الأمثلة الشكل، فحدد أرقامك أنت من الاحتياجات التشغيلية:

البند	شرط الحمل	حد النجاح	المالك
إنشاء أمر مبيعات (VA01 أو تطبيق Fiori)	150 مستخدماً متزامناً لإدخال الطلبات	أقل من 3 ثوانٍ لـ 95 بالمئة من المعاملات	مالك عملية الطلب إلى النقد
أول تحميل لـ Fiori Launchpad عند بدء الوردية	ذروة عمليات الدخول المتزامنة لأكبر وردية	أقل من 5 ثوانٍ لـ 95 بالمئة من المستخدمين	رئيس عمليات تقنية المعلومات
سلسلة مهام إقفال نهاية الشهر	أحجام فترة الإقفال، والتسلسل الكامل	تكتمل داخل نافذة الإقفال المتفق عليها دون أي إيقاف	المراقب المالي
واجهة الطلبات الواردة	الحجم الأقصى للرسائل في الساعة	لا يوجد تراكم في الطابور أقدم من 15 دقيقة	قائد التكامل
تقرير مخصص عالي الحجم	حجم بيانات الإنتاج كاملاً، وتحديد نموذجي	أقل من 60 ثانية، مع حظر التحديدات المفتوحة	مالك التقرير

«يجب أن يكون النظام سريعاً بما يكفي لعمليات الأعمال» لا يمكن اختباره ولا قبوله. وتغيير المعايير بعد وصول النتائج يُفرغ وجودها من معناه.

اطلب كل واحد من هذه بالاسم:

التوقع	ما الذي ينبغي تسليمه	لماذا يهم
مستويات خدمة الأداء	حدود لكل معاملة وواجهة ومهمة، مع النجاح والفشل	تمنع رأي UAT من تجاوز الأدلة
نطاق قائم على المخاطر	ترتيب الأولويات بحسب حجم المستخدمين ونقاط التكامل وتبعية البيانات	يضع دورات الاختبار على أحمال العمل المهمة
مشاركة عبر الفرق	حضور Basis والبنية التحتية والفريق الوظيفي والأمن والتكامل أثناء التشغيلات	يمنع تبادل اللوم حين تظهر الفجوات
الأدوات والبيئات جاهزة	مولّدات الحمل (OpenText LoadRunner وTricentis NeoLoad وApache JMeter) والمراقبة وتحديثات البيانات في مكانها قبل بدء الدورات	يجعل المحاكاة واقعية
بيانات اختبار واقعية	بيانات رئيسية بحجم الإنتاج، واستدعاءات واجهات حقيقية، ومزيج معاملات تمثيلي	يجعل النتائج تتنبأ بسلوك التشغيل الفعلي
تقارير الأداء	مزيج الحمل وأزمنة الاستجابة والمعالج والذاكرة وأزمنة تشغيل المهام ومعدلات الأخطاء	يعطي اعتماد الانتقال قاعدة أدلة
خطة مراقبة بعد التشغيل الفعلي	مؤشرات الأداء الواجب مراقبتها في أول 30 إلى 60 يوماً	تؤكد بقاء النظام الحي ضمن الحدود المُختبَرة

أربعة أخطاء تتكرر أكثر من غيرها، حتى في المؤسسات الكبيرة ذات نماذج التسليم الناضجة.

اعتبار الاختبار الوظيفي اختبار أداء. تثبت الاختبارات الوظيفية أن المعاملة تعطي النتيجة الصحيحة. ولا تقول شيئاً عما يحدث حين يشغّلها 150 شخصاً في وقت واحد.

الاختبار بأحجام بيانات صغيرة. عميل لديه 200,000 بند طلب مفتوح يتصرف بشكل مختلف عن عميل لديه 5,000. والمرشحات التي تعيد النتيجة فوراً في الاختبار تنتهي مهلتها في الإنتاج. ازرع حجماً للمناطق عالية المخاطر.

ترك الأداء لـ Basis. يملك Basis تحجيم السعة وجدولة المهام. ولا يملك تصميم التقارير ولا بنية خدمات OData ولا تصميم تدفقات التكامل، وهذه هي ما يحرك أداء التطبيق.

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

RISE تقسّم المسؤولية

في إطار RISE with SAP، تملك SAP البنية التحتية: التحجيم ومنطقة Hyperscaler والشبكة وتوفر المنصة. ويملك العميل والشريك طبقة التطبيق. وتوضح وثيقة أدوار RISE ومسؤولياتها من SAP ذلك بجلاء: البحث عن عبارات SQL المكلفة وضبطها يبقى على عاتق العميل ما لم تشترِ خدمات التطبيقات الإضافية من SAP.

فشل شائع في برامج RISE هو افتراض أن SAP ستلتقط مشكلات الأداء لأنها تدير البنية التحتية. ستلتقط مشكلات البنية التحتية. ولن تلتقط خدمة OData سيئة التصميم، أو مهمة ABAP غير فعّالة، أو تدفق تكامل لا يتسع. اكتب هذا التقسيم في الميثاق وفي خطة الاختبار:

1. SAP: توفر البنية التحتية والاستجابة على مستوى المنصة
2. الشريك: أداء التطبيق تحت الحمل المحدد، بما في ذلك الإضافات وتدفقات التكامل
3. العميل: نتائج على مستوى العمليات مثل زمن الإقفال وإنتاجية الطلبات، وقرار القبول

Public Edition وGROW تضيّقان النطاق

في S/4HANA Cloud Public Edition، التي تُشترى عادةً عبر GROW with SAP، تجري SAP اختبار الأداء على منصتها متعددة المستأجرين كجزء من معيار منتجها، ولا تتوقع من العملاء اختبار حمل النظام المشترك. وينتقل اختبارك إلى ما هو لك: التكاملات المخصصة والإضافات والتقارير والتحليلات عالية الحجم وتسلسل الإقفال والتوحيد ومسار الشبكة من مواقعك. أما مشكلات الأداء في المنصة نفسها فتذهب إلى دعم SAP.

الذكاء الاصطناعي يساعد في السكربتات لا في البنية

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

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

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

ما هو اختبار أداء SAP ولماذا يهم؟

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

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

متى ينبغي أن يبدأ اختبار الأداء في برنامج SAP؟

يبدأ تحديد المخاطر في Explore، لأن خيارات البنية تحدد نتائج الأداء. ويبدأ الاختبار الفعلي في Realize، حين يصبح الإعداد مستقراً بما يكفي ليكون للنتائج معنى. فالإعداد الجزئي يعطي أرقاماً مضللة.

أنهِ الدورة الأخيرة قبل UAT، لا أثناءه. فعيوب الأداء المكتشفة في UAT تضغط الجدول المتبقي وتخلق ضغطاً لقبولها كمشكلات معروفة.

من ينبغي أن يملك اختبار أداء SAP؟

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

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

كيف تغيّر RISE with SAP مسؤولية اختبار الأداء؟

تملك SAP البنية التحتية: التحجيم والمنطقة والشبكة وتوفر المنصة. ويملك العميل والشريك أداء التطبيق: الإعداد والإضافات وتصميم OData وFiori وتدفقات التكامل ومؤشرات أداء العمليات. وتترك وثيقة أدوار RISE ومسؤولياتها من SAP ضبط SQL على العميل ما لم تُشترَ خدمات إضافية من SAP.

اكتب هذا التقسيم في معايير القبول كي يكون لكل حد مالك.

ما أكثر مشكلات أداء SAP Fiori شيوعاً؟

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

كيف تحدد معايير قبول الأداء في SAP؟

سمِّ المعاملة والحمل والحد. على سبيل المثال: «يكتمل إنشاء الطلب في أقل من 3 ثوانٍ لـ 95 بالمئة من المعاملات مع 150 مستخدماً متزامناً في دور إدخال الطلبات.» هذا قابل للاختبار.

«يجب أن يكون النظام سريعاً بما يكفي» ليس كذلك. اتفق على المعايير مع الأعمال في مرحلة Prepare، بناءً على احتياجات تشغيلية حقيقية، ولا تغيّرها بعد وصول النتائج.

ماذا يحدث إذا تُخطي اختبار الأداء أو جرى ضغطه؟

تظهر المشكلات في الإنتاج: مهام تتجاوز نوافذها وتعطّل غيرها، وتطبيقات Fiori تنتهي مهلتها في الذروة، وإقفال نهاية الشهر يستغرق ضعف الوقت ويفوّت مواعيد التقارير، وطوابير الواجهات تتراكم.

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