هاڻي DevOps جو موضوع hype تي آهي. مسلسل انضمام ۽ پهچائڻ واري پائپ لائن CI/CD هرڪو ان تي عمل ڪري رهيو آهي. پر اڪثر CI/CD پائپ لائن جي مختلف مرحلن تي معلوماتي سسٽم جي اعتبار کي يقيني بڻائڻ تي هميشه ڌيان نه ڏيندا آهن. هن آرٽيڪل ۾ آئون پنهنجي تجربي جي باري ۾ ڳالهائڻ چاهيندس سافٽ ويئر جي معيار جي جانچ کي خودڪار ڪرڻ ۽ ان جي ”خود-شفا“ لاءِ ممڪن منظرنامو لاڳو ڪرڻ.

ذريعو

مان هڪ ڪمپني جي آئي ٽي سروس مئنيجمينٽ ڊپارٽمينٽ ۾ انجنيئر طور ڪم ڪريان ٿو "LANIT-انٽيگريشن". منهنجي مهارت جو بنيادي علائقو مختلف ايپليڪيشن جي ڪارڪردگي ۽ دستيابي مانيٽرنگ سسٽم جو نفاذ آهي. آئون اڪثر ڪري IT گراهڪن سان مختلف مارڪيٽ حصن مان انهن جي آئي ٽي خدمتن جي معيار جي نگراني جي حوالي سان موجوده مسئلن جي حوالي سان ڳالهائيندو آهيان. بنيادي مقصد رليز چڪر جي وقت کي گھٽائڻ ۽ رليز جي تعدد کي وڌائڻ آھي. اهو، يقينا، تمام سٺو آهي: وڌيڪ رليز - وڌيڪ نيون خاصيتون - وڌيڪ مطمئن صارف - وڌيڪ منافعو. پر حقيقت ۾، شيون هميشه سٺو ڪم نه ڪندا آهن. تمام اعلي مقرري جي شرح سان، سوال فوري طور تي پيدا ٿئي ٿو اسان جي رليز جي معيار بابت. ايستائين جو مڪمل طور تي خودڪار پائيپ لائين سان گڏ، سڀ کان وڏو چيلينج سروسز کي جانچ کان وٺي پيداوار ڏانهن منتقل ڪري رهيو آهي بغير ايپليڪيشن اپ ٽائم ۽ صارف جي تجربي کي متاثر ڪرڻ جي.

گراهڪن سان ڪيترن ئي ڳالهين جي نتيجن جي بنياد تي، مان چئي سگهان ٿو ته معيار جي ڪنٽرول کي ڇڏڻ، ايپليڪيشن جي اعتبار جو مسئلو ۽ ان جي "خود-شفا" جو امڪان (مثال طور، هڪ مستحڪم ورزن ڏانهن موٽڻ) CI جي مختلف مرحلن تي. /CD پائپ لائن سڀ کان وڌيڪ دلچسپ ۽ لاڳاپيل عنوانن مان آهن.

تازو، مون پاڻ ڪسٽمر جي پاسي تي ڪم ڪيو - آن لائن بينڪنگ ايپليڪيشن سافٽ ويئر سپورٽ سروس ۾. اسان جي ايپليڪيشن جو فن تعمير وڏي تعداد ۾ خود لکيل مائڪرو سروسز استعمال ڪيو. افسوسناڪ ڳالهه اها آهي ته سڀ ڊولپر ترقيءَ جي تيز رفتار سان مقابلو نه ڪري سگهيا؛ ڪجهه مائڪرو سروسز جي معيار کي نقصان پهتو، جنهن انهن ۽ انهن جي تخليقڪارن لاءِ عجيب لقبن کي جنم ڏنو. اتي ڪهاڻيون هيون ته اهي شيون ڪهڙي مواد مان ٺاهيون ويون آهن.

"مسئلا جي ٺهڻ"

رليز جي اعلي تعدد ۽ مائڪرو سروسز جي وڏي تعداد کي مڪمل طور تي ايپليڪيشن جي آپريشن کي سمجهڻ ڏکيو بڻائي ٿو، ٻنهي ٽيسٽ اسٽيج تي ۽ آپريشنل اسٽيج تي. تبديليون مسلسل ٿينديون آهن ۽ انهن کي ڪنٽرول ڪرڻ تمام ڏکيو هوندو آهي بغير نگراني جي سٺي اوزارن جي. گهڻو ڪري، صبح جو هڪ رات جي ڇڏڻ کان پوء، ڊولپر هڪ پائوڊر ڪيگ وانگر ويهندا آهن ۽ ڪجهه به ڀڃڻ جو انتظار نه ڪندا آهن، جيتوڻيڪ سڀئي چيڪ ٽيسٽ اسٽيج تي ڪامياب ٿي ويا.

