ڪنهن شيءِ جي حالت کي ڪيئن سمجهي؟
توهان پنهنجي راءِ تي ڀروسو ڪري سگهو ٿا، معلومات جي مختلف ذريعن مان ٺهيل آهي، مثال طور، ويب سائيٽن تي اشاعت يا تجربو. توهان پنهنجي ساٿين، واقفڪارن کان پڇي سگهو ٿا. ٻيو اختيار اهو آهي ته ڪانفرنس جي عنوانن کي ڏسڻ لاءِ: پروگرام ڪميٽي صنعت جا سرگرم نمائندا آهن، تنهن ڪري اسان انهن تي ڀروسو رکون ٿا لاڳاپيل عنوانن کي چونڊڻ ۾. هڪ الڳ علائقو تحقيق ۽ رپورٽ آهي. پر اتي هڪ مسئلو آهي. دنيا ۾ هر سال DevOps جي رياست تي تحقيق ڪئي ويندي آهي، رپورٽون شايع ڪيون وينديون آهن پرڏيهي ڪمپنيون، ۽ روسي DevOps بابت تقريبن ڪا به ڄاڻ ناهي.
پر اهو ڏينهن اچي ويو آهي جڏهن اهڙي اڀياس ڪئي وئي هئي، ۽ اڄ اسين نتيجن بابت ڳالهائينداسين. روس ۾ DevOps جي رياست گڏيل طور تي ڪمپنين پاران اڀياس ڪئي وئي ""۽"". ايڪسپريس 42 ٽيڪنالاجي ڪمپنين کي DevOps طريقن ۽ اوزارن کي لاڳو ڪرڻ ۽ ترقي ڪرڻ ۾ مدد ڪري ٿي ۽ روس ۾ DevOps بابت ڳالهائڻ وارن مان پهريون هو. مطالعي جي ليکڪ، Igor Kurochkin ۽ Vitaly Khabarov، ايڪسپريس 42 تي تجزيي ۽ مشاورت ۾ مصروف آهن، جڏهن ته مختلف ڪمپنين ۾ آپريشن ۽ تجربو کان ٽيڪنيڪل پس منظر آهي. 8 سالن تائين، ساٿين ڪيترن ئي ڪمپنين ۽ منصوبن کي ڏٺو آهي - شروعاتي کان وٺي ادارن تائين - مختلف مسئلن سان، گڏوگڏ مختلف ثقافتي ۽ انجنيئرنگ جي پختگي سان.
انهن جي رپورٽ ۾، Igor ۽ Vitaly ٻڌايو ته تحقيق جي عمل ۾ ڪهڙا مسئلا هئا، انهن انهن کي ڪيئن حل ڪيو، انهي سان گڏ ڪيئن DevOps تحقيق اصولي طور تي منعقد ڪئي وئي آهي ۽ ڇو ايڪسپريس 42 پنهنجو پاڻ کي هلائڻ جو فيصلو ڪيو. انهن جي رپورٽ ڏسي سگهجي ٿو .
DevOps ريسرچ
گفتگو Igor Kurochkin پاران شروع ڪيو ويو.
اسان باقاعدي طور تي سامعين کان پڇو ٿا DevOps ڪانفرنسن ۾، ”ڇا توهان هن سال لاءِ DevOps اسٽيٽس رپورٽ پڙهي آهي؟ ٿورا پنهنجا هٿ بلند ڪن ٿا، ۽ اسان جي مطالعي مان ظاهر ٿيو ته صرف ٽيون انهن جو مطالعو. جيڪڏهن توهان اهڙيون رپورٽون ڪڏهن به نه ڏٺيون آهن، اچو ته فوري طور تي چئو ته اهي سڀ هڪجهڙا آهن. گهڻو ڪري اهڙا جملا آهن جهڙوڪ: "گذريل سال جي مقابلي ۾ ..."
هتي اسان وٽ پهريون مسئلو آهي، ۽ ان کان پوء ٻه وڌيڪ:
- اسان وٽ گذريل سال جي ڊيٽا نه آهي. روس ۾ DevOps جي حالت ڪنهن کي به دلچسپي نه آهي؛
- طريقو. اهو واضح ناهي ته مفروضن کي ڪيئن جانچيو وڃي، سوال ڪيئن ٺاهجن، تجزيو ڪيئن ڪجي، نتيجن جو مقابلو ڪجي، ڪنيڪشن ڳولجي.
- اصطلاحات. سڀ رپورٽون انگريزيءَ ۾ آهن، ترجمو گهربل آهي، هڪ عام DevOps فريم ورڪ اڃا ايجاد نه ڪيو ويو آهي ۽ هرڪو پنهنجو پاڻ سان گڏ اچي ٿو.
اچو ته هڪ نظر رکون ته ڪيئن DevOps رياست جا تجزيا سڄي دنيا ۾ ڪيا ويا آهن.
تاريخي پس منظر
DevOps تحقيق 2011 کان وٺي ڪئي وئي آهي. Puppet، هڪ ڊولپر جي ترتيب واري انتظاماتي نظام جو، انهن کي منظم ڪرڻ لاء پهريون هو. ان وقت، اهو بنيادي اوزارن مان هڪ هو، بنيادي ڍانچي کي ڪوڊ جي صورت ۾ بيان ڪرڻ لاء. 2013 تائين، اهي اڀياس صرف سروي بند ڪيا ويا ۽ عوامي رپورٽون نه.
2013 ۾، آئي ٽي انقلاب ظاهر ٿيو، سڀني وڏن ڪتابن جو پبلشر DevOps تي. Puppet سان گڏ، انهن پهرين رياست تيار ڪئي DevOps اشاعت، جتي 4 اهم ميٽرڪس پهريون ڀيرو ظاهر ٿيا. ايندڙ سال، ThoughtWorks، هڪ صلاحڪار فرم جيڪو صنعت جي طريقن ۽ اوزارن تي باقاعده ٽيڪنالاجي ريڊار لاء مشهور آهي، ملوث ٿي ويو. ۽ 2015 ۾، هڪ سيڪشن جو طريقو شامل ڪيو ويو، ۽ اهو واضح ٿيو ته اهي تجزيو ڪيئن ڪن ٿا.
2016 ۾، مطالعي جي ليکڪن، پنھنجي ڪمپني ٺاھيو DORA (DevOps ريسرچ اينڊ اسيسمينٽ)، ھڪڙي سالياني رپورٽ شايع ڪئي. ايندڙ سال، DORA ۽ Puppet پنهنجي آخري گڏيل رپورٽ جاري ڪئي.
۽ پوء ڪجهه دلچسپ شروع ڪيو:
2018 ۾، ڪمپنيون ورهائجي ويون ۽ ٻه آزاد رپورٽون جاري ڪيون ويون: هڪ Puppet کان، ٻيو DORA کان گوگل سان گڏ. DORA اهم ميٽرڪس، ڪارڪردگي جي پروفائيل، ۽ انجنيئرنگ جي مشقن سان گڏ پنهنجي طريقيڪار کي استعمال ڪرڻ جاري رکي ٿو جيڪي اهم ميٽرڪس ۽ ڪمپني جي وسيع ڪارڪردگي تي اثر انداز ڪن ٿا. ۽ پپٽ پنهنجي طريقي سان پيش ڪيو پروسيس جي وضاحت ۽ ڊي اوپس جي ارتقا سان. پر ڪهاڻي جڙي نه وئي، 2019 ۾ پپٽ هن طريقي کي ڇڏي ڏنو ۽ رپورٽن جو هڪ نئون نسخو جاري ڪيو، جنهن ۾ اهم عملن کي درج ڪيو ويو آهي ۽ ڪيئن انهن جي نقطي نظر کان DevOps کي متاثر ڪن ٿا. پوءِ هڪ ٻيو واقعو ٿيو: گوگل DORA خريد ڪيو، ۽ گڏجي هڪ ٻي رپورٽ جاري ڪئي. توهان شايد هن کي ڏٺو هوندو.
هن سال، شيون پيچيده ٿي ويون. پوپٽ کي معلوم ٿئي ٿو ته پنهنجو سروي شروع ڪيو آهي. انهن اسان کان هڪ هفتو اڳ ڪيو، ۽ اهو اڳ ۾ ئي ختم ٿي چڪو آهي. اسان ان ۾ حصو ورتو ۽ ڏٺو ته ڪهڙن موضوعن ۾ دلچسپي رکن ٿا. هاڻي پپٽ پنهنجو تجزيو ڪري رهيو آهي ۽ رپورٽ شايع ڪرڻ جي تياري ڪري رهيو آهي.
پر DORA ۽ گوگل طرفان اڃا تائين ڪو اعلان ناهي. مئي ۾، جڏهن سروي عام طور تي شروع ٿي، معلومات آئي ته نيڪول فورسگرن، DORA جي باني مان هڪ، هڪ ٻي ڪمپني ڏانهن منتقل ٿي چڪو هو. تنهن ڪري، اسان فرض ڪيو ته هن سال DORA کان ڪا به تحقيق ۽ رپورٽ نه هوندي.
روس ۾ شيون ڪيئن آهن؟
اسان DevOps تحقيق نه ڪئي آهي. اسان ڪانفرنسن ۾ ڳالهايو، ٻين ماڻهن جي نتيجن کي ٻيهر ٻڌايو، ۽ Raiffeisenbank ترجمو ڪيو "State of DevOps" 2019 لاءِ (توهان حاصل ڪري سگهو ٿا انهن جو اعلان Habré تي)، انهن جي تمام گهڻي مهرباني. ۽ اهو سڀ ڪجهه آهي.
تنهن ڪري، اسان روس ۾ DORA طريقن ۽ نتيجن کي استعمال ڪندي پنهنجي تحقيق ڪئي. اسان Raiffeisenbank جي ساٿين جي رپورٽ اسان جي تحقيق لاءِ استعمال ڪئي، بشمول اصطلاحن ۽ ترجمي جي هم وقت سازي لاءِ. ۽ صنعت سان لاڳاپيل سوال DORA رپورٽن ۽ هن سال جي پپٽ سوالنامي مان ورتو ويو.
تحقيقي عمل
رپورٽ صرف آخري حصو آهي. سڄي تحقيق جو عمل چار وڏن مرحلن تي مشتمل آهي:
تياري جي مرحلي دوران، اسان صنعت جي ماهرن سان انٽرويو ڪيو ۽ فرضن جي هڪ فهرست تيار ڪئي. انهن جي بنياد تي، سوال گڏ ڪيا ويا ۽ سڄي آگسٽ لاء هڪ سروي شروع ڪئي وئي. پوءِ اسان تجزيو ڪيو ۽ رپورٽ پاڻ تيار ڪئي. DORA لاءِ، اهو عمل 6 مهينا وٺندو آهي. اسان 3 مھينن اندر ملاقات ڪئي، ۽ ھاڻي اسان سمجھون ٿا ته اسان وٽ مشڪل سان ڪافي وقت آھي: صرف تجزيو ڪرڻ سان توھان سمجھو ٿا ته توھان کي ڪھڙا سوال پڇڻ جي ضرورت آھي.
رڪن
سڀ پرڏيهي رپورٽون شرڪت ڪندڙن جي تصوير سان شروع ٿين ٿيون، ۽ انھن مان گھڻا روس کان نه آھن. روسي جواب ڏيڻ وارن جو سيڪڙو 5 کان 1 سيڪڙو تائين سال کان سال تائين ڦري ٿو، ۽ اهو ڪنهن به نتيجو ڪڍڻ جي اجازت نٿو ڏئي.
DevOps 2019 رپورٽ جي Accelerate State مان نقشو:
اسان جي مطالعي ۾، اسان 889 ماڻهن سان انٽرويو ڪرڻ جو انتظام ڪيو - اهو تمام گهڻو آهي (DORA پنهنجي رپورٽن ۾ هر سال هڪ هزار ماڻهن بابت پول) ۽ هتي اسان مقصد حاصل ڪيو آهي:
سچ، اسان جا سڀئي شرڪت پڄاڻيءَ تي نه پهتا آهن: مڪمل ٿيڻ جو سيڪڙو اڌ کان ٿورو گهٽ نڪتو. پر اهو به نمائندو نموني حاصل ڪرڻ ۽ تجزيو ڪرڻ لاءِ ڪافي هو. DORA پنهنجي رپورٽن ۾ في سيڪڙو فيصد ظاهر نٿو ڪري، تنهنڪري هتي ڪو مقابلو ناهي.
صنعت ۽ پوزيشن
اسان جا جوابدار درجنين صنعتن جي نمائندگي ڪن ٿا. انفارميشن ٽيڪنالاجي ۾ اڌ ڪم. هن جي پٺيان آهي مالي خدمتون، واپار، ٽيليڪميونيڪيشن ۽ ٻيا. پوزيشنن ۾ ماهر آهن (ڊولپر، ٽيسٽر، آپريشن انجنيئر) ۽ انتظامي عملي (ٽيمن جا سربراه، گروپ، علائقا، ڊائريڪٽر):
ٻن مان ھڪڙو ھڪڙو وچولي ڪمپني لاء ڪم ڪري ٿو. هر ٽيون ماڻهو وڏين ڪمپنين ۾ ڪم ڪري ٿو. گهڻو ڪري 9 ماڻهن جي ٽيمن ۾ ڪم. الڳ الڳ، اسان مکيه سرگرمين بابت پڇيو، ۽ اڪثريت ڪنهن نه ڪنهن طرح سان لاڳاپيل آهي، ۽ اٽڪل 40٪ ترقي ۾ مصروف آهن:
تنهنڪري اسان مختلف صنعتن، ڪمپنين، ٽيمن جي نمائندن جي مقابلي ۽ تجزيو لاء معلومات گڏ ڪئي. منهنجي ساٿي Vitaly Khabarov تجزيي جي باري ۾ ٻڌائيندو.
تجزيو ۽ مقابلو
Vitaly Khabarov: سڀني شرڪت ڪندڙن جي وڏي مهرباني جن اسان جي سروي کي مڪمل ڪيو، سوالنامي ڀريو ۽ اسان کي اسان جي مفروضن جي وڌيڪ تجزيو ۽ جانچ لاءِ ڊيٽا مهيا ڪئي. ۽ مھرباني ڪري اسان جي گراهڪن ۽ گراهڪن جي، اسان وٽ ھڪڙو تجربو آھي جنھن صنعت جي خدشات کي سڃاڻڻ ۾ مدد ڪئي آھي ۽ انھن مفروضن کي ٺاھڻ ۾ مدد ڪئي آھي جيڪي اسان پنھنجي تحقيق ۾ آزمايا آھن.
بدقسمتي سان، توهان صرف هڪ طرف سوالن جي هڪ فهرست ۽ ٻئي طرف ڊيٽا نٿا وٺي سگهو، ڪنهن به طرح انهن جو مقابلو ڪريو، چئو: "ها، سڀ ڪجهه ڪم ڪري ٿو، اسان صحيح هئاسين" ۽ منتشر ڪريو. نه، طريقيڪار ۽ شمارياتي طريقن جي ضرورت آهي انهي کي يقيني بڻائڻ لاءِ ته اسان غلط نه آهيون ۽ اسان جا نتيجا قابل اعتماد آهن. پوء اسان انهن ڊيٽا جي بنياد تي اسان جو وڌيڪ ڪم ٺاهي سگهون ٿا:
اهم ميٽرڪس
اسان DORA جي طريقي کي هڪ بنياد طور ورتو، جنهن کي انهن تفصيل سان ڪتاب ۾ بيان ڪيو آهي “Accelerate State of DevOps”. اسان چيڪ ڪيو ته ڇا اهم ميٽرڪس روسي مارڪيٽ لاءِ موزون آهن، ڇا اهي ساڳيءَ طرح استعمال ڪري سگھجن ٿا جيئن DORA ان سوال جو جواب ڏيڻ لاءِ استعمال ڪري ٿو: ”روس ۾ صنعت غير ملڪي صنعت سان ڪيئن مطابقت رکي ٿي؟
اهم ماپون:
- لڳائڻ جي تعدد. ايپليڪيشن جو نئون نسخو ڪيتري وقت پيداوار واري ماحول ۾ لڳايو ويو آهي (منصوبابندي ڪيل تبديليون، هاٽ فڪسز ۽ واقعن جي جوابن کان سواء)؟
- پهچائڻ وقت. تبديلي ڪرڻ (لکڻ جي ڪارڪردگي ڪوڊ جي طور تي) ۽ پيداوار جي ماحول ۾ تبديلي کي ترتيب ڏيڻ جي وچ ۾ اوسط وقت ڇا آهي؟
- بحالي جو وقت. ڪنهن واقعي، سروس جي خراب ٿيڻ، يا ايپليڪيشن استعمال ڪندڙن کي متاثر ڪرڻ واري بگ جي دريافت کان پوءِ پيداوار واري ماحول ۾ ايپليڪيشن کي بحال ڪرڻ ۾ اوسط ڪيترو وقت لڳندو آهي؟
- ناڪام تبديليون. پيداوار جي ماحول ۾ ڊيپلائيمينٽ جو ڇا سيڪڙو ايپليڪيشن جي تباهي يا واقعن جو سبب بڻجندو آهي ۽ اصلاح جي ضرورت هوندي آهي (تبديلين جي واپسي، هاٽ فڪس يا پيچ جي ترقي)؟
DORA پنهنجي تحقيق ۾ انهن ميٽرڪ ۽ تنظيمي ڪارڪردگي جي وچ ۾ هڪ تعلق مليو آهي. اسان ان کي اسان جي مطالعي ۾ پڻ جانچيو.
پر پڪ ڪرڻ لاءِ ته چار اهم ميٽرڪ ڪنهن شيءِ تي اثرانداز ٿي سگهن ٿا، توهان کي سمجهڻ جي ضرورت آهي - ڇا اهي ڪنهن به طرح هڪ ٻئي سان لاڳاپيل آهن؟ DORA هڪ احتياط سان اثبات ۾ جواب ڏنو: ناڪام تبديلين جي وچ ۾ لاڳاپو (تبديلي جي ناڪامي جي شرح) ۽ ٽن ٻين ميٽرڪ ٿورڙي ڪمزور آهي. اسان کي ساڳي تصوير ملي آهي. جيڪڏهن ترسيل وقت، مقرري جي تعدد، ۽ وصولي جو وقت هڪ ٻئي سان لاڳاپو رکي ٿو (اسان اهو تعلق پيئرسن جي رابطي ۽ چاڊڊڪ اسڪيل ذريعي قائم ڪيو آهي)، پوءِ ناڪام تبديلين سان اهڙو ڪو مضبوط تعلق ناهي.
اصولي طور تي، اڪثر جواب ڏيڻ وارا جواب ڏيڻ چاهيندا آهن ته انهن جي پيداوار ۾ واقعن جو هڪ ننڍڙو تعداد آهي. جيتوڻيڪ اسان بعد ۾ ڏسندا سين ته اڃا تائين ناڪام تبديلين جي لحاظ کان جوابدارن جي گروپن جي وچ ۾ هڪ اهم فرق آهي، اسان اڃا تائين هن ميٽرڪ کي هن ڊويزن لاء استعمال نٿا ڪري سگهون.
اسان هن حقيقت کي منسوب ڪريون ٿا ته (جيئن اسان جي ڪجهه گراهڪن سان تجزيي ۽ رابطي جي دوران ظاهر ٿيو) ان تصور ۾ ٿورو فرق آهي جيڪو هڪ واقعو سمجهي وڃي ٿو. جيڪڏهن اسان ٽيڪنيڪل ونڊو دوران اسان جي خدمت جي ڪارڪردگي کي بحال ڪرڻ جو انتظام ڪيو، ڇا اهو هڪ واقعو سمجهي سگهجي ٿو؟ شايد نه، ڇو ته اسان سڀ ڪجهه ٺيڪ ڪيو، اسان عظيم آهيون. ڇا اسان ان کي ھڪڙو واقعو سمجھي سگھون ٿا جيڪڏھن اسان کي پنھنجي ايپليڪيشن کي 10 ڀيرا عام، واقف موڊ ۾ ريٽ ڪرڻو پوندو؟ لڳي ٿو نه. تنهن ڪري، ٻين ميٽرڪس سان ناڪام تبديلين جي تعلق جو سوال کليل رهي ٿو. اسان ان کي وڌيڪ بهتر ڪنداسين.
هتي اهم آهي ته اسان ترسيل وقت، وصولي جي وقت، ۽ مقرري جي تعدد جي وچ ۾ هڪ اهم تعلق مليو. تنهن ڪري، اسان انهن ٽنهي ميٽرن کي ورتو ته جواب ڏيڻ وارن کي ڪارڪردگي گروپن ۾ وڌيڪ ورهايو وڃي.
گرام ۾ ڪيترو وزن ڪجي؟
اسان استعمال ڪيو hierarchical ڪلستر تجزيو:
- اسان جواب ڏيڻ وارن کي n-dimensional اسپيس تي ورهائيندا آهيون، جتي هر جواب ڏيندڙ جو همعصر انهن جي سوالن جا جواب هوندو آهي.
- هر جوابدار کي هڪ ننڍڙو ڪلستر قرار ڏنو ويو آهي.
- اسان هڪ ٻئي جي ويجهو ٻن ڪلسترن کي هڪ وڏي ڪلستر ۾ گڏ ڪريون ٿا.
- اسان ڪلستر جو ايندڙ جوڙو ڳوليندا آهيون ۽ انهن کي هڪ وڏي ڪلستر ۾ گڏ ڪندا آهيون.
هن طريقي سان اسان پنهنجي سڀني جوابدارن کي ڪلستر جي تعداد ۾ گروپ ڪريون ٿا جن جي اسان کي ضرورت آهي. ڊينڊروگرام (ڪلسٽرن جي وچ ۾ رابطي جو هڪ وڻ) جي مدد سان، اسان ٻن پاڙيسري ڪلستر جي وچ ۾ فاصلو ڏسون ٿا. اسان لاءِ باقي اهو آهي ته انهن ڪلسترن جي وچ ۾ هڪ خاص فاصلي جي حد مقرر ڪري ۽ چئو: ”اهي ٻئي گروهه هڪ ٻئي کان بلڪل الڳ آهن ڇاڪاڻ ته انهن جي وچ ۾ فاصلو تمام وڏو آهي.
پر هتي هڪ لڪيل مسئلو آهي: اسان وٽ ڪلستر جي تعداد تي ڪا به پابندي ناهي - اسان 2، 3، 4، 10 ڪلستر حاصل ڪري سگهون ٿا. ۽ پهريون خيال اهو هو ته ڇو نه اسان جي سڀني جوابدارن کي 4 گروپن ۾ ورهايو وڃي، جيئن DORA ڪندو آهي. پر اسان ڏٺو ته انهن گروهن جي وچ ۾ اختلاف غير معمولي ٿي ويا آهن، ۽ اسان يقين نه ٿا ڪري سگهون ته جوابدار واقعي سندس گروهه سان تعلق رکي ٿو، ۽ پاڙيسري سان نه. اسان اڃا تائين روسي مارڪيٽ کي چئن گروپن ۾ ورهائي نٿا سگهون. تنهن ڪري، اسان ٽن پروفائلن تي آباد ٿيا جن جي وچ ۾ شمارياتي طور تي اهم فرق آهي:
اڳيون، اسان ڪلستر جي ذريعي پروفائل جو تعين ڪيو: اسان هر گروپ لاءِ هر ميٽرڪ لاءِ ميڊين ورتو ۽ ڪارڪردگي پروفائلز جي ٽيبل مرتب ڪيو. حقيقت ۾، اسان هر گروپ ۾ اوسط شرڪت ڪندڙ جي ڪارڪردگي پروفائل حاصل ڪئي. اسان ٽن ڪارڪردگي پروفائلن جي نشاندهي ڪئي آھي: گھٽ، وچولي، اعلي:
هتي اسان اسان جي مفروضي جي تصديق ڪئي ته 4 اهم ميٽرڪس ڪارڪردگي جي پروفائل کي طئي ڪرڻ لاء مناسب آهن، ۽ اهي مغربي ۽ روسي مارڪيٽن ۾ ڪم ڪن ٿا. گروپن جي وچ ۾ فرق آهي ۽ اهو شمارياتي لحاظ کان اهم آهي. مان زور ڏيان ٿو ته ڪارڪردگي جي پروفائلن جي وچ ۾ ھڪڙو اھم فرق آھي اوسط جي لحاظ کان ناڪام تبديلين جي ميٽرڪ جي لحاظ کان، جيتوڻيڪ اسان شروعاتي طور تي جواب ڏيڻ وارن کي ھن پيٽرولر طرفان ورهايو نه آھي.
پوء سوال پيدا ٿئي ٿو: هي سڀ ڪيئن استعمال ڪجي؟
ڪيئن استعمال ڪجي
جيڪڏهن اسان ڪنهن به ٽيم کي وٺون ٿا، 4 اهم ميٽرڪس ۽ ان کي ميز تي لاڳو ڪريو، پوء 85٪ ڪيسن ۾ اسان کي مڪمل ميچ نه ملندي - اهو صرف هڪ سراسري شرڪت ڪندڙ آهي، ۽ حقيقت ۾ ڇا ناهي. اسان سڀ (۽ هر ٽيم) ٿورڙي مختلف آهيون.
اسان چيڪ ڪيو: اسان اسان جا جواب ڏيڻ وارا ۽ DORA جي ڪارڪردگي جي پروفائيل کي ورتو، ۽ ڏٺو ته ڪيترا جواب ڏيڻ وارا هن يا انهي پروفائل کي پورو ڪن ٿا. اسان اهو محسوس ڪيو ته صرف 16٪ جواب ڏيڻ وارن کي ضرور پروفائل مان هڪ ۾ پئجي ويو. باقي سڀ ڪجهه وچ ۾ پکڙيل آهن:
هن جو مطلب آهي ته ڪارڪردگي جي پروفائيل ۾ هڪ محدود گنجائش آهي. سمجھڻ لاءِ ته توھان ڪٿي آھيو پھرين نزديڪ ۾، توھان ھي ٽيبل استعمال ڪري سگھو ٿا: ”او، لڳي ٿو اسان ويجھو آھيون وچولي يا اعليٰ!" جيڪڏھن توھان سمجھو ته اڳتي ڪٿي وڃڻو آھي، اھو ڪافي ٿي سگھي ٿو. پر جيڪڏهن توهان جو مقصد مسلسل آهي، مسلسل بهتري، ۽ توهان وڌيڪ ڄاڻڻ چاهيو ٿا ته ڪٿي ترقي ڪئي وڃي ۽ ڇا ڪجي، پوء اضافي پئسن جي ضرورت آهي. اسان انهن کي ڳڻپيوڪر سڏين ٿا:
- DORA ڳڻپيوڪر
- ڪليڪٽر ايڪسپريس 42* (ترقي ۾)
- پنهنجي ترقي (توهان پنهنجو اندروني ڳڻپيوڪر ٺاهي سگهو ٿا).
انهن کي ڪهڙي ضرورت آهي؟ سمجھڻ:
- ڇا اسان جي تنظيم جي اندر ٽيم اسان جي معيار تي آهي؟
- جيڪڏهن نه، ڇا اسان ان جي مدد ڪري سگھون ٿا، ان کي ماهر جي فريم ورڪ جي اندر تيز ڪري سگھون ٿا جيڪو اسان جي ڪمپني آھي؟
- جيڪڏهن ائين آهي، ڇا اسان اڃا به بهتر ڪري سگهون ٿا؟
توھان انھن کي استعمال ڪري سگھوٿا ڪمپني اندر انگ اکر گڏ ڪرڻ لاءِ:
- اسان وٽ ڪهڙيون ٽيمون آهن؟
- ٽيمن کي پروفائلز ۾ ورهايو؛
- ڏسو: اوه، اهي حڪم گهٽ پرفارم ڪري رهيا آهن (اهي ٿورڙو نه ڪڍندا آهن)، پر اهي سٺا آهن: اهي هر روز ترتيب ڏين ٿا، بغير ڪنهن غلطي جي، انهن وٽ هڪ ڪلاڪ کان گهٽ وقت جو وقت آهي.
۽ پوءِ توھان ڳولي سگھوٿا ته اسان جي ڪمپني جي اندر انھن ٽيمن لاءِ ضروري صلاحيتون ۽ اوزار آھن جيڪي اڃا تائين برابر نه آھن.
يا، جيڪڏهن توهان سمجھو ٿا ته توهان ڪمپني جي اندر عظيم محسوس ڪيو ٿا، توهان ڪيترن ئي کان بهتر آهيو، پوء توهان ٿورو وسيع نظر ڪري سگهو ٿا. اهو صرف روسي صنعت آهي: ڇا اسان پاڻ کي تيز ڪرڻ لاء روسي صنعت ۾ ضروري ماهر حاصل ڪري سگهون ٿا؟ ايڪسپريس 42 ڳڻپيوڪر هتي مدد ڪندو (اهو ترقي هيٺ آهي). جيڪڏهن توهان روسي مارڪيٽ کي ختم ڪيو آهي، پوء ڏسو ۽ عالمي مارڪيٽ ڏانهن.
ٺيڪ. ۽ جيڪڏھن توھان DORA ڳڻپيوڪر تي ايلٽ گروپ ۾ آھيو، توھان کي ڇا ڪرڻ گھرجي؟ هتي ڪو به سٺو حل ناهي. توھان سڀ کان وڌيڪ امڪان آھيو صنعت ۾ سڀ کان وڌيڪ، ۽ وڌيڪ تيز رفتار ۽ قابل اعتماد اندروني R&D ۽ وڌيڪ وسيلن جي خرچ ذريعي ممڪن آھي.
اچو ته سڀ کان مٺي مقابلي ڏانهن وڃو.
مقابلي ۾
اسان شروعات ۾ روسي صنعت کي مغربي صنعت سان ڀيٽڻ چاهيون ٿا. جيڪڏهن اسان سڌو مقابلو ڪريون ٿا، اسان ڏسون ٿا ته اسان وٽ گهٽ پروفائيل آهن، ۽ اهي هڪ ٻئي سان ٿورو وڌيڪ مليا آهن، سرحدون ٿورو وڌيڪ ڌماڪيدار آهن:
اسان جا ايلٽ پرفارمر اعليٰ اداڪارن ۾ لڪيل آهن، پر اهي اتي آهن - اهي اشراڪ آهن، يونيڪارن جيڪي اهم اونچائي تي پهچي ويا آهن. روس ۾، ايلٽ پروفائل ۽ اعلي پروفائل جي وچ ۾ فرق اڃا تائين ڪافي نه آھي. اسان سمجهون ٿا ته مستقبل ۾ هي علحدگي انجنيئرنگ ڪلچر ۾ اضافو، انجنيئرنگ جي عملن جي عمل درآمد جي معيار ۽ ڪمپنين جي اندر مهارت جي سبب ٿيندي.
جيڪڏهن اسان روسي صنعت ۾ سڌي مقابلي ڏانهن وڃون ٿا، اسان ڏسي سگهون ٿا ته هاء پروفائيل ٽيمون هر لحاظ کان بهتر آهن. اسان پڻ اسان جي مفروضي جي تصديق ڪئي آهي ته انهن ميٽرڪ ۽ تنظيمي ڪارڪردگي جي وچ ۾ هڪ تعلق آهي: هاء پروفائل ٽيمن کي نه رڳو مقصد حاصل ڪرڻ جو امڪان آهي، پر انهن کان به وڌيڪ.
اچو ته ھاء پروفائيل ٽيمون بڻجي وڃون ۽ اتي نه رکون:
پر هي سال خاص آهي، ۽ اسان اهو جانچڻ جو فيصلو ڪيو ته ڪمپنيون ڪيئن ڪري رهيون آهن وبائي مرض ۾: هاءِ پروفائل ٽيمون گهڻو بهتر ڪم ڪري رهيون آهن ۽ صنعت جي اوسط کان بهتر محسوس ڪري رهيون آهن:
- 1,5-2 ڀيرا وڌيڪ امڪان نئين شين کي ڇڏڻ لاء،
- 2 ڀيرا وڌيڪ قابل اعتماد ۽ / يا ايپليڪيشن انفراسٽرڪچر جي ڪارڪردگي کي بهتر ڪرڻ جو امڪان.
اهو آهي، اهي صلاحيتون جيڪي اڳ ۾ ئي انهن کي تيزيء سان ترقي ڪرڻ ۾ مدد ڪري چڪا آهن، نوان پراڊڪٽس لانچ ڪرڻ، موجوده شين کي تبديل ڪرڻ، نئين مارڪيٽن ۽ نوان استعمال ڪندڙن کي فتح ڪرڻ ۾:
ٻيو ڇا اسان جي ٽيمن جي مدد ڪئي؟
انجنيئرنگ جي مشق
مان توهان کي هر مشق جي اهم نتيجن جي باري ۾ ٻڌائيندس جيڪي اسان آزمايا. شايد ڪجهه ٻي ٽيمن جي مدد ڪئي، پر اسان بابت ڳالهائي رهيا آهيون DevOps. ۽ DevOps جي اندر، اسان مختلف پروفائلن جي ٽيمن جي وچ ۾ فرق ڏسون ٿا.
پليٽ فارم هڪ خدمت جي طور تي
اسان پليٽ فارم جي عمر ۽ ٽيم جي پروفائيل جي وچ ۾ هڪ اهم تعلق نه ڳولي سگهيا آهن: پليٽ فارم ٻنهي گهٽ-ٽيم ۽ اعلي-ٽيمن لاء هڪ ئي وقت تي ظاهر ٿيو. پر بعد ۾، پليٽ فارم مهيا ڪري ٿو، سراسري طور تي، وڌيڪ خدمتون ۽ پروگرام ڪوڊ ذريعي ڪنٽرول لاء وڌيڪ پروگرامنگ انٽرفيس. ۽ پليٽ فارم ٽيمون وڌيڪ ممڪن آهن ته انهن جي ڊولپرز ۽ ٽيمن کي پليٽ فارم استعمال ڪرڻ ۾ مدد ڪن، انهن جي مسئلن کي حل ڪن ۽ پليٽ فارم سان لاڳاپيل واقعا گهڻو ڪري، ۽ ٻين ٽيمن کي تعليم ڏين.
بنيادي ڍانچي جي طور تي ڪوڊ
هتي هر شي ڪافي معياري آهي. اسان انفراسٹرڪچر ڪوڊ جي ڪم جي آٽوميشن جي وچ ۾ هڪ تعلق مليو آهي ۽ انفراسٹرڪچر جي مخزن جي اندر ڪيتري معلومات محفوظ ڪئي وئي آهي. هاءِ پروفائيل ڪمانڊز ذخيري ۾ وڌيڪ معلومات محفوظ ڪري ٿو: هي آهي انفراسٽرڪچر ترتيب، سي آءِ / سي ڊي پائپ لائن، ماحوليات سيٽنگون ۽ بلڊ پيٽرول. اهي هن معلومات کي گهڻو ڪري ذخيرو ڪن ٿا، انفراسٽرڪچر ڪوڊ سان بهتر ڪم ڪن ٿا، ۽ انفراسٽرڪچر ڪوڊ سان ڪم ڪرڻ لاءِ وڌيڪ عملن ۽ ڪمن کي خودڪار ڪن ٿا.
دلچسپ ڳالهه اها آهي ته اسان انفراسٽرڪچر ٽيسٽ ۾ ڪو خاص فرق نه ڏٺو. مان هن حقيقت کي منسوب ڪريان ٿو ته هاءِ پروفائل ٽيمن وٽ عام طور تي وڌيڪ ٽيسٽ آٽوميشن آهي. شايد انهن کي انفرااسٽرڪچر ٽيسٽن کان الڳ نه ٿيڻ گهرجي، بلڪه اهي ٽيسٽ جن سان اهي ايپليڪيشن چيڪ ڪن ٿا، ۽ انهن جي مهرباني، اهي اڳ ۾ ئي ڏسندا آهن ته اهي ڇا ۽ ڪٿي ڀڄي ويا آهن.
انضمام ۽ پهچائڻ
سڀ کان وڌيڪ بورنگ سيڪشن، ڇاڪاڻ ته اسان تصديق ڪئي آهي ته توهان وٽ وڌيڪ آٽوميشن آهي، بهتر توهان ڪوڊ سان ڪم ڪندا، وڌيڪ ممڪن آهي ته توهان بهتر نتيجا حاصل ڪندا.
تعمير
اسان ڏسڻ چاهيون ٿا ته مائڪرو سروسز ڪارڪردگي کي ڪيئن متاثر ڪن ٿيون. حقيقت ۾، اهي نه ٿا ڪن، ڇاڪاڻ ته مائڪرو سروسز جو استعمال ڪارڪردگي اشارن ۾ اضافو سان لاڳاپيل ناهي. Microservices ٻنهي لاءِ استعمال ٿينديون آهن هاءِ پروفائيل ڪمانڊ ۽ لو پروفائيل ڪمانڊ.
پر اهم ڳالهه اها آهي ته هاءِ ٽيمن لاءِ، مائڪرو سروس آرڪيٽيڪچر ڏانهن منتقلي انهن کي اجازت ڏئي ٿي ته اهي آزاديءَ سان پنهنجون خدمتون ترقي ڪري سگهن ۽ رول آئوٽ ڪن. جيڪڏهن فن تعمير ڊولپرز کي خودمختياري سان ڪم ڪرڻ جي اجازت ڏئي ٿي، بغير ڪنهن ٽيم جي ٻاهران انتظار ڪرڻ کان سواء، پوء اها رفتار وڌائڻ لاء هڪ اهم صلاحيت آهي. هن معاملي ۾، microservices مدد. ۽ صرف انهن جي عملدرآمد هڪ وڏو ڪردار ادا نٿو ڪري.
اسان اهو سڀ ڪجهه ڪيئن دريافت ڪيو؟
اسان وٽ DORA جي طريقي کي مڪمل طور تي نقل ڪرڻ جو هڪ امڪاني منصوبو هو، پر وسيلن جي کوٽ هئي. جيڪڏهن DORA تمام گهڻو اسپانسرشپ استعمال ڪري ٿو ۽ انهن جي تحقيق ۾ اڌ سال لڳن ٿا، اسان پنهنجي تحقيق ٿوري وقت ۾ ڪئي. اسان هڪ DevOps ماڊل ٺاهڻ چاهيون ٿا جيئن DORA ڪندو آهي، ۽ اسان اهو مستقبل ۾ ڪنداسين. هينئر تائين اسان پاڻ کي گرمي جي نقشن تائين محدود ڪيو آهي:
اسان هر پروفائيل ۾ ٽيمن ۾ انجنيئرنگ جي عملن جي ورڇ کي ڏٺو ۽ ڏٺائون ته هاءِ پروفائيل ٽيمون، سراسري طور تي، انجنيئرنگ جي طريقن کي استعمال ڪرڻ جا وڌيڪ امڪان هئا. توھان ھن بابت وڌيڪ پڙھي سگھو ٿا اسان جي مضمون ۾ .
تبديليءَ لاءِ، اچو ته تبديل ڪريون پيچيده شماريات کان سادو انگن اکرن ڏانهن.
ٻيو ڇا اسان دريافت ڪيو آهي؟
اوزار
اسان ڏسون ٿا ته اڪثر حڪم لينڪس خاندان جي او ايس پاران استعمال ڪيا ويا آهن. پر ونڊوز اڃا تائين رجحان ۾ آهي - گهٽ ۾ گهٽ اسان جي جوابن جو هڪ چوٿون ان جي هڪ يا ٻئي نسخن جي استعمال کي نوٽ ڪيو. اهو لڳي ٿو ته مارڪيٽ کي اها ضرورت آهي. تنهن ڪري، توهان انهن صلاحيتن کي ترقي ڪري سگهو ٿا ۽ ڪانفرنس ۾ پيشيونٽيون ٺاهي سگهو ٿا.
آرڪيسٽرن جي وچ ۾، اهو ڪنهن لاء راز ناهي، ڪبرنيٽس جي اڳواڻي ۾ آهي (52٪). ايندڙ لائن آرڪيسٽرٽر آهي Docker Swarm (اٽڪل 12٪). سڀ کان وڌيڪ مشهور سي آئي سسٽم آهن جينڪنز ۽ گيٽ ليب. سڀ کان وڌيڪ مشهور تشڪيل مينيجمينٽ سسٽم جوابي آهي، جنهن جي پٺيان اسان جي محبوب شيل.
Amazon هن وقت مشهور ڪلائوڊ هوسٽنگ فراهم ڪندڙ آهي. روسي بادلن جو حصو آهستي آهستي وڌي رهيو آهي. ايندڙ سال اهو ڏسڻ ۾ دلچسپ هوندو ته روسي بادل فراهم ڪندڙ ڪيئن محسوس ڪندا، ڇا انهن جي مارڪيٽ جو حصو وڌندو. اھي آھن، اھي استعمال ڪري سگھجن ٿيون، ۽ اھو سٺو آھي:
آئون منزل کي Igor ڏانهن منتقل ڪريان ٿو، جيڪو ڪجهه وڌيڪ انگ اکر ڏيندو.
عملن جي ورهاست
Igor Kurochkin: الڳ الڳ، اسان جواب ڏيڻ وارن کان پڇيو ته اهو ظاهر ڪيو ته ڪيئن سمجهيو ويو انجنيئرنگ عملن کي ڪمپني ۾ ورهايو ويو آهي. اڪثر ڪمپنين ۾، هڪ مخلوط طريقو آهي، جنهن ۾ نمونن جي مختلف سيٽ شامل آهن، ۽ پائلٽ پروجيڪٽ تمام مشهور آهن. اسان پروفائلن جي وچ ۾ ٿورو فرق پڻ ڏٺو. هاءِ پروفائيل جا نمائندا گهڻو ڪري ”هيٺ کان شروعات“ جو نمونو استعمال ڪندا آهن، جڏهن ماهرن جون ننڍيون ٽيمون ڪم جي عملن، اوزارن کي تبديل ڪنديون آهن ۽ ڪامياب عملن کي ٻين ٽيمن سان شيئر ڪنديون آهن. وچولي ۾، هي هڪ مٿين-هيٺ شروعات آهي جيڪا پوري ڪمپني کي متاثر ڪري ٿي ڪميونٽيز ۽ سينٽر آف ايڪسيلنس جي تخليق ذريعي:
چست ۽ DevOps
Agile ۽ DevOps جي وچ ۾ رابطي جو سوال اڪثر صنعت ۾ بحث ڪيو ويندو آهي. اهو مسئلو 2019/2020 جي اسٽيٽ آف ايگلي رپورٽ ۾ پڻ اٿاريو ويو آهي، تنهن ڪري اسان اهو مقابلو ڪرڻ جو فيصلو ڪيو ته ڪيئن Agile ۽ DevOps سرگرميون ڪمپنين ۾ ڳنڍيل آهن. اسان ڏٺو ته DevOps بغير Agile نادر آهي. جواب ڏيڻ وارن جي اڌ لاء، Agile جي پکيڙ تمام گهڻو اڳ شروع ٿي، ۽ تقريبا 20٪ هڪ ئي وقت جي شروعات کي ڏٺو، ۽ گهٽ پروفائل جي نشانين مان هڪ آهي Agile ۽ DevOps جي عملن جي غير موجودگي:
حڪم ٽوپولوجيز
گذريل سال جي آخر ۾، ڪتاب "”، جيڪو ڪمانڊ ٽوپولوجيز کي بيان ڪرڻ لاءِ فريم ورڪ پيش ڪري ٿو. اهو اسان لاء دلچسپ ٿيو ته ڇا اهو روسي ڪمپنين تي لاڳو ٿئي ٿو. ۽ اسان سوال پڇيو: "توهان ڪهڙي نموني ڳوليندا آهيو؟".
انفراسٽرڪچر ٽيمون اڌ جواب ڏيڻ وارن ۾ مشاهدو ڪيون ويون آهن، گڏوگڏ ترقي، جاچ ۽ آپريشن لاءِ الڳ ٽيمون. الڳ DevOps ٽيمون 45٪ نوٽ ڪيو، جن ۾ اعلي جا نمائندا وڌيڪ عام آهن. اڳيان اچي ٿو ڪراس فنڪشنل ٽيمون، جيڪي پڻ وڌيڪ عام آهن هاء تي. الڳ SRE ڪمانڊ هاء، وچولي پروفائلز ۾ ظاهر ٿيندا آهن ۽ گهٽ ۾ گهٽ گهٽ پروفائل ۾ نظر اچن ٿا:
DevQaOps تناسب
اسان اهو سوال FaceBook تي Skyeng پليٽ فارم ٽيم جي ٽيم ليڊر کان ڏٺو - هن کي ڪمپني ۾ ڊولپرز، ٽيسٽرز ۽ منتظمين جي تناسب ۾ دلچسپي هئي. اسان ان کان پڇيو ۽ پروفائلز جي بنياد تي جوابن کي ڏٺو: ھاء پروفائيل نمائندن وٽ گھٽ ٽيسٽ ۽ آپريشن انجنيئر آھن ھر ڊولپر لاءِ:
2021 لاءِ منصوبا
ايندڙ سال جي منصوبن ۾، جواب ڏيڻ وارن ھيٺين سرگرمين کي نوٽ ڪيو:
هتي توهان DevOps Live 2020 ڪانفرنس سان چونڪ ڏسي سگهو ٿا. اسان غور سان جائزو ورتو پروگرام:
- هڪ پيداوار جي طور تي انفراسٽرڪچر
- DevOps تبديلي
- DevOps جي عملن جي ورڇ
- ديو ايس ايس اوپس
- ڪيس ڪلبون ۽ بحث مباحثا
پر اسان جي پريزنٽيشن جو وقت سڀني موضوعن کي ڍڪڻ لاء ڪافي ناهي. پردي پٺيان ڇڏي ويو:
- پليٽ فارم هڪ خدمت ۽ هڪ پيداوار جي طور تي؛
- انفراسٽرڪچر جيئن ڪوڊ، ماحول ۽ بادل؛
- مسلسل انضمام ۽ پهچائڻ؛
- فن تعمير؛
- DevSecOps نمونن؛
- پليٽ فارم ۽ ڪراس فنڪشنل ٽيمون.
اسان وٽ ھڪڙو وڏو، 50 صفحا آھي، ۽ توھان ان کي وڌيڪ تفصيل سان ڏسي سگھو ٿا.
ويٺو آهي
اسان اميد ٿا ڪريون ته اسان جي تحقيق ۽ رپورٽ توهان کي ترقي، جانچ ۽ عملن جي نئين طريقن سان تجربا ڪرڻ جي حوصلا افزائي ڪندي، انهي سان گڏ توهان کي نيويگيٽ ڪرڻ ۾ مدد ڪندي، پنهنجو پاڻ کي مطالعي ۾ ٻين شرڪت ڪندڙن سان مقابلو ڪرڻ، ۽ انهن علائقن جي سڃاڻپ ڪندي جتي توهان پنهنجي طريقن کي بهتر بڻائي سگهو ٿا.
روس ۾ DevOps جي رياست جي پهرين مطالعي جا نتيجا:
- اهم ميٽرڪس. اسان ڏٺو آهي ته اهم ميٽرڪس (ترسيل وقت، مقرري جي تعدد، وصولي وقت، ۽ تبديلي جي ناڪامي) ترقي، جاچ، ۽ عملن جي عملن جي اثرائتي تجزيي لاء مناسب آهن.
- پروفائلز اعلي، وچولي، گھٽ. گڏ ڪيل ڊيٽا جي بنياد تي، اهو ممڪن آهي ته انگن اکرن جي لحاظ کان مختلف گروپن جي اعلي، وچولي، گهٽ ۾ ميٽرڪس، عملن، عملن ۽ اوزارن جي لحاظ کان مخصوص خاصيتن سان. هاءِ پروفائيل جا نمائندا گهٽ کان بهتر نتيجا ڏيکاريندا آهن. انهن کي حاصل ڪرڻ ۽ انهن جي مقصدن کان وڌيڪ ممڪن آهي.
- اشارا، وبائي مرض ۽ منصوبا 2021 لاءِ. هن سال هڪ خاص اشارو اهو آهي ته ڪمپنيون وبائي مرض سان ڪيئن مقابلو ڪيون. اعليٰ نمائندن بهتر ڪارڪردگي ڏيکاري، صارف جي مصروفيت ۾ اضافو تجربو ڪيو، ۽ ڪاميابيءَ جا بنيادي سبب موثر ترقي وارا عمل ۽ مضبوط انجنيئرنگ ڪلچر هئا.
- DevOps طريقا، اوزار ۽ انهن جي ترقي. ايندڙ سال لاءِ ڪمپنين جا مکيه منصوبا شامل آهن DevOps طريقن ۽ اوزارن جي ترقي، DevSecOps طريقن جو تعارف، ۽ تنظيمي ڍانچي ۾ تبديليون. ۽ DevOps جي عملن جي اثرائتي عمل درآمد ۽ ترقي پائلٽ منصوبن جي مدد سان ڪئي وئي آھي، ڪميونٽي جي ٺاھڻ ۽ مرڪز جو مرڪز، ڪمپني جي مٿئين ۽ ھيٺئين سطح تي شروعات.
اسان توهان جي راء، ڪهاڻيون، تاثرات ٻڌڻ چاهيندا. اسان هر ڪنهن جو شڪريو ادا ڪيو جنهن مطالعي ۾ حصو ورتو ۽ ايندڙ سال توهان جي شموليت جو منتظر آهيون.
جو ذريعو: www.habr.com