په روسیه 2020 کې د DevOps حالت

د یو څه حالت څنګه پوهیږو؟

تاسو کولی شئ په خپل نظر تکیه وکړئ، د معلوماتو د مختلفو سرچینو څخه جوړ شوي، د بیلګې په توګه، په ویب پاڼو کې خپرونې یا تجربه. تاسو کولی شئ د همکارانو، پیژندونکو څخه پوښتنه وکړئ. بله لاره د کنفرانسونو موضوعاتو ته کتنه ده: د پروګرام کمیټه د صنعت فعاله استازي دي، نو موږ د اړونده موضوعاتو په غوره کولو کې دوی باور لرو. یوه جلا ساحه څیړنه او راپورونه دي. خو یوه ستونزه شته. د DevOps حالت په اړه څیړنې هر کال په نړۍ کې ترسره کیږي، راپورونه د بهرنیو شرکتونو لخوا خپاره شوي، او د روسیې د DevOps په اړه تقریبا هیڅ معلومات شتون نلري.

مګر هغه ورځ راورسیده چې دا ډول څیړنه ترسره شوه، او نن به د پایلو په اړه خبرې وکړو. په روسیه کې د DevOps حالت د شرکتونو لخوا په ګډه مطالعه شوی "ایکسپریس 42"او"اونټیکو". ایکسپریس 42 د ټیکنالوژۍ شرکتونو سره د DevOps کړنې او وسیلې پلي کولو او پراختیا کې مرسته کوي او په روسیه کې د DevOps په اړه د خبرو کولو لومړی کس و. د مطالعې لیکوالان، ایګور کوروککین او ویتالي خبروف، په ایکسپریس 42 کې په تحلیل او مشورې بوخت دي، پداسې حال کې چې په مختلفو شرکتونو کې د عملیاتو او تجربې څخه تخنیکي پس منظر لري. د 8 کلونو لپاره، همکارانو په لسګونو شرکتونو او پروژو ته کتلي دي - له پیل څخه تر تصدیو پورې - د بیلابیلو ستونزو سره، او همدارنګه د مختلف کلتوري او انجینرۍ بشپړتیا سره.

په خپل راپور کې، ایګور او ویتالي وویل چې د څیړنې په بهیر کې کومې ستونزې شتون لري، دوی څنګه حل کړي، او همدارنګه څنګه د DevOps څیړنه په اصولو کې ترسره کیږي او ولې ایکسپریس 42 پریکړه وکړه چې خپل ځان ترسره کړي. د دوی راپور کتلی شئ دلته.

د DevOps څیړنه

خبرې اترې د ایګور کوروککین لخوا پیل شوې.

موږ په منظم ډول د DevOps کنفرانسونو کې له لیدونکو څخه پوښتنه کوو، "ایا تاسو د دې کال لپاره د DevOps وضعیت راپور لوستلی؟" یو څو خپل لاسونه پورته کوي، او زموږ مطالعې ښودلې چې یوازې دریمه برخه یې مطالعه کوي. که تاسو هیڅکله داسې راپورونه نه وي لیدلي، راځئ چې سمدلاسه ووایو چې دا ټول یو شان دي. ډیری وختونه داسې جملې شتون لري لکه: "د تیر کال په پرتله ..."

دلته موږ لومړۍ ستونزه لرو، او له هغې وروسته دوه نورې:

1. موږ د تیر کال معلومات نلرو. په روسیه کې د DevOps حالت د هیچا لپاره علاقه نلري؛
2. میتودولوژي. دا روښانه نده چې څنګه فرضیه و ازموئ، څنګه پوښتنې رامینځته کړئ، څنګه تحلیل کړئ، پایلې پرتله کړئ، اړیکې ومومئ؛
3. اصطلاحات. ټول راپورونه په انګلیسي کې دي، ژباړې ته اړتیا ده، د DevOps یو عام چوکاټ لا تر اوسه نه دی اختراع شوی او هرڅوک د خپل ځان سره راځي.

راځئ چې وګورو چې څنګه د DevOps دولتي تحلیلونه په ټوله نړۍ کې ترسره شوي.

تاریخي پس منظر

د DevOps څیړنه د 2011 راهیسې ترسره شوې. ګوډاګی، د ترتیب مدیریت سیسټمونو جوړونکی، لومړی کس و چې دوی یې ترسره کړل. په هغه وخت کې، دا د کوډ په بڼه د زیربناوو تشریح کولو لپاره یو له اصلي وسیلو څخه و. تر 2013 پورې، دا مطالعات په ساده ډول تړل شوي سروې وې او هیڅ عامه راپور نه و.

په 2013 کې، د IT انقلاب راڅرګند شو، په DevOps کې د ټولو لوی کتابونو خپرونکی. د ګوډاګی سره یوځای، دوی د DevOps لومړۍ خپرونه چمتو کړه، چیرې چې د لومړي ځل لپاره 4 کلیدي میټریکونه ښکاره شول. راتلونکی کال، ThoughtWorks، یو مشورتي شرکت چې د صنعت تمریناتو او وسیلو کې د منظم ټیکنالوژۍ رادارونو لپاره پیژندل شوی، ښکیل شو. او په 2015 کې، د میتودولوژي سره یوه برخه اضافه شوه، او دا څرګنده شوه چې دوی څنګه تحلیل ترسره کوي.

