حال ہی میں، اس طرح کے اشتہارات نے انٹرنیٹ پر سیلاب آ گیا ہے. خوشنما تنخواہ کے باوجود کوئی مدد نہیں کر سکتا لیکن شرمندہ ہے کہ اندر جنگلی بدعت لکھی ہوئی ہے۔ سب سے پہلے یہ فرض کیا جاتا ہے کہ "DevOps" اور "انجینئر" کو کسی نہ کسی طرح ایک لفظ میں جوڑا جا سکتا ہے، اور پھر ضروریات کی ایک بے ترتیب فہرست ہے، جن میں سے کچھ واضح طور پر sysadmin کی خالی جگہ سے نقل کی گئی ہیں۔
اس پوسٹ میں میں اس بارے میں تھوڑی بات کرنا چاہوں گا کہ ہم زندگی کے اس موڑ پر کیسے پہنچے، DevOps واقعی کیا ہے اور اب اس کے ساتھ کیا کرنا ہے۔
اس طرح کی خالی جگہوں کی ہر ممکن طریقے سے مذمت کی جا سکتی ہے، لیکن حقیقت یہ ہے کہ: ان میں سے بہت سے ہیں، اور اس وقت مارکیٹ اس طرح کام کرتی ہے۔ ہم نے ایک ڈیوپس کانفرنس منعقد کی اور کھلے عام اعلان کیا: - DevOps انجینئرز کے لیے نہیں۔" یہ بہت سے لوگوں کو عجیب اور جنگلی لگے گا: جو لوگ مکمل طور پر تجارتی ایونٹ کر رہے ہیں وہ مارکیٹ کے خلاف کیوں جاتے ہیں۔ اب ہم سب کچھ بیان کریں گے۔
ثقافت اور عمل کے بارے میں
آئیے اس حقیقت کے ساتھ شروع کریں کہ DevOps ایک انجینئرنگ ڈسپلن نہیں ہے۔ یہ سب اس حقیقت کے ساتھ شروع ہوا کہ کرداروں کی تاریخی طور پر قائم کردہ تقسیم مصنوعات کے معیار کے لیے کام نہیں کرتی۔ جب پروگرامرز صرف پروگرام کرتے ہیں، لیکن جانچ کے بارے میں کچھ نہیں سننا چاہتے، تو سافٹ ویئر کیڑے سے بھرا ہوتا ہے۔ جب منتظمین اس بات کی پرواہ نہیں کرتے ہیں کہ سافٹ ویئر کیسے اور کیوں لکھا گیا ہے، تو سپورٹ جہنم میں بدل جاتا ہے۔
مثال کے طور پر، سسٹم ایڈمنسٹریٹر اور سروس مینجمنٹ کے لیے SRE اپروچ کے درمیان فرق کو بیان کرنا . اندر اندر دلچسپ مطالعہ کیا گیا ہے - یہ واضح ہے کہ بہترین ڈویلپرز کسی نہ کسی طرح ایک گھنٹے میں ایک بار سے زیادہ تیزی سے پیداوار میں نئی تبدیلیوں کو تعینات کرنے کا انتظام کرتے ہیں۔ وہ اپنے ہاتھوں سے 10٪ سے زیادہ ٹیسٹ نہیں کرتے ہیں (اس سے دیکھا جا سکتا ہے۔ )۔ وہ یہ کیسے کرتے ہیں؟ رپورٹ کے عنوانات میں سے ایک کہتا ہے "ایکسل یا مرو"۔ جانچ کے تناظر میں ان اعدادوشمار کی تفصیلی بحث کے لیے آپ باروچ سڈوگورسکی کے کلیدی نوٹ کا حوالہ دے سکتے ہیں۔ ہماری دوسری کانفرنس میں، ہائزن بگ۔
"جب ساتھیوں کے درمیان کوئی معاہدہ نہیں ہوتا ہے،
ان کے لیے حالات ٹھیک نہیں ہوں گے،
اور اس سے کچھ نہیں نکلے گا، صرف عذاب۔
ایک زمانے میں ایک ہنس، ایک کری فش اور پائیک..."
آپ کے خیال میں ویب پروگرامرز کا کون سا حصہ واقعی ان حالات کو سمجھتے ہیں جن کے تحت ان کی ایپلی کیشنز کو پروڈکشن میں استعمال کیا جاتا ہے؟ ان میں سے کتنے ایڈمنز کے پاس جائیں گے اور یہ جاننے کی کوشش کریں گے کہ ڈیٹا بیس کریش ہونے کی صورت میں کیا ہوگا؟ اور ان میں سے کون ٹیسٹرز کے پاس جائے گا اور ان سے ٹیسٹ درست طریقے سے لکھنے کا طریقہ سکھانے کو کہے گا؟ اور سیکورٹی گارڈز، پروڈکٹ مینیجر، اور دوسرے لوگوں کا ایک گروپ بھی ہے۔
DevOps کا مجموعی خیال کرداروں اور محکموں کے درمیان تعاون پیدا کرنا ہے۔ سب سے پہلے، یہ کچھ چالاکی سے ترتیب دیئے گئے سافٹ ویئر کے ذریعے حاصل نہیں ہوتا، بلکہ مواصلات کی مشق سے ہوتا ہے۔ DevOps ثقافت، طریقوں، طریقہ کار اور عمل کے بارے میں ہے۔ انجینئرنگ کی کوئی خصوصیت نہیں ہے جو ان سوالات کا جواب دے سکے۔
شیطانی حلقہ
پھر "ڈیوپس انجینئرنگ" کا نظم و ضبط کہاں سے آیا؟ ہمارے پاس ایک ورژن ہے! DevOps کے آئیڈیاز اچھے تھے — اتنے اچھے کہ وہ اپنی ہی کامیابی کا شکار ہو گئے۔ کچھ مشکوک بھرتی کرنے والے اور انسانی سمگلر، جن کا اپنا ماحول ہے، اس سارے موضوع پر گھومنے لگے۔
تصور کریں: کل آپ کھمکی میں شوارما بنا رہے تھے، اور آج آپ پہلے سے ہی ایک بڑے آدمی ہیں، ایک سینئر بھرتی کرنے والے۔ امیدواروں کو تلاش کرنے اور منتخب کرنے کا پورا عمل ہے، سب کچھ آسان نہیں ہے، آپ کو سمجھنے کی ضرورت ہے۔ آئیے کہتے ہیں کہ ایک شعبہ کا سربراہ کہتا ہے: ایکس میں ایک ماہر تلاش کریں۔ ہم لفظ "انجینئر" کو X کو تفویض کرتے ہیں، اور ہم نے کام کر لیا۔ لینکس کی ضرورت ہے؟ ٹھیک ہے، یہ یقینی طور پر ایک لینکس انجینئر ہے، اگر آپ DevOps چاہتے ہیں، تو ایک DevOps انجینئر۔ خالی جگہ نہ صرف عنوان پر مشتمل ہوتی ہے بلکہ اس کے اندر کچھ متن بھی درج کرنا ضروری ہوتا ہے۔ سب سے آسان طریقہ یہ ہے کہ آپ کی تخیل پر منحصر گوگل سے مطلوبہ الفاظ کا ایک سیٹ درج کریں۔ DevOps دو الفاظ پر مشتمل ہے - "Dev" اور "Ops"، جس کا مطلب ہے کہ ہمیں ڈویلپرز اور ایڈمنسٹریٹرز سے متعلق کلیدی الفاظ کو ایک ساتھ جوڑنے کی ضرورت ہے۔ اس طرح 42 پروگرامنگ زبانوں میں مہارت اور کبرنیٹس اور سوارم کو بیک وقت استعمال کرنے کے 20 سال کے بارے میں آسامیاں ظاہر ہوتی ہیں۔ ورکنگ ڈایاگرام۔
اس طرح ایک خاص "ڈیوپس" سپر ہیرو کی بے معنی اور بے رحم تصویر لوگوں کے ذہنوں میں جڑ پکڑ چکی ہے، جو ہر کسی کو جینکنز پر تعینات کرنے کے لیے ترتیب دے گا، اور خوشی آئے گی۔ اوہ، اگر صرف سب کچھ اتنا آسان ہوتا۔ "اور یہ بھی ہے کہ آپ سسٹم ایڈمنسٹریٹرز کو کس طرح تلاش کر سکتے ہیں،" HR سوچتا ہے، "یہ ایک فیشن ایبل لفظ ہے، کلیدی الفاظ ایک جیسے ہیں، انہیں بیت لینا چاہیے۔"
ڈیمانڈ سپلائی پیدا کرتی ہے، اور کوڑے دان کی یہ تمام آسامیاں سسٹم ایڈمنسٹریٹرز کی دیوانہ وار تعداد سے پُر کر دی گئی ہیں جنہوں نے محسوس کیا: آپ پہلے کی طرح سب کچھ کر سکتے ہیں، لیکن اپنے آپ کو "ڈیوپس" کہہ کر کئی گنا زیادہ حاصل کر سکتے ہیں۔ جس طرح آپ نے سرورز کو SSH کے ذریعے ایک وقت میں دستی طور پر ترتیب دیا ہے، آپ انہیں کنفیگر کرنا جاری رکھیں گے، لیکن اب یہ سمجھا جاتا ہے کہ یہ ڈیوپس پریکٹس ہے۔ یہ ایک قسم کا پیچیدہ واقعہ ہے، جس کا جزوی طور پر کلاسک ایڈمنز کی کم تر اندازی اور DevOps کے اردگرد کی ہائپ سے تعلق ہے، لیکن عام طور پر، جو ہوا، وہی ہوا۔
لہذا ہمارے پاس طلب اور رسد ہے۔ ایک شیطانی حلقہ جو خود کو پالتا ہے۔ یہ وہی ہے جس کے خلاف ہم لڑ رہے ہیں (بشمول DevOops کانفرنس بنا کر)۔
بلاشبہ، سسٹم ایڈمنسٹریٹرز کے علاوہ جنہوں نے خود کو "ڈیوپس" کا نام دیا ہے، وہاں دوسرے شرکاء بھی ہیں - مثال کے طور پر، پیشہ ورانہ SREs یا انفراسٹرکچر کے طور پر کوڈ ڈویلپرز۔
لوگ DevOps میں کیا کرتے ہیں (واقعی)
لہذا آپ DevOps طریقوں کو سیکھنے اور لاگو کرنے میں آگے بڑھنا چاہتے ہیں۔ لیکن یہ کیسے کریں، کس سمت میں دیکھنا ہے؟ ظاہر ہے، آپ کو مقبول کلیدی الفاظ پر آنکھیں بند کرکے انحصار نہیں کرنا چاہیے۔
کوئی کام ہے تو کوئی کرے۔ ہمیں پہلے ہی پتہ چل گیا ہے کہ یہ "ڈیوپس انجینئرز" نہیں ہیں، پھر کون ہیں؟ اس کو عہدوں کے لحاظ سے نہیں بلکہ کام کے مخصوص شعبوں کے لحاظ سے وضع کرنا زیادہ درست معلوم ہوتا ہے۔
سب سے پہلے، آپ DevOps — عمل اور ثقافت کے دل کو ایڈریس کر سکتے ہیں۔ ثقافت ایک سست اور مشکل کاروبار ہے، اور اگرچہ یہ روایتی طور پر مینیجرز کی ذمہ داری ہے، پروگرامرز سے لے کر منتظمین تک ہر کوئی کسی نہ کسی طریقے سے اس میں ملوث ہے۔ کچھ مہینے پہلے ٹم لسٹر :
"ثقافت کا تعین تنظیم کی بنیادی اقدار سے ہوتا ہے۔ عام طور پر لوگ اس کا نوٹس نہیں لیتے، لیکن کئی سالوں سے مشاورت میں کام کرنے کے بعد، ہم اسے نوٹس کرنے کے عادی ہیں۔ آپ کسی کمپنی میں داخل ہوتے ہیں اور لفظی طور پر چند ہی منٹوں میں آپ محسوس کرنے لگتے ہیں کہ کیا ہو رہا ہے۔ ہم اسے "ذائقہ" کہتے ہیں۔ کبھی کبھی یہ خوشبو واقعی اچھی ہوتی ہے۔ بعض اوقات یہ متلی کا سبب بنتا ہے۔ (...) آپ کسی ثقافت کو تب تک تبدیل نہیں کر سکتے جب تک کہ مخصوص اعمال کے پیچھے موجود اقدار اور عقائد کو سمجھ نہ لیا جائے۔ رویے کا مشاہدہ کرنا آسان ہے، لیکن عقائد کی تلاش مشکل ہے۔ ڈی او اوپس صرف ایک عمدہ مثال ہے کہ چیزیں کس طرح پیچیدہ ہوتی جارہی ہیں۔
یقیناً اس مسئلے کا ایک تکنیکی حصہ بھی ہے۔ اگر آپ کے نئے کوڈ کی جانچ ایک ماہ میں ہو جاتی ہے، لیکن صرف ایک سال بعد اسے جاری کیا جاتا ہے، اور اس کی رفتار کو تیز کرنا جسمانی طور پر ناممکن ہے، تو ہو سکتا ہے آپ اچھے طریقوں پر پورا نہ اتر سکیں۔ اچھے طریقوں سے اچھے اوزاروں کی مدد کی جاتی ہے۔ مثال کے طور پر، انفراسٹرکچر-ایس-کوڈ کے خیال کو ذہن میں رکھتے ہوئے، آپ AWS CloudFormation اور Terraform سے لے کر Chef-Ansible-Puppet تک کچھ بھی استعمال کر سکتے ہیں۔ آپ کو یہ سب کچھ جاننے اور کرنے کے قابل ہونے کی ضرورت ہے، اور یہ پہلے سے ہی کافی انجینئرنگ کا شعبہ ہے۔ یہ ضروری ہے کہ وجہ کو اثر کے ساتھ الجھایا نہ جائے: پہلے آپ SRE کے اصولوں کے مطابق کام کریں اور اس کے بعد ہی ان اصولوں کو کچھ مخصوص تکنیکی حلوں کی شکل میں نافذ کریں۔ ایک ہی وقت میں، SRE ایک بہت ہی جامع طریقہ کار ہے جو آپ کو یہ نہیں بتاتا کہ جینکنز کو کیسے ترتیب دیا جائے، لیکن تقریباً پانچ بنیادی اصول:
- کرداروں اور محکموں کے درمیان بہتر مواصلت
- غلطیوں کو کام کا ایک لازمی حصہ سمجھنا
- بتدریج تبدیلیاں کرنا
- ٹولنگ اور دیگر آٹومیشن کا استعمال
- ہر چیز کی پیمائش کرنا جس کی پیمائش کی جاسکتی ہے۔
یہ صرف بیانات کا کچھ مجموعہ نہیں ہے، بلکہ ایک مخصوص ہے۔ . مثال کے طور پر، غلطیوں کو قبول کرنے کے راستے پر، آپ کو خطرات کو سمجھنا ہوگا، SLI () اور SLO ()، پوسٹ مارٹم لکھنا سیکھیں اور لکھنے کو خوفناک نہ بنائیں۔
SRE نظم و ضبط میں، ٹولز کا استعمال کامیابی کا صرف ایک حصہ ہے، حالانکہ ایک اہم ہے۔ ہمیں مسلسل تکنیکی طور پر ترقی کرنے کی ضرورت ہے، یہ دیکھنا ہے کہ دنیا میں کیا ہو رہا ہے اور اسے ہمارے کام میں کیسے لاگو کیا جا سکتا ہے۔
بدلے میں، کلاؤڈ کے مقامی حل اب بہت مقبول ہو چکے ہیں۔ جیسا کہ کلاؤڈ نیٹیو کمپیوٹنگ فاؤنڈیشن نے آج کی تعریف کی ہے، کلاؤڈ نیٹیو ٹیکنالوجیز تنظیموں کو آج کے متحرک ماحول، جیسے کہ پبلک، پرائیویٹ، اور ہائبرڈ کلاؤڈز میں توسیع پذیر ایپلیکیشنز تیار کرنے اور چلانے کے قابل بناتی ہیں۔ مثالوں میں کنٹینرز، سروس میشز، مائیکرو سروسز، ناقابل تغیر انفراسٹرکچر، اور اعلانیہ APIs شامل ہیں۔ یہ تمام تکنیکیں ڈھیلے جوڑے والے نظاموں کو لچکدار، قابل انتظام، اور انتہائی قابل مشاہدہ رہنے کی اجازت دیتی ہیں۔ اچھی آٹومیشن انجینئرز کو کام کاج بنائے بغیر اکثر اور متوقع نتائج کے ساتھ بڑی تبدیلیاں کرنے کی اجازت دیتی ہے۔ یہ سب معروف ٹولز جیسے ڈوکر اور کبرنیٹس کے اسٹیک سے تعاون یافتہ ہے۔
یہ بلکہ پیچیدہ اور وسیع تعریف اس حقیقت کی وجہ سے ہے کہ علاقہ بھی کافی پیچیدہ ہے۔ ایک طرف، یہ دلیل دی جاتی ہے کہ اس نظام میں نئی تبدیلیوں کو کافی سادگی سے شامل کیا جانا چاہیے۔ دوسری طرف، یہ معلوم کرنے کے لیے کہ ایک قسم کا کنٹینرائزڈ ماحول کیسے بنایا جائے جس میں نرمی سے جوڑے جانے والی خدمات سافٹ ویئر سے طے شدہ انفراسٹرکچر پر رہتی ہیں اور مسلسل CI/CD کا استعمال کرتے ہوئے وہاں ڈیلیور کی جاتی ہیں، اور اس سب کے ارد گرد DevOps پریکٹسز تیار کی جاتی ہیں۔ ایک سے زیادہ کتے کو کھاتے ہیں۔
اس سب کا کیا کرنا ہے۔
ہر کوئی ان مسائل کو اپنے طریقے سے حل کرتا ہے: مثال کے طور پر، آپ شیطانی دائرے کو توڑنے کے لیے عام آسامیاں شائع کر سکتے ہیں۔ آپ یہ جان سکتے ہیں کہ DevOps اور Cloud Native جیسے الفاظ کا کیا مطلب ہے اور ان کا صحیح طریقے سے استعمال کریں۔ آپ DevOps میں ترقی کر سکتے ہیں اور اپنی مثال سے صحیح نقطہ نظر کا مظاہرہ کر سکتے ہیں۔
ہم ایک کانفرنس کر رہے ہیں۔ ، جو ان چیزوں کی گہرائی میں جانے کا موقع فراہم کرتا ہے جن کے بارے میں ہم نے ابھی بات کی ہے۔ اس کے لیے رپورٹس کے کئی گروپ ہیں:
- عمل اور ثقافت؛
- سائٹ کی وشوسنییتا انجینئرنگ؛
- کلاؤڈ مقامی؛
کہاں جانا ہے کا انتخاب کیسے کریں؟ یہاں ایک لطیف نکتہ ہے۔ ایک طرف، DevOps بات چیت کے بارے میں ہے، اور ہم واقعی چاہتے ہیں کہ آپ مختلف بلاکس سے پیشکشوں میں شرکت کریں۔ دوسری طرف، اگر آپ ایک ڈویلپمنٹ مینیجر ہیں جو ایک مخصوص کام پر توجہ مرکوز کرنے کے لیے کانفرنس میں آئے ہیں، تو کوئی بھی آپ کو محدود نہیں کرتا - ظاہر ہے، یہ عمل اور ثقافت کے بارے میں ایک بلاک ہوگا۔ یہ نہ بھولیں کہ کانفرنس کے بعد آپ کے پاس ریکارڈنگ ہوں گی (فیڈ بیک فارم بھرنے کے بعد)، تاکہ آپ بعد میں ہمیشہ کم اہم پیشکشیں دیکھ سکیں۔
ظاہر ہے، کانفرنس میں ہی آپ بیک وقت تین ٹریک پر نہیں جا سکتے، اس لیے ہم پروگرام کو اس طرح ترتیب دیتے ہیں کہ ہر بار سلاٹ میں ہر ذوق کے لیے عنوانات ہوتے ہیں۔
بس یہ سمجھنا باقی ہے کہ اگر آپ DevOps انجینئر ہیں تو کیا کرنا ہے! سب سے پہلے، یہ طے کرنے کی کوشش کریں کہ آپ اصل میں کیا کرتے ہیں۔ عام طور پر وہ اس لفظ کو پکارنا پسند کرتے ہیں:
- ڈویلپرز جو انفراسٹرکچر پر کام کرتے ہیں۔ SRE اور Cloud Native کے بارے میں رپورٹس کے گروپ آپ کے لیے موزوں ترین ہیں۔
- سسٹم ایڈمنسٹریٹرز۔ یہ یہاں زیادہ پیچیدہ ہے۔ DevOops سسٹم ایڈمنسٹریشن کے بارے میں نہیں ہے۔ خوش قسمتی سے، سسٹم ایڈمنسٹریشن کے موضوع پر بہت ساری بہترین کانفرنسیں، کتابیں، مضامین، انٹرنیٹ پر ویڈیوز وغیرہ موجود ہیں۔ دوسری طرف، اگر آپ ثقافت اور عمل کو سمجھنے، کلاؤڈ ٹیکنالوجیز کے بارے میں سیکھنے اور Cloud Native کے ساتھ زندگی کی تفصیلات کے لحاظ سے اپنے آپ کو ترقی دینے میں دلچسپی رکھتے ہیں، تو ہم آپ سے ملنا پسند کریں گے! اس کے بارے میں سوچیں: آپ انتظامیہ کر رہے ہیں، اور پھر آپ کیا کریں گے؟ اپنے آپ کو اچانک کسی ناخوشگوار صورتحال میں نہ پانے کے لیے، آپ کو ابھی سیکھنا چاہیے۔
ایک اور آپشن ہے: آپ برقرار رہیں اور دعوی کرتے رہیں کہ آپ ہیں۔ خاص طور پر ایک DevOps انجینئر اور کچھ نہیں، اس کا جو بھی مطلب ہے۔ پھر ہمیں آپ کو مایوس کرنا پڑے گا، DevOops DevOps انجینئرز کے لیے کانفرنس نہیں ہے!
سے سلائیڈ کریں۔ میونخ میں
DevOops 2020 ماسکو میں 29-30 اپریل کو ماسکو میں منعقد ہوگا، ٹکٹ پہلے ہی دستیاب ہیں .
متبادل کے طور پر ، آپ کر سکتے ہیں 8 فروری تک براہ کرم نوٹ کریں کہ فارم پُر کرتے وقت، آپ کو مطلوبہ سامعین کا انتخاب کرنا چاہیے جو آپ کی رپورٹ سے زیادہ فائدہ اٹھائیں گے (فہرست کے اندر ایک حیرت چھپی ہوئی ہے۔).
ماخذ: www.habr.com