سياسات أداء التطبيقات

سياسات أداء التطبيقات


مقدمة

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

الأهداف

  • تحديد السياسات العامة التي تضمن تحسين تجربة المستفيدين من حيث استقرار الأنظمة وإتاحيتها وسرعة أدائها.

نطاق الوثيقة

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

تعريفات أساسية

وقت الاستجابة (Response Time)

الوقت المطلوب لمعالجة الطلب، من بداية إنشاء الطلب (Request) إلى وقت استلام الرد (Response).

الإنتاجية (Throughput)

عدد الطلبات التي يستطيع النظام معالجتها خلال فترة معينة.

الاستجابة (Responsiveness)

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

الأداء (Performance)

أداء النظام هو عادة وقت استجابته (Response time) أو إنتاجيته (Throughput)، وفي تطبيقات الويب، وقت الاستجابة هو الأكثر شيوعا.

الأداء المحسوس أو الملموس (Perceived Performance)

هو شعور المستخدمين بسرعة العمليات التي يقومون بها، وهي كالتالي:

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

تحسين استجابة النظام تحسن من أدائه الملموس.

يشعر المستخدمون بتحسن الأداء إذا كانت استجابة النظام أفضل بنسبة 20% على الأقل على الاستجابة الحالية.

القدرة على التوسع (Scalability)

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

هناك نوعان من التوسع:

  1. التوسع الرأسي (Vertical Scalability/Scaling up or down): ويكون عن طريق زيادة موارد الخادم الواحد
  2. التوسع الأفقي (Horizontal Scalability/Scaling out or in): ويكون عن طريق زيادة خوادم جديدة

الإتاحية (Availability)

هي نسبة وقت تشغيل النظام مطروحا منه وقت توقفه، أو بعبارة أخرى =  100 * (وقت التشغيل – وقت التوقف)/ (وقت التشغيل + وقت التوقف). وهذه النسبة عادة ينص عليها في اتفاقيات سياسة الخدمة (Service Level Agreements).

اختبارات التحميل (Load Tests)

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

اختبارات الضغط (Stress Tests)

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

السياسات

السياسات العامة

  • ما بين 80-90% من تحسينات أداء التطبيقات تتم في طبقة الواجهات الأمامية (front-end)، فيجب بذل 80-90% من مجهودات تحسين الأداء في هذه الطبقة.
  • استرشد بالدليل التفصيلي المعتمد في الوزارة لتحسين أداء التطبيقات.
  • تسجل جميع العمليات التي تتم على النظام والوقت الذي تستغرقه بالأدوات المعتمدة في الوزارة، ويتم الاستفادة من هذه المعلومات في قياس أداء النظام وإتاحيته باستمرار .

سياسات الأداء (Performance)

  • اعتمد على وقت الاستجابة (Response Time) في قياس أداء النظام وليس الإنتاجية (Throughput).
  • القاعدة الافتراضية لأداء الأنظمة:
    • وقت الاستجابة لـ 95% من الطلبات لا يتجاوز ثانية واحدة لجميع مستخدمي النظام
    • وقت معالجة 95% من الطلبات لا يتجاوز 200 مل ث على الخوادم
  • اهتم بتحسين استجابة النظام (Responsiveness) مما يحسن أداءه الملموس حتى وإن أثر ذلك سلبا على أدائه المَقيس.
  • يتم إجراء اختبار تحميل النظام قبل أول إطلاق له.
  • فكر في الاعتماد على معمارية CQRS  لتحسين أداء العمليات التي تتم في النظام.

سياسات الإتاحية (Availability)

  • إتاحية النظام الافتراضية هي 99.95% أثناء أوقات الدوام، أي لا يسمح بأن يتوقف النظام عن العمل خلال أوقات الدوام لأكثر من 6 دقائق في الأسبوع.
  • الحد الأدنى أن أي نظام يُستضاف على خادمين في كل طبقة (tier) في مركز المعلومات الرئيسي في الرياض ومثلها في مركز المعلومات الاحتياطي في القصيم.

سياسات القدرة على التوسع (Scalability)

  • يتم تصميم معمارية النظام بحيث تقبل التوسع الأفقي (Horizontal Scalability)
  • الالتزام بمعمارية RESTful Architecture والتي تدعم القدرة على التوسع، والمعتمدة في أنظمة الوزارة  (يراجع الدليل التفصيلي المعتمد في الوزارة في ذلك)
  • يتم عمل اختبار ضغط للنظام قبل أول إطلاق له.
  • يتم عمل اختبارات ضغط النظام بصورة دورية، خاصة مع كل إصدارة كبيرة.
  • أي نظام يتحمل على الأقل 30% زيادة عن تحمله الطبيعي من غير تأثر أدائه.
  • اختبارات ضغط النظام تتم في بيئة ما قبل الإطلاق (Staging Environment) مع التأكد من عزل جميع خدمات التكامل – خاصة التكامل مع الجهات الخارجية.

سياسات فحص مشكلات بطء الأنظمة

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

استرشد بالدليل التفصيلي المعتمد في الوزارة لفحص مشكلات أداء التطبيقات.