वेब प्रोजेक्ट एक्सेसिबिलिटी - गुड नाइट, प्रोडक्टऑनर

आप ProductOwner हैं और वेब प्रोजेक्ट टीम के लिए जिम्मेदार हैं। जब साइटें लटकती हैं, तो अनुपलब्ध हैं, या डिबगिंग जानकारी जैसे "ऑब्जेक्ट में अपवाद कॉडरक्रंट्रोलर कंस्ट्रक्टर ..." ग्राहकों को प्रदर्शित किया जाता है - वे आपको अपने मोबाइल पर कॉल करना शुरू करते हैं, ट्विटर पर लिखते हैं, आदि:

• शीर्ष प्रबंधक (या सामान्य)
• सहयोगियों, कुछ दस्ताने
• हमारे प्यारे ग्राहक

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

प्रतिक्रिया समय कम करें

एक अच्छे तरीके से, आपको वेब प्रोजेक्ट के साथ समस्याओं के बारे में पता लगाने की आवश्यकता होगी, क्योंकि साइट का उपयोगकर्ता किस भाग में आया था और स्थिति को ठीक करने की कोशिश करता है। इससे भी बदतर, जब उपयोगकर्ताओं के दसियों (हजारों) को आपकी वेब परियोजना, आपके पर्यवेक्षक के साथ समस्या के बारे में पता चला, और यहां तक ​​कि ट्विटर पर "फांसी" पर चर्चा करने में कामयाब रहे, त्रुटि का स्क्रीनशॉट लेने के लिए।
अक्सर निम्नानुसार होता है:

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

कहने के लिए धन्यवाद, अब मैं अपाचे को अधिभारित करूंगा ... - अर्थात जब तक आप अंदर धकेलेंगे ... कोई कुछ नहीं करेगा।
एक साधारण वेब परियोजना का परिणाम दसियों मिनट तक है। उपयोगकर्ताओं को यह समझाने की आवश्यकता होगी कि मूल्यवान ग्राहक डेटा के साथ आपकी शांत, उच्च तकनीक वाली वेब परियोजना क्यों लटकी हुई थी।
एक उत्कृष्ट कम लागत वाली व्यावसायिक प्रक्रिया है जो आपको PROACTIVELY का जवाब देने की अनुमति देती है। हम यह करते हैं:

1. हम आपकी वेब परियोजनाओं की स्वचालित निगरानी स्थापित करने के लिए सिस्टम एडमिनिस्ट्रेशन सेवा से सहमत हैं। ऐसा करने के लिए, बहुत सारे मुफ्त प्रभावी सॉफ़्टवेयर हैं। हम नगिओस का उपयोग करते हैं, कई ज़ैबिक्स और अन्य का उपयोग करते हैं। ऐसे सॉफ़्टवेयर को कॉन्फ़िगर करने में कई घंटे लगते हैं । क्या परीक्षण करें? सबसे सरल मामला: आपकी वेब परियोजना के पृष्ठ का लोड समय और उस पर एक अद्वितीय हस्ताक्षर की उपस्थिति, उदाहरण के लिए, पाद लेख में एक फ़ोन नंबर।
2. निगरानी प्रणाली से समस्या के बारे में अधिसूचना के मामले में "किसी को" प्रतिक्रिया देनी चाहिए। यदि "किसी ने" दोपहर का भोजन किया है या आधे घंटे तक धूम्रपान करता है, तो वेब परियोजनाएं आधे घंटे के लिए लटक जाएंगी। यह मोबाइल फोन पर एसएमएस भेजने के लिए कॉन्फ़िगर करने में मदद करता है। Mail.ru पर , हालांकि सीमाओं के साथ, आप अपने मेलबॉक्स से मुफ्त में एसएमएस भेज सकते हैं, लेकिन हर आधे घंटे में एक बार से अधिक नहीं। यदि आप एसएमएस वितरण सेवा की सदस्यता खरीदते हैं, तो उन्हें तेजी से और प्रतिबंधों के बिना वितरित किया जाएगा। सिस्टम के बारे में 30 मिनट - मोबाइल sysadmins को एक एसएमएस निगरानी प्रणाली भेजने की प्रक्रिया सेट करें। यदि आप एसएमएस भेजने की सेवा को मंजूरी नहीं देते हैं, तो आप कम से कम, निगरानी प्रणाली को सभी sysmmins को मेल करने के लिए मजबूर कर सकते हैं, आप और आपके सहकर्मी - आप उम्मीद कर सकते हैं कि सिस्टम प्रशासक में से एक। कार्यस्थल में होगा और प्रतिक्रिया देगा।
3. "किसी को" आपके वेब प्रोजेक्ट के साथ एक समस्या का जवाब देना होगा ... सप्ताहांत पर, रात में, छुट्टियों पर (उदाहरण के लिए, जनवरी की शुरुआत में)। अक्सर मुझे ऐसे मामले सामने आते हैं जब उन्हें सप्ताहांत या नए साल की छुट्टियों पर वेब परियोजनाओं को लटकाने के बारे में पता चला ... तुरंत नहीं, लेकिन कुछ घंटों या दिनों के बाद। यह सिर्फ यह है कि सिस्टम प्रशासक में से कोई भी काम पर नहीं था :-) इस मामले में, आप यह कर सकते हैं - काम के घंटे के बाहर ड्यूटी घंटे के आयोजन पर तकनीकी सहायता सेवा से सहमत हैं - इस मामले में "कोई" होगा जो सबसे महत्वपूर्ण रूप से प्रतिक्रिया कर सकता है।

