اکنون مبحث DevOps بر سر زبان ها افتاده است. خط لوله یکپارچه سازی و تحویل مستمر CI / CD همه در حال اجرای آن هستند. اما اکثر آنها همیشه توجه لازم را به اطمینان از قابلیت اطمینان سیستم های اطلاعاتی در مراحل مختلف خط لوله CI/CD نمی دهند. در این مقاله می‌خواهم در مورد تجربه‌ام در اتوماسیون بررسی‌های کیفیت نرم‌افزار و اجرای سناریوهای احتمالی برای «خوددرمانی» آن صحبت کنم.

منبع

من به عنوان مهندس در بخش مدیریت خدمات فناوری اطلاعات یک شرکت کار می کنم "LANIT-ادغام". زمینه اصلی تخصص من پیاده سازی سیستم های نظارت بر عملکرد و در دسترس بودن برنامه های مختلف است. من اغلب با مشتریان IT از بخش های مختلف بازار در رابطه با مسائل جاری در مورد نظارت بر کیفیت خدمات فناوری اطلاعات آنها ارتباط برقرار می کنم. هدف اصلی به حداقل رساندن زمان چرخه انتشار و افزایش دفعات انتشار است. البته همه اینها خوب است: نسخه های بیشتر - ویژگی های جدید بیشتر - کاربران راضی تر - سود بیشتر. اما در واقعیت، همه چیز همیشه خوب پیش نمی رود. با نرخ های بسیار بالا استقرار، بلافاصله این سوال در مورد کیفیت نسخه های ما مطرح می شود. حتی با وجود یک خط لوله کاملاً خودکار، یکی از بزرگترین چالش ها انتقال خدمات از آزمایش به تولید بدون تأثیر بر زمان آپدیت برنامه و تجربه کاربر است.

بر اساس نتایج گفتگوهای متعدد با مشتریان، می توانم بگویم که کنترل کیفیت انتشار، مشکل قابلیت اطمینان برنامه و امکان "خود ترمیم" آن (به عنوان مثال، بازگشت به نسخه پایدار) در مراحل مختلف CI / خط لوله CD از جمله موضوعات هیجان انگیز و مرتبط هستند.

اخیراً من خودم در سمت مشتری کار کردم - در سرویس پشتیبانی نرم افزار برنامه بانکداری آنلاین. معماری برنامه ما از تعداد زیادی ریزسرویس خودنویس استفاده می‌کرد. غم انگیزترین چیز این است که همه توسعه دهندگان نتوانستند با سرعت بالای توسعه کنار بیایند؛ کیفیت برخی از میکروسرویس ها آسیب دید که باعث ایجاد نام مستعار خنده دار برای آنها و سازندگان آنها شد. داستان هایی در مورد اینکه این محصولات از چه موادی ساخته شده بودند وجود داشت.

"تدوین مسئله"

فرکانس بالای انتشار و تعداد زیاد میکروسرویس ها، درک عملکرد برنامه را به عنوان یک کل، هم در مرحله آزمایش و هم در مرحله عملیاتی، دشوار می کند. تغییرات به طور مداوم رخ می دهد و کنترل آنها بدون ابزارهای نظارتی خوب بسیار دشوار است. اغلب، پس از انتشار شبانه در صبح، توسعه‌دهندگان مانند روی یک بشکه باروت می‌نشینند و منتظر می‌مانند تا چیزی شکسته نشود، اگرچه همه بررسی‌ها در مرحله آزمایش موفقیت‌آمیز بودند.

یه نکته دیگه هم هست در مرحله آزمایش، عملکرد نرم افزار بررسی می شود: اجرای عملکردهای اصلی برنامه و عدم وجود خطا. ارزیابی عملکرد کیفی یا وجود ندارد یا تمام جنبه های برنامه و لایه یکپارچه سازی را در نظر نمی گیرد. برخی از معیارها ممکن است اصلا بررسی نشوند. در نتیجه، هنگامی که خرابی در یک محیط تولید رخ می دهد، بخش پشتیبانی فنی تنها زمانی متوجه آن می شود که کاربران واقعی شروع به شکایت کنند. من می خواهم تأثیر نرم افزارهای با کیفیت پایین را بر کاربران نهایی به حداقل برسانم.

