ہم اسپورٹ ماسٹر کی نگرانی کرتے ہیں - کیسے اور کس کے ساتھ

ہم نے پروڈکٹ ٹیموں کی تشکیل کے مرحلے پر ایک مانیٹرنگ سسٹم بنانے کے بارے میں سوچا۔ واضح ہو گیا کہ ہمارا کاروبار‘ استحصال‘ ان ٹیموں میں نہیں آتا۔ ایسا کیوں ہے؟

حقیقت یہ ہے کہ ہماری تمام ٹیمیں انفرادی انفارمیشن سسٹمز، مائیکرو سروسز اور فرنٹ کے ارد گرد بنائی گئی ہیں، اس لیے ٹیمیں پورے نظام کی مجموعی صحت کو نہیں دیکھتی ہیں۔ مثال کے طور پر، وہ نہیں جانتے کہ گہرے پسدید میں کچھ چھوٹا سا حصہ سامنے والے سرے کو کیسے متاثر کرتا ہے۔ ان کی دلچسپی کا دائرہ ان نظاموں تک محدود ہے جن کے ساتھ ان کا نظام مربوط ہے۔ اگر کسی ٹیم اور اس کی سروس A کا سروس B سے تقریباً کوئی تعلق نہیں ہے، تو ایسی سروس ٹیم کے لیے تقریباً پوشیدہ ہے۔

ہماری ٹیم، بدلے میں، ایسے نظاموں کے ساتھ کام کرتی ہے جو ایک دوسرے کے ساتھ بہت مضبوطی سے مربوط ہیں: ان کے درمیان بہت سے رابطے ہیں، یہ ایک بہت بڑا انفراسٹرکچر ہے۔ اور آن لائن سٹور کے آپریشن کا انحصار ان تمام سسٹمز پر ہے (جن میں سے ہمارے پاس، ویسے بھی ایک بڑی تعداد ہے)۔

تو پتہ چلا کہ ہمارا محکمہ کسی ٹیم سے تعلق نہیں رکھتا بلکہ تھوڑا سا سائیڈ پر واقع ہے۔ اس پوری کہانی میں، ہمارا کام جامع طور پر یہ سمجھنا ہے کہ انفارمیشن سسٹم کیسے کام کرتے ہیں، ان کی فعالیت، انضمام، سافٹ ویئر، نیٹ ورک، ہارڈویئر، اور یہ سب ایک دوسرے سے کیسے جڑے ہوئے ہیں۔

جس پلیٹ فارم پر ہمارے آن لائن اسٹورز کام کرتے ہیں وہ اس طرح لگتا ہے:

• سامنے
• درمیانی دفتر
• واپس دفتر

اس سے کوئی فرق نہیں پڑتا ہے کہ ہم کتنا ہی چاہتے ہیں، ایسا نہیں ہوتا ہے کہ تمام نظام آسانی سے اور بے عیب طریقے سے کام کریں۔ نقطہ، ایک بار پھر، نظام اور انضمام کی تعداد ہے - ہمارے جیسے کچھ کے ساتھ، جانچ کے معیار کے باوجود، کچھ واقعات ناگزیر ہیں. مزید یہ کہ ایک الگ نظام کے اندر اور ان کے انضمام کے لحاظ سے۔ اور آپ کو پورے پلیٹ فارم کی حالت کی جامع نگرانی کرنے کی ضرورت ہے، نہ کہ صرف اس کے کسی انفرادی حصے کی۔

مثالی طور پر، پلیٹ فارم بھر میں صحت کی نگرانی خودکار ہونی چاہیے۔ اور ہم اس عمل کے ایک ناگزیر حصے کے طور پر نگرانی کے لیے آئے۔ ابتدائی طور پر، یہ صرف فرنٹ لائن حصے کے لیے بنایا گیا تھا، جب کہ نیٹ ورک کے ماہرین، سافٹ ویئر اور ہارڈویئر ایڈمنسٹریٹرز کے پاس اپنے پرت بہ پرت نگرانی کے نظام موجود ہیں اور اب بھی ہیں۔ ان تمام لوگوں نے صرف اپنی سطح پر نگرانی کی، کسی کو بھی جامع سمجھ نہیں تھی۔

