DevOps کی تعریف بہت پیچیدہ ہے، لہذا ہمیں ہر بار اس کے بارے میں بحث دوبارہ شروع کرنی ہوگی۔ صرف Habré پر اس موضوع پر ایک ہزار اشاعتیں ہیں۔ لیکن اگر آپ اسے پڑھ رہے ہیں، تو آپ کو شاید معلوم ہوگا کہ DevOps کیا ہے۔ کیونکہ میں نہیں ہوں۔ ہیلو! میرا نام ہے الیگزینڈر ٹائٹوف (@)، اور ہم صرف DevOps کے بارے میں بات کریں گے اور میں اپنا تجربہ شیئر کروں گا۔
میں ایک طویل عرصے سے سوچ رہا ہوں کہ اپنی کہانی کو کس طرح کارآمد بنایا جائے، اس لیے یہاں بہت سارے سوالات ہوں گے - وہ جو میں خود سے پوچھتا ہوں اور وہ جو میں اپنی کمپنی کے گاہکوں سے پوچھتا ہوں۔ ان سوالوں کے جواب دینے سے سمجھ بہتر ہو جاتی ہے۔ میں آپ کو بتاؤں گا کہ میرے نقطہ نظر سے DevOps کی ضرورت کیوں ہے، یہ ایک بار پھر، میرے نقطہ نظر سے کیا ہے، اور یہ کیسے سمجھیں کہ آپ میرے نقطہ نظر سے دوبارہ DevOps کی طرف بڑھ رہے ہیں۔ آخری نکتہ سوالات کے ذریعے ہوگا۔ خود ان کا جواب دے کر، آپ سمجھ سکتے ہیں کہ آیا آپ کی کمپنی DevOps کی طرف بڑھ رہی ہے یا کسی طرح سے مسائل ہیں۔
ایک وقت میں میں انضمام اور حصول کی لہروں پر سوار تھا۔ سب سے پہلے، میں نے Qik نامی ایک چھوٹے اسٹارٹ اپ کے لیے کام کیا، پھر اسے Skype نامی قدرے بڑی کمپنی نے خریدا، جسے پھر مائیکروسافٹ نامی قدرے بڑی کمپنی نے خرید لیا۔ اس وقت، میں نے یہ دیکھنا شروع کیا کہ کس طرح مختلف سائز کی کمپنیوں میں DevOps کا آئیڈیا تبدیل ہو رہا ہے۔ اس کے بعد، میں ڈی او اوپس کو مارکیٹ کے نقطہ نظر سے دیکھنے میں دلچسپی لینے لگا، اور میں نے اور میرے ساتھیوں نے کمپنی ایکسپریس 42 کی بنیاد رکھی۔ اب 6 سال سے ہم مارکیٹ کی لہروں کے ساتھ آگے بڑھ رہے ہیں۔
دیگر چیزوں کے علاوہ، میں DevOps ماسکو کمیونٹی کے منتظمین اور DevOps-Days 2017 کے منتظمین میں سے ایک ہوں، لیکن میں نے 2018 کا اہتمام نہیں کیا۔ ایکسپریس 42 بہت سی کمپنیوں کے ساتھ کام کرتا ہے۔ ہم وہاں DevOps کو بڑھاتے ہیں، دیکھتے ہیں کہ یہ کیسے ہوتا ہے، نتیجہ اخذ کرتے ہیں، تجزیہ کرتے ہیں، ہر کسی کو اپنے نتائج بتاتے ہیں، اور لوگوں کو DevOps طریقوں میں تربیت دیتے ہیں۔ عام طور پر، ہم اس سلسلے میں اپنے تجربے اور مہارت کو بڑھانے کی پوری کوشش کر رہے ہیں۔
کیوں DevOps
پہلا سوال جو ہر کسی کو پریشان کرتا ہے اور ہمیشہ ہے - کیوں؟ بہت سے لوگوں کا خیال ہے کہ DevOps صرف آٹومیشن ہے یا ایسی ہی چیز ہے جو ہر کمپنی کے پاس پہلے سے موجود تھی۔
- ہمارے پاس مسلسل انٹیگریشن تھا - اس کا مطلب ہے کہ ہمارے پاس پہلے سے ڈی او اوپس موجود ہیں، اور اس سب چیزوں کی ضرورت کیوں ہے؟ وہ بیرون ملک مزے کر رہے ہیں، لیکن وہ ہمیں کام کرنے سے روک رہے ہیں!
کمیونٹی اور طریقہ کار کی ترقی کے 9 سالوں میں، یہ پہلے ہی واضح ہو گیا ہے کہ یہ اب بھی مارکیٹنگ کی چمک نہیں ہے، لیکن یہ ابھی تک پوری طرح سے واضح نہیں ہے کہ اس کی ضرورت کیوں ہے. کسی بھی ٹول اور عمل کی طرح، DevOps کے مخصوص اہداف ہیں جو وہ بالآخر حاصل کرتا ہے۔
یہ سب اس حقیقت کی وجہ سے ہے کہ دنیا بدل رہی ہے۔ وہ انٹرپرائز کے نقطہ نظر سے ہٹ جاتا ہے، جب کمپنیاں سیدھے خواب کی طرف بڑھ جاتی ہیں، جیسا کہ ہمارے سینٹ پیٹرزبرگ کلاسک نے گایا تھا، پوائنٹ A سے پوائنٹ B تک ایک خاص حکمت عملی کے مطابق، اس کے لیے ایک خاص ڈھانچہ بنایا گیا تھا۔
اصولی طور پر، آئی ٹی میں ہر چیز کو اس نقطہ نظر کے مطابق بنایا جانا چاہیے۔ یہاں IT کا استعمال خصوصی طور پر عمل کو خودکار کرنے کے لیے کیا جاتا ہے۔
آٹومیشن اکثر تبدیل نہیں ہوتا ہے، کیونکہ جب کوئی کمپنی اچھی طرح سے روڑے ہوئے ہو جاتی ہے، تو اس میں تبدیلی کی کیا ضرورت ہے؟ یہ کام کرتا ہے - اسے ہاتھ نہ لگائیں۔ اب دنیا میں نقطہ نظر تبدیل ہو رہے ہیں، اور ایگیل نامی ایک تجویز کرتا ہے کہ اختتامی نقطہ B فوری طور پر نظر نہیں آتا۔
جب کوئی کمپنی مارکیٹ سے گزرتی ہے، کسی کلائنٹ کے ساتھ کام کرتی ہے، تو وہ مسلسل مارکیٹ کو تلاش کرتی ہے اور اختتامی نقطہ B کو تبدیل کرتی ہے۔ مزید یہ کہ کمپنی جتنی بار اپنی سمت بدلتی ہے، آخر میں وہ اتنی ہی کامیاب ہوتی ہے، کیونکہ وہ زیادہ مارکیٹ کا انتخاب کرتی ہے۔ طاق
حکمت عملی کا مظاہرہ ایک دلچسپ کمپنی نے کیا ہے جس کے بارے میں میں نے حال ہی میں سیکھا ہے۔ ون باکس شیو ایک ڈبے میں ریزر اور شیونگ لوازمات کے لیے سبسکرپشن ڈیلیوری سروس ہے۔ وہ جانتے ہیں کہ مختلف کلائنٹس کے لیے اپنے "باکس" کو کس طرح اپنی مرضی کے مطابق بنانا ہے۔ یہ ایک مخصوص سافٹ ویئر کے ذریعہ کیا جاتا ہے، جو اس کے بعد سامان تیار کرنے والی کوریائی فیکٹری کو آرڈر بھیجتا ہے۔
اس پروڈکٹ کو یونی لیور نے 1 بلین ڈالر میں خریدا تھا۔ اب اس کا مقابلہ Gillette سے ہے اور اس نے امریکی مارکیٹ میں صارفین کا نمایاں حصہ چھین لیا ہے۔ ون باکس شیو کہتے ہیں:
- 4 بلیڈ؟ کیا آپ سنجیدگی سے ہیں؟ آپ کو اس کی ضرورت کیوں ہے - یہ مونڈنے کے معیار کو بہتر نہیں کرتا ہے۔ ایک خاص طور پر منتخب کردہ کریم، خوشبو اور دو بلیڈوں کے ساتھ ایک اعلیٰ معیار کا استرا ان بیوقوف 4 جیلیٹ بلیڈوں سے کہیں زیادہ مسائل حل کرتا ہے! کیا ہم جلد ہی 10 تک پہنچ جائیں گے؟
اس طرح دنیا بدلتی ہے۔ یونی لیور کا دعویٰ ہے کہ ان کے پاس ایک ٹھنڈا آئی ٹی سسٹم ہے جو آپ کو ایسا کرنے کی اجازت دیتا ہے۔ آخر میں یہ ایک تصور کی طرح لگتا ہے۔ بازار جانے کا وقتجس کے بارے میں پہلے ہی کسی نے بات نہیں کی۔
ٹائم ٹو مارکیٹ کا نقطہ یہ نہیں ہے کہ ہم کتنی بار تعینات کرتے ہیں۔ آپ اکثر تعینات کر سکتے ہیں، لیکن رہائی کے چکر طویل ہوں گے۔ اگر تین ماہ کے ریلیز سائیکل کو ایک دوسرے پر سپرد کیا جاتا ہے، انہیں ایک ہفتے تک منتقل کیا جاتا ہے، تو یہ پتہ چلتا ہے کہ کمپنی ہفتے میں ایک بار تعیناتی کر رہی ہے۔ اور آئیڈیا سے حتمی نفاذ تک 3 ماہ لگتے ہیں۔
ٹائم ٹو مارکیٹ خیال سے حتمی نفاذ تک کے وقت کو کم سے کم کرنے کے بارے میں ہے۔
اس صورت میں، سافٹ ویئر مارکیٹ کے ساتھ بات چیت کرتا ہے۔ ون باکس شیو ویب سائٹ کلائنٹ کے ساتھ اس طرح بات چیت کرتی ہے۔ ان کے پاس سیلز لوگ نہیں ہیں - صرف ایک ویب سائٹ جہاں زائرین کلک کرتے ہیں اور خواہشات چھوڑتے ہیں۔ اس کے مطابق، کچھ نیا مسلسل سائٹ پر پوسٹ کیا جانا چاہئے اور خواہشات کے مطابق اپ ڈیٹ کیا جانا چاہئے. مثال کے طور پر، جنوبی کوریا میں وہ روس کے مقابلے میں مختلف طریقے سے شیو کرتے ہیں، اور وہ دیودار کی نہیں بلکہ، مثال کے طور پر، گاجر اور ونیلا کی خوشبو پسند کرتے ہیں۔
چونکہ سائٹ کے مواد کو فوری طور پر تبدیل کرنا ضروری ہے، سوفٹ ویئر کی ترقی میں بہت زیادہ تبدیلیاں آتی ہیں۔ سافٹ ویئر کے ذریعے ہمیں یہ معلوم کرنا چاہیے کہ کلائنٹ کیا چاہتا ہے۔ پہلے، ہم نے یہ کچھ چکر لگانے کے طریقوں سے سیکھا تھا، مثال کے طور پر، کاروباری انتظام کے ذریعے۔ پھر ہم نے اسے ڈیزائن کیا، ضروریات کو IT سسٹم میں ڈالا، اور سب کچھ ٹھنڈا تھا۔ اب یہ مختلف ہے - سافٹ ویئر کو ہر اس شخص نے ڈیزائن کیا ہے جو اس عمل میں شامل ہے، بشمول انجینئرز، کیونکہ تکنیکی تفصیلات کے ذریعے وہ سیکھتے ہیں کہ مارکیٹ کیسے کام کرتی ہے اور کاروبار کے ساتھ اپنی بصیرت کا اشتراک بھی کرتی ہے۔
مثال کے طور پر، کیک میں ہمیں اچانک معلوم ہوا کہ لوگ واقعی سرور پر رابطہ فہرستیں اپ لوڈ کرنا پسند کرتے ہیں، اور انہوں نے ہمیں ایک درخواست فراہم کی۔ شروع میں ہم نے اس کے بارے میں نہیں سوچا۔ ایک کلاسک کمپنی میں، سب نے فیصلہ کیا ہوگا کہ یہ ایک بگ ہے، چونکہ قیاس میں یہ نہیں کہا گیا تھا کہ اسے بہت اچھا کام کرنا چاہیے اور عام طور پر گھٹنے پر لاگو کیا جاتا ہے، اس لیے وہ اس فیچر کو بند کر دیتے اور کہتے: "کسی کو اس کی ضرورت نہیں، سب سے اہم بات یہ ہے کہ مرکزی فعالیت کام کرتی ہے۔ اور ٹیکنالوجی کمپنی اسے ایک موقع کے طور پر دیکھتی ہے اور اس کے مطابق سافٹ ویئر کو تبدیل کرنا شروع کر دیتی ہے۔
1968 میں، ایک بصیرت آدمی، میلون کونوے، نے مندرجہ ذیل خیال تیار کیا۔
نظام کو تخلیق کرنے والی تنظیم ایک ایسے ڈیزائن کے ذریعے محدود ہے جو اس تنظیم کے مواصلاتی ڈھانچے کو نقل کرتا ہے۔
مزید تفصیل میں، ایک مختلف قسم کے نظام تیار کرنے کے لیے، آپ کے پاس ایک مختلف قسم کی کمپنی کے اندر مواصلاتی ڈھانچہ بھی ہونا چاہیے۔ اگر آپ کا مواصلاتی ڈھانچہ اعلی درجے کا ہے، تو یہ آپ کو ایسے نظام بنانے کی اجازت نہیں دے گا جو وقت سے مارکیٹ کے لیے بہت زیادہ اشارے فراہم کر سکے۔
پڑھیں ایک کر سکتے ہیں . DevOps ثقافت یا فلسفہ کو سمجھنے کے لیے یہ ضروری ہے کیونکہ واحد چیز جو بنیادی طور پر ڈی او اوپس میں تبدیل ہوتی ہے وہ ہے ٹیموں کے درمیان رابطے کا ڈھانچہ.
عمل کے نقطہ نظر سے، DevOps سے پہلے، تمام مراحل: تجزیات، ترقی، جانچ، آپریشن، لکیری تھے۔
DevOps کے معاملے میں، یہ تمام عمل ایک ساتھ ہوتے ہیں۔
ٹائم ٹو مارکیٹ ہی واحد طریقہ ہے جسے کیا جا سکتا ہے۔ ان لوگوں کے لیے جنہوں نے پرانے عمل میں کام کیا، یہ کسی حد تک کائناتی اور عام طور پر ایسا لگتا ہے۔
تو آپ کو DevOps کی ضرورت کیوں ہے؟
ڈیجیٹل مصنوعات کی ترقی کے لیے. اگر آپ کی کمپنی کے پاس ڈیجیٹل پروڈکٹ نہیں ہے، تو DevOps کی ضرورت نہیں ہے - یہ بہت اہم ہے۔
DevOps ترتیب وار سافٹ ویئر پروڈکشن کی رفتار کی حدود پر قابو پاتا ہے۔. اس میں تمام عمل بیک وقت ہوتے ہیں۔
مشکل بڑھ جاتی ہے۔ جب DevOps مبشر آپ کو بتاتے ہیں کہ یہ آپ کے لیے سافٹ ویئر کو ریلیز کرنا آسان بنا دے گا، تو یہ بکواس ہے۔
DevOps کے ساتھ، چیزیں صرف اور زیادہ پیچیدہ ہوں گی۔
ایویٹو اسٹینڈ پر کانفرنس میں، آپ دیکھ سکتے تھے کہ ڈوکر کنٹینر کو تعینات کرنا کیسا تھا - ایک غیر حقیقی کام۔ پیچیدگی ممنوع ہو جاتی ہے؛ آپ کو ایک ہی وقت میں کئی گیندوں کو جگانا پڑتا ہے۔
DevOps کمپنی میں عمل اور تنظیم کو مکمل طور پر تبدیل کرتا ہے۔ — زیادہ واضح طور پر، یہ DevOps نہیں ہے جو تبدیل ہوتا ہے، لیکن ڈیجیٹل مصنوعات۔ DevOps پر آنے کے لیے، آپ کو ابھی بھی اس عمل کو مکمل طور پر تبدیل کرنے کی ضرورت ہے۔
ایک ماہر کے لیے سوالات
تمھارے پاس کیاہے؟ وہ سوالات جو آپ کسی کمپنی میں کام کرتے ہوئے اور بطور ماہر ترقی کرتے ہوئے اپنے آپ سے پوچھ سکتے ہیں۔
کیا آپ کے پاس ڈیجیٹل پروڈکٹ بنانے کی حکمت عملی ہے؟ اگر وہاں ہے تو، یہ پہلے سے ہی اچھا ہے. اس کا مطلب ہے کہ آپ کی کمپنی DevOps کی طرف بڑھ رہی ہے۔
کیا آپ کی کمپنی پہلے ہی ڈیجیٹل پروڈکٹ بنا رہی ہے؟ اس کا مطلب یہ ہے کہ آپ ایک اور سطح کو اونچا کر سکتے ہیں اور مزید دلچسپ طریقے سے کام کر سکتے ہیں – ایک بار پھر DevOps نقطہ نظر سے۔ میں صرف اس نقطہ نظر سے بات کر رہا ہوں۔
کیا آپ کی کمپنی ڈیجیٹل پروڈکٹ میں مارکیٹ لیڈرز میں سے ایک ہے؟ Spotify، Yandex، Uber وہ کمپنیاں ہیں جو اب تکنیکی ترقی کے عروج پر ہیں۔
اپنے آپ سے یہ سوالات پوچھیں، اور اگر تمام جوابات نفی میں ہیں، تو شاید آپ کو اس کمپنی میں DevOps نہیں کرنا چاہیے۔ اگر DevOps کا موضوع واقعی آپ کے لیے دلچسپ ہے، تو شاید... آپ کو کسی دوسری کمپنی میں جانا چاہیے؟ اگر آپ کی کمپنی DevOps میں جانا چاہتی ہے، لیکن آپ نے تمام سوالات کا جواب "نہیں" میں دیا، تو یہ اس خوبصورت گینڈے کی طرح ہے جو کبھی نہیں بدلے گا۔
تنظیم
جیسا کہ میں نے کہا، کانوے کے قانون کے مطابق، کمپنی کی تنظیم بدل جاتی ہے۔ میں اس چیز سے شروع کروں گا جو تنظیمی نقطہ نظر سے DevOps کو کمپنی کے اندر گھسنے سے روکتی ہے۔
"کنویں" کا مسئلہ
انگریزی لفظ "Silo" کا ترجمہ یہاں روسی میں "well" کیا گیا ہے۔ اس مسئلہ کا نکتہ یہ ہے۔ ٹیموں کے درمیان معلومات کا کوئی تبادلہ نہیں ہے۔. ہر ٹیم نیویگیٹ کرنے کے لیے ایک مشترکہ نقشہ بنائے بغیر اپنی مہارت کی گہرائی میں کھودتی ہے۔
کچھ طریقوں سے یہ مجھے ایک ایسے شخص کی یاد دلاتا ہے جو ابھی ماسکو پہنچا ہے اور ابھی تک یہ نہیں جانتا کہ میٹرو کے نقشے پر کیسے جانا ہے۔ Muscovites عام طور پر اپنے علاقے کو اچھی طرح جانتے ہیں، اور پورے ماسکو میں وہ میٹرو کا نقشہ استعمال کر سکتے ہیں۔ جب آپ پہلی بار ماسکو آتے ہیں، تو آپ کے پاس یہ ہنر نہیں ہے، اور آپ صرف مایوسی کا شکار ہیں۔
ڈی او اوپس تجویز کرتا ہے کہ اس گمراہی کے لمحے سے گزریں اور تمام محکمے مل کر کام کر رہے ہیں تاکہ ایک مشترکہ تعامل کا نقشہ بنایا جا سکے۔
اس میں دو عوامل رکاوٹ ہیں۔
کارپوریٹ مینجمنٹ سسٹم کا نتیجہ۔ یہ الگ الگ درجہ بندی کے "کنویں" میں بنایا گیا ہے۔ مثال کے طور پر، کمپنیوں میں کچھ KPIs ہیں جو اس سسٹم کو سپورٹ کرتی ہیں۔ دوسری طرف، ایک ایسے شخص کا دماغ جو اپنی مہارت کی حدود سے باہر جانا اور پورے نظام کو چلانا مشکل محسوس کرتا ہے، راستے میں آ جاتا ہے۔ یہ صرف غیر آرام دہ ہے۔ تصور کریں کہ آپ بنکاک ہوائی اڈے پر ہیں - آپ کو جلدی سے اپنا راستہ نہیں ملے گا۔ DevOps کو نیویگیٹ کرنا بھی مشکل ہے، اور اسی وجہ سے لوگ کہتے ہیں کہ آپ کو وہاں جانے کے لیے گائیڈ تلاش کرنے کی ضرورت ہے۔
لیکن سب سے اہم بات یہ ہے کہ ایک انجینئر کے لیے "کنویں" کا مسئلہ جو DevOps کے جذبے سے لبریز ہے، جس نے Fowler اور دوسری کتابوں کا ایک گچھا پڑھا ہے، اس کا اظہار اس حقیقت سے ہوتا ہے کہ "کنویں" آپ کو "واضح" چیزیں کرنے کی اجازت نہیں دیتے ہیں۔. ہم اکثر DevOps ماسکو کے بعد اکٹھے ہوتے ہیں، ایک دوسرے سے بات کرتے ہیں، اور لوگ شکایت کرتے ہیں:
- ہم صرف CI شروع کرنا چاہتے تھے، لیکن پتہ چلا کہ انتظامیہ کو اس کی ضرورت نہیں تھی۔
یہ بالکل اس لیے ہوتا ہے کہ CI и مسلسل ترسیل کا عمل بہت سے امتحانات کی سرحد پر ہیں۔ بس تنظیمی سطح پر "کنویں" کے مسئلے پر قابو پائے بغیر، آپ آگے نہیں بڑھ پائیں گے، چاہے آپ کچھ بھی کریں اور خواہ کتنا ہی افسوسناک کیوں نہ ہو۔
کمپنی میں اس عمل میں ہر شریک: بیک اینڈ اور فرنٹ اینڈ ڈویلپرز، ٹیسٹنگ، ڈی بی اے، آپریشن، نیٹ ورک، اپنی سمت میں کھودتے ہیں، اور مینیجر کے علاوہ کسی کے پاس مشترکہ نقشہ نہیں ہوتا، جو کسی نہ کسی طرح ان کی نگرانی کرتا ہے اور "تقسیم" کا استعمال کرتے ہوئے ان کا انتظام کرتا ہے۔ اور فتح" کا طریقہ۔
لوگ کسی نہ کسی ستارے یا جھنڈے کے لیے لڑ رہے ہیں، ہر کوئی اپنی مہارت کھود رہا ہے۔
نتیجتاً، جب ان سب کو آپس میں جوڑنے اور مشترکہ پائپ لائن بنانے کا کام اٹھتا ہے، اور ستاروں اور جھنڈوں کے لیے لڑنے کی ضرورت نہیں رہتی، تو سوال یہ پیدا ہوتا ہے کہ بہرحال کیا کیا جائے؟ ہمیں کسی نہ کسی طرح معاہدے پر آنے کی ضرورت ہے، لیکن کسی نے ہمیں اسکول میں یہ نہیں سکھایا کہ یہ کیسے کریں۔ ہمیں اسکول سے ہی پڑھایا جاتا ہے: آٹھویں جماعت - واہ! - ساتویں جماعت کے مقابلے! یہاں بھی ایسا ہی ہے۔
کیا آپ کی کمپنی میں بھی ایسا ہی ہے؟
اسے چیک کرنے کے لیے، آپ اپنے آپ سے درج ذیل سوالات پوچھ سکتے ہیں۔
کیا ٹیمیں عام ٹولز استعمال کرتی ہیں اور ان عام ٹولز میں تبدیلیوں میں تعاون کرتی ہیں؟
ٹیمیں کتنی بار تنظیم نو کرتی ہیں — ایک ٹیم کے کچھ ماہرین دوسری ٹیم میں چلے جاتے ہیں؟ یہ DevOps ماحول میں ہے کہ یہ معمول بن جاتا ہے، کیونکہ بعض اوقات ایک شخص صرف یہ نہیں سمجھ سکتا کہ مہارت کا دوسرا شعبہ کیا کر رہا ہے۔ وہ دوسرے محکمے میں چلا جاتا ہے، وہاں دو ہفتے کام کرتا ہے تاکہ اپنے لیے اس شعبے کے ساتھ واقفیت اور تعامل کا نقشہ بنا سکے۔
کیا تبدیلی کمیٹی بنا کر حالات بدلنا ممکن ہے؟ یا اس کے لیے اعلیٰ ترین انتظام اور سمت کے مضبوط ہاتھ کی ضرورت ہے؟ میں نے حال ہی میں فیس بک پر لکھا کہ کس طرح ایک غیر معروف بینک آرڈرز کے ذریعے ٹولز کو لاگو کر رہا ہے: ہم ایک آرڈر لکھتے ہیں، ہم اسے ایک سال تک نافذ کرتے ہیں، اور دیکھتے ہیں کہ کیا ہوتا ہے۔ یہ، یقینا، طویل اور افسوسناک ہے.
مینیجرز کے لیے کمپنی کی کامیابیوں پر غور کیے بغیر ذاتی کامیابیاں حاصل کرنا کتنا ضروری ہے؟
اگر آپ خود ان سوالات کا جواب دیتے ہیں تو یہ واضح ہو جائے گا کہ آیا آپ کو اپنی کمپنی میں اس طرح کا مسئلہ درپیش ہے۔
بنیادی ڈھانچہ بطور کوڈ
اس مسئلے کے گزر جانے کے بعد، پہلی اہم مشق، جس کے بغیر DevOps میں آگے بڑھنا مشکل ہے، یہ ہے۔ بنیادی ڈھانچہ بطور کوڈ.
اکثر، بنیادی ڈھانچے کو کوڈ کے طور پر مندرجہ ذیل سمجھا جاتا ہے:
- آئیے باش میں ہر چیز کو خودکار بنائیں، خود کو اسکرپٹ سے ڈھانپیں تاکہ منتظمین کو دستی کام کم ہو!
لیکن یہ سچ نہیں ہے۔
کوڈ کے طور پر انفراسٹرکچر کا مطلب یہ ہے کہ آپ جس آئی ٹی سسٹم کے ساتھ کام کرتے ہیں اسے کوڈ کی شکل میں بیان کرتے ہیں تاکہ اس کی حالت کو مسلسل سمجھ سکیں۔
دوسری ٹیموں کے ساتھ مل کر، آپ کوڈ کی شکل میں ایک نقشہ بناتے ہیں جسے ہر کوئی سمجھ سکتا ہے اور اسے نیویگیٹ کر سکتا ہے۔ اس سے کوئی فرق نہیں پڑتا ہے کہ اس نے کیا کیا ہے - شیف، جوابی، نمک، یا Kubernetes میں YAML فائلوں کا استعمال - کوئی فرق نہیں ہے۔
کانفرنس میں، 2GIS کے ایک ساتھی نے بتایا کہ کس طرح انہوں نے Kubernetes کے لیے اپنی اندرونی چیز بنائی، جو انفرادی نظام کی ساخت کو بیان کرتی ہے۔ 500 سسٹمز کو بیان کرنے کے لیے، انہیں ایک علیحدہ ٹول کی ضرورت تھی جو یہ تفصیل تیار کرے۔ جب یہ تفصیل موجود ہو تو، ہر کوئی ایک دوسرے کے ساتھ چیک کر سکتا ہے، تبدیلیوں کی نگرانی کر سکتا ہے، اسے کیسے تبدیل کیا جائے اور اسے کیسے بہتر کیا جائے، کیا غائب ہے۔
متفق ہوں، انفرادی باش اسکرپٹ عام طور پر یہ سمجھ فراہم نہیں کرتی ہیں۔ ایک کمپنی میں جہاں میں کام کرتا تھا، یہاں تک کہ "صرف لکھیں" اسکرپٹ کا نام بھی تھا - جب اسکرپٹ لکھا جاتا ہے، لیکن اسے پڑھنا اب ممکن نہیں ہے۔ مجھے لگتا ہے کہ یہ آپ کو بھی واقف ہے۔
بنیادی ڈھانچہ جیسا کہ کوڈ ہے۔ کوڈ جو بنیادی ڈھانچے کی موجودہ حالت کو بیان کرتا ہے۔. بہت سے پروڈکٹ، انفراسٹرکچر، اور سروس ٹیمیں اس کوڈ پر مل کر کام کرتی ہیں، اور سب سے اہم بات، ان سب کو یہ سمجھنے کی ضرورت ہے کہ یہ کوڈ دراصل کیسے کام کرتا ہے۔
کوڈ کو بہترین کوڈ کے طریقوں کے مطابق برقرار رکھا جاتا ہے۔: مشترکہ ترقی، کوڈ کا جائزہ، XP-پروگرامنگ، ٹیسٹنگ، پل کی درخواستیں، کوڈ انفراسٹرکچر کے لیے CI - یہ سب موزوں ہے اور استعمال کیا جا سکتا ہے۔
کوڈ تمام انجینئرز کے لیے ایک مشترکہ زبان بن جاتا ہے۔
کوڈ میں بنیادی ڈھانچے کو تبدیل کرنے میں زیادہ وقت نہیں لگتا ہے۔. ہاں، انفراسٹرکچر کوڈ میں تکنیکی قرض بھی ہو سکتا ہے۔ عام طور پر ٹیموں کا سامنا ڈیڑھ سال بعد ہوتا ہے جب انہوں نے اسکرپٹ کے ایک گروپ یا حتی کہ جوابی شکل میں "انفراسٹرکچر بطور کوڈ" کو لاگو کرنا شروع کیا، جسے وہ اسپگیٹی کوڈ کی طرح لکھتے ہیں، اور وہ باش اسکرپٹ کو بھی مکس میں ڈال دیتے ہیں!
یہ ضروری ہے: اگر آپ نے ابھی تک یہ چیز آزمائی نہیں ہے تو یاد رکھیں جواب دینے والا باش نہیں ہے۔! دستاویزات کو غور سے پڑھیں، مطالعہ کریں کہ وہ اس کے بارے میں کیا لکھتے ہیں۔
انفراسٹرکچر بطور کوڈ انفراسٹرکچر کوڈ کو الگ الگ تہوں میں الگ کرنا ہے۔
ہماری کمپنی میں، ہم 3 بنیادی تہوں میں فرق کرتے ہیں، جو بہت واضح اور سادہ ہیں، لیکن ان میں سے اور بھی ہو سکتی ہیں۔ آپ اپنے انفراسٹرکچر کوڈ کو دیکھ کر بتا سکتے ہیں کہ آپ کی یہ حالت ہے یا نہیں۔ اگر کوئی تہہ نمایاں نہیں ہوتی ہے، تو آپ کو کچھ وقت اور تھوڑا سا ری فیکٹر کرنے کی ضرورت ہے۔
بیس پرت - اس طرح OS، بیک اپ اور دیگر نچلی سطح کی چیزیں ترتیب دی جاتی ہیں، مثال کے طور پر، کس طرح بنیادی سطح پر Kubernetes کو تعینات کیا جاتا ہے۔
خدمت کا درجہ - یہ وہ خدمات ہیں جو آپ ڈویلپر کو فراہم کرتے ہیں: سروس کے طور پر لاگنگ، سروس کے طور پر نگرانی، سروس کے طور پر ڈیٹا بیس، سروس کے طور پر بیلنس، سروس کے طور پر قطار، سروس کے طور پر مسلسل ڈیلیوری - خدمات کا ایک گروپ جو انفرادی ٹیمیں ترقی فراہم کر سکتے ہیں۔ یہ سب آپ کے کنفیگریشن مینجمنٹ سسٹم میں الگ الگ ماڈیولز میں بیان کرنے کی ضرورت ہے۔
وہ پرت جہاں ایپلیکیشنز بنائی جاتی ہیں۔ اور بیان کرتا ہے کہ وہ پچھلی دو تہوں کے اوپر کیسے کھلیں گے۔
سوالات کو کنٹرول کریں۔
کیا آپ کی کمپنی کے پاس بنیادی ڈھانچے کا مشترکہ ذخیرہ ہے؟ کیا آپ اپنے بنیادی ڈھانچے میں تکنیکی قرض کا انتظام کر رہے ہیں؟ کیا آپ انفراسٹرکچر کے ذخیرے میں ترقیاتی طریقوں کا استعمال کرتے ہیں؟ کیا آپ کا بنیادی ڈھانچہ تہوں میں کٹا ہوا ہے؟ آپ Base-service-APP ڈایاگرام کو چیک کر سکتے ہیں۔ تبدیلی لانا کتنا مشکل ہے؟
اگر آپ نے تجربہ کیا ہے کہ تبدیلیاں کرنے میں ڈیڑھ دن لگے تو اس کا مطلب ہے کہ آپ پر تکنیکی قرض ہے اور اس کے ساتھ کام کرنے کی ضرورت ہے۔ آپ نے ابھی اپنے انفراسٹرکچر کوڈ میں ایک تکنیکی قرض کے ریک سے ٹھوکر کھائی۔ مجھے ایسی بہت سی کہانیاں یاد ہیں جب کچھ سی سی ٹی ایل کو تبدیل کرنے کے لیے، آپ کو انفراسٹرکچر کوڈ کا آدھا حصہ دوبارہ لکھنا پڑتا ہے، کیونکہ تخلیقی صلاحیت اور ہر چیز کو خودکار بنانے کی خواہش اس حقیقت کا باعث بنی کہ ہر چیز ہر جگہ خراب ہو چکی ہے، تمام ہینڈل ہٹا دیے گئے ہیں، اور یہ ری ایکٹر کے لئے ضروری ہے.
مسلسل ترسیل
آئیے ڈیبٹ کا کریڈٹ کے ساتھ موازنہ کریں۔ سب سے پہلے بنیادی ڈھانچے کی تفصیل آتی ہے، جو کافی بنیادی ہو سکتی ہے۔ آپ کو ہر چیز کو تفصیل سے بیان کرنے کی ضرورت نہیں ہے، لیکن کچھ بنیادی تفصیل درکار ہے تاکہ آپ اس کے ساتھ کام کر سکیں۔ دوسری صورت میں، یہ واضح نہیں ہے کہ آگے مسلسل ترسیل کے ساتھ کیا کرنا ہے. جب آپ DevOps پر آتے ہیں تو یہ تمام مشقیں بیک وقت سامنے آتی ہیں، لیکن یہ اس بات کو سمجھنے سے شروع ہوتی ہے کہ آپ کے پاس کیا ہے اور اس کا نظم کیسے کریں۔ بنیادی ڈھانچے کا بطور ضابطہ عمل یہی ہے۔
ایک بار جب یہ واضح ہو جائے کہ آپ کے پاس یہ ہے اور اس کا انتظام کیسے کریں، آپ یہ جاننا شروع کر دیتے ہیں کہ ڈویلپر کوڈ کو پروڈکشن میں جلد سے جلد کیسے بھیجنا ہے۔ میرا مطلب ہے ڈویلپر کے ساتھ مل کر - ہمیں "کنویں" کے مسئلے کے بارے میں یاد ہے، یعنی یہ انفرادی لوگ نہیں ہیں جو اس کے ساتھ آتے ہیں، بلکہ ایک ٹیم ہے۔
جب ہم ساتھ ہوتے ہیں۔ وانیا ایوتخووچ پہلی کتاب دیکھی۔ جیز عاجز اور مصنفین کے گروپ "مسلسل ترسیل"، جو 2009 میں جاری کیا گیا تھا، ہم نے طویل عرصے تک سوچا کہ اس کے عنوان کا روسی میں ترجمہ کیسے کیا جائے۔ وہ اس کا ترجمہ "مسلسل ترسیل" کے طور پر کرنا چاہتے تھے، لیکن، بدقسمتی سے، اس کا ترجمہ "مسلسل ترسیل" کے طور پر کیا گیا۔ مجھے ایسا لگتا ہے کہ ہمارے نام میں کچھ روسی ہے، دباؤ کے ساتھ۔
مسلسل ذرائع کی فراہمی
پروڈکٹ ریپوزٹری میں موجود کوڈ کو ہمیشہ پروڈکشن میں ڈاؤن لوڈ کیا جا سکتا ہے۔. ہو سکتا ہے کہ وہ بے بس نہ ہو، لیکن وہ اس کے لیے ہمیشہ تیار رہتا ہے۔ اس کے مطابق، آپ ہمیشہ اپنی دم کی ہڈی کے نیچے کسی پریشانی کے احساس کے ساتھ کوڈ لکھتے ہیں۔ یہ اکثر ظاہر ہوتا ہے جب آپ انفراسٹرکچر کوڈ کو رول آؤٹ کرتے ہیں۔ کچھ پریشانی کا یہ احساس موجود ہونا چاہئے - یہ دماغی عمل کو متحرک کرتا ہے جو آپ کو کوڈ کو تھوڑا مختلف طریقے سے لکھنے کی اجازت دیتا ہے۔ یہ ترقی کے اندر اندر قواعد میں درج کیا جانا چاہئے.
مسلسل ڈیلیور کرنے کے لیے، آپ کو ایک آرٹفیکٹ فارمیٹ کی ضرورت ہے جو انفراسٹرکچر پلیٹ فارم پر چلتا ہو۔ اگر آپ انفراسٹرکچر پلیٹ فارم پر مختلف فارمیٹس کا "زندگی کا ضیاع" پھینک دیتے ہیں، تو یہ متحد ہو جاتا ہے، اسے برقرار رکھنا مشکل ہو جاتا ہے، اور تکنیکی قرض کا مسئلہ پیدا ہوتا ہے۔ فن پارے کی شکل کو ترتیب دینے کی ضرورت ہے - یہ بھی ایک اجتماعی کام ہے: ہم سب کو اکٹھا ہونا، اپنے دماغ کو ہلانا اور اس فارمیٹ کے ساتھ آنے کی ضرورت ہے۔
آرٹفیکٹ کو مسلسل بہتر بنایا جاتا ہے اور پیداواری ماحول کے مطابق بدلتا ہے کیونکہ یہ ترسیل پائپ لائن سے گزرتا ہے۔ جب کوئی آرٹفیکٹ پائپ لائن کے ساتھ حرکت کرتا ہے، تو اسے مسلسل کچھ چیزوں کا سامنا کرنا پڑتا ہے جو اس کے لیے تکلیف دہ ہوتی ہیں، جو کہ آپ کے پروڈکشن میں ڈالے جانے والے فن پارے سے ملتی جلتی ہیں۔ اگر کلاسیکی ترقی میں یہ ایک سسٹم ایڈمنسٹریٹر کے ذریعہ کیا جاتا ہے جو رول آؤٹ کرتا ہے، تو پھر DevOps کے عمل میں یہ ہر وقت ہوتا ہے: یہاں انہوں نے اسے کچھ ٹیسٹوں کے ساتھ آزمایا، یہاں انہوں نے اسے Kubernetes کلسٹر میں پھینک دیا، جو کم و بیش اسی طرح کا ہے۔ پیداوار کے لیے، پھر اچانک انہوں نے لوڈ ٹیسٹنگ شروع کر دی۔
یہ کسی حد تک Pac-Man گیم کی یاد دلاتا ہے - نمونہ کسی قسم کی کہانی سے گزرتا ہے۔ ایک ہی وقت میں، یہ کنٹرول کرنا ضروری ہے کہ آیا کوڈ حقیقت میں کہانی سے گزرتا ہے اور آیا یہ کسی طرح آپ کی پروڈکشن سے متعلق ہے۔ پیداوار کی کہانیوں کو مسلسل ترسیل کے عمل میں گھسیٹا جا سکتا ہے: ایسا ہوتا تھا جب کچھ گر جاتا تھا، اب آئیے صرف اس منظر نامے کو سسٹم کے اندر پروگرام کرتے ہیں۔ ہر بار کوڈ اس منظر نامے سے بھی گزرے گا، اور آپ کو اگلی بار اس مسئلے کا سامنا نہیں کرنا پڑے گا۔ آپ اس کے بارے میں آپ کے کلائنٹ تک پہنچنے سے بہت پہلے جان لیں گے۔
تعیناتی کی مختلف حکمت عملی۔ مثال کے طور پر، آپ مختلف کلائنٹس پر کوڈ کو مختلف طریقے سے جانچنے کے لیے AB ٹیسٹنگ یا کینری تعیناتیوں کا استعمال کرتے ہیں، اس بارے میں معلومات حاصل کرتے ہیں کہ کوڈ کیسے کام کرتا ہے، اور اس سے بہت پہلے جب اسے 100 ملین صارفین تک پہنچایا جاتا ہے۔
"مسلسل ڈیلیور کریں" ایسا لگتا ہے۔
ڈیلیوری کا عمل Dev, CI, Test, PreProd, Prod کوئی الگ ماحول نہیں ہے، یہ ایسے مراحل یا اسٹیشن ہیں جن میں فائر پروف رقمیں ہیں جن سے آپ کا نمونہ گزرتا ہے۔
اگر آپ کے پاس انفراسٹرکچر کوڈ ہے جسے بیس سروس اے پی پی کے طور پر بیان کیا گیا ہے تو یہ مدد کرتا ہے۔ تمام اسکرپٹ کو مت بھولنا، اور انہیں اس نمونے کے کوڈ کے طور پر لکھیں، آرٹفیکٹ کو فروغ دینا اور جاتے وقت اسے تبدیل کریں۔
خود ٹیسٹ کے سوالات
فیچر ڈسکرپشن سے لے کر 95 فیصد کیسز میں پروڈکشن میں ریلیز ہونے کا وقت ایک ہفتے سے کم ہے؟ کیا پائپ لائن کے ہر مرحلے پر آرٹفیکٹ کا معیار بہتر ہوتا ہے؟ کیا کوئی ایسی کہانی ہے جس سے گزرتی ہے؟ کیا آپ مختلف تعیناتی کی حکمت عملی استعمال کرتے ہیں؟
اگر تمام جوابات ہاں میں ہیں، تو آپ ناقابل یقین حد تک اچھے ہیں! اپنے جوابات کمنٹس میں لکھیں - مجھے خوشی ہوگی)۔
آپ کی رائے
یہ سب سے مشکل مشق ہے۔ DevOpsConf کانفرنس میں، Infobip کے ایک ساتھی، اس کے بارے میں بات کرتے ہوئے، اپنے الفاظ میں تھوڑا سا الجھا ہوا تھا، کیونکہ یہ واقعی اس حقیقت کے بارے میں ایک بہت پیچیدہ عمل ہے کہ آپ کو ہر چیز کی نگرانی کرنے کی ضرورت ہے!
مثال کے طور پر، بہت عرصہ پہلے، جب میں نے Qik میں کام کیا تھا اور ہمیں احساس ہوا کہ ہمیں ہر چیز کی نگرانی کرنے کی ضرورت ہے۔ ہم نے یہ کیا، اور اب ہمارے پاس Zabbix میں 150 آئٹمز ہیں، جن کی مسلسل نگرانی کی جاتی ہے۔ یہ خوفناک تھا، تکنیکی ڈائریکٹر نے اپنی انگلی اپنے مندر پر گھما دی:
- دوستو، آپ سرور کو غیر واضح چیز کے ساتھ کیوں ریپ کر رہے ہیں؟
لیکن پھر ایک واقعہ پیش آیا جس سے معلوم ہوا کہ یہ واقعی ایک بہت ہی ٹھنڈی حکمت عملی ہے۔
ایک سروس مسلسل کریش ہونے لگی۔ ابتدائی طور پر، یہ کریش نہیں ہوا، جو کہ دلچسپ ہے، وہاں کوڈ شامل نہیں کیا گیا، کیونکہ یہ ایک بنیادی بروکر تھا، جس میں عملی طور پر کوئی کاروباری فعالیت نہیں تھی - یہ صرف انفرادی خدمات کے درمیان پیغامات بھیجتا تھا۔ سروس میں 4 ماہ تک کوئی تبدیلی نہیں آئی، اور اچانک یہ "سیگمنٹیشن فالٹ" کی خرابی کے ساتھ کریش ہونے لگی۔
ہم حیران رہ گئے، Zabbix میں اپنے چارٹ کھولے، اور یہ پتہ چلا کہ ڈیڑھ ہفتہ قبل، API سروس میں درخواستوں کا رویہ جو یہ بروکر استعمال کرتا ہے بہت بدل گیا ہے۔ اس کے بعد ہم نے دیکھا کہ ایک خاص قسم کے پیغام بھیجنے کی فریکوئنسی بدل گئی ہے۔ بعد میں ہمیں پتہ چلا کہ یہ اینڈرائیڈ کلائنٹس تھے۔ ہم نے پوچھا:
- دوستو، ڈیڑھ ہفتہ پہلے تمہیں کیا ہوا تھا؟
جواب میں، ہم نے اس بارے میں ایک دلچسپ کہانی سنی کہ انہوں نے UI کو کیسے دوبارہ ڈیزائن کیا تھا۔ اس بات کا امکان نہیں ہے کہ کوئی بھی فوری طور پر یہ کہے کہ انہوں نے HTTP لائبریری کو تبدیل کر دیا ہے۔ اینڈرائیڈ کلائنٹس کے لیے، یہ باتھ روم میں صابن کو تبدیل کرنے جیسا ہے - انہیں بس یاد نہیں ہے۔ نتیجے کے طور پر، 40 منٹ کی گفتگو کے بعد، ہمیں پتہ چلا کہ انہوں نے HTTP لائبریری کو تبدیل کر دیا ہے، اور اس کے پہلے سے طے شدہ اوقات تبدیل ہو چکے ہیں۔ اس کی وجہ سے API سرور پر ٹریفک کا رویہ تبدیل ہو گیا، جس کی وجہ سے ایسی صورتحال پیدا ہو گئی جس کی وجہ سے بروکر کے اندر دوڑ لگ گئی، اور یہ کریش ہونے لگا۔
گہری نگرانی کے بغیر اسے کھولنا عام طور پر ناممکن ہے۔. اگر تنظیم کو اب بھی "کنوئیں" کا مسئلہ ہے، جب ہر کوئی ایک دوسرے پر پیسہ پھینکتا ہے، تو یہ برسوں تک زندہ رہ سکتا ہے۔ آپ صرف سرور کو دوبارہ شروع کریں کیونکہ مسئلہ کو حل کرنا ناممکن ہے۔ جب آپ اپنے پاس موجود تمام واقعات کی نگرانی کرتے ہیں، ٹریک کرتے ہیں، ٹریک کرتے ہیں، اور مانیٹرنگ کو بطور ٹیسٹنگ استعمال کرتے ہیں - کوڈ لکھیں اور فوری طور پر اشارہ کریں کہ اس کی نگرانی کیسے کی جائے، کوڈ کی شکل میں بھی (ہمارے پاس پہلے سے ہی بنیادی ڈھانچہ بطور کوڈ موجود ہے)، سب کچھ واضح ہو جاتا ہے کہ کیسے ہتھیلی پر یہاں تک کہ اس طرح کے پیچیدہ مسائل کو آسانی سے ٹریک کیا جاتا ہے.
ڈیلیوری کے عمل کے ہر مرحلے پر آرٹفیکٹ کے ساتھ کیا ہوتا ہے اس کے بارے میں تمام معلومات جمع کریں - پیداوار میں نہیں۔
نگرانی کو CI پر اپ لوڈ کریں، اور کچھ بنیادی چیزیں وہاں پہلے سے نظر آئیں گی۔ بعد میں آپ انہیں ٹیسٹ، پری پروڈ، اور لوڈ ٹیسٹنگ میں دیکھیں گے۔ تمام مراحل پر معلومات اکٹھی کریں، نہ صرف میٹرکس، اعداد و شمار، بلکہ لاگز بھی: ایپلیکیشن کیسے شروع ہوئی، بے ضابطگیاں - سب کچھ جمع کریں۔
ورنہ اس کا اندازہ لگانا مشکل ہو جائے گا۔ میں نے پہلے ہی کہا ہے کہ DevOps زیادہ پیچیدہ ہے۔ اس پیچیدگی سے نمٹنے کے لیے، آپ کو عام تجزیات کی ضرورت ہے۔.
خود پر قابو پانے کے لیے سوالات
کیا آپ کی نگرانی اور لاگنگ آپ کے لیے ترقیاتی ٹول ہے؟ کوڈ لکھتے وقت، کیا آپ سمیت آپ کے ڈویلپرز یہ سوچتے ہیں کہ اس کی نگرانی کیسے کی جائے؟
کیا آپ گاہکوں سے مسائل کے بارے میں سنتے ہیں؟ کیا آپ کلائنٹ کو نگرانی اور لاگنگ سے بہتر سمجھتے ہیں؟ کیا آپ نظام کو نگرانی اور لاگنگ سے بہتر سمجھتے ہیں؟ کیا آپ سسٹم کو صرف اس لیے بدلتے ہیں کہ آپ نے دیکھا کہ سسٹم میں رجحان بڑھ رہا ہے اور آپ سمجھتے ہیں کہ مزید 3 ہفتوں میں سب کچھ ختم ہو جائے گا؟
ایک بار جب آپ کے پاس یہ تین اجزاء ہوں تو، آپ سوچ سکتے ہیں کہ آپ کی کمپنی میں کس قسم کا انفراسٹرکچر پلیٹ فارم ہے۔
انفراسٹرکچر پلیٹ فارم
بات یہ نہیں ہے کہ یہ مختلف ٹولز کا ایک سیٹ ہے جو ہر کمپنی کے پاس ہوتا ہے۔
بنیادی ڈھانچے کے پلیٹ فارم کا نقطہ یہ ہے کہ تمام ٹیمیں ان ٹولز کا استعمال کرتی ہیں اور انہیں ایک ساتھ تیار کرتی ہیں۔
یہ واضح ہے کہ الگ الگ ٹیمیں ہیں جو انفراسٹرکچر پلیٹ فارم کے انفرادی ٹکڑوں کی ترقی کے لیے ذمہ دار ہیں۔ لیکن ایک ہی وقت میں، ہر انجینئر انفراسٹرکچر پلیٹ فارم کی ترقی، کارکردگی اور فروغ کی ذمہ داری لیتا ہے۔ اندرونی سطح پر یہ ایک عام ٹول بن جاتا ہے۔.
تمام ٹیمیں انفراسٹرکچر پلیٹ فارم تیار کرتی ہیں اور اسے اپنے IDE کے طور پر دیکھ بھال کے ساتھ پیش کرتی ہیں۔. اپنے IDE میں آپ ہر چیز کو اچھا اور تیز بنانے کے لیے مختلف پلگ ان انسٹال کرتے ہیں، اور ہاٹکیز کو کنفیگر کرتے ہیں۔ جب آپ سبلائم، ایٹم یا ویژول اسٹوڈیو کوڈ کھولتے ہیں، تو کوڈ کی غلطیاں سامنے آتی ہیں اور آپ کو احساس ہوتا ہے کہ یہ بالکل بھی ناممکن ہے، آپ کو فوراً دکھ ہوتا ہے اور آپ اپنا IDE ٹھیک کرنے کے لیے بھاگتے ہیں۔
اپنے انفراسٹرکچر پلیٹ فارم کے ساتھ اسی طرح سلوک کریں۔ اگر آپ سمجھتے ہیں کہ اس میں کچھ گڑبڑ ہے، تو ایک درخواست چھوڑ دیں اگر آپ اسے خود ٹھیک نہیں کر سکتے۔ اگر کوئی آسان چیز ہے تو خود اس میں ترمیم کریں، پل کی درخواست بھیجیں، لوگ اس پر غور کریں گے اور اسے شامل کریں گے۔ یہ ڈویلپر کے سر میں انجینئرنگ ٹولز کے لیے قدرے مختلف نقطہ نظر ہے۔
انفراسٹرکچر پلیٹ فارم معیار میں مسلسل بہتری کے ساتھ آرٹفیکٹ کی ترقی سے کلائنٹ تک منتقلی کو یقینی بناتا ہے۔. آئی پی کو کہانیوں کے ایک سیٹ کے ساتھ پروگرام کیا گیا ہے جو پروڈکشن میں کوڈ کے ساتھ ہوتا ہے۔ ترقی کے سالوں میں، ان میں سے بہت ساری کہانیاں ہیں، ان میں سے کچھ منفرد ہیں اور صرف آپ سے متعلق ہیں - انہیں گوگل نہیں کیا جا سکتا۔
اس وقت، انفراسٹرکچر پلیٹ فارم آپ کا مسابقتی فائدہ بن جاتا ہے۔، کیونکہ اس میں کچھ ایسا بنایا گیا ہے جو حریف کے ٹول میں نہیں ہے۔ آپ کا IP جتنا گہرا ہوگا، ٹائم ٹو مارکیٹ کے لحاظ سے آپ کا مسابقتی فائدہ اتنا ہی زیادہ ہوگا۔ یہاں ظاہر ہوتا ہے۔ وینڈر لاک کا مسئلہ: آپ کسی اور کا پلیٹ فارم لے سکتے ہیں، لیکن کسی اور کے تجربے کو استعمال کرتے ہوئے، آپ نہیں سمجھیں گے کہ یہ آپ کے لیے کتنا متعلقہ ہے۔ ہاں، ہر کمپنی ایمیزون جیسا پلیٹ فارم نہیں بنا سکتی۔ یہ ایک مشکل لائن ہے جہاں کمپنی کا تجربہ مارکیٹ میں اس کی پوزیشن سے متعلق ہے، اور آپ وہاں وینڈر لاک استعمال نہیں کر سکتے۔ اس کے بارے میں سوچنا بھی ضروری ہے۔
ڈرائیونگ
یہ انفراسٹرکچر پلیٹ فارم کا ایک بنیادی خاکہ ہے جو آپ کو DevOps کمپنی میں تمام طریقوں اور عمل کو ترتیب دینے میں مدد کرے گا۔
آئیے دیکھتے ہیں کہ یہ کن چیزوں پر مشتمل ہے۔
ریسورس آرکیسٹریشن سسٹم، جو ایپلی کیشنز اور دیگر خدمات کو CPU، میموری، ڈسک فراہم کرتا ہے۔ اس کے اوپر - کم سطح کی خدمات: نگرانی، لاگنگ، CI/CD انجن، آرٹفیکٹ اسٹوریج، سسٹم کوڈ کے طور پر انفراسٹرکچر۔
اعلی درجے کی خدمات: ڈیٹا بیس بطور سروس، قطاریں بطور سروس، لوڈ بیلنس بطور سروس، تصویر کا سائز تبدیل کرنا بطور سروس، بگ ڈیٹا فیکٹری بطور سروس۔ اس کے اوپر - پائپ لائن جو آپ کے کلائنٹ کو مسلسل تبدیل شدہ کوڈ فراہم کرتی ہے۔.
آپ اس بارے میں معلومات حاصل کرتے ہیں کہ آپ کا سافٹ ویئر کلائنٹ کے لیے کیسے کام کرتا ہے، اسے تبدیل کرتے ہیں، اس کوڈ کو دوبارہ فراہم کرتے ہیں، معلومات حاصل کرتے ہیں - اور اس طرح آپ بنیادی ڈھانچے کے پلیٹ فارم اور اپنے سافٹ ویئر دونوں کو مسلسل تیار کرتے ہیں۔
ڈایاگرام میں، ترسیل پائپ لائن بہت سے مراحل پر مشتمل ہے. لیکن یہ ایک اسکیمیٹک ڈایاگرام ہے جسے ایک مثال کے طور پر دیا گیا ہے - اسے ایک ایک کرکے دہرانے کی ضرورت نہیں ہے۔ مراحل خدمات کے ساتھ اس طرح تعامل کرتے ہیں جیسے وہ خدمات ہوں — پلیٹ فارم کی ہر اینٹ اپنی کہانی رکھتی ہے: وسائل کیسے مختص کیے جاتے ہیں، ایپلیکیشن کیسے شروع کی جاتی ہے، وسائل کے ساتھ کام کیا جاتا ہے، نگرانی کی جاتی ہے اور تبدیلیاں ہوتی ہیں۔
یہ سمجھنا ضروری ہے کہ پلیٹ فارم کے ہر حصے میں ایک کہانی ہوتی ہے، اور اپنے آپ سے پوچھیں کہ یہ اینٹ کون سی کہانی رکھتی ہے، ہو سکتا ہے اسے پھینک دیا جائے اور اس کی جگہ کسی تیسرے فریق کی خدمت کی جائے۔ مثال کے طور پر، کیا اینٹ کے بجائے اوکمیٹر انسٹال کرنا ممکن ہے؟ شاید لڑکوں نے پہلے ہی اس مہارت کو ہم سے کہیں زیادہ تیار کیا ہے۔ لیکن شاید نہیں - شاید ہمارے پاس منفرد مہارت ہے، ہمیں Prometheus کو انسٹال کرنے اور اسے مزید ترقی دینے کی ضرورت ہے۔
پلیٹ فارم کی تخلیق
یہ ایک پیچیدہ مواصلاتی عمل ہے۔ جب آپ کے پاس بنیادی مشقیں ہوتی ہیں، تو آپ مختلف انجینئرز اور ماہرین کے درمیان مواصلت شروع کرتے ہیں جو ضروریات اور معیارات تیار کرتے ہیں، اور انہیں مسلسل مختلف ٹولز اور طریقوں میں تبدیل کرتے ہیں۔ ڈی او اوپس میں جو ثقافت ہمارے پاس ہے وہ یہاں اہم ہے۔
ثقافت کے ساتھ سب کچھ بہت آسان ہے - یہ تعاون اور مواصلات کے بارے میں ہے، یعنی، ایک دوسرے کے ساتھ مشترکہ میدان میں کام کرنے کی خواہش، ایک ساتھ ایک آلہ چلانے کی خواہش۔ یہاں کوئی راکٹ سائنس نہیں ہے - سب کچھ بہت آسان ہے. مثال کے طور پر، ہم سب داخلی دروازے میں رہتے ہیں اور اسے صاف ستھرا رکھتے ہیں - ثقافت کی ایسی سطح۔
تمھارے پاس کیاہے؟
ایک بار پھر، سوالات جو آپ خود سے پوچھ سکتے ہیں۔
کیا انفراسٹرکچر پلیٹ فارم وقف ہے؟ اس کی ترقی کا ذمہ دار کون ہے؟ کیا آپ اپنے بنیادی ڈھانچے کے پلیٹ فارم کے مسابقتی فوائد کو سمجھتے ہیں؟
آپ کو اپنے آپ سے یہ سوالات مسلسل پوچھنے کی ضرورت ہے۔ اگر کسی چیز کو تھرڈ پارٹی سروسز میں منتقل کیا جا سکتا ہے، تو اسے منتقل کر دینا چاہیے؛ اگر کوئی تھرڈ پارٹی سروس آپ کی نقل و حرکت کو روکنا شروع کر دے، تو آپ کو اپنے اندر ایک نظام بنانے کی ضرورت ہے۔
تو، DevOps...
... یہ ایک پیچیدہ نظام ہے، اس میں ہونا چاہیے:
- ڈیجیٹل پروڈکٹ۔
- کاروباری ماڈیول جو اس ڈیجیٹل پروڈکٹ کو تیار کرتے ہیں۔
- پروڈکٹ ٹیمیں جو کوڈ لکھتی ہیں۔
- مسلسل ترسیل کے طریقے۔
- پلیٹ فارمز بطور سروس۔
- بنیادی ڈھانچہ بطور خدمت۔
- بنیادی ڈھانچہ بطور کوڈ۔
- وشوسنییتا کو برقرار رکھنے کے لیے علیحدہ طریقے، جو ڈی او اوپس میں بنائے گئے ہیں۔
- ایک فیڈ بیک پریکٹس جو یہ سب بیان کرتی ہے۔
آپ اس خاکہ کو استعمال کر سکتے ہیں، اس میں روشنی ڈالتے ہوئے کہ آپ کی کمپنی میں کسی نہ کسی شکل میں کیا موجود ہے: کیا یہ تیار ہوا ہے یا اب بھی اسے تیار کرنے کی ضرورت ہے۔
یہ ایک دو ہفتوں میں ختم ہو جائے گا۔ . RIT++ کے حصے کے طور پر۔ کانفرنس میں آئیں، جہاں آپ کو مسلسل ڈیلیوری، کوڈ کے طور پر انفراسٹرکچر اور DevOps کی تبدیلی کے بارے میں بہت سی عمدہ رپورٹس ملیں گی۔ قیمت کی آخری تاریخ 20 مئی ہے۔
ماخذ: www.habr.com