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

एक अगला कदम यहां बहुत स्वाभाविक लगता है: परिवर्तनों को एक विश्वसनीय स्टेजिंग वातावरण में धकेलें और परिवर्तनों को आगे बढ़ाने से पहले साझेदारों (क्यूए, पीएम, अन्य इंजीनियरों) को सत्यापन में मदद करें। इसके बाद बग फिक्सिंग और पुनः सत्यापन किया जाएगा जब तक कि हमें विश्वास न हो जाए कि यह उत्पादन के लिए पर्याप्त है। महान!

हालाँकि, अधिकांश संदर्भों में ऐसा होता ही नहीं है। यह विभिन्न कारणों से हो सकता है, लेकिन कारण चाहे जो भी हो, इसका परिणाम यह होता है कि हमें अक्सर उत्पादन सर्वरों में परिवर्तनों को अच्छी तरह से परीक्षण या मान्य करने से पहले ही बढ़ावा देना पड़ता है।

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

आधार रेखा: मेट्रिक्स

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

बिजनेस मेट्रिक्स

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

तकनीकी मेट्रिक्स

एक बार बिजनेस मेट्रिक्स परिभाषित हो जाने के बाद, तकनीकी मेट्रिक्स को समझना भी महत्वपूर्ण है। ये यह सुनिश्चित करने के लिए मौलिक हैं कि सिस्टम स्वस्थ रहें क्योंकि समय के साथ परिवर्तन पेश किए जाते हैं। यहां हम सिस्टम स्थिरता, त्रुटि दर, वॉल्यूम, मशीन क्षमता की कमी आदि के बारे में बात कर रहे हैं।

अच्छे तकनीकी मेट्रिक्स व्यावसायिक मेट्रिक्स में देखी गई समस्याओं को समझाने, या प्रतिगमन के मूल कारण का तुरंत पता लगाने के लिए भी उपयोगी होते हैं। उदाहरण के लिए, मान लें कि हमने पिछले संस्करण के रोलआउट के बाद उपयोगकर्ताओं को किसी विशेष सुविधा के साथ बहुत कम संलग्न होते देखा है। अनुरोध टाइमआउट या त्रुटि दर में वृद्धि से तुरंत पता चल सकता है कि कौन सी सेवाएँ/समाप्ति बिंदु समस्या पैदा कर रहे हैं।

निगरानी

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

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

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

सुरक्षित लैंडिंग

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

स्वचालित परीक्षण

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

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

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

कुत्ता खाना

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

डॉगफूडिंग के लिए अलग-अलग रणनीतियाँ हैं। सरलीकृत अवलोकन के लिए, हम उन्हें दो बड़ी बाल्टियों में समूहित कर सकते हैं:

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

कैनरी रिलीज

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

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

नीला हरा परिनियोजन

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

ब्लू ग्रीन परिनियोजन की तुलना अक्सर कैनरी रिलीज़ से की जाती है जिसकी हमने पहले चर्चा की थी। हम इस चर्चा के विवरण में नहीं जाएंगे, लेकिन यह तय करना महत्वपूर्ण है कि हमारे काम के लिए कौन से उपकरण अधिक उपयुक्त हैं, यह तय करते समय हमें मदद मिलेगी।

किल स्विच और फ़ीचर टॉगल

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

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

 if (feature_is_enabled('feature_x')) {xNewBehaviour();} else {xOldBehaviour();}

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

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

पुराने व्यवहार को सुलभ बनाए रखना

ऊपर दिए गए उदाहरण से शायद हममें से कुछ लोग आश्चर्यचकित रह गए कि क्या यह वास्तव में एक अच्छा पैटर्न है, जिसमें पुराने और नए दोनों व्यवहार एक ही समय में एप्लिकेशन में रहते हैं। मैं इस बात से सहमत हूं कि यह संभवतः वह अंतिम स्थिति नहीं है जो हम अपने कोडबेस के लिए चाहते हैं, अन्यथा, कोड का हर एक टुकड़ा if/else क्लॉज से घिरा होगा, जिससे कोड कुछ ही समय में अपठनीय हो जाएगा।

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

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

छाया परीक्षण

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

 int sum(int a, int b) {int currentResult = currentMathLib.sum(a, b);int newResult = newMathLib.sum(a, b);logDivergences(a, b, currentResult, newResult);return currentResult;}void logSumDivergences(int a, int b, int currentResult, int newResult) {if (currentResult != newResult) {logger.warn(      'Divergence detected when executing {0} + {1}: {2} != {3}',a, b, currentResult, newResult);}}

हालाँकि दोनों योग संचालन निष्पादित किए जाते हैं, नए का उपयोग केवल तुलना करने और विचलन लॉग करने के लिए किया जाता है। यह तकनीक जटिल सिस्टम परिवर्तनों की निगरानी के लिए विशेष रूप से उपयोगी है और हम पुराने और नए व्यवहारों के बीच कुछ समानता की उम्मीद करते हैं। एक और बढ़िया उपयोग का मामला तब होता है जब हमें उन उत्पादों में बदलाव करना होता है जिनसे हम बहुत परिचित नहीं होते हैं, या जब हम अच्छी तरह से नहीं जानते हैं कि इच्छित परिवर्तन से कौन से किनारे के मामले प्रभावित हो सकते हैं।

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

अंत में, यह समझना महत्वपूर्ण है कि किस चीज़ की निगरानी और परीक्षण की आवश्यकता है, और यदि समानता हासिल नहीं की जाती है तो कौन से मानदंड लागू किए जाएंगे। कुछ गंभीर परिदृश्यों में, हमें छाया परीक्षण को तब तक दोहराना होगा जब तक कि परिणाम बिल्कुल समान न हों। दूसरों में, जब नया कार्यान्वयन नुकसान से अधिक अतिरिक्त लाभ प्रदान करता है तो कुछ% विचलन होना ठीक हो सकता है।

लॉग्स

मजबूत सुरक्षा उपायों के बावजूद भी, प्रणालियाँ लड़खड़ा सकती हैं। जब ऐसा होता है, तो हमें यह समझने में सक्षम होने की आवश्यकता है कि क्या हो रहा है, उचित स्तर के विवरण के साथ, अन्यथा, एक कुशल समाधान प्राप्त करना बेहद कठिन हो सकता है। यहां वह जगह है जहां दिन बचाने के लिए लॉग आते हैं।

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

अंतिम विचार

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

सुरक्षित लैंडिंग, हर कोई!