یکی از راه حل ها پیاده سازی فرآیندهایی برای بررسی کیفیت نرم افزار در مراحل مختلف خط لوله CI/CD و افزودن سناریوهای مختلف برای بازیابی سیستم در مواقع اضطراری است. ما همچنین به یاد داریم که DevOps داریم. کسب و کارها انتظار دارند محصول جدید را در سریع ترین زمان ممکن دریافت کنند. بنابراین، تمام چک ها و اسکریپت های ما باید خودکار باشند.

وظیفه به دو بخش تقسیم می شود:

• کنترل کیفیت مجموعه ها در مرحله آزمایش (برای خودکار کردن فرآیند گرفتن مجموعه های با کیفیت پایین).
• کنترل کیفیت نرم افزار در محیط تولید (مکانیسم هایی برای تشخیص خودکار مشکلات و سناریوهای احتمالی برای خوددرمانی آنها).

ابزاری برای نظارت و جمع آوری معیارها

برای دستیابی به اهداف تعیین شده، یک سیستم نظارتی مورد نیاز است که بتواند مشکلات را شناسایی و به سیستم های اتوماسیون در مراحل مختلف خط لوله CI/CD منتقل کند. همچنین اگر این سیستم معیارهای مفیدی را برای تیم های مختلف ارائه دهد: توسعه، آزمایش، عملیات، نکته مثبتی خواهد بود. و اگر برای تجارت نیز باشد، کاملاً فوق العاده است.

برای جمع آوری معیارها، می توانید از مجموعه ای از سیستم های مختلف (Prometheus، ELK Stack، Zabbix و غیره) استفاده کنید، اما به نظر من، راه حل های کلاس APM برای این کارها مناسب هستند (نظارت بر عملکرد برنامه) که می تواند زندگی شما را بسیار ساده کند.

به عنوان بخشی از کارم در سرویس پشتیبانی، شروع به انجام پروژه مشابهی با استفاده از راه حل کلاس APM از Dynatrace کردم. اکنون که برای یک ادغام کننده کار می کنم، بازار سیستم های مانیتورینگ را به خوبی می شناسم. نظر ذهنی من: Dynatrace بهترین گزینه برای حل چنین مشکلاتی است.
Dynatrace یک نمای افقی از هر عملیات کاربر را در سطح دانه ای تا سطح اجرای کد ارائه می دهد. می‌توانید کل زنجیره تعامل بین سرویس‌های اطلاعاتی مختلف را ردیابی کنید: از سطوح جلویی برنامه‌های وب و تلفن همراه، سرورهای برنامه کاربردی، گذرگاه یکپارچه‌سازی تا یک تماس خاص با پایگاه داده.

منبع. ساخت خودکار تمام وابستگی ها بین اجزای سیستم

منبع. تشخیص خودکار و ساخت مسیر عملیات سرویس

همچنین به یاد داریم که باید با ابزارهای مختلف اتوماسیون یکپارچه شویم. در اینجا راه حل دارای یک API مناسب است که به شما امکان ارسال و دریافت معیارها و رویدادهای مختلف را می دهد.

در ادامه، بیایید به بررسی دقیق‌تر نحوه حل این مشکلات با استفاده از سیستم Dynatrace بپردازیم.

وظیفه 1. اتوماسیون کنترل کیفیت مجموعه ها در مرحله آزمایش

اولین چالش این است که مشکلات را در اسرع وقت در خط لوله تحویل برنامه پیدا کنید. فقط بیلدهای کد "خوب" باید به تولید برسند. برای انجام این کار، خط لوله شما در مرحله آزمایش باید شامل مانیتورهای اضافی برای بررسی کیفیت خدمات شما باشد.

بیایید نگاهی گام به گام به نحوه پیاده سازی این و خودکارسازی این فرآیند بیندازیم:

منبع

شکل جریان مراحل تست کیفیت خودکار نرم افزار را نشان می دهد:

1. استقرار یک سیستم نظارت (نصب عوامل)؛
2. شناسایی رویدادها برای ارزیابی کیفیت نرم افزار شما (معیارها و مقادیر آستانه) و انتقال آنها به سیستم نظارت.
3. تولید تست های بار و عملکرد؛
4. جمع آوری داده های عملکرد و در دسترس بودن در سیستم نظارت؛
5. انتقال داده های آزمون بر اساس رویدادهای ارزیابی کیفیت نرم افزار از سیستم نظارت به سیستم CI/CD. تجزیه و تحلیل خودکار مجموعه ها

مرحله 1. استقرار سیستم نظارت

