الآن موضوع DevOps هو الضجيج. التكامل المستمر وخط أنابيب التسليم CI / CD تنفيذ كل ومتنوعة. لكن معظمهم لا يهتم دائمًا بضمان موثوقية أنظمة المعلومات في مراحل مختلفة من خط أنابيب CI / CD. في هذه المقالة ، أود أن أتحدث عن تجربتي في أتمتة عمليات فحص جودة البرامج وتنفيذ السيناريوهات المحتملة لـ "الشفاء الذاتي".

مصدر

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

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

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

"صياغة المشكلة"

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

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

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

تنقسم المهمة إلى قسمين:

• مراقبة جودة التجميعات في مرحلة الاختبار (لأتمتة عملية اصطياد التجميعات منخفضة الجودة) ؛
• مراقبة جودة البرمجيات في بيئة الإنتاج (آليات الكشف التلقائي عن المشاكل والسيناريوهات المحتملة للشفاء الذاتي لها).

أداة لرصد وجمع المقاييس

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

لجمع المقاييس ، يمكنك استخدام مجموعة من الأنظمة المختلفة (Prometheus و ELK Stack و Zabbix وما إلى ذلك) ، ولكن ، في رأيي ، فإن حلول فئة APM هي الأنسب لهذه المهام (مراقبة أداء التطبيق) ، والتي يمكن أن تبسط حياتك بشكل كبير.

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

مصدر. البناء التلقائي لجميع التبعيات بين مكونات النظام

مصدر. الكشف الآلي وإنشاء مسار تشغيل الخدمة

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

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

المهمة 1. أتمتة مراقبة جودة التجميعات في مرحلة الاختبار

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

دعنا نفكر خطوة بخطوة في كيفية تنفيذ ذلك وأتمتة هذه العملية:

مصدر

يوضح الشكل تدفق خطوات ضمان جودة البرامج المؤتمتة:

1. نشر نظام مراقبة (تركيب وكلاء) ؛
2. تحديد الأحداث لتقييم جودة برنامجك (المقاييس والعتبات) ونقلها إلى نظام المراقبة ؛
3. توليد اختبارات الحمل والأداء ؛
4. جمع البيانات عن الأداء والتوافر في نظام المراقبة ؛
5. نقل بيانات الاختبار بناءً على أحداث تقييم جودة البرامج من نظام المراقبة إلى نظام CI / CD. التحليل الآلي للتجميعات.

الخطوة الأولى: نشر نظام المراقبة

تحتاج أولاً إلى تثبيت العوامل في بيئة الاختبار الخاصة بك. في الوقت نفسه ، يتمتع حل Dynatrace بميزة رائعة - فهو يستخدم العامل العالمي OneAgent ، المثبت على مثيل نظام التشغيل (Windows و Linux و AIX) ، ويكتشف تلقائيًا خدماتك ويبدأ في جمع بيانات المراقبة عليها. لا تحتاج إلى تكوين وكيل لكل عملية على حدة. سيكون الوضع مشابهًا للمنصات السحابية والحاويات. في نفس الوقت ، يمكنك أيضًا أتمتة عملية تثبيت الوكلاء. Dynatrace يتناسب تمامًا مع مفهوم "البنية التحتية كرمز" (البنية التحتية كرمز أو IaC): توجد نصوص وإرشادات جاهزة لجميع المنصات الشائعة. تقوم بتضمين الوكيل في تكوين الخدمة ، وعندما تقوم بنشره ، تحصل على الفور على خدمة جديدة مع وكيل قيد التشغيل بالفعل.

الخطوة 2. تحديد أحداث تقييم جودة البرامج الخاصة بك

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

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

من أجل الأتمتة وسهولة الاستخدام من قبل فريق DevOps ، بدأ مفهوم "المراقبة ككود" في الظهور. ما أعنيه بهذا هو أن المطور / المختبِر يمكنه كتابة ملف JSON بسيط يحدد مقاييس ضمان الجودة للبرنامج.

لنلقِ نظرة على مثال لملف JSON. يتم استخدام الكائنات من Dynatrace API كزوج مفتاح / قيمة (يمكن العثور على وصف API هنا Dynatrace API).

{
    "timeseries": [
    {
      "timeseriesId": "service.ResponseTime",
      "aggregation": "avg",
      "tags": "Frontend",
      "severe": 250000,
      "warning": 1000000
    },
    {
      "timeseriesId": "service.ResponseTime ",
      "aggregation": "avg",
      "tags": "Backend",
      "severe": 4000000,
      "warning": 8000000
    },
    {
      "timeseriesId": "docker.Container.Cpu",
      "aggregation": "avg",
      "severe": 50,
      "warning": 70
    }
  ]
}