په 2016 کې، د مطالعې لیکوالانو، خپل شرکت DORA (DevOps څیړنه او ارزونه) جوړه کړې، یو کلنی راپور خپور کړ. راتلونکی کال، DORA او ګوډاګی خپل وروستی ګډ راپور خپور کړ.

او بیا یو څه په زړه پورې پیل شو:

په 2018 کې، شرکتونه وویشل شول او دوه خپلواک راپورونه خپاره شول: یو د پوپټ څخه، دوهم د DORA څخه د ګوګل سره په ګډه. DORA د کلیدي میټریکونو، د فعالیت پروفایلونو، او انجنیري تمرینونو سره خپل میتودولوژي ته دوام ورکړی چې کلیدي میټریکونه او د شرکت په کچه فعالیت اغیزه کوي. او ګوډاګی د پروسې توضیح او د DevOps ارتقاء سره خپله تګلاره وړاندې کړه. مګر کیسه ریښه ونه نیوله، په 2019 کې ګوډاګی دا میتودولوژي پریښوده او د راپورونو یوه نوې نسخه یې خپره کړه، کوم چې کلیدي کړنې لیست کړي او څنګه دوی د دوی له نظره DevOps اغیزه کوي. بیا بله پیښه وشوه: ګوګل DORA اخیستی، او په ګډه یې یو بل راپور خپور کړ. تاسو شاید هغه لیدلی وي.

سږکال، شیان پیچلي شول. ګوډاګی پیژندل شوی چې خپله سروې یې پیل کړې. دوی دا زموږ په پرتله یوه اونۍ دمخه وکړل ، او دا لا دمخه پای ته رسیدلی. موږ په دې کې برخه واخیسته او وګورو چې کوم موضوعات چې دوی ورسره علاقه لري. اوس ګوډاګی خپل تحلیل کوي او د راپور خپرولو لپاره چمتووالی نیسي.

مګر لاهم د DORA او ګوګل لخوا هیڅ اعلان ندی شوی. د می په میاشت کې، کله چې سروې معمولا پیل شوه، معلومات راغلل چې نیکول فورسګرین، د DORA یو بنسټ ایښودونکی، بل شرکت ته تللی و. له همدې امله، موږ فکر کاوه چې سږ کال به د DORA لخوا هیڅ څیړنه او راپور شتون ونلري.

په روسیه کې شیان څنګه دي؟

موږ د DevOps څیړنه نه ده کړې. موږ په کنفرانسونو کې خبرې وکړې، د نورو خلکو موندنې بیا بیانول، او Raiffeisenbank د 2019 لپاره "State of DevOps" ژباړلی (تاسو کولی شئ د دوی اعلان په Habré کې ومومئ)، له دوی څخه ډیره مننه. او دا ټول دي.

له همدې امله، موږ خپله څیړنه په روسیه کې د DORA میتودولوژیو او موندنو په کارولو سره ترسره کړه. موږ د خپلې څیړنې لپاره د Raiffeisenbank د همکارانو راپور کارولی، په شمول د اصطلاحاتو او ژباړې همغږي کولو لپاره. او د صنعت پورې اړوند پوښتنې د DORA راپورونو او د سږکال پوپټ پوښتنلیک څخه اخیستل شوي.

د څیړنې بهیر

راپور یوازې وروستۍ برخه ده. د څیړنې ټوله پروسه له څلورو مهمو مرحلو څخه جوړه ده:

د چمتووالي مرحلې په جریان کې، موږ د صنعت کارپوهانو سره مرکه وکړه او د فرضیو لیست یې چمتو کړ. د دوی پر بنسټ، پوښتنې راټولې شوې او د اګست په میاشت کې یوه سروې پیل شوه. بیا مو راپور پخپله تحلیل او چمتو کړ. د DORA لپاره، دا پروسه 6 میاشتې وخت نیسي. موږ په 3 میاشتو کې ولیدل، او اوس موږ پوهیږو چې موږ په سختۍ سره کافي وخت درلود: یوازې د تحلیل په ترسره کولو سره تاسو پوهیږئ چې کومې پوښتنې ته اړتیا لرئ.

ګډونوالو

ټول بهرني راپورونه د ګډون کوونکو د انځور سره پیل کیږي، او ډیری یې د روسیې څخه ندي. د روسیې د ځواب ویونکو سلنه په کال کې له 5 څخه تر 1٪ پورې بدلون مومي، او دا اجازه نه ورکوي چې کومې پایلې ته ورسیږي.

د DevOps 2019 راپور د سرعت حالت څخه نقشه:

زموږ په څیړنه کې، موږ د 889 خلکو سره مرکه وکړه - دا خورا ډیره ده (د DORA ټولپوښتنه په کال کې د زرو خلکو په اړه په خپلو راپورونو کې) او دلته موږ هدف ترلاسه کړ:

