क्या आप ब्लैक फ्राइडे और साइबर मंडे के लिए तैयार हैं? आज ही अपने डेटा को सुरक्षित करें

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

2018 ब्लैक फ्राइडे के लिए बिक्री रिपोर्ट दिखाती है कि ऑनलाइन बिक्री $6.2 बिलियन थी, जो पिछले वर्ष से 23.6 प्रतिशत की वृद्धि है , और साइबर मंडे 2018 में वर्ष का सबसे बड़ा बिक्री दिन था, जिसमें ऑनलाइन राजस्व $7.9 बिलियन था, जो 2017 से 19.3 प्रतिशत की वृद्धि है।

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

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

यह ब्लॉग आपके डेटा प्रौद्योगिकी स्टैक के कुछ प्रमुख क्षेत्रों को कवर करता है जिन पर आप ब्लैक फ्राइडे के निकट होने पर विचार करना चाहते हैं, तैयारी के बारे में संकेत, और आपकी ObjectRocket टीम ब्लैक फ्राइडे और साइबर मंडे के लिए तैयार होने के लिए आपके साथ कैसे काम कर सकती है।

अपने डेटा स्टैक को तैयार करने के सामान्य चरण

ऐसे कई चरण हैं जिन्हें तैयारी के लिए उठाया जाना चाहिए, चाहे आप किन डेटाबेस का उपयोग करते हों। इनमें आपके डेटा स्टोर को सुचारू रूप से चलाने के लिए मानक सर्वोत्तम प्रथाएं शामिल हैं, लेकिन ब्लैक फ्राइडे और साइबर मंडे की तैयारी करते समय उनकी विशेष तात्कालिकता होती है।

• बड़ी मात्रा में ट्रैफिक के लिए तैयारी करें: क्षमता योजना, विकास प्रक्षेपण, डेटा स्थिरता, उच्च उपलब्धता, रेप्लिकेशन, फेलओवर क्लस्टर, बढ़े हुए ट्रैफिक भार को सहन करने के लिए प्राथमिक अवधारणाएं हैं। तैयारी करते समय इन वस्तुओं पर विचार करें:
  • शार्डेड क्लस्टर के लिए, अधिक शार्ड जोड़ने पर विचार करें ताकि यह सुनिश्चित हो सके कि ऐसी चरम अवधि के दौरान आप स्थान से बाहर नहीं निकलते। ObjectRocket पर, हम आमतौर पर उन ग्राहकों को लगभग 60% उपयोग पर रखना चाहते हैं जो बहुत अधिक विकास की उम्मीद करते हैं ताकि फुल डिस्क के परिणामस्वरूप किसी भी आउटेज को रोका जा सके।
  • Elasticsearch क्लस्टर वर्जन 6.x और उससे अधिक के साथ आपको यह सुनिश्चित करना होगा कि, यदि छोटे प्लान आकार का उपयोग कर रहे हैं, तो तेजी से विकास की संभावना पर विचार किया जाए, और विशेष रूप से डिस्क आकार को 95% से कम रखने का महत्वपूर्ण लक्ष्य ताकि रीड-ओनली लॉक से बचा जा सके। क्षमता योजना करते समय ध्यान रखें कि प्रत्येक शार्ड में एक ट्रांसलॉग हो सकता है जो 512MB तक बढ़ सकता है और 12 घंटे तक उस तरह रह सकता है।
  • एक छोटे, साधारण रेप्लिका सेट के लिए जो ऑटो-स्केलिंग का उपयोग नहीं करता है, विकास प्रक्षेपण के आधार पर समवर्ती और विकास को संभालने वाले प्लान आकार में जाने पर विचार करें।
  • जैसे-जैसे ट्रैफिक बढ़ता है, डेटाबेस से कनेक्शन अनुरोध भी बढ़ते हैं। एप्लिकेशन टीम के सदस्यों/ग्राहकों के साथ समीक्षा करें ताकि यह सुनिश्चित हो सके कि सही कनेक्शन पूलिंग सेटिंग्स मौजूद हैं साथ ही सही OS सेटिंग्स (जैसे ulimits, जो आपको उपयोगकर्ताओं के लिए संसाधन सीमाएं प्रदर्शित और सेट करने की अनुमति देते हैं)। कभी-कभी एप्लिकेशन को एक सिंगल रेप्लिका सेट या 4 डिफ़ॉल्ट mongos (विशेष नोड्स जो शार्डेड क्लस्टर पर कनेक्शन के लिए सुनते हैं) की तुलना में अधिक कनेक्शन खोलने की आवश्यकता हो सकती है। इस मामले में, हम अक्सर ग्राहकों के साथ अधिक mongos आवंटित करने के लिए काम करते हैं ताकि कनेक्शन संभाले जा सकें।
  • यह सुनिश्चित करना कि oplog सही आकार का है, एक और क्षेत्र है जिसे देखना चाहिए। oplog सभी क्रिएट, रीड, और डिलीट ऑपरेशन का एक कैप्ड कलेक्शन (फिक्स्ड साइज के साथ) है, जिससे सेकेंडरी नोड्स अपने सिंक स्रोत से डेटा रेप्लिकेट करते हैं। यदि वे जिस नोड से सिंक कर रहे हैं उस पर oplog साइज छोटा है और वे ऑपरेशन के साथ तालमेल नहीं रख पा रहे हैं - विशेष रूप से चरम अवधि के दौरान - तो सेकेंडरी नोड्स आउट ऑफ सिंक हो सकते हैं। oplog जितना बड़ा होगा, सेकेंडरी नोड्स को प्राइमरी नोड पर गतिविधियों के साथ सिंक में रहने के लिए उतना ही अधिक समय मिलेगा, भले ही वे डाउन हो जाएं।
