في
مقال سابق ، تحدثت عن البنية التحتية لاختبار الحمولة الكبيرة لدينا. في المتوسط ، نقوم بإنشاء حوالي 100 خادم لتوفير الحمل وحوالي 150 خادمًا لخدمتنا. جميع هذه الخوادم تحتاج إلى إنشاء وحذف وتكوين وتشغيل. للقيام بذلك ، نستخدم الأدوات نفسها المستخدمة في prod لتقليل حجم العمل اليدوي:
- لإنشاء وحذف بيئة اختبار - البرامج النصية Terraform.
- لتكوين وتحديث وتشغيل - البرامج النصية Ansible.
- للتحجيم الديناميكي حسب الحمل - نصوص بيثون المكتوبة ذاتيا.
بفضل البرامج النصية Terraform و Ansible ، يتم تنفيذ جميع العمليات من إنشاء المثيلات إلى بدء تشغيل الخادم من خلال ستة أوامر فقط:
# aws ansible-playbook deploy-config.yml # ansible-playbook start-application.yml # ansible-playbook update-test-scenario.yml --ask-vault-pass # Jmeter , infrastructure-aws-cluster/jmeter_clients:~# terraform apply # jmeter ansible-playbook start-jmeter-server-cluster.yml # jmeter ansible-playbook start-stress-test.yml #
تحجيم الخادم الديناميكي
في ساعة الذروة عند الإنتاج ، لدينا أكثر من 20 ألف مستخدم عبر الإنترنت في نفس الوقت ، وفي ساعات أخرى قد يكون هناك 6 آلاف مستخدم. ليس من المنطقي الحفاظ على الحجم الكامل للخوادم باستمرار ، لذلك قمنا بإعداد القياس التلقائي لخوادم اللوحة ، والتي يتم فتح المجالس عليها فور دخول المستخدمين إليها ، وخوادم واجهة برمجة التطبيقات التي تعالج طلبات API. الآن يتم إنشاء الخوادم وحذفها عند الضرورة.
هذه الآلية فعالة للغاية في اختبار الحمل: بشكل افتراضي ، يمكننا الحصول على الحد الأدنى لعدد الخوادم ، وفي وقت الاختبار ، سيرتفعون تلقائيًا بالكمية المناسبة. في البداية ، يمكن أن يكون لدينا 4 خوادم لوحة ، وفي الذروة - ما يصل إلى 40. في الوقت نفسه ، لا يتم إنشاء خوادم جديدة على الفور ، ولكن فقط بعد تحميل الخوادم الحالية. على سبيل المثال ، قد يكون معيار إنشاء مثيلات جديدة 50٪ من استخدام وحدة المعالجة المركزية. يتيح لك ذلك عدم إبطاء نمو المستخدمين الظاهريين في البرنامج النصي وعدم إنشاء خوادم غير ضرورية.
ومن ميزات هذا النهج أنه بفضل التحجيم الديناميكي ، فإننا نتعلم مقدار السعة التي نحتاجها لعدد مختلف من المستخدمين ، وهو ما لم نمتلكه للبيع بعد.
مجموعة من المقاييس كما هو الحال في همز
هناك العديد من الأساليب والأدوات لمراقبة اختبارات الإجهاد ، لكننا ذهبنا بطريقتنا الخاصة.
نحن نراقب الإنتاج باستخدام مكدس قياسي: Logstash و Elasticsearch و Kibana و Prometheus و Grafana. تتشابه مجموعة الاختبارات الخاصة بنا مع المنتج ، لذلك قررنا إجراء نفس المراقبة مثل prod ، بنفس المقاييس. هناك سببان لهذا:
- لا حاجة لبناء نظام مراقبة من الصفر ، لدينا بالفعل كاملة وفورية.
- نقوم أيضًا باختبار مراقبة المبيعات: إذا فهمنا أثناء مراقبة الاختبار أنه ليس لدينا بيانات كافية لتحليل المشكلة ، فلن تكون كافية للإنتاج ، عندما تظهر مثل هذه المشكلة هناك.
ما نظهره في التقارير
- الخصائص التقنية للحامل ؛
- البرنامج النصي نفسه ، الموصوف بالكلمات ، وليس بالكود ؛
- نتيجة مفهومة لجميع أعضاء الفريق ، كل من المطورين والمديرين ؛
- الرسوم البيانية للحالة العامة للموقف ؛
- الرسوم البيانية التي تظهر عنق الزجاجة أو التي تتأثر بالتحسين الذي تم فحصه في الاختبار.
من المهم أن يتم تخزين جميع النتائج في مكان واحد. لذلك سيكون من المناسب مقارنتها مع بعضها البعض من الإطلاق إلى الإطلاق.
نقوم بعمل تقارير في منتجنا
(مثال على لوحة بيضاء مع تقرير) :
يستغرق إنشاء تقرير الكثير من الوقت. لذلك ، نخطط لجعل عملية جمع المعلومات العامة تلقائية باستخدام
واجهة برمجة التطبيقات العامة الخاصة بنا .
البنية التحتية كرمز
نحن مسؤولون عن جودة المنتج ليسوا QA Engineers ، ولكن الفريق بأكمله. اختبارات الإجهاد هي واحدة من أدوات ضمان الجودة. رائع ، إذا كان الفريق يدرك أنه من المهم التحقق من تحميل التغييرات التي أجراها. لبدء التفكير في الأمر ، تحتاج إلى أن تصبح مسؤولة عن الإنتاج. وهنا ساعدنا مبادئ ثقافة DevOps ، التي بدأنا تنفيذها في عملنا.
لكن البدء في التفكير في إجراء اختبارات الإجهاد ليس سوى الخطوة الأولى. لن يتمكن الفريق من التفكير في الاختبارات دون فهم جهاز الإنتاج. واجهنا مثل هذه المشكلة عندما بدأنا في إعداد عملية إجراء اختبارات الحمل في فرق. في ذلك الوقت ، لم يكن لدى الفرق طريقة لمعرفة جهاز الإنتاج ، لذلك كان من الصعب عليهم العمل على تصميم الاختبارات. كانت هناك عدة أسباب: عدم وجود مستندات محدّثة أو شخص واحد كان سيحتفظ بالصورة الكاملة للبيع في رأسي ؛ النمو المتعدد لفريق التطوير.
لمساعدة الفرق على فهم عمل المبيعات ، يمكن استخدام نهج البنية التحتية كرمز ، والذي بدأ استخدامه في فريق التطوير.
ما هي المشاكل التي بدأنا حلها بالفعل باستخدام هذا النهج:
- كل شيء يجب كتابته ويمكن رفعه في أي وقت. هذا يقلل بشكل كبير من وقت الاسترداد للمبيعات في حالة وقوع حادث مركز البيانات ويسمح لك للحفاظ على الكمية المناسبة من بيئات الاختبار ذات الصلة ؛
- وفورات معقولة: نقوم بنشر بيئات على Openstack عندما يمكن أن تحل محل الأنظمة الأساسية الباهظة الثمن مثل AWS ؛
- تُنشئ الفرق نفسها اختبارات إجهاد لأنهم يفهمون أن الجهاز يبيع ؛
- يحل الرمز محل الوثائق ، لذلك ليست هناك حاجة لتحديثه إلى ما لا نهاية ، فهو دائمًا كامل ومحدث ؛
- لا تحتاج إلى خبير منفصل في مجال ضيق لحل المشكلات العادية. يمكن لأي مهندس معرفة الرمز ؛
- من خلال هيكل مبيعات واضح ، من الأسهل كثيرًا جدولة اختبارات تحميل البحوث مثل اختبارات قرد الفوضى أو اختبارات تسرب الذاكرة الطويلة.
أود توسيع هذا النهج ليس فقط لإنشاء البنية التحتية ، ولكن أيضًا لدعم مختلف الأدوات. على سبيل المثال ، اختبار قاعدة البيانات ، الذي
تحدثت عنه في مقال سابق ، تحولنا بالكامل إلى رمز. نتيجة لهذا ، بدلاً من موقع تم إعداده مسبقًا ، لدينا مجموعة من البرامج النصية ، والتي في غضون 7 دقائق نحصل على البيئة التي تم تكوينها في حساب AWS فارغ تمامًا ويمكننا بدء الاختبار. للسبب نفسه ، نحن الآن نفكر ملياً في
Gatling ، التي
يضعها المبدعون كأداة لـ "اختبار التحميل كرمز".
يستلزم النهج المتبع في البنية الأساسية ككود اتباع نهج مماثل لاختباره والبرامج النصية التي يكتبها الفريق لرفع البنية التحتية للميزات الجديدة. كل هذا يجب أن تكون مغطاة الاختبارات. هناك أيضًا أطر اختبار مختلفة ، مثل
Molecule . هناك أدوات لاختبار قرد الفوضى ، وهناك أدوات مدفوعة الأجر لـ AWS ، وهناك عامل
Pumba لـ Docker ، إلخ. إنها تسمح لك بحل أنواع مختلفة من المهام:
- كيفية التحقق من تعطل أحد مثيلات AWS للتحقق من إعادة تحميل الحمل على الخوادم المتبقية وما إذا كانت الخدمة ستستمر من إعادة التوجيه الحادة للطلبات ؛
- كيفية محاكاة التشغيل البطيء للشبكة وكسرها والمشاكل الفنية الأخرى ، وبعدها يجب ألا ينقطع منطق البنية التحتية للخدمة.
حل هذه المشاكل في خططنا الفورية.
النتائج
- لا يستحق إضاعة الوقت في التنسيق اليدوي للبنية التحتية للاختبار ؛ فمن الأفضل أتمتة هذه الإجراءات من أجل إدارة جميع البيئات بشكل أكثر موثوقية ، بما في ذلك prod ؛
- القياس الديناميكي يقلل بشكل كبير من تكلفة الحفاظ على المبيعات وبيئة اختبار كبيرة ، وكذلك يقلل من العامل البشري عند القياس ؛
- لا يمكنك استخدام نظام مراقبة منفصل للاختبارات ، ولكن يمكنك أخذه من السوق ؛
- من المهم أن يتم جمع تقارير اختبار الإجهاد تلقائيًا في مكان واحد وأن يكون لها رؤية موحدة. سيسمح لهم ذلك بمقارنة وتحليل التغييرات بسهولة ؛
- ستصبح اختبارات الإجهاد عملية في الشركة عندما تشعر الفرق بالمسؤولية عن المبيعات ؛
- اختبارات الحمل - اختبارات البنية التحتية. إذا نجح اختبار الحمل ، فمن المحتمل أنه لم يتم تجميعه بشكل صحيح. يتطلب التحقق من صحة الاختبار وجود فهم عميق للمبيعات. يجب أن تتاح للفرق الفرصة لفهم جهاز المبيعات بشكل مستقل. نحل هذه المشكلة باستخدام البنية التحتية كنهج الكود ؛
- تتطلب البرامج النصية لإعداد البنية الأساسية أيضًا اختبارًا مثل أي كود آخر.