ریښتیا، زموږ ټول ګډونوال پای ته نه دي رسیدلي: د بشپړیدو سلنه له نیمایي څخه لږ څه کمه شوه. مګر حتی دا د نمایندګۍ نمونې ترلاسه کولو او تحلیل ترسره کولو لپاره کافي و. DORA په خپلو راپورونو کې د ډکولو سلنه نه څرګندوي، نو دلته هیڅ پرتله نشته.

صنعتونه او پوستونه

زموږ ځواب ویونکي د لسګونو صنعتونو استازیتوب کوي. په معلوماتي ټکنالوجۍ کې نیم کار. دا د مالي خدماتو، سوداګرۍ، مخابراتو او نورو لخوا تعقیب کیږي. د پوستونو په منځ کې متخصصین (پراختیا کونکي، ټیسټر، عملیاتي انجنیر) او د مدیریت کارمندان (د ټیمونو مشران، ډلې، ساحې، رییسان) دي:

په دوو کې یو یې د منځنۍ کچې شرکت لپاره کار کوي. هر دریم کس په لویو شرکتونو کې کار کوي. ډیری د 9 کسانو په ټیمونو کې کار کوي. په جلا توګه، موږ د اصلي فعالیتونو په اړه وپوښتل، او ډیری یې د عملیاتو سره تړاو لري، او نږدې 40٪ په پراختیا کې بوخت دي:

نو موږ د مختلفو صنعتونو، شرکتونو، ټیمونو د استازو د پرتله کولو او تحلیل لپاره معلومات راټول کړل. زما همکار ویتالی خبرروف به د تحلیل په اړه ووایی.

تحلیل او پرتله کول

ویتالي خبرروف: د ټولو ګډونوالو څخه ډیره مننه چې زموږ سروې یې بشپړه کړې، پوښتنلیکونه یې ډک کړل او موږ ته یې زموږ د فرضیې د نورو تحلیل او ازموینې لپاره معلومات راکړل. او زموږ د پیرودونکو او پیرودونکو څخه مننه، موږ د تجربې بډایه لرو چې د صنعت اندیښنو په پیژندلو کې یې مرسته کړې او هغه فرضیې چې موږ زموږ په څیړنه کې ازمول شوي دي.

له بده مرغه، تاسو نشئ کولی یوازې له یوې خوا د پوښتنو لیست واخلئ او له بلې خوا ډاټا، یو څه یې پرتله کړئ، ووایاست: "هو، هر څه د دې په څیر کار کوي، موږ سم وو" او توزیع کړئ. نه، موږ میتودولوژي او احصایوي میتودونو ته اړتیا لرو ترڅو ډاډ ترلاسه کړو چې موږ غلط نه یو او زموږ پایلې د باور وړ دي. بیا موږ کولی شو خپل نور کار د دې معلوماتو پراساس جوړ کړو:

کلیدي میترونه

موږ د DORA میتودولوژي د اساس په توګه واخیسته، کوم چې دوی په تفصیل سره په کتاب "د DevOps ګړندي حالت" کې تشریح کړي. موږ ولیدل چې ایا کلیدي میټریکونه د روسیې بازار لپاره مناسب دي، ایا دوی په ورته ډول کارول کیدی شي لکه څنګه چې DORA د دې پوښتنې ځواب لپاره کاروي: "په روسیه کې صنعت څنګه د بهرني صنعت سره مطابقت لري؟"

کلیدي معیارونه:

1. د تعدد تعدد. د اپلیکیشن نوې نسخه څو ځله د تولید چاپیریال ته ګمارل کیږي (پلان شوي بدلونونه ، د هاټ فکسونو او پیښې غبرګون پرته)؟
2. د لېږدون وخت. د بدلون ترسره کولو (د کوډ په توګه د فعالیت لیکلو) او د تولید چاپیریال ته د بدلون پلي کولو تر مینځ اوسط وخت څومره دی؟
3. د بیا رغونې وخت. د پیښې ، خدماتو تخریب ، یا د بګ کشف وروسته چې د اپلیکیشن کاروونکو اغیزه کوي د تولید چاپیریال ته د غوښتنلیک بیرته راګرځولو لپاره په اوسط ډول څومره وخت نیسي؟
4. ناکام بدلونونه. د تولید په چاپیریال کې د ګمارنې څومره سلنه د غوښتنلیک تخریب یا پیښو لامل کیږي او درملنې ته اړتیا لري (د بدلونونو رول بیک ، د هاټ فکس پراختیا یا پیچ)؟

DORA په خپله څیړنه کې د دې میترونو او سازماني فعالیت ترمنځ اړیکه موندلې ده. موږ دا زموږ په مطالعې کې هم ازموینه کوو.

مګر د دې لپاره چې ډاډ ترلاسه کړئ چې څلور کلیدي میترونه کولی شي په یو څه اغیزه وکړي، تاسو باید پوه شئ - ایا دوی یو له بل سره تړاو لري؟ DORA په مثبت ځواب کې د یو احتیاط سره ځواب ورکړ: د ناکامو بدلونونو (د ناکامۍ نرخ بدلون) او درې نورو میټریکونو ترمنځ اړیکه یو څه کمزورې ده. موږ د ورته انځور په اړه ترلاسه کړ. که د سپارلو وخت، د ځای پرځای کولو فریکونسۍ، او د بیا رغونې وخت یو له بل سره تړاو ولري (موږ دا اړیکه د پییرسن ارتباط او د چاډاک پیمان له لارې تاسیس کړه)، نو د ناکامو بدلونونو سره دومره قوي اړیکه شتون نلري.

