अपने वर्कलोड से शुरुआत करें, किसी होस्टिंग प्लान से नहीं
उन यात्रा/जर्नियों की सूची बनाएं जो मूल्य या जोखिम पैदा करती हैं: पहली विज़िट, सर्च, साइन-इन, प्रोडक्ट डिटेल, फॉर्म सबमिशन, चेकआउट, एडिटर अपडेट, या API कॉल। प्रत्येक के लिए पीक रिक्वेस्ट/समानांतर यूज़र्स, पेलोड, पर्सनलाइज़ेशन, निर्भरताएँ और विज़िटर क्षेत्र दर्ज करें। शेड्यूल्ड और एडमिन काम भी शामिल करें क्योंकि वे वही संसाधन लेते हैं।
सूची को स्वीकृति मापदंडों में बदलें। मुख्य-सामग्री लोडिंग को मापने के लिए Largest Contentful Paint (LCP); प्रतिक्रियाशीलता के लिए Interaction to Next Paint (INP); और अप्रत्याशित लेआउट मूवमेंट के लिए Cumulative Layout Shift (CLS)। Google अच्छे लक्ष्यों को LCP को 2.5 सेकंड के भीतर, INP को 200 मिलीसेकंड से कम, और CLS को 0.1 से कम बताता है। रूट कम्पलीशन, सर्वर रिस्पॉन्स टाइम और एरर-रेट लक्ष्य भी जोड़ें।
एक तेज़ कैश्ड पेज को प्रमाणित या डेटाबेस-आधारित ट्रांज़ैक्शन का विकल्प न बनने दें।
पीक अवधि, अपेक्षित वृद्धि, अभियान स्पाइक्स और ओवरलैपिंग बैच काम पर परिभाषा करें।
निश्चित करें कि संभावित बॉटलनेक का स्वामित्व होस्ट का है, आपकी टीम का है, या किसी तीसरे पक्ष का।
क्षमता, सीमाएँ और स्केलिंग व्यवहार की तुलना करें
ऑफ़र के पीछे की सीमाएँ पूछें: कंप्यूट और मेमोरी, स्टोरेज प्रदर्शन, डेटाबेस कनेक्शन, वर्कर लिमिट, नेटवर्क शुल्क, अनुरोध नियंत्रण, और साझा-पड़ोसी सीमाएँ। “अनलिमिटेड बैंडविड्थ” यह नहीं बताता कि पीक पर पर्याप्त अनकैश्ड काम ऐप कर सकती है या नहीं। पूछें कि कौन से मैट्रिक्स दिखाई देते हैं और वे कितने समय तक उपलब्ध रहते हैं।
स्केलिंग केवल तब मायने रखती है जब उसके ट्रिगर, देरी, छत, और कीमत ज्ञात हों। पुष्टि करें कि क्या यह स्वत: है, क्या सेशंस और जॉब सुरक्षित रहते हैं, और छत पर क्या होता है। सैद्धांतिक क्षमता दावे से बेहतर है कि अपेक्षित पीक और उससे परे पर एक परीक्षण किया जाए। हेडरूम एक व्यवसायिक निर्णय है, कोई सार्वभौमिक प्रतिशत नहीं।
सिर्फ औसत नहीं, p95 या p99 रिस्पॉन्स टाइम की तुलना करें।
परीक्षण के दौरान डेटाबेस, क्यू, और अपस्ट्रीम API का समय एकत्र करें।
प्रतिबद्ध होने से पहले स्केल, डिलीवरी, बैकअप और सेकंड-रीजन लागत का अनुमान लगाएं।
ओरिजिन को सोच-समझकर रखें और डिलीवरी सत्यापित करें
प्रेक्षक स्थान, एप्लिकेशन निर्भरताएँ, डेटा-स्थान आवश्यकताएँ और ऑपरेटिंग एक्सेस को देखकर एक ओरिजिन रीजन चुनें। प्रतिनिधि जियोग्राफियों और नेटवर्क कंडीशन्स से टेस्ट करें। कंटेंट डिलीवरी नेटवर्क (CDN) एक वितरित कैश है जो योग्य एस्सेट्स को विज़िटर के नज़दीक सर्व कर सकता है और ओरिजिन पर काम कम कर सकता है; यह एक स्वस्थ ओरिजिन, डेटाबेस या एप्लिकेशन की जगह नहीं लेता।
सिर्फ़ डैशबोर्ड सेटिंग न देखें—हेडर और व्यवहार का निरीक्षण करें। वर्जन्ड स्थैटिक एस्सेट्स आमतौर पर लंबे जीवनकाल रख सकती हैं क्योंकि अपडेट में नई URL होती है। डायनामिक और पर्सनलाइज़्ड रिस्पॉन्सेस के लिए स्पष्ट नियम चाहिए। HTTP साझा और निजी कैश को अलग करता है; खाते का डेटा किसी अन्य ग्राहक द्वारा पुन: उपयोग योग्य नहीं होना चाहिए। कैश परज और रोलबैक का अभ्यास करें।
पहली विज़िट और वापसी विज़िट कैप्चर करें क्योंकि कैश स्टेट्स अलग होते हैं।
पेज, एस्सेट्स, कुकीज़, पैरामीटर और लोकेल के लिए Cache-Control और कैश-कीज़ सत्यापित करें।
दस्तावेज़ करें कि अधिकृत स्टाफ किस तरह किसी हानिकारक नियम को सुरक्षित तरीके से अक्षम कर सकता है बिना संवेदनशील कंटेंट एक्सपोज़ करने के।
रिकवरी के प्रमाण को प्रदर्शन आवश्यकता की तरह मानें
पूछें कि क्या बैकअप होता है, प्रतियाँ कहाँ रहती हैं, रिटेंशन क्या है, किसके पास बहाली का अधिकार है, और क्या बैकअप डेटाबेस, अपलोड्स, कोड, कॉन्फ़िगरेशन और इंफ्रास्ट्रक्चर को कवर करते हैं। रिकवरी पॉइंट ऑब्जेक्टिव (RPO) को स्वीकार्य डेटा लॉस के रूप में परिभाषित करें, और रिकवरी टाइम ऑब्जेक्टिव (RTO) को स्वीकार्य बहाली समय के रूप में। दोनों को पैकेज डिफ़ॉल्ट से नहीं, बल्कि व्यवसायिक परिणामों से सेट करें।
सफल बैकअप रिकवरी का प्रमाण नहीं है। CISA शेड्यूल्ड रिकवरी टेस्ट की सिफारिश करती है, और AWS कहता है कि डिजास्टर रिकवरी का आकलन और परीक्षण किया जाना चाहिए। हाल की कॉपी को अलग थलग वातावरण में रिस्टोर करें, महत्वपूर्ण रिकॉर्ड और मीडिया चेक करें, दस्तावेज़ित अनुक्रम का पालन करें, और बीता समय रिकॉर्ड करें। वैकल्पिक रीजन कुछ जोखिम कम कर सकता है पर लागत और जटिलता बढ़ाता है।
वर्तमान डेटा को ओवरराइट किए बिना एक फ़ाइल या रिकॉर्ड रिकवर करें।
रिस्टोर एक्सेस सीमित रखें और रिकवरी क्रेडेंशियल्स व रनबुक अधिकृत रिस्पॉन्डरों के लिए उपलब्ध रखें।
एक डेटाबेस स्नैपशॉट जरूरी नहीं कि सेटिंग्स, एप्लिकेशन वर्ज़न या डिलीवरी नियम पुन: बनाये।
आपको ज़रूरत होने से पहले समर्थन और साझा जिम्मेदारी का मूल्यांकन करें
सपोर्ट स्कोप, घंटे, चैनल, एस्केलेशन और प्लेटफ़ॉर्म घटनाओं व एप्लिकेशन ट्रबलशूटिंग में अंतर की तुलना करें। पैच, मैनेज्ड डेटाबेस, TLS, फ़ायरवॉल नियम, बैकअप और बहाली के लिए लिखित जिम्मेदारी लें। एक सपोर्ट वादा उपयोगी तब होता है जब वह वास्तविक परिदृश्य में मालिक और अगला कदम नाम देता है।
एक्सेस रोल्स, मल्टी-फैक्टर ऑथेंटिकेशन, ऑडिट लॉग्स, सीक्रेट हैंडलिंग और अकाउंट पृथक्करण की समीक्षा करें। पेमेंट कार्ड या संवेदनशील नियमन-योग्य डेटा के लिए होस्टिंग फीचर अकेले अनुपालन स्थापित नहीं करते। इस तुलना का उपयोग तकनीकी इनपुट के रूप में करें और पेमेंट आर्किटेक्चर व लागू दायित्वों के लिए योग्य सुरक्षा, कानूनी या अनुपालन समीक्षा प्राप्त करें।
पूछें कि प्रदाता फेलिंग रिस्टोर, सैचुरेटेड डेटाबेस, या हानिकारक कैश नियम को कैसे संभालता है।
जाँचें कि कौन प्रोडक्शन बदल सकता है, बैकअप पढ़ सकता है, लॉग देख सकता है, और क्रेडेंशियल बना सकता है।
सर्विस क्रेडिट्स और मैनेज्ड कवरेज में महत्वपूर्ण शर्तें हो सकती हैं।
यथार्थवादी, सुरक्षित तुलना परीक्षण चलाएँ और स्कोरकार्ड रखें
हर उम्मीदवार के लिए एक ही रिलीज़, कॉन्फ़िगरेशन इरादा और टेस्ट स्क्रिप्ट का उपयोग करें। एक बेसलाइन, अपेक्षित पीक, छोटा स्पाइक, सतत अवधि, और सुरक्षित रिकवरी या डिप्लॉयमेंट अभ्यास चलाएँ। AWS प्रोडक्शन-नुमा वातावरण, परिभाषित परिदृश्य, आर्किटेक्चर-वाइड मॉनिटरिंग, सैनिटाइज़्ड या सिंथेटिक डेटा और नियमित पुन:परीक्षण की सलाह देता है। प्रदाता की मंज़ूरी लें और उसकी टेस्टिंग नीति का पालन करें।
नियंत्रित लैब परीक्षणों को लॉन्च के बाद फील्ड डेटा के साथ मिलाएँ। लैब परीक्षण डिबगिंग के लिए दोहराने योग्य होते हैं; फील्ड डेटा वास्तविक डिवाइसेज़, नेटवर्क्स, भूगोल, कैश स्टेट और व्यवहार को दर्शाता है। प्रमुख रिलीज़ या निर्भरताओं में बदलाव के बाद स्कोरकार्ड पर पुनर्विचार करें। SIU निष्कर्षों को प्री-लॉन्च हार्डनिंग, मालिक-आधारित सुधार और रोलबैक-तैयार सुधारों में बदल सकता है।
लोकेशन्स, समवर्तीता, कैश स्टेट और पेलोड्स को सुसंगत रखें।
रूट टाइमिंग्स, एरर्स, रिसोर्स मैट्रिक्स, वर्ज़न्स, लागत और टिप्पणियाँ सहेजें।
डॉक्यूमेंटेड आवश्यकताओं को स्थायी परिचालन लागत पर पूरा करने वाला विकल्प चुनें।