اوس د DevOps موضوع په هایپ کې ده. دوامداره ادغام او تحویلي پایپ لاین CI / CD هرڅوک یې پلي کوي. مګر ډیری تل د CI/CD پایپ لاین په مختلفو مرحلو کې د معلوماتو سیسټمونو اعتبار یقیني کولو ته پاملرنه نه کوي. پدې مقاله کې زه غواړم د سافټویر کیفیت چکونو اتومات کولو او د دې "ځان درملنې" لپاره د ممکنه سناریوګانو پلي کولو کې زما تجربې په اړه وغږیږم.

سرچینه

زه د یوه شرکت د معلوماتي ټکنالوجۍ مدیریت څانګې کې د انجنیر په توګه کار کوم "LANIT - ادغام". زما د تجربې اصلي ساحه د مختلف غوښتنلیک فعالیت او شتون څارنې سیسټمونو پلي کول دي. زه ډیری وختونه د بازار د بیلابیلو برخو څخه د آی ټي پیرودونکو سره د دوی د معلوماتي ټیکنالوژۍ خدماتو کیفیت څارنې په اړه د اوسنیو مسلو په اړه خبرې کوم. اصلي هدف د خوشې کولو دورې وخت کمول او د خوشې کولو فریکوینسي ډیرول دي. دا، البته، ټول ښه دي: ډیر ریلیزونه - نور نوي ځانګړتیاوې - ډیر مطمین کارونکي - ډیرې ګټې. مګر په واقعیت کې، شیان تل ښه کار نه کوي. د خورا لوړ ګمارنې نرخونو سره ، پوښتنه سمدلاسه زموږ د خپرونو کیفیت په اړه راپورته کیږي. حتی د بشپړ اتومات پایپ لاین سره ، یو له لوی ننګونو څخه د خدماتو لیږد له ازموینې څخه تولید ته پرته له دې چې د غوښتنلیک اپټایټ او کارونکي تجربې اغیزه وکړي.

د پیرودونکو سره د ډیری خبرو اترو پایلو پراساس ، زه کولی شم ووایم چې د کیفیت کنټرول خوشې کول ، د غوښتنلیک اعتبار ستونزه او د دې "ځان درملنې" احتمال (د مثال په توګه ، د CI په مختلفو مرحلو کې یو باثباته نسخه ته راستنیدل) /CD پایپ لاین خورا په زړه پوري او اړونده موضوعاتو کې دي.

په دې وروستیو کې، ما پخپله د پیرودونکي اړخ کې کار کړی - د آنلاین بانکي غوښتنلیک سافټویر ملاتړ خدمت کې. زموږ د غوښتنلیک جوړښت د ځان لیکل شوي مایکرو خدماتو لوی شمیر کارولی. د خواشینۍ خبره دا ده چې ټول پراختیا کونکي نشي کولی د پرمختګ لوړ سرعت سره مقابله وکړي؛ د ځینې مایکرو خدماتو کیفیت زیانمن شوی ، کوم چې د دوی او د دوی جوړونکو لپاره مسخره نومونه رامینځته کړي. د دې په اړه کیسې شتون درلود چې دا محصولات له کومو موادو څخه جوړ شوي.

"د ستونزې جوړښت"

د ریلیزونو لوړه فریکونسۍ او د مایکرو خدماتو لوی شمیر دا ستونزمن کوي ​​​​چې د غوښتنلیک عملیات په بشپړ ډول پوه شي ، دواړه د ازموینې مرحله او عملیاتي مرحله کې. بدلونونه په دوامداره توګه واقع کیږي او د څارنې د ښه وسیلو پرته د دوی کنټرول خورا ستونزمن دی. ډیری وختونه ، په سهار کې د شپې خوشې کیدو وروسته ، پراختیا کونکي د پوډر کیګ په څیر ناست وي او د ماتیدو لپاره هیڅ شی ته انتظار نه کوي ، که څه هم ټول چکونه د ازموینې په مرحله کې بریالي وو.