ابتدا باید Agent ها را در محیط تست خود نصب کنید. در عین حال، راه حل Dynatrace دارای یک ویژگی خوب است - از عامل جهانی OneAgent استفاده می کند که بر روی یک نمونه سیستم عامل (ویندوز، لینوکس، 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
    }
  ]
}

فایل آرایه ای از تعاریف سری زمانی است:

• timeseriesId – معیاری که بررسی می شود، به عنوان مثال، زمان پاسخ، تعداد خطا، حافظه استفاده شده و غیره؛  
• تجمع - سطح تجمیع معیارها، در مورد ما میانگین، اما می‌توانید از هر موردی که نیاز دارید استفاده کنید (متوسط، حداقل، حداکثر، مجموع، تعداد، صدک).
• برچسب ها - برچسب شی در سیستم نظارت، یا می توانید یک شناسه شی خاص را مشخص کنید.
• شدید و هشدار دهنده - این شاخص ها مقادیر آستانه معیارهای ما را تنظیم می کنند؛ اگر مقدار آزمایش از آستانه شدید فراتر رود، ساخت ما به عنوان ناموفق علامت گذاری می شود.

شکل زیر نمونه ای از استفاده از چنین آستانه هایی را نشان می دهد.

منبع

مرحله 3: تولید بار

هنگامی که سطوح کیفیت خدمات خود را مشخص کردیم، باید یک بار آزمایشی تولید کنیم. می توانید از هر یک از ابزارهای آزمایشی که با آن راحت هستید مانند Jmeter، Selenium، Neotys، Gatling و غیره استفاده کنید.

سیستم مانیتورینگ Dynatrace به شما این امکان را می‌دهد که متادیتاهای مختلف را از آزمایش‌های خود دریافت کنید و تشخیص دهید که کدام تست‌ها به کدام چرخه انتشار و کدام سرویس تعلق دارند. توصیه می شود به درخواست های تست HTTP سرصفحه های اضافی اضافه کنید.

شکل زیر نمونه‌ای را نشان می‌دهد که در آن، با استفاده از هدر اضافی X-Dynatrace-Test، نشان می‌دهیم که این تست به آزمایش عملیات افزودن یک کالا به سبد خرید مربوط می‌شود.

منبع

هنگامی که هر تست بارگیری را اجرا می کنید، اطلاعات متنی اضافی را با استفاده از Event API از سرور CI/CD به Dynatrace ارسال می کنید. به این ترتیب سیستم می تواند بین تست های مختلف تفاوت قائل شود.

منبع. رویداد در سیستم مانیتورینگ در مورد شروع آزمایش بار

مرحله 4-5. جمع آوری داده های عملکرد و انتقال داده ها به سیستم CI/CD

همراه با آزمایش تولید شده، رویدادی در مورد نیاز به جمع آوری داده ها در مورد بررسی شاخص های کیفیت خدمات به سیستم نظارت منتقل می شود. همچنین فایل JSON ما را که معیارهای کلیدی را تعریف می کند، مشخص می کند.

رویدادی در مورد نیاز به بررسی کیفیت نرم افزار تولید شده روی سرور CI/CD برای ارسال به سیستم مانیتورینگ

در مثال ما، رویداد بررسی کیفیت نامیده می شود perfSigDynatraceReport (عملکرد_امضا) - این آماده است افزونه برای ادغام با جنکینز، که توسط بچه های T-Systems Multimedia Solutions توسعه داده شد. هر رویداد راه اندازی آزمایشی حاوی اطلاعاتی در مورد سرویس، شماره ساخت و زمان آزمایش است. این افزونه مقادیر عملکرد را در زمان ساخت جمع آوری می کند، آنها را ارزیابی می کند و نتیجه را با ساخت های قبلی و الزامات غیر کاربردی مقایسه می کند.

رویدادی در سیستم مانیتورینگ درباره شروع بررسی کیفیت ساخت. منبع

پس از اتمام تست، تمام معیارهای ارزیابی کیفیت نرم افزار به یک سیستم یکپارچه سازی پیوسته، به عنوان مثال، جنکینز، که گزارشی از نتایج تولید می کند، بازگردانده می شود.

نتیجه آمار مجموعه ها در سرور CI/CD. منبع

برای هر ساخت مجزا، آماری را برای هر معیاری که در کل آزمایش تنظیم می‌کنیم، می‌بینیم. همچنین مشاهده می‌کنیم که آیا در مقادیر آستانه خاصی (هشدار و آستانه‌های شدید) نقض شده است. بر اساس معیارهای کلی، کل ساخت به عنوان پایدار، ناپایدار یا ناموفق علامت‌گذاری می‌شود. همچنین، برای راحتی، می توانید شاخص هایی را به گزارش مقایسه ساخت فعلی با نسخه قبلی اضافه کنید.

