🤔 ♦️ 🎵 اختبار على همز: نشر الكناري 💙 🆔 🛌🏻

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

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

يعمل Andrey Markelov ، وهو مهندس برمجيات رائد في Infobip ، على تطوير تطبيقات Java في التمويل والاتصالات لمدة 11 عامًا. يقوم بتطوير منتجات مفتوحة المصدر ، ويشارك بنشاط في مجتمع Atlassian ويكتب الإضافات لمنتجات Atlassian. الإنجيلي بروميثيوس ، دوكر ، وريدس.

حول Infobip

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

Infobip البنية التحتية لتكنولوجيا المعلومات بالأرقام:

15 مركز بيانات حول العالم ؛
تشغيل 500 خدمة فريدة ؛
2500 حالة من الخدمات ، وهو أكثر بكثير من الفرق ؛
4.5 تيرابايت من الحركة الشهرية.
4.5 مليار رقم هاتف.

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

إطلاق

الإصدار القياسي معنا يذهب هكذا. على سبيل المثال ، هناك خدمات A و B و C و D و E ، تم تطوير كل منها بواسطة فريق منفصل.

في مرحلة ما ، يقرر فريق الخدمة A نشر إصدار جديد ، ولكن فرق الخدمة B و C و D و E ليست على علم بذلك. هناك خياران لكيفية وصول فريق الخدمة أ.

سيتم تنفيذ إصدار تدريجي: أولاً سيحل محل إصدار واحد ، ثم الثاني.

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

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

إذن ماذا نريد؟

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

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

قضايا النشر

حركة مرور العميل غير متوقعة . من المستحيل التنبؤ بموعد حركة مرور العميل. لا نعرف أين ومتى سيبدأ العملاء حملاتهم - ربما الليلة في الهند ، وغدًا في هونغ كونغ. نظرًا للفارق الزمني الكبير ، لا يضمن النشر حتى الساعة 2 صباحًا عدم معاناة العملاء.

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

الفرق الموزعة . تقع الفرق التي تطور جانب العميل والخلفية في مناطق زمنية مختلفة. وبسبب هذا ، غالبًا ما لا يتفقون فيما بينهم.

لا يمكن تكرار مراكز البيانات على المسرح. هناك 200 رف في مركز بيانات واحد - لتكرار ذلك في وضع الحماية لن يعمل حتى تقريبًا.

أوقات التوقف غير مسموح بها! لدينا مستوى مقبول من إمكانية الوصول (خطأ الميزانية) عندما نعمل 99.99٪ من الوقت ، على سبيل المثال ، والنسب المئوية المتبقية هي "الحق في ارتكاب الأخطاء". من المستحيل تحقيق موثوقية بنسبة 100٪ ، ولكن من المهم مراقبة وقت التوقف عن العمل ووقت التوقف عن العمل باستمرار.

حلول كلاسيكية

اكتب الرمز بدون أخطاء . عندما كنت مطورًا شابًا ، طلب مني المديرون طلبًا للإفراج دون أخطاء ، ولكن هذا ليس ممكنًا دائمًا.

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

اختبار على المسرح . على مدى 3.5 عامًا من عملي في Infobip ، لم أر أبدًا حالة مرحلة تتزامن جزئيًا على الأقل مع الإنتاج.

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

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

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

الإصدارات المتفق عليها . يوفر هذا الخيار عادةً الإدارة: "دعنا نتفق على أنك ستختبر وتضيف إصدارات جديدة كل يوم." هذا لا يعمل: هناك دائمًا فريق ينتظر الجميع أو العكس.

اختبارات الدخان

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

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

الخيار الثاني هو النشر بمكواة إضافية. يقوم الفريق باختباره للإنتاج ، ثم تبديله ، ويعمل كل شيء.

مساوئ اختبارات الدخان:

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

المكافأة الوحيدة هنا هي أنه يمكنك التحقق من الأداء .

إصدارات الكناري

بسبب عيوب اختبارات الدخان ، بدأنا باستخدام إطلاق الكناري.

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

التنفيذ والفروق الدقيقة

كيف قمنا بتنفيذ إصدارات الكناري؟ على سبيل المثال ، ترسل مجموعة من العملاء رسائل من خلال خدمتنا.

يسير النشر على هذا النحو: إزالة عقدة واحدة من تحت الموازن (1) ، وتغيير الإصدار (2) وبدء بعض حركة المرور بشكل منفصل (3).

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

سأعرض بشكل تخطيطي كيف تبدو الخدمات الصغيرة في معظم الحالات.

يوجد Service Discovery وخدمتان أخريان: S1N1 و S2. تقوم الخدمة الأولى (S1N1) بإعلام Service Discovery عند بدء تشغيلها ، ويتذكرها Service Discovery. تقوم الخدمة الثانية التي تحتوي على عقدتين (S2N1 و S2N2) بإعلام Service Discovery عند بدء التشغيل.

الخدمة الثانية للأول تعمل كخادم. يطلب الأول معلومات عن خوادمه من Service Discovery ، وعندما يستلمها ، يبحث عنها ويتحقق منها ("الفحص الصحي"). عندما يتحقق ، سيرسل لهم رسائل.

عندما يريد شخص ما نشر إصدار جديد من الخدمة الثانية ، يخبر Service Discovery أن العقدة الثانية ستكون عقدة كناري: سيتم إرسال حركة مرور أقل إليها ، لأنه سيتم نشرها الآن. نزيل عقدة الكناري من تحت الموازن ولا ترسل الخدمة الأولى حركة مرور إليها.