مثال کے طور پر، اگر کوئی ورچوئل مشین کریش ہو جاتی ہے، تو زیادہ تر معاملات میں ہارڈ ویئر اور ورچوئل مشین کے لیے ذمہ دار صرف ایڈمنسٹریٹر ہی اس کے بارے میں جانتا ہے۔ ایسے معاملات میں، فرنٹ لائن ٹیم نے ایپلی کیشن کے کریش ہونے کی حقیقت کو دیکھا، لیکن اس کے پاس ورچوئل مشین کے کریش کے بارے میں ڈیٹا نہیں تھا۔ اور منتظم جان سکتا ہے کہ گاہک کون ہے اور اس کا اندازہ ہو سکتا ہے کہ فی الحال اس ورچوئل مشین پر کیا چل رہا ہے، بشرطیکہ یہ کسی قسم کا بڑا پروجیکٹ ہو۔ وہ غالباً چھوٹوں کے بارے میں نہیں جانتا۔ کسی بھی صورت میں، منتظم کو مالک کے پاس جانے کی ضرورت ہے اور پوچھنا ہوگا کہ اس مشین میں کیا تھا، کیا بحال کرنے کی ضرورت ہے اور کیا تبدیل کرنے کی ضرورت ہے۔ اور اگر واقعی کوئی سنجیدہ چیز ٹوٹ گئی تو وہ حلقوں میں دوڑنا شروع ہو گئے - کیونکہ کسی نے پورے نظام کو نہیں دیکھا۔

بالآخر، اس طرح کی مختلف کہانیاں پورے فرنٹ اینڈ، صارفین اور ہمارے بنیادی کاروباری فنکشن - آن لائن فروخت کو متاثر کرتی ہیں۔ چونکہ ہم کسی ٹیم کا حصہ نہیں ہیں، لیکن ایک آن لائن اسٹور کے حصے کے طور پر تمام ای کامرس ایپلی کیشنز کے آپریشن میں مصروف ہیں، اس لیے ہم نے ای کامرس پلیٹ فارم کے لیے ایک جامع نگرانی کا نظام بنانے کا کام سنبھالا۔

سسٹم کی ساخت اور اسٹیک

ہم نے اپنے سسٹمز کے لیے کئی مانیٹرنگ لیئرز کی نشاندہی کرکے شروعات کی، جن کے اندر ہمیں میٹرکس جمع کرنے کی ضرورت ہوگی۔ اور ان سب کو یکجا کرنے کی ضرورت تھی، جو ہم نے پہلے مرحلے میں کیا تھا۔ اب اس مرحلے پر ہم اپنی تمام پرتوں میں میٹرکس کے اعلیٰ ترین معیار کے مجموعے کو حتمی شکل دے رہے ہیں تاکہ باہمی ربط پیدا کیا جا سکے اور یہ سمجھ سکیں کہ سسٹم ایک دوسرے پر کیسے اثر انداز ہوتے ہیں۔

ایپلی کیشن کے آغاز کے ابتدائی مراحل میں جامع نگرانی کی کمی (چونکہ ہم نے اسے اس وقت بنانا شروع کیا جب زیادہ تر سسٹمز پروڈکشن میں تھے) اس حقیقت کا باعث بنے کہ پورے پلیٹ فارم کی نگرانی کے لیے ہمارے پاس اہم تکنیکی قرض تھا۔ ہم ایک آئی ایس کے لیے نگرانی قائم کرنے اور اس کے لیے تفصیل سے نگرانی کرنے پر توجہ مرکوز کرنے کے متحمل نہیں ہو سکتے، کیونکہ باقی نظام کچھ عرصے کے لیے نگرانی کے بغیر رہ جائیں گے۔ اس مسئلے کو حل کرنے کے لیے، ہم نے انفارمیشن سسٹم کی حالت کو پرت کے حساب سے جانچنے کے لیے انتہائی ضروری میٹرکس کی ایک فہرست کی نشاندہی کی اور اسے نافذ کرنا شروع کیا۔

لہذا، انہوں نے ہاتھی کو حصوں میں کھانے کا فیصلہ کیا.

ہمارے نظام پر مشتمل ہے:

• ہارڈ ویئر
• آپریٹنگ سسٹم؛
• سافٹ ویئر
• مانیٹرنگ ایپلی کیشن میں UI حصے؛
• کاروباری پیمائش؛
• انضمام ایپلی کیشنز؛
• انفارمیشن سیکورٹی؛
• نیٹ ورکس
• ٹریفک بیلنسر