یو بل ټکی هم شته. د ازموینې په مرحله کې، د سافټویر فعالیت چک شوی: د غوښتنلیک اصلي دندو پلي کول او د غلطیو نشتوالی. د کیفیت د فعالیت ارزونه یا ورکه ده یا د غوښتنلیک او ادغام پرت ټول اړخونه په پام کې نه نیسي. ځینې ​​​​میتریکونه ممکن په بشپړ ډول ونه کتل شي. د پایلې په توګه، کله چې د تولید چاپیریال کې خرابوالی واقع کیږي، د تخنیکي مالتړ څانګه یوازې د هغې په اړه پوهیږي کله چې اصلي کاروونکي شکایت پیل کړي. زه غواړم په پای کاروونکو باندې د ټیټ کیفیت سافټویر اغیزه کمه کړم.

یو له حل لارو څخه د CI/CD پایپ لاین په مختلفو مرحلو کې د سافټویر کیفیت چک کولو پروسې پلي کول دي، او د بیړني حالت په صورت کې د سیسټم بیا رغولو لپاره مختلف سناریوګانې اضافه کول دي. موږ دا هم په یاد لرو چې موږ DevOps لرو. سوداګرۍ تمه لري چې ژر تر ژره نوی محصول ترلاسه کړي. له همدې امله، زموږ ټول چکونه او سکریپټونه باید اتومات شي.

دنده په دوو برخو ویشل شوې ده:

• د ازموینې په مرحله کې د مجلسونو کیفیت کنټرول (د ټیټ کیفیت لرونکي مجلسونو نیولو پروسه اتومات کول)؛
• د تولید چاپیریال کې د سافټویر کیفیت کنټرول (د ستونزو اتوماتیک کشف میکانیزمونه او د دوی د ځان درملنې لپاره احتمالي سناریوګانې).

د میټریکونو د څارنې او راټولولو وسیله

د ټاکل شویو اهدافو د ترلاسه کولو لپاره، د څارنې سیسټم ته اړتیا ده چې کولی شي ستونزې کشف کړي او د CI/CD پایپ لاین په مختلفو مرحلو کې د اتوماتیک سیسټمونو ته یې انتقال کړي. دا به هم یو مثبت شی وي که چیرې دا سیسټم د مختلفو ټیمونو لپاره ګټور میټریکونه چمتو کړي: پراختیا، ازموینه، عملیات. او دا بالکل په زړه پوری دی که دا د سوداګرۍ لپاره هم وي.

د میټریکونو راټولولو لپاره ، تاسو کولی شئ د مختلف سیسټمونو سیټ وکاروئ (Prometheus, ELK Stack, Zabbix, etc.)، مګر، زما په اند، د APM ټولګي حلونه د دې دندو لپاره غوره دي (د غوښتنلیک د کړنې څارنه)، کوم چې کولی شي ستاسو ژوند خورا ساده کړي.

د ملاتړ خدمت کې زما د کار د یوې برخې په توګه، ما د Dynatrace څخه د APM ټولګي حل په کارولو سره ورته پروژه پیل کړه. اوس، د ادغام لپاره کار کول، زه د څارنې سیسټم بازار ښه پوهیږم. زما موضوعي نظر: Dynatrace د دې ډول ستونزو د حل لپاره خورا مناسب دی.
Dynatrace د کوډ اجرا کولو کچې ته په دانه کچه کې د هر کارونکي عملیاتو افقی لید وړاندې کوي. تاسو کولی شئ د مختلف معلوماتو خدماتو ترمینځ د متقابل عمل ټوله سلسله تعقیب کړئ: د ویب او ګرځنده غوښتنلیکونو له لومړۍ پای کچې څخه ، د شاته پای غوښتنلیک سرورونه ، ډیټابیس ته ځانګړي تلیفون ته ادغام بس.

سرچینه. د سیسټم اجزاو تر مینځ د ټولو انحصاراتو اتوماتیک جوړښت

سرچینه. د خدماتو عملیاتي لارې اتوماتیک کشف او جوړول

موږ دا هم په یاد لرو چې موږ اړتیا لرو د مختلف اتوماتیک وسیلو سره مدغم کړو. دلته حل یو مناسب API لري چې تاسو ته اجازه درکوي مختلف میټریکونه او پیښې واستوئ او ترلاسه کړئ.

بیا ، راځئ چې د ډینټریس سیسټم په کارولو سره د دې ستونزو حل کولو څرنګوالي په اړه نور تفصيلي لید ته لاړ شو.

دنده 1. د ازموینې په مرحله کې د مجلسونو د کیفیت کنټرول اتومات کول

