آئی ٹی کمپنی کو 2019 میں کامیاب ہونے کے لیے کیا ضرورت ہے؟ کانفرنسوں اور میٹنگوں میں لیکچررز بہت اونچی آواز میں بولتے ہیں جو عام لوگوں کے لیے ہمیشہ سمجھ میں نہیں آتے۔ تعیناتی کے وقت کے لیے جدوجہد، مائیکرو سروسز، یک سنگی کو ترک کرنا، DevOps کی تبدیلی اور بہت کچھ۔ اگر ہم زبانی خوبصورتی کو ترک کرتے ہیں اور براہ راست اور روسی زبان میں بات کرتے ہیں، تو یہ سب ایک سادہ تھیسس پر آتا ہے: ایک اعلیٰ معیار کی پروڈکٹ بنائیں، اور ٹیم کے لیے آرام کے ساتھ کریں۔
مؤخر الذکر تنقیدی طور پر اہم ہو گیا ہے۔ کاروبار بالآخر اس نتیجے پر پہنچا ہے کہ ایک آرام دہ ترقی کا عمل پیداواری صلاحیت کو بڑھاتا ہے، اور اگر ہر چیز کو ڈیبگ کیا جائے اور گھڑی کی طرح کام کیا جائے، تو یہ نازک حالات میں تدبیر کے لیے کچھ گنجائش بھی فراہم کرتا ہے۔ ایک زمانے میں، اس تدبیر کی خاطر، ایک خاص ذہین شخص بیک اپ لے کر آیا، لیکن صنعت ترقی کر رہی ہے، اور ہمارے پاس DevOps انجینئرز آئے - وہ لوگ جو ترقی اور بیرونی انفراسٹرکچر کے درمیان تعامل کے عمل کو مناسب چیز میں بدل دیتے ہیں اور shamanism سے متعلق نہیں.
یہ پوری "ماڈیولر" کہانی حیرت انگیز ہے، لیکن... ایسا ہوا کہ کچھ ایڈمنز کو اچانک ڈی او اوپس کا نام دیا گیا، اور خود ڈی او اوپس انجینئرز کو ٹیلی پیتھی اور کلیر وائینس کی کم از کم مہارت کی ضرورت پڑنے لگی۔
اس سے پہلے کہ ہم بنیادی ڈھانچے کی فراہمی کے جدید مسائل کے بارے میں بات کریں، آئیے اس اصطلاح کی وضاحت کرتے ہیں کہ ہمارا کیا مطلب ہے۔ موجودہ لمحے میں، صورت حال اس طرح سے تیار ہوئی ہے کہ ہم اس تصور کی دوائی تک پہنچ چکے ہیں: بنیادی ڈھانچہ مشروط طور پر بیرونی اور مشروط طور پر اندرونی ہو سکتا ہے۔
بیرونی انفراسٹرکچر سے ہمارا مطلب ہر وہ چیز ہے جو ٹیم تیار کر رہی سروس یا پروڈکٹ کی فعالیت کو یقینی بناتی ہے۔ یہ ایپلیکیشن یا ویب سائٹ سرورز، ہوسٹنگ اور دیگر خدمات ہیں جو پروڈکٹ کی فعالیت کو یقینی بناتے ہیں۔
اندرونی انفراسٹرکچر میں خدمات اور آلات شامل ہیں جو خود ترقیاتی ٹیم اور دیگر ملازمین استعمال کرتے ہیں، جن میں سے عام طور پر بہت سے ہوتے ہیں۔ یہ کوڈ اسٹوریج سسٹمز کے اندرونی سرورز ہیں، مقامی طور پر تعینات ٹاسک مینیجر اور ہر چیز، ہر چیز، ہر وہ چیز جو کارپوریٹ انٹرانیٹ کے اندر موجود ہے۔
سسٹم ایڈمنسٹریٹر کمپنی میں کیا کرتا ہے؟ اس انتہائی کارپوریٹ انٹرانیٹ کے انتظام کے کام کے علاوہ، یہ دفتری آلات کی آپریٹیبلٹی کو یقینی بنانے کے لیے اکثر معاشی خدشات کا بوجھ اٹھاتا ہے۔ ایڈمن وہی آدمی ہے جو پچھلے کمرے سے ایک نیا سسٹم یونٹ یا استعمال کے لیے تیار اسپیئر لیپ ٹاپ کو تیزی سے گھسیٹ کر لے جائے گا، ایک تازہ کی بورڈ دے گا اور ایتھرنیٹ کیبل کو پھیلاتے ہوئے دفاتر کے چاروں طرف رینگے گا۔ منتظم نہ صرف اندرونی اور بیرونی سرورز کا مقامی مالک اور حکمران ہوتا ہے بلکہ ایک کاروباری ایگزیکٹو بھی ہوتا ہے۔ ہاں، کچھ منتظمین ہارڈ ویئر کے بغیر صرف سسٹم کے جہاز میں کام کر سکتے ہیں۔ انہیں "انفراسٹرکچر سسٹم ایڈمنسٹریٹرز" کے الگ ذیلی طبقے میں الگ کیا جانا چاہیے۔ اور کچھ خاص طور پر دفتری آلات کی خدمت میں مہارت رکھتے ہیں؛ خوش قسمتی سے، اگر کمپنی میں سو سے زیادہ افراد ہوں، تو کام کبھی ختم نہیں ہوتا۔ لیکن ان میں سے کوئی بھی ڈیوپس نہیں ہے۔
DevOps کون ہیں؟ ڈیوپس وہ لوگ ہیں جو بیرونی انفراسٹرکچر کے ساتھ سافٹ ویئر ڈویلپمنٹ کے تعامل کے بارے میں بات کرتے ہیں۔ مزید واضح طور پر، جدید ڈیوپس ترقی اور تعیناتی کے عمل میں ان ایڈمنز کے مقابلے میں بہت گہرے شامل ہیں جنہوں نے ftp پر اپ ڈیٹس اپ لوڈ کیں جو کبھی شامل تھے۔ DevOps انجینئر کے اہم کاموں میں سے ایک اب ترقیاتی ٹیموں اور مصنوعات کے بنیادی ڈھانچے کے درمیان بات چیت کے ایک آرام دہ اور مؤثر طریقے سے تشکیل شدہ عمل کو یقینی بنانا ہے۔ یہ وہ لوگ ہیں جو رول بیک اور تعیناتی کے نظام کی تعیناتی کے ذمہ دار ہیں؛ یہی لوگ ہیں جو ڈویلپرز کا کچھ بوجھ اٹھاتے ہیں اور اپنے انتہائی اہم کام پر زیادہ سے زیادہ توجہ مرکوز کرتے ہیں۔ ایک ہی وقت میں، ڈیوپس کبھی بھی نئی کیبل نہیں چلائیں گے یا پچھلے کمرے سے نیا لیپ ٹاپ جاری نہیں کریں گے (c) KO
کیچ کیا ہے؟
اس سوال پر کہ "ڈیو اوپس کون ہے؟" فیلڈ میں آدھے کارکن کچھ جواب دینا شروع کر دیتے ہیں جیسے "ٹھیک ہے، مختصر میں، یہ وہ ایڈمن ہے جو..." اور مزید متن میں۔ جی ہاں، ایک زمانے میں، جب DevOps انجینئر کا پیشہ صرف سروس مینٹیننس کے لحاظ سے انتہائی باصلاحیت منتظمین سے ابھر رہا تھا، ان کے درمیان اختلافات ہر کسی کے لیے واضح نہیں تھے۔ لیکن اب، جب ٹیم میں ڈیوپس اور ایڈمن کے افعال یکسر مختلف ہو چکے ہیں، تو انہیں ایک دوسرے کے ساتھ الجھانا، یا حتیٰ کہ ان کے برابر کرنا بھی ناقابل قبول ہے۔
لیکن کاروبار کے لیے اس کا کیا مطلب ہے؟
بھرتی، یہ سب اس کے بارے میں ہے.
آپ "سسٹم ایڈمنسٹریٹر" کے لیے ایک آسامی کھولتے ہیں، اور وہاں درج تقاضے "ترقی اور صارفین کے ساتھ تعامل"، "CI/CD ڈیلیوری سسٹم"، "کمپنی کے سرورز اور آلات کی دیکھ بھال"، "اندرونی نظام کی انتظامیہ" وغیرہ ہیں۔ پر آپ سمجھتے ہیں کہ آجر بکواس کر رہا ہے۔ کیچ یہ ہے کہ "سسٹم ایڈمنسٹریٹر" کے بجائے خالی جگہ کا عنوان "DevOps انجینئر" ہونا چاہئے، اور اگر اس عنوان کو تبدیل کر دیا جائے تو سب کچھ اپنی جگہ پر آجاتا ہے۔
تاہم، اس طرح کی خالی جگہ کو پڑھ کر کیا تاثر ملتا ہے؟ کہ کمپنی ایک ملٹی مشین آپریٹر کی تلاش میں ہے جو ایک ورژن کنٹرول اور مانیٹرنگ سسٹم دونوں کو تعینات کرے گا اور اپنے دانتوں سے ٹوئسٹر کو نچوڑ دے گا...
لیکن لیبر مارکیٹ میں منشیات کی لت میں اضافہ نہ کرنے کے لیے، خالی آسامیوں کو ان کے مناسب ناموں سے پکارنا اور واضح طور پر سمجھنا کافی ہے کہ ایک DevOps انجینئر اور ایک سسٹم ایڈمنسٹریٹر دو مختلف ادارے ہیں۔ لیکن کچھ آجروں کی ایک امیدوار کو ضروریات کی وسیع ترین ممکنہ فہرست پیش کرنے کی ناقابل تلافی خواہش اس حقیقت کی طرف لے جاتی ہے کہ "کلاسک" سسٹم کے منتظمین یہ سمجھنا چھوڑ دیتے ہیں کہ ان کے آس پاس کیا ہو رہا ہے۔ کیا، پیشہ بدل رہا ہے اور وہ زمانے سے پیچھے ہیں۔
نہیں نہیں اور ایک بار پھر نہیں۔ انفراسٹرکچر ایڈمنسٹریٹر جو کمپنی کے اندرونی سرورز کا انتظام کریں گے، یا L2/L3 سپورٹ پوزیشنز پر قابض ہوں گے اور دوسرے ملازمین کی مدد کریں گے، وہ دور نہیں ہوئے اور نہ ہی چلے جائیں گے۔
کیا یہ ماہرین DevOps انجینئر بن سکتے ہیں؟ یقیناً وہ کر سکتے ہیں۔ درحقیقت، یہ ایک متعلقہ ماحول ہے جس کے لیے سسٹم ایڈمنسٹریشن کی مہارتوں کی ضرورت ہوتی ہے، لیکن اس کے علاوہ، نگرانی، ترسیل کے نظام اور عمومی طور پر، ترقی اور جانچ ٹیم کے ساتھ قریبی تعامل کو شامل کیا جاتا ہے۔
ایک اور DevOps مسئلہ
درحقیقت، سب کچھ صرف بھرتی کرنے اور ایڈمنز اور ڈیوپس کے درمیان مسلسل الجھن تک محدود نہیں ہے۔ کسی وقت، کاروبار کو حتمی انفراسٹرکچر کے ساتھ اپ ڈیٹس فراہم کرنے اور ترقیاتی ٹیم کے تعامل کے مسئلے کا سامنا تھا۔
شاید یہ تھا جب چمکتی ہوئی آنکھوں کے ساتھ ایک چچا کسی کانفرنس کے اسٹیج پر کھڑے ہوئے اور کہا، "ہم یہ کرتے ہیں اور اسے DevOps کہتے ہیں۔ یہ لوگ آپ کے تمام مسائل حل کر دیں گے" - اور یہ بتانا شروع کیا کہ DevOps کے طریقوں کو لاگو کرنے کے بعد کمپنی میں زندگی کتنی اچھی ہے۔
تاہم، یہ کافی نہیں ہے کہ ڈیو اوپس انجینئر کی خدمات حاصل کی جائیں تاکہ ہر چیز کو جیسا کہ ہونا چاہیے۔ کمپنی کو ایک مکمل DevOps تبدیلی سے گزرنا چاہیے، یعنی ہمارے DevOps کے کردار اور صلاحیتوں کو پروڈکٹ ڈویلپمنٹ اور ٹیسٹنگ ٹیم کی طرف سے بھی واضح طور پر سمجھنا چاہیے۔ ہمارے پاس اس موضوع پر ایک "حیرت انگیز" کہانی ہے جو کچھ جگہوں پر ہونے والی تمام بربریت کو پوری طرح سے واضح کرتی ہے۔
صورتحال DevOps کو ایک ورژن رول بیک سسٹم کو متعین کرنے کی ضرورت ہوتی ہے بغیر اس کے کہ یہ کیسے کام کرے گا۔ آئیے فرض کریں کہ یوزرز سسٹم کے اندر پہلے نام، آخری نام اور پاس ورڈ کے لیے الگ الگ فیلڈز ہیں۔ پروڈکٹ کا ایک نیا ورژن سامنے آتا ہے، لیکن ڈویلپرز کے لیے، "رول بیک" صرف ایک جادو کی چھڑی ہے جو سب کچھ ٹھیک کر دے گی، اور وہ یہ بھی نہیں جانتے کہ یہ کیسے کام کرتا ہے۔ لہذا، مثال کے طور پر، اگلے پیچ میں ڈویلپرز نے پہلے اور آخری نام کے فیلڈز کو یکجا کیا، اسے پروڈکشن میں رول آؤٹ کیا، لیکن ورژن کسی وجہ سے سست ہے۔ کیا ہو رہا ہے؟ انتظامیہ ڈیوپس کے پاس آتی ہے اور کہتی ہے "سوئچ کو کھینچو!"، یعنی اس سے پچھلے ورژن پر واپس آنے کو کہتا ہے۔ ڈیوپس کیا کرتا ہے؟ یہ پچھلے ورژن پر واپس چلا جاتا ہے، لیکن چونکہ ڈویلپر یہ نہیں جاننا چاہتے تھے کہ یہ رول بیک کیسے ہوا، اس لیے کسی نے ڈیوپس ٹیم کو نہیں بتایا کہ ڈیٹا بیس کو بھی رول بیک کرنے کی ضرورت ہے۔ نتیجے کے طور پر، ہمارے لیے سب کچھ کریش ہو جاتا ہے، اور ایک سست ویب سائٹ کے بجائے، صارفین کو "500" کی خرابی نظر آتی ہے، کیونکہ پرانا ورژن نئے ڈیٹا بیس کے فیلڈز کے ساتھ کام نہیں کرتا ہے۔ ڈیوپس کو اس کے بارے میں نہیں معلوم۔ ڈویلپر خاموش ہیں۔ انتظامیہ اپنے اعصاب اور پیسے کھونا شروع کر دیتی ہے اور بیک اپ کو یاد رکھتی ہے، ان سے واپس آنے کی پیشکش کرتی ہے تاکہ "کم از کم کچھ تو کام ہو جائے۔" نتیجے کے طور پر، صارفین وقت کی ایک مدت میں اپنا تمام ڈیٹا کھو دیتے ہیں۔
گری دار میوے، یقینا، ڈیوپس پر جاتے ہیں، جس نے "ایک مناسب رول بیک سسٹم نہیں بنایا،" اور کسی کو اس بات کی پرواہ نہیں ہے کہ اس کہانی میں موز ڈویلپر ہیں۔
نتیجہ آسان ہے: ڈی او اوپس کے لیے معمول کے نقطہ نظر کے بغیر، اس کا کوئی فائدہ نہیں ہے۔
یاد رکھنے کی اہم بات: ایک DevOps انجینئر جادوگر نہیں ہے، اور معیاری مواصلات اور ترقی کے ساتھ دو طرفہ تعامل کے بغیر، وہ اپنے کاموں سے نمٹ نہیں پائے گا۔ ڈیوس کو ان کے "مسائل" کے ساتھ تنہا نہیں چھوڑا جا سکتا یا "ڈویلپرز کے ساتھ مداخلت نہ کریں، ان کا کام کوڈ کرنا ہے" اور پھر امید ہے کہ ایک نازک لمحے پر سب کچھ ویسا ہی کام کرے گا جیسا کہ ہونا چاہیے۔ ایسا نہیں ہے کہ یہ کیسے کام کرتا ہے۔
بنیادی طور پر، DevOps مینجمنٹ اور ٹیکنالوجی کے درمیان سرحد پر ایک قابلیت ہے۔ اس کے علاوہ، یہ واضح نہیں ہے کہ اس کاک میں مینجمنٹ سے زیادہ ٹیکنالوجی ہونا چاہئے. اگر آپ واقعی تیز تر اور زیادہ موثر ترقیاتی عمل بنانا چاہتے ہیں، تو آپ کو اپنی ڈیوپس ٹیم پر بھروسہ کرنا چاہیے۔ وہ صحیح ٹولز جانتا ہے، اس نے اسی طرح کے منصوبے لگائے ہیں، وہ جانتا ہے کہ اسے کیسے کرنا ہے۔ اس کی مدد کریں، اس کے مشورے سنیں، اسے کسی خود مختار یونٹ میں الگ کرنے کی کوشش نہ کریں۔ اگر ایڈمنز اپنے طور پر کام کر سکتے ہیں، تو اس معاملے میں ڈیوپس بیکار ہیں، اگر آپ خود اس مدد کو قبول نہیں کرنا چاہتے تو وہ آپ کو بہتر بننے میں مدد نہیں کر سکیں گے۔
اور ایک آخری چیز: انفراسٹرکچر کے منتظمین کو ناگوار گزرنا بند کریں۔ ان کا اپنا، کام کا انتہائی اہم محاذ ہے۔ ہاں، ایک ایڈمنسٹریٹر DevOps انجینئر بن سکتا ہے، لیکن یہ خود شخص کی درخواست پر ہونا چاہیے، نہ کہ دباؤ میں۔ اور اس میں کوئی حرج نہیں کہ ایک سسٹم ایڈمنسٹریٹر سسٹم ایڈمنسٹریٹر رہنا چاہتا ہے - یہ اس کا الگ پیشہ اور اس کا حق ہے۔ اگر آپ پیشہ ورانہ تبدیلی سے گزرنا چاہتے ہیں، تو آپ کو یہ کبھی نہیں بھولنا چاہیے کہ آپ کو نہ صرف تکنیکی مہارتیں بلکہ انتظامی صلاحیتیں بھی تیار کرنی ہوں گی۔ غالباً، یہ آپ پر منحصر ہوگا کہ ایک لیڈر کے طور پر ان تمام لوگوں کو ایک ساتھ لانا اور انہیں ایک ہی زبان میں بات چیت کرنا سکھانا ہے۔
ماخذ: www.habr.com