ھڪڙو وڌيڪ نقطو آھي. جاچ واري مرحلي ۾، سافٽ ويئر جي ڪارڪردگي جي جانچ ڪئي وئي آهي: ايپليڪيشن جي بنيادي ڪمن تي عملدرآمد ۽ غلطي جي غير موجودگي. قابليت واري ڪارڪردگي جا جائزو يا ته غائب آهن يا نه ٿا وٺن اپليڪيشن جي سڀني پهلوئن ۽ انٽيگريشن پرت کي. ڪجھ ميٽرڪ جي چڪاس نه ٿي سگھي. نتيجي طور، جڏهن پيداوار جي ماحول ۾ خرابي ٿئي ٿي، ٽيڪنيڪل سپورٽ ڊپارٽمينٽ صرف ان جي باري ۾ ڳولي ٿو جڏهن حقيقي صارفين شڪايت ڪرڻ شروع ڪن ٿا. مان آخر استعمال ڪندڙن تي گھٽ معيار واري سافٽ ويئر جي اثر کي گھٽائڻ چاھيندس.

هڪ حل اهو آهي ته CI/CD پائپ لائن جي مختلف مرحلن تي سافٽ ويئر جي معيار کي جانچڻ لاءِ عمل کي لاڳو ڪرڻ، ۽ ايمرجنسي جي صورت ۾ سسٽم کي بحال ڪرڻ لاءِ مختلف منظرنامو شامل ڪرڻ. اسان کي اهو به ياد آهي ته اسان وٽ آهي DevOps. ڪاروبار جلدي ممڪن طور تي نئين پيداوار حاصل ڪرڻ جي اميد رکي ٿو. تنهن ڪري، اسان جا سڀئي چيڪ ۽ اسڪرپٽ خودڪار ٿيڻ گهرجن.

ڪم ٻن حصن ۾ ورهايل آهي:

• ٽيسٽ اسٽيج تي اسيمبلين جو معيار ڪنٽرول (گهٽ معيار جي اسيمبلين کي پڪڙڻ جي عمل کي خودڪار ڪرڻ)؛
• پيداوار جي ماحول ۾ سافٽ ويئر جي معيار تي ضابطو (مکانيزم جي خودڪار طريقي سان ڳولڻ ۽ انهن جي خود علاج لاء ممڪن منظرنامو).

ميٽرڪ جي نگراني ۽ گڏ ڪرڻ جو اوزار

مقرر ڪيل مقصدن کي حاصل ڪرڻ لاء، هڪ مانيٽرنگ سسٽم جي ضرورت آهي جيڪا مسئلن کي ڳولي سگهي ٿي ۽ انهن کي CI/CD پائپ لائن جي مختلف مرحلن تي خودڪار نظام ڏانهن منتقل ڪري سگهي ٿي. اهو پڻ هڪ مثبت شيء آهي جيڪڏهن هي نظام مختلف ٽيمن لاء مفيد ميٽرڪ مهيا ڪري ٿو: ترقي، جاچ، آپريشن. ۽ اھو بلڪل شاندار آھي جيڪڏھن اھو ڪاروبار لاءِ پڻ آھي.

ميٽرڪ گڏ ڪرڻ لاءِ، توهان استعمال ڪري سگهو ٿا مختلف سسٽم جو هڪ سيٽ (Prometheus, ELK Stack, Zabbix, etc.) پر، منهنجي خيال ۾، APM-ڪلاس حل انهن ڪمن لاءِ بهترين آهن (درخواست جي ڪارڪردگي جي نگراني)، جيڪو توهان جي زندگي کي تمام گهڻو آسان بڻائي سگهي ٿو.