په اصل کې، ډیری ځواب ورکوونکي ځواب ورکوي چې دوی په تولید کې لږ شمیر پیښې لري. که څه هم موږ به وروسته وګورو چې د ځواب ورکوونکو ډلو تر منځ د ناکامو بدلونونو په اړه لاهم د پام وړ توپیر شتون لري، موږ لاهم نشو کولی د دې ویش لپاره دا میټریک وکاروو.

موږ دا حقیقت ته منسوب کوو چې (لکه څنګه چې دا زموږ د ځینو پیرودونکو سره د تحلیل او اړیکو په جریان کې راوتلی) د هغه څه په نظر کې لږ توپیر شتون لري چې پیښه ګڼل کیږي. که موږ د تخنیکي کړکۍ په جریان کې زموږ د خدماتو فعالیت بحال کړو، ایا دا یوه پیښه ګڼل کیدی شي؟ شاید نه، ځکه چې موږ هرڅه سم کړل، موږ عالي یو. ایا موږ کولی شو دا یوه پیښه وګڼو که چیرې موږ خپل غوښتنلیک 10 ځله زموږ لپاره په نورمال ، پیژندل شوي حالت کې راوباسئ؟ داسې ښکاري چې نه. له همدې امله، د نورو میترونو سره د ناکامو بدلونونو د اړیکو پوښتنه خلاصه پاتې ده. موږ به یې نور هم اصلاح کړو.

دلته مهم دی چې موږ د تحویلي وختونو ، د بیا رغونې وختونه ، او د ځای په ځای کولو فریکوینسي ترمینځ د پام وړ اړیکه وموندله. له همدې امله، موږ دا درې میټریکونه واخیستل ترڅو ځواب ورکوونکي نور د فعالیت ګروپونو ته وویشي.

په ګرام کې څومره وزن لري؟

موږ د درجه بندي کلستر تحلیل کارولی:

• موږ ځواب ورکوونکي په n-dimensional ځای ویشو، چیرې چې د هر ځواب ورکوونکي همغږي د دوی پوښتنو ته ځوابونه دي.
• هر ځواب ورکوونکی یو کوچنی کلستر اعلان شوی.
• موږ یو بل ته نږدې دوه کلسترونه په یوه لوی کلستر کې سره یوځای کوو.
• موږ د کلسترونو راتلونکی جوړه پیدا کوو او په لوی کلستر کې یې یوځای کوو.

په دې توګه موږ خپل ټول ځواب ویونکي په هغو کلسترونو کې ګروپ کوو چې موږ ورته اړتیا لرو. د ډنډروګرام (د کلسترونو ترمنځ د ارتباط یوه ونه) په مرسته، موږ د دوو ګاونډیو کلسترونو ترمنځ فاصله ګورو. ټول هغه څه چې زموږ لپاره پاتې دي دا دي چې د دې کلسترونو تر مینځ یو ټاکلی فاصله حد وټاکو او ووایو: "دا دوه ډلې یو له بل څخه د توپیر وړ دي ځکه چې د دوی ترمینځ فاصله خورا لوی دی."

مګر دلته یوه پټه ستونزه شتون لري: موږ د کلسترونو په شمیر کې هیڅ محدودیت نلرو - موږ کولی شو 2، 3، 4، 10 کلسترونه ترلاسه کړو. او لومړۍ مفکوره دا وه - ولې زموږ ټول ځواب ویونکي په 4 ګروپونو نه ویشل کیږي، لکه څنګه چې DORA کوي. مګر موږ ولیدل چې د دې ډلو تر منځ توپیر خورا مهم دی، او موږ نشو کولی ډاډ ترلاسه کړو چې ځواب ورکوونکی واقعیا د هغه ډلې پورې اړه لري، نه د ګاونډي سره. موږ لاهم نشو کولی د روسیې بازار په څلورو ډلو وویشو. له همدې امله، موږ په دریو پروفایلونو کې میشت شو چې تر منځ یې د احصایې له پلوه د پام وړ توپیر شتون لري:

بیا، موږ پروفایل د کلسترونو په واسطه وټاکه: موږ د هرې ډلې لپاره د هر میټریک لپاره میډین واخیست او د فعالیت پروفایلونو جدول مو ترتیب کړ. په حقیقت کې، موږ په هر ګروپ کې د اوسط ګډون کونکي د فعالیت پروفایلونه ترلاسه کړل. موږ درې د موثریت پروفایلونه پیژندلي: ټیټ، متوسط، لوړ:

دلته موږ خپل فرضیه تایید کړه چې 4 کلیدي میټریکونه د فعالیت پروفایل ټاکلو لپاره مناسب دي، او دوی دواړه په لویدیځ او روسی بازارونو کې کار کوي. د ډلو ترمنځ توپیر شتون لري او دا د احصایې له پلوه خورا مهم دی. زه ټینګار کوم چې د اوسط په شرایطو کې د ناکامو بدلونونو میټریک په شرایطو کې د فعالیت پروفایلونو ترمنځ د پام وړ توپیر شتون لري، که څه هم موږ په پیل کې ځواب ورکوونکي د دې پیرامیټر لخوا نه وو ویشلي.

