DevOps کون ہیں؟

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

ہم ابھی بھی ساتھیوں کی تلاش میں ہیں، کیونکہ DevOps لیبل کے پیچھے مختلف قسم کے انجینئرز کی ایک بہت بڑی پرت چھپی ہوئی ہے۔

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

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

تو DevOps انجینئر کون ہیں؟

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

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

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

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

کسی خاص وسائل کے ماہر علم کی سطح میں اسی طرح کے "جھولے" آج تک جاری ہیں۔ لیکن ہم تھوڑا سا پیچھے ہٹتے ہیں، بہت سے نکات ہیں جن کو اجاگر کرنا ضروری ہے۔

تعمیر انجینئر/ریلیز انجینئر

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

آپریشن بہت مختلف ہیں۔

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

• ٹیک اوپس - اینیکی سسٹم ایڈمنسٹریٹرز عرف ہیلپ ڈیسک انجینئر
• LiveOps - نظام کے منتظمین بنیادی طور پر پیداواری ماحول کے لیے ذمہ دار ہیں۔
• CloudOps - سسٹم ایڈمنسٹریٹرز جو عوامی بادلوں میں مہارت رکھتے ہیں Azure، AWS، GCP، وغیرہ۔
• PlatOps/InfraOps/SysOps - بنیادی ڈھانچے کے نظام کے منتظمین۔
• NetOps - نیٹ ورک ایڈمنسٹریٹرز
• SecOps - سسٹم ایڈمنسٹریٹر جو معلومات کی حفاظت میں مہارت رکھتے ہیں - PCI کی تعمیل، CIS کی تعمیل، پیچنگ، وغیرہ۔

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

اس قسم کے کام اور ذمہ داریوں کو انجام دینے کے لیے، اس شخص کے پاس نہ صرف ترقی اور جانچ کے عمل، بلکہ پروڈکٹ کے بنیادی ڈھانچے کے انتظام کے ساتھ ساتھ وسائل کی منصوبہ بندی کا بھی ذریعہ ہونا چاہیے۔ اس تفہیم میں DevOps یا تو IT میں، یا R&D میں، یا یہاں تک کہ PMO میں بھی واقع نہیں ہوسکتے؛ اس کا ان تمام شعبوں میں اثر و رسوخ ہونا چاہیے - کمپنی کے تکنیکی ڈائریکٹر، چیف ٹیکنیکل آفیسر۔

کیا آپ کی کمپنی میں یہ سچ ہے؟ - مجھے شک ہے. زیادہ تر معاملات میں، یہ یا تو IT یا R&D ہے۔

فنڈز کی کمی اور سرگرمی کے ان تین شعبوں میں سے کم از کم ایک پر اثر انداز ہونے کی صلاحیت مسائل کے وزن کو اس طرف لے جائے گی جہاں ان تبدیلیوں کا اطلاق آسان ہے، جیسے کہ جامد کے مطابق "گندے" کوڈ کے سلسلے میں ریلیز پر تکنیکی پابندیوں کا اطلاق تجزیہ کار نظام. یعنی، جب PMO فعالیت کے اجراء کے لیے ایک سخت ڈیڈ لائن مقرر کرتا ہے، R&D ان ڈیڈ لائنوں کے اندر اعلیٰ معیار کا نتیجہ نہیں دے سکتا اور اسے بہترین طریقے سے پیش کرتا ہے، بعد میں ری فیکٹرنگ کو چھوڑ کر، IT سے متعلق DevOps تکنیکی ذرائع سے ریلیز کو روکتا ہے۔ . ذمہ دار ملازمین کے معاملے میں صورت حال کو تبدیل کرنے کے اختیارات کی کمی، انتہائی ذمہ داری کے اظہار کا باعث بنتی ہے جس پر وہ اثر انداز نہیں ہو سکتے، خاص طور پر اگر یہ ملازمین غلطیوں کو سمجھتے اور دیکھتے ہیں، اور انہیں درست کرنے کا طریقہ - "خوشی ہے نادانی"، اور اس کے نتیجے میں ان ملازمین کے جلانے اور نقصان کے طور پر۔

DevOps ریسورس مارکیٹ

آئیے مختلف کمپنیوں سے DevOps عہدوں کے لیے متعدد خالی آسامیوں کو دیکھتے ہیں۔

ہم آپ سے ملنے کے لیے تیار ہیں اگر آپ:

1. آپ Zabbix کے مالک ہیں اور جانتے ہیں کہ Prometheus کیا ہے؛
2. Iptables؛
3. BASH پی ایچ ڈی طالب علم؛
4. پروفیسر جوابدہ؛
5. لینکس گرو؛
6. ڈیبگنگ کو استعمال کرنے کا طریقہ جانیں اور ڈویلپرز (php/java/python) کے ساتھ مل کر ایپلی کیشن کے مسائل کو تلاش کریں؛
7. روٹنگ آپ کو پراسرار نہیں بناتی ہے۔
8. سسٹم کی حفاظت پر خاص توجہ دینا؛
9. "کچھ بھی اور ہر چیز" کا بیک اپ لیں، اور اس "کچھ بھی اور ہر چیز" کو کامیابی سے بحال کریں۔
10. آپ جانتے ہیں کہ نظام کو اس طرح ترتیب دینا ہے کہ کم از کم سے زیادہ سے زیادہ حاصل کیا جا سکے۔
11. Postgres اور MySQL پر سونے سے پہلے نقل ترتیب دیں؛
12. CI/CD کو ترتیب دینا اور ایڈجسٹ کرنا آپ کے لیے ناشتہ/دوپہر کے کھانے/رات کے کھانے کی طرح ضروری ہے۔
13. AWS کے ساتھ تجربہ ہے؛
14. کمپنی کے ساتھ ترقی کے لیے تیار؛

