توهان ضرور حيران ڪيو آهي ته توهان جي منصوبي جي انفراسٽرڪچر جي قيمت ڪيتري آهي. ساڳئي وقت، اها حيرت انگيز آهي: قيمتن جي واڌ لوڊ جي حوالي سان سڌريل نه آهي. ڪيترائي ڪاروبار مالڪن، سروس اسٽيشنز ۽ ڊولپرز ڳجھي طور تي سمجھندا آھن ته اھي وڌيڪ ادا ڪري رھيا آھن. پر ڇا لاءِ بلڪل؟
عام طور تي، ڪٽڻ جي قيمت صرف سستا حل ڳولڻ لاء هيٺ اچي ٿي، هڪ AWS منصوبو، يا، جسماني ريڪ جي صورت ۾، هارڊويئر جي ترتيب کي بهتر ڪرڻ. نه رڳو ايترو: حقيقت ۾، ڪو به اهو ڪري رهيو آهي، جيئن خدا جي مرضي: جيڪڏهن اسان هڪ شروعات جي باري ۾ ڳالهائي رهيا آهيون، ته اهو شايد هڪ معروف ڊولپر آهي جنهن کي ڪافي سر درد آهي. وڏين آفيسن ۾، اهو معاملو CMO/CTO ذريعي ڪيو ويندو آهي، ۽ ڪڏهن ڪڏهن جنرل ڊائريڪٽر ذاتي طور تي چيف اڪائونٽنٽ سان گڏ ان مسئلي ۾ ملوث ٿيندو آهي. عام طور تي، اهي ماڻهو جيڪي ڪافي "بنيادي" خدشات آهن. ۽ اهو ظاهر ٿئي ٿو ته انفراسٽرڪچر بل وڌي رهيا آهن، پر جن وٽ ان سان معاملو ڪرڻ جو وقت نه آهي ان سان معاملو ڪري رهيا آهن.
جيڪڏهن توهان کي آفيس لاء ٽوائلٽ پيپر خريد ڪرڻ جي ضرورت آهي، اهو سپلائي مئنيجر يا صفائي ڪمپني جي هڪ ذميوار شخص طرفان ڪيو ويندو. جيڪڏهن اسان ترقي بابت ڳالهائي رهيا آهيون - ليڊس ۽ سي ٽي او. وڪرو - سڀڪنھن شيء کي به واضح آهي. پر پراڻن ڏينهن کان وٺي، جڏهن هڪ "سرور روم" هڪ ڪابينا جو نالو هو، جنهن ۾ هڪ عام ٽاور سسٽم هو، جنهن ۾ ٿوري وڌيڪ ريم ۽ ڪجهه هارڊ ڊرائيو سان گڏ، هرڪو (يا گهٽ ۾ گهٽ ڪيترائي) نظر انداز ڪندا هئا. حقيقت اها آهي ته ظرفيت جي خريداري پڻ هڪ خاص تربيت يافته شخص کي هٿ ڪرڻ گهرجي.
افسوس، تاريخي ياداشت ۽ تجربو اهو ظاهر ڪري ٿو ته ڏهاڪن تائين اهو ڪم "بي ترتيب" ماڻهن ڏانهن منتقل ڪيو ويو آهي: جيڪو به ويجھو هو اهو سوال ورتو. ۽ صرف تازو ئي FinOps پيشو مارڪيٽ تي شڪل وٺڻ ۽ ڪجهه ڪنڪريٽ شڪل وٺڻ شروع ڪيو. هي اهو ئي خاص تربيت يافته ماڻهو آهي جنهن جو ڪم ظرفيت جي خريداري ۽ استعمال کي ڪنٽرول ڪرڻ آهي. ۽، آخرڪار، هن علائقي ۾ ڪمپني جي قيمتن کي گهٽائڻ ۾.
اسان مهانگو ۽ اثرائتو حل ڇڏڻ جي صلاح نه ڪري رهيا آهيون: هر ڪاروبار کي پاڻ لاءِ فيصلو ڪرڻ گهرجي ته هارڊويئر ۽ ڪلائوڊ ٽريف جي لحاظ کان آرامده وجود لاءِ ڪهڙي ضرورت آهي. پر ڪو به مدد نه ٿو ڪري سگهي پر حقيقت تي ڌيان ڏئي ٿو ته ڪيترن ئي ڪمپنين لاءِ استعمال جي نگراني ۽ تجزيي کان سواءِ بغير سوچ ويچار جي خريداري “فهرست جي مطابق” آخرڪار انهن جي پسمنظر جي ”اثاثن“ جي غير موثر انتظام جي ڪري تمام گهڻو ، تمام گهڻو نقصان جو نتيجو آهي.
FinOps ڪير آهي
اچو ته چئو ته توهان وٽ هڪ معزز ڪاروبار آهي، جنهن کي وڪرو ڪندڙ ماڻهو "انٽرپرائز" بابت ڳالهائيندا آهن سانس جي سر ۾. شايد، "فهرست جي مطابق" توهان هڪ درجن يا ٻه سرور خريد ڪيو، AWS ۽ ڪجهه ٻيون "ننڍيون شيون". جيڪو منطقي آهي: هڪ وڏي ڪمپني ۾ ڪجهه قسم جي حرڪت مسلسل ٿي رهي آهي - ڪجهه ٽيمون وڌندا آهن، ٻيا ڀڄي ويندا آهن، ٻيا پاڙيسري منصوبن ڏانهن منتقل ڪيا ويا آهن. ۽ انهن تحريڪن جو ميلاپ، "فهرست تي ٻڌل" خريداري واري ميڪانيزم سان گڏ، آخرڪار ايندڙ مهيني انفراسٽرڪچر بل کي ڏسندي، آخرڪار نئين گرين بالن ڏانهن وڌي ٿو.
پوء ڇا ڪجي - صبر سان سرمائي جاري رکو، ان جي مٿان رنگ ڪريو، يا ادائيگي ۾ انهن ڪيترن ئي خوفناڪ صفر جي ظاهر ٿيڻ جا سبب معلوم ڪريو؟
اچو ته ايماندار رهون: ساڳئي AWS ٽريف لاءِ ڪمپني جي اندر هڪ درخواست جي منظوري، منظوري ۽ سڌي ادائگي هميشه (حقيقت ۾، تقريبن ڪڏهن به) جلدي ناهي. ۽ خاص طور تي مسلسل ڪارپوريٽ تحريڪ جي ڪري، انهن مان ڪجهه ساڳيون حاصلات شايد "گم" ٿي سگهن ٿيون. ۽ بيڪار بيهڻ تمام معمولي آهي. جيڪڏهن هڪ محتاط ايڊمنسٽريٽر پنهنجي سرور روم ۾ هڪ مالڪ بيڪار ريڪ کي نوٽيس ڪري ٿو، پوء بادل ٽريف جي صورت ۾ سڀ ڪجهه وڌيڪ اداس آهي. اھي مھينن لاءِ رکي سگھجن ٿيون - ادا ڪرڻ لاءِ، پر ساڳئي وقت ڊپارٽمينٽ ۾ ڪنھن کي به ضرورت نه آھي جنھن لاءِ اھي خريد ڪيا ويا آھن. ساڳئي وقت، ايندڙ آفيس جا ساٿي نه رڳو پنهنجن سرن تي، پر ٻين هنڌن تي پڻ، اڃا تائين ڳاڙهو وار نه ڪڍڻ شروع ڪن ٿا - اهي تقريبا ساڳئي AWS ٽريف جي لاء ادا نه ڪري سگهيا آهن جيڪي 9 هفتي لاء، جيڪي جي سخت ضرورت آهي.
سڀ کان وڌيڪ واضح حل ڇا آهي؟ اھو صحيح آھي، انھن کي ضرورتن جي حوالي ڪريو، ۽ سڀ خوش آھن. پر افقي ڪميونيڪيشن هميشه چڱي طرح قائم نه آهن. ۽ ٻيو ڊپارٽمينٽ شايد پهرين جي دولت جي باري ۾ نه ڄاڻندو هجي، جيڪو ڪنهن به صورت ۾ اهو نڪتو ته واقعي هن دولت جي ضرورت ناهي.
ان جو ذميوار ڪير آهي؟ - حقيقت ۾، ڪو به نه. اهو سڀ ڪجهه هن وقت تائين قائم ڪيو ويو آهي.
هن مان ڪنهن کي تڪليف ٿئي ٿي؟ - اھو اھو آھي، سڄي ڪمپني.
ڪير صورتحال کي درست ڪري سگهي ٿو؟ - ها، ها، FinOps.
FinOps صرف ڊولپرز ۽ سامان جي وچ ۾ هڪ پرت ناهي جنهن کي انهن جي ضرورت آهي، پر هڪ شخص يا ٽيم جيڪو ڄاڻندو ته ڪٿي، ڇا ۽ ڪيترو سٺو "ڪوڙي" آهي ڪمپني طرفان خريد ڪيل ساڳئي بادل ٽريف جي لحاظ کان. حقيقت ۾، انهن ماڻهن کي هڪ طرف DevOps سان گڏ ڪم ڪرڻ گهرجي، ۽ ٻئي طرف فنانس ڊپارٽمينٽ، هڪ مؤثر وچولي جو ڪردار ادا ڪندي ۽، سڀ کان اهم، هڪ تجزيه نگار.
اصلاح جي باري ۾ ٿورو
بادل. نسبتا سستو ۽ تمام آسان. پر اهو حل سستو ٿيڻ بند ٿي ويندو آهي جڏهن سرورن جو تعداد ٻيڻو يا ٽن نمبرن تائين پهچي ويندو آهي. ان کان علاوه، بادل ان کي وڌيڪ ۽ وڌيڪ خدمتون استعمال ڪرڻ ممڪن بڻائين ٿيون جيڪي اڳ ۾ موجود نه هيون: اهي آهن ڊيٽابيس هڪ خدمت جي طور تي (Amazon AWS، Azure Database)، بي سرور ايپليڪيشنون (AWS Lambda، Azure Functions) ۽ ٻيا ڪيترائي. اهي تمام سٺا آهن ڇو ته اهي استعمال ڪرڻ آسان آهن - خريد ڪريو ۽ وڃو، ڪو مسئلو ناهي. پر ڪمپني ۽ ان جا منصوبا اوترو اونڌو ڪڪر ۾ ٻڏي ويندا، سي ايف او جي ننڊ به خراب ٿيندي. ۽ تيزيءَ سان جنرل گرين ٿي ويندو آهي.
حقيقت اها آهي ته مختلف ڪلائوڊ سروسز لاءِ انوائسز هميشه انتهائي پريشان ڪندڙ آهن: هڪ شئي لاءِ توهان کي ملي سگهي ٿو ٽن صفحن جي وضاحت ته توهان جو پئسو ڇا، ڪٿي ۽ ڪيئن ويو. اهو، يقينا، خوشگوار آهي، پر ان کي سمجهڻ لڳ ڀڳ ناممڪن آهي. ان کان علاوه، هن مسئلي تي اسان جي راء صرف هڪ کان پري آهي: بادل اڪائونٽن کي انسانن ڏانهن منتقل ڪرڻ لاء، مثال طور، مڪمل خدمتون آهن. يا . جيڪڏهن ڪو ماڻهو بلن کي سمجهڻ لاءِ هڪ الڳ سروس ٺاهڻ جي زحمت ڪري ٿو، ته پوءِ مسئلي جي ماپ بال رنگ جي قيمت کي وڌائي ڇڏيو آهي.
تنهن ڪري هن صورتحال ۾ FinOps ڇا ڪندو:
- واضح طور تي سمجھي ٿو ته ڪھڙي مقدار ۾ بادل حل خريد ڪيا ويا.
- ڄاڻي ٿو ته اهي صلاحيتون ڪيئن استعمال ٿين ٿيون.
- هڪ خاص يونٽ جي ضرورتن جي بنياد تي انهن کي ٻيهر ورهائي ٿو.
- خريد نه ڪندو آهي "ته جيئن اهو ٿي سگهي".
- ۽ آخر ۾، اهو توهان کي پئسا بچائيندو.
هڪ بهترين مثال هڪ ڊيٽابيس جي ٿڌي ڪاپي جي ڪلائوڊ اسٽوريج آهي. مثال طور، ڇا توهان ان کي محفوظ ڪيو ٿا ته جيئن اسٽوريج کي اپڊيٽ ڪرڻ وقت استعمال ٿيندڙ جاءِ ۽ ٽريفڪ جو مقدار گھٽجي؟ ها، اهو لڳي ٿو ته صورتحال سستي آهي - هڪ واحد مخصوص صورت ۾، پر اهڙين سستي حالتن جي مجموعي جو نتيجو بعد ۾ ڪلائوڊ سروسز لاءِ بيحد خرچن ۾.
يا ٻي صورتحال: توهان AWS يا Azure تي رزرو گنجائش خريد ڪيو ته جيئن چوٽي جي لوڊ هيٺ نه اچي. ڇا توهان پڪ ڪري سگهو ٿا ته اهو بهترين حل آهي؟ آخرڪار، جيڪڏهن اهي مثال بيڪار آهن 80٪، پوء توهان صرف پئسا ڏئي رهيا آهيو Amazon کي. ان کان علاوه، اهڙين ڪيسن لاء، ساڳيا AWS ۽ Azure ۾ burstable مثال آهن - توهان کي بيڪار سرور جي ضرورت ڇو آهي، جيڪڏهن توهان چوٽي لوڊ جي مسئلن کي حل ڪرڻ لاء هڪ اوزار استعمال ڪري سگهو ٿا؟ يا، پريميس مثالن جي بدران، توهان کي ڏسڻ گهرجي محفوظ ڪيل - اهي تمام سستا آهن ۽ اهي پڻ پيش ڪن ٿا رعايا.
رستي ۾، discounts جي باري ۾
جيئن ته اسان شروع ۾ چيو آهي، خريداري اڪثر ڪري هر ڪنهن جي طرفان ڪيو ويندو آهي - انهن کي آخري مليو، ۽ پوء هو ڪنهن به طرح اهو پاڻ ڪندو آهي. گهڻو ڪري، جيڪي ماڻهو اڳ ۾ ئي مصروف آهن "انتهائي" بڻجي ويا آهن، ۽ نتيجي ۾ اسان کي هڪ صورتحال ملي ٿي جتي هڪ شخص جلدي ۽ مهارت سان، پر مڪمل طور تي آزاديء سان، فيصلو ڪري ٿو ته ڇا ۽ ڪهڙي مقدار ۾ خريد ڪيو وڃي.
پر جڏهن ڪلائوڊ سروس مان وڪرو ڪندڙ سان رابطو ڪريو، توهان وڌيڪ سازگار حالتون حاصل ڪري سگهو ٿا جڏهن اها گنجائش جي هول سيل خريداري جي اچي ٿي. اهو واضح آهي ته توهان خاموش ۽ هڪ طرفي رجسٽريشن سان ڪار مان اهڙي رعايتون حاصل ڪرڻ جي قابل نه هوندا - پر هڪ حقيقي سيلز مينيجر سان ڳالهائڻ کان پوء، توهان کي ساڙيو ويندو. يا اهي ماڻهو توهان کي ٻڌائي سگهن ٿا ته انهن وٽ هن وقت ڪهڙي رعايت آهي. اهو پڻ مفيد ٿي سگهي ٿو.
ساڳئي وقت، توهان کي ياد رکڻ جي ضرورت آهي ته روشني AWS يا Azure تي پچر وانگر نه ٺهڪي اچي. يقينن، توهان جي پنهنجي سرور روم کي منظم ڪرڻ جو ڪو سوال ناهي - پر انهن ٻن کلاسک حلن جا متبادل آهن جنن کان.
مثال طور، گوگل ڪمپنين لاءِ فائر بيس پليٽ فارم کڻي آيو، جنهن تي اهي هڪ ئي موبائيل پروجيڪٽ کي ٽرنڪي بنياد تي ميزباني ڪري سگهن ٿا، جنهن لاءِ تيز رفتار اسڪيلنگ جي ضرورت ٿي سگھي ٿي. اسٽوريج، حقيقي وقت ڊيٽابيس، هوسٽنگ ۽ ڪلائوڊ ڊيٽا هم وقت سازي هن حل کي استعمال ڪندي مثال طور هڪ جڳهه تي موجود آهن.
ٻئي طرف، جيڪڏهن اسان هڪ واحد منصوبي بابت نه ڳالهايو آهي، پر انهن جي مجموعي بابت، پوء هڪ مرڪزي حل هميشه فائدي وارو ناهي. جيڪڏهن پروجيڪٽ ڊگھي رهي ٿي، ان جي پنهنجي ترقي جي تاريخ آهي ۽ اسٽوريج لاء گهربل ڊيٽا جي ساڳئي رقم آهي، پوء اهو وڌيڪ ٽڪڙي واري جڳهه جي باري ۾ سوچڻ جي قابل آهي.
جڏهن ڪلائوڊ سروسز لاءِ قيمتن کي بهتر بڻائي رهيا آهيو، توهان اوچتو محسوس ڪري سگهو ٿا ته ڪاروباري-نازڪ ايپليڪيشنن لاءِ توهان خريد ڪري سگهو ٿا وڌيڪ طاقتور محصول جيڪي ڪمپني کي اڻ رڪاوٽ آمدني فراهم ڪندا. ساڳئي وقت، قيمتي بادل ۾ ترقي جي "وراثت"، پراڻي آرڪائيوز، ڊيٽابيس، وغيره کي محفوظ ڪرڻ هڪ حل آهي. سڀ کان پوء، اهڙي ڊيٽا لاء، هڪ معياري ڊيٽا سينٽر باقاعده HDDs ۽ وچولي-پاور هارڊويئر سان بغير ڪنهن گھنٽي ۽ سيٽن جي بلڪل مناسب آهي.
هتي ٻيهر، توهان سوچيو ته "هي ڦوٽو ان جي قابل ناهي،" پر هن اشاعت جو سڄو مسئلو ان حقيقت تي ٻڌل آهي ته مختلف مرحلن تي ذميوار ماڻهون ننڍن شين کي نظرانداز ڪن ٿا ۽ جيڪي وڌيڪ آسان ۽ تيز آهن. جنهن جي نتيجي ۾، ڪجهه سالن کان پوء، انهن انتهائي خوفناڪ اڪائونٽن ۾ نتيجو آهي.
آخر ۾ ڇا ٿيو؟
عام طور تي، بادل ٿڌو آهن، اهي ڪنهن به سائيز جي ڪاروبار لاء تمام گهڻا مسئلا حل ڪن ٿا. بهرحال، هن رجحان جي نئين هجڻ جو مطلب اهو آهي ته اسان وٽ اڃا تائين استعمال ۽ انتظام جي ثقافت نه آهي. FinOps ھڪڙو تنظيمي ليور آھي جيڪو توھان جي مدد ڪري ٿو بادل جي طاقت کي وڌيڪ اثرائتي طريقي سان. بنيادي شيء هن پوزيشن کي فائرنگ اسڪواڊ جي هڪ اينالاگ ۾ تبديل ڪرڻ نه آهي، جنهن جو ڪم هٿ سان اڻڄاتل ڊولپرز کي پڪڙڻ ۽ انهن کي ختم ڪرڻ لاء "ڊپڻ" هوندو.
ڊولپرز کي ترقي ڪرڻ گهرجي، ڪمپني جي رقم کي ڳڻڻ نه گهرجي. ۽ تنهن ڪري FinOps ٻنهي کي خريد ڪرڻ جي عمل ۽ ٻين ٽيمن کي ڪلائوڊ جي صلاحيت کي ختم ڪرڻ يا منتقل ڪرڻ جي عمل کي سڀني پارٽين لاءِ هڪ آسان ۽ خوشگوار واقعو بڻائڻ گهرجي.
جو ذريعو: www.habr.com