بیا پوښتنه راپورته کیږي: دا ټول څنګه کارول کیږي؟

څنګه کارول کیږي

که موږ کوم ټیم واخلو، 4 کلیدي میترونه او میز ته یې پلي کړو، نو په 85٪ قضیو کې به موږ بشپړ لوبه ونه کړو - دا یوازې یو اوسط ګډون کوونکی دی، او نه هغه څه چې په واقعیت کې دي. موږ ټول (او هر ټیم) یو څه توپیر لرو.

موږ وکتل: موږ خپل ځواب ورکوونکي او د DORA فعالیت پروفایل واخیست، او وګورو چې څومره ځواب ورکوونکي دا یا هغه پروفایل سره سمون لري. موږ وموندله چې یوازې 16٪ ځواب ویونکي یقینا یو پروفایل ته راوتلي. پاتې ټول په منځ کې په یو ځای کې ویشل شوي دي:

دا پدې مانا ده چې د موثریت پروفایل محدود ساحه لري. د دې لپاره چې پوه شئ چې تاسو په لومړي اټکل کې یاست، تاسو کولی شئ دا جدول وکاروئ: "هو، داسې ښکاري چې موږ منځنۍ یا لوړې ته نږدې یو!" که تاسو پوهیږئ چې چیرته لاړ شئ، دا ممکن کافي وي. مګر که ستاسو هدف ثابت، دوامداره پرمختګ وي، او تاسو غواړئ په سمه توګه پوه شئ چې چیرته پراختیا ومومي او څه وکړي، نو اضافي فنډونو ته اړتیا ده. موږ ورته حساب ورکوونکي وایو:

• د DORA کیلکولیټر
• کیلکولیټر ایکسپریس 42* (په پراختیا کې)
• خپل پرمختګ (تاسو کولی شئ خپل داخلي کیلکولیټر جوړ کړئ).

دوی د څه لپاره اړتیا لري؟ د پوهیدو لپاره:

• ایا زموږ په سازمان کې ټیم زموږ معیارونو سره سم دی؟
• که نه، ایا موږ کولی شو له دې سره مرسته وکړو، د هغه مهارت په چوکاټ کې چې زموږ شرکت لري ګړندی کړو؟
• که داسې وي، ایا موږ نور هم ښه کولی شو؟

تاسو کولی شئ دا په شرکت کې د احصایو راټولولو لپاره هم وکاروئ:

• کوم ټیمونه لرو؟
• ټیمونه په پروفایلونو ویشئ؛
• وګورئ: اوه، دا امرونه کم کار کوي (دوی لږ څه نه راوباسي)، مګر دا ښه دي: دوی هره ورځ ځای په ځای کوي، پرته له غلطیو، دوی د یو ساعت څخه لږ وخت لري.

او بیا تاسو کولی شئ ومومئ چې زموږ په شرکت کې د هغه ټیمونو لپاره اړین مهارتونه او وسیلې شتون لري چې لاهم په مساوي ندي.

یا، که تاسو پوهیږئ چې تاسو د شرکت دننه ښه احساس کوئ، تاسو د ډیرو څخه غوره یاست، نو تاسو کولی شئ یو څه پراخه وګورئ. دا یوازې د روسیې صنعت دی: ایا موږ کولی شو د ځان ګړندي کولو لپاره د روسیې صنعت کې اړین مهارت ترلاسه کړو؟ د ایکسپریس 42 کیلکولیټر به دلته مرسته وکړي (دا د پراختیا لاندې ده). که تاسو د روسیې بازار وده کړې وي، نو بیا وګورئ د DORA کیلکولیټر او د نړۍ بازار ته.

ښه. او که تاسو د DORA کیلکولیټر کې د ایلیت ګروپ کې یاست، تاسو باید څه وکړئ؟ دلته هیڅ ښه حل نشته. تاسو ډیری احتمال د صنعت په سر کې یاست، او نور سرعت او اعتبار د داخلي R&D او د ډیرو سرچینو مصرفولو له لارې ممکن دی.

راځئ چې تر ټولو خوږ - پرتله کولو ته لاړ شو.

پرتله کول

موږ په پیل کې غوښتل چې د روسیې صنعت د لویدیځ صنعت سره پرتله کړو. که موږ مستقیم پرتله کړو، موږ ګورو چې موږ لږ پروفایلونه لرو، او دوی یو له بل سره یو څه ډیر مخلوط دي، سرحدونه یو څه نور روښانه دي:

زموږ د غوره لوبغاړو په منځ کې پټ دي، مګر دوی هلته دي - دا هغه اشرافي، یونیکورن دي چې د پام وړ لوړوالی ته رسیدلي دي. په روسیه کې، د ایلیټ پروفایل او لوړ پروفایل ترمنځ توپیر لاهم د پام وړ ندی. موږ فکر کوو چې په راتلونکي کې دا جلا کول به د انجینرۍ کلتور د زیاتوالي له امله رامینځته شي ، د انجینرۍ عملونو پلي کولو کیفیت او په شرکتونو کې تخصص.

