भले ही यह बाढ़ हो, 1C को काम करना चाहिए! हम डीआर पर व्यवसाय से सहमत हैं

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

वर्णित कहानी कोई कल्पना नहीं है, बल्कि 2020 की कुछ घटनाओं का सामूहिक वर्णन है। बड़ी कंपनियों में, एक आपदा पुनर्प्राप्ति योजना, या आपदा पुनर्प्राप्ति योजना (डीआरपी), इस मामले के लिए हमेशा तैयार रहती है। निगमों में, यह व्यवसाय निरंतरता विशेषज्ञों की जिम्मेदारी है। लेकिन मध्यम और छोटी कंपनियों में ऐसी समस्याओं का समाधान आईटी सेवाओं पर पड़ता है। आपको व्यावसायिक तर्क को स्वयं समझने की आवश्यकता है, समझें कि क्या विफल हो सकता है और कहां, सुरक्षा के साथ आएं और इसे लागू करें। 

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

एक वास्तुकार की स्थिति से, मैं आपको बताऊंगा कि इस स्थिति से कैसे बचा जाए। लेख के पहले भाग में, मैं प्रारंभिक कार्य दिखाऊंगा: सुरक्षा उपकरण चुनने के लिए ग्राहक के साथ तीन प्रश्नों पर चर्चा कैसे करें: 

• हम किसकी रक्षा कर रहे हैं?
• हम किससे रक्षा कर रहे हैं?
• हम कितना बचाव करते हैं? 

दूसरे भाग में, हम प्रश्न का उत्तर देने के विकल्पों के बारे में बात करेंगे: अपना बचाव कैसे करें। मैं ऐसे मामलों का उदाहरण दूंगा कि विभिन्न ग्राहक अपनी सुरक्षा कैसे बनाते हैं।

हम क्या सुरक्षा करते हैं: महत्वपूर्ण व्यावसायिक कार्यों की पहचान करना 

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

एक आईटी पेशेवर को कई कारणों से ऐसी बातचीत में कठिनाई हो सकती है:

• आईटी सेवा व्यवसाय में सूचना प्रणाली की भूमिका को पूरी तरह से नहीं समझती है। उदाहरण के लिए, यदि व्यावसायिक प्रक्रियाओं या पारदर्शी व्यवसाय मॉडल का कोई विवरण उपलब्ध नहीं है। 
• पूरी प्रक्रिया आईटी सेवा पर निर्भर नहीं है। उदाहरण के लिए, जब काम का कुछ हिस्सा ठेकेदारों द्वारा किया जाता है, और आईटी विशेषज्ञों का उन पर सीधा प्रभाव नहीं होता है।

मैं बातचीत को इस तरह से संरचित करूंगा: 

1. हम व्यवसायों को समझाते हैं कि दुर्घटनाएँ हर किसी के साथ होती हैं, और पुनर्प्राप्ति में समय लगता है। सबसे अच्छी बात यह है कि स्थितियों को प्रदर्शित किया जाए कि यह कैसे होता है और इसके क्या परिणाम संभव हैं।
2. हम दिखाते हैं कि सब कुछ आईटी सेवा पर निर्भर नहीं करता है, लेकिन आप अपनी जिम्मेदारी के क्षेत्र में एक कार्य योजना के साथ मदद करने के लिए तैयार हैं।
3. हम व्यवसाय ग्राहक से उत्तर देने के लिए कहते हैं: यदि सर्वनाश होता है, तो सबसे पहले कौन सी प्रक्रिया बहाल की जानी चाहिए? इसमें कौन भाग लेता है और कैसे? 

   व्यवसाय की ओर से एक सरल उत्तर की आवश्यकता है, उदाहरण के लिए: कॉल सेंटर को 24/7 आवेदनों का पंजीकरण जारी रखना होगा।

4. हम सिस्टम के एक या दो उपयोगकर्ताओं से इस प्रक्रिया का विस्तार से वर्णन करने के लिए कहते हैं। 
   यदि आपकी कंपनी में कोई विश्लेषक है तो मदद के लिए उसे शामिल करना बेहतर है।

   आरंभ करने के लिए, विवरण इस तरह दिख सकता है: कॉल सेंटर को फोन, मेल और वेबसाइट से संदेशों के माध्यम से आवेदन प्राप्त होते हैं। फिर वह उन्हें वेब इंटरफ़ेस के माध्यम से 1C में प्रवेश करता है, और उत्पादन उन्हें इस तरह से वहां से ले जाता है।

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

6. हम विफलता के संभावित बिंदुओं का पता लगाते हैं: सिस्टम नोड्स जिस पर सेवा का प्रदर्शन निर्भर करता है। हम अलग से उन नोड्स को नोट करते हैं जो अन्य कंपनियों द्वारा समर्थित हैं: टेलीकॉम ऑपरेटर, होस्टिंग प्रदाता, डेटा सेंटर, इत्यादि। इससे आप अगले चरण के लिए बिजनेस ग्राहक के पास लौट सकते हैं।

हम किससे रक्षा करते हैं: जोखिम