اس نظام کے مرکز میں خود نگرانی کر رہا ہے۔ عام طور پر پورے سسٹم کی حالت کو سمجھنے کے لیے، آپ کو یہ جاننے کی ضرورت ہے کہ ان تمام پرتوں اور ایپلی کیشنز کے پورے سیٹ میں ایپلی کیشنز کے ساتھ کیا ہو رہا ہے۔

تو، اسٹیک کے بارے میں.

ہم اوپن سورس سافٹ ویئر استعمال کرتے ہیں۔ مرکز میں ہمارے پاس Zabbix ہے، جسے ہم بنیادی طور پر الرٹنگ سسٹم کے طور پر استعمال کرتے ہیں۔ ہر کوئی جانتا ہے کہ یہ انفراسٹرکچر کی نگرانی کے لیے مثالی ہے۔ اس کا کیا مطلب ہے؟ بالکل وہی کم سطحی میٹرکس جو ہر کمپنی جو اپنے ڈیٹا سینٹر کو برقرار رکھتی ہے (اور اسپورٹ ماسٹر کے پاس اپنے ڈیٹا سینٹرز ہیں) - سرور کا درجہ حرارت، میموری کی حیثیت، چھاپہ، نیٹ ورک ڈیوائس میٹرکس۔

ہم نے Zabbix کو ٹیلیگرام میسنجر اور Microsoft ٹیموں کے ساتھ مربوط کیا ہے، جو ٹیموں میں فعال طور پر استعمال ہوتے ہیں۔ Zabbix اصل نیٹ ورک، ہارڈ ویئر اور کچھ سافٹ ویئر کی پرت کا احاطہ کرتا ہے، لیکن یہ کوئی علاج نہیں ہے۔ ہم اس ڈیٹا کو کچھ دوسری سروسز سے بہتر بناتے ہیں۔ مثال کے طور پر، ہارڈویئر کی سطح پر، ہم براہ راست API کے ذریعے اپنے ورچوئلائزیشن سسٹم سے منسلک ہوتے ہیں اور ڈیٹا اکٹھا کرتے ہیں۔

اور کیا. Zabbix کے علاوہ، ہم Prometheus کا استعمال کرتے ہیں، جو ہمیں متحرک ماحول کی ایپلی کیشن میں میٹرکس کی نگرانی کرنے کی اجازت دیتا ہے۔ یعنی، ہم HTTP اینڈ پوائنٹ کے ذریعے ایپلیکیشن میٹرکس وصول کر سکتے ہیں اور اس بات کی فکر نہیں کرتے کہ اس میں کون سے میٹرکس لوڈ کیے جائیں اور کون سے نہیں۔ اس ڈیٹا کی بنیاد پر، تجزیاتی سوالات تیار کیے جا سکتے ہیں۔

دوسری تہوں کے لیے ڈیٹا کے ذرائع، مثال کے طور پر، کاروباری میٹرکس، کو تین اجزاء میں تقسیم کیا گیا ہے۔

سب سے پہلے، یہ بیرونی کاروباری نظام ہیں، گوگل تجزیات، ہم لاگز سے میٹرکس جمع کرتے ہیں۔ ان سے ہمیں فعال صارفین، تبادلوں اور کاروبار سے متعلق ہر چیز کا ڈیٹا ملتا ہے۔ دوم، یہ UI مانیٹرنگ سسٹم ہے۔ اسے مزید تفصیل سے بیان کیا جانا چاہیے۔

ایک زمانے میں ہم نے دستی جانچ کے ساتھ آغاز کیا اور یہ فعالیت اور انضمام کے خودکار ٹیسٹوں میں اضافہ ہوا۔ اس سے ہم نے نگرانی کی، صرف اہم فعالیت کو چھوڑ کر، اور مارکروں پر انحصار کیا جو ممکن حد تک مستحکم ہیں اور وقت کے ساتھ اکثر تبدیل نہیں ہوتے ہیں۔

ٹیم کے نئے ڈھانچے کا مطلب ہے کہ درخواست کی تمام سرگرمیاں پروڈکٹ ٹیموں تک ہی محدود ہیں، اس لیے ہم نے خالص جانچ کرنا چھوڑ دیا۔ اس کے بجائے، ہم نے جاوا، سیلینیم اور جینکنز میں لکھے گئے ٹیسٹوں سے UI کی نگرانی کی (رپورٹ شروع کرنے اور بنانے کے لیے ایک سسٹم کے طور پر استعمال کیا جاتا ہے)۔

