आप बुनियादी ढांचे पर कितना खर्च करते हैं? और इस पर कैसे बचा जाए?

निश्चित रूप से, आप सोच रहे थे कि आपकी परियोजना के बुनियादी ढांचे की लागत कितनी है। इसी समय, यह आश्चर्यजनक है: खर्चों की वृद्धि भार के सापेक्ष रैखिक नहीं है। कई व्यवसाय के मालिक, सर्विस स्टेशन और डेवलपर्स को स्पष्ट रूप से समझ में आता है कि वे ओवरपे करते हैं। लेकिन वास्तव में क्या?

आमतौर पर, लागत में कमी केवल सबसे सस्ता समाधान खोजने के लिए नीचे आती है, एडब्ल्यूएस टैरिफ, या, अगर हम भौतिक स्टैंड के बारे में बात कर रहे हैं, तो उपकरण के कॉन्फ़िगरेशन को अनुकूलित करना। केवल इतना ही नहीं: वास्तव में, कोई भी ऐसा करता है, जैसा कि ईश्वर आत्मा में डालता है: यदि हम किसी स्टार्टअप के बारे में बात कर रहे हैं, तो यह संभवतया अग्रणी डेवलपर है, जिसके पास पर्याप्त बंटिंग है। बड़े कार्यालयों में, सीएमओ / सीटीओ इससे संबंधित हैं; कई बार, सीईओ मुख्य लेखाकार के साथ व्यक्तिगत रूप से हस्तक्षेप करते हैं। सामान्य तौर पर, वे लोग जिनके पास पर्याप्त "प्रोफ़ाइल" चिंता है। और यह पता चला है कि बुनियादी ढांचे के बिल बढ़ रहे हैं, लेकिन वे इसका पता लगाते हैं ... जिनके पास इससे निपटने का समय नहीं है।

यदि आपको कार्यालय में टॉयलेट पेपर खरीदने की आवश्यकता है, तो आपूर्ति प्रबंधक या सफाई कंपनी का एक जिम्मेदार व्यक्ति ऐसा करेगा। अगर हम विकास - लीड और सीटीओ के बारे में बात कर रहे हैं। बिक्री - सब कुछ भी स्पष्ट है। लेकिन दाढ़ी वाले समय से भी, जब "सर्वर" को कैबिनेट कहा जाता था, जिसमें थोड़ी अधिक रैम के साथ एक साधारण टॉवर-सिस्टम था और छापे में कुछ हद तक, सभी (या कम से कम कई) इस तथ्य की अनदेखी करते हैं कि इसे क्षमता की खरीद से निपटना चाहिए। एक विशेष रूप से प्रशिक्षित व्यक्ति भी।

काश, ऐतिहासिक स्मृति और अनुभव से संकेत मिलता है कि इस कार्य को दशकों से "यादृच्छिक" लोगों के लिए स्थानांतरित कर दिया गया था: जो कोई भी निकटतम था वह सवाल उठाया गया था। और हाल ही में FinOps पेशे ने आकार लेना और बाजार पर कुछ विशिष्ट रूपरेखाओं को लेना शुरू किया। यह बहुत ही विशेष रूप से प्रशिक्षित व्यक्ति है जिसका कार्य क्षमताओं की खरीद और उपयोग को नियंत्रित करना है। और, अंततः, इस क्षेत्र में कंपनी की लागत को कम करने में।

हम महंगे और प्रभावी समाधानों को छोड़ने के लिए अभियान नहीं करते हैं: प्रत्येक व्यवसाय को खुद तय करना चाहिए कि उसे लोहे और क्लाउड टैरिफ के मामले में एक आरामदायक अस्तित्व के लिए क्या चाहिए। लेकिन कोई भी इस तथ्य पर ध्यान नहीं दे सकता है कि विचारशील खरीद "एक सूची में" बाद की निगरानी के बिना और कई कंपनियों के लिए उपयोग के विश्लेषण के परिणामस्वरूप, इसके बैकेंड की "परिसंपत्तियों" के अक्षम प्रबंधन के कारण बहुत, बहुत अधिक नुकसान होता है।

फिनओप्स कौन है