इसके बाद, हम व्यावसायिक ग्राहक से यह पता लगाते हैं कि हम पहले किन जोखिमों से खुद को बचाते हैं। सभी जोखिमों को दो समूहों में विभाजित किया जा सकता है: 

• सेवा डाउनटाइम के कारण समय की हानि;
• भौतिक प्रभावों, मानवीय कारकों आदि के कारण डेटा की हानि।

व्यवसाय डेटा और समय दोनों खोने से डरते हैं - इन सब से धन की हानि होती है। तो फिर हम प्रत्येक जोखिम समूह के लिए प्रश्न पूछते हैं: 

• इस प्रक्रिया के लिए, क्या हम अनुमान लगा सकते हैं कि डेटा हानि और समय हानि में कितना पैसा खर्च होता है? 
• हम कौन सा डेटा नहीं खो सकते? 
• हम कहाँ डाउनटाइम की अनुमति नहीं दे सकते? 
• कौन सी घटनाएँ हमारे लिए सबसे अधिक संभावित और सबसे अधिक खतरनाक हैं?

चर्चा के बाद, हम समझेंगे कि विफलता बिंदुओं को कैसे प्राथमिकता दी जाए। 

हम कितनी सुरक्षा करते हैं: आरपीओ और आरटीओ 

जब विफलता के महत्वपूर्ण बिंदु स्पष्ट होते हैं, तो हम आरटीओ और आरपीओ संकेतकों की गणना करते हैं। 

मुझे याद है कि आरटीओ (वसूली समय उद्देश्य) - यह दुर्घटना के क्षण से लेकर सेवा पूरी तरह से बहाल होने तक का स्वीकार्य समय है। व्यावसायिक भाषा में, यह स्वीकार्य डाउनटाइम है। यदि हम जानते हैं कि इस प्रक्रिया में कितना पैसा आया, तो हम डाउनटाइम के प्रत्येक मिनट से होने वाले नुकसान की गणना कर सकते हैं और स्वीकार्य नुकसान की गणना कर सकते हैं। 

आरपीओ (पुनर्प्राप्ति बिंदु उद्देश्य) - वैध डेटा पुनर्प्राप्ति बिंदु। यह उस समय को निर्धारित करता है जिसके दौरान हम डेटा खो सकते हैं। उदाहरण के लिए, व्यावसायिक दृष्टिकोण से, डेटा हानि के परिणामस्वरूप जुर्माना हो सकता है। इस तरह के नुकसान को पैसों में भी बदला जा सकता है. 

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

आइए एक विशिष्ट उदाहरण देखें. उपयोगकर्ता 1C में लॉग इन करता है, सिस्टम डेटाबेस त्रुटि के साथ खुलता है। वह सिस्टम एडमिनिस्ट्रेटर से संपर्क करता है। डेटाबेस क्लाउड में स्थित है, सिस्टम प्रशासक सेवा प्रदाता को समस्या की रिपोर्ट करता है। मान लीजिए कि सभी संचारों में 15 मिनट लगते हैं। क्लाउड में, इस आकार के डेटाबेस को एक घंटे में बैकअप से पुनर्स्थापित किया जाएगा, इसलिए, सेवा प्रदाता की ओर से आरटीओ एक घंटे का है। लेकिन यह अंतिम समय सीमा नहीं है, यूजर के लिए समस्या का पता लगाने के लिए इसमें 15 मिनट जोड़े गए हैं। 
 
इसके बाद, सिस्टम प्रशासक को यह जांचना होगा कि डेटाबेस सही है, इसे 1सी से कनेक्ट करें और सेवाएं शुरू करें। इसके लिए एक और घंटे की आवश्यकता है, जिसका अर्थ है कि प्रशासक की ओर से आरटीओ के पास पहले से ही 2 घंटे 15 मिनट हैं। उपयोगकर्ता को और 15 मिनट चाहिए: लॉग इन करें, जांचें कि आवश्यक लेनदेन सामने आए हैं। इस उदाहरण में 2 घंटे 30 मिनट कुल सेवा पुनर्प्राप्ति समय है।

ये गणनाएँ व्यवसाय को दिखाएंगी कि पुनर्प्राप्ति अवधि किन बाहरी कारकों पर निर्भर करती है। उदाहरण के लिए, यदि कार्यालय में पानी भर गया है, तो आपको सबसे पहले रिसाव का पता लगाना होगा और उसे ठीक करना होगा। इसमें समय लगेगा, जो आईटी पर निर्भर नहीं है.  

हम कैसे सुरक्षा करते हैं: विभिन्न जोखिमों के लिए उपकरण चुनना

सभी बिंदुओं पर चर्चा करने के बाद, ग्राहक पहले से ही व्यवसाय के लिए एक दुर्घटना की लागत को समझता है। अब आप उपकरण चुन सकते हैं और बजट पर चर्चा कर सकते हैं। ग्राहक मामलों के उदाहरणों का उपयोग करते हुए, मैं आपको दिखाऊंगा कि हम विभिन्न कार्यों के लिए कौन से उपकरण पेश करते हैं। 

