तकनीकी भागीदारों की समस्याएं और लघु कथाओं में उनकी रोकथाम

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

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

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

किसी तरह यह सब काम करता है ...

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

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

एक चरम का एक उदाहरण: साथी ने हमें प्रोटोकॉल (SOAP) दिया। ठीक है, यहाँ जावा, यहाँ JCP (क्योंकि GOST EDS था) - हम काम कर रहे हैं। प्रवेश द्वार लिखा है, हमारे परीक्षण एमुलेटर पर सब कुछ काम करता है - हम भागीदारों के साथ परीक्षण पास करते हैं। और ... आप क्या सोचेंगे? काम नहीं करता है! उन्होंने 3 (तीन) महीनों के लिए कारण की खोज की (साथी के समर्थन ने बहुत सुस्त प्रतिक्रिया व्यक्त की और परिणामस्वरूप कनेक्शन समस्या को दोनों कंपनियों के नेतृत्व स्तर पर हल करना पड़ा)। यह पता चला कि दूसरी तरफ SOAP को "छोटी सुविधा" के साथ लागू किया गया था: इसके बजाय

<tagName></tagName> 

भेजने की जरूरत है

 <tagName><\tagName> 

JCP का क्या? इसकी जरूरत नहीं थी, क्योंकि दूसरी तरफ कोई क्रियान्वयन नहीं था।

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

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

क्या कोई लड़का था?

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

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

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

आप विश्वसनीय संरक्षण में हैं।

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

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

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

नियम तीन : स्व-कार्यान्वित पहुंच प्रतिबंध प्रणाली काम नहीं करती है।
निष्कर्ष : मानक और सिद्ध साधनों (लेकिन नियम 5 देखें) के साथ सुरक्षा उपायों को और मजबूत करना आवश्यक है।

प्रशांत महासागर में उपग्रह।

एक बार मेरे मोबाइल पर कॉल आया: “हेलो, एलेक्सी! यह कंपनी **** है (यहाँ प्रसिद्ध कंपनी का नाम है)। आपने हमारे उत्पाद **** के लिए एक अनुरोध छोड़ा है ”। मुझे लगता है कि आप समझते हैं कि अगर मैंने वास्तव में इस उत्पाद के लिए अनुरोध छोड़ा है, तो मैं इसके बारे में यहां नहीं लिखूंगा । जैसा कि यह पता चला, दो मिनट पहले, और हमारे व्यवसाय को एक समान कॉल मिला।
स्थिति सरल हो गई: हमने अपने सिस्टम की ताजा बेक्ड कार्यक्षमता का व्यावसायिक रूप से परीक्षण किया, जिसके परिणामस्वरूप एक रजिस्ट्री एक साथी को हस्तांतरित करने का इरादा था। और भागीदार को यह रजिस्ट्री प्राप्त हुई (मैन्युअल रूप से हमारे वाणिज्य द्वारा ई-मेल द्वारा दूसरी तरफ से प्रबंधक को रजिस्ट्री के प्रारूप की जांच करने के अनुरोध के साथ भेजा गया)। मुझे नहीं पता कि रिमोट की तरफ क्या हुआ था, लेकिन परिणामस्वरूप, वह किसी तरह प्रसंस्करण में लग गया।

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

नियम चार : यदि अनुरोध गलत तरीके से जा सकता है, तो यह गलत तरीके से जाएगा।
निष्कर्ष : नियम 2 देखें।

यहाँ कौन है?

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

एक बार हमें पता: गेटएक्सएक्सएक्सएक्सएक्सपी.ओपी.काम (जहाँ XXX वयस्क नहीं है, लेकिन गेटवे का प्रकार है) के समान पतों वाला गेटवे दिया गया था। क्या यह कहना आवश्यक है कि उत्पादन के पहले सप्ताह के बाद साथी का डीएनएस गिर गया? मुझे लगता है कि यह कहना अतिश्योक्तिपूर्ण होगा कि डीएनएस को बढ़ाने के बाद, उन्होंने रिवर्स ऑर्डर में आईपी पते दिए। लेकिन इस क्षण तक हम पहले से ही "हैरान" थे और प्राथमिक DNS सर्वरों पर भरोसा नहीं करते थे।

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

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

नियम पांच : यदि कोई साथी पहले से ही आपके लिए एक प्रसिद्ध प्रणाली स्थापित कर चुका है, तो इसे एक अलग प्रणाली मानें।
निष्कर्ष : सरलता और तनाव प्रतिरोध (दोनों समर्थन और प्रवेश द्वार)।

(फिर से) कुछ नहीं काम करता है।

ओह, मैंने कितनी बार इस वाक्यांश को सुना ... नूओ ... एक एकाउंटेंट नहीं, बल्कि दूसरी तरफ से तकनीकियों से।

नियम छह : यदि कुछ "टूटा हुआ" है, तो आपको पता नहीं है कि वास्तव में क्या है।
निष्कर्ष : पूर्ण लॉगिंग और सुविधाजनक लॉग प्रस्तुति।

सफेद और शराबी

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

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