که موږ د روسیې په صنعت کې مستقیم پرتله کولو ته لاړ شو، موږ لیدلی شو چې د لوړ پروفایل ټیمونه په ټولو برخو کې غوره دي. موږ زموږ فرضیه هم تایید کړه چې د دې میټریکونو او سازماني فعالیت تر مینځ اړیکه شتون لري: د لوړ پروفایل ټیمونه ډیر احتمال لري چې نه یوازې اهداف ترلاسه کړي ، بلکه له دوی څخه هم ډیر وي.
راځئ چې د لوړ پروفایل ټیمونه واوسو او دلته نه ودریږو:

مګر دا کال ځانګړی دی ، او موږ پریکړه وکړه چې وګورو چې شرکتونه څنګه په وبا کې کار کوي: د لوړ پروفایل ټیمونه د صنعت اوسط څخه ډیر ښه کار کوي او ښه احساس کوي:

• د نوي محصولاتو خوشې کولو احتمال 1,5-2 ځله ډیر ،
• د غوښتنلیک زیربنا د اعتبار او / یا فعالیت ښه کولو احتمال 2 ځله ډیر.

دا، هغه وړتیاوې چې دوی یې مخکې له دوی سره مرسته کړې وه په چټکۍ سره وده وکړي، نوي محصولات پیل کړي، موجوده محصولات تعدیل کړي، په دې توګه نوي بازارونه او نوي کاروونکي فتح کړي:

بل څه زموږ ټیمونو سره مرسته وکړه؟

د انجینرۍ کړنې

زه به تاسو ته د هر تمرین لپاره د پام وړ موندنو په اړه ووایم چې موږ یې ازموینه کړې. شاید بل څه د ټیمونو سره مرسته کړې، مګر موږ د DevOps په اړه خبرې کوو. او په DevOps کې ، موږ د مختلف پروفایلونو ټیمونو ترمینځ توپیر ګورو.

د خدمت په توګه پلیټ فارم

موږ د پلیټ فارم عمر او ټیم پروفایل ترمنځ د پام وړ اړیکه ونه موندله: پلیټ فارمونه په ورته وخت کې د ټیټ ټیمونو او عالي ټیمونو لپاره څرګند شول. مګر د وروستي لپاره، پلیټ فارم په اوسط ډول، د پروګرام کوډ له لارې د کنټرول لپاره ډیر خدمتونه او د پروګرام کولو ډیر انټرنیټونه چمتو کوي. او د پلیټ فارم ټیمونه ډیر احتمال لري چې د دوی پراختیا کونکو او ټیمونو سره د پلیټ فارم کارولو کې مرسته وکړي ، د دوی ستونزې حل کړي او پلیټ فارم پورې اړوند پیښې ډیر ځله ، او نورو ټیمونو ته روزنه ورکړي.

د کوډ په توګه زیربنا

دلته هرڅه خورا معیاري دي. موږ د زیربنا کوډ د کار اتومات کولو او د زیربنا ذخیره کې دننه څومره معلومات زیرمه شوي ترمینځ اړیکه وموندله. د لوړ پروفایل کمانډونه په ذخیره کې نور معلومات ذخیره کوي: دا د زیربناوو ترتیب، CI / CD پایپ لاین، د چاپیریال ترتیبات او د جوړولو پیرامیټونه دي. دوی دا معلومات ډیر ځله ذخیره کوي، د زیربنا کوډ سره ښه کار کوي، او د زیربنا کوډ سره کار کولو لپاره ډیرې پروسې او دندې اتومات کوي.

په زړه پورې خبره، موږ د زیربناوو په ازموینو کې د پام وړ توپیر ونه لید. زه دا حقیقت ته منسوبوم چې د لوړ پروفایل ټیمونه په عمومي ډول د ازموینې ډیر اتومات لري. شاید دوی باید د زیربنایی ازموینو لخوا جلا جلا نه وي ، بلکه هغه ازموینې چې دوی یې غوښتنلیکونه ګوري ، او د دوی څخه مننه دوی دمخه ګوري چې څه او چیرې مات شوي.

ادغام او تحویل

ترټولو ستړي کوونکې برخه، ځکه چې موږ تایید کړه چې تاسو څومره اتومات لرئ، څومره چې تاسو د کوډ سره ښه کار کوئ، ډیر احتمال به تاسو غوره پایلې ترلاسه کړئ.

معمارۍ

موږ غوښتل وګورو چې مایکرو خدمتونه څنګه فعالیت اغیزه کوي. په حقیقت کې، دوی نه کوي، ځکه چې د مایکرو خدماتو کارول د فعالیت شاخصونو زیاتوالي سره تړاو نلري. مایکرو خدمات دواړه د لوړ پروفایل کمانډونو او ټیټ پروفایل کمانډونو لپاره کارول کیږي.

