تاسو په زیربنا څومره مصرف کوئ؟ او تاسو څنګه کولی شئ پدې کې پیسې خوندي کړئ؟

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

عموما، د لګښتونو کمول په ساده ډول د ارزانه حل موندلو لپاره راځي، د AWS پلان، یا د فزیکي ریکونو په صورت کې، د هارډویر ترتیب اصلاح کول. نه یوازې دا: په حقیقت کې ، هرڅوک دا کار کوي ، لکه څنګه چې خدای خوښوي: که موږ د پیل کولو په اړه وغږیږو ، نو دا شاید یو مخکښ جوړونکی وي چې ډیر سر درد لري. په لویو دفترونو کې، دا د CMO/CTO لخوا معامله کیږي، او ځینې وختونه عمومي رییس په شخصي توګه د لوی محاسب سره یوځای په مسله کې ښکیل کیږي. په عموم کې، هغه خلک چې کافي "اصلي" اندیښنې لري. او دا معلومه شوه چې د زیربناوو بیلونه مخ په ډیریدو دي، مګر هغه څوک چې د دې سره معامله کولو وخت نلري ورسره معامله کوي.

که تاسو د دفتر لپاره د تشناب کاغذ پیرودلو ته اړتیا لرئ، دا به د اکمالاتو مدیر یا د پاکولو شرکت مسؤل کس لخوا ترسره شي. که موږ د پراختیا په اړه خبرې کوو - لیډز او CTO. خرڅلاو - هر څه هم روښانه دي. مګر د پخوانیو ورځو راهیسې ، کله چې د "سرور خونه" د کابینې نوم و چې په کې د یو څه ډیر رام او یو څو هارډ ډرایو سره یو عادي برج سیسټم شتون درلود ، هرڅوک (یا لږترلږه ډیری) له پامه غورځول شوي. حقیقت دا دی چې د ظرفیت پیرود باید د یو ځانګړي روزل شوي کس لخوا اداره شي.

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

موږ د ګران او مؤثره حلونو د پریښودلو پلوی نه یو: هره سوداګرۍ باید د ځان لپاره پریکړه وکړي چې د هارډویر او کلاوډ تعرفو شرایطو کې د آرامۍ شتون لپاره څه ته اړتیا لري. مګر یو څوک نشي کولی مرسته وکړي مګر دې حقیقت ته پام وکړي چې د ډیری شرکتونو لپاره د تعقیب نظارت او تحلیل پرته د "لست سره سم" بې فکره پیرود په نهایت کې د دوی د شاته د "اثاثو" غیر مؤثر مدیریت له امله خورا خورا خورا لوی زیانونه پایله کوي.

FinOps څوک دی

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

نو څه باید وکړو - په صبر سره خړ ته دوام ورکړئ ، په هغې باندې رنګ کړئ ، یا په تادیه کې د دې ډیری خطرناکو صفرونو څرګندیدو لاملونه ومومئ؟

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

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

د دې لپاره څوک ملامت دي؟ - په حقیقت کې، هیڅوک نه. دا هر څه د اوس لپاره تنظیم شوي دي.
څوک له دې څخه رنځ وړي؟ - دا دی، ټول شرکت.
څوک کولی شي وضعیت سم کړي؟ - هو، هو، FinOps.

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

د اصلاح کولو په اړه لږ څه

ورېځې. نسبتا ارزانه او خورا اسانه. مګر دا حل د ارزانه کیدو مخه نیسي کله چې د سرورونو شمیر دوه یا درې چنده ته ورسیږي. برسېره پردې، بادل دا ممکنه کوي چې د ډیرو خدماتو کارول چې مخکې شتون نلري: دا د خدماتو په توګه ډیټابیسونه دي (Amazon AWS، Azure ډیټابیس)، بې سرور غوښتنلیکونه (AWS Lambda، Azure Functions) او ډیری نور. دا ټول خورا ښه دي ځکه چې دوی کارول اسانه دي - پیرود او لاړ شئ، هیڅ ستونزه نشته. مګر هرڅومره ژوره چې شرکت او د هغې پروژې په بادونو کې ډوبیږي ، د CFO ډیر بد خوب کوي. او په چټکۍ سره جنرال خړ کیږي.

حقیقت دا دی چې د مختلف کلاوډ خدماتو لپاره رسیدونه تل خورا مغشوش دي: د یو توکي لپاره تاسو ممکن د دریو مخونو توضیح ترلاسه کړئ چې ستاسو پیسې څه ، چیرې او څنګه لاړې. دا، البته، خوندور دی، مګر د دې پوهیدل تقریبا ناممکن دي. سربیره پردې ، پدې مسله کې زموږ نظر یوازې له یو څخه لرې دی: انسانانو ته د بادل حسابونو لیږدولو لپاره ، د مثال په توګه ټول خدمات شتون لري www.cloudyn.com او یا www.cloudability.com. که یو څوک د بیلونو د تشریح کولو لپاره د جلا خدمت رامینځته کولو زحمت وکړي ، نو د ستونزې پیمانه د ویښتو رنګ لګښت ډیر کړی.

نو FinOps پدې حالت کې څه کوي:

• په روښانه توګه پوهیږي کله او په کوم مقدار کې د بادل حلونه پیرودل شوي.
• پوهیږي چې دا ظرفیتونه څنګه کارول کیږي.
• د یو ځانګړي واحد اړتیاو پراساس دوی بیا توزیع کوي.
• نه اخلي "تر څو دا وي".
• او په پای کې، دا ستاسو پیسې خوندي کوي.