ہمارے بہت سارے ٹیسٹ تھے، لیکن آخر کار ہم نے مین روڈ، ٹاپ لیول میٹرک پر جانے کا فیصلہ کیا۔ اور اگر ہمارے پاس بہت سارے مخصوص ٹیسٹ ہیں، تو ڈیٹا کو اپ ٹو ڈیٹ رکھنا مشکل ہو جائے گا۔ ہر بعد کی ریلیز پورے نظام کو نمایاں طور پر توڑ دے گی، اور ہم بس اسے ٹھیک کریں گے۔ لہذا، ہم نے بہت ہی بنیادی چیزوں پر توجہ مرکوز کی جو شاذ و نادر ہی تبدیل ہوتی ہیں، اور ہم صرف ان کی نگرانی کرتے ہیں۔

آخر میں، تیسرا، ڈیٹا کا ذریعہ ایک مرکزی لاگنگ سسٹم ہے۔ ہم نوشتہ جات کے لیے لچکدار اسٹیک استعمال کرتے ہیں، اور پھر ہم اس ڈیٹا کو کاروباری میٹرکس کے لیے اپنے مانیٹرنگ سسٹم میں کھینچ سکتے ہیں۔ ان سب کے علاوہ، ہمارے پاس اپنی مانیٹرنگ API سروس ہے، جو Python میں لکھی گئی ہے، جو API کے ذریعے کسی بھی خدمات سے استفسار کرتی ہے اور ان سے Zabbix میں ڈیٹا اکٹھا کرتی ہے۔

نگرانی کا ایک اور ناگزیر وصف تصور ہے۔ ہمارا گرافانا پر مبنی ہے۔ یہ دوسرے ویژولائزیشن سسٹمز میں نمایاں ہے کہ یہ آپ کو ڈیش بورڈ پر ڈیٹا کے مختلف ذرائع سے میٹرکس کو دیکھنے کی اجازت دیتا ہے۔ ہم ایک آن لائن اسٹور کے لیے اعلیٰ سطحی میٹرکس جمع کر سکتے ہیں، مثال کے طور پر، DBMS سے آخری گھنٹے میں کیے گئے آرڈرز کی تعداد، OS کے لیے کارکردگی کے میٹرکس جس پر یہ آن لائن اسٹور Zabbix سے چل رہا ہے، اور اس ایپلیکیشن کی مثالوں کے لیے میٹرکس Prometheus سے. اور یہ سب ایک ڈیش بورڈ پر ہوگا۔ صاف اور قابل رسائی۔

میں سیکورٹی کے بارے میں نوٹ کرتا ہوں - ہم فی الحال نظام کو حتمی شکل دے رہے ہیں، جسے ہم بعد میں عالمی نگرانی کے نظام کے ساتھ مربوط کریں گے۔ میری رائے میں، ای کامرس کو انفارمیشن سیکیورٹی کے شعبے میں جن اہم مسائل کا سامنا ہے وہ بوٹس، پارسرز اور بروٹ فورس سے متعلق ہیں۔ ہمیں اس پر نظر رکھنے کی ضرورت ہے، کیونکہ یہ سب ہماری ایپلی کیشنز کے عمل اور کاروباری نقطہ نظر سے ہماری ساکھ دونوں کو تنقیدی طور پر متاثر کر سکتا ہے۔ اور منتخب کردہ اسٹیک کے ساتھ ہم کامیابی کے ساتھ ان کاموں کا احاطہ کرتے ہیں۔

ایک اور اہم نکتہ یہ ہے کہ ایپلی کیشن پرت کو پرومیتھیس نے جمع کیا ہے۔ وہ خود بھی Zabbix کے ساتھ مربوط ہے۔ اور ہمارے پاس سائٹ اسپیڈ بھی ہے، ایک ایسی سروس جو ہمیں پیرامیٹرز دیکھنے کی اجازت دیتی ہے جیسے کہ ہمارے پیج کی لوڈنگ اسپیڈ، رکاوٹیں، پیج رینڈرنگ، لوڈنگ اسکرپٹس وغیرہ، یہ بھی API انٹیگریٹڈ ہے۔ لہذا ہمارے میٹرکس زبکس میں جمع کیے جاتے ہیں، اور اسی کے مطابق، ہم وہاں سے الرٹ بھی کرتے ہیں۔ تمام انتباہات فی الحال بھیجنے کے اہم طریقوں پر بھیجے گئے ہیں (ابھی یہ ای میل اور ٹیلیگرام ہے، MS ٹیمیں بھی حال ہی میں منسلک ہوئی ہیں)۔ انتباہ کو ایسی حالت میں اپ گریڈ کرنے کے منصوبے ہیں کہ سمارٹ بوٹس ایک سروس کے طور پر کام کریں اور تمام دلچسپی رکھنے والی مصنوعات کی ٹیموں کو نگرانی کی معلومات فراہم کریں۔

