مون تازو شرڪت ڪئي DevOpsForum 2019، ميزباني ڪيل Logrocon. هن ڪانفرنس ۾، شرڪت ڪندڙن ڪاروبار ۽ ترقي ۽ انفارميشن ٽيڪنالاجي سروس ماهرن جي وچ ۾ مؤثر رابطي لاء حل ۽ نوان اوزار ڳولڻ جي ڪوشش ڪئي.
ڪانفرنس هڪ ڪامياب هئي: واقعي تمام گهڻيون مفيد رپورٽون، دلچسپ پريزنٽيشن فارميٽ ۽ ڳالهائيندڙن سان تمام گهڻو مواصلات هئا. ۽ اهو خاص طور تي اهم آهي ته ڪنهن به مون کي ڪجهه وڪڻڻ جي ڪوشش نه ڪئي، جيڪو ڪجهه وڏي ڪانفرنس ۾ ڳالهائيندڙن کي تازو ڪيو ويو آهي.
Raiffeisenbank جي تقريرن مان هڪ اقتباس، Alfastrakhovanie، Mango Telecom جي تجربي کي لاڳو ڪرڻ ۾ آٽوميشن ۽ ٻين تفصيلن جي هيٺان.
منهنجو نالو يانا آهي، مان هڪ ٽيسٽر طور ڪم ڪريان ٿو، مان آٽوميشن ڪريان ٿو، گڏوگڏ DevOps، ۽ مون کي ڪانفرنسن ۽ ملاقاتن ۾ وڃڻ پسند آهي. گذريل ٻن سالن کان، مان Oleg Bunin جي ڪانفرنسن ۾ ويو آهيان (HighLoad++، TeamLead Conf)، جگ واقعا (Heisenbug، JPoint)، TestCon ماسڪو، DevOps Pro Moscow، Big Data Moscow.
سڀ کان پهرين، مان ڪانفرنس جي پروگرام ڏانهن ڌيان ڏيان ٿو. مان گهٽ ڏسان ٿو ته رپورٽ ڪهڙي بابت هوندي، ۽ اسپيڪر تي وڌيڪ. جيتوڻيڪ اها رپورٽ تمام ٽيڪنالاجي ۽ دلچسپ ثابت ٿي، اها حقيقت ناهي ته توهان پنهنجي ڪمپني ۾ رپورٽ مان ڪجهه بهترين طريقا لاڳو ڪرڻ جي قابل هوندا. ۽ پوء توهان کي اسپيڪر جي ضرورت آهي.
Raiffeisenbank تي پائپ لائن جي آخر ۾ روشني
عام طور تي، مان ڳولهيان ٿو ڳالهائيندڙن جي پاسي تي جيڪي منهنجي دلچسپي رکن ٿا. DevOpsForum 2019 تي، Raiffeisenbank جي هڪ اسپيڪر، ميخائل بزن، منهنجي دلچسپي ورتي. هن جي تقرير دوران، هن بابت ڳالهايو ته اهي ڪيئن آهستي آهستي پنهنجون ٽيمون DevOps تي ڳنڍي رهيا آهن، انهن کي ان جي ضرورت ڇو آهي، ۽ ڪاروبار ۾ DevOps جي تبديلي جي خيال کي ڪيئن وڪرو ڪجي. خير، عام طور تي، مون بابت ڳالهايو ته پائپ لائن جي آخر ۾ روشني ڪيئن ڏسجي.
Mikhail Bizhan، Raiffeisenbank ۾ آٽوميشن جو ڊائريڪٽر
هاڻي انهن وٽ نه آهي “DevOps” انهن جي ڪمپني ۾. اهو آهي، هو ڪم ڪري ٿو، پر سڀني ٽيمن ۾ نه. جڏهن DevOps تي عمل ڪيو وڃي، اهي ٽيمن جي تياري تي ڀاڙين ٿا، ٻنهي مخصوص انجنيئرن جي لحاظ کان، ۽ پيداوار جي ضرورت ۽ پليٽ فارم جي پختگي جي لحاظ کان جنهن تي هي پراڊڪٽ ٺهيل آهي. ميشا ٻڌايو ته هڪ ڪاروبار کي ڪيئن بيان ڪجي ڇو ته DevOps جي ضرورت آهي.
بينڪن جي حصي ۾ ڪيترائي ترقي وارا ڊرائيور آهن: خدمتن جي قيمت ۽ ڪلائنٽ جي بنياد جي توسيع. خدمتن جي قيمت وڌائڻ تمام سٺو ڊرائيور ناهي، پر ڪلائنٽ جو بنياد وڌائڻ ان جي برعڪس آهي. جيڪڏهن مقابلا هڪ معقول طور تي سٺي پراڊڪٽ جاري ڪن ٿا، سڀئي گراهڪ اتي ويندا آهن، پوء وقت سان مارڪيٽ جي سطح ٻاهر نڪرندي آهي. تنهن ڪري، مارڪيٽ ۾ نئين شين کي متعارف ڪرائڻ ۽ انهن جي تعارف جي رفتار بنيادي شيء آهي جنهن تي بينڪن تي ڌيان ڏيڻ. اھو اھو آھي جيڪو DevOps لاءِ آھي، ۽ ڪاروبار سمجھن ٿا.
ايندڙ اهم نوٽ: DevOps هميشه مارڪيٽ ۾ وقت گهٽ نه ڪندو آهي. DevOps اڪيلو ڪم نٿو ڪري سگهي، اهو صرف هڪ پراڊڪٽ ٺاهڻ ۽ آڻڻ جي عمل جو حصو آهي ترقي کان پيداوار تائين (ڪوڊ کان ڪسٽمر تائين). پر ڪوڊ کان اڳ سڀڪنھن شيء کي سڌو سنئون سان لاڳاپيل نه آهي DevOps. اهو آهي، مارڪيٽ وارا سالن تائين مارڪيٽ جو مطالعو ڪري سگهن ٿا ۽ پنهنجون سموريون زندگيون مقابلن سان پڪڙڻ ۾ گذاري سگهن ٿيون. اهو ضروري آهي ته جلدي سمجھو ته ڪلائنٽ کي ڪهڙي ضرورت آهي ۽ هن يا انهي خصوصيت تي عمل ڪرڻ جو منصوبو ٺاهيو - اڪثر اهو آهي جيڪو DevOps ڪم ڪرڻ ۽ ڪمپني لاءِ پنهنجو مقصد حاصل ڪرڻ لاءِ ڪافي ناهي. تنهن ڪري، سڀ کان پهريان، Raiffeisenbank ڪاروبار سان اتفاق ڪيو ته اهو سکڻ ضروري هو ته ڪيئن استعمال ڪجي DevOps. آٽوميشن جي خاطري نون گراهڪن لاءِ جنگ ۾ گهڻو مدد نه ڪندي.
عام طور تي، ميشا يقين رکي ٿو ته DevOps کي لاڳو ڪرڻ جي ضرورت آهي، پر عقلمندي سان. ۽ اسان کي ان حقيقت لاءِ تيار رهڻو پوندو ته تبديليءَ جي شروعات ۾ ٽيم جي پيداوار گهٽجي ويندي، ان کي گهٽ پئسا ملندا، پر پوءِ ان کي جائز قرار ڏنو ويندو.
Mango Telecom تي ٽيسٽنگ جي آٽوميشن
منهنجي لاءِ هڪ ٻي دلچسپ رپورٽ هڪ ٽيسٽر طور ڏني وئي هئي ايگور مسلوف مانگو ٽيليڪم. پريزنٽيشن کي سڏيو ويو "آٽوميشن آف مڪمل ٽيسٽنگ چڪر هڪ SCRUM ٽيم ۾." ايگور مڃي ٿو ته DevOps خاص طور تي SCRUM لاءِ ٺاهي وئي هئي، پر ساڳئي وقت، DevOps کي SCRUM ٽيم ۾ متعارف ڪرائڻ ڪافي مشڪل آهي. اهو ان ڪري ٿئي ٿو ڇاڪاڻ ته SCRUM ٽيم هميشه ڪنهن نه ڪنهن جاءِ تي ڊوڙي رهي آهي، اتي ڪو به وقت ناهي ته جدت کان پريشان ٿيڻ ۽ عمل کي ٻيهر تعمير ڪيو وڃي. مسئلو پڻ ان حقيقت ۾ آهي ته SCRUM ٽيم ۾ ذيلي ٽيمن جي علحدگيء ۾ شامل نه آهي (ٽيسٽ ٽيم، ڊولپمينٽ ٽيم، وغيره). خير، ان کان علاوه، موجوده عمل کي خودڪار ڪرڻ لاء، دستاويز جي ضرورت آهي، ۽ SCRUM ۾، اڪثر ڪري مڪمل طور تي ڪا به دستاويز نه آهي - "پراڊڪٽ ڪنهن قسم جي لکڻين کان وڌيڪ اهم آهي."
SCRUM تي سوئچ ڪرڻ کان پوء، ٽيسٽرز ڊولپرز سان صلاح ڪرڻ شروع ڪيو ته ڪيئن خاصيتن جي جانچ ڪجي. تدريجي طور تي، ڪارڪردگي جي مقدار ۾ اضافو ٿيو، ڪو به دستاويز نه هو، ۽ انهن ڪارڪردگي ۾ ڪيترائي ڪيڙا پڪڙڻ شروع ڪيا جيڪي ٽيسٽ ۾ شامل نه هئا ۽ عام طور تي اهو واضح ناهي ته ڪير ان کي آزمائي ٿو ۽ ڪڏهن. مختصر ۾ - مونجهارو ۽ خلل. اسان کي تبديل ڪرڻ جو فيصلو ڪيو آٽوميشن ٽيسٽنگ. پر ان جي باوجود مڪمل ناڪامي هئي. انهن آئوٽ سورس ٿيل آٽوميشن ماهرن کي ڀرتي ڪيو جيڪي هڪ اسٽيڪ تي لکندا هئا جيڪي اڻڄاتل اندرين ٽيسٽرن کي. خودڪار ٽيسٽ لاء فريم ورڪ ڪم ڪيو، يقينا، پر ٻاهر نڪرڻ کان پوء، اهو ٻن هفتن تائين هليو ويو. اڳتي هلي آٽو ٽيسٽنگ نمبر ٻه متعارف ڪرائڻ جي ڪوشش ڪئي وئي. اهو حقيقت سان شروع ٿيو ته هر شي کي ڪمپني جي اندر تعمير ڪرڻ جي ضرورت آهي، توهان جي پنهنجي (صحيح ویکٹر: اندروني طور تي ماهر تعمير ڪريو)، SCRUM جي فريم ورڪ جي اندر، ۽ پروسيس ۾ دستاويز ٺاهي. آٽوميشن لاءِ اسٽيڪ پراڊڪٽ جي اسٽيڪ جي برابر هجڻ گهرجي (هتي مان ان کي شامل ڪري رهيو آهيان، پنهنجي جاوا اسڪرپٽ پروجيڪٽ کي ڪنهن ٻئي سان نه آزمايو). سپرنٽ جي آخر ۾، انهن هڪ ڊيمو ڪيو ته ڪيئن آٽو ٽيسٽ سڄي ٽيم سان ڪم ڪري ٿو (مددگار). اهڙيءَ طرح، آٽوميشن جي عمل ۾ ٽيم جي سڀني ميمبرن جي شموليت وڌي وئي، ان سان گڏ آٽو ٽيسٽ تي ڀروسو به ٿيو ۽ اهو موقعو به ته اهو آٽو ٽيسٽ ضرور استعمال ڪيو ويندو (۽ مسلسل ناڪامين جي ڪري هڪ مهيني ۾ تبصرو نه ڪيو ويندو).
رستي جي ذريعي، DevOpsForum 2019 تي اتي هڪ کليل مائڪروفون هو - هڪ ڊگهو سڃاتل ۽، منهنجي خيال ۾، تقرير جي مفيد شڪل. توهان هن طرح گھمندا وڃو، رپورٽون ٻڌو، ۽ پوء فيصلو ڪيو ته ڪانفرنس ۾ ڪنهن خاص موضوع يا مسئلي تي بحث ڪرڻ جي قابل آهي، مسئلي کي حل ڪرڻ ۾ لاڳاپيل تجربو حصيداري ڪريو.
مون اهو پڻ محسوس ڪيو ته منتظمين مختصر رپورٽن جو سلسلو ٺاهيو. هر رپورٽ 10 منٽن کان وڌيڪ نه رهي، سوالن جي پٺيان. هن طريقي سان توهان هڪ ئي وقت ڪيترن ئي عنوانن کي ڍڪي سگهو ٿا ۽ ڳالهائيندڙن کان سوال پڇي سگهو ٿا جيڪي توهان جي دلچسپي رکن ٿا.
پريزنٽيشن جي وچ ۾، مان ڪانفرنس جي ڀائيوارن جي بوٽن جي چوڌاري گھمندو هوس ۽ گهڻو سامان چوري / کٽيو. اوه، مون کي دستاويز پسند آهي!
Alfastrakhovanie ۾ ڊولپمينٽ ڊائريڪٽر سان گول ميز ۽ DevOps مسئلا
منهنجي لاءِ DevOpsForum 2019 ڪيڪ تي آئسنگ ڊي اوپس جي ماهرن سان گڏ ڪلاڪ ڊگهو مڪمل سيشن هو. چار سيشن شرڪت ڪندڙن کي مختلف زاوين کان DevOps ڏسڻ لاءِ دعوت ڏني وئي: Anton Isanin (Alfastrakhovanie، ڊولپمينٽ ڊائريڪٽر)، Nailya Zamashkina (Fintech Lab، آپريٽنگ ڊائريڪٽر)، Oleg Egorkin (Rostelecom، Agile coach) ۽ Anton Martyanov (آزاد ماهر، DevOps کي ڏٺو. ڪاروباري نقطي نظر کان).
ماهرن ماڻهن جي ويجھو ويھي رھيا ۽ پوءِ شيون ٿيڻ لڳيون: ھڪ ڪلاڪ تائين، سامعين مان شرڪت ڪندڙن پنھنجا سوال پڇيا، ۽ ماهرن ريپ ورتو. ڪڏهن ڪڏهن حقيقي بحث مباحثا هوندا هئا. سوال ڏاڍا مختلف هئا، مثال طور: ڇا DevOps انجنيئرن جي ضرورت آهي، انهن کي تربيت ڇو نه ٿي ڏني وڃي سسٽم ايڊمنسٽريٽر، ڇا DevOps سڀني کي پيش ڪيو وڃي، ان جي قيمت ڇا آهي، وغيره.
ان کان پوء، مون ذاتي طور تي Anton Isanin سان ڳالهايو. اسان هر گهر ۾ DevOps ڪلچر کي آڻڻ جي ضرورت تي بحث ڪيو ۽ DevOps تبديلي جي اونداهي پاسي کي ظاهر ڪيو.
اچو ته تصور ڪريو ته هرڪو گڏ ٿي ويو ۽ فيصلو ڪيو ته DevOps ٻنهي جي ضرورت آهي پيداوار ۽ ڪاروبار ۽ ٽيم طرفان. اچو ته ان تي عمل ڪريون. سڀ ڪجھ ڪم ڪيو. اسان ساهه کنيو. DevOps اسان کي ڪلائنٽ جي ويجهو آڻي ڇڏيو آهي، هاڻي اسان جلدي هن جون سڀئي خواهشون پوريون ڪري سگهون ٿا. نتيجي طور، اسان وٽ ھڪڙو وڏو Ops ڊپارٽمينٽ آھي سخت ضابطن ۽ ضرورتن سان، ۽ اھو مسلسل مصنوعات ۾ نقص ڳولي ٿو ۽ درخواستن جو ھڪڙو گروپ ٺاھي ٿو. ان کان علاوه، سڀني خرابين کي "تڪڙو" حيثيت ڏني وئي آهي، جيتوڻيڪ ڪلائنٽ غير متوقع طور تي سائي جي بدران پيلو بٽڻ کي رنگ ڏيڻ چاهيندو آهي. پروجيڪٽ وڌي رهيو آهي، رليز جو تعداد وڌي رهيو آهي، ۽، مطابق، خرابين جو تعداد ۽ نئين ڪارڪردگي جي غلط فهمي گراهڪن طرفان. Ops 10 وڌيڪ ماڻهن کي ڀرتي ڪري ٿو رپورٽنگ جي خرابين کي برقرار رکڻ لاءِ، ۽ ڊولپمينٽ 15 وڌيڪ ماڻهن کي رکي ٿو انهن کي بند ڪرڻ لاءِ. ۽ نئين خاصيتون متعارف ڪرائڻ جي بدران، ٽيم ڪم ڪري ٿي لامحدود SD's سان، صارف کي ڪارڪردگي جي وضاحت ڪندي ۽ ساڳئي وقت سپورٽ. نتيجي طور، ٻئي Ops ۽ ترقي ڪم ڪري رهيا آهن، پر ڪلائنٽ ۽ ڪاروبار ناخوش آهن: نيون خاصيتون ڦاسي پيا. اهو ظاهر ٿئي ٿو ته DevOps موجود آهي، پر اهو موجود ناهي.
DevOps کي لاڳو ڪرڻ جي ضرورت جي حوالي سان، انتون واضح طور تي چيو ته اهو سڌو سنئون ڪاروبار جي پيماني تي منحصر آهي. جيڪڏهن هڪ سال ۾ هڪ ڪلائنٽ جي خدمت ڪندي ڪمپني کي هڪ ارب آڻيندو، DevOps جي ضرورت ناهي (بطور ته توهان کي هن ڪلائنٽ ۾ باقاعده تبديليون آڻڻ جي ضرورت ناهي). هر شي چاکليٽ ۾ ڍڪيل آهي. پر جيڪڏهن ڪاروبار وڌندو آهي ۽ وڌيڪ گراهڪ ظاهر ٿيندا آهن، پوء توهان کي عمل ڪرڻو پوندو. ضابطي جي طور تي، شروعاتي طور تي ڪمپني ۾ ڪو به ٿڌو اوپس ناهي. پهرين اسان پراڊڪٽ کي ڪٽيو، ۽ صرف پوء اسان سمجھون ٿا ته پيداوار جي ڪم ڪرڻ لاء، اسان کي سرور تي نظر رکڻو پوندو ۽ سامان جي نگراني ڪرڻ جي ضرورت آهي. اهو آهي جڏهن Ops وجود ۾ اچي ٿو. اهو سمجهڻ باقي آهي ته اوپس، هڪ الڳ ڊويزن جي طور تي، ترقي جي رڪاوٽن جو هڪ گروپ لڳائڻ شروع ڪندو ۽ سڀني ترسيل اسٽال ٿيڻ شروع ٿي وينديون. اهو آهي، هن معاملي ۾، DevOps ڪلچر اڳ ۾ ئي لاڳاپيل آهي، پر اسان کي ان جي اونداهي پاسي جي باري ۾ وسارڻ نه گهرجي.
جو ذريعو: www.habr.com