میں نے حال ہی میں Logrocon کے زیر اہتمام DevOpsForum 2019 میں شرکت کی۔ اس کانفرنس میں، شرکاء نے کاروبار اور ترقی اور انفارمیشن ٹیکنالوجی سروس کے ماہرین کے درمیان موثر تعامل کے لیے حل اور نئے ٹولز تلاش کرنے کی کوشش کی۔
کانفرنس کامیاب رہی: واقعی بہت ساری مفید رپورٹس، پریزنٹیشن کے دلچسپ فارمیٹس اور مقررین کے ساتھ بہت ساری بات چیت تھی۔ اور یہ خاص طور پر اہم ہے کہ کسی نے مجھے کچھ بھی بیچنے کی کوشش نہیں کی، ایسی چیز جس کے لیے بڑی کانفرنسوں میں مقررین حال ہی میں قصوروار رہے ہیں۔
Raiffeisenbank، Alfastrakhovanie کی تقریروں کا ایک اقتباس، مینگو ٹیلی کام کے آٹومیشن کو نافذ کرنے کے تجربے اور کٹ کے تحت دیگر تفصیلات۔
میرا نام یانا ہے، میں ٹیسٹر کے طور پر کام کرتا ہوں، میں آٹومیشن کے ساتھ ساتھ DevOps بھی کرتا ہوں، اور مجھے کانفرنسوں اور میٹنگز میں جانا پسند ہے۔ پچھلے دو سالوں میں، میں Oleg Bunin کی کانفرنسوں (HighLoad++، TeamLead Conf)، جگ ایونٹس (Heisenbug، JPoint)، TestCon Moscow، DevOps Pro Moscow، Big Data Moscow میں گیا ہوں۔
سب سے پہلے میں کانفرنس کے پروگرام کی طرف توجہ مبذول کرواتا ہوں۔ میں رپورٹ کے بارے میں کم اور اسپیکر پر زیادہ دیکھتا ہوں۔ یہاں تک کہ اگر رپورٹ بہت تکنیکی اور دلچسپ نکلتی ہے، یہ حقیقت نہیں ہے کہ آپ اپنی کمپنی میں رپورٹ سے کچھ بہترین طریقوں کو لاگو کر سکیں گے۔ اور پھر آپ کو اسپیکر کی ضرورت ہے۔
Raiffeisenbank میں پائپ لائن کے آخر میں روشنی
عام طور پر، میں ایسے بولنے والوں کی تلاش کرتا ہوں جو میری دلچسپی رکھتے ہوں۔ DevOpsForum 2019 میں، Raiffeisenbank کے ایک اسپیکر، Mikhail Bizhan نے میری دلچسپی لی۔ اپنی تقریر کے دوران، اس نے اس بارے میں بات کی کہ وہ کس طرح آہستہ آہستہ اپنی ٹیموں کو DevOps پر جوڑ رہے ہیں، انہیں اس کی ضرورت کیوں ہے، اور DevOps کی تبدیلی کے خیال کو کاروبار میں کیسے بیچنا ہے۔ ٹھیک ہے، عام طور پر، میں نے پائپ لائن کے آخر میں روشنی کو دیکھنے کے بارے میں بات کی.
میخائل بزہان، رائیفیسن بینک میں آٹومیشن کے ڈائریکٹر
اب ان کی کمپنی میں "DevOps" نہیں ہے۔ یعنی وہ کام کرتا ہے لیکن تمام ٹیموں میں نہیں۔ DevOps کو لاگو کرتے وقت، وہ ٹیموں کی تیاری پر انحصار کرتے ہیں، دونوں مخصوص انجینئرز کے لحاظ سے، اور مصنوعات کی ضرورت اور اس پلیٹ فارم کی پختگی کے لحاظ سے جس پر یہ پروڈکٹ بنایا گیا ہے۔ میشا نے بتایا کہ کس طرح کاروبار کو سمجھانا ہے کہ DevOps کی ضرورت کیوں ہے۔
بینکنگ طبقہ میں ترقی کے کئی محرکات ہیں: خدمات کی لاگت اور کلائنٹ بیس کی توسیع۔ خدمات کی قیمت میں اضافہ ایک بہت اچھا ڈرائیور نہیں ہے، لیکن کلائنٹ بیس کو بڑھانا اس کے برعکس ہے۔ اگر مدمقابل معروضی طور پر ٹھنڈی پروڈکٹ جاری کرتے ہیں، تو تمام گاہک وہاں جاتے ہیں، پھر وقت کے ساتھ ساتھ مارکیٹ کی سطح ختم ہوجاتی ہے۔ لہذا، مارکیٹ میں نئی مصنوعات کو متعارف کرانا اور ان کے تعارف کی رفتار بنیادی چیز ہے جس پر بینک توجہ دیتے ہیں۔ یہ بالکل وہی ہے جس کے لیے DevOps ہے، اور کاروبار اسے سمجھتے ہیں۔
اگلا اہم نوٹ: DevOps ہمیشہ مارکیٹ میں وقت کم نہیں کرتا۔ DevOps اکیلے کام نہیں کر سکتے ہیں، یہ صرف ایک پروڈکٹ کو بنانے اور اسے ترقی سے پیداوار تک (کوڈ سے کسٹمر تک) مارکیٹ میں لانے کے عمل کا حصہ ہے۔ لیکن کوڈ سے پہلے کی ہر چیز کا براہ راست تعلق DevOps سے نہیں ہے۔ یعنی، مارکیٹرز برسوں تک مارکیٹ کا مطالعہ کر سکتے ہیں اور اپنی پوری زندگی حریفوں کو پکڑنے میں گزار سکتے ہیں۔ یہ فوری طور پر سمجھنا ضروری ہے کہ کلائنٹ کو کیا ضرورت ہے اور اس یا اس خصوصیت کے نفاذ کی منصوبہ بندی کریں - اکثر یہ وہی ہوتا ہے جو DevOps کے کام کرنے اور کمپنی کے اپنے مقصد کو حاصل کرنے کے لیے کافی نہیں ہوتا ہے۔ لہذا، سب سے پہلے، Raiffeisenbank نے کاروبار سے اتفاق کیا کہ DevOps کو استعمال کرنے کا طریقہ سیکھنا ضروری ہے۔ آٹومیشن کی خاطر آٹومیشن نئے صارفین کی لڑائی میں زیادہ مدد نہیں کرے گی۔
عام طور پر، میشا کا خیال ہے کہ DevOps کو لاگو کرنے کی ضرورت ہے، لیکن سمجھداری سے۔ اور ہمیں اس حقیقت کے لیے تیار رہنا چاہیے کہ تبدیلی کے آغاز میں ٹیم کی پیداواری صلاحیت کم ہو جائے گی، وہ کم پیسے کمائے گی، لیکن پھر اسے جائز قرار دیا جائے گا۔
مینگو ٹیلی کام میں ٹیسٹنگ کا آٹومیشن
ٹیسٹر کے طور پر میرے لیے ایک اور دلچسپ رپورٹ مینگو ٹیلی کام سے ایگور مسلوف نے دی تھی۔ اس پریزنٹیشن کو "SCRUM ٹیم میں مکمل ٹیسٹنگ سائیکل کا آٹومیشن" کہا گیا تھا۔ ایگور کا خیال ہے کہ DevOps کو خاص طور پر SCRUM کے لیے بنایا گیا تھا، لیکن ساتھ ہی، DevOps کو SCRUM ٹیم میں متعارف کرانا کافی مشکل ہے۔ ایسا اس لیے ہوتا ہے کیونکہ SCRUM ٹیم ہمیشہ کہیں دوڑتی رہتی ہے، اختراعات سے پریشان ہونے اور اس عمل کو دوبارہ بنانے کا وقت نہیں ہوتا ہے۔ مسئلہ اس حقیقت میں بھی ہے کہ SCRUM میں ٹیم میں ذیلی ٹیموں کی علیحدگی شامل نہیں ہے (ٹیسٹنگ ٹیم، ڈیولپمنٹ ٹیم، وغیرہ)۔ ٹھیک ہے، اس کے علاوہ، موجودہ عمل کو خودکار کرنے کے لیے، دستاویزات کی ضرورت ہوتی ہے، اور SCRUM میں، اکثر کوئی دستاویز مکمل طور پر نہیں ہوتی ہے - "مصنوعہ کسی قسم کی تحریر سے زیادہ اہم ہے۔"
SCRUM پر سوئچ کرنے کے بعد، ٹیسٹرز نے ڈویلپرز سے مشورہ کرنا شروع کر دیا کہ خصوصیات کی جانچ کیسے کی جائے۔ دھیرے دھیرے، فعالیت کا حجم بڑھتا گیا، کوئی دستاویز نہیں تھی، اور انہوں نے فنکشنلٹی میں بہت سارے کیڑے پکڑنا شروع کر دیے تھے جو ٹیسٹوں میں شامل نہیں تھے اور عام طور پر یہ واضح نہیں تھا کہ اسے کس نے اور کب ٹیسٹ کیا۔ مختصر میں - الجھن اور خلل۔ ہم نے ٹیسٹنگ آٹومیشن پر جانے کا فیصلہ کیا۔ لیکن پھر بھی مکمل ناکامی ہوئی۔ انہوں نے آؤٹ سورس آٹومیشن ماہرین کی خدمات حاصل کیں جنہوں نے اندرون ملک ٹیسٹرز کو نامعلوم اسٹیک پر لکھا۔ آٹو ٹیسٹ کے فریم ورک نے یقیناً کام کیا، لیکن آؤٹ سورسرز کے جانے کے بعد، یہ دو ہفتوں تک جاری رہا۔ اگلا آٹو ٹیسٹنگ نمبر دو متعارف کرانے کی کوشش تھی۔ اس کا آغاز اس حقیقت سے ہوا کہ ہر چیز کو کمپنی کے اندر، اپنے طور پر بنانے کی ضرورت ہے (صحیح ویکٹر: اندرونی طور پر مہارت پیدا کریں)، SCRUM کے فریم ورک کے اندر، اور اس عمل میں دستاویزات بنائیں۔ آٹومیشن کے لیے اسٹیک پروڈکٹ کے اسٹیک کے برابر ہونا چاہیے (یہاں میں اسے شامل کر رہا ہوں، اپنے جاوا اسکرپٹ پروجیکٹ کو کسی اور چیز کے ساتھ نہ آزمائیں)۔ سپرنٹ کے اختتام پر، انہوں نے ایک ڈیمو کیا کہ آٹو ٹیسٹ پوری ٹیم کے ساتھ کیسے کام کرتا ہے (مددگار)۔ اس طرح، آٹومیشن کے عمل میں ٹیم کے تمام ممبران کی شمولیت میں اضافہ ہوا، ساتھ ہی آٹو ٹیسٹس پر اعتماد اور اس بات کا امکان کہ اس آٹو ٹیسٹ کو یقینی طور پر استعمال کیا جائے گا (اور مسلسل ناکامیوں کی وجہ سے ایک ماہ میں اس پر تبصرہ نہیں کیا جائے گا)۔
ویسے، DevOpsForum 2019 میں ایک کھلا مائیکروفون تھا - ایک طویل عرصے سے جانا پہچانا اور، میری رائے میں، تقریروں کا مفید فارمیٹ۔ آپ اس طرح گھومتے پھرتے ہیں، رپورٹیں سنتے ہیں، اور پھر فیصلہ کرتے ہیں کہ کانفرنس میں کسی خاص موضوع یا مسئلے پر بات کرنا، مسئلے کو حل کرنے کے لیے متعلقہ تجربہ شیئر کرنا قابل قدر ہے۔
میں نے یہ بھی دیکھا کہ منتظمین نے مختصر رپورٹس کا سلسلہ بنایا۔ ہر رپورٹ 10 منٹ سے زیادہ نہیں رہتی، اس کے بعد سوالات ہوتے ہیں۔ اس طرح آپ ایک ہی وقت میں بہت سے موضوعات کا احاطہ کر سکتے ہیں اور ان مقررین سے سوالات پوچھ سکتے ہیں جو آپ کی دلچسپی رکھتے ہیں۔
پریزنٹیشنز کے درمیان، میں کانفرنس کے شراکت داروں کے بوتھوں کے گرد گھومتا رہا اور بہت ساری چیزیں چرا/جیتیں۔ اوہ، میں ہینڈ آؤٹ سے محبت کرتا ہوں!
Alfastrakhovanie میں ترقیاتی ڈائریکٹر کے ساتھ گول میز اور DevOps کے مسائل
میرے لیے DevOpsForum 2019 کیک پر آئیکنگ ڈی او اوپس کے ماہرین کے ساتھ ایک گھنٹے کا مکمل سیشن تھا۔ سیشن کے چار شرکاء کو مختلف زاویوں سے DevOps کو دیکھنے کے لیے مدعو کیا گیا تھا: Anton Isanin (Alfastrakhovanie، Development Director)، Nailya Zamashkina (Fintech Lab، آپریٹنگ ڈائریکٹر)، Oleg Egorkin (Rostelecom، Agile کوچ) اور Anton Martyanov (آزاد ماہر، DevOps کو دیکھا۔ کاروباری نقطہ نظر سے)۔
ماہرین لوگوں کے قریب بیٹھ گئے اور پھر چیزیں ہونے لگیں: پورے ایک گھنٹے تک سامعین میں سے شرکاء نے اپنے سوالات کیے اور ماہرین نے ریپ کیا۔ کبھی کبھی حقیقی بحثیں ہوتی تھیں۔ سوالات بہت مختلف تھے، مثال کے طور پر: کیا DevOps انجینئرز کی بالکل بھی ضرورت ہے، انہیں سسٹم ایڈمنسٹریٹر کے طور پر تربیت کیوں نہیں دی جا سکتی، کیا DevOps سب کو پیش کیا جانا چاہیے، اس کی کیا قیمت ہے، وغیرہ۔
پھر، میں نے ذاتی طور پر Anton Isanin سے بات کی۔ ہم نے DevOps کلچر کو ہر گھر تک پہنچانے کی ضرورت پر تبادلہ خیال کیا اور DevOps تبدیلی کے تاریک پہلو کو ظاہر کیا۔
آئیے تصور کریں کہ سب اکٹھے ہوئے اور فیصلہ کیا کہ ڈی او اوپس کی ضرورت پروڈکٹ اور کاروبار اور ٹیم دونوں کو ہے۔ چلو اس پر عمل درآمد کرتے ہیں۔ سب کچھ ہو گیا. ہم نے سانس چھوڑی۔ DevOps نے ہمیں کلائنٹ کے قریب لایا ہے، اب ہم اس کی تمام خواہشات کو تیزی سے پورا کر سکتے ہیں۔ نتیجے کے طور پر، ہمارے پاس سخت ضوابط اور تقاضوں کے ساتھ ایک بڑا Ops محکمہ ہے، اور یہ مسلسل پروڈکٹ میں نقائص تلاش کرتا ہے اور درخواستوں کا ایک گروپ بناتا ہے۔ مزید برآں، تمام نقائص کو "فوری" حیثیت دی جاتی ہے، یہاں تک کہ اگر کلائنٹ غیر متوقع طور پر بٹن کو سبز کی بجائے پیلا رنگ دینا چاہتا ہو۔ پروجیکٹ بڑھ رہا ہے، ریلیز کی تعداد بڑھ رہی ہے اور، اس کے مطابق، گاہکوں کی طرف سے نئی فعالیت کے نقائص اور غلط فہمیوں کی تعداد۔ Ops رپورٹنگ کی خرابیوں کو برقرار رکھنے کے لیے مزید 10 لوگوں کی خدمات حاصل کرتا ہے، اور ڈیولپمنٹ ان کو بند کرنے کے لیے مزید 15 افراد کی خدمات حاصل کرتی ہے۔ اور نئی خصوصیات متعارف کرانے کے بجائے، ٹیم لامتناہی SD کے ساتھ کام کرتی ہے، صارف کو فعالیت اور ایک ہی وقت میں مدد کی وضاحت کرتی ہے۔ نتیجے کے طور پر، Ops اور ترقی دونوں کام کر رہے ہیں، لیکن کلائنٹ اور کاروبار ناخوش ہیں: نئی خصوصیات پھنس جاتی ہیں۔ یہ پتہ چلتا ہے کہ لگتا ہے کہ ڈی او اوپس موجود ہے، لیکن ایسا لگتا ہے کہ یہ موجود نہیں ہے۔
DevOps کو لاگو کرنے کی ضرورت کے بارے میں، Anton نے واضح طور پر کہا کہ یہ براہ راست کاروبار کے پیمانے پر منحصر ہے۔ اگر سال میں ایک کلائنٹ کی خدمت کرنے سے کمپنی کو ایک بلین حاصل ہوتا ہے، تو DevOps کی ضرورت نہیں ہے (بشرطیکہ آپ کو اس کلائنٹ میں باقاعدگی سے نئی تبدیلیاں لانے کی ضرورت نہ ہو)۔ ہر چیز چاکلیٹ میں ڈھکی ہوئی ہے۔ لیکن اگر کاروبار بڑھتا ہے اور زیادہ کلائنٹ ظاہر ہوتے ہیں، تو آپ کو تعمیل کرنے کی ضرورت ہے۔ ایک اصول کے طور پر، کمپنی میں ابتدائی طور پر کوئی ٹھنڈا آپریشن نہیں ہے۔ پہلے ہم پروڈکٹ کو کاٹتے ہیں، اور تب ہی ہم سمجھتے ہیں کہ پروڈکٹ کے کام کرنے کے لیے، ہمیں سرورز پر نظر رکھنے اور سپلائیز کی نگرانی کرنے کی ضرورت ہے۔ اسی وقت جب Ops وجود میں آتا ہے۔ یہ سمجھنا باقی ہے کہ Ops، ایک علیحدہ ڈویژن کے طور پر، ترقی کی راہ میں رکاوٹیں کھڑی کرنا شروع کر دے گا اور تمام ترسیل رک جانا شروع ہو جائیں گی۔ یعنی، اس معاملے میں، DevOps ثقافت پہلے سے ہی متعلقہ ہے، لیکن ہمیں اس کے تاریک پہلو کو نہیں بھولنا چاہیے۔
ماخذ: www.habr.com