ہمارے لیے، میٹرکس نہ صرف انفرادی انفارمیشن سسٹمز کے لیے اہم ہیں، بلکہ اس پورے انفراسٹرکچر کے لیے بھی عمومی میٹرکس جو ایپلی کیشنز استعمال کرتی ہیں: فزیکل سرورز کے کلسٹرز جن پر ورچوئل مشینیں چلتی ہیں، ٹریفک بیلنسرز، نیٹ ورک لوڈ بیلنسرز، نیٹ ورک خود، کمیونیکیشن چینلز کا استعمال۔ . ہمارے اپنے ڈیٹا سینٹرز کے لیے پلس میٹرکس (ہمارے پاس ان میں سے کئی ہیں اور انفراسٹرکچر کافی بڑا ہے)۔

ہمارے مانیٹرنگ سسٹم کے فائدے یہ ہیں کہ اس کی مدد سے ہم تمام سسٹمز کی صحت کی حالت دیکھتے ہیں اور ایک دوسرے اور مشترکہ وسائل پر ان کے اثرات کا اندازہ لگا سکتے ہیں۔ اور بالآخر، یہ ہمیں وسائل کی منصوبہ بندی میں مشغول ہونے کی اجازت دیتا ہے، جو کہ ہماری ذمہ داری بھی ہے۔ ہم سرور کے وسائل کا انتظام کرتے ہیں - ای کامرس کے اندر ایک پول، کمیشن اور نئے آلات کو ختم کرنا، اضافی نئے آلات خریدنا، وسائل کے استعمال کا آڈٹ کرنا وغیرہ۔ ہر سال، ٹیمیں نئے منصوبوں کی منصوبہ بندی کرتی ہیں، اپنے نظام کو تیار کرتی ہیں، اور ہمارے لیے انہیں وسائل فراہم کرنا اہم ہے۔

اور میٹرکس کی مدد سے، ہم اپنے انفارمیشن سسٹمز کے ذریعہ وسائل کی کھپت کا رجحان دیکھتے ہیں۔ اور ان کی بنیاد پر ہم کچھ منصوبہ بندی کر سکتے ہیں۔ ورچوئلائزیشن کی سطح پر، ہم ڈیٹا اکٹھا کرتے ہیں اور ڈیٹا سینٹر کے ذریعہ وسائل کی دستیاب مقدار پر معلومات دیکھتے ہیں۔ اور پہلے سے ہی ڈیٹا سینٹر کے اندر آپ ری سائیکلنگ، اصل تقسیم، اور وسائل کی کھپت دیکھ سکتے ہیں۔ مزید برآں، دونوں اسٹینڈ سرورز اور ورچوئل مشینوں اور فزیکل سرورز کے کلسٹرز کے ساتھ جن پر یہ تمام ورچوئل مشینیں بھرپور طریقے سے گھوم رہی ہیں۔

امکانات

اب ہمارے پاس سسٹم کا بنیادی حصہ مکمل طور پر تیار ہے، لیکن ابھی بھی بہت ساری چیزیں ہیں جن پر کام کرنے کی ضرورت ہے۔ کم از کم، یہ ایک انفارمیشن سیکیورٹی پرت ہے، لیکن نیٹ ورک تک پہنچنا، الرٹ تیار کرنا اور ارتباط کے مسئلے کو حل کرنا بھی ضروری ہے۔ ہمارے پاس بہت سی پرتیں اور سسٹمز ہیں، اور ہر پرت پر کئی اور میٹرکس ہیں۔ یہ ایک میٹریوشکا کی ڈگری تک میٹریوشکا نکلا۔