سپورٽ سروس ۾ منهنجي ڪم جي حصي جي طور تي، مون Dynatrace کان APM ڪلاس حل استعمال ڪندي ساڳيو منصوبو ڪرڻ شروع ڪيو. هاڻي، هڪ انٽيگريٽر لاء ڪم ڪري رهيو آهيان، مانيٽرنگ سسٽم مارڪيٽ کي چڱي طرح ڄاڻان ٿو. منهنجي تابع راءِ: Dynatrace اهڙين مسئلن کي حل ڪرڻ لاءِ بهترين موزون آهي.
Dynatrace هر صارف جي آپريشن جو افقي منظر مهيا ڪري ٿو گرينولر سطح تي ڪوڊ جي عمل جي سطح تائين. توهان مختلف معلوماتي خدمتن جي وچ ۾ رابطي جي پوري زنجير کي ٽريڪ ڪري سگهو ٿا: ويب ۽ موبائيل ايپليڪيشنن جي فرنٽ-اينڊ ليولز کان، بيڪ-اينڊ ايپليڪيشن سرورز، انٽيگريشن بس هڪ مخصوص ڪال تائين ڊيٽابيس تائين.

ذريعو. سسٽم جي اجزاء جي وچ ۾ سڀني انحصار جي خودڪار تعمير

ذريعو. خودڪار ڳولڻ ۽ خدمت جي آپريشن جي رستي جي تعمير

اسان اهو پڻ ياد رکون ٿا ته اسان کي مختلف خودڪار اوزارن سان گڏ ڪرڻ جي ضرورت آهي. هتي حل هڪ آسان API آهي جيڪو توهان کي مختلف ميٽرڪ ۽ واقعن کي موڪلڻ ۽ وصول ڪرڻ جي اجازت ڏئي ٿو.

اڳيون، اچو ته وڌيڪ تفصيلي نظر تي وڃو ته ڪيئن انهن مسئلن کي حل ڪرڻ لاء Dynatrace سسٽم استعمال ڪندي.

ٽاسڪ 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 - ميٽرڪ چيڪ ڪيو پيو وڃي، مثال طور، جوابي وقت، غلطي جي ڳڻپ، استعمال ٿيل ياداشت، وغيره.  
• مجموعي - ميٽرڪ جي مجموعي جي سطح، اسان جي صورت ۾ اوسط، پر توهان استعمال ڪري سگهو ٿا جيڪو توهان کي گهربل هجي (avg، منٽ، وڌ، رقم، شمار، سيڪڙو)؛
• ٽيگ - مانيٽرنگ سسٽم ۾ اعتراض ٽيگ، يا توهان هڪ مخصوص اعتراض جي سڃاڻپ ڪندڙ بيان ڪري سگهو ٿا؛
• سخت ۽ ڊيڄاريندڙ - اهي اشارا اسان جي ميٽرڪس جي حدن جي قيمتن کي منظم ڪن ٿا؛ جيڪڏهن امتحان جي قيمت سخت حد کان وڌي ٿي، ته پوء اسان جي تعمير کي ڪامياب نه ڪيو ويو آهي.

هيٺ ڏنل انگ اکر ڏيکاري ٿو اهڙي حدن جي استعمال جو هڪ مثال.

ذريعو

قدم 3: لوڊ پيداوار

هڪ دفعو اسان پنهنجي خدمت جي معيار جي سطح کي طئي ڪيو آهي، اسان کي ٽيسٽ لوڊ پيدا ڪرڻ جي ضرورت آهي. توھان استعمال ڪري سگھوٿا ڪو به ٽيسٽنگ اوزار جنھن سان توھان آرام سان آھيو، جھڙوڪ Jmeter، Selenium، Neotys، Gatling، وغيره.

Dynatrace جو مانيٽرنگ سسٽم توهان کي اجازت ڏئي ٿو ته توهان جي ٽيسٽن مان مختلف ميٽا ڊيٽا کي پڪڙي ۽ سڃاڻي ته ڪهڙن ٽيسٽن جو تعلق ڪهڙي رليز چڪر ۽ ڪهڙي خدمت سان آهي. اها سفارش ڪئي وئي آهي ته اضافي هيڊر شامل ڪرڻ لاءِ HTTP ٽيسٽ درخواستون.

هيٺ ڏنل انگ اکر ڏيکاري ٿو هڪ مثال جتي، اضافي هيڊر X-Dynatrace-Test استعمال ڪندي، اسان اهو ظاهر ڪريون ٿا ته هي امتحان ڪارٽ ۾ شيون شامل ڪرڻ جي عمل کي جانچڻ سان لاڳاپيل آهي.

ذريعو

