फकप हिट परेड: टेस्टर डे के सम्मान में हमारे पसंदीदा कीड़े के शीर्ष -5

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

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

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

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

कुछ साज़िशों को संरक्षित करने के लिए, प्रत्येक मामले में दो भाग होंगे - यह शुरुआत से कैसे दिखता था, और अंत में हमें क्या पता चला।
तो -

5. अप्रत्याशित प्रभाव से देजा वु

यह कैसा दिखता था:

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

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

वास्तव में क्या:

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

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

और शेड्यूल पर फिर से हमारी प्रणाली ने सिंक्रनाइज़ेशन और गणना की दूसरी प्रतिलिपि लॉन्च की। और दो समानांतर ऑपरेटिंग सिस्टम, एक साथ डेटा को अपडेट करते हुए, अप्रत्याशित स्थितियों का एक अटूट स्रोत हैं।

4. वस्या यहाँ थी!

यह कैसा दिखता था:

क्लाइंट का एक ऑपरेटर हमें लिखता है: “ओह, कूल, आपने दुनिया भर की साइटों पर खुद का विज्ञापन करने का फैसला किया है! अच्छा हुआ, शानदार कार्यक्रम, आपको अपने बारे में जानना चाहिए। लेकिन मुझे यह समझ में नहीं आया कि आप सभी को एक पंक्ति में विज्ञापन क्यों दिखा रहे हैं? "

वास्तव में क्या:

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

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

हमें माफी मांगनी होगी, नुकसान की भरपाई करनी होगी, इत्यादि, इत्यादि। एक बार फिर आप समझते हैं कि सबसे गंभीर गलतियां कार्यक्रम द्वारा नहीं, बल्कि व्यक्ति द्वारा की जाती हैं। या, जैसा कि वे कहते हैं, आप मूर्ख से सुरक्षा प्रदान कर सकते हैं, लेकिन केवल अविवेकी से।

3. कोई भी हमारे समय में विश्वास नहीं कर सकता है। मैं कर सकता हूँ!

यह कैसा दिखता था:

हमारे पास एक रणनीतिक ग्राहक के लिए एक डेमो है। मानक डेमो उसके लिए उपयुक्त नहीं है, हमेशा की तरह, विक्रेता नवीनतम प्रदर्शित करना चाहते हैं, कुछ ऐसा जो कल ही उनके सिर में मौजूद था, और आज भी, अनिश्चित रूप से, कोड में।

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

वास्तव में क्या:

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

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

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

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

2. मेरी तुम्हारी समझ में नहीं आता

यह कैसा दिखता था:

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

वास्तव में क्या:

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

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

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

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

नतीजतन, एक प्रणाली ग्राहकों को भेजी गई जो न केवल उनके लिए बहुत असामान्य थी, बल्कि हमारे लिए भी। और किसी भी प्रश्न ने समर्थन (रूस में भी स्थित) एक स्तूप में डाल दिया - क्योंकि वह बस समझ में नहीं आया कि क्या मतलब था। और प्रोग्रामर मदद नहीं कर सके - और उन्होंने पहली बार सिस्टम को देखा।

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

1. क्रिसमस ट्री ने लगभग क्रिसमस को कैसे बर्बाद कर दिया

यह कैसा दिखता था:

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

वास्तव में क्या:

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

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

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

मुझे उम्मीद है कि इन सभी कहानियों ने आपकी आत्माओं को ऊपर उठाया है या आपको कुछ खाने के लिए दिया है। यदि आपके पास अपने स्वयं के अनुभव से उत्सुक या शिक्षाप्रद कहानियाँ हैं - कृपया टिप्पणियों में साझा करें - यह दिलचस्प है।