इस बिंदु पर, हम आशा कर सकते हैं कि सिस्टम प्रशासन सेवा से कोई व्यक्ति आपके वेब प्रोजेक्ट की समस्या के बारे में पहले या उसी समय ग्राहकों को जान लेगा और किसी भी समय जवाब देगा।
गंभीर संगठनों में, तेजी से प्रतिक्रिया के कार्य को हल करने के लिए, आप एसएलए पर आईटी सेवा "समझौते" से सहमत होने का प्रयास कर सकते हैं, जहां उपरोक्त कार्यों को शामिल करना है।
मैं मॉनिटरिंग मशीन को दूसरे डेटा सेंटर में रखने की सलाह देता हूं - पालन करें। यदि, जैसा कि अक्सर घरेलू होस्टिंग के साथ होता है (और, जैसा कि हम याद करते हैं, हाल ही में एक डेटा सेंटर जहां हमारी मशीनें भी हाल ही में अमेज़ॅन में "गिरा दी गई थीं " ), डेटा सेंटर कई घंटों के लिए डी-एनर्जेट किया जाता है, तो हमारी निगरानी मशीन और कंपनी के अंदर कोई भी बंद नहीं होगा। अगर सप्ताहांत पर घटना होती है तो कुछ भी पता नहीं है :-)

प्रोएक्टिव मॉनिटरिंग - आउटसाइड

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

प्रोएक्टिव मॉनिटरिंग - अंदर

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

स्पर्श न करें - विकास अलग से किया जाता है

अपने निंदक, लेकिन व्यापक मामले में खौफनाक - डेवलपर्स "मुकाबला" सर्वर पर सीधे वेब प्रोजेक्ट कोड में परिवर्तन करते हैं, अक्सर दिन के दौरान परियोजना की कार्यक्षमता को तोड़ते हुए, साइट के पृष्ठों और डेटा को हटाते हुए (बेशक दुर्घटना से) ...
डेवलपर्स के लिए ऐसा करने का सबसे आसान तरीका है - लॉग इन और फिक्स / ब्रेक और तुरंत डेवलपर और क्लाइंट दोनों के लिए परिणाम देखें :-)
इस दुःस्वप्न से कैसे निपटें:

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

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

डाटासेंटर और उनकी संख्या

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

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

"डीसी के बीच तेजी से पलायन" की इस समस्या का एक सुरुचिपूर्ण और सरल समाधान अमेज़ॅन द्वारा प्रदान किया गया है। डेटा सेंटर वहां हाई-स्पीड हाईवे से जुड़े होते हैं और आप मिनटों में ताज़ातरी स्नैपशॉट्स से डेटा लेकर दूसरे डेटा सेंटर में "लिफ्ट" कर सकते हैं!

ग्राहक डेटा हमेशा के लिए कैसे खोएं?

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

परिणाम

यदि आप चाहते हैं और एक निश्चित मुखरता है, तो आप जल्दी से आपको सौंपी गई वेब परियोजनाओं की निगरानी और पुनर्स्थापना के लिए एक व्यावसायिक प्रक्रिया स्थापित कर सकते हैं। खासकर यदि आप बादल में स्थित हैं। तकनीकी क्षमता ... स्थायी रचनात्मक आनंद ProductOwner - उपलब्ध :-)