ہمارا کام بالآخر صحیح الرٹس بنانا ہے۔ مثال کے طور پر، اگر ہارڈ ویئر میں کوئی مسئلہ تھا، ایک بار پھر، ایک ورچوئل مشین کے ساتھ، اور ایک اہم ایپلیکیشن تھی، اور سروس کا کسی بھی طرح سے بیک اپ نہیں لیا گیا تھا۔ ہمیں پتہ چلا کہ ورچوئل مشین مر چکی ہے۔ پھر کاروباری میٹرکس آپ کو متنبہ کریں گے: صارف کہیں غائب ہو گئے ہیں، کوئی تبدیلی نہیں ہے، انٹرفیس میں UI دستیاب نہیں ہے، سافٹ ویئر اور سروسز بھی ختم ہو چکی ہیں۔

اس صورت حال میں، ہم انتباہات سے سپیم وصول کریں گے، اور یہ اب مناسب نگرانی کے نظام کی شکل میں فٹ نہیں بیٹھتا ہے۔ تعلق کا سوال پیدا ہوتا ہے۔ اس لیے، مثالی طور پر، ہمارے مانیٹرنگ سسٹم کو یہ کہنا چاہیے: "دوستوں، آپ کی فزیکل مشین مر گئی ہے، اور اس کے ساتھ یہ ایپلیکیشن اور یہ میٹرکس،" ایک الرٹ کی مدد سے، بجائے اس کے کہ ہم پر سو انتباہات کے ساتھ شدید بمباری کریں۔ یہ اہم چیز کی اطلاع دینا چاہئے - وجہ، جو اس کے لوکلائزیشن کی وجہ سے مسئلہ کو فوری طور پر ختم کرنے میں مدد ملتی ہے.

ہمارا نوٹیفکیشن سسٹم اور الرٹ پروسیسنگ XNUMX گھنٹے ہاٹ لائن سروس کے ارد گرد بنایا گیا ہے۔ تمام انتباہات جو کہ ضروری سمجھے جاتے ہیں اور چیک لسٹ میں شامل ہیں وہاں بھیجے جاتے ہیں۔ ہر الرٹ کی ایک تفصیل ہونی چاہیے: کیا ہوا، اس کا اصل مطلب کیا ہے، اس کا کیا اثر ہوتا ہے۔ اور ڈیش بورڈ کا لنک اور اس معاملے میں کیا کرنا ہے اس کی ہدایات بھی۔

یہ سب ایک الرٹ بنانے کی ضروریات کے بارے میں ہے۔ پھر صورت حال دو سمتوں میں ترقی کر سکتی ہے - یا تو کوئی مسئلہ ہے اور اسے حل کرنے کی ضرورت ہے، یا نگرانی کے نظام میں ناکامی ہوئی ہے۔ لیکن کسی بھی صورت میں، آپ کو جانے اور اس کا پتہ لگانے کی ضرورت ہے۔

اوسطاً، اب ہمیں روزانہ تقریباً سو الرٹس موصول ہوتے ہیں، اس حقیقت کو مدنظر رکھتے ہوئے کہ انتباہات کا باہمی تعلق ابھی تک درست طریقے سے ترتیب نہیں دیا گیا ہے۔ اور اگر ہمیں تکنیکی کام کرنے کی ضرورت ہے، اور ہم زبردستی کسی چیز کو بند کر دیتے ہیں، تو ان کی تعداد میں نمایاں اضافہ ہو جاتا ہے۔

ان سسٹمز کی نگرانی کرنے کے علاوہ جو ہم چلاتے ہیں اور میٹرکس اکٹھا کرتے ہیں جو ہماری طرف اہم سمجھے جاتے ہیں، نگرانی کا نظام ہمیں پروڈکٹ ٹیموں کے لیے ڈیٹا اکٹھا کرنے کی اجازت دیتا ہے۔ وہ انفارمیشن سسٹم کے اندر میٹرکس کی ساخت کو متاثر کر سکتے ہیں جن کی ہم نگرانی کرتے ہیں۔

ہمارا ساتھی آ کر کچھ میٹرک شامل کرنے کے لیے کہہ سکتا ہے جو ہمارے اور ٹیم دونوں کے لیے مفید ہو گا۔ یا، مثال کے طور پر، ٹیم کے پاس ہمارے پاس موجود بنیادی میٹرکس کافی نہیں ہیں؛ انہیں کچھ مخصوص کو ٹریک کرنے کی ضرورت ہے۔ Grafana میں، ہم ہر ٹیم کے لیے ایک جگہ بناتے ہیں اور منتظم کے حقوق دیتے ہیں۔ اس کے علاوہ، اگر کسی ٹیم کو ڈیش بورڈز کی ضرورت ہے، لیکن وہ خود نہیں جانتے/نہیں جانتے کہ اسے کیسے کرنا ہے، ہم ان کی مدد کرتے ہیں۔