الملف عبارة عن مجموعة من تعريفات السلاسل الزمنية (سلاسل زمنية):

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

يوضح الشكل التالي مثالاً على استخدام مثل هذه القمامة.

مصدر

الخطوة 3. توليد الحمل

بعد أن حددنا مستويات جودة خدمتنا ، نحتاج إلى إنشاء حمل تجريبي. يمكنك استخدام أي من أدوات الاختبار المناسبة لك ، مثل Jmeter و Selenium و Neotys و Gatling وما إلى ذلك.

يسمح لك نظام مراقبة Dynatrace بالتقاط بيانات وصفية مختلفة من اختباراتك والتعرف على الاختبار الذي ينتمي إلى دورة الإصدار وأي خدمة. يوصى بإضافة رؤوس إضافية لاختبار طلبات HTTP.

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

مصدر

عند تشغيل كل اختبار تحميل ، فإنك ترسل معلومات سياقية إضافية إلى Dynatrace باستخدام واجهة برمجة تطبيقات الحدث من خادم CI / CD. وبالتالي ، يمكن للنظام التمييز بين الاختبارات المختلفة.

مصدر. حدث في نظام المراقبة حول إطلاق اختبار الحمل

الخطوة 4-5. التقاط بيانات الأداء ونقل البيانات إلى نظام CI / CD

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

حدث حول الحاجة إلى التحقق من جودة البرنامج الذي تم إنشاؤه على خادم CI / CD لإرساله إلى نظام المراقبة

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

حدث في نظام المراقبة حول بدء فحص جودة البناء. مصدر

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

نتيجة إحصائيات البناء على خادم CI / CD. مصدر

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

عرض إحصائيات مفصلة عن البنيات الموجودة على خادم CI / CD. مصدر

مقارنة مفصلة بين بنائين

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

مقارنة بين إحصائيات البناء في Dynatrace. مصدر
 
النتائج

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

المهمة 2. أتمتة مراقبة جودة البرامج في بيئة الإنتاج

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

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

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

التصحيح التلقائي كرمز

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

في حين أن حالات الاستخدام هذه معروفة للعديد من الفرق التي تحدثت إليها منذ سنوات ، إلا أن القليل منهم فكر واستثمر في أتمتة هذه الحالات.

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

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

يمكنك استخدام أي نظام أو مجموعة من الأنظمة: Prometheus و ELK Stack و Zabbix وما إلى ذلك. لكنني سأقدم بعض الأمثلة بناءً على حل APM (مرة أخرى سيكون Dynatrace مثالاً) والذي سيساعد أيضًا في جعل حياتك أسهل.

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

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

مستويات المراقبة في Dynatrace. مصدر

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

يوجد أدناه مثال للتفاعل مع Ansible.

مصدر

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

1. نشر سيء - التراجع عن الإصدار

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

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

تدهور أداء العملية بعد النشر. مصدر

2. تحميل الموارد أقل من 100٪ - أضف عقدة إلى التوجيه

في المثال التالي ، يحدد نظام المراقبة أن أحد المكونات يستخدم وحدة المعالجة المركزية بنسبة 100٪.

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

التحجيم بعد الحادث

3. لا توجد مساحة على القرص الصلب - تنظيف القرص

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

تحميل القرص 100٪
 
4. نشاط مستخدم منخفض أو تحويل منخفض - التبديل بين الفرع الأزرق والأخضر

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

الوقوع في التحويل بعد التبديل بين فروع البرمجيات. مصدر

آليات الكشف التلقائي عن المشكلة

في النهاية سأقدم مثالًا آخر ، والذي أحب Dynatrace أكثر من غيره.

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

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

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

مثال على تحديد السبب الجذري للفشل. مصدر

يوضح الشكل التالي عملية مراقبة المشكلات في تطبيقك منذ بداية الحادث.

تصور المشكلة الناشئة مع عرض كافة المكونات والأحداث عليها

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

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

اختتام

نتيجة لذلك ، لدينا خط أنابيب CI / CD مع فحوصات جودة برامج آلية مضمنة في خط الأنابيب. نقوم بتقليل عدد التجميعات منخفضة الجودة ، وزيادة موثوقية النظام ككل ، وإذا كان لا يزال لدينا عطل في النظام ، فإننا نطلق آليات لاستعادته.

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

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

مصدر

المصدر: www.habr.com