मान लें कि आपके पास एक ठोस उद्यम है, जिसके बारे में विक्रेताओं का कहना है कि "उद्यम"। संभवतः, "सूची में" आपने एक दर्जन या दो सर्वर, AWS और कुछ और "छोटी चीजों पर" खरीदा। जो तार्किक है: एक बड़ी कंपनी में, किसी प्रकार का आंदोलन होता है - कुछ टीमें बढ़ती हैं, अन्य टूट जाती हैं, और अन्य पड़ोसी परियोजनाओं में स्थानांतरित हो जाती हैं। और "सूची-आधारित" खरीद तंत्र के संयोजन में इन आंदोलनों का संयोजन अंततः अगले मासिक बुनियादी ढांचे के बिल को देखने के दौरान नए भूरे बालों की ओर जाता है।

तो क्या करें - धैर्यपूर्वक आगे बढ़ें, भुगतान में इन कई भयानक शून्य की उपस्थिति के कारणों का पता लगाएं या पेंट करें?

यह छिपाने के लिए एक पाप है: एक ही AWS टैरिफ के लिए कंपनी के भीतर एक आवेदन के अनुमोदन, अनुमोदन और प्रत्यक्ष भुगतान हमेशा एक वास्तविकता नहीं है (लगभग कभी नहीं)। और लगातार कॉरपोरेट आंदोलन के कारण, इनमें से कुछ अधिग्रहण कहीं खो गए हैं। और बस बेकार खड़े रहो। यदि एक चौकस प्रशासक अपने सर्वर रूम में एक मालिक रहित रैक को नोटिस करता है, तो क्लाउड टैरिफ के मामले में, सब कुछ बहुत दुखी है। वे महीनों तक एक मज़ाक पर खड़े रह सकते हैं - भुगतान किया जाता है, लेकिन साथ ही साथ विभाग में किसी को भी ज़रूरत नहीं है जिसके तहत उन्हें अधिग्रहण किया गया था। उसी समय, अगले कार्यालय के सहयोगियों ने अभी तक न केवल अपने सिर पर, बल्कि अन्य स्थानों पर - अपने भूरे बालों को फाड़ने के लिए शुरू नहीं किया है, वे एक ही एडब्ल्यूएस टैरिफ के बारे में उसी सप्ताह के लिए भुगतान नहीं कर पाए हैं, जिसकी सख्त जरूरत है।

सबसे स्पष्ट समाधान क्या है? यह सही है, जरूरतमंद लोगों को बागडोर सौंपें, और हर कोई खुश है। हां, केवल क्षैतिज संचार हमेशा अच्छी तरह से स्थापित नहीं होते हैं। और दूसरा विभाग केवल पहले के धन के बारे में नहीं जान सकता है, जिसके लिए यह बहुत धन किसी भी तरह से विशेष रूप से आवश्यक नहीं था।

किसे दोष देना है? - आम तौर पर कोई नहीं कहता। अब तक, अब तक, सब कुछ व्यवस्थित है।
इससे कौन पीड़ित है? - यही है, पूरी कंपनी।
स्थिति को कौन ठीक कर सकता है? - हाँ, हाँ, FinOps।

FinOps केवल डेवलपर्स और उनके लिए आवश्यक उपकरणों के बीच की एक परत नहीं है, बल्कि एक व्यक्ति या टीम जो यह जानती है कि कंपनी द्वारा खरीदे गए समान क्लाउड टैरिफ के संदर्भ में कहां, क्या, और कितनी अच्छी तरह से "झूठ" है। वास्तव में, इन लोगों को एक ओर DevOps के साथ एक ही टीम में काम करना चाहिए, और दूसरी तरफ वित्त विभाग, एक प्रभावी मध्यस्थ की भूमिका निभा रहा है और, सबसे महत्वपूर्ण, विश्लेषिकी।

अनुकूलन के बारे में थोड़ा सा

बादल। अपेक्षाकृत सस्ते और बहुत सुविधाजनक। लेकिन यह समाधान तब सस्ता पड़ता है जब सर्वर की संख्या दो अंकों या तीन अंकों की हो जाती है। इसके अलावा, बादल अधिक से अधिक सेवाओं का उपयोग करना संभव बनाते हैं जो पहले अनुपलब्ध थे: ये एक सेवा (अमेज़ॅन एडब्ल्यूएस, एज़्योर डेटाबेस), सर्वर रहित एप्लिकेशन (एडब्ल्यूएस लैंबडा, एज़्योर फ़ंक्शंस) और कई अन्य के रूप में डेटाबेस हैं। वे सभी बहुत शांत हैं कि वे उपयोग करने में आसान हैं - खरीदा और चलाई, कोई समस्या नहीं। यही कारण है कि कंपनी और इसकी परियोजनाओं को बादलों में डुबकी लगाने के दौरान सीएफओ की नींद खराब होती है। और तेजी से सामान्य ग्रे हो जाता है।

