تتناول هذه المقالة أنواعًا مختلفة من الاختبارات في الإنتاج والظروف التي يكون فيها كل منها مفيدًا للغاية ، كما تصف كيفية تنظيم الاختبار الآمن للخدمات المختلفة في الإنتاج.
تجدر الإشارة إلى أن محتوى هذه المقالة ينطبق فقط على تلك
الخدمات ، التي يتحكم المطورون في نشرها. بالإضافة إلى ذلك ، يجب عليك أن تحذر على الفور من أن استخدام أي من أنواع الاختبارات الموضحة هنا ليست مهمة سهلة ، والتي تتطلب غالبًا تغييرات خطيرة في تصميم الأنظمة وتطويرها واختبارها. وعلى الرغم من عنوان المقال ، لا أعتقد أن أيًا من أنواع الاختبارات في الإنتاج يمكن الاعتماد عليه تمامًا. هناك رأي فقط بأن مثل هذا الاختبار يمكن أن يقلل بشكل كبير من مستوى المخاطر في المستقبل ، وسيتم تبرير تكاليف الاستثمار.
(ملاحظة: نظرًا لأن المقالة الأصلية هي Longrid ، فقد تم تقسيمها لراحة القراء) إلى قسمين).لماذا الاختبار في الإنتاج ضروري إذا كان يمكن القيام به في المرحلة؟
يتم إدراك أهمية مجموعة الترحيل (أو بيئة التدريج) من قبل أشخاص مختلفين بشكل مختلف. بالنسبة للعديد من الشركات ، يعد نشر المنتج واختباره في المرحلة مرحلة متكاملة قبل إصداره النهائي.
ترى العديد من المنظمات المعروفة التقديم كنسخة مصغرة من بيئة العمل. في مثل هذه الحالات ، هناك حاجة لضمان التزامن الأقصى. في هذه الحالة ، عادة ما يكون من الضروري التأكد من تشغيل حالات مختلفة من الأنظمة ذات الحالة ، مثل قواعد البيانات ، ومزامنة البيانات بانتظام من بيئة الإنتاج مع التدريج. والاستثناء الوحيد هو المعلومات السرية التي تسمح لك لتحديد هوية المستخدم (وهذا أمر ضروري للامتثال
GDPR ،
وPCI ،
وHIPAA وغيرها من الأنظمة).
المشكلة في هذا النهج (في تجربتي) هي أن الاختلاف ليس فقط في استخدام نسخة منفصلة من قاعدة البيانات التي تحتوي على بيانات بيئة الإنتاج الفعلية. غالبًا ما يمتد الاختلاف إلى الجوانب التالية:
- حجم الكتلة المرحلية (إذا كان يمكنك تسميتها "كتلة" - أحيانًا يكون مجرد خادم واحد متنكراً في شكل كتلة) ؛
- حقيقة أن الترحيل يستخدم عادةً كتلة أصغر بكثير يعني أيضًا أن إعدادات التكوين لكل خدمة ستختلف تقريبًا. ينطبق هذا على تكوينات موازنات التحميل وقواعد البيانات وقوائم الانتظار ، على سبيل المثال ، عدد واصفات الملفات المفتوحة ، وعدد اتصالات قاعدة البيانات المفتوحة ، وحجم تجمع سلاسل المحادثات ، وما إلى ذلك. إذا تم تخزين التكوين في قاعدة بيانات أو تخزين بيانات قيمة المفتاح (على سبيل المثال ، Zookeeper أو القنصل) ، يجب أن تكون هذه الأنظمة المساعدة موجودة أيضًا في بيئة التدريج ؛
- عدد الاتصالات عبر الإنترنت التي تتم معالجتها بواسطة الخدمة عديمة الحالة ، أو طريقة إعادة استخدام اتصالات TCP بواسطة خادم وكيل (إذا تم تنفيذ هذا الإجراء على الإطلاق) ؛
- عدم وجود مراقبة في المرحلة. ولكن حتى إذا تم إجراء المراقبة ، فقد تتحول بعض الإشارات إلى أنها غير دقيقة تمامًا ، حيث تتم مراقبة بيئة أخرى غير بيئة العمل. على سبيل المثال ، حتى إذا كنت تراقب وقت استجابة استعلام MySQL أو وقت الاستجابة ، فمن الصعب تحديد ما إذا كان الرمز الجديد يحتوي على استعلام يمكنه بدء فحص جدول كامل في MySQL ، لأنه أسرع كثيرًا (وأحيانًا أفضل) لإجراء فحص كامل للجدول الصغير المستخدم في الاختبار قاعدة بيانات بدلاً من قاعدة بيانات إنتاج ، حيث يمكن أن يكون للاستعلام ملف تعريف أداء مختلف تمامًا.
على الرغم من أنه من الإنصاف أن نفترض أن جميع الاختلافات المذكورة أعلاه ليست حججًا جدية ضد استخدام التدريج على هذا النحو ، على عكس المضادات المضادة التي يجب تجنبها. في الوقت نفسه ، غالبًا ما تتطلب الرغبة في القيام بكل شيء بشكل صحيح تكاليف العمالة الهائلة للمهندسين في محاولة لضمان بيئة متسقة. يتغير الإنتاج باستمرار ويتأثر بعوامل مختلفة ، لذا فإن محاولة تحقيق هذه المباراة تشبه الذهاب إلى أي مكان.
علاوة على ذلك ، حتى إذا كانت الظروف على المرحلة ستكون متشابهة قدر الإمكان مع بيئة العمل ، فهناك أنواع أخرى من الاختبارات التي من الأفضل استخدامها بناءً على معلومات الإنتاج الحقيقية. من الأمثلة الجيدة اختبار النقع ، حيث يتم اختبار موثوقية واستقرار الخدمة على مدى فترة طويلة من الزمن على مستويات حقيقية من تعدد المهام والحمل. يتم استخدامه للكشف عن تسرب الذاكرة ، وتحديد مدة التوقفات في GC ومستوى تحميل المعالج ومؤشرات أخرى لفترة معينة من الزمن.
لا يشير أي مما سبق إلى أن الترحيل عديم الفائدة
تمامًا (سيظهر هذا بعد قراءة القسم الخاص بتكرار الظل للبيانات عند اختبار الخدمات). هذا يشير فقط إلى أنهم يعتمدون في كثير من الأحيان على التدريج إلى حد أكبر مما هو ضروري ، وفي العديد من المنظمات يظل النوع
الوحيد من الاختبار الذي يتم إجراؤه قبل الإصدار الكامل للمنتج.
فن الاختبار في الإنتاج
حدث ذلك تاريخيًا أن مفهوم "الاختبار في الإنتاج" مرتبط ببعض القوالب النمطية والدلالات السلبية ("برمجة حرب العصابات" ، ونقص أو عدم اختبار الوحدة والتكامل ، والإهمال أو عدم الانتباه إلى إدراك المنتج من قبل المستخدم النهائي).
من المؤكد أن الاختبار في الإنتاج يستحق مثل هذه السمعة إذا تم إجراؤه بلا مبالاة وسوء. إنها
لا تحل بأي حال من الأحوال
محل الاختبار في مرحلة ما قبل الإنتاج ، وهي
مهمة بسيطة تحت أي ظرف من الظروف. علاوة على ذلك ، أجادل بأن الاختبار
الناجح والآمن في الإنتاج يتطلب مستوى كبير من الأتمتة ، وفهمًا جيدًا للممارسات المعمول بها ، وتصميم الأنظمة ذات التوجه الأولي لهذا النوع من الاختبار.
من أجل تنظيم عملية شاملة وآمنة للاختبار الفعال للخدمات في الإنتاج ، من المهم عدم اعتبارها مصطلحًا عامًا يشير إلى مجموعة من الأدوات والتقنيات المختلفة. لسوء الحظ ، لقد ارتكبت هذا الخطأ أيضًا -
في مقالتي السابقة لم يتم تقديم تصنيف علمي تمامًا لطرق الاختبار ، وفي قسم "الاختبار في الإنتاج" تم تجميع مجموعة متنوعة من المنهجيات والأدوات.
من الملاحظة اختبار الخدمات الصغيرة ، الطريقة المعقولة ("نهج ذكي لاختبار الخدمات الصغيرة")منذ نشر المذكرة في نهاية ديسمبر 2017 ، كنت أناقش محتواها وعمومًا موضوع الاختبار في الإنتاج مع عدة أشخاص.
في سياق هذه المناقشات ، وأيضًا بعد سلسلة من المحادثات المنفصلة ، اتضح لي أنه لا يمكن اختزال موضوع الاختبار في الإنتاج إلى عدة نقاط مدرجة أعلاه.
مصطلح "اختبار prodakshene" يشمل تقنيات الطيف تطبيقها
في ثلاث مراحل مختلفة. أي منها - دعنا نفهم.
ثلاث مراحل من الإنتاج
عادة ما تتم المناقشات حول الإنتاج فقط في سياق نشر التعليمات البرمجية في الإنتاج أو المراقبة أو في حالات الطوارئ عندما يحدث خطأ ما.
أنا نفسي استخدمت حتى الآن مصطلحات مثل "النشر" و "الإصدار" و "التسليم" وما إلى ذلك ، كمرادفات ، مع القليل من التفكير في معناها. قبل بضعة أشهر ، رفضت كل محاولات التمييز بين هذه الشروط باعتبارها شيئًا غير مهم.
بعد التفكير في ذلك ، توصلت إلى فكرة أن
هناك حاجة حقيقية للتمييز بين مراحل الإنتاج المختلفة.
المرحلة 1. النشر
عندما يكون الاختبار (حتى في الإنتاج) فحصًا لتحقيق
أفضل المؤشرات الممكنة ، يتم ضمان دقة الاختبار (وبالفعل أي اختبارات) بشرط أن تكون طريقة إجراء الاختبارات قريبة قدر الإمكان من الطريقة التي يتم بها استخدام الخدمة بالفعل في الإنتاج.
بمعنى آخر ، يجب إجراء الاختبارات في بيئة
تحاكي بيئة العمل على أفضل وجه .
وأفضل تقليد لبيئة العمل هو ... بيئة العمل نفسها. لإجراء أكبر عدد ممكن من الاختبارات في بيئة الإنتاج ، من الضروري ألا تؤثر النتيجة غير الناجحة لأي منها على المستخدم النهائي.
وهذا بدوره ممكن فقط إذا
لم يحصل المستخدمون ،
عند نشر الخدمة في بيئة إنتاج ، على وصول مباشر إلى هذه الخدمة .
في هذه المقالة ، قررت استخدام المصطلحات من
Deploy! = مقالة
الإصدار التي كتبها
Turbine Labs . يعرف مصطلح "النشر" كما يلي:
"النشر هو التثبيت من قبل مجموعة عمل لإصدار جديد من رمز برنامج الخدمة في البنية التحتية للإنتاج. عندما نقول أنه تم
نشر إصدار جديد من البرنامج ، فإننا نعني أنه يتم تشغيله في مكان ما ضمن إطار البنية التحتية العاملة. يمكن أن يكون هذا نسخة EC2 جديدة في AWS أو حاوية Docker تعمل في قلب مجموعة Kubernetes. تم بدء الخدمة بنجاح ، واجتازت فحصًا صحيًا وهي جاهزة (آمل!) لمعالجة بيانات بيئة الإنتاج ، ولكن قد لا تتلقى البيانات بالفعل. هذه نقطة مهمة ، أؤكدها مرة أخرى:
للنشر ليس من الضروري للمستخدمين الوصول إلى الإصدار الجديد من الخدمة الخاصة بك . بالنظر إلى هذا التعريف ، يمكن أن يطلق على النشر عملية تنطوي على مخاطر صفر تقريبًا ".
عبارة "عملية خالية من المخاطر" هي مجرد بلسم لروح العديد من الناس الذين عانوا من عمليات نشر غير ناجحة. القدرة على تثبيت البرامج
في بيئة حقيقية دون السماح للمستخدمين لها عدد من المزايا عندما يتعلق الأمر بالاختبار.
أولاً ، يتم تقليل الحاجة إلى الحفاظ على بيئات منفصلة للتطوير والاختبار والتدريج ، والتي يجب حتماً أن تكون متزامنة مع الإنتاج ، (وقد تختفي تمامًا).
وبالإضافة إلى ذلك، خلال الخدمات مرحلة التصميم لا بد من عزلهم عن كل ذلك الآخر أن تجربة فاشلة مثيل خدمة معينة في prodakshene
لا يؤدي إلى الفشل المتتالية أو التأثير على المستخدمين من الخدمات الأخرى. يمكن أن يكون أحد الحلول لذلك هو تصميم نموذج البيانات ومخطط قاعدة البيانات حيث يمكن للاستعلامات غير المنفتحة (
عمليات الكتابة بشكل أساسي):
- يتم إجراؤه فيما يتعلق بقاعدة بيانات بيئة الإنتاج أثناء أي إطلاق اختبار للخدمة في الإنتاج (أفضل هذا النهج) ؛
- أن يتم رفضك بأمان على مستوى الطلب حتى يصل إلى مستوى الكتابة أو الحفظ ؛
- يتم تخصيصها أو عزلها في السجل أو حفظ المستوى بطريقة ما (على سبيل المثال ، عن طريق تخزين بيانات تعريف إضافية).
المرحلة 2. الإصدار
ملاحظة
نشر! = يحدد
الإصدار مصطلح
التحرير كما يلي:
"عندما نقول أن
إصدار إصدار الخدمة حدث ، فإننا نعني أنه يوفر معالجة البيانات في بيئة الإنتاج. بمعنى آخر ،
الإصدار هو عملية توجه بيانات بيئة الإنتاج إلى إصدار برنامج جديد. مع وضع هذا التعريف في الاعتبار ، فإن جميع المخاطر التي نربطها بإرسال تدفقات البيانات الجديدة (انقطاع العمل ، وعدم رضا العملاء ، والملاحظات السامة في
السجل ) تتعلق
بإصدار برنامج جديد ، وليس نشره (في بعض الشركات تسمى هذه المرحلة أيضًا
الإصدار . في هذه المقالة سنستخدم مصطلح
الإصدار ). "
في كتاب Google عن SRE ، يتم استخدام مصطلح "الإصدار" في
الفصل الخاص بتنظيم إصدار البرنامج لوصفه .
"
المشكلة هي عنصر منطقي للعمل يتكون من مهمة منفصلة واحدة أو أكثر. هدفنا هو تنسيق عملية النشر مع ملف تعريف المخاطر لهذه الخدمة .
في بيئات التطوير أو ما قبل الإنتاج ، يمكننا إنشاء كل ساعة وتوزيع الإصدارات تلقائيًا بعد اجتياز جميع الاختبارات. بالنسبة للخدمات الكبيرة الموجهة للمستخدم ، يمكننا بدء الإصدار بمجموعة واحدة ، ثم زيادة حجمه حتى نقوم بتحديث جميع المجموعات.
بالنسبة لعناصر البنية التحتية الهامة ، يمكننا تمديد فترة التنفيذ لعدة أيام وتنفيذها بدورها في مناطق جغرافية مختلفة. "في هذه المصطلحات، وكلمة "الافراج" و "الافراج" يشير إلى حقيقة أن المفردات الإجمالية هو المقصود ب "تتكشف"، وغالبا ما تستخدم المصطلحات لوصف استراتيجيات مختلفة
لنشر (على سبيل المثال، نشر الأزرق والأخضر أو نشر الكناري)، والرجوع إلى
الإفراج عن الجديد البرمجيات.
علاوة على ذلك ، قد يؤدي
الإصدار غير الناجح للتطبيقات إلى حدوث انقطاعات جزئية أو كبيرة في العمل. في هذه المرحلة ، يتم أيضًا تنفيذ
التراجع أو
الإصلاح العاجل إذا اتضح أن الإصدار الجديد من الخدمة غير مستقر.
تعمل عملية
الإصدار بشكل أفضل عندما تكون مؤتمتة وتعمل
بشكل متزايد . وبالمثل ، فإن
التراجع أو
الإصلاح العاجل للخدمة يكون أكثر فائدة عندما يرتبط معدل الخطأ وتكرار الطلب تلقائيًا بخط الأساس.
المرحلة 3. بعد الإصدار
إذا سار الإصدار
بسلاسة وكان الإصدار الجديد من الخدمة يعالج بيانات بيئة الإنتاج دون مشاكل واضحة ، فيمكننا اعتبارها ناجحة. يتبع الإصدار الناجح مرحلة يمكن تسميتها "بعد الإصدار".
إن أي نظام معقد بدرجة كافية سيكون
دائمًا في حالة فقدان تدريجي للأداء. هذا لا يعني أن
التراجع أو
الإصلاح العاجل مطلوب . بدلاً من ذلك ، من الضروري مراقبة هذا التدهور (للأغراض التشغيلية والتشغيلية المختلفة) وتصحيح الأخطاء إذا لزم الأمر. لهذا السبب ، لم يعد الاختبار بعد الإصدار يشبه الإجراءات الروتينية فحسب ، بل
تصحيح الأخطاء أو جمع البيانات التحليلية.
بشكل عام ، أعتقد أنه يجب إنشاء كل مكون من مكونات النظام مع الأخذ في الاعتبار حقيقة أنه لا يوجد نظام واحد كبير يعمل بشكل مثالي بنسبة 100٪ وأنه يجب التعرف على الأعطال وأخذها في الاعتبار في مراحل تصميم البرنامج وتطويره واختباره ونشره ومراقبته تقديم.
الآن بعد أن حددنا المراحل الثلاثة للإنتاج ، دعونا نلقي نظرة على آليات الاختبار المختلفة المتاحة في كل منها. ليس لدى الجميع فرصة للعمل على مشاريع جديدة أو إعادة كتابة التعليمات البرمجية من الصفر. في هذه المقالة ، حاولت تحديد الأساليب التي ستعمل بشكل أفضل عند تطوير مشاريع جديدة بوضوح ، بالإضافة إلى التحدث عن ما يمكننا القيام به أيضًا للاستفادة من الأساليب المقترحة دون إجراء تغييرات كبيرة على مشاريع العمل.
اختبار النشر
قمنا بفصل مرحلتي النشر والإصدار عن بعضهما البعض ، والآن سننظر في بعض أنواع الاختبارات التي يمكن تطبيقها بعد نشر الكود في بيئة الإنتاج.
اختبار التكامل
عادة ، يتم تنفيذ اختبار التكامل من قبل خادم التكامل المستمر في بيئة اختبار معزولة لكل فرع Git. ومن المقرر نسخة
من طوبولوجيا خدمة
بأكمله (بما في ذلك قواعد البيانات، طوابير، خوادم بروكسي، وهلم جرا. N.) لاختبار مجموعات
من كافة الخدمات التي ستعمل معا.
أعتقد أن هذا ليس فعالًا بشكل خاص لعدة أسباب. بادئ ذي بدء ، لا يمكن نشر بيئة الاختبار ، مثل بيئة التدريج ، بطريقة
تتطابق مع بيئة الإنتاج الحقيقية ،
حتى إذا تم تشغيل الاختبارات في حاوية Docker نفسها التي سيتم استخدامها في الإنتاج. هذا صحيح بشكل خاص عندما يكون
الشيء الوحيد الذي يعمل في بيئة الاختبار هو الاختبارات نفسها.
بغض النظر عما إذا كان الاختبار يتم تشغيله كحاوية Docker أو عملية POSIX ، فمن المرجح أن يُجري اتصالًا أو أكثر بخدمة أو قاعدة بيانات أو ذاكرة تخزين مؤقت متفوقة ، وهو أمر نادر الحدوث إذا كانت الخدمة في بيئة إنتاج حيث يمكنها في وقت واحد معالجة اتصالات متزامنة متعددة ، غالبًا إعادة استخدام اتصالات TCP غير النشطة (وهذا ما يسمى إعادة استخدام اتصالات HTTP).
أيضا ، سبب المشكلة هو حقيقة أن معظم الاختبارات في كل بداية تنشئ جدول قاعدة بيانات جديد أو مساحة مفتاح ذاكرة التخزين المؤقت على
نفس العقدة حيث يتم تنفيذ هذا الاختبار (بهذه الطريقة يتم عزل الاختبارات من فشل الشبكة). يمكن أن يوضح هذا النوع من الاختبارات في أحسن الأحوال أن النظام يعمل بشكل صحيح مع طلب محدد للغاية. ونادرا ما تكون فعالة في محاكاة أنواع الفشل الخطيرة والموزعة بشكل جيد ، ناهيك عن الأنواع المختلفة من الفشل الجزئي. توجد
دراسات شاملة تؤكد أن الأنظمة الموزعة غالبًا ما تظهر
سلوكًا غير متوقع لا يمكن توقعه عن طريق التحليل الذي يتم إجراؤه بشكل مختلف عن النظام بأكمله.
ولكن هذا لا يعني أن اختبار التكامل لا جدوى من
حيث المبدأ . يمكننا أن نقول فقط أن تنفيذ اختبارات التكامل في بيئة
اصطناعية ومعزولة تمامًا ، كقاعدة عامة ، لا معنى له. لا يزال يتعين إجراء اختبار التكامل للتحقق من أن الإصدار الجديد من الخدمة:
- لا تتداخل مع التفاعل مع خدمات التيار أو التيار ؛
- لا يؤثر سلبا على أهداف وغايات الخدمات الأعلى أو الأدنى.
يمكن توفير الأول إلى حد ما من خلال اختبار العقد.
نظرًا لحقيقة أن
الواجهات بين الخدمات تعمل بشكل صحيح ، يعد
اختبار العقد طريقة فعالة لتطوير واختبار الخدمات الفردية في
مرحلة ما قبل الإنتاج ، والتي لا تتطلب نشر طوبولوجيا الخدمة بالكامل.
تدعم منصات اختبار العقود الموجهة للعملاء ، مثل
Pact ، حاليًا فقط إمكانية التشغيل المتبادل بين الخدمات من خلال RESTful JSON RPC ، على الرغم من أنه من المحتمل أن
العمل جار لدعم التفاعل غير المتزامن من خلال مآخذ الويب والتطبيقات غير التابعة للخادم وقوائم انتظار الرسائل . من المحتمل أن تتم إضافة دعم بروتوكولي gRPC و GraphQL في المستقبل ، ولكنه الآن غير متاح بعد.
ومع ذلك ، قبل
إصدار نسخة جديدة ، قد يكون من الضروري التحقق ليس فقط من التشغيل الصحيح
للواجهات . , , , RPC- . , , , .
,
, — ,
, ( , ).
:
?
. – , : - - ( C) MySQL ( D) memcache ( B).
, ( ), stateful- stateless- .
,
.
service discovery
( ),
.
.
,
C .
,
, , . , , . ,
, .
Google
Just Say No to More End-to-End Tests (« »), :
«
( ) . , ? , .
, , , »., :
. , A .
,
C MySQL, .
( , , «» ,
).
MySQL , , .
— -. , . -, .
, -
, /:
, (, ).
, ,
. IP- , , , , , , , , .
, , , , . . Facebook,
Kraken , :
«
— , . - , . , . - , , , »., , , , , .
- . service mesh . -. -, , , :
إذا اختبرنا الخدمة B ، فيمكن تهيئة خادم الوكيل الصادر لإضافة رأس
X-ServiceB-Test لكل طلب اختبار. في هذه الحالة ، سيكون خادم الوكيل الوارد للخدمة المتفوقة C قادرًا على:
- كشف هذا الرأس وإرسال استجابة قياسية للخدمة B ؛
- أخبر الخدمة C أن الطلب عبارة عن اختبار .
اختبار تكامل تفاعل الإصدار المنشور من الخدمة B مع الإصدار الذي تم إصداره من الخدمة C ، حيث لا تصل عمليات الكتابة مطلقًا إلى قاعدة البياناتيسمح إجراء اختبار التكامل بهذه الطريقة أيضًا باختبار تفاعل الخدمة B مع الخدمات الأعلى
عندما تعالج بيانات بيئة الإنتاج العادية - ربما يكون هذا تقليدًا أقرب لكيفية تصرف الخدمة B عند
إطلاقها في الإنتاج.
سيكون من الجيد أيضًا إذا دعمت كل خدمة في هذه البنية مكالمات API الحقيقية في وضع الاختبار أو وهمية ، مما يسمح لك باختبار تنفيذ عقود الخدمة مع خدمات المصب دون تغيير البيانات الحقيقية. سيكون هذا بمثابة اختبار للعقد ، ولكن على مستوى الشبكة.
تكرار بيانات الظل (اختبار دفق البيانات أو النسخ المطابق)
ازدواج الظل (في المقالة على مدونة Google يطلق عليه
الإطلاق المظلم ، ويستخدم مصطلح
النسخ المطابق في
Istio ) في كثير من الحالات مزايا أكثر من اختبار التكامل.
تنص
مبادئ هندسة الفوضى على ما يلي:
"
تتصرف الأنظمة بشكل مختلف اعتمادًا على البيئة ونظام نقل البيانات. نظرًا لأن وضع الاستخدام يمكن أن يتغير في أي وقت ، فإن
أخذ عينات من البيانات الحقيقية هو الطريقة الوحيدة الموثوقة لإصلاح مسار الطلب ".يعد تكرار بيانات الظل طريقة يتم من خلالها التقاط دفق بيانات بيئة الإنتاج التي تدخل خدمة معينة وإعادة إنتاجها في إصدار جديد من الخدمة. يمكن تنفيذ هذه العملية إما في الوقت الفعلي ، عندما يتم تقسيم دفق البيانات الواردة وإرسالها إلى كل من الإصدارات التي
تم إصدارها ونشرها من الخدمة ، أو بشكل غير متزامن ، عند تشغيل نسخة من البيانات التي تم التقاطها مسبقًا في الخدمة
المنشورة .
عندما عملت في
imgix (شركة ناشئة مع طاقم من 7 مهندسين ، أربعة منهم فقط من مهندسي النظام) ، تم استخدام تدفقات البيانات المظلمة بنشاط لاختبار التغييرات في البنية التحتية لتصور الصور. سجلنا نسبة معينة من جميع الطلبات الواردة وأرسلناها إلى مجموعة كافكا - لقد مررنا سجلات الوصول HAProxy إلى خط أنابيب
الهكا ، والذي بدوره مرر تدفق الطلب الذي تم تحليله إلى مجموعة كافكا. قبل مرحلة
الإصدار ، تم اختبار إصدار جديد من تطبيق معالجة الصور الخاص بنا على دفق بيانات داكن تم التقاطه - وهذا جعل من الممكن التحقق من معالجة الطلبات بشكل صحيح. ومع ذلك ، كان نظام تصور الصور الخاص بنا إلى حد كبير خدمة بلا حالة مناسبة بشكل خاص لهذا النوع من الاختبارات.
تفضل بعض الشركات التقاط ليس جزءًا من دفق البيانات ، ولكن ترسل
نسخة كاملة من هذا الدفق إلى الإصدار الجديد من التطبيق.
شركة الموجه McRouter الفيسبوك (الوكيل أعطها) يدعم هذا النوع من الظل الازدواجية دفق البيانات memcache.
"
عند اختبار تثبيت جديد لذاكرة التخزين المؤقت ، وجدنا أنه من الملائم جدًا أن نتمكن من إعادة توجيه نسخة كاملة من دفق البيانات من العملاء. يدعم McRouter إعدادات تكرار الظل المرنة. من الممكن تنفيذ تكرار الظل لمجموعة متنوعة الأحجام (عن طريق إعادة تخزين مساحة المفتاح مؤقتًا) ، أو نسخ جزء فقط من مساحة المفتاح ، أو تغيير المعلمات ديناميكيًا أثناء التشغيل . "
الجانب السلبي لتكرار الظل لتدفق البيانات بالكامل لخدمة
منتشرة في بيئة إنتاج هو أنه إذا تم تنفيذه في لحظة كثافة نقل البيانات القصوى ، فقد يتطلب ضعف الطاقة.
تدعم البروكسيات مثل Envoy تكرار الظل لتدفق البيانات إلى مجموعة أخرى في وضع إطلاق النار والنسيان. تقول
وثائقها :
"
يمكن لجهاز التوجيه تنفيذ ازدواج الظل لتدفق البيانات من مجموعة إلى أخرى. يتم حاليًا تنفيذ وضع إطلاق النار والنسيان ، حيث لا ينتظر خادم وكيل Envoy استجابة من مجموعة الظل قبل إرجاع استجابة من المجموعة الرئيسية. بالنسبة لمجموعة الظل ، يتم جمع جميع الإحصائيات المعتادة ، وهو أمر مفيد لأغراض الاختبار. مع تكرار الظل ، يتم إضافة خيار -shadow إلى -shadow المضيف / السلطة. هذا مفيد للتسجيل. على سبيل المثال ، تتحول المجموعة 1 إلى cluster1-shadow "
ومع ذلك ، غالبًا ما يكون من غير العملي أو المستحيل إنشاء نسخة طبق الأصل من مجموعة متزامنة مع الإنتاج للاختبار (لنفس السبب الذي يصعب تنظيم مجموعة مرحلية متزامنة). إذا تم استخدام ازدواج الظل لاختبار خدمة جديدة
منشورة لها العديد من التبعيات ، فيمكن أن تبدأ تغييرات غير متوقعة في حالة الخدمات ذات المستوى الأعلى فيما يتعلق بالخدمة المختبرة. يمكن أن يؤدي ازدواج الظل للحجم اليومي لتسجيلات المستخدم في الإصدار
المنشور من الخدمة مع التسجيل في قاعدة بيانات الإنتاج إلى زيادة في معدل الخطأ يصل إلى 100٪ نظرًا لحقيقة أن تدفق بيانات الظل سيتم اعتباره محاولات متكررة للتسجيل ورفض.
تقترح تجربتي الشخصية أن ازدواج الظل هو الأنسب لاختبار الطلبات غير المصنفة أو الخدمات عديمة الحالة مع بذرة جانب الخادم. في هذه الحالة ، غالبًا ما يتم استخدام تكرار البيانات في الظل لاختبار الحمل والاستقرار والتكوينات. في نفس الوقت ، بمساعدة اختبار التكامل أو التقسيم المرحلي ، يمكنك اختبار كيفية تفاعل الخدمة مع خادم ذي حالة عند العمل مع الطلبات غير المصنفة.
مقارنة TAP
يذكر هذا المصطلح فقط في
مقالة من مدونة Twitter مخصصة لإطلاق الخدمات بمستوى عالٍ من جودة الخدمة.
"للتحقق من صحة التنفيذ الجديد للنظام الحالي ، استخدمنا طريقة تسمى مقارنة النقر . تعيد أداة مقارنة النقر لدينا نسخ بيانات الإنتاج في النظام الجديد وتقارن الإجابات المستلمة مع نتائج النظام القديم. وقد ساعدتنا النتائج التي تم الحصول عليها في العثور على الأخطاء وإصلاحها في النظام حتى قبل أن يواجهها المستخدمون ".تحدد مشاركة مدونة Twitter
أخرى مقارنات النقر على النحو التالي:
"إرسال الطلبات لمثيلات الخدمة في كل من الإنتاج وبيئات الترحيل مع التحقق من النتائج وتقييم خصائص الأداء."الفرق بين مقارنة النقرات وتكرار الظل هو أنه في الحالة الأولى ، تتم مقارنة الاستجابة التي تم إرجاعها بواسطة الإصدار الذي تم
إصداره مع الاستجابة التي تم إرجاعها بواسطة الإصدار
المنشور ، وفي الحالة الثانية ، يتم تكرار الطلب إلى الإصدار
المنشور في وضع عدم الاتصال مثل إطلاق النار والنسيان.
أداة أخرى للعمل في هذا المجال هي مكتبة
العلماء المتاحة على GitHub. وقد تم تصميم هذه الأداة لاختبار التعليمات البرمجية في روبي، ولكن تم طرحه في وقت لاحق إلى
عدة لغات أخرى . وهو مفيد لبعض أنواع الاختبار ، ولكن به عدد من المشاكل التي لم يتم حلها. إليك ما كتبه مطور GitHub في مجتمع Slack محترف:
"تقوم هذه الأداة ببساطة بتنفيذ فرعين من التعليمات البرمجية وتقارن النتائج. يجب أن تكون حذرا مع رمز هذه الفروع. من الضروري التأكد من عدم تكرار استعلامات قاعدة البيانات إذا أدى ذلك إلى مشاكل. أعتقد أن هذا لا ينطبق فقط على العالم ، ولكن أيضًا على أي موقف تفعل فيه شيئًا مرتين ، ثم تقارن النتائج. تم إنشاء أداة العلماء للتحقق من أن نظام الإذن الجديد يعمل بنفس الطريقة التي يعمل بها النظام القديم ، وفي أوقات معينة تم استخدامه لمقارنة البيانات النموذجية لكل طلب ريلز تقريبًا. أعتقد أن العملية ستستغرق المزيد من الوقت ، حيث يتم تنفيذ المعالجة بالتسلسل ، ولكن هذه مشكلة روبي حيث لا يتم استخدام الخيوط.
في معظم الحالات المعروفة لي ، تم استخدام أداة العلماء للعمل مع عمليات القراءة بدلاً من الكتابة ، على سبيل المثال ، لمعرفة ما إذا كانت الاستعلامات المحسنة الجديدة ومخططات الأذونات تتلقى نفس الإجابة مثل تلك القديمة. يتم تشغيل كلا الخيارين في بيئة إنتاج (على النسخ المتماثلة). إذا كانت الموارد المختبرة لها آثار جانبية ، أعتقد أنه يجب إجراء الاختبار على مستوى التطبيق. "Diffy هي أداة Scala مكتوبة مفتوحة المصدر مقدمة من Twitter في 2015. من المحتمل
أن مقالة من مدونة Twitter بعنوان
اختبار بدون كتابة اختبارات هي أفضل مورد لفهم كيفية عمل مقارنات النقر في الممارسة.
"يكتشف Diffy الأخطاء المحتملة في الخدمة من خلال إطلاق إصدار جديد وقديم من الشفرة في نفس الوقت. تعمل هذه الأداة كخادم وكيل وترسل جميع الطلبات المستلمة إلى كل مثيل قيد التشغيل. ثم يقارن ردود الحالات ويذكر جميع الانحرافات التي تم العثور عليها أثناء المقارنة. يعتمد Diffy على الفكرة التالية: إذا أعاد تنفيذان لخدمة نفس الإجابات مع مجموعة كبيرة ومتنوعة من الطلبات ، فيمكن اعتبار هذين التنفيذين متساويين ، وأحدثهما دون تدهور في الأداء. تقنية ديفي المبتكرة للحد من الضوضاء تميزها عن أدوات تحليل الانحدار المقارن الأخرى ".تعتبر مقارنة النقر رائعة عندما تحتاج إلى التحقق مما إذا كان إصداران يعطيان نفس النتائج. وفقًا لمارك ماكبرايد ،
"كانت أداة Diffy تستخدم غالبًا في إعادة تصميم الأنظمة. في حالتنا ، قمنا بتقسيم قاعدة شفرة مصدر Rails إلى العديد من الخدمات التي تم إنشاؤها باستخدام Scala ، واستخدم عدد كبير من عملاء API وظائف مختلفة عما كنا نتوقعه. وظائف مثل تنسيق التاريخ كانت خطيرة بشكل خاص ".مقارنة النقرات ليست الخيار الأفضل لاختبار نشاط المستخدم أو هوية سلوك نسختين من الخدمة عند أقصى حمل. كما هو الحال مع تكرار الظل ، تظل الآثار الجانبية مشكلة لم يتم حلها ، خاصة عندما يكتب كل من الإصدار المنشور ونسخة الإنتاج البيانات إلى نفس قاعدة البيانات. كما هو الحال مع اختبار التكامل ، تتمثل إحدى الطرق للتغلب على هذه المشكلة في استخدام اختبارات مقارنة النقر مع مجموعة محدودة فقط من الحسابات.
اختبار الحمل
بالنسبة لأولئك الذين ليسوا على دراية باختبار الضغط ، يمكن أن تكون
هذه المقالة نقطة بداية جيدة. لا يوجد نقص في الأدوات والمنصات لاختبار الحمل المفتوح المصدر. الأكثر شيوعًا منهم
Apache Bench ،
Gatling ،
wrk2 ،
Tsung ، المكتوبة في Erlang ،
Siege ،
Iago من Twitter ، المكتوبة بلغة Scala (التي
تعيد إنتاج سجلات خادم HTTP ، أو خادم وكيل أو محلل حزم الشبكة في مثيل اختبار). يعتقد بعض الخبراء أن أفضل أداة لتوليد الحمل هي
mzbench ، والتي تدعم مجموعة متنوعة من البروتوكولات ، بما في ذلك MySQL ، Postgres ، Cassandra ، MongoDB ، TCP ، إلخ.
NDBench من Netflix هو أداة أخرى مفتوحة المصدر لمستودعات بيانات اختبار الحمل. ، الذي يدعم معظم البروتوكولات المعروفة.
تصف مدونة تويتر الرسمية
Iago بمزيد من التفصيل الميزات التي يجب أن يكون لها مولد تحميل جيد:
"عدم عرقلة طلبات ولدت في وتيرة محددة سلفا على أساس التوزيع الإحصائي الداخلي قابل للتعديل (الافتراضي غرار عملية بواسون ). يمكن تغيير تكرار الطلبات حسب الحاجة ، على سبيل المثال ، لإعداد ذاكرة التخزين المؤقت قبل العمل عند التحميل الكامل.
بشكل عام ، ينصب التركيز على تكرار الطلبات وفقًا لقانون ليتل ، وليس على عدد المستخدمين المتزامنين ، والذي يمكن أن يختلف اعتمادًا على مقدار التأخير المتأصل في هذه الخدمة. ونتيجة لذلك ، تظهر فرص جديدة لمقارنة نتائج العديد من الاختبارات ومنع التدهور في الخدمة ، مما يبطئ تشغيل مولد الحمل.
بمعنى آخر ، تسعى أداة Iago إلى محاكاة نظام يتم فيه تلقي الطلبات بغض النظر عن قدرة خدمتك على معالجتها. في هذا ، يختلف عن مولدات الحمل التي تحاكي الأنظمة المغلقة التي سيعمل فيها المستخدمون بصبر مع التأخير الحالي. هذا الاختلاف يسمح لنا بأن نمثل بدقة أنماط الفشل التي يمكن مواجهتها في الإنتاج ".نوع آخر من اختبار الحمل هو اختبار الإجهاد بإعادة توزيع تدفق البيانات. جوهرها هو كما يلي: يتم توجيه التدفق الكامل للبيانات من بيئة الإنتاج إلى مجموعة أصغر من المجموعة المعدة للخدمة ؛ إذا كانت هناك مشاكل ، يتم نقل دفق البيانات إلى الكتلة أكبر. يتم استخدام هذه التقنية من قبل Facebook ، كما هو موضح في إحدى
المقالات على مدونتها الرسمية :
"إننا نعيد تحديدًا تدفق أكبر للبيانات إلى مجموعات أو عُقد فردية ، ونقيس استهلاك الموارد في هذه العقد ونحدد حدود استقرار الخدمة. هذا النوع من الاختبار ، على وجه الخصوص ، مفيد لتحديد موارد وحدة المعالجة المركزية اللازمة لدعم الحد الأقصى لعدد عمليات البث المتزامنة لـ Facebook Live. "إليك ما يكتبه مهندس سابق في LinkedIn في مجتمع Slack المحترف:
"استخدمت LinkedIn أيضًا اختبارات الخط الأحمر في الإنتاج - تمت إزالة الخوادم من موازن التحميل حتى وصل الحمل إلى قيم الحد الأدنى أو بدأت تحدث الأخطاء."في الواقع ، يوفر بحث Google رابطًا إلى
ورقة بيضاء كاملة ومقال مدونة LinkedIn حول هذا الموضوع:
"يستخدم حل Redliner للقياسات دفق بيانات حقيقي لبيئة الإنتاج ، والذي يتجنب الأخطاء التي تمنع القياسات الدقيقة للأداء في المختبر.
يقوم Redliner بإعادة توجيه جزء من دفق البيانات إلى الخدمة قيد الاختبار ويحلل أداءه في الوقت الفعلي. تم تطبيق هذا الحل في مئات من خدمات LinkedIn الداخلية ويستخدم يوميًا لأنواع مختلفة من تحليل الأداء.
Redliner يدعم تنفيذ اختبار موازي لحالات الكناري والإنتاج. يسمح هذا للمهندسين بنقل نفس كمية البيانات إلى مثيلين خدمة مختلفين: 1) مثيل خدمة يحتوي على ابتكارات ، مثل التكوينات الجديدة أو الخصائص أو التعليمات البرمجية الجديدة ؛ 2) مثيل خدمة لإصدار العمل الحالي."تؤخذ نتائج اختبار الحمل في الاعتبار عند اتخاذ القرارات وتساعد على منع نشر الرمز ، مما قد يؤدي إلى ضعف الأداء."أخذ Facebook اختبار الحمل باستخدام تدفقات البيانات الحقيقية إلى مستوى جديد تمامًا بفضل نظام Kraken ، كما يستحق
وصفه القراءة.
يتم تنفيذ الاختبار عن طريق إعادة توزيع دفق البيانات عند تغيير قيم الوزن (اقرأ من مخزن التكوين الموزع) للأجهزة والمجموعات في تكوين
Proxygen (موازن تحميل Facebook). تحدد هذه القيم حجم البيانات الحقيقية المرسلة ، على التوالي ، إلى كل مجموعة ومنطقة في نقطة وجود معينة.
بيانات من ورقة كراكن البيضاءيعرض نظام المراقبة (
Gorilla ) مؤشرات للخدمات المختلفة (كما هو موضح في الجدول أعلاه). بناءً على بيانات المراقبة والعتبات ، يتم اتخاذ قرار بشأن إرسال البيانات بشكل أكبر وفقًا لقيم الوزن ، أو ما إذا كان من الضروري تقليل أو حتى إيقاف نقل البيانات تمامًا إلى مجموعة معينة.
اختبارات التكوين
جعلت موجة جديدة من أدوات البنية التحتية مفتوحة المصدر التقاط جميع التغييرات في البنية التحتية في شكل رمز ليس ممكناً فحسب ، بل أيضاً
سهل نسبياً. لقد أصبح من الممكن أيضًا بدرجات متفاوتة
اختبار هذه التغييرات ، على الرغم من أن معظم اختبارات البنية التحتية ككود في مرحلة ما قبل الإنتاج يمكن أن تؤكد فقط المواصفات والنحو الصحيحين.
في هذه الحالة، رفض لاختبار التكوين الجديد قبل أن يصبح
الافراج عن رمز سبب
عددا كبيرا من انقطاع التيار .
للاختبار الشامل لتغييرات التكوين ، من المهم التمييز بين أنواع التكوينات المختلفة. اقترح فريد هيبرت مرة واحدة استخدام الربع التالي:
هذا الخيار ، بطبيعة الحال ، ليس عالميًا ، لكن هذا التمييز يسمح لك بتحديد أفضل طريقة لاختبار كل من التكوينات وفي أي مرحلة للقيام بذلك. تكوين وقت البناء أمر منطقي إذا كان بإمكانك ضمان التكرار الحقيقي للتجميعات. ليست كل التكوينات ثابتة ، ولكن لا مفر من التغيير الديناميكي في التكوين على الأنظمة الأساسية الحديثة (حتى إذا كنا نتعامل مع "بنية تحتية دائمة").
, , blue-green , . (
Jamie Wilkinson ), Google ,
:
« , , , - . . - , — , , . ., . , , — ».Facebook :
« . — , . . , .
. Facebook , . , .
(, JSON). , . .
(, Facebook Thrift) . , .
, , - . . — A/B-, 1 % . A/B-, . A/B- . , , , , . , A/B- . , A/B-. Facebook .
, A/B- 1% , 1% , ( « »). , . , .
Facebook . , . , , . , , .- إلغاء بسيط ومريح للتغييرات
في بعض الحالات ، على الرغم من جميع التدابير الوقائية ، يتم نشر التكوين غير العملي. يعد العثور على التغييرات واسترجاعها سريعًا أمرًا بالغ الأهمية لمعالجة هذه المشكلة. "تتوفر أدوات التحكم في الإصدار في نظام التهيئة الخاص بنا ، مما يسهل التراجع عن التغييرات."
يتبع!محدث: تابع هنا .