ہیلو، حبر! میں دس سالوں سے ہائی لوڈ آئی ٹی سسٹم کو سپورٹ کر رہا ہوں۔ میں اس مضمون میں 1000+ RPS موڈ یا دیگر تکنیکی چیزوں میں کام کرنے کے لیے nginx کو ترتیب دینے کے مسائل کے بارے میں نہیں لکھوں گا۔ میں اس طرح کے نظاموں کے تعاون اور آپریشن میں پیدا ہونے والے عمل میں ہونے والی پریشانیوں کے بارے میں اپنے مشاہدات کا اشتراک کروں گا۔
نگرانی
تکنیکی مدد اس وقت تک انتظار نہیں کرتی جب تک کہ "کیا کیوں... سائٹ دوبارہ کام نہیں کر رہی؟" مواد کے ساتھ درخواست نہیں آتی۔ سائٹ کے کریش ہونے کے ایک منٹ کے اندر، سپورٹ کو پہلے سے ہی مسئلہ نظر آنا چاہیے اور اسے حل کرنا شروع کر دینا چاہیے۔ لیکن سائٹ آئس برگ کا سرہ ہے۔. اس کی دستیابی سب سے پہلے مانیٹر کرنے والوں میں سے ایک ہے۔
اس صورت حال کے ساتھ کیا کیا جائے جب آن لائن اسٹور کا باقی سامان ERP سسٹم سے نہیں آتا؟ یا کیا CRM سسٹم جو کلائنٹس کے لیے چھوٹ کا حساب لگاتا ہے نے جواب دینا بند کر دیا ہے؟ ایسا لگتا ہے کہ سائٹ کام کر رہی ہے۔ مشروط زیبکس کو اس کا 200 جواب موصول ہوتا ہے۔ ڈیوٹی شفٹ کو مانیٹرنگ سے کوئی اطلاع نہیں ملی ہے اور وہ گیم آف تھرونز کے نئے سیزن کی پہلی قسط خوشی سے دیکھ رہی ہے۔
نگرانی اکثر صرف میموری، RAM اور سرور پروسیسر لوڈ کی حالت کی پیمائش تک محدود ہوتی ہے۔ لیکن کاروبار کے لیے ویب سائٹ پر مصنوعات کی دستیابی حاصل کرنا بہت زیادہ اہم ہے۔ کلسٹر میں ایک ورچوئل مشین کی مشروط ناکامی اس حقیقت کا باعث بنے گی کہ ٹریفک اس کی طرف جانا بند کر دے گی اور دوسرے سرورز پر بوجھ بڑھ جائے گا۔ کمپنی پیسہ نہیں کھوئے گی۔
لہذا، سرورز پر آپریٹنگ سسٹم کے تکنیکی پیرامیٹرز کی نگرانی کے علاوہ، آپ کو کاروباری میٹرکس کو ترتیب دینے کی ضرورت ہے۔ میٹرکس جو پیسے کو براہ راست متاثر کرتی ہیں۔ بیرونی نظاموں (CRM، ERP اور دیگر) کے ساتھ مختلف تعاملات۔ ایک مخصوص مدت کے لیے آرڈرز کی تعداد۔ کامیاب یا ناکام کلائنٹ کی اجازت اور دیگر میٹرکس۔
بیرونی نظام کے ساتھ تعامل
کوئی بھی ویب سائٹ یا موبائل ایپلیکیشن جس کا سالانہ ٹرن اوور ایک ارب روبل سے زیادہ ہوتا ہے بیرونی نظاموں کے ساتھ تعامل کرتا ہے۔ مذکورہ بالا CRM اور ERP سے شروع ہو کر اور خریداریوں کا تجزیہ کرنے اور کلائنٹ کو ایک ایسی مصنوعات کی پیشکش کرنے کے لیے ایک بیرونی بگ ڈیٹا سسٹم میں سیلز ڈیٹا کی منتقلی کے ساتھ ختم ہوتا ہے جسے وہ یقینی طور پر خریدے گا (حقیقت میں نہیں)۔ ایسے ہر نظام کی اپنی حمایت ہوتی ہے۔ اور اکثر ان نظاموں کے ساتھ مواصلت درد کا باعث بنتی ہے۔ خاص طور پر جب مسئلہ عالمی ہو اور آپ کو مختلف سسٹمز میں اس کا تجزیہ کرنے کی ضرورت ہو۔
کچھ سسٹمز اپنے منتظمین کے لیے فون نمبر یا ٹیلی گرام فراہم کرتے ہیں۔ کہیں آپ کو مینیجرز کو خط لکھنے یا ان بیرونی سسٹمز کے بگ ٹریکرز کے پاس جانے کی ضرورت ہے۔ یہاں تک کہ ایک بڑی کمپنی کے تناظر میں بھی، مختلف نظام اکثر مختلف ایپلیکیشن اکاؤنٹنگ سسٹمز میں کام کرتے ہیں۔ بعض اوقات کسی درخواست کی حیثیت کو ٹریک کرنا ناممکن ہو جاتا ہے۔ آپ کو ایک مشروط جیرا میں درخواست موصول ہوتی ہے۔ پھر آپ نے اس پہلے جراثیم کے کمنٹ میں دوسرے جرح میں اس مسئلے کا لنک ڈال دیا۔ درخواست کے دوسرے جراثیم میں پہلے ہی کوئی تبصرہ لکھ رہا ہے کہ مسئلہ حل کرنے کے لیے آپ کو مشروط ایڈمن اینڈری کو کال کرنے کی ضرورت ہے۔ اور اسی طرح کی.
اس مسئلے کا بہترین حل یہ ہوگا کہ مواصلات کے لیے ایک جگہ بنائی جائے، مثال کے طور پر Slack میں۔ بیرونی نظام کو چلانے کے عمل میں شامل ہونے کے لیے تمام شرکاء کو مدعو کرنا۔ اور ایک سنگل ٹریکر بھی تاکہ ایپلی کیشنز کو ڈپلیکیٹ نہ کیا جائے۔ ایپلی کیشنز کو ایک ہی جگہ پر ٹریک کیا جانا چاہیے، مانیٹرنگ نوٹیفیکیشن سے لے کر مستقبل میں بگ حل کے آؤٹ پٹ تک۔ آپ کہیں گے کہ یہ غیر حقیقی ہے اور تاریخی طور پر ایسا ہوا ہے کہ ہم ایک ٹریکر میں کام کرتے ہیں اور وہ دوسرے میں کام کرتے ہیں۔ مختلف نظام نمودار ہوئے، ان کی اپنی خود مختار آئی ٹی ٹیمیں تھیں۔ میں متفق ہوں، اور اس لیے مسئلہ کو اوپر سے CIO یا پروڈکٹ کے مالک کی سطح پر حل کرنے کی ضرورت ہے۔
ہر وہ نظام جس کے ساتھ آپ تعامل کرتے ہیں اسے ترجیحی بنیادوں پر مسائل کو حل کرنے کے لیے ایک واضح SLA کے ساتھ ایک خدمت کے طور پر تعاون فراہم کرنا چاہیے۔ اور نہیں جب مشروط ایڈمن اینڈری کے پاس آپ کے لیے ایک منٹ ہو۔
Bottleneck Man
کیا پراجیکٹ (یا پروڈکٹ) پر ہر ایک کے پاس کوئی ایسا شخص ہوتا ہے جس کے چھٹیوں پر جانا ان کے اعلیٰ افسران کے درمیان ہنگامہ آرائی کا سبب بنتا ہے؟ یہ ڈیوپس انجینئر، تجزیہ کار یا ڈویلپر ہوسکتا ہے۔ سب کے بعد، صرف ایک ڈیوپس انجینئر جانتا ہے کہ کن سرورز میں کن کنٹینرز نصب ہیں، کسی مسئلہ کی صورت میں کنٹینر کو کیسے ریبوٹ کیا جائے، اور عام طور پر، کوئی بھی پیچیدہ مسئلہ اس کے بغیر حل نہیں ہو سکتا۔ تجزیہ کار صرف وہی ہے جو جانتا ہے کہ آپ کا پیچیدہ طریقہ کار کیسے کام کرتا ہے۔ کون سا ڈیٹا اسٹریمز کہاں جاتا ہے۔ درخواستوں کے کن پیرامیٹرز کے تحت ہمیں کن خدمات کے جوابات موصول ہوں گے۔
کون جلدی سمجھے گا کہ لاگز میں خرابیاں کیوں ہیں اور فوری طور پر پروڈکٹ میں ایک اہم بگ کو ٹھیک کرے گا؟ یقیناً وہی ڈویلپر۔ اور بھی ہیں، لیکن صرف کسی وجہ سے وہ سمجھتا ہے کہ سسٹم کے مختلف ماڈیول کیسے کام کرتے ہیں۔
اس مسئلے کی جڑ دستاویزات کی کمی ہے۔. سب کے بعد، اگر آپ کے سسٹم کی تمام خدمات بیان کی جاتی ہیں، تو تجزیہ کار کے بغیر مسئلہ سے نمٹنے کے لئے ممکن ہو گا. اگر ڈیوپس نے اپنے مصروف شیڈول میں سے کچھ دن نکال کر عام مسائل کے حل کے لیے تمام سرورز، خدمات اور ہدایات بیان کیں، تو اس کی غیر موجودگی میں مسئلہ اس کے بغیر حل ہو سکتا ہے۔ آپ کو چھٹی کے وقت ساحل سمندر پر اپنی بیئر کو جلدی ختم کرنے کی ضرورت نہیں ہے اور مسئلہ کو حل کرنے کے لیے وائی فائی تلاش کریں۔
معاون عملے کی اہلیت اور ذمہ داری
بڑے منصوبوں پر، کمپنیاں ڈویلپر کی تنخواہوں میں کمی نہیں کرتی ہیں۔ وہ اسی طرح کے منصوبوں سے مہنگے مڈل یا بزرگوں کی تلاش میں ہیں۔ حمایت کے ساتھ صورتحال تھوڑی مختلف ہے۔ وہ ہر ممکن طریقے سے ان اخراجات کو کم کرنے کی کوشش کر رہے ہیں۔ کمپنیاں سستے کل کے Enikey کارکنوں کی خدمات حاصل کرتی ہیں اور دلیری سے جنگ میں جاتی ہیں۔ یہ حکمت عملی ممکن ہے اگر ہم Zelenograd میں ایک پلانٹ کے بزنس کارڈ کی ویب سائٹ کے بارے میں بات کر رہے ہیں۔
اگر ہم ایک بڑے آن لائن سٹور کے بارے میں بات کر رہے ہیں، تو ہر گھنٹے کے ڈاؤن ٹائم کی قیمت ایک اینیکی ایڈمنسٹریٹر کی ماہانہ تنخواہ سے زیادہ ہے۔ آئیے ایک نقطہ آغاز کے طور پر سالانہ ٹرن اوور کے 1 بلین روبل لیں۔ یہ درجہ بندی سے کسی بھی آن لائن اسٹور کا کم از کم کاروبار ہے۔ . اس رقم کو ہر سال گھنٹوں کی تعداد سے تقسیم کریں اور 100 روبل سے زیادہ خالص نقصانات حاصل کریں۔ اور اگر آپ رات کے اوقات شمار نہیں کرتے ہیں، تو آپ محفوظ طریقے سے رقم کو دوگنا کر سکتے ہیں۔
لیکن پیسہ بنیادی چیز نہیں ہے، ٹھیک ہے؟ (نہیں، یقیناً اہم بات) شہرت کے نقصانات بھی ہیں۔ ایک معروف آن لائن سٹور کا زوال سوشل نیٹ ورکس اور موضوعاتی میڈیا میں اشاعتوں پر جائزوں کی لہر کا سبب بن سکتا ہے۔ اور باورچی خانے میں دوستوں کی گفتگو کو "وہاں کچھ نہ خریدیں، ان کی ویب سائٹ ہمیشہ ڈاؤن رہتی ہے" کے انداز میں بالکل بھی ناپا نہیں جا سکتا۔
اب ذمہ داری کی طرف۔ میری پریکٹس میں، ایک ایسا معاملہ تھا جب ڈیوٹی پر موجود ایڈمنسٹریٹر نے سائٹ کی عدم دستیابی کے بارے میں مانیٹرنگ سسٹم کی طرف سے اطلاع کا بروقت جواب نہیں دیا۔ جمعہ کی شام ایک خوشگوار موسم گرما میں، ماسکو میں ایک معروف آن لائن اسٹور کی ویب سائٹ خاموشی سے پڑی تھی۔ ہفتہ کی صبح، اس سائٹ کے پروڈکٹ مینیجر کو یہ سمجھ نہیں آیا کہ سائٹ کیوں نہیں کھلی، اور سلیک میں سپورٹ اور فوری نوٹیفکیشن چیٹس میں خاموشی تھی۔ اس طرح کی غلطی کی وجہ سے ہمیں چھ اعداد و شمار کی رقم ادا کرنا پڑی، اور اس ڈیوٹی آفیسر نے اپنی نوکری کی۔
ذمہ داری تیار کرنا ایک مشکل ہنر ہے۔ یا تو کسی شخص کے پاس ہے یا نہیں۔ لہذا، انٹرویو کے دوران، میں مختلف سوالات کے ساتھ اس کی موجودگی کی نشاندہی کرنے کی کوشش کرتا ہوں جو بالواسطہ طور پر ظاہر کرتے ہیں کہ آیا کوئی شخص ذمہ داری لینے کا عادی ہے یا نہیں۔ اگر کوئی شخص جواب دیتا ہے کہ اس نے یونیورسٹی کا انتخاب اس لیے کیا کہ اس کے والدین نے ایسا کہا تھا یا اس کی بیوی نے کہا تھا کہ وہ کافی کماتا نہیں ہے، تو بہتر ہے کہ ایسے لوگوں کے ساتھ نہ پڑیں۔
ترقیاتی ٹیم کے ساتھ تعامل
جب صارفین کو آپریشن کے دوران کسی پروڈکٹ کے ساتھ آسان مسائل کا سامنا کرنا پڑتا ہے، تو سپورٹ انہیں خود ہی حل کر دیتی ہے۔ مسئلہ کو دوبارہ پیش کرنے کی کوشش کرتا ہے، نوشتہ جات کا تجزیہ کرتا ہے، وغیرہ۔ لیکن جب پروڈکٹ میں بگ ظاہر ہو تو کیا کریں؟ اس صورت میں، سپورٹ ڈویلپرز کو کام تفویض کرتا ہے اور یہیں سے مزہ شروع ہوتا ہے۔
ڈویلپرز مسلسل اوورلوڈ ہیں۔ وہ نئی خصوصیات بنا رہے ہیں۔ سیلز کے ساتھ کیڑے ٹھیک کرنا سب سے دلچسپ سرگرمی نہیں ہے۔ اگلی سپرنٹ مکمل کرنے کے لیے آخری تاریخیں قریب آ رہی ہیں۔ اور پھر حمایت سے ناخوشگوار لوگ آتے ہیں اور کہتے ہیں: "فوری طور پر سب کچھ چھوڑ دو، ہمیں پریشانی ہے۔" ایسے کاموں کی ترجیح کم سے کم ہے۔ خاص طور پر جب مسئلہ سب سے زیادہ نازک نہ ہو اور سائٹ کی بنیادی فعالیت کام کر رہی ہو، اور جب ریلیز مینیجر ابھری ہوئی آنکھوں کے ساتھ ادھر ادھر نہیں بھاگتا اور لکھتا ہے: "فوری طور پر اس کام کو اگلی ریلیز یا ہاٹ فکس میں شامل کریں۔"
عام یا کم ترجیح والے مسائل کو ریلیز سے ریلیز میں منتقل کیا جاتا ہے۔ اس سوال پر کہ "کام کب مکمل ہوگا؟" آپ کو اس انداز میں جوابات موصول ہوں گے: "معذرت، ابھی بہت سارے کام ہیں، اپنی ٹیم کے لیڈز سے پوچھیں یا منیجر کو ریلیز کریں۔"
پیداواری مسائل نئی خصوصیات بنانے سے زیادہ ترجیح دیتے ہیں۔ اگر صارفین مسلسل کیڑے سے ٹھوکر کھاتے رہتے ہیں تو برے جائزے آنے میں زیادہ دیر نہیں لگے گی۔ تباہ شدہ ساکھ بحال کرنا مشکل ہے۔
ترقی اور تعاون کے درمیان تعامل کے مسائل DevOps کے ذریعے حل کیے جاتے ہیں۔ یہ مخفف اکثر ایک مخصوص شخص کی شکل میں استعمال ہوتا ہے جو ترقی کے لیے ٹیسٹ ماحول پیدا کرنے میں مدد کرتا ہے، CICD پائپ لائنز بناتا ہے اور ٹیسٹ شدہ کوڈ کو تیزی سے پیداوار میں لاتا ہے۔ DevOps سافٹ ویئر ڈویلپمنٹ کا ایک نقطہ نظر ہے جب اس عمل میں شامل تمام شرکاء ایک دوسرے کے ساتھ قریب سے بات چیت کرتے ہیں اور سافٹ ویئر کی مصنوعات اور خدمات کو تیزی سے بنانے اور اپ ڈیٹ کرنے میں مدد کرتے ہیں۔ میرا مطلب ہے تجزیہ کار، ڈویلپرز، ٹیسٹرز اور سپورٹ۔
اس نقطہ نظر میں، حمایت اور ترقی ان کے اپنے مقاصد اور مقاصد کے ساتھ مختلف محکمے نہیں ہیں. ترقی آپریشن میں شامل ہے اور اس کے برعکس۔ تقسیم شدہ ٹیموں کا مشہور جملہ: "مسئلہ میری طرف نہیں ہے" اب چیٹس میں اتنی کثرت سے ظاہر نہیں ہوتا ہے، اور اختتامی صارفین قدرے خوش ہو جاتے ہیں۔
ماخذ: www.habr.com