डेटा महामारी

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

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

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

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

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

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