स्केल पर वेबसाइट रखरखाव: इसकी मासिक लागत क्या है

"स्केल पर वेबसाइट रखरखाव" वास्तव में क्या शामिल है

स्केल पर वेबसाइट रखरखाव एक कार्य नहीं है। यह एक ढेर है जो काम का दोहराव है जो साइट की संख्या बढ़ने, ट्रैफ़िक बढ़ने और रिलीज़ चक्रों के छोटे होने के साथ बढ़ता है। 12 पृष्ठों और एक मासिक अपडेट के साथ एक एकल ब्रोशर साइट एक बात है। 8 ब्रांडों, 3 CMSs, और साप्ताहिक रिलीज़ के पोर्टफोलियो का होना एक और बात है।

मासिक बिल आमतौर पर कोड परिवर्तनों, सामग्री सुधारों, QA, सुरक्षा पैच, तैनाती जांच, और उन संपादकों के लिए समर्थन से शुरू होता है जो हर दिन प्रकाशित करते हैं। एक टीम एक सप्ताह में एक टूटे हुए फॉर्म पर 6 घंटे और अगले सप्ताह रिलीज़ मान्यता पर 40 घंटे बिता सकती है। यह उतार-चढ़ाव महत्वपूर्ण है।

स्केल पर, रखरखाव में समन्वय भी शामिल है। एक साझा घटक में एक परिवर्तन 5 पृष्ठों, 2 वातावरणों, और 1 एनालिटिक्स टैग प्रबंधक को प्रभावित कर सकता है। यदि साइट एक से जुड़ी है कॉर्पोरेट वेबसाइटशाखाओं, भाषाओं, या व्यावसायिक इकाइयों के साथ संरचना, काम तेजी से बढ़ता है। कोई नाटक नहीं। बस अधिक चलने वाले हिस्से।

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

मासिक रखरखाव की लागत बढ़ाने वाले लागत बकेट

सबसे बड़े मासिक बकेट आमतौर पर इंजीनियरिंग घंटे, QA, सुरक्षा, सामग्री संचालन, बुनियादी ढांचा, और विक्रेता समर्थन होते हैं। ये अमूर्त लाइन आइटम नहीं हैं। ये चालान, वेतन, और खोए हुए समय के रूप में प्रकट होते हैं जब एक रिलीज 2 दिन पीछे हो जाती है।

इंजीनियरिंग घंटे बग फिक्स, फीचर ट्वीक, टेम्पलेट कार्य, और आपातकालीन परिवर्तनों को कवर करते हैं। QA पुनरावृत्ति परीक्षण, ब्राउज़र जांच, मोबाइल जांच, और उस उबाऊ लेकिन महंगे कार्य को कवर करता है जिसमें यह पुष्टि करना शामिल है कि एक "छोटी" परिवर्तन ने चेकआउट या खोज को नहीं तोड़ा। यहाँ उबाऊ होना अच्छा है।

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

सामग्री संचालन से अधिक जोड़ता है जितना लोग उम्मीद करते हैं। संपादक छवि स्वैप, उत्पाद विवरण, लैंडिंग पृष्ठ अपडेट, और टूटे लिंक की सफाई चाहते हैं। एक साइट जिसमें महीने में 20 नए लेख होते हैं, उसे बनाए रखने में अधिक लागत आएगी बनिस्बत एक ऐसी साइट के जो 2 प्रकाशित करती है। गणित स्पष्ट है।

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

एक बड़े साइट और कई साइट रखरखाव के बीच का अंतर

एक बड़ा साइट और कई छोटे साइट्स की लागत समान नहीं होती। एक 1-साइट स्टैक सरल हो सकता है यदि सब कुछ एक कोडबेस, एक सामग्री मॉडल, और एक डिप्लॉयमेंट पथ साझा करता है। एक 12-साइट पोर्टफोलियो कठिन हो सकता है, भले ही प्रत्येक साइट छोटी हो, क्योंकि हर अपडेट के पास 12 बार गलत होने का मौका होता है।

यहां एक पाठक 'एक वेबसाइट के लिए कितना' पूछना बंद करता है और 'एक पोर्टफोलियो, मार्केटप्लेस, या मल्टी-ब्रांड स्टैक के लिए कितना' पूछना शुरू करता है। उत्तर इस पर निर्भर करता है कि कितना साझा किया गया है। एक लॉगिन सिस्टम 10 प्रॉपर्टीज़ की सेवा कर सकता है। एक टूटी हुई साझा मॉड्यूल सभी 10 को प्रभावित कर सकती है।

कई साइटों का रखरखाव संस्करण भिन्नता जोड़ता है। साइट A CMS संस्करण 9.2 पर अपडेट होती है, साइट B 8.7 पर रहती है, और साइट C एक प्लगइन पर निर्भर करती है जो केवल 8.7 के साथ काम करता है। फिर हर पैच एक संगतता समस्या बन जाती है। कैलेंडर भर जाता है।