جڏهن توهان هر لوڊ ٽيسٽ کي هلائيندا آهيو، توهان CI/CD سرور کان ايونٽ API استعمال ڪندي Dynatrace ڏانهن اضافي لاڳاپيل معلومات موڪليندا آهيو. هن طريقي سان، سسٽم مختلف تجربن جي وچ ۾ فرق ڪري سگهي ٿو.

ذريعو. لوڊ ٽيسٽ جي شروعات بابت مانيٽرنگ سسٽم ۾ واقعو

قدم 4-5. ڪارڪردگي ڊيٽا گڏ ڪريو ۽ ڊيٽا کي سي آء / سي ڊي سسٽم ڏانهن منتقل ڪريو

ٺاهيل ٽيسٽ سان گڏ، هڪ واقعو نگراني سسٽم ڏانهن منتقل ڪيو ويو آهي ڊيٽا گڏ ڪرڻ جي ضرورت بابت خدمت جي معيار جي اشارن جي جانچ ڪرڻ تي. اهو پڻ وضاحت ڪري ٿو اسان جي JSON فائل، جيڪا وضاحت ڪري ٿي اهم ميٽرڪس.

مانيٽرنگ سسٽم ڏانهن موڪلڻ لاءِ CI/CD سرور تي ٺاهيل سافٽ ويئر جي معيار کي جانچڻ جي ضرورت بابت واقعو

اسان جي مثال ۾، معيار چيڪ واقعي سڏيو ويندو آهي perfSigDynatraceReport (ڪارڪردگي_دستخط) - هي تيار آهي پلگ ان جينڪنز سان انضمام لاءِ، جيڪو T-Systems Multimedia Solutions جي ماڻھن پاران تيار ڪيو ويو آھي. هر ٽيسٽ لانچ ايونٽ ۾ خدمت، تعمير نمبر، ۽ ٽيسٽنگ وقت بابت معلومات شامل آهي. پلگ ان تعمير وقت تي ڪارڪردگي جي قيمتن کي گڏ ڪري ٿو، انهن جو جائزو وٺندو آهي، ۽ نتيجن کي اڳئين تعمير ۽ غير فنڪشنل گهرجن سان مقابلو ڪري ٿو.

مانيٽرنگ سسٽم ۾ واقعو تعمير جي معيار جي جانچ جي شروعات بابت. ذريعو

ٽيسٽ مڪمل ٿيڻ کان پوءِ، سافٽ ويئر جي معيار کي جانچڻ لاءِ سڀئي ميٽرڪ واپس منتقل ڪيا ويندا آهن مسلسل انٽيگريشن سسٽم ۾، مثال طور، جينڪنز، جيڪو نتيجن تي رپورٽ ٺاهي ٿو.

CI/CD سرور تي اسيمبلين تي انگن اکرن جو نتيجو. ذريعو

هر فرد جي تعمير لاءِ، اسان ڏسون ٿا انگ اکر هر ميٽرڪ لاءِ جيڪي اسان پوري ٽيسٽ دوران سيٽ ڪيون ٿا. اسان اهو پڻ ڏسون ٿا ته ڪي خاص حدن جي قيمتن ۾ خلاف ورزيون هيون (خبردار ۽ سخت thrashholds). مجموعي ميٽرڪ جي بنياد تي، سڄي تعمير کي نشان لڳايو ويو آهي مستحڪم، غير مستحڪم، يا ناڪام. انهي سان گڏ، سهولت لاء، توهان رپورٽ ۾ اشارا شامل ڪري سگهو ٿا موجوده تعمير جي مقابلي ۾ اڳئين هڪ سان.

CI/CD سرور تي اسيمبلين تي تفصيلي انگ اکر ڏسو. ذريعو

ٻن اسيمبلين جو تفصيلي مقابلو

جيڪڏهن ضروري هجي ته، توهان وڃي سگهو ٿا Dynatrace انٽرفيس ۽ اتي توهان ڏسي سگهو ٿا انگ اکر توهان جي هر تعمير لاءِ وڌيڪ تفصيل سان ۽ انهن جو هڪ ٻئي سان مقابلو ڪري سگهو ٿا.

Dynatrace ۾ تعميراتي انگ اکر جو مقابلو. ذريعو
 
پهچڻ