یو ښه مثال د ډیټابیس د سړې کاپي بادل ذخیره ده. د مثال په توګه، ایا تاسو د ذخیره کولو تازه کولو په وخت کې د مصرف شوي ځای او ترافیک مقدار کمولو لپاره آرشیف کوئ؟ هو، دا به داسې بریښي چې وضعیت ارزانه دی - په یوه ځانګړي قضیه کې، مګر د داسې ارزانه حالتونو مجموعه وروسته د بادل خدماتو لپاره خورا لګښتونو پایله لري.

یا بل حالت: تاسو په AWS یا Azure کې د ریزرو ظرفیت پیرود کړی ترڅو د لوړ بار لاندې نه راشي. ایا تاسو ډاډه یاست چې دا غوره حل دی؟ په هرصورت، که دا مثالونه 80٪ بې کاره وي، نو تاسو په ساده ډول ایمیزون ته پیسې ورکوئ. سربیره پردې ، د ورته قضیو لپاره ، ورته AWS او Azure د سوځیدو وړ مثالونه لري - تاسو ولې بې کاره سرورونو ته اړتیا لرئ ، که تاسو د لوړ بارونو ستونزې حل کولو لپاره وسیله وکاروئ؟ یا ، د پریمیس مثالونو پرځای ، تاسو باید ریزرو ته وګورئ - دا خورا ارزانه دي او دوی تخفیف هم وړاندیز کوي.

په لاره کې، د تخفیف په اړه

لکه څنګه چې موږ په پیل کې وویل، تدارکات اکثرا د هر چا لخوا ترسره کیږي - دوی وروستی وموندل، او بیا هغه پخپله دا کار کوي. ډیری وختونه، هغه خلک چې دمخه بوخت دي "انتها" کیږي، او د پایلې په توګه موږ داسې وضعیت ترلاسه کوو چیرې چې یو شخص په چټکۍ او مهارت سره، مګر په بشپړه توګه په خپلواکه توګه پریکړه کوي چې څه او په کوم مقدار کې پیرود وکړي.

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

په ورته وخت کې، تاسو باید په یاد ولرئ چې رڼا د AWS یا Azure په څیر د ویج په څیر نه بدلیږي. البته، ستاسو د خپل سرور خونې تنظیم کولو کومه پوښتنه شتون نلري - مګر د جنات څخه د دې دوه کلاسیک حلونو لپاره بدیلونه شتون لري.

د مثال په توګه، ګوګل شرکتونو ته د Firebase پلیټ فارم راوړی، په کوم کې چې دوی کولی شي د ورته ګرځنده پروژه کوربه توب وکړي، کوم چې ممکن ګړندي اندازه کولو ته اړتیا ولري. ذخیره کول، د ریښتیني وخت ډیټابیس، کوربه کول او د کلاوډ ډیټا همغږي کول د مثال په توګه د دې حل په کارولو سره په یو ځای کې شتون لري.

له بلې خوا، که موږ د یوې واحدې پروژې په اړه خبرې نه کوو، مګر د دوی د بشپړتیا په اړه، نو یو مرکزي حل تل ګټور نه دی. که پروژه اوږدمهاله وي، خپل پراختیایي تاریخ لري او د ذخیره کولو لپاره اړین ډیټا اندازه لري، نو دا د نورو ټوټې ځای پرځای کولو په اړه فکر کولو ارزښت لري.

کله چې د کلاوډ خدماتو لپاره لګښتونه اصلاح کول، تاسو ممکن ناڅاپه پوه شئ چې د سوداګرۍ - مهم غوښتنلیکونو لپاره تاسو کولی شئ ډیر پیاوړي تعرفې واخلئ چې شرکت ته به بې بنسټه عاید چمتو کړي. په ورته وخت کې ، په ګران بادل کې د پراختیا "میراث" ذخیره کول ، زاړه آرشیفونه ، ډیټابیسونه او نور یو حل دی. په هرصورت، د داسې معلوماتو لپاره، د منظم HDDs او د منځني بریښنا هارډویر سره یو معیاري ډیټا مرکز پرته له کوم زنګونو او ویسلونو څخه مناسب دی.

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

په پای کې څه شی دی؟

په عموم کې ، ورېځې یخې دي ، دوی د هرې اندازې سوداګرۍ لپاره ډیری ستونزې حل کوي. په هرصورت، د دې پدیدې نوي کیدل پدې معنی دي چې موږ لاهم د مصرف او مدیریت کلتور نه لرو. FinOps یو تنظیمي لیور دی چې تاسو سره مرسته کوي د بادل ځواک ډیر مؤثره ګټه پورته کړئ. اصلي شی دا نه دی چې دا موقعیت د ډزو سکواډ انلاګ ته واړوي، چې دنده به یې د لاس په واسطه د بې پروایۍ پراختیا کونکي ونیسي او د وخت لپاره یې "ډار" کړي.

پراختیا کونکي باید وده وکړي، نه د شرکت پیسې حسابوي. او له همدې امله FinOps باید د پیرود پروسه او نورو ټیمونو ته د کلاوډ ظرفیت له مینځه وړلو یا لیږدولو پروسه دواړه د ټولو اړخونو لپاره یوه پیښه ساده او خوندور کړي.

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