एक बड़ा साइट अभी भी महंगा हो सकता है यदि इसमें 100 टेम्पलेट्स, 6 स्थानीयताएँ, और बार-बार सामग्री परिवर्तन होते हैं। साइट की संख्या पूरी कहानी नहीं है। एक स्केलेबल सूचना और मनोरंजन पोर्टल यह दिखाता है कि स्केल अक्सर कई सेक्शनों में दोहराए गए रखरखाव पैटर्न का मतलब होता है, न कि केवल एक बड़े होमपेज का। एक रिलीज का मतलब 15 जुड़े हुए घटक हो सकता है।

कई साइटों का रखरखाव भी डुप्लिकेट काम पैदा करता है। यदि 4 साइटों को एक ही फुटर परिवर्तन की आवश्यकता है, तो लागत 4 सरल संपादनों की नहीं है। यह 4 QA चक्र, 4 तैनाती जांच, और 4 टूटे लिंक के लिए अवसर हैं। यहीं पर मासिक लागत चुपचाप बढ़ती है।

कौन सी टीमें आमतौर पर रखरखाव की लागत वहन करती हैं

व्यवहार में, रखरखाव की लागत विभिन्न टीमों के साथ होती है, जो संगठन की संरचना पर निर्भर करती है। आंतरिक कर्मचारी CMS और फ्रंट एंड के मालिक हो सकते हैं। एक एजेंसी मासिक रिटेनर का मालिक हो सकती है। फ्रीलांसर स्पेशलिस्ट नौकरियों जैसे गति सुधार, माइग्रेशन कार्य, या टेम्पलेट मरम्मत को संभाल सकते हैं। प्लेटफ़ॉर्म मालिक होस्टिंग और कोर समर्थन ले जा सकते हैं।

आंतरिक टीम अक्सर वेतन समय में भुगतान करती है, भले ही कोई चालान हाथों में न हो। एक उत्पाद प्रबंधक प्राथमिकता निर्धारण में 5 घंटे बिता सकता है। एक डिज़ाइनर पृष्ठ ड्रिफ्ट को ठीक करने में 3 घंटे बिता सकता है। एक डेवलपर एक असफल तैनाती के कारण एक दिन खो सकता है। यही लागत है।

एजेंसी रिटेनर आमतौर पर हर महीने एक निश्चित संख्या में घंटों को बंडल करते हैं, साथ ही आउट-ऑफ-स्कोप कार्य के लिए ऐड-ऑन। फ्रीलांसर कागज पर सस्ते लग सकते हैं, जब तक कि साइट को 1 सप्ताह में 4 विशेषज्ञों की आवश्यकता न हो। तब बजट गड़बड़ हो जाता है। बहुत तेजी से।

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

एक उपयोगी प्रश्न सरल है: चालान कौन प्राप्त करता है, और श्रम कौन अवशोषित करता है? कई कंपनियों में, उत्तर एक ही व्यक्ति नहीं होता। यह अंतर बताता है कि पहले तिमाही की समीक्षा तक बजट क्यों कम दिखते हैं।

जटिलता स्तर के अनुसार रखरखाव की लागत, साइट के आकार के अनुसार नहीं

आकार अकेले भ्रामक हो सकता है। एक 40-पृष्ठ का ब्रोशर साइट जिसमें एक CMS और तिमाही संपादन होते हैं, बनाए रखने के लिए सस्ता हो सकता है। एक 15-पृष्ठ का कस्टम ऐप जिसमें साप्ताहिक डिप्लॉयमेंट होते हैं, अधिक महंगा हो सकता है। जटिलता लागत को पृष्ठ संख्या से बेहतर तरीके से प्रभावित करती है।

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

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

एक कस्टम ऐप जिसमें बार-बार डिप्लॉयमेंट होते हैं, कई टीमों के लिए सबसे अधिक रखरखाव की आवश्यकता वाला प्रकार है। प्रत्येक रिलीज़ को परीक्षण, रोलबैक योजना, त्रुटि ट्रैकिंग और निर्भरता समीक्षा की आवश्यकता होती है। यदि महीने में 12 डिप्लॉयमेंट होते हैं, तो यहां तक कि 45-मिनट का QA चरण भी महत्वपूर्ण हो जाता है। समय जमा होता है।

इस बारे में सोचने का एक व्यावहारिक तरीका यह है: एक साइट जो महीने में 2 बार बदलती है, उसे एक ऐसी साइट से अलग तरीके से बनाए रखा जाता है जो सप्ताह में 20 बार बदलती है। पहली धीमी लय में जीवित रह सकती है। दूसरी को रिलीज़ चक्र में रखरखाव प्रक्रिया की आवश्यकता होती है।