مګر هغه څه چې د پام وړ دي دا دي چې د عالي ټیمونو لپاره ، د مایکرو سرویس جوړښت ته لیږد دوی ته اجازه ورکوي چې په خپلواکه توګه خپل خدمات رامینځته کړي او وده وکړي. که چیرې جوړښت پراختیا کونکو ته اجازه ورکړي چې په خپلواکه توګه عمل وکړي، پرته له دې چې ټیم ته د بهرني چا انتظار وکړي، نو دا د سرعت زیاتولو لپاره کلیدي وړتیا ده. په دې حالت کې، مایکرو خدمتونه مرسته کوي. او یوازې د دوی پلي کول لوی رول نه لوبوي.

موږ دا ټول څنګه کشف کړل؟

موږ د DORA میتودولوژي په بشپړه توګه د نقل کولو لپاره یو هوښیار پلان درلود، مګر سرچینې نه درلودې. که DORA ډیر سپانسرشپ کاروي او د دوی څیړنه نیم کال وخت نیسي، موږ په لنډ وخت کې خپلې څیړنې ترسره کړې. موږ غوښتل د DevOps ماډل جوړ کړو لکه DORA کوي، او موږ به په راتلونکي کې دا کار وکړو. تر دې دمه موږ خپل ځان د تودوخې نقشې پورې محدود کړی دی:

موږ په هر پروفایل کې د ټیمونو په اوږدو کې د انجینرۍ تمریناتو ویش ته کتنه وکړه او وموندله چې د لوړ پروفایل ټیمونه په اوسط ډول د انجینرۍ تمریناتو څخه ډیر احتمال لري. تاسو کولی شئ د دې ټولو په اړه نور زموږ په برخه کې ولولئ راپور.

د بدلون لپاره، راځئ چې له پیچلو احصایو څخه ساده ته واړوو.

موږ نور څه کشف کړل؟

توکي

موږ ګورو چې ډیری کمانډونه د لینکس کورنۍ OS لخوا کارول کیږي. مګر وینډوز لاهم په رجحان کې دی - لږترلږه زموږ د ځواب ویونکو څلورمه برخه یې د یوې یا بلې نسخې کارولو یادونه کړې. داسې ښکاري چې بازار دې ته اړتیا لري. له همدې امله ، تاسو کولی شئ دا وړتیاوې رامینځته کړئ او په کنفرانسونو کې پریزنټشنونه وړاندې کړئ.

د آرکیسټریټانو په مینځ کې، دا د هیچا لپاره پټ نه دی، Kubernetes په مخکښ دی (52٪). بل په لیکه کې آرکیسټرټر د ډاکر سوارم دی (شاوخوا 12٪). ترټولو مشهور CI سیسټمونه جینکنز او ګیټ لیب دي. ترټولو مشهور د تنظیم کولو مدیریت سیسټم ځواب وړ دی، زموږ د محبوب شیل لخوا تعقیب شوی.

ایمیزون اوس مهال د بادل کوربه توب مخکښ چمتو کونکی دی. د روسیې د ورېځو ونډه په تدریجي ډول مخ په زیاتیدو ده. راتلونکی کال به دا په زړه پورې وي چې وګورئ د روسیې بادل چمتو کونکي به څنګه احساس وکړي ، ایا د دوی د بازار برخه به لوړه شي. دوی دي، دوی کارول کیدی شي، او دا ښه دی:

زه ایګور ته فرش تیر کړم، څوک به نور احصایې ورکړي.

د عملونو خپرول

ایګور کوروچکین: په جلا توګه، موږ له ځواب ویونکو څخه وغوښتل چې دا په ګوته کړي چې څنګه په شرکت کې د انجینرۍ په پام کې نیولو سره توزیع کیږي. په ډیری شرکتونو کې، مخلوط طریقه شتون لري، د مختلفو نمونو څخه جوړه شوې، او پیلوټ پروژې خورا مشهور دي. موږ د پروفایلونو ترمنځ یو څه توپیر هم ولید. د لوړ پروفایل استازي اکثرا د "لاندې څخه نوښت" بڼه کاروي، کله چې د متخصصینو کوچني ټیمونه د کار پروسې، وسایل بدلوي، او د نورو ټیمونو سره بریالي تمرینونه شریکوي. په منځني ډول، دا د پورته څخه ښکته نوښت دی چې د ټولنو او د غوره مرکزونو د جوړولو له لارې ټول شرکت اغیزه کوي:

Agile او DevOps

د Agile او DevOps ترمنځ د ارتباط پوښتنه اکثرا په صنعت کې بحث کیږي. دا مسله د 2019/2020 لپاره د Agile راپور ریاست کې هم راپورته شوې ، نو موږ پریکړه وکړه چې پرتله کړو چې څنګه Agile او DevOps فعالیتونه په شرکتونو کې وصل دي. موږ وموندله چې له ایجیل پرته DevOps نادر دي. د نیمایي ځواب ویونکو لپاره، د Agile خپریدل ډیر دمخه پیل شوي، او شاوخوا 20٪ په ورته وخت کې پیل لیدلی، او د ټیټ پروفایل یوه نښه به د Agile او DevOps کړنو نشتوالی وي:

د قوماندې ټوپولوژي

د تیر کال په پای کې، کتابد ټیم ټوپولوژی"، کوم چې د کمانډ ټوپولوژیو تشریح کولو لپاره چوکاټ وړاندیز کوي. دا زموږ لپاره په زړه پوري شوه چې ایا دا د روسیې شرکتونو لپاره پلي کیږي. او موږ پوښتنه وکړه: "تاسو کوم نمونې ومومئ؟".