مشاهده آمار دقیق مجموعه ها در سرور CI/CD. منبع

مقایسه دقیق دو مجموعه

در صورت لزوم می توانید به رابط Dynatrace بروید و در آنجا آمار هر یک از بیلدهای خود را با جزئیات بیشتری مشاهده کنید و آنها را با یکدیگر مقایسه کنید.

مقایسه آمار ساخت در Dynatrace. منبع
 
یافته ها

در نتیجه، ما یک سرویس "نظارت به عنوان یک سرویس" را دریافت می کنیم که در خط لوله یکپارچه سازی پیوسته خودکار می شود. توسعه‌دهنده یا آزمایش‌کننده فقط باید فهرستی از معیارها را در یک فایل JSON تعریف کند و بقیه موارد به‌طور خودکار اتفاق می‌افتد. ما کنترل کیفیت شفاف انتشارات را دریافت می کنیم: همه اعلان ها در مورد عملکرد، مصرف منابع یا رگرسیون های معماری.

وظیفه 2. اتوماسیون کنترل کیفیت نرم افزار در یک محیط تولید

بنابراین، ما مشکل چگونگی خودکارسازی فرآیند نظارت در مرحله آزمایش در Pipeline را حل کرده ایم. به این ترتیب درصد مجموعه های بی کیفیتی که به محیط تولید می رسند را به حداقل می رسانیم.

اما اگر نرم افزار بد در نهایت فروخته شد یا چیزی خراب شد، چه باید کرد. برای یک مدینه فاضله، ما مکانیزم هایی را می خواستیم که به طور خودکار مشکلات را شناسایی کنند و در صورت امکان، خود سیستم عملکرد خود را حداقل در شب بازیابی کند.

برای انجام این کار، به قیاس با بخش قبل، نیاز داریم تا بررسی های خودکار کیفیت نرم افزار را در محیط تولید فراهم کنیم و آنها را بر اساس سناریوهایی برای خودترمیمی سیستم قرار دهیم.

تصحیح خودکار به عنوان کد

اکثر شرکت ها در حال حاضر یک پایگاه دانش انباشته از انواع مختلف مشکلات رایج و لیستی از اقدامات برای رفع آنها دارند، به عنوان مثال، راه اندازی مجدد فرآیندها، پاک کردن منابع، بازگرداندن نسخه ها، بازگرداندن تغییرات پیکربندی نامعتبر، افزایش یا کاهش تعداد مؤلفه ها در خوشه، تغییر طرح کلی آبی یا سبز و غیره.

در حالی که این موارد استفاده سال‌ها توسط بسیاری از تیم‌هایی که من با آنها صحبت می‌کنم شناخته شده‌اند، تعداد کمی از آنها به خودکارسازی آنها فکر کرده‌اند یا روی آنها سرمایه‌گذاری کرده‌اند.

اگر در مورد آن فکر کنید، هیچ چیز بیش از حد پیچیده ای در پیاده سازی فرآیندهای عملکرد برنامه خود ترمیم وجود ندارد؛ شما باید سناریوهای کاری از قبل شناخته شده مدیران خود را در قالب اسکریپت های کد ارائه دهید (مفهوم "اصلاح خودکار به عنوان کد") ، که از قبل برای هر مورد خاص نوشته اید. هدف اسکریپت های تعمیر خودکار باید از بین بردن علت اصلی مشکل باشد. شما خودتان اقدامات صحیح برای پاسخ به یک حادثه را تعیین می کنید.

هر معیاری از سیستم مانیتورینگ شما می تواند به عنوان محرکی برای راه اندازی اسکریپت عمل کند، نکته اصلی این است که این معیارها به طور دقیق تعیین می کنند که همه چیز بد است، زیرا نمی خواهید در یک محیط سازنده به نتایج مثبت کاذب دست پیدا کنید.

شما می توانید از هر سیستم یا مجموعه ای از سیستم ها استفاده کنید: Prometheus، ELK Stack، Zabbix و غیره. اما من چند مثال بر اساس یک راه حل APM ارائه می کنم (Dynatrace دوباره یک مثال خواهد بود) که به آسان تر کردن زندگی شما نیز کمک می کند.