• टेस्ट करें, ट्वीक करें, और फिर से टेस्ट करें: जितना अधिक आप अपने डेटाबेस का टेस्ट करते हैं, उतना ही अधिक आप अपने डेटाबेस को जानते हैं। यह आपके डेटाबेस पर स्ट्रेस और परफॉरमेंस टेस्ट चलाने का समय है, और फिर अपने ग्राहकों के खरीदारी शुरू करने से पहले कोई भी बदलाव लागू करें।
  • पिछले हिचकी/डेटा विफलताओं, कमजोरी के क्षेत्रों को देखें, और निर्धारित करें कि क्या कुछ चीजें हैं जिन्हें मजबूत करने की आवश्यकता है (लेकिन BF से ठीक पहले बड़े फिक्स लागू न करें)।
  • तैयारी अवधि की शुरुआत में लोड और परफॉरमेंस टेस्ट करें, लेकिन साल भर भी, और इन प्रकार के टेस्ट को अपनी कंटीन्यूअस इंटीग्रेशन प्रक्रिया में शामिल करें।
  • यदि संभव हो तो टेस्ट वातावरण में ट्रैफिक पैटर्न और लोड की लंबाई का अनुकरण करें।
• एनालिटिक्स का लाभ उठाएं: यदि आप पिछले कई महीनों में ट्रैफिक फ्लो और अन्य पैटर्न देख रहे हैं, तो आपको "सामान्य" क्या है, इससे परिचित होना चाहिए।
  • किसी भी परफॉरमेंस या इनपुट/आउटपुट मुद्दों को देखना शुरू करें जो सब-ऑप्टिमल लगते हैं और जिन्हें बड़े दिन से पहले हल किया जा सकता है।
  • अपने ट्रैफिक पैटर्न का अध्ययन करें: सबसे व्यस्त समय पर अधिकतम कनेक्शन की संख्या देखें और फिर 20% अधिक क्षमता के लिए योजना बनाएं।
  • Elasticsearch के लिए, आप New Relic जैसे थर्ड-पार्टी मेट्रिक्स कलेक्टर का उपयोग कर सकते हैं जो आपको CPU उपयोग/GC समय/क्वेरी समय देगा। ये सभी स्टैट्स आपको ब्लैक फ्राइडे के बड़े सप्ताह के लिए योजना बनाने में मदद करेंगे।
