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

مصدر

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

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


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

"بيان المشكلة"

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

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

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

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

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

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

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

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

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

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

مصدر . الكشف التلقائي وبناء مسار لعملية الخدمة

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

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

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

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



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

مصدر

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

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

الخطوة 1. نشر نظام المراقبة

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

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

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

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

من أجل التشغيل الآلي وسهولة الاستخدام ، يقدم فريق DevOps مفهوم "المراقبة كرمز". ما أعنيه بهذا هو أن المطور / المختبر يمكنه كتابة ملف JSON بسيط يحدد مؤشرات التحكم في جودة البرنامج.

دعونا نلقي نظرة على مثال لمثل هذا الملف JSON. يتم استخدام كائنات من Dynatrace API كزوج مفتاح / قيمة (انظر Dynatrace API للحصول على وصف 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    }  ] } 

الملف عبارة عن مجموعة من تعريفات timeseries:

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

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

مصدر

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

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

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

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

مصدر

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

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

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

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

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

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

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

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

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

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

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

مقارنة مفصلة بين جمعيتين

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

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

النتائج

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

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

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

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

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


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

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

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

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

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

يمكنك استخدام أي نظام أو مجموعة من الأنظمة: 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 مع اختبارات جودة البرمجيات المدمجة المتكاملة في Pipeline. نعمل على تقليل عدد التجميعات ذات الجودة الرديئة إلى الحد الأدنى ، وزيادة موثوقية النظام ككل ، وإذا كنا لا نزال نعطل أداء النظام ، فإننا نطلق آليات لاستعادته.


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

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

مصدر