اولاً، همه چیز مربوط به عملکرد از نظر عملکرد برنامه وجود دارد. این راه حل صدها معیار را در سطوح مختلف ارائه می دهد که می توانید از آنها به عنوان محرک استفاده کنید:

• سطح کاربر (مرورگرها، برنامه های کاربردی تلفن همراه، دستگاه های اینترنت اشیا، رفتار کاربر، تبدیل و غیره)؛
• سطح خدمات و عملیات (عملکرد، در دسترس بودن، خطاها و غیره)؛
• سطح زیرساخت برنامه (معیارهای سیستم عامل میزبان، JMX، MQ، وب سرور و غیره)؛
• سطح پلت فرم (مجازی سازی، ابر، کانتینر و غیره).

سطوح نظارت در Dynatrace. منبع

ثانیا، همانطور که قبلاً گفتم، Dynatrace یک API باز دارد که ادغام با سیستم های شخص ثالث مختلف را بسیار آسان می کند. به عنوان مثال، ارسال یک اعلان به سیستم اتوماسیون زمانی که پارامترهای کنترلی بیش از حد مجاز است.

در زیر مثالی برای تعامل با Ansible آورده شده است.

منبع

در زیر چند نمونه از این که چه نوع اتوماسیونی را می توان انجام داد، خواهم آورد. این تنها بخشی از موارد است؛ فهرست آنها در محیط شما تنها با تخیل شما و قابلیت های ابزار نظارت شما محدود می شود.

1. استقرار بد - بازگشت نسخه

حتی اگر همه چیز را به خوبی در یک محیط آزمایشی آزمایش کنیم، باز هم این احتمال وجود دارد که نسخه جدید بتواند برنامه شما را در محیط تولید از بین ببرد. همان عامل انسانی لغو نشده است.

در شکل زیر مشاهده می کنیم که یک جهش شدید در زمان اجرای عملیات روی سرویس وجود دارد. شروع این پرش مصادف با زمان استقرار به برنامه است. ما تمام این اطلاعات را به عنوان رویداد به سیستم اتوماسیون منتقل می کنیم. اگر عملکرد سرویس پس از زمانی که تنظیم کردیم به حالت عادی برنگردد، به طور خودکار یک اسکریپت فراخوانی می شود که نسخه را به نسخه قبلی برمی گرداند.

کاهش عملکرد عملیات پس از استقرار. منبع

2. بارگیری منبع در 100٪ - یک گره به مسیریابی اضافه کنید

در مثال زیر، سیستم مانیتورینگ تعیین می کند که یکی از اجزای 100٪ بار CPU را تجربه می کند.

بار CPU 100%
 
چندین سناریو مختلف برای این رویداد ممکن است. به عنوان مثال، سیستم نظارت علاوه بر این بررسی می کند که آیا کمبود منابع با افزایش بار روی سرویس مرتبط است یا خیر. اگر چنین است، یک اسکریپت اجرا می شود که به طور خودکار یک گره به مسیریابی اضافه می کند، در نتیجه عملکرد سیستم به عنوان یک کل بازیابی می شود.

پوسته پوسته شدن بعد از یک حادثه

3. کمبود فضای روی هارد - تمیز کردن دیسک

من فکر می کنم که بسیاری از افراد قبلاً این فرآیندها را خودکار کرده اند. با استفاده از APM، می توانید فضای آزاد روی زیرسیستم دیسک را نیز نظارت کنید. اگر فضای خالی وجود ندارد یا دیسک به کندی کار می کند، یک اسکریپت را فراخوانی می کنیم تا آن را پاک کرده یا فضا اضافه کنیم.

بار دیسک 100٪
 
4. فعالیت کم کاربر یا تبدیل کم - جابجایی بین شاخه های آبی و سبز

من اغلب مشتریانی را می بینم که از دو حلقه (استقرار سبز-آبی) برای برنامه های کاربردی در یک محیط تولید استفاده می کنند. این به شما امکان می دهد هنگام ارائه نسخه های جدید به سرعت بین شاخه ها جابجا شوید. اغلب، پس از استقرار، تغییرات چشمگیری ممکن است رخ دهد که بلافاصله قابل توجه نیستند. در این حالت، کاهش عملکرد و در دسترس بودن ممکن است مشاهده نشود. برای پاسخ سریع به چنین تغییراتی، بهتر است از معیارهای مختلفی استفاده کنید که رفتار کاربر را منعکس می کند (تعداد جلسات و اقدامات کاربر، تبدیل، نرخ پرش). شکل زیر نمونه ای را نشان می دهد که در آن هنگام کاهش نرخ تبدیل، جابجایی بین شاخه های نرم افزار اتفاق می افتد.