• बड़े दिनों के बहुत करीब बड़े मरम्मत या अपग्रेड पर रोक लगाएं! और, अपनी टीम में इस स्थगन को संप्रेषित करना सुनिश्चित करें।
• अपने सुरक्षा उपायों को फिर से देखें, उन्हें जानें और समझें, अपनी क्षमता के बारे में तैयार और आश्वस्त रहें कि आप उन्हें दूसरों को समझा सकते हैं (क्या आवश्यकता उत्पन्न होनी चाहिए)। न्यूनतम, सुनिश्चित करें कि आप डेटा उल्लंघन के लिए "सॉफ्ट टारगेट" नहीं हैं।
• गोपनीयता नियम, सुरक्षा मुद्दों के समान, तेजी से महत्वपूर्ण हैं। विचार करें कि GDPR आवश्यकताएं आपके बिक्री अभियानों (और संबंधित कुकीज़) के उपयोग को कैसे प्रभावित करती हैं और आप ग्राहकों के डेटा का उपयोग/भंडारण कैसे करते हैं।
• भविष्य पर नजर के साथ निरंतर सुधार: हर ब्लैक फ्राइडे/साइबर मंडे के बाद रेट्रोस्पेक्टिव मीटिंग (रेट्रो) आयोजित करना एक शानदार विचार है ताकि उन क्षेत्रों की पहचान की जा सके जिनमें अगली बार सुधार किया जा सके!

डेटाबेस-विशिष्ट विचार

