في هذا الجزء من المقالة ، سنواصل النظر في أنواع مختلفة من الاختبارات في الإنتاج. أولئك الذين تخطيوا الجزء الأول يمكنهم قراءته
هنا . للبقية - مرحبا بكم في القطط.
اختبار الإنتاج: الإصدار
بعد اختبار الخدمة بعد
النشر ، يجب تحضيرها
للنشر .
من المهم ملاحظة أنه في هذه المرحلة يكون التراجع عن التغييرات ممكنًا فقط في حالات الفشل
المستدام ، على سبيل المثال:
- حلقات فشل الخدمة ؛
- تجاوز وقت الانتظار لعدد كبير من الاتصالات في المنبع ، مما تسبب في زيادة قوية في تكرار الأخطاء ؛
- تغيير التكوين غير المقبول ، على سبيل المثال ، عدم وجود مفتاح سري في متغير بيئة يسبب خللاً في الخدمة (من الأفضل تجنب متغيرات البيئة بشكل عام ، ولكن هذا موضوع لمناقشة أخرى).
يسمح لي الاختبار الشامل في مرحلة
النشر بتقليل المفاجآت غير السارة أو تجنبها تمامًا في مرحلة
الإصدار . ومع ذلك ، هناك عدد من التوصيات لإصدار رمز جديد بأمان.
نشر الكناري
نشر الكناري هو
إصدار جزئي
من خدمة في الإنتاج. مع مرور الفحص الصحي الأساسي ، يتم إرسال الأجزاء الصغيرة من حركة بيئة الإنتاج الحالية إلى الأجزاء المحررة. تتم مراقبة نتائج أجزاء الخدمة أثناء معالجة حركة المرور ، وتتم مقارنة المؤشرات مع المؤشرات المرجعية (غير المتعلقة بالكناري) ، وإذا كانت خارج قيم العتبة المقبولة ، يتم تنفيذ التراجع إلى الحالة السابقة. على الرغم من أن هذا الأسلوب يستخدم عادةً عند إصدار برنامج الخادم ، إلا أن
الاختبار الكناري لبرنامج العميل أصبح أكثر شيوعًا.
تؤثر عوامل مختلفة على حركة المرور التي سيتم استخدامها لنشر الكناري. في عدد من الشركات ، لا تتلقى الأجزاء التي تم إصدارها من الخدمة سوى حركة مرور المستخدم الداخلية أولاً (ما يسمى بتجربة الكلاب). إذا لم تتم ملاحظة أي أخطاء ، فسيتم إضافة جزء صغير من حركة مرور بيئة الإنتاج ، وبعد ذلك يتم تنفيذ النشر الكامل.
يوصى بالرجوع إلى الحالة السابقة في حالة نتائج نشر الكناري غير الصالحة
تلقائيًا ، والأدوات مثل
Spinnaker لها دعم مدمج للتحليل الآلي ووظائف التراجع.
هناك بعض المشاكل في اختبار الكناري ،
وهذه المقالة تقدم نظرة عامة كاملة إلى حد ما عنها.
المراقبة
المراقبة إجراء ضروري للغاية في
كل مرحلة من مراحل نشر المنتج في الإنتاج ، ولكن هذه الوظيفة ستكون مهمة بشكل خاص في مرحلة
الإصدار . تعتبر المراقبة مناسبة تمامًا للحصول على معلومات حول المستوى العام لأداء النظام. لكن مراقبة كل شيء في العالم قد لا يكون الحل الأفضل. يتم تنفيذ المراقبة
الفعالة بشكل نقطي ، مما يسمح لك بتحديد مجموعة صغيرة من أنماط الفشل المستدام للنظام أو مجموعة أساسية من المؤشرات. يمكن أن تكون أمثلة أوضاع الفشل هذه:
- زيادة في معدل الخطأ ؛
- انخفاض في السرعة الإجمالية لمعالجة الطلبات طوال الخدمة ، عند نقطة نهاية محددة ، أو الأسوأ من ذلك ، التوقف التام للعمل ؛
- زيادة التأخير.
ملاحظة أي من أنماط الفشل المستدام هذه هي أساس التراجع الفوري عن حالة سابقة أو التراجع عن الإصدارات الجديدة من البرامج. من المهم أن نتذكر أنه من غير المرجح أن تكون المراقبة في هذه المرحلة كاملة ودلالية. يعتقد الكثيرون أن العدد المثالي للإشارات التي تتم مراقبتها أثناء المراقبة يتراوح من 3 إلى 5 ، ولكن
بالتأكيد ليس أكثر من 7-10. يقدم المستند التقني Kraken Facebook الحل التالي:
"يتم حل المشكلة بمساعدة مكون مراقبة يمكن تكوينه بسهولة ، والذي يتم إبلاغه بمؤشرين أساسيين (النسبة المئوية 99 من وقت استجابة خادم الويب وتكرار حدوث أخطاء HTTP فادحة) التي تصف بشكل موضوعي جودة تفاعل المستخدم."من الأفضل تحديد مجموعة مؤشرات النظام والتطبيق التي تتم مراقبتها أثناء مرحلة التحرير أثناء تصميم النظام.
تتبع الاستثناء
نحن نتحدث عن تتبع الاستثناءات في مرحلة الإصدار ، على الرغم من أنه قد يبدو أنه في مراحل
النشر وبعد الإصدار لن يكون هذا أقل فائدة. غالبًا ما لا تضمن أدوات تتبع الاستثناءات نفس الدقة والدقة والتغطية الجماعية مثل بعض أدوات مراقبة النظام الأخرى ، ولكن لا يزال من الممكن أن تكون مفيدة جدًا.
تعرض الأدوات مفتوحة المصدر (مثل
Sentry ) معلومات متقدمة حول الطلبات الواردة وإنشاء مجموعات من بيانات التتبع والمتغيرات المحلية ، الأمر الذي يبسط إلى حد كبير عملية التصحيح ، والتي تتكون عادةً من عرض سجلات الأحداث. يُعد تتبع الاستثناءات مفيدًا أيضًا عند فرز المشاكل وتحديد أولوياتها التي لا تتطلب التراجع الكامل إلى حالة سابقة (على سبيل المثال ، حالة خطية تثير استثناء).
تشكيل حركة المرور
إن تشكيل حركة المرور (إعادة توزيع حركة المرور) ليس شكلًا مستقلاً من الاختبارات بقدر ما هو أداة لدعم نهج الكناري والإفراج المرحلي عن رمز جديد. في الواقع ، يتم ضمان تشكيل حركة المرور عن طريق تحديث تكوين موازن التحميل ، والذي يسمح لك بإعادة توجيه المزيد من حركة المرور تدريجيًا إلى الإصدار الجديد الذي تم
إصداره .
هذه الطريقة مفيدة أيضًا للنشر التدريجي للبرامج الجديدة (منفصلة عن النشر المنتظم). تأمل في مثال. احتاجت Imgix إلى نشر بنية تحتية جديدة بشكل أساسي في يونيو 2016. بعد الاختبار الأول للبنية التحتية الجديدة مع قدر معين من حركة المرور المظلمة ، بدأوا في الانتشار في الإنتاج ، وأعادوا في البداية توجيه حوالي 1 ٪ من حركة مرور بيئة الإنتاج إلى مكدس جديد. ثم ، على مدار عدة أسابيع ، تم زيادة حجم البيانات التي تصل إلى المكدس الجديد (حل المشكلات على طول الطريق) ، حتى بدأت في معالجة 100٪ من حركة المرور.
أثارت شعبية بنية شبكة الخدمة طفرة جديدة في الاهتمام بالخوادم الوكيلة. ونتيجة لذلك ، أضاف كل من الوكيل القديم (nginx و HAProxy) والوكيل الجديد (Envoy، Conduit) دعمًا للوظائف الجديدة في محاولة لتجاوز المنافسين. يبدو لي أن المستقبل ، الذي يتم فيه إعادة توزيع حركة المرور من 0 إلى 100٪ في مرحلة إصدار المنتج تلقائيًا ، على الأبواب.
اختبار الإنتاج: بعد الإصدار
يتم إجراء اختبار ما بعد الإصدار باعتباره فحصًا يتم إجراؤه
بعد الإصدار الناجح للكود. في هذه المرحلة ، يمكنك التأكد من صحة الشفرة ككل ، وقد تم
إصدارها بنجاح في الإنتاج ومعالجة حركة المرور بشكل صحيح. يتم استخدام الرمز المنشور بشكل مباشر أو غير مباشر في ظروف حقيقية ، أو خدمة عملاء حقيقيين أو أداء مهام لها تأثير كبير على الأعمال.
الهدف من أي اختبار في هذه المرحلة هو التحقق بشكل أساسي من قابلية تشغيل النظام ، مع مراعاة مختلف الأحمال المحتملة وأنماط حركة المرور. أفضل طريقة للقيام بذلك هي جمع أدلة وثائقية على كل ما يحدث في الإنتاج واستخدامه في تصحيح الأخطاء والحصول على صورة كاملة للنظام.
ميزة الإبلاغ ، أو التشغيل المظلم
أقدم منشور حول الاستخدام الناجح لعلامات الميزات التي وجدتها تم نشره قبل حوالي عشر سنوات. يوفر
Virtureflags.io الدليل الأكثر شمولاً لذلك.
"الإبلاغ عن ميزة هو طريقة يستخدمها المطورون لوضع علامة على وظيفة جديدة باستخدام عبارات if-then ، والتي تتيح المزيد من التحكم في إصدارها. من خلال وضع علامة على وظيفة وعزلها بهذه الطريقة ، يحصل المطور على القدرة على تشغيل هذه الوظيفة وإيقافها بغض النظر عن حالة النشر. وهذا يفصل بشكل فعال تحرير الوظيفة عن نشر الكود. "من خلال وضع علامة على الرمز الجديد ، يمكنك اختبار أدائه وأدائه في الإنتاج حسب الحاجة. يعد الإبلاغ عن الميزة أحد أنواع الاختبارات المقبولة عمومًا في الإنتاج ، وهو معروف جيدًا وغالبًا ما يتم
وصفه في
مصادر مختلفة . حقيقة أن هذه الطريقة يمكن استخدامها في عملية اختبار
نقل قواعد البيانات أو البرمجيات للأنظمة الشخصية هي أقل شهرة.
نادرًا ما يكتب مؤلفو المقالات عن أفضل الطرق لتطوير واستخدام علامات الوظائف. يمكن أن يكون الاستخدام غير المنضبط للأعلام مشكلة خطيرة. يؤدي عدم الانضباط من حيث إزالة العلامات غير المستخدمة بعد فترة محددة أحيانًا إلى حقيقة أنه يجب عليك إجراء مراجعة كاملة وحذف العلامات القديمة المتراكمة على مدى أشهر (إن لم يكن على مدى سنوات) من العمل.
اختبار أ / ب
غالبًا ما
يتم إجراء اختبار A / B كجزء من التحليل التجريبي ولا يعتبر اختبارًا في الإنتاج. لهذا السبب ، لا يتم استخدام اختبارات A / B على نطاق واسع فقط (أحيانًا حتى بطريقة
مشكوك فيها ) ، ولكن يتم
دراستها ووصفها بنشاط (بما في ذلك مقالات حول
ما يحدد بطاقة الأداء الفعالة للتجارب عبر الإنترنت). أقل شيوعًا ، تُستخدم اختبارات A / B لاختبار تكوينات الأجهزة المختلفة أو الأجهزة الافتراضية. غالبًا ما يطلق عليها "الضبط" (على سبيل المثال ، ضبط JVM) ، لكنها لا تصنف على أنها اختبارات أ / ب نموذجية (على الرغم من أنه يمكن اعتبار الضبط كنوع من اختبار أ / ب يتم إجراؤه بنفس المستوى من الدقة عندما يتعلق الأمر بالقياسات) .
السجلات والأحداث والمؤشرات والتعقب
يمكنك
أن تقرأ عن ما يسمى ب "الحيتان الثلاثة للرصد" - السجلات والمؤشرات والتتبع الموزع
هنا .
التنميط
في بعض الحالات ، لتشخيص مشاكل الأداء ، من الضروري استخدام ملف تعريف التطبيق في الإنتاج. اعتمادًا على اللغات وأوقات التشغيل المدعومة ، يمكن أن يكون التنميط إجراءً بسيطًا إلى حد ما ، والذي يتضمن إضافة سطر واحد فقط من التعليمات البرمجية إلى التطبيق (
import _ "net/http/pprof" في حالة Go). من ناحية أخرى ، قد يتطلب الأمر استخدام العديد من الأدوات أو اختبار العملية باستخدام طريقة الصندوق الأسود والتحقق من النتائج باستخدام أدوات مثل
flamegraphs .
اختبار الإنطلاق
يعتبر العديد من الأشخاص أن هذا الاختبار هو شيء يشبه الازدواجية للبيانات ، نظرًا لأنه في كلتا الحالتين يتم إرسال حركة مرور بيئة الإنتاج إلى مجموعات أو عمليات غير إنتاجية. في رأيي ، الفرق هو أن استخدام حركة المرور لأغراض
الاختبار يختلف إلى حد ما عن استخدامه لأغراض
التصحيح .
كتبت Etsy على مدونتها حول استخدام اختبارات الإنطلاق كأداة للتحقق (هذا المثال يشبه حقًا تكرار البيانات في الظل).
"هنا يمكن فهم tee على أنه أمر tee في سطر الأوامر. كتبنا قاعدة iRule استنادًا إلى موازن تحميل F5 موجود لاستنساخ حركة مرور HTTP الموجهة إلى أحد التجمعات وإعادة توجيهه إلى تجمع آخر. وبالتالي ، تمكنا من استخدام حركة مرور بيئة الإنتاج الموجهة إلى مجموعة API الخاصة بنا وإرسال نسخة منها إلى مجموعة HHVM التجريبية ، وكذلك إلى مجموعة PHP معزولة للمقارنة.
أثبتت هذه التقنية أنها فعالة للغاية. لقد سمح لنا بمقارنة أداء التكوينين باستخدام ملفات تعريف حركة مرور متطابقة ".ومع ذلك ، في بعض الأحيان يكون اختبار الإنطلاق بناءً على حركة مرور بيئة الإنتاج في نظام مستقل مطلوبًا
لتصحيح الأخطاء . في مثل هذه الحالات ، يمكن تغيير النظام المستقل لتكوين إخراج معلومات تشخيصية إضافية أو إجراء تجميع آخر (على سبيل المثال ، باستخدام أداة تنظيف الدفق) ، مما يبسط إلى حد كبير عملية استكشاف الأخطاء وإصلاحها. في مثل هذه الحالات ، ينبغي النظر في اختبارات الإنطلاق ، بدلاً من ذلك ،
أدوات التصحيح ، بدلاً من
التحقق .
في السابق ، كانت مثل هذه الأنواع من التصحيح نادرة نسبيًا في
imgix ، لكنها كانت لا تزال تستخدم ، خاصة عندما يتعلق الأمر بمشكلات في تطبيقات تصحيح الأخطاء الحساسة للتأخير.
على سبيل المثال ، فيما يلي وصف تحليلي لأحد هذه الحوادث التي وقعت في عام 2015. حدث الخطأ 400 نادرًا جدًا لدرجة أنه لم تتم رؤيته تقريبًا عند محاولة إعادة إنتاج المشكلة. ظهرت في عدد قليل من الحالات من أصل مليار. كان هناك القليل جدا منهم خلال النهار. ونتيجة لذلك ، اتضح أنه من المستحيل ببساطة إعادة إنتاج المشكلة بشكل موثوق ، لذلك كان من الضروري إجراء تصحيح الأخطاء باستخدام حركة مرور العمل من أجل الحصول على فرصة لتتبع حدوث هذا الخطأ. إليك ما كتبه زميلي السابق حول هذا:
"اخترت مكتبة كان من المفترض أن تكون داخلية ، ولكن في النهاية اضطررت إلى إنشاء مكتبتي الخاصة على أساس المكتبة التي يوفرها النظام. في النسخة التي يوفرها النظام ، حدث خطأ دوري لم يظهر بأي شكل من الأشكال بينما كان مقدار حركة المرور صغيرًا. ومع ذلك ، كان الاسم المقتطع في العنوان هو المشكلة الحقيقية.
خلال اليومين التاليين ، درست بالتفصيل المشكلة المرتبطة بتكرار الأخطاء الزائفة 400. وقد ظهر الخطأ في عدد صغير جدًا من الطلبات ، ومن الصعب تشخيص المشكلات من هذا النوع. كل هذا بدا وكأنه إبرة سيئة السمعة في كومة قش: تم مواجهة المشكلة في حالة واحدة لكل مليار.
كانت الخطوة الأولى في تحديد مصدر الأخطاء هي الحصول على جميع بيانات طلب HTTP الأولية التي أدت إلى استجابة غير صحيحة. لإجراء اختبار سريع لحركة المرور الواردة عند الاتصال بمقبس ، أضفت نقطة نهاية مقبس مجال Unix إلى خادم التقديم. كانت الفكرة هي السماح لنا بتشغيل تدفق حركة المرور الداكنة وإيقافه بسرعة وسهولة وإجراء الاختبار مباشرة على جهاز الكمبيوتر الخاص بالمطور. لتجنب مشاكل في الإنتاج ، كان من الضروري قطع الاتصال إذا كانت هناك مشكلة في الضغط الخلفي. على سبيل المثال إذا تعذر على التكرار التعامل مع المهمة ، فقد تم فصلها. كان هذا المقبس مفيدًا جدًا في بعض الحالات أثناء التطوير. ومع ذلك ، استخدمنا هذه المرة لجمع حركة المرور الواردة على الخوادم المحددة ، على أمل الحصول على طلبات كافية للكشف عن النمط الذي أدى إلى ظهور أخطاء خاطئة 400. باستخدام dsh و netcat ، تمكنت من إخراج حركة المرور الواردة إلى ملف محلي بسهولة نسبيًا .
تم إنفاق معظم البيئة في جمع هذه البيانات. بمجرد حصولنا على ما يكفي من البيانات ، تمكنت من استخدام netcat لتشغيله على النظام المحلي ، والذي تم تغيير تكوينه لعرض كمية كبيرة من معلومات التصحيح. وكل شيء سار بشكل مثالي. الخطوة التالية هي تشغيل البيانات بأقصى سرعة ممكنة. في هذه الحالة ، ترسل الحلقة مع فحص الحالة الطلبات الأولية واحدة تلو الأخرى. بعد حوالي ساعتين ، تمكنت من تحقيق النتيجة المرجوة. أظهرت البيانات في السجلات عدم وجود رأس!
أستخدم الخشب الأحمر والأسود لنقل الرؤوس. تعتبر هذه الهياكل إمكانية المقارنة على أنها هوية ، وهي في حد ذاتها مفيدة جدًا عندما تكون هناك متطلبات خاصة للمفاتيح: في حالتنا ، لم تكن رؤوس HTTP حساسة لحالة الأحرف. في البداية اعتقدنا أن المشكلة كانت في العقدة الورقية للمكتبة المستخدمة. يؤثر ترتيب الإضافة حقًا على ترتيب بناء الشجرة الأساسية ، وموازنة الشجرة الحمراء السوداء عملية معقدة إلى حد ما. وعلى الرغم من أن هذا الوضع غير محتمل ، إلا أنه لم يكن مستحيلاً. تحولت إلى تنفيذ آخر من الأبنوس الأحمر. تم إصلاحه قبل عدة سنوات ، لذلك قررت تضمينه مباشرة في المصدر للحصول على النسخة المطلوبة بالضبط. ومع ذلك ، اختار التجميع إصدارًا مختلفًا ، وبما أنني كنت أعتمد على إصدار أحدث ، فقد حصلت على سلوك غير صحيح في النهاية.
وبسبب هذا ، أنتج نظام التصور 500 خطأ ، مما أدى إلى انقطاع الدورة. هذا هو سبب حدوث الخطأ فقط بمرور الوقت. بعد المعالجة الدورية للعديد من التجميعات ، تمت إعادة توجيه حركة المرور منها إلى مسار مختلف ، مما زاد من حجم المشكلة على هذا الخادم. افترضت أن المشكلة كانت في المكتبة تبين أنها خاطئة ، وأن المفتاح العكسي حل 500 خطأ.
عدت إلى 400 خطأ: لا تزال هناك مشكلة في الخطأ ، والتي استغرقت ساعتين تقريبًا للكشف. من الواضح أن تغيير المكتبة لم يحل المشكلة ، لكنني متأكد من أن المكتبة المحددة كانت موثوقة بما فيه الكفاية. لم أدرك مغالطة الاختيار ، لم أغير أي شيء. بعد دراسة الموقف بمزيد من التفصيل ، أدركت أنه تم تخزين القيمة الصحيحة في عنوان أحادي الحرف (على سبيل المثال ، "h: 12345"). لقد ظهر لي أخيراً أن h كانت الشخصية اللاحقة لرأس طول المحتوى. بالنظر إلى البيانات مرة أخرى ، أدركت أن رأس طول المحتوى فارغ.
ونتيجة لذلك ، كان كل شيء خطأ تحيزًا عند قراءة الرؤوس. يقوم محلل HTTP nginx / joyent بإنشاء بيانات جزئية ، وفي كل مرة تحول حقل الرأس الجزئي إلى حرف واحد أقصر من اللازم ، قمت بإرسال الرأس بدون قيمة واستلمت بعد ذلك حقل رأس من حرف واحد يحتوي على القيمة الصحيحة. هذا مزيج نادر إلى حد ما ، لذلك يستغرق تشغيله وقتًا طويلاً. لذلك قمت بزيادة كمية جمع البيانات في كل مرة يظهر فيها رأس من حرف واحد ، وقمت بتطبيق الإصلاح المقترح وتشغيل البرنامج النصي بنجاح لعدة ساعات.
بالطبع ، يمكن اكتشاف بعض العثرات الأخرى مع وجود عطل في المكتبة المذكورة ، ولكن تم إصلاح كلا الخطأين. "
يحتاج المهندسون المشاركون في تطوير التطبيقات الحساسة للتأخير إلى القدرة على تصحيح الأخطاء باستخدام حركة المرور الديناميكية الملتقطة ، لأن الأخطاء غالبًا ما لا يمكن تكرارها أثناء اختبار الوحدة أو اكتشافها باستخدام أداة مراقبة (خاصة إذا كان هناك تأخير خطير في التسجيل).
نهج الهندسة الفوضى
هندسة الفوضى هي نهج يعتمد على التجارب على نظام موزع من أجل تأكيد قدرته على تحمل الظروف الفوضوية لبيئة الإنتاج.أصبحت طريقة هندسة الفوضى ، التي اشتهر بها
قرد الفوضى في Netflix ، الانضباط المستقل. ظهر مصطلح هندسة الفوضى مؤخرًا ، ولكن اختبار الأخطاء هو ممارسة طويلة الأمد.
يشير مصطلح "اختبار الفوضى" إلى التقنيات التالية:
- تعطيل العقد التعسفية لتحديد مدى مقاومة النظام للفشل ؛
- إدخال أخطاء (على سبيل المثال ، زيادة التأخير) من أجل التأكد من أن النظام يعالجها بشكل صحيح ؛
- الانتهاك القسري للشبكة من أجل تحديد استجابة الخدمة.
تستخدم معظم الشركات بيئة تشغيل معقدة وغير كافية لإجراء اختبارات فوضوية بشكل فعال. من المهم التأكيد على أن إدخال الأعطال في النظام هو الأفضل بعد تحديد الوظائف الأساسية لتحمل الخطأ.
تقدم هذه الورقة البيضاء الخاصة بـ Gremlin وصفاً شاملاً إلى حد ما لمبادئ الاختبار الفوضوي ، بالإضافة إلى إرشادات للتحضير لهذا الإجراء.
"من المهم بشكل خاص حقيقة أن هندسة الفوضى تعتبر انضباطًا علميًا. ضمن هذا التخصص ، يتم تطبيق العمليات الهندسية عالية الدقة.
تتمثل مهمة Chaos Engineering في إخبار المستخدمين بشيء جديد حول نقاط الضعف في النظام من خلال إجراء تجارب عليه. من الضروري تحديد جميع المشاكل الخفية التي يمكن أن تنشأ في الإنتاج ، حتى قبل أن تتسبب في فشل كبير. فقط بعد ذلك ستكون قادرًا على التخلص من جميع نقاط الضعف في النظام بشكل فعال وجعله متسامحًا مع الأخطاء حقًا ".الخلاصة
الغرض من الاختبار في الإنتاج ليس
القضاء تمامًا
على جميع الأعطال المحتملة في النظام. يقول
John Allspaw :
" نرى أن الأنظمة أصبحت أكثر قدرة على تحمل الأخطاء - وهذا أمر رائع. ولكن يجب أن نعترف: "المزيد والمزيد" لا يساوي "مطلقًا". في أي نظام معقد ، يمكن أن يحدث الفشل (وسيحدث) بطريقة لا يمكن التنبؤ بها ".
قد يبدو الاختبار في الإنتاج للوهلة الأولى مهمة معقدة نوعًا ما ، تتجاوز بكثير اختصاص معظم الشركات الهندسية. وعلى الرغم من أن هذا الاختبار
ليس بالمهمة
السهلة ، المرتبطة ببعض المخاطر ، إذا اتبعته بكل القواعد ، إلا أنه سيساعد على تحقيق موثوقية الأنظمة الموزعة المعقدة الموجودة في كل مكان اليوم.