إطلاق النار في الليل ، أو لماذا تحميل همز - وليس مخيفا

"وإذا لم تطلق النار ، فسوف أفسد"

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

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

أنا فيكتور بودروف ، أعمل في Yandex.Money في فريق أبحاث الأداء وأريد أن أتحدث عن مدى فائدة دراسة الإنتاجية مباشرة على الإنتاج.

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

لماذا البحث عنه؟

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

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

ثالثًا ، بالاعتماد على بيانات الأداء الحديثة ، يسهل على الشركة تخطيط عملية تطوير الخدمة واختيار اتجاهات النمو.

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

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

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

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

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

اختيار السيناريو وأنماط تدفق التحميل

من أجل التنظيم الآمن والسليم لهذه التجارب ، يجب إكمال العديد من الخطوات الإلزامية.

اختيار السيناريو

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

ما هي السيناريوهات التي ينبغي إدراجها في مجموعة الأولوية؟

• تلك التي يتوقع لها زيادة في نشاط المستخدم في المستقبل القريب.
• تلك التي توجد بها قيود مشددة ثابتة (لأسباب مختلفة) لا تسمح لك بالسقوط تحت SLA.

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

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

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

دائرة الحمل

في الخطوة الثانية ، نختار دائرة تغذية كثافة المدخلات.

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

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

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

المحور X - الوقت ، المحور Y - كثافة الحمل (الطلبات في الثانية)

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

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

اختيار الوقت

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

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

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

صعوبات في العمل مع النظراء

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

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

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

التحقق من الوصول والتنسيق مع مجلس الأمن والإدارات المالية ومدراء

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

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

بعد الوصول ، تحتاج إلى تصحيح والتحقق من البرنامج النصي على أصغر تيار وحدة.

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

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

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

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

إطلاق وتحليل النتائج

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

هناك عدة أسباب للتوقف.

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

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

تحليل النتائج

في النهاية ، يبقى تحليل النتائج وتقديم البيانات التي تم الحصول عليها للأطراف المعنية. يمكنك البدء في القيام بذلك بالفعل خلال التجارب. نستخدم حزم Zabbix و Elastic مع Grafana و Kibana للتحليل. نحن نراقب خصائص الوقت لجميع المكالمات الخارجية والداخلية المشاركة في تجربتنا ، ونراقب تجمعات الموصل ، وقوائم الانتظار ، ومراقبة قاعدة البيانات. لتتبع المقاييس عبر الإنترنت من جانب مولد الحركة - خدمة ياندكس Lunapark (هناك تناظرية مفتوحة - overload.yandex.net).

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

بحث ناجح ، وتذكر سلامة المستخدم!