سب کو جمعہ مبارک! دوستو، آج ہم کورس کے لیے وقف اشاعتوں کا سلسلہ جاری رکھے ہوئے ہیں۔ کیونکہ کورس کے لیے نئے گروپ میں کلاسز اگلے ہفتے کے آخر میں شروع ہوں گی۔ تو، چلو شروع کرتے ہیں!
نگرانی ہے۔ صرف. یہ ایک معلوم حقیقت ہے۔ ناگیوس کو لائیں، ریموٹ سسٹم پر NRPE چلائیں، NRPE TCP پورٹ 5666 پر Nagios کو کنفیگر کریں اور آپ کی نگرانی ہے۔
یہ اتنا آسان ہے کہ یہ دلچسپ نہیں ہے۔ اب آپ کے پاس CPU ٹائم، ڈسک سب سسٹم، RAM کے لیے بنیادی میٹرکس ہیں، جو Nagios اور NRPE کو بطور ڈیفالٹ فراہم کیے جاتے ہیں۔ لیکن یہ دراصل اس طرح کی "مانیٹرنگ" نہیں ہے۔ یہ تو ابھی شروعات ہے۔
(عام طور پر وہ PNP4Nagios، RRDtool اور Thruk انسٹال کرتے ہیں، Slack میں نوٹیفیکیشن مرتب کرتے ہیں اور سیدھے nagiosexchange پر جاتے ہیں، لیکن آئیے اسے ابھی کے لیے چھوڑ دیں)۔
اچھی نگرانی درحقیقت کافی پیچیدہ ہے، آپ کو واقعی اس ایپلی کیشن کے اندرونی حصوں کو جاننے کی ضرورت ہے جس کی آپ نگرانی کر رہے ہیں۔
کیا نگرانی مشکل ہے؟
کوئی بھی سرور، چاہے وہ لینکس ہو یا ونڈوز، تعریف کے مطابق کچھ مقصد پورا کرے گا۔ اپاچی، سامبا، ٹامکیٹ، فائل اسٹوریج، ایل ڈی اے پی - یہ تمام سروسز ایک یا زیادہ حوالوں سے کم و بیش منفرد ہیں۔ ہر ایک کا اپنا کام ہے، اس کی اپنی خصوصیات ہیں۔ میٹرکس، KPIs (اہم کارکردگی کے اشارے) حاصل کرنے کے مختلف طریقے ہیں جو آپ کے لیے اس وقت دلچسپ ہوتے ہیں جب سرور بوجھ کے نیچے ہو۔
تصویر کا مصنف پر
(کاش میرے ڈیش بورڈز نیون نیلے ہوتے - خوابیدہ سانس لیتے ہوئے -... ہمم...)
کوئی بھی سافٹ ویئر جو خدمات فراہم کرتا ہے اس کے پاس میٹرکس جمع کرنے کا طریقہ کار ہونا ضروری ہے۔ اپاچی کا ایک ماڈیول ہے۔ mod-status، سرور کی حیثیت کا صفحہ دکھا رہا ہے۔ Nginx کے پاس - stub_status. Tomcat میں JMX یا حسب ضرورت ویب ایپلیکیشنز ہیں جو کلیدی میٹرکس دکھاتی ہیں۔ مائی ایس کیو ایل کے پاس کمانڈ ہے "عالمی حیثیت دکھائیں" وغیرہ۔
تو کیوں ڈویلپرز اپنی تخلیق کردہ ایپلی کیشنز میں اسی طرح کے میکانزم نہیں بناتے ہیں؟
کیا صرف ڈویلپر ہی ایسا کر رہے ہیں؟
میٹرکس ایمبیڈنگ سے لاتعلقی کی ایک خاص سطح صرف ڈویلپرز تک محدود نہیں ہے۔ میں نے ان کمپنیوں میں کام کیا جہاں انہوں نے Tomcat کا استعمال کرتے ہوئے ایپلی کیشنز تیار کیں اور عام ٹامکیٹ ایرر لاگز کے علاوہ اپنی کوئی بھی میٹرکس، سروس کی سرگرمی کا کوئی لاگس فراہم نہیں کیا۔ کچھ ڈویلپرز بہت سارے لاگز تیار کرتے ہیں جن کا سسٹم ایڈمنسٹریٹر کے لیے کوئی مطلب نہیں ہوتا جو صبح 3:15 پر پڑھنے کے لیے کافی بدقسمت ہے۔
تصویر کا مصنف پر
سسٹم انجینئرز جو اس طرح کی مصنوعات کو جاری کرنے کے قابل بناتے ہیں ان کو بھی صورت حال کی کچھ ذمہ داری اٹھانا ہوگی۔ بہت کم سسٹم انجینئرز کے پاس لاگز سے بامعنی میٹرکس نکالنے کی کوشش کرنے کا وقت یا خیال ہوتا ہے، ان میٹرکس کے سیاق و سباق کے بغیر اور درخواست کی سرگرمی کی روشنی میں ان کی تشریح کرنے کی صلاحیت کے۔ کچھ سمجھ نہیں پا رہے ہیں کہ وہ اس سے کیسے فائدہ اٹھا سکتے ہیں، اس کے علاوہ "کچھ فی الحال غلط ہے (یا جلد ہی ہوگا)" اشارے۔
میٹرکس کی ضرورت کے حوالے سے سوچ میں تبدیلی نہ صرف ڈویلپرز بلکہ سسٹم انجینئرز کے درمیان بھی ہونی چاہیے۔
کسی بھی سسٹم انجینئر کے لیے جسے نہ صرف اہم واقعات کا جواب دینے کی ضرورت ہوتی ہے، بلکہ اس بات کو بھی یقینی بنانا ہوتا ہے کہ وہ رونما نہ ہوں، میٹرکس کی کمی عام طور پر ایسا کرنے میں ایک رکاوٹ ہوتی ہے۔
تاہم، سسٹم انجینئرز عام طور پر اپنی کمپنی کے لیے پیسہ کمانے کے لیے کوڈ کے ساتھ ٹنکر نہیں کرتے ہیں۔ انہیں ایسے لیڈ ڈویلپرز کی ضرورت ہے جو مسائل کی نشاندہی کرنے، کارکردگی کے مسائل کے بارے میں بیداری پیدا کرنے اور اس طرح کی چیزوں میں سسٹم انجینئر کی ذمہ داری کی اہمیت کو سمجھتے ہوں۔
یہ چیز کو ختم کر دیتی ہے۔
ڈیوپس ذہنیت ترقی (ڈیو) اور آپریشنز (اوپس) سوچ کے درمیان ہم آہنگی کو بیان کرتی ہے۔ کوئی بھی کمپنی جو "ڈوپس" کرنے کا دعوی کرتی ہے اسے لازمی ہے:
- وہ باتیں جو وہ شاید نہیں کہتے (The Princess Bride meme کا حوالہ دیتے ہوئے - "مجھے نہیں لگتا کہ اس کا مطلب وہی ہے جو آپ کے خیال میں اس کا مطلب ہے!")
- مسلسل مصنوعات کی بہتری کے رویے کی حوصلہ افزائی کریں۔
آپ کسی پروڈکٹ کو بہتر نہیں بنا سکتے اور جانتے ہیں کہ اس میں بہتری آئی ہے اگر آپ نہیں جانتے کہ یہ فی الحال کیسے کام کرتی ہے۔ آپ نہیں جان سکتے کہ کوئی پروڈکٹ کیسے کام کرتا ہے اگر آپ یہ نہیں سمجھتے کہ اس کے اجزاء کیسے کام کرتے ہیں، وہ خدمات جن پر یہ منحصر ہے، اس کے بنیادی درد کے مقامات اور رکاوٹیں ہیں۔
اگر آپ ممکنہ رکاوٹوں کو نہیں دیکھتے ہیں، تو آپ پوسٹ مارٹم لکھتے وقت فائیو وائز تکنیک پر عمل نہیں کر پائیں گے۔ آپ یہ دیکھنے کے لیے ہر چیز کو ایک اسکرین پر نہیں رکھ پائیں گے کہ کوئی پروڈکٹ کیسے کام کرتا ہے یا یہ جان سکتا ہے کہ یہ "عام اور خوش کن" کیسا لگتا ہے۔
بائیں، بائیں شفٹ، میں نے کہا لی-
میرے لیے ڈیوپس کے کلیدی اصولوں میں سے ایک "بائیں شفٹ" ہے۔ اس تناظر میں بائیں شفٹ کا مطلب ہے امکان کو تبدیل کرنا (کوئی ذمہ داری نہیں، لیکن صرف صلاحیتیں) وہ کام کرنے کے لیے جن کا نظام انجینئرز عام طور پر خیال رکھتے ہیں، جیسے کہ کارکردگی کے میٹرکس بنانا، لاگ کو زیادہ موثر طریقے سے استعمال کرنا، وغیرہ، سافٹ ویئر ڈیلیوری لائف سائیکل میں بائیں جانب۔
تصویر کا مصنف پر
سافٹ ویئر ڈویلپرز کو ان مانیٹرنگ ٹولز کو استعمال کرنے اور جاننے کے قابل ہونا چاہیے جو کمپنی اپنی تمام شکلوں، میٹرکس، لاگنگ، مانیٹرنگ انٹرفیس اور سب سے اہم بات میں نگرانی کرنے کے لیے استعمال کرتی ہے۔ دیکھیں کہ ان کی پروڈکٹ پروڈکشن میں کیسے کام کرتی ہے۔. آپ ڈیولپرز کو نگرانی میں کوشش اور وقت لگانے کے لیے اس وقت تک حاصل نہیں کر سکتے جب تک کہ وہ میٹرکس کو نہ دیکھ سکیں اور اس بات پر اثر انداز نہ ہوں کہ وہ کس طرح نظر آتے ہیں، پروڈکٹ کا مالک انہیں اگلی بریفنگ میں CTO کے سامنے کیسے پیش کرتا ہے، وغیرہ۔
کچھ ہی دیر میں بول رہا ہوں
- اپنے گھوڑے کو پانی کی طرف لے جائیں۔ ڈویلپرز کو دکھائیں کہ وہ اپنے لیے کتنی پریشانی سے بچ سکتے ہیں، ان کی ایپلی کیشنز کے لیے صحیح KPIs اور میٹرکس کی نشاندہی کرنے میں ان کی مدد کریں تاکہ پروڈکٹ کے مالک کی طرف سے کم چیخیں نکلیں جس پر CTO کی طرف سے چیخ پکار کی جا رہی ہے۔ انہیں روشنی میں لائیں، نرمی اور سکون سے۔ اگر یہ کام نہیں کرتا ہے، تو رشوت دیں، دھمکی دیں، اور انہیں یا پروڈکٹ کے مالک کو درخواست سے ان میٹرکس کو جلد از جلد حاصل کرنے پر عمل درآمد کریں، اور پھر خاکے بنائیں۔ یہ مشکل ہو گا کیونکہ اسے ترجیح کے طور پر نہیں دیکھا جائے گا اور پروڈکٹ کے روڈ میپ میں آمدنی پیدا کرنے والے بہت سے منصوبے زیر التوا ہوں گے۔ اس لیے، آپ کو پروڈکٹ میں مانیٹرنگ کو لاگو کرنے کے لیے خرچ کیے گئے وقت اور اخراجات کا جواز پیش کرنے کے لیے ایک کاروباری کیس کی ضرورت ہوگی۔
- سسٹم انجینئرز کو اچھی رات کی نیند لینے میں مدد کریں۔ انہیں دکھائیں کہ جاری ہونے والی کسی بھی پروڈکٹ کے لیے "چلو جاری کریں" چیک لسٹ کا استعمال ایک اچھی چیز ہے۔ اور اس بات کو یقینی بنانا کہ پروڈکشن میں موجود تمام ایپلیکیشنز میٹرکس سے ڈھکی ہوئی ہیں، آپ کو رات کو بہتر سونے میں مدد ملے گی تاکہ آپ ڈویلپرز کو یہ دیکھ سکیں کہ کیا غلط ہو رہا ہے اور کہاں۔ تاہم، کسی بھی ڈویلپر، پروڈکٹ کے مالک، یا CTO کو غصہ دلانے اور مایوس کرنے کا صحیح طریقہ ثابت قدم رہنا اور مزاحمت کرنا ہے۔ اگر آپ دوبارہ آخری منٹ تک انتظار کرتے ہیں تو یہ طرز عمل کسی بھی پروڈکٹ کی ریلیز کی تاریخ کو متاثر کرے گا، اس لیے دوبارہ بائیں شفٹ ہو جائیں اور ان مسائل کو جلد از جلد اپنے پروجیکٹ پلان میں شامل کریں۔ اگر ضروری ہو تو، پروڈکٹ میٹنگز کے لیے اپنا راستہ بنائیں۔ جعلی مونچھیں پہنیں اور محسوس کریں یا کچھ اور، یہ کبھی ناکام نہیں ہوگا۔ اپنے خدشات سے آگاہ کریں، واضح فوائد کا مظاہرہ کریں، اور انجیلی بشارت دیں۔
- اس بات کو یقینی بنائیں کہ ترقی (dev) اور آپریشنز (ops) دونوں پروڈکٹ میٹرکس کے ریڈ زون میں جانے کے معنی اور نتائج کو سمجھتے ہیں۔ Ops کو پروڈکٹ کی صحت کے واحد سرپرست کے طور پر مت چھوڑیں، یقینی بنائیں کہ ڈویلپر بھی اس میں شامل ہیں (#productsquads)۔
- لاگز ایک عظیم چیز ہیں، لیکن میٹرکس بھی ہیں۔ ان کو یکجا کریں اور اپنے لاگز کو بیکار کی ایک بڑی بھڑکتی ہوئی گیند میں ردی کی ٹوکری میں نہ بننے دیں۔ ڈیولپرز کو سمجھائیں اور دکھائیں کہ کوئی اور ان کے لاگز کو کیوں نہیں سمجھے گا، انہیں دکھائیں کہ صبح 3:15 بجے بیکار لاگز کو دیکھنا کیسا لگتا ہے۔
تصویر کا مصنف پر
بس۔ نیا مواد اگلے ہفتے جاری کیا جائے گا۔ اگر آپ کورس کے بارے میں مزید جاننا چاہتے ہیں، تو ہم آپ کو مدعو کرتے ہیں۔ ، جو پیر کو ہوگا۔ اور اب ہم روایتی طور پر آپ کے تبصروں کا انتظار کر رہے ہیں۔
ماخذ: www.habr.com