د زیربنا ټیمونه د ځواب ویونکو په نیمایي کې لیدل کیږي، او همدارنګه د پراختیا، ازموینې او عملیاتو لپاره جلا ټیمونه. جلا جلا DevOps ټیمونو 45٪ یادونه وکړه، چې په منځ کې یې د لوړ استازو ډیر عام دي. بل د کراس فنکشن ټیمونه راځي، کوم چې په لوړ کې ډیر عام دي. جلا جلا SRE کمانډونه په لوړ، منځني پروفایلونو کې ښکاري او په ټیټ پروفایل کې په ندرت سره لیدل کیږي:

د DevQaOps تناسب

موږ دا پوښتنه په فېسبوک کې د سکاینګ پلیټ فارم ټیم د ټیم مشر څخه ولیده - هغه په ​​شرکتونو کې د پراختیا کونکو ، ازموینې کونکو او مدیرانو تناسب سره علاقه درلوده. موږ دا وپوښتل او د پروفایلونو پراساس ځوابونو ته یې وکتل: د لوړ پروفایل استازي د هر پراختیا کونکي لپاره لږ ازموینې او عملیاتي انجینران لري:

د 2021 لپاره پلانونه

د راتلونکي کال په پلانونو کې، ځواب ویونکو د لاندې فعالیتونو یادونه وکړه:

دلته تاسو کولی شئ د DevOps Live 2020 کنفرانس سره تقاطع وګورئ. موږ برنامه په دقت سره بیاکتنه وکړه:

• د محصول په توګه زیربنا
• د DevOps بدلون
• د DevOps کړنو ویش
• DevSecOps
• د قضیې کلبونه او بحثونه

مګر زموږ د پریزنټشن وخت دومره نه دی چې ټول موضوعات پوښي. د پردې شاته پاتې شوي:

• پلیټ فارم د خدمت او محصول په توګه؛
• د کوډ، چاپیریال او بادل په توګه زیربنا؛
• دوامداره ادغام او تحویل؛
• معمارۍ;
• د DevSecOps نمونې؛
• پلیټ فارم او کراس فنکشن ټیمونه.

راپور موږ یو لوی، 50 پاڼې ترلاسه کړې، او تاسو کولی شئ په تفصیل سره وګورئ.

سمول

موږ هیله مند یو چې زموږ څیړنه او راپور به تاسو ته وهڅوي چې د پراختیا، ازموینې او عملیاتو لپاره نوي طریقې تجربه کړي، او همدارنګه تاسو سره مرسته وکړي چې په څیړنه کې د نورو ګډون کونکو سره ځان پرتله کړي، او هغه ساحې وپیژني چیرې چې تاسو کولی شئ خپل ځان ته وده ورکړئ.

په روسیه کې د DevOps حالت د لومړۍ مطالعې پایلې:

• کلیدي میترونه. موږ موندلي چې کلیدي میټریکونه (د سپارلو وخت، د ځای پرځای کولو فریکونسۍ، د بیا رغونې وخت، او د بدلون ناکامۍ) د پراختیا، ازموینې، او عملیاتي پروسو د اغیزمنتیا تحلیل لپاره مناسب دي.
• پروفایلونه لوړ، منځنۍ، ټیټ. د راټولو شویو معلوماتو پراساس، موږ کولی شو د احصایې له پلوه د لوړ، متوسط ​​​​او ټیټ ګروپونو توپیر وکړو د میټریکونو، کړنو، پروسو او وسایلو له مخې د ځانګړو ځانګړتیاوو سره. د لوړ پروفایل استازي د ټیټ په پرتله غوره پایلې ښیې. دوی ډیر احتمال لري چې خپلو اهدافو ته ورسیږي او ډیر شي.
• شاخصونه، وبا او د 2021 لپاره پلانونه. سږکال یو ځانګړی شاخص دا دی چې شرکتونه څنګه د وبا سره مقابله کوي. لوړ استازو ښه کار وکړ، د کاروونکي ښکیلتیا یې تجربه کړې، او د بریالیتوب اصلي لاملونه اغیزمن پرمختیایي پروسې او قوي انجنیري کلتور و.
• د DevOps کړنې، وسیلې او د دوی پراختیا. د راتلونکي کال لپاره د شرکتونو اصلي پلانونو کې د DevOps کړنو او وسیلو پراختیا ، د DevSecOps طرزالعملونو معرفي کول او په سازماني جوړښت کې بدلونونه شامل دي. او د DevOps کړنو اغیزمن پلي کول او پراختیا د ازمایښتي پروژو په مرسته ترسره کیږي، د ټولنو او د غوره مرکزونو رامینځته کول، د شرکت په لوړو او ټیټو کچو کې نوښتونه.

موږ خوښ یو چې ستاسو نظرونه، کیسې، نظرونه واورو. موږ د هر هغه چا څخه مننه کوو چې په څیړنه کې یې برخه اخیستې او راتلونکی کال ستاسو ګډون ته سترګې په لار یو.

سرچینه: www.habr.com