यहां ObjectRocket द्वारा समर्थित कुछ डेटाबेस के लिए प्रो टिप्स हैं (या शायद आप सभी तीन डेटाबेस चलाते हैं (पॉलीग्लॉट पर्सिस्टेंस)!

MongoDB प्रो टिप्स

MongoDB ई-कॉमर्स के लिए NoSQL डेटाबेस में तेजी से लोकप्रिय विकल्प है, जिसमें स्पीड और स्केलेबिलिटी प्राथमिक लाभ हैं। कई व्यापारी अपने उत्पाद प्रसाद, मूल्य निर्धारण, शिपिंग, और इन्वेंट्री को प्रबंधित करने के लिए MongoDB प्रोडक्ट कैटलॉग का उपयोग करते हैं। हमारे MongoDB विशेषज्ञों के प्रो टिप्स में शामिल हैं:

• सुनिश्चित करें कि रेप्लिका सेट के लिए कनेक्शन स्ट्रिंग में रेप्लिका सेट के सभी तीन होस्टनाम और शार्डेड क्लस्टर के मामले में सभी 4 mongos जोड़े गए हैं।
• सुनिश्चित करें कि वे डेटाबेस के लिए अनावश्यक कनेक्शन खोलने से बचने के लिए कनेक्शन पूल का उपयोग कर रहे हैं।
• विचार करें कि आपका ट्रैफिक और रीड/राइट कितना बढ़ सकता है (आपका विकास प्रक्षेपण) और MongoDB की ऑटो-स्केलिंग सुविधा का लाभ उठाएं।
• बड़े शॉपिंग दिनों से पहले और दौरान परफॉरमेंस ट्यूनिंग (मेमोरी उपयोग, कनेक्शन हैंडलिंग, रेप्लिका सेट का स्वास्थ्य) पर नजर रखें।

Elasticsearch प्रो टिप्स

हमने ObjectRocket के Elasticsearch विशेषज्ञों की टीम से ब्लैक फ्राइडे और साइबर मंडे के लिए डेटाबेस तैयार करने के लिए कुछ प्रो टिप्स एकत्र किए। Elasticsearch अक्सर ई-कॉमर्स प्रौद्योगिकी स्टैक का एक महत्वपूर्ण हिस्सा होता है, चाहे वह मुख्य रूप से स्ट्रीमिंग लॉग डेटा के विज़ुअलाइज़ेशन और विश्लेषण के लिए उपयोग किया जाता हो या ऑनलाइन-शॉपिंग कार्यक्षमता के लिए खोज (ऑटो-कम्प्लीशन, फेसेटेड खोज, और समानार्थी शब्द) के लिए।

• ब्लैक फ्राइडे से 2 दिन पहले, स्नैपशॉट लेने की आवृत्ति बढ़ाएं। हम खरीदारी सप्ताहांत के दौरान प्रति दिन 2-3 बार स्नैपशॉट लेने का सुझाव देते हैं, और फिर साइबर मंडे के बाद सामान्य बैकअप शेड्यूल पर लौट आते हैं। हम इन स्नैपशॉट को पीक ट्रैफिक से पहले और फिर पीक ट्रैफिक के बाद शेड्यूल करने का सुझाव देते हैं - और एक आपके द्वारा चुने गए समय पर। क्योंकि Elasticsearch बैकअप डिफ के रूप में किए जाते हैं, दिन में 3 बार स्नैपशॉट लेने से स्नैपशॉट की अवधि काफी कम रहती है।
• यदि आप Elasticsearch का उपयोग मुख्य रूप से लॉग फाइलों को विज़ुअलाइज़ करने के लिए करते हैं:
  • इवेंट के दौरान बढ़ी हुई डेटा खपत के लिए योजना बनाएं।
  • सुनिश्चित करें कि Kibana डैशबोर्ड सबसे महत्वपूर्ण लॉग और इवेंट का विश्लेषण करने के लिए उपयुक्त सेटिंग्स के साथ अद्यतित हैं।
  • अपने एग्रीगेशन/डैशबोर्ड में अपने बेसलाइन को जानें ताकि आप स्पाइक्स और मुद्दों की पहचान कर सकें। कुछ उपयोग के मामले Elastalert एकीकरण से विभिन्न इवेंट पर अलर्ट करने से लाभान्वित हो सकते हैं।
• यदि आप Elasticsearch का उपयोग मुख्य रूप से खोज कार्यक्षमता के लिए करते हैं:
  • चूंकि ये रीड-हैवी दिन होने की संभावना है, आप चाहेंगे:
    • अतिरिक्त एक्टिव थ्रेड पूल प्राप्त करने के लिए नोड काउंट बढ़ाएं
    • अधिक स्थानों से पढ़ने के लिए रेप्लिका काउंट बढ़ाएं
• Elasticsearch के टूल Rally का उपयोग करके बेंचमार्किंग टेस्ट करें यह देखने के लिए कि क्या वर्तमान Elasticsearch क्लस्टर वर्तमान नियोजित खोज थ्रूपुट को संभाल सकता है।
• किसी भी अतिरिक्त त्रुटियों के लिए Elasticsearch लॉग की जांच करें जो फेंकी जा सकती हैं।
• सुनिश्चित करें कि सभी एप्लिकेशन सभी 4 कनेक्शन एंडपॉइंट का उपयोग कर रहे हैं।
• वर्तमान स्लो क्वेरी को देखें, और यदि आप क्वेरी का विश्लेषण या सुधार करने में सहायता चाहते हैं, तो अपनी ObjectRocket टीम से संपर्क करें।

Redis प्रो टिप्स

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

• यदि आप Redis का उपयोग सेशन स्टोर या कैश के रूप में कर रहे हैं, तो आकार बढ़ाने पर विचार करें यदि आपको लगता है कि बढ़े हुए ब्लैक फ्राइडे ट्रैफिक के साथ आप मेमोरी या बैंडविड्थ सीमा तक पहुंच सकते हैं।
• पुष्टि करें कि आप किसी भी की पर TTL ("टाइम टू लिव" की समाप्ति समय निर्धारित करता है) सेट कर रहे हैं जो स्वचालित रूप से समाप्त हो सकती हैं और होनी चाहिए।
• पुष्टि करें कि maxmemory-policy उचित रूप से सेट है यदि आप मेमोरी से बाहर निकलते हैं। यदि आपको अपने इंस्टेंस पर इस सेटिंग को संशोधित करने की आवश्यकता है तो ObjectRocket सपोर्ट से संपर्क करें।
• प्रोडक्शन इंस्टेंस के लिए, ट्रैफिक में किसी भी स्पाइक से पहले स्वस्थ मेमोरी फ्रैगमेंटेशन अनुपात सुनिश्चित करें।
• यदि आप किसी जॉब क्यू मैनेजमेंट फ्रेमवर्क के लिए बैकएंड के रूप में Redis का उपयोग कर रहे हैं, तो हम इस फ्रेमवर्क के लिए डैशबोर्ड रखने और जॉब स्टेटस की निगरानी करने की अत्यधिक अनुशंसा करते हैं। ऐसे डैशबोर्ड के कुछ उदाहरण हैं resque-web, arena, sideqik।
• यह जितना आकर्षक लग सकता है, अभियान से ठीक पहले flushdb, flushall, या अन्य बड़े डिलीशन ऑपरेशन न चलाएं; इसके बजाय, एक SCAN और DEL स्क्रिप्ट लिखें।
• वर्तमान प्रविष्टियों के लिए COMMANDSTATS लॉग और SLOWLOG लॉग की जांच करें और देखें कि किन पैटर्न को ऑप्टिमाइज़ किया जा सकता है, ताकि आप ब्लॉकिंग ऑपरेशन में न चलें। "KEYS * " और अन्य लंबे समय तक चलने वाले ऑपरेशन के उपयोग से बचें।
• डेवलपमेंट इंस्टेंस (प्रोडक्शन नहीं!) पर, MONITOR कमांड से आउटपुट देखते हुए स्ट्रेस टेस्ट चलाएं ताकि पैटर्न का विश्लेषण किया जा सके।
• सैंपल डेटा के साथ डेवलपमेंट इंस्टेंस पर, अपने डेटा वितरण और मेमोरी उपयोग का विश्लेषण करने के लिए rdb-tools, redis-cli –bigkeys, और redis-cli –memkeys का उपयोग करें।
• एक एजेंट सेटअप करें जो आपके इंस्टेंस की निगरानी को आपके मौजूदा स्टैट्स प्लेटफॉर्म में एकीकृत करता है। उदाहरण: Datadog, New Relic, Prometheus।

ObjectRocket आपके साथ साझेदारी में क्या करता है

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

यहां कुछ उदाहरण हैं जो आपकी ObjectRocket टीम करती है:

• स्लो क्वेरी विश्लेषण: हम उन क्वेरी के लिए सलाह प्रदान कर सकते हैं जो इष्टतम से अधिक समय ले रही हैं (उदाहरण के लिए, Elasticsearch में कोई भी क्वेरी जो 1 सेकंड से अधिक समय लेती है वह सब-ऑप्टिमल है)।
  • क्लस्टर पर स्लो क्वेरी के लिए लॉगिंग सक्षम होना चाहिए - (हमारे ग्राहक इसका अनुरोध कर सकते हैं) और फिर - एक या दो दिन के डेटा होने के बाद - हम उन क्वेरी की संख्या देखते हैं जिन्होंने परिभाषित इष्टतम सेकंड से अधिक समय लिया और फिर उन्हें क्वेरी प्रोफाइलर के माध्यम से चलाते हैं, जो क्वेरी के सबसे महंगे हिस्से की पहचान करता है। फिर हम अपने ग्राहक के साथ परामर्श करते हैं और क्वेरी समय कम करने के तरीके पर सलाह प्रदान करते हैं।
• परफॉरमेंस ट्यूनिंग: यह एक और क्षेत्र है जहां हम अपने ग्राहकों के लिए अनऑप्टिमाइज़्ड ऑपरेशन को ट्यून करने में कुछ समय बिताते हैं, विशेष रूप से:
• • खराब रेगेक्स क्वेरी आपके डेटाबेस को क्रॉल तक धीमा कर सकती हैं। रेगेक्स क्वेरी के लिए किए जा सकने वाले कुछ ऑप्टिमाइज़ेशन के लिए हमारे ब्लॉग पोस्ट का संदर्भ लें।
  • कलेक्शन स्कैन की आवश्यकता वाली क्वेरी। ये ऑपरेशन काफी महंगे हो सकते हैं क्योंकि वे अक्सर बहुत सारे डॉक्यूमेंट स्कैन करते हैं और केवल कुछ वापस करते हैं (यानी वे इंडेक्स का उपयोग नहीं करते)।
  • नॉन-परफॉरमेंट ऑपरेटर्स का उपयोग करने वाले ऑपरेशन अक्सर बहुत सारे डॉक्यूमेंट और इंडेक्स कीज़ की जांच करते हैं, इसलिए जहां संभव हो, $ne, $exists: true, $nin. जैसे ऑपरेटर्स के उपयोग से बचें।

• इंडेक्सिंग: उचित इंडेक्स होना अक्सर सबसे महत्वपूर्ण कार्य होता है, और इसी तरह हमारे अधिकांश ग्राहक ब्लैक फ्राइडे से बचे हैं। हम इंस्टेंस को प्रोफाइल कर सकते हैं ताकि यह सुनिश्चित हो सके कि अधिकांश ऑपरेशन के लिए उचित इंडेक्स मौजूद हैं, और यदि अतिरिक्त इंडेक्स की आवश्यकता है, तो हम उन्हें बनाने के लिए आपके साथ काम करते हैं।
• लोड टेस्टिंग और स्केलिंग — अनुरोध पर, हम अपेक्षित ट्रैफिक वृद्धि से पहले उनका अनुकरण करने के लिए लोड टेस्टिंग का समन्वय कर सकते हैं। यह सुनिश्चित करने के लिए अनिवार्य है कि अनुमानित वृद्धि और ट्रैफिक स्पाइक्स के दौरान आपके एप्लिकेशन का परफॉरमेंस इष्टतम रहे।
• मेंटेनेंस मोरेटोरियम — हम इस बात की सराहना करने आए हैं कि हमारे ग्राहक इस समय हम पर बहुत निर्भर करते हैं और एक मेंटेनेंस मोरेटोरियम लागू किया है। इसका मतलब है कि नवंबर की शुरुआत और जनवरी की शुरुआत के बीच इंफ्रास्ट्रक्चर मेंटेनेंस वर्क पर एक सॉफ्ट फ्रीज प्रभावी है। इस दौरान केवल आपातकालीन मेंटेनेंस की अनुमति होगी जो एक कठोर अनुमोदन प्रक्रिया से गुजरे हैं।
• 24x7x365 सपोर्ट — ObjectRocket सपोर्ट टीम आपकी आवश्यकताओं को पूरा करने के लिए चौबीसों घंटे तैनात है। हमारे DBAs और डेटा प्रौद्योगिकी विशेषज्ञों की टीम ब्लैक फ्राइडे और साइबर मंडे के पागलपन के अनुभवी दिग्गज हैं; वे इस महत्वपूर्ण अवधि से पहले, दौरान, और बाद में आपके लिए यहां हैं!

हमेशा की तरह, ObjectRocket सपोर्ट तक पहुंचने का सबसे अच्छा तरीका हमें support@objectrocket.com पर ईमेल करना है। हमें बताएं कि हम कैसे मदद कर सकते हैं, और हैप्पी ब्लैक फ्राइडे!