لومړۍ ننګونه د غوښتنلیک تحویلي پایپ لاین کې ژر تر ژره ستونزې موندل دي. یوازې "ښه" کوډ جوړونه باید تولید ته ورسیږي. د دې کولو لپاره، د ازموینې په مرحله کې ستاسو پایپ لاین باید ستاسو د خدماتو کیفیت چک کولو لپاره اضافي څارونکي شامل کړي.

راځئ چې ګام په ګام وګورو چې دا څنګه پلي کړئ او دا پروسه اتومات کړئ:

سرچینه

ارقام د اتوماتیک سافټویر کیفیت ازموینې مرحلو جریان ښیې:

1. د څارنې سیسټم ځای په ځای کول (د اجنټانو نصب کول)؛
2. ستاسو د سافټویر کیفیت ارزولو لپاره د پیښو پیژندل (میتریک او حد ارزښتونه) او د څارنې سیسټم ته یې لیږدول؛
3. د بار او فعالیت ازموینې نسل؛
4. د څارنې په سیسټم کې د فعالیت او شتون ډاټا راټولول؛
5. د سافټویر کیفیت ارزونې پیښو پراساس د ازموینې ډیټا لیږد د نظارت سیسټم څخه CI/CD سیسټم ته. د مجلسونو اتوماتیک تحلیل.

مرحله 1. د څارنې سیسټم ځای په ځای کول