نقوم بتغيير الإصدار ويعرف Service Discovery أن العقدة الثانية أصبحت الآن كناري - يمكنك إعطاؤها حملاً أقل (5٪). إذا كان كل شيء على ما يرام ، قم بتغيير الإصدار ، وأعد الحمل واعمل على.

لتنفيذ كل هذا ، نحتاج إلى:

موازنة
, , , ;
, , ;
— (deployment pipeline).

هذا هو أول شيء يجب أن نفكر فيه. هناك استراتيجيتان لتحقيق التوازن.

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

يتم تعيين عقدة كناري أثناء عملية النشر . عندما ينتهي النشر ونزيل حالة العقدة الكناري منها ، سيتم استعادة توازن حركة المرور. مع عدد أقل من السيارات ، نحصل على توزيع صادق.

المراقبة

حجر الزاوية لإطلاق الكناري. يجب أن نفهم بالضبط سبب قيامنا بذلك وما هي المقاييس التي نريد جمعها.

أمثلة على المقاييس التي نجمعها من خدماتنا.

, . , . , .
(latency). , .
(throughput).
.
95% .
-: . , , .

أمثلة على المقاييس في أنظمة المراقبة الأكثر شيوعًا.

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

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

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

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

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

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

أدوات

مكدس ELK . يمكنك تنفيذ الكناري باستخدام Elasticsearch - نكتب الأخطاء فيه عند وقوع الأحداث. ببساطة استدعاء API، يمكنك الحصول على أخطاء في أي وقت، ومقارنتها مع القطاعات السابقة: GET /applg/_cunt?q=level:errr.

بروميثيوس. أظهر نفسه جيدا في Infobip. يسمح لك بتنفيذ مقاييس متعددة الأبعاد لأنه يتم استخدام التسميات.

يمكننا استخدام level، instance، service، إلى الجمع بينها في نظام واحد. الوسائل C offsetمتاحة ، على سبيل المثال ، قيمة الأمر قبل أسبوع واحد فقط GET /api/v1/query?query={query}، حيث {query}:

rate(logback_appender_total{ 
    level="error",  
    instance=~"$instance" 
}[5m] offset $offset_value)

تحليل الإصدار

هناك العديد من استراتيجيات الإصدار.

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

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

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

التشغيل الآلي

نريد تحرير المهندسين من المقارنات اليدوية ، لذا من المهم تنفيذ الأتمتة. عادةً ما تبدو عملية خط أنابيب النشر كما يلي:

نحن بدأنا؛
إزالة العقدة من تحت الموازن ؛
تعيين عقدة الكناري.
قم بتشغيل الموازن بالفعل مع كمية محدودة من الحركة ؛
قارن.

عند هذه النقطة ، نقوم بتنفيذ مقارنة تلقائية . كيف يمكن أن تبدو ولماذا هي أفضل من التحقق بعد النشر ، سننظر في المثال من Jenkins.

هذا هو خط الأنابيب إلى Groovy.

while (System.currentTimeMillis() < endCanaryTs) {
    def isOk = compare(srv, canary, time, base, offset, metrics)
    if (isOk) {
        sleep DEFAULT SLEEP
    }   else {
        echo "Canary failed, need to revert"  
        return false
    }
}

هنا في الدورة وضعنا أننا سنقارن العقدة الجديدة لمدة ساعة. إذا لم تنته عملية الكناري من العملية بعد ، فإننا نسميها الوظيفة. وذكرت أن كل شيء على ما يرام أم لا: def isOk = compare(srv, canary, time, base, offset, metrics).

إذا كان كل شيء على ما يرام - sleep DEFAULT SLEEPعلى سبيل المثال ، لمدة ثانية ، واستمر. إذا لم يكن كذلك ، فإننا نخرج - فشل النشر.

وصف المقياس. دعونا نرى كيف قد تبدو دالة compareعلى مثال DSL.

metric(
    'errorCounts',
    'rate(errorCounts{node=~"$canaryInst"}[5m] offset $offset)',
    {   baseValue, canaryValue ->
        if (canaryValue > baseValue * 1.3) return false 
        return true
    }
)

لنفترض أننا قارنا عدد الأخطاء ونريد معرفة عدد الأخطاء في الثانية في الدقائق الخمس الأخيرة.

لدينا قيمتان: العقد القاعدية والكناري. قيمة العقدة الكناري هي الحالية. Basic - baseValueهي قيمة أي عقدة أخرى غير الكناري. نقارن القيم مع بعضها البعض وفقًا للصيغة ، التي نضعها بناءً على خبرتنا وملاحظاتنا. إذا كانت القيمة canaryValueرديئة ، فحينئذٍ فشل النشر ، وسنعيد إلى الوراء.

لماذا كل هذا ضروري؟

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

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

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

العقبات

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

من الضروري التحقق من استقرار المقاييس. يساعد التحقق على فهم الحد الأدنى من مجموعة المقاييس المطلوبة لضمان الجودة .

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

ما الفائدة التي حصلنا عليها من إصدارات الكناري

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

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

النشر الآلي . لم تعد هذه عملية يدوية ، كما كان من قبل ، ولكنها عملية تلقائية حقيقية. لكن الأمر يستغرق وقتًا أطول.

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

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

— TechLead Conf. , , — .

TechLead Conf 8 9 . , , — , .

اختبار على همز: نشر الكناري