छिपे हुए मासिक खर्च जो आसानी से छूट सकते हैं

कुछ लागतें तब तक अदृश्य रहती हैं जब तक वे विफल नहीं होतीं। घटना प्रतिक्रिया समय उनमें से एक है। एक टूटी हुई चेकआउट, एक मृत फॉर्म, या एक लॉगिन समस्या 3 लोगों को 2 घंटे के लिए नियोजित काम से हटा सकती है। वह समय वास्तविक है, भले ही कोई इसे स्प्रेडशीट में दर्ज न करे।

प्लगइन रखरखाव एक और चुप्पा खर्च है। एक साइट 18 प्लगइनों पर चल सकती है, और उनमें से 2 को मासिक ध्यान की आवश्यकता होती है क्योंकि निर्भरता में बदलाव या सुरक्षा मुद्दे होते हैं। रखरखाव टीम एक प्लगइन को ठीक करने में 1 घंटा बिताती है, फिर यह सुनिश्चित करने के लिए 2 और घंटे लगाती है कि कुछ और टूट न जाए। छोटी समस्या, बड़ा बिल।

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

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

बैकलॉग सफाई सबसे चुप्पा खर्च है। एक टीम एक तिमाही के लिए 25 “छोटी” सुधारों को टाल सकती है, फिर यह पता चलता है कि अब प्रत्येक एक बड़े रिलीज को रोकता है। मासिक रखरखाव बजट सफाई में खा जाता है बजाय सुधार के। यह एक सामान्य जाल है।

खरीद के लिए मासिक रखरखाव बजट का अनुमान कैसे लगाएं

खरीद के लिए एक संख्या की आवश्यकता होती है, भावना नहीं। एक मासिक दायरा पत्र से शुरू करें जो साइट की संख्या, रिलीज़ आवृत्ति, CMS या ऐप प्रकार, समर्थन घंटे, और शामिल लोगों की संख्या को सूचीबद्ध करता है। यदि विक्रेता कहता है “यह निर्भर करता है,” तो पूछें कि यह किस पर निर्भर करता है। फिर से पूछें।

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

एक सरल खरीद मॉडल 4 प्रश्नों से बनाया जा सकता है। पहले, कितने उत्पादन स्थल दायरे में हैं? दूसरे, हर महीने कितने अपडेट होते हैं? तीसरे, कौन से सिस्टम साइट से जुड़े हैं? चौथे, जब कुछ टूटता है तो कितनी प्रतिक्रिया समय की आवश्यकता होती है? ये उत्तर आमतौर पर बजट रेंज का बचाव करने के लिए पर्याप्त होते हैं।

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

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

जब फिर से डिज़ाइन या पुनर्निर्माण करना रखरखाव करने से सस्ता हो

किसी बिंदु पर, मासिक रखरखाव रखरखाव बनना बंद कर देता है और मरम्मत में बदल जाता है। यदि एक साइट को समान टेम्पलेट्स के लिए बार-बार सुधार की आवश्यकता होती है, तो आर्किटेक्चर कार्यभार के लिए बहुत पुराना हो सकता है। 6 महीनों में समान घटक के 3 पुनर्लेखन एक चेतावनी संकेत है।

जब रखरखाव के घंटे बढ़ते रहते हैं जबकि व्यावसायिक उत्पादन स्थिर रहता है, तो पुन: डिज़ाइन या पुनर्निर्माण सस्ता हो सकता है। यदि 4 डेवलपर्स अपने महीने का आधा समय पैचिंग में बिताते हैं, तो संगठन घर्षण को बनाए रखने के लिए भुगतान कर रहा है। यह शायद ही कभी एक अच्छा दीर्घकालिक सौदा होता है।

विरासत CMS सेटअप अक्सर पहले इस बिंदु पर पहुंचते हैं। एक साइट जो कभी 1 भाषा और 10 सामग्री प्रकारों को संभालती थी, अब 5 भाषाओं, 3 उत्पाद लाइनों, और 2 अनुमोदन कार्यप्रवाहों का समर्थन कर सकती है। पुरानी संरचना झुकती है, फिर टूटती है। रखरखाव एक श्रृंखला में अपवादों में बदल जाता है।

कभी-कभी सिग्नल रिलीज लॉग में स्पष्ट होता है। यदि हर डिप्लॉयमेंट के लिए मैनुअल फिक्स, आपातकालीन रोलबैक, या बार-बार QA राउंड की आवश्यकता होती है, तो मासिक लागत आपको कुछ बता रही है। पहले महीने में पुनर्निर्माण की लागत अधिक हो सकती है, लेकिन 6 से 12 महीने में कम हो सकती है। उस व्यापारिक समझौते के लिए एक स्प्रेडशीट की आवश्यकता है, न कि आशावाद की।

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