نرخ تبدیل پس از جابجایی بین شاخه های نرم افزار کاهش می یابد. منبع

مکانیسم هایی برای تشخیص خودکار مشکل

در نهایت، من یک مثال دیگر برای شما می‌آورم که چرا Dynatrace را بیشتر دوست دارم.

در بخشی از داستان من در مورد خودکارسازی بررسی کیفیت مجموعه ها در یک محیط آزمایشی، ما تمام مقادیر آستانه را به صورت دستی تعیین کردیم. این برای یک محیط آزمایشی طبیعی است؛ آزمایشگر خود نشانگرها را قبل از هر آزمایش بسته به بار تعیین می کند. در یک محیط تولید، مطلوب است که مشکلات به طور خودکار با در نظر گرفتن مکانیسم های مختلف پایه شناسایی شوند.

Dynatrace دارای ابزارهای هوش مصنوعی داخلی جالبی است که بر اساس مکانیسم هایی برای تعیین معیارهای غیرعادی (پایه بندی) و ساختن نقشه تعامل بین همه مؤلفه ها، مقایسه و همبستگی رویدادها با یکدیگر، ناهنجاری ها را در عملکرد سرویس شما تعیین می کند و جزئیات را ارائه می دهد. اطلاعات در مورد هر مشکل و علت اصلی.

با تجزیه و تحلیل خودکار وابستگی‌ها بین مؤلفه‌ها، Dynatrace نه تنها علت اصلی بودن سرویس مشکل‌زا، بلکه وابستگی آن به سایر سرویس‌ها را نیز تعیین می‌کند. در مثال زیر، Dynatrace به طور خودکار سلامت هر سرویس را در اجرای تراکنش بررسی و ارزیابی می کند و سرویس Golang را به عنوان علت اصلی شناسایی می کند.

نمونه ای از تعیین علت اصلی یک شکست. منبع

شکل زیر روند نظارت بر مشکلات برنامه شما را از شروع یک حادثه نشان می دهد.

تجسم یک مشکل در حال ظهور با نمایش تمام اجزا و رویدادها روی آنها

سیستم مانیتورینگ یک گاهشماری کامل از وقایع مربوط به مشکل ایجاد شده را جمع آوری کرد. در پنجره زیر جدول زمانی، همه رویدادهای کلیدی هر یک از مؤلفه ها را می بینیم. بر اساس این رویدادها، می توانید رویه هایی را برای تصحیح خودکار در قالب اسکریپت های کد تنظیم کنید.

علاوه بر این، من به شما توصیه می کنم که یک سیستم نظارتی را با Service Desk یا یک ردیاب اشکال ادغام کنید. هنگامی که مشکلی رخ می دهد، توسعه دهندگان به سرعت اطلاعات کاملی را برای تجزیه و تحلیل آن در سطح کد در محیط تولید دریافت می کنند.

نتیجه

در نتیجه، ما به یک خط لوله CI/CD با بررسی های کیفی خودکار نرم افزار داخلی در Pipeline رسیدیم. ما تعداد مجموعه‌های با کیفیت پایین را به حداقل می‌رسانیم، قابلیت اطمینان سیستم را به طور کلی افزایش می‌دهیم، و اگر سیستم ما همچنان از کار بیفتد، مکانیسم‌هایی را برای بازیابی آن راه‌اندازی می‌کنیم.

مطمئناً ارزش سرمایه گذاری برای خودکارسازی نظارت بر کیفیت نرم افزار را دارد؛ این همیشه یک فرآیند سریع نیست، اما به مرور زمان نتیجه خواهد داد. توصیه می کنم پس از حل یک اتفاق جدید در محیط تولید، بلافاصله به این فکر کنید که چه مانیتورهایی را برای بررسی در محیط تست اضافه کنید تا از ورود بیلد بد به مرحله تولید جلوگیری شود و همچنین یک اسکریپت برای اصلاح خودکار این مشکلات ایجاد کنید.

امیدوارم نمونه های من به شما در تلاش شما کمک کند. من همچنین علاقه مند خواهم بود نمونه های شما را از معیارهای مورد استفاده برای پیاده سازی سیستم های خوددرمانی ببینم.

منبع

منبع: www.habr.com