(د بازار ته وخت).
حتی د اونۍ په پای کې ، هغه د میټریکونو په اړه فکر وکړ: "نو که زه وخت اندازه کړم؟ دا به ماته څه راکړي؟
په حقیقت کې، د وخت پوهه به څه ورکړي؟ راځئ چې ووایو تحویلي 5 ورځې وخت نیسي. نو، راتلونکی څه دی؟ ایا دا ښه یا بد دی؟ حتی که دا خراب وي، نو تاسو باید دا وخت یو څه کم کړئ. خو څنګه؟
دې فکرونو هغه ځوراوه، مګر هیڅ حل یې نه درلود.
ایوان پوه شو چې هغه اصل ته راغلی دی. د میټریکونو بې شمیره ګرافونه چې هغه دمخه لیدلي و ډیر دمخه یې هغه قانع کړی و چې معیاري چلند به کار ونکړي ، او دا چې که هغه په ساده ډول پلان کړي ()، دا به هیڅ ګټه ونلري.
څنګه به وي؟…
یو میټریک د عادي لرګیو حاکم په څیر دی. د هغې په مرسته ترسره شوي اندازه کول به دلیل ونه وايي، ولې هغه شی چې اندازه کیږي دقیقا هغه اوږدوالی دی چې هغې ښودلې. حاکم به په ساده ډول د هغې اندازه وښیې، او نور څه نه. هغه د فیلسوف ډبره نه ده، مګر یوازې د لرګیو تخته ده چې اندازه یې کړي.
د هغه د خوښې لیکوال هیري هریسن "د سټینلیس سټیل موږک" تل ویل: یو فکر باید د مغز پای ته ورسیږي او هلته پروت وي، نو د څو ورځو له زغملو وروسته ، ایوان پریکړه وکړه چې بله دنده په غاړه واخلي ...
یو څو ورځې وروسته ، د آنلاین پلورنځیو په اړه د یوې مقالې لوستلو پرمهال ، ایوان ناڅاپه پوه شو چې د آنلاین پلورنځي ترلاسه کولو پیسو مقدار پدې پورې اړه لري چې د سایټ لیدونکي څنګه چلند کوي. دا دوی دي، لیدونکي / پیرودونکي، چې پلورنځي ته پیسې ورکوي او سرچینه یې ده. د نغدو پیسو لاندینۍ کرښه چې پلورنځي ترلاسه کوي د پیرودونکي چلند کې بدلونونو لخوا اغیزمن کیږي، نه بل څه.
دا معلومه شوه چې د اندازه شوي ارزښت بدلولو لپاره دا اړینه وه چې په هغو کسانو اغیزه وکړي چې دا ارزښت جوړوي، د بیلګې په توګه. د آنلاین پلورنځي د پیسو مقدار بدلولو لپاره ، دا اړینه وه چې د دې پلورنځي پیرودونکو چلند باندې اغیزه وکړي ، او په DevOps کې د تحویل وخت بدلولو لپاره ، دا اړینه وه چې په ټیمونو اغیزه وکړي چې دا ځل "جوړوي" ، د بیلګې په توګه. د دوی په کار کې DevOps وکاروئ.
ایوان پوه شو چې د DevOps میټریکونه باید په هیڅ ډول د ګرافونو لخوا نمایش نه شي. دوی باید د خپل ځان استازیتوب وکړي د لټون وسیله "مستقیم" ټیمونه چې د تحویل وروستي وخت ته شکل ورکوي.
هیڅ میټریک به هیڅکله دا دلیل ونه ښیې چې ولې دې یا دې ټیم د توزیع کولو لپاره ډیر وخت نیولی ، ایوان فکر کاوه ، ځکه چې په حقیقت کې یو ملیون او یو کوچنی کارټ کیدی شي ، او دا ممکن تخنیکي نه وي ، مګر تنظیمي وي. هغوی. ترټولو ډیر چې تاسو یې د میټریکونو څخه تمه کولی شئ د ټیمونو او د دوی پایلې ښودل دي، او بیا تاسو باید دا ټیمونه په خپلو پښو تعقیب کړئ او ومومئ چې د دوی سره څه شی دی.
له بلې خوا، د ایوان شرکت یو معیار درلود چې ټول ټیمونه یې په څو بنچونو کې د غونډو ازموینې ته اړتیا لري. ټیم نشي کولی بل سټینډ ته لاړ شي تر هغه چې مخکینی بشپړ شوی نه وي. دا معلومه شوه چې که موږ د DevOps پروسې د سټینډونو څخه تیریدو د لړۍ په توګه تصور کړو ، نو میټریک کولی شي پدې سټینډونو کې د ټیمونو لخوا مصرف شوي وخت وښیې. د ټیم موقف او وخت په پوهیدو سره، دا ممکنه وه چې د دوی سره په ځانګړې توګه د دلیلونو په اړه خبرې وکړو.
پرته له ځنډه ، ایوان تلیفون پورته کړ او د یو کس شمیره یې ډایل کړه چې د DevOps په داخل او بهر کې ښه پوه دی:
- ډینس، مهرباني وکړئ ما ته ووایاست، ایا دا ممکنه ده چې یو څه پوه شي چې ټیم دا یا هغه موقف تېر کړی؟
- یقینا. زموږ جینکنز بیرغ له مینځه وړي که چیرې ودانۍ په بینچ کې په بریالیتوب سره رول ولوبوي (ازموینه تیره کړي).
- سوپر. بیرغ څه شی دی؟
- دا یو منظم متن فایل دی لکه "stand_OK" یا "stand_FAIL"، کوم چې وایي چې مجلس ازموینه پاس کړې یا ناکامه شوې. ښه، تاسو پوهیږئ، سمه ده؟
- زه فکر کوم، هو. ایا دا په ذخیره کې ورته فولډر ته لیکل شوی چیرې چې مجلس موقعیت لري؟
- هو
- څه پیښیږي که چیرې مجلس د ازموینې بنچ پاس نه کړي؟ ایا زه اړتیا لرم چې یو نوی جوړ کړم؟
- هو
- ښه، ښه، مننه. او بله پوښتنه: ایا زه په سمه توګه پوهیږم چې زه کولی شم د بیرغ د جوړولو نیټه د موقف نیټې په توګه وکاروم؟
- بالکل!
- عالي!
الهام شوی، ایوان ودرېد او پوه شو چې هرڅه په خپل ځای کې راوتلي دي. د جوړونې فایل رامینځته کولو نیټې او د بیرغونو رامینځته کولو نیټې په پوهیدلو سره ، دا ممکنه وه چې دوهم ته محاسبه شي چې ټیمونه په هر سټینډ کې څومره وخت تیروي او پوهیدل چې دوی چیرې ډیر وخت تیروي.
"په دې پوهیدل چې چیرې ډیری وخت تیریږي، موږ به ټیمونه په ګوته کړو، دوی ته لاړ شو او ستونزه به وڅیړو." ایوان وخندل.
د سبا لپاره، هغه ځان ته د سیسټم د جوړښت د انځور کولو دنده ټاکلې.
نور بیا…
سرچینه: www.habr.com