اب DevOps کا موضوع hype پر ہے۔ مسلسل انضمام اور ترسیل پائپ لائن ہر کوئی اسے نافذ کر رہا ہے. لیکن زیادہ تر لوگ ہمیشہ CI/CD پائپ لائن کے مختلف مراحل پر انفارمیشن سسٹم کی وشوسنییتا کو یقینی بنانے پر توجہ نہیں دیتے ہیں۔ اس مضمون میں میں سافٹ ویئر کی کوالٹی چیک کو خودکار کرنے اور اس کے "خود علاج" کے لیے ممکنہ منظرناموں کو نافذ کرنے میں اپنے تجربے کے بارے میں بات کرنا چاہوں گا۔
میں ایک کمپنی کے آئی ٹی سروس مینجمنٹ ڈیپارٹمنٹ میں انجینئر کے طور پر کام کرتا ہوں۔ . میری مہارت کا بنیادی شعبہ مختلف ایپلیکیشن کی کارکردگی اور دستیابی کی نگرانی کے نظام کا نفاذ ہے۔ میں اکثر مارکیٹ کے مختلف حصوں سے تعلق رکھنے والے IT صارفین سے ان کی IT خدمات کے معیار کی نگرانی کے حوالے سے موجودہ مسائل کے حوالے سے بات چیت کرتا ہوں۔ بنیادی مقصد ریلیز سائیکل کے وقت کو کم سے کم کرنا اور ریلیز کی فریکوئنسی کو بڑھانا ہے۔ یقیناً یہ سب اچھا ہے: مزید ریلیزز - مزید نئی خصوصیات - زیادہ مطمئن صارفین - زیادہ منافع۔ لیکن حقیقت میں، چیزیں ہمیشہ اچھی طرح سے کام نہیں کرتی ہیں. بہت زیادہ تعیناتی کی شرح کے ساتھ، ہماری ریلیز کے معیار کے بارے میں فوری طور پر سوال اٹھتا ہے۔ مکمل طور پر خودکار پائپ لائن کے ساتھ بھی، سب سے بڑے چیلنجوں میں سے ایک ایپلی کیشن اپ ٹائم اور صارف کے تجربے کو متاثر کیے بغیر خدمات کو جانچ سے پروڈکشن کی طرف لے جانا ہے۔
صارفین کے ساتھ متعدد بات چیت کے نتائج کی بنیاد پر، میں یہ کہہ سکتا ہوں کہ CI کے مختلف مراحل میں کوالٹی کنٹرول، ایپلیکیشن کی قابل اعتمادی کا مسئلہ اور اس کے "خود شفا یابی" (مثال کے طور پر مستحکم ورژن پر واپس آنا) کا امکان۔ /CD پائپ لائن سب سے زیادہ دلچسپ اور متعلقہ موضوعات میں سے ہیں۔
حال ہی میں، میں نے خود کسٹمر سائیڈ پر کام کیا ہے - آن لائن بینکنگ ایپلیکیشن سافٹ ویئر سپورٹ سروس میں۔ ہماری ایپلیکیشن کے فن تعمیر میں خود تحریر کردہ مائیکرو سروسز کی ایک بڑی تعداد استعمال کی گئی ہے۔ سب سے افسوسناک بات یہ ہے کہ تمام ڈویلپرز ترقی کی تیز رفتاری کا مقابلہ نہیں کر سکتے؛ کچھ مائیکرو سروسز کے معیار کو نقصان پہنچا، جس نے ان کے اور ان کے تخلیق کاروں کے لیے مضحکہ خیز عرفی ناموں کو جنم دیا۔ اس بارے میں کہانیاں تھیں کہ یہ مصنوعات کس مواد سے بنی ہیں۔
"مسئلہ کی تشکیل"
ریلیز کی اعلی تعدد اور مائیکرو سروسز کی ایک بڑی تعداد جانچ کے مرحلے اور آپریشنل مرحلے دونوں پر، مجموعی طور پر ایپلیکیشن کے عمل کو سمجھنا مشکل بناتی ہے۔ تبدیلیاں مسلسل ہوتی رہتی ہیں اور نگرانی کے اچھے آلات کے بغیر ان پر قابو پانا بہت مشکل ہے۔ اکثر، صبح کے وقت ایک رات کی رہائی کے بعد، ڈویلپرز پاؤڈر کیگ کی طرح بیٹھتے ہیں اور کسی چیز کے ٹوٹنے کا انتظار نہیں کرتے، حالانکہ جانچ کے مرحلے پر تمام چیکس کامیاب ہو گئے تھے۔
ایک نکتہ اور ہے۔ جانچ کے مرحلے پر، سافٹ ویئر کی فعالیت کی جانچ پڑتال کی جاتی ہے: ایپلی کیشن کے اہم افعال کا نفاذ اور غلطیوں کی عدم موجودگی۔ معیار کی کارکردگی کے جائزے یا تو غائب ہیں یا درخواست کے تمام پہلوؤں اور انضمام پرت کو مدنظر نہیں رکھتے۔ ہو سکتا ہے کہ کچھ میٹرکس بالکل چیک نہ ہوں۔ نتیجے کے طور پر، جب پیداواری ماحول میں خرابی واقع ہوتی ہے، تو تکنیکی معاونت کے شعبے کو اس کے بارے میں تب ہی پتہ چلتا ہے جب حقیقی صارفین شکایت کرنا شروع کر دیتے ہیں۔ میں اختتامی صارفین پر کم معیار والے سافٹ ویئر کے اثرات کو کم کرنا چاہوں گا۔
ایک حل یہ ہے کہ CI/CD پائپ لائن کے مختلف مراحل پر سافٹ ویئر کے معیار کو جانچنے کے عمل کو لاگو کیا جائے، اور ہنگامی صورت حال میں سسٹم کو بحال کرنے کے لیے مختلف منظرنامے شامل کیے جائیں۔ ہمیں یہ بھی یاد ہے کہ ہمارے پاس DevOps ہیں۔ کاروبار جلد از جلد ایک نئی مصنوعات حاصل کرنے کی توقع رکھتے ہیں۔ لہذا، ہمارے تمام چیک اور اسکرپٹ خودکار ہونے چاہئیں۔
کام کو دو اجزاء میں تقسیم کیا گیا ہے:
- جانچ کے مرحلے پر اسمبلیوں کا کوالٹی کنٹرول (کم معیار کی اسمبلیوں کو پکڑنے کے عمل کو خودکار کرنے کے لیے)؛
- پیداواری ماحول میں سافٹ ویئر کوالٹی کنٹرول (مسائل کا خودکار پتہ لگانے کے طریقہ کار اور ان کی خود شفا یابی کے لیے ممکنہ منظرنامے)۔
میٹرکس کی نگرانی اور جمع کرنے کا آلہ
مقررہ اہداف کو حاصل کرنے کے لیے، ایک مانیٹرنگ سسٹم کی ضرورت ہے جو CI/CD پائپ لائن کے مختلف مراحل پر مسائل کا پتہ لگا سکے اور انہیں آٹومیشن سسٹم میں منتقل کر سکے۔ یہ بھی ایک مثبت چیز ہوگی اگر یہ نظام مختلف ٹیموں کے لیے مفید میٹرکس فراہم کرتا ہے: ترقی، جانچ، آپریشن۔ اور یہ بالکل شاندار ہے اگر یہ کاروبار کے لیے بھی ہو۔
میٹرکس جمع کرنے کے لیے، آپ مختلف سسٹمز کا ایک سیٹ استعمال کر سکتے ہیں (Prometheus, ELK Stack, Zabbix, وغیرہ)، لیکن، میری رائے میں، APM-class سلوشنز ان کاموں کے لیے بہترین موزوں ہیں ()، جو آپ کی زندگی کو بہت آسان بنا سکتا ہے۔
سپورٹ سروس میں اپنے کام کے حصے کے طور پر، میں نے Dynatrace سے APM کلاس سلوشن کا استعمال کرتے ہوئے اسی طرح کا پروجیکٹ کرنا شروع کیا۔ اب، ایک انٹیگریٹر کے لیے کام کرتے ہوئے، میں مانیٹرنگ سسٹمز کی مارکیٹ کو اچھی طرح جانتا ہوں۔ میری ساپیکش رائے: Dynatrace اس طرح کے مسائل کو حل کرنے کے لیے بہترین موزوں ہے۔
Dynatrace کوڈ پر عمل درآمد کی سطح تک دانے دار سطح پر ہر صارف کے آپریشن کا افقی منظر فراہم کرتا ہے۔ آپ مختلف معلوماتی خدمات کے درمیان تعامل کے پورے سلسلے کو ٹریک کر سکتے ہیں: ویب اور موبائل ایپلیکیشنز کی فرنٹ اینڈ لیولز، بیک اینڈ ایپلیکیشن سرورز، انٹیگریشن بس سے لے کر ڈیٹا بیس کو مخصوص کال تک۔
. سسٹم کے اجزاء کے درمیان تمام انحصار کی خودکار تعمیر
. خود کار طریقے سے پتہ لگانے اور سروس آپریشن کے راستے کی تعمیر
ہمیں یہ بھی یاد ہے کہ ہمیں مختلف آٹومیشن ٹولز کے ساتھ ضم کرنے کی ضرورت ہے۔ یہاں حل میں ایک آسان API ہے جو آپ کو مختلف میٹرکس اور ایونٹس بھیجنے اور وصول کرنے کی اجازت دیتا ہے۔
اس کے بعد، آئیے مزید تفصیلی نظر کی طرف چلتے ہیں کہ ڈائنٹریس سسٹم کا استعمال کرتے ہوئے ان مسائل کو کیسے حل کیا جائے۔
ٹاسک 1۔ جانچ کے مرحلے پر اسمبلیوں کے کوالٹی کنٹرول کا آٹومیشن
پہلا چیلنج درخواست کی ترسیل کی پائپ لائن میں جلد از جلد مسائل کو تلاش کرنا ہے۔ صرف "اچھے" کوڈ کی تعمیر کو پیداوار تک پہنچنا چاہئے۔ ایسا کرنے کے لیے، جانچ کے مرحلے پر آپ کی پائپ لائن میں آپ کی خدمات کے معیار کو جانچنے کے لیے اضافی مانیٹر شامل ہونے چاہئیں۔
آئیے اس پر عمل درآمد کرنے اور اس عمل کو خودکار کرنے کے طریقہ پر ایک قدم بہ قدم جائزہ لیتے ہیں:
یہ اعداد و شمار خودکار سافٹ ویئر کے معیار کی جانچ کے مراحل کو ظاہر کرتا ہے:
- نگرانی کے نظام کی تعیناتی (ایجنٹس کی تنصیب)؛
- آپ کے سافٹ ویئر کے معیار (میٹرکس اور حد کی قدروں) کا اندازہ لگانے کے لیے واقعات کی نشاندہی کرنا اور انہیں مانیٹرنگ سسٹم میں منتقل کرنا؛
- بوجھ اور کارکردگی کے ٹیسٹ کی نسل؛
- نگرانی کے نظام میں کارکردگی اور دستیابی کا ڈیٹا اکٹھا کرنا؛
- سافٹ ویئر کوالٹی اسسمنٹ ایونٹس کی بنیاد پر مانیٹرنگ سسٹم سے CI/CD سسٹم میں ٹیسٹ ڈیٹا کی منتقلی۔ اسمبلیوں کا خودکار تجزیہ۔
مرحلہ 1. نگرانی کے نظام کی تعیناتی۔
پہلے آپ کو اپنے ٹیسٹ ماحول میں ایجنٹوں کو انسٹال کرنے کی ضرورت ہے۔ اسی وقت، Dynatrace حل میں ایک اچھی خصوصیت ہے - یہ یونیورسل ایجنٹ OneAgent کا استعمال کرتا ہے، جو OS مثال (Windows, Linux, AIX) پر انسٹال ہوتا ہے، خود بخود آپ کی خدمات کا پتہ لگاتا ہے اور ان پر مانیٹرنگ ڈیٹا اکٹھا کرنا شروع کر دیتا ہے۔ آپ کو ہر عمل کے لیے علیحدہ ایجنٹ کو ترتیب دینے کی ضرورت نہیں ہے۔ کلاؤڈ اور کنٹینر پلیٹ فارم کے لیے بھی صورت حال ایک جیسی ہو گی۔ ایک ہی وقت میں، آپ ایجنٹ کی تنصیب کے عمل کو بھی خودکار کر سکتے ہیں۔ Dynatrace "انفراسٹرکچر بطور کوڈ" کے تصور میں بالکل فٹ بیٹھتا ہے (): تمام مقبول پلیٹ فارمز کے لیے تیار اسکرپٹ اور ہدایات موجود ہیں۔ آپ ایجنٹ کو اپنی سروس کی ترتیب میں شامل کرتے ہیں، اور جب آپ اسے تعینات کرتے ہیں، تو آپ کو پہلے سے کام کرنے والے ایجنٹ کے ساتھ فوری طور پر ایک نئی سروس موصول ہوتی ہے۔
مرحلہ 2: اپنے سافٹ ویئر کے معیار کے واقعات کی وضاحت کریں۔
اب آپ کو خدمات اور کاروباری کارروائیوں کی فہرست پر فیصلہ کرنے کی ضرورت ہے۔ یہ ضروری ہے کہ صارف کے بالکل ان کاموں کو مدنظر رکھا جائے جو آپ کی خدمت کے لیے اہم ہیں۔ یہاں میں کاروبار اور نظام کے تجزیہ کاروں سے مشورہ کرنے کی تجویز کرتا ہوں۔
اگلا، آپ کو یہ تعین کرنے کی ضرورت ہے کہ آپ ہر سطح کے جائزے میں کون سے میٹرکس شامل کرنا چاہتے ہیں۔ مثال کے طور پر، یہ عمل درآمد کا وقت ہو سکتا ہے (اوسط، میڈین، پرسنٹائلز وغیرہ میں تقسیم کیا گیا)، غلطیاں (منطقی، سروس، انفراسٹرکچر، وغیرہ) اور مختلف انفراسٹرکچر میٹرکس (میموری ہیپ، کوڑا اٹھانے والا، دھاگے کی گنتی، وغیرہ)۔
DevOps ٹیم کے ذریعہ آٹومیشن اور استعمال میں آسانی کے لیے، "کوڈ کے طور پر مانیٹرنگ" کا تصور ظاہر ہوتا ہے۔ اس سے میرا مطلب یہ ہے کہ ایک ڈویلپر/ٹیسٹر ایک سادہ JSON فائل لکھ سکتا ہے جو سافٹ ویئر کوالٹی اشورینس میٹرکس کی وضاحت کرتا ہے۔
آئیے ایسی JSON فائل کی ایک مثال دیکھیں۔ 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
}
]
}فائل ٹائم سیریز کی تعریفوں کی ایک صف ہے:
- timeseriesId - میٹرک کی جانچ کی جا رہی ہے، مثال کے طور پر، رسپانس ٹائم، ایرر کاؤنٹ، استعمال شدہ میموری وغیرہ۔
- ایگریگیشن - میٹرکس کے مجموعے کی سطح، ہمارے معاملے میں اوسط، لیکن آپ اپنی ضرورت کا کوئی بھی استعمال کر سکتے ہیں (اوسط، کم سے کم، زیادہ سے زیادہ، رقم، شمار، فیصد)؛
- ٹیگز - نگرانی کے نظام میں آبجیکٹ ٹیگ، یا آپ ایک مخصوص آبجیکٹ شناخت کنندہ کی وضاحت کر سکتے ہیں۔
- شدید اور انتباہ - یہ اشارے ہمارے میٹرکس کی حد کی قدروں کو منظم کرتے ہیں؛ اگر ٹیسٹ ویلیو شدید حد سے تجاوز کر جاتی ہے، تو ہماری تعمیر کو کامیاب نہیں کے طور پر نشان زد کیا جاتا ہے۔
مندرجہ ذیل اعداد و شمار اس طرح کی حدوں کے استعمال کی ایک مثال دکھاتا ہے۔
مرحلہ 3: لوڈ جنریشن
ایک بار جب ہم اپنی سروس کے معیار کی سطحوں کا تعین کر لیتے ہیں، تو ہمیں ٹیسٹ لوڈ بنانے کی ضرورت ہوتی ہے۔ آپ کسی بھی ٹیسٹنگ ٹولز کا استعمال کر سکتے ہیں جن سے آپ آرام دہ ہوں، جیسے Jmeter، Selenium، Neotys، Gatling، وغیرہ۔
ڈائنٹریس کا مانیٹرنگ سسٹم آپ کو اپنے ٹیسٹوں سے مختلف میٹا ڈیٹا حاصل کرنے اور یہ پہچاننے کی اجازت دیتا ہے کہ کون سے ٹیسٹ کس ریلیز سائیکل اور کون سی سروس سے تعلق رکھتے ہیں۔ 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 حل کی بنیاد پر کچھ مثالیں دوں گا (Dynatrace دوبارہ ایک مثال ہو گا) جو آپ کی زندگی کو آسان بنانے میں بھی مددگار ثابت ہوں گی۔
سب سے پہلے، ایپلی کیشن آپریشن کے لحاظ سے کارکردگی سے متعلق ہر چیز موجود ہے۔ حل مختلف سطحوں پر سینکڑوں میٹرکس فراہم کرتا ہے جنہیں آپ محرکات کے طور پر استعمال کر سکتے ہیں:
- صارف کی سطح (براؤزرز، موبائل ایپلی کیشنز، آئی او ٹی ڈیوائسز، صارف کا رویہ، تبدیلی، وغیرہ)؛
- سروس اور آپریشنز کی سطح (کارکردگی، دستیابی، غلطیاں، وغیرہ)؛
- ایپلیکیشن انفراسٹرکچر لیول (میزبان OS میٹرکس، JMX، MQ، ویب سرور، وغیرہ)؛
- پلیٹ فارم کی سطح (ورچوئلائزیشن، کلاؤڈ، کنٹینر، وغیرہ)۔
Dynatrace میں نگرانی کی سطح.
دوم، جیسا کہ میں نے پہلے کہا، Dynatrace کے پاس ایک کھلا API ہے، جو اسے مختلف تھرڈ پارٹی سسٹمز کے ساتھ ضم کرنا بہت آسان بناتا ہے۔ مثال کے طور پر، کنٹرول کے پیرامیٹرز سے تجاوز ہونے پر آٹومیشن سسٹم کو اطلاع بھیجنا۔
ذیل میں Ansible کے ساتھ بات چیت کرنے کی ایک مثال ہے۔
ذیل میں میں چند مثالیں دوں گا کہ کس قسم کی آٹومیشن کی جا سکتی ہے۔ یہ کیسز کا صرف ایک حصہ ہے؛ آپ کے ماحول میں ان کی فہرست صرف آپ کے تخیل اور آپ کے مانیٹرنگ ٹولز کی صلاحیتوں سے محدود ہو سکتی ہے۔
1. خراب تعیناتی - ورژن رول بیک
یہاں تک کہ اگر ہم آزمائشی ماحول میں ہر چیز کو اچھی طرح سے جانچتے ہیں، تب بھی ایک موقع موجود ہے کہ نئی ریلیز پیداواری ماحول میں آپ کی درخواست کو ختم کر سکتی ہے۔ اسی انسانی عنصر کو منسوخ نہیں کیا گیا ہے۔
مندرجہ ذیل اعداد و شمار میں ہم دیکھتے ہیں کہ سروس پر کارروائیوں کے عمل کے وقت میں تیزی سے اضافہ ہوا ہے۔ اس چھلانگ کا آغاز درخواست پر تعیناتی کے وقت کے ساتھ موافق ہے۔ ہم ان تمام معلومات کو واقعات کے طور پر آٹومیشن سسٹم میں منتقل کرتے ہیں۔ اگر سروس کی کارکردگی ہمارے مقرر کردہ وقت کے بعد معمول پر نہیں آتی ہے، تو ایک اسکرپٹ خود بخود کہلایا جاتا ہے جو ورژن کو پرانے پر واپس لے جاتا ہے۔
تعیناتی کے بعد آپریشنز کی کارکردگی کا انحطاط۔
2. 100% پر وسائل کی لوڈنگ - روٹنگ میں ایک نوڈ شامل کریں۔
مندرجہ ذیل مثال میں، نگرانی کا نظام اس بات کا تعین کرتا ہے کہ اجزاء میں سے ایک کو 100% CPU لوڈ کا سامنا ہے۔
CPU لوڈ 100%
اس تقریب کے لیے کئی مختلف منظرنامے ممکن ہیں۔ مثال کے طور پر، نگرانی کا نظام اضافی طور پر چیک کرتا ہے کہ آیا وسائل کی کمی سروس پر بوجھ میں اضافے سے وابستہ ہے۔ اگر ایسا ہے تو، پھر ایک اسکرپٹ کو عمل میں لایا جاتا ہے جو خود بخود روٹنگ میں ایک نوڈ شامل کرتا ہے، اس طرح مجموعی طور پر سسٹم کی فعالیت کو بحال کرتا ہے۔
ایک واقعہ کے بعد پیمانہ کاری
3. ہارڈ ڈرائیو پر جگہ کی کمی - ڈسک کی صفائی
مجھے لگتا ہے کہ بہت سے لوگ پہلے ہی ان عملوں کو خودکار کر چکے ہیں۔ اے پی ایم کا استعمال کرتے ہوئے، آپ ڈسک کے سب سسٹم پر خالی جگہ کی نگرانی بھی کر سکتے ہیں۔ اگر کوئی جگہ نہیں ہے یا ڈسک آہستہ چل رہی ہے، تو ہم اسے صاف کرنے یا جگہ شامل کرنے کے لیے اسکرپٹ کہتے ہیں۔
ڈسک لوڈ 100%
4. صارف کی کم سرگرمی یا کم تبدیلی - نیلی اور سبز شاخوں کے درمیان سوئچنگ
میں اکثر صارفین کو پیداواری ماحول میں ایپلیکیشنز کے لیے دو لوپس (نیلی سبز تعیناتی) استعمال کرتے ہوئے دیکھتا ہوں۔ یہ آپ کو نئی ریلیز فراہم کرتے وقت شاخوں کے درمیان تیزی سے سوئچ کرنے کی اجازت دیتا ہے۔ اکثر، تعیناتی کے بعد، ڈرامائی تبدیلیاں واقع ہوسکتی ہیں جو فوری طور پر قابل توجہ نہیں ہوتی ہیں۔ اس صورت میں، کارکردگی اور دستیابی میں انحطاط کا مشاہدہ نہیں کیا جا سکتا ہے۔ ایسی تبدیلیوں کا فوری جواب دینے کے لیے، بہتر ہے کہ مختلف میٹرکس کا استعمال کیا جائے جو صارف کے رویے کی عکاسی کرتے ہیں (سیشنز اور صارف کے اعمال کی تعداد، تبدیلی، باؤنس ریٹ)۔ مندرجہ ذیل اعداد و شمار ایک مثال دکھاتا ہے جس میں، جب تبادلوں کی شرح کم ہوتی ہے، تو سافٹ ویئر کی شاخوں کے درمیان سوئچنگ ہوتی ہے۔
سافٹ ویئر کی شاخوں کے درمیان سوئچ کرنے کے بعد تبادلوں کی شرح گر جاتی ہے۔
خودکار مسئلہ کا پتہ لگانے کے طریقہ کار
آخر میں، میں آپ کو ایک اور مثال دوں گا کہ مجھے Dynatrace سب سے زیادہ کیوں پسند ہے۔
امتحانی ماحول میں اسمبلیوں کے معیار کی جانچ کو خودکار کرنے کے بارے میں میری کہانی کے حصے میں، ہم نے تمام حد کی قدروں کا دستی طور پر تعین کیا۔ ٹیسٹ کے ماحول کے لیے یہ معمول ہے؛ ٹیسٹر خود بوجھ کے لحاظ سے ہر ٹیسٹ سے پہلے اشارے کا تعین کرتا ہے۔ پیداواری ماحول میں، یہ ضروری ہے کہ مختلف بنیادی میکانزم کو مدنظر رکھتے ہوئے مسائل کا خود بخود پتہ چل جائے۔
Dynatrace کے پاس مصنوعی ذہانت کے دلچسپ ٹولز ہیں جو غیر متضاد میٹرکس (بیس لائننگ) کا تعین کرنے اور تمام اجزاء کے درمیان تعامل کا نقشہ بنانے، واقعات کا ایک دوسرے کے ساتھ موازنہ اور ارتباط کے طریقہ کار کی بنیاد پر، آپ کی سروس کے عمل میں بے ضابطگیوں کا تعین کرتے ہیں اور تفصیلی معلومات فراہم کرتے ہیں۔ ہر مسئلے اور جڑ کے بارے میں معلومات۔
اجزاء کے درمیان انحصار کا خود بخود تجزیہ کرکے، Dynatrace نہ صرف اس بات کا تعین کرتا ہے کہ آیا مسئلہ کی خدمت بنیادی وجہ ہے، بلکہ دیگر خدمات پر اس کا انحصار بھی۔ نیچے دی گئی مثال میں، Dynatrace لین دین کے عمل میں ہر سروس کی صحت کی خود بخود نگرانی کرتا ہے اور اس کا جائزہ لیتا ہے، گولانگ سروس کو اس کی بنیادی وجہ کے طور پر شناخت کرتا ہے۔
ناکامی کی بنیادی وجہ کا تعین کرنے کی ایک مثال۔
مندرجہ ذیل اعداد و شمار ایک واقعہ کے آغاز سے آپ کی درخواست کے ساتھ مسائل کی نگرانی کے عمل کو ظاہر کرتا ہے۔
ان پر تمام اجزاء اور واقعات کی نمائش کے ساتھ ابھرتے ہوئے مسئلے کا تصور
نگرانی کے نظام نے پیدا ہونے والے مسئلے سے متعلق واقعات کی مکمل تاریخ جمع کی۔ ٹائم لائن کے نیچے والی ونڈو میں ہم ہر ایک اجزاء پر تمام اہم واقعات دیکھتے ہیں۔ ان واقعات کی بنیاد پر، آپ کوڈ اسکرپٹس کی شکل میں خودکار اصلاح کے لیے طریقہ کار مرتب کر سکتے ہیں۔
مزید برآں، میں آپ کو مشورہ دیتا ہوں کہ مانیٹرنگ سسٹم کو سروس ڈیسک یا بگ ٹریکر کے ساتھ مربوط کریں۔ جب کوئی مسئلہ پیش آتا ہے تو، ڈویلپرز فوری طور پر مکمل معلومات حاصل کرتے ہیں تاکہ پیداواری ماحول میں کوڈ کی سطح پر اس کا تجزیہ کریں۔
حاصل يہ ہوا
نتیجے کے طور پر، ہم پائپ لائن میں بلٹ ان خودکار سافٹ ویئر کوالٹی چیک کے ساتھ ایک CI/CD پائپ لائن کے ساتھ ختم ہوئے۔ ہم کم معیار کی اسمبلیوں کی تعداد کو کم سے کم کرتے ہیں، مجموعی طور پر سسٹم کی بھروسے میں اضافہ کرتے ہیں، اور اگر ہمارا سسٹم پھر بھی ناکام ہو جاتا ہے، تو ہم اسے بحال کرنے کے لیے میکانزم شروع کرتے ہیں۔
یہ یقینی طور پر سافٹ ویئر کوالٹی مانیٹرنگ کو خودکار کرنے میں سرمایہ کاری کرنے کے قابل ہے؛ یہ ہمیشہ ایک تیز عمل نہیں ہوتا ہے، لیکن وقت کے ساتھ ساتھ اس کا پھل آئے گا۔ میں تجویز کرتا ہوں کہ پروڈکشن کے ماحول میں کسی نئے واقعے کو حل کرنے کے بعد، آپ فوری طور پر اس بارے میں سوچیں کہ ٹیسٹ کے ماحول میں چیک کے لیے کون سے مانیٹر شامل کیے جائیں تاکہ خراب تعمیر کو پروڈکشن میں آنے سے روکا جا سکے، اور ان مسائل کو خود بخود درست کرنے کے لیے ایک اسکرپٹ بھی بنائیں۔
مجھے امید ہے کہ میری مثالیں آپ کی کوششوں میں آپ کی مدد کریں گی۔ میں خود شفا یابی کے نظام کو لاگو کرنے کے لیے استعمال ہونے والے میٹرکس کی آپ کی مثالیں دیکھنے میں بھی دلچسپی کروں گا۔
ماخذ: www.habr.com