په ریښتیا، ایوان اکثرا د څارنې څانګې څخه د خپلو همکارانو په ناکامه هڅو وخندل. دوی د میټریکونو پلي کولو لپاره ډیرې هڅې وکړې چې د شرکت مدیریت دوی ته امر کړی ترڅو ترلاسه کړي. دوی دومره بوخت وو چې دوی نه غوښتل بل څوک څه وکړي.
مګر دا د مدیریت لپاره کافي نه و - دوی په دوامداره توګه ډیر او نوي میټریکونه امر کړل، په چټکۍ سره د هغه څه کارولو مخه نیسي چې مخکې ترسره شوي.
په دې وروستیو کې، هرڅوک د لیډ ټایم په اړه خبرې کوي - د سوداګرۍ ځانګړتیاوو وړاندې کولو وخت. میټریک یو لیونی شمیره ښودلې - 200 ورځې د یوې دندې ترسره کولو لپاره. هرچا څنګه اوښکې تویې کړې او لاسونه یې آسمان ته پورته کړل!
یو څه وخت وروسته، شور په تدریج سره مړ شو او مدیریت د بل میټریک جوړولو امر ترلاسه کړ.
ایوان ته دا په بشپړه توګه روښانه وه چې نوی میټریک به په تیاره کونج کې په خاموشۍ سره مړ شي.
په حقیقت کې، ایوان فکر وکړ، د شمیر په پوهیدو سره هیڅوک هیڅ شی نه وایي. 200 ورځې یا 2 ورځې - هیڅ توپیر نلري، ځکه چې دا ناشونې ده چې د شمیر له مخې دلیل وټاکي او پوه شي چې دا ښه یا بد دی.
دا د میټریکونو یو عام جال دی: داسې بریښي چې یو نوی میټریک به د وجود جوهر بیان کړي او یو څه پټ رازونه تشریح کړي. هر څوک د دې لپاره ډیرې هیلې لري، مګر د ځینو دلیلونو لپاره هیڅ نه کیږي. هو، ځکه چې راز باید په میټریکونو کې ونه موندل شي!
د ایوان لپاره، دا یو تیریدونکی مرحله وه. هغه په دې پوه شو د اندازه کولو لپاره، او ټول رازونه باید په لټه کې شي , i.e. دا چې دا میټریک جوړ شوی دی.
د آنلاین پلورنځي لپاره ، د نفوذ هدف به د دې پیرودونکي وي چې پیسې راوړي ، او د DevOps لپاره ، دا به هغه ټیمونه وي چې د پایپ لاین په کارولو سره توزیع رامینځته او تنظیموي.
یوه ورځ، په تالار کې په آرامۍ څوکۍ ناست، ایوان پریکړه وکړه چې په دقت سره فکر وکړي چې څنګه غواړي د DevOps میټریکونه وګوري، دا حقیقت په پام کې نیولو سره چې د نفوذ هدف ټیمونه دي.
د DevOps میټریک هدف
دا روښانه ده چې هرڅوک غواړي د تحویل وخت کم کړي. 200 ورځې، البته، هیڅ ښه نه دي.
مګر څنګه، دا پوښتنه ده؟
شرکت په سلګونو ټیمونه ګماري، او هره ورځ زرګونه توزیع د DevOps پایپ لاین له لارې تیریږي. د تحویلۍ اصلي وخت به د توزیع په توګه څرګند شي. هر ټیم به خپل وخت او خپل ځانګړتیاوې ولري. تاسو څنګه د دې ګډوډۍ په مینځ کې څه موندلی شئ؟
ځواب په طبیعي ډول راپورته شو - موږ اړتیا لرو چې د ستونزې ټیمونه ومومئ او معلومه کړو چې د دوی سره څه تیریږي او ولې دا ډیر وخت نیسي ، او د "ښه" ټیمونو څخه زده کړئ چې څنګه هرڅه په چټکۍ سره ترسره کړئ. او د دې کولو لپاره، تاسو اړتیا لرئ هغه وخت اندازه کړئ چې د ټیمونو لخوا په هر DevOps سټینډونو کې مصرف شوي:
"د سیسټم هدف به د ټیمونو ټاکل د هغه وخت پراساس وي چې دوی سټینډونه تیریږي ، د بیلګې په توګه. د پایلې په توګه، موږ باید د ټاکل شوي وخت سره د امرونو لیست ترلاسه کړو، نه شمیره.
که موږ معلومه کړو چې په سټینډ کې په مجموع کې څومره وخت تیر شوی او د سټینډونو ترمینځ په ځنډ کې څومره وخت تیر شوی ، موږ کولی شو ټیمونه ومومئ ، دوی ته زنګ ووهئ او لاملونه یې په تفصیل سره پوه کړئ او له مینځه یې یوسو ، "ایوان فکر وکړ.
د DevOps لپاره د تحویلي وخت محاسبه کولو څرنګوالی
د دې محاسبه کولو لپاره ، دا اړینه وه چې د DevOps پروسې او د هغې جوهر ته لاړشئ.
شرکت یو محدود شمیر سیسټمونه کاروي، او معلومات یوازې له دوی څخه ترلاسه کیدی شي او بل چیرې نه.
په شرکت کې ټولې دندې په جیرا کې ثبت شوي. کله چې یو کار په لاره واچول شو، د هغې لپاره یوه څانګه جوړه شوه، او د پلي کولو وروسته، د BitBucket او Pull Request ته ژمن شو. کله چې د PR (Pull Request) ومنل شو، یو توزیع په اوتومات ډول رامینځته شوی او د Nexus ذخیره کې زیرمه شوی.
بیا ، توزیع د جینکنز په کارولو سره په څو سټینډونو کې د رول آوټ ، اتوماتیک او لارښود ازموینې سموالي چیک کولو لپاره راپورته شوې:
ایوان تشریح کړه چې له کوم سیسټمونو څخه کوم معلومات اخیستل کیدی شي په سټینډ کې د وخت محاسبه کولو لپاره:
- د Nexus څخه - د توزیع کولو وخت او د فولډر نوم چې د کمانډ کوډ لري
- د جینکنز څخه - د پیل وخت، دوره او د هرې دندې پایله، د موقف نوم (د دندې په پیرامیټونو کې)، مرحلې (د کار مرحلې)، په Nexus کې د ویش سره اړیکه.
- ایوان پریکړه وکړه چې جیرا او بټ بکټ په پایپ لاین کې شامل نه کړي، ځکه چې ... دوی د پراختیایي مرحلې سره ډیر تړاو درلود، او په سټینډونو کې د بشپړ شوي توزیع رول نه کول.
د شته معلوماتو پر بنسټ، لاندې انځور شوی دی:
پدې پوهیدل چې د توزیع رامینځته کولو لپاره څومره وخت نیسي او په هر یو کې څومره وخت مصرف کیږي ، تاسو کولی شئ په اسانۍ سره د ټول DevOps پایپ لاین (بشپړ دوره) له لارې د تګ ټول لګښتونه محاسبه کړئ.
دلته د DevOps میټریکونه دي چې ایوان یې پای ته رسیدلی:
- د جوړ شوي توزیع شمیر
- د توزیع برخه چې سټینډ ته "راغلي" او سټینډ ته "تېر شوي".
- په سټینډ کې مصرف شوی وخت (د سټینډ سائیکل)
- بشپړ دوره (د ټولو سټینډونو لپاره ټول وخت)
- د کار موده
- د سټینډونو ترمینځ د ځنډ وخت
- په ورته موقف کې د کار پیل کولو ترمنځ د ځنډ وخت
له یوې خوا، میټریک د وخت په شرایطو کې د DevOps پایپ لاین خورا ښه مشخص کړی، له بلې خوا، دوی خورا ساده ګڼل شوي.
د ښه ترسره شوي کار څخه راضي، ایوان یو پریزنټشن جوړ کړ او مدیریت ته یې د وړاندې کولو لپاره لاړ.
هغه په خندا سره بیرته راغی او لاسونه یې ښکته کړل.
"دا یوه ناکامه ده، وروره،" ستومانه همکار وخندل ...
په مقاله کې نور ولولئ "".
سرچینه: www.habr.com