چیٹ ڈسکشن پر مبنی
حال ہی میں، DevOps اور SRE کی تعریف پر حقیقی لڑائیاں بھڑک اٹھی ہیں۔
اس حقیقت کے باوجود کہ کئی طریقوں سے اس موضوع پر ہونے والی بات چیت نے پہلے ہی میرے دانتوں کو کنارہ کشی میں ڈال دیا ہے، بشمول میں، میں نے اس موضوع پر اپنا نظریہ حبرا برادری کی عدالت میں پیش کرنے کا فیصلہ کیا۔ ان لوگوں کے لئے جو دلچسپی رکھتے ہیں، بلی میں خوش آمدید. اور سب کچھ نئے سرے سے شروع ہونے دو!
پس منظر
لہذا، قدیم زمانے میں، سافٹ ویئر ڈویلپرز اور سرور ایڈمنسٹریٹرز کی ایک ٹیم الگ الگ رہتی تھی۔ پہلے نے کامیابی کے ساتھ کوڈ لکھا، دوسرا، پہلے کو مخاطب کرتے ہوئے مختلف گرم، پیار بھرے الفاظ کا استعمال کرتے ہوئے، سرورز مرتب کیے، وقتاً فوقتاً ڈویلپرز کے پاس آتے اور جواب میں ایک جامع "میری مشین پر ہر چیز کام کرتی ہے۔" کاروبار سافٹ ویئر کا انتظار کر رہا تھا، سب کچھ بیکار تھا، وقتاً فوقتاً ٹوٹتا تھا، ہر کوئی گھبرا جاتا تھا۔ خاص طور پر جس نے اس ساری گندگی کی قیمت ادا کی۔ شاندار چراغ کا دور۔ ٹھیک ہے، آپ پہلے ہی جانتے ہیں کہ DevOps کہاں سے آتا ہے۔
DevOps طریقوں کی پیدائش
پھر سنجیدہ لوگ آئے اور کہا - یہ انڈسٹری نہیں ہے، آپ اس طرح کام نہیں کر سکتے۔ اور وہ لائف سائیکل ماڈل لائے۔ یہاں، مثال کے طور پر، V-ماڈل ہے۔
تو ہم کیا دیکھتے ہیں؟ ایک کاروبار ایک تصور کے ساتھ آتا ہے، آرکیٹیکٹس ڈیزائن حل، ڈویلپرز کوڈ لکھتے ہیں، اور پھر یہ ناکام ہوجاتا ہے۔ کوئی کسی نہ کسی طرح پروڈکٹ کی جانچ کرتا ہے، کوئی کسی طرح اسے آخری صارف تک پہنچاتا ہے، اور کہیں اس معجزاتی ماڈل کے آؤٹ پٹ پر ایک تنہا کاروباری گاہک بیٹھا ہے جو سمندر کے کنارے وعدے کے مطابق موسم کا انتظار کر رہا ہے۔ ہم اس نتیجے پر پہنچے کہ ہمیں ایسے طریقوں کی ضرورت ہے جو ہمیں اس عمل کو قائم کرنے کی اجازت دیں۔ اور ہم نے ایسے طریقوں کو بنانے کا فیصلہ کیا جو ان پر عمل درآمد کریں گے۔
پریکٹس کیا ہے اس موضوع پر ایک گیت انگیز ڈگریشن
مشق سے میرا مطلب ٹیکنالوجی اور نظم و ضبط کا مجموعہ ہے۔ ایک مثال ٹیرافارم کوڈ کا استعمال کرتے ہوئے بنیادی ڈھانچے کو بیان کرنے کی مشق ہے۔ نظم و ضبط یہ ہے کہ کوڈ کے ساتھ انفراسٹرکچر کو کیسے بیان کیا جائے، یہ ڈویلپر کے سر میں ہے، اور ٹیکنالوجی ہی ٹیرافارم ہے۔
اور انہوں نے انہیں DevOps پریکٹسز کہنے کا فیصلہ کیا - میرے خیال میں ان کا مطلب ترقی سے لے کر آپریشنز تک تھا۔ ہم مختلف ہوشیار چیزیں لے کر آئے ہیں - CI/CD طرز عمل، IaC اصول پر مبنی طرز عمل، ان میں سے ہزاروں۔ اور ہم جاتے ہیں، ڈویلپرز کوڈ لکھتے ہیں، ڈیو اوپس انجینئرز سسٹم کی تفصیل کو کوڈ کی شکل میں ورکنگ سسٹم میں تبدیل کرتے ہیں (ہاں، کوڈ، بدقسمتی سے، صرف ایک تفصیل ہے، لیکن نظام کا مجسم نہیں)، ترسیل جاری ہے، اور اسی طرح. کل کے منتظمین، نئے طریقوں میں مہارت حاصل کرنے کے بعد، فخر کے ساتھ DevOps انجینئرز کے طور پر دوبارہ تربیت یافتہ ہوئے، اور سب کچھ وہاں سے چلا گیا۔ اور شام ہوئی، اور صبح ہوئی... افسوس، وہاں سے نہیں۔
یہ سب دوبارہ ٹھیک نہیں ہے، خدا کا شکر ہے۔
جیسے ہی سب کچھ پرسکون ہو گیا، اور مختلف چالاک "میتھوڈولوجسٹ" نے DevOps کے طریقوں پر موٹی کتابیں لکھنا شروع کر دیں، تنازعات خاموشی سے اس بارے میں بھڑک اٹھے کہ بدنام زمانہ DevOps انجینئر کون ہے اور DevOps ایک پروڈکشن کلچر ہے، عدم اطمینان دوبارہ پیدا ہو گیا۔ اچانک معلوم ہوا کہ سافٹ ویئر کی ترسیل بالکل غیر معمولی کام ہے۔ ہر ترقیاتی انفراسٹرکچر کا اپنا اسٹیک ہوتا ہے، کہیں آپ کو اسے جمع کرنے کی ضرورت ہوتی ہے، کہیں آپ کو ماحول کو تعینات کرنے کی ضرورت ہوتی ہے، یہاں آپ کو Tomcat کی ضرورت ہوتی ہے، یہاں آپ کو اسے شروع کرنے کے لیے ایک چالاک اور پیچیدہ طریقہ کی ضرورت ہوتی ہے - عام طور پر، آپ کا سر دھڑک رہا ہے۔ اور مسئلہ، عجیب طور پر کافی، بنیادی طور پر عمل کی تنظیم میں نکلا - یہ ترسیل کی تقریب، ایک رکاوٹ کی طرح، عمل کو روکنے کے لئے شروع کر دیا. اس کے علاوہ، کسی نے بھی آپریشن منسوخ نہیں کیا۔ یہ V-ماڈل میں نظر نہیں آتا، لیکن پھر بھی دائیں طرف پورا لائف سائیکل موجود ہے۔ نتیجے کے طور پر، کسی نہ کسی طرح بنیادی ڈھانچے کو برقرار رکھنے، نگرانی کی نگرانی، واقعات کو حل کرنے، اور ترسیل سے نمٹنے کے لئے ضروری ہے. وہ. ترقی اور آپریشن دونوں میں ایک پاؤں کے ساتھ بیٹھنا - اور اچانک یہ ترقی اور آپریشنز نکلا۔ اور پھر مائیکرو سروسز کے لیے عام ہائپ تھی۔ اور ان کے ساتھ، مقامی مشینوں سے ترقی بادل میں منتقل ہونے لگی - مقامی طور پر کچھ ڈیبگ کرنے کی کوشش کریں، اگر درجنوں اور سینکڑوں مائیکرو سروسز ہیں، تو مسلسل ترسیل بقا کا ذریعہ بن جاتی ہے۔ ایک "چھوٹی معمولی کمپنی" کے لیے یہ سب ٹھیک تھا، لیکن پھر بھی؟ گوگل کے بارے میں کیا خیال ہے؟
ایس آر ای بذریعہ گوگل
گوگل آیا، سب سے بڑا کیکٹی کھایا اور فیصلہ کیا - ہمیں اس کی ضرورت نہیں ہے، ہمیں بھروسے کی ضرورت ہے۔ اور وشوسنییتا کا انتظام کیا جانا چاہئے. اور میں نے فیصلہ کیا کہ ہمیں ایسے ماہرین کی ضرورت ہے جو بھروسے کا انتظام کریں گے۔ میں نے انہیں ایس آر انجینئرز کو بلایا اور کہا، یہ آپ کے لیے ہے، اسے معمول کے مطابق کرو۔ یہاں SLI ہے، یہاں SLO ہے، یہاں نگرانی ہے۔ اور اس نے آپریشن میں ناک بھون ڈالی۔ اور اس نے اپنے "قابل اعتماد ڈی او اوپس" کو SRE کہا۔ ایسا لگتا ہے کہ سب کچھ ٹھیک ہے، لیکن ایک گندی ہیک ہے جسے گوگل برداشت کر سکتا ہے - SR انجینئرز کے عہدے کے لیے، ایسے لوگوں کی خدمات حاصل کریں جو اہل ڈویلپر تھے اور تھوڑا سا ہوم ورک بھی کرتے تھے اور ورکنگ سسٹمز کے کام کو سمجھتے تھے۔ مزید برآں، گوگل کو خود ایسے لوگوں کو ملازمت دینے میں مشکلات کا سامنا ہے - بنیادی طور پر اس لیے کہ یہاں وہ خود سے مقابلہ کرتا ہے - کسی کو کاروباری منطق بیان کرنا ضروری ہے۔ ڈیلیوری کو رہائی کے انجینئرز کو تفویض کیا گیا تھا، SR - انجینئرز وشوسنییتا کا انتظام کرتے ہیں (یقیناً، براہ راست نہیں، لیکن بنیادی ڈھانچے کو متاثر کرکے، فن تعمیر کو تبدیل کرکے، تبدیلیوں اور اشارے کو ٹریک کرکے، واقعات سے نمٹنے کے ذریعے)۔ اچھا، آپ کر سکتے ہیں۔ . لیکن اگر آپ گوگل نہیں ہیں، لیکن وشوسنییتا اب بھی کسی نہ کسی طرح ایک تشویش ہے؟
DevOps آئیڈیاز کی ترقی
بس اسی وقت Docker پہنچا، جو lxc سے نکلا، اور پھر مختلف آرکیسٹریشن سسٹم جیسے Docker Swarm اور Kubernetes، اور DevOps انجینئرز نے سانس چھوڑا - طریقوں کے اتحاد نے ترسیل کو آسان بنا دیا۔ اس نے اسے اس حد تک آسان بنا دیا کہ ڈویلپرز کو آؤٹ سورس ڈیلیوری بھی ممکن ہو گئی - deployment.yaml کیا ہے۔ کنٹینرائزیشن مسئلہ حل کرتی ہے۔ اور CI/CD سسٹمز کی پختگی پہلے سے ہی ایک فائل لکھنے کی سطح پر ہے اور ہم چھوڑ دیتے ہیں - ڈویلپر خود اسے سنبھال سکتے ہیں۔ اور پھر ہم اس بارے میں بات کرنا شروع کر دیتے ہیں کہ ہم کس طرح اپنا SRE بنا سکتے ہیں،... یا کم از کم کسی کے ساتھ۔
SRE گوگل پر نہیں ہے۔
ٹھیک ہے، ٹھیک ہے، ہم نے ڈیلیوری کر دی، ایسا لگتا ہے کہ ہم سانس چھوڑ سکتے ہیں، اچھے پرانے دنوں کی طرف لوٹ سکتے ہیں، جب ایڈمنز نے پروسیسر کا بوجھ دیکھا، سسٹم کو ٹیون کیا اور خاموشی سے مگ سے کچھ سمجھ میں نہ آنے والی چیز پی لی۔ یہی وجہ نہیں ہے کہ ہم نے سب کچھ شروع کیا (جو کہ افسوس کی بات ہے!) اچانک یہ پتہ چلا کہ گوگل کے نقطہ نظر میں ہم آسانی سے بہترین طریقوں کو اپنا سکتے ہیں - یہ پروسیسر کا بوجھ نہیں ہے جو اہم ہے، اور یہ نہیں کہ ہم وہاں کتنی بار ڈسک تبدیل کرتے ہیں، یا کلاؤڈ میں لاگت کو بہتر بناتے ہیں، لیکن کاروباری میٹرکس وہی بدنام ہیں ایس ایل ایکس۔ اور کسی نے بھی ان سے انفراسٹرکچر مینجمنٹ کو نہیں ہٹایا ہے، اور انہیں واقعات کو حل کرنے، اور وقتاً فوقتاً ڈیوٹی پر رہنے کی ضرورت ہے، اور عام طور پر کاروباری عمل میں سرفہرست رہنے کی ضرورت ہے۔ اور دوستو، آہستہ آہستہ اچھی سطح پر پروگرامنگ شروع کریں، گوگل پہلے ہی آپ کا انتظار کر رہا ہے۔
مختصر کرنے کے لئے. اچانک، لیکن آپ پڑھ کر پہلے ہی تھک چکے ہیں اور آپ مضمون پر تبصرے میں مصنف کو تھوکنے اور لکھنے کا انتظار نہیں کر سکتے۔ ڈی او اوپس بطور ڈیلیوری پریکٹس ہمیشہ سے رہا ہے اور رہے گا۔ اور یہ کہیں نہیں جا رہا ہے۔ آپریشنل طریقوں کے ایک سیٹ کے طور پر SRE اس کو بہت کامیاب بناتا ہے۔
ماخذ: www.habr.com