तथ्य यह है कि विभिन्न क्लाउड सेवाओं के लिए खाते हमेशा बेहद भ्रामक होते हैं: आप एक पद के लिए तीन-पृष्ठ डिक्रिप्शन प्राप्त कर सकते हैं कि आपके पैसे कहां, कैसे और कैसे गए। यह, ज़ाहिर है, अच्छा है, लेकिन यह समझना लगभग असंभव है। इसके अलावा, इस मुद्दे पर हमारी राय केवल एक से बहुत दूर है: मानव को क्लाउड खातों को स्थानांतरित करने के लिए, पूरी सेवाएं हैं, उदाहरण के लिए www.cloudyn.com या www.cloudability.com । अगर किसी को डिक्रिप्टिंग खातों के लिए एक अलग सेवा बनाकर भ्रमित किया गया था, तो समस्या के पैमाने ने हेयर डाई की लागत को बढ़ा दिया।

तो FinOps इस स्थिति में क्या करता है:

• स्पष्ट रूप से समझता है कि कब और किन संस्करणों में क्लाउड समाधान खरीदे गए थे।
• जानते हैं कि इन शक्तियों का उपयोग कैसे किया जाता है।
• एक विशेष इकाई की आवश्यकताओं के आधार पर, उनका पुनर्वितरण करता है।
• खरीद नहीं करता है "जो था।"
• और अंत में, यह आपको पैसे बचाता है।

एक महान उदाहरण एक डेटाबेस की कोल्ड कॉपी का क्लाउड स्टोरेज है। उदाहरण के लिए, क्या आप संग्रहण को अद्यतन करते समय खपत की गई जगह और यातायात की मात्रा को कम करने के लिए इसे संग्रहीत करते हैं? हां, ऐसा लगता है कि स्थिति सस्ती है - एक विशिष्ट मामले में, लेकिन ऐसी सस्ती स्थितियों की समग्रता तब क्लाउड सेवाओं के लिए अत्यधिक लागत में तब्दील हो जाती है।

या दूसरी स्थिति: आपने AWS या Azure पर एक आरक्षित शक्ति खरीदी, ताकि चरम भार के नीचे न आ सकें। क्या आप सुनिश्चित हो सकते हैं कि यह सबसे अच्छा समाधान है? आखिरकार, अगर ये उदाहरण 80% बेकार हैं, तो आप सिर्फ अमेज़ॅन को पैसा देते हैं। इसके अलावा, ऐसे मामलों के लिए, एक ही एडब्ल्यूएस और एज़्योर में फटने योग्य उदाहरण हैं - अगर आपको चोटी के भार की समस्याओं को हल करने के लिए उपकरण का उपयोग कर सकते हैं तो आपको मुफ्त धूम्रपान सर्वर की आवश्यकता क्यों है? या ऑन प्रिमाइस उदाहरणों के बजाय, आपको आरक्षित की दिशा में देखना चाहिए - वे बहुत सस्ते हैं और उन पर छूट प्रदान करते हैं।

छूट की बात कर रहे हैं

जैसा कि हमने शुरुआत में कहा था, कोई भी अक्सर खरीद में लगा रहता है - उन्होंने अंतिम एक पाया, और फिर किसी तरह वह खुद। सबसे अधिक बार, जो लोग पहले से ही व्यस्त हैं, वे "चरम" हो जाते हैं, और अंत में हमें एक ऐसी स्थिति मिलती है जब कोई व्यक्ति जल्दी और कुशलता से, लेकिन पूरी तरह से स्वतंत्र रूप से निर्णय लेता है कि क्या और कितनी मात्रा में खरीदना है।