تو:

• 1 سے 6 تک - سسٹم ایڈمنسٹریٹر
• 7 - تھوڑا سا نیٹ ورک ایڈمنسٹریشن، جو سسٹم ایڈمنسٹریٹر، مڈل لیول میں بھی فٹ بیٹھتا ہے۔
• 8 - تھوڑی سی سیکیورٹی، جو کہ درمیانی سطح کے سسٹم ایڈمنسٹریٹر کے لیے لازمی ہے۔
• 9-11 - مڈل سسٹم ایڈمنسٹریٹر
• 12 — تفویض کردہ کاموں پر منحصر ہے، یا تو مڈل سسٹم ایڈمنسٹریٹر یا بلڈ انجینئر
• 13 - ورچوئلائزیشن - مڈل سسٹم ایڈمنسٹریٹر، یا نام نہاد کلاؤڈ اوپس، فنڈز کے موثر استعمال اور دیکھ بھال پر بوجھ کو کم کرنے کے لیے مخصوص ہوسٹنگ سائٹ کی خدمات کا جدید علم

اس آسامی کا خلاصہ کرتے ہوئے، ہم کہہ سکتے ہیں کہ مڈل/سینئر سسٹم ایڈمنسٹریٹر لڑکوں کے لیے کافی ہے۔

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

آئیے ایک اور خالی جگہ پر غور کریں:

1. اعلی بوجھ کے نظام کی تعمیر میں تجربہ؛
2. لینکس OS، جنرل سسٹم سافٹ ویئر اور ویب اسٹیک (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK) کا بہترین علم؛
3. ورچوئلائزیشن سسٹم کے ساتھ تجربہ (KVM, VMWare, LXC/Docker)؛
4. سکرپٹ کی زبانوں میں مہارت؛
5. نیٹ ورک پروٹوکول نیٹ ورکس کے آپریٹنگ اصولوں کی تفہیم؛
6. غلطی برداشت کرنے والے نظام کی تعمیر کے اصولوں کی تفہیم؛
7. آزادی اور پہل؛

آئیے دیکھتے ہیں:

• 1 - سینئر سسٹم ایڈمنسٹریٹر
• 2 - اس اسٹیک میں ڈالے گئے معنی پر منحصر ہے - مڈل/سینئر سسٹم ایڈمنسٹریٹر
• 3 - کام کا تجربہ، بشمول، مطلب ہو سکتا ہے - "کلسٹر نے اضافہ نہیں کیا، لیکن ورچوئل مشینیں بنائی اور ان کا انتظام کیا، ایک ڈاکر ہوسٹ تھا، کنٹینرز تک رسائی دستیاب نہیں تھی" - مڈل سسٹم ایڈمنسٹریٹر
• 4 - جونیئر سسٹم ایڈمنسٹریٹر - جی ہاں، ایک ایڈمن جو بنیادی آٹومیشن اسکرپٹ لکھنا نہیں جانتا ہے، چاہے زبان کچھ بھی ہو، ایڈمن نہیں۔
• 5 - مڈل سسٹم ایڈمنسٹریٹر
• 6 - سینئر سسٹم ایڈمنسٹریٹر

خلاصہ کرنے کے لیے - مڈل/سینئر سسٹم ایڈمنسٹریٹر

ایک دوسرا:

1. ڈیوپس کا تجربہ؛
2. CI/CD پروسیس بنانے کے لیے ایک یا زیادہ مصنوعات استعمال کرنے کا تجربہ۔ Gitlab CI ایک فائدہ ہو گا؛
3. کنٹینرز اور ورچوئلائزیشن کے ساتھ کام کرنا؛ اگر آپ نے ڈوکر استعمال کیا تو اچھا، لیکن اگر آپ k8s استعمال کرتے ہیں تو بہت اچھا!
4. فرتیلی ٹیم میں کام کرنے کا تجربہ؛
5. کسی بھی پروگرامنگ زبان کا علم؛

چلو دیکھتے ہیں:

• 1 - ہمم... لڑکوں کا کیا مطلب ہے؟ =) غالباً وہ خود نہیں جانتے کہ اس کے پیچھے کیا چھپا ہوا ہے۔
• 2 - انجینئر بنائیں
• 3 - مڈل سسٹم ایڈمنسٹریٹر
• 4 - نرم مہارت، ہم ابھی اس پر غور نہیں کریں گے، حالانکہ چست ایک اور چیز ہے جس کی تشریح اس طرح کی جاتی ہے جو آسان ہو۔
• 5 - بہت زیادہ لفظی - یہ سکرپٹ کی زبان یا مرتب شدہ زبان ہوسکتی ہے۔ مجھے حیرت ہے کہ کیا اسکول میں پاسکل اور بیسک میں لکھنا ان کے مطابق ہوگا؟ =)

