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

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

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

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

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

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

फिनऑप्स कौन है?

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

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

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

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

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

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

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

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

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

तो इस स्थिति में फिनऑप्स क्या करता है:

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

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

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

वैसे, छूट के बारे में

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

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

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

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

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

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

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

नतीजा?

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

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

स्रोत: www.habr.com