نتيجي طور، اسان حاصل ڪندا آهيون "سروس جي طور تي نگراني" سروس، مسلسل انضمام پائپ لائن ۾ خودڪار. ڊولپر يا ٽيسٽر کي صرف JSON فائل ۾ ميٽرڪس جي فهرست جي وضاحت ڪرڻ جي ضرورت آهي، ۽ ٻيو سڀ ڪجهه خودڪار طريقي سان ٿئي ٿو. اسان وصول ڪندا آهيون شفاف معيار جو ڪنٽرول رليز: ڪارڪردگي، وسيلن جي استعمال يا تعميراتي ريگريشن بابت سڀ اطلاع.

ٽاسڪ 2. پيداوار جي ماحول ۾ سافٽ ويئر جي معيار جي ڪنٽرول جي خودڪار

تنهن ڪري، اسان اهو مسئلو حل ڪيو آهي ته پائپ لائن ۾ جاچ واري مرحلي تي نگراني جي عمل کي ڪيئن خودڪار ڪجي. انهي طريقي سان اسان گهٽ معيار جي اسيمبلين جو سيڪڙو گھٽائي سگهون ٿا جيڪي پيداوار جي ماحول تائين پهچن ٿا.

پر ڇا ڪجي جيڪڏهن خراب سافٽ ويئر ختم ٿي وڃي ته وڪرو ٿي وڃي، يا ڪا شيءِ صرف ڀڃي. هڪ يوٽوپيا لاءِ، اسان چاهيون ٿا ته خودڪار طريقي سان مسئلا معلوم ڪن ۽، جيڪڏهن ممڪن هجي، ته سسٽم پاڻ ئي پنهنجي ڪارڪردگيءَ کي بحال ڪري، گهٽ ۾ گهٽ رات جو.

هن کي ڪرڻ لاء، اسان کي ضرورت آهي، پوئين حصي سان قياس ڪندي، پيداوار جي ماحول ۾ خودڪار سافٽ ويئر جي معيار جي چڪاس لاء مهيا ڪرڻ ۽ انهن کي سسٽم جي خود شفا ڏيڻ لاء منظرنامي تي بنياد ڏيڻ.

ڪوڊ جي طور تي خودڪار درست ڪريو

گهڻيون ڪمپنيون اڳ ۾ ئي مختلف قسمن جي عام مسئلن جو گڏ ڪيل ڄاڻ جو بنياد ۽ انهن کي حل ڪرڻ لاءِ ڪارناما جي هڪ فهرست آهي، مثال طور، پروسيس کي ٻيهر شروع ڪرڻ، وسيلن کي صاف ڪرڻ، ورجن کي واپس آڻڻ، غلط ترتيب واري تبديلين کي بحال ڪرڻ، حصن جو تعداد وڌائڻ يا گهٽائڻ. ڪلستر، نيري يا سائي آئوٽ لائن کي تبديل ڪرڻ ۽ وغيره.

جڏهن ته انهن استعمال جا ڪيس ڪيترن ئي ٽيمن جي سالن کان سڃاتا ويا آهن جن سان آئون ڳالهائيندو آهيان، ڪجھ انهن بابت سوچيو آهي يا انهن کي خودڪار ڪرڻ ۾ سيڙپڪاري ڪئي آهي.

جيڪڏهن توهان ان جي باري ۾ سوچيو ٿا، خود شفا ڏيڻ واري ايپليڪيشن جي ڪارڪردگي لاء عملن کي لاڳو ڪرڻ ۾ گهڻو ڪجهه پيچيده ناهي؛ توهان کي توهان جي منتظمين جي اڳ ۾ ئي ڄاڻايل ڪم جي منظرنامن کي ڪوڊ اسڪرپٽ جي صورت ۾ پيش ڪرڻ جي ضرورت آهي ("ڪوڊ جي طور تي خودڪار طريقي سان" تصور) ، جيڪو توهان هر مخصوص ڪيس لاءِ اڳ ۾ لکيو آهي. خودڪار مرمت جي اسڪرپٽ جو مقصد مسئلو جي بنيادي سبب کي ختم ڪرڻ جو مقصد هجڻ گهرجي. توهان پنهنجو پاڻ کي درست ڪارناما جو اندازو لڳايو ته واقعي جو جواب ڏيڻ لاء.

