जब आप किसी लाइव वेबसाइट पर परिवर्तन करते हैं, तो आप यह जांचने के लिए कैसे जाते हैं कि लाइव सिस्टम सही तरीके से काम कर रहा है? आप किस उपकरण का उपयोग करते हैं? इसे कौन करता है? क्या आप परीक्षण अवधि के लिए साइट तक पहुंच को अवरुद्ध करते हैं? डाउनटाइम कितनी स्वीकार्य है?आप एक राजनीतिक तरीके से लाइव, व्यस्त वेब साइट को कैसे अपडेट करते हैं?
मैं अपने सभी परीक्षणों को किसी अन्य वातावरण में करता हूं (लाइव नहीं!)। यह मुझे लाइव साइट पर अद्यतनों को धक्का देने की अनुमति देता है यह जानकर कि कोड ठीक काम कर रहा है, और मैं बस लाइव डेटा पर सैनिटी परीक्षण करता हूं - सुनिश्चित करें कि मैंने कहीं भी फ़ाइल को नहीं भूलया है, या कुछ अजीब गलत है।
तो परीक्षण या स्टेजिंग वातावरण में उचित परीक्षण, फिर केवल छोटी सैनिटी जांच। डाउनटाइम की कोई ज़रूरत नहीं है।
यदि आपके पास लोड-संतुलित सर्वर का एक सेट है, तो आप एक-एक करके ऑफ़लाइन अलग-अलग ले सकते हैं और इसे अपडेट कर पाएंगे। उपयोगकर्ताओं के लिए कोई डाउनटाइम नहीं!
इनमें से कुछ इस बात पर निर्भर करता है कि आप डेटाबेस को भी अपडेट कर रहे हैं या नहीं। अतीत में, यदि डीबी अपडेट किया जा रहा था, तो हमने योजनाबद्ध (और प्रकाशित) रखरखाव अवधि के लिए साइट को डाउन किया - आम तौर पर वास्तव में कुछ घंटों से दूर जहां प्रभाव कम था। यदि अद्यतन में डीबी शामिल नहीं है, तो लोड संतुलित वातावरण में, हम मिश्रण से 1 बॉक्स ले लेंगे, & परीक्षण तैनात करें। यदि वह सफल होता, तो यह मिश्रण में चला गया और दूसरा बॉक्स (माना जाता है कि 2 बक्से) लाया गया था और अपडेट/परीक्षण किया गया था।
नोट: हम कोड का परीक्षण नहीं कर रहे हैं, बस तैनाती आसानी से डाउन टाइम कम हो गई थी। जैसा कि उल्लेख किया गया है, कोड पहले से ही किसी अन्य वातावरण में परीक्षण पास कर दिया जाना चाहिए था।
80 के अलावा किसी अन्य बंदरगाह पर अपना मुख्य सर्वर चलाएं। पोर्ट 80 पर इसके सामने हल्के सर्वर (उदा। Nginx) चिपकाएं। जब आप अपनी साइट अपडेट करते हैं, तो एक नए पोर्ट पर एक और उदाहरण शुरू करें। परीक्षा। जब आप संतुष्ट होते हैं कि इसे सही तरीके से तैनात किया गया है, तो अपनी प्रॉक्सी कॉन्फ़िगरेशन फ़ाइल संपादित करें, और इसे पुनरारंभ करें। Nginx के मामले में, यह शून्य डाउनटाइम या असफल अनुरोधों में परिणाम देता है, और अधिक विशिष्ट अपाचे-केवल होस्टिंग विकल्प पर प्रदर्शन सुधार भी प्रदान कर सकता है।
बेशक, यह एक उचित स्टेजिंग सर्वर के लिए कोई विकल्प नहीं है, यह केवल सीमित संसाधनों के साथ हैंडओवर करने का 'विनम्र' तरीका है।
काम पर, हम परीक्षण वातावरण में जमे हुए कोड के साथ समय की अवधि बिताते हैं। फिर नोटिस के कुछ हफ्तों के बाद, हम शुक्रवार रात मध्यरात्रि में साइट लेते हैं, रात्रि तैनाती और सत्यापन के माध्यम से काम करते हैं, और शनिवार देर सुबह इसे रख देते हैं। यातायात के आंकड़े बताते हैं कि यह करने के लिए यह सबसे अच्छा समय सीमा थी।
एक प्यारा, निराशाजनक छवि और/या बैकअप पृष्ठ है। अपडेट की प्रतीक्षा करते समय कुछ व्यस्त साइट आपको व्यस्त रखने के लिए सरल जावास्क्रिप्ट गेम लागू करती हैं।
जैसे, विफल व्हेल।
-Adam
IMHO लंबे टाइम (घंटे) एक नि: शुल्क साइट के लिए स्वीकार्य हैं। यदि आप अपने उपयोगकर्ताओं को पर्याप्त शिक्षित करते हैं तो वे समझेंगे कि यह एक आवश्यकता है। हो सकता है कि वेबसाइट वापस आने तक उन्हें खेलने के लिए कुछ दें (उदाहरण के लिए फ़्लैश खेल, वेबकैम लाइव फीड काम पर देव टीम दिखाती है)। ऐसी वेबसाइट के लिए जो लोग पहुंचने के लिए भुगतान करते हैं, यदि आप नियमित रूप से डाउनटाइम खिलाते हैं तो बहुत से लोग शिकायत के साथ अपना समय बर्बाद कर रहे हैं। अगर मैं ऐसी सेवा चला रहा था जो उपयोगकर्ताओं को चार्ज करता है तो मैं प्लेग की तरह डाउनटाइम से बचूंगा और अपडेट को धीरे-धीरे धीरे-धीरे और ध्यान से बाहर रखूंगा।
मेरे वर्तमान सेटअप में मेरे पास एक ही डेटाबेस से कनेक्ट एक माध्यमिक वेबसाइट है और मेरे परिवर्तनों का परीक्षण करने के लिए लाइव कॉपी के रूप में कैश है।
मेरे पास क्रॉन नौकरियों पर चलने वाली कई "पेज वॉचर" स्क्रिप्ट भी हैं जो नियमित अभिव्यक्तियों का उपयोग करते हैं ताकि यह जांच सके कि वेबसाइट महत्वपूर्ण पृष्ठों को सही तरीके से प्रस्तुत कर रही है।
उत्तर यह है कि "यह निर्भर करता है"। सबसे पहले, जिस तरह के पर्यावरण में आप रिलीज कर रहे हैं उस पर। क्या यह किसी साझा मेजबान पर कहीं भी "हैलो, वर्ल्ड" वेबसाइट है, या google.com आधे मिल सर्वर के साथ? क्या प्रति दिन आम तौर पर एक उपयोगकर्ता होता है, या दो मिलियन की तरह अधिक? क्या आप एचटीएमएल/सीएसएस/जेपीजी प्रकाशित कर रहे हैं, या एसक्यूएल सर्वर, मध्यम स्तरीय सर्वर, वितरित कैश इत्यादि के साथ एक बड़ा बालों वाली बैकएंड है?
सामान्य रूप से - यदि आप विकास, क्यूए, स्टेजिंग और उत्पादन के लिए अलग वातावरण प्राप्त कर सकते हैं - तो उनके पास है। यदि आपके पास संसाधन हैं - पारिस्थितिकी तंत्र बनाएं ताकि आप 1 (एक) क्लिक के साथ पूर्ण इंस्टॉल करने योग्य पैकेज बना सकें। और सुनिश्चित करें कि वही बाइनरी इंस्टॉल को किसी अन्य क्लिक के साथ DEV/QA/STAGE/PROD में सफलतापूर्वक इंस्टॉल किया जा सकता है ... इस विषय पर बहुत सी चीजें लिखी गई हैं, और आपको अपने प्रश्न के साथ अधिक विशिष्ट होना चाहिए एक उचित जवाब
रूप में अच्छी तरह से संभव के रूप में एक अलग देव साइट पर सब कुछ परीक्षण करने के लिए लाइव जाने से पहले, मैं सेलेनियम (एक वेब पेज परीक्षक) का उपयोग करें, साइट के सभी नौगम्य भागों के माध्यम से चलाने में डमी मूल्यों को भरने के लिए फॉर्म, जांचें कि परिणाम वे परिणामस्वरूप सही जगहों पर दिखाई देते हैं, आदि
यह बहुत सारे जावास्क्रिप्ट याकी जांच करने के लिए पर्याप्त शक्तिशाली हैगतिशील सामान भी।
फिर सेनेनियम के साथ एक त्वरित रन-थ्रू लाइव साइट को अपग्रेड करने के बाद सत्यापित करता है कि अद्यतन काम करता है और इसमें कोई अनुपलब्ध लिंक या डेटाबेस त्रुटियां नहीं हैं।
यह सूक्ष्म त्रुटियों को पकड़कर मुझे कुछ बार बचाया गया है कि मैं मैन्युअल रूप से मैन्युअल रूप से फिसल गया होगा।
इसके अलावा, अगर आप "रिवर्स प्रॉक्सी" या लोड संतुलन के कुछ प्रकार के पीछे लाइव साइट डाल (अगर यह बड़ा है), कि यह आसान पिछले संस्करण पर वापस स्विच करने के लिए अगर वहाँ समस्याएं हैं बनाता है।
इसे अपने उपयोगकर्ताओं के लिए पारदर्शी बनाने का एकमात्र तरीका यह है कि इसे लोड संतुलित प्रॉक्सी के पीछे रखा जाए। जब आप किसी अन्य सर्वर को अपडेट करते हैं तो आप एक सर्वर नीचे ले जाते हैं। फिर जब आप अपडेट करते हैं तो आपने उसे ऑनलाइन अपडेट किया है और दूसरे को नीचे ले जाया है। यह हमारा करने का तरीका है।
यदि आपके पास किसी भी तरह का 'बीटा' बिल्ड है, तो इसे लाइव सर्वर पर रोल न करें। अगर आपके पास 'लाइव, व्यस्त साइट' संभावना है तो लोग इस पर पाउंड करने जा रहे हैं और कुछ तोड़ सकते हैं।
यह एक विशिष्ट उच्च availbility स्थापना, उच्च उपलब्धता की आवश्यकता होगी कम से कम। 3 सर्वर 2 लाइव लोगों और 1 परीक्षण सर्वर। प्लस किसी भी oter अतिरिक्त सर्वर आप एक समर्पित डीबी या कुछ और करना चाहते हैं, तो बनाए रखना है।
यहां मुश्किल बात यह है कि जब आपके पास लोड संतुलित प्रॉक्सी होता है तो आपके पास डेटाबेस होता है। डेटा/स्कीमा/डीबी कोड बदलना मुश्किल है जो संतुलन लोड करने में मदद नहीं करेगा। – EBarr
पहले से ही बहुत अच्छी सलाह है।
जैसा कि लोगों ने उल्लेख किया है, यदि आपके पास एक बिंदु शामिल नहीं है, तो बस बदलाव में बदलाव करना आसान है एक समय में एक ऐप सर्वर को अपग्रेड करके। लेकिन यह शायद ही मामला है, इसलिए चलो इसे अनदेखा करें और मुश्किल बिट्स पर ध्यान दें।
आमतौर पर वहां एक डीबी है जो बाकी सब कुछ के लिए आम है। तो इसका मतलब है पूरे सिस्टम के लिए डाउनटाइम। आप इसे कैसे कम करते हैं?
स्वचालन। पूरी तैनाती प्रक्रिया स्क्रिप्ट। यह (विशेष रूप से) में किसी भी डेटाबेस स्कीमा परिवर्तन शामिल हैं। यह (विशेष रूप से) स्कीमा के संस्करणों के बीच आपको आवश्यक डेटा माइग्रेशन शामिल करता है।
गुणवत्ता नियंत्रण। सुनिश्चित करें कि परीक्षण हैं। स्वचालित स्वीकृति परीक्षण (उपयोगकर्ता जो व्यवसायिक तर्क/अनुभव परिप्रेक्ष्य से देखता है और अपेक्षा करता है)। उत्पादन प्रणाली में परीक्षण खाते होने पर विचार करें, जिसे आप पढ़ाई गतिविधियों का परीक्षण करने के लिए स्क्रिप्ट कर सकते हैं। यदि आप अन्य बाहरी प्रणालियों से बातचीत नहीं करते हैं, तो भी लेखन गतिविधियों पर विचार करें। आपको सिस्टम के कुछ हिस्सों में परीक्षण खाता गतिविधि को फ़िल्टर करने की आवश्यकता हो सकती है, खासकर अगर वे पैसे और लेखांकन से निपटते हैं। बीन काउंटर परेशान हो जाते हैं, अच्छे कारणों से, जब सेम मेल नहीं खाते हैं।
रीहर्स। एक स्टेजिंग वातावरण में तैनात करें जो उत्पादन के लिए जितना संभव हो उतना ही है। इसे उत्पादन डेटा वॉल्यूम, और उत्पादन डेटा के साथ करें। आपको यह महसूस करने की ज़रूरत है कि तालिका में कितनी देर लगती है। और आपको यह जांचने की ज़रूरत है कि एक परिवर्तित तालिका संरचनात्मक रूप से, और वास्तविक डेटा में सभी विदेशी कुंजी के साथ काम करती है।
यदि आपके पास भारी डेटा वॉल्यूम है, तो स्कीमा में परिवर्तन समय लगेगा। हो सकता है कि आप जितना अधिक समय बर्बाद कर सकें। एक समाधान चरणबद्ध डेटा माइग्रेशन का उपयोग करना है, ताकि स्कीमा परिवर्तन डाउनटाइम के दौरान "हालिया" या "वर्तमान" (चलो एक या तीन महीने पुराना) डेटा के साथ आबादी हो, और शेष पांच वर्षों के लिए डेटा ट्रिकल हो सकता है बाद में आप फिर से ऑनलाइन हैं। अंत उपयोगकर्ता की चीजों को ठीक लग रहा है, लेकिन कुछ विशेषताओं को कुछ और घंटों/दिनों/जो भी हो, तक पहुंचा नहीं जा सकता है।
आखिरी जगह जहां मैंने काम किया, क्यूए क्यूए पर्यावरण में परीक्षण करेगा। रोलिंग से पहले किसी भी बड़ी समस्या को ठीक, परीक्षण और सत्यापित किया जाएगा।
निर्माण के बाद क्यूए द्वारा प्रमाणित किया गया है, उत्पादन सहायता टीम ने कोड को स्टेजिंग वातावरण में धक्का दिया जहां ग्राहक साइट पर देखता है और सत्यापित करता है कि सब कुछ वांछित है।
वास्तविक उत्पादन रोलआउट ऑफ घंटों के दौरान होता है (9 पीएम के बाद यदि यह एक आपातकालीन रात धक्का है, या 5 एएम - 8 एएम से है यदि यह आमतौर पर निर्धारित रोलआउट है)।
साइट एकाधिक सर्वर है, जो लोड एक F5 लोड बैलेंसर का उपयोग कर संतुलित कर रहे हैं पर होस्ट की है सर्वर को पूल में वापस रखने से पहले सर्वर पर कर्सर चेक किया जाता है।
यह तब तक दोहराया जाता है जब तक कि सभी सर्वर नवीनतम कोड में अपग्रेड नहीं हो जाते हैं और साइट को पूरे समय तक रहने की अनुमति देता है।
यह प्रक्रिया आदर्श है, लेकिन ऐसे मामले हैं जब डेटाबेस को भी अपग्रेड करने की आवश्यकता है। यदि यह मामला है, तो नया डेटाबेस साइट को तोड़ देगा या नहीं, इसके आधार पर दो विकल्प हैं।
यदि नया डेटाबेस मौजूदा फ्रंट एंड के साथ असंगत है, तो आपके पास कोई वास्तविक विकल्प नहीं है, लेकिन साइट की कमी के समय की खिड़की है।
लेकिन यदि नया डेटाबेस मौजूदा फ्रंट एंड के साथ संगत है, तो आप अभी भी बिना किसी वास्तविक डाउनटाइम के कोड को धक्का दे सकते हैं, लेकिन इसके लिए दो उत्पादन डेटाबेस सर्वर होने की आवश्यकता है।
तो संक्षेप में प्रस्तुत करने के लिए:
जब आप किसी को लाइव वेब साइट में परिवर्तन शुरू, आप कैसे यह जांच करना कि लाइव प्रणाली सही ढंग से काम कर रहा है के बारे में जाते हैं? सबसे अच्छे मामले में, यह वृद्धिशील रूप से किया जाता है।
आप कौन से टूल्स का उपयोग करते हैं? किसी भी स्वचालन उपकरण का उपयोग कर, कुछ बुनियादी स्वचालित परीक्षणों के साथ कोड को सत्यापित करने के लिए मैन्युअल जांच सही ढंग से स्थापित की जाती है। हमने सेलेनियम आईडीई का इस्तेमाल किया।
यह कौन करता है? डीबीए डीबी अपग्रेड करता है, टेक सपोर्ट/सिस्टम एडमिन्स सर्वर को पुश/पुल करता है और कोड इंस्टॉल करता है, और क्यूए या प्रोडक्शन सपोर्ट मैनुअल टेस्ट करता है और/या स्वचालित परीक्षण चलाता है।
क्या आप परीक्षण अवधि के लिए साइट तक पहुंच को अवरुद्ध करते हैं? यदि संभव हो, तो इसे सभी लागतों से बचा जाना चाहिए, खासतौर पर, जैसा गिल्स ने पहले उल्लेख किया था, यदि यह एक सशुल्क साइट है।
डाउनटाइम कितनी स्वीकार्य है? डाउनटाइम उन समय तक सीमित होना चाहिए जब उपयोगकर्ताओं को साइट का उपयोग करने की संभावना कम होगी, और 3 घंटे से कम समय में किया जाना चाहिए।
नोट: 3 घंटे बहुत उदार है। प्रैक्टिस और रीहर्सिंग के बाद, जेप्लिंडस्ट्रॉम का उल्लेख किया गया है, टीम की पूरी प्रक्रिया नीचे होगी और कभी-कभी एक घंटे से भी कम समय में अंदर और बाहर जा सकती है।
आशा है कि इससे मदद मिलती है!
क्या होगा यदि हमारे पास केवल 1 सर्वर है ?? – AminM
होस्ट क्लास बनाएं और उस होस्ट क्लास पर अपनी लाइव साइट को तैनात करें। मेजबान वर्ग से मेरा मतलब मेजबानों का एक समूह है जहां भार संतुलन स्थापित होता है और कक्षा से मेजबान को जोड़ने और हटाने में आसान होता है।
जब आप बीटा परीक्षण और उत्पादन के लिए तैयार होते हैं, तो आपकी साइट को नीचे ले जाने की आवश्यकता नहीं होती है, केवल उत्पादन होस्ट क्लास से कुछ होस्ट हटा दें, उन्हें नए होस्ट क्लास में जोड़ें और अपना नवीनतम कोड तैनात करें और ठीक से परीक्षण करें। एक बार जब आप सुनिश्चित हो जाएं कि सबकुछ ठीक से काम कर रहा है, तो अपने सभी होस्ट धीरे-धीरे नए पर जाएं और नए होस्ट क्लास को उत्पादन होस्ट क्लास के रूप में इंगित करें।या आप इसका उपयोग कर सकते हैं, जिसे आप प्रारंभ में उपयोग कर रहे थे, इस गतिविधि के पीछे पूरा विचार यह सुनिश्चित करना है कि आप उत्पादन बक्से पर अपनी तैनाती का परीक्षण कर रहे हैं, जहां आपकी साइट तैनाती के बाद चल रही है, क्योंकि मुद्दों को तैनात करना डरावना और डीबग करना मुश्किल है।
इस प्रश्न में चर्चा आपके लिए भी उपयोग की जा सकती है - http://stackoverflow.com/questions/148084/how-to-deploy-an-asp-net-application-with-zero-downtime – EBarr