لومړی تاسو اړتیا لرئ اجنټان ستاسو د ازموینې چاپیریال کې نصب کړئ. په ورته وخت کې، د Dynatrace حل یو ښه ځانګړتیا لري - دا د نړیوال اجنټ OneAgent کاروي، کوم چې په OS مثال (وینډوز، لینکس، 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 - هغه میټریک چې چک کیږي، د بیلګې په توګه، د ځواب وخت، د تېروتنې شمیره، یادداشت کارول، او داسې نور؛  
• Aggregation - د میټریک راټولولو کچه، زموږ په قضیه کې اوسط، مګر تاسو کولی شئ هر هغه کار وکاروئ چې تاسو ورته اړتیا لرئ (اوس، لږترلږه، اعظمي، رقم، شمیره، فیصده)؛
• tags - د څارنې په سیسټم کې د څیز ټاګ، یا تاسو کولی شئ یو ځانګړی څیز پیژندونکی مشخص کړئ؛
• سخت او خبرداری - دا شاخصونه زموږ د میټریکونو حد ارزښتونه تنظیموي؛ که د ازموینې ارزښت له سخت حد څخه ډیر وي، نو زموږ جوړونه د بریالۍ نه په توګه نښه کیږي.

لاندې انځور د دې ډول حدونو کارولو یوه بیلګه ښیي.

سرچینه

3 ګام: د بار تولید

یوځل چې موږ زموږ د خدماتو کیفیت کچه ​​مشخصه کړه ، موږ اړتیا لرو د ازموینې بار تولید کړو. تاسو کولی شئ د ازموینې هر هغه وسیلې وکاروئ چې تاسو ورسره راحته یاست ، لکه Jmeter ، Selenium ، Neotys ، Gatling او داسې نور.

د Dynatrace د څارنې سیسټم تاسو ته اجازه درکوي د خپلو ازموینو څخه مختلف میټاډاټا ونیسئ او دا وپیژندئ چې کومې ازموینې د کوم خوشې کولو دورې او کوم خدمت پورې اړه لري. دا سپارښتنه کیږي چې د HTTP ازموینې غوښتنو ته اضافي سرلیکونه اضافه کړئ.

لاندې شمیره یوه بیلګه ښیې چیرې چې د اضافي سرلیک X-Dynatrace-Test په کارولو سره ، موږ په ګوته کوو چې دا ازموینه په کارټ کې د توکي اضافه کولو عملیاتو ازموینې پورې اړه لري.

سرچینه

کله چې تاسو د هر بار ازموینه پرمخ وړئ، تاسو د CI/CD سرور څخه د Event API په کارولو سره Dynatrace ته اضافي متناسب معلومات لیږئ. په دې توګه، سیسټم کولی شي د مختلفو ازموینو ترمنځ توپیر وکړي.

سرچینه. د بار ازموینې پیل په اړه د څارنې سیسټم کې پیښه

ګام 4-5. د فعالیت ډیټا راټول کړئ او CI/CD سیسټم ته ډیټا لیږدئ

د تولید شوي ازموینې سره یوځای، یوه پیښه د څارنې سیسټم ته لیږدول کیږي چې د خدماتو کیفیت شاخصونو چک کولو په اړه د معلوماتو راټولولو اړتیا په اړه. دا زموږ د JSON فایل هم مشخص کوي، کوم چې کلیدي میترونه تعریفوي.

د څارنې سیسټم ته د لیږلو لپاره په CI/CD سرور کې رامینځته شوي سافټویر کیفیت چیک کولو اړتیا په اړه پیښه

زموږ په مثال کې، د کیفیت چک پیښه ویل کیږي perfSigDynatraceReport (کارکردګي_ننلیک) - دا چمتو دی نښلول د جینکنز سره د ادغام لپاره ، کوم چې د T-Systems ملټي میډیا حلونو څخه د هلکانو لخوا رامینځته شوی. د ازموینې هر لانچ پیښه د خدماتو ، جوړیدو شمیره ، او د ازموینې وخت په اړه معلومات لري. پلگ ان د جوړیدو په وخت کې د فعالیت ارزښتونه راټولوي، ارزونه یې کوي، او پایله یې د پخوانیو ودانیو او غیر فعال غوښتنو سره پرتله کوي.

د څارنې سیسټم کې د جوړونې کیفیت چک پیل کولو په اړه پیښه. سرچینه

وروسته له دې چې ازموینه بشپړه شي، د سافټویر کیفیت ارزولو لپاره ټول میترونه بیرته د دوامداره ادغام سیسټم ته لیږدول کیږي، د بیلګې په توګه، جینکنز، کوم چې د پایلو په اړه راپور چمتو کوي.

په CI/CD سرور کې د مجلسونو د احصایو پایله. سرچینه

د هر فرد جوړونې لپاره، موږ د هر میټریک لپاره احصایې ګورو چې موږ په ټوله ازموینه کې تنظیم کوو. موږ دا هم وګورو چې ایا په ټاکلي حد ارزښتونو کې سرغړونې شتون لري (خبرتیا او سخت فشارونه). د مجموعي میټریکونو پراساس، ټول جوړښت د ثابت، بې ثباته، یا ناکام په توګه نښه شوی. همدارنګه، د اسانتیا لپاره، تاسو کولی شئ په راپور کې شاخصونه اضافه کړئ چې اوسني جوړونه د تیر سره پرتله کړئ.

په CI/CD سرور کې د مجلسونو تفصيلي احصایې وګورئ. سرچینه

د دوو مجلسونو تفصيلي پرتله کول

که اړتیا وي، تاسو کولی شئ د Dynatrace انٹرفیس ته لاړ شئ او هلته تاسو کولی شئ د خپلو هر جوړونو احصایې په ډیر تفصیل سره وګورئ او د یو بل سره پرتله کړئ.

په Dynatrace کې د ودانیو احصایې پرتله کول. سرچینه
 
موندنو

د پایلې په توګه، موږ د "خدمت په توګه د څارنې" خدمت ترلاسه کوو، د دوامداره ادغام پایپ لاین کې اتوماتیک. پراختیا کونکی یا ټیسټر یوازې د JSON فایل کې د میټریکونو لیست تعریف کولو ته اړتیا لري ، او نور هرڅه په اوتومات ډول پیښیږي. موږ د ریلیزونو شفاف کیفیت کنټرول ترلاسه کوو: د فعالیت په اړه ټول خبرتیاوې، د سرچینو مصرف یا معماري راجسټریشن.

دنده 2. د تولید چاپیریال کې د سافټویر کیفیت کنټرول اتومات کول

نو، موږ په پایپ لاین کې د ازموینې په مرحله کې د څارنې پروسې اتومات کولو څرنګوالي ستونزه حل کړې. پدې توګه موږ د ټیټ کیفیت لرونکي مجلسونو سلنه کموو چې د تولید چاپیریال ته رسي.

مګر څه باید وکړو که خراب سافټویر وپلورل شي، یا یو څه مات شي. د یوټوپیا لپاره، موږ غوښتل چې میکانیزمونه په اتوماتيک ډول ستونزې کشف کړي او که امکان ولري، سیسټم پخپله خپل فعالیت بیرته راولي، لږترلږه د شپې.

د دې کولو لپاره ، موږ اړتیا لرو ، د تیرې برخې سره ورته والی سره ، د تولید چاپیریال کې د اتوماتیک سافټویر کیفیت چیک چمتو کولو لپاره او د سیسټم د ځان درملنې لپاره سناریوګانو باندې اساس کول.

د کوډ په توګه اتوماتیک

ډیری شرکتونه دمخه د مختلف ډوله عامو ستونزو په اړه د پوهې راټول شوي اساس لري او د دوی د حل لپاره د کړنو لیست لري ، د بیلګې په توګه ، د پروسې بیا پیل کول ، د سرچینو پاکول ، د نسخو بیرته راګرځول ، د غلط تشکیلاتو بدلونونو بحالول ، د اجزاو شمیر ډیرول یا کمول. کلستر، د نیلي یا شنه نقشې بدلول او داسې نور.

پداسې حال کې چې دا د کارونې قضیې د ډیری ټیمونو لخوا چې زه ورسره خبرې کوم د کلونو لپاره پیژندل شوي، یو څو یې د اتومات کولو په اړه فکر کړی یا یې پانګونه کړې.

که تاسو د دې په اړه فکر کوئ، د ځان شفاهي غوښتنلیک فعالیت لپاره د پروسو پلي کولو کې خورا پیچلي شتون نلري؛ تاسو اړتیا لرئ د کوډ سکریپټونو په بڼه د خپلو مدیرانو دمخه پیژندل شوي کاري سناریوګانې وړاندې کړئ (د "کوډ په توګه د اتوماتیک حل" مفهوم) ، کوم چې تاسو د هرې ځانګړې قضیې لپاره دمخه لیکلي. د اتوماتیک ترمیم سکریپټونه باید د ستونزې اصلي لامل له مینځه ویسي. تاسو پخپله د یوې پیښې ځواب لپاره سم عملونه وټاکئ.

ستاسو د څارنې سیسټم څخه هر میټریک کولی شي د سکریپټ پیل کولو لپاره د محرک په توګه عمل وکړي، اصلي شی دا دی چې دا میټریک په سمه توګه ټاکي چې هرڅه خراب دي، ځکه چې تاسو نه غواړئ په تولیدي چاپیریال کې غلط مثبت ترلاسه کړئ.

تاسو کولی شئ هر سیسټم یا د سیسټمونو سیټ وکاروئ: Prometheus، ELK Stack، Zabbix، او داسې نور. مګر زه به د APM حل پراساس ځینې مثالونه درکړم (ډیناټریس به بیا یو مثال وي) دا به ستاسو د ژوند اسانه کولو کې هم مرسته وکړي.

لومړی، د غوښتنلیک عملیاتو شرایطو کې د فعالیت پورې اړوند هرڅه شتون لري. حل په مختلفو کچو کې سلګونه میټریکونه وړاندې کوي چې تاسو یې د محرک په توګه کارولی شئ:

• د کارونکي کچه (براوزر، ګرځنده غوښتنلیکونه، IoT وسایل، د کاروونکي چلند، تبادله، او نور)؛
• د خدماتو او عملیاتو کچه (کارکردګي، شتون، تېروتنې، او نور)؛
• د غوښتنلیک زیربنا کچه (د کوربه OS میټریک، JMX، MQ، ویب سرور، او نور)؛
• د پلیټ فارم کچه (مجازی کول، بادل، کانټینر، او نور).

په Dynatrace کې د څارنې کچه. سرچینه

دوهم، لکه څنګه چې ما مخکې وویل، Dynatrace یو خلاص API لري، کوم چې د دریمې ډلې سیسټمونو سره یوځای کول خورا اسانه کوي. د مثال په توګه ، د اتوماتیک سیسټم ته د خبرتیا لیږل کله چې د کنټرول پیرامیټرونه تیریږي.

لاندې د ځواب وړ سره د متقابل عمل لپاره یوه بیلګه ده.

سرچینه

لاندې به زه یو څو مثالونه وړاندې کړم چې کوم ډول اتومات کیدی شي. دا یوازې د قضیو یوه برخه ده؛ ستاسو په چاپیریال کې د دوی لیست یوازې ستاسو د تصور او ستاسو د څارنې وسیلو وړتیاو لخوا محدود کیدی شي.

1. خراب ځای پرځای کول – نسخه بیرته راګرځول

حتی که موږ د ازموینې چاپیریال کې هرڅه په ښه توګه و ازموئ ، لاهم یو چانس شتون لري چې نوی خوشې کولی شي ستاسو غوښتنلیک د تولید چاپیریال کې وژني. ورته انساني عامل نه دی منسوخ شوی.

په لاندې شکل کې موږ ګورو چې په خدمت کې د عملیاتو اجرا کولو وخت کې تیز کود شتون لري. د دې کود پیل د غوښتنلیک لپاره د ځای په ځای کولو وخت سره سمون لري. موږ دا ټول معلومات د پیښو په توګه د اتوماتیک سیسټم ته لیږدوو. که چیرې د خدماتو فعالیت د ټاکل شوي وخت څخه وروسته نورمال ته راستون نشي ، نو بیا یو سکریپټ په اوتومات ډول ویل کیږي چې نسخه بیرته زاړه ته واړوي.

د ګمارنې وروسته د عملیاتو فعالیت خرابول. سرچینه

2. په 100٪ کې د سرچینو بار کول - روټینګ ته نوډ اضافه کړئ

په لاندې مثال کې، د څارنې سیسټم ټاکي چې یوه برخه د 100٪ CPU بار تجربه کوي.

د CPU بار 100٪
 
د دې پیښې لپاره ډیری مختلف سناریوګانې شتون لري. د بیلګې په توګه، د څارنې سیسټم اضافي معاینه کوي چې ایا د سرچینو نشتوالی په خدمت کې د بار زیاتوالي سره تړاو لري. که داسې وي ، نو بیا یو سکریپټ اجرا کیږي چې په اتوماتيک ډول روټینګ ته نوډ اضافه کوي ، په دې توګه د سیسټم فعالیت په بشپړ ډول بحالوي.

د پیښې وروسته اندازه کول

3. په هارډ ډرایو کې د ځای نشتوالی - د ډیسک پاکول

زه فکر کوم چې ډیری خلکو دمخه دا پروسې اتومات کړي دي. د APM په کارولو سره ، تاسو کولی شئ د ډیسک فرعي سیسټم کې وړیا ځای هم وڅارئ. که چیرې ځای شتون ونلري یا ډیسک ورو ورو روان وي ، موږ د پاکولو یا ځای اضافه کولو لپاره سکریپټ غږ کوو.

د ډیسک بار 100٪
 
4. د کارونکي ټیټ فعالیت یا ټیټ تبادله - د نیلي او شین څانګو ترمینځ بدلول

زه ډیری وختونه پیرودونکي ګورم چې د تولید چاپیریال کې غوښتنلیکونو لپاره دوه لوپونه (نیلي شنه ځای پرځای کول) کاروي. دا تاسو ته اجازه درکوي په چټکۍ سره د څانګو تر مینځ بدل کړئ کله چې نوي ریلیزونه وړاندې کړئ. ډیری وختونه، د ځای پرځای کولو وروسته، ډراماتیک بدلونونه واقع کیدی شي چې سمدستي د پام وړ نه وي. په دې حالت کې، د فعالیت او شتون کمښت ممکن نه لیدل کیږي. د دې ډول بدلونونو په چټکۍ سره ځواب ویلو لپاره، دا غوره ده چې مختلف میټریکونه وکاروئ چې د کاروونکي چلند منعکس کوي (د غونډو شمیر او د کاروونکي عملونه، د تبادلې، د اچولو کچه). لاندې ارقام یوه بیلګه ښیې چې په هغه کې کله چې د تبادلې نرخ راټیټیږي، د سافټویر څانګو ترمنځ بدلیږي.

د سافټویر څانګو تر مینځ بدلولو وروسته د تبادلې نرخ راټیټیږي. سرچینه

د اتوماتیک ستونزې کشف کولو میکانیزمونه

په نهایت کې ، زه به تاسو ته یو بل مثال درکړم چې ولې زه ډیناټریس خورا خوښوم.

د ازموینې چاپیریال کې د مجلسونو د کیفیت چک اتومات کولو په اړه زما د کیسې په برخه کې ، موږ ټول حد ارزښتونه په لاسي ډول مشخص کړل. دا د ازموینې چاپیریال لپاره نورمال دی؛ ټیسټر پخپله شاخصونه د هرې ازموینې دمخه د بار پورې اړه لري. د تولید چاپیریال کې ، دا مطلوب دی چې ستونزې په اوتومات ډول کشف شي ، د مختلف اساساتو میکانیزمونو په پام کې نیولو سره.

Dynatrace په زړه پورې جوړ شوي مصنوعي استخباراتو وسیلې لري چې د غیر متقابل میټریکونو (بیسلین کولو) ټاکلو میکانیزمونو پراساس او د ټولو اجزاوو ترمینځ د متقابل عمل نقشه رامینځته کوي ، د یو بل سره پیښې پرتله کوي او تړاو لري ، ستاسو د خدماتو په عملیاتو کې ګډوډي ټاکي او توضیحات وړاندې کوي. د هرې ستونزې او اصلي لامل په اړه معلومات.

د اجزاوو تر مینځ د انحصاراتو په اتوماتيک ډول تحلیل کولو سره، Dynatrace نه یوازې دا ټاکي چې آیا د ستونزې خدمت اصلي لامل دی، بلکې په نورو خدماتو پورې تړاو لري. په لاندې مثال کې، Dynatrace په اتوماتيک ډول د لیږد په اجرا کې د هر خدمت روغتیا څارنه او ارزونه کوي، د ګولنګ خدمت د اصلي لامل په توګه پیژني.

د ناکامۍ د اصلي لامل د ټاکلو یوه بیلګه. سرچینه

لاندې ارقام د پیښې له پیل څخه ستاسو د غوښتنلیک سره د څارنې ستونزې ښیي.

د ټولو برخو او پیښو ښودلو سره د راپورته کیدونکي ستونزې لید

د څارنې سیسټم د رامنځته شوې ستونزې په اړه د پیښو بشپړ تاریخ راټول کړ. د مهال ویش لاندې کړکۍ کې موږ د هرې برخې ټولې کلیدي پیښې ګورو. د دې پیښو پراساس، تاسو کولی شئ د کوډ سکریپټونو په بڼه د اتوماتیک سمون لپاره طرزالعملونه تنظیم کړئ.

سربیره پردې ، زه تاسو ته مشوره درکوم چې د څارنې سیسټم د خدماتو میز یا بګ ټریکر سره مدغم کړئ. کله چې ستونزه رامینځته کیږي ، پراختیا کونکي په چټکۍ سره بشپړ معلومات ترلاسه کوي ترڅو دا د تولید چاپیریال کې د کوډ په کچه تحلیل کړي.

پایلې

د پایلې په توګه، موږ په پایپ لاین کې د جوړ شوي اتوماتیک سافټویر کیفیت چکونو سره د CI/CD پایپ لاین سره پای ته ورسیدو. موږ د ټیټ کیفیت لرونکي مجلسونو شمیر کموو، په ټولیز ډول د سیسټم اعتبار ډیروو، او که زموږ سیسټم لاهم ناکام وي، موږ د هغې د بیا رغونې لپاره میکانیزمونه پیل کوو.

دا د سافټویر کیفیت نظارت اتومات کولو کې د پانګوونې هڅو ارزښت لري؛ دا تل یو ګړندی پروسه نه ده ، مګر د وخت په تیریدو سره به میوه ولري. زه وړاندیز کوم چې د تولید چاپیریال کې د یوې نوې پیښې حل کولو وروسته ، تاسو سمدلاسه فکر وکړئ چې د ازموینې چاپیریال کې د چکونو لپاره کوم مانیټرونه اضافه کړئ ترڅو تولید ته د خراب جوړیدو مخه ونیسي ، او د دې ستونزو په اوتومات ډول سمولو لپاره سکریپټ رامینځته کړئ.

زه امید لرم چې زما مثالونه به تاسو سره ستاسو په هڅو کې مرسته وکړي. زه به هم علاقه ولرم چې ستاسو د میټریک مثالونه وګورم چې د ځان درملنې سیسټم پلي کولو لپاره کارول کیږي.

سرچینه

سرچینه: www.habr.com