ما پدې وروستیو کې په DevOpsForum 2019 کې ګډون وکړ، چې د Logrocon لخوا کوربه شوی. په دې کنفرانس کې، ګډونوالو هڅه وکړه چې د سوداګرۍ او پراختیا او د معلوماتي ټکنالوجۍ خدماتو متخصصینو ترمنځ د اغیزمن تعامل لپاره حلونه او نوي وسایل ومومي.
کنفرانس یو بریالیتوب و: واقعیا ډیر ګټور راپورونه، په زړه پورې پریزنټشن فارمیټونه او د ویناوالو سره ډیرې اړیکې وې. او دا په ځانګړي توګه مهم دي چې هیڅوک هڅه نه کوي چې ما څه وپلوري، هغه څه چې په لویو کنفرانسونو کې وینا کونکي پدې وروستیو کې مجرم شوي.
د Raiffeisenbank، Alfastrakhovanie، د اتوماتیک پلي کولو په برخه کې د منګو مخابراتي تجربې او د کټ لاندې نور توضیحاتو څخه یوه اقتباس.
زما نوم یانا دی، زه د ټیسټر په توګه کار کوم، زه اتومات کاروم، او همدارنګه DevOps، او زه کنفرانسونو او غونډو ته تلل خوښوم. په تیرو دوو کلونو کې، زه د اولیګ بنین کنفرانسونو ته تللی یم (HighLoad++، TeamLead Conf)، د جگ پیښو (Heisenbug، JPoint)، TestCon مسکو، DevOps Pro مسکو، لوی ډیټا مسکو.
تر ټولو لومړی، زه د کنفرانس پروګرام ته پاملرنه کوم. زه لږ ګورم چې راپور به د څه په اړه وي ، او ډیر په سپیکر کې. حتی که راپور خورا تخنیکي او په زړه پوري وګرځي ، دا حقیقت ندی چې تاسو به وکولی شئ په خپل شرکت کې د راپور څخه ځینې غوره عملونه پلي کړئ. او بیا تاسو سپیکر ته اړتیا لرئ.
په Raiffeisenbank کې د پایپ لاین په پای کې رڼا
معمولا ، زه په څنګ کې د وینا کونکو لټون کوم چې زما سره علاقه لري. په DevOpsForum 2019 کې، د Raiffeisenbank څخه سپیکر، میخایل بیزان، زما دلچسپي ونیوله. د خپلې وینا په جریان کې ، هغه پدې اړه خبرې وکړې چې څنګه دوی په تدریجي ډول خپل ټیمونه په DevOps کې ښکیلوي ، ولې دوی ورته اړتیا لري ، او څنګه سوداګرۍ ته د DevOps بدلون نظر وپلوري. ښه، په عموم کې، ما د پایپ لاین په پای کې د رڼا لیدلو څرنګوالي په اړه خبرې وکړې.
میخایل بیزان، د رایفیسینبینک د اتوماتیک رییس
اوس دوی په خپل شرکت کې "DevOps" نلري. دا دی، هغه کار کوي، مګر په ټولو ټیمونو کې نه. کله چې د DevOps پلي کول ، دوی د ټیمونو چمتووالي باندې تکیه کوي ، دواړه د ځانګړي انجینرانو په شرایطو کې ، او د محصول اړتیا او د هغه پلیټ فارم د پختۍ په شرایطو کې چې دا محصول رامینځته شوی. میشا وویل چې څنګه سوداګرۍ ته تشریح کړي چې ولې DevOps ته اړتیا ده.
د بانکدارۍ برخه د ودې ډیری چلوونکي لري: د خدماتو لګښت او د پیرودونکي اساس پراخول. د خدماتو لګښت ډیرول خورا ښه چلونکی ندی، مګر د پیرودونکي اساس وده کول برعکس دي. که سیالي کونکي په معقول ډول ښه محصول خپور کړي، ټول پیرودونکي هلته ځي، بیا د وخت په تیریدو سره د بازار کچه راټیټه کیږي. له همدې امله، بازار ته د نوي محصولاتو معرفي کول او د دوی د معرفي کولو سرعت هغه اصلي شی دی چې بانکونه یې تمرکز کوي. دا په حقیقت کې هغه څه دي چې د DevOps لپاره دي، او سوداګرۍ پدې پوهیږي.
بل مهم یادونه: DevOps تل بازار ته وخت نه کموي. DevOps نشي کولی یوازې کار وکړي ، دا یوازې د محصول رامینځته کولو او بازار ته د پراختیا څخه تولید ته راوړلو پروسې برخه ده (له کوډ څخه پیرودونکي ته). مګر د کوډ څخه مخکې هرڅه په مستقیم ډول د DevOps سره تړاو نلري. دا دی ، بازار موندونکي کولی شي د کلونو لپاره بازار مطالعه کړي او خپل ټول ژوند د سیالانو په نیولو کې تیر کړي. دا اړینه ده چې ژر تر ژره پوه شئ چې پیرودونکي څه ته اړتیا لري او د دې یا دې ځانګړتیا پلي کول پلان کړي - ډیری وختونه دا هغه څه دي چې د DevOps کار کولو لپاره کافي ندي او شرکت خپل هدف ترلاسه کولو لپاره. له همدې امله، لومړی، Raiffeisenbank د سوداګرۍ سره موافقه وکړه چې دا اړینه وه چې د DevOps کارولو څرنګوالی زده کړي. د اتوماتیک کولو لپاره به د نوي پیرودونکو لپاره مبارزه کې ډیره مرسته ونکړي.
په عموم کې، میشا باور لري چې DevOps باید پلي شي، مګر په هوښیارۍ سره. او موږ باید د دې حقیقت لپاره چمتو اوسو چې د بدلون په پیل کې به د ټیم تولید راټیټ شي، دا به لږې پیسې وګټي، مګر بیا به توجیه شي.
په منګو ټیلیکام کې د ازموینې اتومات کول
زما لپاره یو بل په زړه پوری راپور د ټیسټر په توګه د منګو ټیلی کام څخه ایګور مسلوف لخوا ورکړل شوی و. پریزنټشن ته "د SCRUM ټیم کې د بشپړ ازموینې دورې اتومات" نوم ورکړل شوی و. ایګور باور لري چې DevOps په ځانګړي ډول د SCRUM لپاره رامینځته شوی ، مګر په ورته وخت کې ، د SCRUM ټیم ته د DevOps معرفي کول خورا ستونزمن دي. دا پیښیږي ځکه چې د SCRUM ټیم تل په کوم ځای کې روان وي، هیڅ وخت شتون نلري چې د نوښتونو له امله مغشوش شي او د پروسې بیا رغونه وکړي. ستونزه په حقیقت کې هم شتون لري چې SCRUM په ټیم کې د فرعي ټیمونو جلا کول شامل نه دي (د ازموینې ټیم، پراختیایی ټیم، او داسې نور). ښه، سربیره پردې، د موجوده پروسې اتومات کولو لپاره، اسنادو ته اړتیا ده، او په SCRUM کې، ډیری وختونه په بشپړ ډول هیڅ اسناد شتون نلري - "محصول د یو ډول لیکلو څخه ډیر مهم دی."
SCRUM ته د بدلولو وروسته، ازموینو د پراختیا کونکو سره مشوره پیل کړه چې څنګه د ځانګړتیاوو ازموینه وکړي. په تدریج سره، د فعالیت حجم زیات شو، هیڅ اسناد شتون نلري، او دوی په فعالیت کې ډیری بګونه نیول پیل کړل چې د ازموینو لخوا پوښل شوي ندي او په عموم کې دا روښانه نده چې چا دا ازموینه کړې او کله. په لنډه توګه - ګډوډي او خلا. موږ پریکړه وکړه چې د ازموینې اتوماتیک ته لاړ شو. خو بیا هم په بشپړه توګه ناکامه وه. دوی د آوټ سورس اتومات متخصصین استخدام کړل چې د کور دننه ازموینو ته نامعلومه سټیک باندې لیکلي. د آټوټسټس لپاره چوکاټ کار وکړ، البته، مګر وروسته له دې چې بهرنیان پریښودل، دا دوه اونۍ دوام وکړ. بله یوه هڅه وه چې د اتوماتیک ازموینې دوهم نمبر معرفي کړي. دا د دې حقیقت سره پیل شو چې هرڅه باید د شرکت دننه جوړ شي، په خپله (سمه ویکتور: د داخلي مهارتونو رامینځته کول)، د SCRUM په چوکاټ کې، او په پروسه کې اسناد جوړ کړئ. د اتومات کولو سټیک باید د محصول سټیک سره مساوي وي (دلته زه یې اضافه کوم ، ستاسو د جاواسکریپټ پروژه د بل څه سره مه ازموئ). د سپرینټ په پای کې، دوی یو ډیمو ترسره کړ چې څنګه آټوټیسټ د ټول ټیم سره کار کوي (مرسته کوونکی). پدې توګه ، د اتومات کولو پروسې کې د ټیم ټولو غړو ښکیلتیا زیاته شوې ، په بیله بیا په آټوټیسټونو باور او دا چانس چې دا آټوټیسټ به خامخا وکارول شي (او د دوامداره ناکامیو له امله به په یوه میاشت کې تبصره ونه کړي).
په هرصورت، په DevOpsForum 2019 کې یو خلاص مایکروفون و - یو اوږد پیژندل شوی او زما په نظر، د وینا ګټور بڼه. تاسو همداسې ګرځئ، راپورونه واورئ او بیا پریکړه وکړئ چې په کنفرانس کې د یوې ټاکلې موضوع یا ستونزې په اړه بحث کول ارزښت لري، د ستونزې د حل لپاره اړونده تجربه شریکه کړئ.
ما دا هم ولیدل چې تنظیم کونکو د لنډو راپورونو لړۍ جوړه کړه. هر راپور له 10 دقیقو څخه زیات دوام نه کوي، وروسته پوښتنې. پدې توګه تاسو کولی شئ په یوځل کې ډیری موضوعات پوښښ کړئ او له وینا کونکو څخه پوښتنې وکړئ چې تاسو سره علاقه لري.
د پریزنټشنونو په مینځ کې ، زه د کنفرانس شریکانو بوټو شاوخوا ګرځم او ډیری توکي یې غلا / وګټل. اوه، زه لاسوند خوښوم!
ګردي میز او DevOps مسلې په الفاسټرخواني کې د پراختیا رییس سره
زما لپاره د DevOpsForum 2019 کیک کې یخ کول د DevOps متخصصینو سره د یو ساعت اوږده ناسته وه. د غونډې څلور ګډونوال د مختلفو زاویو څخه DevOps ته د کتلو لپاره رابلل شوي وو: انتون ایزانین (الفاسترخوانی، پراختیایی رییس)، نایلیا زماشکینا (فینټیک لابراتوار، عملیاتي رییس)، اولیګ ایګورکین (روستیلیک، ایجیل کوچ) او انتون مارتیانوف (خپلواک کارپوه، DevOps ته کتل. د سوداګرۍ له نظره).
متخصصین خلکو ته نږدې ناست وو او بیا شیان پیل شول: د ټول ساعت لپاره، د اوریدونکو څخه ګډونوالو خپلې پوښتنې وکړې، او متخصصینو ریپ واخیست. ځینې وختونه ریښتینې مناظرې وې. پوښتنې خورا متفاوت وې ، د مثال په توګه: ایا د DevOps انجینرانو ته اړتیا ده ، ولې دوی نشي کولی د سیسټم مدیرانو په توګه وروزل شي ، باید DevOps هرچا ته وړاندیز شي ، د دې ارزښت څه دی ، او داسې نور.
بیا، ما په شخصي توګه د انتون اسانین سره خبرې وکړې. موږ هر کور ته د DevOps کلتور راوړلو اړتیا باندې بحث وکړ او د DevOps بدلون تیاره اړخ یې په ګوته کړ.
راځئ چې تصور وکړو چې هرڅوک یوځای شول او پریکړه یې وکړه چې DevOps دواړه د محصول او سوداګرۍ او ټیم لخوا اړین دي. راځئ چې پلي کړو. هرڅه سم شول. موږ تنفس وکړ. DevOps موږ پیرودونکي ته نږدې کړي، اوس موږ کولی شو ژر تر ژره د هغه ټولې هیلې پوره کړو. د پایلې په توګه، موږ د سختو مقرراتو او اړتیاو سره لوی عملیاتي څانګه لرو، او دا په دوامداره توګه په محصول کې نیمګړتیاوې لټوي او د غوښتنو یوه ډله جوړوي. سربیره پردې، ټولې نیمګړتیاوې د "عاجل" حالت ټاکل شوي، حتی که چیرې پیرودونکي په ناڅاپي ډول غوښتل د شنه پرځای ژیړ تڼۍ رنګ کړي. پروژه وده کوي، د خپرونو شمیر مخ په ډیریدو دی او په وینا، د پیرودونکو لخوا د نوي فعالیت نیمګړتیاوو او غلط فهمونو شمیر. Ops د راپور ورکولو نیمګړتیاو سره د ساتلو لپاره 10 نور کسان استخدام کوي، او پراختیا 15 نور کسان استخداموي ترڅو د دوی تړلو ته دوام ورکړي. او د نوي ب featuresو معرفي کولو پرځای ، ټیم د نه ختمیدونکي SDs سره کار کوي ، کارونکي ته فعالیت تشریح کوي او په ورته وخت کې ملاتړ کوي. د پایلې په توګه، دواړه Ops او پراختیا په سوداګرۍ کې دي، مګر پیرودونکي او سوداګرۍ ناخوښه دي: نوې ځانګړتیاوې په ټپه ولاړې دي. دا معلومه شوه چې DevOps شتون لري، مګر داسې ښکاري چې شتون نلري.
د DevOps پلي کولو اړتیا په اړه، انتون په واضح ډول وویل چې دا په مستقیم ډول د سوداګرۍ کچې پورې اړه لري. که په کال کې د یو پیرودونکي خدمت کول شرکت ته یو ملیارد راوړي ، نو DevOps ته اړتیا نشته (په دې شرط چې تاسو اړتیا نلرئ پدې پیرودونکي کې په منظم ډول نوي بدلونونه رامینځته کړئ). هرڅه په چاکلیټ پوښل شوي. مګر که سوداګرۍ وده وکړي او ډیر پیرودونکي څرګند شي ، نو تاسو اړتیا لرئ اطاعت وکړئ. د یوې قاعدې په توګه، په پیل کې په شرکت کې هیڅ ښه عملیات شتون نلري. لومړی موږ محصول پرې کوو، او یوازې بیا موږ پوهیږو چې د محصول د کار کولو لپاره، موږ اړتیا لرو چې په سرورونو او اکمالاتو څارنه وکړو. دا هغه وخت دی چې Ops منځ ته راځي. دا باید پوه شي چې Ops، د یوې جلا څانګې په توګه، به د پراختیا په وړاندې د خنډونو یوه ډله پیل کړي او ټولې تحویلۍ به په ټپه ودریږي. دا ، پدې حالت کې ، د DevOps کلتور لا دمخه اړوند دی ، مګر موږ باید د هغې تیاره اړخ هیر نکړو.
سرچینه: www.habr.com