जब क्लाउड सेवा की क्षमताएं पहले से ही कम होती जा रही हैं, और बॉक्सिंग संस्करण के लिए संक्रमण को कॉर्पोरेट पोर्टल और सीआरएम सिस्टम के आगे विकास के लिए अगले तार्किक कदम के रूप में देखा जाता है, तो कंपनियों के लिए यह सवाल उठता है कि यह कैसे करें, उनका क्या इंतजार है और हस्तांतरण के बाद भी सब कुछ बना रहेगा?
ऐसा लगता है कि सब कुछ काफी सरल है:
- बॉक्स के साथ मेजबान का विस्तार करें;
- हम तकनीकी सहायता लिख रहे हैं;
- हम एक बैकअप का आदेश देते हैं;
- हम इसे प्राप्त करने के लिए तत्पर हैं;
- हम बैकअप को तैनात करते हैं और बॉक्सिंग संस्करण की व्यापक संभावनाओं का आनंद लेते हैं।
लेकिन अभ्यास से पता चलता है कि क्लाउड से बॉक्सिंग संस्करण में संक्रमण तुच्छ से दूर है और इसके लिए एक स्पष्ट कार्य योजना, संभावित जोखिमों का विश्लेषण और इस तथ्य के लिए तैयारियों की आवश्यकता है कि सब कुछ गलत हो जाएगा।
हमें बिट्रिक्स 24 क्लाउड पर आधारित अत्यधिक लोड सीआरएम-सिस्टम के साथ एक बड़े डेवलपर द्वारा संपर्क किया गया था। सीआरएम में सक्रिय रूप से काम करने वाली कंपनी की कई शाखाओं से बिक्री प्रबंधक, पोर्टल को स्वचालित रूप से लीड बनाने के लिए, ग्राहकों के साथ बातचीत रिकॉर्ड करने और सीआरएम में ग्राहक के कार्ड में रिकॉर्ड कॉल तथ्यों के साथ तारांकित आईपी टेलीफोनी के साथ एकीकृत किया गया था। विभिन्न चैनलों के माध्यम से सीआरएम में प्रति दिन 100 से अधिक लीड बनाए गए थे।
यह स्पष्ट था कि बॉक्सिंग संस्करण में स्थानांतरण के दौरान किसी भी सरल समय में ग्राहक को भारी नुकसान होता है। संक्रमण की गंभीरता और संभावित जोखिमों के बारे में ग्राहक के साथ बात करने के बाद, हमने काम करना तय किया।
सबसे पहले, हमने क्लाउड को बॉक्स में स्थानांतरित करने पर मौजूदा मामलों और प्रकाशनों का विश्लेषण किया, त्रुटियों की एक विस्तृत चेकलिस्ट बनाई, जिससे हम सामना कर सकते हैं:
- क्लाउड में चल रहे एप्लिकेशन बॉक्स पर नहीं हैं;
- क्लाउड संस्करण और बॉक्स के लिए अनुप्रयोगों के लिए लाइसेंस की लागत भिन्न हो सकती है;
- स्थानांतरण के दौरान एक समय अंतराल के कारण कुछ डेटा खोने का जोखिम;
- विभिन्न शाखाओं के कुछ उपयोगकर्ता स्थानांतरण के बाद क्लाउड सेवा पर काम करना जारी रखेंगे, और सीआरएम में बनाई गई संस्थाओं को अतिरिक्त रूप से खोजना और स्थानांतरित करना आवश्यक होगा;
- बंद पोर्टल पर, सेवा का मोबाइल एप्लिकेशन काम नहीं करेगा;
- स्थानांतरण के बाद, कुछ उपयोगकर्ता अपने पुराने पासवर्ड के साथ लॉग इन नहीं कर पाएंगे;
- चैट बॉट में खराबी हो सकती है;
- पोर्टल पर काम करते समय लगातार प्राधिकरण रीसेट;
- कार्य टिप्पणियों का केवल एक हिस्सा प्रदर्शित किया जा सकता है;
- डेटाबेस एक खोज इंडेक्स के बिना होगा।
इसके बाद, भूमिकाओं के टूटने के साथ कार्यों का एक स्पष्ट एल्गोरिथ्म संकलित किया गया था, जिसे ठेकेदार और ग्राहक दोनों द्वारा निष्पादित किया जाना था:
1 चरण (तात्कालिकता माध्यम)- उत्पादन पर्यावरण (ठेकेदार) की तैनाती;
- तैनात पर्यावरण (ठेकेदार) का परीक्षण;
- मेजबानों (ठेकेदार) पर बॉक्सिंग संस्करण की तैनाती;
- टेलीफोनी के लिए एक एसएसएल प्रमाणपत्र की खरीद और स्थापना (ग्राहक-खरीद, ठेकेदार-स्थापना);
- बॉक्सिंग संस्करण का परीक्षण - प्रदर्शन, पैरामीटर, आंतरिक परीक्षण (ठेकेदार)।
- प्री-प्रोडक्शन पर्यावरण की तैनाती - उत्पादन (ठेकेदार) की एक पूरी प्रति।
2 चरण (तात्कालिकता)- बैकअप अनलोड करने के लिए आवेदन। बैकअप तिथि (ग्राहक) की सेवा के तकनीकी समर्थन के साथ समन्वय;
- उपयोगकर्ताओं को बैकअप तिथि के बारे में सूचित करना और सीआरएम (ग्राहक) से जानकारी के अस्थायी भंडारण के लिए एक योजना तैयार करना;
- उत्पादन (ठेकेदार) पर एक बैकअप की तैनाती;
- बैकअप (ठेकेदार) के बाद पोर्टल स्थापित करना;
- पोर्टल (ग्राहक) के साथ काम करने के लिए एक टेलीफोनी सर्वर स्थापित करना;
- एक टेलीफोनी मॉड्यूल (ठेकेदार) की स्थापना;
- प्रारंभिक टेलीफोनी परीक्षण (ग्राहक);
- सीआरएम, टेलीफोनी, सीआरएम व्यापार प्रक्रियाओं (ग्राहक बिक्री विभाग) का गहराई से परीक्षण;
- स्वास्थ्य कथन। परीक्षण डेटा का विलोपन (ग्राहक);
- क्लाउड सेवा (ग्राहक) में बिक्री प्रबंधकों को रोकना;
- क्लाउड संस्करण से बॉक्स (ठेकेदार) में बैकअप बनाने के क्षण से लेनदेन, लीड, संपर्कों का स्थानांतरण;
- बॉक्सिंग संस्करण (ग्राहक) पर बिक्री प्रबंधकों के काम की शुरुआत।
3 चरण (तात्कालिकता कम)- 2-3 दिनों के भीतर बॉक्सिंग संस्करण का परीक्षण करना (ग्राहक);
- पूर्ण प्रदर्शन (ग्राहक) की स्वीकृति;
- प्री-प्रोडक्शन अपडेट करना - प्रोडक्शन (ठेकेदार) की पूरी कॉपी ट्रांसफर करना।
इस योजना को तैयार करने और संभावित त्रुटियों के साथ एक चेकलिस्ट होने के बाद, हमने महसूस किया कि बड़ी संख्या में अनिश्चितताओं के कारण हमारे बहुत जोखिम हैं:
- सेवा कितनी तेजी से बैकअप प्रदान करेगी?
- सीआरएम डेटाबेस विशाल है, यह देखते हुए कि बैकअप को लागू करने में कितना समय लगता है?
- सीआरएम के साथ सही ढंग से काम करने के लिए मैं कितनी जल्दी मॉड्यूल और टेलीफोनी सर्वर को फिर से कॉन्फ़िगर कर सकता हूं?
- पोर्टल पर कौन से विशिष्ट कीड़े दिखाई दे सकते हैं, वे उपयोगकर्ताओं के काम करने के लिए कितने महत्वपूर्ण होंगे और उन्हें ठीक करने में कितना समय लग सकता है?
हमें एहसास हुआ कि हमारे पास एक अनिश्चित समय अंतराल है, जो, जैसे-जैसे बढ़ता है, ग्राहक को अधिक से अधिक नुकसान पहुंचाएगा। समय अंतराल को कम करने के लिए, यह समझना आवश्यक था कि हम पोर्टल को पोर्ट करने और उसे डिबग करने में कितना समय देते हैं।
इसलिए हम इस निष्कर्ष पर पहुंचे कि क्लाउड से एक बैकअप पर्याप्त नहीं होगा, और नुकसान को कम करने के लिए एक बैकअप को तैनात करना आवश्यक है - सभी संभावित जोखिमों की पहचान करने और समय अंतराल का अनुमान लगाने के लिए, और फिर दूसरा बैकअप जिसे हम इस तरह से योजना बना सकते हैं जैसे कि घाटे को कम करने के लिए। ।
बिट्रिक्स केवल एक बैकअप और केवल एक बार प्रदान करता है, क्योंकि क्लाउड से बॉक्स में स्थानांतरित करने की प्रक्रिया तकनीकी रूप से जटिल है। तकनीकी सहायता की ओर मुड़ने और ग्राहक को इस मुद्दे से जोड़ने के लिए, हमें अभी भी अलग-अलग समय पर क्लाउड से दो बैकअप प्रदान करने के लिए आगे बढ़ना है। पहले बैकअप के समय पर सहमति हुई और हस्तांतरण का काम शुरू हुआ।
वॉल्यूम, गति और टूटे हुए हिस्से
यह समझने के लिए कि हमें कितना और क्या समय लगेगा, हमने एक पत्रिका रखना शुरू किया जिसमें हमने हर कदम दर्ज किया।
इसलिए, पोर्टल ने गुरुवार रात को सेवा का बैकअप लेना शुरू कर दिया, अर्थात, सीआरएम में गुरुवार के अंत में नवीनतम डेटा था, और हमें शुक्रवार दोपहर बैकअप के लिए लिंक प्रदान किया। यहां हमने पहली कठिनाई का सामना किया - बैकअप का वजन लगभग 30 जीबी था, और अमेज़ॅन डॉट कॉम सर्वर से क्लाउड की मेजबानी की डाउनलोड गति आदर्श से दूर थी (औसतन 800 Kb / s)। लगभग उस समय की गणना के दौरान, जिसके दौरान बैकअप के कई हिस्सों को लोड किया गया था, हमने महसूस किया कि कुल में केवल बैकअप डाउनलोड करने में लगभग 10 घंटे लगेंगे।
अगली समस्या बैकअप के विभिन्न भागों के पंपिंग के दौरान त्रुटियों की उपस्थिति थी, जो केवल तैनात होने पर पता चला था। इन भागों, एक नियम के रूप में, एक हैश मिसमैच त्रुटि भी हुई, क्योंकि इसकी वजह से एरर टेक्स्ट में आर्काइव के टूटे हुए हिस्से की पहचान करना और इसे SSH के माध्यम से मैन्युअल रूप से ट्रांसफर करना था, जिसके बाद अनपैकिंग को पूरे बैकअप की स्क्रैच से फिर से शुरू किया गया था।
अपने मेजबानों पर बैकअप को सफलतापूर्वक डाउनलोड करने और तैनात करने के बाद, हमें बॉक्स में क्लाउड की एक कार्यशील प्रति प्राप्त हुई और पोर्टल पर अगले चरण - परीक्षण और डिबगिंग पर चला गया।
मामूली कीड़े और कपटी धक्का और पुल
हमारे आश्चर्य के लिए, बॉक्स परीक्षण अपेक्षाकृत सुचारू रूप से चला गया। हमने सीआरएम का परीक्षण किया, सेवा के सभी उपकरणों के माध्यम से चला गया, दूत की कार्यक्षमता की जांच की, आंतरिक परीक्षण किए और केवल 3 त्रुटियां बताईं:
- मेसेंजर में फाइल अटैचमेंट आइकन गायब हो गया और मेसेंजर में फाइल भेजने से काम नहीं चला;
- सूचनाओं के लिंक में डोमेन के बिना एक पता था, उदाहरण के लिए: कंपनी / व्यक्तिगत / उपयोगकर्ता / 1250 / कार्य / कार्य / दृश्य , क्रमशः काम नहीं कर रहे थे;
- कुछ उपयोगकर्ता गलत लॉगिन / पासवर्ड त्रुटि के साथ पोर्टल पर लॉग इन नहीं कर सके।
हम अग्रिम में स्थानांतरण के बाद लॉग इन करने में असमर्थता के बारे में जानते थे, सेवा तुरंत बैकअप प्रदान करते समय इस बारे में चेतावनी देती है। दुर्भाग्य से, यह समस्या केवल उपयोगकर्ता द्वारा पासवर्ड पुनर्प्राप्त करने या मैन्युअल रूप से व्यवस्थापक द्वारा प्रत्येक उपयोगकर्ता के लिए पासवर्ड बदलने से हल की जा सकती है, क्योंकि बिट्रिक्स 24.Network से पासवर्ड पोर्टल पर संग्रहीत नहीं हैं।
सूचनाओं में लिंक के साथ त्रुटि को जल्दी से हल किया गया था - साइट सेटिंग्स में पोर्टल डोमेन और मुख्य मॉड्यूल की सेटिंग्स को पंजीकृत करके।
लेकिन मैसेंजर में गुम फ़ाइल अटैचमेंट आइकन ने कुछ चिंताएं दूर कीं। कार्य ने लापता आइकन के कारण को समझने के असफल प्रयासों के एक और दो घंटे ले लिए। नतीजतन, हमने पाया कि इसका कारण डिस्क मॉड्यूल में होने से दूर था, जैसा कि मूल रूप से माना जाता था। कारण पुश एंड पुल मॉड्यूल की सेटिंग में डिस्कनेक्ट किए गए पुश सर्वर में निहित है, जो मैसेंजर में फ़ाइल ट्रांसफर को स्वचालित रूप से बंद कर देता है।
अंतिम परीक्षण
पोर्टल के सफल परीक्षण और डिबगिंग के बाद, ग्राहक के लिए एक विस्तृत रिपोर्ट तैयार की गई और अगला कदम सीआरएम ग्राहक बिक्री विभाग द्वारा पूरी तरह से परीक्षण किया गया, साथ ही साथ बॉक्स और परीक्षण कॉल के साथ काम करने के लिए टेलीफोनी सर्वर स्थापित किया गया।
परीक्षण के दौरान, महत्वपूर्ण समस्याओं की पहचान नहीं की गई थी। हमने एक परीक्षण होस्ट की तैनाती की और उस पर मुकाबला पोर्टल की एक पूरी प्रतिलिपि बनाई, जिसमें हमारे पास पोर्टल का 100% कार्यशील संस्करण था और जिसके अनुसार यदि हम पहले बैकअप का परीक्षण नहीं कर रहे थे तो गैर-मानक त्रुटियां हुईं थीं, तो हम सेटिंग्स में तुलना कर सकते हैं।
पोर्टल की एक प्रति तैनात करने के बाद, हम पत्रिका के विश्लेषण के लिए आगे बढ़े, जिसमें हमने त्रुटियों को हल किया और उन्हें हल करने का समय दिया। पत्रिका का विस्तार से विश्लेषण करने के बाद, हमने दूसरे बैकअप को स्थानांतरित करने की योजना को अद्यतन किया, महसूस किया कि हम अंतिम हस्तांतरण के दौरान कितना नुकसान उठा सकते हैं, और क्लाउड संस्करण से खोए हुए लीड के मैन्युअल आयात के लिए अतिरिक्त समय निर्धारित कर सकते हैं। ग्राहक के साथ सभी विवरणों और जोखिमों पर भी चर्चा की गई और दूसरा बैकअप तैयार करने के अनुरोध के साथ सेवा के तकनीकी समर्थन के लिए एक पत्र भेजा गया।
दूसरा बैकअप और सब कुछ गलत क्यों हो सकता है?
गुरुवार को भी बैकअप निर्माण समय पर सहमत होने के बाद, हमने शुक्रवार को दोपहर 12 बजे तक परिचालन कार्यों के लिए टीम तैयार की। 12-13 घंटों के क्षेत्र में, हमें लंबे समय से प्रतीक्षित लिंक मिला और डाउनलोड करना शुरू कर दिया। कुछ घंटों बाद यह स्पष्ट था कि संग्रह 10 घंटे के लिए पंप नहीं किया जाएगा, लेकिन लगभग 14! इस दिन हमारे प्रदाता और Amazon.com सर्वर के चैनल की बैंडविड्थ वांछित होने के लिए बहुत कुछ छोड़ दिया है। हम रात के काम की तैयारी कर रहे थे, क्योंकि लीड लगातार गिर रही थी और ग्राहक टेलीफोनी सर्वर की स्थापना शुरू करने के लिए एक रिपोर्ट की प्रतीक्षा कर रहा था।
जैसा कि अक्सर होता है, सब कुछ योजना के अनुसार नहीं हुआ। अगला चरण क्लाउड संस्करण से संचित लीड को बॉक्स में स्थानांतरित करना था - प्रक्रिया सरल और स्पष्ट है, लेकिन इसकी अपनी बारीकियों है। यदि लीड की सूची में आप उन लीड्स का चयन करते हैं जिन्हें निर्यात करने की आवश्यकता है और "CSV को निर्यात करें" पर क्लिक करें, तो CRM में सभी मौजूदा लीड्स केवल चयनित नहीं हैं, अनलोड किए जाएंगे। यह तर्कसंगत है कि एक बड़े लीड डेटाबेस के साथ, क्लाउड त्रुटि में गिर गया। समाधान एक फिल्टर का उपयोग करना था, केवल इस मामले में लीड सही ढंग से अनलोड किए गए थे।
आगे का परीक्षण आश्चर्य के बिना पारित हो गया, जैसा कि हम पहले से ही जानते थे: क्या काम नहीं करेगा, इसे कैसे ठीक किया जाए और कहां। सफलतापूर्वक जुड़े हुए और टेलीफोनी का परीक्षण करने के बाद, सोमवार को बिक्री प्रबंधक पहले से ही पूरी तरह से बॉक्स वाले संस्करण में सीआरएम के साथ काम करते थे। और पहले से ही एक सप्ताह के लिए कार्य क्रम में हमने पोर्टल को ट्यून किया, बैकअप किया, परीक्षण मेजबान को पोर्टल की एक अंतिम प्रति बनाया।
संपूर्ण स्थानांतरण प्रक्रिया में योजना के क्षण से लेकर अंतिम सेटिंग्स तक लगभग एक सप्ताह का समय लगा।
परिणामस्वरूप, मैं इस तरह की जटिल और जोखिम भरी परियोजनाओं की योजना बनाने, प्रक्रिया में ग्राहक की अनिवार्य भागीदारी और संभावित जोखिमों को बोलने के महत्व को नोट करना चाहूंगा, हालांकि, अभ्यास से पता चलता है, योजना से विचलन कोई अपवाद नहीं हैं।