توهان جي مانيٽرنگ سسٽم مان ڪا به ميٽرڪ اسڪرپٽ لانچ ڪرڻ لاءِ ٽرگر طور ڪم ڪري سگهي ٿي، بنيادي ڳالهه اها آهي ته اهي ميٽرڪ صحيح طور تي طئي ڪن ٿا ته هر شيءِ خراب آهي، ڇو ته توهان پيداواري ماحول ۾ غلط مثبت نتيجا حاصل ڪرڻ نٿا چاهيو.

توھان استعمال ڪري سگھوٿا ڪو به سسٽم يا سسٽم جو سيٽ: Prometheus، ELK Stack، Zabbix، وغيره. پر مان ڪجهه مثال ڏيندس APM حل جي بنياد تي (Dynatrace ٻيهر هڪ مثال هوندو) جيڪي توهان جي زندگي کي آسان بڻائڻ ۾ پڻ مدد ڪندا.

سڀ کان پهريان، ايپليڪيشن آپريشن جي لحاظ کان ڪارڪردگي سان لاڳاپيل هر شيء آهي. حل مختلف سطحن تي سوين ميٽرڪ مهيا ڪري ٿو جيڪي توھان استعمال ڪري سگھو ٿا ٽريگرز:

• استعمال ڪندڙ جي سطح (برائوزرز، موبائل ايپليڪيشنون، IoT ڊوائيسز، صارف جي رويي، تبديلي، وغيره)؛
• خدمت ۽ عملن جي سطح (ڪارڪردگي، دستيابي، غلطيون، وغيره)؛
• ايپليڪيشن انفراسٽرڪچر سطح (ميزبان OS ميٽرڪس، JMX، MQ، ويب سرور، وغيره)؛
• پليٽ فارم جي سطح (ورچوئلائيزيشن، بادل، ڪنٽينر، وغيره).

Dynatrace ۾ نگراني جي سطح. ذريعو

ٻيو، جيئن مون اڳ ۾ چيو آهي، Dynatrace وٽ هڪ کليل API آهي، جيڪو مختلف ٽئين پارٽي سسٽم سان ضم ڪرڻ تمام آسان بڻائي ٿو. مثال طور، آٽوميشن سسٽم ڏانهن نوٽيفڪيشن موڪلڻ جڏهن ڪنٽرول پيٽرولر کان وڌي ويا آهن.

هيٺ ڏنل هڪ مثال آهي جوابي سان لهه وچڙ لاءِ.

ذريعو

هيٺ آئون ڪجهه مثال ڏيندس ته ڪهڙي قسم جي آٽوميشن ٿي سگهي ٿي. اهو صرف ڪيسن جو هڪ حصو آهي؛ توهان جي ماحول ۾ انهن جي فهرست صرف توهان جي تخيل ۽ توهان جي نگراني جي اوزار جي صلاحيتن جي ڪري محدود ٿي سگهي ٿي.

1. خراب ترتيب - ورزن رول بيڪ

جيتوڻيڪ اسان امتحان واري ماحول ۾ هر شي کي چڱي طرح جانچيو، اتي اڃا به هڪ موقعو آهي ته هڪ نئين رليز توهان جي ايپليڪيشن کي پيداوار واري ماحول ۾ ماري سگهي ٿي. ساڳئي انساني عنصر کي منسوخ نه ڪيو ويو آهي.

هيٺ ڏنل انگن اکرن ۾ اسان ڏسون ٿا ته سروس تي عملن جي عمل جي وقت ۾ هڪ تيز ٽپو آهي. هن جمپ جي شروعات ايپليڪيشن تي مقرري جي وقت سان ٺهڪي اچي ٿي. اسان هي سڀ معلومات منتقل ڪريون ٿا واقعن جي طور تي خودڪار نظام ڏانهن. جيڪڏهن خدمت جي ڪارڪردگي اسان جي مقرر ڪيل وقت کان پوء معمول تي واپس نه ايندي، پوء هڪ اسڪرپٽ خودڪار طور تي سڏيو ويندو آهي جيڪو واپس ورزن کي پراڻي ڏانهن واپس آڻيندو.

لڳائڻ کان پوءِ آپريشن جي ڪارڪردگيءَ جي خراب ٿيڻ. ذريعو

2. 100٪ تي وسيلن جي لوڊشيڊنگ - روٽنگ ۾ نوڊ شامل ڪريو

هيٺين مثال ۾، مانيٽرنگ سسٽم اهو طئي ڪري ٿو ته اجزاء مان هڪ 100٪ سي پي يو لوڊ تجربو ڪري رهيو آهي.