आइए जोखिमों के पहले समूह से शुरू करें: सेवा डाउनटाइम के कारण नुकसान। इस समस्या का समाधान अच्छे आरटीओ को उपलब्ध कराना चाहिए।

1. एप्लिकेशन को क्लाउड में होस्ट करें 

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

   उदाहरण के लिए, आप क्लाउड में डेटाबेस के साथ एक वर्चुअल मशीन होस्ट कर सकते हैं। एप्लिकेशन एक स्थापित चैनल के माध्यम से या उसी क्लाउड से बाहरी रूप से डेटाबेस से कनेक्ट होगा। यदि क्लस्टर में किसी एक सर्वर में समस्या आती है, तो VM 2 मिनट से भी कम समय में पड़ोसी सर्वर पर पुनः आरंभ हो जाएगा। उसके बाद इसमें DBMS चालू हो जाएगा और कुछ ही मिनटों में डेटाबेस उपलब्ध हो जाएगा।

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

2. एप्लिकेशन को क्लस्टर करें  

   यदि आप आरटीओ में सुधार करना चाहते हैं, तो आप पिछले विकल्प को मजबूत कर सकते हैं और तुरंत क्लस्टर्ड एप्लिकेशन को क्लाउड में रख सकते हैं।

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

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

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

3. आपदा-रोधी बादल की ओर बढ़ें

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

   आरटीओ: 0 की ओर जाता है।
   लागत: सबसे महंगा क्लाउड विकल्प। 
   यह किस चीज़ से आपकी रक्षा नहीं करेगा: यह डेटा भ्रष्टाचार के खिलाफ, साथ ही मानवीय कारक से भी मदद नहीं करेगा, इसलिए एक ही समय में बैकअप बनाने की सिफारिश की जाती है। 

   अभ्यास से: हमारे ग्राहकों में से एक ने एक व्यापक आपदा पुनर्प्राप्ति योजना विकसित की। यह वह रणनीति है जिसे उन्होंने चुना: 

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

   सप्ताह में एक बार, क्लाइंट सुरक्षा का परीक्षण करता है और टेप सहित सभी बैकअप की कार्यक्षमता की जांच करता है। हर साल कंपनी संपूर्ण आपदा प्रतिरोधी क्लाउड का परीक्षण करती है। 

4. किसी अन्य साइट पर प्रतिकृति व्यवस्थित करें 

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

   आरपीओ और आरटीओ: 5 मिनट से. 

   लागत: पहले विकल्प से अधिक महंगा, लेकिन आपदा-प्रूफ क्लाउड में हार्डवेयर प्रतिकृति से सस्ता। कीमत में वीसीएवी लाइसेंस की लागत, प्रशासन शुल्क, क्लाउड संसाधनों की लागत और PAYG मॉडल के अनुसार आरक्षित संसाधनों (बंद किए गए वीएम के लिए काम करने वाले संसाधनों की लागत का 10%) शामिल हैं।

   अभ्यास से: क्लाइंट ने मॉस्को में हमारे क्लाउड में विभिन्न डेटाबेस के साथ 6 वर्चुअल मशीनें रखीं। सबसे पहले, बैकअप द्वारा सुरक्षा प्रदान की गई थी: कुछ बैकअप प्रतियां मॉस्को में क्लाउड में संग्रहीत की गईं, और कुछ हमारी सेंट पीटर्सबर्ग साइट पर संग्रहीत की गईं। समय के साथ, डेटाबेस का आकार बढ़ता गया और बैकअप से पुनर्स्थापित करने में अधिक समय लगने लगा। 
    
   VMware vCloud उपलब्धता पर आधारित प्रतिकृति को बैकअप में जोड़ा गया था। वर्चुअल मशीनों की प्रतिकृतियां सेंट पीटर्सबर्ग में एक बैकअप साइट पर संग्रहीत की जाती हैं और हर 5 मिनट में अपडेट की जाती हैं। यदि मुख्य साइट पर कोई विफलता होती है, तो कर्मचारी स्वतंत्र रूप से सेंट पीटर्सबर्ग में वर्चुअल मशीन की प्रतिकृति पर स्विच करते हैं और इसके साथ काम करना जारी रखते हैं। 

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

5. बैकअप के बारे में मत भूलना

हर कोई जानता है कि आपको बैकअप बनाने की ज़रूरत है, भले ही आपके पास सबसे अच्छा आपदा-प्रूफ समाधान हो। इसलिए मैं आपको संक्षेप में कुछ बिंदु याद दिलाऊंगा।

कड़ाई से बोलते हुए, बैकअप डीआर नहीं है। और यही कारण है: 

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

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

अंतिम आपदा पुनर्प्राप्ति योजना में कम से कम 2 उपकरण होने चाहिए:  

• विकल्प 1-4 में से एक, जो सिस्टम को विफलताओं और गिरावट से बचाएगा।
• डेटा को हानि से बचाने के लिए बैकअप। 

मुख्य इंटरनेट प्रदाता के बंद होने की स्थिति में बैकअप संचार चैनल का ध्यान रखना भी उचित है। और - वोइला! -न्यूनतम वेतन पर डीआर पहले से ही तैयार है। 

स्रोत: www.habr.com