लेकिन क्लाउड सेवा की तरफ से विक्रेता के साथ बातचीत करते समय, आप क्षमता के थोक खरीद की बात आने पर अधिक अनुकूल परिस्थितियां प्राप्त कर सकते हैं। यह स्पष्ट है कि मूक और एक तरफा पंजीकरण वाली कार से इस तरह की छूट प्राप्त करने से काम नहीं चलेगा - लेकिन वास्तविक बिक्री प्रबंधक के साथ बात करने के बाद, यह जल सकता है। या ये लोग बता सकते हैं कि उनके पास अभी के लिए क्या छूट है। भी उपयोगी है।

उसी समय, आपको यह याद रखने की आवश्यकता है कि AWS या Azure पर प्रकाश अभिसरण नहीं हुआ था। बेशक, अपने स्वयं के सर्वर रूम को व्यवस्थित करने की कोई बात नहीं है - लेकिन दिग्गजों से इन दो क्लासिक समाधानों के विकल्प भी हैं।

उदाहरण के लिए, Google कंपनियों के लिए फायरबेस प्लेटफॉर्म लाया, जिस पर टर्नकी आधार पर उसी मोबाइल प्रोजेक्ट को रखना संभव है, जिसे तेजी से स्केलिंग की आवश्यकता हो सकती है। इस समाधान के उदाहरण का उपयोग करके संग्रहण, रीयल-टाइम डेटाबेस, होस्टिंग और क्लाउड डेटा सिंक्रोनाइज़ेशन एक ही स्थान पर उपलब्ध हैं।

दूसरी ओर, यदि हम एक अखंड परियोजना के बारे में बात नहीं कर रहे हैं, लेकिन उनके संयोजन के बारे में, तो एक केंद्रीकृत समाधान हमेशा फायदेमंद नहीं होता है। यदि परियोजना लंबे समय से जीवित है, तो इसका अपना विकास इतिहास है और भंडारण के लिए आवश्यक डेटा की समान मात्रा है, तो यह अधिक खंडित प्लेसमेंट के बारे में सोचने योग्य है।

क्लाउड सेवाओं की लागतों का अनुकूलन करते समय, आपको अचानक महसूस हो सकता है कि व्यावसायिक-महत्वपूर्ण अनुप्रयोगों के लिए, आप अधिक शक्तिशाली टैरिफ खरीद सकते हैं जो कंपनी के लिए निर्बाध आय सुनिश्चित करेगा। इसी समय, विकास की "विरासत", पुराने अभिलेखागार, डेटाबेस इत्यादि को महंगे बादलों में संग्रहित किया जाना अपने आप में एक समाधान है। वास्तव में, इस तरह के डेटा के लिए, बिना किसी "लोशन" के साधारण एचडीडी और मध्यम-शक्ति हार्डवेयर के साथ एक मानक डेटा केंद्र काफी उपयुक्त है।

यहां फिर से, आप सोच सकते हैं कि "यह उपद्रव इसके लायक नहीं है," लेकिन इस प्रकाशन का पूरा मुद्दा इस तथ्य पर आधारित है कि विभिन्न चरणों में जिम्मेदार लोग trifles पर हथौड़ा मारते हैं और यथासंभव सुविधाजनक और तेज करते हैं। जो, अंत में, एक दो साल में उन्हीं डरावने खातों में बदल जाता है।

परिणाम क्या है?

सामान्य तौर पर, बादल शांत होते हैं, वे किसी भी आकार के व्यवसाय के लिए बहुत सारी समस्याओं का समाधान करते हैं। हालांकि, इस घटना की नवीनता इस तथ्य की ओर ले जाती है कि हमारे पास अभी भी उपभोग और प्रबंधन की संस्कृति नहीं है। फिनऑप्स एक संगठनात्मक उत्तोलन है जो आपको अपनी क्लाउड पावर का अधिक कुशलता से लाभ उठाने में मदद करता है। मुख्य बात यह नहीं है कि इस पोस्ट को फायरिंग दस्ते के एक एनालॉग में बदल दिया जाए, जिसका काम हाथ से असंगत डेवलपर्स को पकड़ना होगा और उन्हें डाउनटाइम के लिए "डांटना" होगा।

डेवलपर्स को विकास करना चाहिए, न कि कंपनी के पैसे को गिनना चाहिए। तो FinOps दोनों खरीद प्रक्रिया और decommissioning या अन्य टीमों के लिए एक घटना सरल और सुखद करने के लिए अन्य टीमों के लिए क्लाउड क्षमता स्थानांतरित करने की प्रक्रिया करना चाहिए।