میں پوائنٹ 3 کے حوالے سے ایک نوٹ بھی چھوڑنا چاہوں گا تاکہ اس بات کی سمجھ کو مضبوط کیا جا سکے کہ یہ نکتہ سسٹم ایڈمنسٹریٹر کے ذریعے کیوں احاطہ کرتا ہے۔ Kubernetes صرف ایک آرکیسٹریشن ہے، ایک ایسا ٹول جو نیٹ ورک ڈرائیوروں اور ورچوئلائزیشن/آئیسولیشن ہوسٹس کو براہ راست کمانڈز کو ایک دو کمانڈز میں سمیٹتا ہے اور آپ کو ان کے ساتھ بات چیت کو خلاصہ بنانے کی اجازت دیتا ہے، بس۔ مثال کے طور پر، آئیے 'بلڈ فریم ورک' بنائیں، جسے، ویسے، میں فریم ورک پر غور نہیں کرتا۔ جی ہاں، میں میک کو کہیں بھی ہلانے کے فیشن کے بارے میں جانتا ہوں، جہاں یہ ضروری ہے اور ضرورت نہیں ہے - ماون کو میک میں لپیٹنا، مثال کے طور پر، سنجیدگی سے؟
بنیادی طور پر، میک شیل کے اوپر صرف ایک ریپر ہے، جو k8s کی طرح تالیف، لنکنگ، اور کمپلیشن ماحول کے احکام کو آسان بناتا ہے۔

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

آئیے ایک بار پھر خلاصہ کرتے ہیں - ان کے لیے مڈل/سینئر سسٹم ایڈمنسٹریٹر کافی ہوگا۔

گرام میں کتنا وزن کرنا ہے؟

اشارہ شدہ آسامیوں کے لیے مجوزہ تنخواہوں کی حد 90k-200k ہے۔
اب میں سسٹم ایڈمنسٹریٹرز اور DevOps انجینئرز کے مالیاتی انعامات کے درمیان ایک متوازی بنانا چاہوں گا۔

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

ایک تجربہ:

1. 3 سال تک - جونیئر
2. 6 سال کی عمر تک - درمیانی۔
3. 6 سے زیادہ - سینئر

ملازم کی تلاش کی سائٹ پیش کرتی ہے:
سسٹم ایڈمنسٹریٹرز:

1. جونیئر - 2 سال - 50k رگڑیں۔
2. درمیانی - 5 سال - 70k رگڑنا۔
3. سینئر - 11 سال - 100k رگڑنا۔

DevOps انجینئرز:

1. جونیئر - 2 سال - 100k رگڑیں۔
2. درمیانی - 3 سال - 160k رگڑنا۔
3. سینئر - 6 سال - 220k رگڑنا۔

"DevOps" کے تجربے کے مطابق، تجربہ استعمال کیا گیا جس نے کم از کم کسی نہ کسی طرح SDLC کو متاثر کیا۔

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

DevOps انجینئرز کو تربیت دینے کا عمل بھی صرف مخصوص کاموں، افادیت کے ایک سیٹ تک محدود ہے اور یہ عمل اور ان کے انحصار کے بارے میں عام فہم فراہم نہیں کرتا ہے۔ یہ یقینی طور پر اچھا ہے جب کوئی شخص اس کلسٹر میں Fluentd sidecar اور AWS ELK اسٹیک کے ساتھ 10 منٹ میں کنسول میں صرف ایک کمانڈ کا استعمال کرتے ہوئے Terraform کا استعمال کرتے ہوئے AWS EKS کو تعینات کر سکتا ہے، لیکن اگر وہ نہیں سمجھتا لاگز کو خود پروسیسنگ کرنے کا اصول اور ان کی کیا ضرورت ہے، اگر آپ نہیں جانتے کہ ان پر میٹرکس کیسے جمع کرنا ہے اور سروس کے انحطاط کو کیسے ٹریک کرنا ہے، تب بھی یہ وہی اینیکی ہوگا جو کچھ یوٹیلیٹیز کو استعمال کرنا جانتا ہے۔

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

تو وہ کون ہیں؟ ڈی او اوپس یا لالچی سسٹم ایڈمنسٹریٹر؟ =)

زندگی کیسے جاری رکھی جائے؟

آجروں کو چاہیے کہ وہ تقاضے زیادہ درست طریقے سے مرتب کریں اور بالکل ان لوگوں کو تلاش کریں جن کی ضرورت ہے، اور لیبل کے ارد گرد نہیں پھینکنا چاہیے۔ آپ نہیں جانتے کہ DevOps کیا کرتے ہیں - آپ کو اس معاملے میں ان کی ضرورت نہیں ہے۔

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

ماخذ: www.habr.com