سي پي يو لوڊ 100٪
 
ھن واقعي لاءِ ڪيترائي مختلف منظرنامو ممڪن آھن. مثال طور، مانيٽرنگ سسٽم اضافي طور تي چيڪ ڪري ٿو ته ڇا وسيلن جي کوٽ جي خدمت تي لوڊ وڌائڻ سان لاڳاپيل آهي. جيڪڏهن ائين آهي، ته پوء هڪ اسڪرپٽ تي عمل ڪيو ويو آهي جيڪو خودڪار طريقي سان روٽنگ ڏانهن هڪ نوڊ شامل ڪري ٿو، انهي سان گڏ سسٽم جي ڪارڪردگي کي بحال ڪري ٿو.

هڪ واقعي کان پوء اسڪيلنگ

3. هارڊ ڊرائيو تي جاء جي کوٽ - ڊسڪ جي صفائي

مان سمجهان ٿو ته ڪيترائي ماڻهو پهريان ئي انهن عملن کي خودڪار ڪري چڪا آهن. APM استعمال ڪندي، توھان پڻ نگراني ڪري سگھوٿا مفت جاءِ ڊسڪ سبسسٽم تي. جيڪڏهن ڪا جاءِ نه آهي يا ڊسڪ آهستي آهستي هلي رهي آهي، اسان ان کي صاف ڪرڻ يا اسپيس شامل ڪرڻ لاءِ اسڪرپٽ سڏين ٿا.

ڊسڪ لوڊ 100٪
 
4. گھٽ استعمال ڪندڙ سرگرمي يا گھٽ تبديلي - نيري ۽ سائي شاخن جي وچ ۾ سوئچنگ

مان اڪثر ڏسان ٿو گراهڪن کي استعمال ڪندي ٻه لوپ (نيرو-سائي ڊيپلائي) ايپليڪيشنن لاءِ پيداوار واري ماحول ۾. هي توهان کي جلدي شاخن جي وچ ۾ سوئچ ڪرڻ جي اجازت ڏئي ٿو جڏهن نوان رليز پهچائڻ. گهڻو ڪري، لڳائڻ کان پوء، ڊرامائي تبديليون ٿي سگهن ٿيون جيڪي فوري طور تي قابل ذڪر نه آهن. انهي حالت ۾، ڪارڪردگي ۽ دستيابي ۾ خرابي نه ٿي سگھي. اهڙين تبديلين کي تڪڙو جواب ڏيڻ لاءِ، اهو بهتر آهي ته مختلف ميٽرڪ استعمال ڪن جيڪي صارف جي رويي کي ظاهر ڪن ٿيون (سيشنن جو تعداد ۽ صارف جي عملن جو تعداد، تبادلي، اچ وڃ جي شرح). هيٺ ڏنل انگ اکر ڏيکاري ٿو هڪ مثال جنهن ۾، جڏهن تبادلي جي شرح گهٽجي ٿي، سافٽ ويئر شاخن جي وچ ۾ سوئچنگ ٿيندي آهي.

سافٽ ويئر شاخن جي وچ ۾ تبديل ٿيڻ کان پوء تبادلي جي شرح گھٽجي ٿي. ذريعو

خودڪار مسئلو ڳولڻ لاء ميڪانيزم

آخرڪار، مان توهان کي هڪ وڌيڪ مثال ڏيندس ڇو ته مون کي Dynatrace تمام گهڻو پسند آهي.

امتحان واري ماحول ۾ اسيمبلين جي معيار جي جانچ کي خودڪار ڪرڻ بابت منهنجي ڪهاڻي جي حصي ۾، اسان سڀني حدن جي قيمتن کي دستي طور تي طئي ڪيو. اهو امتحان واري ماحول لاءِ عام آهي؛ ٽيسٽ ڪندڙ پاڻ هر ٽيسٽ کان اڳ اشارن کي طئي ڪري ٿو لوڊ جي لحاظ کان. پيداوار جي ماحول ۾، اهو ضروري آهي ته مسئلا خود بخود معلوم ڪيا وڃن، مختلف بنيادي ميکانيزم جي حساب سان.