چونکہ ہم ٹیم کی ویلیو تخلیق، ان کی ریلیزز اور منصوبہ بندی کے بہاؤ سے باہر ہیں، اس لیے ہم بتدریج اس نتیجے پر پہنچ رہے ہیں کہ تمام سسٹمز کی ریلیز بغیر کسی رکاوٹ کے ہیں اور ہمارے ساتھ ہم آہنگی کے بغیر اسے روزانہ جاری کیا جا سکتا ہے۔ اور ہمارے لیے ان ریلیز کی نگرانی کرنا ضروری ہے، کیونکہ وہ ممکنہ طور پر ایپلیکیشن کے عمل کو متاثر کر سکتے ہیں اور کچھ توڑ سکتے ہیں، اور یہ بہت اہم ہے۔ ریلیز کو منظم کرنے کے لیے، ہم بانس کا استعمال کرتے ہیں، جہاں سے ہم API کے ذریعے ڈیٹا حاصل کرتے ہیں اور یہ دیکھ سکتے ہیں کہ کون سی ریلیز جاری کی گئی ہیں جن میں انفارمیشن سسٹم اور ان کی حیثیت۔ اور سب سے اہم بات یہ ہے کہ کس وقت۔ ہم ریلیز مارکر کو اہم تنقیدی میٹرکس پر سپرپوز کرتے ہیں، جو کہ مسائل کی صورت میں بصری طور پر بہت زیادہ اشارہ کرتا ہے۔

اس طرح ہم نئی ریلیزز اور ابھرتے ہوئے مسائل کے درمیان ارتباط کو دیکھ سکتے ہیں۔ مرکزی خیال یہ سمجھنا ہے کہ سسٹم تمام پرتوں پر کیسے کام کرتا ہے، مسئلہ کو فوری طور پر مقامی بنانا اور اسے اتنی ہی جلدی ٹھیک کرنا ہے۔ سب کے بعد، یہ اکثر ہوتا ہے کہ جس چیز میں سب سے زیادہ وقت لگتا ہے وہ مسئلہ کو حل نہیں کر رہا ہے، لیکن وجہ تلاش کرنا ہے.

اور مستقبل میں اس علاقے میں ہم سرگرمی پر توجہ مرکوز کرنا چاہتے ہیں۔ مثالی طور پر، میں کسی قریب آنے والے مسئلے کے بارے میں پہلے سے جاننا چاہوں گا، نہ کہ حقیقت کے بعد، تاکہ میں اسے حل کرنے کے بجائے روک سکوں۔ بعض اوقات مانیٹرنگ سسٹم کے غلط الارم ہوتے ہیں، دونوں انسانی غلطیوں اور ایپلیکیشن میں تبدیلیوں کی وجہ سے۔ اور ہم اس پر کام کرتے ہیں، اسے ڈیبگ کرتے ہیں، اور ان صارفین کو خبردار کرنے کی کوشش کرتے ہیں جو مانیٹرنگ سسٹم میں کسی بھی قسم کی ہیرا پھیری سے پہلے اس کے بارے میں ہمارے ساتھ استعمال کرتے ہیں۔ ، یا تکنیکی ونڈو میں ان سرگرمیوں کو انجام دیں۔

لہذا، یہ نظام شروع کیا گیا ہے اور موسم بہار کے آغاز سے کامیابی سے کام کر رہا ہے... اور بہت حقیقی منافع دکھا رہا ہے۔ بلاشبہ یہ اس کا حتمی ورژن نہیں ہے؛ ہم بہت ساری مفید خصوصیات متعارف کرائیں گے۔ لیکن ابھی، بہت سارے انضمام اور ایپلی کیشنز کے ساتھ، آٹومیشن کی نگرانی کرنا واقعی ناگزیر ہے۔

اگر آپ بڑی تعداد میں انضمام کے ساتھ بڑے پروجیکٹس کی بھی نگرانی کرتے ہیں تو کمنٹس میں لکھیں کہ آپ کو اس کے لیے کون سی سلور بلٹ ملی۔

ماخذ: www.habr.com