Dynatrace وٽ دلچسپ تعمير ٿيل مصنوعي ذھني اوزار آھن جيڪي، غير معمولي ميٽرڪس (بيس لائيننگ) کي طئي ڪرڻ ۽ سڀني اجزاء جي وچ ۾ رابطي جو نقشو ٺاھڻ جي ميڪانيزم جي بنياد تي، واقعن کي ھڪٻئي سان مقابلو ڪرڻ ۽ لاڳاپو ڪرڻ، توھان جي خدمت جي عمل ۾ بي ضابطگين جو تعين ڪرڻ ۽ تفصيلي مهيا ڪن ٿا. هر مسئلي ۽ بنيادي سبب تي معلومات.

اجزاء جي وچ ۾ انحصار خود بخود تجزيو ڪندي، Dynatrace نه رڳو اهو طئي ڪري ٿو ته ڇا مشڪلاتي خدمت بنيادي سبب آهي، پر ٻين خدمتن تي انحصار پڻ. هيٺ ڏنل مثال ۾، Dynatrace پاڻمرادو نگراني ڪري ٿو ۽ هر خدمت جي صحت کي ٽرانزيڪشن جي عمل جي اندر اندر، گولانگ سروس کي بنيادي سبب جي طور تي سڃاڻي ٿو.

ناڪامي جي بنيادي سبب کي طئي ڪرڻ جو هڪ مثال. ذريعو

هيٺ ڏنل انگ اکر ڏيکاري ٿو توهان جي ايپليڪيشن سان مسئلن جي نگراني جي عمل کي واقعي جي شروعات کان وٺي.

انهن تي سڀني اجزاء ۽ واقعن جي ڊسپلي سان هڪ اڀرندڙ مسئلي جو تصور

مانيٽرنگ سسٽم ان مسئلي سان لاڳاپيل واقعن جو هڪ مڪمل ڪرنالوجي گڏ ڪيو. ٽائم لائن هيٺ ڏنل ونڊو ۾ اسان هر هڪ اجزاء تي سڀ اهم واقعا ڏسون ٿا. انهن واقعن جي بنياد تي، توهان ڪوڊ اسڪرپٽ جي صورت ۾ خودڪار اصلاح لاء طريقا سيٽ ڪري سگهو ٿا.

اضافي طور تي، مان توهان کي صلاح ڏيو ته مانيٽرنگ سسٽم کي سروس ڊيسڪ يا بگ ٽريڪر سان گڏ ڪريو. جڏهن ڪو مسئلو ٿئي ٿو، ڊولپرز جلدي مڪمل معلومات حاصل ڪن ٿا ان جو تجزيو ڪرڻ لاءِ ڪوڊ جي سطح تي پيداوار جي ماحول ۾.

ٿڪل

نتيجي طور، اسان پائپ لائن ۾ تعمير ٿيل خودڪار سافٽ ويئر معيار جي چڪاس سان گڏ هڪ CI/CD پائپ لائن سان ختم ڪيو. اسان گھٽ معيار جي اسيمبلين جو تعداد گھٽائي، مجموعي طور تي سسٽم جي اعتبار کي وڌايو، ۽ جيڪڏھن اسان جو سسٽم اڃا تائين ناڪام ٿئي ٿو، اسان ان کي بحال ڪرڻ لاء ميڪانيزم شروع ڪريون ٿا.

اهو يقيني طور تي سافٽ ويئر جي معيار جي نگراني کي خودڪار ڪرڻ ۾ سيڙپڪاري جي ڪوشش جي قابل آهي؛ اهو هميشه هڪ تڪڙو عمل ناهي، پر وقت سان گڏ اهو ميوو کڻندو. مان سفارش ڪريان ٿو ته پيداوار جي ماحول ۾ هڪ نئين واقعي کي حل ڪرڻ کان پوء، توهان فوري طور تي سوچيو ته ٽيسٽ ماحول ۾ چيڪن لاء ڪهڙن مانيٽر شامل ڪيو وڃي ته جيئن خراب تعمير کي پيداوار ۾ اچڻ کان بچڻ لاء، ۽ انهن مسئلن کي خودڪار طور تي درست ڪرڻ لاء هڪ اسڪرپٽ پڻ ٺاهيو.

مون کي اميد آهي ته منهنجا مثال توهان جي ڪوششن ۾ توهان جي مدد ڪندا. مان پڻ دلچسپي وٺندس توهان جي ميٽرڪ جا مثال ڏسڻ لاءِ استعمال ٿيل خود شفا ڏيڻ واري نظام کي لاڳو ڪرڻ لاءِ.

ذريعو

جو ذريعو: www.habr.com